Bug 871798

Summary: using displaylink device for extended desktop renders desktop unusable
Product: [openSUSE] openSUSE 13.1 Reporter: Ivanov <damianatorrpm>
Component: X.OrgAssignee: Michal Srb <msrb>
Status: RESOLVED WONTFIX QA Contact: E-mail List <xorg-maintainer-bugs>
Severity: Critical    
Priority: P3 - Medium CC: damianatorrpm, msrb
Version: Final   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Ivanov 2014-04-03 10:21:50 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.152 Safari/537.36

Description of problem:
I try to use the Plugable UD160A as a docking station for an extended desktop. To do this as Lennart Poettering suggested http://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg12801.html
I dropped the auto seat logic in /etc/udev/rules.d/
After reboot as expected the display is detected at the same seat and is available, but whole X and every application is unusable slow, the window moving and every click happens with very long delay. Immediately after disconnecting the displaylink device the system is perfectly fast again.   

How reproducible:
always (openSUSE 13.1 - latest updates), happens with GNOME and KDE (with and without desktop acceleration enabled) 

Steps to Reproduce:
1. Drop autoseat for multiseat device Plugable UD160A
2. Connect the device (or if it is connected, reboot).
3. System is unusable.

PS: As multiseat config both seats are perfectly fast.
    Does with the udl driver the rendering happen in the main GPU (I know there was work on it)? Maybe the rendering is set to happen on the main GPU only if it is set as a separate seat but not when set as extended desktop to current seat?

Reproducible: Always
Comment 1 Stefan Dirsch 2014-04-03 13:19:07 UTC
*** Bug 847613 has been marked as a duplicate of this bug. ***
Comment 2 Stefan Dirsch 2014-04-03 13:44:36 UTC
This has been discussed recently. Fedora is using this patch.

http://pkgs.fedoraproject.org/cgit/xorg-x11-server.git/plain/xserver-autobind-hotplug.patch (hardcode configuration in Xserver)

One of our GNOME developers is currently working on client support, so this can be configured easily inside the desktop. We're planning to add the Xserver patch
to openSUSE:Factory (upcoming openSUSE 13.2) or client support respectively once it becomes available.
Comment 3 Ivanov 2014-04-03 13:47:36 UTC
This is the fix for Bug 847613 this bug here is different. This bug is about when you already run the 3rd desktop that it renders Xserver almost unusable not about hot-plugging.
Comment 4 Stefan Dirsch 2014-04-03 13:50:32 UTC
(In reply to comment #2)
> This has been discussed recently. Fedora is using this patch.
> 
> http://pkgs.fedoraproject.org/cgit/xorg-x11-server.git/plain/xserver-autobind-hotplug.patch
> (hardcode configuration in Xserver)
> 
> One of our GNOME developers is currently working on client support, so this can
> be configured easily inside the desktop. We're planning to add the Xserver
> patch
> to openSUSE:Factory (upcoming openSUSE 13.2) or client support respectively
> once it becomes available.

commented to wrong bugreport ..
Comment 5 Michal Srb 2014-04-28 11:16:18 UTC
I was testing this with Xtreamer DisplayLink (usb 17e9:02f2) and nouveau as main GPU. The rendering gets bit slower and cursor rendering switches to software, but overall it's reasonably fast.

What is your main GPU?
Comment 6 Ivanov 2014-04-28 11:26:07 UTC
==============MAIN GPU===============
42: PCI 100.0: 0300 VGA compatible controller (VGA)
  [Created at pci.319]
  Unique ID: VCu0.YBAEf6mAqm1
  Parent ID: _Znp.mxGZ4sT7tg6
  SysFS ID: /devices/pci0000:00/0000:00:02.0/0000:01:00.0
  SysFS BusID: 0000:01:00.0
  Hardware Class: graphics card
  Model: "ATI Redwood [Radeon HD 5670]"
  Vendor: pci 0x1002 "ATI Technologies Inc"
  Device: pci 0x68d8 "Redwood [Radeon HD 5670]"
  SubVendor: pci 0x174b "PC Partner Limited"
  SubDevice: pci 0xe166 
  Driver: "radeon"
  Driver Modules: "drm"
  Memory Range: 0xc0000000-0xcfffffff (ro,non-prefetchable)
  Memory Range: 0xfea20000-0xfea3ffff (rw,non-prefetchable)
  I/O Ports: 0xe000-0xefff (rw)
  Memory Range: 0xfea00000-0xfea1ffff (ro,non-prefetchable,disabled)
  IRQ: 76 (69545 events)
  Module Alias: "pci:v00001002d000068D8sv0000174Bsd0000E166bc03sc00i00"
  Driver Info #0:
    Driver Status: radeon is active
    Driver Activation Cmd: "modprobe radeon"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #20 (PCI bridge)





==============DISPLAYLINK GPU===============

68: USB 00.0: 0000 Unclassified device
  [Created at usb.122]
  Unique ID: BkVc.BX_QxMZK131
  Parent ID: mZxt.S+2E5Iv3QA6
  SysFS ID: /devices/pci0000:00/0000:00:16.2/usb3/3-2/3-2.1/3-2.1:1.0
  SysFS BusID: 3-2.1:1.0
  Hardware Class: unknown
  Model: "DisplayLink Plugable UD-160-A"
  Hotplug: USB
  Vendor: usb 0x17e9 "DisplayLink"
  Device: usb 0x0377 "Plugable UD-160-A"
  Revision: "1.03"
  Serial ID: "114939"
  Driver: "udl"
  Driver Modules: "drm_usb"
  Speed: 480 Mbps
  Module Alias: "usb:v17E9p0377d0103dc00dsc00dp00icFFisc00ip00in00"
  Driver Info #0:
    Driver Status: udl is active
    Driver Activation Cmd: "modprobe udl"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #61 (Hub)
Comment 7 Michal Srb 2014-11-03 12:39:12 UTC
The slowness is caused by those factors:
* udl driver doesn't support hardware cursors -> X server has to switch to software cursor and then every mouse movement triggers repaint.
* In this kind of setup, udl has output provider role in X server. In that case it receives full screen update each time main GPU renders anything.
* udl driver doesn't keep a shadow framebuffer to find out which parts of it actually changed -> it has to send the whole framebuffer to the device.
* udl driver doesn't support Display Link's proprietary compression (because it's not well understood), so it uses only simple RLE.
* The device is slow.

Improving any of those would improve the rendering speed. Adding the shadow framebuffer to udl would be probably the easiest one. Technically there is no bug anywhere, udl has just poor performance in it's current implementation.

The slowness can be partially workarounded by using lower resolution and more RLE friendly content (e.g. single color desktop background).