[PATCH v6] unstable/drm-lease: DRM lease protocol support

[Erwin Burema]

> On Tue, 03 Sep 2019 00:15:56 +0200
> Sebastian Wick <sebastian at sebastianwick.net> wrote:
>
> > On 2019-07-30 14:53, Drew DeVault wrote:
> > > From: Marius Vlad <marius.vlad at collabora.com>
> > >
> > > DRM leasing is a feature which allows the DRM master to "lease" a
> > > subset
> > > of its DRM resources to another DRM master via drmModeCreateLease,
> > > which
> > > returns a file descriptor for the new DRM master. We use this protocol
> > > to negotiate the terms of the lease and transfer this file descriptor
> > > to
> > > clients.
> > >
> > > In less DRM-specific terms: this protocol allows Wayland compositors to
> > > give over their GPU resources (like displays) to a Wayland client to
> > > exclusively control.
> > >
> > > The primary use-case for this is Virtual Reality headsets, which via
> > > the
> > > non-desktop DRM property are generally not used as desktop displays by
> > > Wayland compositors, and for latency reasons (among others) are most
> > > useful to games et al if they have direct control over the DRM
> > > resources
> > > associated with it. Basically, these are peripherals which are of no
> > > use
> > > to the compositor and may be of use to a client, but since they are
> > > tied
> > > up in DRM we need to use DRM leasing to get them into client's hands.
> >
> > Talking about use-cases, I'm evaluating leasing for display calibration
> > and profiling which requires leasing outputs which are are part of the
> > desktop and also requires user interaction (keyboard, mice). Are there
> > any ideas on how something like that would work?
> >
> > I think it would be great if it worked similar to fullscreen surfaces
> > but input handling depends on having a surface but leasing an output is
> > independent.
>
> Hi,
>
Hi,

Since Sebastian hasn't replied yet I think I can give some insight
here, to be honest in my opinion using drm-lease for this is already a
compromise (since Sebastian already shot down protocols that give any
form of calibration/gamma curve access)

> sorry, I don't think that would work.
>
> Your measurement app must become a KMS app, which is something other
> color management people seemed to be quite opposed of. Compositors
> probably would not allow leasing outputs used for the desktop. You
> would not be able to get any input unless you had another output still
> controlled by the compositor where to show a window, or you had access
> to the kernel input devices which you don't.
>

The biggest reason a straight KMS application won't work for our use
case is that it would give horrible user experience in that you first
need to get a vtty session and then launch the application from the
terminal there, since this will be needed to do by people who are not
necessarily the most computer savvy people and the
calibration/profiling generally needs to be performed somewhat
regularly (from once every quarter to once every month depending on
required accuracy and screen drift). With DRM leasing we at least
don't have to tell people they first need to switch terminal (which in
the worst case can mean a need for logging out), for input I am not
that concerned since the needed input can be done using a normal
wayland application that then launches the KMS based
calibrator/profiler (which is mostly an automatic process).

There are also some other issues with a KMS bases calibrator/profiler
is, one is that it is harder to program and there might be exposed HW
differences that we would prefer not to deal with (this would still be
an issue with DRM leasing), the other main one is that for extreme
accuracy it would be nice to get the compositor involved so that
during calibration/profiling the same curve is set as in usage.

> If you want to write a KMS app for measurements, I'd recommend making
> it a stand-alone app, not something using DRM leases. That way you can
> assume there is no other program (usually a display server) already
> running and owning the input and output devices.
>

As I said above during the profiling/calibration we don't need input
(well from the tool used from profiling/calibrating but that is
usually not a classical input device)

> DRM leasing is for kernel device access, not a fancy way to run an app
> fullscreen.
>

And calibrating/profiling is not a just any fullscreen application it
does require extra stuff (gamma table access is the main one (which is
a kernel device although in this case indirect access is sufficient)
but capabilities to load/unload profiles would be a nice one as well
and either a way to tell the calibrator/profiler that it should stop
(temporary))

So from worst to best it would look like this
* normal fullscreen - Better user experience but no gamma table
access, also it would be nice to let the compositor know it shouldn't
lock the screen, go standby, or let other application draw over the
critical regions (or at least have a way to
* stand alone KMS - Horrible use experience, harder to program for,
but have full access to everything
* drm lease - Better user experience but requires the capability to
lease the main screen and also still hard to program for
* specific wayland calibration protocol - Has gamma table access, is
easy to program for and best user experience

>
> Thanks,
> pq

Kind regards,

Erwin Burema