01:20 orowith2os: zamundaaa: I replied to the EGL_EXT_swap_control_tear comments, and fwiw would you mind maybe pinging me on here for future comments? I didn't see your comments yesterday.
01:40 luc: could both 8086:7d51 and 8086:7dd1 be identified as the same intel arc igpu(140T)? i am asking because it seems to show different PCI device ids under different drivers for the same Core Ultra 9 285H platform
02:09 zamundaaa[m]: <orowith2os> "zamundaaa: I replied to the..." <- Does Github not send you emails for responses?
02:10 orowith2os: it usually gets drowned out by my school emails, assignments, and other projects on github ^^;;;
10:52 mupuf: Hi from xdc2026. On the topic of reviving the interest on drm-ci and public kernel testing, we started toying with the idea of having a single tree for the whole subsystem. The initial reaction from the maintainers present at xdc have been quite positive, and I was wondering if anyone here had some opinions on the topic. The move to to the merge request workflow was also
10:52 mupuf: mentioned, and seemed quite popular.
10:53 mupuf: fixes would have to be handled through a different branch, that maintainers push to. And part of dim would likely have to be ported to gitlab ci to generate trees that are testable
10:55 mupuf: airlied, sima, mripard: I think you would be among the most affected by this change, are there some specific concerns you could have?
10:57 mupuf: the current maintainers of the different trees could keep writing pull request summaries so that the drm maintainers don't suddenly have to follow everything. This is not a unique problem though, as mesa has the same problem with collaboration on release notes.
10:59 sima: mupuf, I think the big vendors want their own thing for various reasons, but otherwise that was kinda what I had in mind with drm-misc long-term
10:59 sima: it just seemed that people want to have their own repos more than the big thing
11:00 mupuf: sima: rob, rodrigo, and alex are enthusiastic about the prospect, that;s a good start
11:00 mupuf: pixelcluster also seem happy with the idea
11:00 pixelcluster: config
11:00 pixelcluster: confirm
11:01 mupuf: maybe you were just too ahead of your time, wouldn't have been the first time
11:01 sima: mupuf, imo absolutely no one is stopping people from piling onto drm-misc (or renaming that to drm-most-things-actually)
11:01 sima: that way we can have a smooth/opt-in transition and when we have the point where airlied&me are unemployed we just retire and call the job done, great success
11:02 mupuf: fantastic, I like this idea because each team can review the workflow of drm-misc and see how this could be problematic for them
11:03 sima: I've generally encouraged people to congregate into bigger teams since below a certain size there's just not enough for stuff like 3 maintainer volunteers so you can rotate
11:03 mupuf: makes sense
11:04 sima: but also I think realistically airlied&me will have to deal with the oddball single trees for another few decades, given how fast people move and at least for the mostly-inactive ones, how little pain they feel
11:04 mupuf: makes sense
11:04 sima: I think there's a notch more incentive to pile into drm-misc-fixes since then you don't have to worry about doing a pr for a single bugfix, so that might be the sales pitch to win the last few hold-outs
11:05 sima: but I think it's also ok if they stay, we'll need someone to process m-l PR probably for a very long time just to interop with the kernel at large
11:05 mupuf: yeah, quite likely
11:06 mupuf: any thoughts on opening contribution through merge requests?
11:06 sima: but yeah in general, bigger, more resilient teams I'm very much a fan of
11:06 sima: I think the big one for that has been to get some minimal CI into place, so it's not a total horror show
11:07 sima: since a lot of the bots we have on various m-l won't read the gitlab stuff
11:07 mupuf: yeah, that's the goal indeed, and we would not open contributions until this is in place
11:07 sima: and I think the other one was to somehow dump it all into lore so the other parts of the kernel still have some idea what we're doing
11:07 sima: or for consistent archiving
11:07 sima: at least
11:08 sima: very unsure on that part tbh
11:08 sima: could perhaps also just yolo if airlied is on board with that
11:08 mupuf: right. I'll need to look into what was done for mesa, but there was a transition period. The transition will just never fully end though, as we will always receive emails to contribute to drm
11:08 sima: yeah ...
11:09 sima: oh airlied might also care about sashiko on gitlab
11:10 mupuf: I'll talk to ivyl about that. He also has experience transitioning a old hats from mailing lists to gitlab (wine)
11:11 sima: sounds good
11:11 sima: lunch over-ready here now, ttyl
11:11 mupuf: enjoy! And thanks for the feedback <3
11:21 sima: mupuf, one more thing to discuss among maintainers I think is how to handle fixes
11:21 sima: my take at least is that you want a cherry-pick model like intel/amd and mesa have, but that's work that needs volunteers
11:22 mupuf: yes, it would have to be a separate branch, like we do in mesa for stable releases
11:22 sima: and it's really not how the kernel traditionally works, so might cause more friction
11:22 mupuf: noted, thanks :)
11:22 sima: well it is like that rn with drm-misc-fixes, but committers push there directly
11:22 sima: instead of pushing to the main branch and letting release person cherry-pick over
11:23 sima: but also since I have argued gregkh into the ground and kernel-stable scripts can cope with our cherry-pick tags, we can go wild without upsetting people outside of drm
11:24 sima: so it's really just about people who work across subsystems like mostly armsoc world
11:25 alyssa: mupuf: as much as gitlab MR's and mesa CI sometimes frustrates me, it is nowhere near the utter terror I feel from pushing a patch with dim and hoping I don't break the x86 build
11:25 alyssa: so that's two thumbs up from me
11:29 sima: oh yeah, dim push is nightmare fuel, fully agreed
11:29 sima: only bested by dim pull-request to linus/lkml :-P
11:30 alyssa: Oh gosh
11:38 mripard: mupuf: I'm not quite sure what you meant by "single tree for the whole subsystem" ? Do you mean merging drm with drm-misc, or drm-* into drm.git?
11:39 mupuf: drm-* into drm.git
11:39 mripard: yeah, I'm not sure how reasonable it is for *every* tree to move there
11:40 mripard: but for drm-misc only I'm fine with it
11:40 mripard: also, the CI is mostly what I had in mind with https://lore.kernel.org/r/20260911-drm-drm-misc-ci-v2-1-1847f89585cb@kernel.org
11:40 mupuf: cool, will read when I arrive at the venue
11:40 mripard: the plan was to add that CI file to CI on push, and once stable extend it to PR and eventually MR
11:41 mupuf: any objections to having msm, i915, xe, amdgpu, and radeon be part of drm-misc?
11:42 mripard: on my end, no, but they would obviously have to follow the same rules we do so I'm not sure if it works for them
11:43 mripard: but if it does, I have 0 problem with that
11:43 mripard: (except for the tag message being harder to write :D )
11:43 mupuf: yeah, that would obviously be needed
11:44 mupuf: there would be obvious benefits to the migration that would hopefully motivate better collaboration
11:44 mripard: I'm curious what they would be, and how you came to have that discussion though :)
11:46 mupuf: ha ha, yeah, I was also a little surprised that the wind has changed so much!
11:47 mupuf: the idea was floated when discussing on the contribution model for a shared drm-ci
11:48 mupuf: the constant back merges were not appealing and are against the guiding principle of never merging untested code
11:51 mripard: yeah, I remember having that discussion with Rob (I think? or lumag?) last year or so
12:22 DragoonAethis: mupuf: +1 for a single repo from Intel kernel CI folks :)
12:23 DragoonAethis: GitLab MRs would be a godsend
15:05 robclark: mupuf, sima: fwiw for msm we've been handling msm-fixes just like msm-next, just a different MR target branch. The key thing is that all changes flowing into a mr+ci branch has to go thru mr+ci. So for either msm-next or msm-fixes, backmerges (drm-next/drm-misc/etc.. or merging random other things like qcom-soc/qcom-drivers/etc) itself is an MR containing the merge, run thru an MR with CI run and if needed xfails updates)
15:08 robclark: (the exception is moving/resetting msm-fixes forward to msm-next for the current cycle.. since msm-next has already gone thru CI)
15:47 dcbaker: mupuf: RE: cherry picking. I've been trying to rework the mesa infastructure to have a more automated approach, perhaps even a bot that can automate some of the backporting, and throw the rest back to the authors. That might also be suitable for drm work in gitlab as well. If you're interested let me know and I'll share what I have as I get further along.
15:48 mupuf: dcbaker: niiice
15:56 dwfreed: We do that at my work; once an MR is merged, the bot runs and attempts to apply the branch to the releases that are tagged, then automatically opens an MR with the backport
17:29 mripard: dcbaker: if anything, I'd like less cherry-picking. it should be an exception when we made some kind of mistake, not the norm
18:52 jani: the worst part about *not* cherry-picking is that the fixes go to -fixes, but they have conflicts galore with the features in -next, and you have a forward porting problem instead of backporting problem
18:55 jani: mupuf: it seems to me nowadays a lot of newcomers treat the mailing list and patches with the same mentality as MR based workflow, and send rapid fire updates to the patches like they would just push new version of the branch
18:56 jani: mupuf: and frankly despite b4, patches are a lossy medium to move data from one git repo to another git repo
18:57 dcbaker: mripard: Mesa has a somewhat different workflow I think, because we strictly backport never forward port. Patches either land in main and then go back to stable as cherry picks, or rarely, patches go to stable but never to main. But nothing goes into stable *before* main.
18:58 jani: mupuf: the main thing I like about patch based workflow is that I can code *and* read my emails *and* review patches in emacs, have code and patches side by side. It will be really really tough to start writing reviews in a web browser as opposed to my editor
19:00 jani: dcbaker: that's basically the rule for kernel stable bacports. the commit has to be in linus' master before it can get backported to stable. for drm-intel, we've just extended that to our -next and -fixes. and it's kind of hard to do any other way if your -next is a fast moving target that never rebases. airlied and sima have argued about this with linus and gregkh for ages.
19:02 jani: I think part of it is that git sucks at cherry-picks, and there's no notion of it being anything other than just a unique commit with the same commit message
19:08 rodrigovivi: jani: time for us, emacs users, to make a gitlab module for emacs?! :) But well, I indeed like the email and hability to get the mbox and all of that... But the amount of emails nowadays and people getting more and more used to MR flows and the AI flooding mailing lists, I believe it is a good idea to try the MR
19:08 rodrigovivi: I also like the idea of the unified tree like mesa with the distributed commit rights
19:09 rodrigovivi: I believe that the biggest change is for misc because they will need to adjust to our flow of merging in a single branch and then backporting to the fixes line....
19:11 rodrigovivi: another thing that might be challenging is for sima and airlied to do the PR to Linus... so for that I had the idea of instrumenting dim for that... we (maintainers of the drivers) would create annotated&signed tags with the summary for our drivers, and they would get dim to provide a unified summary or a complain if there are patches that are not under any specific tag
19:11 rodrigovivi: robclark has some different ideas of handling the sub-branches/drivers
19:12 rodrigovivi: but overall I like the idea of the single/unified drm branch
19:13 pinchartl: rodrigovivi: won't AI flood MRs the same way ?
19:16 mupuf: jani: yeah, emails have their pros, but how many years did it take you to get to it? And then, all the work you do to organize the flood of emails is somehow feeling wasted to me since *everyone* need to make to reproduce this work, thus wasting weeks and weeks of their work day to figure out a workflow that works for them.
19:19 mupuf: To me, forges are amazing because of: 1. they deal with trees only; 2. they provide a unified view on what needs to be looked at, the list of issues, what is fixed or not; 3. they are much more structured and enable a lot more automation (such as CI) that simply work better than whatever you could do with emails.
19:19 jani: mupuf: I'm not arguing *any* of those points
19:20 jani: I just mentioned the one thing for *me* that I'll miss about patch based reviews :)
19:21 mupuf: ack :) Alyssa was quite unhappy about gitlab also when she started using it, but IIRC she has found ways to interact with gitlab in a less painful way
19:22 jani: as far as forges go, I'm really really disillusioned about the freemium gitlab. there's basically zero hope of ever getting better features we want.
19:22 jani: instead, you get things like s/issues/work items/ we don't want
19:22 mupuf: Amen to that, we had a slide about that in the Mesa CI pain points
19:22 jani: gitlab is going full hd jira
19:23 jani: but looks like we're locked in at the moment, so no use debating that :/
19:24 mupuf: yeah, but if it gets that bad, gnome, kde, fd.o, and many other orgs can fork and maintain the thing
19:25 mupuf: there is nothing like gitlab ci though, and it is very powerful
19:25 jani: if you put everything in one repo in gitlab, how many MR's is it going to have every day? are we still going to have separate issue tracking?
19:27 jani: rodrigovivi: I think dim could be retired from developer use completely with a MR based workflow. and eventually the rest could be rewritten in a programming language
19:27 pzanoni: jani: gitlab tags really help separating the stuff you want to see from the stuff you don't want. You can even subscribe to get notification emails only for the tags you want
19:28 jani: pzanoni: o/
19:29 pzanoni: jani: most of my "catching up with what's going on" is done from my email client, for for MRs and bugs. I basically only really need to click when the quotes on email are not good enough or when I need to comment
19:29 jani: pzanoni: for issues you can't really do proper boolean queries with the labels, though... like, (foo OR bar) AND baz is not possible with the freemium version
19:30 jani: dunno if it's the same with MRs
19:30 pzanoni: I never tried that
19:31 jani: mupuf: anyway, need to go for the day, but I'm not opposed to the plan. that said, I'm also not going to have a lot of bandwidth to work on it or iron out any issues either.
19:32 Hazematman: I just tried to do that with MR labels to find all freedreno/turnip MRs in the last year and I couldn't figure out how to do it
19:33 mupuf: jani: you are right, this is unsupported. It still is more fine-grained than mailing lists though, and you would still be free to use client-side tagging like you currently do
19:34 Hazematman: It seems like gitlab used to have that feature but they got rid of it https://docs.gitlab.com/user/project/issues/managing_issues/
19:34 Hazematman: "is one of" and "||" doesn't seem to be there anymore
19:34 mupuf: and no worries, currently, the idea would be to try to slowly converge on drm-misc
19:34 mupuf: piecemeal
19:35 mupuf: I'll be working on the CI there, and you would have a carrot to move to it :)
19:35 jani: mupuf: you gotta have a better name than "misc" for the main drm tree ;D
19:36 mupuf: eventually, it can just be renamed to just drm ;)
19:36 mupuf: anyway, go enjoy your evening, we have months to mull over the idea ;)
19:36 jani: o/
19:36 mupuf: thanks for letting us know your thoughts on it
19:39 jani: sure thing!
19:47 pinchartl: mupuf: jani: for a transition to a forge for patch review, someone(s) would need to invest time and effort into developing tools that would provide all the good parts of the e-mail workflow, where web UI sucks
19:48 pinchartl: I'm sure there are plenty of APIs that can be used to avoid interacting with the web UI, but there's very little in terms of ecosystem around those APIs
19:49 airlied: I'm not that interested in pushing for MR for patcehes initially
19:49 airlied: MRs for pull requests I think would be better
19:49 pinchartl: for what it's worth, that's something libcamera may experiment with at some point
19:49 airlied: One issue I'd have with a combined drm-misc-* is the balance between amount of time and the quality of the weekly pull request summaries will change
19:49 pinchartl: keeping reviews on the mailing list, but using MRs (*not* from the web UI) for merging
19:50 airlied: I'm not saying I consistently get great pull request summaries from anyonem but I'd definitely want to have more rigour around if it I'm only getting one
19:52 airlied: but I'd really like that to have pull requests to me go via MRs that have gone through CI builds and testing, and have some way for my potential MRs to Linus to travel that path, but then I still send a manual MR
19:53 pinchartl: for your pull requests to Linus, you could just push them to a branch in a gitlab tree with CI, would anything else be needed ?
19:56 pinchartl: there's also the question of automatically running patches sent to the list through CI. it's a common practice, and it comes with important security issues that people usually dismiss, when they're even aware about it
19:59 airlied: pinchartl: just have to send the email to Linus in a more disjoint fashion, so I make branches, push to CI, and two days later I realise I forgot to send email :-)
20:00 airlied: I'm not sure we want pre-merge CI on random mailing list submissions, though I'm interested in providing pre-merge CI access to some developers, whether they then use b4 or something to send the patches to the list as well
20:07 pinchartl: for trusted developers I think it's a good idea
20:07 pinchartl: and that could be done in their trees
20:07 pinchartl: so the pipeline wouldn't have access to secrets
20:12 mupuf: airlied: yeah, this was not even an option to test every single series at first
20:29 lucaceresoli: mripard: I'm working on v2 of the "drm bridge hotplug" series, and I've implemented the biggest changes we had discussed
20:29 lucaceresoli: v1: https://lore.kernel.org/all/20260519-drm-bridge-hotplug-v1-0-45e2bdb3dfb4@bootlin.com/
20:29 lucaceresoli: Question is: are you attending LPC/ELCE next week?
20:30 lucaceresoli: I might be able to send a RFCv2 tomorrow morning, just with a few details still to be ironed out, but the bulk of the work is there
20:30 lucaceresoli: Would you have some time to review the most relevant patches before the conference?
20:30 lucaceresoli: That would be material for discussion IRL
20:31 lucaceresoli: pinchartl: lumag_ same questions for you ^^
20:31 pinchartl: lucaceresoli: I'll be at LPC, likely not at ELC
20:32 pinchartl: even though I'll be in Prague for the whole week, the ELC ticket doesn't feel worth it for just one day
20:37 lucaceresoli: pinchartl: good to know, see you there!
20:41 pinchartl: will you attend both conferences ?
20:46 lucaceresoli: I will
21:40 rodrigovivi: airlied: if I'm understanding you right, we should keep our patches in mailing list, but then we maintainers to a MR to you and sima instead of a PR and that is what is going through the CI. is that your view? Even patches from misc? or at least moving misc to a direct patches PR would be okay to you?
21:49 airlied: rodrigovivi: that would be where I'd start
21:50 airlied: I think having misc to me be MRs, but I'm not sure how we can get patches into misc via MRs without seriously running two parallel ways of handling patches
21:51 airlied: like it would be good if any patches going into misc get into CI before they go to me, but I think that giving MR/CI privs to everyone is bit scarier
22:01 austriancoder: hakzsam: have you used a script etc to do all the renaming in !42631 ?
22:03 hakzsam: Not really, I did it manually somehow
22:05 austriancoder: okay .. then its too late for my brain to do this successfully