[core] PLATFORM_DRM rotate screen/window

[colesnicov]

Hello, I have set my raspberry to start so that the screen is rotated 90 degrees. boot and console are now found. Otherwise, I have a display that is made for mounting in a vertical position.

The console is displayed fine for me (horizontally), but the raylib window still appears the same, so it is now turned 90 degrees sideways... I read somewhere that the DRM setting has no effect on fbdev.? And now I'm not sure if it will be the team, @raysan5 , are you using fbdev here? I read somewhere that when writing directly to fbdev, the settings sent to cmdline.txt are not reflected...

Environment

RPI 2B, Rapberry OS LITE

Code Example

I added this to my /boot/firmware/cmdline.txt:

video=HDMI-A-1:400x1280M@60,rotate=90

console good - gui rotated
console good - gui rotated
console good - gui rotated

[colesnicov]

@gabriel-marques
I'm sorry to bother you, but you already advised me once, so I want to ask if you know how to turn the LIBRAY output by 90°?

• I tried to add video=HDMI-A-1:400x1280M@60,rotate=90 to /boot/firmvare/cmdline.txt but only the console rotates, the RayLib window has the order of the original rotations.
• I tried echo 1 | sudo tee /sys/class/graphics/fbcon/rotate and echo 1 | sudo tee /sys/class/graphics/fbcon/rotate_all but still nothing. It only affects the console.

[colesnicov]

I was only able to rotate RayLib outputs 180˚ and flip the X or Y axis.

I tried adding different options to /boot/firmvare/cmdline.txt and came up with this:

• panel_orientation - It can only rotate the screen 180˚.
• rotate - It only affects the text mode
• reflect_x a reflect_y - it can only flip in its axis.
• fbcon=rotate - It only affects the text mode

I found this, Screen rotation with drm/egl rendering on Rpi4 and I think that this will be the end of my journey. Even though I learned elsewhere that someone had succeeded, but there wasn't enough information about it...

But to excuse the fact that I'm spamming here, I wonder if RayLib offers a way to rotate the rendered window by 90° so that I don't have to rotate the entire contents of the window manually?

If anyone is interested, the sources where I looked are:

• Screen rotation with drm/egl rendering on Rpi4
• modedb default video mode support
• Raspberry Pi Documentation - HDMI Documentation
• How to add hardware rotation, scaling etc to a DRM/KMS driver
• Rotate display on startup
• [TUTO] touchscreen rotations
• Raspberry 7" Touchscreen Rotation Ignored By Kodi 20.2
• Kernel Mode Setting (KMS)
• Bookworm lite with official 7" display display regression
• Accelerated video on rotated screen using cvlc on Buster

So why make displays of such a size...

[colesnicov]

I don't know if it is possible to definitively solve it somehow. But I'd like to note it here for future reference. Although these discussions are not related directly to RayLib, they are related to Raspberry PI and DRM/KMS.

Starting from https://forums.raspberrypi.com/viewtopic.php?t=361116&start=50#p2191569 and continuing through https://forums.raspberrypi.com/viewtopic.php?t=361116&start=75#p2191843, the KMS capabilities of the LINUX kernel 6.6 are explored.

And here he's trying to convince me definitively that I'll have to do it programmatically? https://forums.raspberrypi.com/viewtopic.php?p=2191429#p2191429

[raysan5]

@colesnicov Thank you very much for all the investigation work put into this issue. I'm afraid I'm not an expert on PLATFORM_DRM but I'm sure all the info posted will be really useful for other users facing this same issue! Thanks!

[colesnicov]

Good. Tanks.
Okay, but I don't want to close it yet. I'm wondering if I can rotate the entire contents of the window by 90° in some simple way. I mean both a 3D scene, which is not difficult to multiply matrices, and a 2D scene. In the PLATFORM_DRM mode, the title of the window is not displayed, so the rotation only concerns the contents of the window.

[raysan5]

@colesnicov Not sure if I understand it correctly... Why not just create the window with the rotated size?

[colesnicov]

I have a display (it's my fault, I didn't know at the time what problems it would cause) with a resolution of 400x1280 (it's not 1280x400) which is mounted vertically. I turned it to a wide angle, and I want to keep it like that.

Here are screenshots of what I have on my laptop. this is the way I want it (horizontal):

And this is when I change the dimensions from 1280x400 to 400x1280.

I wanted to have a horizontal layout, but now it looks like it won't be possible.

EDIT:

I don't have it installed on Raspberry. When I upload it to RPI, I'll throw in a photo and it will be clear what it is about.

[raysan5]

@colesnicov I'm afraid the best option is redesign the application to render to 400x1280 framebuffer...

Still. you have another option. You can draw everything to a 1280x400 RenderTexture and draw the RenderTexture.texture rotated 90º to screen.

RenderTexture target = LoadRenderTexture(1280, 400);
...
BeginDrawing();
    BeginTextureMode(target);
         // Draw everything to RT at 1280x400
    EndTextureMode();

    // Draw RT.texture rotated 90º to screen (and flipped Y)
    DrawTexturePro(target.texture, (Rectangle){ 0, 0, target.texture.width, -target.texture.height }, (Rectangle){ 0, 0, target.texture.width, target.texture.height }, (Vector2){ 0, 0 }, 90.0f, WHITE);

EndDrawing();

But in this case is up to you to map inputs correctly...

[colesnicov]

That's exactly what I meant.
I once played a video on Billboard in a 3D scene https://youtu.be/NHFiAHJNFJE?si=qh8Lp_-PCkqW_6OS&t=68 . I thought about the inputs that they would have to be remapped, but probably on the dtoverlay layer.

In the future, I will buy another display, I have already checked which one will have a native resolution for landscape.

But I will change this layout to a new layout. And then I'll try to render it into a texture.

[JesperNaarttijarvi]

Hi,

Thought i would just share what we did to solve this, if anyone else is stuck with the same problem.

We also require rotating without X, and it's challenging. I spent countless hours trying but ended up rotating everything 90º in code instead.

We extracted raylib code into our own functions that in turn rotate the content 90º and handles X/Y conversions, so if it ever comes out an update to DRM, it's simple to revert to standard setting again. You could even take this a step further and define rotation, and then support both ways.

[bonsaipanda]

Was asking about this on the Reddit page as I couldn't figure out what would be the proper approach. I'm working on a display that is permanently mounted horizontally (a commercial product), but reports itself as portrait, so everything is drawn sideways.

I would suggest implementing a global rotation in Raylib itself as the view should be separate from the physical display anyways.

It could be one function that takes in 4 orientation enums and rotates the visual content as well as input OR as an option of having input coordinates rotate with the view content freely, aka follow one global transform. That would be available to all platforms and wouldn't require diving into the haystack of DRM drivers (did it, 1/7, would not recommend).