Hi Matthijs,
Am 03.11.2018 um 07:51 schrieb Matthijs van Duin matthijsvanduin@gmail.com:
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.
Well, the /root/tiler-ctl simply unloads the module and reloads with different fbdev_rotation parameters.
This is easier that changing the command line for every device.
LetuxOS kernel is thought to be (mostly) device independent, so it uses a static command line and only the device tree is different.
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.
Ah, no. My description wasn't precise. There is only black picture for 90/270.
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:
- you're using software rotation, or
- you're using xorg-video-omap, which has always worked (even without
my patches).
I think I use Driver "omap" but xrandr refuses to rotate left/right unless your patches are included. I have not checked which one does make the difference.
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:
- (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:
- 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:
- (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?
Well, if people say that this are patches to make use of the OMAP5 TILER and some change from 4.15 to 4.16 has broken TILER rotation, the first order assumption is that there are commands to program the TILER.
Of course your description and my now a little increased understanding is that TILER control is already part of omapdrm - but not enabled in a way that we can simply rotate the framebuffer.
So your patches do that "higher level" stuff.
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).
My new "solution" (also a hack) removes your drm_kms_helper patch and replaces it by a different way to read and apply the fbdev_rotation parameter.
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
Ah, good to know!
BR and thanks, Nikolaus