Thread: [DIGImend-devel] Some problems with hidrd-convert
Brought to you by:
spb_nick
Menu
▾
▴
digimend-devel
|
From: Mitch D. <mjd...@af...> - 2012-06-22 05:13:22
|
Hello, 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. 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 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. But I get very good results from usbhid-dump: ## The descriptor: [root@xiaomao mjd]# usbhid-dump 2 8 000:DESCRIPTOR 1340338136.139784 05 0D 09 01 A1 01 85 01 A1 00 09 00 15 00 26 FF 00 75 08 95 07 81 02 C0 09 00 85 02 95 07 B1 02 C0 ## The stream: [root@xiaomao mjd]# usbhid-dump -e stream 2 8 ## Pressing and releasing button 1 000:STREAM 1340338152.436599 01 1A 28 10 30 21 1A 00 000:STREAM 1340338152.564446 01 1A 28 10 30 20 1A 00 ## Pressing and releasing button 2 000:STREAM 1340338154.460639 01 1A 28 10 30 24 1A 00 000:STREAM 1340338154.620563 01 1A 28 10 30 20 1A 00 ## Pressing and releasing button 3 000:STREAM 1340338156.068511 01 1A 28 10 30 22 1A 00 000:STREAM 1340338156.148547 01 1A 28 10 30 20 1A 00 ## Seems that byte 6 contains button state ## Touching the surface of the pad: 000:STREAM 1340338161.220574 01 B4 2A 29 33 20 1A 00 000:STREAM 1340338161.228565 01 B4 2A 29 33 20 1A 00 000:STREAM 1340338161.236552 01 B4 2A 29 33 20 1A 00 000:STREAM 1340338161.244576 01 B4 2A 29 33 20 1A 00 000:STREAM 1340338161.252583 01 B4 2A 29 33 20 1A 00 000:STREAM 1340338161.260572 01 B4 2A 29 33 20 1A 00 000:STREAM 1340338161.268543 01 B4 2A 29 33 20 1A 00 000:STREAM 1340338161.276549 01 B4 2A 29 33 20 1A 00 000:STREAM 1340338161.284588 01 B4 2A 29 33 20 1A 00 000:STREAM 1340338161.292592 01 B4 2A 29 33 20 1A 00 000:STREAM 1340338161.300578 01 B4 2A 29 33 20 1A 00 000:STREAM 1340338161.308593 01 AD 2A 2C 33 20 1A 00 000:STREAM 1340338161.316532 01 D2 2A 50 33 20 1A 00 000:STREAM 1340338161.324527 01 C6 2A 54 33 20 1A 00 000:STREAM 1340338161.332549 01 E9 2A 59 33 20 1A 00 000:STREAM 1340338161.340621 01 13 2B 5E 33 20 1A 00 000:STREAM 1340338161.348582 01 07 2B 43 33 20 1A 00 000:STREAM 1340338161.356605 01 31 2B 47 33 20 1A 00 000:STREAM 1340338161.364586 01 2A 2B 49 33 20 1A 00 000:STREAM 1340338161.372536 01 2A 2B 49 33 20 1A 00 000:STREAM 1340338161.380554 01 33 2B 49 33 20 1A 00 000:STREAM 1340338161.388587 01 06 2B 48 33 20 1A 00 000:STREAM 1340338161.396574 01 1E 2B 45 33 20 1A 00 000:STREAM 1340338161.404518 01 F6 2A 40 33 20 1A 00 000:STREAM 1340338161.412579 01 CE 2A 5C 33 20 1A 00 000:STREAM 1340338161.420522 01 DA 2A 58 33 20 1A 00 000:STREAM 1340338161.428591 01 B5 2A 54 33 20 1A 00 000:STREAM 1340338161.436540 01 BD 2A 53 33 20 1A 00 000:STREAM 1340338161.444613 01 B8 2A 52 33 20 1A 00 000:STREAM 1340338161.452578 01 B8 2A 52 33 20 1A 00 000:STREAM 1340338161.460577 01 B2 2A 51 33 20 1A 00 000:STREAM 1340338161.468534 01 A9 2A 51 33 20 1A 00 000:STREAM 1340338161.476551 01 DC 2A 52 33 20 1A 00 000:STREAM 1340338161.484575 01 C0 2A 53 33 20 1A 00 000:STREAM 1340338161.492588 01 F1 2A 56 33 20 1A 00 000:STREAM 1340338161.500564 01 E2 2A 5A 33 20 1A 00 000:STREAM 1340338161.508534 01 E2 2A 5A 33 20 1A 00 000:STREAM 1340338161.516586 01 1A 28 10 30 28 1A 00 000:STREAM 1340338161.524581 01 1A 28 10 30 28 1A 00 000:STREAM 1340338161.532615 01 1A 28 10 30 28 1A 00 000:STREAM 1340338161.540540 01 1A 28 10 30 28 1A 00 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. 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? - 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 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 [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. [mjd@xiaomao hidrd-0.2.0]$ cat mouse-hid.txt 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 [mjd@xiaomao hidrd-0.2.0]$ xxd -r -p < mouse-hid.txt > mouse-hid.bin [mjd@xiaomao hidrd-0.2.0]$ file src/hidrd-convert src/hidrd-convert: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped [mjd@xiaomao hidrd-0.2.0]$ ldd src/hidrd-convert linux-vdso.so.1 => (0x00007fffdf4b2000) libxml2.so.2 => /usr/lib64/libxml2.so.2 (0x00000035bbc00000) libz.so.1 => /lib64/libz.so.1 (0x00000035b6800000) libm.so.6 => /lib64/libm.so.6 (0x00000035b6000000) libc.so.6 => /lib64/libc.so.6 (0x00000035b5000000) libdl.so.2 => /lib64/libdl.so.2 (0x00000035b5800000) /lib64/ld-linux-x86-64.so.2 (0x00000035b4c00000) [mjd@xiaomao hidrd-0.2.0]$ gdb src/hidrd-convert GNU gdb (GDB) Fedora (7.3.50.20110722-13.fc16) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/mjd/src/hidrd-0.2.0/src/hidrd-convert...done. (gdb) (gdb) set args -o spec mouse-hid.bin (gdb) run Starting program: /home/mjd/src/hidrd-0.2.0/src/hidrd-convert -o spec mouse-hid.bin &hidrd_spec=0x415c40 Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00000000004057ba in hidrd_snk_put (snk=0x42a120, item=0x42a010 "\005\001\t\002\241\001\t\001\240\005\t\031\001)\003\024%\001u\001\225\003\201\002u\005\225\001\201\001\005\001\t0\t1\t8\025\201%\177u\b\225\003\201\006\300\300") at inst.c:358 #2 0x0000000000402a91 in process (input_name=0x7fffffffe3cd "mouse-hid.bin", input_fmt_name=0x415765 "natv", input_options=0x41527c "", output_name=0x415763 "-", output_fmt_name=0x7fffffffe3c8 "spec", output_options=0x41527c "") at hidrd-convert.c:345 #3 0x000000000040302f in main (argc=4, argv=0x7fffffffe068) at hidrd-convert.c:570 (gdb) up #1 0x00000000004057ba in hidrd_snk_put (snk=0x42a120, item=0x42a010 "\005\001\t\002\241\001\t\001\240\005\t\031\001)\003\024%\001u\001\225\003\201\002u\005\225\001\201\001\005\001\t0\t1\t8\025\201%\177u\b\225\003\201\006\300\300") at inst.c:358 358 return (*snk->type->put)(snk, item); (gdb) p snk $1 = (hidrd_snk *) 0x42a120 (gdb) ptype *snk type = struct hidrd_snk { const hidrd_snk_type *type; void **pbuf; size_t *psize; } (gdb) p snk->type $2 = (const hidrd_snk_type *) 0x429720 (gdb) p *snk->type $3 = {size = 0, initv = 0, init_opts = 0, opts_spec = 0x0, valid = 0, errmsg = 0, put = 0, flush = 0, clnp = 0} (gdb) 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. Any ideas why hidrd-convert isn't working for me? Anyway, thanks for the digimend project, and any help you're able to give me. Mitch. |
|
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 |
|
From: Nikolai K. <sp...@gm...> - 2012-06-22 13:26:36
|
On 06/22/2012 03:21 PM, Nikolai Kondrashov wrote: > 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. The issue didn't reproduce on Fedora 17 either. Which release do you use? Thanks. Sincerely, Nick |
|
From: Mitch D. <mjd...@af...> - 2012-06-22 14:52:01
|
On Fri, Jun 22, 2012 at 8:21 PM, Nikolai Kondrashov <sp...@gm...> wrote: > > I'm currently on a sort of vacation Haha, let's wait until you're back. Vacations are sacred :-) Mitch. |
|
From: Mitch D. <mjd...@af...> - 2012-06-25 03:49:37
|
Hello Nick and others!
On Fri, Jun 22, 2012 at 8:21 PM, Nikolai Kondrashov <sp...@gm...> wrote:
>
> Can you also please show the output of "sudo lsusb -d 08f2:6370 -v"?
[root@xiaomao mjd]# lsusb -d 08f2:6370 -v
Bus 002 Device 014: ID 08f2:6370 Gotop Information Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x08f2 Gotop Information Inc.
idProduct 0x6370
bcdDevice 0.01
iManufacturer 1 Green Asia Corp
iProduct 2 KingSon Touchpad
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 4 ?
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 300mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 2 Mouse
iInterface 4 ?
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 33
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Device Status: 0x0000
(Bus Powered)
Curiously enough, Gotop Information Inc. has a VID of 0x08f2, but
the apparent manufacturer, "Green Asia Corp" also has their own VID
(0e8f, "GreenAsia Inc.")
> A photo would also be good to have.
This is the product:
http://www.hqbuy.com/UniscomCR300-DWB151554ASS.html
Curiously but irrelevantly, the HQ in the name of that company stands
for Huaqiang, the world's largest electronics market, here in Shenzhen
China. That's where I live :-)
>> On insertion, these messages appear in /var/log/messages:
>>
> 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?
For $5? LOL-with-ponies.
This device is a wrapper around a resistive touchpad almost identical
to that found in a Nintendo DS. You touch the screen, it shorts two
layers together, and you get X/Y samples. I have made similar devices
myself:
http://capnstech.blogspot.com/2010/02/computer-assisted-chinese-part-vi.html
http://capnstech.blogspot.com/2010/02/computer-assisted-chinese-part-vii.html
http://capnstech.blogspot.com/2010/07/touchscreen-update.html
There's no barrel buttons, no pen switches, no nothing. Just the
sensor and three buttons.
> 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?
The nibble that shows the buttons is completely independent of the
nibbles for the position.
I found this C struct works ok:
struct report {
// Byte 0
unsigned char reportid;
// Bytes 1-2
unsigned int x:11 __attribute__ ((packed));
unsigned char fixed1:5 __attribute__ ((packed));
// Bytes 3-4
unsigned int y:11 __attribute__ ((packed));
unsigned char fixed2:5 __attribute__ ((packed));
// Byte 5
unsigned buttons:3 __attribute__ ((packed));
unsigned char penup:1 __attribute__ ((packed));
unsigned char fixed3:4 __attribute__ ((packed));
// Bytes 6-7
unsigned char fixed4;
unsigned char fixed5;
};
These fields always have fixed values: fixed1 == 5, fixed2 == 6,
fixed3 == 2, fixed4 == 0x1a, fixed5 == 0
> I can help you with making a report descriptor, if needed.
Ok. First I will try the pseudo-mouse descriptor I used with my USB
device, because I know it'll show up and be noticed by X. Then I
might try a descriptor with a little more finesse, and I might need
your help for this.
The descriptor for my USB device describes a 1-button absolute
coordinate mouse. When the touchpad is touched, it appears that not
only is the pointer moving, but button 1 has been pressed. When
samples stop, I report that button 1 has been released. So there's no
real button one, just a faked button one. I think this approach is
necessary for a device where there is no pressure sensitivity and no
pen switch. Sounds klunky, but it works fine for the app I want to
use the tablet for. I'm interested in your thoughts on whether this
is good or bad.
Note the X and Y values are uncalibrated. They are 11-bit unsigned
values, but they don't span 0-2047. There needs to be a calibration
phase, and a coordinate transformation step to map the returned values
to full screen. I've done this in the past (in the USB device) but I
haven't done it in the kernel. Is a transformation like this done
elsewhere in the kernel? How does one tell the driver the values of
the calibration constants? (Hopefully it can be done live, rather
than at module load time. Is there an example somewhere?)
> You can copy the approach used in drivers/hid/hid-uclogic.c - it is hard to do simpler.
Thanks, I understand that file. The Waltop one is also interesting,
because it modifies the USB report. I may have to do something like
that.
Ok, I copied the uclogic file, and modified it. The module is
registering ok, but a printk in my report fixup function never fires.
My guess is that this tablet needs to also be registered in the
hid_have_special_driver[] table in hid-core.c, or be registered at
run-time. I'm imagining there would be a call to store_new_id(),
either from my code, or from some command-line interface, but I can't
work out how to do it. Any pointers?
>> Also, I've been trying to run hidrd-convert from the 0.2.0 tarball,
>> exactly as given in this example, but it segfaults:
>
> 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.
>
> This is indeed strange.
> The issue didn't reproduce on Fedora 17 either. Which release do you use?
Fedora 16, 64-bit.
> I'll try to figure it out. Maybe after vacation.
Yes :-)
Anyway, thanks for your help!
Mitch.
|
|
From: Nikolai K. <sp...@gm...> - 2012-06-25 20:19:58
|
Hi Mitch, On 06/25/2012 06:49 AM, Mitch Davis wrote: > On Fri, Jun 22, 2012 at 8:21 PM, Nikolai Kondrashov<sp...@gm...> wrote: >> Can you also please show the output of "sudo lsusb -d 08f2:6370 -v"? > > [root@xiaomao mjd]# lsusb -d 08f2:6370 -v Thanks! > Curiously enough, Gotop Information Inc. has a VID of 0x08f2, but > the apparent manufacturer, "Green Asia Corp" also has their own VID > (0e8f, "GreenAsia Inc.") Well, it's quite in line with the usual chaos Asian engineers are known to produce. >> A photo would also be good to have. > > This is the product: > > http://www.hqbuy.com/UniscomCR300-DWB151554ASS.html > > Curiously but irrelevantly, the HQ in the name of that company stands > for Huaqiang, the world's largest electronics market, here in Shenzhen > China. That's where I live :-) I have a feeling that this device was thrown together from whatever was available at the moment :) >>> On insertion, these messages appear in /var/log/messages: >>> >> 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? > > For $5? LOL-with-ponies. Well, you said yourself it was a graphics tablet, and I was quite amazed at that too :) OTOH, would you have believed even in such a limited device being sold for $5, say, five years ago? > This device is a wrapper around a resistive touchpad almost identical > to that found in a Nintendo DS. You touch the screen, it shorts two > layers together, and you get X/Y samples. I have made similar devices > myself: > > http://capnstech.blogspot.com/2010/02/computer-assisted-chinese-part-vi.html > http://capnstech.blogspot.com/2010/02/computer-assisted-chinese-part-vii.html > http://capnstech.blogspot.com/2010/07/touchscreen-update.html Quite interesting stuff you do there. Coincidently, a colleague of mine was tinkering with an Arduino and LUFA in his own input project recently :) > There's no barrel buttons, no pen switches, no nothing. Just the > sensor and three buttons. > > The nibble that shows the buttons is completely independent of the > nibbles for the position. Ah, I see now, thanks. >> I can help you with making a report descriptor, if needed. > > Ok. First I will try the pseudo-mouse descriptor I used with my USB > device, because I know it'll show up and be noticed by X. Then I > might try a descriptor with a little more finesse, and I might need > your help for this. > > The descriptor for my USB device describes a 1-button absolute > coordinate mouse. When the touchpad is touched, it appears that not > only is the pointer moving, but button 1 has been pressed. When > samples stop, I report that button 1 has been released. So there's no > real button one, just a faked button one. I think this approach is > necessary for a device where there is no pressure sensitivity and no > pen switch. Sounds klunky, but it works fine for the app I want to > use the tablet for. I'm interested in your thoughts on whether this > is good or bad. If you don't plan to contribute the driver to the Linux kernel, then it is up to you, of course. However, if you do, it is best to implement the functionality most users expect, which, probably, is what the Windows driver does. To me this device looks like a (laptop) touchpad, but with a pen. So it would make sense to implement a touchpad protocol of sorts and not to introduce movement tracking and synthetic button pressures. I'm not very knowledgeable in the touchpad protocol, but I can suggest looking at the xf86-input-evdev source and existing touchpad kernel drivers. > Note the X and Y values are uncalibrated. They are 11-bit unsigned > values, but they don't span 0-2047. There needs to be a calibration > phase, and a coordinate transformation step to map the returned values > to full screen. I've done this in the past (in the USB device) but I > haven't done it in the kernel. Is a transformation like this done > elsewhere in the kernel? How does one tell the driver the values of > the calibration constants? (Hopefully it can be done live, rather > than at module load time. Is there an example somewhere?) I suggest you try using "Coordinate Transformation Matrix" pointer property in X.org and not implement it yourself. There is a bug in X.org which might affect you, though: https://bugs.freedesktop.org/show_bug.cgi?id=49347 > Ok, I copied the uclogic file, and modified it. The module is > registering ok, but a printk in my report fixup function never fires. > My guess is that this tablet needs to also be registered in the > hid_have_special_driver[] table in hid-core.c, or be registered at > run-time. I'm imagining there would be a call to store_new_id(), > either from my code, or from some command-line interface, but I can't > work out how to do it. Any pointers? You have to register your device in hid-core.c. If a device is not in hid_have_special_driver, the generic HID driver will claim it. You can rebind the driver through sysfs, but if it changes the report descriptor, this won't work in kernels before 3.5. >> The issue didn't reproduce on Fedora 17 either. Which release do you use? > > Fedora 16, 64-bit. I'll try installing it and reproducing the issue sometime after vacation. Sincerely, Nick |
|
From: Mitch D. <mjd...@af...> - 2012-07-07 17:04:32
|
On Tue, Jun 26, 2012 at 4:19 AM, Nikolai Kondrashov <sp...@gm...> wrote: > > I'll try installing it and reproducing the issue sometime after vacation. How was your sort-of vacation? I would still like to get this tablet going. I'm running kernel 3.5.0-0.rc4.git4. Is there a way to bind the driver into the table of hid-bus devices at run-time? Mitch. |
|
From: Nikolai K. <sp...@gm...> - 2012-07-08 10:21:25
|
Hi Mitch, On 07/07/2012 08:04 PM, Mitch Davis wrote: > How was your sort-of vacation? It kind-of doesn't want to end. I found I have a serious burnout, so I'll try to take things easy for a while. At least until I get a real vacation on my day job (within a month). > I would still like to get this tablet going. I'm running kernel > 3.5.0-0.rc4.git4. Is there a way to bind the driver into the table of > hid-bus devices at run-time? Yes, it should work there. If not, please report to Jiri Kosina and the linux-input maillist. You can do it by writing bus device ID to "bind" and "unbind" files under corresponding driver directories. Like this: echo 0003:172F:0502.0002 | sudo tee /sys/bus/hid/drivers/generic-usb/unbind echo 0003:172F:0502.0002 | sudo tee /sys/bus/hid/drivers/waltop/bind The format of HID bus device ID is this: TRANSPORT_BUS_ID:VENDOR_ID:PRODUCT_ID.DEVICE_NUMBER Please don't hesitate to ask any other questions regarding your tablet support. Sincerely, Nick |
|
From: Mitch D. <mjd...@af...> - 2012-07-14 05:26:31
|
On Sun, Jul 8, 2012 at 6:21 PM, Nikolai Kondrashov <sp...@gm...> wrote: > Hi Mitch, > > echo 0003:172F:0502.0002 | sudo tee /sys/bus/hid/drivers/generic-usb/unbind Newb question, but I can't find that virtual file, only /sys/bus/hid/drivers/hid-generic/unbind. Is it the same thing, or something different? If it's different, how do I get that one? Which module should I load to make it appear? Also, regarding the four numbers, in particular the fourth number. In your example, it's 0002. On my machine, if I do lsusb, the tablet is on bus 2, device 41. Will this do the job? echo 0002:08F2:6370:0029 > unbind Thanks, Mitch. |
|
From: Nikolai K. <sp...@gm...> - 2012-07-14 09:45:44
|
Hi Mitch, On 07/14/2012 08:26 AM, Mitch Davis wrote: >> echo 0003:172F:0502.0002 | sudo tee /sys/bus/hid/drivers/generic-usb/unbind > > Newb question, but I can't find that virtual file, only > /sys/bus/hid/drivers/hid-generic/unbind. Is it the same thing, or > something different? If it's different, how do I get that one? Which > module should I load to make it appear? It appears the 3.5 kernel changed it and "hid-generic" is the new driver. So, use it instead of "generic-usb". > Also, regarding the four numbers, in particular the fourth number. In > your example, it's 0002. On my machine, if I do lsusb, the tablet is > on bus 2, device 41. Will this do the job? > > echo 0002:08F2:6370:0029> unbind Sure. Every HID device plugged in gets a new fourth number. So if you just unplug and plug back the same device it will get assigned the next number. BTW, I failed to reproduce the hidrd-convert problem on a freshly installed Fedora 16 64 bits so far. Sincerely, Nick |
|
From: Mitch D. <mjd...@af...> - 2012-07-15 08:11:29
|
On Sun, Jul 8, 2012 at 6:21 PM, Nikolai Kondrashov <sp...@gm...> wrote: > > echo 0003:172F:0502.0002 | sudo tee /sys/bus/hid/drivers/generic-usb/unbind > echo 0003:172F:0502.0002 | sudo tee /sys/bus/hid/drivers/waltop/bind > > The format of HID bus device ID is this: > > TRANSPORT_BUS_ID:VENDOR_ID:PRODUCT_ID.DEVICE_NUMBER Very strange, the numbers I need are not what I expect: [root@xiaomao /]# cd /sys/bus/hid/drivers/hid-generic/ [root@xiaomao hid-generic]# ls -la total 0 drwxr-xr-x. 2 root root 0 Jul 14 18:37 . drwxr-xr-x. 15 root root 0 Jul 14 18:37 .. lrwxrwxrwx. 1 root root 0 Jul 14 19:20 0003:040B:2013.0001 -> ../../../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0/0003:040B:2013.0001 lrwxrwxrwx. 1 root root 0 Jul 14 19:20 0003:040B:2013.0002 -> ../../../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.1/0003:040B:2013.0002 lrwxrwxrwx. 1 root root 0 Jul 14 19:20 0003:08F2:6370.0003 -> ../../../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0/0003:08F2:6370.0003 --w-------. 1 root root 4096 Jul 14 18:37 bind --w-------. 1 root root 4096 Jul 14 18:37 new_id --w-------. 1 root root 4096 Jul 14 18:37 uevent --w-------. 1 root root 4096 Jul 14 18:37 unbind [root@xiaomao hid-generic]# lsusb 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 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 003: ID 0402:9665 ALi Corp. Bus 002 Device 003: ID 040b:2013 Weltrend Semiconductor Bus 002 Device 004: ID 08f2:6370 Gotop Information Inc. ## Note the bus and device number. I'll try according to your formula: [root@xiaomao hid-generic]# echo 0002:08f2:6370:0004 > unbind bash: echo: write error: No such device ## Let's try the symlink from the dir listing: [root@xiaomao hid-generic]# echo 0003:08F2:6370.0003 > unbind ## No error message! [root@xiaomao hid-generic]# ls -la total 0 drwxr-xr-x. 2 root root 0 Jul 14 18:37 . drwxr-xr-x. 15 root root 0 Jul 14 18:37 .. lrwxrwxrwx. 1 root root 0 Jul 14 19:20 0003:040B:2013.0001 -> ../../../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0/0003:040B:2013.0001 lrwxrwxrwx. 1 root root 0 Jul 14 19:20 0003:040B:2013.0002 -> ../../../../devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.1/0003:040B:2013.0002 --w-------. 1 root root 4096 Jul 14 18:37 bind --w-------. 1 root root 4096 Jul 14 18:37 new_id --w-------. 1 root root 4096 Jul 14 18:37 uevent --w-------. 1 root root 4096 Jul 14 19:22 unbind [root@xiaomao hid-generic]# Also, I'm having a problem with loading modules: https://bugzilla.redhat.com/show_bug.cgi?id=840267 I think I'll have to wait for a solution to that before proceeding. > 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. Yes I'd like your help please? Do you understand the format of the current report? Mitch. |
|
From: Nikolai K. <sp...@gm...> - 2012-07-16 19:54:24
|
On 07/15/2012 11:11 AM, Mitch Davis wrote: > On Sun, Jul 8, 2012 at 6:21 PM, Nikolai Kondrashov<sp...@gm...> wrote: >> >> echo 0003:172F:0502.0002 | sudo tee /sys/bus/hid/drivers/generic-usb/unbind >> echo 0003:172F:0502.0002 | sudo tee /sys/bus/hid/drivers/waltop/bind >> >> The format of HID bus device ID is this: >> >> TRANSPORT_BUS_ID:VENDOR_ID:PRODUCT_ID.DEVICE_NUMBER > > Very strange, the numbers I need are not what I expect: The device number in the HID bus device ID is *not* USB bus device number. It's a number local to the HID bus - just an ordinal number of a connected device. HID is a high-level bus and uses other buses for transport. Currently USB and Bluetooth are supported. The first number in the HID device ID is the transport bus ID, 3 being USB. > Also, I'm having a problem with loading modules: > > https://bugzilla.redhat.com/show_bug.cgi?id=840267 > > I think I'll have to wait for a solution to that before proceeding. You can build your own kernel and work in-tree in the meantime. >> 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. > > Yes I'd like your help please? Do you understand the format of the > current report? I assume that you mean format of the reports. You described it quite well - I guess I will be able to understand it. However, you haven't told me how you want this tablet/touchpad to be represented and whether you want to submit the driver upstream or not. Without this I can't make a meaningful report descriptor. Sincerely, Nick |
Thanks for helping keep SourceForge clean.
X