F37 Change: Legacy Xorg Driver Removal (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/LegacyXorgDriverRemoval


== Summary ==

This change will remove the `xorg-x11-drv-vesa` and
`xorg-x11-drv-fbdev` driver packages, and associated support code from
the `xorg-x11-server-Xorg` package.

== Owner ==
* Name: [[User:ajax|Adam Jackson]]
* Email: ajax(a)redhat.com


== Detailed Description ==

Fedora's primary desktop environments are moving away from being X11
sessions, to being Wayland servers in their own right. This transition
is incomplete, and the Xorg server is still potentially used in a
variety of "fallback" situations. In particular the `vesa` and `fbdev`
drivers can find themselves pressed into use when accelerated graphics
is unavailable. Both of these drivers are somewhat deprecated
upstream, and the code to reach them is increasingly fragile as it
gets exercised less and less.

This change will identify the remaining configurations that can reach
these drivers, establish an alternative for display support for each
configuration, and then remove the drivers and their support code in
xserver.

== Feedback ==

None yet.

== Benefit to Fedora ==

* Verified modern supported paths for cases currently handled by vesa/fbdev
* Simpler support/testing matrix for QE
* One less reason to need Xorg installed at all

== Scope ==
* Proposal owners: ajax needs to audit hardware support matrix for
cases that can hit these drivers, and the rest of the OS for places
that can configure them.

* Other developers: Maintainers of other affected components may need
to incorporate some changes, and may wish to look for additional
support code that can be dropped.

* Release engineering: This is mostly ensuring that the two driver
packages are indeed dropped from the compose, etc.

* Policies and guidelines: N/A (not needed for this Change) Although
this is a system-wide change I don't think there's any real policy
impact.

* Trademark approval: N/A (not needed for this Change)

* Alignment with Objectives: Yes, we'd be arguably the First to try this.

== Upgrade/compatibility impact ==

For an upgraded system to notice this change, it would need to be
already using one of these drivers. For cases we can identify where
this would happen without explicit configuration, we will ensure the
display is enabled by some other path or documented as no longer
supported. However, for cases where the driver is set explicitly in
`xorg.conf`, there is no obviously correct remedy that we could do
automatically, and the user will need to fix their X configuration
manually.

== How To Test ==

This should fall out naturally from the normal release testing
process, but we'll expand the details here as the various
configurations are tested and fixed.

== User Experience ==

This change should be largely invisible, but there will likely be
observable changes (for instance, if you end up using a Wayland
session, `$WAYLAND_DISPLAY` will likely no longer be empty). These
will be documented here as we fix the individual cases.

== Dependencies ==

The kernel may need changes to add more drivers for more situations.

The installer and other system-wide configuration tools should be
audited to ensure they don't emit cases that can force vesa/fbdev.

The major desktop environments may need to be fixed to handle more
cases, and may wish to drop code to support the old cases.

== Contingency Plan ==

* Contingency mechanism: ajax reverts the changes.
* Contingency deadline: Beta freeze seems fine.
* Blocks release? No. Partial completion is possible.

== Documentation ==

Just this page so far.

== Release Notes ==

None yet.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[JT]

How will this affect Desktop Developers who are still reliant on x for
their DE/WM to work? For example, I dont have the needed bits in Lumina for
it to work with Wayland.
I'm asking because I dont know how this will or won't affect me and other
desktops in a similar situation.

On Thu, Apr 7, 2022 at 3:57 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:

>  https://fedoraproject.org/wiki/Changes/LegacyXorgDriverRemoval
>
>
>  == Summary ==
>
>  This change will remove the `xorg-x11-drv-vesa` and
>  `xorg-x11-drv-fbdev` driver packages, and associated support code from
>  the `xorg-x11-server-Xorg` package.
>
>  == Owner ==
>  * Name: [[User:ajax|Adam Jackson]]
>  * Email: ajax(a)redhat.com
>
>
>  == Detailed Description ==
>
>  Fedora's primary desktop environments are moving away from being X11
>  sessions, to being Wayland servers in their own right. This transition
>  is incomplete, and the Xorg server is still potentially used in a
>  variety of "fallback" situations. In particular the `vesa` and `fbdev`
>  drivers can find themselves pressed into use when accelerated graphics
>  is unavailable. Both of these drivers are somewhat deprecated
>  upstream, and the code to reach them is increasingly fragile as it
>  gets exercised less and less.
>
>  This change will identify the remaining configurations that can reach
>  these drivers, establish an alternative for display support for each
>  configuration, and then remove the drivers and their support code in
>  xserver.
>
>  == Feedback ==
>
>  None yet.
>
>  == Benefit to Fedora ==
>
>  * Verified modern supported paths for cases currently handled by vesa/fbdev
>  * Simpler support/testing matrix for QE
>  * One less reason to need Xorg installed at all
>
>  == Scope ==
>  * Proposal owners: ajax needs to audit hardware support matrix for
>  cases that can hit these drivers, and the rest of the OS for places
>  that can configure them.
>
>  * Other developers: Maintainers of other affected components may need
>  to incorporate some changes, and may wish to look for additional
>  support code that can be dropped.
>
>  * Release engineering: This is mostly ensuring that the two driver
>  packages are indeed dropped from the compose, etc.
>
>  * Policies and guidelines: N/A (not needed for this Change) Although
>  this is a system-wide change I don't think there's any real policy
>  impact.
>
>  * Trademark approval: N/A (not needed for this Change)
>
>  * Alignment with Objectives: Yes, we'd be arguably the First to try this.
>
>  == Upgrade/compatibility impact ==
>
>  For an upgraded system to notice this change, it would need to be
>  already using one of these drivers. For cases we can identify where
>  this would happen without explicit configuration, we will ensure the
>  display is enabled by some other path or documented as no longer
>  supported. However, for cases where the driver is set explicitly in
>  `xorg.conf`, there is no obviously correct remedy that we could do
>  automatically, and the user will need to fix their X configuration
>  manually.
>
>  == How To Test ==
>
>  This should fall out naturally from the normal release testing
>  process, but we'll expand the details here as the various
>  configurations are tested and fixed.
>
>  == User Experience ==
>
>  This change should be largely invisible, but there will likely be
>  observable changes (for instance, if you end up using a Wayland
>  session, `$WAYLAND_DISPLAY` will likely no longer be empty). These
>  will be documented here as we fix the individual cases.
>
>  == Dependencies ==
>
>  The kernel may need changes to add more drivers for more situations.
>
>  The installer and other system-wide configuration tools should be
>  audited to ensure they don't emit cases that can force vesa/fbdev.
>
>  The major desktop environments may need to be fixed to handle more
>  cases, and may wish to drop code to support the old cases.
>
>  == Contingency Plan ==
>
>  * Contingency mechanism: ajax reverts the changes.
>  * Contingency deadline: Beta freeze seems fine.
>  * Blocks release? No. Partial completion is possible.
>
>  == Documentation ==
>
>  Just this page so far.
>
>  == Release Notes ==
>
>  None yet.
>
>
>  --
>  Ben Cotton
>  He / Him / His
>  Fedora Program Manager
>  Red Hat
>  TZ=America/Indiana/Indianapolis
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it:
>  https://pagure.io/fedora-infrastructure
>

[Samuel Sieb]

On 4/7/22 13:04, JT wrote:
>  How will this affect Desktop Developers who are still reliant on x
> for 
>  their DE/WM to work? For example, I dont have the needed bits in Lumina 
>  for it to work with Wayland.
>  I'm asking because I dont know how this will or won't affect me and 
>  other desktops in a similar situation. 
As long as you aren't using the vesa or fbdev drivers, it won't affect you.

[JT]

On Thu, Apr 7, 2022 at 4:16 PM Samuel Sieb <samuel(a)sieb.net&gt; wrote:

>  On 4/7/22 13:04, JT wrote:
>  > How will this affect Desktop Developers who are still reliant on x for
>  > their DE/WM to work? For example, I dont have the needed bits in Lumina
>  > for it to work with Wayland.
>  > I'm asking because I dont know how this will or won't affect me and
>  > other desktops in a similar situation.
>
>  As long as you aren't using the vesa or fbdev drivers, it won't affect you.
>
>  
Cool, thanks for the info.

[Kevin Kofler]

Ben Cotton wrote:
>  == Owner ==
>  * Name: [[User:ajax|Adam Jackson]]
>  * Email: ajax(a)redhat.com
>  
>  == Detailed Description ==
>  
>  Fedora's primary desktop environments are moving away from being X11
>  sessions, to being Wayland servers in their own right. This transition
>  is incomplete, and the Xorg server is still potentially used in a
>  variety of "fallback" situations. In particular the `vesa` and `fbdev`
>  drivers can find themselves pressed into use when accelerated graphics
>  is unavailable. Both of these drivers are somewhat deprecated
>  upstream, and the code to reach them is increasingly fragile as it
>  gets exercised less and less.
>  
>  This change will identify the remaining configurations that can reach
>  these drivers, establish an alternative for display support for each
>  configuration, and then remove the drivers and their support code in
>  xserver. 
Removing the fallback drivers that (almost) always work strikes me as an 
extraordinarily bad idea. It will knowingly desupport any graphics hardware 
not covered by the main drivers and it may turn out to unknowingly desupport 
even more hardware, where the hardware-specific drivers that should work 
actually do not. It also means that there will be no workaround at all if 
the native driver is temporarily broken on the given hardware for whatever 
reason. Hence, I am strongly opposed to this change.

        Kevin Kofler

[Zbigniew Jędrzejewski-Szmek]

On Thu, Apr 07, 2022 at 03:56:13PM -0400, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/LegacyXorgDriverRemoval
>  
>  
>  == Summary ==
>  
>  This change will remove the `xorg-x11-drv-vesa` and
>  `xorg-x11-drv-fbdev` driver packages, and associated support code from
>  the `xorg-x11-server-Xorg` package.
>  
>  == Owner ==
>  * Name: [[User:ajax|Adam Jackson]]
>  * Email: ajax(a)redhat.com
>  
>  
>  == Detailed Description ==
>  
>  Fedora's primary desktop environments are moving away from being X11
>  sessions, to being Wayland servers in their own right. This transition
>  is incomplete, and the Xorg server is still potentially used in a
>  variety of "fallback" situations. In particular the `vesa` and `fbdev`
>  drivers can find themselves pressed into use when accelerated graphics
>  is unavailable. Both of these drivers are somewhat deprecated
>  upstream, and the code to reach them is increasingly fragile as it
>  gets exercised less and less.
>  
>  This change will identify the remaining configurations that can reach
>  these drivers, establish an alternative for display support for each
>  configuration, and then remove the drivers and their support code in
>  xserver.
>  
>  == Feedback ==
>  
>  None yet.
>  
>  == Benefit to Fedora ==
>  
>  * Verified modern supported paths for cases currently handled by vesa/fbdev
>  * Simpler support/testing matrix for QE
>  * One less reason to need Xorg installed at all
>  
>  == Scope ==
>  * Proposal owners: ajax needs to audit hardware support matrix for
>  cases that can hit these drivers, and the rest of the OS for places
>  that can configure them. 
The crux is: how widespread this is. I know you say "TBD", but do you
have any estimates?

>  For an upgraded system to notice this change, it would need to be
>  already using one of these drivers. For cases we can identify where
>  this would happen without explicit configuration, we will ensure the
>  display is enabled by some other path or documented as no longer
>  supported. However, for cases where the driver is set explicitly in
>  `xorg.conf`, there is no obviously correct remedy that we could do
>  automatically, and the user will need to fix their X configuration
>  manually. 
Could we add a runtime warning to those drivers in F35 and F36?
(That'd need some patch in the code I assume, but that should be
easy to do.) It'd be nice to warn users that their configuration
is becoming obsolete.

Also, I don't think we want to go from "used" to "removed"
directly.
I would very much prefer for the code to remain built for F37, but
require an opt-in. The can even declare the package as unsupported,
"bugs will not be fixed", etc. Inevitably, some users will be caught
off guard and unhappy, and if they have *some* workaround to prolong
the old state, it'll probably save us all a few grey hair.

Zbyszek

[Peter Boy]

>  Am 07.04.2022 um 21:56 schrieb Ben Cotton
> <bcotton(a)redhat.com&gt;:
>  
>  == Detailed Description ==
>  
>  .... In particular the `vesa` and `fbdev`
>  drivers can find themselves pressed into use when accelerated graphics
>  is unavailable. 
I miss or probably don’t understand what will happen when "accelerated graphics is
unavailable" after these drivers will be removed, in cases they are currently in
use.

And I miss any analysis of to what extent and for what these drivers are currently used.
And who and how many will be negatively affected? Who and how many will we bitterly
disappoint with this? And how does this affect our reputation as a (hopefully) reliable
and usable distribution for everyone (which is one of our stated goals). 

It is not purely a technical issue. We have (desktop) users to care about!

And until the above issues are resolved, I am opposed to this change.

Myself, I am one of those who left Fedora Desktop with the arrival of Gnome 3. Another
example of a change, that had a huge negative impact on us as a distribution. Since then I
only, but extensively, use Fedora headless server. In this respect, I am happy with a
serial terminal functionality. But it would be really nice if graphical Anaconda would
continue to work on whatever strange graphics hardware is installed in a server.

[Hans de Goede]

Hi,

On 4/8/22 07:01, Kevin Kofler via devel wrote:
>  Ben Cotton wrote:
> > == Owner ==
> > * Name: [[User:ajax|Adam Jackson]]
> > * Email: ajax(a)redhat.com
> >
> > == Detailed Description ==
> >
> > Fedora's primary desktop environments are moving away from being X11
> > sessions, to being Wayland servers in their own right. This transition
> > is incomplete, and the Xorg server is still potentially used in a
> > variety of "fallback" situations. In particular the `vesa` and `fbdev`
> > drivers can find themselves pressed into use when accelerated graphics
> > is unavailable. Both of these drivers are somewhat deprecated
> > upstream, and the code to reach them is increasingly fragile as it
> > gets exercised less and less.
> >
> > This change will identify the remaining configurations that can reach
> > these drivers, establish an alternative for display support for each
> > configuration, and then remove the drivers and their support code in
> > xserver.
>  
>  Removing the fallback drivers that (almost) always work strikes me as an 
>  extraordinarily bad idea. It will knowingly desupport any graphics hardware 
>  not covered by the main drivers and it may turn out to unknowingly desupport 
>  even more hardware, where the hardware-specific drivers that should work 
>  actually do not. It also means that there will be no workaround at all if 
>  the native driver is temporarily broken on the given hardware for whatever 
>  reason. Hence, I am strongly opposed to this change. 
Note that for Fedora 36 we have already dropped efifb and replaced it
with simpledrm:

https://fedoraproject.org/wiki/Changes/ReplaceFbdevDrivers

So this means that in our default configs we no longer have any
fbdev drivers active.

And simpledrm can also be used with the kernels builtin vesa support
on legacy BIOS systems, so in essence starting with F36 we will always
have a drm/kms node available for the Xorg modesetting to bind to.

With the above Fedora *36* change in place the fbdev/vesa drivers
will be practically completely unused, so I don't really expect
any problems from this change.

As for odd hw out there, a lot of work has been the last couple
of years to make sure that we have drm/kms drivers for almost all
hw out there, esp. also focusing on weird server hw VGA cards.

So most hw will either be new enough to offer an efifb which
simpledrm will turn into a drm/kms /dev/dri/card0 device. Or it
will be old enough that it almost certainly will have
a drm/kms driver.

And for the really odd duck out a vesa mode can be set on the kernel
cmdline which simpledrm should then pick up:

https://www.kernel.org/doc/html/latest/admin-guide/svga.html
https://www.systutorials.com/configuration-of-linux-kernel-video-mode/

So I believe that this change is fine.

Regards,

Hans

[Kamil Paral]

On Thu, Apr 7, 2022 at 10:06 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:

>  https://fedoraproject.org/wiki/Changes/LegacyXorgDriverRemoval
>
>  == Summary ==
>
>  This change will remove the `xorg-x11-drv-vesa` and
>  `xorg-x11-drv-fbdev` driver packages, and associated support code from
>  the `xorg-x11-server-Xorg` package.
>  
Adam, I'm sure this proposal is related to your comment here:
https://bugzilla.redhat.com/show_bug.cgi?id=2067151#c42

Thanks for creating it as a Change.

Can you please clarify what happens to the "basic graphics mode" boot
options on our install media? As I understand it, it's required to let
Fedora boot on systems with unsupported/broken driver graphics. So I assume
this basically means a) old hardware which doesn't get much testing and
drivers bitrot, b) completely new hardware for which the drivers are not
yet ready, and c) nvidia (nouveau has a high failure rate, afaik)? Is this
summary correct? How many nvidia users will get affected? What happens in
any of those cases, will those users not be able to run a Fedora installer
at all? Will they need to run netinst in text mode, or will even text mode
be unsupported? What will they do instead?

