View Single Post
Old 10-24-2018, 06:35 AM   #226
baskerville
Evangelist
baskerville ought to be getting tired of karma fortunes by now.baskerville ought to be getting tired of karma fortunes by now.baskerville ought to be getting tired of karma fortunes by now.baskerville ought to be getting tired of karma fortunes by now.baskerville ought to be getting tired of karma fortunes by now.baskerville ought to be getting tired of karma fortunes by now.baskerville ought to be getting tired of karma fortunes by now.baskerville ought to be getting tired of karma fortunes by now.baskerville ought to be getting tired of karma fortunes by now.baskerville ought to be getting tired of karma fortunes by now.baskerville ought to be getting tired of karma fortunes by now.
 
baskerville's Avatar
 
Posts: 446
Karma: 305160
Join Date: Aug 2015
Device: Kobo Glo HD, Kobo Aura ONE
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?
baskerville is offline   Reply With Quote