linuxconsole-dev

evdev types

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

Gday all,

In my continuing journey of documentation, I got to EVIOCGID, which returns 
short[4]. Is there any reason why that couldn't be a 
struct evdev_ident (or input_ident)
{
	uint16_t bustype;
	uint16_t vendor_id;
	uint16_t product_id;
	uint16_t version;
};

Similarly, 
struct ff_replay probably should be
{
        uint16_t length;           /* Duration of an effect */
        uint16_t delay;            /* Time to wait before to start playing an 
effect */
};

because __u16 is inherently non-portable (refer Linux Device Drivers book, 
Chapter 10), not to mention being even uglier than the [type]_t notation. No 
mean feat :)

And same principle for the other ff_ structures.

The followon from this would be for the internal struct input_dev to contain a 
struct evdev_ident (or input_ident) instead of the 
        unsigned short idbus;
        unsigned short idvendor;
        unsigned short idproduct;
        unsigned short idversion;

Any thoughts?

Brad

Re: evdev types

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

On Mon, Apr 15, 2002 at 04:23:09PM +1000, Brad Hards wrote:

> Gday all,
> 
> In my continuing journey of documentation, I got to EVIOCGID, which returns 
> short[4]. Is there any reason why that couldn't be a 
> struct evdev_ident (or input_ident)
> {
> 	uint16_t bustype;
> 	uint16_t vendor_id;
> 	uint16_t product_id;
> 	uint16_t version;
> };

Yes, if this is cleaner. I have much bigger worries about the size of
'long' in EVIOCGBIT and /proc/bus/input/devices output on archs that
support mixed 32/64-bit binaries (SPARC, PPC, x86-64).

> Similarly, 
> struct ff_replay probably should be
> {
>         uint16_t length;           /* Duration of an effect */
>         uint16_t delay;            /* Time to wait before to start playing an 
> effect */
> };
> 
> because __u16 is inherently non-portable (refer Linux Device Drivers book, 
> Chapter 10), not to mention being even uglier than the [type]_t notation. No 
> mean feat :)
> 
> And same principle for the other ff_ structures.
> 
> The followon from this would be for the internal struct input_dev to contain a 
> struct evdev_ident (or input_ident) instead of the 
>         unsigned short idbus;
>         unsigned short idvendor;
>         unsigned short idproduct;
>         unsigned short idversion;
> 
> Any thoughts?

Feel free to submit a patch. :) I'll most likely accept it.

-- 
Vojtech Pavlik
SuSE Labs

Re: evdev types

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

On Mon, 15 Apr 2002 17:40, Vojtech Pavlik wrote:
<snip>
> Feel free to submit a patch. :) I'll most likely accept it.
OK. I'll attack this problem in small chunks.

Patch against evtest.c and patch against 2.4.19-pre6 attached, just attacking 
the EVIOCGID ioctl at this stage. Note that most of the kernel changes are in 
driver/usb.

How does this look?

Brad

Re: evdev types

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

On Mon, 15 Apr 2002 17:40, Vojtech Pavlik wrote:
> Yes, if this is cleaner. I have much bigger worries about the size of
> 'long' in EVIOCGBIT and /proc/bus/input/devices output on archs that
> support mixed 32/64-bit binaries (SPARC, PPC, x86-64).
Oh. Ugly.
I thought that those definitions were purely internal - I hadn't got that far 
into the detail of the API.

I'll continue along with the documentation/tutorial, and raise questions / 
patches as appropriate.

BTW: The documentation is for USB HID, to try to answer questions for 
developers of products and userspace apps.
It covers hiddev, evdev, joystick (including force feedback), mouse and 
keyboard.
I am doing hiddev and evdev in detail, since I think these are basically 
undocumented. I've just done a couple of ioctl examples for each so far.
I am doing joystick by direct reference to the kernel docs - I may copy the 
kernel files into the documentation (and docbook them) at a later stage and 
add some examples, but the initial work work will be on evdev and hiddev, and 
there is plenty there.

What is missing is keyboard and mouse. I'd be willing to leave out keyboard 
(because the stdin/scanf/getc semantic is probably enough. What I don't have 
is mouse coverage. Does anyone have a good pointer to programming with the 
PS2 variations? I was thinking about just pointing to libgpm, but that 
doesn't really explain what comes out of /dev/input/mouse[0..30] when you 
read. 

Brad

Re: evdev types

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

On Mon, Apr 15, 2002 at 08:41:33PM +1000, Brad Hards wrote:
> On Mon, 15 Apr 2002 17:40, Vojtech Pavlik wrote:
> > Yes, if this is cleaner. I have much bigger worries about the size of
> > 'long' in EVIOCGBIT and /proc/bus/input/devices output on archs that
> > support mixed 32/64-bit binaries (SPARC, PPC, x86-64).
> Oh. Ugly.

Yeah. setbit() et al work on longs, and longs are OK in an API which
isn't on a mixed 32/64-bit arch. But since the 32/64 bit stuff happens,
it gets pretty ugly.

> I thought that those definitions were purely internal - I hadn't got that far 
> into the detail of the API.

Unfortunately they are not - they can't be - apps need to know what
valuators, keys, whatever the device has.

> I'll continue along with the documentation/tutorial, and raise questions / 
> patches as appropriate.
> 
> BTW: The documentation is for USB HID, to try to answer questions for 
> developers of products and userspace apps.
> It covers hiddev, evdev, joystick (including force feedback), mouse and 
> keyboard.

God bless you for that. It is really needed. And I never can get me to
write docs. :(

> I am doing hiddev and evdev in detail, since I think these are basically 
> undocumented. I've just done a couple of ioctl examples for each so far.
> I am doing joystick by direct reference to the kernel docs - I may copy the 
> kernel files into the documentation (and docbook them) at a later stage and 
> add some examples, but the initial work work will be on evdev and hiddev, and 
> there is plenty there.

That's exactly what's needed - actually joydev (and its api) is
obsoleted by evdev.

> What is missing is keyboard and mouse. I'd be willing to leave out keyboard 
> (because the stdin/scanf/getc semantic is probably enough.

There isn't any keyboard API other than evdev and the console.

> What I don't have 
> is mouse coverage. Does anyone have a good pointer to programming with the 
> PS2 variations? I was thinking about just pointing to libgpm, but that 
> doesn't really explain what comes out of /dev/input/mouse[0..30] when you 
> read. 

 /dev/input/mouse[0..30] simulates (quite exactly, both directions) the
protocol of Microsoft IntelliMouse Explorer. But no new applications
should use it, evdev is more powerful and easier to write for.

I hope both mousedev and joydev will not be needed by 2.6 (2.8) or so.

-- 
Vojtech Pavlik
SuSE Labs

Re: evdev types

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

On Mon, 15 Apr 2002 22:14, Vojtech Pavlik wrote:
<snip>
> God bless you for that. It is really needed. And I never can get me to
> write docs. :(
We each do what we are good at. You just keep coding...

> > I am doing hiddev and evdev in detail, since I think these are basically
> > undocumented. I've just done a couple of ioctl examples for each so far.
> > I am doing joystick by direct reference to the kernel docs - I may copy
> > the kernel files into the documentation (and docbook them) at a later
> > stage and add some examples, but the initial work work will be on evdev
> > and hiddev, and there is plenty there.
>
> That's exactly what's needed - actually joydev (and its api) is
> obsoleted by evdev.
I actually wrote the joystick bit first. I put the whole joystick section on 
the end of this email. It is more markup than content :)

> > What is missing is keyboard and mouse. I'd be willing to leave out
> > keyboard (because the stdin/scanf/getc semantic is probably enough.
>
> There isn't any keyboard API other than evdev and the console.
I was thinking about how to get the different modes (scancodes, keycodes, etc) 
for those apps that care about such stuff.

> > What I don't have
> > is mouse coverage. Does anyone have a good pointer to programming with
> > the PS2 variations? I was thinking about just pointing to libgpm, but
> > that doesn't really explain what comes out of /dev/input/mouse[0..30]
> > when you read.
>
>  /dev/input/mouse[0..30] simulates (quite exactly, both directions) the
> protocol of Microsoft IntelliMouse Explorer. But no new applications
> should use it, evdev is more powerful and easier to write for.
>
> I hope both mousedev and joydev will not be needed by 2.6 (2.8) or so.
Until it is removed, we need to document it :/
I'd like to have about the same amount of detail for mouse and keyboard 
programming as the following joystick section. And in the same way - which 
modules matter, what the device nodes do (for mouse/mice), and a pointer to 
some more data.

I certainly don't want to maintain documentation on weird, legacy interfaces 
:)

Brad


- - Joystick section follows.
<Sect1><title>The joystick interface</title>

<para>
The joystick interface is provided by the
<filename>joydev.o</filename> module, and the outputs appear on the
<filename>/dev/input/js0</filename>,
<filename>/dev/input/js1</filename> (and so on) device nodes.
</para>

<para>
More information on programming with the joystick interface is
provided in the kernel distribution (see the file
<filename>Documentation/input/joystick-api.txt</filename> in a current
kernel).
</para>

<Sect2><title>Force Feedback</title>
<para>
Information on programming force feedback effects for joysticks is
provided in the kernel distribution (see the file
<filename>Documentation/input/ff.txt</filename> in a current
kernel).
</para>
</Sect2>

</Sect1>

Re: evdev types

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

On Mon, 15 Apr 2002 20:22, Brad Hards wrote:
> On Mon, 15 Apr 2002 17:40, Vojtech Pavlik wrote:
> <snip>
>
> > Feel free to submit a patch. :) I'll most likely accept it.
>
> OK. I'll attack this problem in small chunks.
>
> Patch against evtest.c and patch against 2.4.19-pre6 attached, just
> attacking the EVIOCGID ioctl at this stage. Note that most of the kernel
> changes are in driver/usb.
Note: I missed a bit in the patch - should have incremented the version 
(EV_VERSION). Please don't forward the patch without adding that part.

Brad

Re: evdev types

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

On Mon, Apr 15, 2002 at 11:11:33PM +1000, Brad Hards wrote:
> On Mon, 15 Apr 2002 20:22, Brad Hards wrote:
> > On Mon, 15 Apr 2002 17:40, Vojtech Pavlik wrote:
> > <snip>
> >
> > > Feel free to submit a patch. :) I'll most likely accept it.
> >
> > OK. I'll attack this problem in small chunks.
> >
> > Patch against evtest.c and patch against 2.4.19-pre6 attached, just
> > attacking the EVIOCGID ioctl at this stage. Note that most of the kernel
> > changes are in driver/usb.

> Note: I missed a bit in the patch - should have incremented the version 
> (EV_VERSION). Please don't forward the patch without adding that part.

May I suggest one more change?

dev->dinfo.bustype to dev->id.bus
dev->devinfo.id_vendor ro dev->id.vendor

It's no less informative, and looks much better. 

-- 
Vojtech Pavlik
SuSE Labs

Re: evdev types

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

On Mon, 15 Apr 2002 23:44, Vojtech Pavlik wrote:
<snip>
> May I suggest one more change?
>
> dev->dinfo.bustype to dev->id.bus
> dev->devinfo.id_vendor ro dev->id.vendor
Mostly done. I kept bustype, because it is more descriptive, and because it 
helps the assignment operators line up :)

Patch against 2.4.19-pre7 and evtest are enclosed.

How does this look?

Brad

Re: evdev types

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

On Mon, 15 Apr 2002 22:14, Vojtech Pavlik wrote:
> On Mon, Apr 15, 2002 at 08:41:33PM +1000, Brad Hards wrote:
> > On Mon, 15 Apr 2002 17:40, Vojtech Pavlik wrote:
> > > Yes, if this is cleaner. I have much bigger worries about the size of
> > > 'long' in EVIOCGBIT and /proc/bus/input/devices output on archs that
> > > support mixed 32/64-bit binaries (SPARC, PPC, x86-64).
> >
> > Oh. Ugly.
>
> Yeah. setbit() et al work on longs, and longs are OK in an API which
> isn't on a mixed 32/64-bit arch. But since the 32/64 bit stuff happens,
> it gets pretty ugly.
OK, I have looked at it some more, and it is scaring me quite a bit :)

The approximate plan is to return a 32 bit quantity (uint32_t or __u32, 
depending on whether Greg convinces me or not).

I am not sure I really understand what EVIOCGBIT is doing. It looks like it 
returns a 2-d bitfield array, where one dimension is the event type, and the 
other dimension is a index of possible options within that event type. The 
"zeroth" option is whether that event type is supported at all by the device.

The result can be constrained by arguments so
ioctl(fd, EVIOCGBIT[EV_KEY,EV_KEY], result[0])
will only return the options for keys, as a bitfield array.

Is this all basically true?

What is EV_RST?

Is the limit on KEY_MAX (in evtest.c) showing that there will probably always 
be more KEY options that RELative or ABSolute options?

Brad

Re: evdev types

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

On Wed, Apr 17, 2002 at 11:58:31AM +1000, Brad Hards wrote:
> On Mon, 15 Apr 2002 22:14, Vojtech Pavlik wrote:
> > On Mon, Apr 15, 2002 at 08:41:33PM +1000, Brad Hards wrote:
> > > On Mon, 15 Apr 2002 17:40, Vojtech Pavlik wrote:
> > > > Yes, if this is cleaner. I have much bigger worries about the size of
> > > > 'long' in EVIOCGBIT and /proc/bus/input/devices output on archs that
> > > > support mixed 32/64-bit binaries (SPARC, PPC, x86-64).
> > >
> > > Oh. Ugly.
> >
> > Yeah. setbit() et al work on longs, and longs are OK in an API which
> > isn't on a mixed 32/64-bit arch. But since the 32/64 bit stuff happens,
> > it gets pretty ugly.
> OK, I have looked at it some more, and it is scaring me quite a bit :)
> 
> The approximate plan is to return a 32 bit quantity (uint32_t or __u32, 
> depending on whether Greg convinces me or not).
> 
> I am not sure I really understand what EVIOCGBIT is doing. It looks like it 
> returns a 2-d bitfield array, where one dimension is the event type, and the 
> other dimension is a index of possible options within that event type. The 
> "zeroth" option is whether that event type is supported at all by the device.

Not really a 2d bitfield, more like a bunch of 1d bitfields with uneven
lengths. You pass an argument selecting which one you want and you get
it. I think EVIOCGBIT is quite OK, because it doesn't really depend on
the data type ... it just copies a chunk of memory.

What is probably the only wrong w/ the bit arrays is the way they're
passed through by /proc and hotplug support. And that can be fixed
without any major pain, because noone is using that on 64-bit systems
yet.

> The result can be constrained by arguments so
> ioctl(fd, EVIOCGBIT[EV_KEY,EV_KEY], result[0])
> will only return the options for keys, as a bitfield array.

I think that'd be

	ioctl(fd, EVIOCGBIT(EV_KEY, sizeof(my_buffer)), buffer);

> 
> Is this all basically true?
> 
> What is EV_RST?

