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

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

[Corentin Chary]

On Wed, Apr 14, 2010 at 3:24 PM, Chris Bagwell <chris@cnpbagwell.com> wrote:
> On Wed, Apr 14, 2010 at 1:16 AM, Corentin Chary
> <corentin.chary@gmail.com> wrote:
>> On Wed, Apr 14, 2010 at 4:34 AM, Chris Bagwell <chris@cnpbagwell.com> 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.
>>>
>>> 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
>>
>> Hi,
>> Did you try the eeepc-wmi ? It's the long term solution and it don't need
>> any extra kernel parameters. Yong Wang just added backlight support to it.
>>
>> http://git.kernel.org/?p=linux/kernel/git/mjg59/platform-drivers-x86.git;a=shortlog;h=refs/heads/for_linus
>>
>
> I havent't tried it yet but it looks like it has same issue that
> eeepc-laptop does.  If ACPI reports it handles backlight then
> eeepc-wmi disables controlling of backlight and I'd get buggy ACPI
> version.
>
> Does Yong happen to be on this email list?

I don't think, but he reads platform-x86 which is now CCed

Are you sure that the backlight behavior is the same with and without
acpi_osi=Linux ?


-- 
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 8:45 AM, Corentin Chary
<corentin.chary@gmail.com> wrote:
> On Wed, Apr 14, 2010 at 3:24 PM, Chris Bagwell <chris@cnpbagwell.com> wrote:
>> On Wed, Apr 14, 2010 at 1:16 AM, Corentin Chary
>> <corentin.chary@gmail.com> wrote:
>>> On Wed, Apr 14, 2010 at 4:34 AM, Chris Bagwell <chris@cnpbagwell.com> 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.
>>>>
>>>> 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
>>>
>>> Hi,
>>> Did you try the eeepc-wmi ? It's the long term solution and it don't need
>>> any extra kernel parameters. Yong Wang just added backlight support to it.
>>>
>>> http://git.kernel.org/?p=linux/kernel/git/mjg59/platform-drivers-x86.git;a=shortlog;h=refs/heads/for_linus
>>>
>>
>> I havent't tried it yet but it looks like it has same issue that
>> eeepc-laptop does.  If ACPI reports it handles backlight then
>> eeepc-wmi disables controlling of backlight and I'd get buggy ACPI
>> version.
>>
>> Does Yong happen to be on this email list?
>
> I don't think, but he reads platform-x86 which is now CCed
>
> Are you sure that the backlight behavior is the same with and without
> acpi_osi=Linux ?
>

I just retested to be sure and I think this confirms my suspicion that
using eeepc-wmi will not work either for 1005PE's backlights.

I tried no acpi_osi (same as "WIndows 2009" I guess),
acpi_osi="!Windows 2009", and acpi_osi="Linux"... all without
specifying acpi_backlight=vendor.  They all had the same behaviour.
The later two options allow eeepc-laptop to load and it always gives
message about ACPI controlling backlight.

You can see bad behaviour easiest by using Gnome's Preferences->Power
Management and controlling dimmer.  Sliding between 0% and 100% gives
seemingly random behaviour.  Anything software based acts bad.

Since ACPI did seem to be controlling backlight when I didn't specify
an acpi_osi, I suspect that means eeepc-wmi's logic to disable
backlight support would be invoked for 1005PE's.

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

[Wang, Yong Y]

> -----Original Message-----
> From: platform-driver-x86-owner@vger.kernel.org
> [mailto:platform-driver-x86-owner@vger.kernel.org] On Behalf Of Chris
> Bagwell
> Sent: Wednesday, April 14, 2010 10:00 PM
> To: Corentin Chary
> Cc: acpi4asus-user@lists.sourceforge.net;
> platform-driver-x86@vger.kernel.org
> Subject: Re: [Acpi4asus-user] 1005PE's and backlight controls
> 
> On Wed, Apr 14, 2010 at 8:45 AM, Corentin Chary
> <corentin.chary@gmail.com> wrote:
> > On Wed, Apr 14, 2010 at 3:24 PM, Chris Bagwell <chris@cnpbagwell.com>
> wrote:
> >> On Wed, Apr 14, 2010 at 1:16 AM, Corentin Chary
> >> <corentin.chary@gmail.com> wrote:
> >>> On Wed, Apr 14, 2010 at 4:34 AM, Chris Bagwell <chris@cnpbagwell.com>
> 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.
> >>>>
> >>>> 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
> >>>
> >>> Hi,
> >>> Did you try the eeepc-wmi ? It's the long term solution and it don't need
> >>> any extra kernel parameters. Yong Wang just added backlight support to it.
> >>>
> >>>
> http://git.kernel.org/?p=linux/kernel/git/mjg59/platform-drivers-x86.git;a=sho
> rtlog;h=refs/heads/for_linus
> >>>
> >>
> >> I havent't tried it yet but it looks like it has same issue that
> >> eeepc-laptop does.  If ACPI reports it handles backlight then
> >> eeepc-wmi disables controlling of backlight and I'd get buggy ACPI
> >> version.
> >>
> >> Does Yong happen to be on this email list?
> >
> > I don't think, but he reads platform-x86 which is now CCed
> >
> > Are you sure that the backlight behavior is the same with and without
> > acpi_osi=Linux ?
> >
> 
> I just retested to be sure and I think this confirms my suspicion that
> using eeepc-wmi will not work either for 1005PE's backlights.
> 

That is correct. Eeepc-wmi does not work on 1005PE at this moment. That is because
the ACPI BIOS of 1005PE has not fully implemented all the necessary WMI interfaces yet.
If you dump the 1005PE BIOS using acpidump, you will find that many control methods
end up calling a dummy method. We are following up this issue with ASUS and hopefully
they will fix it in later BIOS updates. Current eeepc-wmi driver has been tested on Eee PC
1008HA.

