[PATCH v6 09/11] modesetting: Blacklist UDL from PRIME sync

[Hans de Goede]

Hi,

On 14-06-16 03:02, Alex Goins wrote:
> 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.

A USB device should always be a platform device, so you can do something like this:

#if XSERVER_PLATFORM_BUS
     if (pEnt->location.type == BUS_PLATFORM) {
         char *syspath = xf86_platform_device_odev_attributes(pEnt->location.id.plat)->syspath;

         if (syspath && strstr(syspath, "usb")
             do_blacklist_action();
     }
#endif

I think that is probably the best way to deal with both current and future
usb video-output devices.

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

Dave Airlie just reviewed them, but thanks for the offer!

Regards,

Hans