Here is an updated version to fix the initialization of the vt_led_work
queues before registering LEDs, and refresh against 3.19.
Samuel
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
[email protected]
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
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
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
[email protected]
FTR, the two patches apply and work fine with linux 4.0.
Samuel
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
[email protected]
On Thu, Apr 23, 2015 at 9:55 AM, Pali Rohár <[email protected]> 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
On Thursday 23 April 2015 19:04:49 Dmitry Torokhov wrote:
> On Thu, Apr 23, 2015 at 9:55 AM, Pali Rohár
> <[email protected]> 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
[email protected]
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
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
>>>>> "Samuel" == Samuel Thibault <[email protected]> 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
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
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
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
[email protected]