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! :)
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] ? -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