[PATCH v6 09/11] modesetting: Blacklist UDL from PRIME sync
Alex Goins
agoins at nvidia.com
Tue Jun 14 01:02:03 UTC 2016
Hi Hans! Replying inline.
> On 11-06-16 02:21, Alex Goins wrote:
> > UDL (USB 2.0 DisplayLink DRM driver) has strange semantics when it comes to
> > vblank events and damage tracking when page flipping.
> >
> > When doing a page flip, it will instantly raise a vblank event without
> > waiting for vblank. However, it has no support for DRM_IOCTL_WAIT_VBLANK.
> > It also seems to have some issues with damage tracking when page flipping.
> >
> > It's possible to get something semi-working by hacking around these issues,
> > but even then there isn't much value-add vs single buffered PRIME, and it
> > reduces maintainability and adds additional risks to the modesetting driver
> > when running with more well-behaved DRM drivers.
> >
> > Work needs to be done on UDL in order to properly support synchronized
> > PRIME. For now, just blacklist it, causing RandR to fall back to
> > unsynchronized PRIME.
>
> Hmm, I've been working on getting a driver for another video-output device
> using usb transport (mostly to teach myself kms), see:
>
> http://www.spinics.net/lists/dri-devel/msg109311.html
>
> This has some of the same limitations as the udl driver, for one it
> raise a vblank event without waiting for vblank. I can probably fix this to
> at least wait till all data has been send over the usb-bus, but there
> is no way I can get actual vblank info on this device.
That's unfortunate, I wish this problem was exposed to userspace. Waiting until
all the data has been sent over the USB bus would definitely be preferable, but
would probably still result in some undesirable behavior with the vblank event
loop running way too fast.
> As such this device likely also needs to be excluded from using
> synchronized prime, which makes me think that maybe we just need
> to blacklist synchronized prime for any devices using a usb transport
> instead of blacklisting UDL ?
Is there a way to query for USB transport and/or misbehaved vblank events that
I'm not aware of? If so, then yes I'd highly prefer that option. Short of that,
I could blacklist your driver as well.
Preferably it would be something to query info about vblank events in
particular, since it's conceivable that there could be a USB transport device
that exposes the correct vblank. IIRC, the USB 3.0 DisplayLink is one such
device, though its DRM driver EVDI is out of tree, and its userspace driver is
proprietary.
> Regards,
>
> Hans
>
>
> p.s.
>
> Since you've been working on prime and the modesetting driver, I've
> a set of pending prime / modesetting related patches which need a
> review, and which may interest you:
>
> https://patchwork.freedesktop.org/patch/89722/
> https://patchwork.freedesktop.org/patch/90777/
> https://patchwork.freedesktop.org/patch/90982/
> https://patchwork.freedesktop.org/patch/90778/
> https://patchwork.freedesktop.org/patch/90779/
Sure, I'll look at these soon.
Thanks,
Alex
More information about the xorg-devel
mailing list