In my personal experience, I had to use basic graphics mode on one laptop
which had an extremely old Radeon driver, and Fedora installer simply
didn't boot on it. So the basic graphics mode was a way to at least install
the system, and then I could start experimenting with different kernels or
trying some advice from the net. But the installation must be done first,
in some way.

In a similar fashion, there is sometimes a new GPU launch which is not
supported on our latest stable installer (because it has an old
kernel/mesa), and installing Rawhide is... hard to recommend, not to
mention it's often very broken. So enthusiasts with the latest GPU can
install Fedora using basic graphics mode, and then fully update their
system and switch to a regular driver. What will they do after this Change?

Thanks.

[Kevin Kofler]

Hans de Goede wrote:
>  So most hw will either be new enough to offer an efifb which
>  simpledrm will turn into a drm/kms /dev/dri/card0 device. Or it
>  will be old enough that it almost certainly will have
>  a drm/kms driver.
>   
>  And for the really odd duck out a vesa mode can be set on the kernel
>  cmdline which simpledrm should then pick up:
>   
>  https://www.kernel.org/doc/html/latest/admin-guide/svga.html
>  https://www.systutorials.com/configuration-of-linux-kernel-video-mode/ 
Thanks for the explanation. If that is true, then this change should be more 
acceptable than the partly related "desupport all non-(U)EFI systems" one 
(which I consider entirely unacceptable).

