Screen rotation

[timemaster5]

Hi, sorry for sending this question here, I tried to find some better place or documentation, but I wasn't successful. If you can point me to the right place, or some Slack/IRC anything better, it would be appreciated :)

Since this should be fully accelerated environment, I am sure there must be a way to rotate the screen without experiencing negative effect known from a raspberry pi (and maybe other boards), where rotated screen results in expensive software processing instead of accelerated output.

What would be the best place to dig for the configuration options, please?

[wouterlucas]

Have you tried display_hdmi_rotate on the RPI? I'd be really suprised if that has any negative processing/performance results.

From https://www.raspberrypi.org/documentation/configuration/config-txt/video.md:

display_hdmi_rotate | result
-- | --
0 | no rotation
1 | rotate 90 degrees clockwise
2 | rotate 180 degrees clockwise
3 | rotate 270 degrees clockwise
0x10000 | horizontal flip
0x20000 | vertical flip

[timemaster5]

Hello, thank you for your comment. Yes, I've tried everything. Here is the explanation:

Driving a portrait display is expensive.

The HVS (hardware video scaler) normally fetches all the source layers, format converts, resizes and blends the data "on-the-fly" for each horizontal output line of display output.

You can fetch horizontal lines of images from sdram in an efficient manner. It is not possible to fetch vertical lines of images from sdram in an efficient manner.

So when the display is portrait, the HVS doesn't composite on-the-fly. It has to write a landscape buffer to memory. It then has to use the transposer hardware to convert the landscape image to a portrait image, involving another memory read and write. It then finally fetches this portrait image and outputs to the display.

It is inevitable that performance for this case is worse. We can't fix that.

The only way to make this efficient is to remove the display_rotate config option, and explicitly render your openVG (or GL) rotated (which can be done very cheaply from the VG/GL APIs).

[wouterlucas]

Interesting, many thanks for the extra details. Everyday is a school day :)
I don't know if it is possible, but the EGL hooks are over at https://github.com/WebPlatformForEmbedded/WPEBackend-rdk/blob/master/src/bcm-rpi/renderer-backend.cpp

Or possibly higher up the WebKit stack. It's beyond my expertise, maybe @magomez has some pointers?

[timemaster5]

Glad to help :) I had to find out the hard way, unfortunately :( but never mind :)
Thank you for this, I think I need to try adding something like that:

dispman_element = vc_dispmanx_element_add ( dispman_update, dispman_display,
        0/*layer*/, &dst_rect, 0/*src*/,
        &src_rect, DISPMANX_PROTECTION_NONE, &alpha, 0/*clamp*/, DISPMANX_NO_ROTATE/*transform*/);

This comes from from some other code I found online, the point here is to pass the DISPMANX_NO_ROTATE settings, or it's alternative:

DISPMANX_NO_ROTATE = 0,
DISPMANX_ROTATE_90 = 1,
DISPMANX_ROTATE_180 = 2,
DISPMANX_ROTATE_270 = 3,

This is from userland source.

I am still a bit lost in layering WPE components (just need to read more about everything basically.. ), maybe the right way is to rotate the userland if that is the underlying layer? Just guessing, and I am very likely totally out at this point :)

(https://github.com/raspberrypi/userland/blob/master/interface/vmcs_host/vc_dispmanx_types.h)

[wouterlucas]

So it's WPEWebKit uses WPEBackend which takes WPEBackend-RDK for graphics/input.

I think what you are looking for sits here:
https://github.com/WebPlatformForEmbedded/WPEBackend-rdk/blob/master/src/bcm-rpi/view-backend.cpp#L176

You could write a patch against that and see if that rotates it :)

[timemaster5]

Oh, great! thanks for that, gonna try it now :)

[timemaster5]

