Since 2.21.11 the output at the last pipe stays black. The monitor gets a signal, but it doesn't show anything. Within the X server log I see messages that the driver sets up the pipes correctly. The driver has been build with --disable-uxa. Reproduced with: - Lenovo T400 (GM45) o LVDS is okay @ pipe 0 o external monitor at DVI docking station port stays black @ pipe 1 - Lenovo X230 (IvyBridge) o LVDS is okay @ pipe 0 o external monitor at VGA docking station port is okay @ pipe 1 o external monitor at DP docking station port stays black @ pipe 2 Bisecting atm.
Can you please attach the Xorg.0.log? And in the meantime test with git for commit c361b449cc3ec15819883afc220aad8823c0072d Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jul 2 09:49:48 2013 +0100 sna: Include connector status in the initial probe We cannot simply rely on connector->encoder->crtc status as with the introduction of Haswell or SDVO we may have multiple connectors using the same encoder. So we need to explictly check the connector status first, before determining if the output is connected to an active encoder and CRTC. References: https://bugs.freedesktop.org/show_bug.cgi?id=66488 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Created attachment 81864 [details] X server log
Unrelated to this bug: [ 42.584] Unknown CPU cache size I use /proc/cpuinfo to query the cache size. Is that not accessible on your system? Can you please attach it?
When you say stays black, do you mean that the kernel doesn't output anything to that pipe either? I think I need drm.debug=6 (i.e. append drm.debug=6 to your kernel commandline parameters in grub) dmesg from boot as well in this case.
(In reply to comment #1) > Can you please attach the Xorg.0.log? And in the meantime test with git for > > commit c361b449cc3ec15819883afc220aad8823c0072d > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Tue Jul 2 09:49:48 2013 +0100 > > sna: Include connector status in the initial probe > ... This one doesn't fix it. A new Xorg.0.log with access to /proc/cpuinfo will be attached. (In reply to comment #3) > Unrelated to this bug: [ 42.584] Unknown CPU cache size > > I use /proc/cpuinfo to query the cache size. Is that not accessible on your > system? Can you please attach it? The X server runs in a chroot with a striped down /proc. I've added it now. Does the lack of it result in any other drawbacks than lesser optimizations/speed? (In reply to comment #4) > When you say stays black, do you mean that the kernel doesn't output > anything to that pipe either? The monitor switches from the power saving mode to "something connected". The on-screen menu of the monitor states that the correct resolution is set. But, it doesn't show anything than a black screen. > I think I need drm.debug=6 (i.e. append drm.debug=6 to your kernel > commandline parameters in grub) dmesg from boot as well in this case. Will be attached. I've to revise my initial statement (the output at the last pipe stays black). It doesn't seem to be "last pipe" related, because a monitor at the VGA port works. X and kernel logs will be attached too.
Created attachment 81870 [details] Lenovo T400: /proc/cpuinfo
Created attachment 81871 [details] Lenovo T400: Xorg.log with c361b44, monitor at DVI - black screen
Created attachment 81873 [details] Lenovo T400: dmesg, monitor at DVI - black screen
Created attachment 81874 [details] Lenovo T400: Xorg.log with c361b44, monitor at VGA - working
Created attachment 81875 [details] Lenovo T400: dmesg, monitor at VGA - working
> (In reply to comment #3) > > Unrelated to this bug: [ 42.584] Unknown CPU cache size > > > > I use /proc/cpuinfo to query the cache size. Is that not accessible on your > > system? Can you please attach it? > > The X server runs in a chroot with a striped down /proc. I've added it now. > Does the lack of it result in any other drawbacks than lesser > optimizations/speed? It's used as a guide (amongst various other heuristics) for when it is preferrable to buffer up small operations versus writing directly into wc (slow) memory. Without knowing the cachesize, it presumes a small cache and so will do more operations inplace. It should just disable a small performance optimisation.
Hmm, the last action for the DVI is that we turn it off: [ 50.591298] [drm:intel_crtc_set_config], [CRTC:3] [FB:9] #connectors=1 (x y) (0 0) [ 50.591309] [drm:intel_modeset_stage_output_state], [CONNECTOR:5:LVDS-1] to [CRTC:3] [ 50.591313] [drm:intel_modeset_stage_output_state], [CONNECTOR:21:HDMI-A-2] to [CRTC:4] [ 50.591326] [drm:i9xx_update_plane], Writing base 00046000 00000000 0 0 5760 [ 50.593081] [drm:intel_update_fbc], more than one pipe active, disabling compression [ 50.593088] [drm:intel_crtc_set_config], [CRTC:4] [NOFB] [ 50.593094] [drm:intel_modeset_stage_output_state], [CONNECTOR:21:HDMI-A-2] to [NOCRTC] [ 50.593096] [drm:intel_modeset_stage_output_state], encoder changed, full mode switch [ 50.593100] [drm:intel_modeset_stage_output_state], [CONNECTOR:5:LVDS-1] to [CRTC:3] [ 50.593103] [drm:intel_modeset_stage_output_state], crtc changed, full mode switch [ 50.593109] [drm:__intel_set_mode], set mode pipe masks: modeset: 0, prepare: 0, disable: 2 Can you please recompile -intel with --enable-debug=full and attach the Xorg.0.log for both cases? (The VGA case also gets switched off then on again.)
Also interesting is that the DVI output is not detected by the kernel during boot. In fact, I think I am back to my second hypothesis that since it is not detected during boot and so not setup for fbcon/inteldrmfb, it is not passed onto X and X ignores it as well. It is detected later when somebody triggers an output probe, but they choose to ignore it as well (i.e. do not extend the desktop to the new output.)
Don't worry about rebuilding with --enable-debug=full, I can see the switch off happening here...
Next step: commit 67a6a4bfd9cd1a861911e76096923bfc652189e2 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jul 2 14:27:03 2013 +0100 sna: Hook into crtc_notify rather than ModeSet ModeSet is called after updating each CRTC, unlike crtc_notify which is called after applying all changes. The last is what we need as if we are called too early we detect that the next CRTC doesn't match our expectations and so we disable it, right before applying the desired mode. References: https://bugs.freedesktop.org/show_bug.cgi?id=66494 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Do you mind repeating your testing and attaching Xorg & dmesg? Thanks.
(In reply to comment #15) > Next step: > > commit 67a6a4bfd9cd1a861911e76096923bfc652189e2 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Tue Jul 2 14:27:03 2013 +0100 > > sna: Hook into crtc_notify rather than ModeSet > > ModeSet is called after updating each CRTC, unlike crtc_notify which is > called after applying all changes. The last is what we need as if we are > called too early we detect that the next CRTC doesn't match our > expectations and so we disable it, right before applying the desired > mode. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=66494 > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > Do you mind repeating your testing and attaching Xorg & dmesg? Thanks. Sure, with or without --enable-debug=full? Meanwhile I've got a log with --enable-debug=full. Should I attach it? And I started to annotate (for better understanding) the log of my randr client, which has things like crtc and output ids within. Would that help? (I've verified that the problem exists with xrandr too.)
(In reply to comment #16) > (In reply to comment #15) > > Do you mind repeating your testing and attaching Xorg & dmesg? Thanks. > > Sure, with or without --enable-debug=full? If you have the extra debug information, it will not hurt, so please do. At the moment, I just want to confirm that we stop doing the incorrect middle step of switching off a pipe. But after that I'll need a new idea, which will probably require more information again! > Meanwhile I've got a log with --enable-debug=full. Should I attach it? Yes, it will be useful to check the full details. > And I started to annotate (for better understanding) the log of my randr > client, which has things like crtc and output ids within. Would that help? > (I've verified that the problem exists with xrandr too.) Right now, I think the root cause of this issue is that the kernel decides there is no DVI/HDMI connection until the probe initiated by the randr client. The new DDX probe mechanism is designed to avoid doing a detection and modeset cycle and so requires the information determined by the kernel during boot to be accurate (and matches your expectations).
Created attachment 81885 [details] Lenovo T400: dmesg, monitor at DVI - black screen
Created attachment 81886 [details] Lenovo T400: Xorg.log with 67a6a4b, monitor at DVI - black screen
(In reply to comment #19) > Created attachment 81886 [details] > Lenovo T400: Xorg.log with 67a6a4b, monitor at DVI - black screen This one is with --enable-debug=full.
Ok, there seem to be no surprises left in there now. For whatever reason the HDMI/DVI connection is invisible during early boot, and is because of that never enabled. What I suspect we need to do here is run hotplug after the dock is enabled, as I presume we need to run some ACPI firmware before we can see connections beyond it.
Created attachment 81892 [details] [review] Listen for ACPI dock events and Can you please try this kernel patch and see what happens? The logging requires drm.debug=6.
(In reply to comment #22) > Created attachment 81892 [details] [review] [review] > Listen for ACPI dock events and > > Can you please try this kernel patch and see what happens? The logging > requires drm.debug=6. It doesn't change anything and the ...event=... message doesn't show up. I've added debug messages to see when the introduced functions get called and if register_dock_notifier() fails. With that, at least a message shows up that intel_dock_register() gets called, register_dock_notifier() doesn't fail. So, I wondered if it makes a difference if the thinkpad_acpi module is compiled in or not. It doesn't, no ...event=... message. These tests have been made with kernel 3.10 (+ drm.debug=6) and xf86-video-intel (+enable-debug=full) including commit 158095ff2b2d38f54ca91d2a728f919cd705ff62 sna/gen2: Fix alpha replication in the copy pipeline Additionally, I've booted into the X server, waited a few seconds, removed the monitor cable and connected it after a few seconds again. The log messages (dmesg and Xorg.0.log) for both tests (thinkpad_acpi+video compiled in or not) will float in ...
(In reply to comment #23) > These tests have been made with kernel 3.10 (+ drm.debug=6) and > xf86-video-intel (+enable-debug=full) including commit > 158095ff2b2d38f54ca91d2a728f919cd705ff62 > sna/gen2: Fix alpha replication in the copy pipeline To clarify it: with the patch "Listen for ACPI dock events" applied.
Created attachment 81953 [details] T400: dmesg (thinkpad_acpi as module)
Created attachment 81954 [details] T400: Xorg.log (thinkpad_acpi as module)
Created attachment 81955 [details] T400: dmesg (thinkpad_acpi compiled in)
Created attachment 81956 [details] T400: Xorg.log (thinkpad_acpi compiled in)
That scuppers the theory that we get an event when the dock becomes active. There is definitely a point in time at which the HDMI connection becomes available, but we don't automatically notice. Worse still, I can't see any log message suggesting something we could hook into. Suggestions?
I've added an option to restore the old probing behaviour as a temporary w/a: commit 1445a62da8a08acd8a732176d085fd098f68cec3 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Jul 3 12:59:31 2013 +0100 intel: Add an option for forced rediscovery of output status on startup Specifying Section "Device" Option "ReprobeOutputs" "true" EndSection will restore the old behaviour of scanning each output on startup and picking a spanning mode. Obviously we still need to get to the bottom of why we are not able to detect the change in output status.
(In reply to comment #0) > ... The monitor gets a signal, but it doesn't show anything. ... And I figured out why, the brightness doesn't get initialized/stays at 0.0 for the output. A simple `xrandr --output HDMI2 --brightness 1.0` fixes it. I scrolled like a 100 times through the `xrandr --verbose` output, but didn't noticed the offending line earlier. Sorry.
(In reply to comment #31) > (In reply to comment #0) > > ... The monitor gets a signal, but it doesn't show anything. ... > > And I figured out why, the brightness doesn't get initialized/stays at 0.0 > for the output. A simple `xrandr --output HDMI2 --brightness 1.0` fixes it. > > I scrolled like a 100 times through the `xrandr --verbose` output, but > didn't noticed the offending line earlier. Sorry. Heck, I had missed we had gone from wondering why the monitor was absent from the connections found by the kernel to wondering why your xrandr script wasn't working. :) Still the problem remains that we do not automatically detect the docked HDMI/DP connection.
(In reply to comment #31) > (In reply to comment #0) > > ... The monitor gets a signal, but it doesn't show anything. ... > > And I figured out why, the brightness doesn't get initialized/stays at 0.0 > for the output. A simple `xrandr --output HDMI2 --brightness 1.0` fixes it. > > I scrolled like a 100 times through the `xrandr --verbose` output, but > didn't noticed the offending line earlier. Sorry. Just had time to test the "gamma fixes" and I can verify that this behaviour is fixed with commit: d36c9542d2bd707838a87c451bf76f091aaf5cba sna: Fix gamma query to not request uninitialized values Then I tested the latest git version (ccf0fdd) with regard to the remaining problem - that HDMI output doesn't get detected. Therefor I've created new dmesg and X logs, which I'll attach (and obsolete all the others). Additionally, I've disabled my randr client to get a more clear view on what's happening. Within the logs you can see a time gap at the end. There, I've waited a few seconds and called `xrandr` (at round about uptime=61.29). (In reply to comment #32) > Heck, I had missed we had gone from wondering why the monitor was absent > from the connections found by the kernel to wondering why your xrandr script > wasn't working. :) Nit-pick: it's an application using a self written c++ library with a none blocking API and that library uses xcb. ;)
Created attachment 82271 [details] dmesg log
Created attachment 82272 [details] xorg log (xf86-video-intel at ccf0fdd)
a few notes: - Kristen Carlson Accardi's ACPI dock driver whitepaper is an interesting read: https://www.kernel.org/doc/ols/2006/ols2006v1-pages-9-18.pdf - The in-kernel notification mechanism for docking/undocking is gone from upstream
Weird. I had a T400 once, and I seem to recall that the docking station DVI port was only connected to the discrete GPU (radeon something). Or was I mistaken and it's actually muxed?
(In reply to comment #37) > Weird. I had a T400 once, and I seem to recall that the docking station DVI > port was only connected to the discrete GPU (radeon something). Or was I > mistaken and it's actually muxed? I (we) just have T400s without the additional Radeon. I even didn't knew that such models exist before your comment.
And sorry, I've completly forgotten that I've created this bug report. I just retested the T400 and X230 with - Kernel 3.12.7 - xf86-video-intel-2.99.909 and the bug is gone. Therefore I'm closing this bug. If you want me to bisect to find the "offending" commit that fixed it, then reopen the bug, please.
.o0( Hmm, don't test to much before coffee. ) - The DVI port at the docking station of the T400 doesn't come up during boot. Though, it gets activated when X comes up and the VGA port works even during boot. - All ports (VGA, DVI, DP) at the DS of the X230 work during boot. Imo the minor problem for the T400 - for this old HW - can be ignored and it seems that no one else ever noticed/cared about this issue before.
The problem is that we are aiming to eliminate that re-detection, so really the HDMI connection remains hidden until user input as the kernel (and thus userspace daemons) doesn't get a hotplug event for the dock/output coming live. I suspect the problem is more commonplace (that almost every dock will have similar problems) which will be exposed (and treated as a regression) by fastboot.
xf86-video-intel releases more recent than 2.21.9 suffer from the same kind of issue on DragonFly. Screens attached to regular outputs (not docking stations) are not properly initialized on Xorg startup. For example, I have to run xrandr --screen 1 --output HDMI1 --mode 1920x1200 for my monitor to become active. Downstream bug report: https://github.com/DragonFlyBSD/DPorts/issues/87
(In reply to comment #42) > xf86-video-intel releases more recent than 2.21.9 suffer from the same kind > of issue on DragonFly. > Screens attached to regular outputs (not docking stations) are not properly > initialized on Xorg startup. > > For example, I have to run xrandr --screen 1 --output HDMI1 --mode 1920x1200 > for my monitor to become active. > > Downstream bug report: > https://github.com/DragonFlyBSD/DPorts/issues/87 Depending on *BSD that may be intentional. X will try to inherit the mode from the previous VT user during startup, expecting that to be either what the user wants or to be immediately corrected by the display manager.
If I understand your comment correctly, that means we cannot use VTs running in 80x25 VGA text mode without getting a broken Xorg display, right ?
(In reply to comment #44) > If I understand your comment correctly, that means we cannot use VTs running > in 80x25 VGA text mode without getting a broken Xorg display, right ? You cannot use 80x25 VGA text mode whilst using the i915 driver, full stop. Somebody has to choose the mode at some point. On linux we push that to the endpoints - either the system is already configured to run at a good mode by the bios/uefi setup, or the display manager applies the user configuration. In between, there is also the fbcon layer that can autoselect a mode, and if push comes to shove, you can force the mode selection by X during its startup.
So far the only reliable way to get a working display seems to force the mode selection by Xorg, like it was done previously. I have patched the DragonFly xf86-video-intel packages to behave as if "ReprobeOutputs" "true" was always set in xorg.conf .
So does that mean we can close this one?
Chris, I'm assuming this is fixed. Please re-open if there's something you'd still like to track here.
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.