* [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer
@ 2015-04-23 17:04 ` Dmitry Torokhov
0 siblings, 0 replies; 30+ messages in thread
From: Dmitry Torokhov @ 2015-04-23 17:04 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Apr 23, 2015 at 9:55 AM, Pali Roh?r <pali.rohar@gmail.com> wrote:
> On Thursday 02 April 2015 16:44:10 Pavel Machek wrote:
>> On Wed 2015-04-01 23:11:40, Samuel Thibault wrote:
>> > Pali Roh?r, le Wed 01 Apr 2015 22:00:07 +0200, a ?crit :
>> > > On Tuesday 17 February 2015 20:15:27 Samuel Thibault wrote:
>> > > > Here is an updated version to fix the initialization of the
>> > > > vt_led_work queues before registering LEDs, and refresh
>> > > > against 3.19.
>> > >
>> > > Hello! I would like to ask when will be this patch series merged
>> > > into mainline kernel? Are there still some problems with it?
>> >
>> > There are no known problems ATM.
>>
>> I thought it made it to -next, but apparently not.
>>
>> Dmitry, can you comment what needs to be done, or just merge it,
>> please?
>>
>> Pavel
>
> Dmitry, can you merge this patch?
Sorry, I keep intending to go back to it and keep getting distracted
with other items. Last time I tried it it did not appear to work for
some scenarios that I tried, but I did not document it to provide
reasonable feedback to Samuel.
One thing that I know we'd have to fix is that input device must be
"opened" before we can engage it, right now LED interface violates
this requirement. It works right now because keyboard handler attaches
to most input devices with LEDs early enough for it to be
unnoticeable, but it does not mean that it is correct. It might be as
easy as calling input_open() unconditionally if devices has LEDs.
Another issue is that I do not think we should be introducing virtual
VT leds. I believe LEDs should belong to real devices; multiplexing
several into one usually ends up with problems (like the whole
mousedev and various users having to "grab" touchpads to exclude their
data form mousedev to avoid duplicate movement/button presses).
Hopefully I will have more coherent response RSN.
Thanks and sorry.
--
Dmitry
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer
2015-04-23 17:04 ` Dmitry Torokhov
@ 2015-05-02 22:44 ` Pali Rohár
-1 siblings, 0 replies; 30+ messages in thread
From: Pali Rohár @ 2015-05-02 22:44 UTC (permalink / raw)
To: Samuel Thibault
Cc: Dmitry Torokhov, Pavel Machek, Andrew Morton, David Herrmann,
Jiri Slaby, Bryan Wu, Richard Purdie, lkml, Evan Broder,
Arnaud Patard, Peter Korsgaard, Sascha Hauer, Rob Clark,
Niels de Vos, linux-arm-kernel, blogic
[-- Attachment #1: Type: Text/Plain, Size: 2261 bytes --]
On Thursday 23 April 2015 19:04:49 Dmitry Torokhov wrote:
> On Thu, Apr 23, 2015 at 9:55 AM, Pali Rohár
> <pali.rohar@gmail.com> wrote:
> > On Thursday 02 April 2015 16:44:10 Pavel Machek wrote:
> >> On Wed 2015-04-01 23:11:40, Samuel Thibault wrote:
> >> > Pali Rohár, le Wed 01 Apr 2015 22:00:07 +0200, a écrit :
> >> > > On Tuesday 17 February 2015 20:15:27 Samuel Thibault
> >> > > wrote:
> >> > > > Here is an updated version to fix the initialization
> >> > > > of the vt_led_work queues before registering LEDs,
> >> > > > and refresh against 3.19.
> >> > >
> >> > > Hello! I would like to ask when will be this patch
> >> > > series merged into mainline kernel? Are there still
> >> > > some problems with it?
> >> >
> >> > There are no known problems ATM.
> >>
> >> I thought it made it to -next, but apparently not.
> >>
> >> Dmitry, can you comment what needs to be done, or just
> >> merge it, please?
> >>
> >> Pavel
> >
> > Dmitry, can you merge this patch?
>
> Sorry, I keep intending to go back to it and keep getting
> distracted with other items. Last time I tried it it did not
> appear to work for some scenarios that I tried, but I did not
> document it to provide reasonable feedback to Samuel.
>
> One thing that I know we'd have to fix is that input device
> must be "opened" before we can engage it, right now LED
> interface violates this requirement. It works right now
> because keyboard handler attaches to most input devices with
> LEDs early enough for it to be unnoticeable, but it does not
> mean that it is correct. It might be as easy as calling
> input_open() unconditionally if devices has LEDs.
>
> Another issue is that I do not think we should be introducing
> virtual VT leds. I believe LEDs should belong to real
> devices; multiplexing several into one usually ends up with
> problems (like the whole mousedev and various users having to
> "grab" touchpads to exclude their data form mousedev to avoid
> duplicate movement/button presses).
>
> Hopefully I will have more coherent response RSN.
>
> Thanks and sorry.
Samuel, can you look at those issues?
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer
@ 2015-05-02 22:44 ` Pali Rohár
0 siblings, 0 replies; 30+ messages in thread
From: Pali Rohár @ 2015-05-02 22:44 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 23 April 2015 19:04:49 Dmitry Torokhov wrote:
> On Thu, Apr 23, 2015 at 9:55 AM, Pali Roh?r
> <pali.rohar@gmail.com> wrote:
> > On Thursday 02 April 2015 16:44:10 Pavel Machek wrote:
> >> On Wed 2015-04-01 23:11:40, Samuel Thibault wrote:
> >> > Pali Roh?r, le Wed 01 Apr 2015 22:00:07 +0200, a ?crit :
> >> > > On Tuesday 17 February 2015 20:15:27 Samuel Thibault
> >> > > wrote:
> >> > > > Here is an updated version to fix the initialization
> >> > > > of the vt_led_work queues before registering LEDs,
> >> > > > and refresh against 3.19.
> >> > >
> >> > > Hello! I would like to ask when will be this patch
> >> > > series merged into mainline kernel? Are there still
> >> > > some problems with it?
> >> >
> >> > There are no known problems ATM.
> >>
> >> I thought it made it to -next, but apparently not.
> >>
> >> Dmitry, can you comment what needs to be done, or just
> >> merge it, please?
> >>
> >> Pavel
> >
> > Dmitry, can you merge this patch?
>
> Sorry, I keep intending to go back to it and keep getting
> distracted with other items. Last time I tried it it did not
> appear to work for some scenarios that I tried, but I did not
> document it to provide reasonable feedback to Samuel.
>
> One thing that I know we'd have to fix is that input device
> must be "opened" before we can engage it, right now LED
> interface violates this requirement. It works right now
> because keyboard handler attaches to most input devices with
> LEDs early enough for it to be unnoticeable, but it does not
> mean that it is correct. It might be as easy as calling
> input_open() unconditionally if devices has LEDs.
>
> Another issue is that I do not think we should be introducing
> virtual VT leds. I believe LEDs should belong to real
> devices; multiplexing several into one usually ends up with
> problems (like the whole mousedev and various users having to
> "grab" touchpads to exclude their data form mousedev to avoid
> duplicate movement/button presses).
>
> Hopefully I will have more coherent response RSN.
>
> Thanks and sorry.
Samuel, can you look at those issues?
--
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150503/50985102/attachment.sig>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer
2015-04-23 17:04 ` Dmitry Torokhov
@ 2015-06-05 15:28 ` Samuel Thibault
-1 siblings, 0 replies; 30+ messages in thread
From: Samuel Thibault @ 2015-06-05 15:28 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Pali Rohár, Pavel Machek, Andrew Morton, David Herrmann,
Jiri Slaby, Bryan Wu, Richard Purdie, lkml, Evan Broder,
Arnaud Patard, Peter Korsgaard, Sascha Hauer, Rob Clark,
Niels de Vos, linux-arm-kernel, blogic
Hello,
Dmitry Torokhov, le Thu 23 Apr 2015 10:04:49 -0700, a écrit :
> One thing that I know we'd have to fix is that input device must be
> "opened" before we can engage it, right now LED interface violates
> this requirement.
What do you mean precisely by "engage"? In the following, I guess
actually calling dev->event(EV_LED)
> It works right now because keyboard handler attaches
> to most input devices with LEDs early enough for it to be
> unnoticeable, but it does not mean that it is correct. It might be as
> easy as calling input_open() unconditionally if devices has LEDs.
This seems like only a workaround, perhaps it should rather be leds.c
which checks for dev->users before calling dev->event(EV_LED)?
> Another issue is that I do not think we should be introducing virtual
> VT leds. I believe LEDs should belong to real devices;
But then how to fix console-setup's bug? (it was actually the starter
for all this work)
See http://bugs.debian.org/514464
console-setup needs a way to tell which kbd modifier should toggle the
capslock LED on all the keyboards used by the VT. Thus the point of VT
leds, which people can use to decide the LED behavior of all keyboards,
including hotplugged ones etc.
Samuel
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer
@ 2015-06-05 15:28 ` Samuel Thibault
0 siblings, 0 replies; 30+ messages in thread
From: Samuel Thibault @ 2015-06-05 15:28 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
Dmitry Torokhov, le Thu 23 Apr 2015 10:04:49 -0700, a ?crit :
> One thing that I know we'd have to fix is that input device must be
> "opened" before we can engage it, right now LED interface violates
> this requirement.
What do you mean precisely by "engage"? In the following, I guess
actually calling dev->event(EV_LED)
> It works right now because keyboard handler attaches
> to most input devices with LEDs early enough for it to be
> unnoticeable, but it does not mean that it is correct. It might be as
> easy as calling input_open() unconditionally if devices has LEDs.
This seems like only a workaround, perhaps it should rather be leds.c
which checks for dev->users before calling dev->event(EV_LED)?
> Another issue is that I do not think we should be introducing virtual
> VT leds. I believe LEDs should belong to real devices;
But then how to fix console-setup's bug? (it was actually the starter
for all this work)
See http://bugs.debian.org/514464
console-setup needs a way to tell which kbd modifier should toggle the
capslock LED on all the keyboards used by the VT. Thus the point of VT
leds, which people can use to decide the LED behavior of all keyboards,
including hotplugged ones etc.
Samuel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer
2015-06-05 15:28 ` Samuel Thibault
@ 2015-06-25 15:30 ` Samuel Thibault
-1 siblings, 0 replies; 30+ messages in thread
From: Samuel Thibault @ 2015-06-25 15:30 UTC (permalink / raw)
To: Dmitry Torokhov, Pali Rohár, Pavel Machek, David Herrmann,
Jiri Slaby, Bryan Wu, Richard Purdie, lkml, Evan Broder,
Arnaud Patard, Peter Korsgaard, Sascha Hauer, Rob Clark,
Niels de Vos, linux-arm-kernel, blogic
Hello,
Just to give an update to people who where Cc-ed at some point in the
discussion: a version reworked by Dmitry got pulled into Linus' tree, so
it should get into 4.2!
Thanks to everybody involved,
Samuel
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer
@ 2015-06-25 15:30 ` Samuel Thibault
0 siblings, 0 replies; 30+ messages in thread
From: Samuel Thibault @ 2015-06-25 15:30 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
Just to give an update to people who where Cc-ed at some point in the
discussion: a version reworked by Dmitry got pulled into Linus' tree, so
it should get into 4.2!
Thanks to everybody involved,
Samuel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer
2015-06-25 15:30 ` Samuel Thibault
@ 2015-06-25 15:37 ` Peter Korsgaard
-1 siblings, 0 replies; 30+ messages in thread
From: Peter Korsgaard @ 2015-06-25 15:37 UTC (permalink / raw)
To: Samuel Thibault
Cc: Dmitry Torokhov, Pali Rohár, Pavel Machek, David Herrmann,
Jiri Slaby, Bryan Wu, Richard Purdie, lkml, Evan Broder,
Arnaud Patard, Peter Korsgaard, Sascha Hauer, Rob Clark,
Niels de Vos, linux-arm-kernel, blogic
>>>>> "Samuel" == Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> Hello,
> Just to give an update to people who where Cc-ed at some point in the
> discussion: a version reworked by Dmitry got pulled into Linus' tree, so
> it should get into 4.2!
> Thanks to everybody involved,
Wee, thanks!
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer
@ 2015-06-25 15:37 ` Peter Korsgaard
0 siblings, 0 replies; 30+ messages in thread
From: Peter Korsgaard @ 2015-06-25 15:37 UTC (permalink / raw)
To: linux-arm-kernel
>>>>> "Samuel" == Samuel Thibault <samuel.thibault@ens-lyon.org> writes:
> Hello,
> Just to give an update to people who where Cc-ed at some point in the
> discussion: a version reworked by Dmitry got pulled into Linus' tree, so
> it should get into 4.2!
> Thanks to everybody involved,
Wee, thanks!
--
Bye, Peter Korsgaard
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer
2015-06-25 15:30 ` Samuel Thibault
@ 2015-06-25 16:25 ` Samuel Thibault
-1 siblings, 0 replies; 30+ messages in thread
From: Samuel Thibault @ 2015-06-25 16:25 UTC (permalink / raw)
To: Dmitry Torokhov, Pali Rohár, Pavel Machek, David Herrmann,
Jiri Slaby, Bryan Wu, Richard Purdie, lkml, Evan Broder,
Arnaud Patard, Peter Korsgaard, Sascha Hauer, Rob Clark,
Niels de Vos, linux-arm-kernel, blogic
Samuel Thibault, le Thu 25 Jun 2015 17:30:32 +0200, a écrit :
> Just to give an update to people who where Cc-ed at some point in the
> discussion: a version reworked by Dmitry got pulled into Linus' tree, so
> it should get into 4.2!
(5 years after first submission, but better late than never :) )
Samuel
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer
@ 2015-06-25 16:25 ` Samuel Thibault
0 siblings, 0 replies; 30+ messages in thread
From: Samuel Thibault @ 2015-06-25 16:25 UTC (permalink / raw)
To: linux-arm-kernel
Samuel Thibault, le Thu 25 Jun 2015 17:30:32 +0200, a ?crit :
> Just to give an update to people who where Cc-ed at some point in the
> discussion: a version reworked by Dmitry got pulled into Linus' tree, so
> it should get into 4.2!
(5 years after first submission, but better late than never :) )
Samuel
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer
2015-06-25 16:25 ` Samuel Thibault
@ 2015-06-25 16:53 ` Dmitry Torokhov
-1 siblings, 0 replies; 30+ messages in thread
From: Dmitry Torokhov @ 2015-06-25 16:53 UTC (permalink / raw)
To: Samuel Thibault, Pali Rohár, Pavel Machek, David Herrmann,
Jiri Slaby, Bryan Wu, Richard Purdie, lkml, Evan Broder,
Arnaud Patard, Peter Korsgaard, Sascha Hauer, Rob Clark,
Niels de Vos, linux-arm-kernel, blogic
On Thu, Jun 25, 2015 at 06:25:56PM +0200, Samuel Thibault wrote:
> Samuel Thibault, le Thu 25 Jun 2015 17:30:32 +0200, a écrit :
> > Just to give an update to people who where Cc-ed at some point in the
> > discussion: a version reworked by Dmitry got pulled into Linus' tree, so
> > it should get into 4.2!
>
> (5 years after first submission, but better late than never :) )
Just like a good wine it had to mature a bit :)
Seriously though, I am sorry it took so long, I just had hard time
wrapping my head around of how to do it cleanly.
Thanks.
--
Dmitry
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer
@ 2015-06-25 16:53 ` Dmitry Torokhov
0 siblings, 0 replies; 30+ messages in thread
From: Dmitry Torokhov @ 2015-06-25 16:53 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jun 25, 2015 at 06:25:56PM +0200, Samuel Thibault wrote:
> Samuel Thibault, le Thu 25 Jun 2015 17:30:32 +0200, a ?crit :
> > Just to give an update to people who where Cc-ed at some point in the
> > discussion: a version reworked by Dmitry got pulled into Linus' tree, so
> > it should get into 4.2!
>
> (5 years after first submission, but better late than never :) )
Just like a good wine it had to mature a bit :)
Seriously though, I am sorry it took so long, I just had hard time
wrapping my head around of how to do it cleanly.
Thanks.
--
Dmitry
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer
2015-06-25 15:30 ` Samuel Thibault
@ 2015-06-26 8:09 ` Pali Rohár
-1 siblings, 0 replies; 30+ messages in thread
From: Pali Rohár @ 2015-06-26 8:09 UTC (permalink / raw)
To: Samuel Thibault, Dmitry Torokhov, Pavel Machek, David Herrmann,
Jiri Slaby, Bryan Wu, Richard Purdie, lkml, Evan Broder,
Arnaud Patard, Peter Korsgaard, Sascha Hauer, Rob Clark,
Niels de Vos, linux-arm-kernel, blogic
On Thursday 25 June 2015 17:30:32 Samuel Thibault wrote:
> Hello,
>
> Just to give an update to people who where Cc-ed at some point in the
> discussion: a version reworked by Dmitry got pulled into Linus' tree, so
> it should get into 4.2!
>
> Thanks to everybody involved,
> Samuel
Thanks! I'm very very happy to hear this!
--
Pali Rohár
pali.rohar@gmail.com
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer
@ 2015-06-26 8:09 ` Pali Rohár
0 siblings, 0 replies; 30+ messages in thread
From: Pali Rohár @ 2015-06-26 8:09 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 25 June 2015 17:30:32 Samuel Thibault wrote:
> Hello,
>
> Just to give an update to people who where Cc-ed at some point in the
> discussion: a version reworked by Dmitry got pulled into Linus' tree, so
> it should get into 4.2!
>
> Thanks to everybody involved,
> Samuel
Thanks! I'm very very happy to hear this!
--
Pali Roh?r
pali.rohar at gmail.com
^ permalink raw reply [flat|nested] 30+ messages in thread