An RESET event. It's sent to reset the device or received when the
device was reset. Currently unused, but planned for use with possible
recalibration (after changing the EVIOCGABS boundaries) of touchscreen and
joystick devices.

> Is the limit on KEY_MAX (in evtest.c) showing that there will probably always 
> be more KEY options that RELative or ABSolute options?

Yes. There is more different key types than joystick or mouse axis
types.

-- 
Vojtech Pavlik
SuSE Labs

Re: evdev types

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

On Wed, 17 Apr 2002 18:21, Vojtech Pavlik wrote:
<snip>
> Not really a 2d bitfield, more like a bunch of 1d bitfields with uneven
> lengths. You pass an argument selecting which one you want and you get
> it. I think EVIOCGBIT is quite OK, because it doesn't really depend on
> the data type ... it just copies a chunk of memory.
>
> What is probably the only wrong w/ the bit arrays is the way they're
> passed through by /proc and hotplug support. And that can be fixed
> without any major pain, because noone is using that on 64-bit systems
> yet.
OK, no issue on 2.4, correct?
This was stuff you added in 2.5?

><snip>
> 	ioctl(fd, EVIOCGBIT(EV_KEY, sizeof(my_buffer)), buffer);
Ah, I think I have it now. For 

ioctl(a, EVIOCGBIT(b, c), d)

a is the file descriptor for the event device you want

b is the type of descriptor bitfield to return
	0 for the type of descriptors that are used
	EV_KEY for the key bitfield
	EV_REL for the relative axes bitfield
	EV_ABS for the absolute axes bitfield
	EV_MSC for the miscellaneous bitfield (not used yet?)
	EV_LED for the bright lights bitfield
	EV_SND for the loud noises bitfield
	EV_REP for the repeat function bitfield (not used yet?)
	EV_FF for the force feedback bitfield

c is the maximum number of bits to return
	If the number of bits available is greater, then you get a warning message

d is a pointer to the memory to put the bitfield

and the return value is the number of bits transfered (if it succeeds) or 
-EFAULT if it fails. The number of bits transferred is the lesser of c, and 
the number of bits for that descriptor type (eg forb == 0, it is EV_MAX,  b 
== EV_KEY, it is KEY_MAX; for b == EV_REL it is REL_MAX, and so on).

OK, my only question now is "how do you get the descriptor bitfield for 
EV_RST?"

Brad

Re: evdev types

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

On Wed, Apr 17, 2002 at 09:56:05PM +1000, Brad Hards wrote:
> On Wed, 17 Apr 2002 18:21, Vojtech Pavlik wrote:
> <snip>
> > Not really a 2d bitfield, more like a bunch of 1d bitfields with uneven
> > lengths. You pass an argument selecting which one you want and you get
> > it. I think EVIOCGBIT is quite OK, because it doesn't really depend on
> > the data type ... it just copies a chunk of memory.
> >
> > What is probably the only wrong w/ the bit arrays is the way they're
> > passed through by /proc and hotplug support. And that can be fixed
> > without any major pain, because noone is using that on 64-bit systems
> > yet.
> OK, no issue on 2.4, correct?
> This was stuff you added in 2.5?
> 
> ><snip>
> > 	ioctl(fd, EVIOCGBIT(EV_KEY, sizeof(my_buffer)), buffer);
> Ah, I think I have it now. For 
> 
> ioctl(a, EVIOCGBIT(b, c), d)
> 
> a is the file descriptor for the event device you want
> 
> b is the type of descriptor bitfield to return
> 	0 for the type of descriptors that are used
> 	EV_KEY for the key bitfield
> 	EV_REL for the relative axes bitfield
> 	EV_ABS for the absolute axes bitfield
> 	EV_MSC for the miscellaneous bitfield (not used yet?)
> 	EV_LED for the bright lights bitfield
> 	EV_SND for the loud noises bitfield
> 	EV_REP for the repeat function bitfield (not used yet?)
> 	EV_FF for the force feedback bitfield
> 
> c is the maximum number of bits to return
> 	If the number of bits available is greater, then you get a warning message

Bytes.

> d is a pointer to the memory to put the bitfield

Yes.

> and the return value is the number of bits transfered (if it succeeds) or 
> -EFAULT if it fails. 

Bytes, again.

> The number of bits transferred is the lesser of c, and 
> the number of bits for that descriptor type (eg forb == 0, it is EV_MAX,  b 
> == EV_KEY, it is KEY_MAX; for b == EV_REL it is REL_MAX, and so on).
> 
> OK, my only question now is "how do you get the descriptor bitfield for 
> EV_RST?"

There is none. There are no bits for EV_RST, it's only one event in its
own class.

-- 
Vojtech Pavlik
SuSE Labs

Re: evdev types

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

