Re: [DIGImend-devel] PT-1001 digitizer

[Yann V. <yan...@or...>]

Nikolai Kondrashov <sp...@gm...> wrote:

> I would prefer the latter. I.e. have the lower side button report middle click
> and the upper one report right click to match other tablets.

Okay, doing that. 

> >> Is the actual physical drawing area square?
> >
> > No. I believe it's meant to be 16:10 proportions.
> > A quick measurement by the printed border shows:
> > X: inner 103.65mm, outer 105mm
> > Y: inner 65.6mm, outer 66.45mm
> > This gives an aspect ratio somewhere from 1.56 to 1.60. Measuring the firmware limits
> > would be a bit harder (for instance, it doesn't measure the tip but the coil position).
> > I guess 105.6*66mm would be a reasonable approximation.
> 
> This would be awfully low resolution and most likely scaled by firmware for
> compatibility. The oldest tablet I have (UC-Logic WP8060U) has higher
> resolution, I think. There's very little chance a non-square tablet would
> report equal coordinate range for both axes in hardware. There might be a way
> to get it to report real ranges over USB. I would try poking at those features
> in the report descriptor. There should have been a driver for this tablet
> doing that. Perhaps we can find it and take a look at the USB traffic. We can
> postpone it for later, though.

It is definitely scaled by firmware; the non-square area is reported as a full 
12 bit range. This works out to roughly 4096/(105.6/25.4)=985cpi. The soft buttons 
are outside of this reported area and handled entirely in firmware. 
Obviously the resolution runs out as this hits 4k monitors; quantisation errors 
may be notable before that. 

In mouse mode, it reports a higher resolution at 16 bits, but takes steps of 
about 7 counts, which works out to roughly 2200cpi. 

The tablet was designed to work with Windows default drivers, and did not come 
with any drivers. I have no idea how to request raw data out of it. 


> BTW, the original descriptor for interface 2 seems to have the correct range
> and physical extents. You can take the extents from there at least, which seem
> to be 4x2.5 inches.

I find the HID encoding of units rather confusing. The descriptor seems 
to read 4x2.5 English inches, with a mistaken unit of cubic inches. If I have 
managed to figure out the system of HID correctly, the nibble value says what 
the exponent is for a unit in that position, so the inches should be 0x31. 
The only reason I didn't make the same mistake was that centimeters just 
happened to be written under column 1 in the nearly unreadable table. 

> Speaking of which, I think you need to make the report descriptor as simple as
> possible to make it easier to get into the kernel. Strip it down to the
> absolute minimum required to work. Remove unused report IDs and collections.

Okay, stripping it down. 

> You can replace the multiplier fields with constant fields, if they're unused.
> Also get rid of nested collections and repeated report IDs, if you can.

I was mistaken about the resolution multiplier fields; the tablet really does 
use one of them for scrolling events. The other looks like it's horisontal 
scrolling, which there isn't a control for. 

> I would disable interface #2 here, if we can't make it work, with something
> like this:

Done. 


> BTW, can you make pull requests to digimend-kernel-drivers instead of sending
> files?

I think I may have figured it out. 
https://github.com/DIGImend/digimend-kernel-drivers/pull/11