* Re: [Acpi4asus-user] 1005PE's and backlight controls [not found] ` <r2odb599ead1004140624g56c2465qc4aaa3d1ee1c79b3@mail.gmail.com> @ 2010-04-14 13:45 ` Corentin Chary 2010-04-14 14:00 ` Chris Bagwell 0 siblings, 1 reply; 16+ messages in thread From: Corentin Chary @ 2010-04-14 13:45 UTC (permalink / raw) To: Chris Bagwell; +Cc: acpi4asus-user, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Acpi4asus-user] 1005PE's and backlight controls 2010-04-14 13:45 ` [Acpi4asus-user] 1005PE's and backlight controls Corentin Chary @ 2010-04-14 14:00 ` Chris Bagwell 2010-04-15 3:34 ` Wang, Yong Y 0 siblings, 1 reply; 16+ messages in thread From: Chris Bagwell @ 2010-04-14 14:00 UTC (permalink / raw) To: Corentin Chary; +Cc: acpi4asus-user, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: [Acpi4asus-user] 1005PE's and backlight controls 2010-04-14 14:00 ` Chris Bagwell @ 2010-04-15 3:34 ` Wang, Yong Y 2010-04-15 4:35 ` Wang, Yong Y 0 siblings, 1 reply; 16+ messages in thread From: Wang, Yong Y @ 2010-04-15 3:34 UTC (permalink / raw) To: Chris Bagwell, Corentin Chary; +Cc: acpi4asus-user, platform-driver-x86 > -----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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: [Acpi4asus-user] 1005PE's and backlight controls 2010-04-15 3:34 ` Wang, Yong Y @ 2010-04-15 4:35 ` Wang, Yong Y 0 siblings, 0 replies; 16+ messages in thread From: Wang, Yong Y @ 2010-04-15 4:35 UTC (permalink / raw) To: Chris Bagwell, Corentin Chary; +Cc: acpi4asus-user, platform-driver-x86 > -----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 ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <y2g3b2dfeb01004131934x67e23d80vc73dfd6d5af133fa-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: 1005PE's and backlight controls [not found] ` <y2g3b2dfeb01004131934x67e23d80vc73dfd6d5af133fa-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2010-04-14 16:23 ` Alan Jenkins 2010-04-14 16:40 ` [Acpi4asus-user] " Matthew Garrett 0 siblings, 1 reply; 16+ messages in thread From: Alan Jenkins @ 2010-04-14 16:23 UTC (permalink / raw) To: Chris Bagwell Cc: ACPI Devel Maling List, acpi4asus-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, platform-driver-x86-u79uwXL29TY76Z2rM5mHXA 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® 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Acpi4asus-user] 1005PE's and backlight controls 2010-04-14 16:23 ` Alan Jenkins @ 2010-04-14 16:40 ` Matthew Garrett 2010-04-14 17:14 ` Chris Bagwell 2010-04-14 20:07 ` Corentin Chary 0 siblings, 2 replies; 16+ messages in thread From: Matthew Garrett @ 2010-04-14 16:40 UTC (permalink / raw) To: Alan Jenkins Cc: Chris Bagwell, ACPI Devel Maling List, acpi4asus-user, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Acpi4asus-user] 1005PE's and backlight controls 2010-04-14 16:40 ` [Acpi4asus-user] " Matthew Garrett @ 2010-04-14 17:14 ` Chris Bagwell 2010-04-14 17:26 ` Matthew Garrett 2010-04-14 20:07 ` Corentin Chary 1 sibling, 1 reply; 16+ messages in thread From: Chris Bagwell @ 2010-04-14 17:14 UTC (permalink / raw) To: Matthew Garrett Cc: Alan Jenkins, ACPI Devel Maling List, acpi4asus-user, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Acpi4asus-user] 1005PE's and backlight controls 2010-04-14 17:14 ` Chris Bagwell @ 2010-04-14 17:26 ` Matthew Garrett 2010-04-14 22:18 ` Chris Bagwell 0 siblings, 1 reply; 16+ messages in thread From: Matthew Garrett @ 2010-04-14 17:26 UTC (permalink / raw) To: Chris Bagwell Cc: Alan Jenkins, ACPI Devel Maling List, acpi4asus-user, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Acpi4asus-user] 1005PE's and backlight controls 2010-04-14 17:26 ` Matthew Garrett @ 2010-04-14 22:18 ` Chris Bagwell 2010-04-15 1:30 ` Zhang Rui 0 siblings, 1 reply; 16+ messages in thread From: Chris Bagwell @ 2010-04-14 22:18 UTC (permalink / raw) To: Matthew Garrett Cc: Alan Jenkins, ACPI Devel Maling List, acpi4asus-user, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Acpi4asus-user] 1005PE's and backlight controls 2010-04-14 22:18 ` Chris Bagwell @ 2010-04-15 1:30 ` Zhang Rui 2010-04-15 1:42 ` Zhang Rui 2010-04-15 2:00 ` Chris Bagwell 0 siblings, 2 replies; 16+ messages in thread From: Zhang Rui @ 2010-04-15 1:30 UTC (permalink / raw) To: Chris Bagwell Cc: Matthew Garrett, Alan Jenkins, ACPI Devel Maling List, acpi4asus-user, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: 1005PE's and backlight controls 2010-04-15 1:30 ` Zhang Rui @ 2010-04-15 1:42 ` Zhang Rui 2010-04-15 2:10 ` [Acpi4asus-user] " Chris Bagwell 2010-04-15 2:00 ` Chris Bagwell 1 sibling, 1 reply; 16+ messages in thread From: Zhang Rui @ 2010-04-15 1:42 UTC (permalink / raw) To: Chris Bagwell Cc: platform-driver-x86-u79uwXL29TY76Z2rM5mHXA, Matthew Garrett, acpi4asus-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f, ACPI Devel Maling List 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® 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Acpi4asus-user] 1005PE's and backlight controls 2010-04-15 1:42 ` Zhang Rui @ 2010-04-15 2:10 ` Chris Bagwell 2010-04-15 2:29 ` Zhang Rui 0 siblings, 1 reply; 16+ messages in thread From: Chris Bagwell @ 2010-04-15 2:10 UTC (permalink / raw) To: Zhang Rui Cc: Matthew Garrett, Alan Jenkins, ACPI Devel Maling List, acpi4asus-user, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Acpi4asus-user] 1005PE's and backlight controls 2010-04-15 2:10 ` [Acpi4asus-user] " Chris Bagwell @ 2010-04-15 2:29 ` Zhang Rui 2010-04-16 0:02 ` Chris Bagwell 0 siblings, 1 reply; 16+ messages in thread From: Zhang Rui @ 2010-04-15 2:29 UTC (permalink / raw) To: Chris Bagwell Cc: Matthew Garrett, Alan Jenkins, ACPI Devel Maling List, acpi4asus-user, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Acpi4asus-user] 1005PE's and backlight controls 2010-04-15 2:29 ` Zhang Rui @ 2010-04-16 0:02 ` Chris Bagwell 0 siblings, 0 replies; 16+ messages in thread From: Chris Bagwell @ 2010-04-16 0:02 UTC (permalink / raw) To: Zhang Rui Cc: Matthew Garrett, Alan Jenkins, ACPI Devel Maling List, acpi4asus-user, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Acpi4asus-user] 1005PE's and backlight controls 2010-04-15 1:30 ` Zhang Rui 2010-04-15 1:42 ` Zhang Rui @ 2010-04-15 2:00 ` Chris Bagwell 1 sibling, 0 replies; 16+ messages in thread From: Chris Bagwell @ 2010-04-15 2:00 UTC (permalink / raw) To: Zhang Rui Cc: Matthew Garrett, Alan Jenkins, ACPI Devel Maling List, acpi4asus-user, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Acpi4asus-user] 1005PE's and backlight controls 2010-04-14 16:40 ` [Acpi4asus-user] " Matthew Garrett 2010-04-14 17:14 ` Chris Bagwell @ 2010-04-14 20:07 ` Corentin Chary 1 sibling, 0 replies; 16+ messages in thread From: Corentin Chary @ 2010-04-14 20:07 UTC (permalink / raw) To: Matthew Garrett Cc: Alan Jenkins, Chris Bagwell, ACPI Devel Maling List, acpi4asus-user, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2010-04-16 0:02 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <y2g3b2dfeb01004131934x67e23d80vc73dfd6d5af133fa@mail.gmail.com> [not found] ` <o2z71cd59b01004132316jd06b2a40m593ee5376e4dfa28@mail.gmail.com> [not found] ` <r2odb599ead1004140624g56c2465qc4aaa3d1ee1c79b3@mail.gmail.com> 2010-04-14 13:45 ` [Acpi4asus-user] 1005PE's and backlight controls Corentin Chary 2010-04-14 14:00 ` Chris Bagwell 2010-04-15 3:34 ` Wang, Yong Y 2010-04-15 4:35 ` Wang, Yong Y [not found] ` <y2g3b2dfeb01004131934x67e23d80vc73dfd6d5af133fa-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2010-04-14 16:23 ` Alan Jenkins 2010-04-14 16:40 ` [Acpi4asus-user] " Matthew Garrett 2010-04-14 17:14 ` Chris Bagwell 2010-04-14 17:26 ` Matthew Garrett 2010-04-14 22:18 ` Chris Bagwell 2010-04-15 1:30 ` Zhang Rui 2010-04-15 1:42 ` Zhang Rui 2010-04-15 2:10 ` [Acpi4asus-user] " Chris Bagwell 2010-04-15 2:29 ` Zhang Rui 2010-04-16 0:02 ` Chris Bagwell 2010-04-15 2:00 ` Chris Bagwell 2010-04-14 20:07 ` Corentin Chary
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.