3 ms·

What KMS driver will attempt to bind to unsupported hardware, and which other KMS driver would you be attempting to replace it with in that scenario?

by mjg59 4y ago

ComputerGuru 4y ago
We had dependency conflicts between the latest separate releases for both older and newer nVidia hardware (obviously all complaints should be directed at nVidia there), and issues with the latest AMD drivers for their older devices panicking on unload in the presence of certain newer hardware and/or issues loading KMS for the newer products at the same time time as the separate driver for the older. Can’t remember the specifics but we had to load and try them in a certain order (not having a perfect map of hardware ids).
- mjg59 4y ago
  Parallel shipping of the various versions of the proprietary stack is definitely more tedious than it should be, but the PCI IDs that they support are declared in the module metadata and only the appropriate version will be bound to the hardware by the kernel. The scenarios where you'll have trouble are where an in-kernel driver has bound before the proprietary one (eg, nouveau) and potentially left the card in a state the proprietary driver isn't expecting. But the answer there is not to simultaneously ship both the free and the proprietary stacks.
  - ComputerGuru 4y ago
    > in-kernel driver has bound before the proprietary one (eg, nouveau) and potentially left the card in a state the proprietary driver isn't expecting Thanks for reminding me of that - we definitely ran into that some. It wasn’t always with proprietary drivers, though. I think there were cases where legacy intel or amd cards would be incorrectly brought up by the old non-KMS drivers and then the KMS driver wouldn’t load, or maybe vice-versa as there were definitely specific cards within generations of chipsets that were documented as working under KMS/DRM failing and we would have to resort to the legacy drivers. > But the answer there is not to simultaneously ship both the free and the proprietary stacks. We didn’t really have a choice given that there wasn’t a one-size-fits-all driver (we didn’t try simpledrm - iirc it went through phases of breakage). But truth be told, while nvidia was the worst and most painful to deploy and upgrade, aside from the issue that we had to choose which version of the nvidia driver we wanted to ship (until we got the conflicting shared dependencies situation worked out by hot swapping the components before loading the driver), it was the most likely to work with all the cards it advertised support for. Only issue there was older cards not supported on current kernel versions or lacking drm drivers altogether.

What KMS driver will attempt to bind to unsupported hardware, and which other KMS driver would you be attempting to replace it with in that scenario?

by mjg59 4y ago

What KMS driver will attempt to bind to unsupported hardware, and which other KMS driver would you be attempting to replace it with in that scenario?

ComputerGuru 4y ago

We had dependency conflicts between the latest separate releases for both older and newer nVidia hardware (obviously all complaints should be directed at nVidia there), and issues with the latest AMD drivers for their older devices panicking on unload in the presence of certain newer hardware and/or issues loading KMS for the newer products at the same time time as the separate driver for the older. Can’t remember the specifics but we had to load and try them in a certain order (not having a perfect map of hardware ids).

mjg59 4y ago
Parallel shipping of the various versions of the proprietary stack is definitely more tedious than it should be, but the PCI IDs that they support are declared in the module metadata and only the appropriate version will be bound to the hardware by the kernel. The scenarios where you'll have trouble are where an in-kernel driver has bound before the proprietary one (eg, nouveau) and potentially left the card in a state the proprietary driver isn't expecting. But the answer there is not to simultaneously ship both the free and the proprietary stacks.
- ComputerGuru 4y ago
  > in-kernel driver has bound before the proprietary one (eg, nouveau) and potentially left the card in a state the proprietary driver isn't expecting Thanks for reminding me of that - we definitely ran into that some. It wasn’t always with proprietary drivers, though. I think there were cases where legacy intel or amd cards would be incorrectly brought up by the old non-KMS drivers and then the KMS driver wouldn’t load, or maybe vice-versa as there were definitely specific cards within generations of chipsets that were documented as working under KMS/DRM failing and we would have to resort to the legacy drivers. > But the answer there is not to simultaneously ship both the free and the proprietary stacks. We didn’t really have a choice given that there wasn’t a one-size-fits-all driver (we didn’t try simpledrm - iirc it went through phases of breakage). But truth be told, while nvidia was the worst and most painful to deploy and upgrade, aside from the issue that we had to choose which version of the nvidia driver we wanted to ship (until we got the conflicting shared dependencies situation worked out by hot swapping the components before loading the driver), it was the most likely to work with all the cards it advertised support for. Only issue there was older cards not supported on current kernel versions or lacking drm drivers altogether.