Hi,
On 01/24/2017 11:56 PM, Jacek Anaszewski wrote:
> Hi,
>
> On 01/24/2017 01:32 PM, Pavel Machek wrote:
>> Hi!
>>
> There might exist users that adjust LED brightness while having
> active trigger. The best example is default-on trigger - it sets
> brightness only on init, but remain
Hi,
On 01/24/2017 01:32 PM, Pavel Machek wrote:
> Hi!
>
There might exist users that adjust LED brightness while having
active trigger. The best example is default-on trigger - it sets
brightness only on init, but remains active all the time. Whereas
this could be fixed, there
Hi!
> >> There might exist users that adjust LED brightness while having
> >> active trigger. The best example is default-on trigger - it sets
> >> brightness only on init, but remains active all the time. Whereas
> >> this could be fixed, there is another case: think of changing blinking
> >> bri
Hi,
On 15-01-17 13:25, Henrique de Moraes Holschuh wrote:
> On Sun, 15 Jan 2017, Hans de Goede wrote:
>> Do you want me to also send out a new version of the platform patches when
>> I send the next shot at the LED side of things, or shall I keep those
>> in my personal tree until the LED api is f
On Sun, 15 Jan 2017, Hans de Goede wrote:
> Do you want me to also send out a new version of the platform patches when
> I send the next shot at the LED side of things, or shall I keep those
> in my personal tree until the LED api is finalized ?
If you don't sent the entire patch set here, please
Hi,
On 13-01-17 20:17, Darren Hart wrote:
> On Fri, Dec 23, 2016 at 10:55:34PM +0100, Jacek Anaszewski wrote:
>> Hi,
>>
>> On 12/21/2016 07:49 PM, Pavel Machek wrote:
>>> Hi!
>>>
>>> In my eyes trigger approach is neccessary at least for some hardware,
>>> and things it pretty clear: trigg
On Fri, Dec 23, 2016 at 10:55:34PM +0100, Jacek Anaszewski wrote:
> Hi,
>
> On 12/21/2016 07:49 PM, Pavel Machek wrote:
> > Hi!
> >
> > In my eyes trigger approach is neccessary at least for some hardware,
> > and things it pretty clear: trigger on == LED changes without
> > userspace
Hi,
On 12/21/2016 07:49 PM, Pavel Machek wrote:
> Hi!
>
> In my eyes trigger approach is neccessary at least for some hardware,
> and things it pretty clear: trigger on == LED changes without
> userspace involvement. trigger off == userspace controls the LED.
It is likely th
Hi!
> >>>In my eyes trigger approach is neccessary at least for some hardware,
> >>>and things it pretty clear: trigger on == LED changes without
> >>>userspace involvement. trigger off == userspace controls the LED.
> >>
> >>It is likely that it would break many existing users.
> >
> >Can you ela
On 11/24/2016 04:36 PM, 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 idea to
On 11/25/2016 09:40 PM, Pavel Machek wrote:
> 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 s
On 11/24/2016 05:51 PM, Pali Rohár wrote:
> On Thursday 24 November 2016 17:21:19 Jacek Anaszewski wrote:
>> On 11/24/2016 04:36 PM, 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
On 11/24/2016 10:45 PM, Pali Rohár wrote:
> On Thursday 24 November 2016 22:35:52 Jacek Anaszewski wrote:
>>> I understood that we cannot notify about changes done by CPU
>>> trigger due to high power usage... Or not?
>>
>> Exactly.
>
> So in this case exporting any new sysfs file (or using existin
On 11/25/2016 12:05 PM, 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
On 11/21/2016 11:42 AM, Hans de Goede wrote:
> Hi,
>
> On 21-11-16 11:24, Jacek Anaszewski wrote:
>> Hi,
>>
>> On 11/20/2016 05:21 PM, Pavel Machek wrote:
>>> Hi!
>>>
> Thanks for the patch.
>
> I think we need less generic trigger name.
> With present name we preten
Hi,
On 11/25/2016 03:49 PM, Pavel Machek wrote:
> 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 limit
Hi,
On 11/20/2016 05:21 PM, Pavel Machek wrote:
> Hi!
>
>>> Thanks for the patch.
>>>
>>> I think we need less generic trigger name.
>>> With present name we pretend that all kbd-backlight controllers
>>> can change LED brightness autonomously.
>>>
>>> How about kbd-bac
Hi,
On 11/21/2016 12:56 PM, Hans de Goede wrote:
> Hi,
>
> On 21-11-16 12:24, Jacek Anaszewski wrote:
>> On 11/21/2016 11:42 AM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 21-11-16 11:24, Jacek Anaszewski wrote:
Hi,
On 11/20/2016 05:21 PM, Pavel Machek wrote:
> Hi!
>
>>
Hi Hans,
Thanks for the patch.
I think we need less generic trigger name.
With present name we pretend that all kbd-backlight controllers
can change LED brightness autonomously.
How about kbd-backlight-pollable ?
Best regards,
Jacek Anaszewski
On 11/17/2016 11:24 PM, Hans de Goede wrote:
> Add
Pali Rohár [2016-11-22 15:58:25 +0100]:
> On Monday 21 November 2016 14:29:00 Jacek Anaszewski wrote:
> > Let's wait until every involved part agrees (Pavel, Pali).
>
> Ok, I read that discussion on linux-leds ML and finally understand
> motivation and results.
>
> Personally I still do not like
On 11/24/2016 10:15 AM, 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 would su
Hi,
On 11/18/2016 07:47 PM, Hans de Goede wrote:
> HI,
>
> On 18-11-16 17:03, Jacek Anaszewski wrote:
>> Hi,
>>
>> On 11/18/2016 10:07 AM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 18-11-16 09:55, Jacek Anaszewski wrote:
Hi Hans,
Thanks for the patch.
I think we need less ge
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,
>>>
>>> On 18-11-16 17:03, Jacek Anaszewski wrote:
Hi,
On 11/18/2016 10:07 AM, Hans de Goede wrote:
> Hi,
>>
On 11/25/2016 11:01 AM, 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
Hi,
On 11/18/2016 10:07 AM, Hans de Goede wrote:
> Hi,
>
> On 18-11-16 09:55, Jacek Anaszewski wrote:
>> Hi Hans,
>>
>> Thanks for the patch.
>>
>> I think we need less generic trigger name.
>> With present name we pretend that all kbd-backlight controllers
>> can change LED brightness autonomousl
Hi,
On 11/25/2016 12:26 PM, Pali Rohár wrote:
> 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
Hi,
On 11/21/2016 12:41 PM, Pavel Machek wrote:
> 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 brightn
Hi Pali, Glenn,
Thanks for your feedback.
On 11/22/2016 03:58 PM, Pali Rohár wrote:
> On Monday 21 November 2016 14:29:00 Jacek Anaszewski wrote:
>> Let's wait until every involved part agrees (Pavel, Pali).
>
> Ok, I read that discussion on linux-leds ML and finally understand
> motivation and r
On 11/24/2016 03:26 PM, Pali Rohár wrote:
> On Thursday 24 November 2016 15:21:36 Jacek Anaszewski wrote:
>> On 11/24/2016 10:15 AM, 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
probl
Hi,
On 11/25/2016 12:14 PM, 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 readout of brigh
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
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
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
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,
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
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.
> >
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.
> That's why a s
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
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
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 Thursday 24 November 2016 22:35:52 Jacek Anaszewski wrote:
> > I understood that we cannot notify about changes done by CPU
> > trigger due to high power usage... Or not?
>
> Exactly.
So in this case exporting any new sysfs file (or using existing) which
report POLLPRI events for LED devices
On Thursday 24 November 2016 17:21:19 Jacek Anaszewski wrote:
> On 11/24/2016 04:36 PM, 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
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 idea to use brightness
> file for this.
How is brightn
On Thursday 24 November 2016 15:21:36 Jacek Anaszewski wrote:
> On 11/24/2016 10:15 AM, 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 f
Hi Pali,
On 24-11-16 10:15, 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 wou
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 would support POLLPRI events,
> and reading brightness.
On Monday 21 November 2016 14:29:00 Jacek Anaszewski wrote:
> Let's wait until every involved part agrees (Pavel, Pali).
Ok, I read that discussion on linux-leds ML and finally understand
motivation and results.
Personally I still do not like current approach and big problem what I
see is that I
Hi,
On 21-11-16 12:24, Jacek Anaszewski wrote:
> On 11/21/2016 11:42 AM, Hans de Goede wrote:
>> Hi,
>>
>> On 21-11-16 11:24, Jacek Anaszewski wrote:
>>> Hi,
>>>
>>> On 11/20/2016 05:21 PM, Pavel Machek wrote:
Hi!
>> Thanks for the patch.
>>
>> I think we need les
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 trigger. If we don
Hi,
On 21-11-16 11:24, Jacek Anaszewski wrote:
> Hi,
>
> On 11/20/2016 05:21 PM, Pavel Machek wrote:
>> Hi!
>>
Thanks for the patch.
I think we need less generic trigger name.
With present name we pretend that all kbd-backlight controllers
can change LE
Hi,
On 21-11-16 11:12, Pali Rohár wrote:
> On Monday 21 November 2016 10:31:33 Hans de Goede wrote:
>> Pali, I'm sorry that you don't like the LED side design, but there
>> has been a long discussion about this (which you apparently missed)
>> and this really is the best way forward.
>
> Yea, I th
On Monday 21 November 2016 10:31:33 Hans de Goede wrote:
> Pali, I'm sorry that you don't like the LED side design, but there
> has been a long discussion about this (which you apparently missed)
> and this really is the best way forward.
Yea, I thought that I should have missed something as I was
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,
On 18-11-16 17:03, Jacek Anaszewski wrote:
> Hi,
>
>>>
On Sunday 20 November 2016 19:48:02 Hans de Goede wrote:
> HI,
>
> On 20-11-16 17:21, Pavel Machek wrote:
> > Hi!
> >
> >>> Thanks for the patch.
> >>>
> >>> I think we need less generic trigger name.
> >>> With present name we pretend that all kbd-backlight
> >>> controllers
HI,
On 20-11-16 17:21, Pavel Machek wrote:
> Hi!
>
>>> Thanks for the patch.
>>>
>>> I think we need less generic trigger name.
>>> With present name we pretend that all kbd-backlight controllers
>>> can change LED brightness autonomously.
>>>
>>> How about kbd-backligh
Hi!
> > Thanks for the patch.
> >
> > I think we need less generic trigger name.
> > With present name we pretend that all kbd-backlight controllers
> > can change LED brightness autonomously.
> >
> > How about kbd-backlight-pollable ?
> > >>>
> > >>> This is
On Saturday 19 November 2016 16:44:09 Jacek Anaszewski wrote:
> Hi,
>
> On 11/18/2016 07:47 PM, Hans de Goede wrote:
> > HI,
> >
> > On 18-11-16 17:03, Jacek Anaszewski wrote:
> >> Hi,
> >>
> >> On 11/18/2016 10:07 AM, Hans de Goede wrote:
> >>> Hi,
> >>>
> >>> On 18-11-16 09:55, Jacek Anaszews
HI,
On 18-11-16 17:03, Jacek Anaszewski wrote:
> Hi,
>
> On 11/18/2016 10:07 AM, Hans de Goede wrote:
>> Hi,
>>
>> On 18-11-16 09:55, Jacek Anaszewski wrote:
>>> Hi Hans,
>>>
>>> Thanks for the patch.
>>>
>>> I think we need less generic trigger name.
>>> With present name we pretend that all kbd-
Hi,
On 18-11-16 09:55, Jacek Anaszewski wrote:
> Hi Hans,
>
> Thanks for the patch.
>
> I think we need less generic trigger name.
> With present name we pretend that all kbd-backlight controllers
> can change LED brightness autonomously.
>
> How about kbd-backlight-pollable ?
This is a trigger t
Add a trigger to control keyboard backlight LED devices. Note that in
some cases the keyboard backlight control is hardwired (taken care of
in firmware outside of the kernels control), in that case this triggers
main purpose is to allow userspace to monitor these changes.
The ledtrig_kbd_backlight
61 matches
Mail list logo
