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