From: Thomas Zimmermann <tzimmermann@suse.de>
To: "Jonas Ådahl" <jadahl@gmail.com>
Cc: nerdopolis <bluescreen_avenger@verizon.net>,
dri-devel@lists.freedesktop.org
Subject: Re: simpledrm, running display servers, and drivers replacing simpledrm while the display server is running
Date: Fri, 10 May 2024 14:45:48 +0200 [thread overview]
Message-ID: <4710c7b9-d4e5-4eb9-9d69-d80c385deadf@suse.de> (raw)
In-Reply-To: <Zj3tvKayXdn2_JMq@gmail.com>
Hi
> (This was discussed on #dri-devel, but I'll reiterate here as well).
>
> There are two problems at hand; one is the race condition during boot
> when the login screen (or whatever display server appears first) is
> launched with simpledrm, only some moments later having the real GPU
> driver appear.
>
> The other is general purpose GPU hotplugging, including the unplugging
> the GPU decided by the compositor to be the primary one.
The situation of booting with simpledrm (problem 2) is a special case of
problem 1. From the kernel's perspective, unloading simpledrm is the
same as what you call general purpose GPU hotplugging. Even through
there is not a full GPU, but a trivial scanout buffer. In userspace, you
see the same sequence of events as in the general case.
>
> The latter is something that should be handled in userspace, by
> compositors, etc, I agree.
>
> The former, however, is not properly solved by userspace learning how to
> deal with primary GPU unplugging and switching to using a real GPU
> driver, as it'd break the booting and login experience.
>
> When it works, i.e. the race condition is not hit, is this:
>
> * System boots
> * Plymouth shows a "splash" screen
> * The login screen display server is launched with the real GPU driver
> * The login screen interface is smoothly animating using hardware
> accelerating, presenting "advanced" graphical content depending on
> hardware capabilities (e.g. high color bit depth, HDR, and so on)
>
> If the race condition is hit, with a compositor supporting primary GPU
> hotplugging, it'll work like this:
>
> * System boots
> * Plymouth shows a "splash" screen
> * The login screen display server is launched with simpledrm
> * Due to using simpldrm, the login screen interface is not animated and
> just plops up, and no "advanced" graphical content is enabled due to
> apparent missing hardware capabilities
> * The real GPU driver appears, the login screen now starts to become
> animated, and may suddenly change appearance due to capabilties
> having changed
>
> Thus, by just supporting hotplugging the primary GPU in userspace, we'll
> still end up with a glitchy boot experience, and it forces userspace to
> add things like sleep(10) to work around this.
>
> In other words, fixing userspace is *not* a correct solution to the
> problem, it's a work around (albeit a behaivor we want for other
> reasons) for the race condition.
To really fix the flickering, you need to read the old DRM device's
atomic state and apply it to the new device. Then tell the desktop and
applications to re-init their rendering stack.
Depending on the DRM driver and its hardware, it might be possible to do
this without flickering. The key is to not loose the original scanout
buffer, while not probing the new device driver. But that needs work in
each individual DRM driver.
>
> Arguably, the only place a more educated guess about whether to wait or
> not, and if so how long, is the kernel.
As I said before, driver modules come and go and hardware devices come
and go.
To detect if there might be a native driver waiting to be loaded, you
can test for
- 'nomodeset' on the command line -> no native driver
- 'systemd-load-modules' not started -> maybe wait
- look for drivers under /lib/modules/<version>/kernel/drivers/gpu/drm/
-> maybe wait
- maybe udev can tell you more
- it might for detection help that recently simpledrm devices refer to
their parent PCI device
- maybe systemd tracks the probed devices
Best regards
Thomas
>
>
> Jonas
>
>> The next best solution is to keep the final DRM device open until a new one
>> shows up. All DRM graphics drivers with hotplugging support are required to
>> accept commands after their hardware has been unplugged. They simply won't
>> display anything.
>>
>> Best regards
>> Thomas
>>
>>
>>> Thanks
>>>
>> --
>> --
>> Thomas Zimmermann
>> Graphics Driver Developer
>> SUSE Software Solutions Germany GmbH
>> Frankenstrasse 146, 90461 Nuernberg, Germany
>> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
>> HRB 36809 (AG Nuernberg)
>>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
next prev parent reply other threads:[~2024-05-10 12:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <9215788.EvYhyI6sBW.ref@nerdopolis2>
2024-05-09 13:06 ` simpledrm, running display servers, and drivers replacing simpledrm while the display server is running nerdopolis
2024-05-10 7:29 ` Pekka Paalanen
2024-05-10 7:32 ` Thomas Zimmermann
2024-05-10 9:49 ` Jonas Ådahl
2024-05-10 12:45 ` Thomas Zimmermann [this message]
2024-05-10 13:11 ` Jonas Ådahl
2024-05-20 2:25 ` nerdopolis
2024-05-21 12:52 ` Daniel Vetter
2024-05-10 7:36 ` Javier Martinez Canillas
2024-05-21 10:06 ` Jani Nikula
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=4710c7b9-d4e5-4eb9-9d69-d80c385deadf@suse.de \
--to=tzimmermann@suse.de \
--cc=bluescreen_avenger@verizon.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=jadahl@gmail.com \
/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).