Re: simpledrm, running display servers, and drivers replacing simpledrm while the display server is running

[Pekka Paalanen <pekka.paalanen@haloniitty.fi>]

[-- Attachment #1: Type: text/plain, Size: 3264 bytes --]

On Thu, 09 May 2024 09:06:29 -0400
nerdopolis <bluescreen_avenger@verizon.net> wrote:

> 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?

Hi,

what you describe sounds similar to what has been agreed that drivers
should implement:
https://docs.kernel.org/gpu/drm-uapi.html#device-hot-unplug

That would be the first step. Then display servers would need fixing to
handle the hot-unplug. Then they would need to handle hot-plug of the
new DRM devices and ideally migrate to GPU accelerated compositing in
order to support GPU accelerated applications.

Simpledrm is not a GPU driver, and I assume that in the case you
describe, the GPU driver comes up later, just like the
hardware-specific display driver. Any userspace that initialized with
simpledrm will be using software rendering. Ideally if a hardware
rendering GPU driver turns up later and is usable with the displays,
userspace would migrate to that.

Essentially this is a display/GPU device switch. In general that's a
big problem, needing all applications to be able to handle a GPU
disappearing and another GPU appearing, and not die in between. For
the simpledrm case it is easier, because the migration is from no GPU
to a maybe GPU. So applications like Wayland clients could stay alive
as-is, they just don't use a GPU until they restart.

The problem is making display servers handle this switch of display
devices and a GPU hotplug. Theoretically I believe it is doable. E.g.
Weston used to be able to migrate from pixman-renderer to GL-renderer,
but I suspect it is lacking support for hot-unplug of the "main" DRM
display device.


Thanks,
pq

> Thanks
> 
> --------
> [1] https://github.com/sddm/sddm/issues/1917
> [2] https://github.com/systemd/systemd/issues/32509


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]