Leopold_ has quit [Remote host closed the connection]
yyds_ has joined #dri-devel
mclasen has quit []
Leopold_ has joined #dri-devel
mclasen has joined #dri-devel
fab has joined #dri-devel
yyds has quit [Ping timeout: 480 seconds]
fab has quit [Remote host closed the connection]
<eric_engestrom>
tjaalton: your welcome :)
fab has joined #dri-devel
ngcortes has quit [Read error: Connection reset by peer]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
<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
<eric_engestrom>
(and those are very short jobs so not taking much resources)
Leopold_ has quit [Remote host closed the connection]
mclasen has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
jsa has quit []
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
simondnnsn has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
lemonzest has quit [Quit: WeeChat 4.2.1]
lemonzest has joined #dri-devel
Leopold_ has joined #dri-devel
mclasen has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
mvlad has joined #dri-devel
jsa has joined #dri-devel
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #dri-devel
Leopold has quit [Remote host closed the connection]
alatiera has quit [Quit: Connection closed for inactivity]
lynxeye has joined #dri-devel
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
crabbedhaloablut has quit []
crabbedhaloablut has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
loki_val has joined #dri-devel
simondnnsn has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
hansg has joined #dri-devel
crabbedhaloablut has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
jfalempe has joined #dri-devel
flynnjiang has quit [Quit: flynnjiang]
pcercuei has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
Leopold has joined #dri-devel
Leopold has quit [Remote host closed the connection]
yyds has joined #dri-devel
yyds_ has quit [Read error: Connection reset by peer]
apinheiro has joined #dri-devel
jsa has quit []
simondnnsn has joined #dri-devel
Leopold has joined #dri-devel
Leopold has quit [Remote host closed the connection]
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
Leopold_ has quit [Remote host closed the connection]
krei-se has joined #dri-devel
Leopold_ has joined #dri-devel
kts has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
simondnnsn has joined #dri-devel
jsa has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
kts_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
kts has joined #dri-devel
Haaninjo has joined #dri-devel
simondnnsn has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
kts_ has quit [Ping timeout: 480 seconds]
alatiera has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.2.1]
Daanct12 has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.2.1]
kts has quit [Quit: Leaving]
jsa has quit [Read error: Connection reset by peer]
chaos_princess has quit [Quit: chaos_princess]
chaos_princess has joined #dri-devel
kts has joined #dri-devel
vliaskov has joined #dri-devel
ity has quit [Remote host closed the connection]
ity has joined #dri-devel
sgm has quit [Quit: sgm]
sgm has joined #dri-devel
mripard__ has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
crabbedhaloablut has joined #dri-devel
mripard_ has quit [Ping timeout: 480 seconds]
loki_val has quit [Ping timeout: 480 seconds]
Leopold has joined #dri-devel
rgallaispou has quit [Read error: Connection reset by peer]
Leopold has quit [Remote host closed the connection]
rgallaispou has joined #dri-devel
Leopold_ has joined #dri-devel
yyds_ has joined #dri-devel
yyds has quit [Read error: Connection reset by peer]
mripard__ has quit [Remote host closed the connection]
mripard_ has joined #dri-devel
mripard_ has quit []
Leopold_ has quit [Remote host closed the connection]
itoral has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
apinheiro has quit [Quit: Leaving]
mripard_ has joined #dri-devel
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
mripard is now known as Guest1216
mripard_ is now known as mripard
glennk has joined #dri-devel
<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?
<pq>
mripard, anything between not at all and image unreadable.
<mripard>
cool
<mripard>
so, uh, we're doing that in the EDID loader
<pq>
IOW, we would need to look at the EDID fields individually to determine their impact.
<mripard>
we have a few EDID in the kernel that can get used for any connector
<mripard>
and they are all analog EDIDs, without any kind of extension
<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.
<pq>
you wouldn't happen to have edid-decode reports of those edids?
cheako has joined #dri-devel
<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
<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.
<pq>
that may change one day, though
<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.
<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?
jsa has joined #dri-devel
<pq>
yeah
<pq>
I guess these pre-baked EDIDs exist for monitors that have none?
<pq>
would be nice if they were generated to be as true to what is certainly known already as possible, like connection type
<pq>
or, just have no EDID and configure kernel mode lists etc. in some other way
<pq>
that might actually be the best course of action, for all I know
kts has joined #dri-devel
<mripard>
yeah
<pq>
you could see what happens if you simply stop these pre-baked EDIDs from ever reaching userspace
<mripard>
one thing that isn't working at the moment due to this is audio
<mripard>
since the display isn't considered an HDMI monitor, audio is disabled
<mripard>
even though the monitor might be capable of it
<pq>
hah
<mripard>
having somewhat reasonable EDIDs for each connector type would solve this too
<pq>
smells like awful many new kernel command line options coming, if most things need to be configurable :-D
<pq>
How about letting people craft an EDID file of their liking with some simple tool, and load that instead of anything pre-baked?
<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
<pinchartl>
I'm also inclined to prefer not reporting EDID at all in those cases
<jani>
sima: thoughts on shifting dim to operate more on the currently checked out branch without having to specify it?
<pinchartl>
instead of lying
<pq>
swick[m] has been thinking of EDID crafting tools in the libdisplay-info project.
<jani>
sima: dim apply-branch vs. dim apply
<jani>
sima: iirc it was mainly a safeguard against applying patches to the wrong branch by accident
<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).
<pq>
the latter being "I know my display can do 1600x1200 so I want the kernel to expose that mode"
<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
<mripard>
without introducing anything user-facing
<swick[m]>
blergh, stupid matrix
<pq>
mripard, I wonder, number of modes × connector types × audio yees/no × ...
<swick[m]>
mripard: I had the urge to rewrite libdisplay-info in rust multiple times
<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
<jani>
mripard: so why would those edids from drm_edid_load.c be used? you have to explicitly choose them
<mripard>
and the kernel coming up with its own which probably shouldn't
<mripard>
swick[m]: it was for something entirely different that I did that, but if it can help / be reused, it's there :)
<jani>
also, if the user chooses a broken edid for the display, imo they get to keep both pieces
<pq>
mripard, surely the kernel nows if the command line referred to an actual file or just something built-in?
<mripard>
jani: afaik, it's used as a fallback to ignore the EDID the monitor reports when they are broken / failing
<mripard>
and part of the issue is that it's never told anywhere that they are broken
<pq>
I'd never forward built-in EDID to userspace.
<jani>
mripard: fallback how? I think they're only used if explicitly specified, no?
<mripard>
yeah, I meant a user fallback :)
<sima>
jani, if the current commands with explicit branch names stay, then I think no objections from me
<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
<sima>
jani, if you want to remove them too, maybe mild grumbling
<swick[m]>
are you going to spend more time on it?
<jani>
mripard: I have to wonder if anyone really uses those builtin EDIDs anymore
<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
<sima>
jani, yeah I don't think they're ever meant for production use really
gouchi has joined #dri-devel
<any1>
The biggest problem with forcing a crafted edid from user space is that then you don't get notified when the EDID changes
<jani>
sima: rip them out and see if anyone notices ;)
<sima>
any1, I thought we've fixed those issues of missing hotplug uevent generation?
<jani>
any1: please elaborate
<sima>
otherwise could add the missing call, wouldn't be the first missing uevent we have by a long shot :-/
<pq>
userspace can upload EDID after boot-up?
<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
<any1>
pq: yeah, it's somewhere in /sys/kernel/debub
<any1>
err, debug
<pq>
oh, /sys/kernel/debug does not exist in production
<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
<any1>
yeah, the problem was that I couldn't get the EDID from the display after forcing it, so I switched tactics
<jani>
that's kind of the point ;)
<jani>
I guess what you're after is a per-display instead of per-connector way of forcing an EDID
<jani>
but to identify the display, you'd have to read, uh, the edid
<any1>
I'm just saying that crafting edids from userspace isn't an ideal solution to bad edids, as is
<any1>
Unless you ignore the kernel completely
<jani>
I'm not sure the solution to bad edids lies in the kernel either
<pq>
The ideal solution is to have the display provide a good EDID. :-)
<jani>
ah yes, the unicorn pony solution ;)
<pq>
well, *ideal*
<any1>
Yeah, let me just call up LG and Samsung...
<pq>
meaning there is no ideal solution at all
<jani>
we have some edid quirks, and we also filter out *some* edid extensions with broken checksums in the kernel
<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?
<pq>
jani, do those fix-ups end up in the EDID given to userspace, too?
<any1>
pq: Yeah, that would be good
<jani>
pq: yes
<jani>
pq: no
<jani>
:)
<pq>
I see you talk like an EDID.
<jani>
:D
<any1>
lol
<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
gouchi has quit [Remote host closed the connection]
<pq>
alright
<jani>
I think the argument has been made that we should not filter out extensions, even if they have broken checksums
<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...
<sima>
any1, jani might know, since it was a huge junk of work to redo how it all works
<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
<sima>
and so you /should/ get all the usual events
<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
<sima>
originally it was a separate path, if I recall correctly
<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 :)
<mripard>
but yeah, for the foreseeable future I intend to work on it
<any1>
sima: yeah, but I might have been dealing with this issue in something unrelated to forcing edid
<mripard>
and being able to parse EDIDs is fair indeed
<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
<mripard>
jani, sima: the RPi folks seem to use it regularly at least
<sima>
mripard, the built in edids, or the override stuff in general?
<swick[m]>
jani: I would appreciate if the kernel didn't mess at all with the EDID blob that's given to user space
<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
<jani>
swick[m]: agreed. maybe we could try a patch that stops doing that and see if anything falls apart
<mripard>
sima: both, really
<swick[m]>
btw, the kernel is still not looking for DisplayID, is it?
<mripard>
I think it is but it got introduced recently
<swick[m]>
the non-embedded blobs
<jani>
swick[m]: we're not
<jani>
I had some test patches for that, sent it to intel CI, and the resultes were not encouraging
<swick[m]>
has anyone seen a non-embedded DisplayID blob?
<jani>
swick[m]: some displays in intel CI responded in the Display ID ddc address... and had either garbage or a plain EDID there
<swick[m]>
oh boy
<jani>
swick[m]: iirc no display had an actual Display ID in there :/
karolherbst_ has joined #dri-devel
<jani>
par for the course
karolherbst has quit [Ping timeout: 480 seconds]
karolherbst_ is now known as karolherbst
karolherbst has quit [Quit: Konversation terminated!]
karolherbst has joined #dri-devel
fab has quit [Quit: fab]
airlied has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
yyds_ has quit [Ping timeout: 480 seconds]
karolherbst has quit [Quit: Konversation terminated!]
karolherbst has joined #dri-devel
karolherbst has quit []
<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.
karolherbst has joined #dri-devel
<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...
<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
<pq>
any time the kernel changes the way it changed the blob, I presume?
<jani>
zamundaaa[m]: my gut feeling is that the broken checksums isn't all that common
heat has joined #dri-devel
<jani>
because we already accept broken checksums for cea extension, and that's the most common extension anyway
karolherbst_ has joined #dri-devel
<mripard>
pq: I plead guilty
<mripard>
(but also, I couldn't find a library to *generate* them back when I started)
<jani>
mripard: I presume you've checked how the current builtin edids were generated. ugh.
<mripard>
I mean, generating EDIDs with assembly and makefiles look perfectly reasonable to me
<jani>
o_O
<mripard>
(I was being sarcastic)
<jani>
*phew*
<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
karolherbst has quit [Ping timeout: 480 seconds]
<jani>
of course, it would be yet another edid parser :)
karolherbst_ is now known as karolherbst
<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
<pq>
jani, swick[m] was planning something like that in libdisplay-info.
<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 :)
<mripard>
also, I have no way to tell what was the original intent of the i915 devs
<swick[m]>
all I want is a bit more documentation on the expected behavior, which I guess is whatever i915 does right
<swick[m]>
isn't there someone who can answer the questions I had with what i915 does?
<dcbaker>
karolherbst: I think the images for meson got fixed and if you rebase your bindgen patches we can merge them
simondnnsn has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
djbw has quit [Read error: Connection reset by peer]
<karolherbst>
dcbaker: okay cool, will look into it tomorrow or so then
ADS_Sr has quit [Remote host closed the connection]
mbrost has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
vliaskov has joined #dri-devel
simondnnsn has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
yyds has joined #dri-devel
yyds_ has quit [Ping timeout: 480 seconds]
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
frieder has quit [Remote host closed the connection]
simondnnsn has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
Calandracas_ has quit [Remote host closed the connection]
Calandracas_ has joined #dri-devel
yyds has quit [Remote host closed the connection]
heat has quit [Read error: No route to host]
yyds has joined #dri-devel
heat has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
yyds has quit [Ping timeout: 480 seconds]
<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
hansg has quit [Quit: Leaving]
<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
mclasen has quit [Ping timeout: 480 seconds]
yyds has joined #dri-devel
simondnnsn has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
enick_936 is now known as pmoreau
<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
<q66>
(specifically for a distro where proprietary drivers are impossible to do)
<q66>
I'm just wondering if it's something I should bother with since some people have been asking about it
<q66>
and it's not like an alternative choice exists
<bl4ckb0ne>
i plan on taking a look to packaging it for alpine
simondnnsn has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
<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
Leopold_ has joined #dri-devel
<zmike>
has anyone else been having issues with latest deqp-runner and glcts?
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
<zmike>
I guess I'll file a ticket
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
<zmike>
and now I've downgraded and arrived at a massive memory leak somehow
<zmike>
tremendous
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
Kayden has quit [Quit: -> JF]
kzd has quit [Quit: kzd]
simon-perretta-img has quit [Read error: Connection reset by peer]
simon-perretta-img has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
gouchi has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
Leopold has joined #dri-devel
Leopold has quit [Remote host closed the connection]
jsa has quit []
mbrost has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #dri-devel
junaid has joined #dri-devel
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
ngcortes has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
kzd has joined #dri-devel
junaid has quit [Remote host closed the connection]
fab has quit [Quit: fab]
sima has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
ngcortes has joined #dri-devel
Leopold_ has joined #dri-devel
konstantin_ has joined #dri-devel
konstantin has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
jsa has joined #dri-devel
gouchi has quit [Remote host closed the connection]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
mvlad has quit [Remote host closed the connection]
yyds_ has joined #dri-devel
yyds has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
vliaskov has quit [Remote host closed the connection]
ngcortes has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
mclasen has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]