03:08 mareko: DemiMarie: I don't see the question
03:50 DemiMarie: mareko: which message are you replying to?
04:06 mareko: 19:55 < DemiMarie> marmarek: do you agree with that assessment?
04:17 DemiMarie: mareko: I’m trying to figure out if Qubes OS needs to make a copy of untrusted dmabufs before passing them to the compositor.
04:17 DemiMarie: In Qubes OS, security is a constraint, but performance should be as good as possible within that constraint.
04:18 DemiMarie: It appears that AMD does not properly validate a buffer parameter (probably alignment), causing glitches.
04:18 DemiMarie: Do those glitches indicate that undefined behavior (such as GPU memory corruption) could happen?
04:43 mareko: DemiMarie: do you mean 1 app corrupting another app?
04:44 DemiMarie: mareko: If an app can cause another app to misrender (as opposed to fail-stop crashing, such as by resetting the GPU) that’s a security hole.
04:44 mareko: DemiMarie: it's impossible, the hw implements virtual memory
04:45 DemiMarie: mareko: the attack I am thinking about is that a client passes malicious linux-dmabuf params to the compositor over Wayland that trick the client into reading or writing out of bounds
04:45 DemiMarie: trick the compositor, obviously
04:47 mareko: DemiMarie: that's something that is mitigated by radeonsi by rejecting an unsupported pitch
04:47 mareko: if such a corruption could occur, it would be a SW bug
04:48 DemiMarie: mareko: What about the bug that zamundaaa pointed out earlier?
04:49 mareko: DemiMarie: that's a bug in our modifier implementation in Mesa
04:51 DemiMarie: mareko: For context, in Qubes OS the assumption is that software will have bugs. The question is whether the Mesa validation code is trustworthy enough to include in the trusted computing base of code that must be correct in face of malicious input (as opposed to merely not-malicious on not-malicious input).
04:51 mareko: it's not corruption, it's just a different order of tiles
04:52 mareko: you can never assume that there are never any bugs
04:52 mareko: even kernel code will have bugs
04:59 DemiMarie: mareko: Of course code will have bugs, unless it is trivial or has a formal proof of correctness (and maybe even then there might still be bugs).
05:00 mareko: there are no formal proofs for anything anywhere
05:04 DemiMarie: What I would not be okay with is introducing a feature with a known, unfixed security hole.
05:05 mareko: I'm not aware of any
07:00 tomba: Can 96b5d2e807f667320c66f41ddc1c473023a73ab2 from drm-misc-next be picked to a -fixes branch? It fixes 3ec5c1579305, which is in drm-misc-next and in drm-next.
09:56 MrCooper: sima: any take on the discussion in https://gitlab.gnome.org/GNOME/mutter/-/issues/3833#note_2298594 ?
10:10 sima: MrCooper, uh ...
10:11 sima: MrCooper, so for asymmetric crtc situation it's on userspace, especially when userspace ignores stuff like possible_crtc or asymmetric properties/features
10:11 sima: and there's definitely been compositors that failed at that
10:12 sima: but for the dual-crtc case we've chatted about this endless when iirc msm and rcar-du tried to enable dual-dsi, and reached the conclusion that you pretty much have to virtualize or it's an impossible uapi
10:12 sima: ofc if you combine those two and have dual-crtc but also asymmetric crtc on the same platform, then there's going to be situation where virtualization won't get you out
10:12 sima: but imo that's a case of "design less shit hw"
10:13 sima: for intel-display I thought the full virtualization at least among equal crtc was on the requirements, but I guess that didn't make it
10:14 MrCooper: right, my concern is only about dual CRTC; is there asymmetry involved as well in the specific scenario in that issue?
10:14 sima: either way, it's not documented, so I think step 1 here is an upstream kms uapi doc patches that clarifies what exactly the contract between kms driver and compositor is for the case of dual-crtc usage
10:14 sima: MrCooper, not sure, I thought aside from crtc A for edp power improvements intel hasn't has asymmetric crtc since a lot of platforms, the last being the gen7/8 atoms
10:14 sima: jani, ^^ ?
10:15 sima: but maybe some of that came back
10:16 MrCooper: anyway, even with asymmetry, there have to be two symmetrical CRTCs to make dual CRTC work, so virtualization can work for that?
10:17 sima: yeah, but if those happen to be like in the example, then trying to use C for another output won't work
10:17 sima: because if we remap userspace C to real D with less features, it could break in funny ways again
10:18 sima: also i915 does remap on old crap, but statically
10:19 MrCooper: that seems fine; if the kernel can't make it work via virtualization, user space couldn't make it work with any uAPI permutation either?
10:19 sima: because pipe B is the better one for the integrated panel, so that's the first crtc and things mostly work because userspace tends to light up the internal panel as first priority
10:19 sima: MrCooper, yeah, in the end there's just random hw limitations that make things fail, so I guess that's fine
10:20 emersion: reminds me of a patch from ville to document CRTC priorities
10:20 sima: I'm thinking more of the case where there's a hardwired limitation of which connector can use which crtc
10:20 emersion: https://lore.kernel.org/dri-devel/20240612141903.17219-2-ville.syrjala@linux.intel.com/
10:20 sima: but userspace should already be able to figure that out with possible_crtc
10:20 emersion: vsyrjala: any plans to update that patch?
10:21 sima: yeah that'd be good to document too, it's been pretty much the assumption
10:22 jani: that commit message captures some of the problems with virtualization. what do you expose to userspace in CRTCs if the pipes have pipe specific limitations, and the CRTC <-> pipe assignment varies?
10:23 jani: the CRTC virtualization is a huge amount of work, and still doesn't solve the problems, so we're quite hesitant to plunge ahead with it
10:23 emersion: is it that much work?
10:23 MrCooper: it solves the problem that issue is about
10:23 jani: well, maybe
10:24 emersion: hm, i suppose a lot of the driver access the drm_crtc base
10:24 jani: emersion: entire history of i915 has been based on the assumption that CRTCs and pipes have fixed 1:1 mapping
10:25 MrCooper: that contradicts what sima wrote about pipe B above
10:26 jani: we've minimized the assumptions that crtc index == pipe, but going dynamic is different
10:28 MrCooper: if user space has to repeat every failed test commit which tries to enable any new CRTC with all possible permutations of CRTCs, that'll suck
10:29 jani: I don't disagree
10:31 sima: the trouble with trying other crtc is that in full generality you also need to try other planes
10:31 sima: so things explode really quickly
10:32 sima: and strictly speaking, you might also need to reassign other connectors to different crtc
10:33 sima: hence why with other drivers we concluded that assigning in order + virtualization is the best we can do really
10:33 sima: that's also why we move the panel to the first position, if there is one
10:34 sima: it's still not going to cover everything, but eventually it's down to stupid hw
10:34 jani: but even in a virtualized setting, there's no api for kernel to tell userspace what crtc features are actually possible, and there's no api for userspace to convey what it needs, and the kernel has not enough info to make reasonable crtc <-> pipe assignments
10:35 jani: and in the virtualized setting, you don't even know *why* something failed
10:35 jani: I mean, there's not a whole lot of info now, but at least it's more predictable I think
10:36 sima: that problem already exists
10:36 sima: you might not be able to use all planes because you've run out of fifo space
10:36 sima: or you can't use scaler on all of them because they're used up
10:36 MrCooper: that's all fine, it can only matter if user space tries to enable an additional CRTC, which can already fail for other reasons, so user space has to be prepared to back down
10:37 sima: so the case of "this crtc actually does less than advertised" is already happening
10:38 emersion: agreed
10:38 jani: the bug at hand is a special case of it :p
10:38 jani: "this crtc can do nothing at all, but try the next one"
10:38 MrCooper: that's not a thing in KMS API that I know of
10:39 sima: yeah but does the next one actually have a reduced feature set compared to what the previous one advertised?
10:39 sima: yeah I think every time we've had this discussion it boiled down to "if the driver has to steal resources, it needs to remap"
10:40 sima: same with planes, if you need 2 to scan out planar formats
10:40 sima: then "oops the next one is now defunct" isn't great
10:40 jani: say, you have four virtualized CRTCs, but enabling one of them might render one, two, or four of them unusable, because it might need 1-4 pipes. how's that better?
10:40 sima: except the fallback is a bit nicer
10:41 sima: jani, userspace doesn't need to go through the combinatorial search to find if there's still one that does work
10:41 sima: we essentially assume that lower crtc/plane are better
10:41 jani: fair
10:41 sima: so if you dynamically put one in that doesn't work at all, userspace makes the reasonable conclusion that trying further will only be worse
10:41 sima: same applies to planes
10:42 sima: essentially it would be a contraction to vsyrjala 's doc patch of "lower crtc are better"
10:43 sima: if you drop that, it becomes a full combinatorial search of all connector->crtc assignments
10:43 MrCooper: might a simple intermediate solution be to prefer the last API CRTCs for stealing?
10:43 jani: so what you're saying is that all virtual CRTCs should advertize all the features of all the pipes, even if there isn't a single pipe that can handle all of them?
10:43 MrCooper: in the driver
10:43 sima: jani, well if they're not symmetric it gets more messy
10:44 jani: we've been in the more messy land for a long time now
10:44 sima: I'd say it depends upon the exact asymmetry you have
10:44 sima: if the higher crtc numbers have strictly less features, I'd still leave that
10:45 jani: "leave that"?
10:45 emersion: leave the features advertised
10:45 sima: since if you go with "lower crtc first" there's never a case where you end up with a crtc with more features than advertised
10:45 sima: jani, leave those stricter limits in place instead of making every crtc advertise the maximum feature set
10:46 emersion: er, *unadvertised then
10:46 jani: :)
10:46 jani: sounds like a bit of a mess to me
10:46 emersion: sima, that sounds a bit fragile to me
10:46 sima: like if D/E only have 2 planes and the other crtc much more, don't advertise more planes on D/E
10:46 sima: because if userspace uses lower crtc first, it'll never get a better crtc assigned to D/E
10:47 emersion: what if after some state changes the first CRTC gets assigned to a pipe with less features
10:47 sima: otoh might make the driver implementation more tricky
10:47 sima: emersion, yeah that can always happen
10:47 sima: for pretty much any reason
10:48 sima: atomic has the "sorry I ran out of magic" escape hatch
10:48 emersion: what if we had a way for drivers to return a connector-CRTC assignment?
10:49 sima: not sure that helps, since then the driver is in the business of guessing what the compositor really wants
10:49 sima: plus you'd need to teach all compositors about this, so there's still pressure to just virtualize in drivers
10:49 sima: which is where we are at
10:50 emersion: what do you mean by guessing?
10:50 sima: maybe robclark and pinchartl could confirm whether or whether not there's virtualization in their drivers
10:50 sima: emersion, like how many planes you want to use where
10:50 emersion: userspace can prefer a CRTC because it will in the future use a feature available only there?
10:50 jani: vsyrjala: the whole discussion above ^
10:51 sima: emersion, yeah, or just because it wants the most feature on the panel for power efficiency reasons
10:51 sima: or on the tv for gaming
10:51 emersion: i was thinking userspace would send the full atomic state, but with placeholders instead of CRTCs
10:52 sima: like for me the big difference is between "sorry I ran out of magic", which is ok, and "sorry I misplaced the magic in a crtc/plane further down, go chase it, have some luck" which imo isn't good uapi
10:52 emersion: but in the end, that's more or less equivalent to virtualization
10:52 emersion: i think virtualization + better feedback for errors would be a good solution
10:52 emersion: (even if it's Hard)
10:52 sima: emersion, yeah except it's new uapi, so much harder to roll out
10:53 emersion: hm, i'm not afraid at new uAPI, i would prefer that in fact
10:54 sima: it's not so much what I prefer, but the sticking power of existing uapi
10:55 MrCooper: jani: in the scenario in the mutter issue, if i915 stole pipe D (the last one available) instead of C for big joiner, would that allow the third display to work with pipe C?
10:55 sima: new uapi for these has a chicken-egg problem, compositors won't adopt it without drivers, drivers will be pushed towards the virtualization hack without compositors
10:56 sima: and afaik we're already firmly in the "fix this with virtualization" except it's not documented
10:56 emersion: if it fixes bugs, there is intensive to adopt the new uAPI
10:56 emersion: for compositors
10:56 jani: MrCooper: there are platform specific restrictions on which pipes may be joined at all
10:56 sima: how many people have 3 displays, one of which is a dual-pipe dp?
10:56 MrCooper: not clear what the new uAPI would really buy anyway, seems like just an additional step for no clear gain
10:57 sima: emersion, so I expect the pressure to be fairly low on each individual compositor, and higher on the kernel driver to just make this work
10:57 jani: MrCooper: as a rule of thumb, it's consecutive pipes that can be joined, but could be e.g. A+B and C+D but not B+C. and depends on the platform
10:57 jani: MrCooper: it's a mess :(
10:57 MrCooper: I see
10:58 jani: I think there are cases where A is pretty much designed for eDP, and then B+C can be joined. I don't even remember all of this, would have to peruse the specs
10:59 sima: jani, yeah so for that you need full combinatorial search, since if you have A, B (needs bigjoiner) and D but can't use B+C then userspace also needs to shuffle the assignment for the first connector
10:59 emersion: fun stuff
10:59 jani: "the rest is just software"
10:59 sima: and I don't think we can "do full combinatorial search" onto compositors
10:59 sima: jani, :-/
11:00 MrCooper: compositors might need to put up "grab a coffee" dialogues when changing display settings ;)
11:00 sima: jani, also kinda wondering how badly fbcon fares on this ...
11:01 jani: idk
11:05 jani: I guess we'll have to take another hard look at virtualized crtcs, check our past notes, and see if we missed something in this discussion. but even if we decided to go for it, it would still take a looong time to get there. even if we all had copious free time to work on it
11:08 jani: and I think there are still non-obvious gotchas in how to advertize the crtc properties to userspace, how to assign the crtcs to physical pipes, and if and how to migrate crtcs to new pipes (and how often that causes unnecessary full modesets), etc etc
11:08 jani: if the pipes were uniform, this would be much less of a problem, but they're just not
11:11 MrCooper: doesn't enabling an additional CRTC always require a modeset?
11:12 sima: MrCooper, it might require a modeset on existing ones, and if userspace doesn't include them in the request, you're not really allowed to mess with them
11:12 MrCooper: I see
11:12 sima: so userspace would definitely need a fallback where it throws the entire config at the kernel with an ALLOW_MODESET
11:13 sima: but I think that's already required for other reasons like reassigning clocks, but not sure
11:14 sima: I think fifo reassignment stuff we can do without a modeset on intel, but I think other drivers aren't that good
11:14 zamundaaa[m]: <sima> "and I don't think we can "do..." <- KWin already does a full connector<->crtc search
11:15 zamundaaa[m]: IIRC it was necessary for a setup with some old Intel GPU
11:15 sima: zamundaaa[m], did you not obey possible_crtc?
11:16 sima: unless your "old" is not like 15 years old
11:16 zamundaaa[m]: It was a long time ago, but I'm pretty sure we did
11:16 sima: zamundaaa[m], also is this is a full search with atomic test_only ioctl?
11:16 zamundaaa[m]: yes
11:17 sima: the possible_crtc you can check in userspace, and I think that was all that was needed on old intel gpu
11:17 zamundaaa[m]: Heh, not so old: Intel® Core™ i7-8700K CPU
11:18 MrCooper: zamundaaa[m]: you do that full search every time you try to enable anything new, and it fails?
11:18 zamundaaa[m]: We do that search on every modeset, unconditionally
11:18 MrCooper: just once?
11:20 emersion: zamundaaa[m]: do you perform test commits at each step of the search?
11:20 emersion: or just one test commit at the end of the search?
11:20 emersion: wlroots does the latter
11:20 zamundaaa[m]: We do a test commit with every crtc combination that might work
11:20 zamundaaa[m]: And exit the search at the first one that does
11:21 MrCooper: zamundaaa[m]: per above, might also need to try different connector / plane / ... mappings in some cases
11:22 sima: also pixel formats, since some are really hard to scan out
11:22 sima: if you do full modifiers
11:22 zamundaaa[m]: The code originally did that, but I optimized it out as the combinatorial explosion was a bit too much... guess that was premature :D
11:22 MrCooper: I'd really rather not even start down that road in mutter
11:23 sima: yeah like for an individual issue doing full combinatorial is doable. but if we have that as the solution for every kms config issue, it's unworkable
11:23 zamundaaa[m]: sima: we do fall back to implicit modifiers if everything else fails
11:23 sima: zamundaaa[m], yeah that's progressively getting worse as a fallback on newer platforms
11:24 sima: since you might end up with linear
11:24 zamundaaa[m]: With all of those problems, having actual feedback on why the test commit failed would help a ton
11:24 zamundaaa[m]: sima: could we get some helper function or whatever that tells us what the modifier is that needs the least bandwidth?
11:24 sima: I think just documenting the expected fallback order would be a big improvement
11:25 sima: zamundaaa[m], for extra lolz you need a different set when rotated
11:25 zamundaaa[m]: KWin doesn't do rotations with modesets, only for direct scanout
11:26 emersion: yeah, trying all modifiers is a bit much
11:27 emersion: esp since you need to allocate each time you try
11:27 sima: emersion, well if we say a linear scan on the crtc is enough, and then also walk through the modifiers, it's not that bad
11:27 sima: but if you need to do both, it goes up real fast
11:28 sima: especially if we do this with everything else too
11:29 emersion: also wlroots retries the CRTC/modifier/etc allocation for all enabled CRTCs on each modeset
11:29 emersion: (because Intel)
11:29 jani: re actual feedback on why the test commit failed. there are so many reasons that I'm not sure you can make clever adjustments to make progress
11:30 emersion: (to fix the issue where you might need to downgrade the modifier of an already-enabled CRTC to light up a new one)
11:30 zamundaaa[m]: jani: we don't need to fix every single special case
11:30 jani: and then all userspace will make different adjustments, and behave differently
11:30 zamundaaa[m]: It already does behave differently. Most just fails hard
11:31 emersion: jani, anything that can reduce the search matrix would be welcome
11:31 emersion: we can leave "unknown" as a default when there's no solid answer
11:31 sima: I think we should start to document all these assumptions and especially the specific fallbacks
11:31 sima: in upstream
11:31 jani: agreed
11:31 sima: and then discuss on each case whether it's part of the kms uapi (meaning compositors need to do it) or buggy driver hacks
11:32 jani: agreed
11:32 sima: starting with the very simply of "enabling a crtc needs a fallback for the full configuration involving all crtc/connector with allow_modeset"
11:33 sima: some will be feature specific and you can ignore (like for rotation)
11:33 sima: and I'm sure we'll discover a bunch that are just flat out contradictory
11:34 sima: probably need an entire new "atomic test fallback rules" chapter
11:35 jani: preferrably with explicit mentions what both sides of the api need to do
11:37 emersion: that sounds like a good start
11:39 lumag: mripard, r-b for https://lore.kernel.org/dri-devel/20250107-drm-bridge-fix-docs-v1-1-84e539e6f348@linaro.org/ ? It fixes the documentation warning in -next, so it should go into drm-misc-next-fixes
11:39 sima: emersion, maybe even separate rst file so that we can add a MAINTAINERS entry for cc'ing compositor people?
11:39 emersion: interesting idea
11:39 sima: or at least a separate kms-uapi file for all that stuff
11:40 sima: anyway lunchtime, gtg find some food, bbl
11:40 emersion: i wonder if it makes sense to add uapi headers to that MAINTAINERS entry as well
11:41 emersion: OTOH, it sounds a bit weird to have maintainers who aren't kernel devs
11:41 emersion: ah, just for CC would be fine I suppose, would be probably wayland-devel as additional ML
11:42 emersion: ideally the prop docs would be part of this as well
12:58 pq: 12213 unread emails from dri-devel... maybe I should just stop email delivery :-P
13:03 Ermine: pq: yeah, dri-devel is super busy
13:07 sima: emersion, yeah just as a reviewer or something like that, not maintainer
13:08 Ermine: if mailman had an option for weekly digests or so...
13:12 jani: maybe user lore to pull it in at your leisure?
13:15 pq: my problem isn't the volume but finding the interesting bits I might want to see
13:15 jani: true
13:15 jani: I mean yes, that's a problem
13:17 pq: the more unreads there are, the less likely I am to start shifting through them
13:27 emersion: pq, i've given up on dri-devel a while ago
13:29 pq: emersion, how do you keep an eye nowadays? Or depend on personal cc's?
13:29 emersion: yeah, i don't :/
13:50 jani: I archive most threads based on the subject of the root message of the thread, unless I'm Cc'd
13:55 javierm: jani: I used to do that but evein going through the root thread msg and mark it as archived takes too long so now I automatically archive it but mark it as "unread" in case I've time to go through them
13:55 javierm: unless I'm in to: or cc:, in those cases I keep it in my inbox
13:56 jani: javierm: yeah, I also very much like the distinction between "inbox" vs. "unread"
13:57 javierm: jani: is no surprises since you are my email management coach :)
13:57 jani: because I archive a lot of stuff without reading, and it's nice to know afterwards whether I've even read it
13:57 jani: javierm: :D
14:00 sima: I get cc'ed on everything, cc stopped being a useful signal
14:01 MrCooper: dri-devel is the new lkml
14:01 javierm: sima: I can see how for you could be too much noise indeed
14:01 javierm: but for us that are no maintainers, is a good indicator
14:05 emersion: i know lore can have per-file rules, but never got around to try it
14:05 javierm: maybe we could use one of those hallucinations as a service :D e.g: https://www.perplexity.ai/search/what-are-the-most-relevant-top-a2KpD504QNOTJFNRoVwFYQ
14:08 tzimmermann: pq, i have 49728 emails from dri-devel. they've been piling up since march 24. :(
14:08 tzimmermann: unread °
14:08 tzimmermann: unread ^
14:09 tzimmermann: i guess i could auto-mark everything as read that does not explicitly cc me
14:10 tzimmermann: javierm, does this auto-read work for you?
14:12 mripard: lumag: ack
14:13 lumag: mripard, r-b on ML when you have time?
14:14 mripard: lumag: not sure I'll have the time today, just add my acked-by when applying the patch
14:14 javierm: tzimmermann: these past few months I was too busy with internal stuff and had like 8k+ unread emails, so I had to declare dri-devel email bankruptcy
14:15 tzimmermann: :D
14:15 javierm: tzimmermann: I've been doing the auto archive since before leaving on PTO due Christmas, let's see how it goes...
14:16 tzimmermann: i guess i'll set up some email filters and test it out
14:16 javierm: tzimmermann: in particular, is hard when you start accumulating unread emails because by the time you read some for example v3, there's already a v5 been discussed
14:17 tzimmermann: that never happens to me. i'll miss v3 and when i see the series I go 'oh it's at v5 already?'
14:18 javierm: tzimmermann: yeah but if you try to catch chronologically, how do you know ?
14:18 javierm: *catch up
14:19 tzimmermann: i scroll from newest to older mails. if it's too old, i won't see it
14:20 javierm: tzimmermann: ah, you catch up in inverse chronologically order then
14:20 tzimmermann: still i manage to see most of what comes in during the day.
14:20 javierm: it's funny when I see people complaining in the mailing list that "DRM moves too fast" and yet, most folks have a hard time to keep up with the posted patches
14:21 tzimmermann: it's just that i don't have the time to really go through the series and review. so they remain unread and pile up
14:22 javierm: imagine if devs could keep up with the mailing list and review patches in time, the rate of pushed patches could probably double or triple :)
14:23 lumag: mripard, ack
14:24 daniels: imagine if we had some way of submitting patches where you could follow the conversation for a patch series in linear order without having to wonder whilst reading v3 if a v5 had been sent and discussed in a thread you haven't even seen yet
14:24 mripard: daniels: witchcraft!
14:25 javierm: daniels :)
14:41 tzimmermann: javierm, i've set up a filter that auto-reads all dri-devel mails that are not explicitly addressed to me. i'm down to 31k unread from 49k. a mixed result, i'd say
14:43 robclark: sima, emersion: yeah, the resources backing planes/crtcs are dynamically assigned.. in some cases you need to gang up mixers (crtc) / sspp (plane).. in some cases a single sspp can serve multiple planes, etc, etc.. the hw is all too.. flexible
14:44 javierm: tzimmermann: yeah, same comment that I had for sima. I guess that for maintainers is not a good a signal if someone address to you
14:47 tzimmermann: javierm, and 21k of those unread mails are older than 3 months
14:47 sima: mlankhorst, I guess we need some dmem kerneldoc fixups?
14:49 mripard: sima: https://lore.kernel.org/all/20250113092608.1349287-1-mripard@kernel.org/
14:50 sima: mripard, I think that's another one
14:51 sima: sfr send some mails about kerneldoc warnings
14:51 mripard: no, it's part of that series (patches 3 and 4, I think?)
14:51 tzimmermann: javierm, since we're talking about it, there's a ssd130x series for you
14:51 sima: mripard, oops, didn't look at the entire thread
14:51 javierm: tzimmermann: I know, it's in my TODO since yesterday. But thanks for pointing that out
14:52 javierm: that's for example was addressed to me and so remaining in my inbox. Is a good example why for non-maintainers the to: / cc: fields are useful
15:00 mlankhorst: Hmm, need to look
15:02 mlankhorst: mripard: those patches look sane
15:04 sima: mlankhorst, mripard slapped some r-b on them
15:05 sima: I overlooked them because I accidentally marked everything as read today
15:05 sima: oops
15:21 mripard: sima: I replied to your mail, but how should we merge them?
15:21 mripard: it's only in drm-next for now
15:21 sima: uh
15:22 sima: mripard, drm-misc-next-fixes doesn't have a new enough drm-next?
15:22 sima: since we're at -rc7 already
15:22 sima: plus that would be the right branch anyway
15:23 pq: If a connector does not have "PATH" property, does it mean it is a fixed connector? One that is always at the same index in the UAPI array of connectors.
15:23 pq: 'cause I just kinda suggested people to assume that :-P
15:24 mripard: sima: drm-misc-next-fixes is at the latest drm-misc-next tag we sent at the moment, but I guess that means I can backmerge drm-next :)
15:25 sima: pq, I guess if you're unlucky we could start processing dp mst hotplug stuff while still adding fixed connectors
15:26 sima: which would shift the enumeration around
15:26 sima: but I think within a connector type it's safe to assume the ordering stays the same
15:26 sima: pq, I guess if you want to make this an official uapi promise then maybe we should document that, and also enforce that "has PATH property" is equivalent to "is hotplugged connector"
15:27 pq: hmm, so not even in the index in the array, but the order for the same type in the array
15:27 sima: since with imre's latest series the drm code just learned to tell these two apart since it's required to fix a race condition
15:27 sima: pq, maybe order of all non-PATH connectors
15:27 pixelcluster: oh, on the topic of dmem cgroups, I discovered a kinda gnarly bug yesterday :/
15:27 sima: but I think you might get a PATH connector stuffed in there if unlucky
15:27 pixelcluster: I've fixed it with https://gitlab.freedesktop.org/pixelcluster/linux/-/commit/31c98d948b98d6990052ea0bdc89dc1fb083ea16, will send it out to ML soon
15:28 pq: sima, oookay, do not count PATHy connectors, got it
15:28 sima: pq, I'd still be very vary to make this an official promise without docs/enforcement
15:28 pq: btw. I don't mind if fixed connectors gain PATH property, just that dynamic connectors do not lack it.
15:29 sima: ah yeah that's a bit simpler promise
15:29 sima: would still be good to check/document
15:29 pq: yeah
15:31 sima: hm otoh there's a lot of things to check if we ever add some other hotpluggeable connector that's not dp mst
15:31 sima: but then people are talking about doing that with hotplugged bridge chains
15:34 pq: oh... if I use PATH property for the connector name whenever it exists, then the name would change if a driver adds PATH for a connector that didn't have it.
15:36 emersion: yeah…
15:37 emersion: you can check for "mst:"
15:37 emersion: (also see https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3979)
15:38 pq: ah
15:42 pq: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1666#note_2736303 is where I'm discussing this.
15:46 pq: using an udev generator to assing persistent names to DRM connectors could be sweet, if connectors were sufficiently presented in udev
15:47 emersion: would be nice (but still wouldn't want to rely on that in wlroots)
15:48 emersion: sadly connectors already have ID_PATH and various other stuff inherited from the device
15:48 pq: that weston MR suggests to have udev rules to add alternate names to DRM devices so that connectors would have persistent names
15:49 pq: I was thinking of a whole new udev property
15:52 pq: Indeed, ID_PATH refers to the DRM device.
15:55 emersion: pq, would the alternate name be picked by the user, or automatically generated?
15:56 pq: emersion, it's an udev rule, weston wouldn't care.
15:57 pq: also udev rules cannot distinguish between connectors that I can see
15:58 pq: without a new name generator that looks into KMS resources
15:59 pq: not in any reliable way, anyway
16:00 pq: My thought was that there could be an udev generator program that opens the DRM device, iterates through the KMS resources and assigns persistent names to the connectors as udev properties.
16:01 pq: ...that might unexpectedly steal the by-default DRM master status :-p
16:11 zmike: kusma: are you able to attend GL WG this week?
16:16 emersion: pq, also, do we want to standardize on a scheme for a port path?
16:16 emersion: (the same way we're standardizing on a scheme for sink tag)
16:24 kusma: zmike: when is it again?
16:24 zmike: 8am pacific time
16:28 kusma: Today? Then no...
16:29 zmike: tomorrow
16:30 kusma: Ah, then maybe... I'll need to strike a deal with the wife about kindergarten pickup
16:30 zmike: if not tomorrow then 2 weeks from tomorrow, or 2 weeks from then, or ...
16:30 zmike: I would like to get your mipmap issue resolved
16:30 zmike: but it's too scary for us to look without you
16:31 kusma: Yeah, that's always my turn to pick up, so probably will have to find a compromise :-P
16:32 kusma: But honestly, I think jan harald kinda/sorta answered it, and I expect a better answer to be a can of worms... Perhaps we just close it?
16:32 zmike: if you're fine closing it then I won't stop you
16:35 demarchi: airlied: sima: should we force `dim fixes` to mangle the patch and change "Fixes: XXXXX" to a XXXXX that exists in the current branch? Or maybe just add checks so people use the right commit?
16:37 demarchi: we won't fix the case of people replying to a patch that failed to apply to stable and then providing the wrong commit, which was the case this week, but at least we would reduce the complaints from stable maintainers
16:38 sima: demarchi, I think that'd be worse
16:38 sima: we'd fix the Fixes lines, but the double-apply issue still exists
16:39 sima: the only way to solve that is by consulting cherry-picked from lines in your backport branch
16:39 sima: and asking everyone to include them
16:39 demarchi: sima: I don't think we will be able to remove the double apply... because we don't want to change the workflow
16:39 sima: yeah
16:39 sima: the only option where gregkh doesn't have to parse our cherry-picked from lines is if we rebase -next
16:39 sima: never get that wrong
16:39 demarchi: sima: I think he curses, but is fine with the double apply
16:39 sima: and ditch the committer model
16:40 sima: yeah but if the script would just take cherry-picked from as aliases, he wouldn't even curse about double-apply
16:40 demarchi: sima: I think the cherry picked from is not sufficient if he doesn't store the state
16:40 sima: because instead of "this doesn't apply, seems you have it" it wouldn't even try
16:40 sima: demarchi, yeah you need to crawl through git log from the branch point
16:40 sima: like dim cherry-pick does
16:40 sima: iirc
16:41 sima: and since there's lots of ways to nominate a commit for stable (send it per mail, cc: stable on the commit, list it as a dependency in another patch) gregkh needs to do that already anyway
16:42 sima: demarchi, what is clear imo is that if you try to hide the double commits, it's all just worse
16:42 sima: since you need to guess, like sasha shows with the examples from amd where they're now again lacking
16:43 demarchi: I think the worst case is this: a commit is cherry-picked, and then the cherry-pick is reverted.
16:44 sima: yeah but if you track all the cherry-picks it should still sort itself out
16:44 sima: if you get a revert you first check whether you have the commit it reverts in your stable branch
16:44 demarchi: as long as you wait the -next to be merged, i.e. delay the fixes
16:44 sima: checking all cherry-picked from will give you the right answer
16:44 sima: nope
16:44 demarchi: (or look a linux-next, which would be a good option)
16:45 sima: then you check whether you already have that commit again against all cherry-picked from
16:45 sima: demarchi, why would you need to do that?
16:45 sima: if you consistently check for cherry-picks it will just work
16:45 sima: unless drm maintainers screwed up something
16:46 sima: like there's a revert in -next for a commit in -next
16:46 sima: both get cherry-picked (otherwise the revert wouldn't ever)
16:46 sima: but the revert points at a commit in -next
16:46 sima: but you already _have_ a cherry-picked from with the right sha1 from -next in your stable backport
16:46 sima: or at least in -fixes
16:47 sima: so you know you need that revert too
16:47 sima: even if the sha1 does not resolve anywhere
16:47 sima: but it does resolve when you always look at cherry-picked from as an alias
16:47 sima: so no need to wait, no need to special case (beyond "look at all cherry-picked from, not just the one stable added")
16:48 demarchi: so when walking the log he would to mark the aliases, somewhere
16:48 demarchi: *would have to
16:48 sima: or just search them
16:48 sima: you only need to search from the branch point, so it's not the worst
16:49 sima: but yeah a db somewhere is probably a good idea, just needs to cope with more than one cherry-pick alias
16:49 demarchi: last time he said searching them would not be an option since he can't apply the branch point heuristic
16:49 sima: hm why that?
16:50 demarchi: what are the 2 commits to define the branch point?
16:50 demarchi: i.e. with a common parent
16:51 sima: hm right, the original cherry-pick could be before the common parent between the revert in -fixes and your stable tree
16:51 demarchi: yep
16:51 sima: in that case you'd miss the backport
16:51 sima: until -next rolls in
16:52 sima: but does that happen?
16:52 demarchi: sima: I remember it did when I was maintaining a few internal trees with backports
16:53 sima: hm yeah drm-intel-next-fixes cherry-picks would generally fall into that one
16:54 sima: which I guess is why this comes up every merge window
16:55 sima: demarchi, so I guess you'd need a db to annotate them all, worst case
16:56 sima: or just look one more release into the past, since it should never be more than that
16:59 sima: demarchi, takes 0.6s here to do that for the past year
17:00 sima: that = git log --grep="(cherry picked from commit "
17:00 sima: so really not an issue to grep a bit too much
17:01 demarchi: sima: yeah... it can be a alias db that is just rebuilt on every single run, before start walking the log
17:02 sima: demarchi, I'd expect just grep is fast enough, you do it once per commit
17:02 sima: that you need to check
17:05 sima: like there's 800 stable commits roughly from the merge window or so, it's still fast enough
17:06 demarchi: sima: you are filtering out by the ones that have Cc: stable, right?
17:07 demarchi: I don't think this is really the case... they have some other heuristics going on to select candidate commits for stable
17:07 sima: demarchi, I looked at what ended up in stable
17:07 sima: hm yeah that's the wrong number
17:08 demarchi: they need to go through every commit to decide what are the commits that are selected
17:08 sima: yeah but they select first candidates
17:08 sima: cc: stable, Fixes:, Reverts: and some heuristics
17:10 sima: and they need to do an ancestor check anyway to check all the commits before the branch point
18:25 alarumbe: tursulin: I posted a new revision for the fdinfo patch series in panthor, this time around with the changes you suggested in drm_file.c