Hi Samuel,
On Mon, Mar 31, 2014 at 02:23:23PM +0200, Samuel Thibault wrote:
> This permits to reassign keyboard LEDs to something else than keyboard "leds"
> state, by adding keyboard led and modifier triggers connected to a series
> of VT input LEDs, themselves connected to VT input triggers, which
> per-input device LEDs use by default. Userland can thus easily change the LED
> behavior of (a priori) all input devices, or of particular input devices.
>
I still have the same concern that I believe I already mentioned a while
ago: how do we reconcile the LED control via triggers with LED control
done through event devices? Currently, as far as I can see, they will be
clashing with each other. I.e. if I remap my capslock led to be the new
shiftlock and then userspace writes EV_LED/LED_CAPSL it would light up
my new "shift lock", right?
Also I wonder if we really need to have the multiplexing (VT-level) leds
in addition to per-device ones.
Thanks.
--
Dmitry
Dmitry Torokhov, le Sun 06 Apr 2014 19:10:15 -0700, a ?crit :
> On Mon, Mar 31, 2014 at 02:23:23PM +0200, Samuel Thibault wrote:
> > This permits to reassign keyboard LEDs to something else than keyboard "leds"
> > state, by adding keyboard led and modifier triggers connected to a series
> > of VT input LEDs, themselves connected to VT input triggers, which
> > per-input device LEDs use by default. Userland can thus easily change the LED
> > behavior of (a priori) all input devices, or of particular input devices.
> >
>
> I still have the same concern that I believe I already mentioned a while
> ago: how do we reconcile the LED control via triggers with LED control
> done through event devices?
I don't remember that raised during the discussion.
> Currently, as far as I can see, they will be
> clashing with each other. I.e. if I remap my capslock led to be the new
> shiftlock and then userspace writes EV_LED/LED_CAPSL it would light up
> my new "shift lock", right?
Well, yes, sure, if you shoot in your foot it will hurt :) (although
here the damage is really small, it is just LED lighting or not).
I don't see why people would both tinker with such triggers and run
userland programs writing to evdev. Of course it typically happens with
X, but that's not a problem in the usual case: kbd triggers are not
doing anything while on X, so X can play with evdev with no problem.
If the user puts e.g. a heartbeat on some LED and then runs X, the X
events will mix with the heartbeat. The solution is for the user to
just disable the corresponding LED in the X keyboard configuration.
Do we really want to impose some overriding between VT-generated and
other application-generated events? AIUI, we don't do this between
applications which would open the same evdev, so I don't see why we
should care more about the VT.
> Also I wonder if we really need to have the multiplexing (VT-level) leds
> in addition to per-device ones.
We do: we want to be able to easily remap all (current and future)
keyboards' LEDs easily.
My goal, at the beginning, was to be able to fix the console-setup
bug. That was that console-setup wants to use, for the capslock key,
something else than the capslock mechanism hard-wired in the kernel,
so as to get way more fine-grain control over how caps is handled.
But then the capslock LED would not lit any more. By remapping the
VT-level capslock led to the foo-lock used by console-setup, one gets
back capslock LEDs of all keyboards working back as expected by the
user. I also use it for getting a group LED, just like I have on X,
to know which keyboard layout group I am in. People using non-latin
layouts really need that.
Samuel
On Mon, Apr 07, 2014 at 09:54:23AM +0200, Samuel Thibault wrote:
> Dmitry Torokhov, le Sun 06 Apr 2014 19:10:15 -0700, a ?crit :
> > On Mon, Mar 31, 2014 at 02:23:23PM +0200, Samuel Thibault wrote:
> > > This permits to reassign keyboard LEDs to something else than keyboard "leds"
> > > state, by adding keyboard led and modifier triggers connected to a series
> > > of VT input LEDs, themselves connected to VT input triggers, which
> > > per-input device LEDs use by default. Userland can thus easily change the LED
> > > behavior of (a priori) all input devices, or of particular input devices.
> > >
> >
> > I still have the same concern that I believe I already mentioned a while
> > ago: how do we reconcile the LED control via triggers with LED control
> > done through event devices?
>
> I don't remember that raised during the discussion.
Hmm, I might be mistaken, I thought I did mention that.
>
> > Currently, as far as I can see, they will be
> > clashing with each other. I.e. if I remap my capslock led to be the new
> > shiftlock and then userspace writes EV_LED/LED_CAPSL it would light up
> > my new "shift lock", right?
>
> Well, yes, sure, if you shoot in your foot it will hurt :) (although
> here the damage is really small, it is just LED lighting or not).
This is not about amount of damage but the overall correctness of the
implementation. I'd rather not have a solution with known holes, if
possible.
>
> I don't see why people would both tinker with such triggers and run
> userland programs writing to evdev. Of course it typically happens with
> X, but that's not a problem in the usual case: kbd triggers are not
> doing anything while on X, so X can play with evdev with no problem.
> If the user puts e.g. a heartbeat on some LED and then runs X, the X
> events will mix with the heartbeat. The solution is for the user to
> just disable the corresponding LED in the X keyboard configuration.
> Do we really want to impose some overriding between VT-generated and
> other application-generated events? AIUI, we don't do this between
> applications which would open the same evdev, so I don't see why we
> should care more about the VT.
It is not about the VT, I am talking about pure input core. If I
repurpose CapsLock LED for my WiFi indicator I do not want to go into
other programs and teach them that they should stay away from trying to
control this LED. IOW if we switch to LED-subsystem-backed LEDs then we
should go all the way and implement this cleanly.
>
> > Also I wonder if we really need to have the multiplexing (VT-level) leds
> > in addition to per-device ones.
>
> We do: we want to be able to easily remap all (current and future)
> keyboards' LEDs easily.
>
> My goal, at the beginning, was to be able to fix the console-setup
> bug. That was that console-setup wants to use, for the capslock key,
> something else than the capslock mechanism hard-wired in the kernel,
> so as to get way more fine-grain control over how caps is handled.
> But then the capslock LED would not lit any more. By remapping the
> VT-level capslock led to the foo-lock used by console-setup, one gets
> back capslock LEDs of all keyboards working back as expected by the
> user. I also use it for getting a group LED, just like I have on X,
> to know which keyboard layout group I am in. People using non-latin
> layouts really need that.
I understand the desire, however I still wonder if we should be
extending legacy VT given that David wants to move it all to userspace.
Thanks.
--
Dmitry
Hello,
Dmitry Torokhov, le Tue 08 Apr 2014 01:39:40 -0700, a ?crit :
> It is not about the VT, I am talking about pure input core. If I
> repurpose CapsLock LED for my WiFi indicator I do not want to go into
> other programs and teach them that they should stay away from trying to
> control this LED.
Err, but even without talking about repurposing Capslock LED for WiFi...
How is managed the conflict between the normal capslock behavior and
other programs' action on the underlying input device? I don't think
this patch does not introduce the problem.
Now you may answer "well, if it could fix the problem along the way it'd
be good". I'd like to answer "well, this is not my shit" :)
But still, the problem is interesting, and I don't know how to deal
properly with it. More precisely, I don't think we *want* to deal with
it. Currently, what happens is that there is no priority between what
the VT keyboard events produce and what applications produce, so things
happily mix with strange results as soon as a user tries to combine
both. My concern is:
How to decide which one to prioritize?
Is it just because console-setup happens to repurpose the capslock LED
key that applications should suddenly not have capslock LED control
at all? That's contradictory with the use case you have given. That
leads me into believing that we should not try to push a hard rule, and
just let the user manage what accesses it. We could indeed make the VT
always take priority, but then that would probably break some existing
applications. Then, is "repurposing a keyboard LED" enough of an action
to be able to decide that applications modifying that LED should be just
ignored? I doubt it.
> I understand the desire, however I still wonder if we should be
> extending legacy VT given that David wants to move it all to userspace.
I believe I have heard about moving the console implementation to
userland for more that a decide. Will that really happen any time?
In the meanwhile, we have broken capslock keys on e.g. all Debian and
Ubuntu systems for a couple of years already (because they have adopted
console-setup), and some ARM systems don't have keyboard LEDs at all
without a patched kernel.
Samuel
Hello,
I'm sorry this went out with a few mistakes.
Samuel Thibault, le Wed 09 Apr 2014 01:33:06 +0200, a ?crit :
> Dmitry Torokhov, le Tue 08 Apr 2014 01:39:40 -0700, a ?crit :
> > It is not about the VT, I am talking about pure input core. If I
> > repurpose CapsLock LED for my WiFi indicator I do not want to go into
> > other programs and teach them that they should stay away from trying to
> > control this LED.
>
> Err, but even without talking about repurposing Capslock LED for WiFi...
> How is managed the conflict between the normal capslock behavior and
> other programs' action on the underlying input device? I don't think
> this patch does not introduce the problem.
I of course meant "I don't think this patch introduces the problem".
> How to decide which one to prioritize?
>
> Is it just because console-setup happens to repurpose the capslock LED
> key that applications should suddenly not have capslock LED control
> at all? That's contradictory with the use case you have given.
Oops, not the use case you have given, but a typical use-case of wanting
to use a program which does nice things with the capslock LED, and then
having to teach console-setup not to repurpose the capslock LED.
> That
> leads me into believing that we should not try to push a hard rule, and
> just let the user manage what accesses it. We could indeed make the VT
> always take priority, but then that would probably break some existing
> applications.
Such as the example above, with the capslock LED.
Samuel
Hi!
> > > > This permits to reassign keyboard LEDs to something else than keyboard "leds"
> > > > state, by adding keyboard led and modifier triggers connected to a series
> > > > of VT input LEDs, themselves connected to VT input triggers, which
> > > > per-input device LEDs use by default. Userland can thus easily change the LED
> > > > behavior of (a priori) all input devices, or of particular input devices.
> > > >
> > >
> > > I still have the same concern that I believe I already mentioned a while
> > > ago: how do we reconcile the LED control via triggers with LED control
> > > done through event devices?
I think we should deprecate LED controls using event devices. We have
nice API for LEDs, and it is not in input.
> > > Currently, as far as I can see, they will be
> > > clashing with each other. I.e. if I remap my capslock led to be the new
> > > shiftlock and then userspace writes EV_LED/LED_CAPSL it would light up
> > > my new "shift lock", right?
> >
> > Well, yes, sure, if you shoot in your foot it will hurt :) (although
> > here the damage is really small, it is just LED lighting or not).
>
> This is not about amount of damage but the overall correctness of the
> implementation. I'd rather not have a solution with known holes, if
> possible.
I'd say that applications using direct EV_LED interface should just
stop doing it. Yes, you can probably use led API and still toggle the
led using gpio api behind leds back (not tested, perhaps there are
interlocks that prevent that)... and it is same situation with
EV_LED. We should just teach applications not to do that.
Would solution where EV_LED would be ignored when there's non-default
trigger selected work for you?
> > My goal, at the beginning, was to be able to fix the console-setup
> > bug. That was that console-setup wants to use, for the capslock key,
> > something else than the capslock mechanism hard-wired in the kernel,
> > so as to get way more fine-grain control over how caps is handled.
> > But then the capslock LED would not lit any more. By remapping the
> > VT-level capslock led to the foo-lock used by console-setup, one gets
> > back capslock LEDs of all keyboards working back as expected by the
> > user. I also use it for getting a group LED, just like I have on X,
> > to know which keyboard layout group I am in. People using non-latin
> > layouts really need that.
>
> I understand the desire, however I still wonder if we should be
> extending legacy VT given that David wants to move it all to
> userspace.
It looks like legacy VT is going to stay here for long long time...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Fri, Apr 11, 2014 at 08:12:02AM +0200, Samuel Thibault wrote:
> Hello,
>
> I'm sorry this went out with a few mistakes.
>
> Samuel Thibault, le Wed 09 Apr 2014 01:33:06 +0200, a ?crit :
> > Dmitry Torokhov, le Tue 08 Apr 2014 01:39:40 -0700, a ?crit :
> > > It is not about the VT, I am talking about pure input core. If I
> > > repurpose CapsLock LED for my WiFi indicator I do not want to go into
> > > other programs and teach them that they should stay away from trying to
> > > control this LED.
> >
> > Err, but even without talking about repurposing Capslock LED for WiFi...
> > How is managed the conflict between the normal capslock behavior and
> > other programs' action on the underlying input device? I don't think
> > this patch does not introduce the problem.
>
> I of course meant "I don't think this patch introduces the problem".
The difference in my eyes is that with old interface both players knew
that they would be affecting (and potentially interfering) with the
state of CapsLock LED. With your proposed changes users of old
interfaces have no idea if they are actually toggling CapsLock LED or if
they are affecting something that is no longer a CapsLock LED.
>
> > How to decide which one to prioritize?
> >
> > Is it just because console-setup happens to repurpose the capslock LED
> > key that applications should suddenly not have capslock LED control
> > at all? That's contradictory with the use case you have given.
>
> Oops, not the use case you have given, but a typical use-case of wanting
> to use a program which does nice things with the capslock LED, and then
> having to teach console-setup not to repurpose the capslock LED.
I believe that applications should be able to control sate of CapsLock
and other LEDs and that the affected LED should not be the physical LED
but rather LED that is currently tied to CapsLock trigger (if any). This
way everything works as is by default and if I decide to have my
physical CapsLock LED to be repurposed for Wifi or HDD activity or
whatever I do not need to teach unrelated applications to stop touching
it.
>
> > That
> > leads me into believing that we should not try to push a hard rule, and
> > just let the user manage what accesses it. We could indeed make the VT
> > always take priority, but then that would probably break some existing
> > applications.
>
> Such as the example above, with the capslock LED.
I am not saying that VT shoudl have priority, I am saying we need to
come up with implementation that does not result in inconsistent
behavior.
Thanks.
--
Dmitry
On Sat, Apr 12, 2014 at 12:09:34PM +0200, Pavel Machek wrote:
> Hi!
>
> > > > > This permits to reassign keyboard LEDs to something else than keyboard "leds"
> > > > > state, by adding keyboard led and modifier triggers connected to a series
> > > > > of VT input LEDs, themselves connected to VT input triggers, which
> > > > > per-input device LEDs use by default. Userland can thus easily change the LED
> > > > > behavior of (a priori) all input devices, or of particular input devices.
> > > > >
> > > >
> > > > I still have the same concern that I believe I already mentioned a while
> > > > ago: how do we reconcile the LED control via triggers with LED control
> > > > done through event devices?
>
> I think we should deprecate LED controls using event devices. We have
> nice API for LEDs, and it is not in input.
>
>
>
>
> > > > Currently, as far as I can see, they will be
> > > > clashing with each other. I.e. if I remap my capslock led to be the new
> > > > shiftlock and then userspace writes EV_LED/LED_CAPSL it would light up
> > > > my new "shift lock", right?
> > >
> > > Well, yes, sure, if you shoot in your foot it will hurt :) (although
> > > here the damage is really small, it is just LED lighting or not).
> >
> > This is not about amount of damage but the overall correctness of the
> > implementation. I'd rather not have a solution with known holes, if
> > possible.
>
> I'd say that applications using direct EV_LED interface should just
> stop doing it. Yes, you can probably use led API and still toggle the
> led using gpio api behind leds back (not tested, perhaps there are
> interlocks that prevent that)... and it is same situation with
> EV_LED. We should just teach applications not to do that.
>
> Would solution where EV_LED would be ignored when there's non-default
> trigger selected work for you?
Not ignored but rather routed to the LED that is currently selected for
given function. This way if I re-purposed CapsLock LED for Wifi and do
not provide a replacement EV_LED will be effectively dropped, but if I
switch CapsLock with NumLock I want the event to affect the appropriate
LED.
Thanks.
--
Dmitry
Hello,
Dmitry Torokhov, le Sat 12 Apr 2014 18:25:57 -0700, a ?crit :
> On Fri, Apr 11, 2014 at 08:12:02AM +0200, Samuel Thibault wrote:
> > I'm sorry this went out with a few mistakes.
> >
> > Samuel Thibault, le Wed 09 Apr 2014 01:33:06 +0200, a ?crit :
> > > Dmitry Torokhov, le Tue 08 Apr 2014 01:39:40 -0700, a ?crit :
> > > > It is not about the VT, I am talking about pure input core. If I
> > > > repurpose CapsLock LED for my WiFi indicator I do not want to go into
> > > > other programs and teach them that they should stay away from trying to
> > > > control this LED.
> > >
> > > Err, but even without talking about repurposing Capslock LED for WiFi...
> > > How is managed the conflict between the normal capslock behavior and
> > > other programs' action on the underlying input device? I don't think
> > > this patch does not introduce the problem.
> >
> > I of course meant "I don't think this patch introduces the problem".
>
> The difference in my eyes is that with old interface both players knew
> that they would be affecting (and potentially interfering) with the
> state of CapsLock LED. With your proposed changes users of old
> interfaces have no idea if they are actually toggling CapsLock LED or if
> they are affecting something that is no longer a CapsLock LED.
Mmm, I thought you were talking about evdev programs (which would always
get to manipulate the hardware capslock leds anyway)?
Are you here talking about KDSETLEDS? This is a very odd ioctl
actually. Its name suggests that its purpose is to just light LEDs,
but AFAIK it is essentially used by users to change the status of the
keyboard state, and the LED change is just a side effect for them. So
if e.g. the numlock LED is repurposed to wifi, should KDSETLEDS really
just switch on the LED (thus defeating the wifi purpose), while the user
probably used setleds +num only to get its numlock enabled by default
(and doesn't care about seeing that on the keyboard, on the contrary, he
preferred to see the wifi state).
> > > How to decide which one to prioritize?
> > >
> > > Is it just because console-setup happens to repurpose the capslock LED
> > > key that applications should suddenly not have capslock LED control
> > > at all? That's contradictory with the use case you have given.
> >
> > Oops, not the use case you have given, but a typical use-case of wanting
> > to use a program which does nice things with the capslock LED, and then
> > having to teach console-setup not to repurpose the capslock LED.
>
> I believe that applications should be able to control sate of CapsLock
> and other LEDs and that the affected LED should not be the physical LED
> but rather LED that is currently tied to CapsLock trigger (if any).
Which kind of applications are you talking about? What I have heard
from users was that they either wanted to have an effect on the physical
LED, or on the keyboard state, but not really "on the LED which shows
the keyboard state", which would just be a side consequence of what they
really want to achieve.
> This
> way everything works as is by default and if I decide to have my
> physical CapsLock LED to be repurposed for Wifi or HDD activity or
> whatever I do not need to teach unrelated applications to stop touching
> it.
Again, which applications are you thinking about precisely? If a
user has an application which wants to really show something on the
capslock LED, then the user's intent was really the physical LED, and he
hurted himself in the foot. Otherwise, what was the intention of the
application? I don't understand why an application would want to light
"the LED which shows the capslock state", and not simply the keyboard
capslock status (which thus may or may not be reflected on some physical
LED, depending whether some LED is plugged on the keyboard capslock
status).
> > > That
> > > leads me into believing that we should not try to push a hard rule, and
> > > just let the user manage what accesses it. We could indeed make the VT
> > > always take priority, but then that would probably break some existing
> > > applications.
> >
> > Such as the example above, with the capslock LED.
>
> I am not saying that VT shoudl have priority, I am saying we need to
> come up with implementation that does not result in inconsistent
> behavior.
Ok, but for now I don't see in which exact case we'd have an
inconsistency.
Dmitry Torokhov, le Sat 12 Apr 2014 18:30:49 -0700, a ?crit :
> > I'd say that applications using direct EV_LED interface should just
> > stop doing it. Yes, you can probably use led API and still toggle the
> > led using gpio api behind leds back (not tested, perhaps there are
> > interlocks that prevent that)... and it is same situation with
> > EV_LED. We should just teach applications not to do that.
> >
> > Would solution where EV_LED would be ignored when there's non-default
> > trigger selected work for you?
>
> Not ignored but rather routed to the LED that is currently selected for
> given function. This way if I re-purposed CapsLock LED for Wifi and do
> not provide a replacement EV_LED will be effectively dropped, but if I
> switch CapsLock with NumLock I want the event to affect the appropriate
> LED.
Err, but are we really talking about the same layer? I thought
EV_LED was meant to drive hardware, not to drive any kind of software
abstraction on top of it. Adding an indirection to what EV_LED actually
means at least surely needs quite some heavy patching in the input
layer, I'm not even sure I really want to dive into that.
Adding an indirection there also looks to me like confusing the picture
even more. The way I see it is (using a monospace font):
kbd state -> kbd led -> kbd trigger -> vt led -> vt trigger -> input led
^^ ^^ ^^ ^^
KDSETLED XX YY EV_LED
XX is vt::capsl/trigger, and YY is input*::capsl/trigger. Applications
can either modify the keyboard state through KDSETLED, which may or may
not be shown by some LEDs depending on XX and YY, or modify the hardware
leds through EV_LED, which thus doesn't care about XX and YY.
The only "case" I see "broken" is applications which would be using
KDSETLED to just flash some keyboard LEDs (and happen to also tamper
with keyboard state...). With a default configuration they will still
work. If the LEDs are repurposed, the application effect won't show up
(unless the scroll/caps/num still appear in the LED reassignation, and
then the application effect will show up, with the repurpose exchanges).
In the end, I really don't see which use case you are thinking about
precisely.
Samuel