00:45 Company: karolherbst: (because you're on the forefront of the AI discussions, I'm interested in your opinion in particular) What's your opinion on tools like https://sashiko.dev/ ?
00:47 karolherbst: I'd be okay with it, if the AI companies wouldn't see any money for it 🙃
00:48 karolherbst: like I think it's fine as long as it's something that gives something back to the community and not is just another source of income. But I suspect the linux thing is also "advertisement" in that sense and I suspect smaller projects _will_ have to pay for it, even though most of the genAI models are trained on the collective FOSS communities work
00:49 Company: well, projects like FDO or Gnome could ask for sponsorships to run it
00:50 Company: and some of us have employers that are keen on their employees using more AI, so...
00:51 karolherbst: my personal take on companies forcing employees to use AI is, that it makes them unfit to be maintainers 🙃
00:51 Company: but I'm still wondering if there's a catch - and I can't judge if their reports are useful or a waste of time
00:51 karolherbst: like I can't trust a person to be a good maintainer if decisions are based on "my employer might fire me if I don't do X"
00:52 Company: yeah, I was more thinking about "my employer might have extra funding if I come up with ways to use AI"
00:52 karolherbst: I think it depends, and we can always try it out for a while and make it opt-in
00:52 karolherbst: but dunno
00:52 karolherbst: it has to be a decision by the community
00:54 karolherbst: but then again, if we get it for free, so that it's "advertisement", then that can put us in a weird spot, what if they say after a year "yeah.. now you have to pay"
00:54 karolherbst: which is super likely, because all the tooling is heavily subsidized and all the companies are running at a loss with it
00:55 karolherbst: and I don't appreciate the "let's hook everybody first and then we'll reap" dynamics
00:55 Company: yeah, I've thought about that
00:55 Company: but we get sponsorships for CI - and are kinda hooked on that, too
00:56 Company: of course, that's a different relationship than getting it as an ad
00:58 Company: I have to admit I have no idea what it costs to do this, and what the expectation is for costs in a year or so
01:01 karolherbst: yeah...
01:01 karolherbst: most of our sponsorship comes form putting up logos of companies at XDC
01:02 karolherbst: we decided against corpo gitlab edition, because we also didn't want to depend on that
07:58 dolphin: airlied, sima: drm-intel-fixes PR sent
09:41 MrCooper: karolherbst: certainly need to avoid reliving the Bitkeeper experience, though this probably wouldn't be as critical
10:32 karolherbst: oh yeah.. switching the implementation is way simpler... though given our reliance on gitlab CI it might not matter much :')
11:01 emersion: i feel dumb, i'm getting these errors when building mesa main:
11:01 emersion: src/mesa/glapi/glapi/gen/unmarshal_table.c:1174:5: error: ‘DISPATCH_CMD_InternalReleaseBufferMESA’ undeclared here (not in a function); did you mean ‘_mesa_InternalReleaseBufferMESA’?
11:01 emersion: any ideas what's wrong?
11:02 emersion: that file is generated from a .xml checked in Git, with a Python script checked in Git, so i don't know how it could generate bad code
11:37 MrCooper: the source/build tree might have a stale file
11:37 emersion: i've tried deleting it
11:39 MrCooper: might be another file
11:40 soreau: git clean -fdx
11:45 MrCooper: I hit this kind of issue a few times when a file moved between source & build tree, and the old version remained
12:07 emersion: you were correct, deleting the whole build dir helped
12:07 emersion: thanks!
13:42 tomba: emersion: ping on 20260128-xilinx-formats-v8-0-9ea8adb70269@ideasonboard.com =)
14:27 MrCooper: jadahl: do you remember where the last discussion was re mutter using a simpledrm device node, which stops working when control of the GPU is transferred from simpledrm to the real driver?
14:32 javierm: MrCooper: I think that gdm ignored simpledrm to prevent this issue? https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/219
14:34 javierm: although I also see https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/347 now, maybe increasing the timeout could help?
14:34 MrCooper: hmm, somebody reported hitting it on Ubuntu 24.04, which should have that? Unless it was patched out downstream
14:35 javierm: MrCooper: yeah, my gut feeling is that this 10 secs timeout added by the second MR might not be enough for HW / cases
14:35 MrCooper: ah, or it could be the second bullet point in the latter MR
14:36 javierm: MrCooper: oh, indeed
14:37 MrCooper: hmm no, that would result in the GDM session never showing up instead
14:38 MrCooper: my guess would be that Ubuntu patched out the former MR due to the issues mentioned in the latter one
14:41 jadahl: MrCooper: I think for flicker free boot, at least my conclusion is that mutter needs to have a timeout before tryig to use simple-drm, since it seems impossible to know if amdgpu will ever load/finish loading and have a device available, and if we show the login screen with simpledrm, we'll break initial animations and potentially hdr capabilties etc
14:43 MrCooper: right, I'm looking for a discussion reference I could point the user to for more information
14:44 zamundaaa[m]: It would be great if we could know if the kernel is still attempting to load a different driver for the device
14:44 jadahl: ah, not sure where linking to would be best
14:44 jadahl: zamundaaa[m]: indeed, i've been asking for that but been told its impossible
14:45 zamundaaa[m]: The arbitrary timeouts situation is quite annoying
14:45 jadahl: yea, being able to be told up front that this is a gpu-less system would be good
14:46 javierm: zamundaaa[m], jadahl: IMO what would be great is to have a uAPI for user-space (systemd or whatever) to tell the kernel "we are done loading modules"
14:47 javierm: then the kernel could from this point don't attempt to do probe deferrals and user-space could ask if we are already at that point
14:47 zamundaaa[m]: We wouldn't need to know upfront if simpledrm is all we got, just knowing when the kernel is done attempting to load drivers that could be relevant
14:47 javierm: zamundaaa[m]: exactly
14:49 jadahl: that is pretty much what I've been asking for to avoid that timeout
14:49 javierm: theoretically there's always the possibility of a user to manually load a kernel module that doesnt' have proper module alias info / has broken autoload
14:50 javierm: but in practice I think that something to flag that systemd/udev/kmod are finished loading modules would cover most cases
14:52 jadahl: I think post-boot manual loading, or hotplugging for that matter, is a different story, and in that case, a login screen with simple-drm is the correct solution
14:53 javierm: jadahl: agreed. I was talking about the more general use case of a "tell the kernel that user-space is done loading modules" feature
14:56 MrCooper: isn't Hans' udev idea in https://gitlab.gnome.org/GNOME/mutter/-/issues/2909#note_1805829 more or less equivalent to that?
14:58 tzimmermann: oh, please. no
14:58 tzimmermann: not that discussion again...
14:58 MrCooper: don't like discussing problems? ;)
14:59 tzimmermann: not this one :)
14:59 jadahl: :D
14:59 MrCooper: it is a problem that needs to be solved somehow...
15:00 tzimmermann: one thing i noticed is that udev_is_settled() tests for platform-simple-framebuffer. that is not overly correct, as there are now plenty of system framebuffers
15:00 tzimmermann: not just simpledrm on simple-framebuffer
15:01 MrCooper: Hans' suggestion doesn't require any driver detection heuristics
15:02 MrCooper: just waits for udev to finish handling the device
15:02 javierm: MrCooper: yeah, if it can be inferred from uevents then that's even better since doesn't require any kernel changes
15:03 emersion: pq, what was your reasoning about DRM_FORMAT_Y8?
15:03 emersion: i'm struggling to understand
15:03 javierm: MrCooper: anyways, regardless that timeout of 10 secs in gdm seems to short to me, because in the thread you shared people were talking about 12 secs for the amdgpu driver to be probed IIUC
15:04 MrCooper: ... on a really slow system
15:04 pq: emersion, about what exactly?
15:04 emersion: the difference with R8
15:04 javierm: MrCooper: which might be similar to the system of the ubuntu user that's reporting the issue
15:05 tzimmermann: my point is: we now have a sysfs attribute 'boot_vga' (i think) and that is set only for the system's boot-up pci graphic device
15:05 tzimmermann: once gdm sees that, it can stop waiting and use that device.
15:06 pq: emersion, I don't remember anymore what I said. Obviously the color model is different. R8 expands to (R, 0, 0), but Y8 expands to (Y, Y, Y) in RGB.
15:06 tzimmermann: does it do that already?
15:06 MrCooper: javierm: doubtful, it's a Zen 2 based APU
15:06 javierm: MrCooper: I see
15:06 emersion: pq, i was hoping to see a wall of text in your R-b but it was just a lone R-b :P
15:07 MrCooper: tzimmermann: that's not set with simpledrm or other generic drivers?
15:07 pq: emersion, the discussions were probably in the earlier incarnations of the patch over the years.
15:07 emersion: ah, so R8 really means zero for other channels, not "undefined"?
15:07 javierm: tzimmermann: point 2 in https://gitlab.gnome.org/GNOME/gdm/-/merge_requests/347 mentions that it is not always the case
15:07 tzimmermann: the gdm loop would be "wait until settled or the boot-up vga shows up".
15:08 tzimmermann: MrCooper: it's a pci attribute in sysfs. simple-framebuffer and all the others are platform devices
15:08 pq: emersion, we tend to use X to mark undefined, while B and G are just missing completely from R8.
15:08 emersion: pq, my main concern is that it'll create an alias for userspace
15:08 emersion: pq, X is for padding
15:08 pq: emersion, we don't use RGB formats for other YUV data either, even if the layout would match.
15:08 emersion: by "alias", i mean that userspace will need to shove R8 into Y8 and vice versa
15:09 emersion: depending on what the driver supports
15:09 pq: Does anything actually support R8, and if yes, what does it expand to?
15:10 tzimmermann: javierm, sure. it's rather new. about all the old systems can update. putting a complicated heuristic in place for them might not be of much use
15:10 pq: We have also the "darkness" pixel formats nowadays, I think.
15:11 emersion: yea
15:11 javierm: tzimmermann: right, agree
15:13 pq: emersion, cannot lei dig up my emails about it? Sender is me either gmail or collabora.com, and in a thread about Y8.
15:13 pq: and the list almost surely drm-devel
15:14 pq: *dri-devel
15:15 pq: emersion, let's say you have a YCbCr-to-RGB conversion hardware block. How would feeding it with R8 look like?
15:17 pq: What about GL and Vulkan when sampling from R8 or a luminance texture, what RGBA do you get?
15:21 emersion: no known KMS device supports any R-only format
15:22 MrCooper: for GL, I want to say R8 gets the sampled value only in the R channel, luminance in all of RGB, and the A channel samples 1.0
15:22 pq: I believe so too.
15:23 pq: emersion, I meant, look like API-wise. This block takes YUV, and I'm giving it R8.
15:24 pq: the list of supported formats would need to include both YUV and some set of RGB-reinterpreted-as-YUV
15:27 pq: In the past I did argue that RGB are just arbitrary data channels with no indication to what's in them, but then we already have YUV formats, and they are explicitly named R,G,B,A,Y,Cb,Cr and not C1,C2,C3,C4.
15:28 emersion: C is already used for something else :)
15:28 pq: it wouldn't be
15:28 pq: paletted format is just another "R8" in that case
15:30 emersion: what i mean is that we already have DRM_FORMAT_C8 for paletted formats
15:30 javierm: yeah, AFAIU Cx is for color indexed values and Rx is for linear
15:31 pq: exactly - instead of "single 8-bit channel" format we have paletted, red, darkness, and now luminance formats
15:31 javierm: and yeah, Rx doesn't mean "red" but an arbitrary single channel for monochrome displays
15:32 emersion: so… R could be any color, but Y is grayscale?
15:32 pq: Y is luma (electrically encoded luminance percentage)
15:32 javierm: emersion: R could be grayscale too
15:33 emersion: vulkan spec says:
15:33 emersion: >If after conversion, less than four of the (R,G,B,A) components are present, missing components are substituted by the components of (0,0,0,1) for missing (R,G,B,A) components, respectively.
15:34 pq: javierm, those are more of a corner case. Since we don't actually have a format for "undefined color model", people use R8.
15:34 javierm: pq: yeah, I understand is just for convenience but falls into your "arbitrary data channels" definition
15:35 pq: emersion, nice, so Vulkan agrees that R8 expands to (R, 0, 0, 1).
15:35 emersion: yup
15:35 pq: javierm, indeed - it may have been the only example in favor of that concept.
15:36 pq: A display could be e.g. single-channel axis between blue and white. No black at all.
15:36 pq: I recall some tiny LCDs like that.
15:37 javierm: pq: yup, I've some of them. white-on-blue or white-on-green
15:37 pq: might have been 1 bit per pixel though, so they'd be more C1 format
15:37 javierm: pq: but don't really have a palete so are more like R1 ?
15:37 pq: are they?
15:37 pq: they have a fixed palette
15:38 pq: and in fact knowing that they have a fixed palette is the only way to plug their color model into a more generic software system.
15:38 javierm: pq: given that only have two values I guess that's debatable ?
15:38 pq: how so?
15:38 javierm: because I remember that when porting the ssd130x driver from fbdev to DRM I asked and was told to use R1 instead of C1
15:39 pq: why?
15:39 emersion: i think R1 makes more sense in that case
15:39 emersion: C1 could be arbitrary 0/1, R1 attaches a meaning to 0/1
15:39 emersion: should the driver expose Y1?
15:40 pq: R1 implies the colors are RGB=(0, 0, 0) and RGB=(1, 0, 0). With a palette you could actually say 0 = RGB(0, 0, 1) and 1 = RGB(1, 1, 1).
15:40 javierm: pq: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7dae503584a1
15:40 javierm: pq, emersion: I've to pick my kid from school, back in 1 hr
15:41 pq: However, I understand that DRM probably does not have the concept of a fixed palette. There is only a programmable arbitrary palette.
15:41 javierm: pq: but that patch was actually why I learned the diff between Cx and Rx :)
15:43 pq: I think the lack of a concept for a fixed palette is somewhat of a design wart, which muddies things a bit, but can we worked around in practice.
15:44 pq: Then again, KMS doesn't even have an API to set a palette for a fraembuffer.
15:46 MrCooper: it really does, it's called "gamma LUT" :)
15:46 pq: yeah, on the CRTC
15:46 pq: not even on the plane, until very very recently
15:46 pq: let alone the FB
15:47 MrCooper: true
15:47 MrCooper: maybe the driver could make the gamma LUT immutable?
15:47 pq: Programming the palette on the plane would make most sense, given that the color pipeline is RGB.
15:49 pq: MrCooper, there's a problem with that. You feed R8 to the display and *panel* converts it into whatever. If you expose (even an immutable) LUT in between, that LUT is supposed to modify the pixel values as they flow through.
15:50 pq: So there should be a panel property (well, connector I guess) that says "this device has a fixed palette, here it is", and then userspace programs the KMS pipeline to produce data that is suitable for indexing into the palette.
15:51 pq: So the old-school API supported paletted FB on an RGB display. It never supported paletted displays AFAICT.
15:54 pq: anyway, I suppose all this did not help emersion one bit :-)
15:54 emersion: i'm less and mroe confused at the same time :P
16:34 javierm: pq: I guess that for example a 16 grayscale dot matrix display could even support both R8 and C8 ?
16:34 javierm: with C8 a CLUT could be set and when using R8 would have a fixed linear values ?