Hm, it was fast :( maybe outdated docs? Anyway, keep digging.

Following this meta-wpe/wiki/Raspberry-PI

Maybe will get back to the builroot, it should use the same bundle (WPEWebKit, backend, backend-rdk), I was quite successful there.

Parsing recipes: 100% |################################################################################################| Time: 0:01:23
Parsing of 1942 .bb files complete (0 cached, 1942 parsed). 2638 targets, 366 skipped, 0 masked, 0 errors.
WARNING: No recipes available for:
  /home/timemaster/rpi-yocto/meta-wpe/recipes-bsp/broadcom-refsw/broadcom-refsw_%.bbappend
  /home/timemaster/rpi-yocto/meta-wpe/recipes-extended/aamp/aamp_git.bbappend
  /home/timemaster/rpi-yocto/meta-wpe/recipes-extended/aamp/gst-plugins-rdk-aamp_git.bbappend
  /home/timemaster/rpi-yocto/meta-wpe/recipes-graphics/wayland-egl-bnxs/wayland-egl-bnxs_git.bbappend
NOTE: Resolving any missing task queue dependencies
ERROR: Nothing PROVIDES 'gst-plugins-rdk-aamp' (but /home/timemaster/rpi-yocto/meta-wpe/recipes-wpe/wpeframework/wpeframework-plugins_git.bb DEPENDS on or otherwise requires it). Close matches:
  gst-plugins-bad
  gst-plugins-good
  gst-plugins-base
NOTE: Runtime target 'wpeframework-plugins' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['wpeframework-plugins', 'gst-plugins-rdk-aamp']
NOTE: Runtime target 'packagegroup-wpeframework' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['packagegroup-wpeframework', 'wpeframework-plugins', 'gst-plugins-rdk-aamp']
ERROR: Required build target 'wpe-eglfs-image' has no buildable providers.
Missing or unbuildable dependency chain was: ['wpe-eglfs-image', 'packagegroup-wpeframework', 'wpeframework-plugins', 'gst-plugins-rdk-aamp']

Summary: There was 1 WARNING message shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

[wouterlucas]

oh AAMP shouldn't be in the default dependency chain (tagging @Haseenamol), this is not correct:
https://github.com/WebPlatformForEmbedded/meta-wpe/blob/morty/recipes-wpe/wpeframework/include/streamer.inc#L35

The quick and dirty route around this, remove the streamer from the entire setup:
https://github.com/WebPlatformForEmbedded/meta-wpe/blob/morty/recipes-wpe/wpeframework/wpeframework-plugins_git.bb#L34

Just remove L34 and it should continue.

[timemaster5]

Now we are talking, cool. Moving forward, thank you!

[timemaster5]

Ok, there is one problem left with ccache, which comes from openembeded-core, full log is here. What is interesting, the problem is very old and already fixed.

I was trying to fix it by changing the commit id to download, which didn't work. I thought that is because of wrong ccache repo URL stated in openembedded-core/meta/recipes-devtools/ccache/ccache_3.2.5.bb (git://git.samba.org/ccache.git no longer exists), so I tried to replace it with the github one, but then failed again because of some checksum problems.

There I left it and tried to disable ccache instead, which worked nicely until the end when the build failed again on wpewebkit, because of missing ccache :) so at least we know this is the only issue.

[wouterlucas]

Interesting, from which OE core version are you building? Because I do not have this particular issue in Morty. Though yes, I do explicitly stay on Debian 9.x as I know upgrading to 10 will give me similar problems as you're experiencing when it comes down to building the toolchain.

If you are on a latest debian / ubuntu few things you can do like trying to take the lowest GCC in your package manager. If that fails I'd suggest taking a VM and install debian 9.x or ubuntu 16.04 for Morty OR take the latest master branch of meta-wpe with Yoe in which any host dependency should not exist (or be dealt with).

Another route would be to backport ccache from a newer version of OE-core, typically you can copy the ccache recipes from a newer version that includes the patch you linked. But that might snowball yourself into a chain of these issues.

[timemaster5]

I am using this command to initialise: openembedded-core/oe-init-build-env rpi-ml-build, the other one source poky/oe-init-build-env rpi-ml-build doesn't work because of missing poky directory.

But anyway, thank you for that OS recommendation. I've been successful and built an image for rpi 3 on ubuntu 16.04.

The documentation for RPI, and also the image produced by this build seems to be a little bit outdated though. I've seen some package versions during the process, and they are often from 2017. But the worse problem is that I am not able to boot that image on my RPI 3b+, led error code show deprecated system (or sth like this).

So I tried building raspberrypi3-64 target, which unfortunately failed on Cairo log file.

I was also particularly successful with joe-distro, which seems to be very recent. I have a working image of the base distro, but so far I can't build wpe-eglfs one. But a better place where to report potential problems is probably there, once I am sure it is not an issue on my side.