I just received my two DL-195 adapters. I’m using Archlinux and installed xf86-video-displaylink0.3 and udlfb2.3. When I add the udlfb module to the loaded ones, I get two green screens on boot. Now I configured my xorg.conf to use the now existing /dev/fb0 and /dev/fb1 for 2 new separate xsessions. I disabled Xinerama. Still, when I restart X the monitors are still green. Nothing changed.
When I run the USB display as Screen0 with 0 0, I get a Segfault. When I run them as additional screens they keep being green. Though green is a nice color, I ́d like to start xsessions on them.
When I do a ‘cat /dev/urandom > /dev/fb1’, the screen changes to noise. So access should be there.
I added my xorg.conf and logs here: https://gist.github.com/1330354
I removed one UGA-2K-A from my USB-Hub. Now the Left USB Screen shows a picture.
I read that there is support for multiple DL-195 Screens with xf86-video-fbdev and the latest UDLFB commit. So I uninstalled the existing ones and installed from git clones.
Now I only get the left USB Monitor to work. Even I add the Notebook Monitor from my Nvidiacard to the ServerLayout, the screen stays blank.
Another Problem is, that I cannot rotate the USB Monitor. When I do, then the lower half of the screen stays green and the upper 1200 pixels (height) only update, when I move the mouse.
Hi Leoc,
Thanks for posting with good details. Yes, while the kernel fbdev driver for the devices is there, configuring xorg to use multiple fbdev devices is a pain.
I see you’re running the latest udlfb and fbdev patched with damage support, which is great - from the DisplayLink perspective, you have all the latest pieces.
Some high-level expectation setting to start: it’s likely you’ll have problems getting the nVidia xorg drivers to coexist with others (e.g. fbdev). I’ve seen people report making it happen with some older versions of xorg, but nothing recent. The only thing that is consistently achievable (but still a pain) is to go with all-USB displays and not make use of your primary.
So your ultimate goal here might not be achievable.
Let us know if having only the two USB displays in your layout (not using the Macbook screen) is still interesting, as we might be able to make progress on that.
On the rotate problem, one thing to check is that there isn’t a mismatch in the xorg.conf between the screen set to rotate, while setting an explicit mode in the “Screen” section matched to that USB adapter.
The best thing to do is to remove the SubSection “Display” from all USB screens, and let the USB adapter detect the native mode of the monitor automatically.
If that doesn’t work for rotate, let us know.
Thanks,
Bernie
Alright. Thanks for the answer.
When I use only the two USB Displays the second one (RightOf “DLScreenLeft”) stays black.
I will try again without the Display section.
Okay. When I use only the USB Screens the both monitors display correctly.
Still, when I uncomment ‘Option “rotate” “CCW”’, I still get the same display errors. Only the regions I moved the mouse cursor at are updated and the picture is cut off at 1200px.
EDIT1: As soon as I kill the X server in tty1, the picture is displayed correctly. But it ́s only the last state of the buffer. No fbdev anymore. And only on the first USB device.
EDIT2: When I use all my Screens in the layout, I get the following error:
Cannot run in Framebuffer mode. Please specify busIDs
Ok, great - let’s try to figure out the rotate problem, at least.
Let’s try relying on page faults (defio), rather than damage notifications, when rotated.
To try this:
-
Make sure fb_defio option of uldfb is enabled. (here’s how: http://git.kernel.org/?p=linux/kernel…)
-
Comment out the ReportDamage option in your xorg.conf
This will switch to relying on fb_defio (a page-fault based mechanism).
Note that rotation is quite CPU intensive at the xorg level, so you’ll see a big drop in performance as you go from normal to rotated.
And let us know if you find a solution to the “Cannot run in Framebuffer mode. Please specify busIDs” problem – my belief is it’s assumptions in the xorg code that graphics devices are on the PCI bus, but I’m not really sure about problem or solution.
Thanks,
Bernie
Okay. For the framebuffer I will check back on the xorg mailing list.
Now, when I remove the ReportDamage Option I only get black screens.
The content of my /etc/modprobe.d/udlfb.conf is “options udlfb fb_defio=1”.
This should be loaded when the udlfb module is loaded while booting the initramfs image, right?
Performance won’t be a problem, because I want to use the displays solely for terminals or static webpages.
That should work with fb_defio enabled, so let’s figure out what’s going wrong.
Could you run
sudo tail -f /var/log/kern.log
And unplug/replug one of the USB adapters? You’ll get a dump of the initialization messages from udlfb. Could you copy that here?
Thanks,
Bernie
Alright.
https://gist.github.com/1330937#file_…
So it ́s still loaded without fb_defio=1. Even after I ran ‘modprobe udlfb fb_defio=1’ which should set the options right?
Another question. When I boot the computer the framebuffers are /dev/fb0 and /dev/fb1. When I pull the hub and replug it I get 3 framebuffers. (/dev/fb0, /dev/fb1 and /dev/fb2).
Why that? It would mean that I cannot start into X with the same config, that I would use when I replug the hub.
If you reload the module dependencies with
sudo depmod -a
does that get fb_defio enabled for udlfb?
What’s happening with the /dev/fb* is Linux won’t allow a framebuffer to be freed as long as a client has an open handle. So when you unplug/replug, X has kept open a handle to the first instance, so the new instance must get the next available number.
The udlfb code has been designed with the idea that we might have the fb device that’s sticking around get matched back up to the USB device with the same serial #, if the USB device goes away and comes back. But that support’s not finished.
Okay. After reloading the module dependencies the value of fb_defio is still 0.
That’s not right. Let me check to make sure that no recent checkins have messed that up.
While I do that, can you try modify the option on the fly by going to the
/sys/module/udlfb/parameters
directory and open the fb_defio file as su in an editor
sudo nano fb_defio
And change the parameter in place, save the file, and let me know if fb_defio is enabled?
Thanks,
Bernie
Okay. I changed it manually and when I replug it gets loaded with fb_defio=1 correctly.
Now when it ́s set manually. The screens are rotated correctly.
Thank you very much!
It ́s late for me, so I ́m going to check on why the fb_defio isn ́t loaded from the udlfb.conf tomorrow.
Glad that’s working! Thanks for working through it.
Alright. It had to do with the archlinux mkinitcpio config. I had to specify the /etc/modprobe.d/udlfb.conf to be copied into the initramfs image.
I have one more question concerning the numbering of /dev/fbX.
When I boot - nothing connected to my laptop - and I plug in the USB hub the /dev/fb0 and /dev/fb1 are created. Now, without ever using those framebuffers, I replug the hub. Now the framebuffers are /dev/fb1 and /dev/fb2.
I do not understand this, because you said, one could only be locked when when X had opened a handle. Which sound logical. But I did not use any of the first framebuffers.
Furthermore. When I put my laptop to sleep and wake it up again, the framebuffers are not used again. That ́s quite annoying. When will the feature for reassigning DL devices finished?
EDIT: Does your fbdev driver have the latest changes? I just peeked on the official repo. There have been some changes since your fork, but I did not look at them entirely.
On the xorg-fbdev driver - it’s not the latest, let me know if there’s a particular fix or feature that’s needed.
On keeping same fb number across unplug/replug: no schedule, and this has some conflicts with some things (dynamic multiseat, where higher-level code expects teardown and restart) which means we’d probably have to make the behavior an option.
On the numbering: the reason I can think of is if fbcon is opening the framebuffers.
If that’s correct, then setting udlfb’s “console” option off would keep that from happening.
As always, if there are improvements that can be done, patches are welcome.