Still, I remain worried about the details, such as:
* that, if VESA is needed, the VESA mode has to be configured through the
  kernel CLI,
* that, as far as I can see, switching to another mode with kernel VESA
  requires a reboot (with different kernel CLI options),
* what will happen to the "basic video mode" boot option (as pointed out by
  Kamil Paral).

      Kevin Kofler

[Demi Marie Obenour]

On 4/8/22 01:01, Kevin Kofler via devel wrote:
>  Ben Cotton wrote:
> > == Owner ==
> > * Name: [[User:ajax|Adam Jackson]]
> > * Email: ajax(a)redhat.com
> >
> > == Detailed Description ==
> >
> > Fedora's primary desktop environments are moving away from being X11
> > sessions, to being Wayland servers in their own right. This transition
> > is incomplete, and the Xorg server is still potentially used in a
> > variety of "fallback" situations. In particular the `vesa` and `fbdev`
> > drivers can find themselves pressed into use when accelerated graphics
> > is unavailable. Both of these drivers are somewhat deprecated
> > upstream, and the code to reach them is increasingly fragile as it
> > gets exercised less and less.
> >
> > This change will identify the remaining configurations that can reach
> > these drivers, establish an alternative for display support for each
> > configuration, and then remove the drivers and their support code in
> > xserver.
>  
>  Removing the fallback drivers that (almost) always work strikes me as an 
>  extraordinarily bad idea. It will knowingly desupport any graphics hardware 
>  not covered by the main drivers and it may turn out to unknowingly desupport 
>  even more hardware, where the hardware-specific drivers that should work 
>  actually do not. It also means that there will be no workaround at all if 
>  the native driver is temporarily broken on the given hardware for whatever 
>  reason. Hence, I am strongly opposed to this change.
>  
>          Kevin Kofler 
Same here.  There needs to be an always-working fallback, even if it
is slow.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Demi Marie Obenour]

