Bug 30710 - server layout with first screen managed by intel driver not behaving correctly
Summary: server layout with first screen managed by intel driver not behaving correctly
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
Depends on:
Reported: 2010-10-08 08:16 UTC by Jelle de Jong
Modified: 2018-06-12 18:43 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

dual-head-intel-displaylink-setup01-working-not-wanted (40.62 KB, text/plain)
2010-10-08 08:17 UTC, Jelle de Jong
no flags Details
dual-head-intel-displaylink-setup02-not-working-wanted (23.32 KB, text/plain)
2010-10-08 08:17 UTC, Jelle de Jong
no flags Details
plugable-uga-2k-a-displaylink-usb-2.0-display-adapter-device-information (10.65 KB, text/plain)
2010-10-08 08:18 UTC, Jelle de Jong
no flags Details

Description Jelle de Jong 2010-10-08 08:16:11 UTC
I am now trying to get a setup working with a intel based laptop with a 19" SAMSUNG VGA attached and a displaylink devices with 19" DVI SAMSUNG attached. I need the intel VGA output to be the primary monitor because I also use it to watch video and the displaylink devices shutters when playing full screen video (small sized video windows do work)

My major issues is that my displaylink device is not used when it is not the first found screen section in the serverlayout section of my xorg configuration. When it is the first found screen section it does work but the displaylink will be the primary monitor and this is not a situation I can work with.
Comment 1 Jelle de Jong 2010-10-08 08:17:04 UTC
Created attachment 39286 [details]
Comment 2 Jelle de Jong 2010-10-08 08:17:38 UTC
Created attachment 39287 [details]
Comment 3 Jelle de Jong 2010-10-08 08:18:00 UTC
Created attachment 39288 [details]
Comment 4 Jelle de Jong 2010-10-08 11:28:57 UTC
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?
Comment 5 Chris Wilson 2011-01-26 10:11:23 UTC
Doesn't seem to be an Intel problem, just that probing of the DL device fails.
Comment 6 Jelle de Jong 2011-01-26 10:45:11 UTC
(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?
Comment 7 Leho Kraav (:macmaN :lkraav) 2011-06-18 19:17:55 UTC
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?
Comment 8 Leho Kraav (:macmaN :lkraav) 2011-06-18 19:40:57 UTC
is http://www.spinics.net/lists/xorg/msg51273.html related?
Comment 9 Orion Poplawski 2012-03-12 09:52:01 UTC
I see the same thing but with the nouveau driver as primary, so probably not intel specific.
Comment 10 Leho Kraav (:macmaN :lkraav) 2012-03-12 09:55:58 UTC
I'm pretty sure http://www.phoronix.com/scan.php?page=news_item&px=MTA2NzE is what we're all waiting for here.
Comment 11 Orion Poplawski 2012-03-13 08:01:16 UTC
Hmm, both intel and nouveau also load fb, I wonder if that is conflicting with displaylink's attempt to acuire its fb device.
Comment 12 Orion Poplawski 2012-03-13 15:12:53 UTC

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.
Comment 13 Orion Poplawski 2012-03-13 16:16:08 UTC
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?
Comment 14 Adam Jackson 2018-06-12 18:43:52 UTC
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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.