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

[raysan5]

@Loadus I believe is better to do it in the DRM driver side, to just get the correct resolution. Redesigning all raylib functionality to accomodate to a random display orientation seems overengineering and not feasible. If required to reach this point, it's up to the user to manage it. I'm convinced that DRM device driver could report and set the desired orientation.

[bonsaipanda]

@Loadus I believe is better to do it in the DRM driver side

The view rotation on the DRM is one function call away, if one knows what to call. But the documentation of the DRM/KMS driver is assuming the reader knows exactly how it works. :D

And yeah, if one wants a complete global transform implementation, that would mean a lot of modifications in the input capture etc., but a 4 orientation option would be just handling the X and Y (and offset).

My personal problem - where I am 100% stuck right now - is that I have no idea where to start looking on how to rotate the mouse / touch X and Y coordinates as I can easily rotate the view but the input is still applying the original coordinates. It's the only thing preventing me from actually starting to program the actual app. :D

I would somehow need to capture the input coordinates before they arrive to the visual items on screen, I guess? And I'm doing this from the Go version of the library as I can't be allowed to poke C code without adult supervision.

[bonsaipanda]

While continuing poking around, I noticed that an actual, physical mouse has it's coordinates rotated along the view correctly and works nicely - it's the screen touch that has it's coordinates in the original portrait mode when rotating the view manually, which is problematic in my case.

[colesnicov]

I also had a problem with the screen orientation being reversed. You haven't done anything to the hardware if it can't do it natively. It has to be solved on the framebuffer side, manually turn the entire frame to the required angle...

[bonsaipanda]

manually turn the entire frame to the required angle

Yes, that's what I resorted to as I couldn't figure out where to inject commands to the DRM sufrace. I used BeginMode2D and then rotated the camera, which worked perfectly. Apparently, it was only the touch that didn't follow the rotation and I think it's a bug as mouse coordinates are correct.

[colesnicov]

I needed it for Raspberry and HDMI touch TFT panel. unfortunately, I bought the wrong display, oriented at height. I didn't want to rotate each frame before rendering it, so I simply changed the layout of the application and noted in the future that I have to be careful about the native orientation of the screen/driver. In the final, I completely abandoned the use of frameworks such as RAYLIB, SFML and SDL and wrote my own DRM wrapper for RPI that also works on my desktop PC (laptop). In addition, it can dynamically distinguish whether it is launched from a TTY terminal and opens a window in DRM mode or whether it is launched from a desktop and opens a window with the help of GLFW. Which makes development a lot easier for me. I can compile the program on the desktop and test it. I immediately switch to the TTY console and without a new build or any switches I run the application in DRM mode. Basically, it just checks the presence of the DISPLAY variable in the system and if it is found, it opens the GLFW window :) .. I wrote, using libinput, a custom loop that captures mouse and keyboard events (With the possibility to set the keyboard layout, it was important because I use a non-English ASCII keyboard..) and provides them to my application. I ran under that IMGUI and already ported my project under it. I'm not bragging, I'm presenting an alternative way to solve the problem, it took me about 3 months to find the info and write it down. Unfortunately, I won't share the code then, it's very ugly and poorly tested, without documentation and without an example... But there are more projects like that, if you're interested, I'll throw you some links. RAYLIB and SFML are good, but I got 4FPS on RPI!! my DRM implementation then drags it to about 50 FPS friend. That's the main reason why I'm switching to native..

[bonsaipanda]

wrote my own DRM wrapper for RPI

That is really cool! I'm also on the fence of maybe doing or using a very simple 2D GUI system, but I do get 60fps on the Raylib (and the only one that builds as it's just so sleek), so it's currently the winner.

@raysan5 is it ok if I report the touch rotation malfunction as a bug report? Do you have any way to try and reproduce it?

[colesnicov]

As a pearl, I looked for the official DRM website and found this https://github.com/robclark/libgbm. Here a project (I didn't look at the code at the time) that could be a good starting point. It should be useful to someone..

[colesnicov]

wrote my own DRM wrapper for RPI

That is really cool! I'm also on the fence of maybe doing or using a very simple 2D GUI system, but I do get 60fps on the Raylib (and the only one that builds as it's just so sleek), so it's currently the winner.

I know that on rpi4 and rpi5 raylib flies like a hawk. But I agree, just because of lower performance, I'm testing on RPI2 B. I have some program that pretends to be graphically accelerated.. :) I like Raylib, but I had 4 FPS, I couldn't let it be like that was unusable.
I have now completely ported my program (unfortunately, irretrievably, I have completely removed the RayLib code), I also wrote routines for drawing into the texture, recording the mesh and other things (so that it is under one roof) for my DRM implementation, and I have it tested. I'm looking at it right now, I have 61FPS. It's 25X more FPS than RayLib had.
I just wanted to mention it here, in the previous comment I wrote that I haven't tested it yet...

P.S. I don't know how RayLib has solved input acquisition (mouse, keyboard, touch). I'm using libinput and had to move the functionality for polling input events to a separate thread. I only had 15 FPS before. If Raylib solves these things in the main thread, then that could be the cause..

[colesnicov]

@bonsaipanda

manually turn the entire frame to the required angle

Yes, that's what I resorted to as I couldn't figure out where to inject commands to the DRM sufrace. I used BeginMode2D and then rotated the camera, which worked perfectly. Apparently, it was only the touch that didn't follow the rotation and I think it's a bug as mouse coordinates are correct.

Maybe you could try installing some wayland server.. then the rotation is in charge of composer and it can do it better.. #4648 Vivarium does not support rotation, but there are others that do.

[bonsaipanda]

@bonsaipanda

manually turn the entire frame to the required angle

Yes, that's what I resorted to as I couldn't figure out where to inject commands to the DRM sufrace. I used BeginMode2D and then rotated the camera, which worked perfectly. Apparently, it was only the touch that didn't follow the rotation and I think it's a bug as mouse coordinates are correct.

Maybe you could try installing some wayland server.. then the rotation is in charge of composer and it can do it better.. #4648 Vivarium does not support rotation, but there are others that do.

I have to keep it as minimal as possible. I'm currently looking into Clay (https://github.com/nicbarker/clay) to see if I can bolt that in and use it as the skeleton for the UI and have Raylib as the renderer. Looks very promising.

[colesnicov]

It looks interesting. I use ImGui but it's not satisfactory. ImGui and CLay, lacks transitions and animations. I'm thinking about switching to something else.