On 4/8/22 05:02, Hans de Goede wrote:
>  Hi,
>  
>  On 4/8/22 07:01, Kevin Kofler via devel wrote:
> > Ben Cotton wrote:
> >> == Owner ==
> >> * Name: [[User:ajax|Adam Jackson]]
> >> * Email: ajax(a)redhat.com
> >>
> >> == Detailed Description ==
> >>
> >> Fedora's primary desktop environments are moving away from being X11
> >> sessions, to being Wayland servers in their own right. This transition
> >> is incomplete, and the Xorg server is still potentially used in a
> >> variety of "fallback" situations. In particular the `vesa` and `fbdev`
> >> drivers can find themselves pressed into use when accelerated graphics
> >> is unavailable. Both of these drivers are somewhat deprecated
> >> upstream, and the code to reach them is increasingly fragile as it
> >> gets exercised less and less.
> >>
> >> This change will identify the remaining configurations that can reach
> >> these drivers, establish an alternative for display support for each
> >> configuration, and then remove the drivers and their support code in
> >> xserver.
> >
> > Removing the fallback drivers that (almost) always work strikes me as an 
> > extraordinarily bad idea. It will knowingly desupport any graphics hardware 
> > not covered by the main drivers and it may turn out to unknowingly desupport 
> > even more hardware, where the hardware-specific drivers that should work 
> > actually do not. It also means that there will be no workaround at all if 
> > the native driver is temporarily broken on the given hardware for whatever 
> > reason. Hence, I am strongly opposed to this change.
>  
>  Note that for Fedora 36 we have already dropped efifb and replaced it
>  with simpledrm:
>  
>  https://fedoraproject.org/wiki/Changes/ReplaceFbdevDrivers
>  
>  So this means that in our default configs we no longer have any
>  fbdev drivers active. 
Dropping fbdev is fine if there is nothing using it.

>  And simpledrm can also be used with the kernels builtin vesa support
>  on legacy BIOS systems, so in essence starting with F36 we will always
>  have a drm/kms node available for the Xorg modesetting to bind to. 
That’s okay so long as the modes can be switched at runtime.

>  With the above Fedora *36* change in place the fbdev/vesa drivers
>  will be practically completely unused, so I don't really expect
>  any problems from this change.
>  
>  As for odd hw out there, a lot of work has been the last couple
>  of years to make sure that we have drm/kms drivers for almost all
>  hw out there, esp. also focusing on weird server hw VGA cards.
>  
>  So most hw will either be new enough to offer an efifb which
>  simpledrm will turn into a drm/kms /dev/dri/card0 device. Or it
>  will be old enough that it almost certainly will have
>  a drm/kms driver.
>  
>  And for the really odd duck out a vesa mode can be set on the kernel
>  cmdline which simpledrm should then pick up: 
If this could be made runtime configurable I would be fine with this
change.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Zbigniew Jędrzejewski-Szmek]

