| Message ID | 20130611151313.GG31600@ulrik.uio.no (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
[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 >.
--- 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)