On Di, 2018-10-23 at 19:42 +0200, H. Nikolaus Schaller wrote:

Are you sure you're even using TILER for X?

Kernel 4.15 still showed the console on the screen with rotated TILER- Setting, so the full framebuffer was working. If the framebuffer / console doesn't show, something is broken...

If you're using X with omapdrm or modesetting, the framebuffer isn't used and thus, you are not using TILER.

Of course, rotating with xrandr works, but it has MASSIVE slowdowns.

What driver are you using for X in your setup?

Hi, Tiler rotation works for me with latest kernels for me. It was only broken between 4.19-rc1 and 4.19-rc5. It could be a different user-space setup.

Here is how I do the setup:

1. boot
2. in xserverrc (should not make a difference if a systemd rule is

used): /root/tiler-ctl 270 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) so maybe the console or /dev/fb0 is not aware of TILER rotated framebuffer. 3. start Xorg 4. xrandr --output Unknown16-1 --rotate right / left / normal / inverted shows all 4 rotations

Otherwise I have no idea how I could help here...

BR, Nikolaus

...

Am 23.10.2018 um 01:38 schrieb Michael Mrozek < EvilDragon@openpandora.org>:

Hi,

as we probably all know, TILER doesn't work with the latest kernel versions for some reasons. Hopefully, it's something simple, but still someone needs to look at it.

The reason I'm asking is not just because the OS would be more usable, but as part of the test is the pandora_input_tester which doesn't fully show because of the missing rotation.

Does anyone has the time to look into that, so we have a usable system again?

-- Greetings,

Michael Mrozek

---

OpenPandora GmbH CEO: Michael Mrozek

Schäffbräustr. 11 85049 Ingolstadt Germany Tel.: +49 841 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt

---

eMail: mrozek@openpandora.org

---

Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel

Am Donnerstag, den 25.10.2018, 06:50 +0200 schrieb H. Nikolaus Schaller:

Hi,

...

Are you sure you're even using TILER for X?

I assume yes. Because tiler-ctrl has a visible effect. And when removing the TILER patch set compeletely, xrandr refuses to rotate.

That would be weird, as I've used xrandr before to rotate screens before we even HAD the TILER patches. Not sure if I did it with OMAP-Drivers though.

So it is at least using something from the new patches.

Yes - but it should already show the rotated console. It did this fine with Kernel 4.15.

So while something may be working, it shows it's not really working correctly.

...

Kernel 4.15 still showed the console on the screen with rotated TILER- Setting, so the full framebuffer was working. If the framebuffer / console doesn't show, something is broken...

I am not sure about this as framebuffer seems to be deprecated and there have been patches to remove some framebuffer things from kernel. But I have not analysed what they do.

It's not deprecated, some CALL it deprecated but it's still being used by (mostly) embedded devs and it's not removed.

It has been improved with Kernel 4.19, here is some more detail:

https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.19-FBDEV-Def...

...

If you're using X with omapdrm or modesetting, the framebuffer isn't used and thus, you are not using TILER. Of course, rotating with xrandr works, but it has MASSIVE slowdowns. What driver are you using for X in your setup?

Driver "omap" And xorg package from Debian Jessie.

Does rotating the screen give a huge performance hit?

...

...

Hi, Tiler rotation works for me with latest kernels for me. It was only broken between 4.19-rc1 and 4.19-rc5. It could be a different user-space setup.

Here is how I do the setup:

1. boot
2. in xserverrc (should not make a difference if a systemd rule is

used): /root/tiler-ctl 270 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) so maybe the console or /dev/fb0 is not aware of TILER rotated framebuffer. 3. start Xorg 4. xrandr --output Unknown16-1 --rotate right / left / normal / inverted shows all 4 rotations

Otherwise I have no idea how I could help here...

BR, Nikolaus

...

Am 23.10.2018 um 01:38 schrieb Michael Mrozek < EvilDragon@openpandora.org>:

Hi,

as we probably all know, TILER doesn't work with the latest kernel versions for some reasons. Hopefully, it's something simple, but still someone needs to look at it.

The reason I'm asking is not just because the OS would be more usable, but as part of the test is the pandora_input_tester which doesn't fully show because of the missing rotation.

Does anyone has the time to look into that, so we have a usable system again?

-- Greetings,

Michael Mrozek

---

OpenPandora GmbH CEO: Michael Mrozek

Schäffbräustr. 11 85049 Ingolstadt Germany Tel.: +49 841 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt

---

eMail: mrozek@openpandora.org

---

Kernel mailing list Kernel@pyra-handheld.com http://pyra-handheld.com/cgi-bin/mailman/listinfo/kernel

-- Mit freundlichen Grüßen,

Michael Mrozek

---

OpenPandora GmbH Geschäftsführer: Michael Mrozek

Schäffbräustr. 11 85049 Ingolstadt Deutschland Tel.: 0841 / 990 5548 http://www.openpandora.de/ HRB 4879, Amtsgericht Ingolstadt

---

eMail: mrozek@openpandora.org

Hi,

Am 26.10.2018 um 19:12 schrieb H. Nikolaus Schaller hns@goldelico.com:

...

...

...

Kernel 4.15 still showed the console on the screen with rotated TILER- Setting, so the full framebuffer was working. If the framebuffer / console doesn't show, something is broken...

I did set up an SD card without X11 so that it does not disturb the console.

tiler-ctl 0 (the default) shows a non-rotated image, i.e. the cursor is binking in the lower left corner.

cat /dev/urandom /dev/fb0

writes a random picture.

After doing tiler-ctl 270 the screen is black.

And there is a difference between kernels.

