[PATCH] drm: rework SET_MASTER and DROP_MASTER perm handling

[Emil Velikov]

On Mon, 9 Mar 2020 at 18:36, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>
> On Mon, 9 Mar 2020 at 13:13, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>
> > > OTOH, if applications exist that rely on drop-master failing in this
> > > specific case, making drop-master succeed would break them. That might
> > > include a buggy set-master path that was written, but does not actually
> > > work because it was never tested since drop-master never worked.
> > >
> > > So I do not fully buy this argument yet, but I also cannot name any
> > > explicit examples that would break.
> > >
> > >
> > I've ventured for a while in the X (Xorg + drivers), Weston,
> > sway/wlroots and Mesa's codebase.
> > There were zero instances of such misuse. If other projects come to
> > mind - I'll gladly take a look.
> >
> Just checked a few other projects with git pickaxe* - zero cases of
> mentioned (mis)use. In particular:
>  - qtbase + qtwayland + gtk
> Never used the wrappers or ioctls
>
>  - kwin + plasmashell
> Never used the wrappers or ioctls
>
>  - mutter + gnome-shell
> Briefly used the wrappers. Sane codepath
>
>  - igt-gpu-tools ... just because I had it open
> Sane use both wrappers and ioctls.
>
> Any other projects I should check?
>
Coming back from an interesting venture in efl world:
 - enlightment - correctly usage during 2012-2014, switched to ecore_drm
 - evas (imlib2 successor) correct usage, few months in 2014, switched
to ecore_drm
 - legacy/ecore - never used either
 - ecore - ecore_drm backend, correct usage of drmSet/DropMaster

Given the above, it does seem that the raised concern is more or less
hypothetical.

-Emil