On Fri, Apr 08, 2022 at 11:02:53AM +0200, Hans de Goede wrote:
>  Note that for Fedora 36 we have already dropped efifb and replaced
> it
>  with simpledrm:
>  
>  https://fedoraproject.org/wiki/Changes/ReplaceFbdevDrivers
>  
>  So this means that in our default configs we no longer have any
>  fbdev drivers active.
>  
>  And simpledrm can also be used with the kernels builtin vesa support
>  on legacy BIOS systems, so in essence starting with F36 we will always
>  have a drm/kms node available for the Xorg modesetting to bind to.
>  
>  With the above Fedora *36* change in place the fbdev/vesa drivers
>  will be practically completely unused, so I don't really expect
>  any problems from this change.
>  
>  As for odd hw out there, a lot of work has been the last couple
>  of years to make sure that we have drm/kms drivers for almost all
>  hw out there, esp. also focusing on weird server hw VGA cards.
>  
>  So most hw will either be new enough to offer an efifb which
>  simpledrm will turn into a drm/kms /dev/dri/card0 device. Or it
>  will be old enough that it almost certainly will have
>  a drm/kms driver.
>  
>  And for the really odd duck out a vesa mode can be set on the kernel
>  cmdline which simpledrm should then pick up:
>  
>  https://www.kernel.org/doc/html/latest/admin-guide/svga.html
>  https://www.systutorials.com/configuration-of-linux-kernel-video-mode/
>  
>  So I believe that this change is fine. 
It'd be great if this text could be incorporated into the Change
page.

Zbyszek

[Hans de Goede]

Hi,

On 4/8/22 13:18, Kevin Kofler via devel wrote:
>  Hans de Goede wrote:
> > So most hw will either be new enough to offer an efifb which
> > simpledrm will turn into a drm/kms /dev/dri/card0 device. Or it
> > will be old enough that it almost certainly will have
> > a drm/kms driver.
> >  
> > And for the really odd duck out a vesa mode can be set on the kernel
> > cmdline which simpledrm should then pick up:
> >  
> > https://www.kernel.org/doc/html/latest/admin-guide/svga.html
> > https://www.systutorials.com/configuration-of-linux-kernel-video-mode/
>  
>  Thanks for the explanation. If that is true, then this change should be more 
>  acceptable than the partly related "desupport all non-(U)EFI systems" one 
>  (which I consider entirely unacceptable).
>  
>  Still, I remain worried about the details, such as:
>  * that, if VESA is needed, the VESA mode has to be configured through the
>    kernel CLI,
>  * that, as far as I can see, switching to another mode with kernel VESA
>    requires a reboot (with different kernel CLI options), 
Both are correct and are indeed somewhat of a downside, although I'm
not sure if Xorg ever automatically uses vesa as fallback of last
resort, or if this needs manual setup.

>  * what will happen to the "basic video mode" boot option
> (as pointed out by
>    Kamil Paral). 
That is a good question, AFAIK this is just adding nomodeset on the
kernel cmdline, so on UEFI systems we will just end up with simpledrm
using the EFI framebuffer device. I'm not sure what will happen with
legacy BIOS boot here though.

Regards,

Hans

[Mateusz Jończyk]

Hans de Goede wrote:
>  On 4/8/22 13:18, Kevin Kofler via devel wrote:
> > Still, I remain worried about the details, such as:
> > * that, if VESA is needed, the VESA mode has to be configured through the
> > kernel CLI,
> > * that, as far as I can see, switching to another mode with kernel VESA
> > requires a reboot (with different kernel CLI options),
>
>  Both are correct and are indeed somewhat of a downside, although I'm
>  not sure if Xorg ever automatically uses vesa as fallback of last
>  resort, or if this needs manual setup. 
Hello,

I have checked and really Xorg uses VESA as a fallback of last resort without
any configuration, at least in Fedora 36 beta.
I have booted Fedora 36 LiveCD inside QEMU with the default "-vga std"
parameter
and in the boot menu selected Troubleshoot -> "Start using basic graphics
mode".
It used the VESA Xorg driver and the resolution could be switched at runtime.

What about virtual machines?
* Current versions of QEMU default to "-vga std": "Standard VGA card with
Bochs VBE extensions." [1] I have tested Fedora 36 beta and the bochs kernel driver
runs fine with Wayland.

* Older QEMU versions (I have 4.2.1) with the "-vga vmware" parameter do not
support the HW pitchlock and the vmwgfx kernel driver inside
the virtual machine errors out with a "Hardware has no pitchlock" message.
This works nicely with Xorg and the vmware driver, though.

It is also possible that VESA is still used with some cloud providers / etc.,
at least when the virtual machine does not use UEFI.


I have been thinking about writing a KMS version of the uvesafb kernel driver.
The uvesafb driver is able to change VESA modes at runtime using a helper program
that runs in userspace and executes or emulates VBE (VESA BIOS Extensions) code
from the video card BIOS. This will allow Wayland to run on top of VESA/VBE and the user
to switch video modes at runtime, from the GUI.

This is on my TODO list, but I am not experienced enough with kernel development to do it
yet.


After all, I am not convinced that there is much benefit in dropping the vesa
and fbdev Xorg drivers. There are instances when they could be useful, for example
when KMS / other Xorg drivers do not work due to bugs. The user should then be able
to get to a workable desktop and at least easily copy logs and submit a bug report.
I am not a stakeholder here, though.

Greetings,
Mateusz

