digimend-devel — Development matters

[DIGImend-devel] Genius EasyPen M610

[Favux ... <fav...@gm...>]

Hi Nick,

I'm sending this for LannaD because she's having touble e-mailing the
devel list for some reason.  She has what I think is a new model to us
bought about a year ago.

Genius EasyPen M610/ 6x10 Tablet/ UC-LOGIC Tablet WP1700U

The tablet diagnostics are attached.

Favux

Re: [DIGImend-devel] Wiki editing

[Nikolai K. <sp...@gm...>]

Hi Viktoria, Dave,

On 06/13/2012 05:19 PM, Favux ... wrote:
> As far as I know you are correct.  Page deletion rights are above our
> privilege level.  Nick has to delete "Tablet setup in GTKMM based
> applications (Inkscape, Synfig Studio)" himself.

Sorry, didn't know that. Removed.

Sincerely,
Nick

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

[Nikolai K. <sp...@gm...>]

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

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

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

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.

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

[Nikolai K. <sp...@gm...>]

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

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.

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

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

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.

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

[Nikolai K. <sp...@gm...>]

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

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

[Nikolai K. <sp...@gm...>]

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

[DIGImend-devel] Some problems with hidrd-convert

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

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.

Re: [DIGImend-devel] Wiki editing

[Favux ... <fav...@gm...>]

Hi Viktoria,

As far as I know you are correct.  Page deletion rights are above our
privilege level.  Nick has to delete "Tablet setup in GTKMM based
applications (Inkscape, Synfig Studio)" himself.

Favux

Re: [DIGImend-devel] Wiki editing

[Viktoria S. <vik...@fr...>]

Hi!

I have corrected almost everything you have asked.
The problems I have got:
1. As I wrote as far as I know on sourceforge it is not possible.
4. I looked after it I guess I should have seen a delete button at the bottom of the pages, which I didn't so I think I don't have right to delete pages....
6. I did not had to do anything about that did I?

Kind regards:
Viktoria

Nikolai Kondrashov <sp...@gm...> írta:

Here are a few general comments on the articles:>
>
1. Could you please format your footnotes with <ref> and <references /> as>
    described in the manual: http://en.wikipedia.org/wiki/Help:Footnotes ?>
>
2. Please format lists using appropriate syntax:>
    http://meta.wikimedia.org/wiki/Help:List>
>
3. It is better to link from text instead of pasting links directly into the>
    article text, as intended for hypertext.>
>
    I.e., please don't write this:>
>
         You can find more information about Alchemy on the>
         official website: http://al.chemy.org/.>
>
    But instead this:>
>
         You can find more information about Alchemy on the>
         [http://al.chemy.org/ official website].>
>
    This also concerns mailto: links.>
>
4. I assume you don't need the "Tablet setup in GTKMM based applications>
    (Inkscape, Synfig Studio)" page anymore. Could you please delete it?>
>
5. I've noticed one mistake which you often do: you write "... does not>
    compatible with ...", whereas it should be written "... is not compatible>
    with ...", because compatible is an adjective, so describes a property,>
    not an action. OTOH, "... does not work ..." is correct.>
>
6. Please use =Heading 1= as the top level header syntax and the>
    corresponding lower level syntax for lower level headers, at least for>
    the time being. I've fixed this in your articles.>
>
Could you please go through your articles and correct these, when time>
allows? Thank you very much for your help!>
>
Oh, and could you please add yourself as a Wiki contributor to the "People">
section on the front page?>
>
Thanks :)>
>
Sincerely,>
Nick>

Re: [DIGImend-devel] Wiki editing

[Viktoria S. <vik...@fr...>]

Hi!

Nikolai Kondrashov <sp...@gm...> írta:
Here are a few general comments on the articles:>
>
1. Could you please format your footnotes with <ref> and <references /> as>
    described in the manual: http://en.wikipedia.org/wiki/Help:Footnotes ?>
>

I originally wanted to use this, but there is bug in soueforge wiki: the cite extension does not work. You cannot use this.
See here:
http://sourceforge.net/tracker/?func=detail&atid=350001&aid=2752161&group_id=1
I have tried it did not work for me..... That is the reason I did the reference the way I did.

According to the others I do my best to correct the pages the way you have suggested.

Best wishes:
Viktoria

Re: [DIGImend-devel] Wiki editing

[Nikolai K. <sp...@gm...>]

