View Single Post
Old 01-19-2018, 06:44 PM   #12
tshering
Wizard
tshering ought to be getting tired of karma fortunes by now.tshering ought to be getting tired of karma fortunes by now.tshering ought to be getting tired of karma fortunes by now.tshering ought to be getting tired of karma fortunes by now.tshering ought to be getting tired of karma fortunes by now.tshering ought to be getting tired of karma fortunes by now.tshering ought to be getting tired of karma fortunes by now.tshering ought to be getting tired of karma fortunes by now.tshering ought to be getting tired of karma fortunes by now.tshering ought to be getting tired of karma fortunes by now.tshering ought to be getting tired of karma fortunes by now.
 
Posts: 3,462
Karma: 2909989
Join Date: Jun 2012
Device: kobo touch
rotation problem, intro

I give here, in the spoiler, a short account of the rotation problem, how I tried to solve it, and failed.
Spoiler:
I try to describe the problem as I understand it. Since I do not have a model with a rotation problem myself, I know the details only from user reports. It is not unlikely that I might have misunderstood some reports.
It started with the Aura HD (and the Aura H2O, and Aura H2O2 seem to show the same behaviour). KSM appeared upside down on this model the very first time after the device was powered on, from that point on however with every new call, KSM was displayed correctly. The work around was to start the KSM menu once, and exit it immediately without user interaction. I do not like this workaround, but if it still works, let us keep it for the moment as it is.

The next problem was seen after one exited nickel to return to KSM. What happens is that nickel, on some models needs (and therefor sets) a different rotation value (/sys/class/graphics/fb0/rotate) than KSM needs. Therefore after exiting nickel and before calling a KSM application, one has to reset the rotation value. On the problematic models there is a strange behaviour: The rotation value is actually different from what one sets. For instance, if one sets the value 0, it actually takes the value 2; or if one sets the value to 3, it takes the value 1, and the other way round. Starting from this point the rotation value is unstable: KSM has a rotated screen, and with each new call turns 180.
The workaround was to (try to) set the needed value, and then set the resulting value again, in order to get the wished result:

Code:
code fragment 01
### currentRotation contains the value needed by KSM
  echo "$currentRotation" > /sys/class/graphics/fb0/rotate
  cat /sys/class/graphics/fb0/rotate > /sys/class/graphics/fb0/rotate
At a certain point nickel started to change the display depth from 16 to 32 bits per pixel, whereas KSM still needs 16 bits depth. We therefore had to reset the display depth after running nickel, and did this by adding:
Code:
### code fragment 02
### fbgeometry contains the geometry settings needed by KSM, which include the depth value
fbset -${fbgeometry}
Since a call to fbset seems also to destabalise the roation value, I tried to counteract this by adding:
Code:
### code fragment 03
if [ "$currentRotation" != "$(cat /sys/class/graphics/fb0/rotate)" ]; then
  cat /sys/class/graphics/fb0/rotate > /sys/class/graphics/fb0/rotate
fi
As it turned out, this does not work. Therefore, I would like you to use the webinterface, in order to do some experiments.
The first is to try a completely new approach.
If this does not work, we will try to go through the code fragments 01 - 03 manually, watch at each point how the different values change, and maybe find something that helps us.
For the first experiment, however, reading this is not necessary. Therefore if you like, go directly to next post.
tshering is offline   Reply With Quote