On Thursday 23 February 2017 22:03:21 Pavel Machek wrote:
> So, if you seriously want to do this, can you
>
> 1) write specification explaining how desktops should poll() the
> brightness files
>
> 2) get someone to volunteer to implement that specification for at
> least GNOME and KDE?
Hm...
On Thursday 23 February 2017 22:03:21 Pavel Machek wrote:
> So, if you seriously want to do this, can you
>
> 1) write specification explaining how desktops should poll() the
> brightness files
>
> 2) get someone to volunteer to implement that specification for at
> least GNOME and KDE?
Hm...
On Friday 24 February 2017 09:52:11 Hans de Goede wrote:
> Hi,
>
> On 24-02-17 09:50, Pali Rohár wrote:
> >On Thursday 23 February 2017 22:03:21 Pavel Machek wrote:
> >>So, if you seriously want to do this, can you
> >>
> >>1) write specification explaining how desktops should poll() the
>
On Friday 24 February 2017 09:52:11 Hans de Goede wrote:
> Hi,
>
> On 24-02-17 09:50, Pali Rohár wrote:
> >On Thursday 23 February 2017 22:03:21 Pavel Machek wrote:
> >>So, if you seriously want to do this, can you
> >>
> >>1) write specification explaining how desktops should poll() the
>
Hi,
On 24-02-17 09:50, Pali Rohár wrote:
On Thursday 23 February 2017 22:03:21 Pavel Machek wrote:
So, if you seriously want to do this, can you
1) write specification explaining how desktops should poll() the
brightness files
2) get someone to volunteer to implement that specification for
Hi,
On 24-02-17 09:50, Pali Rohár wrote:
On Thursday 23 February 2017 22:03:21 Pavel Machek wrote:
So, if you seriously want to do this, can you
1) write specification explaining how desktops should poll() the
brightness files
2) get someone to volunteer to implement that specification for
Hi!
> > > > 2) there may be more then one
> > >
> > > Yes and script can be adjusted to use specific one (config option
> > > for script).
> >
> > No, you should autoconfigure it,
>
> Why? Because you prefer autoconfiguration and all other people must use
> it only? Does not seems a good
Hi!
> > > > 2) there may be more then one
> > >
> > > Yes and script can be adjusted to use specific one (config option
> > > for script).
> >
> > No, you should autoconfigure it,
>
> Why? Because you prefer autoconfiguration and all other people must use
> it only? Does not seems a good
On Thursday 23 February 2017 21:23:33 Pavel Machek wrote:
> Hi!
>
> > > Ok, and this is where the problems start. You are not supposed to
> > > control keyboard backlight like that. (In the same way you can't
> > > control display backlight like that.)
> > >
> > > There are numerous problems
On Thursday 23 February 2017 21:23:33 Pavel Machek wrote:
> Hi!
>
> > > Ok, and this is where the problems start. You are not supposed to
> > > control keyboard backlight like that. (In the same way you can't
> > > control display backlight like that.)
> > >
> > > There are numerous problems
Hi!
> > Ok, and this is where the problems start. You are not supposed to
> > control keyboard backlight like that. (In the same way you can't
> > control display backlight like that.)
> >
> > There are numerous problems with the shell script:
> >
> > 1) how to identify the keyboard backlight
Hi!
> > Ok, and this is where the problems start. You are not supposed to
> > control keyboard backlight like that. (In the same way you can't
> > control display backlight like that.)
> >
> > There are numerous problems with the shell script:
> >
> > 1) how to identify the keyboard backlight
On Thursday 23 February 2017 15:37:26 Pavel Machek wrote:
> Hi!
>
> > > So... you don't want to use systemd, so don't use systemd. What is
> > > the problem? :-)
> > >
> > > > And my own application for controlling leds should know current
> > > > state of them if it is possible.
> > >
> > > If
On Thursday 23 February 2017 15:37:26 Pavel Machek wrote:
> Hi!
>
> > > So... you don't want to use systemd, so don't use systemd. What is
> > > the problem? :-)
> > >
> > > > And my own application for controlling leds should know current
> > > > state of them if it is possible.
> > >
> > > If
Hi!
> > So... you don't want to use systemd, so don't use systemd. What is
> > the problem? :-)
> >
> > > And my own application for controlling leds should know current
> > > state of them if it is possible.
> >
> > If you have at most one application controlling each LED, you are
> > fine.
Hi!
> > So... you don't want to use systemd, so don't use systemd. What is
> > the problem? :-)
> >
> > > And my own application for controlling leds should know current
> > > state of them if it is possible.
> >
> > If you have at most one application controlling each LED, you are
> > fine.
On Wednesday 22 February 2017 21:54:08 Pavel Machek wrote:
> On Wed 2017-02-22 13:39:29, Pali Rohár wrote:
> > On Wednesday 22 February 2017 13:25:57 Pavel Machek wrote:
> > > Hi!
> > >
> > > > But this support is useful just for one single central
> > > > userspace application which will control
On Wednesday 22 February 2017 21:54:08 Pavel Machek wrote:
> On Wed 2017-02-22 13:39:29, Pali Rohár wrote:
> > On Wednesday 22 February 2017 13:25:57 Pavel Machek wrote:
> > > Hi!
> > >
> > > > But this support is useful just for one single central
> > > > userspace application which will control
On Wed 2017-02-22 13:39:29, Pali Rohár wrote:
> On Wednesday 22 February 2017 13:25:57 Pavel Machek wrote:
> > Hi!
> >
> > > But this support is useful just for one single central userspace
> > > application which will control all leds in system other application
> > > which will change state by
On Wed 2017-02-22 13:39:29, Pali Rohár wrote:
> On Wednesday 22 February 2017 13:25:57 Pavel Machek wrote:
> > Hi!
> >
> > > But this support is useful just for one single central userspace
> > > application which will control all leds in system other application
> > > which will change state by
On Wednesday 22 February 2017 13:25:57 Pavel Machek wrote:
> Hi!
>
> > But this support is useful just for one single central userspace
> > application which will control all leds in system other application
> > which will change state by /sys/class/leds/ will de-synchronize that one
> > central
On Wednesday 22 February 2017 13:25:57 Pavel Machek wrote:
> Hi!
>
> > But this support is useful just for one single central userspace
> > application which will control all leds in system other application
> > which will change state by /sys/class/leds/ will de-synchronize that one
> > central
Hi!
> But this support is useful just for one single central userspace
> application which will control all leds in system other application
> which will change state by /sys/class/leds/ will de-synchronize that one
> central application.
Yes. Does it matter for some real use case?
> So I think
Hi!
> But this support is useful just for one single central userspace
> application which will control all leds in system other application
> which will change state by /sys/class/leds/ will de-synchronize that one
> central application.
Yes. Does it matter for some real use case?
> So I think
Hello,
now in linus tree appeared new support for brightness_hw_changed sysfs
attribute which provides poll() for reporting brightness changes from
hardware itself.
But this support is useful just for one single central userspace
application which will control all leds in system other
Hello,
now in linus tree appeared new support for brightness_hw_changed sysfs
attribute which provides poll() for reporting brightness changes from
hardware itself.
But this support is useful just for one single central userspace
application which will control all leds in system other
26 matches
Mail list logo
