-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[core] RPI Opengl - Wrong DRM connector? #3946
Comments
Underscan is NOT that. Cause i've not installed X..
|
I was wondering where is the magic limit beyond which it falls, it's 384px, everything above the image is destroyed. Because I don't have a desktop installed, I can't set the screen. Editing |
@colesnicov thanks for the detailed report! I'm afraid I don't know what causes this issue, maybe it could be related to the driver or the display supported resolutions... I neither have the means to reproduce or track the issue... |
Thanx. Sometimes, when the problem is unclear, a detailed analysis of the problem may be the only way to fix it... The link I wrote in the first comment, did you deal with a gentleman there, I mean something similar? Which code/function in the code did you refer to? I honestly don't know how all these Such things happened to me with (as an example) AVR + ssd1136 where I wrote beyond the limits of the buffer (physical display) and then the pixels appeared differently on the display..? Of course it was a mistake.. |
This line in the successful test means that this is one of the supported modes that was found. It ends up all screwed up with the 400px size because it can't find a mode with a width that fits that. raylib is depending on libdrm to provide a list of available connector modes and libdrm isn't finding one with a width of 400. You can use SetTraceLog to increase the logging to show you more output regarding what raylib is getting from DRM, including how many modes it is actually finding. It wouldn't shock me if it is only finding 1 mode (384x1280p@62). I don't know exactly how DRM figures out the modes, I believe it uses a formula and reads information about the device to determine what resolutions are supported. If that belief is true, then it's possible something about the drivers for this device don't play well with that formula. |
Actually it looks like the drm info should be coming from here: https://github.com/waveshare/linux-patch/blob/e9da5fc701b637f9379d89044005e3d15997802c/drivers/gpu/drm/panel/panel-waveshare-dsi.c#L98 And that looks correct...I guess? Not sure what's happening but I do believe this could be outside the realm of raylib. |
I set
|
I don't develop on RPI, but for RPI (currently I'm testing, a little bit), so unfortunately I can't debug to see there. Laptop, I have a laptop for an incredible amount of money - I don't understand how it's possible, it doesn't cooperate with the HDMI output. Windows Yes, Ununtu No. ): So I can't even debug it on my laptop. |
@michaelfiber maybe you're right. Maybe it's not LIBRAY's fault, but the waveshare adapter's fault. Only they (waveshare) don't have Issues enabled. EDIT: But Desktop GUI does not have this problem. |
Here is
I think I won't get any more information from it. But I'll check out forum.raspberry.com |
Sorry for 'spamming' but here is my config.txt:
|
Hello, The problem is in the function raylib/src/platforms/rcore_drm.c Lines 1837 to 1883 in f100755
@colesnicov, you are trying to create a screen of 400x450 px but there is no exact matching DRM Mode for this resolution so we try to find the nearest matching resolution. From the log you show, we can see that there is 3 DRM modes for your screen.
So it starts a loop over all available DRM Modes and stores at the end of the first loop the mode 0 (the one you want) as the selected one. Then it tests DRM Mode 1 and in order to know which DRM Mode is the nearest it does a substraction of all members (respectively : width, height and refresh rate). So for DRM Mode 0 (selected Mode) we have: selected nearest Width diff: 400 - 400 = 0 and for DRM Mode 1 we have: new Width diff: 1280 - 400 = 880 And if one of the new diff is smaller than nearest diff (270 < 830 in our case) it will change the nearest DRM Mode. So the new nearest DRM Mode is the 1. Then the upscaling will mess with the display I suppose. Just to be sure, try to create a window of 400 x 1011 and the selected DRM Mode should be 400x1280 If you really want to have a resolution of 400x450, you will have to modifiy this function or to set the DRM Mode on the connector yourself. But still, it will upscale to the fullscreen anyway |
That's exactly what I 'missed'.. That it takes up the whole screen anyway. I don't actually create a window, in this case, but a canvas... Okay, that would do, I need it in full mode, otherwise I don't need such a large display... So, no bad framebuffer, not that there isn't enough RAM, just bad parameters I chose.
|
Issue description
I got have a same display and have has same the problem like his one: https://www.reddit.com/r/raylib/comments/ykmke0/raylib_on_1280x400_hdmi_screen_w_fbconrotate3/
When I run core_basic_window, everything is fine, well almost. I had to edit the examples, change the size (width) of the window in them from 800 px to a smaller one. My display is in a vertical position, so it is 400 px wide. when I try to create a window in the program that is larger than the screen resolution, instead of one window, 4 small ones are displayed, which in addition slowly disappear in black, and then only some text and letters are visible...
When I adjusted the window size to 400px, everything works.When I adjusted the window size to 300px, so everything works.Here is the output at 300px width:
But if I set the size to 400px, which is the physical resolution of my monitor, it's screwed,
here is the output:
Environment
Raspberry PI 2B, Raspberry OS LITE
Code Example
I used sample examples. I just changed the width of the window from 800px to 400px or to 300px.
Append
I checked it now. 400px doesn't work but 300px does.
I'm wondering if it's not the fault of the 'underscan' (black border around the screen) that it detects wrongly? In
raspi-config => Display Options => D1 Underscan
I do not have compensation enabled.P.S. https://www.reddit.com/r/raylib/comments/ykmke0/raylib_on_1280x400_hdmi_screen_w_fbconrotate3/ The file you refer to has already been edited a lot and I can't imagine what happened there.
The text was updated successfully, but these errors were encountered: