On Wed, 11 Sep 2019 14:48:20 -0400 "Drew DeVault" <s...@cmpwn.com> wrote:
> On Mon Sep 2, 2019 at 3:51 PM Pekka Paalanen wrote: > > Hi Drew, > > > > I seem to recall that you didn't want to add multi-DRM-device support > > here just yet and go first with just one implied DRM device. That is > > ok, but would be nice to have a TODO note somewhere near the top in the > > XML file saying that this will be re-designed to support multiple DRM > > devices at some point. > > This was resolved by choosing to have multiple drm_lease_manager > globals, one for each DRM device. No reworking should be necessary. Hi, in that case, document it in the XML please. I didn't see any identification of the DRM device in that case, meaning that they would be all anonymous. It may be significant for VR performance to have the rendering and KMS happen both on the same device. If the user plugs a HMD to the wrong card, it would be good to be able to tell. > > Can you point to the discussion or elaborate here on when a zero > > connector lease would be useful? > > > > I checked the Xwayland discussion and didn't see it there. I remember > > some old talk about giving out a no-resources lease first for > > discovering DRM resources to lease, but that didn't work because > > non-leased resources would not be visible either. > > https://gitlab.freedesktop.org/xorg/xserver/issues/864 > > The main issue is that we have no way to enumerate detailed mode > information in Xwayland to populate RandR, which is used by X clients in > the wild today to prep for a DRM lease (the corresponding X extension > for Vulkan is an example of where this is a problem). Oh yes, that. If that is to be solved with Wayland protocol, you'd have to send events with all the kernel video modes. Some random thoughts: Was it considered to give out full (as in, not leased) but non-master DRM device fds for iterating possible resources? A compositor would get one by opening the DRM device again. I'm assuming that logind would do a new open() for it. It has the drawback that the resources would be unfiltered by the compositor. About a possible attack vector, I don't think the client could gain DRM master even if the compositor dropped it unless the client is already root. I'm starting to think that what you might need is a lease fd that cannot be DRM-master. Then the compositor could create a "pre-lease" with all the resources it could be willing to lease out. The client would use KMS UAPI to query everything, and then decide what it wants to actually lease. That would avoid sending EDID, modes and whatnot over Wayland. Or maybe sysfs could expose all the information (EDID, modes, whatnot). Lastly, there is the arduous option of defining how to serialize everything to be passed through Wayland. You already have EDID. You could add video modes to that blob by defining more structure. I might favour sysfs, but then I guess BSD would be left out cold. Thanks, pq
pgp5o0lTHzjoe.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
