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.
While under X it was possible to install a dozen drivers and - mostly - be able to cycle through them (auto detection sucked and continues to suck at matching drivers to hardware via manufacturer/device ids), DRM/KMS drivers are unfortunately another story. You often cannot bring up a KMS driver for one hardware on another and expect to be able to gracefully unload if it’s not supported. There KMS drivers that can’t be installed in parallel (you have to choose which set of cards to support over the other a priori), and there is a ton of legacy hardware that will never get KMS drivers working, ever.