I like how the screen is forcing you to get the rotation to work, unlike the Pandora, where rotating the screen simply doesn't exist
Weird, I haven't looked in detail but I think I've seen stuff for the omap3's rotation engine (VRFB) in kernel as well. But I guess maybe noone took the effort to make all the ingredients work together properly for the desired end result?
Will that TILER thing also be able to do the trick for the HDMI out? Rotating the screen is awesome for coding, it would be sad if that doesn't work.
That's a question worth repeating. I suspect, since he's working on a devboard connected to a screen, this is actually rotating the HDMI out at present, and hopefully it's just a matter of switching the target to make it rotate the LCD out instead.
Actually mostly my effort has been on fixing slowness of cpu access to buffers allocated in tiler memory, or (in this case) getting buffers to be allocated in tiler memory in the first place.
Once the framebuffer is there I know (and have verified) that DSS can scan it out in any orientation. Its rotation can be changed with one flip of a switch (or rather one DRM_IOCTL_MODE_ATOMIC setting the "rotation" property of the relevant layer):
(Yes, I managed to fix the stride issue with mmap()ing the fbdev
At least, if you don't mind the kernel oopses.)
Making the rotation happen by default for the built-in lcd screen (invisible to userspace) would be the finishing touch, and mostly just requires the kernel to meddle a bit with metadata to lie about the true dimensions and orientation.
I do still wonder if it'll be possible to rotate both displays independently (you'd want the internal LCD to be rotated, but normally not the HDMI out).
Yes. Specifically DSS supports 4 layers (total, not per output) that have independent buffers, pixel format, rotation/mirroring, scaling (for 3 of the layers), cropping, positioning, and z-order relative to other layers on the same output. Every layer can have an alpha channel and each output has a configurable solid background color (default black) to deal with pixels not covered by any fully opaque layer.
I do have a screen mount that does allow the screen to be switched edge on, but you don't want a simple rotated 16:9 framebuffer for that, you want the OS to configure a new 9:16 framebuffer, render to that and then rotate it, so that when the screen unrotates it by virtue of being on its side, text it still the right way up.
You mean exactly what xrandr --rotate does?
For ±90-degree rotation you'll always need to reconfigure the framebuffer dimensions since a 16:9 framebuffer rotated 90 degrees obviously does not fit on a 16:9 display. This is also plainly visible in my demo above (where I just positioned it randomly for fun). That's also why I mentioned the need to lie about the true dimensions of the screen to finish things off: fbdev needs to allocate and advertise a 1280 x 720 framebuffer, so that when rotated it'll fit neatly on the 720 x 1280 display.
