linuxconsole-dev

Event API changes - EVIOCGID

[Brad H. <bh...@bi...>]

G'day,

The attached patch basically implements:
+struct input_devinfo {
+       uint16_t bustype;
+       uint16_t vendor;
+       uint16_t product;
+       uint16_t version;
+};
+

-#define EVIOCGID               _IOR('E', 0x02, short[4])               /* get device ID */
+#define EVIOCGID               _IOR('E', 0x02, struct input_devinfo)   /* get device ID */

It affects just about every input driver, as a result of some associated
cleanups that I applied, and its about 40K uncompressed - hence the gzip.

Is there anything that would stop this being applied?

Also, I note that some drivers don't set all the id values (before or after 
patch). Is there any reason for this?

Brad

-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

[with PATCH]: Event API changes - EVIOCGID

[Brad H. <bh...@bi...>]

Patch actually atached this time.

On Sun, 21 Jul 2002 20:50, Brad Hards wrote:
> G'day,
>
> The attached patch basically implements:
> +struct input_devinfo {
> +       uint16_t bustype;
> +       uint16_t vendor;
> +       uint16_t product;
> +       uint16_t version;
> +};
> +
>
> -#define EVIOCGID               _IOR('E', 0x02, short[4])               /*
> get device ID */ +#define EVIOCGID               _IOR('E', 0x02, struct
> input_devinfo)   /* get device ID */
>
> It affects just about every input driver, as a result of some associated
> cleanups that I applied, and its about 40K uncompressed - hence the gzip.
>
> Is there anything that would stop this being applied?
>
> Also, I note that some drivers don't set all the id values (before or after
> patch). Is there any reason for this?
>
> Brad

-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

Re: Event API changes - EVIOCGID

[Vojtech P. <vo...@su...>]

On Sun, Jul 21, 2002 at 08:50:56PM +1000, Brad Hards wrote:

> G'day,
> 
> The attached patch basically implements:
> +struct input_devinfo {
> +       uint16_t bustype;
> +       uint16_t vendor;
> +       uint16_t product;
> +       uint16_t version;
> +};
> +
> 
> -#define EVIOCGID               _IOR('E', 0x02, short[4])               /* get device ID */
> +#define EVIOCGID               _IOR('E', 0x02, struct input_devinfo)   /* get device ID */
> 
> It affects just about every input driver, as a result of some associated
> cleanups that I applied, and its about 40K uncompressed - hence the gzip.
> 
> Is there anything that would stop this being applied?

No, the patch is OK.

> Also, I note that some drivers don't set all the id values (before or after 
> patch). Is there any reason for this?

That'd be a bug.

Now, if you could fix that, I'd be much happier applying the patch. ;)

-- 
Vojtech Pavlik
SuSE Labs

Re: Event API changes - EVIOCGID

[Brad H. <bh...@bi...>]

On Tue, 23 Jul 2002 02:04, Vojtech Pavlik wrote:
> On Sun, Jul 21, 2002 at 08:50:56PM +1000, Brad Hards wrote:
<snip>
> > Also, I note that some drivers don't set all the id values (before or
> > after patch). Is there any reason for this?
>
> That'd be a bug.
>
> Now, if you could fix that, I'd be much happier applying the patch. ;)
OK, new patch attached. It should be fairly obvious which drivers
didn't set idvendor/idproduct/idversion, and what I hardwired them to
when I couldn't find anything sensible (like for the BUS_ISA case).

I updated it to 2.5.27 too, not that it should make any difference.

Please apply.

Brad
-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

Re: Event API changes - EVIOCGID

[Vojtech P. <vo...@su...>]

On Wed, Jul 24, 2002 at 07:32:47AM +1000, Brad Hards wrote:
> On Tue, 23 Jul 2002 02:04, Vojtech Pavlik wrote:
> > On Sun, Jul 21, 2002 at 08:50:56PM +1000, Brad Hards wrote:
> <snip>
> > > Also, I note that some drivers don't set all the id values (before or
> > > after patch). Is there any reason for this?
> >
> > That'd be a bug.
> >
> > Now, if you could fix that, I'd be much happier applying the patch. ;)
> OK, new patch attached. It should be fairly obvious which drivers
> didn't set idvendor/idproduct/idversion, and what I hardwired them to
> when I couldn't find anything sensible (like for the BUS_ISA case).
> 
> I updated it to 2.5.27 too, not that it should make any difference.
> 
> Please apply.

