DisplayLink Forum - View Single Post

mlukaszek · 06-16-2016, 01:32 PM

Having DisplayLinkManager process using more CPU with no device connected (what sanette reported) is not normal and we'll be looking into that.

To give context for remaining reports so far: DisplayLinkManager does some heavy lifting to talk to devices and push pixels to all additional screens connected to docking stations - so it will always need some CPU resources to do that.

We use EVDI as a kernel mode DRM driver which receives all notifications from standard Linux subsystems, including those telling there is a change on the screen that needs to be displayed. DisplayLinkManager gets those updates from EVDI, and uses them to refresh screens connected to DisplayLink devices.

The CPU usage is proportional to how much data we need to work with. Generally speaking, the more extra screens, the higher CPU usage.

Unfortunately, some graphical environments (default Unity being a prime example) are working in such a way that the notifications we receive are about an entire screen changing, even if it's not exactly true.

For this reason, we can be forced to refresh all DisplayLink screens even if the update was just for the built-in laptop screen, and there was no real need to update contents of any other screen. We have seen much better behaviour in other desktop environments (e.g. Gnome 3 or KDE), where EVDI is given much more accurate information.

Having full screens needing to redraw will also make the process use more resources than updating a fraction of the screen. Unfortunately, this again comes back to the quality of screen update notifications we receive on Linux - even if the thing changing is tiny, if we're told that we should update the entire screen, we must do as we're instructed.

Having said all that...

We are currently looking at possibilities of reducing the CPU usage on Linux, but first would like understand what CPU usage (and overall performance) are people getting on different setups. Therefore, we'd need your help!

If you see something that you don't like please record a short video (smartphone quality is just fine) and share here. This will let us see how things work on your systems.

Some caveats:
Having Ubuntu's "Display Properties" window opened makes the CPU usage high - as the app is rendering an overlay with a display number on each screen - massively increasing the number of screen updates.

If using Unity desktop environment - for reasons explained above - even having a cursor blinking in console, or "top" window updating itself regularly on the internal screen will cause updates for all DisplayLink screens, too.

Regards,
Michal

06-16-2016, 01:32 PM	#21
mlukaszek Senior Member Join Date: Feb 2010 Posts: 386	Having DisplayLinkManager process using more CPU with no device connected (what sanette reported) is not normal and we'll be looking into that. To give context for remaining reports so far: DisplayLinkManager does some heavy lifting to talk to devices and push pixels to all additional screens connected to docking stations - so it will always need some CPU resources to do that. We use EVDI as a kernel mode DRM driver which receives all notifications from standard Linux subsystems, including those telling there is a change on the screen that needs to be displayed. DisplayLinkManager gets those updates from EVDI, and uses them to refresh screens connected to DisplayLink devices. The CPU usage is proportional to how much data we need to work with. Generally speaking, the more extra screens, the higher CPU usage. Unfortunately, some graphical environments (default Unity being a prime example) are working in such a way that the notifications we receive are about an entire screen changing, even if it's not exactly true. For this reason, we can be forced to refresh all DisplayLink screens even if the update was just for the built-in laptop screen, and there was no real need to update contents of any other screen. We have seen much better behaviour in other desktop environments (e.g. Gnome 3 or KDE), where EVDI is given much more accurate information. Having full screens needing to redraw will also make the process use more resources than updating a fraction of the screen. Unfortunately, this again comes back to the quality of screen update notifications we receive on Linux - even if the thing changing is tiny, if we're told that we should update the entire screen, we must do as we're instructed. Having said all that... We are currently looking at possibilities of reducing the CPU usage on Linux, but first would like understand what CPU usage (and overall performance) are people getting on different setups. Therefore, we'd need your help! If you see something that you don't like please record a short video (smartphone quality is just fine) and share here. This will let us see how things work on your systems. Some caveats: Having Ubuntu's "Display Properties" window opened makes the CPU usage high - as the app is rendering an overlay with a display number on each screen - massively increasing the number of screen updates. If using Unity desktop environment - for reasons explained above - even having a cursor blinking in console, or "top" window updating itself regularly on the internal screen will cause updates for all DisplayLink screens, too. Regards, Michal Last edited by mlukaszek; 06-16-2016 at 01:37 PM.