| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <71cd59b00906141226k37b90b9ey7347ed85ec17a17b@mail.gmail.com> Date: Sun, 14 Jun 2009 21:26:02 +0200 From: Corentin Chary <corentin.chary@...il.com> To: Alan Jenkins <sourcejedi.lkml@...glemail.com> Cc: Alan Jenkins <alan-jenkins@...fmail.co.uk>, linux-kernel@...r.kernel.org, acpi4asus-user@...ts.sourceforge.net, Matthew Garrett <mjg59@...f.ucam.org>, Darren Salt <linux@...mustbejoking.demon.co.uk>, gnome-power-manager-list@...me.org Subject: Re: [PATCH 2.6.29] eeepc-laptop: report brightness control events via the input layer On Sat, Jun 13, 2009 at 7:51 PM, Alan Jenkins<sourcejedi.lkml@...glemail.com> wrote: > On 6/13/09, Darren Salt <linux@...mustbejoking.demon.co.uk> wrote: >> I demand that Corentin Chary may or may not have written... >> >>> On Sat, Jun 13, 2009 at 11:33 AM, Alan >>> Jenkins<alan-jenkins@...fmail.co.uk> >>> wrote: >> [snip] >>>> The firmware still changes the brightness immediately. It seems >>>> that when g-p-m gets delayed, it responds _wrongly_. It doesn't realize >>>> that the firmware already changed the brightness, so it changes the >>>> brightness again. >> >> Should it be changing the brightness at all? I ask because every laptop >> which >> I've used will change the brightness without userspace being involved. >> (Although it's possible that g-p-m might get brightness-change events from >> some source other than that which is used to report the laptop's own >> brightness controls...) > > Good point. Google suggests it may be necessary on some other systems though. > > <https://lists.ubuntu.com/archives/kubuntu-bugs/2009-February/067008.html> > > And I was wrong before when I said g-p-m should watch the generic > backlight interface. It doesn't generate uevents, and in one way > that's good, because uevents are relatively heavyweight. So the > brightness up / down "keypress" events are the only generic way that > g-p-m can use to detect changes :-(. > > But I don't think it's important to be able to show a brightness > pop-up. So I'm less confident, but I still think this change should > be reverted. > >> [snip] >>> Version: 2.24.2-2ubuntu8 >>> Ok I can reproduce [the brightness being changed inappropriately from >>> userspace]. >> >>> I want to check if we can't fix g-p-m before reverting the patch. If >>> there is no way to fix it, I'll revert. >> >> I don't see that it can ever be reliable in the face of the brightness >> having >> already been changed without userspace involvement short of being able to >> tell it to report only on some/all events from some input devices. > > Hmm. I think I could accept it if it only played up when thrashing > the SSD. So I'll try to work out exactly what happens in the other > case I reported, in case they're not the same problem. (This other > problem is where I hold down "brightness down", then tap "brightness > up" a couple of times; the first couple of taps casue a flash as the > brightness goes first up and then down). > > Alan > CCed gnome-power-manager, as it seems to be the only userspace program concerned. You may be able to help us here. You can find the complet discussion here: http://groups.google.com/group/linux.kernel/browse_thread/thread/a7bef6cffb7c2d6b/c732f616555d5180?#c732f616555d5180 -- Corentin Chary http://xf.iksaif.net - http://uffs.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists