Re: [DIGImend-devel] Some problems with hidrd-convert

[Mitch D. <mjd...@af...>]

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.