5 ms·

I remember using Xvesa in the 00's on 90's hardware with great success. Damn Small Linux, etc. iirc, -vesa got kinda bad after the advent of the "GPU". Cards d

I remember using Xvesa in the 00's on 90's hardware with great success. Damn Small Linux, etc. iirc, -vesa got kinda bad after the advent of the "GPU". Cards didn't natively support VBE and emulated a subset of it just for compatibility purposes. It's gotten worse these days. I don't know if I'd call it a bad thing though - with the push for hardware accelerated rendering to help with battery life on portable devices, many of the desktop environments have lost support for "software" graphics. They instead depend on software OpenGL support via llvmpipe and chug hard even on modern devices (if you don't have a driver installed) and VMs.

mjg59 4y ago
Some degree of VBE is required for Windows to boot in BIOS mode (and even in EFI mode before Windows 8 for really tedious reasons). I'd expect it to be fine for basic mode setting, but you're still stuck with the modes the card firmware provides which means it's probably 4:3 ratios.
- bibaheu 4y ago
  What are those tedious reasons? Like when booting on very old hardware, you got a Vista-like splash screen on Win7?
  - mjg59 4y ago
    Some part of the boot stack expected to be able to make VBE calls to set the inital screen mode before loading actual drivers, which means hardware that wants to support Windows 7 needs to provide a CSM layer to support that even if it's otherwise booting via EFI (the CSM layer just rewrites VBE calls into EFI GOP calls, so the graphics card doesn't need to provide VBE itself)
ComputerGuru 4y ago
While it’s true that having a better proliferation of hardware accelerated displays in use is a net win, you can’t discount the need to be able to bring up a GUI on generic hardware without knowing the underlying stack in advance. 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.
- 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.
userbinator 4y ago
Cards didn't natively support VBE and emulated a subset of it just for compatibility purposes. What do you mean by "natively support VBE" or "emulated"? VBE is just a set of functions in the VBIOS to do modesetting and get information about the modes.
- Teknoman117 4y ago
  It also has some calls to have the card do accelerated blitting on later versions.
  - userbinator 4y ago
    That's VBE/AF but I'm not aware of any VBIOS that actually contained the VBE/AF extension functionality, despite that being the original goal; instead, VBE/AF mainly exists as a TSR "soft VBIOS" and only for relatively few early GPUs.

mjg59 4y ago

Some degree of VBE is required for Windows to boot in BIOS mode (and even in EFI mode before Windows 8 for really tedious reasons). I'd expect it to be fine for basic mode setting, but you're still stuck with the modes the card firmware provides which means it's probably 4:3 ratios.

bibaheu 4y ago
What are those tedious reasons? Like when booting on very old hardware, you got a Vista-like splash screen on Win7?
- mjg59 4y ago
  Some part of the boot stack expected to be able to make VBE calls to set the inital screen mode before loading actual drivers, which means hardware that wants to support Windows 7 needs to provide a CSM layer to support that even if it's otherwise booting via EFI (the CSM layer just rewrites VBE calls into EFI GOP calls, so the graphics card doesn't need to provide VBE itself)

ComputerGuru 4y ago

While it’s true that having a better proliferation of hardware accelerated displays in use is a net win, you can’t discount the need to be able to bring up a GUI on generic hardware without knowing the underlying stack in advance. 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.

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.

userbinator 4y ago

Cards didn't natively support VBE and emulated a subset of it just for compatibility purposes. What do you mean by "natively support VBE" or "emulated"? VBE is just a set of functions in the VBIOS to do modesetting and get information about the modes.

Teknoman117 4y ago
It also has some calls to have the card do accelerated blitting on later versions.
- userbinator 4y ago
  That's VBE/AF but I'm not aware of any VBIOS that actually contained the VBE/AF extension functionality, despite that being the original goal; instead, VBE/AF mainly exists as a TSR "soft VBIOS" and only for relatively few early GPUs.