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.