the patch here: http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=5935c93ce77a5da09aab9b45b1a5710d681c171e seems uneffective to me. I just installed xf86-video-intel 2.99.916 but the issue is still present, ivybridge here. Switching from sna to uxa made thing works as they should.
Ineffective because it is not a ddx bug.
Thanks for answering. Could you please point me in some direction? Maybe we need to file a bug report to the kernel?
We just did file a bug report against the kernel. If you attach you Xorg.0.log we know if it is the intel backlight or acpi. If you attach a drm.debug=6 dmesg from across the VT switch, we should be able to see exactly what i915.ko sets the backlight to (if not why).
Similarly if you compile with --enable-debug=full you can see exactly what the ddx thinks is happening.
Created attachment 106253 [details] Xorg.0.log while switching VTs
Created attachment 106254 [details] dmesg with drm.debug=6 while switching Vts
After 32.8s (which is when X starts its VT switch), in the kernel we see the backlight set to 0 (for the modeswitch), then set to 100 (which I presume is the actual_level being restored), then the kernel sets it to max on the installation of the fbcon and intel_panel_enable_backlight(). The bug is that intel_panel_enable_backlight() always sets the max value ignoring the current user value.
(A second bug that should be fixed with 3.17/universal planes is the need to switch of the CRTCs in the first place in order to uninstall the Xserver's framebuffer.)
Created attachment 106300 [details] [review] More backlight debug A little more debugging to track changes in the backlight.level
(In reply to Chris Wilson from comment #7) > The bug is that intel_panel_enable_backlight() always sets the max value > ignoring the current user value. That's not really true. It sets the max value if the userspace set the level to minimum before the backlight was disabled. Why does the userspace insist on setting backlight to min before disable?
Because we may not be using a backlight interface that interacts with i915.ko. E.g. a bunch of my pineview machines.
(In reply to Jani Nikula from comment #10) > (In reply to Chris Wilson from comment #7) > > The bug is that intel_panel_enable_backlight() always sets the max value > > ignoring the current user value. > > That's not really true. It sets the max value if the userspace set the level > to minimum before the backlight was disabled. Why does the userspace insist > on setting backlight to min before disable? To put it another way: Why does the kernel insist on providing policy that overrides userspace?
(In reply to Chris Wilson from comment #12) > (In reply to Jani Nikula from comment #10) > > (In reply to Chris Wilson from comment #7) > > > The bug is that intel_panel_enable_backlight() always sets the max value > > > ignoring the current user value. > > > > That's not really true. It sets the max value if the userspace set the level > > to minimum before the backlight was disabled. Why does the userspace insist > > on setting backlight to min before disable? > > To put it another way: Why does the kernel insist on providing policy that > overrides userspace? Hysterical raisins, dating back to i915 mode setting support in 2008. I assume pretty much impossible to remove now, since too many use cases depend on being able to see something when the connector is enabled, regardless of the backlight setting. For the record, I wince every time I look at that if (level == min) level = max; bit in the code.
So I guess this is a wontfix wart? It can be worked around in userspace at least, by avoiding the set to a minimum backlight level before switching.
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.