Hi,
On 01-03-17 12:15, Pali Rohár wrote:
On Wednesday 22 February 2017 13:20:46 Hans de Goede wrote:
1) These events do not happen 100s of times per second, they happen
almost never
100 events per second is probably not happening, but on my Latitude I
see that sometimes more events are delayed and delivered at once.
2) This is the best we can do given the firmware interface we have
What about just dropping upcoming one event in interval of next 2-3
second? Instead of trying to remember last state in kernel and then
trying to mach if received event was that which was caused by change?
That is way more racy then the solution with the kernel remembering
the brightness. With my proposed solution there is basically no race,
the only downside is the driver seeing a brightness change caused by
libsmbios as one caused by the hotkeys, but it will do so 100%
reliably and that is something which I believe we can live with
just fine.
This would allow us to reduce doing one SMM call for each received
event and I think it would be same reliable as your approach.
As I explained *already* we already have only one SMM call for reach
received event, we pass the read-back brightness into
led_classdev_notify_brightness_hw_changed and when userspace
reads the new brightness_hw_changed event in response to the wakeup
the led-core will use the value passed through
led_classdev_notify_brightness_hw_changed so only 1 SMM call happens
per event.
Also again this does not happen 100 times per second you're really
trying to optimize something which does not need any optimization
at all here.
Regards,
Hans