On Wed, 17 Apr 2002 23:18, Vojtech Pavlik wrote:
> On Wed, Apr 17, 2002 at 09:56:05PM +1000, Brad Hards wrote:
<snip>
> > Ah, I think I have it now. For
> >
> > ioctl(a, EVIOCGBIT(b, c), d)
> >
> > a is the file descriptor for the event device you want
> >
> > b is the type of descriptor bitfield to return
> > 	0 for the type of descriptors that are used
> > 	EV_KEY for the key bitfield
> > 	EV_REL for the relative axes bitfield
> > 	EV_ABS for the absolute axes bitfield
> > 	EV_MSC for the miscellaneous bitfield (not used yet?)
> > 	EV_LED for the bright lights bitfield
> > 	EV_SND for the loud noises bitfield
> > 	EV_REP for the repeat function bitfield (not used yet?)
> > 	EV_FF for the force feedback bitfield
> >
> > c is the maximum number of bits to return
> > 	If the number of bits available is greater, then you get a warning
> > message
>
> Bytes.
Actually, it is more complex than that. The code all assumes that there is a 
long on the other end.
So my sample code for reading LED values (simplified here for shortness, let 
me know if you want it all):
<programlisting>
  uint8_t led_bitmask[LED_MAX/8 + 1];
...
  ioctl(fd, EVIOCGBIT(EV_LED, sizeof(led_bitmask)), led_bitmask)
</programlisting>

is hitting the truncation check, because I'm only providing two bytes, and it 
wants to return four (long, on ix86). Makes a mess in my syslog, and yet it 
is reasonable from an application point of view, since the led_bitmask 
doesn't really need to be an array - I could have just malloc'd it, and it is 
big enough to hold all valid bit settings.

Why use long arrays for the bitfields? Why not byte arrays? This seems like 
the easiest way to clean up your concerns with 32/64 split systems, and also 
to clean up this.


> > OK, my only question now is "how do you get the descriptor bitfield for
> > EV_RST?"
>
> There is none. There are no bits for EV_RST, it's only one event in its
> own class.
OK. This also applies to EV_REP?

Thanks again for all your help.

Brad

Re: evdev types

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

On Thu, Apr 18, 2002 at 05:23:51PM +1000, Brad Hards wrote:
> On Wed, 17 Apr 2002 23:18, Vojtech Pavlik wrote:
> > On Wed, Apr 17, 2002 at 09:56:05PM +1000, Brad Hards wrote:
> <snip>
> > > Ah, I think I have it now. For
> > >
> > > ioctl(a, EVIOCGBIT(b, c), d)
> > >
> > > a is the file descriptor for the event device you want
> > >
> > > b is the type of descriptor bitfield to return
> > > 	0 for the type of descriptors that are used
> > > 	EV_KEY for the key bitfield
> > > 	EV_REL for the relative axes bitfield
> > > 	EV_ABS for the absolute axes bitfield
> > > 	EV_MSC for the miscellaneous bitfield (not used yet?)
> > > 	EV_LED for the bright lights bitfield
> > > 	EV_SND for the loud noises bitfield
> > > 	EV_REP for the repeat function bitfield (not used yet?)
> > > 	EV_FF for the force feedback bitfield
> > >
> > > c is the maximum number of bits to return
> > > 	If the number of bits available is greater, then you get a warning
> > > message
> >
> > Bytes.
> Actually, it is more complex than that. The code all assumes that there is a 
> long on the other end.
> So my sample code for reading LED values (simplified here for shortness, let 
> me know if you want it all):
> <programlisting>
>   uint8_t led_bitmask[LED_MAX/8 + 1];
> ...
>   ioctl(fd, EVIOCGBIT(EV_LED, sizeof(led_bitmask)), led_bitmask)
> </programlisting>
> 
> is hitting the truncation check, because I'm only providing two bytes, and it 
> wants to return four (long, on ix86). Makes a mess in my syslog, and yet it 
> is reasonable from an application point of view, since the led_bitmask 
> doesn't really need to be an array - I could have just malloc'd it, and it is 
> big enough to hold all valid bit settings.
> 
> Why use long arrays for the bitfields? Why not byte arrays? This seems like 
> the easiest way to clean up your concerns with 32/64 split systems, and also 
> to clean up this.

Because set_bit/test_bit and friends all operate on longs.

Regarding the two bytes/four bytes stuff we can:

1) Remove the warning and all will work OK

or

2) Don't warn if the valid bits actually fit

And for /proc and hotplug I think we can specify that we'll always use
32-bit numbers (we currently use longs (%lx), where the size varies
between 32 and 64-bit kernels on the same system).

> > > OK, my only question now is "how do you get the descriptor bitfield for
> > > EV_RST?"
> >
> > There is none. There are no bits for EV_RST, it's only one event in its
> > own class.

> OK. This also applies to EV_REP?

Yes.

> Thanks again for all your help.

-- 
Vojtech Pavlik
SuSE Labs

Re: evdev types

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

On Thu, 18 Apr 2002 17:33, Vojtech Pavlik wrote:
<snip>
> > Why use long arrays for the bitfields? Why not byte arrays? This seems
> > like the easiest way to clean up your concerns with 32/64 split systems,
> > and also to clean up this.
>
> Because set_bit/test_bit and friends all operate on longs.
Ah.

> Regarding the two bytes/four bytes stuff we can:
>
> 1) Remove the warning and all will work OK
>
> or
>
> 2) Don't warn if the valid bits actually fit
I like 2. Do you want a patch?

