3 Mar
2013
3 Mar
'13
1:26 p.m.
Dear all,
I got two cheap drumpads here that are _exactly_ the same, also on the
inside (PCB's have the same revision ID):
http://dx.com/p/portable-roll-up-usb-drum-kit-118841
But they get recognized differently, one as an USB MIDI device and the
other as an USB HID device. And when it gets recognized as a HID device
it's pretty useless because I can't hook it up easily to software that
accepts MIDI input.
This is the "working" drumpad (the one that gets recognized as an USB
MIDI device):
/var/log/syslog:
Mar 3 13:09:40 piertje kernel: [ 864.820341] usb 5-2: new full-speed
USB device number 2 using uhci_hcd
Mar 3 13:09:40 piertje mtp-probe: checking bus 5, device 2:
"/sys/devices/pci0000:00/0000:00:1d.0/usb5/5-2"
Mar 3 13:09:40 piertje mtp-probe: bus: 5, device: 2 was not an MTP device
Mar 3 13:09:40 piertje kernel: [ 865.123664] usbcore: registered new
interface driver snd-usb-audio
Mar 3 13:09:40 piertje pulseaudio[2044]: [pulseaudio]
module-alsa-card.c: Failed to find a working profile.
Mar 3 13:09:40 piertje pulseaudio[2044]: [pulseaudio] module.c: Failed
to load module "module-alsa-card" (argument: "device_id="1"
name="usb-UTECK_MIDI_DRUM-00-DRUM"
card_name="alsa_card.usb-UTECK_MIDI_DRUM-00-DRUM" namereg_fail=false
tsched=yes ignore_dB=no deferred_volume=yes
card_properties="module-udev-detect.discovered=1""): initialization
failed.
lsusb:
Bus 005 Device 002: ID 0218:0001 Hangzhou Worlde
This is the non working drumpad:
/var/log/syslog:
Mar 2 20:49:45 piertje kernel: [ 3040.388297] usb 5-1: new full-speed
USB device number 7 using uhci_hcd
Mar 2 20:49:45 piertje mtp-probe: checking bus 5, device 7:
"/sys/devices/pci0000:00/0000:00:1d.0/usb5/5-1"
Mar 2 20:49:45 piertje mtp-probe: bus: 5, device: 7 was not an MTP device
Mar 2 20:49:45 piertje kernel: [ 3040.602562] generic-usb
0003:1941:8021.0001: hiddev0,hidraw0: USB HID v1.10 Device
[HID 1941:8021] on usb-0000:00:1d.0-1/input0
lsusb:
Bus 005 Device 005: ID 1941:8021 Dream Link WH1080 Weather Station / USB
Missile Launcher
So my questions are, why does this happen? The PCB is extremely simple
and only has one small IC. Is the USB ID determined by this IC? And the
big question, can I trick this non working pad to get recognized as a
valid USB MIDI device? I already looked into this (unbinding, binding,
new_id) but can't get it to work. And I'm 100% sure these pads are
exactly the same.
I could use this: https://code.google.com/p/drumroll/
But I get the idea this is not necessary. drumroll also already consumes
4% CPU on my notebook and I want to use this drumpad with my Raspberry
Pi, besides, it's extra overhead and only runs SUID.
So anybody any idea how I could trick my system in properly recognizing
this non working drumpad? I don't mind hacking kernel modules if that
would be necessary.
Thanks in advance,
Jeremy
3 Mar
3 Mar
4:13 p.m.
On Sun, 03 Mar 2013 13:26:21 +0100
Jeremy Jongepier <jeremy(a)autostatic.com> wrote:
Dear all,
I got two cheap drumpads here that are _exactly_ the same, also on the
inside (PCB's have the same revision ID):
http://dx.com/p/portable-roll-up-usb-drum-kit-118841
But they get recognized differently, one as an USB MIDI device and the
other as an USB HID device. And when it gets recognized as a HID device
it's pretty useless because I can't hook it up easily to software that
accepts MIDI input.
I have no idea what chip it uses, but I have played a bit with Atmel
and ARM chips with built-in USB controllers. The way these work is that
the controller does the basic USB stuff in hardware, but the higher
level things, such as the USB class, are determined by the firmware. So
what you see might be a firmware bug. This sounds likely if that the
hardware is otherwise identical.
So maybe you could find a way to read out the firmware from the good
one, and flash it onto the bad one. Unfortunately, most such chips have
a code read lock bit set, so reading it may be impossible. Anyway, maybe
you could make photos of the PCB, and also see if you can decipher any
text on the chip, and post both? If we could get these to work, I might
buy one myself. For that price... :)
Is the working one otherwise okay? Are the pads pressure sensitive,
i.e. are notes played with different velocity depending depending on
how hard you hit it? (Guess not, but it would be cool)
8:07 p.m.
On 03/03/2013 04:13 PM, Johannes Kroll wrote:
I have no idea what chip it uses, but I have played a
bit with Atmel
and ARM chips with built-in USB controllers. The way these work is that
the controller does the basic USB stuff in hardware, but the higher
level things, such as the USB class, are determined by the firmware. So
what you see might be a firmware bug. This sounds likely if that the
hardware is otherwise identical.
Hello Johannes,
Yes, the hardware is identical, PCB's have the same revision, layout
looks the same, same IC.
So maybe you could find a way to read out the firmware
from the good
one, and flash it onto the bad one. Unfortunately, most such chips have
a code read lock bit set, so reading it may be impossible. Anyway, maybe
you could make photos of the PCB, and also see if you can decipher any
text on the chip, and post both?
The IC's are blank, there's no text on it. I could make photos, good
idea. Will do that shortly.
If we could get these to work, I might
buy one myself. For that price...:)
Afaik these are the cheapest USB controllers available. If you buy them
in bulk they're even cheaper (as low as $10 a piece!).
Is the working one otherwise okay? Are the pads
pressure sensitive,
i.e. are notes played with different velocity depending depending on
how hard you hit it? (Guess not, but it would be cool)
No pressure sensitive pads, just MIDI notes on channel 10. Works quite
nicely. I'm thinking of taking it apart and using it as base for a 6
button footswitch.
Jeremy
8:30 p.m.
On 03/03/2013 04:13 PM, Johannes Kroll wrote:
If we could get these to work, I might
buy one myself. For that price...:)
I'm going to participate in a Linux/JACK based educational music project
and the person coordinating that project just bought a new batch of
these pads for $17.45 a piece. Hopefully these are USB MIDI devices.
http://www.dhgate.com/usb-roll-up-electronic-drum-pad-set-usb-drum/p-ff8080…
Regards,
Jeremy
9 Mar
9 Mar
9:31 p.m.
On 03/03/2013 04:13 PM, Johannes Kroll wrote:
So maybe you could find a way to read out the firmware
from the good
one, and flash it onto the bad one. Unfortunately, most such chips have
a code read lock bit set, so reading it may be impossible. Anyway, maybe
you could make photos of the PCB, and also see if you can decipher any
text on the chip, and post both? If we could get these to work, I might
buy one myself. For that price...:)
Here are some pics:
http://downloads.autostatic.com/temp/hid-device.jpg (picture of PCB of
drum pad recognized as USB hid device)
http://downloads.autostatic.com/temp/midi-device.jpg (picture of PCB of
drum pad recognized as USB midi device)
Regards,
Jeremy
3 Mar
3 Mar
4:32 p.m.
On Sun, 03 Mar 2013 13:26:21 +0100
Jeremy Jongepier <jeremy(a)autostatic.com> wrote:
This is the non working drumpad:
/var/log/syslog:
Mar 2 20:49:45 piertje kernel: [ 3040.388297] usb 5-1: new full-speed
USB device number 7 using uhci_hcd
Mar 2 20:49:45 piertje mtp-probe: checking bus 5, device 7:
"/sys/devices/pci0000:00/0000:00:1d.0/usb5/5-1"
Mar 2 20:49:45 piertje mtp-probe: bus: 5, device: 7 was not an MTP device
Mar 2 20:49:45 piertje kernel: [ 3040.602562] generic-usb
0003:1941:8021.0001: hiddev0,hidraw0: USB HID v1.10 Device
[HID 1941:8021] on usb-0000:00:1d.0-1/input0
lsusb:
Bus 005 Device 005: ID 1941:8021 Dream Link WH1080 Weather Station / USB
Missile Launcher
Also, can you test if this one works with the windows software?
8:08 p.m.
On 03/03/2013 04:32 PM, Johannes Kroll wrote:
Also, can you test if this one works with the windows
software?
Then I'd have to take it with me to my work as I don't have a Windows
machine at home. But from what I've read, yes it apparently works with
the software so I don't think it's a firmware bug.
Jeremy
4:51 p.m.
On Sun, March 3, 2013 4:26 am, Jeremy Jongepier wrote:
Dear all,
I got two cheap drumpads here that are _exactly_ the same, also on the
inside (PCB's have the same revision ID):
http://dx.com/p/portable-roll-up-usb-drum-kit-118841
But they get recognized differently, one as an USB MIDI device and the
other as an USB HID device. And when it gets recognized as a HID device
it's pretty useless because I can't hook it up easily to software that
accepts MIDI input.
Dumb question :) I am not sure from the original post, but are these
outputs from plugging only one unit in at a time, or booting with both
plugged in? That is if there is only one unit plugged in, does the bad
unit then work, or is the bad unit always bad? If so, with the bad unit
plugged in, is it possible to manually load the correct kernel modules and
have them recognize it?
--
Len Ovens
www.OvenWerks.net
8:13 p.m.
On 03/03/2013 04:51 PM, Len Ovens wrote:
Dumb question:) I am not sure from the original post,
but are these
outputs from plugging only one unit in at a time, or booting with both
plugged in?
Hello Len,
Haven't tried booting with the pads plugged in, don't think it makes a
difference though but I'll give it a go.
That is if there is only one unit plugged in, does the bad
unit then work, or is the bad unit always bad?
Bad unit is always bad because of the different USB ID.
If so, with the bad unit
plugged in, is it possible to manually load the
correct kernel modules and
have them recognize it?
Yes you can load the correct kernel module by using modalias for
example. But the module (snd-usb-audio) doesn't recognize the controller
no matter what I try (using new_id for example:
http://lwn.net/Articles/160944/).
Jeremy
4 Mar
4 Mar
9:11 p.m.
Quoting Jeremy Jongepier <jeremy(a)autostatic.com>om>:
This is the non working drumpad:
/var/log/syslog:
Mar 2 20:49:45 piertje kernel: [ 3040.388297] usb 5-1: new full-speed
USB device number 7 using uhci_hcd
lsusb:
Bus 005 Device 005: ID 1941:8021 Dream Link WH1080 Weather Station /
USB Missile Launcher
Dude, are you blind? The non working pad is a Missile Launcher. Do not
- I repeat, NOT - hit on it with anything...
- Peder
9 Mar
9 Mar
10:05 p.m.
Governments using linux powered missile launchers? Seems legit.
'Missile Linux - the distro that packs a boom!'
Andrew.
On Mon, Mar 4, 2013 at 8:11 PM, Peder Hedlund <peder(a)musikhuset.org> wrote:
Quoting Jeremy Jongepier
<jeremy(a)autostatic.com>om>:
This is the non working drumpad:
/var/log/syslog:
Mar 2 20:49:45 piertje kernel: [ 3040.388297] usb 5-1: new full-speed
USB device number 7 using uhci_hcd
lsusb:
Bus 005 Device 005: ID 1941:8021 Dream Link WH1080 Weather Station /
USB Missile Launcher
Dude, are you blind? The non working pad is a Missile Launcher. Do not - I
repeat, NOT - hit on it with anything...
- Peder
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user 
10 Mar
10 Mar
10:54 a.m.
On Monday 04 March 2013 21:11:51 Peder Hedlund wrote:
Quoting Jeremy Jongepier
<jeremy(a)autostatic.com>om>:
Indeed, it looks frightening
http://matthias.vallentin.net/blog/2007/04/writing-a-linux-kernel-driver-fo…
an-unknown-usb-device/
Now seriously. The drums manufactured by Konix include several references that
look the same but are different products
W750 - USB Rollup drum. Includes windows-only software.
W751M - USB Game drum kit. This one is Mac only.
MD1001 - Portable MIDI Drum. USB class compliant without additional driver.
Compatible with any major sequencer software.
http://www.konixtech.com/product/&pmcId=101e7168-9c15-4b90-88c3-
fc08b9baa03a.html
Regards,
Pedro
This is the non working drumpad:
/var/log/syslog:
Mar 2 20:49:45 piertje kernel: [ 3040.388297] usb 5-1: new full-speed
USB device number 7 using uhci_hcd
lsusb:
Bus 005 Device 005: ID 1941:8021 Dream Link WH1080 Weather Station /
USB Missile Launcher
Dude, are you blind? The non working pad is a Missile Launcher. Do not
- I repeat, NOT - hit on it with anything...
9 Mar
9 Mar
9:35 p.m.
Attached the output of lsusb -vvv of both devices. hid-device.txt is the
output of the drum pad that gets recognized as a USB hid device and
midi-device.txt is the output of the pad that gets recognized as a USB
midi device.
Regards,
Jeremy
On 03/03/2013 01:26 PM, Jeremy Jongepier wrote:
Dear all,
I got two cheap drumpads here that are _exactly_ the same, also on the
inside (PCB's have the same revision ID):
http://dx.com/p/portable-roll-up-usb-drum-kit-118841
But they get recognized differently, one as an USB MIDI device and the
other as an USB HID device. And when it gets recognized as a HID device
it's pretty useless because I can't hook it up easily to software that
accepts MIDI input.
This is the "working" drumpad (the one that gets recognized as an USB
MIDI device):
/var/log/syslog:
Mar 3 13:09:40 piertje kernel: [ 864.820341] usb 5-2: new full-speed
USB device number 2 using uhci_hcd
Mar 3 13:09:40 piertje mtp-probe: checking bus 5, device 2:
"/sys/devices/pci0000:00/0000:00:1d.0/usb5/5-2"
Mar 3 13:09:40 piertje mtp-probe: bus: 5, device: 2 was not an MTP device
Mar 3 13:09:40 piertje kernel: [ 865.123664] usbcore: registered new
interface driver snd-usb-audio
Mar 3 13:09:40 piertje pulseaudio[2044]: [pulseaudio]
module-alsa-card.c: Failed to find a working profile.
Mar 3 13:09:40 piertje pulseaudio[2044]: [pulseaudio] module.c: Failed
to load module "module-alsa-card" (argument: "device_id="1"
name="usb-UTECK_MIDI_DRUM-00-DRUM"
card_name="alsa_card.usb-UTECK_MIDI_DRUM-00-DRUM" namereg_fail=false
tsched=yes ignore_dB=no deferred_volume=yes
card_properties="module-udev-detect.discovered=1""): initialization
failed.
lsusb:
Bus 005 Device 002: ID 0218:0001 Hangzhou Worlde
This is the non working drumpad:
/var/log/syslog:
Mar 2 20:49:45 piertje kernel: [ 3040.388297] usb 5-1: new full-speed
USB device number 7 using uhci_hcd
Mar 2 20:49:45 piertje mtp-probe: checking bus 5, device 7:
"/sys/devices/pci0000:00/0000:00:1d.0/usb5/5-1"
Mar 2 20:49:45 piertje mtp-probe: bus: 5, device: 7 was not an MTP device
Mar 2 20:49:45 piertje kernel: [ 3040.602562] generic-usb
0003:1941:8021.0001: hiddev0,hidraw0: USB HID v1.10 Device
[HID 1941:8021] on usb-0000:00:1d.0-1/input0
lsusb:
Bus 005 Device 005: ID 1941:8021 Dream Link WH1080 Weather Station / USB
Missile Launcher
So my questions are, why does this happen? The PCB is extremely simple
and only has one small IC. Is the USB ID determined by this IC? And the
big question, can I trick this non working pad to get recognized as a
valid USB MIDI device? I already looked into this (unbinding, binding,
new_id) but can't get it to work. And I'm 100% sure these pads are
exactly the same.
I could use this: https://code.google.com/p/drumroll/
But I get the idea this is not necessary. drumroll also already consumes
4% CPU on my notebook and I want to use this drumpad with my Raspberry
Pi, besides, it's extra overhead and only runs SUID.
So anybody any idea how I could trick my system in properly recognizing
this non working drumpad? I don't mind hacking kernel modules if that
would be necessary.
Thanks in advance,
Jeremy
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
9:41 p.m.
I'm still looking for a way to work around the 'faulty' drum pad getting
recognized as a USB hid device. What's the best way to do this? Is it
possible? How does the device gets a driver assigned? Where can I find
which USB device ID gets assigned which driver?
Thanks in advance,
Jeremy
On 03/03/2013 01:26 PM, Jeremy Jongepier wrote:
Dear all,
I got two cheap drumpads here that are _exactly_ the same, also on the
inside (PCB's have the same revision ID):
http://dx.com/p/portable-roll-up-usb-drum-kit-118841
But they get recognized differently, one as an USB MIDI device and the
other as an USB HID device. And when it gets recognized as a HID device
it's pretty useless because I can't hook it up easily to software that
accepts MIDI input.
This is the "working" drumpad (the one that gets recognized as an USB
MIDI device):
/var/log/syslog:
Mar 3 13:09:40 piertje kernel: [ 864.820341] usb 5-2: new full-speed
USB device number 2 using uhci_hcd
Mar 3 13:09:40 piertje mtp-probe: checking bus 5, device 2:
"/sys/devices/pci0000:00/0000:00:1d.0/usb5/5-2"
Mar 3 13:09:40 piertje mtp-probe: bus: 5, device: 2 was not an MTP device
Mar 3 13:09:40 piertje kernel: [ 865.123664] usbcore: registered new
interface driver snd-usb-audio
Mar 3 13:09:40 piertje pulseaudio[2044]: [pulseaudio]
module-alsa-card.c: Failed to find a working profile.
Mar 3 13:09:40 piertje pulseaudio[2044]: [pulseaudio] module.c: Failed
to load module "module-alsa-card" (argument: "device_id="1"
name="usb-UTECK_MIDI_DRUM-00-DRUM"
card_name="alsa_card.usb-UTECK_MIDI_DRUM-00-DRUM" namereg_fail=false
tsched=yes ignore_dB=no deferred_volume=yes
card_properties="module-udev-detect.discovered=1""): initialization
failed.
lsusb:
Bus 005 Device 002: ID 0218:0001 Hangzhou Worlde
This is the non working drumpad:
/var/log/syslog:
Mar 2 20:49:45 piertje kernel: [ 3040.388297] usb 5-1: new full-speed
USB device number 7 using uhci_hcd
Mar 2 20:49:45 piertje mtp-probe: checking bus 5, device 7:
"/sys/devices/pci0000:00/0000:00:1d.0/usb5/5-1"
Mar 2 20:49:45 piertje mtp-probe: bus: 5, device: 7 was not an MTP device
Mar 2 20:49:45 piertje kernel: [ 3040.602562] generic-usb
0003:1941:8021.0001: hiddev0,hidraw0: USB HID v1.10 Device
[HID 1941:8021] on usb-0000:00:1d.0-1/input0
lsusb:
Bus 005 Device 005: ID 1941:8021 Dream Link WH1080 Weather Station / USB
Missile Launcher
So my questions are, why does this happen? The PCB is extremely simple
and only has one small IC. Is the USB ID determined by this IC? And the
big question, can I trick this non working pad to get recognized as a
valid USB MIDI device? I already looked into this (unbinding, binding,
new_id) but can't get it to work. And I'm 100% sure these pads are
exactly the same.
I could use this: https://code.google.com/p/drumroll/
But I get the idea this is not necessary. drumroll also already consumes
4% CPU on my notebook and I want to use this drumpad with my Raspberry
Pi, besides, it's extra overhead and only runs SUID.
So anybody any idea how I could trick my system in properly recognizing
this non working drumpad? I don't mind hacking kernel modules if that
would be necessary.
Thanks in advance,
Jeremy
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
10:08 p.m.
On Sat, Mar 9, 2013 at 12:41 PM, Jeremy Jongepier <jeremy(a)autostatic.com> wrote:
I'm still looking for a way to work around the
'faulty' drum pad getting
recognized as a USB hid device. What's the best way to do this? Is it
possible? How does the device gets a driver assigned? Where can I find which
USB device ID gets assigned which driver?
If I were to guess, I would say that the firmware in the 'faulty' drum
pad is corrupt or just plain wrong. It appears to be an obscure
Chinese manufacturer, so I think there's little hope of getting the
information (firmware) that you need. From the pictures you supplied,
it appears the 'hid' device has been refurbished or something. The
assembly quality isn't as good as the 'midi' device.
Thus the question, "does the 'faulty' one work in Windows?" Right
now, all signs point to "you have a defect." If it's defective in
Windows, too... then case closed.
I think your best bet is to order a replacement.
-gabriel
10:21 p.m.
On 03/09/2013 10:08 PM, Gabriel Beddingfield wrote:
If I were to guess, I would say that the firmware in
the 'faulty' drum
pad is corrupt or just plain wrong. It appears to be an obscure
Chinese manufacturer, so I think there's little hope of getting the
information (firmware) that you need. From the pictures you supplied,
it appears the 'hid' device has been refurbished or something. The
assembly quality isn't as good as the 'midi' device.
Thus the question, "does the 'faulty' one work in Windows?" Right
now, all signs point to "you have a defect." If it's defective in
Windows, too... then case closed.
I think your best bet is to order a replacement.
-gabriel
Hello Gabriel,
I'm almost a 100% sure this is not a defective drum pad. People even
wrote software (or attempted to) for it to make it work with Linux:
https://code.google.com/p/drumroll/
http://www.organicdesign.co.nz/USB_human_interface_devices_with_Linux
http://ezod.livejournal.com/25271.html
I agree that the hid device looks refurbished and I now also noticed the
hid device has the resistor R1 while the midi device lacks this resistor.
I'll also test with Windows this week and report back.
Jeremy
10:51 p.m.
On Sat, 2013-03-09 at 22:21 +0100, Jeremy Jongepier wrote:
I agree that the hid device looks refurbished and I
now also noticed the
hid device has the resistor R1 while the midi device lacks this resistor.
There's nothing at the other side of the board? Perhaps a bridge?
And the existing resistor isn't a _zero_ ohm "resistor"? Not a joke!
10 Mar
10 Mar
12:32 p.m.
Jeremy Jongepier wrote:
On 03/09/2013 10:08 PM, Gabriel Beddingfield wrote:
> If I were to guess, I would say that the firmware in the 'faulty' drum
> pad is corrupt or just plain wrong.
No, it just sends HID reports, and requires a special driver that converts
these into MIDI messages.
Does this driver work?
Regards,
Clemens
3:36 p.m.
On 03/10/2013 12:31 PM, Clemens Ladisch wrote:
Does this driver work?
Hello Clemens,
Yes it does. But it consumes way too much CPU and since I want to use
this drumpad with a Raspberry Pi drumroll isn't really an option.
Haven't tried it on the RPi yet though.
Jeremy
17 Mar
17 Mar
5:20 p.m.
Jeremy Jongepier wrote:
On 03/10/2013 12:31 PM, Clemens Ladisch wrote:
This is a problem with the firmware, not with the driver.
You could try getting docs for reading/writing the chip's firmware.
Regards,
Clemens
Does this driver work?
Yes it does. But it consumes way too much CPU
18 Mar
18 Mar
9:41 a.m.
On 03/17/2013 05:19 PM, Clemens Ladisch wrote:
Jeremy Jongepier wrote:
Hello Clemens,
Thanks for the pointers. It's a pretty generic chip used in a lot of
different devices so there should be some documentation out there.
Jeremy
On 03/10/2013 12:31 PM, Clemens Ladisch wrote:
This is a problem with the firmware, not with the driver.
You could try getting docs for reading/writing the chip's firmware.
Regards,
Clemens Does this driver work?
Yes it does. But it consumes way too much CPU
4271
days inactive
4286
days old
linux-audio-user@lists.linuxaudio.org
20 comments
9 participants
participants (9)
-
Andrew C -
Clemens Ladisch -
Gabriel Beddingfield -
Jeremy Jongepier -
Johannes Kroll -
Len Ovens -
Peder Hedlund -
Pedro Lopez-Cabanillas -
Ralf Mardorf