On 06/11/2012 11:10 AM, Viktoria S. wrote:
> I have created the final 2 pages about configuring applications:
> https://sourceforge.net/apps/mediawiki/digimend/index.php?title=Tablet_setup_in_Blender
> https://sourceforge.net/apps/mediawiki/digimend/index.php?title=Tablet_setup_in_Wine
>
> The are ready for review :)

Thanks :)! I'll do a proper review of these and the rest after the vacation.

> I think now the most popular artistic applications are covered. If someone
> want to use some other applications and writes about it in the users
> mailing list then I look after it and write a page about it.

I agree.

> There is one thing I have been thinking about. The Tip, Note and Warning
> text blocks could be made a bit fancier. I have created some icons for
> this (with my very amateur artistic skills) and a proposal for those text
> blocks. See the attached image. What do you think about those? (I am not
> sure if that can be created in the wiki, but if yes I think it might be
> worth go for it.)

I have several comments about these:

The purpose of such icons is to signify the type of the text block and
nothing else. The icons shouldn't be too distracting and shouldn't take too
much space. Based on this here are my suggestions:

1. Reduce them by about 25%.

2. Reduce the number of colors (shades). Either provide outlines with flat
    filling or maybe use cel shading.

3. Use roughly the same framing across all the icons. I.e. the pen should be
    seen from roughly the same distance in all icons. For example, the "note"
    icon could instead show a close up of the pen tip writing a pair of
    letters.

4. Improve meaning of the "warning" icon - now the picture doesn't really
    spell "warning!" to me. How about showing a pen tip as it is being
    strained, bent or broken from too much pressure? Cartoney "strain" or
    "pain" lines (don't know how they're called by artists, really) along the
    pen would help reinforce the message.

Also, take a look at how the pen tips look on more expensive tablets - maybe
it's better to take them as a model.

Thanks :)!

Sincerely,
Nick

Re: [DIGImend-devel] Wiki editing

[Nikolai K. <sp...@gm...>]

On 06/08/2012 01:44 PM, Viktoria S. wrote:
> I have created separate pages for some applications. I have enhanced the previous content. These are ready for ready for review. :)
> Here they are:
> https://sourceforge.net/apps/mediawiki/digimend/index.php?title=Tablet_setup_in_GIMP
> https://sourceforge.net/apps/mediawiki/digimend/index.php?title=Tablet_setup_in_MyPaint
> https://sourceforge.net/apps/mediawiki/digimend/index.php?title=Tablet_setup_in_Synfig_Studio
> https://sourceforge.net/apps/mediawiki/digimend/index.php?title=Tablet_setup_in_Inkscape
>
> I guess if you find something to correct with these just go ahead. :)
>
> According to wine (just to be clear):
> I do not want to write articles about how to make windows applications
> work with wine. (I could test only the demo version of those anyway....) I
> just wanted to check if wine is recognizing my tablet or not. I for that
> purpose the windows version of gimp was perfect.

Yes, I guessed that. I think we can skip writing instructions for
Windows-based apps until there is demand for them.

> Actually I wanted to create an article how to compile QT with my suggested
> fix. But that will take time to put it together.

We can put these instructions in the bug comments.

> So for now maybe the better solution will be to follow your advice and
> just add a note and a link to the bug on the application pages.

Thanks :)

I'll postpone correcting English and formatting of the articles until after
the vacation. So, I decided to publish your pages as they are, as it is
better to have information available, even though it might not be ideal in
some regards.

Here are a few general comments on the articles:

1. Could you please format your footnotes with <ref> and <references /> as
    described in the manual: http://en.wikipedia.org/wiki/Help:Footnotes ?

2. Please format lists using appropriate syntax:
    http://meta.wikimedia.org/wiki/Help:List

3. It is better to link from text instead of pasting links directly into the
    article text, as intended for hypertext.

    I.e., please don't write this:

         You can find more information about Alchemy on the
         official website: http://al.chemy.org/.

    But instead this:

         You can find more information about Alchemy on the
         [http://al.chemy.org/ official website].

    This also concerns mailto: links.

4. I assume you don't need the "Tablet setup in GTKMM based applications
    (Inkscape, Synfig Studio)" page anymore. Could you please delete it?

5. I've noticed one mistake which you often do: you write "... does not
    compatible with ...", whereas it should be written "... is not compatible
    with ...", because compatible is an adjective, so describes a property,
    not an action. OTOH, "... does not work ..." is correct.

6. Please use =Heading 1= as the top level header syntax and the
    corresponding lower level syntax for lower level headers, at least for
    the time being. I've fixed this in your articles.

Could you please go through your articles and correct these, when time
allows? Thank you very much for your help!

Oh, and could you please add yourself as a Wiki contributor to the "People"
section on the front page?

Thanks :)

Sincerely,
Nick

[DIGImend-devel] Out on vacation

[Nikolai K. <sp...@gm...>]

Hi Viktoria, Dave,

I've decided to go on vacation for a while. Working in the evenings and on
weekends in addition to the day job has taken its toll. There's just been
a bit too much worry for me in the last weeks and I'd like to relax a
little.

I will have 5 computer-free holidays starting tomorrow and then I'd like to
avoid working on the project for some time. Let it be two weeks for a start
and then we'll see.

During that time I will look through my e-mails from time to time, but will
try to answer only urgent ones.

Thank you for your help.

Sincerely,
Nick

Re: [DIGImend-devel] Wiki editing

[Viktoria S. <vik...@fr...>]

Hi!

I have created the final 2 pages about configuring applications:
https://sourceforge.net/apps/mediawiki/digimend/index.php?title=Tablet_setup_in_Blender
https://sourceforge.net/apps/mediawiki/digimend/index.php?title=Tablet_setup_in_Wine

The are ready for review :)

I think now the most popular artistic applications are covered. If someone want to use some other applications and writes about it in the users mailing list then I look after it and write a page about it.

There is one thing I have been thinking about. The Tip, Note and Warning text blocks could be made a bit fancier. I have created some icons for this (with my very amateur artistic skills) and a proposal for those text blocks. See the attached image. What do you think about those? (I am not sure if that can be created in the wiki, but if yes I think it might be worth go for it.)

Best wishes:
Viktoria

[DIGImend-devel] [ digimend-Bugs-3534260 ] Wine does not compatible with evdev

[SourceForge.net <no...@so...>]

Bugs item #3534260, was opened at 2012-06-11 00:54
Message generated for change (Tracker Item Submitted) made by viktoria-s
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1089171&aid=3534260&group_id=233297

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: tablets
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Viktoria S. (viktoria-s)
Assigned to: Viktoria S. (viktoria-s)
Summary: Wine does not compatible with evdev

Initial Comment:
Wine does recognise tablet wich uses the evdev driver as tablet.
The bug filed here: http://bugs.winehq.org/show_bug.cgi?id=30893

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1089171&aid=3534260&group_id=233297

[DIGImend-devel] Wiki header styles

[Nikolai K. <sp...@gm...>]

Hi everyone,

I've finally implemented the style hack for the wiki headers I was
planning.

Now, in page content, header level 1 (=Heading 1=), looks like header
level 2 (==Heading 2==) in original style, level 2 - like level 3, level 3 -
like level 4, and so on.

This allows us to use =Heading 1= syntax for first level headers in wiki
page content, otherwise wasted, and save a little on typing. This will make
the existing pages, which do that, look properly. I will update Viktoria's
pages to do that, myself.

This is the kind of "fighting against the system", which I usually don't
agree to. However, it allows us to keep pages which I wrote, not knowing this
Wiki quirk.

Having a syntax for the first level headers, which cannot be used feels
unlogical. OTOH, it is logical from the point of overall page design, that
the content uses second level headers, while there is only one top level
header. All-in-all, this could be controversial.

So, could we please try to stick using the =Heading 1= for top level headers
in the page content for a while? If it turns out we make mistakes too often,
or a MediaWiki upgrade breaks that, I would make a script which would shift
header levels down in the content of all our pages.

Thanks!

Sincerely,
Nick

Re: [DIGImend-devel] Wiki editing

[Favux ... <fav...@gm...>]

On Fri, Jun 8, 2012 at 1:48 PM, Viktoria S. <vik...@fr...> wrote:
> Hi!
>
> I have created 2 more pages for the wiki:
> https://sourceforge.net/apps/mediawiki/digimend/index.php?title=Tablet_setup_in_Krita
> https://sourceforge.net/apps/mediawiki/digimend/index.php?title=Tablet_setup_in_Alchemy
>
> I guess they are ready for review too :)
>
> Best wishes:
> Viktoria

Wow!

Looking good Vikotria S!  The DIGImend mediawiki is going to be packed
with useful information!

Favux

Re: [DIGImend-devel] Wiki editing

[Viktoria S. <vik...@fr...>]

Hi!

I have created 2 more pages for the wiki:
https://sourceforge.net/apps/mediawiki/digimend/index.php?title=Tablet_setup_in_Krita
https://sourceforge.net/apps/mediawiki/digimend/index.php?title=Tablet_setup_in_Alchemy

I guess they are ready for review too :)

Best wishes:
Viktoria

Re: [DIGImend-devel] Wiki editing

[Viktoria S. <vik...@fr...>]

Hi!

I have created separate pages for some applications. I have enhanced the previous content. These are ready for ready for review. :)
Here they are:
https://sourceforge.net/apps/mediawiki/digimend/index.php?title=Tablet_setup_in_GIMP
https://sourceforge.net/apps/mediawiki/digimend/index.php?title=Tablet_setup_in_MyPaint
https://sourceforge.net/apps/mediawiki/digimend/index.php?title=Tablet_setup_in_Synfig_Studio
https://sourceforge.net/apps/mediawiki/digimend/index.php?title=Tablet_setup_in_Inkscape

I guess if you find something to correct with these just go ahead. :)

According to wine (just to be clear):
I do not want to write articles about how to make windows applications work with wine. (I could test only the demo version of those anyway....) I just wanted to check if wine is recognizing my tablet or not. I for that purpose the windows version of gimp was perfect. And it turned out that the tablet itself was not recognized as tablet :(.

Nikolai Kondrashov <sp...@gm...> wrote:
> Tablets and QT>
> (I guess this topic should be created because of the QT bug. Do you have>
> better idea for the title?)>
>
If this page is needed only to describe the issue, and there is no common>
Qt-specific instructions there, then we can simply add a note and a link to>
the bug to all the Qt-based application pages.>

Actually I wanted to create an article how to compile QT with my suggested fix. But that will take time to put it together. So for now maybe the better solution will be to follow your advice and just add a note and a link to the bug on the application pages.

Best wishes:
Viktoria

Re: [DIGImend-devel] Wiki editing

[Nikolai K. <sp...@gm...>]

Hi Viktoria,

On 06/05/2012 11:13 AM, Viktoria S. wrote:
> Well, it can be a good idea yes. It will be easier for the users to find
> informations, and I guess it will be easier to maintain it too. I suggest
> to do the following pages then:
> Tablet setup in Gimp
> Tablet setup in MyPaint
> Tablet setup in Krita
> Tablet setup in Alchemy
> Tablet setup in Blender
> Tablet setup in Wine
> (I am not quite sure about this topic yet. I guess it should be created,
> because there are some people who are running windows applications under
> wine and they want to use their tablet there as well. But there is a bug
> in wine.... I tried to run Gimp 2.8 windows version and my tablet is not
> recognised at all, but I guess I should file a bug first which I hasn't
> done yet.)

If there could be Wine-specific setup instructions, then I think it is still
worth creating a page on Wine, even if it doesn't work, just to say that and
link to the bug, which would describe the reasons and possible resolution.

If Wine-based applications are set up differently and their setup differs
from Windows it is better to have separate application pages, IMHO. So, if
there are no significant amount of common Wine-specific instructions between
them, we could just have links to the bug from application pages.

I don't think there is much sense in running Windows version of Gimp on
Linux, so instructions for that are not needed, probably. Yet, we could try
looking at how popular Windows-native apps work under Wine.

> Tablets and QT
> (I guess this topic should be created because of the QT bug. Do you have
> better idea for the title?)

If this page is needed only to describe the issue, and there is no common
Qt-specific instructions there, then we can simply add a note and a link to
the bug to all the Qt-based application pages.

> I think there is no need for creating a page for Pencil then, unless users
> demand it.

Well, you probably know better if the instructions are needed - I never used
it and don't know if it's popular or not.

>> We can additionally have toolkit categories, if needed.
>>
>> The category pages would look like this one (with more introductory
>> text, maybe):
>> https://sourceforge.net/apps/mediawiki/digimend/index.php?title=Category:Tablets
>>
>> If you don't like this design, we could have a dedicated page instead,
>> but the list of articles will need manual updating in this case.
>
> I guess let's drop this category stuff then. My main idea was that if a
> program uses a toolkit and the tablet works then probably it is going to
> work in other applications using the same toolkit too. And if a toolkit
> does not support the tablet then none of the applications will work with
> the tablet (see QT).

I think we can achieve similar effect with just notes and links to the bug.
Still, we'll need a page listing all the application-specific instructions.

>> 3. There are some small English mistakes and minor style issues. If
>> you don't mind, I can fix them in place. I'll try to group the changes
>> so that it is easier for you to review. Maybe Dave would be able to go
>> through and further improve them after my fixes.
>
> OK, thanks. But I guess that should be done after the content has been
> reorganized.

Sure. Thank you :)

