View Single Post
Old 05-01-2012, 06:00 PM   #29
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 knc1 View Post
Your correct.
The ioctl() commands, once released, are supposed to be engraved in stone.

The addition of a new (or changed) one is supposed to overlap the continued existance of the one being replaced.

So the maintainer of the e-ink driver screwed the pooch on letting that change(s) in.
I guessed on what to set for the MARKER value in the structure passed to the ioctl() call. I suppose if I used an undocumented value that worked previously, there is no guarantee that it would continue working. The problem is that, there is no example code that I can find that calls this with parameters needed for the kindle (I modeled the call after code used for the illiad ebook).

From the GPL source code I determined the correct values for all fields except MARKER. Value 0 did not work, but value 1 DID work (but apparently not any more). I suppose I need to look in the kernel code for how it is used. The header file does not define any values for it that I can see.
geekmaster is offline   Reply With Quote