Bug 30710

Created attachment 39286 [details]
dual-head-intel-displaylink-setup01-working-not-wanted

Created attachment 39287 [details]
dual-head-intel-displaylink-setup02-not-working-wanted

Created attachment 39288 [details]
plugable-uga-2k-a-displaylink-usb-2.0-display-adapter-device-information

Comparing the logs of the one creating a dualhead setup and the one failing. I can see that the intel detection process causes an unloads the displaylink module that is needed for the next screen section to initialize.

Why is the displaylink module unloaded when the screen with the intel devices is the first in the serverlayout and not when it is listed as second screen?

Doesn't seem to be an Intel problem, just that probing of the DL device fails.

(In reply to comment #5)
> Doesn't seem to be an Intel problem, just that probing of the DL device fails.

Please compare the logs, if the DisplayLink device is the first in the serverlayout screens it works, if Intel is the first it fails, because the Intel driver unloads/loads/does something that makes the DL device probing fail. I will be at FOSDEM and I can demonstrate the issues if needed?

I am also seeing this exact same issue happen. Unfortunately, I don't have any more detailed information to contribute for now. What information is needed to pinpoint the cause of this?

is http://www.spinics.net/lists/xorg/msg51273.html related?

I see the same thing but with the nouveau driver as primary, so probably not intel specific.

I'm pretty sure http://www.phoronix.com/scan.php?page=news_item&px=MTA2NzE is what we're all waiting for here.

Hmm, both intel and nouveau also load fb, I wonder if that is conflicting with displaylink's attempt to acuire its fb device.

http://lists.freedesktop.org/archives/libdlo/2010-November/000807.html

there is another (similar) check in 
xf86ClaimFbSlot() (xf86fbBus.c) that, when claiming a frambuffer slot, 
makes sure no PCI slot has been allocated

xf86ClaimFbSlot() is failing in DisplayLinkProbe for this reason.  The poster states:

As I wanted to test the fbdev driver (as Bernie suggested in another 
thread), I just removed those fb-vs-pci checks from the X server, and 
hey, it works. I'm pretty sure this test has a reason, but as long as it 
works I'm willing to patch my X server.

So, what are the reasons for those checks?  Can we have a PCI device and fb device at the same time?  Re-assigning to server component.

Well, I am not as lucky as Christoph.  My X server crashes on login.  It may be because I already have a dual head display.  I certainly got strange behavior before the crash.

[  4164.350] 0: /usr/bin/X (xorg_backtrace+0x3c) [0x80a86ac]
[  4164.350] 1: /usr/bin/X (0x8048000+0x654d6) [0x80ad4d6]
[  4164.350] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0x62c40c]
[  4164.351] 3: /usr/bin/X (ProcRRSetScreenSize+0xa7) [0x813e897]
[  4164.351] 4: /usr/bin/X (0x8048000+0xecb11) [0x8134b11]
[  4164.351] 5: /usr/bin/X (0x8048000+0x2e195) [0x8076195]
[  4164.351] 6: /usr/bin/X (0x8048000+0x1c39a) [0x806439a]
[  4164.351] 7: /lib/libc.so.6 (__libc_start_main+0xf3) [0x462e96b3]
[  4164.351] 8: /usr/bin/X (0x8048000+0x1c6c9) [0x80646c9]
[  4164.351] Segmentation fault at address 0x50

Also, if I remove the check and go back to my default no xorg.conf configuration nouveau fails to load because it tries to run in framebuffer mode and fails.  So a reason for the check confirmed!

So, any other way around this?  A different way to claim the framebuffer for displaylink?

Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.