hallo

thanks to all the input, so will give evdev a try and have a look on the devices then. will post back next couple of days if i could make myself happy triggering with multiple devices...

lg marc

IOhannes m zmoelnig wrote:

Georg Holzmann wrote:

...

Hallo!

...

hmm. I have the 'evdev' module loaded, but there is nothing at /dev/input/event*

You need:

mknod /dev/input/event0 c 13 64 mknod /dev/input/event5 c 13 69 ...

or use devfs or udev

mfg.a.d IOhannes

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list

On Apr 8, 2005, at 12:11 PM, august wrote:

...

...

hmm. I have the 'evdev' module loaded, but there is nothing at /dev/input/event*

You need:

mknod /dev/input/event0 c 13 64 mknod /dev/input/event1 c 13 65 mknod /dev/input/event2 c 13 66 mknod /dev/input/event3 c 13 67 mknod /dev/input/event4 c 13 68 mknod /dev/input/event5 c 13 69 ...

thanks....I had the devices listed alright....but the permissions
weren't set. maybe someone else is having the same problem.

doing "chmod +r /dev/input/event*" should do the trick.

now, HID works as expected.....but I only get a resolution from 0-255
on the joystick axis. Is that how it is supposed to be? I thought the resolution was much higher.

best -august.

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

"Supposed to" might be the key word there. That value, AFAIK, depends
on the hardware. I have two joysticks: a Logitech Wingman, which
outputs 0-127, and a Saitek Force 3D, which outputs 0-4091. This is
also why I wrote the [autoscale] object which is used in the
[joystick], [tablet], and [mouse] objects. These objects always output
between 0 and 1, converting the output range of the device, to
resolution between 0 and 1. Then when you write a patch for one
joystick, it'll stick work with other joysticks.

.hc

        "The arc of history bends towards justice."
                                                           Dr.  

Martin Luther King, Jr.

hi david,

Am Samstag 28 Januar 2006 22:29 schrieb David Merrill:

Hello Hans, et al -

I've got another puzzling joystick bug that's showing up today as i play around with the [hid] object in linux (Ubuntu Hoary, kernel 2.6.10-5-686).

I am using a Microsoft "Sidewinder Dual Strike" USB joystick, and after changing the permissions on /dev/input/event* I can successfully peek at the output with evtest, and I can open the device for reading with the [hid] object.

The strange behavior is that when I push the continuous input-degree-of-freedom near one edge or another, a *button-press* registers, but I have not pressed any button (I see this buttonpress in both evtest, and hans' [hid] external). The continuous DOF of this joystick has a springy region near the edges where there is some resistance - and I get the spurious buttonpress when I cross into this region.

what exactly happens? it sends continous data, and a certain point it also submits a button-press? does the continous data continue beyond this point? or is it that there is no continous data at all, and only a button function around that point?

I tried the same joystick in windows, and I don't get the spurious buttonpresses. (I tested it with both the windows control panel "game controllers" interface, and jsarlo's joystick external).

if they always happen at a certain point, they are not spurious. how does the info for that device look, i.e. what axes and buttons does it have (you can query that with the hid object, afaik....)

Has anyone see this kind of behavior? Any ideas why it doesn't show up in Windows, but does in Linux? I'd be really interested to find out how to fix something like this..

thanks, -David Merrill

it may be that the linux event system gets an certain value wrong. at what continuos data/value does that occur? for example, if it occurs at the 255 - 256 crossing, it may be that the 9th bit may be interpreted as a button....

another theory is that the joystick itself send an button event when that boundary is reached, but that windows only shows "regular" buttons, while linux sends whatever comes ....

that signal may be used by software to detect when the controller is about to reach its limit soon, but i really dont know.

greets,

chris

So its either in the Linux input driver or the joystick itself. A lot
of USB HIDs abuse the standard, so it is likely a case of that (yes,
even tho Microsoft was a major author of USB HID). I am curious which
button it shows up as? It might be a "feature", a kind of limit
button.

.hc

On Jan 28, 2006, at 4:29 PM, David Merrill wrote:

Hello Hans, et al -

I've got another puzzling joystick bug that's showing up today as i
play around with the [hid] object in linux (Ubuntu Hoary, kernel
2.6.10-5-686).

I am using a Microsoft "Sidewinder Dual Strike" USB joystick, and
after changing the permissions on /dev/input/event* I can successfully peek at the output with evtest, and I can open the
device for reading with the [hid] object.

