On Tue, 23 Oct 2018 at 19:42, H. Nikolaus Schaller hns@goldelico.com wrote:
- in xserverrc (should not make a difference if a systemd rule is used): /root/tiler-ctl 270
Note that rotating the framebuffer should not require any tools at runtime. Adding drm_kms_helper.fbdev_rotation=8 (it was 8 right? or 2?) to the kernel parameters should suffice.
this already makes the console rotate (except that there is no visible cursor for 90/270 and cat /dev/urandom >/dev/fb0 also does not show a pattern)
But other than this the console still works normally, i.e. text still shows up? That's... really bizarre.
Note btw that using read() or write() on /dev/fb0 (e.g. with cat) uses the kernel-mapping of the fbdev (like the framebuffer console) rather than a userspace-mapping (like every other fbdev client, including xorg-video-fbdev), and the code paths involved are quite different.
- xrandr --output Unknown16-1 --rotate right / left / normal / inverted shows all 4 rotations
That either means: 1. you're using software rotation, or 2. you're using xorg-video-omap, which has always worked (even without my patches).
On Thu, 25 Oct 2018 at 03:14, Michael Mrozek EvilDragon@openpandora.org wrote:
If you're using X with omapdrm or modesetting, the framebuffer isn't used and thus, you are not using TILER.
That's not accurate. There are two parts to my patches: 1. (tiler/fast) Improve performance of userspace mappings of TILER-allocated framebuffers. 2. (tiler/fbdev) Hack the legacy fbdev to allocate it in TILER and rotate it.
The effect on X11 depends on the video backend used: 1. xorg-video-fbdev: simply renders into the legacy fbdev hence will be rotated without being aware of it. No xrandr support unless emulated (slowly) in software. 2. xorg-video-omap: does not use the legacy fbdev. This supports rotation and has always used TILER. It benefits from the performance improvements of my patches. 3. xorg-video-modesetting: does not use the legacy fbdev. Its attempts to rotate will fail because it uses "dumb" buffers which are not allocated in TILER. I did once make a patch that forces "dumb" buffers (patch/tiler-buf-dumb) to be allocated in TILER, but this breaks all dma-buf users (such as SGX) because dma-buf export of TILER buffers was never implemented correctly in omapdrm.
On Fri, 26 Oct 2018 at 19:12, H. Nikolaus Schaller hns@goldelico.com wrote:
The problem is that I have not even the tiniest idea how the tiler patches work and make use of the TILER. They basically modify frame buffer layout and enable some more write modes and user-space mapping.
The crucial changes are: 1. (patch/tiler-buffer-fbdev) allocate a tiled buffer in omap_fbdev_create (pass OMAP_BO_TILED_32 to omap_gem_new) 2. (patch/tiler-fbdev) add a kernel parameter to set the rotation of the legacy fbdev
It all ended up a bit hacky, for a large part because omapdrm had no support for kernel-mapping of tiled buffers and I wasn't sure how to implement it properly :P
But that is all. There is no explicit code in the patch set to write any TILER control register differently
Why would you expect any?
On Tue, 30 Oct 2018 at 21:20, H. Nikolaus Schaller hns@goldelico.com wrote:
So this has something to do with panel orientation!
It may be in conflict with our TILER code and tiler-ctl...
I agree, it sounds like there's good potential for interaction. It also sounds like it could at least replace the final commit of my patch/tiler-fbdev branch, though I haven't yet looked at it to confirm (but I will after sending this email).
if (rotation != DRM_MODE_ROTATE_180 || !plane->rotation_property) { fb_helper->sw_rotations |= rotation; return; }
which makes me think that this code indeed disables hardware rotation for /dev/fb0.
No, plane->rotation_property != NULL, so it should not use software rotation.
It may still use TILER for X11. But I have no means or do not know any means to test if TILER is used or not.
grep rotation /sys/kernel/debug/dri/[0-9]/state
Matthijs