[RFC PATCH] drm: Add plane event

[Ville Syrjälä]

On Wed, Apr 18, 2012 at 05:27:57PM +0200, Daniel Vetter wrote:
> On Wed, Apr 18, 2012 at 05:10:47PM +0200, Marcus Lorentzon wrote:
> > On 04/18/2012 04:36 PM, Daniel Vetter wrote:
> > >Last time around I've discussed with people we've ended up with 2 new
> > >ioctls:
> > >
> > >- atomic modeset, to configure the output state on more than one crtc at
> > >   the same time. This is useful to get pll assignement, memory bandwidth
> > >   constrains and similar stuff right. This ioctl is synchronous. A
> > >   testmode can be used to inquire the driver whether the proposed mode
> > >   actually works. This could be used for gui interfaces to automatically
> > >   grey out unsupportable configurations, e.g. if you have 3 crtc but on 2
> > >   pll and 2 modes need to have the same pixelclocks to drive all 3 crtcs.
> > >
> > >- an atomic pageflip. This one would be like the current pageflip ioclt,
> > >   i.e. run asynchronously and deliver a drm event upont completion. The
> > >   idea is that compositors can use this to make flicker-free compositition
> > >   with drm planes possible. I think we want drivers to be able to indicate
> > >   which crtc properties they can switch with this ioctl, e.g. I expect
> > >   some yuv->rbg color space properties might not work. All the changes
> > >   should be applied on the same vblank, obviously.
> > Why an atomic pagefilp? How is this different from an atomic modeset
> > where only fbs change? Can't drm frmwrk "optimize" this like SETCRTC
> > does today with base/full modeset helpers?
> 
> The important difference is that the pageflip should happen vsynced on one
> single crtc. So it can't do anything which takes longer than a vsync
> (usually you need to wait a frame for the clocks to stabilize before
> switching on the next stage in the output pipeline), so any output
> configuration changes are pretty much out of the window. We also want
> pageflip to run asynchronously and return immediately after emitting all
> relevant commands. That's not really important for modeset.

Whether something can happen immediately or needs some multi frame
sychronization steps may depend on the hardware. Also the split in
this case is rather vague. You most likely want to change a lot of
other state in addition to just flipping buffers.

> So yeah, you could smash all this into one giant ioctl, but I think the
> split is useful and would simplify things quite a bit on the
> implementation side. Otherwise you need to add funny queries so that
> userspace can figure out which modeset ops run asynchronous, which can be
> vblank synced. And it needs to tell the kernel for which it wants an
> event. Especially when you have multiple crtc and want to drive all of
> them with a compositor, this can get funny.

Just ask for the event always, and if the driver decides to block during
the ioctl, so be it.

That being said it would be nice to be able to pipeline all mode setting
operations. The driver could implement some of that using a kernel thread
if it has to perform blocking operations, or if you don't want to implement
a state machine into the driver.

> Also, I'm toying around with ideas to split up the big modeset lock such
> that operations that only touch the crtc (like pageflip, plane changes and
> cursor changes) do not take the big modeset lock but only a per-crtc
> mutex.

Plane operations might well involve multiple CRTCs (when moving the
planes between pipes for example). You have to be careful with the
locking order when doing stuff like that. One option would be to
always take the per-CRTC locks in the same order (based on the
object ID for example).

> This way a compositor running on crtc A could run without hiccups
> while we do a modeset operation on crtc B, or while a hotplug detection is
> reading back the edid from a unused connector (which can easily take
> longer than a few frames). We have tons of bug reports from users that
> complain that every 10s their cursor stalls (due to hotplug detect).

I think the EDID stuff should be split completely from other state.
I have one interesting bit of hardware at home where reading an EDID
block took over 30 seconds. The device is structured like this:
GPIO pins <-> bitbanged i2c <-> GPIO expander <-> bitbanged i2c <-> EDID

If I would like to use that device in any sane way, I'd really need to
read the EDID from a kernel thread and possibly also come up with some
way to avoid blocking access to encoders accessed through the same GPIO
pins.

Obviously the 30 second wait for the EDID after plugging in a display
would still be a major PITA.

> If you smash everything into one ioctl, I imagine you have plenty of fun
> implementing all this. Which is why I prefer to split this up.

I don't think there's that much differnce. You build up the full device
state, check it, and when you're ready to commit it you decide whether
to go with the blocking approach or not.

-- 
Ville Syrjälä
Intel OTC