Skip to content

Conversation

@stefan11111
Copy link
Contributor

Part of reverting #1564

It didn't fix #1565

The pr can land later, but needs a lot more discussion.

v3: #1587
Make fb slot checks even tighter.
Now an autoconfigured fb slot can only be claimed if no other slots were claimed.
We can enforce the reverse too, to not allow other kinds of slots
to be claimed an autoconfigured fb slot is claimed.
I didn't add this now to keep the changes as simple as possible.

@stefan11111 stefan11111 force-pushed the no-fb-autoconfigure-v3 branch 3 times, most recently from 9177b14 to 2f61969 Compare December 12, 2025 17:21
stefan11111 added a commit to stefan11111/xserver that referenced this pull request Dec 12, 2025
This patch adds a check that prevents xf86ClaimFbSlot
from claiming already used slots.

Drivers like xf86-video-fbdev can drive almost anything.
This makes it an excellent fallback driver, useful when the
proper driver breaks, or on livecd's.

Sadly, this also means that it can collide with other drivers,
using the same pci slot as them.
This usually doesn't lead to broken graphics, since the dedicated
drivers usually take priority, and the device ignores the fbdev interface.'

This means that when autoconfiguring, if the fbdev driver is installed,
the X server will likely use it, and that can lead to 2 X11 screens being
initializes on the same physical device, one being the dedicated driver
the user intended to use, another being fbdev.

This configuration is suboptimal and can break glx.

v1: X11Libre#1581

v2: X11Libre#1587
Siplify the checks and make them driver-independent.

v3: X11Libre#1650
Make fb slot checks even tighter.
Now an autoconfigured fb slot can only be claimed if no other slots were claimed.
We can enforce the reverse too, to not allow other kinds of slots
to be claimed an autoconfigured fb slot is claimed.
I didn't add this now to keep the changes as simple as possible.

Fixes: X11Libre#1505
Fixes: X11Libre#1565

Fixes: X11Libre@d3fd8c3
Fixes: X11Libre@d09b3da
Fixes: X11Libre@22d963b

Fixes: https://gitlab.freedesktop.org/xorg/driver/xf86-video-fbdev/-/issues/9
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/commit/fc78bcca21e767697de6ad4d8e03b6728856f613
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/commit/a8e41a81909ef74faa38ef12ca35c5d83f7c56a5
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/commit/728b54528d37ffa27b07c9b181c5ed8d2d359379
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1798
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1826

Heavily inspired by X11Libre#1564

Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
@stefan11111 stefan11111 changed the title No fb autoconfigure v3 Fix X server autoconfigure when framebuffer drivers are installed v3 Dec 12, 2025
@ONykyf
Copy link
Contributor

ONykyf commented Dec 15, 2025

This is too tight. You have said yourself that fbdev is a good fallback driver, so why not allow it to be autoconfigured if nothing else works?

Here is how it works with #1564

