alanc has quit [Remote host closed the connection]
valpackett has joined #dri-devel
<DemiMarie>
mareko: which message are you replying to?
alanc has joined #dri-devel
valpackett_ has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
valpackett has quit [Ping timeout: 480 seconds]
nerdopolis_ has joined #dri-devel
nerdopolis is now known as Guest5859
nerdopolis_ is now known as nerdopolis
Guest5859 has quit [Read error: Connection reset by peer]
kzd has quit [Quit: kzd]
<mareko>
19:55 < DemiMarie> marmarek: do you agree with that assessment?
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<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.
epoch101 has joined #dri-devel
<DemiMarie>
In Qubes OS, security is a constraint, but performance should be as good as possible within that constraint.
<DemiMarie>
It appears that AMD does not properly validate a buffer parameter (probably alignment), causing glitches.
<DemiMarie>
Do those glitches indicate that undefined behavior (such as GPU memory corruption) could happen?
nerdopolis has quit [Ping timeout: 480 seconds]
<mareko>
DemiMarie: do you mean 1 app corrupting another app?
<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.
<mareko>
DemiMarie: it's impossible, the hw implements virtual memory
<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
<DemiMarie>
trick the compositor, obviously
<mareko>
DemiMarie: that's something that is mitigated by radeonsi by rejecting an unsupported pitch
mbrost_ has joined #dri-devel
<mareko>
if such a corruption could occur, it would be a SW bug
<DemiMarie>
mareko: What about the bug that zamundaaa pointed out earlier?
<mareko>
DemiMarie: that's a bug in our modifier implementation in Mesa
epoch101_ has joined #dri-devel
<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).
<mareko>
it's not corruption, it's just a different order of tiles
<mareko>
you can never assume that there are never any bugs
epoch101 has quit [Ping timeout: 480 seconds]
<mareko>
even kernel code will have bugs
mbrost has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
<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).
<mareko>
there are no formal proofs for anything anywhere
<DemiMarie>
What I would not be okay with is introducing a feature with a known, unfixed security hole.
<mareko>
I'm not aware of any
mwalle has quit [Quit: WeeChat 3.8]
Daanct12 has joined #dri-devel
kzd has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
bolson has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
Company has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
blaztinn has quit [Remote host closed the connection]
Fijxu_ has joined #dri-devel
blaztinn has joined #dri-devel
Fijxu has quit [Read error: Connection reset by peer]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<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.
cgbowman has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
mehdi-djait3397165695212282475 has joined #dri-devel
jsa1 has joined #dri-devel
LeviYun has joined #dri-devel
fab has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
SpieringsAE has joined #dri-devel
tzimmermann has joined #dri-devel
shoragan has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
nccn has joined #dri-devel
LeviYun has joined #dri-devel
mvlad has joined #dri-devel
sima has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
dsimic is now known as Guest5878
dsimic has joined #dri-devel
Guest5878 has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
chiku has quit [Ping timeout: 480 seconds]
caitcatd- has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
lynxeye has joined #dri-devel
Sid127 has joined #dri-devel
caitcatdev has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
frankbinns has joined #dri-devel
sukuna has quit [Remote host closed the connection]
hansg has joined #dri-devel
apinheiro has joined #dri-devel
sinatosk has joined #dri-devel
frankbinns has quit [Read error: Connection reset by peer]
frankbinns has joined #dri-devel
frankbinns1 has joined #dri-devel
sinatosk has quit [Quit: Leaving]
zsz645[m] has joined #dri-devel
mehdi-djait3397165695212282475 has quit [Ping timeout: 480 seconds]
<sima>
MrCooper, so for asymmetric crtc situation it's on userspace, especially when userspace ignores stuff like possible_crtc or asymmetric properties/features
<sima>
and there's definitely been compositors that failed at that
<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
<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
<sima>
but imo that's a case of "design less shit hw"
<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
<MrCooper>
right, my concern is only about dual CRTC; is there asymmetry involved as well in the specific scenario in that issue?
<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
<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
<sima>
jani, ^^ ?
LeviYun has joined #dri-devel
<sima>
but maybe some of that came back
<MrCooper>
anyway, even with asymmetry, there have to be two symmetrical CRTCs to make dual CRTC work, so virtualization can work for that?
<sima>
yeah, but if those happen to be like in the example, then trying to use C for another output won't work
<sima>
because if we remap userspace C to real D with less features, it could break in funny ways again
<sima>
also i915 does remap on old crap, but statically
<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?
<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
<sima>
MrCooper, yeah, in the end there's just random hw limitations that make things fail, so I guess that's fine
<emersion>
reminds me of a patch from ville to document CRTC priorities
<sima>
I'm thinking more of the case where there's a hardwired limitation of which connector can use which crtc
<sima>
but userspace should already be able to figure that out with possible_crtc
<emersion>
vsyrjala: any plans to update that patch?
<sima>
yeah that'd be good to document too, it's been pretty much the assumption
<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?
<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
LeviYun has quit [Ping timeout: 480 seconds]
<emersion>
is it that much work?
<MrCooper>
it solves the problem that issue is about
<jani>
well, maybe
<emersion>
hm, i suppose a lot of the driver access the drm_crtc base
<jani>
emersion: entire history of i915 has been based on the assumption that CRTCs and pipes have fixed 1:1 mapping
<MrCooper>
that contradicts what sima wrote about pipe B above
<jani>
we've minimized the assumptions that crtc index == pipe, but going dynamic is different
kts has joined #dri-devel
<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
<jani>
I don't disagree
feaneron has joined #dri-devel
<sima>
the trouble with trying other crtc is that in full generality you also need to try other planes
<sima>
so things explode really quickly
<sima>
and strictly speaking, you might also need to reassign other connectors to different crtc
<sima>
hence why with other drivers we concluded that assigning in order + virtualization is the best we can do really
<sima>
that's also why we move the panel to the first position, if there is one
<sima>
it's still not going to cover everything, but eventually it's down to stupid hw
<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
<jani>
and in the virtualized setting, you don't even know *why* something failed
<jani>
I mean, there's not a whole lot of info now, but at least it's more predictable I think
<sima>
that problem already exists
<sima>
you might not be able to use all planes because you've run out of fifo space
<sima>
or you can't use scaler on all of them because they're used up
<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
<sima>
so the case of "this crtc actually does less than advertised" is already happening
<emersion>
agreed
<jani>
the bug at hand is a special case of it :p
<jani>
"this crtc can do nothing at all, but try the next one"
<MrCooper>
that's not a thing in KMS API that I know of
<sima>
yeah but does the next one actually have a reduced feature set compared to what the previous one advertised?
<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"
<sima>
same with planes, if you need 2 to scan out planar formats
<sima>
then "oops the next one is now defunct" isn't great
<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?
<sima>
except the fallback is a bit nicer
<sima>
jani, userspace doesn't need to go through the combinatorial search to find if there's still one that does work
<sima>
we essentially assume that lower crtc/plane are better
<jani>
fair
<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
<sima>
same applies to planes
<sima>
essentially it would be a contraction to vsyrjala 's doc patch of "lower crtc are better"
<sima>
if you drop that, it becomes a full combinatorial search of all connector->crtc assignments
<MrCooper>
might a simple intermediate solution be to prefer the last API CRTCs for stealing?
<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?
<MrCooper>
in the driver
<sima>
jani, well if they're not symmetric it gets more messy
<jani>
we've been in the more messy land for a long time now
<sima>
I'd say it depends upon the exact asymmetry you have
LeviYun has joined #dri-devel
<sima>
if the higher crtc numbers have strictly less features, I'd still leave that
<jani>
"leave that"?
<emersion>
leave the features advertised
<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
<sima>
jani, leave those stricter limits in place instead of making every crtc advertise the maximum feature set
<emersion>
er, *unadvertised then
<jani>
:)
<jani>
sounds like a bit of a mess to me
<emersion>
sima, that sounds a bit fragile to me
<sima>
like if D/E only have 2 planes and the other crtc much more, don't advertise more planes on D/E
<sima>
because if userspace uses lower crtc first, it'll never get a better crtc assigned to D/E
<emersion>
what if after some state changes the first CRTC gets assigned to a pipe with less features
<sima>
otoh might make the driver implementation more tricky
<sima>
emersion, yeah that can always happen
<sima>
for pretty much any reason
<sima>
atomic has the "sorry I ran out of magic" escape hatch
<emersion>
what if we had a way for drivers to return a connector-CRTC assignment?
<sima>
not sure that helps, since then the driver is in the business of guessing what the compositor really wants
<sima>
plus you'd need to teach all compositors about this, so there's still pressure to just virtualize in drivers
<sima>
which is where we are at
<emersion>
what do you mean by guessing?
<sima>
maybe robclark and pinchartl could confirm whether or whether not there's virtualization in their drivers
<sima>
emersion, like how many planes you want to use where
<emersion>
userspace can prefer a CRTC because it will in the future use a feature available only there?
<jani>
vsyrjala: the whole discussion above ^
<sima>
emersion, yeah, or just because it wants the most feature on the panel for power efficiency reasons
<sima>
or on the tv for gaming
<emersion>
i was thinking userspace would send the full atomic state, but with placeholders instead of CRTCs
<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
<emersion>
but in the end, that's more or less equivalent to virtualization
<emersion>
i think virtualization + better feedback for errors would be a good solution
guludo has joined #dri-devel
<emersion>
(even if it's Hard)
<sima>
emersion, yeah except it's new uapi, so much harder to roll out
LeviYun has quit [Ping timeout: 480 seconds]
<emersion>
hm, i'm not afraid at new uAPI, i would prefer that in fact
<sima>
it's not so much what I prefer, but the sticking power of existing uapi
<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?
<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
<sima>
and afaik we're already firmly in the "fix this with virtualization" except it's not documented
<emersion>
if it fixes bugs, there is intensive to adopt the new uAPI
<emersion>
for compositors
<jani>
MrCooper: there are platform specific restrictions on which pipes may be joined at all
<sima>
how many people have 3 displays, one of which is a dual-pipe dp?
<MrCooper>
not clear what the new uAPI would really buy anyway, seems like just an additional step for no clear gain
<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
<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
<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
asriel has quit [Quit: Don't drink the water. They put something in it to make you forget.]
<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
<emersion>
fun stuff
rgallaispou has quit [Quit: Leaving.]
NiGaR has quit []
<jani>
"the rest is just software"
<sima>
and I don't think we can "do full combinatorial search" onto compositors
<sima>
jani, :-/
Danct12 has joined #dri-devel
NiGaR has joined #dri-devel
<MrCooper>
compositors might need to put up "grab a coffee" dialogues when changing display settings ;)
<sima>
jani, also kinda wondering how badly fbcon fares on this ...
<jani>
idk
<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
asriel has joined #dri-devel
<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
<jani>
if the pipes were uniform, this would be much less of a problem, but they're just not
<MrCooper>
doesn't enabling an additional CRTC always require a modeset?
<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
<MrCooper>
I see
<sima>
so userspace would definitely need a fallback where it throws the entire config at the kernel with an ALLOW_MODESET
<sima>
but I think that's already required for other reasons like reassigning clocks, but not sure
<sima>
I think fifo reassignment stuff we can do without a modeset on intel, but I think other drivers aren't that good
LeviYun has joined #dri-devel
<zamundaaa[m]>
<sima> "and I don't think we can "do..." <- KWin already does a full connector<->crtc search
<zamundaaa[m]>
IIRC it was necessary for a setup with some old Intel GPU
<sima>
zamundaaa[m], did you not obey possible_crtc?
<sima>
unless your "old" is not like 15 years old
<zamundaaa[m]>
It was a long time ago, but I'm pretty sure we did
kts has quit [Quit: Leaving]
<sima>
zamundaaa[m], also is this is a full search with atomic test_only ioctl?
<zamundaaa[m]>
yes
<sima>
the possible_crtc you can check in userspace, and I think that was all that was needed on old intel gpu
<zamundaaa[m]>
Heh, not so old: Intel® Core™ i7-8700K CPU
<MrCooper>
zamundaaa[m]: you do that full search every time you try to enable anything new, and it fails?
haaninjo has joined #dri-devel
<zamundaaa[m]>
We do that search on every modeset, unconditionally
<MrCooper>
just once?
<emersion>
zamundaaa[m]: do you perform test commits at each step of the search?
<emersion>
or just one test commit at the end of the search?
<emersion>
wlroots does the latter
<zamundaaa[m]>
We do a test commit with every crtc combination that might work
<zamundaaa[m]>
And exit the search at the first one that does
<MrCooper>
zamundaaa[m]: per above, might also need to try different connector / plane / ... mappings in some cases
<sima>
also pixel formats, since some are really hard to scan out
<sima>
if you do full modifiers
<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
<MrCooper>
I'd really rather not even start down that road in mutter
<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
<zamundaaa[m]>
sima: we do fall back to implicit modifiers if everything else fails
<sima>
zamundaaa[m], yeah that's progressively getting worse as a fallback on newer platforms
<sima>
since you might end up with linear
<zamundaaa[m]>
With all of those problems, having actual feedback on why the test commit failed would help a ton
<zamundaaa[m]>
sima: could we get some helper function or whatever that tells us what the modifier is that needs the least bandwidth?
<sima>
I think just documenting the expected fallback order would be a big improvement
<sima>
zamundaaa[m], for extra lolz you need a different set when rotated
<zamundaaa[m]>
KWin doesn't do rotations with modesets, only for direct scanout
<emersion>
yeah, trying all modifiers is a bit much
<emersion>
esp since you need to allocate each time you try
<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
<sima>
but if you need to do both, it goes up real fast
<sima>
especially if we do this with everything else too
<emersion>
also wlroots retries the CRTC/modifier/etc allocation for all enabled CRTCs on each modeset
<emersion>
(because Intel)
<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
<emersion>
(to fix the issue where you might need to downgrade the modifier of an already-enabled CRTC to light up a new one)
<zamundaaa[m]>
jani: we don't need to fix every single special case
<jani>
and then all userspace will make different adjustments, and behave differently
<zamundaaa[m]>
It already does behave differently. Most just fails hard
<emersion>
jani, anything that can reduce the search matrix would be welcome
<emersion>
we can leave "unknown" as a default when there's no solid answer
<sima>
I think we should start to document all these assumptions and especially the specific fallbacks
<sima>
in upstream
<jani>
agreed
<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
<jani>
agreed
<sima>
starting with the very simply of "enabling a crtc needs a fallback for the full configuration involving all crtc/connector with allow_modeset"
<sima>
some will be feature specific and you can ignore (like for rotation)
<sima>
and I'm sure we'll discover a bunch that are just flat out contradictory
vliaskov has joined #dri-devel
<sima>
probably need an entire new "atomic test fallback rules" chapter
<jani>
preferrably with explicit mentions what both sides of the api need to do
<sima>
emersion, maybe even separate rst file so that we can add a MAINTAINERS entry for cc'ing compositor people?
<emersion>
interesting idea
<sima>
or at least a separate kms-uapi file for all that stuff
<sima>
anyway lunchtime, gtg find some food, bbl
<emersion>
i wonder if it makes sense to add uapi headers to that MAINTAINERS entry as well
dolphin has joined #dri-devel
<emersion>
OTOH, it sounds a bit weird to have maintainers who aren't kernel devs
<emersion>
ah, just for CC would be fine I suppose, would be probably wayland-devel as additional ML
<emersion>
ideally the prop docs would be part of this as well
dolphin has quit [Quit: Leaving]
nccn has quit []
indigo has joined #dri-devel
indigo has quit []
cobalt has joined #dri-devel
cobalt has quit []
lemonesque has joined #dri-devel
pcercuei has joined #dri-devel
valpackett_ has quit [Ping timeout: 480 seconds]
chomwitt has joined #dri-devel
rgallaispou has joined #dri-devel
haaninjo has quit [Quit: Ex-Chat]
chomwitt has quit [Remote host closed the connection]
<pq>
12213 unread emails from dri-devel... maybe I should just stop email delivery :-P
ickle has quit [Ping timeout: 480 seconds]
<Ermine>
pq: yeah, dri-devel is super busy
<sima>
emersion, yeah just as a reviewer or something like that, not maintainer
<Ermine>
if mailman had an option for weekly digests or so...
ickle has joined #dri-devel
<jani>
maybe user lore to pull it in at your leisure?
LeviYun has quit [Ping timeout: 480 seconds]
<pq>
my problem isn't the volume but finding the interesting bits I might want to see
<jani>
true
<jani>
I mean yes, that's a problem
<pq>
the more unreads there are, the less likely I am to start shifting through them
<emersion>
pq, i've given up on dri-devel a while ago
rgallaispou1 has joined #dri-devel
kts has joined #dri-devel
<pq>
emersion, how do you keep an eye nowadays? Or depend on personal cc's?
<emersion>
yeah, i don't :/
rgallaispou1 has quit [Read error: Connection reset by peer]
rgallaispou has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
frankbinns1 has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
rgallaispou has joined #dri-devel
frankbinns2 has quit [Ping timeout: 480 seconds]
<jani>
I archive most threads based on the subject of the root message of the thread, unless I'm Cc'd
kzd has joined #dri-devel
nerdopolis has joined #dri-devel
<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
<javierm>
unless I'm in to: or cc:, in those cases I keep it in my inbox
<jani>
javierm: yeah, I also very much like the distinction between "inbox" vs. "unread"
<javierm>
jani: is no surprises since you are my email management coach :)
<jani>
because I archive a lot of stuff without reading, and it's nice to know afterwards whether I've even read it
<jani>
javierm: :D
kzd has quit [Ping timeout: 480 seconds]
<sima>
I get cc'ed on everything, cc stopped being a useful signal
<MrCooper>
dri-devel is the new lkml
<javierm>
sima: I can see how for you could be too much noise indeed
<javierm>
but for us that are no maintainers, is a good indicator
nerdopolis has quit [Ping timeout: 480 seconds]
JRepin has quit []
<emersion>
i know lore can have per-file rules, but never got around to try it
<tzimmermann>
pq, i have 49728 emails from dri-devel. they've been piling up since march 24. :(
<tzimmermann>
unread °
<tzimmermann>
unread ^
LeviYun has joined #dri-devel
<tzimmermann>
i guess i could auto-mark everything as read that does not explicitly cc me
<tzimmermann>
javierm, does this auto-read work for you?
kts has quit [Ping timeout: 480 seconds]
<mripard>
lumag: ack
<lumag>
mripard, r-b on ML when you have time?
bolson has joined #dri-devel
<mripard>
lumag: not sure I'll have the time today, just add my acked-by when applying the patch
<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
<tzimmermann>
:D
<javierm>
tzimmermann: I've been doing the auto archive since before leaving on PTO due Christmas, let's see how it goes...
<tzimmermann>
i guess i'll set up some email filters and test it out
<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
LeviYun has quit [Ping timeout: 480 seconds]
<tzimmermann>
that never happens to me. i'll miss v3 and when i see the series I go 'oh it's at v5 already?'
<javierm>
tzimmermann: yeah but if you try to catch chronologically, how do you know ?
<javierm>
*catch up
MrCooper has quit [Remote host closed the connection]
<tzimmermann>
i scroll from newest to older mails. if it's too old, i won't see it
MrCooper has joined #dri-devel
<javierm>
tzimmermann: ah, you catch up in inverse chronologically order then
<tzimmermann>
still i manage to see most of what comes in during the day.
<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
<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
<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 :)
<lumag>
mripard, ack
digetx is now known as Guest5903
digetx has joined #dri-devel
<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
<mripard>
daniels: witchcraft!
<javierm>
daniels :)
Guest5903 has quit [Ping timeout: 480 seconds]
<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
fab has quit [Quit: fab]
<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
Daanct12 has quit [Quit: WeeChat 4.4.4]
<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
<tzimmermann>
javierm, and 21k of those unread mails are older than 3 months
<sima>
mlankhorst, I guess we need some dmem kerneldoc fixups?
<sima>
sfr send some mails about kerneldoc warnings
<mripard>
no, it's part of that series (patches 3 and 4, I think?)
<tzimmermann>
javierm, since we're talking about it, there's a ssd130x series for you
<sima>
mripard, oops, didn't look at the entire thread
<javierm>
tzimmermann: I know, it's in my TODO since yesterday. But thanks for pointing that out
<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
davispuh has joined #dri-devel
mbrost has joined #dri-devel
<mlankhorst>
Hmm, need to look
<mlankhorst>
mripard: those patches look sane
<sima>
mlankhorst, mripard slapped some r-b on them
<sima>
I overlooked them because I accidentally marked everything as read today
<sima>
oops
aswar002_ is now known as aswar002
cgbowman has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
LeviYun has joined #dri-devel
ids1024 has quit []
LeviYun has quit [Ping timeout: 480 seconds]
ids1024 has joined #dri-devel
<mripard>
sima: I replied to your mail, but how should we merge them?
<mripard>
it's only in drm-next for now
<sima>
uh
<sima>
mripard, drm-misc-next-fixes doesn't have a new enough drm-next?
<sima>
since we're at -rc7 already
<sima>
plus that would be the right branch anyway
fab has joined #dri-devel
<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.
<pq>
'cause I just kinda suggested people to assume that :-P
ids1024 has quit []
<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 :)
Hazematman has quit [Quit: WeeChat 4.5.1]
<sima>
pq, I guess if you're unlucky we could start processing dp mst hotplug stuff while still adding fixed connectors
<sima>
which would shift the enumeration around
ids1024 has joined #dri-devel
<sima>
but I think within a connector type it's safe to assume the ordering stays the same
<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"
<pq>
hmm, so not even in the index in the array, but the order for the same type in the array
<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
<sima>
pq, maybe order of all non-PATH connectors
<pixelcluster>
oh, on the topic of dmem cgroups, I discovered a kinda gnarly bug yesterday :/
Hazematman has joined #dri-devel
<sima>
but I think you might get a PATH connector stuffed in there if unlucky
<pq>
sima, oookay, do not count PATHy connectors, got it
<sima>
pq, I'd still be very vary to make this an official promise without docs/enforcement
<pq>
btw. I don't mind if fixed connectors gain PATH property, just that dynamic connectors do not lack it.
<sima>
ah yeah that's a bit simpler promise
<sima>
would still be good to check/document
<pq>
yeah
<sima>
hm otoh there's a lot of things to check if we ever add some other hotpluggeable connector that's not dp mst
<sima>
but then people are talking about doing that with hotplugged bridge chains
enzuru has quit [Ping timeout: 480 seconds]
<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.
frankbinns1 has quit [Read error: Connection reset by peer]
kzd has joined #dri-devel
<pq>
using an udev generator to assing persistent names to DRM connectors could be sweet, if connectors were sufficiently presented in udev
SpieringsAE has quit [Quit: Leaving]
<emersion>
would be nice (but still wouldn't want to rely on that in wlroots)
lynxeye has quit [Quit: Leaving.]
<emersion>
sadly connectors already have ID_PATH and various other stuff inherited from the device
<pq>
that weston MR suggests to have udev rules to add alternate names to DRM devices so that connectors would have persistent names
<pq>
I was thinking of a whole new udev property
<pq>
Indeed, ID_PATH refers to the DRM device.
<emersion>
pq, would the alternate name be picked by the user, or automatically generated?
LeviYun has joined #dri-devel
<pq>
emersion, it's an udev rule, weston wouldn't care.
<pq>
also udev rules cannot distinguish between connectors that I can see
<pq>
without a new name generator that looks into KMS resources
<pq>
not in any reliable way, anyway
<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.
<pq>
...that might unexpectedly steal the by-default DRM master status :-p
LeviYun has quit [Ping timeout: 480 seconds]
valpackett has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
valpackett_ has joined #dri-devel
<zmike>
kusma: are you able to attend GL WG this week?
valpackett has quit [Ping timeout: 480 seconds]
<emersion>
pq, also, do we want to standardize on a scheme for a port path?
<emersion>
(the same way we're standardizing on a scheme for sink tag)
hansg has quit [Quit: Leaving]
Duke`` has joined #dri-devel
soreau has quit [Ping timeout: 480 seconds]
<kusma>
zmike: when is it again?
<zmike>
8am pacific time
kts has quit [Quit: Konversation terminated!]
<kusma>
Today? Then no...
<zmike>
tomorrow
soreau has joined #dri-devel
<kusma>
Ah, then maybe... I'll need to strike a deal with the wife about kindergarten pickup
<zmike>
if not tomorrow then 2 weeks from tomorrow, or 2 weeks from then, or ...
<zmike>
I would like to get your mipmap issue resolved
<zmike>
but it's too scary for us to look without you
<kusma>
Yeah, that's always my turn to pick up, so probably will have to find a compromise :-P
<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?
LeviYun has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
<zmike>
if you're fine closing it then I won't stop you
tzimmermann has quit [Quit: Leaving]
enzuru has joined #dri-devel
<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?
<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
<sima>
demarchi, I think that'd be worse
yrlf has quit [Ping timeout: 480 seconds]
<sima>
we'd fix the Fixes lines, but the double-apply issue still exists
<sima>
the only way to solve that is by consulting cherry-picked from lines in your backport branch
<sima>
and asking everyone to include them
<demarchi>
sima: I don't think we will be able to remove the double apply... because we don't want to change the workflow
<sima>
yeah
kaiwenjon has joined #dri-devel
<sima>
the only option where gregkh doesn't have to parse our cherry-picked from lines is if we rebase -next
<sima>
never get that wrong
<demarchi>
sima: I think he curses, but is fine with the double apply
<sima>
and ditch the committer model
LeviYun has quit [Ping timeout: 480 seconds]
<sima>
yeah but if the script would just take cherry-picked from as aliases, he wouldn't even curse about double-apply
<demarchi>
sima: I think the cherry picked from is not sufficient if he doesn't store the state
<sima>
because instead of "this doesn't apply, seems you have it" it wouldn't even try
<sima>
demarchi, yeah you need to crawl through git log from the branch point
<sima>
like dim cherry-pick does
<sima>
iirc
<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
<sima>
demarchi, what is clear imo is that if you try to hide the double commits, it's all just worse
<sima>
since you need to guess, like sasha shows with the examples from amd where they're now again lacking
<demarchi>
I think the worst case is this: a commit is cherry-picked, and then the cherry-pick is reverted.
<sima>
yeah but if you track all the cherry-picks it should still sort itself out
<sima>
if you get a revert you first check whether you have the commit it reverts in your stable branch
<demarchi>
as long as you wait the -next to be merged, i.e. delay the fixes
<sima>
checking all cherry-picked from will give you the right answer
epoch101_ has quit []
<sima>
nope
<demarchi>
(or look a linux-next, which would be a good option)
<sima>
then you check whether you already have that commit again against all cherry-picked from
<sima>
demarchi, why would you need to do that?
<sima>
if you consistently check for cherry-picks it will just work
<sima>
unless drm maintainers screwed up something
<sima>
like there's a revert in -next for a commit in -next
<sima>
both get cherry-picked (otherwise the revert wouldn't ever)
<sima>
but the revert points at a commit in -next
<sima>
but you already _have_ a cherry-picked from with the right sha1 from -next in your stable backport
<sima>
or at least in -fixes
<sima>
so you know you need that revert too
<sima>
even if the sha1 does not resolve anywhere
<sima>
but it does resolve when you always look at cherry-picked from as an alias
<sima>
so no need to wait, no need to special case (beyond "look at all cherry-picked from, not just the one stable added")
<demarchi>
so when walking the log he would to mark the aliases, somewhere
<demarchi>
*would have to
<sima>
or just search them
<sima>
you only need to search from the branch point, so it's not the worst
<sima>
but yeah a db somewhere is probably a good idea, just needs to cope with more than one cherry-pick alias
<demarchi>
last time he said searching them would not be an option since he can't apply the branch point heuristic
yrlf has joined #dri-devel
<sima>
hm why that?
<demarchi>
what are the 2 commits to define the branch point?
<demarchi>
i.e. with a common parent
<sima>
hm right, the original cherry-pick could be before the common parent between the revert in -fixes and your stable tree
<demarchi>
yep
<sima>
in that case you'd miss the backport
<sima>
until -next rolls in
<sima>
but does that happen?
<demarchi>
sima: I remember it did when I was maintaining a few internal trees with backports
frieder has quit [Remote host closed the connection]
<sima>
hm yeah drm-intel-next-fixes cherry-picks would generally fall into that one
<sima>
which I guess is why this comes up every merge window
<sima>
demarchi, so I guess you'd need a db to annotate them all, worst case
<sima>
or just look one more release into the past, since it should never be more than that
<sima>
demarchi, takes 0.6s here to do that for the past year
<sima>
that = git log --grep="(cherry picked from commit "
<sima>
so really not an issue to grep a bit too much
<demarchi>
sima: yeah... it can be a alias db that is just rebuilt on every single run, before start walking the log
<sima>
demarchi, I'd expect just grep is fast enough, you do it once per commit
<sima>
that you need to check
<sima>
like there's 800 stable commits roughly from the merge window or so, it's still fast enough
<demarchi>
sima: you are filtering out by the ones that have Cc: stable, right?
<demarchi>
I don't think this is really the case... they have some other heuristics going on to select candidate commits for stable
<sima>
demarchi, I looked at what ended up in stable
<sima>
hm yeah that's the wrong number
<demarchi>
they need to go through every commit to decide what are the commits that are selected
<sima>
yeah but they select first candidates
<sima>
cc: stable, Fixes:, Reverts: and some heuristics
<sima>
and they need to do an ancestor check anyway to check all the commits before the branch point
LeviYun has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
heat has joined #dri-devel
alarumbe has quit [Read error: No route to host]
alarumbe has joined #dri-devel
ids1024 has quit []
fab has quit [Read error: Connection reset by peer]
ids1024 has joined #dri-devel
frankbinns has joined #dri-devel
fab has joined #dri-devel
feaneron has quit [Ping timeout: 480 seconds]
ids1024 has quit []
ids1024 has joined #dri-devel
rasterman has joined #dri-devel
LeviYun has joined #dri-devel
<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
rsalvaterra_ has joined #dri-devel
rsalvaterra_ is now known as rsalvaterra
feaneron has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
zsz645[m] has left #dri-devel [#dri-devel]
NiGaR has quit [Ping timeout: 480 seconds]
NiGaR has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
fab has quit [Quit: fab]
rasterman has quit [Quit: Gettin' stinky!]
macromorgan_ has quit []
sima has quit [Ping timeout: 480 seconds]
macromorgan has joined #dri-devel
vliaskov has joined #dri-devel
vliaskov_ has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
haaninjo has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Quit: Konversation terminated!]
LeviYun has joined #dri-devel
eukara has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
feaneron has quit [Quit: feaneron]
tarceri has quit [Quit: Leaving]
LeviYun has joined #dri-devel
mvlad has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
nerdopolis has joined #dri-devel
linkmauve has left #dri-devel [Error from remote client]
linkmauve has joined #dri-devel
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
Calandracas has joined #dri-devel
Calandracas_ has joined #dri-devel
Calandracas has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
LeviYun has joined #dri-devel
rz has joined #dri-devel
guludo has quit [Quit: WeeChat 4.5.1]
LeviYun has quit [Ping timeout: 480 seconds]
Calandracas_ has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
Company has quit [Quit: Leaving]
apinheiro has quit [Remote host closed the connection]