How does EFI affect the operation of iron?

Question

Iron

Greetings!
Recently, I was surprised to find that the same computer behaves differently in LEGACY and EFI modes.
There is self-written software that works with video cameras. It is based on some kind of open source video capture driver. So, this driver, if you switch to EFI mode, it stops recognizing the addressing of capture cards. Drives all calls to 0xFFFFFF and, of course, nothing works. To be honest, I've always assumed that EFI is the same as BIOS, only with GPT support, but apparently that's not the case.
As they say, any ideas, guys?

Answer 1

Very influential.
UEFI is not just a piece of some firmware in a small mikruha, but it can be regarded as a second OS, in normal mode it takes on most of the hardware initialization, verification of firmware signing keys in the same PCI devices, and in general, dofiga what can be stumbled there and depends on the imagination of the MP developer.
Modern hardware is already being developed taking into account the UEFI requirements for hardware, old devices, respectively, are not up to date with fashion trends, and it’s unlikely that they will ever receive a firmware update for correct operation, it’s not even the greed of the manufacturer of the old piece of iron and the unwillingness to bother, but quite architectural troubles.
On desktop mothers, as a rule, the choice is only from UEFI / Legasy for everything in a crowd, on server ones, you can often find a compatibility configuration for each device and makes it possible to disable the intervention of UEFI modules in its operation for the device.
PS I did not understand deeply the question "how to make it work", there is simply no such need.

Answer 2

The answer to the question in my case is as follows:
In the LEGACY mode "unknown" devices received an "advance" IRQ. When booting in UEFI mode, they did not receive it, respectively. Therefore, the driver, implemented as a service, without seeing the IRQ, drove calls somewhere in the direction of NULL.
The solution is to initialize the device with any driver so that it ceases to be "unknown" and receives an interrupt. Then, a universal driver-service works with it, at a low level, ignoring the "firewood" assigned to the device in the manager.