The strange behavior is that when I push the continuous
input-degree-of-freedom near one edge or another, a *button-press*
registers, but I have not pressed any button (I see this buttonpress
in both evtest, and hans' [hid] external). The continuous DOF of this
joystick has a springy region near the edges where there is some
resistance - and I get the spurious buttonpress when I cross into this
region.

I tried the same joystick in windows, and I don't get the spurious
buttonpresses. (I tested it with both the windows control panel "game
controllers" interface, and jsarlo's joystick external).

Has anyone see this kind of behavior? Any ideas why it doesn't show up
in Windows, but does in Linux? I'd be really interested to find out
how to fix something like this..

thanks, -David Merrill

Hans-Christoph Steiner wrote:

...

On Apr 8, 2005, at 12:11 PM, august wrote:

...

...

...

hmm. I have the 'evdev' module loaded, but there is nothing at /dev/input/event*

You need:

mknod /dev/input/event0 c 13 64 mknod /dev/input/event1 c 13 65 mknod /dev/input/event2 c 13 66 mknod /dev/input/event3 c 13 67 mknod /dev/input/event4 c 13 68 mknod /dev/input/event5 c 13 69 ...

thanks....I had the devices listed alright....but the permissions
weren't set. maybe someone else is having the same problem.

doing "chmod +r /dev/input/event*" should do the trick.

now, HID works as expected.....but I only get a resolution from
0-255 on the joystick axis. Is that how it is supposed to be? I thought the resolution was much higher.

best -august.

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

"Supposed to" might be the key word there. That value, AFAIK,
depends on the hardware. I have two joysticks: a Logitech Wingman,
which outputs 0-127, and a Saitek Force 3D, which outputs 0-4091.
This is also why I wrote the [autoscale] object which is used in the
[joystick], [tablet], and [mouse] objects. These objects always
output between 0 and 1, converting the output range of the device,
to resolution between 0 and 1. Then when you write a patch for one
joystick, it'll stick work with other joysticks.

.hc

---

---

       "The arc of history bends towards justice."
                                                          Dr.   

Martin Luther King, Jr.

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

                 There is no way to peace, peace is the way.
					        				-A.J. Muste

This is a bit of a quandary. Currently [hid] maps all buttons to
btn_0, btn_1, etc. whether its of the type BTN_MISC, BTN_MOUSE,
BTN_JOYSTICK, BTN_GAMEPAD, BTN_DIGI, or BTN_WHEEL. Axes are treated
similarly. This means patches that are written for a gamepad will also
work for a joystick since all of the names are the same. But this
relies on manufacturer following the USB HID spec, which it seems only
50% do. arg.

So with the Microsoft Sidewinder gamepad, they are way off (its a
gamepad, right?). Btn3 is a BTN_MISC type and ThumbBtn2 is a
BTN_JOYSTICK type. So they are using BTN_MISC and BTN_JOYSTICK when
they should be using only BTN_GAMEPAD.

So my grand plan is to have platform-specific classes which give raw
access to the USB HID info (i.e. [linuxinput], [darwinhid],
[windowshid], and [directinput]). I haven't had a need for those yet,
so I haven't written them. But you are in luck, [linuxevent] still
works, and will give you raw access. But keep in mind, [linuxevent]
works differently than [hid], and is deprecated. (Come to think of it,
I'll probably do [windowshid] and [directinput] soon since there are
fundamental problems with [hid] on Windows which aren't quite resolved
yet.

.hc

On Jan 28, 2006, at 5:33 PM, David Merrill wrote:

Hello again hans & everyone -

I have a little more detail, after some investigation. I found an
article that describes what I think is responsible for the spurious
button presses, at:

http://www.linux-magazine.com/issue/04/LinuxUSB.pdf

So it seems that the sidewinder *does* send out buttonpresses when the
continuous DOF gets near any edge of its range. But when I look at the
output of evtest, I can see that the button codes for the near-edge
condition are actually different than the codes for the thumb buttons

• but I think the [hid] object is mapping the different codes to the

same output, causing the confusing condition that I noticed:

vertical edge condition: evtest says: 259 (Btn3), [hid] is mapping
this to the same output as 291 (TopBtn), sending "key btn_3 1" for
both. horizontal: evtest says: 258 (Btn2), [hid] is mapping this to the
same output as 290 (ThumbBtn2), sending "key btn_2 1" for both.

So is there a way to ask [hid] to not conflate codes 259/291, and
258/290? Or to have [hid] just spit out raw codes, rather than the
processed textual output that I'm seeing?

thanks! -David M.

David Merrill wrote:

...

Hello Hans, et al -

I've got another puzzling joystick bug that's showing up today as i
play around with the [hid] object in linux (Ubuntu Hoary, kernel
2.6.10-5-686).

I am using a Microsoft "Sidewinder Dual Strike" USB joystick, and
after changing the permissions on /dev/input/event* I can successfully peek at the output with evtest, and I can open the
device for reading with the [hid] object.

The strange behavior is that when I push the continuous
input-degree-of-freedom near one edge or another, a *button-press*
registers, but I have not pressed any button (I see this buttonpress
in both evtest, and hans' [hid] external). The continuous DOF of this
joystick has a springy region near the edges where there is some
resistance - and I get the spurious buttonpress when I cross into
this region.

I tried the same joystick in windows, and I don't get the spurious
buttonpresses. (I tested it with both the windows control panel "game
controllers" interface, and jsarlo's joystick external).

Has anyone see this kind of behavior? Any ideas why it doesn't show
up in Windows, but does in Linux? I'd be really interested to find
out how to fix something like this..

thanks, -David Merrill

Hans-Christoph Steiner wrote:

...

On Apr 8, 2005, at 12:11 PM, august wrote:

...

...

...

hmm. I have the 'evdev' module loaded, but there is nothing at /dev/input/event*

You need:

mknod /dev/input/event0 c 13 64 mknod /dev/input/event1 c 13 65 mknod /dev/input/event2 c 13 66 mknod /dev/input/event3 c 13 67 mknod /dev/input/event4 c 13 68 mknod /dev/input/event5 c 13 69 ...

thanks....I had the devices listed alright....but the permissions
weren't set. maybe someone else is having the same problem.

doing "chmod +r /dev/input/event*" should do the trick.

now, HID works as expected.....but I only get a resolution from
0-255 on the joystick axis. Is that how it is supposed to be? I thought
the resolution was much higher.

best -august.

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

"Supposed to" might be the key word there. That value, AFAIK,
depends on the hardware. I have two joysticks: a Logitech Wingman,
which outputs 0-127, and a Saitek Force 3D, which outputs 0-4091.
This is also why I wrote the [autoscale] object which is used in
the [joystick], [tablet], and [mouse] objects. These objects
always output between 0 and 1, converting the output range of the
device, to resolution between 0 and 1. Then when you write a patch
for one joystick, it'll stick work with other joysticks.

.hc

---

---

       "The arc of history bends towards justice."
                                                          Dr.   

Martin Luther King, Jr.

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

"Computer science is no more related to the computer than astronomy is
related to the telescope." -Edsger
Dykstra

On Jan 28, 2006, at 10:57 PM, David Merrill wrote:

Hi Hans -

Hans-Christoph Steiner wrote:

...

This is a bit of a quandary. Currently [hid] maps all buttons to
btn_0, btn_1, etc. whether its of the type BTN_MISC, BTN_MOUSE,
BTN_JOYSTICK, BTN_GAMEPAD, BTN_DIGI, or BTN_WHEEL. Axes are treated
similarly. This means patches that are written for a gamepad will
also work for a joystick since all of the names are the same. But
this relies on manufacturer following the USB HID spec, which it
seems only 50% do. arg.

So with the Microsoft Sidewinder gamepad, they are way off (its a
gamepad, right?). Btn3 is a BTN_MISC type and ThumbBtn2 is a
BTN_JOYSTICK type. So they are using BTN_MISC and BTN_JOYSTICK when
they should be using only BTN_GAMEPAD.

Hmm - I'm not sure if I would call it a gamepad - have a look at what
it looks like: http://www.linux-user.de/ausgabe/2000/11/035-usb-eingabe/sidewinder.jpg It has 2 continuous degrees of freedom, along with all of the buttons.
Maybe it's a gamepad, depending on what the definition of one is! :)

Call it a gamepad, call it a joystick, or call it a "MISC". In any
case, they should have used one button type consistently... I forgot to
mention, these button types that I mentioned are actually the Linux
interpretation of the USB HID spec, mostly its much better. I wonder
what the actual "proper" USB HID values are for all the buttons...

...

So my grand plan is to have platform-specific classes which give raw
access to the USB HID info (i.e. [linuxinput], [darwinhid],
[windowshid], and [directinput]). I haven't had a need for those
yet, so I haven't written them. But you are in luck, [linuxevent]
still works, and will give you raw access. But keep in mind,
[linuxevent] works differently than [hid], and is deprecated. (Come
to think of it, I'll probably do [windowshid] and [directinput] soon
since there are fundamental problems with [hid] on Windows which
aren't quite resolved yet.

Ok, so for the short-term, I should use the linuxevent external then.
I'll have a look at that. So it sounds like it's too much trouble to
unify the [hid] external and have it work the same way everywhere
then? What would the difference be between [windowshid] and
[directinput] ?

[windowshid] would use the DDK HID API, and [directinput] would use the
DirectX DirectInput API. They are quite different. DirectInput is
quite easy, but also quite limited. DDK HID is a standard HID
implementation, very similar to Mac OS X's HID stuff, but they have the
standard Microsoft-style arbitrary restrictions: the mouse and keyboard
are exclusively locked by the OS, so you can open those devices for
reading (i.e. you can't use them at all, except with DirectInput).

.hc

-Dave

...

.hc

On Jan 28, 2006, at 5:33 PM, David Merrill wrote:

...

Hello again hans & everyone -

I have a little more detail, after some investigation. I found an
article that describes what I think is responsible for the spurious
button presses, at:

http://www.linux-magazine.com/issue/04/LinuxUSB.pdf

So it seems that the sidewinder *does* send out buttonpresses when
the continuous DOF gets near any edge of its range. But when I look
at the output of evtest, I can see that the button codes for the
near-edge condition are actually different than the codes for the
thumb buttons - but I think the [hid] object is mapping the
different codes to the same output, causing the confusing condition
that I noticed:

vertical edge condition: evtest says: 259 (Btn3), [hid] is mapping
this to the same output as 291 (TopBtn), sending "key btn_3 1" for
both. horizontal: evtest says: 258 (Btn2), [hid] is mapping this to the
same output as 290 (ThumbBtn2), sending "key btn_2 1" for both.

So is there a way to ask [hid] to not conflate codes 259/291, and
258/290? Or to have [hid] just spit out raw codes, rather than the
processed textual output that I'm seeing?

thanks! -David M.

David Merrill wrote:

...

Hello Hans, et al -

I've got another puzzling joystick bug that's showing up today as i
play around with the [hid] object in linux (Ubuntu Hoary, kernel
2.6.10-5-686).

I am using a Microsoft "Sidewinder Dual Strike" USB joystick, and
after changing the permissions on /dev/input/event* I can successfully peek at the output with evtest, and I can open
the device for reading with the [hid] object.

The strange behavior is that when I push the continuous
input-degree-of-freedom near one edge or another, a *button-press*
registers, but I have not pressed any button (I see this
buttonpress in both evtest, and hans' [hid] external). The
continuous DOF of this joystick has a springy region near the edges
where there is some resistance - and I get the spurious buttonpress
when I cross into this region.

I tried the same joystick in windows, and I don't get the spurious
buttonpresses. (I tested it with both the windows control panel
"game controllers" interface, and jsarlo's joystick external).

Has anyone see this kind of behavior? Any ideas why it doesn't show
up in Windows, but does in Linux? I'd be really interested to find
out how to fix something like this..

thanks, -David Merrill

Hans-Christoph Steiner wrote:

...

On Apr 8, 2005, at 12:11 PM, august wrote:

...

>> hmm. I have the 'evdev' module loaded, but there is nothing at >> /dev/input/event* > > > > You need: > > mknod /dev/input/event0 c 13 64 > mknod /dev/input/event1 c 13 65 > mknod /dev/input/event2 c 13 66 > mknod /dev/input/event3 c 13 67 > mknod /dev/input/event4 c 13 68 > mknod /dev/input/event5 c 13 69 > ...

thanks....I had the devices listed alright....but the permissions
weren't set. maybe someone else is having the same problem.

doing "chmod +r /dev/input/event*" should do the trick.

now, HID works as expected.....but I only get a resolution from
0-255 on the joystick axis. Is that how it is supposed to be? I thought
the resolution was much higher.

best -august.

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

"Supposed to" might be the key word there. That value, AFAIK,
depends on the hardware. I have two joysticks: a Logitech
Wingman, which outputs 0-127, and a Saitek Force 3D, which
outputs 0-4091. This is also why I wrote the [autoscale] object
which is used in the [joystick], [tablet], and [mouse] objects.
These objects always output between 0 and 1, converting the
output range of the device, to resolution between 0 and 1. Then
when you write a patch for one joystick, it'll stick work with
other joysticks.

.hc

---

---

       "The arc of history bends towards justice."
                                                          Dr.   

Martin Luther King, Jr.

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list

---

---

"Computer science is no more related to the computer than astronomy
is related to the telescope." -Edsger
Dykstra

-- MIT Media Lab dmerrill@media.mit.edu

        "The arc of history bends towards justice."
                                        - Dr. Martin Luther King, Jr.

On Jan 29, 2006, at 8:29 AM, Christian Klippel wrote:

hi all,

Am Sonntag 29 Januar 2006 07:20 schrieb Hans-Christoph Steiner:

[...snip...]

...

Call it a gamepad, call it a joystick, or call it a "MISC". In any case, they should have used one button type consistently... I forgot
to mention, these button types that I mentioned are actually the Linux interpretation of the USB HID spec, mostly its much better. I wonder what the actual "proper" USB HID values are for all the buttons...

skimming through the hid usage tables ( http://www.usb.org/developers/devclass_docs/Hut1_12.pdf ) i see that
there are no MISC types anyway, only a reserverd range at the end of most
usage tables.

this is generally the problem with hid names/usages: they thought of a
lot of things, but it can never be complete since there are too many different (new?) devices.

if you look at the usage tables, what would you assign to these "hidden buttons" in david's device? i can see nothing that could fit....

Now that I have dived into the source again, I think this is more of a
question of how the Linux kernel module author mapped things. I am
curious to see how the buttons are mapped in USB HID. The problem
might either be with how Microsoft mapped the buttons to USB HID, or
how the kernel module author mapped the USB HID types to linux/input.h.
(David, maybe you could try the device on Mac OS X with [hid]?)

In linux/input.h, buttons are all laid out by device type, so it would
have been quite handy if the buttons of this device were mapped to
buttons of one type. All joystick buttons for example. That special
button could be a BTN_DEAD:

#define BTN_JOYSTICK 0x120 #define BTN_TRIGGER 0x120 #define BTN_THUMB 0x121 #define BTN_THUMB2 0x122 #define BTN_TOP 0x123 #define BTN_TOP2 0x124 #define BTN_PINKIE 0x125 #define BTN_BASE 0x126 #define BTN_BASE2 0x127 #define BTN_BASE3 0x128 #define BTN_BASE4 0x129 #define BTN_BASE5 0x12a #define BTN_BASE6 0x12b #define BTN_DEAD 0x12f

If the buttons were using USB HID's Button Page, then they would be
sequentially numbered, which is what [hid] does.

But the really great news is that I just found libHID! This sounds
like the perfect solution for the [hid] object in the future. Its a
library for working with HID that bypasses the OS and uses libusb to
access the device, then parses HID itself. Yeee haw! Its even in
Debian. So it looks like this is the future of the [hid] object. Then
there is (hopefully) no need for the [linuxhid], [windowshid], and
[darwinhid] objects, instead there can be [hid], [usb], and then
[linuxinput] and [directinput] for good measure.

http://libhid.alioth.debian.org/

.hc

"Information wants to be free." -Stewart Brand

hello all -

Christian Klippel wrote:

hi all,

Am Sonntag 29 Januar 2006 07:20 schrieb Hans-Christoph Steiner:

[...snip...]

...

Call it a gamepad, call it a joystick, or call it a "MISC". In any case, they should have used one button type consistently... I forgot to mention, these button types that I mentioned are actually the Linux interpretation of the USB HID spec, mostly its much better. I wonder what the actual "proper" USB HID values are for all the buttons...

skimming through the hid usage tables ( http://www.usb.org/developers/devclass_docs/Hut1_12.pdf ) i see that there are no MISC types anyway, only a reserverd range at the end of most usage tables.

this is generally the problem with hid names/usages: they thought of a lot of things, but it can never be complete since there are too many different (new?) devices.

if you look at the usage tables, what would you assign to these "hidden buttons" in david's device? i can see nothing that could fit....

I suspect that they gave it a different type in order to minimize the chance that it would trigger some actual game/application behavior - unless the software developer writing for it *really* knew that they wanted to use that "hidden button" functionality. cheers, -David

greets,

chris

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list