Oops, could you send me a patch relative to your last? I've already
applied that one.

-- 
Vojtech Pavlik
SuSE Labs

Re: Event API changes - EVIOCGID

[Brad H. <bh...@bi...>]

On Tue, 23 Jul 2002 02:04, Vojtech Pavlik wrote:
> On Sun, Jul 21, 2002 at 08:50:56PM +1000, Brad Hards wrote:
> > G'day,
> >
> > The attached patch basically implements:
> > +struct input_devinfo {
> > +       uint16_t bustype;
> > +       uint16_t vendor;
> > +       uint16_t product;
> > +       uint16_t version;
> > +};
> > +
> >
> > -#define EVIOCGID               _IOR('E', 0x02, short[4])              
> > /* get device ID */ +#define EVIOCGID               _IOR('E', 0x02,
> > struct input_devinfo)   /* get device ID */
> >
> > It affects just about every input driver, as a result of some associated
> > cleanups that I applied, and its about 40K uncompressed - hence the gzip.
> >
> > Is there anything that would stop this being applied?
>
> No, the patch is OK.
I am not happy about the change from uint16_t to __u16, which you appear
to have made before sending this to Linus.

That is a broken change - there is a standard type, and you've changed
it to a non-standard type. This is confusing to userspace programmers, and
I cannot provide a satisfactory explaination for this in documentation.

Please change it back.

Brad

-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

Re: Event API changes - EVIOCGID

[Vojtech P. <vo...@su...>]

On Sun, Jul 28, 2002 at 05:45:37PM +1000, Brad Hards wrote:
> On Tue, 23 Jul 2002 02:04, Vojtech Pavlik wrote:
> > On Sun, Jul 21, 2002 at 08:50:56PM +1000, Brad Hards wrote:
> > > G'day,
> > >
> > > The attached patch basically implements:
> > > +struct input_devinfo {
> > > +       uint16_t bustype;
> > > +       uint16_t vendor;
> > > +       uint16_t product;
> > > +       uint16_t version;
> > > +};
> > > +
> > >
> > > -#define EVIOCGID               _IOR('E', 0x02, short[4])              
> > > /* get device ID */ +#define EVIOCGID               _IOR('E', 0x02,
> > > struct input_devinfo)   /* get device ID */
> > >
> > > It affects just about every input driver, as a result of some associated
> > > cleanups that I applied, and its about 40K uncompressed - hence the gzip.
> > >
> > > Is there anything that would stop this being applied?
> >
> > No, the patch is OK.
> I am not happy about the change from uint16_t to __u16, which you appear
> to have made before sending this to Linus.
> 
> That is a broken change - there is a standard type, and you've changed
> it to a non-standard type. This is confusing to userspace programmers, and
> I cannot provide a satisfactory explaination for this in documentation.
> 
> Please change it back.

Well, I know this has been discussed back and forth.

__u16 is a kernel type and is defined if you #include <linux/input.h>.
uint16_t isn't.

__u* is used extensively in the input API anyway, so you'd have to
explain it to userspace programmers nevertheless. So I prefer keeping
the input.h include use just one type of explicit sized types.

Sure, we can change them all to uint*_t, but then do it all at once and
provide a satisfactory explanation for it. ;)

-- 
Vojtech Pavlik
SuSE Labs

Re: Event API changes - EVIOCGID

[Brad H. <bh...@bi...>]

On Sun, 28 Jul 2002 18:22, Vojtech Pavlik wrote:
> On Sun, Jul 28, 2002 at 05:45:37PM +1000, Brad Hards wrote:
<snip>
> > I am not happy about the change from uint16_t to __u16, which you appear
> > to have made before sending this to Linus.
> >
> > That is a broken change - there is a standard type, and you've changed
> > it to a non-standard type. This is confusing to userspace programmers,
> > and I cannot provide a satisfactory explaination for this in
> > documentation.
> >
> > Please change it back.
>
> Well, I know this has been discussed back and forth.
And I was right last time too :-)

> __u16 is a kernel type and is defined if you #include <linux/input.h>.
> uint16_t isn't.
__u16 is no more a kernel type than uint16_t.
It is a one line fix: include <linux/types.h> instead of <asm/types.h>
Which you probably should be doing anyway, since there is no
reason to rely on any assembler types in <linux/input.h>

