01:53 alyssa: Sachiel: oh, lordy lordy
01:53 alyssa: nice :)
01:56 alyssa: yeah, that's what changed - I had nvk in my build enabled because of what I was hacking on yesterday.
01:56 alyssa: entertaining. thanks :}
08:07 tzimmermann: sima, mripard, can we talk about that probe-helper patchset? the premise is: to keep compositors happy, we cannot report more 'connected' connectors than there are crtcs available.
08:11 tzimmermann: this can happen with any driver. ast and mgag200 only expose the problem because their hardware is so limited
09:15 sergi: gfxstrand, eric_engestrom, daniels: I studied the issue mesa#11517 and proposed a solution https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30219
09:17 daniels: sergi: gràcies!
09:22 javierm: daniels: you even used the correct accent :)
09:23 javierm: https://en.wikipedia.org/wiki/Catalan_orthography#Accentuation
09:27 daniels: :D
09:30 tzig: Hey everyone, just to make sure, is this the right channel for user-space usage questions or is this one more for the developement of the module/subsystem?
09:33 eric_engestrom: thanks sergi! that change makes perfect sense 👍
09:34 eric_engestrom: I also had a quick look and there is no other `running` by itself so hopefully that's the last bug of this category :)
09:34 soreau: tzig: ask your real question and find out
09:34 eric_engestrom: gfxstrand: yes to creating issues, I don't always follow irc and even if I see something it's easy to forget
09:40 tzig: Okay sure, so I've been banging my head for a few weeks on this: I have some custom hardware with a Mercury+ XU7 SoC. I need to render an image on the GPU and send it to the FPGA part of the SoC (mapped to a physical address on the memory bus), I'm using lima as my DRM so no DUMB Buffers, I created a GEM and I'm stuck at the part where I need to give OpenGL/EGL the physical address, and from what I can gather a dma will work its magic and send
09:40 tzig: the data without any costly glReadPixels. I've tried a few dozen things but can't manage to make it work, I'd be very glad for any pointers cause the documentation online is sparse, to say the least
10:03 sima: tzimmermann, yeah, but the issue is that this does reduce functionality
10:03 sima: and the compositors are just broken if the fall over with that
10:03 sima: the bmc is kinda special because no regression rules, but otherwise I really don't think we should try to hack around this in the kernel
10:11 sima: compositors already have heuristics like preferring panels
10:16 daniels: yeah; Weston at least will just pick a random connector and assign it to that CRTC and it certainly should work just fine
10:16 daniels: having more connectors than CRTCs is massively common
10:16 daniels: but having them all (falsely?) report connected is definitely not common
10:16 daniels: I'm not sure what else userspace could really do here
10:18 mripard: why couldn't they all be connected? I mean, I get the uAPI discussion, but what makes it so uncommon at the hardware level that it's unreasonable to expect it?
10:19 daniels: if they're all connected then that's fine, but we have to pick only one to light up, unless clone actually works
10:20 daniels: and given that we're talking about a regression here - what changed to regress it? at which point did it work?
10:20 sima: adding the always-connected bmc changed things
10:21 soreau: unless all connectors use the same mode from the crtc?
10:21 sima: but in the end userspace needs to decide which one to light up when both are connected
10:21 sima: soreau, often even more restrictions apply, like you can't clone across hdmi and dp
10:22 sima: so many compositors stopped bothering with clone support
10:22 soreau: not wayfire :P
10:22 mripard: sima: but that's the part I don't get, why did it regress things? Is it because the default connector the compositor would pick change?
10:23 HdkR: Oh wow, no clone support? That would immediately ruin my duplicating a display that I use each day
10:23 sima: mripard, iirc yeah
10:23 soreau: HdkR: use wayfire :)
10:23 HdkR: soreau: I'm still on the X11 train :P
10:23 soreau: HdkR: ouch
10:23 sima: the commit unfortunately lacks a bit details and I don't remember more what we discussed
10:23 soreau: HdkR: I haven't x11'd since 2018
10:24 sima: HdkR, hw clone, as in 2 outputs driven by same crtc
10:24 HdkR: oh
10:24 sima: most compositors do clone with 2 crtcs for 2 outputs
10:24 soreau: yea, wayfire just fakes it
10:24 HdkR: Okay, that's way more reasonable
10:24 sima: 10-20 years ago it was much more commonly used, when gpus had 1-2 crtcs max
10:46 HdkR: NVIDIA has been stuck on 4 CRTCs for such a long time
10:46 HdkR: Would be nice if they boosted that to six at least on some configs
10:49 daniels: weston does same-crtc clone \o/
10:51 soreau: double the trouble ;)
10:54 tzimmermann: sima, mripard, the problem is not strictly related to the bmc. i have an ast device with VGA and DP. if i connect both, the compositor error happens as well. there's been a patchset to do this. and i'm now in the situation where i'd have to add another workaround to the ast driver. hence my interest in solving this in a shared code
10:55 sima: tzimmermann, but why add that workaround to ast?
10:55 sima: the kms uapi very much is that there's possibly more connected connectors than crtcs
10:56 tzimmermann: because there are devices that support vga and dp with only a single CRTC. if someone tries to use both conenctors, the compositors will fall over
10:56 sima: yeah but that compositor is kinda broken
10:56 tzimmermann: sima, tell that to userspace
10:56 sima: happy to
10:56 tzimmermann: exactly my point :)
10:56 sima: like if it's a regression because we added bmc, kernel needs to paper around it
10:56 sima: otherwise, not the kernel's problem
10:57 sima: also if it's a specific compositor, maybe, worst case, we'll do a gross hack matching the comm name like we've done for Xorg's atomic support
10:58 sima: but definitely can't do that for everyone
10:58 tzimmermann: sima, to my knowledge, it's gnome and kde and maybe others
10:58 sima: and we'd need some "I'm fixed now" escape
10:58 tzimmermann: even our in-kernel don't handle this well
10:58 tzimmermann: AFAIK, only weston supports cloning correctly
10:58 sima: yeah, maybe we should try to fix that first then ...
10:58 sima: old Xorg does too
10:59 sima: since it's old enough to have been around when cloning really mattered
10:59 tzimmermann: it's a problem in the gnome settings app; but maybe not the backend
10:59 tzimmermann: the issue happens with gnome on x as well
10:59 sima: tzimmermann, so what exactly is the issue? only lights up one of the outputs at random, or actually dies?
11:00 tzimmermann: when trying to set display modes, the settings app does nonsense
11:00 sima: and yeah if it also happens on Xorg there's pretty much nothing we can do, because we have no idea what's driving the xrandr proto
11:01 tzimmermann: independently from the actual backend (xorg, kms), the gnome settings app fails set any modes if there are more connected outputs than crtcs
11:01 tzimmermann: it reports "incompatible hardware" without doing anything
11:02 tzimmermann: so changing display modes is not possible
11:02 sima: eh, feels like a not too horrible failure mode
11:03 sima: it's a bit impressive levels of suck, but oh well
11:03 sima: maybe improving the heuristics for fbcon might help, but otherwise this really is fully on userspace to suck less imo
11:04 tzimmermann: sima bug report is here: https://gitlab.gnome.org/GNOME/mutter/-/issues/3157
11:04 tzimmermann: sima, but why do we even bother about the BMC then?
11:04 sima: dunno, I didn't merge the code for enabling that
11:05 sima: so don't ask my about the motivation for that
11:05 tzimmermann: sima, i did. but back then it was considered a kernel regression
11:05 sima: oh you mean why we bother with the hack for bmc?
11:05 tzimmermann: yeah
11:05 sima: yeah because regression, bmc was added later on
11:05 sima: but for anything that's always been there, it's just userspace being absolutely busted
11:06 sima: so should also limit that bmc hack only to the current set of ast/mgag200 hw, when/if we add more we should disable it for those
11:06 sima: since otherwise we'll never be able to retire this hack
11:06 sima: and if bmc would have been there from the start, we wouldn't have needed to do anything at all
11:06 tzimmermann: but if i add vga+dp support for ast, it will also regress userspace. that's patch 5 of my patchset
11:07 tzimmermann: the distinction isn't really clear to me
11:07 sima: oh yeah, I guess then you get to add the hack to more places
11:07 sima: or you don't, and wait for someone to report it as an actual regression
11:07 sima: maybe mutter gets fixed faster, since it's an issue across the board
11:08 tzimmermann: that's why i'd like to put the code in some shared place.
11:08 sima: also I thought for the bmc regression it was a case of "black screen, unusable"
11:08 sima: if the issue is only that mutter can't change the resolution, I'm much more leaning towards reverting those hacks
11:09 tzimmermann: sima, no black screen
11:09 tzimmermann: now we're talking :)
11:09 sima: we generally don't preemptively hack around terribly broken userspace
11:10 sima: so yeah if kde is also a case of "displays, but can't change the config" then my vote is on reverting these all again
11:11 jfalempe: I had to fix a conflict when pushing https://patchwork.freedesktop.org/series/135356/ to drm-misc. I followed the dim documentation, and pushed the resolution. I hope I didn't mess up :)
11:12 sima: tzimmermann, there's also the hack to force disable the unwanted output on either cmdline or in sysfs, I guess that should also get mutter back into cooperating
11:13 sima: so that might be enough to handle anyone reporting this as a regression for an actual user, if it actually ever happens
11:13 sima: users often tend to be a lot more limited in what they do than exhaustive testing, especially for server platforms
11:13 tzimmermann: sima, really? so one could disable the bmc output on the command line ?
11:14 sima: video=OUTPUT:d iirc
11:14 sima: would need to check docs and test
11:15 tzimmermann: jfalempe, ^
11:16 sima: might also only work for fbcon, but that would stop fbcon from cloning, which might be enough to give mutter something it doesn't understand
11:16 javierm: sima: according Documentation/fb/modedb.rst, you are correct on the :d
11:18 sima: single crtc gpus where kinda en vogue a decade plus ago, not the first time I've had to deploy this hack :-)
11:19 sima: ok checked the code, forcing output state on the cmdline sets connector->force, i.e. the same thing you also can set through sysfs
11:19 sima: which means this should work for everything
11:19 sima: until you change it through sysfs
11:21 jfalempe: ok, so at least there is a workaround if we report both bmc and vga as connected ?
11:21 tzimmermann: sima, for cloned outputs, our in-kernel client code picks 1024x768 by default.
11:21 sima: tzimmermann, hm maybe we should try to fix that then?
11:21 sima: I thought it's smarter and aims for a common one :-/
11:21 tzimmermann: jfalempe, the dicussion is now whether we should remove the workaround entirely
11:22 tzimmermann: sima, yeah we should try ot fix that
11:22 tzimmermann: so at least the kernel works correctly
11:22 sima: yeah if we can improve fbcon clone enough that it's good enough by default
11:22 sima: and the hack if anyone really wants working mutter/kde config tool back
11:23 sima: and there's no black screen, then I think we should ditch the hacks
11:23 tzimmermann: sima, that sounds at least like a way forward.
11:23 sima: ok forgot to get some lunch, gtg now, I'll be back in a bit
11:24 tzimmermann: i can already hear userspace devs curse us
11:24 tzimmermann: cu
11:33 apelete: Hi there
11:41 FLHerne: apelete: Welcome :-)
11:59 zmike: mareko: can you rb https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30224 ? this fixes msaa detection on r300 (tested by ondracka)
12:03 apelete: does someone know the current status of sr-iov support in Linux mainline for intel i915 gpus ?
12:04 zmike: eric_engestrom: I think this should be the last piece before I can land everything^
12:04 zmike: maybe branchpoint today or tomorrow after all depending on the state of marge
14:32 zmike: marge is getting screwy so I'm gonna reassign some MRs
15:09 tzimmermann: jfalempe, hi. any news on the mgag200 machine for testing vblank interrupts?
15:14 jfalempe: tzimmermann: sorry, the machine I used at that time is no more accessible.
15:14 jfalempe: But it worked on the two other machine I've tested, I should have updated you.
15:14 tzimmermann: thanks for testing.
15:15 tzimmermann: i'd like to merge the patchset then
15:16 tzimmermann: even if something breaks, it's easy to revert and the first 5 patches in the series are useful anyway
15:23 tzimmermann: jfalempe, can i add your Tested-by to the patch?
15:23 jfalempe: tzimmermann: yes sure.
15:23 tzimmermann: great, thanks again
15:35 zmike: MrCooper: so what all needs fixing in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30224
15:36 MrCooper: is there any other use case than eglinfo (which never worked before)?
15:36 zmike: yes, xservers
15:37 MrCooper: don't think so, can't work without DRM master anyway
15:37 zmike: well excepting the bo_get_handle part, that MR does fix xserver usage
15:38 zmike: with DRIL anyway
15:39 MrCooper: ah, so it's a DRIL specific issue? Then it's probably still broken with the amdgpu winsys and other drivers though
15:40 zmike: is amdgpu winsys actually affected by this? I thought everything there would support glamor
15:45 MrCooper: glamor should use the same DRM fd as xf86-video-amdgpu/ati pass to gbm_create_device, so still confused what the issue is
15:45 zmike: the issue is this is not the glamor path
15:46 MrCooper: if the DRM fd works for glamor, why not for GBM?
15:48 MrCooper: both should hit the same code in the Gallium driver
15:51 MrCooper: something doesn't add up for me
15:52 daniels: MrCooper: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28378/diffs?commit_id=488cef65333d31a8947384ed8260858fd0d6c0c5#d34686e2380a4eff1d7c2cd955af9e84d86b1b86_0_275
15:54 MrCooper: pass the fd from drilCreateNewScreen to init_dri2_configs ?
15:55 daniels: yeah, I was just grepping to see, and it looks like that should work
16:04 HdkR:  /12
16:06 MrCooper: this explains why it works with the amdgpu winsys though, it automagically reuses the pre-existing DRM file description internally instead of the one created by eglGetPlatformDisplayEXT
16:23 eric_engestrom: zmike: you closed !30227, was that on purpose or a mis-click?
16:24 zmike: on purpose
16:24 zmike: I've never misclicked in my life
16:31 MrCooper: or explained why you did something :P
16:32 zmike: I'm not misunderstood, I'm mysterious
16:33 eric_engestrom: I just saw your comment MrCooper on the other MR, I think you're to blame for that MR being closed :P
16:35 MrCooper: guilty as charged
16:35 zmike: I'm struggling and failing at multitasking today
16:36 MrCooper: well our brains can't really do it, though they make us believe otherwise
16:36 zmike: mine is very convincing
16:47 karolherbst: vsyrjala: I was looking into an EDID related bug for nouveau and noticed, that some stuff might be missing. E.g. it isn't apparent to be if e.g. the errata 2 of CTA-861 was applied. But I'm also not sure if what nvidia is doing maps nicely to how drm declares those things. But more curiously there is some "Resolution Identification" stuff going on I have no idea about. I just saw that you were adding those modes like 5? years ago
20:51 mattst88: Fossilize ERROR: Cannot copy unknown pNext sType: 1000068000.
20:51 mattst88: Fossilize WARN: Failed to record graphics pipeline, usually caused by unsupported pNext.
20:51 mattst88: 1000068000 is VK_STRUCTURE_TYPE_PIPELINE_ROBUSTNESS_CREATE_INFO_EXT
20:51 mattst88: anyone know why fossilize wouldn't be able to handle something using VK_STRUCTURE_TYPE_PIPELINE_ROBUSTNESS_CREATE_INFO_EXT?
20:52 mattst88: I see various search hits for "fossilize 1000068000", but nothing useful
20:52 Sachiel: someone needs to add support for it in there, I guess
21:33 mattst88: filed https://github.com/ValveSoftware/Fossilize/issues/249
21:35 zmike: HKA is on vacation, so I doubt that will get resolved anytime soon
21:36 Sachiel: is it like filing a zink issue in early november?
21:36 zmike: yes