We have bought a USB pedal which we'd like to get working with Gizmod. If I connect the pedal to a Windows computer, load up cmd.exe, and depress the pedal, a "Enter char to delete up to: " message appears within the cmd.exe window (as a side note, I used a built-in keyboard driver to get it working under Windows, no vendor-supplied drivers have been provided). I have also been told (although, have never confirmed) that depressing the pedal whilst plugged into a SuSE machine (version 9.2 or 10.0) caused emacs to 'react'. These things tell me the pedal is working.
However, with Gizmod, we cannot pick up the event from the pedal.
On insertion, dmesg shows:
[ 2370.992000] usb 1-2: new low speed USB device using uhci_hcd and address 4
[ 2371.164000] usb 1-2: configuration #1 chosen from 1 choice
[ 2371.188000] input: Cleware GmbH USB-Keys01 as /class/input/input5
[ 2371.188000] input: USB HID v1.00 Keyboard [Cleware GmbH USB-Keys01] on usb-0000:00:1d.0-2
Standard - Directory [/dev/input]
Mouse - Macintosh mouse button emulation [/dev/input/event0]
Keyboard - AT Translated Set 2 keyboard [/dev/input/event1]
Standard - PC Speaker [/dev/input/event2]
Standard - Cleware GmbH USB-Keys01 [/dev/input/event3]
Standard - HID 062a:0000 [/dev/input/event4]
LIRC device node [/dev/lircd] does not exist -- disabling LIRC support
Loading User Scripts:
CatchAllDebug - CatchAll Event Mapping for Testing
.
.
.
Unable to Open X11 Display [Default] -- Per application mappings will not work!
onEvent: Standard -- /dev/input/event4 | [EV_REL] c: 0x0 Val: -0x8
onEvent: Standard -- /dev/input/event4 | [EV_REL] c: 0x1 Val: 0x3
onEvent: Standard -- /dev/input/event4 | [EV_REL] c: 0x0 Val: -0x8
onEvent: Standard -- /dev/input/event4 | [EV_REL] c: 0x1 Val: 0x2
onEvent: Standard -- /dev/input/event4 | [EV_REL] c: 0x0 Val: -0x9
onEvent: Standard -- /dev/input/event4 | [EV_REL] c: 0x1 Val: 0x3
onEvent: Standard -- /dev/input/event4 | [EV_REL] c: 0x0 Val: -0x7
Depressing the pedal doesn't show anything from gizmod above (those event4 printouts are me moving the USB mouse). I followed the instructions at the wiki regarding creating udev rules in order to grant permissions to the input group to files in /dev/input, but of course I am running gizmod as root above, and so this didn't make any difference.
Here are some general details on the system used:
Distro: Ubuntu Gutsy Gibbon, up to date as of 09/02/07.
Sorry about the hordes of information but I figure any info that can speed up the diagnosis won't harm :-)
I suspect that because Gizmod cannot pick up any events in the first place this may be more likely to be an issue with the kernel configuration rather than Gizmod; if this is the case would you be able to give any pointers?
Having said that, I have also just noticed this thread:
...which concerns Gizmod's device type detection. I see in there that you can force Gizmod to treat a device as a keyboard (presumably via a python script) - not sure if that would be relevant in this case, just an observation.
Thanks,
Jonny
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting... if you cat the device node (in this case "cat /dev/input/event3") and press the pedal do you see any garbage spit out?
If you do, then the kernel is picking up events from the device and gizmod is not detecting them properly. If you do not, then the kernel isn't picking up any events at all, in which case gizmod will never detect them.
Even if it's the latter, there's things to try, but I'll wait to hear from you before suggesting.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
catting the device node you mentioned yields nothing when the pedal is depressed - these reports of the pedal doing something on older SuSE installations did cause me to suspect it was a kernel issue rather than a gizmod issue. I posted an lsmod above... I have no idea what modules would cause gizmod not to pick up these events (if any?).
Jonny
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hrmm... I can't think of any modules that could be conflicting -- it's just a standard HID device. I assume other USB devices work fine?
Is it plugged into a HUB or other USB device? If so, try plugging it directly into the computer's USB ports. If not, try plugging into a HUB :). In my experience with Gizmod I've seen several devices that work / don't work depending on how you plug them in. Looks like some devices have slight flaws in their USB protocol compliance which can be handled better by some USB controllers than others.
Is it plugged into a USB extension? Try removing it if it is. If you have access to another Linux machine, try plugging into that and see if the results are the same.
Thanks,
Tim.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My apologies for taking so long to reply - plugging it into a brand new USB hub brought no joy, but a colleague of mine tested another of these pedals and he gets output when catting the device node - he is running 2.6.24, I am running Ubuntu Gutsy's 2.6.22. When I get the chance I will test the other pedal on this machine and vice-versa and, if necessary, compare kernel .configs :)
Jonny
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I installed the 2.6.24.3 kernel onto the machine and, under the new kernel, catting the device node *does* get stuff through it! Interestingly, even if I don't press the pedal, lots of garbage comes through...
However, Gizmod doesn't display any events, although it does detect the presence of the pedal fine, as before.
So it sounds to me like the protocol the pedal is using is unintelligible to Gizmod or something?
Thanks for your patience,
Jonny
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We have bought a USB pedal which we'd like to get working with Gizmod. If I connect the pedal to a Windows computer, load up cmd.exe, and depress the pedal, a "Enter char to delete up to: " message appears within the cmd.exe window (as a side note, I used a built-in keyboard driver to get it working under Windows, no vendor-supplied drivers have been provided). I have also been told (although, have never confirmed) that depressing the pedal whilst plugged into a SuSE machine (version 9.2 or 10.0) caused emacs to 'react'. These things tell me the pedal is working.
However, with Gizmod, we cannot pick up the event from the pedal.
On insertion, dmesg shows:
[ 2370.992000] usb 1-2: new low speed USB device using uhci_hcd and address 4
[ 2371.164000] usb 1-2: configuration #1 chosen from 1 choice
[ 2371.188000] input: Cleware GmbH USB-Keys01 as /class/input/input5
[ 2371.188000] input: USB HID v1.00 Keyboard [Cleware GmbH USB-Keys01] on usb-0000:00:1d.0-2
Starting gizmod gives us:
root@lap-asus:~# gizmod -g
GizmoDaemon v3:4 -=- (c) 2007, Tim Burrell <tim.burrell@gmail.com>
-----------
Debug Mode Enabled
Registering Devices:
Standard - Directory [/dev/input]
Mouse - Macintosh mouse button emulation [/dev/input/event0]
Keyboard - AT Translated Set 2 keyboard [/dev/input/event1]
Standard - PC Speaker [/dev/input/event2]
Standard - Cleware GmbH USB-Keys01 [/dev/input/event3]
Standard - HID 062a:0000 [/dev/input/event4]
LIRC device node [/dev/lircd] does not exist -- disabling LIRC support
Loading User Scripts:
CatchAllDebug - CatchAll Event Mapping for Testing
.
.
.
Unable to Open X11 Display [Default] -- Per application mappings will not work!
onEvent: Standard -- /dev/input/event4 | [EV_REL] c: 0x0 Val: -0x8
onEvent: Standard -- /dev/input/event4 | [EV_REL] c: 0x1 Val: 0x3
onEvent: Standard -- /dev/input/event4 | [EV_REL] c: 0x0 Val: -0x8
onEvent: Standard -- /dev/input/event4 | [EV_REL] c: 0x1 Val: 0x2
onEvent: Standard -- /dev/input/event4 | [EV_REL] c: 0x0 Val: -0x9
onEvent: Standard -- /dev/input/event4 | [EV_REL] c: 0x1 Val: 0x3
onEvent: Standard -- /dev/input/event4 | [EV_REL] c: 0x0 Val: -0x7
Depressing the pedal doesn't show anything from gizmod above (those event4 printouts are me moving the USB mouse). I followed the instructions at the wiki regarding creating udev rules in order to grant permissions to the input group to files in /dev/input, but of course I am running gizmod as root above, and so this didn't make any difference.
Here are some general details on the system used:
Distro: Ubuntu Gutsy Gibbon, up to date as of 09/02/07.
root@lap-asus:~# cat /proc/bus/input/devices
.
.
.
I: Bus=0003 Vendor=0d50 Product=0141 Version=0100
N: Name="Cleware GmbH USB-Keys01"
P: Phys=usb-0000:00:1d.0-2/input0
S: Sysfs=/class/input/input5
U: Uniq=0008D32
H: Handlers=kbd event3
B: EV=120003
B: KEY=e080ffdf 1cfffff ffffffff fffffffe
B: LED=1f
root@lap-asus:~# cat /proc/bus/input/handlers
N: Number=0 Name=kbd
N: Number=1 Name=mousedev Minor=32
N: Number=2 Name=evdev Minor=64
root@lap-asus:~# uname -a
Linux lap-asus 2.6.22-14-generic #1 SMP Fri Feb 1 04:59:50 UTC 2008 i686 GNU/Linux
root@lap-asus:/etc/udev/rules.d# ls -al /dev/input
total 0
drwxr-xr-x 4 root root 240 2008-02-09 18:49 .
drwxr-xr-x 13 root root 13920 2008-02-09 18:49 ..
drwxr-xr-x 2 root root 100 2008-02-09 18:49 by-id
drwxr-xr-x 2 root root 140 2008-02-09 18:49 by-path
crw-rw---- 1 root input 13, 64 2008-02-09 18:49 event0
crw-rw---- 1 root input 13, 65 2008-02-09 18:49 event1
crw-rw---- 1 root input 13, 66 2008-02-09 18:49 event2
crw-rw---- 1 root input 13, 67 2008-02-09 18:49 event3
crw-rw---- 1 root input 13, 68 2008-02-09 18:49 event4
crw-rw---- 1 root root 13, 63 2008-02-09 18:48 mice
crw-rw---- 1 root root 13, 32 2008-02-09 18:48 mouse0
crw-rw---- 1 root root 13, 33 2008-02-09 18:49 mouse1
root@lap-asus:/etc/udev/rules.d# lsmod
Module Size Used by
ipv6 273892 8
michael_mic 3584 4
arc4 2944 4
ecb 4608 4
blkcipher 7556 1 ecb
ieee80211_crypt_tkip 11776 2
af_packet 24840 4
i915 25856 2
drm 83348 3 i915
rfcomm 42136 2
l2cap 26240 11 rfcomm
bluetooth 57060 4 rfcomm,l2cap
apm 22616 2
ppdev 10244 0
speedstep_centrino 8256 0
cpufreq_userspace 5280 0
cpufreq_powersave 2688 0
cpufreq_stats 7232 0
cpufreq_ondemand 9612 1
freq_table 5792 3 speedstep_centrino,cpufreq_stats,cpufreq_ondemand
cpufreq_conservative 8072 0
sbp2 24072 0
lp 12580 0
loop 19076 0
snd_intel8x0 34972 0
snd_ac97_codec 100644 1 snd_intel8x0
ac97_bus 3200 1 snd_ac97_codec
snd_pcm_oss 44672 0
snd_mixer_oss 17664 1 snd_pcm_oss
snd_pcm 80388 3 snd_intel8x0,snd_ac97_codec,snd_pcm_oss
snd_seq_dummy 4740 0
snd_seq_oss 33152 0
snd_seq_midi 9600 0
pcmcia 41388 0
snd_rawmidi 25728 1 snd_seq_midi
snd_seq_midi_event 8448 2 snd_seq_oss,snd_seq_midi
ipw2100 72240 0
irda 202300 0
ieee80211 35656 1 ipw2100
ieee80211_crypt 7040 2 ieee80211_crypt_tkip,ieee80211
snd_seq 53232 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
snd_timer 24324 2 snd_pcm,snd_seq
snd_seq_device 9228 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq
crc_ccitt 3072 1 irda
yenta_socket 27532 2
rsrc_nonstatic 14080 1 yenta_socket
pcmcia_core 40980 3 pcmcia,yenta_socket,rsrc_nonstatic
parport_pc 37412 1
parport 37448 3 ppdev,lp,parport_pc
snd 54660 10 snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
soundcore 8800 1 snd
pcspkr 4224 0
usbhid 29536 0
hid 28928 1 usbhid
shpchp 34580 0
pci_hotplug 32704 1 shpchp
serio_raw 8068 0
psmouse 39952 0
snd_page_alloc 11400 2 snd_intel8x0,snd_pcm
intel_agp 25620 1
agpgart 35016 3 drm,intel_agp
iTCO_wdt 11940 0
iTCO_vendor_support 4868 1 iTCO_wdt
evdev 11136 2
ext3 133896 1
jbd 60456 1 ext3
mbcache 9732 1 ext3
sg 36764 0
sd_mod 30336 3
8139cp 25088 0
ata_piix 17540 2
8139too 27776 0
mii 6528 2 8139cp,8139too
ohci1394 36528 0
ieee1394 96312 2 sbp2,ohci1394
ata_generic 8452 0
libata 125168 2 ata_piix,ata_generic
scsi_mod 147084 4 sbp2,sg,sd_mod,libata
ehci_hcd 36492 0
uhci_hcd 26640 0
usbcore 138632 4 usbhid,ehci_hcd,uhci_hcd
fuse 47124 1
apparmor 40728 0
commoncap 8320 1 apparmor
Sorry about the hordes of information but I figure any info that can speed up the diagnosis won't harm :-)
I suspect that because Gizmod cannot pick up any events in the first place this may be more likely to be an issue with the kernel configuration rather than Gizmod; if this is the case would you be able to give any pointers?
Having said that, I have also just noticed this thread:
http://sourceforge.net/forum/forum.php?thread_id=1896974&forum_id=467994
...which concerns Gizmod's device type detection. I see in there that you can force Gizmod to treat a device as a keyboard (presumably via a python script) - not sure if that would be relevant in this case, just an observation.
Thanks,
Jonny
Interesting... if you cat the device node (in this case "cat /dev/input/event3") and press the pedal do you see any garbage spit out?
If you do, then the kernel is picking up events from the device and gizmod is not detecting them properly. If you do not, then the kernel isn't picking up any events at all, in which case gizmod will never detect them.
Even if it's the latter, there's things to try, but I'll wait to hear from you before suggesting.
Thanks for the reply Tim.
catting the device node you mentioned yields nothing when the pedal is depressed - these reports of the pedal doing something on older SuSE installations did cause me to suspect it was a kernel issue rather than a gizmod issue. I posted an lsmod above... I have no idea what modules would cause gizmod not to pick up these events (if any?).
Jonny
Hrmm... I can't think of any modules that could be conflicting -- it's just a standard HID device. I assume other USB devices work fine?
Is it plugged into a HUB or other USB device? If so, try plugging it directly into the computer's USB ports. If not, try plugging into a HUB :). In my experience with Gizmod I've seen several devices that work / don't work depending on how you plug them in. Looks like some devices have slight flaws in their USB protocol compliance which can be handled better by some USB controllers than others.
Is it plugged into a USB extension? Try removing it if it is. If you have access to another Linux machine, try plugging into that and see if the results are the same.
Thanks,
Tim.
Tim,
My apologies for taking so long to reply - plugging it into a brand new USB hub brought no joy, but a colleague of mine tested another of these pedals and he gets output when catting the device node - he is running 2.6.24, I am running Ubuntu Gutsy's 2.6.22. When I get the chance I will test the other pedal on this machine and vice-versa and, if necessary, compare kernel .configs :)
Jonny
Finally - some progress!
I installed the 2.6.24.3 kernel onto the machine and, under the new kernel, catting the device node *does* get stuff through it! Interestingly, even if I don't press the pedal, lots of garbage comes through...
However, Gizmod doesn't display any events, although it does detect the presence of the pedal fine, as before.
So it sounds to me like the protocol the pedal is using is unintelligible to Gizmod or something?
Thanks for your patience,
Jonny
Hi Tim,
Have you had a chance to look into this? If I am able to help with sending debug output or whatever, let me know.
Jonny
Same Problem here...the Powermate is sending some garbage output, and pulses if I mute my audio. But nothing happens for powermate input....