Re: [DIGImend-devel] PT-1001 digitizer

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

Hi Yann,

On 03/07/2015 09:35 PM, Yann Vernier wrote:
> 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.

Great!

>>>> 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.

Well, we'll have to do with that then.

>> 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.

Yes, the unit system is complicated and is not helped by the fact that the
authors of the original HID descriptor tool have misinterpreted it, confusing
all its users further.

>> 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.

Thanks!

>> 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

Thanks, Yann. Reviewed now.

Nick