[1] https://manpages.ubuntu.com/manpages/jammy/man1/qemu-system.1.html

[Adam Jackson]

Apologies for the delay here, but I've updated the change proposal
page based on the feedback in this thread. Please let me know what you
think.

- ajax

On Thu, Apr 7, 2022 at 4:10 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:
>  https://fedoraproject.org/wiki/Changes/LegacyXorgDriverRemoval
>
>
>  == Summary ==
>
>  This change will remove the `xorg-x11-drv-vesa` and
>  `xorg-x11-drv-fbdev` driver packages, and associated support code from
>  the `xorg-x11-server-Xorg` package.
>
>  == Owner ==
>  * Name: [[User:ajax|Adam Jackson]]
>  * Email: ajax(a)redhat.com
>
>
>  == Detailed Description ==
>
>  Fedora's primary desktop environments are moving away from being X11
>  sessions, to being Wayland servers in their own right. This transition
>  is incomplete, and the Xorg server is still potentially used in a
>  variety of "fallback" situations. In particular the `vesa` and `fbdev`
>  drivers can find themselves pressed into use when accelerated graphics
>  is unavailable. Both of these drivers are somewhat deprecated
>  upstream, and the code to reach them is increasingly fragile as it
>  gets exercised less and less.
>
>  This change will identify the remaining configurations that can reach
>  these drivers, establish an alternative for display support for each
>  configuration, and then remove the drivers and their support code in
>  xserver.
>
>  == Feedback ==
>
>  None yet.
>
>  == Benefit to Fedora ==
>
>  * Verified modern supported paths for cases currently handled by vesa/fbdev
>  * Simpler support/testing matrix for QE
>  * One less reason to need Xorg installed at all
>
>  == Scope ==
>  * Proposal owners: ajax needs to audit hardware support matrix for
>  cases that can hit these drivers, and the rest of the OS for places
>  that can configure them.
>
>  * Other developers: Maintainers of other affected components may need
>  to incorporate some changes, and may wish to look for additional
>  support code that can be dropped.
>
>  * Release engineering: This is mostly ensuring that the two driver
>  packages are indeed dropped from the compose, etc.
>
>  * Policies and guidelines: N/A (not needed for this Change) Although
>  this is a system-wide change I don't think there's any real policy
>  impact.
>
>  * Trademark approval: N/A (not needed for this Change)
>
>  * Alignment with Objectives: Yes, we'd be arguably the First to try this.
>
>  == Upgrade/compatibility impact ==
>
>  For an upgraded system to notice this change, it would need to be
>  already using one of these drivers. For cases we can identify where
>  this would happen without explicit configuration, we will ensure the
>  display is enabled by some other path or documented as no longer
>  supported. However, for cases where the driver is set explicitly in
>  `xorg.conf`, there is no obviously correct remedy that we could do
>  automatically, and the user will need to fix their X configuration
>  manually.
>
>  == How To Test ==
>
>  This should fall out naturally from the normal release testing
>  process, but we'll expand the details here as the various
>  configurations are tested and fixed.
>
>  == User Experience ==
>
>  This change should be largely invisible, but there will likely be
>  observable changes (for instance, if you end up using a Wayland
>  session, `$WAYLAND_DISPLAY` will likely no longer be empty). These
>  will be documented here as we fix the individual cases.
>
>  == Dependencies ==
>
>  The kernel may need changes to add more drivers for more situations.
>
>  The installer and other system-wide configuration tools should be
>  audited to ensure they don't emit cases that can force vesa/fbdev.
>
>  The major desktop environments may need to be fixed to handle more
>  cases, and may wish to drop code to support the old cases.
>
>  == Contingency Plan ==
>
>  * Contingency mechanism: ajax reverts the changes.
>  * Contingency deadline: Beta freeze seems fine.
>  * Blocks release? No. Partial completion is possible.
>
>  == Documentation ==
>
>  Just this page so far.
>
>  == Release Notes ==
>
>  None yet.
>
>
>  --
>  Ben Cotton
>  He / Him / His
>  Fedora Program Manager
>  Red Hat
>  TZ=America/Indiana/Indianapolis
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Neal Gompa]

On Wed, Apr 20, 2022 at 3:07 PM Adam Jackson <ajax(a)redhat.com&gt; wrote:
>  Apologies for the delay here, but I've updated the change proposal
>  page based on the feedback in this thread. Please let me know what you
>  think.
>  
You noted Parallels Desktop, which is actually a fair point I forgot about.

Fortunately, as long as Fedora and RHEL support VirGL and virtio-gpu,
I think we're good there: https://kb.parallels.com/en/128518

This is especially important for being able to run Fedora and RHEL 9+
on ARM Macs as VMs, since this is how they support Linux graphics now.



--
真実はいつも一つ！/ Always, there's only one truth!

[Zbigniew Jędrzejewski-Szmek]

On Wed, Apr 20, 2022 at 03:06:33PM -0400, Adam Jackson wrote:
>  I've updated the change proposal page based on the feedback in
> this
>  thread. Please let me know what you think. 
I love it. It's funny to read but very clear.

One suggestion: collect the diagnostics commadn in a pastable string that
will print either "not affected" or "system is using fbdev" or
"system is using vesa"
and ask people to report such systems to fedora-devel.
It would be great to know if there are such systems out there.

Zbyszek

[Adam Williamson]

On Wed, 2022-04-20 at 15:06 -0400, Adam Jackson wrote:
>  Apologies for the delay here, but I've updated the change
> proposal
>  page based on the feedback in this thread. Please let me know what you
>  think. 
To echo what Kamil and Kevin said earlier: I'm fine with this so long
as we still have a viable fallback path option that generally works on
hardware which is broken with native drivers for whatever reason. I
don't really care how that is implemented. It doesn't even need to be
set up so that booting with `nomodeset` triggers it, really - it's easy
enough to change the bootloader configs of the installer/live images to
do something else if necessary. I just want it to be explicitly part of
the Change's scope that a replacement fallback path (for both BIOS and
UEFI, as long as we keep BIOS support around):