> And for /proc and hotplug I think we can specify that we'll always use
> 32-bit numbers (we currently use longs (%lx), where the size varies
> between 32 and 64-bit kernels on the same system).
You can fix that - I'm not doing 2.5 yet :)

Brad

Re: evdev types

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

On Thu, Apr 18, 2002 at 05:43:58PM +1000, Brad Hards wrote:
> On Thu, 18 Apr 2002 17:33, Vojtech Pavlik wrote:
> <snip>
> > > Why use long arrays for the bitfields? Why not byte arrays? This seems
> > > like the easiest way to clean up your concerns with 32/64 split systems,
> > > and also to clean up this.
> >
> > Because set_bit/test_bit and friends all operate on longs.
> Ah.
> 
> > Regarding the two bytes/four bytes stuff we can:
> >
> > 1) Remove the warning and all will work OK
> >
> > or
> >
> > 2) Don't warn if the valid bits actually fit
> I like 2. Do you want a patch?

Send it if you have the time to do it. Right now, I don't.

> > And for /proc and hotplug I think we can specify that we'll always use
> > 32-bit numbers (we currently use longs (%lx), where the size varies
> > between 32 and 64-bit kernels on the same system).
> You can fix that - I'm not doing 2.5 yet :)

I will. It's not tough.

-- 
Vojtech Pavlik
SuSE Labs

Re: evdev types

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

On Wed, 17 Apr 2002 16:27, Brad Hards wrote:
> On Mon, 15 Apr 2002 23:44, Vojtech Pavlik wrote:
> <snip>
>
> > May I suggest one more change?
> >
> > dev->dinfo.bustype to dev->id.bus
> > dev->devinfo.id_vendor ro dev->id.vendor
>
> Mostly done. I kept bustype, because it is more descriptive, and because it
> helps the assignment operators line up :)
I have done a similar change to the EVIOCGABS ioctl. It now returns 
input_absinfo, rather than int[5]. Patches against evtest and 2.4.19-pre7 are 
attached, including the previous patch (so you only need these ones). Let me 
know if you'd rather an incremental patch.

I have commented out the current value element. I am unconvinced that it is an 
appropriate thing to return from this ioctl. My tutorial works in stages -
* finding out things about the event system (EVIOCGVERSION)
* finding out about the device identity (EVIOCGNAME and EVIOCGID, maybe 
EVIOCGBUS if it works)
* finding out about the device features (EVIOCGBIT and EVIOCGABS)
* getting information from the device (read())
* sending information to the device (write())
* modifying the device behaviour (eg EVIOCGREP and EVIOCSREP)

I think that the first element (now ->curr_value) is a different concept to 
the programmer compares to the rest of the features identified with 
EVIOCGABS. 

If it is important that that value is available before someone does anything 
to the device, then another ioctl is probably appropriate.

PLEASE NOTE:
I need to know if these patches are going to be accepted and pushed into the 
main-line kernels, because they affect the documentation. Please let me know 
ASAP which way you are going to go.

Brad

Re: evdev types

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

On Mon, 22 Apr 2002 10:04, Brad Hards wrote:
> On Wed, 17 Apr 2002 16:27, Brad Hards wrote:
> > On Mon, 15 Apr 2002 23:44, Vojtech Pavlik wrote:
> > <snip>
> >
> > > May I suggest one more change?
> > >
> > > dev->dinfo.bustype to dev->id.bus
> > > dev->devinfo.id_vendor ro dev->id.vendor
> >
> > Mostly done. I kept bustype, because it is more descriptive, and because
> > it helps the assignment operators line up :)
>
> I have done a similar change to the EVIOCGABS ioctl. It now returns
> input_absinfo, rather than int[5]. Patches against evtest and 2.4.19-pre7
> are attached, including the previous patch (so you only need these ones).
Really attached, this time

> Let me know if you'd rather an incremental patch.
>
> I have commented out the current value element. I am unconvinced that it is
> an appropriate thing to return from this ioctl. My tutorial works in stages
> - * finding out things about the event system (EVIOCGVERSION)
> * finding out about the device identity (EVIOCGNAME and EVIOCGID, maybe
> EVIOCGBUS if it works)
> * finding out about the device features (EVIOCGBIT and EVIOCGABS)
> * getting information from the device (read())
> * sending information to the device (write())
> * modifying the device behaviour (eg EVIOCGREP and EVIOCSREP)
>
> I think that the first element (now ->curr_value) is a different concept to
> the programmer compares to the rest of the features identified with
> EVIOCGABS.
>
> If it is important that that value is available before someone does
> anything to the device, then another ioctl is probably appropriate.
>
> PLEASE NOTE:
> I need to know if these patches are going to be accepted and pushed into
> the main-line kernels, because they affect the documentation. Please let me
> know ASAP which way you are going to go.
>
> Brad

Re: evdev types

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

On Mon, Apr 22, 2002 at 10:04:54AM +1000, Brad Hards wrote:

