Re: 1005PE's and backlight controls

Re: 1005PE's and backlight controls

[Alan Jenkins]

On 4/14/10, Chris Bagwell <chris-ZCD0YumhXB+iMFqZbmIluw@public.gmane.org> wrote:
> Hi all,
>
> I've seen the following issue reported on various web pages but not sure if
> it was directly reported.  First up, you guys know about issue with acpi_osi
> of "Windows 2009" disables eeepc_backend and thats were eeepc_wmi comes in.

[Subsequent messages from Chris clarified that both eeepc-laptop and
eeepc-wmi suffer as described below]

> There is a secondary bug though if you boot with acpi_osi="!Windows 2009"
> (or "Linux").  The ACPI driver will take control of backlight controls with
> Fn-F5/F6.  Those keys will work but has issues with Gnome and other user
> processes.
>
> Anything that uses any of the /sys/* interfaces to control backlight do not
> work correctly.  When software cycles threw levels, the behavior is kinda
> odd.  It will cycle each time you dim to something like
> Bright->Dim->Bight->Off->Bright->etc.  Also, Gnome will give no feedback
> because eeepc_laptop discards the events and it will not make it to
> /dev/input/event*.  And last, the status of current brightness is never
> updated under /sys/* correctly which confuses Gnome as well.
>
> The secondary work around is to add acpi_backlight=vendor to boot options.
> Then eepc_backlight takes charge and life is good.  Gnome gives visual
> feedback and dimmer works as expected.
>
> Baring a firmware fix from Asus, would it be possible to enable some sort of
> backlist for using ACPI backlight support and have 1005P's use eeepc_laptop?
>
> Chris

I suggest you contact the ACPI video maintainer, Zhang Rui
<rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, and attach the output of "dmidecode".  The best
way would probably be to report the problem on bugzilla.kernel.org (on
the ACPI video driver).

I think it will indeed be possible to blacklist your machine, because
someone has already anticipated this problem :-).


drivers/acpi/video_detect.c:

long acpi_video_get_capabilities(acpi_handle graphics_handle)
...
		/* Add blacklists here. Be careful to use the right *DMI* bits
		 * to still be able to override logic via boot params, e.g.:
		 *
		 *   if (dmi_name_in_vendors("XY")) {
...
		 *	acpi_video_support |=
		 *		ACPI_VIDEO_BACKLIGHT_DMI_VENDOR;
		 *}
		 */

Regards
Alan

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

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

[Matthew Garrett]

On Wed, Apr 14, 2010 at 05:23:22PM +0100, Alan Jenkins wrote:

> I suggest you contact the ACPI video maintainer, Zhang Rui
> <rui.zhang@intel.com>, and attach the output of "dmidecode".  The best
> way would probably be to report the problem on bugzilla.kernel.org (on
> the ACPI video driver).
> 
> I think it will indeed be possible to blacklist your machine, because
> someone has already anticipated this problem :-).

dmi blacklisting is almost certainly wrong. It's more likely that 
eeepc-laptop shouldn't be registering a backlight if 
acpi_video_backlight_support() is true, but we'll then want to 
investigate whether we also need to send the keyboard events through.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

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

[Chris Bagwell]

On Wed, Apr 14, 2010 at 11:40 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Wed, Apr 14, 2010 at 05:23:22PM +0100, Alan Jenkins wrote:
>
>> I suggest you contact the ACPI video maintainer, Zhang Rui
>> <rui.zhang@intel.com>, and attach the output of "dmidecode".  The best
>> way would probably be to report the problem on bugzilla.kernel.org (on
>> the ACPI video driver).

Thanks for pointers.  Its sometimes difficult to know were to ask for
help.  I found two bugzilla reports that are related:

Mentions exact bug that I'm seeing but doesn't document the
acpi_backlight=vendor work around.  I've added my information to it:

https://bugzilla.kernel.org/show_bug.cgi?id=15182

Similar issue reported by an HP Mini and a 1005P user:

https://bugzilla.kernel.org/show_bug.cgi?id=15532

>>
>> I think it will indeed be possible to blacklist your machine, because
>> someone has already anticipated this problem :-).
>
> dmi blacklisting is almost certainly wrong. It's more likely that
> eeepc-laptop shouldn't be registering a backlight if
> acpi_video_backlight_support() is true, but we'll then want to
> investigate whether we also need to send the keyboard events through.

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?

