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.
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@xxxxxxxxxx> 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@xxxxxxxxxx
== 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