> I tried no acpi_osi (same as "WIndows 2009" I guess),
> acpi_osi="!Windows 2009", and acpi_osi="Linux"... all without
> specifying acpi_backlight=vendor.  They all had the same behaviour.
> The later two options allow eeepc-laptop to load and it always gives
> message about ACPI controlling backlight.
> 
> You can see bad behaviour easiest by using Gnome's Preferences->Power
> Management and controlling dimmer.  Sliding between 0% and 100% gives
> seemingly random behaviour.  Anything software based acts bad.
> 
> Since ACPI did seem to be controlling backlight when I didn't specify
> an acpi_osi, I suspect that means eeepc-wmi's logic to disable
> backlight support would be invoked for 1005PE's.
> 

Yes, eeepc-wmi will be loaded if acpi_osi is not specified. And if you don't specify
acpi_backlight=vendor, the generic ACPI video driver will control everything.

Thanks
-Yong

--
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

[Wang, Yong Y]

> -----Original Message-----
> From: platform-driver-x86-owner@vger.kernel.org
> [mailto:platform-driver-x86-owner@vger.kernel.org] On Behalf Of Wang, Yong
> Y
> Sent: Thursday, April 15, 2010 11:34 AM
> To: Chris Bagwell; Corentin Chary
> Cc: acpi4asus-user@lists.sourceforge.net;
> platform-driver-x86@vger.kernel.org
> Subject: RE: [Acpi4asus-user] 1005PE's and backlight controls
> 
> > -----Original Message-----
> > From: platform-driver-x86-owner@vger.kernel.org
> > [mailto:platform-driver-x86-owner@vger.kernel.org] On Behalf Of Chris
> > Bagwell
> > Sent: Wednesday, April 14, 2010 10:00 PM
> > To: Corentin Chary
> > Cc: acpi4asus-user@lists.sourceforge.net;
> > platform-driver-x86@vger.kernel.org
> > Subject: Re: [Acpi4asus-user] 1005PE's and backlight controls
> >
> > On Wed, Apr 14, 2010 at 8:45 AM, Corentin Chary
> > <corentin.chary@gmail.com> wrote:
> > > On Wed, Apr 14, 2010 at 3:24 PM, Chris Bagwell <chris@cnpbagwell.com>
> > wrote:
> > >> On Wed, Apr 14, 2010 at 1:16 AM, Corentin Chary
> > >> <corentin.chary@gmail.com> wrote:
> > >>> On Wed, Apr 14, 2010 at 4:34 AM, Chris Bagwell
> <chris@cnpbagwell.com>
> > 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.
> > >>>>
> > >>>> 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
> > >>>
> > >>> Hi,
> > >>> Did you try the eeepc-wmi ? It's the long term solution and it don't need
> > >>> any extra kernel parameters. Yong Wang just added backlight support to
> it.
> > >>>
> > >>>
> >
> http://git.kernel.org/?p=linux/kernel/git/mjg59/platform-drivers-x86.git;a=sho
> > rtlog;h=refs/heads/for_linus
> > >>>
> > >>
> > >> I havent't tried it yet but it looks like it has same issue that
> > >> eeepc-laptop does.  If ACPI reports it handles backlight then
> > >> eeepc-wmi disables controlling of backlight and I'd get buggy ACPI
> > >> version.
> > >>
> > >> Does Yong happen to be on this email list?
> > >
> > > I don't think, but he reads platform-x86 which is now CCed
> > >
> > > Are you sure that the backlight behavior is the same with and without
> > > acpi_osi=Linux ?
> > >
> >
> > I just retested to be sure and I think this confirms my suspicion that
> > using eeepc-wmi will not work either for 1005PE's backlights.
> >
> 
> That is correct. Eeepc-wmi does not work on 1005PE at this moment. That is
> because
> the ACPI BIOS of 1005PE has not fully implemented all the necessary WMI
> interfaces yet.
> If you dump the 1005PE BIOS using acpidump, you will find that many control
> methods
> end up calling a dummy method. We are following up this issue with ASUS and
> hopefully
> they will fix it in later BIOS updates. Current eeepc-wmi driver has been tested
> on Eee PC
> 1008HA.
> 
> > I tried no acpi_osi (same as "WIndows 2009" I guess),
> > acpi_osi="!Windows 2009", and acpi_osi="Linux"... all without
> > specifying acpi_backlight=vendor.  They all had the same behaviour.
> > The later two options allow eeepc-laptop to load and it always gives
> > message about ACPI controlling backlight.
> >
> > You can see bad behaviour easiest by using Gnome's Preferences->Power
> > Management and controlling dimmer.  Sliding between 0% and 100% gives
> > seemingly random behaviour.  Anything software based acts bad.
> >
> > Since ACPI did seem to be controlling backlight when I didn't specify
> > an acpi_osi, I suspect that means eeepc-wmi's logic to disable
> > backlight support would be invoked for 1005PE's.
> >
> 
> Yes, eeepc-wmi will be loaded if acpi_osi is not specified. And if you don't
> specify
> acpi_backlight=vendor, the generic ACPI video driver will control everything.
> 

Another piece of information is that eeepc-wmi only works on latest 2.6.34-rc
kernels. If you are running 2.6.33 kernel on Fedora 13 (I saw that in your comment
of bug 15182), you need to backport b7b30de53aef6ce773d34837ba7d8422bd3baeec
to make the WMI device visible so that wmi can bind to it.

--
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: 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

[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: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

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

[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