Hi Matthijs,
Am 01.02.2017 um 18:37 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
On 1 February 2017 at 14:49, H. Nikolaus Schaller hns@goldelico.com wrote: Or is the tiler rotating the HDMI port which is also enabled in my setup?
It rotates any output of the legacy fbdev framebuffer, of which there is only one per DRM device. I'm not sure which output it will pick if more than one is connected.
Ah, I see. I am not using fbdev for X11 because it did not work any more with debian jessie.
This would explain why I got a rotated console but no rotated pyra logo on my patched PyraOS image (X11 was broken and hence the console became visible).
Applications that perform DRM modesetting does not get automatically rotated currently, but they can request any rotation of a framebuffer via the DRM api provided the buffer is allocated in tiler memory. Either they can use libdrm-omap for that allocation (like e.g. the xorg-video-omap driver) or you can apply my patch/tiler-buf-dumb to force all buffer allocations into tiler memory.
Since I use the xorg-video-omap driver the best thing seems to be to try the patch. And if I understand the recommendations correctly, then xrandr should be able to rotate or who else is controlling the DRM api?
I've considered implementing rotation transparently for all drm clients (including the legacy fbdev), and I still may, but it is a non-trivial amount of work and may not be worth it since only one process can do modesetting at any given time, so normally this task in centralized in one of a very small number of applications (x11, wayland, plymouth...) and they all use libdrm so it could also be implemented there instead.
I also see it not as the most urgent task. I just want to hack a working demo/testing setup...
BR and thanks, Nikolaus