[2025-12-15 07:52:16] (II) modesetting: platform device "/dev/dri/card0" screen 0 at 0:2:0 is requested by "Autoconfigured Video Device"
[2025-12-15 07:52:16] (II)  Platform device "/dev/dri/card0" at 0@0:2:0 can be claimed.
[2025-12-15 07:52:16] (II) Adding "/dev/dri/card0" primary screen to "Autoconfigured Video Device"
[2025-12-15 07:52:16] (II) modeset(0): using drv /dev/dri/card0
[2025-12-15 07:52:16] (II) fbdev: PCI card screen 0 at 0:2:0 is requested by "Autoconfigured Video Device fbdev"
[2025-12-15 07:52:16] (II)  PCI device skipped because
[2025-12-15 07:52:16] (II)   PCI bus id 0@0:2:0 has already been claimed by "Autoconfigured Video Device".
[2025-12-15 07:52:16] (WW) Falling back to old probe method for fbdev
[2025-12-15 07:52:16] (II) Loading sub module "fbdevhw"
[2025-12-15 07:52:16] (II) LoadModule: "fbdevhw"
[2025-12-15 07:52:16] (II) Loading /usr/lib64/xorg/modules/xlibre-25/libfbdevhw.so
[2025-12-15 07:52:16] (II) Module fbdevhw: vendor="X.Org Foundation"
[2025-12-15 07:52:16]   compiled for 1.25.0, module version = 0.0.2
[2025-12-15 07:52:16]   ABI class: X.Org Video Driver, version 28.1
[2025-12-15 07:52:16] (II) "Autoconfigured Video Device fbdev" must be the only device, but "Autoconfigured Video Device" is present.
[2025-12-15 07:52:16] (II) vesa: PCI card screen 0 at 0:2:0 is requested by "Autoconfigured Video Device vesa"
[2025-12-15 07:52:16] (II)  PCI device skipped because
[2025-12-15 07:52:16] (II)   PCI bus id 0@0:2:0 has already been claimed by "Autoconfigured Video Device".
[2025-12-15 07:52:16] (II) modesetting: platform GPU device "/dev/dri/card0" at 0:2:0 is requested
[2025-12-15 07:52:16] (II)  Platform device "/dev/dri/card0" skipped because
[2025-12-15 07:52:16] (II)   PCI bus id 0@0:2:0 has already been claimed by "Autoconfigured Video Device".
[2025-12-15 07:52:16] (II) modeset(0): Creating default Display subsection in Screen section
        "Default Screen Section" for depth/fbbpp 24/32
...
[2025-12-15 07:52:19] (II) UnloadModule: "fbdev"
[2025-12-15 07:52:19] (II) Unloading fbdev
[2025-12-15 07:52:19] (II) UnloadSubModule: "fbdevhw"
[2025-12-15 07:52:19] (II) Unloading fbdevhw
[2025-12-15 07:52:19] (II) UnloadModule: "vesa"
[2025-12-15 07:52:19] (II) Unloading vesa

If the autoconfigured modesetting was not present, the autoconfigured fbdev would be happily initialized.

@stefan11111
Copy link
Contributor Author

@ONykyf Is this the setup I described in #1564 (comment) ?

The problem is that, if the screens are reversed, everything breaks.
If screen0 is driven by fbdev, and screen1 is driver by modesetting, then the kernels ignores writes via the /dev/fb interface.
However, since the fbdev driver now drives the master screen instead of a secondary screen, what ends up on the monitor is a black screen.

@stefan11111
Copy link
Contributor Author

@ONykyf Is this the setup I described in #1564 (comment) ?

The problem is that, if the screens are reversed, everything breaks. If screen0 is driven by fbdev, and screen1 is driver by modesetting, then the kernels ignores writes via the /dev/fb interface. However, since the fbdev driver now drives the master screen instead of a secondary screen, what ends up on the monitor is a black screen.

This is all pedantry though, as I doubt we can have the modesetting driver autoconfigure after fbdev.

What I'm more concerned about is that some drivers, like xf86-video-vesa, don't use the xf86Claim*Slot checks, and instead simply add an entity, bypassing our checks and any logging we could add to the xf86Claim*Slot checks.

@github-actions
Copy link

Merge Conflict found

@github-actions
Copy link

Merge Conflict found

4 similar comments
@github-actions
Copy link

Merge Conflict found

@github-actions
Copy link

Merge Conflict found

@github-actions
Copy link

Merge Conflict found

@github-actions
Copy link

Merge Conflict found

Reduce the number of total workflows, so the list isn't so crowded.

Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
@github-actions
Copy link

Merge Conflict found

Signed-off-by: artist <artist@artixlinux.org>
@github-actions
Copy link

Merge Conflict found

Use the new macros to make request struct parsing / field swapping
much easier.

Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
@github-actions
Copy link

Merge Conflict found

Fixes: X11Libre#1740

Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
@github-actions
Copy link

Merge Conflict found

It is patch 1/3 of a series that makes adding GPU screens
more controllable.

If SingleDriver option is set to "on", then only the first
successfully probed driver adds non-GPU screens, others
may add secondary GPU screens only.

