Accelerated video on rotated screen using cvlc on Buster

[mehrvarz]

After upgrading to Buster, screen rotation (90 degree) didn't work on my Pi. I found this:

If using the VC4 FKMS V3D driver (this is the default on the Raspberry Pi 4), then 90 and 270 degree rotations are not supported. The Screen Configuration utility provides display rotations for this driver.

So in my /boot/config.txt I removed "display_rotate=1" and enabled vc4-kms-v3d. Then I added "@xrandr -o right" to my /etc/xdg/lxsession/LXDE-pi/autostart. This works well.

However, I use cvlc for accelerated fullscreen video playback. Unfortunately, cvlc completely ignores the screen rotation set by xrandr. A tall video is now rendered sideways on the 90 degree rotated screen. What should be on top, is on the left. What should be the bottom, is on the right.

What is the expected solution to this? Do you expect cvlc to come with a fix to this issue, which is caused by the change in the kernel driver? Are there other any options? How can accelerated fullscreen video playback be achieved right now on a rotated screen on Buster?

Another (minor but nagging) issue is that the kernel boot logs are displayed sideways on a rotated screen currently, before xrandr makes things right. Any ideas about that?

[popcornmix]

Video rotation issue is a vlc issue, not kernel.
I have flagged it up to the dev working on vlc.

I don't think console (i.e. boot logs) rotation is something supported in the linux/xrandr world, so I don't think that will be fixed.

If you don't need 3d support, then you can disable vc4-fkms-v3d and return to using display_rotate=1, but that wouldn't be recommended as development will primarily focus on the fkms world.

[mehrvarz]

Thank you for flagging the issue forward. I have no need for 3d support right now. But I need accelerated browser rendering. So I would like to stay with vc4. Especially if it is the recommended driver.

As a command line tool, cvlc can live outside of x11/gui context. I assume they will need to implement some "smart" solution for screen-rotation detection, depending on whether x11 is running or not. Hopefully that won't take too long.

Without vc4 losing screen-rotation support, both issues would not exist. Is there any chance the decision to drop screen-rotation from vc4 could be reversed? Some folks might want to run a portrait-mode screen in console mode, without any x11.

[6by9]

It's not an issue of dropping support, but that we are switching between two alternate graphics stacks - the legacy framebuffer API to the current mainline DRM/KMS API. They have slightly different feature sets and functionality.

Transpose using the Pi SoC has to be done as a two pass operation - compose the scene to memory with transpose, then display the transposed buffer.
With the legacy stack we could implement a mechanism to hide that under the bonnet (although it has a performance hit).
DRM/KMS does have the concept of writeback connectors for configuring writing to memory, but nothing in X or the frame buffer emulation is set up to use it. Rotation in X is done via GL composition instead of the transposer.

Realtime rotation as part of composition is something that very few graphics cards support (some Intel cards may), so I suspect your use case of a rotated console fails on most Linux systems using DRM/KMS. If we can find a way to do it, then we will try.

Can you also confirm you are using vc4-kms-v3d, not vc4-fkms-v3d? Whilst they both expose the 3D side in the same way, they differ in the way they drive the composition hardware (fkms still uses the firmware, whilst kms takes full control from Linux).

[XECDesign]

Does fbcon=rotate:1 in cmdline.txt do anything for the boot messages?

Edit: looks like that requires CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y

Edit 2: Just tried a kernel with the above option enabled, and it works up until X starts. Then I just get a black screen.

[XECDesign]

After playing around with it a bit more, it's not X. Just having CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y, with or without any actual rotation applied results in a black screen after some initial boot messages. Nothing unusual in dmesg.

[6by9]

I'm a couple of patches above rpi-4.19.y as I'm backporting overscan support from 5.1. Those changes also pick up being able to set DRM/KMS rotate from the kernel command line (cmdline.txt, not bash shell).
Enabling CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y does seem to work happily! There's a bug in the current top of tree that sets rot90 by default, but there appears to be a fix sent to the mailing list.

So I think I need to backtrack and say there is a way to rotate the console, but you may need to wait a few days for changes to propagate through into rpi-update images.

[mehrvarz]

Can you also confirm you are using vc4-kms-v3d, not vc4-fkms-v3d? Whilst they both expose the 3D side in the same way, they differ in the way they drive the composition hardware (fkms still uses the firmware, whilst kms takes full control from Linux).

I tried vc4-kms-v3d, but couldn't get the 90 degree rotation working (with xrandr). This is why I am using vc4-fkms-v3d at this moment.

So I think I need to backtrack and say there is a way to rotate the console, but you may need to wait a few days for changes to propagate through into rpi-update images.

excellent, excellent - also thanks to XECDesign

Does anybody know a command line tool that can do hw-accelerated fullscreen video playback on a rotated screen right now? If cvlc would respect the rotated screen config, this is what I would be using: "cvlc -f --no-osd --play-and-exit file.mp4". Otherwise I will just wait for the cvlc patch.

[6by9]

Does anybody know a command line tool that can do hw-accelerated fullscreen video playback on a rotated screen right now?

omxplayer --orientation 90 foo.mp4
You may need to add --no-osd if you have vc4-fkms-v3d or vc4-kms-v3d to avoid trying to use the 3D from the firmware.

[mehrvarz]

I tried omxplayer before. I always (with or without --orientation 90) get this:

Video codec omx-h264 width 750 height 1334 profile 100 fps 25.000000
* failed to add service - already in use?
Audio codec aac channels 2 samplerate 48000 bitspersample 16
/usr/bin/omxplayer: line 67:  1967 Aborted                 LD_LIBRARY_PATH="$OMXPLAYER_LIBS${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}" $OMXPLAYER_BIN "$@"

Many people have posted this issue. I cannot find a single solution, other than "Disable the GL driver": https://www.raspberrypi.org/forums/viewtopic.php?t=204794

I can run cvlc right after omxplayer has failed and it works with full acceleration and even though the screen has blanked for everything x11. (Doing that via ssh.) The only issue with cvlc is that it ignores the screen rotation set by xrandr.

[mehrvarz]

OMG!! omxplayer does work with --no-osd. And with --orientation 90 it's just beautiful.

[6by9]

See popcornmix/omxplayer#720 for the omxplayer not automagically setting --no-osd

[6by9]

Oh, and subtitles will have the same issue of trying to render via the OpenVG service that doesn't exist.

[mehrvarz]

I tried the rotation thing again. This time using kernel "4.19.66-v7+ #1253 SMP Thu Aug 15".
I added kernel boot parameter "fbcon=rotate:1" to the beginning of /boot/cmdline.txt.
I also still have "@xrandr -o right" at the beginning of my /etc/xdg/lxsession/LXDE-pi/autostart. And it works!
The former takes care of the rotation (90 degree right) in console mode. The latter rotates the GUI in just the same way. Together they provide a seamless experience.
Thank you very much for adding that setting to the kernel .config.