From: nerdopolis <bluescreen_avenger@verizon.net>
To: dri-devel@lists.freedesktop.org
Subject: simpledrm, running display servers, and drivers replacing simpledrm while the display server is running
Date: Thu, 09 May 2024 09:06:29 -0400 [thread overview]
Message-ID: <9215788.EvYhyI6sBW@nerdopolis2> (raw)
In-Reply-To: 9215788.EvYhyI6sBW.ref@nerdopolis2
[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]
Hi
So I have been made aware of an apparent race condition of some drivers taking a bit longer to load, which could lead to a possible race condition of display servers/greeters using the simpledrm device, and then experiencing problems once the real driver loads, the simpledrm device that the display servers are using as their primary GPU goes away.
For example Weston crashes, Xorg crashes, wlroots seems to stay running, but doesn't draw anything on the screen, kwin aborts,
This is if you boot on a QEMU machine with the virtio card, with modprobe.blacklist=virtio_gpu, and then, when the display server is running, run sudo modprobe virtio-gpu
Namely, it's been recently reported here: https://github.com/sddm/sddm/issues/1917[1] and here https://github.com/systemd/systemd/issues/32509[2]
My thinking: Instead of simpledrm's /dev/dri/card0 device going away when the real driver loads, is it possible for simpledrm to instead simulate an unplug of the fake display/CRTC?
That way in theory, the simpledrm device will now be useless for drawing for drawing to the screen at that point, since the real driver is now taken over, but this way here, at least the display server doesn't lose its handles to the /dev/dri/card0 device, (and then maybe only remove itself once the final handle to it closes?)
Is something like this possible to do with the way simpledrm works with the low level video memory? Or is this not possible?
Thanks
--------
[1] https://github.com/sddm/sddm/issues/1917
[2] https://github.com/systemd/systemd/issues/32509
[-- Attachment #2: Type: text/html, Size: 2371 bytes --]
next parent reply other threads:[~2024-05-09 13:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <9215788.EvYhyI6sBW.ref@nerdopolis2>
2024-05-09 13:06 ` nerdopolis [this message]
2024-05-10 7:29 ` simpledrm, running display servers, and drivers replacing simpledrm while the display server is running Pekka Paalanen
2024-05-10 7:32 ` Thomas Zimmermann
2024-05-10 9:49 ` Jonas Ådahl
2024-05-10 12:45 ` Thomas Zimmermann
2024-05-10 13:11 ` Jonas Ådahl
2024-05-20 2:25 ` nerdopolis
2024-05-10 7:36 ` Javier Martinez Canillas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9215788.EvYhyI6sBW@nerdopolis2 \
--to=bluescreen_avenger@verizon.net \
--cc=dri-devel@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).