05:08 mareko: zmike: are you able to review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27198 ?
07:32 tjaalton: eric_engestrom: thank you for a punctual mesa 24.0.0 release!
07:55 eric_engestrom: tjaalton: your welcome :)
08:00 eric_engestrom: MrCooper: re- code-validation, no, it's a bug from when we added the python-test job which needed special rules to run on files that are not part of the mesa build; I noticed this but figured it was low priority to fix since having these code checks automatically running in forks (in the first push creating each branch IIRC) might actually be desirable
08:01 eric_engestrom: (and those are very short jobs so not taking much resources)
13:26 mripard: let's assume a DVI/DP/HDMI connector has completely broken EDIDs (like, let's say, reporting an analog sink, or missing the required extensions), how confused would the compositor be?
13:28 pq: mripard, anything between not at all and image unreadable.
13:28 mripard: cool
13:29 mripard: so, uh, we're doing that in the EDID loader
13:29 pq: IOW, we would need to look at the EDID fields individually to determine their impact.
13:29 mripard: we have a few EDID in the kernel that can get used for any connector
13:30 mripard: and they are all analog EDIDs, without any kind of extension
13:31 mripard: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_edid_load.c#L42
13:31 pq: I doubt any compositor would look at the analog bit, I cannot imagine what they'd do with that. Report to user at most.
13:32 pq: you wouldn't happen to have edid-decode reports of those edids?
13:33 pq: userspace generally should not be looking at video mode timings in EDID but rely on the list from the kernel, so that part might be safe depending on where the kernel gets its list
13:33 mripard: https://lore.kernel.org/dri-devel/jlkoofv7nszj2uqmo2672yo4wjd3yjqarge2l2hxofixcchu6a@j72pa4iybitd/
13:35 mripard: (it's the second one in that list)
13:35 pq: userspace is also not interested in any of the video signal format things, because userspace has no way to select those in KMS anyway.
13:36 pq: that may change one day, though
13:39 pq: if EDID is missing everything about HDR or WCG, then I think that won't hurt either, because I suppose HDR and WCG monitors default to sRGB SDR anyway. It just stops people from using their HDR/WCG capabilities.
13:39 mripard: ok, so probably not a big deal at the moment, but still something we should fix at some point if we want to expose some control over the video bpc and format?
13:40 pq: yeah
13:41 pq: I guess these pre-baked EDIDs exist for monitors that have none?
13:41 pq: would be nice if they were generated to be as true to what is certainly known already as possible, like connection type
13:43 pq: or, just have no EDID and configure kernel mode lists etc. in some other way
13:44 pq: that might actually be the best course of action, for all I know
13:45 mripard: yeah
13:45 pq: you could see what happens if you simply stop these pre-baked EDIDs from ever reaching userspace
13:45 mripard: one thing that isn't working at the moment due to this is audio
13:46 mripard: since the display isn't considered an HDMI monitor, audio is disabled
13:46 mripard: even though the monitor might be capable of it
13:46 pq: hah
13:46 mripard: having somewhat reasonable EDIDs for each connector type would solve this too
13:47 pq: smells like awful many new kernel command line options coming, if most things need to be configurable :-D
13:48 pq: How about letting people craft an EDID file of their liking with some simple tool, and load that instead of anything pre-baked?
13:48 any1: I work for a company that sells something akin to a set-top box and I've made some groovy kernel patches to "solve" exactly these problems. :p
13:48 pinchartl: I'm also inclined to prefer not reporting EDID at all in those cases
13:48 jani: sima: thoughts on shifting dim to operate more on the currently checked out branch without having to specify it?
13:48 pinchartl: instead of lying
13:49 pq: swick[m] has been thinking of EDID crafting tools in the libdisplay-info project.
13:49 jani: sima: dim apply-branch vs. dim apply
13:50 jani: sima: iirc it was mainly a safeguard against applying patches to the wrong branch by accident
13:51 pq: mripard, I see two sides to this issue: kernel sending bogus EDID to userspace, and EDID being used as a kernel configuration blob (chosen on the kernel command line).
13:52 pq: the latter being "I know my display can do 1600x1200 so I want the kernel to expose that mode"
13:53 mripard: pq: I wasn't aware swick[m] was working on it, but I guess I'm working on one too: https://github.com/mripard/redid/
13:54 mripard: pq: we can probably solve the latter easily by adding more EDIDs to the kernel and selecting them based on the connector type for example
13:55 mripard: without introducing anything user-facing
13:55 swick[m]: blergh, stupid matrix
13:55 pq: mripard, I wonder, number of modes × connector types × audio yees/no × ...
13:56 swick[m]: mripard: I had the urge to rewrite libdisplay-info in rust multiple times
13:56 mripard: but the former, I don't know how we could solve it, or rather I'm not sure how we can differentiate between users fixing their broken monitors by dropping a custom edid in their firmware directory, which is legitimate and should probably be exposed to userspace
13:56 jani: mripard: so why would those edids from drm_edid_load.c be used? you have to explicitly choose them
13:56 mripard: and the kernel coming up with its own which probably shouldn't
13:57 mripard: swick[m]: it was for something entirely different that I did that, but if it can help / be reused, it's there :)
13:57 jani: also, if the user chooses a broken edid for the display, imo they get to keep both pieces
13:57 pq: mripard, surely the kernel nows if the command line referred to an actual file or just something built-in?
13:58 mripard: jani: afaik, it's used as a fallback to ignore the EDID the monitor reports when they are broken / failing
13:58 mripard: and part of the issue is that it's never told anywhere that they are broken
13:58 pq: I'd never forward built-in EDID to userspace.
13:59 jani: mripard: fallback how? I think they're only used if explicitly specified, no?
13:59 mripard: yeah, I meant a user fallback :)
13:59 sima: jani, if the current commands with explicit branch names stay, then I think no objections from me
13:59 swick[m]: mripard: well, I think both parsing and generating should be done in a single code base because both need some internal representation of all the features
14:00 sima: jani, if you want to remove them too, maybe mild grumbling
14:00 swick[m]: are you going to spend more time on it?
14:00 jani: mripard: I have to wonder if anyone really uses those builtin EDIDs anymore
14:01 sima: mripard, I thought the built-in edids are more like examples, and if you really have a that broken monitor, stitch your own together and load it with the fw stuff
14:01 sima: jani, yeah I don't think they're ever meant for production use really
14:01 any1: The biggest problem with forcing a crafted edid from user space is that then you don't get notified when the EDID changes
14:01 jani: sima: rip them out and see if anyone notices ;)
14:02 sima: any1, I thought we've fixed those issues of missing hotplug uevent generation?
14:02 jani: any1: please elaborate
14:02 sima: otherwise could add the missing call, wouldn't be the first missing uevent we have by a long shot :-/
14:03 pq: userspace can upload EDID after boot-up?
14:04 any1: Well, a while back, I was dealing with poor communication on the bus on which the EDID is communicated, so I added something to the kernel that can signal back to userspace if the EDID is good or not. If it was bad, I crafted an EDID, forced the connector on and forced the EDID via sysfs
14:05 any1: pq: yeah, it's somewhere in /sys/kernel/debub
14:05 any1: err, debug
14:05 pq: oh, /sys/kernel/debug does not exist in production
14:05 jani: both the override edid and the firmware edid loaders are bolted to edid read at such a low level nowadays, that it's really the same as the edid changing on the display
14:06 any1: yeah, the problem was that I couldn't get the EDID from the display after forcing it, so I switched tactics
14:06 jani: that's kind of the point ;)
14:07 jani: I guess what you're after is a per-display instead of per-connector way of forcing an EDID
14:07 jani: but to identify the display, you'd have to read, uh, the edid
14:08 any1: I'm just saying that crafting edids from userspace isn't an ideal solution to bad edids, as is
14:08 any1: Unless you ignore the kernel completely
14:09 jani: I'm not sure the solution to bad edids lies in the kernel either
14:09 pq: The ideal solution is to have the display provide a good EDID. :-)
14:09 jani: ah yes, the unicorn pony solution ;)
14:09 pq: well, *ideal*
14:09 any1: Yeah, let me just call up LG and Samsung...
14:10 pq: meaning there is no ideal solution at all
14:10 jani: we have some edid quirks, and we also filter out *some* edid extensions with broken checksums in the kernel
14:11 pq: I guess you're looking for some kind of "one-shot EDID from userspace" that applies until the next hot-unplug on the connector?
14:12 any1: Anyway, what I ended up doing was to edit the list of fallback modes in the kernel and adding a bunch of other hacks. Here is one for the brave: https://paste.sr.ht/~andri/8b975afa93d9060eea981d1ae7ecc306a4e7ade4
14:12 pq: jani, do those fix-ups end up in the EDID given to userspace, too?
14:12 any1: pq: Yeah, that would be good
14:13 jani: pq: yes
14:13 jani: pq: no
14:13 jani: :)
14:13 pq: I see you talk like an EDID.
14:13 jani: :D
14:13 any1: lol
14:14 jani: the quirks we have affect the parsed results, and don't show up in userspace. but when we filter edid extensions out, they're filtered from userspace too
14:14 pq: alright
14:14 jani: I think the argument has been made that we should not filter out extensions, even if they have broken checksums
14:15 any1: sima: Can you point me to a commit for a fix for "missing hotplug uevent generation"?. I wonder if I might have been dealing with that problem...
14:15 sima: any1, jani might know, since it was a huge junk of work to redo how it all works
14:16 sima: but like jani said, the forced edid should look like a real edid read from the sink for the higher level drm code in the kernel
14:16 sima: and so you /should/ get all the usual events
14:16 jani: the silliest thing is, we originally, a long time ago, filtered all extensions with bad checksums. but then noticed some docks or something modified cea extension but didn't update the checksum -> we don't filter cea extensions with broken checksums
14:16 sima: originally it was a separate path, if I recall correctly
14:16 mripard: swick[m]: I'll continue to work on it to support (at least) HDMI completely (so more descriptors, extensions, etc.). I've been working on it for the last few weeks, was bored and wanted to move to some other things, and got pulled into that discussion again :)
14:17 mripard: but yeah, for the foreseeable future I intend to work on it
14:17 any1: sima: yeah, but I might have been dealing with this issue in something unrelated to forcing edid
14:17 mripard: and being able to parse EDIDs is fair indeed
14:18 swick[m]: dunno what it is about EDID but it feels like everyone starts their own thing and I'm going to be guilty myself
14:18 mripard: jani, sima: the RPi folks seem to use it regularly at least
14:18 sima: mripard, the built in edids, or the override stuff in general?
14:19 swick[m]: jani: I would appreciate if the kernel didn't mess at all with the EDID blob that's given to user space
14:19 jani: any1: look at check_connector_changed() in drm_probe_helper.c and how it's used. edid property update bumps epoch_counter if the edid changes
14:20 jani: swick[m]: agreed. maybe we could try a patch that stops doing that and see if anything falls apart
14:20 mripard: sima: both, really
14:21 swick[m]: btw, the kernel is still not looking for DisplayID, is it?
14:21 mripard: I think it is but it got introduced recently
14:21 swick[m]: the non-embedded blobs
14:21 jani: swick[m]: we're not
14:21 jani: I had some test patches for that, sent it to intel CI, and the resultes were not encouraging
14:22 swick[m]: has anyone seen a non-embedded DisplayID blob?
14:23 jani: swick[m]: some displays in intel CI responded in the Display ID ddc address... and had either garbage or a plain EDID there
14:23 swick[m]: oh boy
14:23 jani: swick[m]: iirc no display had an actual Display ID in there :/
14:23 jani: par for the course
14:43 pq: swick[m], I think the allure is that you have a spec, and "all" you need to do is to implement it, and it doesn't even depend on hardware, and is well contained. :-) Also, "this looks simple enough"... a perfect project to execute perfectly.
14:43 zamundaaa[m]: jani: Just FYI, to complicate matters more, there is at least one userspace program relying on the exact EDID blob to identify displays...
14:43 zamundaaa[m]: Any time the kernel changes the blob, Plasma 5.27 users (or Plasma 6 with Xorg) get a brand new display configuration for that display
14:45 pq: any time the kernel changes the way it changed the blob, I presume?
14:45 jani: zamundaaa[m]: my gut feeling is that the broken checksums isn't all that common
14:46 jani: because we already accept broken checksums for cea extension, and that's the most common extension anyway
14:47 mripard: pq: I plead guilty
14:48 mripard: (but also, I couldn't find a library to *generate* them back when I started)
14:48 jani: mripard: I presume you've checked how the current builtin edids were generated. ugh.
14:49 mripard: I mean, generating EDIDs with assembly and makefiles look perfectly reasonable to me
14:49 jani: o_O
14:50 mripard: (I was being sarcastic)
14:50 jani: *phew*
14:51 jani: it could be a fun hobby project to write a tool to a) parse an EDID into yaml, and b) produce EDID from yaml
14:53 jani: of course, it would be yet another edid parser :)
14:54 zamundaaa[m]: So ideally this should only happen once... Forward the exact edid from the display, with all its brokenness, and never modify it or send generated ones
14:59 pq: jani, swick[m] was planning something like that in libdisplay-info.
14:59 emersion: yeah
14:59 emersion: https://gitlab.freedesktop.org/emersion/libdisplay-info/-/merge_requests/158
15:00 emersion: and https://gitlab.freedesktop.org/emersion/libdisplay-info/-/merge_requests/120
15:14 jani: oh but then it's not a fun hobby project ;)
16:18 mripard: pq: https://codeberg.org/ral/pasedid.git
16:20 mripard: pq: mine went from wanting to generate EDIDs from code, to wanting to generate *proper* EDIDs from code, to wanting to generate proper EDIDs from code and YAML :)
16:58 mripard: sima, swick[m]: I'm still not sure what to do with https://lore.kernel.org/all/20231207-kms-hdmi-connector-state-v5-8-6538e19d634d@kernel.org/. sima was saying that the property was good to go and the doc was good, swick[m] says it's not good enough and we should improve it further. What should I do?
16:58 mripard: also, I have no way to tell what was the original intent of the i915 devs
16:59 swick[m]: all I want is a bit more documentation on the expected behavior, which I guess is whatever i915 does right
17:00 swick[m]: isn't there someone who can answer the questions I had with what i915 does?
17:04 dcbaker: karolherbst: I think the images for meson got fixed and if you rebase your bindgen patches we can merge them
17:08 karolherbst: dcbaker: okay cool, will look into it tomorrow or so then
18:04 airlied: mripard: the kernel edid blobs were meant to be a demo, the intent as sima said was for user to get the real EDID for their broken device and use that
18:05 airlied: like in the vga days not having edid was pretty common, but with hdmi/dp it should really be a warranty or cabling issue you fix
18:23 q66: what's the status of nvk in 24.0.0 in terms of being viable/useful for distribution packaging? i see it's still under experimental and not in the default set
18:23 q66: (specifically for a distro where proprietary drivers are impossible to do)
18:25 q66: I'm just wondering if it's something I should bother with since some people have been asking about it
18:25 q66: and it's not like an alternative choice exists
18:28 bl4ckb0ne: i plan on taking a look to packaging it for alpine
18:50 Company: I was wondering about that in terms of GTK 4 - if I need to check that it picks nvk over things like software rendering GL
18:53 zmike: has anyone else been having issues with latest deqp-runner and glcts?
19:00 zmike: I guess I'll file a ticket
19:10 zmike: and now I've downgraded and arrived at a massive memory leak somehow
19:10 zmike: tremendous