4.15 (up to 4.15.17) is then showing the cursor in the upper left corner. And the cp command fills the image top down.

But with 4.16-rc1 (not -rc4 as with the Audio issue) the screen remains black and there is no fill by cp.

Now we can compare letux-4.15(.0) and letux-4.16-rc1.

There is no diff in device trees.

There are diffs in drivers/gpu/drm/omapdrm.

At a first glance they are mostly cosmetic or not related to TILER operation (but I may have missed something).

Then I compared letux_defconfig.

There is one suspicious entry, a new one introduced in 4.16-rc1:

CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=m

Looking for the code that is configured by it shows:

drivers/gpu/drm/drm_panel_orientation_quirks.c:

new file introduced as <404d1a3edc387>

Kconfig:

# Separate option because drm_panel_orientation_quirks.c is shared with fbdev config DRM_PANEL_ORIENTATION_QUIRKS tristate

The commit message says:

commit 404d1a3edc3873b339198ec3f3d6a09be2ddda4f Author: Hans de Goede j.w.r.degoede@gmail.com Date: Sat Nov 25 20:35:48 2017 +0100

drm: Add panel orientation quirks, v6.

Some x86 clamshell design devices use portrait tablet screens and a display
engine which cannot rotate in hardware, so the firmware just leaves things
as is and we cannot figure out that the display is oriented non upright
from the hardware.

So at least on x86, we need a quirk table for this. This commit adds a DMI
based quirk table which is initially populated with 5 such devices: Asus
T100HA, GPD Pocket, GPD win, I.T.Works TW891 and the VIOS LTH17.

This quirk table will be used by the drm code to let userspace know that
the display is not mounted upright inside the devices case through a new
panel orientation drm-connector property, as well as to tell fbcon to
rotate the console so that it shows the right way up.

Changes in v5:
-Add a kernel-doc comment documenting drm_get_panel_orientation_quirk()
-Remove board_* matches from the dmi-matches for the VIOS LTH17 laptop,
 keeping only the (identical) sys_vendor and product_name matches.
 This is necessary because an older version of the bios has
 board_vendor set to VOIS instead of VIOS

Changes in v6:
-Add reference to added kernel-docs in Documentation/gpu/drm-kms-helpers.rst

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171125193553.23986-3-hdegoede@redhat.com

See: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h... and: https://elixir.bootlin.com/linux/v4.16-rc1/source/drivers/gpu/drm/drm_panel_...

So this has something to do with panel orientation!

It may be in conflict with our TILER code and tiler-ctl...

But:

/* There are no quirks for non x86 devices yet */

It seems to depend on CONFIG_DMI which we do not have set. I.e. this is (almost) dead code on ARM.

But it might still have a side-effect on the console if we tell DRM that we have rotation...

Or we must add a Pyra quirk here so that the rotation defined by tiler-ctl is not undone somewhere else in the fbcon or the fbdev driver.

A hint for such a mixup of rotation setup is here:

https://elixir.bootlin.com/linux/v4.16-rc1/source/drivers/gpu/drm/drm_fb_hel...

This function is new and was introduced by:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h...

and probably drm_setup_crtc_rotation() conflicts with

http://git.goldelico.com/?p=letux-kernel.git;a=commitdiff;h=259bfe5d9140c27f...

So in summary it looks as if a solution for rotated panels was developed upstream. But we did not notice.

Any since we are not heavily working on pushing our work as fast as possible upstream, kernel maintainers also didn't notice that we are working on it.

Finally both solutions conflict. That happens if we deviate too much from mainline or forget to upstream something.

That are my new findings for this topic.

Solutions are welcome or ED can't finish the hardware tester script used for mass production.

Maybe a simple hack to disable drm_setup_crtc_rotation() suffices. Or moving the fbdev_rotation module parameter to drm_panel_orientation_quirks.c

BR, Nikolaus

On Tue, 23 Oct 2018 at 19:42, H. Nikolaus Schaller hns@goldelico.com wrote:

2. 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.

4. 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

Am 04.11.2018 um 18:46 schrieb Matthijs van Duin matthijsvanduin@gmail.com:

On Sat, 3 Nov 2018 at 07:51, Matthijs van Duin matthijsvanduin@gmail.com wrote:

...

...

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.

D'oh, I misread that. This will indeed need to be fixed to support 90/270 degree rotation.

We should definitely arrange for the panel orientation to be declared properly now that there's a mechanism for it, instead of the hack with a kernel parameter.

Agreed.

This doesn't require any of the "orientation quirks" stuff, you can also set connector->display_info.panel_orientation and then call drm_connector_init_panel_orientation_property(connector, 0, 0).

The question is how and where this should be called.

Ideally this panel orientation parameter should not even be any "orientation quirks" or kernel parameter. It should be a property of either the display controller or the panel in the device tree.

Maybe the best next steps would be to discuss this with Hans de Goede and Tomi Valkainen. To get the patches upstream.

Would you want to do this yourself or should I take the lead of editing and sending patches (and you jumping into the discussion for details I can't explain)?

Although, I suppose it might be nice for testing purposes to add an orientation quirk that obtains its value from a kernel parameter.

Indeed. That is why I kept the parameter (+ tiler-ctl tool) for the moment.

BR and thanks, Nikolaus

* Matthijs van Duin matthijsvanduin@gmail.com [181105 00:14]:

I'm currently working on being able to properly map a tiled framebuffer without the hideous zero-percent-chance-of-upstreaming hacks that are in my patches as they are right now. I also think I understand how to get dma-buf export working for them.

Wow, getting that merged would be nice!

Regards,

Tony

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:

...

2. 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.

...

4. 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).

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:

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?

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