View Single Post
Old 10-05-2012, 03:13 PM   #207
geekmaster
Carpe diem, c'est la vie.
geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.geekmaster ought to be getting tired of karma fortunes by now.
 
geekmaster's Avatar
 
Posts: 6,433
Karma: 10773668
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
Quote:
Originally Posted by hawhill View Post
Oh, dang, the ioctl() for updating the eink screen is taken 1:1 from the K3 -- probably it's a bit different on the K5. However, the K4 seems to take it quite well. But that's along the lines of what you posted earlier, geekmaster: K4 in "normal" mode is very much the K3's eink driver. Is there a region-based update for the K5? I'd rather not call eips, there would likely be something like on the K3, even an ioctl() perhaps?
The K5 eink update ioctl() gets passed a data structure that is different and INCOMPATIBLE between 5.0.x and 5.1.x firmware. You cannot even use the mxcfb header file if you want compatibility with both. See my geekmaster kindle video play for an example of how I used copies of the structures instead of a header file. It works for all eink kindle models (but the paperwhite will need updates first)...

The gmplay program does not do dithering (that is done by raw2gmv, also in that thread somewhere). And raw2gmv dithers without a dither table, doing direct differential calculations of dither thresholds instead. That allows dynamic contrast and brightness adjustments, besides the fact that CPU calculations are faster than DRAM memory access table lookups in many cases on modern computers.

And please feel free to borrow my code.

But for a preliminary test, I suggesting replacing the ioctl call with system("eips ''"). That works everywere. And it even automatically selects the update type (including area updates) when it can...

Even my GMLIB code falls back to eips calls if the ioctl calls fail.

Last edited by geekmaster; 10-05-2012 at 03:22 PM.
geekmaster is offline   Reply With Quote