* Exists
* Generally works
* Is available from installer/live images in the same way as currently

If this is possible only for UEFI but not for BIOS, I'd feel much more
conflicted about the Change.

Right now it's not entirely clear whether this is considered part of
the Change scope or not. The paragraph about the `uvesafb` driver seems
kind of aspirational and doesn't seem to commit to anything. The
"Benefit to Fedora" section states "Verified modern supported paths for
cases currently handled by vesa/fbdev", but I'm not 100% clear what is
meant by that.

Thanks!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Kevin Kofler]

Adam Williamson wrote:
>  Right now it's not entirely clear whether this is considered part
> of
>  the Change scope or not. The paragraph about the `uvesafb` driver seems
>  kind of aspirational and doesn't seem to commit to anything. The
>  "Benefit to Fedora" section states "Verified modern supported paths for
>  cases currently handled by vesa/fbdev", but I'm not 100% clear what is
>  meant by that. 
IMHO, it is not acceptable to remove the vesa driver without having 
something like uvesafb to replace it.

        Kevin Kofler

[Adam Jackson]

On Wed, Apr 20, 2022 at 6:06 PM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org&gt; wrote:
>  Adam Williamson wrote:
>  > Right now it's not entirely clear whether this is considered part of
>  > the Change scope or not. The paragraph about the `uvesafb` driver seems
>  > kind of aspirational and doesn't seem to commit to anything. The
>  > "Benefit to Fedora" section states "Verified modern supported paths
> for
>  > cases currently handled by vesa/fbdev", but I'm not 100% clear what is
>  > meant by that.
>
>  IMHO, it is not acceptable to remove the vesa driver without having
>  something like uvesafb to replace it. 
I like how I'm being told _not_ to find out where the remaining bugs
are in our native drivers, and instead preserve something awful for
eternity.

- ajax

[Adam Williamson]

On Thu, 2022-04-21 at 10:10 -0400, Adam Jackson wrote:
>  On Wed, Apr 20, 2022 at 6:06 PM Kevin Kofler via devel
>  <devel(a)lists.fedoraproject.org&gt; wrote:
>  > 
>  > Adam Williamson wrote:
>  > > Right now it's not entirely clear whether this is considered part of
>  > > the Change scope or not. The paragraph about the `uvesafb` driver seems
>  > > kind of aspirational and doesn't seem to commit to anything. The
>  > > "Benefit to Fedora" section states "Verified modern supported
> paths for
>  > > cases currently handled by vesa/fbdev", but I'm not 100% clear what
> is
>  > > meant by that.
>  > 
>  > IMHO, it is not acceptable to remove the vesa driver without having
>  > something like uvesafb to replace it.
>  
>  I like how I'm being told _not_ to find out where the remaining bugs
>  are in our native drivers, and instead preserve something awful for
>  eternity. 
Well, come on, you're not being "told" anything. Neither me nor Kevin
is your boss. This is a Change proposal, it's sent to this list for
people to discuss it and provide feedback on it. That's what we're
doing.

From my perspective, it's fine to find bugs in native drivers, but if a
user is hitting such a bug and has no obvious way to get around it, we
are in danger of giving them a negative perception of Fedora and losing
them as a user. We know this is not an academic case: we have an active
bug right now where we have two people with NVIDIA cards which do not
work with nouveau, but "basic graphics mode" works (now xorg-x11-drv-
vesa has been fixed). Is that going to get fixed in the next few days?
If not, Fedora 36 will ship that way, and anyone with one of those
cards is going to be grateful that "basic graphics mode" exists.

I'm also not sure I agree it's clear that we'd find more bugs if the
fallback path didn't exist. People don't usually just boot straight in
"basic graphics mode", after all. They try a regular boot, and if it
fails, maybe they try "basic graphics mode". So they already *know*
there's a bug - and at least this way we give them a working system and
maybe they'd be more motivated to file the bug than if we just leave
them stuck. We *do* get bug reports when this happens, it's not like we
never hear about these experiences.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Adam Jackson]

On Thu, Apr 21, 2022 at 10:10 AM Adam Jackson <ajax(a)redhat.com&gt; wrote:
>  On Wed, Apr 20, 2022 at 6:06 PM Kevin Kofler via devel
>  <devel(a)lists.fedoraproject.org&gt; wrote:
>  >
>  > Adam Williamson wrote:
>  > > Right now it's not entirely clear whether this is considered part of
>  > > the Change scope or not. The paragraph about the `uvesafb` driver seems
>  > > kind of aspirational and doesn't seem to commit to anything. The
>  > > "Benefit to Fedora" section states "Verified modern supported
> paths for
>  > > cases currently handled by vesa/fbdev", but I'm not 100% clear what
> is
>  > > meant by that.
>  >
>  > IMHO, it is not acceptable to remove the vesa driver without having
>  > something like uvesafb to replace it.
>
>  I like how I'm being told _not_ to find out where the remaining bugs
>  are in our native drivers, and instead preserve something awful for
>  eternity. 
Turns out the support story is less bad than I thought, the simpledrm
change was more powerful than I knew. I've updated the change again
but the short story is vga= on kcmdline will give you just as good of
support as UEFI framebuffer.

- ajax

[Demi Marie Obenour]

On 4/21/22 12:35, Adam Williamson wrote:
>  On Thu, 2022-04-21 at 10:10 -0400, Adam Jackson wrote:
> > On Wed, Apr 20, 2022 at 6:06 PM Kevin Kofler via devel
> > <devel(a)lists.fedoraproject.org&gt; wrote:
> >>
> >> Adam Williamson wrote:
> >>> Right now it's not entirely clear whether this is considered part of
> >>> the Change scope or not. The paragraph about the `uvesafb` driver seems
> >>> kind of aspirational and doesn't seem to commit to anything. The
> >>> "Benefit to Fedora" section states "Verified modern supported
> paths for
> >>> cases currently handled by vesa/fbdev", but I'm not 100% clear what
> is
> >>> meant by that.
> >>
> >> IMHO, it is not acceptable to remove the vesa driver without having
> >> something like uvesafb to replace it.
> >
> > I like how I'm being told _not_ to find out where the remaining bugs
> > are in our native drivers, and instead preserve something awful for
> > eternity.
>  
>  Well, come on, you're not being "told" anything. Neither me nor Kevin
>  is your boss. This is a Change proposal, it's sent to this list for
>  people to discuss it and provide feedback on it. That's what we're
>  doing.
>  
>  From my perspective, it's fine to find bugs in native drivers, but if a
>  user is hitting such a bug and has no obvious way to get around it, we
>  are in danger of giving them a negative perception of Fedora and losing
>  them as a user. We know this is not an academic case: we have an active
>  bug right now where we have two people with NVIDIA cards which do not
>  work with nouveau, but "basic graphics mode" works (now xorg-x11-drv-
>  vesa has been fixed). Is that going to get fixed in the next few days?
>  If not, Fedora 36 will ship that way, and anyone with one of those
>  cards is going to be grateful that "basic graphics mode" exists.
>  
>  I'm also not sure I agree it's clear that we'd find more bugs if the
>  fallback path didn't exist. People don't usually just boot straight in
>  "basic graphics mode", after all. They try a regular boot, and if it
>  fails, maybe they try "basic graphics mode". So they already *know*
>  there's a bug - and at least this way we give them a working system and
>  maybe they'd be more motivated to file the bug than if we just leave
>  them stuck. We *do* get bug reports when this happens, it's not like we
>  never hear about these experiences. 
Could basic graphics mode use the EFI framebuffer on EFI systems?

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[Javier Martinez Canillas]

On Thu, Apr 21, 2022 at 10:09 PM Demi Marie Obenour
<demiobenour(a)gmail.com&gt; wrote:
>  
[snip]

> > I'm also not sure I agree it's clear that we'd find more bugs if
the
> > fallback path didn't exist. People don't usually just boot straight in
> > "basic graphics mode", after all. They try a regular boot, and if it
> > fails, maybe they try "basic graphics mode". So they already *know*
> > there's a bug - and at least this way we give them a working system and
> > maybe they'd be more motivated to file the bug than if we just leave
> > them stuck. We *do* get bug reports when this happens, it's not like we
> > never hear about these experiences.
>  
> Could basic graphics mode use the EFI framebuffer on EFI
systems?
>  
It does already.

Best regards,
Javier

[Kevin Kofler]

Adam Jackson wrote:
>  Turns out the support story is less bad than I thought, the
> simpledrm
>  change was more powerful than I knew. I've updated the change again
>  but the short story is vga= on kcmdline will give you just as good of
>  support as UEFI framebuffer. 
Or rather, as bad of support, because the obvious issue with "give me a 
framebuffer and I'll draw to it" is that the framebuffer is fixed and there 
is no way to change the resolution at runtime (issue which you have 
correctly mentioned in the change description).

Though of course xorg-x11-drv-vesa bypasses KMS and talks directly to the 
VESA BIOS to set modes.

        Kevin Kofler

[Adam Williamson]

On Thu, 2022-04-21 at 13:32 -0400, Adam Jackson wrote:
>  On Thu, Apr 21, 2022 at 10:10 AM Adam Jackson <ajax(a)redhat.com&gt;
> wrote:
>  > 
>  > On Wed, Apr 20, 2022 at 6:06 PM Kevin Kofler via devel
>  > <devel(a)lists.fedoraproject.org&gt; wrote:
>  > > 
>  > > Adam Williamson wrote:
>  > > > Right now it's not entirely clear whether this is considered part of
>  > > > the Change scope or not. The paragraph about the `uvesafb` driver seems
>  > > > kind of aspirational and doesn't seem to commit to anything. The
>  > > > "Benefit to Fedora" section states "Verified modern
> supported paths for
>  > > > cases currently handled by vesa/fbdev", but I'm not 100% clear
> what is
>  > > > meant by that.
>  > > 
>  > > IMHO, it is not acceptable to remove the vesa driver without having
>  > > something like uvesafb to replace it.
>  > 
>  > I like how I'm being told _not_ to find out where the remaining bugs
>  > are in our native drivers, and instead preserve something awful for
>  > eternity.
>  
>  Turns out the support story is less bad than I thought, the simpledrm
>  change was more powerful than I knew. I've updated the change again
>  but the short story is vga= on kcmdline will give you just as good of
>  support as UEFI framebuffer. 
If we can do the "make basic graphics mode do vga=ask and then write
the chosen config to the installed system bootloader" thing, then that
sounds sufficient to me. That will require co-ordination with the
anaconda team, though (and I think with bcl to get the necessary
changes into the image bootloader configurations).

Thanks for looking into it!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Brian C. Lane]

On Wed, Apr 27, 2022 at 04:41:18PM -0700, Adam Williamson wrote:
>  
>  If we can do the "make basic graphics mode do vga=ask and then write
>  the chosen config to the installed system bootloader" thing, then that
>  sounds sufficient to me. That will require co-ordination with the
>  anaconda team, though (and I think with bcl to get the necessary
>  changes into the image bootloader configurations). 
Or a PR on the config files. Which will be changing soon, I hope.

https://github.com/weldr/lorax/tree/master/share/templates.d/99-generic/c...

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart