[PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Samuel Thibault]

Here is an updated version to fix the initialization of the vt_led_work
queues before registering LEDs, and refresh against 3.19.

Samuel

[PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Samuel Thibault]

Here is an updated version to fix the initialization of the vt_led_work
queues before registering LEDs, and refresh against 3.19.

Samuel

Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 387 bytes --]

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.
> 
> Samuel

Hello! I would like to ask when will be this patch series merged 
into mainline kernel? Are there still some problems with it?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Pali Rohár]

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.
> 
> Samuel

Hello! I would like to ask when will be this patch series merged 
into mainline kernel? Are there still some problems with it?

-- 
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/20150401/fb417235/attachment.sig>

Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Samuel Thibault]

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.

Samuel

[PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Samuel Thibault]

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.

Samuel

Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Pavel Machek]

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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Pavel Machek]

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
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 895 bytes --]

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, ping. If everything is OK, can you merge this patch? If 
not can you comment it?

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Pali Rohár]

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, ping. If everything is OK, can you merge this patch? If 
not can you comment it?

-- 
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/20150413/c6493527/attachment.sig>

Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Samuel Thibault]

FTR, the two patches apply and work fine with linux 4.0.

Samuel

[PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Samuel Thibault]

FTR, the two patches apply and work fine with linux 4.0.

Samuel

Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Pali Rohár]

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?

-- 
Pali Rohár
pali.rohar@gmail.com

[PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Pali Rohár]

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?

-- 
Pali Roh?r
pali.rohar at gmail.com

Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Dmitry Torokhov]

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

[PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Dmitry Torokhov]

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

Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Pali Rohár]

[-- 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 --]

[PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Pali Rohár]

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>

Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Samuel Thibault]

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

[PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Samuel Thibault]

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

Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Samuel Thibault]

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

[PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Samuel Thibault]

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

Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Peter Korsgaard]

>>>>> "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

[PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Peter Korsgaard]

>>>>> "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

Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Samuel Thibault]

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

[PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Samuel Thibault]

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

Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Dmitry Torokhov]

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

[PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Dmitry Torokhov]

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

Re: [PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Pali Rohár]

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

[PATCHv7 0/2] INPUT: Route keyboard LEDs through the generic LEDs layer

[Pali Rohár]

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