From what I gather, it's generally a funky mess, and there was a point in time when it was even messier, with vinfo rotate basically bearing no actual relation to what the fb was expecting (... well, even less than now), and where forcing it to a specific value yielded massively weird results. I wasn't playing with fb at the time, so @frostschutz probably remembers more about this than I do
.
From my very small sample of *one* H2O: the touch panel never ever rotates, and *probably* matches the "native" boot rotation of the FB (which appears to be something like a reverse landscape, so, CCW?, despite reporting 0).
On current FW, at startup, Nickel puts the fb in 32bpp mode, and rotates it in portrait. That ends up being reported as a CW rotation (1), so, okay, why not.
Pickel, which is used to display the three dots progress bar, among other things, puts it back in 16bpp mode, in landscape (but the inverse of the boot landscape), which is reported as 2 (UD). AFAICT, that was the state Nickel kept in FW before the 32bpp switch.
(Fun fact: that's the reason why KFMon's initial welcome message is upside down: I'm applying the pickel rotation to a fb that's still in early boot rota).
TL;DR: vinfo rotation appears to be unfortunately barely useful on its own, because, when it works, it appears to be relative to the native rotation, which may not be Portrait. It's pretty much the same on Kindle, where it varies wildly between models.
EDIT: As for smem_len, it doesn't change between 16bpp and 32bpp, which is a bit weird, but saves me a remap. One possible explanation might be that there was probably supposed to be panning/flipping support in 16bpp (despite, again, that not being made apparent elsewhere
)?
(Or a weird shadow buffer optimization like there was on the old einkfb controller?)
Since I barely care about 16bpp anyway, I'm not overly concerned with the fact that I may be mapping double what I actually need. It's certainly still fb memory, so, nothing ever blows up, even with a full memset on it.
So far, trusting smem_len hasn't bit me on the ass on Kindle & NTX devices, but I know from KOReader that it's massively broken on PocketBook devices, for instance...
EDIT²: It shouldn't bear any relation to landscape/portrait, because it should always at least be equal to line_len * yres_virtual (* bufferN if offset > 0, which it never is), and that's usually been sane in my experience.
EDIT³: Fun fact: rotation is weird pretty much everywhere: my desktop's EFI framebuffer happily reports
Code:
[FBInk] Variable fb info: 1920x1080, 32bpp @ rotation: 0 (Upright, 0°)
[FBInk] Fixed fb info: ID is "simple", length of fb mem: 8847360 bytes & line length: 8192 bytes
so, 0/U for landscape
. (For those doing the smem_len maths at home, yeah, virt dims are 2048, except they're not reported as such, because
everything is terrible).
Granted, that may or may not be a factor here:
Code:
zgrep ROTA /proc/config.gz
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set