fbdev-damage no longer plays nice with current xorg


#1

I’ve tried migrating the fbdev-damage changes from Plugable’s 0.4.2 git repository to fbdev 0.4.3 and ran into some errors that are over my head. Net result, with the latest xorg I’m stuck running without DAMAGE support, which means mediocre x11 performance, or backtracking to an older xorg install set in Arch Linux ARM. It looks like the git sources have languished for a couple years now, any plans of working on them again, or is there a better method/driver option now for displaylink devices under xorg?


#2

Hi Josh,

Thanks for posting! Yes, unfortunately it’s been a long time since that xf86-video-fbdev branch with udlfb damage patches has been updated.

It’s a little bit caught up in the churn as the kernel-level framebuffer driver (udlfb) is getting replaced by a DRM driver (udl), but it isn’t working yet.

Any work on damage support needs to be sync’d up between all these pieces, which adds a bit to the work.

I’ll take a look this week and see if I can at least sync with the latest xf86-video-fbdev sources and bring our branch up to date.

Please let everyone here know if you find a different / better way.

Thanks again for posting!
Bernie


#3

I just noticed the DRM-UDL driver today digging through 3.7-rc2’s config, I’ll have to keep an eye on that. In the mean time, I’ve got a DL165 based dock and am more than willing to throw test code at it to see if it works or makes a pretty crater.


#4

OK - great. Will let you know. Note that the udl driver appears to panic on framebuffer access right now – so stick with udlfb for the time being, it is stable. Thanks!


#5

I just updated the arch package with a patch that syncs plugable’s branch with latest fbdev 0.4.3. Works fine here.

https://aur.archlinux.org/packages.ph…


#6

Thanks Alexander!


#7

Nice! I’ll give that a go on Arch-ARM ASAP. Thank you for tackling that Alexander!


#8

So, I’m horribly slow at testing these days… tried your package and it builds and installs cleanly. X loads it just fine, but if I’ve got udlfb set to defio=0, instead of seeing X11 I get a frozen image of my last VT before X ‘takes over’. The system doesn’t hang, if I ssh/serial console in I can kill X and resume using the VTs on the displaylink adapter.


#9

Thanks for the report! Are you running xf86-video-displaylink, (patched) -fbdev?

If it’s what comes with stock xorg, damage support isn’t in there – and we have a report that our old damage patches need to be updated.

So things may be in flux right now with newer xorg on arm, sorry.

We’ll try to take a fresh look in the next weeks and get a blog post up with the latest patches. Thanks again for asking about it – and post if you get any combo working. Thanks!


#10

I’m running the updated plugable fbdev with damage support that Alexander posted. With defio set to 1, it works as per before, slow but viable. With defio set to 0, it acts like it’s working but instead of seeing the X11 display I’m just getting the last framebuffer contents before X11 takes over. You can see it drop the display output as it probes, when it comes back it’s the old contents. If you then kill the X session it drops you right back to the console session you launched from as if nothing was wrong.


#11

Hi Josh, that’s weird, it works fine here. I double-checked that defio is enabled (kernel log says “kernel: udlfb: fb_defio enable=1”). I’m running kernel 3.7.6-1 on a 32 bit system, xorg 1.13.2.


#12

Sorry I misread this, it’s “defio=*0*” that doesn’t work, Will try that.


#13