Pen tilt support

[quo]

Tilt is currently not implemented, because I don't have a pen with tilt support.

If we get some data captures from pens with tilt support, we can probably figure out the format.

To capture the data from the ithc driver, run sudo cat /dev/ithc > ithc.dat (you don't have to stop iptsd). Then put the pen in the center of the screen and tilt it at various angles. Afterwards Ctrl+C to stop the cat command, and you should have an ithc.dat which is several megabytes large. Please zip the file and attach it here, and please also say which Surface device and which pen you're using.

[freak007]

Here is ithc dump from my uogic pen with tilt support.
link: ithc.dat (the link expires in 7 days)

[NP-chaonay]

SLS with quo's ithc+ quo's iptsd on Ubuntu 22.04LTS on Surface Kernel
Surface Slim Pen 2 is used

Tilt from ~center to ~180 degree (I have avoid the bottom part of pen touch or hover the screen so the result wont be too much difficult, also I avoid soft pressing of bottom button as it may alter the result such as middle click (#5 ) for <5 seconds
Link:
https://drive.google.com/file/d/1aA-O4F5rID8yR9S2e2mXfLzHjqQi8jd7/view?usp=sharing

[quo]

Thanks! Your pens are definitely sending a lot more data than my pen.

I've plotted the total magnitudes for the rows of the various DFT packet types, and tried to find some patterns.
Some initial observations:

• The timestamps on the SLS seem to increase much slower: 1MHz instead of 8MHz. (Assuming the packet rate is similar.)
• Some of the frequencies are slightly different in the SLS data.
• In both captures, the second and third row in type 6 packet contains some data (looks fairly constant).
• There are two type 10 packets in each "set" of packets. Each packet seems to encode one byte. There are two rows per bit. One of the two rows contains a high value, the other a low value, this determines whether the bit is 0 or 1. X and Y rows contain the same data. After 6 "sets", the encoded bytes repeat. So there is a pattern of 12 bytes in total. Possibly some kind of pen id? Or maybe for CDMA-like multiplexing?
• Type 7/8 possibly also encode bits. These also look fairly constant. Only the first 6 rows seem to contain data.
• On the SLS, the pattern in packet type 9 does not encode a 14-bit code like the SP7+. The start bit only appears near the start and end of the capture, with 154 bits in between.
• Type 11 packets (which contain pressure in the first 6 rows), have more data: Row 7 seems related to pressure. Then row 8 to 13 seem to encode 3 bits using the 2 rows per bit scheme. Then row 14 to 16 seem to encode 3 bits using 1 row per bit. This data varies. But it seems like too little data for tilt?

So unfortunately it's not immediately obvious how the tilt is encoded. I don't see anything that's obviously frequency modulated.

Since the pens already appear to contain a second transmitter for the eraser, it could even be something like: there's another transmitter slightly behind the main transmitter, and you can determine its position relative to the screen and then combine with the position of the main transmitter to determine pen orientation...

[quo]

I've cleaned up some of my parsing code and uploaded it here:
https://github.com/quo/surface-parser

If anyone wants to have a look at the tilt data themselves, you can run the parser with the dft option:
sudo ./surface-parser.py /dev/ithc --ithc --dft

As you move the pen around near the screen, you should see a colorful display of the pen data:

You will probably have to fullscreen your terminal or decrease the font size to see everything correctly.

For example, on the right side of the output, the first six digits after "11x" (and repeated after "y") represent the pen tip pressure.

Please let me know if you spot anything that correlates strongly with the tilt angle (or if you notice anything else interesting).

[NP-chaonay]

Please let me know if you spot anything that correlates strongly with the tilt angle (or if you notice anything else interesting).

Testing and Analysis progress ( T: testing result created (tick marked): both testing gathering and analysis done )

• Pen tip
• • side key face up
• • • tilt up/down/left/right
• Eraser tip
• • side key face up
• • • tilt up/down/left/right

Test analysis will be here
PS: priority of the analysis is lower than the issue quo/iptsd #5

[quo]

Closer inspection of the DFT bins shows that some of the data does actually have a different position. So it seems there is another transmitter in the pens.

The following table shows the transmitter for each DFT row (a=primary, b=secondary):

	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
type 6	a	b	b	?	?	?	b	b
type 7	a	b	a	a	b	b	?	?	?	?
type 8	a	b	a	a	b	b	?	?	?	?
type 9	a	a	a	a
type 10	a	a	b	b	a	a	b	b	a	a	b	b	a	a	b	b
type 11	a	a	a	a	a	a	a	b	b	b	b	b	b	b	b	b

Based on this, I've added position and tilt decoding to surface-parser.py. The parser will now show four numbers before "7x". These represent x position, y position, x tilt, and y tilt (where tilt is just the offset between the two transmitter positions).

If all pens have the exact same distance between the two transmitters, calculating tilt angles from the shift values is straightforward. To test this, we need to get tilt values for various angles from a few different pens.

So if anyone would like to help, please do the following:

• Get surface-parser from https://github.com/quo/surface-parser
• Run sudo ./surface-parser.py /dev/ithc --ithc --dft
• Press the pen against the screen
• In the output of the parser, look at the four numbers just before "7x"
• The last two of those numbers should be related to tilt; please post which values you get for various tilt angles, e.g. straight (should be near zero), 45 deg up/down/left/right, and (almost) 90 deg up/down/left/right.
• Also please check the tilt values when using the pen upside down

[freak007]

This this the output of the parser for each movements/inclinations:
From center to 45 ° up 45up.txt
From center to 45 ° right 45right.txt
From center to 45 ° left 45left.txt
From center to 45 ° down 45down.txt

[quo]

Thanks! Values seem be approximately in the 95 to 110 range. So that would mean the distance between the transmitters is around 6 mm:

(95...110) / 100 / sin(45°) * 259.78 mm / 63 = 5.54...6.42 mm
(95...110) / 100 / sin(45°) * 173.19 mm / 43 = 5.41...6.27 mm

[quo]

Implemented in linux-surface@b941da4