> On Wed, 17 Apr 2002 16:27, Brad Hards wrote:
> > On Mon, 15 Apr 2002 23:44, Vojtech Pavlik wrote:
> > <snip>
> >
> > > May I suggest one more change?
> > >
> > > dev->dinfo.bustype to dev->id.bus
> > > dev->devinfo.id_vendor ro dev->id.vendor
> >
> > Mostly done. I kept bustype, because it is more descriptive, and because it
> > helps the assignment operators line up :)
> I have done a similar change to the EVIOCGABS ioctl. It now returns 
> input_absinfo, rather than int[5]. Patches against evtest and 2.4.19-pre7 are 
> attached, including the previous patch (so you only need these ones). Let me 
> know if you'd rather an incremental patch.
> 
> I have commented out the current value element. I am unconvinced that it is an 
> appropriate thing to return from this ioctl.

You need a way to read the initial values of all absolute valuators
before you get any events. You may get none if the valuator doesn't
ever change.

> My tutorial works in stages -
> * finding out things about the event system (EVIOCGVERSION)
> * finding out about the device identity (EVIOCGNAME and EVIOCGID, maybe 
> EVIOCGBUS if it works)

EVIOCGBUS? What's that?

> * finding out about the device features (EVIOCGBIT and EVIOCGABS)

Add EVIOCGKEY, EVIOCGLED and EVIOCGSND to that.

> * getting information from the device (read())
> * sending information to the device (write())
> * modifying the device behaviour (eg EVIOCGREP and EVIOCSREP)
> 
> I think that the first element (now ->curr_value) is a different concept to 
> the programmer compares to the rest of the features identified with 
> EVIOCGABS. 

It's also a value you need before you start reading the events, so it's
handy there.

> If it is important that that value is available before someone does anything 
> to the device, then another ioctl is probably appropriate.

Might work as well.

> PLEASE NOTE:
> I need to know if these patches are going to be accepted and pushed into the 
> main-line kernels, because they affect the documentation. Please let me know 
> ASAP which way you are going to go.

They will.
 

-- 
Vojtech Pavlik
SuSE Labs

Re: evdev types

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

On Mon, 22 Apr 2002 17:22, Vojtech Pavlik wrote:
> On Mon, Apr 22, 2002 at 10:04:54AM +1000, Brad Hards wrote:
<snip>
> You need a way to read the initial values of all absolute valuators
> before you get any events. You may get none if the valuator doesn't
> ever change.
My original thinking was "Then why does the valuator matter?", but I thought 
about it some more. A dial that indicates volume is a good example of one 
that matters. Too much joystick thinking...

> > * finding out about the device identity (EVIOCGNAME and EVIOCGID, maybe
> > EVIOCGBUS if it works)
>
> EVIOCGBUS? What's that?
Beats me:
$ grep EVIOCGBUS include/linux/input.h
#define EVIOCGBUS               _IOR('E', 0x07, short[4])               /* get 
bus address */

I just want it to work or go away. Anyone owning up to putting it in 
<linux/input.h>?

> > * finding out about the device features (EVIOCGBIT and EVIOCGABS)
>
> Add EVIOCGKEY, EVIOCGLED and EVIOCGSND to that.
OK, added to list.

> > I think that the first element (now ->curr_value) is a different concept
> > to the programmer compares to the rest of the features identified with
> > EVIOCGABS.
>
> It's also a value you need before you start reading the events, so it's
> handy there.
With further thought, I think we keep it in the same ioctl. Delete the comment 
marks. Might help stop binary breakage too.

Brad

Re: evdev types

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

On Mon, Apr 22, 2002 at 06:19:29PM +1000, Brad Hards wrote:
> On Mon, 22 Apr 2002 17:22, Vojtech Pavlik wrote:
> > On Mon, Apr 22, 2002 at 10:04:54AM +1000, Brad Hards wrote:
> <snip>
> > You need a way to read the initial values of all absolute valuators
> > before you get any events. You may get none if the valuator doesn't
> > ever change.
> My original thinking was "Then why does the valuator matter?", but I thought 
> about it some more. A dial that indicates volume is a good example of one 
> that matters. Too much joystick thinking...

Even on joystick you have the throttle, which doesn't return into center
position automatically.

> > > * finding out about the device identity (EVIOCGNAME and EVIOCGID, maybe
> > > EVIOCGBUS if it works)
> >
> > EVIOCGBUS? What's that?
> Beats me:
> $ grep EVIOCGBUS include/linux/input.h
> #define EVIOCGBUS               _IOR('E', 0x07, short[4])               /* get 
> bus address */

