Re: Removal of vesa and fbdev X.org drivers from Rawhide

[Sérgio Basto]

On Tue, 2024-10-08 at 11:02 +0200, Javier Martinez Canillas wrote:
> Peter Robinson  writes:
>
> Hello Peter and Adam,
> > Hi Adam,
> > > I noticed that the vesa and fbdev X.org drivers were recently
> > > retired
> > > from Rawhide. There appears to be no Change for this. The commit
>
> I remember that there was a Change for this filed by Ajax some time
> ago:
>
> https://fedoraproject.org/wiki/Changes/LegacyXorgDriverRemoval
>
> but I see now that FESCo didn't approve it at the time:
>
> https://pagure.io/fesco/issue/3059#comment-875144
>
> So I guess that Peter's commit needs to be reverted...
>
> This is partially my fault, because Peter did ask me if I thought
> that it
> is time to drop the xorg-x11-drv-{vesa,fbdev} DDX drivers and I said
> yes.

This information is interesting , but remove of vesa , fbdev on Fedora
was not Peter ...

As stated in F37 Change: Legacy Xorg Driver Removal (System-Wide Change
proposal)
https://fedoraproject.org/wiki/Changes/LegacyXorgDriverRemoval

nomodeset can be replaced by vga=ask and vesa and fbdev drivers can be
an alias of modesetting drive

That is the point for me, if we have an replacement there is no point
on keeping old code.

we are revisiting 
https://lists.fedoraproject.org/archives/list/[e-mail]/...

and after reading a bit, I support Adam's decision and I'm convinced
that is the correct
> > > messages for the retirements refer to this old Change:
> > >
> > > https://fedoraproject.org/wiki/Changes/ReplaceFbdevDrivers#Detailed_Descript...
> > >
> > > but that Change was for Fedora 36, and was considered "completed"
> > > at
> > > the time with no removal of any X.org drivers. The scope of that
> > > Change
> > > says nothing about retiring X.org drivers.
> > >
> > > This has had at least one substantial impact that somebody
> > > noticed:
> > > https://lists.fedoraproject.org/archives/list/[e-mail]/m...
> > >
> > > booting with 'nomodeset', which has decades of history as a
> > > standard
> > > workaround for having some kind of issue with the native driver
> > > for
> > > your hardware, no longer works, it seems.
>
> Yes, agreed that we shouldn't break that.
> > > To me this is a significant change which maybe should be a
> > > Change, not
> > > just slipped in with reference to a Change from six releases ago
> > > which
> > > did not have this in its scope.
>
> Yeah, probably Ajax's proposal could be revisited.
> > In all fallback cases it should be using simpledrm and the
> > associated
> > mesa driver. There's been a number of changes since the original F-
> > 36
> > change that has moved a bunch of that stuff forward to the point
> > that
> > there's little to no fbdev left, did you mean vesa?
> >
> > I don't see enough info on that thread to tell.
>
> I believe this could be a problem for x86 legacy BIOS systems that
> are not
> setting a VGA mode using the "vga=" kernel cmdline parameter. Since
> in that
> case a VESA mode isn't set and so a "simple-framebuffer" device won't
> be
> registered and match the simpledrm driver.
>
> In those cases, probably just goes from vgacon -> Xorg + xorg-x11-
> drv-vesa.
> The user won't have a fbcon/VT, but at least will get Xorg working
> with the
> user-space vesa driver.
>
> A solution could be for Anaconda to add a "vga=ask" or "vga=795" (a
> default
> resolution of 1920x1080) to the kernel cmdline or the "safe graphics
> mode"
> entry. That way, a "simple-framebuffer" device will be registered by
> sysfb
> and the simpledrm driver probed.
>
> Then users will have both a fbcon/VT and could even start a wayland
> session
> even in the "safe graphics mode".
> > P
>
> -- 
> Best regards,
>
> Javier Martinez Canillas
> Core Platforms
> Red Hat