Quote:
Originally Posted by NiLuJe
Does that actually result in fbink/fbdepth/ftrace reporting a landscape rotation as the canonical one?
(i.e., does this *actually* rotate the framebuffer in some way, or does Nickel handle rotation entirely in software on that device).
If it actually rotates the framebuffer, I've got a wrong mapping in fbink; but if it's software rotated, it's working as intended  . |
It does appear to actually rotate the framebuffer.
Portrait:
Code:
[FBInk] Detected a Kobo Glo (330 => Kraken @ Mark 4)
[FBInk] Enabled Kobo w/o Multi-Touch quirks
[FBInk] Clock tick frequency appears to be 100 Hz
[FBInk] Screen density set to 212 dpi
[FBInk] Variable fb info: 758x1024, 32bpp @ rotation: 3 (Counter Clockwise, 270°)
[FBInk] Fixed fb info: ID is "mxc_epdc_fb", length of fb mem: 3145728 bytes & line length: 3072 bytes
[FBInk] Canonical rotation: 0 (Upright, 0°)
[FBInk] Fontsize set to 16x16 (IBM (Default) base glyph size: 8x8)
[FBInk] Line length: 47 cols, Page size: 64 rows
[FBDepth] Screen is 758x1024 (768x1024 addressable, fb says 768x1024)
[FBDepth] Buffer is mapped for 3145728 bytes with a scanline stride of 3072 bytes
Landscape:
Code:
[FBInk] Detected a Kobo Glo (330 => Kraken @ Mark 4)
[FBInk] Enabled Kobo w/o Multi-Touch quirks
[FBInk] Clock tick frequency appears to be 100 Hz
[FBInk] Screen density set to 212 dpi
[FBInk] Variable fb info: 1024x758, 32bpp @ rotation: 0 (Upright, 0°)
[FBInk] Fixed fb info: ID is "mxc_epdc_fb", length of fb mem: 3145728 bytes & line length: 4096 bytes
[FBInk] Canonical rotation: 1 (Clockwise, 90°)
[FBInk] Fontsize set to 16x16 (IBM (Default) base glyph size: 8x8)
[FBInk] Line length: 64 cols, Page size: 47 rows
[FBInk] Horizontal fit is perfect!
[FBInk] Vertical fit isn't perfect, shifting rows down by 3 pixels
[FBDepth] Screen is 1024x758 (1024x768 addressable, fb says 1024x768)
[FBDepth] Buffer is mapped for 3145728 bytes with a scanline stride of 4096 bytes
Your patch does fix it! The canonical rotation for Nickel's landscape is now reported as CCW, and ftrace behaves correctly in all 4 rotations. The cursor in my remote works in landscape too
Quote:
Originally Posted by NiLuJe
That also means things gets wonky if FBInk is not the one that triggered the rotation, because the only thing we can do is query the accelerometer... and that can be finicky as hell . |
I have noticed the accelerometer rotation detection occasionally being out of sync with Nickel on my Sage. Think I'll make sunxi_force_rota user-configurable in my remote so people can lock it to a certain rotation if they want.