While planning the implementation of the landscape mode, it occurred to me that it would be much easier to just handle framebuffer rotation as it only requires a transformation of the touch input coordinates instead of having to implement these transformations in a myriad of intermediate functions.
I'll expose my understanding of the situation on the
Glo HD and then try to generalize:
- When the framebuffer rotation is 270° in the clockwise direction, the device is in portrait mode with the logo at the bottom.
- The touch input coordinates are relative to the 0° rotation.
- Therefore, the transformation that we need to apply to the touch coordinates (swap x and y and mirror x) is just a consequence of the 270° rotation.
Some devices (
Aura HD,
Aura H₂O and
Aura H₂O Edition 2 according to
KSM) require a different rotation to accomplish the same result. If we interpret the rotation as 90° clockwise, then the touch input transformation, should be to swap
x and
y, and mirror
y. This isn't the case. One way of making sense of this is to consider that we're dealing with a 90° rotation in the counter clockwise direction.
Does this quirk have to do with a particular framebuffer depth, as the comments in
FBInk seem to indicate?
There's also the
Aura H₂O Edition 2 Version 1: the
x axis isn't mirrored on this device. This means that we can't interpret the display coordinates as a rotation of the touch coordinates.
In any case, if you have one of the aforementioned devices, I would appreciate if you could provide an interpretation for the 0, …, 3 rotation numbers in regard to their meaning in an operational Linux framebuffer.
When I echo
0, …, 3 to
/sys/class/graphics/fb0/rotate I can observe the changes in the output of
fbset. In particular,
xres_virtual * yres_virtual changes. Does that mean I have to call
mremap when I switch from portrait to landscape and vice versa? Or maybe I'm doing things wrong and I should just pass
fix_info.smem_len as second argument to
mmap?