Re: [DIGImend-devel] Some problems with hidrd-convert
Brought to you by:
spb_nick
|
From: Nikolai K. <sp...@gm...> - 2012-06-22 12:21:14
|
Hi Mitch, I'm currently on a sort of vacation, and I hope I'll be able to help you better afterwards. Probably after a week. Still, see my answers below. On 06/22/2012 07:47 AM, Mitch Davis wrote: > I live in China (but I'm not Chinese). I bought a $5 graphics tablet > for Chinese character input, but it doesn't work with Linux. But > usbhid-dump shows very promising results and I think it would be very > easy to get it going. Great! > The device is here on bus 2, device 8: > > [mjd@xiaomao ~]$ lsusb > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub > Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub > Bus 001 Device 003: ID 0402:9665 ALi Corp. > Bus 002 Device 008: ID 08f2:6370 Gotop Information Inc. > Bus 002 Device 009: ID 040b:2013 Weltrend Semiconductor Can you also please show the output of "sudo lsusb -d 08f2:6370 -v"? A photo would also be good to have. > On insertion, these messages appear in /var/log/messages: > > Jun 22 12:09:23 xiaomao kernel: [158014.814575] generic-usb > 0003:08F2:6370.0012: hiddev0,hidraw0: USB HID v1.10 Device [Green Asia > Corp KingSon Touchpad] on usb-0000:00:1d.0-1.2/input0 > > According to evtest, the device does not show up in /dev/input. This is not surprising, considering the report descriptor. > But I get very good results from usbhid-dump: > > Byte 6 seems to go to 28 for a few samples on pen up. > > I can see bytes 1 and 2 changing with one axis, and bytes 3 and 4 > changing with the other. Of each pair of bytes, the first byte is the > LSB and the second is the MSB. Thanks for the detailed dumps! However, they look strange in some regards. First of all, there seems to be no pressure. Is the tablet supposed to support it? Then, button 1 doesn't seem to trigger in the "touching the surface" sample. How did you trigger it in previous samples? Could it be that it triggers only on certain pressure level, which you didn't apply while making the "touching" dump? > Now I have several questions and problems: > > - I'd like to mod an existing kernel driver so it supports this tablet > as well. Can someone recommend the closest one? You can copy the approach used in drivers/hid/hid-uclogic.c - it is hard to do simpler. I can help you with making a report descriptor, if needed. > - This page has a link to both the digimend-users and digimend-devel > mailing lists, but the link to digimend-devel is wrong, because it > points to digimend-users: > > http://sourceforge.net/apps/mediawiki/digimend/index.php?title=DIGImend#Mailing_lists Thanks! It seems David (Favux) has already fixed it. Thanks, David! > Also, I've been trying to run hidrd-convert from the 0.2.0 tarball, > exactly as given in this example, but it segfaults: > > http://sourceforge.net/apps/mediawiki/digimend/index.php?title=Hidrd Wow, this is interesting. Thanks for such a detailed bug report! So far I've failed to reproduce this problem on Debian and Ubuntu. I'll try Fedora next. > [mjd@xiaomao ~]$ cd src/hidrd-0.2.0/ > > [mjd@xiaomao hidrd-0.2.0]$ xxd -r -p<<END | src/hidrd-convert -o spec >> 05 01 09 02 a1 01 09 01 a0 05 09 19 01 29 03 14 >> 25 01 75 01 95 03 81 02 75 05 95 01 81 01 05 01 >> 09 30 09 31 09 38 15 81 25 7f 75 08 95 03 81 06 >> c0 c0 >> END > Segmentation fault > > [mjd@xiaomao hidrd-0.2.0]$ > > Note, for the following, I removed the -Os from "configure", and > recompiled with CFLAGS=-g ./configure --disable-shared. Otherwise > it's too hard to get gdb to pick up the shared libs. You could have used "--enable-debug" configure option, which I added for debugging, instead of modifying the "configure" script. I should think about reducing number of shared libraries, probably. > The segfault is happening because *snk->type->put is being > dereferenced as a function pointer, but put is 0. > > snk in hidrd_snk_put() gets its value from process(), because the > first arg of hidrd_snk_put() is "output". Output is a pointer to the > hidrd_snk variable. I don't know why put is 0. This is indeed strange. > Any ideas why hidrd-convert isn't working for me? I'll try to figure it out. Maybe after vacation. > Anyway, thanks for the digimend project, and any help you're able to give > me. You're welcome :)! Sincerely, Nick |