17:14DPA: What does kmsro do?
17:14DPA: If I open a panel device (mxsfb), use it to initialise gl, but which renders using a gpu (etnaviv),
17:14DPA: how does the rendered image get onto the panel, is kmsro involved there?
17:20sravn: Hrmf: warning: braces around scalar initializer
17:20sravn: struct drm_display_mode new_mode = { { 0 } };
17:20sravn: I though this was fixed for a long time now. Jumps in my face when building and looking for new warnings
17:21sravn: drm-misc-next latest btw
17:22airlied: sravn: omap? there is a patch on list
17:26sravn: airlied: omap, yes.
17:27sravn: having fun with the drm_panel_{attach,detach} removal
18:09SolarAquarion: eric_engestrom: the weird thing is that the SourceLocation overflow only happens in a "systemd chroot"
18:10imirkin: DPA: kmsro presents a "fake" driver for the primary device (e.g. mxsfb) which secretly uses the GPU to actually perform rendering
18:16DPA: Ok, thanks.
18:28DPA: If I have such a device, and a gbm bo created on it is shared to another device using prime on which rendering is done using egl,
18:28DPA: or more specifically, in case of X11 prime buffer sharing, if I can draw to the imported bo from the cpu, but nothing rendered
18:28DPA: on the gpu shows up in a buffer shared like this, where do I need to look to figure out why that is and how to fix it? (Assuming it's not an X11 problem.)
18:29imirkin: you shouldn't need to use PRIME
18:30imirkin: just use it as if the primary device were capable of doing everything
18:30imirkin: the buffer sharing is done behind the scenes
18:52DPA: I've 3 /dev/dri/card* devices. One is the display (using mxsfb), one is for the etnaviv gpu, and one is for hdmi.
18:52DPA: I can initialize egl all cards due to kmsro. X11 has one bo for the entire screen (for both monitors) on one of the devices, though,
18:52DPA: so it has to copy the portion to be displayed on the other one to the other one. So I can't do all the rendering on the device with
18:52DPA: the output where it's to be displayed on without major changes to how X11 works, I think.
18:52DPA: Or do I have to somehow consolidate the 2 devices, if so, how?
19:04imirkin: uhm
19:04imirkin: hdmi gets its own card node?
19:04DPA: Yes
19:04imirkin: xrandr --listproviders
19:05imirkin: so basically you have 2 display devices and 1 gpu device, right?
19:05imirkin: kmsro will be bound to the first display device
19:05imirkin: so with reverse prime for the second device, things ought to still work
19:06imirkin: but it's not a heavily tested scenario, so they might not :)
19:06imirkin: [i.e. kmsro + reverse prime offloading]
19:12DPA: Yes, that's how I've set it up, I think. I had to modify the xorg.conf for this slightly, though.
19:12DPA: Unfortunately, it leads to the second to be black.
19:12DPA: Config & xrandr output: https://pastebin.com/2DSQr76r
19:13DPA: *second output/monitor
19:15imirkin: DPA: AccelMethod off?
19:15imirkin: DPA: run "glxinfo"?
19:27DPA: glxinfo: https://pastebin.com/m0weREY2
19:27DPA: glxgears -info: https://pastebin.com/sJ27rqwu
19:27DPA: The gl version is overriden using "MESA_GL_VERSION_OVERRIDE=2.1", otherwise, glamor would try to use gles,
19:27DPA: and then fall back to software rendering.
19:27DPA: AccelMethod is only off for the device which isn't the first. Otherwise, it would for some reason fail to
19:27DPA: add the framebuffer, and thus modesetting would fail, I'm not sure why. I can have either device as the first,
19:27DPA: as long as the second has AccelMethod off or is a different x11 screen.
19:27DPA: It should be fine, though, because the first one is the one it renders everything with.
19:33DPA: Oh, and to make that config actually work, the following bugfix for X11s old probe method is needed (only that one commit):
19:33DPA: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/490/diffs?commit_id=425ca39676215cb548277ef50d49b3c4396261d2
19:38DPA: Anyway, the first device displays stuff, the second doesn't.
20:24imirkin: DPA: i'm guessing whatever failure you're getting without accelmethod off is why you have the problems
21:08DPA: imirkin: I'm pretty sure this isn't the case. I've verified that mapping and writing to the prime shared filedescriptor draws to the display,
21:08DPA: that it did initialise the bo and X11 pixmap properly, that it tries to copy to it using the GPU, that writing anything to it with the GPU fails,
21:08DPA: and that forcing it to copy using the cpu (by commenting this line https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/glamor/glamor_copy.c#L741-742)
21:08DPA: mostly works (although cpu copy is too slow to be useful).
21:08DPA: So I'm pretty confident that, while needing that "accelmethod off" probably does indicate that something with glamor is wrong in that case,
21:08DPA: solving that problem probably won't resolve my main problem. As far as I can tell, from the X11 side of things, it should have worked.
21:13DPA: Although, I guess I can't completely rule out that fixing that may change which card is used for the gpu copying, so I guess there is a slim chance
21:13DPA: it could change the result.