Regression 2.6.31: ioctl(EVIOCGNAME) no longer returns device name

  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:




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