On 18 December 2018 4:35:37 am AEDT, Emil Velikov &l=
t;emil=2El=2Evelikov@gmail=2Ecom> wrote:
Hi Christopher,

On Tue, 20 Nov 2018 at 03:37, C=
hristopher James Halse Rogers
<christopher=2Ehalse=2Erogers@canonical=
=2Ecom> wrote:
 We c=
an't use drmSetMaster to query whether or not a drm fd is master
 becaus=
e it requires CAP_SYS_ADMIN, even if the fd *is* a master fd=2E

Can you please mention the exact use case here? You mentioned it o=
ver
IRC although it'll be nice to have it here for posterity=2E

Certainly!

The particular use-case I was hitting was tes=
ting my display server in a container, where container-root is not real-roo=
t but the implicit-master FD you get by opening the DRM node when there is =
no current master would be sufficient=2E

Just assuming the FD we get=
 is master and failing later breaks the platform probing; for example, when=
 run under X11 if we don't check master we'll load the KMS platform and the=
n fail, rather than noticing that KMS won't work and using our X11 backend=
=2E

>
 Pick DRM_IOCTL_MODE_ATTACHMODE a=
s a long-deprecated ioctl that is
 DRM_MASTER but not DRM_ROOT_ONLY as t=
he probe by which we can detect
 whether or not the fd is master=2E
<=
br>I'm wondering if we cannot extent DRM_IOCTL_GET_CLIENT or a=
nother
IOCTL=2E
What do you think? May I interest you in writing an R=
FC for the
kernel-side?

I think if I was going to do=
 kernel-side changes if probably just make it so that IOCTL_SET_MASTER just=
 unconditionally succeeded on an fd that was already master?dri-devel m=
ailing list
dri-devel@lists=2Efreedesktop=2Eorg
https://lists=2Efreedes=
ktop=2Eorg/mailman/listinfo/dri-devel