00:26zmike: awesome work guys
09:53MrCooper: DemiMarie: my understanding is yes in principle, though anything which can be represented as a dma-fence must have a timer or other mechanism which ensures that the dma-fence is signalled within reasonable time
10:00pinchartl: emersion: you've reviewed "[PATCH] drm/fourcc: Add RGB161616 and BGR161616 formats" (20240226132544.82817-1-jacopo.mondi@ideasonboard.com). do you plan to push it to drm-misc ? I'm unsure what the rule is regarding pushing core changes to drm-misc. do we need a R-b from any DRM contributor, from a drm-misc maintainer, or from a DRM maintainer ?
10:01pinchartl: we can push it too, once we know what the rule is :-)
10:01pinchartl: sima: ^^
10:02pinchartl: mlankhorst: ^^
10:02sima: https://drm.pages.freedesktop.org/maintainer-tools/committer-drm-misc.html#merge-criteria
10:03sima: and ack is sufficient
10:03pinchartl: thank you :-)
10:03sima: I mean best judgement and all that applies, maybe don't push really gnarly locking rework with just a cursory ack :-P
10:04pinchartl: yes, the usual common sense rule of not gaming the system
10:07sima: pinchartl, jmondi this reminds me of the other discussion of formally adding libcamera to the list of userspace apis/libraries than can ask for drm_fourcc.h allocation
10:08sima: not sure what happened to that idea?
10:09sima: I think a handful of acks from the community would be good, just to sign off on this direction
10:09pinchartl: Jacopo sent patches and things died out I think
10:09pinchartl: we can respin that
10:10jmondi: sima: do you mean https://lore.kernel.org/all/20240228102245.80469-2-jacopo.mondi@ideasonboard.com/T/
10:13emersion: pinchartl: my understanding is that maintainer ACK is not strictly required
10:14emersion: but better ofc
10:14pinchartl: emersion: who are the official maintainers for 4CCs ?
10:14emersion: DRM?
10:15pinchartl: is that Sima and Dave, or Maarten, Thomas and Maxime ?
10:15pinchartl: it sounds like one of the areas that are collectively maintained
10:15sima: pinchartl, yup, just missed it
10:15pinchartl: everybody is responsible for them, so nobody does anything :-)
10:16emersion: i think that falls into "DRM DRIVERS AND MISC GPU PATCHES"
10:16sima: yeah
10:17pinchartl: ok, so strickly speaking, Thomas, Maarten and Maxime
10:17emersion: formally, what does "reviewed" or "acked" in the maintainer-tools docs mean?
10:17emersion: maintainers, committers, contributors, or anybody>?
10:18emersion: i've assumed "committers" so far
10:18sima: emersion, it's all a bit a judgement call
10:18emersion: yeah, i suppose it depends on the patch ofc'
10:18sima: which is why we link to the more in-depth discussion for drm-intel
10:18sima: that tries to answer this kinda unanswerable question a bit at least
10:19sima: since the real rule is that if you merge it and there's immediate screaming, it wasn't enough reivew
10:19emersion: pinchartl: you have drm-misc push access right?
10:19sima: emersion, daniels, airlied https://lore.kernel.org/all/20240228102245.80469-2-jacopo.mondi@ideasonboard.com/T/ maybe ack from you too, should cover enough of the gl/vk/drm side?
10:19sima: pinchartl, and yours and then it's imo good
10:20sima: but you can go fish for more ofc :-)
10:21emersion: sure, ack
10:23pinchartl: emersion: yes
18:05DavidHeidelberg: is possible that Mesa doesn't implement any (EGL) display extension ?
18:08DavidHeidelberg: I wondering after this [1] EGL spec change, where would we put display extension. We have dislay extension EGL_KHR_get_all_proc_addresses, but we handle it as client extension... [1] https://github.com/KhronosGroup/EGL-Registry/pull/199/files
18:16daniels: DavidHeidelberg: every extension which isn’t the EGL_KHR_platform_* is a display extension
18:16daniels: so yeah, loads
18:17DavidHeidelberg: so does that mean, they're reported same way as the client extensions?
18:18DavidHeidelberg: what I'm wondering after this spec change, what has to be changed on the Mesa side, eventually on GTK/Firefox side
18:19daniels: on the users - they’ll discover it through eglQueryString(dpy, EGL_EXTENSIONS) with a real dpy, not EGL_NO_DISPLAY
18:24daniels: just looked at the MR and it shouldn't be added to ClientExtensionString in src/egl/main/eglglobals.c
18:25DavidHeidelberg: right, I got to that conclusion, since glvnd will filter it ;)
18:25daniels: add an _EGL_CHECK_EXTENSION() case to _eglCreateExtensionsString
18:26DavidHeidelberg: thanks!
18:27daniels: np
18:29DavidHeidelberg: I think now we're ready to go in, as it'll pass all the tests
18:29DavidHeidelberg: if you have chance to drop the A/R-b on the MR (or at least the particular commit with this change after I test it locally, I would be very grateful)
18:30zmike: \o/
19:10zmike: DavidHeidelberg: there's already a solution: -Dintel-rt=disabled
19:10zmike: :D
19:11DavidHeidelberg: sounds good to me, but I'll keep the issue opened up :P
19:11DavidHeidelberg: thanks
19:14DavidHeidelberg: extension seems to be reported now after the change :) just need to adjust GL-CTS to account for that
19:15Company: DavidHeidelberg: GTK doesn't use select_group, it just checks the default list of configs and discards all the ones without an RGBA visual
19:33DavidHeidelberg: Good then, so only place where it's checked is likely GL-CTS
19:47derr: 2/Quit
20:06gfxstrand: eric_engestrom: How long do we have before 24.1 final? I kinda want to get modifiers in for NVK.
20:17daniels: please …
21:23DavidHeidelberg: eric_engestrom: any patches u may want to apply to CTS? I'll be pushing https://gerrit.khronos.org/c/vk-gl-cts/+/14636