00:23 <alyssa> Daanct12: panfrost supports both glDrawRangeElementsBaseVertex and FBOs

03:29 <Daanct12> robclark, the apitrace was taken on panfrost

03:29 <Daanct12> i tried that and this is what shows up

03:29 <Daanct12> Mesa: 18 similar GL_INVALID_FRAMEBUFFER_OPERATION errors

03:29 <Daanct12> Mesa: User error: GL_INVALID_FRAMEBUFFER_OPERATION in glClear(incomplete framebuffer)

03:29 <Daanct12> Mesa: 1 similar GL_INVALID_FRAMEBUFFER_OPERATION errors

03:29 <Daanct12> Mesa: User error: GL_INVALID_FRAMEBUFFER_OPERATION in glDrawRangeElements

04:14 <HdkR> Daanct12: Indeed, looks like an application bug

04:14 <HdkR> Since it is complaining about incomplete framebuffer

06:52 <bbrezillon> CounterPillow: uh, taking more time than I expected, but I'm getting there. Goal is to have something submitted before the end of the year.

06:54 <CounterPillow> Neat, good luck!

13:50 <Daanct12> HdkR, hmm, then is there anyway to workaround this? this is a FNA game and the developer doesn't update the game anymore

14:16 <greenjustin> alyssa: Thanks! Was wondering about that, I've just been trying to test with DVFS turned off, but I think I might've messed up the device tree somehow. Will try that tree

18:14 <HdkR> Daanct12: You could try using Mesa's GL version overrides, it's probably using some newer feature that makes it incomplete. To know more you would need to capture the framebuffer creation and deduce why it is failing

19:41 <greenjustin> Probably a dumb question, but is there something special I need to do in order to get panfrost working with X11? I've loaded the kernel driver and built a userspace driver, and I can confirm it all works with kmscube, but X11 is failing to start unless I unload the kernel module

19:58 <HdkR> greenjustin: Did you forget to build the userspace driver with kmsro?

20:00 <greenjustin> HdkR: I don't think so, I definitely added "-Dgallium-drivers=panfrost,kmsro"

20:03 <alyssa> that's not needed now

20:04 <alyssa> the kmsro part, it's automatic on recent (2022) mesa

20:04 <alyssa> (think that was changed in 2021)

20:05 <anarsoul> likely an issue with order of display/render node

20:05 <anarsoul> IIRC X11 didn't like render being card0 and display card1

20:06 <alyssa> oh, ugh, yeah I did have that issue on mt8192, I forget about that

20:06 <alyssa> # mv /dev/dri/card0 /dev/dri/card2

20:06 <alyssa> was my hack to workaround it

20:06 <alyssa> idk how to solve properly

20:09 <anarsoul> it should be solved in X

20:09 <anarsoul> by not attempting mode setting on render node :)

20:13 <alyssa> :+1:

20:17 <greenjustin> alyssa, anarsoul: I thought that might be it, but the logs seem to indicate otherwise https://pastebin.com/Cuw3mwCc

20:17 <greenjustin> I did try moving the cardX files around just in case, no luck

20:43 <anarsoul> looks like it tries xf86-video-fbdev instead of xf86-video-modesetting

20:43 <anarsoul> moreover I thought that modesetting is included into xorg-server by default, but I might be wrong

20:50 <robclark> greenjustin: you might also want to disable vgem if you are using a CrOS(ish) kernel config.. that is yet an extra card node to confuse Xorg..

20:54 <greenjustin> anarsoul: Removing fbdev changed the error message! Now I get https://pastebin.com/byM2Lb5t

20:54 <greenjustin> robclark: How would I go about that?

20:55 <anarsoul> oh, you actually have 3 cards

20:56 <greenjustin> Yeah, the vgem, the display controller, and the GPU. But, to Xorg's credit, it seems to recognize that card1 is the right one?

20:56 <robclark> oh, hmm.. if you aren't using emerge stuff, it is just `make menuconfig`.. if you are doing emerge stuff, I think you can just remove CONFIG_DRM_VGEM from a chromeos/config/chromeos/base.config

21:23 <greenjustin> robclark: Turned off vgem, same error unfortunately :(

21:27 <urja> my thought would be getting rid of that fbdev driver (or having a xorg conf fragment or whatever that specifies the modesetting one)

22:02 <greenjustin> urja: I did try just uninstalling fbdev, that seemed to at least change the error message