The visual indication is very nice to have although its a "feature"
that today the event isn't making it to gnome-power-manager.  If it
got involved, it would probably write to the /sys/* interfaces and I'd
get the non-linear brightness changes even for Fn-* changes.  If ACPI
video driver can be fixed to stop non-linear part then I'd like to
have the events somehow.

If you guys think letting key event go threw is correct behavior then
I may be able to provide a patch to eeepc-laptop for this.

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

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

[Matthew Garrett]

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.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

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

[Corentin Chary]

On Wed, Apr 14, 2010 at 6:40 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Wed, Apr 14, 2010 at 05:23:22PM +0100, Alan Jenkins wrote:
>
>> I suggest you contact the ACPI video maintainer, Zhang Rui
>> <rui.zhang@intel.com>, and attach the output of "dmidecode".  The best
>> way would probably be to report the problem on bugzilla.kernel.org (on
>> the ACPI video driver).
>>
>> I think it will indeed be possible to blacklist your machine, because
>> someone has already anticipated this problem :-).
>
> dmi blacklisting is almost certainly wrong. It's more likely that
> eeepc-laptop shouldn't be registering a backlight if
> acpi_video_backlight_support() is true, but we'll then want to
> investigate whether we also need to send the keyboard events through.
>

Hum, it isn't (or maybe I didn't understand what you mean ?)
> if (!acpi_video_backlight_support())
>                result = eeepc_backlight_init(eeepc);



-- 
Corentin Chary
http://xf.iksaif.net
--
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

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

[Chris Bagwell]

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.

If I change acpi_osi="!Windows 2009" with and without
acpi_backlight=vendor then I get events like:

hotkey ATKD 00000027 00000000
hotkey ATKD 00000026 00000000
hotkey ATKD 00000025 00000000
hotkey ATKD 00000024 00000000

The main difference is that with acpi_backlight=vendor then I also get
events sent on /dev/input/event*.

From here, I'd have to compile some custom eeepc-laptop's and see if
bd->props.brightness is being updated with correct values and then we
could do just the event send while skipping the update part.

...or is there a way to not register for events 0x20 to 0x2f and let
ACPI Video process those?  If later is more correct way, is it obvious
why that code isn't sending key events today?

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

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

[Zhang Rui]

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.

could you tell me your BIOS version please?

thanks,
rui

> If I change acpi_osi="!Windows 2009" with and without
> acpi_backlight=vendor then I get events like:
> 
> hotkey ATKD 00000027 00000000
> hotkey ATKD 00000026 00000000
> hotkey ATKD 00000025 00000000
> hotkey ATKD 00000024 00000000
> 
> The main difference is that with acpi_backlight=vendor then I also get
> events sent on /dev/input/event*.
> 
> From here, I'd have to compile some custom eeepc-laptop's and see if
> bd->props.brightness is being updated with correct values and then we
> could do just the event send while skipping the update part.
> 
> ...or is there a way to not register for events 0x20 to 0x2f and let
> ACPI Video process those?  If later is more correct way, is it obvious
> why that code isn't sending key events today?
> 
> Chris
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: 1005PE's and backlight controls

[Zhang Rui]

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-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.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.
> 
Oh, this have already been fixed in the latest BIOS.

Chris,
do you mean you get duplicate hotkey events after upgrading the BIOS?

thanks,
rui

> could you tell me your BIOS version please?
> 
> thanks,
> rui
> 
> > If I change acpi_osi="!Windows 2009" with and without
> > acpi_backlight=vendor then I get events like:
> > 
> > hotkey ATKD 00000027 00000000
> > hotkey ATKD 00000026 00000000
> > hotkey ATKD 00000025 00000000
> > hotkey ATKD 00000024 00000000
> > 
> > The main difference is that with acpi_backlight=vendor then I also get
> > events sent on /dev/input/event*.
> > 
> > From here, I'd have to compile some custom eeepc-laptop's and see if
> > bd->props.brightness is being updated with correct values and then we
> > could do just the event send while skipping the update part.
> > 
> > ...or is there a way to not register for events 0x20 to 0x2f and let
> > ACPI Video process those?  If later is more correct way, is it obvious
> > why that code isn't sending key events today?
> > 
> > Chris
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

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

[Chris Bagwell]

On Wed, Apr 14, 2010 at 8:30 PM, Zhang Rui <rui.zhang@intel.com> 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.

If I do not set acpi_backlight=vendor and then change brightness by
writing to above /sys/* link this is same behaviour I see as well.  If
I use Fn-F5 and Fn-F6, I do not see the issue (brightness increments
linearly).  I believe thats because events are not sent to
/dev/input/event* and so software (gnome-power-manager) is never
notified and won't wrote to /sys/*.  If I launch power manager
preferences and change brightness then I do see issue.

In this case, I'm using Fedora 13 beta's kernel 2.6.33.2-41.

>
> could you tell me your BIOS version please?

Yesterday, I was running 0901 and today I'm running 1003.  Same
behaviour in both cases.
--
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

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

[Chris Bagwell]

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.

>
> 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.  When I add that
option, I finally get correct events out /dev/input/event* and not any
duplicate.

In all cases, I get some kind of events by monitoring /proc/acpi/event
when pressing Fn-* but not any duplicates... and I suspect those are
not considered  as duplicates of /dev/input/*.

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

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

[Zhang Rui]

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

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

[Chris Bagwell]

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