[Petter Reinholdtsen 2013-06-03]
According to modinfo i915, I should report machines/video cards needing the invert_brightness=1 setting here. The laptop in question is described on <URL: http://www.linlap.com/packard_bell_easynote_lv >. The screen go black as soon as the i915 kernel module is loaded. The problem exist in both Debian Wheezy and Ubuntu Raring.
I had a closer look at the problem, and came up with a patch for the kernel that should fix this, relative to the Debian source 3.9.5-1:
--- drivers/gpu/drm/i915/intel_display.c.orig 2013-06-11 09:44:27.159941945 +0200 +++ drivers/gpu/drm/i915/intel_display.c 2013-06-11 09:45:35.495938898 +0200 @@ -8786,6 +8786,9 @@
/* Acer Aspire 4736Z */ { 0x2a42, 0x1025, 0x0260, quirk_invert_brightness }, + + /* Packard Bell EasyNote LV11HC */ + { 0x0156, 0x1025, 0x0688, quirk_invert_brightness }, };
static void intel_init_quirks(struct drm_device *dev)
PS: Please cc me, as I am not subscribed to the mailing list.
My initial email have not yet shown up on the mailing list archive, but I try again and hope this one fare further. :)
Hi Petter,
Can you please make this into a real kernel patch with commit message, sob line and all? See Documentation/SubmittingPatches. Diff itself looks good.
Thanks, Daniel
On Tue, Jun 11, 2013 at 10:28 AM, Petter Reinholdtsen pere@hungry.com wrote:
[Petter Reinholdtsen 2013-06-03]
According to modinfo i915, I should report machines/video cards needing the invert_brightness=1 setting here. The laptop in question is described on <URL: http://www.linlap.com/packard_bell_easynote_lv >. The screen go black as soon as the i915 kernel module is loaded. The problem exist in both Debian Wheezy and Ubuntu Raring.
I had a closer look at the problem, and came up with a patch for the kernel that should fix this, relative to the Debian source 3.9.5-1:
--- drivers/gpu/drm/i915/intel_display.c.orig 2013-06-11 09:44:27.159941945 +0200 +++ drivers/gpu/drm/i915/intel_display.c 2013-06-11 09:45:35.495938898 +0200 @@ -8786,6 +8786,9 @@
/* Acer Aspire 4736Z */ { 0x2a42, 0x1025, 0x0260, quirk_invert_brightness },
/* Packard Bell EasyNote LV11HC */{ 0x0156, 0x1025, 0x0688, quirk_invert_brightness },};
static void intel_init_quirks(struct drm_device *dev)
PS: Please cc me, as I am not subscribed to the mailing list.
My initial email have not yet shown up on the mailing list archive, but I try again and hope this one fare further. :)
-- Happy hacking Petter Reinholdtsen _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Daniel Vetter]
Hi Petter,
Can you please make this into a real kernel patch with commit message, sob line and all? See Documentation/SubmittingPatches. Diff itself looks good.
Sure. This is my first try, so I hope I got it right.
Set i915.invert_brightness=1 on Packard Bell EasyNote LV
Booting Linux on a Packard Bell EasyNote LV casues the display to turn off. The fix is to invert the brightness handling in the driver. <URL: http://www.linlap.com/packard_bell_easynote_lv > got more information about the laptop.
Bug reports: http://bugs.debian.org/710938
Signed-off-by: Petter Reinholdtsen pere@hungry.com ---
--- linux-3.9.5.orig/drivers/gpu/drm/i915/intel_display.c +++ linux-3.9.5/drivers/gpu/drm/i915/intel_display.c @@ -8786,6 +8786,9 @@ static struct intel_quirk intel_quirks[]
/* Acer Aspire 4736Z */ { 0x2a42, 0x1025, 0x0260, quirk_invert_brightness }, + + /* Packard Bell EasyNote LV11HC */ + { 0x0156, 0x1025, 0x0688, quirk_invert_brightness }, };
static void intel_init_quirks(struct drm_device *dev)
-- Happy hacking Petter Reinholdtsen
[Petter Reinholdtsen 2013-06-11]
Sure. This is my first try, so I hope I got it right.
Does the silence mean I got the kernel patch formatting right, or that I should try again?
<URL: http://lists.freedesktop.org/archives/dri-devel/2013-June/039787.html > contain the complete patch with description etc.
On Mon, Jun 24, 2013 at 11:57:43PM +0200, Petter Reinholdtsen wrote:
[Petter Reinholdtsen 2013-06-11]
Sure. This is my first try, so I hope I got it right.
Does the silence mean I got the kernel patch formatting right, or that I should try again?
Nah, silence just means that your patch fell through the crack while I've travelled around a bit. Thanks for poking, it's merged now for 3.11 (with cc: stable) to my drm-intel-next-queued branch. I've slightly bikeshedded the patch though for formatting.
Thanks, Daniel
[Daniel Vetter]
Nah, silence just means that your patch fell through the crack while I've travelled around a bit. Thanks for poking, it's merged now for 3.11 (with cc: stable) to my drm-intel-next-queued branch. I've slightly bikeshedded the patch though for formatting.
Right. Thank you.
Btw, a related question. On the laptop in question, even when I use i915.invert_brightness=1, the kernel still seem to be confused about the brightness values. This causes the KDE system powerdevil to turn off the screen when I log into KDE. <URL: https://bugs.kde.org/show_bug.cgi?id=321580 > got some details about the problem, which can be seen from this shell run:
% for interface in /sys/class/backlight/*; do echo $interface; cat $interface/max_brightness; cat $interface/actual_brightness; done /sys/class/backlight/acpi_video0 100 0 %
The max_brightness value is 100, and the current brightness is 0, which actually is full brightness (and not black screen). This fools powerdevil into turning off the screen while believing it turn it on.
Should not the ACPI backlight system also know about the inverted brightness setting, and adjust the /sys/ interface to get these values to behave consistently across all hardware models?
Is there some other quirk table for acpi that also need to be updated?
On Wed, Jun 26, 2013 at 01:30:01PM +0200, Petter Reinholdtsen wrote:
[Daniel Vetter]
Nah, silence just means that your patch fell through the crack while I've travelled around a bit. Thanks for poking, it's merged now for 3.11 (with cc: stable) to my drm-intel-next-queued branch. I've slightly bikeshedded the patch though for formatting.
Right. Thank you.
Btw, a related question. On the laptop in question, even when I use i915.invert_brightness=1, the kernel still seem to be confused about the brightness values. This causes the KDE system powerdevil to turn off the screen when I log into KDE. <URL: https://bugs.kde.org/show_bug.cgi?id=321580 > got some details about the problem, which can be seen from this shell run:
% for interface in /sys/class/backlight/*; do echo $interface; cat $interface/max_brightness; cat $interface/actual_brightness; done /sys/class/backlight/acpi_video0 100 0 %
The max_brightness value is 100, and the current brightness is 0, which actually is full brightness (and not black screen). This fools powerdevil into turning off the screen while believing it turn it on.
Should not the ACPI backlight system also know about the inverted brightness setting, and adjust the /sys/ interface to get these values to behave consistently across all hardware models?
Is there some other quirk table for acpi that also need to be updated?
If the acpi brightness controller is broken, it needs to be quirked away. For that please file a bug report against the ACPI subsystem. With that done the automagic fallback rules of the intel DDX driver should expose the "right" backlight interface through the backlight xrandr property. If KDE's powerdevil isn't using that one (and frobs around with the backlight controllers directly) that'd be a bug in kde.
Cheers, Daniel
[Daniel Vetter]
Is there some other quirk table for acpi that also need to be updated?
If the acpi brightness controller is broken, it needs to be quirked away. For that please file a bug report against the ACPI subsystem.
Right. Where do I do that? I can do it if I know what to do. :)
With that done the automagic fallback rules of the intel DDX driver should expose the "right" backlight interface through the backlight xrandr property. If KDE's powerdevil isn't using that one (and frobs around with the backlight controllers directly) that'd be a bug in kde.
I discovered that by adding acpi_backlight=vendor and keeping the i915.invert_brightness=1 setting, the screen went black again. So these settings seem to cancel each other out. But if I remove i915.invert_brightness=1, the screen no longer turn black, and KDE no longer turn off the screen when I log in, because instead of using the acpi_backlight interface it is using the intel_backlight interface, which is not inverted.
So I wonder, perhaps i915.invert_brightness=1 is the wrong quirk for this machine?
On Wed, Jun 26, 2013 at 7:35 PM, Petter Reinholdtsen pere@hungry.com wrote:
[Daniel Vetter]
Is there some other quirk table for acpi that also need to be updated?
If the acpi brightness controller is broken, it needs to be quirked away. For that please file a bug report against the ACPI subsystem.
Right. Where do I do that? I can do it if I know what to do. :)
With that done the automagic fallback rules of the intel DDX driver should expose the "right" backlight interface through the backlight xrandr property. If KDE's powerdevil isn't using that one (and frobs around with the backlight controllers directly) that'd be a bug in kde.
I discovered that by adding acpi_backlight=vendor and keeping the i915.invert_brightness=1 setting, the screen went black again. So these settings seem to cancel each other out. But if I remove i915.invert_brightness=1, the screen no longer turn black, and KDE no longer turn off the screen when I log in, because instead of using the acpi_backlight interface it is using the intel_backlight interface, which is not inverted.
So I wonder, perhaps i915.invert_brightness=1 is the wrong quirk for this machine?
acpi_backlight=vendor should disable the acpi backlights (you can check that in /sys/class/backlight), which would mean that userspace should fall back to intel backlight driver. Can you please check whether that one works even without the invert_brightness knob? I.e. not just whether you'll end up with a black screen, but whether adjusting the backlight also works correctly. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Daniel Vetter]
acpi_backlight=vendor should disable the acpi backlights (you can check that in /sys/class/backlight), which would mean that userspace should fall back to intel backlight driver. Can you please check whether that one works even without the invert_brightness knob? I.e. not just whether you'll end up with a black screen, but whether adjusting the backlight also works correctly.
Adjusting backlight using the laptop keys for this work in KDE when I boot with acpi_backlight=vendor and without invert_brightness=1. I am not sure if the buttons work the right way, though (never seen which should increase or decrease the brighness), so it might be inverted.
Is it possible to tell acpi_backlight to invert the brighness setting? Would it affect i915 too?
On Thu, Jun 27, 2013 at 3:03 PM, Petter Reinholdtsen pere@hungry.com wrote:
[Daniel Vetter]
acpi_backlight=vendor should disable the acpi backlights (you can check that in /sys/class/backlight), which would mean that userspace should fall back to intel backlight driver. Can you please check whether that one works even without the invert_brightness knob? I.e. not just whether you'll end up with a black screen, but whether adjusting the backlight also works correctly.
Adjusting backlight using the laptop keys for this work in KDE when I boot with acpi_backlight=vendor and without invert_brightness=1. I am not sure if the buttons work the right way, though (never seen which should increase or decrease the brighness), so it might be inverted.
The buttons might do something fancy behind the scenes (kernel or userspace), so can you please also check whether directly changing the backlight values in /sys/class/backlight works correctly?
Is it possible to tell acpi_backlight to invert the brighness setting? Would it affect i915 too?
acpi can't invert, and the different backlight drivers can affect each another in funny ways. Which is way we have a clearly defined priority order that userspace should use, and then _only_ touch the selected backlight. ACPI wins over i915, so if the ACPI backlight is broken (but the raw i915 backlight driver works) we need to blacklist it. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Daniel Vetter]
The buttons might do something fancy behind the scenes (kernel or userspace), so can you please also check whether directly changing the backlight values in /sys/class/backlight works correctly?
There is full brightness when I set the value of max_brightness into the brightness file (as in 'echo 4882 > brightness'), and complete darkness when it is set to 0. This was using acpi_backlight=vendor. I suspect that mean the intel_backlight driver is working correctly, but am not sure if 0 is supposed to be completely dark or not.
acpi can't invert, and the different backlight drivers can affect each another in funny ways. Which is way we have a clearly defined priority order that userspace should use, and then _only_ touch the selected backlight. ACPI wins over i915, so if the ACPI backlight is broken (but the raw i915 backlight driver works) we need to blacklist it.
Right. I guess my findings above mean the hardware should be blacklisted (from acpi?).
Is there no way to discover using ACPI if the backlight brightness setting should be inverted or not?
On Thu, Jun 27, 2013 at 05:05:44PM +0200, Petter Reinholdtsen wrote:
[Daniel Vetter]
The buttons might do something fancy behind the scenes (kernel or userspace), so can you please also check whether directly changing the backlight values in /sys/class/backlight works correctly?
There is full brightness when I set the value of max_brightness into the brightness file (as in 'echo 4882 > brightness'), and complete darkness when it is set to 0. This was using acpi_backlight=vendor. I suspect that mean the intel_backlight driver is working correctly, but am not sure if 0 is supposed to be completely dark or not.
Ok, so the intel backlight actually seems to work here and we only have a funny interaction between the acpi backlight and the intel backlight. I'll drop your patch to invert the i915 backlight brightness again.
acpi can't invert, and the different backlight drivers can affect each another in funny ways. Which is way we have a clearly defined priority order that userspace should use, and then _only_ touch the selected backlight. ACPI wins over i915, so if the ACPI backlight is broken (but the raw i915 backlight driver works) we need to blacklist it.
Right. I guess my findings above mean the hardware should be blacklisted (from acpi?).
Sounds like. Please file a bug report against ACPI -> Video on bugzilla.kernel.org.
Is there no way to discover using ACPI if the backlight brightness setting should be inverted or not?
Afai we know, not.
Cheers, Daniel
On Fri, Jun 28, 2013 at 02:15:16PM +0200, Daniel Vetter wrote:
On Thu, Jun 27, 2013 at 05:05:44PM +0200, Petter Reinholdtsen wrote:
[Daniel Vetter]
The buttons might do something fancy behind the scenes (kernel or userspace), so can you please also check whether directly changing the backlight values in /sys/class/backlight works correctly?
There is full brightness when I set the value of max_brightness into the brightness file (as in 'echo 4882 > brightness'), and complete darkness when it is set to 0. This was using acpi_backlight=vendor. I suspect that mean the intel_backlight driver is working correctly, but am not sure if 0 is supposed to be completely dark or not.
Ok, so the intel backlight actually seems to work here and we only have a funny interaction between the acpi backlight and the intel backlight. I'll drop your patch to invert the i915 backlight brightness again.
acpi can't invert, and the different backlight drivers can affect each another in funny ways. Which is way we have a clearly defined priority order that userspace should use, and then _only_ touch the selected backlight. ACPI wins over i915, so if the ACPI backlight is broken (but the raw i915 backlight driver works) we need to blacklist it.
Right. I guess my findings above mean the hardware should be blacklisted (from acpi?).
Sounds like. Please file a bug report against ACPI -> Video on bugzilla.kernel.org.
When you file that bug please add me and Jani Nikula to the cc list. We have a few other inverted brightness quirks all on similar machines. So this could all be due to the same strange interaction between drm/i915 and teh specific ACPI implementation on these machines.
Thanks, Daniel
[Daniel Vetter]
Sounds like. Please file a bug report against ACPI -> Video on bugzilla.kernel.org.
When you file that bug please add me and Jani Nikula to the cc list. We have a few other inverted brightness quirks all on similar machines. So this could all be due to the same strange interaction between drm/i915 and teh specific ACPI implementation on these machines.
Thanks for the pointers. I've now reported the bug as <URL: https://bugzilla.kernel.org/show_bug.cgi?id=60221 >.
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Petter Reinholdtsen