00:02 <alyssa> Just getting a black screen..

00:27 <mrfixit2001> alyssa what are you trying to boot?

00:27 <alyssa> mrfixit2001: ODROID N-2

00:33 <mrfixit2001> alyssa as far as I know manjaro has it booting. Here's what they use for a config: https://gitlab.manjaro.org/manjaro-arm/packages/core/linux-odroid-n2/-/blob/master/config but I think they are still using 4.9: https://github.com/hardkernel/linux/commits/odroidn2-4.9.y

00:33 <alyssa> ainline is a must..

00:34 <alyssa> er, current 5.x mainline anyway

00:36 <mrfixit2001> I wish I had one to help you. Any uart output to look at?

00:36 <alyssa> Don't have a cable atm

00:37 <mrfixit2001> Well, you could always waste a bunch of time diffing the device trees :D https://github.com/hardkernel/linux/blob/odroidn2-4.9.y/arch/arm64/boot/dts/amlogic/meson64_odroidn2.dts

00:38 <mrfixit2001> alyssa can I please pick your brain about something stupid

00:38 <alyssa> mm?

00:40 <mrfixit2001> So in order to improve the performance for some demanding emulators on some rockchip boards, I have added very simple code to change the resolution when the emulator starts. Unfortunately, fbset and tvservice are not applicable to rockchip for some reason... So the kernel param has kms set to 1080p over hdmi - but when an emulator starts I might

00:40 <mrfixit2001> change it to 720p so it runs faster.

00:41 <mrfixit2001> In order to do this - I actually have had to patch the emulator itself to initialize a simple graphics stack prior to the emulator booting. It's init's drm, gbm, and egl.

00:41 <mrfixit2001> then sets the crtc mode that I want

00:42 <mrfixit2001> With the BSP 4.4 kernel and the mali blob - this works without an issue. The resolution changes, the emulator renders fine, and I cleanup everything when it closes and revert back to the old crtc.

00:42 <mrfixit2001> Make sense so far?

00:44 <alyssa> ....not entirely :|

00:44 <mrfixit2001> The problem - it isn't working on mainline. On panfrost or on lima. There is no error. The resolution changes on the screen. But it's left at a blank black screen. The emulator runs and I can hear it's sound but there's no video.

00:45 <mrfixit2001> Let me try and explain better.

00:46 <anarsoul> use wayland and/or x11? :)

00:46 <anarsoul> so you don't have to initialize display yourself

00:48 <mrfixit2001> Before the emulator does any initialization of it's graphics stack at all, I patch it to run a new set of functions. It opens /dev/dri/card0, finds the drmMode that I want in the connector's modes, creates a gbm device and surface, sets up an egl display, context, and surface, swaps the buffers, locks the gbm surface, gets the fb from the bo, and

00:48 <mrfixit2001> then changes the crtc mode. Once that all is done, the emulator continues as usual and renders to the screen with the new resolution.

00:48 <mrfixit2001> Everything I've done is fully GBM / GLES - no windowing system at all...

00:49 <mrfixit2001> so no x or wayland to help me, unfortunately anarsoul

00:50 <mrfixit2001> The thing is - it works perfectly with the old mali drivers. I've literally been tinkering with it for 3 days and trying a variation of different things with no luck.

00:50 <mrfixit2001> So obviously something is different about mesa and mainline.

00:50 <mrfixit2001> And here is something very strange...

00:51 <mrfixit2001> when I printf strerror(errno) at every step along the way - I actually end up seeing "permission denied" showing up after the creation of the gbm device - but the object exists and there's no error.

00:51 <mrfixit2001> I've gone as far as chmod 777 /dev/dri*, no change

00:52 <mrfixit2001> ^-- missed a slash but you get the idea

00:55 <mrfixit2001> I'm hoping SOMEONE has some idea. Cause I'm running out of them haha I did find that I can hijack the buffer_id of the current drm mode and change the resolution on the screen without initializing any gbm or egl, and the resolution does change and the fb graphic on the screen gets all distorted - but then the emulator doesn't render at all and I'm

00:55 <mrfixit2001> just stuck at the distoretd fb image instead of a black screen haha

00:56 <mrfixit2001> I'm going to copy/paste all this into the lima channel as well and hope someone has any ideas. Please don't be shy if someone has any thoughts.

01:03 <anarsoul> no need, thanks

01:03 <anarsoul> I'm already here

01:05 <mrfixit2001> anarsoul I saw that just seconds too late lol sorry, was in the middle of copy and pasting

01:05 <mrfixit2001> your feedback is really appreciated. If you have any ideas at all.

01:05 <mrfixit2001> I'm not shy about patching the kernel or mesa - happy to test and try anything you like.

01:06 <anarsoul> your emulator is likely using SDL, so just use wayland (any compositor of your choice) or X11 and appropriate SDL backend

01:09 <anarsoul> it's not really panfrost or lima specific

01:09 <mrfixit2001> I would really like to get this working with GBM. I'm of the mentality that if it worked on the old driver then we should be able to make it work on the new driver. Full backwards compatibility is the goal, right? :) The entire buildroot defconfig and emulator packages have been setup for GBM/GLES.

01:11 <anarsoul> mrfixit2001: not really, buffer management is totally different in blob, so it's hard to tell where exactly it fails for you. As alternative you can change resolution at boot time

01:11 <mrfixit2001> I guess I don't understand then. Because everything else, all patches and libraries in the entire buildroot toolchain, are identical. I've done a full rebuild using mainline kernel and headers, along with using mesa instead of libmali. Otherwise there's no difference, so what am I missing? How isn't it one of the only two things I've changed? Not

01:11 <mrfixit2001> doubting you - just trying to understand.

01:11 <anarsoul> see https://wiki.archlinux.org/index.php/Kernel_mode_setting#Forcing_modes_and_EDID

01:12 <mrfixit2001> thank you again for taking the time to reply. I do understand that I can just change the entire system's resolution, but the goal is to be able to change the resolution at runtime.

01:13 <mrfixit2001> Other applications are able to accomplish this on their own - namingly retroarch and kodi - they change the resolution to whatever they want as they initialize. But the stand-alone emulators don't have the code for that inherently.

01:13 <anarsoul> then add support for changing resolution to SDL backend?

01:15 <mrfixit2001> the SDL libraries in my build have not changed - they don't interfere at all with it using libmali

01:16 <anarsoul> *sigh*

01:16 <mrfixit2001> :(

01:17 <anarsoul> IIRC libmali doesn't allocate scanout

01:17 <anarsoul> mesa drivers do

01:18 <anarsoul> so likely your emulator is rendering into old scanout

01:18 <anarsoul> that's just a guess though

01:18 <mrfixit2001> One thought I had... is lima/panfrost/mainline perhaps limiting the number of concurrent connections to /dev/dri/card0?

01:19 <mrfixit2001> hmm scanout? is libmali ignored that - I could try removing GBM_BO_USE_SCANOUT from my gbm code

01:19 <anarsoul> mrfixit2001: I'm not sure how exactly blob works

01:19 <anarsoul> but

01:20 <anarsoul> if you get blackscreen and emulator thinks that it's working it means it renders somewhere

01:20 <anarsoul> anyway, to fix it do that same what kodi or retroarch do

01:21 <anarsoul> don't do guess work, research how you're supposed to use API and use it proper way

01:21 <anarsoul> hope it helps

01:21 <mrfixit2001> That's the problem - kodi and retroarch already have the code inherently. They fully init the full graphics stack already and change the resolution. My patch initializes the entire stack first, and then lets the emulator initialize it's own again over it.

01:27 <mrfixit2001> sadly - without GBM_BO_USE_SCANOUT it just segfaults :( worth a shot

01:28 <anarsoul> mrfixit2001: so fix emulators to initialize whole stack

01:29 <anarsoul> BO you allocate with GBM is your scanout

01:29 <anarsoul> aka framebuffer

01:29 <anarsoul> likely your emulator allocates its own

01:30 <mrfixit2001> I did spend a few hours trying to patch the missing pieces into the emulator. I ended up abandoning the idea and hoping that the way it used to work was "close" and just needed some tweaks.

01:31 <mrfixit2001> haha why doesn't it "just work"?? lol I'd prefer to figure out why it's not compatible - but if I need to try adding the missing pieces to the emulator again I can.

01:33 <anarsoul> mrfixit2001: it doesn't "just work" because you're using API incorrectly

01:33 <mrfixit2001> One sneaky suspicion I have is with the eglCreateWindowSurface function. It used to accept the gbm surface as a parameter - but for some reason now it demands that parameter is a EGLNativeWindowType

01:33 <mrfixit2001> I've direct casted the gbm surface - as I've seen done in many examples online - but it "feels" wrong

01:33 <HdkR> That's the correct thing to do

01:34 <HdkR> EGLNativeWindowType is a bit overloaded

01:34 <HdkR> This is why there was a new extension that landed recently

01:34 <mrfixit2001> If the API is incorrect - it shouldn't have worked on libmali tho?

01:34 <mrfixit2001> HdkR that's a relief to know, and one less thing for me to tinker with. Thank you!

01:35 <HdkR> https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_platform_base.txt and a bunch of KHR_platform_* extensions

01:36 <HdkR> Changes the native window to a void* (like it should have originally been) and forces you to declare a platform

01:36 <HdkR> Khronos hecked up and didn't expect multiple window types on a single platform

01:36 <anarsoul> mrfixit2001: my guess is that you're doing something that has undefined behavior

01:38 <mrfixit2001> Uploaded file: https://uploads.kiwiirc.com/files/bfc3b0d87bb985252f198c85cea3454a/pasted.txt

01:38 <mrfixit2001> Here is the exact code I'm trying to make work

01:38 <mrfixit2001> I call drm_setres() within the emulator before it initializes any of it's own graphics at all.

01:38 <mrfixit2001> and then drm_clearres() to clean up as it exits.

01:40 <mrfixit2001> You can ignore the "popen" call - it just reaches into the recalbox config so that users can control what resolution they want the emulator to change to.

01:41 <anarsoul> and what emulator does next?

01:41 <anarsoul> does initialize egl again?

01:42 <mrfixit2001> depends on the emulator. In the one I am currently testing on it actually initializes the SDL video subsystem and creates an SDL window and context.

01:43 <mrfixit2001> ^-- an SDL_WINDOW_OPENGL

01:44 <anarsoul> so likely it reinitilizes egl

01:46 <mrfixit2001> it doesn't run any egl init functions, as those are inside an ifdef statement that disables them when SDL is used

01:47 <anarsoul> likely sdl does it for you

01:47 <mrfixit2001> that is possible, and likely, yes.

01:53 <mrfixit2001> It worries me that when I run "gbm_create_device" the object exists - but if I printf the strerror(errno) then I actually see "permission denied"

01:55 <mrfixit2001> I check the value of strerror(errno) immediately before calling gbm_create_device and it's not that, so I'm 100% confident that is the command creating the errno, but then how is the object being created successfully? very strange.

01:56 <mrfixit2001> I saw one example creating the gbm device and surface against renderD128, but that doesn't seem to be right. I tried it anyways, and it actually resolved the permission denied error - but then there was absolutely no resolution change of course lol

02:02 <mrfixit2001> Another thing I tested is setting the desired resolution to 1080p - the same as it already is. The code still all runs the same, and the screen still goes black. Just to rule out the new resolution itself not being an issue.

02:41 <mrfixit2001> anarsoul I can confirm that if I simplify the code to do nothing more than simply open /dev/dri/card0 and then run drmModeSetCrtc with a different mode against the current crtc's buffer_id that the resolution changes, the screen isn't blank, but the emulator doesn't render to the screen (I hear the sounds still). If I don't do ANYTHING else except

02:41 <mrfixit2001> open card0 then the exact same thing happens. But, if I close card0 then it renders fine - but of course there's no resolution change.

02:41 <mrfixit2001> I really feel like this is an issue with limiting concurrent connections to card0

02:41 <mrfixit2001> but I need to go, to avoid further angering the wife any more haha I'll check back tomorrow for updates, hopefully I don't time out.

02:41 <mrfixit2001> and hope someone has some further ideas.

02:44 <mrfixit2001> ^-- to clarify further and simplify what I'm saying... just running this will cause the emulator to not render to the screen and get audio only: open("/dev/dri/card0", O_RDONLY)

02:44 <mrfixit2001> literally not running anything else except that. Of course, if I close this connection then it renders fine.

02:45 <mrfixit2001> Ok - goodnight - looking forward to feedback

09:08 <icecream95> mrfixit2001: gbm_create_device sets errno for me as well, so I don't think it's related to your problem.

09:37 <icecream95> There can only be one "DRM-Master" at a time, so opening /dev/dri/card0 in two different processes isn't going to work without using drmAuthMagic.

19:41 <mrfixit2001> @icecream95 anarsoul wanted to thank you both for your time and feedback! Icecream's response gave me an idea... something so simple, and something I hadn't tried... I changed my code to do nothing except open card0, find the desired mode, and set it on the local buffer. I didn't init any gbm or egl at all, and I added drmDropMaster after I changed

19:41 <mrfixit2001> the mode... and BOOM it works :D

19:42 <alyssa> :-)

21:20 <mrfixit2001> strange that the mali blob didn't honor what the drm master was

21:29 <alyssa> BREAKING NEWS: The blob has a bug, blob revealed to be "not designed for upstream linux"

23:53 <mrfixit2001> alyssa lol "blob" sounds like a symptom of a "bug" in itself, so no surprise there! haha in this case, the bug was a helpful one lmao