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
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
