Hi!
> As pointed in other email, we do not know if HW really controls keyboard
> backlight,
> so adding "fake" trigger on machines without HW control is not a good
> idea.
> >>>
> >>>Well, if we know that hardware will not change the brightness on its
> >>>own, yes, I'd avoid the
On Thu 2016-11-24 10:15:25, Pali Rohár wrote:
> On Wednesday 23 November 2016 12:01:02 Jacek Anaszewski wrote:
> > I would also appreciate your opinion on the other solution to the
> > problem of notifying brightness changes originating from hardware,
> > i.e. hw_brightness_change{_ro} file, that w
On Thu 2016-11-24 16:36:51, Pali Rohár wrote:
> On Thursday 24 November 2016 16:32:06 Jacek Anaszewski wrote:
> > Since it has been reported that POLLPRI notifications on brightness
> > file can lead to increased power consumption, and having my above
> > statement I don't think that it is a good i
Hi!
> In view of the above we could report hw brightness changes with POLLPRI
> on brightness file, but unfortunately we can't because it is impossible
> to guarantee that readout of brightness file will return the brightness
> the POLLPRI was meant to notify about.
Agreed here.
> That's why a s
On Mon 2016-11-21 10:31:33, Hans de Goede wrote:
> Hi,
>
> On 21-11-16 09:35, Jacek Anaszewski wrote:
> >On 11/20/2016 04:05 PM, Pali Rohár wrote:
> >>On Saturday 19 November 2016 16:44:09 Jacek Anaszewski wrote:
> >>>Hi,
> >>>
> >>>On 11/18/2016 07:47 PM, Hans de Goede wrote:
> HI,
>
> >
Hi!
> >>In view of the above we could report hw brightness changes with POLLPRI
> >>on brightness file, but unfortunately we can't because it is impossible
> >>to guarantee that readout of brightness file will return the brightness
> >>the POLLPRI was meant to notify about.
> >
> >Agreed here.
> >
Hi,
On 25-11-16 11:01, Pavel Machek wrote:
> Hi!
>
>> In view of the above we could report hw brightness changes with POLLPRI
>> on brightness file, but unfortunately we can't because it is impossible
>> to guarantee that readout of brightness file will return the brightness
>> the POLLPRI was mea
On Friday 25 November 2016 12:14:56 Hans de Goede wrote:
> Hi,
>
> On 25-11-16 11:01, Pavel Machek wrote:
> > Hi!
> >
> >> In view of the above we could report hw brightness changes with
> >> POLLPRI on brightness file, but unfortunately we can't because it
> >> is impossible to guarantee that re
Hi!
> > As for the modeling how the hotkey controls the LED as a trigger,
> > although I do like this from one pov, I can see Jacek's point that
> > this is confusing as there really is nothing to configure here,
> > where as normally a user could do "echo none > trigger" to break
> > the link. So
Fix an [-Wold-style-declaration] GCC warning by moving the inline
keyword before the return type.
Signed-off-by: Tobias Klauser
---
drivers/platform/x86/thinkpad_acpi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x8
Hi!
> >Lets keep it simple. Yes, monitoring backlight state while hardware
> >updates it is useful. But doing the monitor when some kind of blinking
> >from the kernel is active is just a unneccessary complexity...
>
> Triggers are not limited to periodic blinking or reporting cpu
> activity. The
On Fri, 25 Nov 2016, Tobias Klauser wrote:
> Fix an [-Wold-style-declaration] GCC warning by moving the inline
> keyword before the return type.
>
> Signed-off-by: Tobias Klauser
Acked-by: Henrique de Moraes Holschuh
> ---
> drivers/platform/x86/thinkpad_acpi.c | 2 +-
> 1 file changed, 1 ins
Hi!
> >>Triggers are not limited to periodic blinking or reporting cpu
> >>activity. There is also oneshot trigger that can be used e.g. when
> >>user touches the screen, as Pali mentioned.
> >
> >Using oneshot trigger for this would be pretty strange.
>
> It was only an example to mention other
13 matches
Mail list logo
