Quote:
Originally Posted by hawhill
Also, in the back of my head I'm remembered of the thread that was talking about modifying the K3 refresh by parametrizing the e-ink driver. I don't remember it to be a permanent change, though. But it definitely had to do with modifying the contrast ratio.
|
That one requires a modification to the e-ink driver module and a kernel module rebuild.
Although it has been copied (archived would be a better term) as part of the KUAL.system repository, it has never been included in any of the kernel module builds.
(nor into any of the kubrick builds - those use 'stock' images)
And as I recall (without pulling up the code), it is for the DX/DXG not the K3
- - - - -
O.P. wrote: "I have the same files on the device before and after using kubrick"
Two possibilities occur to me about that statement:
1) How does the O.P. know that?
Comparison of md5sums for each file would show that, a simple list of file names would not revel versions/build differences.
2) How could kubrick have run and still have the same files?
I suspect that kubrick is not running to completion on this device.
- - - - -
Another note:
O.P: "I just got it a few days ago" != "new"
The K3 has been out of production for awhile now.
No way to know what the prior owner(s) did to it.
- - - -
The display driver is partially compiled into the kernel (image) and partially supplied as kernel modules (part of the system image).
Two files, which **must** match in version and build.
My best __guess__ at the moment is mis-matched kernel/kernel modules.
Not likely if kubrick ran to completion - which we have yet to determine is happening.
But presuming that kubrick does not run to completion - then all bets are off for getting a "matched pair" on a used machine.
Without more specific details from the O.P. - - it is really hard to even guess.