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

Sat Sep 14 19:08:47 UTC 2019

On 2019-09-14 19:29, Erwin Burema wrote:
>> 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)

I'd prefer not having to dictate how calibration/profiling has to work 
but we might not have a choice here and have to design a wayland 
protocol. To be clear, it's just a preference.

>> 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).

Completely agree although some use-cases are not completely automatic 
they should still be doable with DRM leasing (if we can lease desktop 
outputs and get at least some input).

> 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.

It's been discussed before if we want to measure the display or the 
compositor+display. Ideally it's the same but if the compositor somehow 
screws up it's a bug that should be fixed. With intel exposing color 
pipelines per plane those screw ups will probably be there sometimes and 
not some other time so measuring the screw up is not helpful either.

>> 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)

Some use cases do require input and when the kms resource is gone how 
does event routing work? Would the wl_output be destroyed?

>> 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))

To expand on this: we need full control over the color pipeline, we need 
to control which values leave the crtc.

Maybe using the per plane color pipeline produces different results than 
using a full precision shader with whatever precision frame buffer. Some 
displays have arrays of dimmable backlights which bleed into the patch 
you try to measure so you have to force the surrounding backlight off.

So I also feel like this isn't about running apps in fullscreen. I do 
understand that it's undesirable to let applications bypass the 
compositor and if the feature is available it brings the risk of getting 
misused. Is this the only objection to this though?

(Simon mentioned a previous discussion about use cases but I can't seem 
to find it)

> 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel