Danct12 has quit [Read error: Connection reset by peer]
tzimmermann has joined #dri-devel
<danvet>
mripard, mlankhorst, tzimmermann fyi git from ubuntu lts apparently incompatible with rerere of current git
<danvet>
in case someone reports some issues
<danvet>
ubuntu 20.04 has git 2.25 or so
<tzimmermann>
please tell them to upgrade to suse :p
<tzimmermann>
just kidding, do we require such new features?
<tzimmermann>
tbh, it's the first time i'm hearing of git trees that are incompatible with a certain version
toolchains has joined #dri-devel
<mlankhorst>
same
<danvet>
tzimmermann, not git tree, but how conflicts and especially rerere work
<danvet>
occasionally git gets "better"
<danvet>
and then old versions don't understand our stored rerere and fixup patches exactly the same way, and things fall apart
<tzimmermann>
oh
<danvet>
worse, if they then fix it up so drm-tip rebuilds for them
<danvet>
it tends to break for everyone else with newer git
<danvet>
I think it happened like 1-2 times in the past
<danvet>
*past 10 years or so we have dim
<tzimmermann>
i see. i'll keep this in mind
<tzimmermann>
but i'd probably just tell anyone to upgrade their machines. devs shouldn't run old systems IMHO
fab has joined #dri-devel
aravind has joined #dri-devel
rahul_janga has joined #dri-devel
ella-0 has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
fab has quit [Quit: fab]
mbrost has quit [Read error: Connection reset by peer]
ella-0_ has quit [Read error: Connection reset by peer]
kts has quit [Ping timeout: 480 seconds]
rahul_janga has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
mvlad has joined #dri-devel
kts has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
rasterman has joined #dri-devel
lemonzest has joined #dri-devel
rahul_janga has joined #dri-devel
bmodem has quit []
bmodem has joined #dri-devel
fahien has joined #dri-devel
vliaskov has joined #dri-devel
frankbinns has joined #dri-devel
MajorBiscuit has joined #dri-devel
pochu has quit [Ping timeout: 480 seconds]
<javierm>
danvet: maybe dim can check the git version and fail if is not the minimum version supported ?
<javierm>
tzimmermann: agreed, that we should just specify the minimum supported version and people should upgrade
sul has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
sul has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
tursulin has joined #dri-devel
toolchains has joined #dri-devel
sul has quit [Ping timeout: 480 seconds]
sul has joined #dri-devel
glehmann has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
Venemo has quit [Ping timeout: 480 seconds]
Johnny_ has quit [Ping timeout: 480 seconds]
Johnny has quit [Ping timeout: 480 seconds]
Venemo has joined #dri-devel
glehmann has joined #dri-devel
pochu has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Quit: WeeChat 3.5]
bmodem has joined #dri-devel
MajorBiscuit has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
<emersion>
danvet: drm_connector_register() sends a uevent, shouldn't unregister() send one as well?
<danvet>
emersion, it doesn't?
<emersion>
it doesn't seem to, and this results in ENOENT errors because my compositor isn't aware that the connector went away
<danvet>
huh
<emersion>
(ENOENT on commit)
<danvet>
maybe this is an OG dp mst bug, because Xorg just cant remove connectors for reasons so never bothered to listen to this?
<danvet>
airlied, ^^ have some memories?
<emersion>
it's all a bit messy, because the kernel will first send a change uevent with status=disconnected, then wait for the connector/CRTC to be disabled by userspace before free'ing it
<emersion>
but once userspace disables it and kernel destroys it, it doesn't seem like we get a new uevent
<emersion>
so user-space thinks it's still there (albeit disconnected/disabled)
<danvet>
yeah
<danvet>
I also just noticed that when we register at driver load we generate a bit of an ueven storm
<emersion>
(cc JoshuaAshton)
<emersion>
yeah…
<danvet>
but not sure that's fixable, or at least easy fixable
<danvet>
but yeah the lack of uevent is a bit disturbing to say the least :-/
<emersion>
uevent storm can also happen on dock plug/unplug
<danvet>
oh that's the nature if the thing really
<emersion>
at least the uevents are tagged with connector IDs
bmodem has joined #dri-devel
<danvet>
I mean we do generate one per connector even for the fix stuff
<emersion>
so smart user-space can avoid re-probing all connectors always
<danvet>
well only since you fixed that ...
<danvet>
but yeah maybe we need a getcap that says "non-shitty connector uevent"
<danvet>
and add the hotunplug one on unregister
<danvet>
and maybe document the actual lifetime rules we now have, because it's very messy
<danvet>
emersion, btw at least for old kernels you need to deal with ENOENT no matter what
<danvet>
because those just nuked the connector, even if in use or anything
<danvet>
so yay pageflip ioctl keeling over too
<emersion>
the compositor is gamescope, so we can just ship a kernel patch for our purposes
<emersion>
i think other compositors don't disable all connectors one modeset so they should be somewhat fine
<emersion>
on*
bmodem has quit []
pochu has quit [Remote host closed the connection]
<airlied>
danvet: not good memories, but probably overlooked
<airlied>
Lyude: ^ encountered the above?
<MrCooper>
emersion: so you're saying gamescope can't be used outside of SteamOS? ;)
<emersion>
lol
<emersion>
it's nice to be able to tell users to just use an up-to-date kernel with the latest fixes in
<emersion>
instead of adding workarounds all over user-space
<javierm>
tzimmermann: thanks for pushing danvet's patch to drm-misc-next. I was meaning to do the same but saw this morning that Helge already pushed to his tree
<tzimmermann>
np
<emersion>
danvet: where would be a good place to document these lifetime rules?
toolchains has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
rkanwal has joined #dri-devel
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
devilhorns has joined #dri-devel
<danvet>
emersion, don't we have some docs for the connector/property uevent? maybe there?
<danvet>
I guess ideally with some lifetime dot graph or so
<danvet>
but yeah not sure where the best place is
<danvet>
javierm, yeah helge picking up that patch was a bit funny
toolchains has joined #dri-devel
jkrzyszt has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
JohnnyonF has joined #dri-devel
toolchains has joined #dri-devel
<javierm>
danvet: I still don't understand why he can't just use drm-misc-{next,fixes} instead
<javierm>
the important part is someone looking at fbdev patches, not how those make their way into mainline
Company has joined #dri-devel
<MrCooper>
anholt: https://gitlab.freedesktop.org/mesa/mesa/-/pipelines shows post-merge pipelines requiring container jobs to be triggered manually; they need to run automatically, to ensure the docker images in the main registry are up to date
kts has quit [Quit: Konversation terminated!]
toolchains has quit [Read error: Connection timed out]
saurabhg has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
toolchains has quit [Ping timeout: 480 seconds]
rahul_janga has quit [Read error: Connection reset by peer]
JohnnyonF has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
<eric_engestrom>
?ref=main to show the post-merge pipelines
<javierm>
tzimmermann: awesome. Nice to get rid of those TODO finally
<tzimmermann>
javierm, yeah that's a nice side effect. a lot of those TODOs are now gone
<tzimmermann>
but the actual code doesn't necessary implement all the adversised features, as noted in the cover letter. we have to add things as needed
sul has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: yeah, noticed that only for system memory for source buffers
<javierm>
*as source
sul has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<tzimmermann>
javierm, i'll probably add a patch with warnings on top in v2
<tzimmermann>
so that these shortcommings won't go unnoticed
<javierm>
tzimmermann: feel free to add my a-b for patch 11/12. I can't review the whole series because I'm leaving on PTO tomorrow and have to finish a few things today
<tzimmermann>
javierm, oh, enjoy your vacation
<javierm>
tzimmermann: thanks :)
kts has joined #dri-devel
toolchains has joined #dri-devel
<javierm>
tzimmermann: can we do something for CMA-backed memory too? So that we conditionally do the extra memory buffer in the conversion helpers instead of unconditionally?
<javierm>
I remember you mentioned that had some patches for that too
<tzimmermann>
i still do. i simply have to get them ready
<javierm>
tzimmermann: Ok
<javierm>
tzimmermann: I'm surprised about your ability to keep so many in-flight patch series :)
<javierm>
I wouldn't be able to keep al that in my head
<javierm>
*all
kts has quit [Quit: Konversation terminated!]
itoral_ has quit [Remote host closed the connection]
<tzimmermann>
oh, i'm not really able either. but i have plenty of local git branches and i occationally look through them to see if there's anything useful for upstream.
<tzimmermann>
i sometimes start something for experimentation and have to leave it for a while. and when the topic comes up again, i look through the branches to see what i already have
<tzimmermann>
sam's recently been talking about a new driver that needs to do conversion in system memory, so i got back to the topic, which i wanted to do anyway at some point
kts has joined #dri-devel
<javierm>
tzimmermann: interesting approach. I should try to do more of that
<javierm>
tzimmermann: I'm usually afraid that if I leave something in the middle, I won't remember anymore how that worked :)
<tzimmermann>
i know that problem :D
<javierm>
haha
fahien has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
heat has joined #dri-devel
toolchains has joined #dri-devel
alyssa has left #dri-devel [#dri-devel]
kts has joined #dri-devel
kts has quit []
fxkamd has joined #dri-devel
cef has quit [Ping timeout: 480 seconds]
<alatiera>
hey, are there any stable branches in mesa or else that might still be using server2019 windows builds/runner?
cef has joined #dri-devel
zehortigoza has quit [Remote host closed the connection]
<sravn>
tzimmermann: awesome, I will have a look at the format-helper series this week. And now one less excuse to throw hours after the atmel driver
<daniels>
alatiera: yeah, stable branches indeed
<daniels>
ah, though neither of those branches are maintained any longer, so they shouldn't be running
zehortigoza has joined #dri-devel
<alatiera>
excellent, one less repo to worry about then
<alatiera>
thanks!
MajorBiscuit has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
mbrost has quit [Remote host closed the connection]
<jekstrand>
jenatali: Am I reading correctly that D3DKMT_LOCK2 doesn't support any sort of placement options? Like you can't pass it a "requested" address or anything like that.
<anholt>
MrCooper: I've pasted the ymls into the editor and looking at the merged result, and x86_build-base (for example) has the "*is-post-merge" rules present and just after .no-scheduled-pipeline-rules, so it hasn't been overridden by something I've done that I can see.
<MrCooper>
hmm, maybe the conversion to $CI_COMMIT_BRANCH broke it then?
<Kayden>
yeah, that's quite the chain of things going off the rails
<Kayden>
some of which are squarely in the probably-not-going-to-get-fixed camp
ybogdano has quit [Ping timeout: 480 seconds]
<jenatali>
dcbaker: I think I had tagged one patch with a Fixes: but it needs a part of a different patch in the series to be able to build... I'm out of town at the moment so you can drop it since I probably won't be able to help backport it
<Kayden>
the main painful part of that is that i915 deprecated and dropped the GET/SET_TILING APIs, so without modifiers, we have no way to communicate tiling information to X
<Kayden>
so DG2 is stuck with linear buffers for scanout 100% of the time
<Kayden>
which also means no fast clears or anything
<Kayden>
I guess the solution here is to just move to a wayland compositor
<Kayden>
since fixing atomic in the modesetting driver is likely never going to happen
<ajax>
ain't high on my list
<ajax>
personally i'm thinking people use weston in kiosk mode and an Xwayland fullscreen under that
<ajax>
because honestly nobody has the patience to make atomic randr happen
<tleydxdy>
weston have problem passing in relative pointer I think
<tleydxdy>
but just xwayland should be find, idk
JohnnyonFlame has joined #dri-devel
JohnnyonF has joined #dri-devel
rkanwal has joined #dri-devel
<Kayden>
heh, glmark2 runs 41% faster with modifiers enabled
<daniels>
tleydxdy: do you have any details on this?
ybogdano has joined #dri-devel
<tleydxdy>
I was using wayland under another compositor to make use of it's xwayland support, but relative pointer events are not passed
<tleydxdy>
so e.g. games don't work
<daniels>
mm, right - it should work under the DRM backend, but we never had a good reason to implement it for the nested backends, because you're the first person I've heard of who's tried game -> Xwl -> Weston -> another compositor
fahien has quit [Ping timeout: 480 seconds]
<tleydxdy>
I've since added xwayland to that other compositor but I'm still dealing with the edge cases
vliaskov has quit [Remote host closed the connection]
<airlied>
Kayden: bring back the tiling apis if all else fails I suppose
danvet has quit [Ping timeout: 480 seconds]
<Kayden>
I guess that's an option
<Kayden>
I was wondering about stuffing a list of modifiers that can work with display in the modesetting driver or glamor
<Kayden>
I know that negotiating is necessary for all the fancy ones because of Intel display's horrendous "not enough display bandwidth depending on the monitor configurations"
<Kayden>
but maybe it'd be possible to just get Tile4
<Kayden>
if there's something that can actually always work
ybogdano has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
<ajax>
anyone working on / have opinion about VK_KHR_global_priority ?
stuart has quit [Remote host closed the connection]
stuart has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
aswar002 has joined #dri-devel
ybogdano has joined #dri-devel
aswarup_ has joined #dri-devel
aswarup_ has quit [Remote host closed the connection]
<airlied>
ajax: appears windows doesn't have reallocarray
<airlied>
I blame jenatali
<airlied>
though possibly should not have used that, since I think it's a BSDism
<jenatali>
Sorry
<airlied>
ah no it's in glibc
nchery is now known as Guest6225
Guest6225 has quit [Read error: Connection reset by peer]
nchery has joined #dri-devel
<airlied>
anyone want to ack the wrapper in 17746?
eukara has quit [Remote host closed the connection]
<dcbaker>
it was originally a bsdism I think
<dcbaker>
airlied: I've seen that exact implementation elsewhere, so, a-b
<airlied>
dcbaker: is that old enough in musl world?
<dcbaker>
I don't know, I guess we can find out :)
<dcbaker>
If someone using an old musl cares then can send the patch to have meson check
<dcbaker>
my a-b stands
<airlied>
oh I wonder if OSX will be my downfall
<airlied>
the X server uses it everywhere, let me go look
<jenatali>
Seems simpler to just add the meson check than to try to prove which platforms do/don't have it IMO
<airlied>
you have to do a libbsd check to keep up with X server
mvlad has quit [Remote host closed the connection]
<airlied>
okay I think I got the logic right for a meson bit
<jenatali>
Yeah that looks good/better
<ajax>
ngh
<Kayden>
hmm...not getting any modifiers with mutter and xwayland either. I'm guessing that's because they're turned off in mutter. though, if xwayland isn't page flipping or anything, it could probably use them anyway...?
rasterman has quit [Quit: Gettin' stinky!]
toolchains has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
gouchi has quit [Remote host closed the connection]
<dj-death>
Kayden: there is a mutter setting
<dj-death>
Kayden: in dconf /org/gnome/mutter/experimental-features
<dj-death>
Kayden: you have to put "kms-modifiers” in that list
<Kayden>
I don't think we have a path to fix that, either
<jannau>
does anyone know if mesa was tested on a arm64 with branch target identification (BTI)? The fedora 36 package (built with branch protection) is very broken on Apple's M2 which has BTI
toolchains has quit [Ping timeout: 480 seconds]
JohnnyonF has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]