geekmaster touchscreen signature capture script

[geekmaster]

The error message from eips when displaying text off the end of a line shows that it is trying to use 768 pixels per line (xres_virtual) instead of 758 (xres). And yres_virtual shows that the framebuffer will hold 6 pages of data. My K5 had room for 2 pages of data, but twobob reported that his new K5 has a framebuffer that can hold 4 pages of data.

You can change the starting position of the displayed screen to any of those 6K framebuffer rows with by echoing the offset coords into a /sys/ file. And when scrolled, the system still uses offset zero. That way our native code could move the viewing window to the second page and use it without interference, while the system framework continues to use the hidden page zero...

[knc1]

Originally Posted by geekmaster

The error message from eips when displaying text off the end of a line shows that it is trying to use 768 pixels per line (xres_virtual) instead of 758 (xres). And yres_virtual shows that the framebuffer will hold 6 pages of data. My K5 had room for 2 pages of data, but twobob reported that his new K5 has a framebuffer that can hold 4 pages of data.

You can change the starting position of the displayed screen to any of those 6K framebuffer rows with by echoing the offset coords into a /sys/ file. And when scrolled, the system still uses offset zero. That way our native code could move the viewing window to the second page and use it without interference, while the system framework continues to use the hidden page zero...

I will understand that as: Close but no cigar.

Their math was wrong, but not in a way we can fix without a re-build of the driver.
Which might be fine for a handful of developers but isn't much help to the world full of Kindle owners.

Strange that sort of error got out of the development department.
A person would think there was a lot of hours spent looking at things on the display and someone would have noticed they where trying to write into the "over scan" part of the timing. (because somebody picked the wrong symbol name in the code)

Yeah, who (other than the end user) would notice a few missing pixels.

[geekmaster]

Originally Posted by knc1

I will understand that as: Close but no cigar.

Their math was wrong, but not in a way we can fix without a re-build of the driver.
Which might be fine for a handful of developers but isn't much help to the world full of Kindle owners.

The problem is that for my graphics code to continue to support all firmware versions for "all eink kindles" in both main and diags modes, I will have to compensate for this "math glitch", and then again in another way if and when they get around to fixing it in future firmware. Hopefully they will not do the "two incompatible ioctl structures with the same name" problem again like they did with 5.0.x and 5.1.x. Yuck...

[knc1]

If you get desperate enough, try loading the K5 driver modules in the Kpw kernel.
I don't recall lab126 using version locking on the kernel modules.

[twobob]

The 4bpp thing was from the official press release (It's linked in the thread you cite IIRC)

REALLY pleased to hear that is is not.

Typical shenanigans with the graphics, thanks for bringing this thread back to my attention guys..

[twobob]

Bump for awesomeness.

Thanks mate. most excellent work as ever

Spoiler:

unsigned short int sigvec[208]={
25113,
24090,
22812,
21278,
19745,
18723,
17957,
16169,
14381,
13360,
12339,
11318,
10554,
9790,
8516,
8008,
8526,
10061,
11596,
13643,
14667,
15690,
16714,
17994,
19273,
20809,
22345,
26954,
29260,
32846,
35922,
35922,
0,
32298,
30766,
29490,
27959,
26938,
25917,
25152,
23622,
22091,
20816,
19540,
18521,
17757,
18784,
20319,
21342,
22877,
24411,
26201,
27735,
29015,
30039,
29017,
27739,
26461,
27486,
28512,
29538,
30309,
30571,
29038,
28271,
26992,
25969,
24689,
23154,
21364,
17271,
14969,
13180,
11137,
9609,
7827,
7321,
7321,
0,
26240,
27004,
28024,
29303,
30330,
30078,
29571,
28806,
27778,
28028,
28281,
0,
28308,
29332,
31120,
32142,
33164,
35209,
35976,
0,
24727,
23963,
24480,
25253,
26791,
28067,
29086,
29594,
29855,
30372,
31655,
33448,
34980,
36002,
37022,
37786,
38548,
39053,
39046,
39040,
38266,
38266,
0,
35508,
36264,
37286,
38313,
38576,
37812,
37047,
35765,
35762,
0,
35781,
37317,
38340,
39362,
40896,
42173,
45749,
47282,
48560,
49581,
49581,
0,
33220,
32715,
32466,
32986,
34018,
35047,
36329,
37608,
39139,
39903,
40411,
41174,
41425,
41929,
42191,
42711,
43231,
44517,
46312,
47337,
48361,
49385,
50664,
51685,
52962,
53725,
56270,
57285,
58044,
58802,
59304,
59550,
59286,
58764,
57732,
56444,
53364,
52337,
50799,
49517,
48491,
46950,
45152,
44378,
44370,
44365,
44615,
45121,
47665,
49195,
51239,
53541,
55077,
56872,
58414,
58932,
58940,
58182,
58182,
0,
64241,
64239,
0,
0 };

[geekmaster]

Originally Posted by twobob

The 4bpp thing was from the official press release (It's linked in the thread you cite IIRC)

REALLY pleased to hear that is is not.

Typical shenanigans with the graphics, thanks for bringing this thread back to my attention guys..

Well, it technically *IS* 4bpp, but duplicated so it occupies 8bpp. In each byte, the top 4 bits is cloned into the bottom 4 bits. In my "newtrix" demo I have 8-bit dithering code that handles this "8-bit" video mode, and dithers it to provide the equivalent of 256 shades of grey.