On 08/03/14 18:15, Michael Mrozek wrote:
Hi,
as we now have the display working fine, we should try to see if it is usable without any issues for us....
As you know, the display is - like most displays theses days - in portrait mode (1080x1920), but we want to use it in landscape mode (1920x1080).
My first thought here is: you've got the wrong display =). Rotation never comes free.
Ideally, this should be implemented as low-level as possible and be done by some scaler / rotation hardware, so that the main Linux OS sees this as a 1920x1080 display. It would also be great if Linux would offer various resolutions (like 1280x720) and our low-level implementation would scale this automatically as well.
Of course, using the CPU for stuff like that is not really useful. Android phones use OpenGL ES, but we don't want that, as all programs (directly writing to the framebuffer, X11, SDL, etc.) should work out of the box.
Tomi, that's something you might know better than any of us: Is something like that possible with the OMAP5 hardware?
A rotation and scalation using some hardware, which could be implemented low-level (in the display-driver, I guess).
We'd need to make sure the rotation works properly with VSync as well, otherwise we'd have ugly artifacts when games use scrolling.
I'm not that deep into proper implementation of stuff like this, but hopefully, Tomi and notaz have an idea here how to achieve that.
With the restrictions you described above, I think the only option is to use OMAP5's TILER block to handle the rotation. omapdrm supports TILER, but omapfb does not.
Scaling in generic manner is not possible. The DSS hardware can scale video overlays, but the userspace needs to specifically use that functionality. The GFX overlay, which is normally used for the user interface, cannot be scaled.
Tomi