Fixes github.com/X11Libre/issues/1669

Signed-off-by: Oleh Nykyforchyn <oleh.nyk@gmail.com>
It is patch 2/3 of a series that makes adding GPU screens
more controllable.

Signed-off-by: Oleh Nykyforchyn <oleh.nyk@gmail.com>
It is patch 3/3 of a series that makes adding GPU screens
more controllable.

If AutoAddGPU is "off", matching devices for autoconfigured
drivers are sought for anyway, and then the unused list is
freed. This patch cancels an unnecessary search.

Signed-off-by: Oleh Nykyforchyn <oleh.nyk@gmail.com>
@stefan11111 stefan11111 reopened this Jan 1, 2026
Part of reverting X11Libre#1564

The pr can land later, but needs a lot more discussion

Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
Part of reverting X11Libre#1564

The pr can land later, but needs a lot more discussion

Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
This patch adds a check that prevents xf86ClaimFbSlot
from claiming already used slots.

Drivers like xf86-video-fbdev can drive almost anything.
This makes it an excellent fallback driver, useful when the
proper driver breaks, or on livecd's.

Sadly, this also means that it can collide with other drivers,
using the same pci slot as them.
This usually doesn't lead to broken graphics, since the dedicated
drivers usually take priority, and the device ignores the fbdev interface.'

This means that when autoconfiguring, if the fbdev driver is installed,
the X server will likely use it, and that can lead to 2 X11 screens being
initializes on the same physical device, one being the dedicated driver
the user intended to use, another being fbdev.

This configuration is suboptimal and can break glx.

v1: X11Libre#1581

v2: X11Libre#1587
Siplify the checks and make them driver-independent.

v3: X11Libre#1650
Make fb slot checks even tighter.
Now an autoconfigured fb slot can only be claimed if no other slots were claimed.
We can enforce the reverse too, to not allow other kinds of slots
to be claimed an autoconfigured fb slot is claimed.
I didn't add this now to keep the changes as simple as possible.

Fixes: X11Libre#1505
Fixes: X11Libre#1565

Fixes: X11Libre@d3fd8c3
Fixes: X11Libre@d09b3da
Fixes: X11Libre@22d963b

Fixes: https://gitlab.freedesktop.org/xorg/driver/xf86-video-fbdev/-/issues/9
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/commit/fc78bcca21e767697de6ad4d8e03b6728856f613
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/commit/a8e41a81909ef74faa38ef12ca35c5d83f7c56a5
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/commit/728b54528d37ffa27b07c9b181c5ed8d2d359379
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1798
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1826

Heavily inspired by X11Libre#1564

Signed-off-by: stefan11111 <stefan11111@shitposting.expert>
@github-actions
Copy link

github-actions bot commented Jan 2, 2026

Merge Conflict found

15 similar comments
@github-actions
Copy link

github-actions bot commented Jan 5, 2026

Merge Conflict found

@github-actions
Copy link

github-actions bot commented Jan 5, 2026

Merge Conflict found

@github-actions
Copy link

github-actions bot commented Jan 6, 2026

Merge Conflict found

@github-actions
Copy link

github-actions bot commented Jan 7, 2026

Merge Conflict found

@github-actions
Copy link

github-actions bot commented Jan 7, 2026

Merge Conflict found

@github-actions
Copy link

github-actions bot commented Jan 7, 2026

Merge Conflict found

@github-actions
Copy link

github-actions bot commented Jan 8, 2026

Merge Conflict found

@github-actions
Copy link

Merge Conflict found

@github-actions
Copy link

Merge Conflict found

@github-actions
Copy link

Merge Conflict found

@github-actions
Copy link

Merge Conflict found

@github-actions
Copy link

Merge Conflict found

@github-actions
Copy link

Merge Conflict found

@github-actions
Copy link

Merge Conflict found

@github-actions
Copy link

Merge Conflict found

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

drmSetMaster failed: Device or resource busy

8 participants