Sincerely,
Nick

Re: [DIGImend-devel] Wiki editing

[Viktoria S. <vik...@fr...>]

On 04/06/12 21:27, Nikolai Kondrashov wrote:
>
> Here are some comments:
>
> 1. So far I see little sense in putting application instructions
> together based on their toolkit - there is little similarity in the
> configuration instructions.
>
> What if we put every application on a separate page? This way, I
> think, each article will be more focused and the users won't be
> confusing instructions from different applications. We can then have a
> category for application HOWTOs, have an introduction on its page and
> link to it from the main page. 
Well, it can be a good idea yes. It will be easier for the users to find informations, and I guess it will be easier to maintain it too. I suggest to do the following pages then:
Tablet setup in Gimp
Tablet setup in MyPaint
Tablet setup in Krita
Tablet setup in Alchemy
Tablet setup in Blender
Tablet setup in Wine
(I am not quite sure about this topic yet. I guess it should be created, because there are some people who are running windows applications under wine and they want to use their tablet there as well. But there is a bug in wine.... I tried to run Gimp 2.8 windows version and my tablet is not recognised at all, but I guess I should file a bug first which I hasn't done yet.)
Tablets and QT
(I guess this topic should be created because of the QT bug. Do you have better idea for the title?)
I think there is no need for creating a page for Pencil then, unless users demand it.
(Once we agreed on the topics I can reorganize the content than :))

>We can additionally have toolkit
> categories, if needed.
>
> The category pages would look like this one (with more introductory
> text, maybe): https://sourceforge.net/apps/mediawiki/digimend/index.php?title=Category:Tablets
>
> If you don't like this design, we could have a dedicated page instead,
> but the list of articles will need manual updating in this case.

I guess let's drop this category stuff then. My main idea was that if a program uses a toolkit and the tablet works then probably it is going to work in other applications using the same toolkit too. And if a toolkit does not support the tablet then none of the applications will work with the tablet (see QT).

> 2. I think each page should have a note saying where to ask questions
> not covered by the HOWTO and where to send corrections. The
> DIGImend-users maillist is a good place for this, IMHO. Or, maybe
> better still, each article should start with an introduction
> explaining which application and which versions it covers, pointing to
> the maillist for questions and corrections and maybe stating the
> author.

OK. And maybe I can extend some parts of the articles with links to documentations and tutorials etc. if there is some related stuff out there....
>
> 3. There are some small English mistakes and minor style issues. If
> you don't mind, I can fix them in place. I'll try to group the changes
> so that it is easier for you to review. Maybe Dave would be able to go
> through and further improve them after my fixes.

OK, thanks. But I guess that should be done after the content has been reorganized.

>
> 4. I would also like you to be the maintainer of these HOWTOs and keep
> an eye on them, updating and correcting them as necessary. Can you do
> that?

Yes, sure. I do my best.

Best wishes:
Viktoria

[DIGImend-devel] [ digimend-Bugs-3531998 ] Add handling of degenerate event devices

[SourceForge.net <no...@so...>]

Bugs item #3531998, was opened at 2012-06-04 14:05
Message generated for change (Tracker Item Submitted) made by spb_nick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1089171&aid=3531998&group_id=233297

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: tablets
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nikolai Kondrashov (spb_nick)
Assigned to: Nikolai Kondrashov (spb_nick)
Summary: Add handling of degenerate event devices

Initial Comment:
Add handling of degenerate event devices, such as Waltop scroll wheels either to the xorg-server-core or to xf86-input-evdev.

Waltop scroll wheel devices only have vertical and sometimes horizontal scroll wheel reports. This makes them not match any evdev catch-all classes in the default configuration.

This could be resolved by adding match-no-type class to the default xf86-input-evdev configuration, or making xorg-server-core match them to some type.

Peter Hutterer needs to be consulted on this matter.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1089171&aid=3531998&group_id=233297