Re: [Acpi4asus-user] 1005PE's and backlight controls

[Chris Bagwell <chris@cnpbagwell.com>]

On Wed, Apr 14, 2010 at 9:29 PM, Zhang Rui <rui.zhang@intel.com> wrote:
> On Thu, 2010-04-15 at 10:10 +0800, Chris Bagwell wrote:
>> On Wed, Apr 14, 2010 at 8:42 PM, Zhang Rui <rui.zhang@intel.com> wrote:
>> > On Thu, 2010-04-15 at 09:30 +0800, Zhang Rui wrote:
>> >> On Thu, 2010-04-15 at 06:18 +0800, Chris Bagwell wrote:
>> >> > On Wed, Apr 14, 2010 at 12:26 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>> >> > > On Wed, Apr 14, 2010 at 12:14:04PM -0500, Chris Bagwell wrote:
>> >> > >
>> >> > >> Does the acpi-video logic not have logic on its own to send key
>> >> > >> events?  So I guess laptops that don't have custom modules to handle
>> >> > >> this type of stuff don't get visual feedback from gnome-power-manager?
>> >> > >
>> >> > > It does, but it's dependent upon the firmware sending them.
>> >> >
>> >> > I think the following tells me firmware is sending them.  If I leave
>> >> > acpi_osi="Windows 2009" so that eeepc_laptop doesn't get loaded, I see
>> >> > events like this on /pro/acpi/event:
>> >> >
>> >> > video LCDD 00000087 00000000
>> >> > video LCDD 00000087 00000000
>> >> > video LCDD 00000086 00000000
>> >> > video LCDD 00000086 00000000
>> >> >
>> >> > Thats a couple decreases followed by a couple increases.
>> >> >
>> >> I have a EEEpc 1005PE. I'm looking at the backlight problem on this
>> >> machine, but it seems to be different from this one.
>> >>
>> >> The hotkey seems to work perfectly when ACPI video driver is loaded.
>> >> i.e. I get a single hotkey event when pressing the hotkey and the value
>> >> of /sys/class/backlight/acpi_video0/brightness changes correctly.
>> >>
>> >> The only problem I get is that the actual brightness does not change
>> >> consistently.
>> >> say, there are 15 brightness levels in all,
>> >> level 0, level 5 and level 12 give me a screen with lowest brightness.
>> >> If I want to get maximum backlight, I need to set it to level 4 or level
>> >> 11.
>>
>> I'm curious, do you still see this issue if you first kill
>> gnome-power-manager first?
>>
>> >>
>> > Oh, this have already been fixed in the latest BIOS.
>>
>> Wasn't fixed in my case.  I'd be curious to here if it fixes for you.
>>
> no, the problem still exists.
> I misread your comment at
> https://bugzilla.kernel.org/show_bug.cgi?id=15182#c33
>
>> >
>> > Chris,
>> > do you mean you get duplicate hotkey events after upgrading the BIOS?
>>
>> With latest firmware, I get zero hotkey events over /dev/input/event*
>> unless I add acpi_backlight=vendor to boot options.
>
> I just upgrade the BIOS to 1003, and I can still get input event
> from /dev/input/event4 (which is ACPI video bus).
> and there is no duplicate input events when pressing hotkey.
>
> thanks,
> rui

OK, I played around a little more and can now  reproduce what your
seeing.  What I need to do is boot such that eeepc-laptop is not
loaded.

Thanks for mentioning exact device name /dev/input/event4.  Its
interesting that mine is registered so late at /dev/input/event7.

input: Video Bus as
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input7
ACPI: Video Device [VGA] (multi-head: yes  rom: no  post: no)

If I bootup with no options then eeepc-laptop is not loaded.  In this
case, I do see events on input7 (I previously stated that I didn't.
Sorry about that).  In this case, it appears that gnome-power-manager
gets involved (I see the percentage bar updates) and the screen does
those funky non-linear updates.

If I bootup with just acpi_osi="!Windows 2009" then eeepc-laptop does
get loaded.  In this case, the input7 still gets created but no events
are sent on it.  Also, an input9 device is created for eeepc-laptop
and brightness keys are NOT sent over it as well.  In this case, the
brightness levels are linear as long as I use Fn-keys only (not the
/sys/* interface).

And finally, if I boot with both acpi_osi="!Windows 2009" and
acpi_backlight=vendor then I  see events on eeepc-laptop input9 and
gnome-power-manager seems to get involved as well but this time the
display is updated linearly.

So in summary, I think it tells me this:

1) If ACPI only is involved then brightness controls work fine.  By
ACPI only, I mean using Fn-keys for brightness and doing something to
prevent software like gnome-power-manager from getting involved with
/sys/* interface.
2) Anything that writes to /sys/class/backlight/acpi_video0/brightness
works non-linearly.
3) If you keep software from writing to
/sys/class/backlight/acpi_video0/brightness then brightness changes
made with Fn-keys do not get reflected into any of those acpi_video0
files.  Writing to those files controls brightness non-linearly and
show up when you read back.
4) If I use acpi_backlight=vendor then I can access
/sys/class/backlight/eeepc/brightness and it works linearly.  Things
like gnome-power-manager work good with this interface.

Chris
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html