Created attachment 865143 [details] journal snippet Description of problem: If this happens: 1. You power on the notebook inside the docking station. 2. You log in. 3. You dock out the notebook. Then your brightness is set to minimum (the screen is nearly unreadable) and the brightness control is broken - you can't adjust the brightness. When you dock the notebook back in, the brightness is restored to the normal level and you can control it. If you start your notebook outside of the docking station, this bug is not experienced at all (even if you dock in and dock out, everything works). This is a regression with kernel-3.13.2-200.fc20.x86_64 , if I boot kernel-3.12.9-301.fc20.x86_64 then everything works OK. I have this confirmed on Thinkpad X220: 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0126] (rev 09) and also on Thinkpad T520. I guess both use Intel HD 3000? I don't see anything useful in the logs. I attach journal snippet when I undock the notebook. You can see brightness-related systemd printouts, that's when I try to change the brightness (or some of that happens automatically during docking out). Version-Release number of selected component (if applicable): kernel-3.13.2-200.fc20.x86_64 How reproducible: 100% Steps to Reproduce: 1. power on the notebook inside the docking station 2. log in 3. dock out the notebook Actual results: your brightness is set to minimum (the screen is nearly unreadable) and the brightness control is broken - you can't adjust the brightness
Do you have an external monitor attached to the dock? If so, how do you have the screens configured when docked? Which brightness controls are you using? The hardware keys or the software slider? If you use the hardware keys, does the OSD show any changes after you undock but those changes are not reflected in actual brightness adjustment? If you adjust the brightness in any manner, do the values of brightness/actual_brightness in /sys/class/backlight/acpi_video0 and/or /sys/class/backlight/intel_backlight change? If so, which is changed on 3.12 and which is changed on 3.13?
Could you also try the 3.14.0-0.rc3.git0.1.fc21.x86_64 build and see if that fixes the controls for you? I have similar hardware and can recreate your issue, and I think 3.14-rc3 seems to work again but I'd like you to confirm.
(In reply to Josh Boyer from comment #1) > Do you have an external monitor attached to the dock? Yes. > If so, how do you > have the screens configured when docked? $ xrandr Screen 0: minimum 320 x 200, current 3286 x 1080, maximum 8192 x 8192 LVDS1 connected 1366x768+0+128 (normal left inverted right x axis y axis) 277mm x 156mm 1366x768 60.1*+ 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) HDMI3 connected primary 1920x1080+1366+0 (normal left inverted right x axis y axis) 510mm x 290mm 1920x1080 60.0*+ 1680x1050 59.9 1280x1024 60.0 1280x960 60.0 1152x864 60.0 1024x768 60.0 800x600 60.3 640x480 60.0 DP2 disconnected (normal left inverted right x axis y axis) DP3 disconnected (normal left inverted right x axis y axis) > > Which brightness controls are you using? The hardware keys or the software > slider? Neither of them work. > > If you use the hardware keys, does the OSD show any changes after you undock > but those changes are not reflected in actual brightness adjustment? Exactly. OSD indicates changes, but the actual brightness is not changed. > > If you adjust the brightness in any manner, do the values of > brightness/actual_brightness in /sys/class/backlight/acpi_video0 and/or > /sys/class/backlight/intel_backlight change? If so, which is changed on > 3.12 and which is changed on 3.13? On 3.12, the {acpi_video0,intel_backlight}/{actual_,}brightness attribute changes value according to my changes. On 3.13 acpi_video0/{actual_,}brightness value changes as well, but intel_backlight}/{actual_,}brightness value is stuck to 44 (out of 3000 max) and doesn't change at all. (In reply to Josh Boyer from comment #2) > Could you also try the 3.14.0-0.rc3.git0.1.fc21.x86_64 build and see if that > fixes the controls for you? I have similar hardware and can recreate your > issue, and I think 3.14-rc3 seems to work again but I'd like you to confirm. I tested kernel-3.14.0-0.rc3.git2.1.fc21.x86_64 and it seems to be fixed there. It's a bit different build, let me know if I should retest exactly the one you suggested.
No, the kernel you tested is fine. I have no idea what fixed it in the newer kernels yet, but it happened after the DRM merge. A reverse bisect I've been working on has proven utterly unhelpful.
Can you please test this scratch kernel when it finishes building: http://koji.fedoraproject.org/koji/taskinfo?taskID=6557799 It works locally, but I'd like confirmation before I follow up with upstream.
Hello?
Vacation. Problem is fixed in comment 5, thanks.
Upstream reviewed the patch to fix this and said it wasn't technically correct. Doing the correct fix is a bit more invasive of a backport than is really suitable it seems. We're likely going to have to wait for a 3.14 rebase to fix this bug.
Just to clarify, I've found out that this problem is also triggered by disconnecting an external display. Therefore undocking is probably not the root cause (there is an external display connected to my dock), disconnecting from an external display is.
Thanks. That actually makes sense with the upstream diagnosis still.
I see the following stacktrace after suspending/resuming and undocking: [74755.531008] Hardware name: LENOVO 4243BQ9/4243BQ9, BIOS 8AET56WW (1.36 ) 12/06/2011 [74755.531010] 0000000000000009 ffff8800ca74dbd0 ffffffff81686fdc ffff8800ca74dc18 [74755.531015] ffff8800ca74dc08 ffffffff8106d47d ffff880036ce8000 0000000000070008 [74755.531018] 00000001046fce31 0000000000000000 ffff88021029a320 ffff8800ca74dc68 [74755.531022] Call Trace: [74755.531033] [<ffffffff81686fdc>] dump_stack+0x45/0x56 [74755.531040] [<ffffffff8106d47d>] warn_slowpath_common+0x7d/0xa0 [74755.531045] [<ffffffff8106d4ec>] warn_slowpath_fmt+0x4c/0x50 [74755.531071] [<ffffffffa00cc2cb>] intel_wait_for_pipe_off+0x1db/0x1f0 [i915] [74755.531093] [<ffffffffa00cc380>] intel_disable_pipe+0xa0/0xb0 [i915] [74755.531114] [<ffffffffa00cd454>] ironlake_crtc_disable+0xe4/0x940 [i915] [74755.531135] [<ffffffffa00d3abf>] intel_crtc_update_dpms+0x6f/0xa0 [i915] [74755.531157] [<ffffffffa00d7429>] intel_connector_dpms+0x59/0x70 [i915] [74755.531180] [<ffffffffa003b3f8>] drm_mode_obj_set_property_ioctl+0x328/0x340 [drm] [74755.531199] [<ffffffffa003b440>] drm_mode_connector_property_set_ioctl+0x30/0x40 [drm] [74755.531214] [<ffffffffa002ab52>] drm_ioctl+0x502/0x630 [drm] [74755.531226] [<ffffffff8119d2bf>] ? kfree+0xff/0x130 [74755.531231] [<ffffffff81321b50>] ? lockref_put_or_lock+0x50/0x80 [74755.531236] [<ffffffff811cb6d8>] do_vfs_ioctl+0x2d8/0x4a0 [74755.531241] [<ffffffff811ba77e>] ? ____fput+0xe/0x10 [74755.531244] [<ffffffff811cb921>] SyS_ioctl+0x81/0xa0 [74755.531250] [<ffffffff81695fa9>] system_call_fastpath+0x16/0x1b [74755.531253] ---[ end trace cd788d6e38c5424a ]--- [74755.582844] [drm:ironlake_disable_pch_transcoder] *ERROR* failed to disable transcoder A This clearly worked with 3.12
When working with external displays, it seems that: a) every odd display disconnect leaves you with broken (minimal, nonadjustable) brightness b) every even display disconnect seems to work properly (brightness can be adjusted) I haven't tested this with docking station, but it's likely that it could work the same way. This might be at least some workaround, until this is fixed. Simply disconnect the display twice.
3.14.1 is in updates-testing now.
kernel-3.14.2-200.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.14.2-200.fc20
Package kernel-3.14.2-200.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.14.2-200.fc20' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-5808/kernel-3.14.2-200.fc20 then log in and leave karma (feedback).
kernel-3.14.2-200.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Unfortunately, this "Fix" (kernel-3.14.2-200.fc20) actually breaks the brightness control outright for me on an Intel GM965 (Core 2 Duo) on a Dell Inspiron 1420. Since this update, the brightness is stuck at the lowest possible setting. Neither the graphical slider nor the hardware Fn+Up/Down keys have any effect.
I never had an issue described in the original report (or just didn't notice), but just like in Christopher Tubbs' case (Comment 17), after upgrading to kernel-3.14.2-200.fc20 my brightess is messed up - always at the lowest possible setting and there's no way to increase it via xrandr or xbacklightset. Do we need to report a separate bug? What information can I provide to help fixing this issue? I'm using Dell XPS m1330 with Intel® 965GM graphics.
I have encountered the same issue as Karolis Pocius. Since the update to 3.14.2-200.fc20 display brightness isn't working, while I had never experienced the original problem. I use the same laptop as Karolis Pocius (Dell XPS m1330 with Intel® 965GM graphics) Anything we can do to help fixing this? Regards Sören
I also have this problem. Would love to know how to manually get brightness to a proper level without a reboot. For me the issue happens when I'm docked, with an external monitor, and I undock while not suspended. Dave.
3.14.3-200.fc20 still has the same issue
As this issue remains closed, I believe the closes one that deals with brightness on XPS is Bug 1093991.
Same issue on a Dell Latitude D630 with Intel® 965GM graphics.