> __u* is used extensively in the input API anyway, so you'd have to
> explain it to userspace programmers nevertheless. So I prefer keeping
> the input.h include use just one type of explicit sized types.
So do I, and it had better be a standard type.

Note that the input API does *NOT* use __u* extensively. In fact
if you take out the force feedback stuff (which Johannes already
agreed to change:), this is the *only* _u* usage in any part of the 
input API.

> Sure, we can change them all to uint*_t, but then do it all at once and
> provide a satisfactory explanation for it. ;)
I am doing it all. Johannes agreed to the change, and I did the only
other required entry. If Johannes agrees, I'll do the trivial changes
for force-feedback.
The reason why I am not doing it all at once is to provide patches
that do one API change at a time. Or, depending on how you look
at it, I did the only change all-at-once, and you reverted it :)

Brad

-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

Re: Event API changes - EVIOCGID

[Vojtech P. <vo...@su...>]

On Sun, Jul 28, 2002 at 06:42:18PM +1000, Brad Hards wrote:

> > > I am not happy about the change from uint16_t to __u16, which you appear
> > > to have made before sending this to Linus.
> > >
> > > That is a broken change - there is a standard type, and you've changed
> > > it to a non-standard type. This is confusing to userspace programmers,
> > > and I cannot provide a satisfactory explaination for this in
> > > documentation.
> > >
> > > Please change it back.
> >
> > Well, I know this has been discussed back and forth.
> And I was right last time too :-)
> 
> > __u16 is a kernel type and is defined if you #include <linux/input.h>.
> > uint16_t isn't.
> __u16 is no more a kernel type than uint16_t.
> It is a one line fix: include <linux/types.h> instead of <asm/types.h>
> Which you probably should be doing anyway, since there is no
> reason to rely on any assembler types in <linux/input.h>
> 
> > __u* is used extensively in the input API anyway, so you'd have to
> > explain it to userspace programmers nevertheless. So I prefer keeping
> > the input.h include use just one type of explicit sized types.
> So do I, and it had better be a standard type.
> 
> Note that the input API does *NOT* use __u* extensively. In fact
> if you take out the force feedback stuff (which Johannes already
> agreed to change:), this is the *only* _u* usage in any part of the 
> input API.
> 
> > Sure, we can change them all to uint*_t, but then do it all at once and
> > provide a satisfactory explanation for it. ;)
> I am doing it all. Johannes agreed to the change, and I did the only
> other required entry. If Johannes agrees, I'll do the trivial changes
> for force-feedback.

Please do then. Together with the change of <asm/types.h> to
<linux/types.h>.  I hope it doesn't conflict if the user also #includes
"stdint.h" in the userspace program, though.

> The reason why I am not doing it all at once is to provide patches
> that do one API change at a time. Or, depending on how you look
> at it, I did the only change all-at-once, and you reverted it :)

-- 
Vojtech Pavlik
SuSE Labs

Re: Event API changes - EVIOCGID

[Johann D. <joh...@la...>]

Brad Hards wrote:
> On Sun, 28 Jul 2002 18:22, Vojtech Pavlik wrote:
> 
 > [...]
> 
>>__u* is used extensively in the input API anyway, so you'd have to
>>explain it to userspace programmers nevertheless. So I prefer keeping
>>the input.h include use just one type of explicit sized types.
> 
> So do I, and it had better be a standard type.
> 
> Note that the input API does *NOT* use __u* extensively. In fact
> if you take out the force feedback stuff (which Johannes already

(Just a detail: my name is Johann)

> agreed to change:), this is the *only* _u* usage in any part of the 
> input API.
> 

I did this change in the past, but it was undone (not by me), as it 
would break user-space applications. I definitely agree to use uint16_t.

> 
>>Sure, we can change them all to uint*_t, but then do it all at once and
>>provide a satisfactory explanation for it. ;)
> 
> I am doing it all. Johannes agreed to the change, and I did the only
> other required entry. If Johannes agrees, I'll do the trivial changes
> for force-feedback.

Ok with me.

> The reason why I am not doing it all at once is to provide patches
> that do one API change at a time. Or, depending on how you look
> at it, I did the only change all-at-once, and you reverted it :)
> 
> Brad
> 

-- 
Johann Deneux