Humm, don't have it in my current version, sorry. Latest version
(without your patches still) attached. (Note the interface version isn't
changed yet in it, but that's a mistake).

> I just want it to work or go away. Anyone owning up to putting it in 
> <linux/input.h>?
> 
> > > * finding out about the device features (EVIOCGBIT and EVIOCGABS)
> >
> > Add EVIOCGKEY, EVIOCGLED and EVIOCGSND to that.
> OK, added to list.
> 
> > > I think that the first element (now ->curr_value) is a different concept
> > > to the programmer compares to the rest of the features identified with
> > > EVIOCGABS.
> >
> > It's also a value you need before you start reading the events, so it's
> > handy there.
> With further thought, I think we keep it in the same ioctl. Delete the comment 
> marks. Might help stop binary breakage too.

Yes. That's right.

-- 
Vojtech Pavlik
SuSE Labs

Re: evdev types

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

On Mon, 22 Apr 2002 18:26, Vojtech Pavlik wrote:
> On Mon, Apr 22, 2002 at 06:19:29PM +1000, Brad Hards wrote:
> > On Mon, 22 Apr 2002 17:22, Vojtech Pavlik wrote:
> > > EVIOCGBUS? What's that?
> >
> > Beats me:
> > $ grep EVIOCGBUS include/linux/input.h
> > #define EVIOCGBUS               _IOR('E', 0x07, short[4])              
> > /* get bus address */
>
> Humm, don't have it in my current version, sorry. Latest version
> (without your patches still) attached. (Note the interface version isn't
> changed yet in it, but that's a mistake).
I'm looking at the 2.4.19-pre7 from Marcelo, which is what I guess most 
developers are working on. The version in 2.4.19-pre7 is

$Id: input.h,v 1.34 2001/05/28 09:06:44 vojtech Exp $

There are a lot of changes to the version in 2.4.19-pre7. Are you feeding 
changes to just CVS, CVS and 2.5 or CVS, 2.4 and 2.5? Is there plans to run a 
backport later, or is 2.4 going to stagnate?

I am just bringing up a box that I can afford to run a risky kernel on (like 
2.5.X-preY :), so I will soon be able to play with various combos of 2.4, 2.5 
and 2.5+CVS.

I can maybe do some patches for the input system for 2.4 if you just need 
grunt work.

Brad

Re: evdev types

[Johann D. <jo...@do...>]

Brad Hards wrote:

> On Mon, 22 Apr 2002 18:26, Vojtech Pavlik wrote:

>>Humm, don't have it in my current version, sorry. Latest version
>>(without your patches still) attached. (Note the interface version isn't
>>changed yet in it, but that's a mistake).
>>
> I'm looking at the 2.4.19-pre7 from Marcelo, which is what I guess most 
> developers are working on. The version in 2.4.19-pre7 is
> 
> $Id: input.h,v 1.34 2001/05/28 09:06:44 vojtech Exp $
> 
> There are a lot of changes to the version in 2.4.19-pre7. Are you feeding 
> changes to just CVS, CVS and 2.5 or CVS, 2.4 and 2.5? Is there plans to run a 
> backport later, or is 2.4 going to stagnate?
> 
> I am just bringing up a box that I can afford to run a risky kernel on (like 
> 2.5.X-preY :), so I will soon be able to play with various combos of 2.4, 2.5 
> and 2.5+CVS.
> 
> I can maybe do some patches for the input system for 2.4 if you just need 
> grunt work.
> 
> Brad
> 
> 
> 
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
> 

I maintain an unofficial iforce patch, which happens to contain a more 
recent version of input.h (1.63). This patch is against 2.4.17, but it 
should apply with very little efforts to the latest 2.4 kernel.
If you want, you can get it here:

http://www.docs.uu.se/~johannd/projects/ff/patch-2.4.17-020408.bz2

-- 
Johann Deneux

Re: evdev types

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

On Mon, Apr 22, 2002 at 06:40:25PM +1000, Brad Hards wrote:
> On Mon, 22 Apr 2002 18:26, Vojtech Pavlik wrote:
> > On Mon, Apr 22, 2002 at 06:19:29PM +1000, Brad Hards wrote:
> > > On Mon, 22 Apr 2002 17:22, Vojtech Pavlik wrote:
> > > > EVIOCGBUS? What's that?
> > >
> > > Beats me:
> > > $ grep EVIOCGBUS include/linux/input.h
> > > #define EVIOCGBUS               _IOR('E', 0x07, short[4])              
> > > /* get bus address */
> >
> > Humm, don't have it in my current version, sorry. Latest version
> > (without your patches still) attached. (Note the interface version isn't
> > changed yet in it, but that's a mistake).
> I'm looking at the 2.4.19-pre7 from Marcelo, which is what I guess most 
> developers are working on. The version in 2.4.19-pre7 is
> 
> $Id: input.h,v 1.34 2001/05/28 09:06:44 vojtech Exp $
> 
> There are a lot of changes to the version in 2.4.19-pre7. Are you feeding 
> changes to just CVS, CVS and 2.5 or CVS, 2.4 and 2.5? Is there plans to run a 
> backport later, or is 2.4 going to stagnate?

The plan is to do a partial backport later, right now the most recent
stuff is in the CVS, being fed into 2.5 from CVS gradually.

> I am just bringing up a box that I can afford to run a risky kernel on (like 
> 2.5.X-preY :), so I will soon be able to play with various combos of 2.4, 2.5 
> and 2.5+CVS.
> 
> I can maybe do some patches for the input system for 2.4 if you just need 
> grunt work.

It would be nice, if you could. I'm rather low on time right now (should
be better after a couple weeks), because of other projects (robotic cup,
wedding, ...).

-- 
Vojtech Pavlik
SuSE Labs