Message ID | 4A637212.2000002@rtr.ca (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
On Sun, Jul 19, 2009 at 03:20:50PM -0400, Mark Lord wrote: > Mark Lord wrote: >> (resending.. somebody trimmed linux-kernel from the CC: earlier) >> >> Jean Delvare wrote: >>> On Sun, 19 Jul 2009 10:38:37 -0400, Mark Lord wrote: >>>> I'm debugging various other b0rked things in 2.6.31 here right now, >>>> so I had a closer look at the Hauppauge I/R remote issue. >>>> >>>> The ir_kbd_i2c driver *does* still find it after all. >>>> But the difference is that the output from 'lsinput' has changed >>>> and no longer says "Hauppauge". Which prevents the application from >>>> finding the remote control in the same way as before. >>> >>> OK, thanks for the investigation. >>> >>>> I'll hack the application code here now to use the new output, >>>> but I wonder what the the thousands of other users will do when >>>> they first try 2.6.31 after release ? > .. > > Mmm.. appears to be a systemwide thing, not just for the i2c stuff. > *All* of the input devices now no longer show their real names > when queried with ioctl(EVIOCGNAME). This is a regression from 2.6.30. > Note that the real names *are* still stored somewhere, because they > do still show up correctly under /sys/ > Should be fixed by f936601471d1454dacbd3b2a961fd4d883090aeb in the for-linus branch of my tree.
On Sun, 19 Jul 2009 15:20:50 -0400, Mark Lord wrote: > Mark Lord wrote: > > (resending.. somebody trimmed linux-kernel from the CC: earlier) FWIW I don't think it was there in the first place. > > Jean Delvare wrote: > >> On Sun, 19 Jul 2009 10:38:37 -0400, Mark Lord wrote: > >>> I'm debugging various other b0rked things in 2.6.31 here right now, > >>> so I had a closer look at the Hauppauge I/R remote issue. > >>> > >>> The ir_kbd_i2c driver *does* still find it after all. > >>> But the difference is that the output from 'lsinput' has changed > >>> and no longer says "Hauppauge". Which prevents the application from > >>> finding the remote control in the same way as before. > >> > >> OK, thanks for the investigation. > >> > >>> I'll hack the application code here now to use the new output, > >>> but I wonder what the the thousands of other users will do when > >>> they first try 2.6.31 after release ? > .. > > Mmm.. appears to be a systemwide thing, not just for the i2c stuff. > *All* of the input devices now no longer show their real names > when queried with ioctl(EVIOCGNAME). This is a regression from 2.6.30. > Note that the real names *are* still stored somewhere, because they > do still show up correctly under /sys/ I was just coming to the same conclusion. So this doesn't have anything to do with the ir-kbd-i2c conversion after all... This is something for the input subsystem maintainers. I suspect this commit is related to the regression: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=3d5cb60ef3042ac479dab82e5a945966a0d54d53
Dmitry Torokhov wrote: > On Sun, Jul 19, 2009 at 03:20:50PM -0400, Mark Lord wrote: >> Mark Lord wrote: >>> (resending.. somebody trimmed linux-kernel from the CC: earlier) >>> >>> Jean Delvare wrote: >>>> On Sun, 19 Jul 2009 10:38:37 -0400, Mark Lord wrote: >>>>> I'm debugging various other b0rked things in 2.6.31 here right now, >>>>> so I had a closer look at the Hauppauge I/R remote issue. >>>>> >>>>> The ir_kbd_i2c driver *does* still find it after all. >>>>> But the difference is that the output from 'lsinput' has changed >>>>> and no longer says "Hauppauge". Which prevents the application from >>>>> finding the remote control in the same way as before. >>>> OK, thanks for the investigation. >>>> >>>>> I'll hack the application code here now to use the new output, >>>>> but I wonder what the the thousands of other users will do when >>>>> they first try 2.6.31 after release ? >> .. >> >> Mmm.. appears to be a systemwide thing, not just for the i2c stuff. >> *All* of the input devices now no longer show their real names >> when queried with ioctl(EVIOCGNAME). This is a regression from 2.6.30. >> Note that the real names *are* still stored somewhere, because they >> do still show up correctly under /sys/ >> > > Should be fixed by f936601471d1454dacbd3b2a961fd4d883090aeb in the > for-linus branch of my tree. .. Peachy. Push it, or post it here and I can re-test with it. (does anyone else find it spooky that a google search for the above commit id actually finds Dmitry's email quoted above ? Mere seconds after he posted it for the very first time ??) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, 2009-07-19 at 16:14 -0400, Mark Lord wrote: > Dmitry Torokhov wrote: > > On Sun, Jul 19, 2009 at 03:20:50PM -0400, Mark Lord wrote: > > Should be fixed by f936601471d1454dacbd3b2a961fd4d883090aeb in the > > for-linus branch of my tree. > .. > > Peachy. Push it, or post it here and I can re-test with it. > > (does anyone else find it spooky that a google search for the > above commit id actually finds Dmitry's email quoted above ? > Mere seconds after he posted it for the very first time ??) Not since he's using a Gmail account, no. Google probably indexes it on the way in. Very effcient. The google is reading ur e-mail... -Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- lsinput.2.6.30 2009-07-19 15:14:38.278293568 -0400 +++ lsinput.2.6.31 2009-07-19 15:15:43.725375340 -0400 @@ -3,7 +3,7 @@ vendor : 0x1 product : 0x1 version : 43841 - name : "AT Translated Set 2 keyboard" + name : "event0" phys : "isa0060/serio0/input0" bits ev : EV_SYN EV_KEY EV_MSC EV_LED EV_REP @@ -12,7 +12,7 @@ vendor : 0x2 product : 0x7 version : 4017 - name : "SynPS/2 Synaptics TouchPad" + name : "event1" phys : "isa0060/serio1/input0" bits ev : EV_SYN EV_KEY EV_ABS @@ -21,7 +21,7 @@ vendor : 0x0 product : 0x5 version : 0 - name : "Lid Switch" + name : "event2" phys : "PNP0C0D/button/input0" bits ev : EV_SYN EV_SW @@ -30,7 +30,7 @@ vendor : 0x0 product : 0x1 version : 0 - name : "Power Button" + name : "event3" phys : "PNP0C0C/button/input0" bits ev : EV_SYN EV_KEY @@ -39,7 +39,7 @@ vendor : 0x0 product : 0x3 version : 0 - name : "Sleep Button" + name : "event4" phys : "PNP0C0E/button/input0" bits ev : EV_SYN EV_KEY @@ -48,34 +48,16 @@ vendor : 0x1f product : 0x1 version : 256 - name : "PC Speaker" + name : "event5" phys : "isa0061/input0" bits ev : EV_SYN EV_SND /dev/input/event6 - bustype : (null) - vendor : 0x0 - product : 0x0 - version : 0 - name : "HDA Intel Mic at Ext Right Jack" - phys : "ALSA" - bits ev : EV_SYN EV_SW - -/dev/input/event7 - bustype : (null) - vendor : 0x0 - product : 0x0 - version : 0 - name : "HDA Intel HP Out at Ext Right Ja" - phys : "ALSA" - bits ev : EV_SYN EV_SW - -/dev/input/event8 bustype : BUS_USB vendor : 0x46d product : 0xc016 version : 272 - name : "Logitech Optical USB Mouse" + name : "event6" phys : "usb-0000:00:1d.7-5.4/input0" uniq : "" bits ev : EV_SYN EV_KEY EV_REL EV_MSC