DRM leasing part deux (kernel side)
I've stabilized the kernel lease implementation so that leases now work reliably, and don't require a reboot before running the demo app a second time. Here's whats changed:
Reference counting is hard. I'm creating a new drm_master, which means creating a new file. There were a bunch of reference counting errors in my first pass; I've cleaned those up while also reducing the changes needed to the rest of the DRM code.
Added a 'mask_lease' value to the leases -- this controls whether resources in the lease are hidden from the lessor, allowing the lessor to continue to do operations on the leased resources if it likes.
Hacked the mutex locking assertions to not crash in normal circumstances. I'm now doing:
BUG_ON(__mutex_owner(&master->dev->mode_config.idr_mutex) != current);
to make sure the mutex is held by the current thread, instead of just making sure some thread holds the mutex. I have this memory of a better way to do this, but now I can't dig it up. Suggestions welcome, of course.
I'm reasonably pleased with the current state of the code, although I want to squash the patches together so that only the final state of the design is represented, rather than the series of hacks present now.
Comments on #dri-devel
I spent a bit of time on the #dri-devel IRC channel answering questions about the DRM-lease design and the changes above reflect that.
One concern was about mode setting from two masters at the same time. Mode setting depends on a number of shared 'hidden' resources; things like memory fifos and the like. If either lessee or lessor wants to change the displayed modes, they may fail due to conflicts over these resources and not be able to recover easily.
A related concern was that the current TEST/render/commit mechanism used by compositors may no longer be reliable as another master could change hidden resource usage between the TEST and commit operations. Daniel Vetter suggested allowing the lessor to 'exclude' lessee mode sets during this operation.
One solution would be to have the lessor set the mode on the leased resources before ceding control of the objects, and once set, the lessee shouldn't perform additional mode setting operations. This would limit the flexibility in the lessee quite a bit as it wouldn't be able to pop up overlay planes or change resolution.
Let's review the questions from my last post, DRM-lease:
What should happen when a Lessor is closed? Should all access to controlled resources be revoked from all descendant Lessees?
Answer: The lessor is referenced by the lessee and isn't destroyed until it has been closed and all lessees are destroyed.
How about when a Lessee is closed? Should the Lessor be notified in some way?
Answer: I think so? Need to figure out a mechanism here.
CRTCs and Encoders have properties. Should these properties be automatically included in the lease?
Answer -- no, userspace is responsible for constructing the entire lease.
Remaining Kernel Work
The code is running, and appears stable. However, it's not quite done yet. Here's a list of remaining items that I know about:
Changing leases should update sub-leases. When you reduce the resources in one lease, the kernel should walk any sub-leases and clear out resources which the lessor no longer has access to.
Sending events when leases are created/destroyed. When a lease is created, if the mask_lease value is set, then the lessor should get regular events describing the effective change. Similarly, both lessor and lessee should get events when a lease is changed.
Refactoring the patch series to squash intermediate versions of the new code.
Remaining Other Work
Outside of the kernel, I'll be adding X support for this operation. Here's my current thinking:
Extend RandR to add a lease-creation request that returns a file descriptor. This will take a mode and the server will set that mode before returning.
Provide some EDID-based matching for HMD displays in the X server. The goal is to 'hide' these from the regular desktop so that the HMD screen doesn't flicker with desktop content before the lease is created. I think what I want is to let an X client provide some matching criteria and for it to get an event when a output is connected with matching EDID information.
With that, I think this phase of the project will be wrapped up and it will be time to move on to actually hooking up a real HMD and hacking the VR code to use this new stuff.
Seeing the code
For those interested in seeing the state of the code so far, there's kernel, drm and kmscube repositories here: