00:39 heftig: karolherbst: done
00:39 karolherbst: thanks!
00:47 karolherbst: ohh I just noticed I forgot to link the actual PR 🙃 but you figured it out regardless.. sorry for htat
10:53 pq: How did enum drm_colorop_type end up in a public UAPI header?
11:45 emersion: pq: enums should be in public API headers now
11:46 emersion: I think we're missing some for colorops... I just ended up hardcoding them
11:50 zzag: emersion: that'd actually help with bugs like https://invent.kde.org/plasma/kwin/-/merge_requests/9659
11:51 zzag: an enum coming from a header would prevent such typos
12:19 emersion: aha
12:26 pq: emersion, are the string names still UAPI too?
12:26 emersion: yes
12:28 pq: Good.
16:45 zf: Would it be reasonable to stop hiding NV12 format support behind RADV_EXPERIMENTAL=video_decode, while still hiding decode support?
18:16 nowrep: isn't that already the case?
19:27 zf: oh, my bad, indeed it is, I must have tested incorrectly
19:36 daniels: pq: the consensus about 2 years ago (?) was that enum values are uAPI, so when they are declared, the string indirection is unnecessary but harmless
22:03 zf: does XPresentPixmap() block on wait_fence? the libxpresent man page differs from the protocol. also, neither specifies what happens if the fence is NULL; what happens in that case?