All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Christopher James Halse Rogers <raof@ubuntu.com>
Cc: Emil Velikov <emil.l.velikov@gmail.com>,
	Christopher James Halse Rogers
	<christopher.halse.rogers@canonical.com>,
	ML dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH libdrm] xf86drm: Add drmIsMaster()
Date: Tue, 22 Jan 2019 08:55:59 +0100	[thread overview]
Message-ID: <CAKMK7uETbncOYZi0NoA3Laaot_u4pUAVnRAwYS2YkWTyT63MGA@mail.gmail.com> (raw)
In-Reply-To: <518DE9C7-21B3-437C-AF20-6C8D3C3E7E9F@ubuntu.com>

On Tue, Jan 22, 2019 at 3:26 AM Christopher James Halse Rogers
<raof@ubuntu.com> wrote:
>
> On 18 December 2018 7:07:01 pm NZDT, Christopher James Halse Rogers <chris@cooperteam.net> wrote:
>>
>> On 18 December 2018 4:35:37 am AEDT, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>>>
>>> Hi Christopher,
>>>
>>> On Tue, 20 Nov 2018 at 03:37, Christopher James Halse Rogers
>>> <christopher.halse.rogers@canonical.com> wrote:
>>>>
>>>>  We can't use drmSetMaster to query whether or not a drm fd is master
>>>>  because it requires CAP_SYS_ADMIN, even if the fd *is* a master fd.
>>>>
>>> Can you please mention the exact use case here? You mentioned it over
>>> IRC although it'll be nice to have it here for posterity.
>>
>>
>> Certainly!
>>
>> The particular use-case I was hitting was testing my display server in a container, where container-root is not real-root but the implicit-master FD you get by opening the DRM node when there is no current master would be sufficient.
>>
>> 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 then fail, rather than noticing that KMS won't work and using our X11 backend.
>>
>> >
>>>>
>>>>  Pick DRM_IOCTL_MODE_ATTACHMODE as a long-deprecated ioctl that is
>>>>  DRM_MASTER but not DRM_ROOT_ONLY as the probe by which we can detect
>>>>  whether or not the fd is master.
>>>>
>>> I'm wondering if we cannot extent DRM_IOCTL_GET_CLIENT or another
>>> IOCTL.
>>> What do you think? May I interest you in writing an RFC 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?

Use-case seems all reasonable, I was waiting for a respin with my suggestion ...
-Daniel

>> ________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
> Ping!
>
> Is there anything more you'd like to know about my use-case here? Are there any objections to adding drmIsMaster()?
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-01-22  7:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-20  3:36 [PATCH libdrm] xf86drm: Add drmIsMaster() Christopher James Halse Rogers
2018-12-17 17:35 ` Emil Velikov
2018-12-17 17:59   ` Daniel Vetter
2018-12-18  6:07   ` Christopher James Halse Rogers
2019-01-22  2:26     ` Christopher James Halse Rogers
2019-01-22  7:55       ` Daniel Vetter [this message]
2019-01-23  4:38 ` [PATCH v2] " Christopher James Halse Rogers
2019-01-23 11:00   ` Daniel Vetter
2019-01-23 17:18   ` Emil Velikov
2019-01-23 20:56     ` Christopher James Halse Rogers
2019-01-24  9:45       ` Daniel Vetter
2019-02-19 20:40         ` Daniel Vetter

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=CAKMK7uETbncOYZi0NoA3Laaot_u4pUAVnRAwYS2YkWTyT63MGA@mail.gmail.com \
    --to=daniel@ffwll.ch \
    --cc=christopher.halse.rogers@canonical.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=emil.l.velikov@gmail.com \
    --cc=raof@ubuntu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.