(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 ?
>
> Where does lsinput get the string from?
..
Here's a test program for you:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <linux/input.h>
// Invoke with "/dev/input/event4" as argv[1]
//
// On 2.6.30, this gives the real name, eg. "i2c IR (Hauppauge)".
// On 2.6.31, it simply gives "event4" as the "name".
int main(int argc, char *argv[])
{
char buf[32];
int fd, rc;
fd = open(argv[1], O_RDONLY);
if (fd == -1) {
perror(argv[1]);
exit(1);
}
rc = ioctl(fd,EVIOCGNAME(sizeof(buf)),buf);
if (rc >= 0)
fprintf(stderr," name : \"%.*s\"\n", rc, buf);
return 0;
}
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/
> Here's a test program for you:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <errno.h>
> #include <fcntl.h>
> #include <sys/ioctl.h>
> #include <linux/input.h>
>
> // Invoke with "/dev/input/event4" as argv[1]
> //
> // On 2.6.30, this gives the real name, eg. "i2c IR (Hauppauge)".
> // On 2.6.31, it simply gives "event4" as the "name".
>
> int main(int argc, char *argv[])
> {
> char buf[32];
> int fd, rc;
>
> fd = open(argv[1], O_RDONLY);
> if (fd == -1) {
> perror(argv[1]);
> exit(1);
> }
> rc = ioctl(fd,EVIOCGNAME(sizeof(buf)),buf);
> if (rc >= 0)
> fprintf(stderr," name : \"%.*s\"\n", rc, buf);
> return 0;
> }
..
Since this regression should be visible on *any* system, not just mine,
I think perhaps the input-subsystem developers ought to be the ones to
go and burn some time on a git-bisect, if need be.
Eg. Here's what's different on my notebook here:
--- 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
On Sun, Jul 19, 2009 at 02:26:53PM -0400, 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 ?
>>
>> Where does lsinput get the string from?
> ..
>
> Here's a test program for you:
>
And I think have a fix for that, commit
f936601471d1454dacbd3b2a961fd4d883090aeb
in the for-linus branch of my tree.
--
Dmitry
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.
--
Dmitry
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
--
Jean Delvare
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 ??)
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