Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1519602
| From | Hans de Goede <hdegoede@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: PM regression with LED changes in next-20161109 |
| Date | 2016-11-11 09:30 +0100 |
| Message-ID | <sCfnH-1SI-3@gated-at.bofh.it> (permalink) |
| References | (3 earlier) <sBTdv-3ek-7@gated-at.bofh.it> <sBX7t-6lo-43@gated-at.bofh.it> <sC0oF-as-21@gated-at.bofh.it> <sC0I1-h7-1@gated-at.bofh.it> <sC4sh-2Vb-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi, On 10-11-16 21:48, Pavel Machek wrote: > Hi! > >>>> It seems that we should get back to your initial approach. i.e. only >>>> brightness changes caused by hardware should be reported. >>> >>> I don't think enabling poll() here is good idea. Some hardware won't >>> be able to tell you that it changed the state. Returning maximum >>> brightness trigger is going to use seems easier/better. >> >> The idea here is to allow userspace to poll() on the brightness >> sysfs atrribute to detect changes autonomously done by the hardware, >> such as e.g. happens on both Dell and Thinkpad laptops when pressing >> the keyboard backlight cycle hotkey. Note that these keys do not >> generate key-press events, the cycling through the brightness levels >> (including off) is done entirely in firmware. > > Ok, so you can do that for keyboard backlight on thinkpad... I guess > you handle that as a special trigger on the keyboard leds? No, as said this is all done in firmware, as in this is all dealt with by (presumably) the acpi-ec (acpi-embedded-controller) the kernel does not do anything here, the key is "hardwired" to control the keyboard backlight from the kernels pov. > Can other > triggers, such as heartbeat, be assigned to that "led"? > >> But we do get other ACPI events for this which we can use to let >> userspace know this happens, which is something which user- >> interfaces which allow control over the kbd backlight want to know. > > Yes, you can do that for keyboard backlight... but on thinkpads there > are more leds, such as battery led. That can blink on battery low, and > I don't think you can read the current status from hardware. Well the battery LED does not show up under /sys/class/led so that is not relevant for this situation, anyways ... > Getting current state of led blinking with cpu trigger is also not > quite a good idea. I agree with you that it would be better if reading the brightness sysfs attribute would always return the max brightness for LEDs which are blinking or have a trigger set. But it seems that Jacek disagrees, I will leave further discussion of this up to you and Jacek. > So IMO this should not be done in generic code. Instead, > kbd-backlight trigger should have special attribute, and that one > should be pollable. Again there is no kbd-backlight trigger. >> I understand that we will not always be able to do this, here is the >> Documentation/ABI/testing/sysfs-class-led text I have in mind: >> >> The file supports poll() to detect changes, changes are only >> signalled when this file is written or when the hardware / >> firmware changes the brightness itself and the driver can detect >> this. Changes done by kernel triggers / software blinking are >> not signalled. >> >> Note the "and the driver can detect this" language, that has been there >> since v1 of the poll() notification patch since I already expected not >> all hardware to be able to signal this. > > Lets move it to separate attribute, for triggers that can do that, > please. As explained above this has nothing to do with triggers... Regards, Hans
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
PM regression with LED changes in next-20161109 Tony Lindgren <tony@atomide.com> - 2016-11-09 20:30 +0100
Re: PM regression with LED changes in next-20161109 Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2016-11-09 21:50 +0100
Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-10 09:50 +0100
Re: PM regression with LED changes in next-20161109 Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-11-10 14:00 +0100
Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-10 14:10 +0100
Re: PM regression with LED changes in next-20161109 Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-11-10 15:00 +0100
Re: PM regression with LED changes in next-20161109 Pavel Machek <pavel@ucw.cz> - 2016-11-10 17:40 +0100
Re: PM regression with LED changes in next-20161109 Pavel Machek <pavel@ucw.cz> - 2016-11-10 17:30 +0100
Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-10 17:50 +0100
Re: PM regression with LED changes in next-20161109 Pavel Machek <pavel@ucw.cz> - 2016-11-10 21:50 +0100
Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-11 09:30 +0100
Re: PM regression with LED changes in next-20161109 Tony Lindgren <tony@atomide.com> - 2016-11-10 19:10 +0100
Re: PM regression with LED changes in next-20161109 Pavel Machek <pavel@ucw.cz> - 2016-11-10 21:30 +0100
Re: PM regression with LED changes in next-20161109 Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2016-11-10 22:40 +0100
Re: PM regression with LED changes in next-20161109 Pavel Machek <pavel@ucw.cz> - 2016-11-11 13:10 +0100
Re: PM regression with LED changes in next-20161109 Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2016-11-11 18:10 +0100
Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-11 20:30 +0100
Re: PM regression with LED changes in next-20161109 Pavel Machek <pavel@ucw.cz> - 2016-11-11 23:20 +0100
Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-12 09:10 +0100
Three different LED brightnesses (was Re: PM regression with LED changes in next-20161109) Pavel Machek <pavel@ucw.cz> - 2016-11-13 10:20 +0100
Re: Three different LED brightnesses (was Re: PM regression with LED changes in next-20161109) Hans de Goede <hdegoede@redhat.com> - 2016-11-13 10:50 +0100
Re: Three different LED brightnesses (was Re: PM regression with LED changes in next-20161109) Pavel Machek <pavel@ucw.cz> - 2016-11-13 21:50 +0100
Re: PM regression with LED changes in next-20161109 Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2016-11-12 11:30 +0100
Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-12 11:50 +0100
Re: PM regression with LED changes in next-20161109 Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2016-11-12 20:20 +0100
Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-12 22:20 +0100
Re: PM regression with LED changes in next-20161109 Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2016-11-13 12:50 +0100
Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-13 15:00 +0100
Re: PM regression with LED changes in next-20161109 Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-11-14 10:20 +0100
Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-14 14:00 +0100
Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-15 11:10 +0100
Re: PM regression with LED changes in next-20161109 Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-11-15 11:10 +0100
LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109 Pavel Machek <pavel@ucw.cz> - 2016-11-15 11:40 +0100
Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109 Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-11-15 12:00 +0100
Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-15 12:20 +0100
Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109 Pavel Machek <pavel@ucw.cz> - 2016-11-15 12:20 +0100
Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-15 12:30 +0100
Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109 Pavel Machek <pavel@ucw.cz> - 2016-11-15 12:50 +0100
Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-15 13:10 +0100
Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109 Pavel Machek <pavel@ucw.cz> - 2016-11-15 13:20 +0100
Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109 Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-11-15 14:30 +0100
Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-15 14:50 +0100
Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109 Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-11-15 15:10 +0100
Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-15 15:40 +0100
Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109 Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-11-15 15:50 +0100
Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-17 23:20 +0100
Re: PM regression with LED changes in next-20161109 Pavel Machek <pavel@ucw.cz> - 2016-11-14 09:40 +0100
Re: PM regression with LED changes in next-20161109 Pavel Machek <pavel@ucw.cz> - 2016-11-11 23:10 +0100
Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-10 09:40 +0100
Re: PM regression with LED changes in next-20161109 Tony Lindgren <tony@atomide.com> - 2016-11-10 16:20 +0100
csiph-web