support for undocumented 'xforcevesa' boot option should be dropped?

[Steve Langasek]

https://git.launchpad.net/casper/tree/scripts/casper-bottom/20xconfig implements a boot option for live images called 'xforcevesa', which is intended to be an option to generate a "failsafe" xorg.conf using the vesa driver.

The option is not used in the grub menu on any current images; the safe graphics mode we use sets 'nomodeset'.

The option is not documented anywhere; a Google search for 'ubuntu xforcevesa' gives as a first result https://askubuntu.com/questions/4985/why-does-the-xforcevesa-command-throw-me-onto-the-command-line, which is a post from *2010* (the option was implemented in 2009) saying that it doesn't work.

Trying the option manually in a qemu VM using a qxl video device and UEFI firmware boots successfully to the desktop, but /var/log/Xorg.0.log shows that the vesa driver was not used and it auto-probed qxl anyway and used that for the display. (The vesa failure was: xf86EnableIO: failed to enable I/O ports 0000-03ff (Operation not permitted))

The behavior is the same using a VGA video device in qemu.

If I boot in a VM using qxl but BIOS firmware instead of UEFI, I do not get the same error about "Operation not permitted" in the logs, but the qxl driver still winds up being used instead of vesa; vesa is "Ignoring device with a bound kernel driver".

So I think this script should just be dropped as obsolete?

[Daniel van Vugt (vanvugt)]

I've never heard of the 'xforcevesa' option and don't expect virtual machines to use it either. The fallback path when a machine doesn't support 'modeset' is for Xorg to use the 'fbdev' driver. Never the 'vesa' driver because the kernel supports VESA BIOS Extensions using the fbdev API. So Xorg then uses 'fbdev' on VESA (BIOS Extensions) systems.

To actually *need* the Xorg vesa driver I think you would have:
 * A legacy BIOS, not EFI; and
 * An old kernel that doesn't have 'vesafb' to abstract VESA BIOS extensions into fbdev.