Quote:
Originally Posted by frostschutz
@fastrobot: sorry, it seems I inadvertently abducted your thread, I was referring to my own program earlier  (which I wrote because your fbswitch inspired me to do so) |
Oh, I see.
Quote:
It's odd, I thought my workaround worked, but it actually stops working after a reboot.
If you write to /sys/class/graphics/fb0/rotate, the value you write is flipped.
And then the PUT/GET_VINFO syscalls flip too!
But if you never wrote to /sys/class/graphics/fb0/rotate at least once, PUT/GET_VINFO doesn't flip!
 Huuuh?
Now how to hunt for the rotate flippery flag that's hidden somewhere in the bowels of this ... module ... thing.
|
It would be nice if was compiled as a module... but it's actually absorbed into the kernel monolithic-ally. Only a handful of items appear to be actually compiled as a replace-able module... *sigh*.
The generic framebuffer control stuff is going to be the same in all kernels, because the processor itself has the eink controller built in. So - Since I already know that the generic framebuffer skeleton is in the linux kernel at eg: linux-2.6.35.3/drivers/video/imxfb.c -- that means the individual framebuffers driver programs are going to be in a subdirectory of that file; I think you are going to want the file called: linux-2.6.35.3/drivers/video/mxc/mxc_epdc_fb.c
if you cat /sys/class/graphics/fb0/name
Does it say mxc_epdc_fb ?
If so -- that names the file you want.
There are flags for rotation, and additional flags for flipping (mirroring). So there is a possibility of initializing the display incosistently. For two mirrors may be the same as a rotation...
If you're having trouble with boot inconsistencies, often just reading all the variables and then writing them back exactly the same as read will force initialization to be sane; Or else, just choose a state -- and initialize all variables in the framebuffer to always be in a specific state before nickel boots to guarantee the frame-buffer is in a sane state to begin with. There's no guarantee that Kobo initializes all the variables in the framebuffer, unless you can read their code and check. I been assuming they do initialize the screen, but after all the other inconsistencies ... maybe it is a bad assumption.