pallavim has quit [Read error: Connection reset by peer]
yuq825 has joined #dri-devel
kxkamil has quit []
kxkamil has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
thellstrom has joined #dri-devel
Leopold has quit [Remote host closed the connection]
i-garrison has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
fab has joined #dri-devel
tursulin has joined #dri-devel
frieder has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
pochu has joined #dri-devel
pallavim_ has quit [Ping timeout: 480 seconds]
Zopolis4 has quit [Quit: Connection closed for inactivity]
kxkamil2 has joined #dri-devel
dtmrzgl1 has joined #dri-devel
dtmrzgl has quit [Ping timeout: 480 seconds]
kxkamil has quit [Ping timeout: 480 seconds]
tursulin has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
sgruszka has joined #dri-devel
<pq>
Hmm, receiving a massive KMS patch series, it's really hard to see what new UAPI it is actually adding. E.g. no UAPI headers are touched at all, and they don't need to for new KMS properties. Likewise, all UAPI docs are buried in .c files - or is that an indication they don't exist?
<pq>
yes, a cover letter has a summary list, but it's a little vague.
bmodem1 has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
apinheiro has joined #dri-devel
jkrzyszt_ has joined #dri-devel
pcercuei has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest1213
swalker__ has joined #dri-devel
i-garrison has joined #dri-devel
Guest1213 has quit [Ping timeout: 480 seconds]
djbw has quit [Read error: Connection reset by peer]
gouchi has quit [Remote host closed the connection]
bifidock has quit [Ping timeout: 480 seconds]
<DavidHeidelberg[m]>
I got some feedback from Michel Dänzer, incorporated changes, I'll go to the lunch then I'll merge. It's solidly stress-tested, but I need merged rather sooner than later, because it's huge enough to break with additional MR.
<DavidHeidelberg[m]>
In next few days I'll work on making the rebuilding containers and rootfs faster, so more will come soon!
bmodem has joined #dri-devel
<MrCooper>
sounds good, thanks for incorporating my feedback
bmodem1 has quit [Ping timeout: 480 seconds]
neonking has quit [Remote host closed the connection]
neonking has joined #dri-devel
smilessh has quit [Read error: Connection reset by peer]
smilessh has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
itoral has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
apinheiro has quit [Quit: Leaving]
<DavidHeidelberg[m]>
eric_engestrom: can I just merge? For libdrm, I'm preparing whole approach to handle as debian package. You just define git repo + version + add needed patches and it'll build a repository for you
Company has joined #dri-devel
<DavidHeidelberg[m]>
so no-one will have to touch Debian packaging and in Mesa3D CI, you'll just install right packages from the repo@commit
<DavidHeidelberg[m]>
also you'll be able to install same packages locally on your machine and test
<eric_engestrom>
DavidHeidelberg[m]: sure, that sounds like a reasonable solution, as long as you actually manage to do it before the next libdrm uprev is needed 😅
<DavidHeidelberg[m]>
this week is fine? :D
<eric_engestrom>
feel free to ignore my libdrm & wine comments
<DavidHeidelberg[m]>
thanks. I'll move the false -> disabled checks
<eric_engestrom>
haha yeah if you think it'll be done that quickly then I have no reservation :)
<DavidHeidelberg[m]>
I'm currently as Debian miniconf in Hamburg, so in case I get stuck, I'm sure it'll be question of minutes :D
<eric_engestrom>
haha, perfect timing
<shadeslayer>
daniels: btw I noticed that a630 reports gpu hangs when running some of the traces on mesa master
smilessh has quit [Read error: Connection reset by peer]
smilessh has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
yuq825 has quit [Read error: Connection reset by peer]
smilessh has quit [Remote host closed the connection]
<dcbaker>
karolherbst: yes, I will have a look today!
<karolherbst>
cool, thanks!
sgruszka has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
fxkamd has quit []
YuGiOhJCJ has joined #dri-devel
i509vcb has quit [Quit: Connection closed for inactivity]
pallavim has joined #dri-devel
<eric_engestrom>
DavidHeidelberg[m]: would you know how to get ci_run_n_monitor to take a --pipeline instead of trying to guess it? I'm having a need for this again, and last time I had a look I got lost and gave up
<eric_engestrom>
(the guess behaviour works in the common use case, so we should keep it, but also allow the user to specify one)
<sima>
"Because this table is very unwieldy, do not add any new properties here. Instead document them in a section above."
<sima>
emersion, do you mean link to a specific property instead of just the section?
<emersion>
yea
<robclark>
hmm.. but just having them documented in code means there aren't some files to filter on to look for new properties, which is I think what emersion was looking for
<sima>
hm ... not sure how to do that
<sima>
robclark, yeah it's not super great
<emersion>
just use a regular heading instead of the weird <b>
<sima>
:-/
<sima>
emersion, headings in inlined C comments get funny when the nesting is wrong
<sima>
iirc
<emersion>
sima, would you mind if the prop docs were not in .c files?
<emersion>
but in a proper .rst?
<robclark>
heh.. if we had CI we could do something like write a test that fails if any new prop added what isn't also listed in an allowlist.txt type thing
<sima>
the .c comments are proper .rst, just funny inline directives
<robclark>
s/what/which/
<emersion>
i mean a separate .rst file
<sima>
for ioctl v4l has some validator, but the problem is it's pretty hard to programmatically detect prop names
<emersion>
i do parse the existing docs to display them on drmdb
<emersion>
but it's horrible
<sima>
emersion, ime pulling docs out of .c files means developers ignore them even harder than now
<sima>
and as long as we don't have dedicated doc wranglers, that's probably worse
<emersion>
i'd say 30% worse than the parsing of formats and modifiers from drm_fourcc.h i'm doing
<sima>
but we can change the formatting to something that's beter
lemonzest has joined #dri-devel
<sima>
emersion, uh can't you pull it out of the rst?
<emersion>
sima, the prop docs are scattered in random .c files atm
<sima>
sphinx parses it as an entire rst before it's actually generating the output
<sima>
not sure whether there's a good way to dump that intermediate step though
<sima>
parsing .c directly is indeed a bit much lol
<emersion>
i don't really want to run any of the kernel's build when doing that
<emersion>
i don't even have a full kernel checkout
<sima>
emersion, could you at least reuse the kerneldoc parser?
<sima>
that should give you the .rst (without headings)
<sima>
and then it's just rst parsing
<sima>
but yeah if you want to build your own .rst kerneldoc parser I guess you get to keep the pieces :-)
<sima>
hawkdoc from jani might be compatible enough if the kerneldoc one is too horrible
<emersion>
well, w/e i just give people linkds to drmdb instead of kernel docs now
<emersion>
links*
<sima>
emersion, another option might be to put your parser magic into kerneldoc and generate the output there
<sima>
yeah imo totally fine to link people to drmdb
<sima>
the overview is neat
pcercuei has quit [Quit: Lost terminal]
pcercuei has joined #dri-devel
<sima>
emersion, do you also take downstream trees for drmdb?
<sima>
some of the props look really funky
<emersion>
yeah, people submit snapshots from various trees
<emersion>
see the kernel version
<emersion>
not sure how to reliably detect downstream vs. upstream
<sima>
I guess a "upstream documented" flag would be useful in the overview table
<sima>
^^
<emersion>
right
<sima>
if it's not documented it's probably one of the old driver specific ones that you don't want to use in new generic compositor code
<sima>
maybe with a comment that upstream documented should mean consistent semantics across upstream drivers, good for use in generic compositors
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
swalker__ has quit [Remote host closed the connection]
junaid has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
Rayyan has quit [Quit: bye!]
Rayyan has joined #dri-devel
<linkmauve>
When DRM_CAP_CURSOR_WIDTH and DRM_CAP_CURSOR_HEIGHT are defined, wouldn’t it make sense to also have the cursor planes set the maximum size of CRTC_W and CRTC_H to it instead of INT32_MAX?
sukrutb_ has joined #dri-devel
aravind has joined #dri-devel
<emersion>
these caps aren't always the max
<emersion>
they're just a good™ size
<emersion>
on i915 they're the max, on other platforms they're not
<linkmauve>
Oh, ugh.
jkrzyszt_ has quit [Ping timeout: 480 seconds]
<linkmauve>
Why did other platforms just use it as a hint?
<linkmauve>
It makes it pretty much useless.
<emersion>
user-space needs a hint
<emersion>
ville had a series to improve this
<emersion>
advertise multiple sizes, indicate when there are no size constraints
bmodem has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
<agd5f_>
linkmauve, when the CAP was added, we had hardware that didn't support 64x64 cursors and everything assumed that so we need some way to convey what size the hardware actually supported
<agd5f_>
IIRC, the AMD hardware at the time had a min size of 128x128 IIRC. There was also some ARM SoCs that only supports 32x64 cursors
<linkmauve>
But in that case, couldn’t the plane set the property to "CRTC_W" (atomic): range [128, INT32_MAX] = 0 or something?
<linkmauve>
And [32, 32] in the case of that ARM SoC.
<linkmauve>
Can they still do scaling in that case?
frieder has quit [Remote host closed the connection]
<emersion>
sigh, did we really need a whole bus type for this…
<emersion>
well, anyways, feel free to send patches for drm_info, if you have the time
<HdkR>
Considering it is only on Tegra, one could say it actually is obscure :)
<emersion>
should be copy/paste of platform mostly
junaid has quit [Ping timeout: 480 seconds]
<linkmauve>
I’ll try adding a compatible string to my dts, perhaps nvidia,tegra210-host1x or something?
<linkmauve>
Hmm, but almost none of the existing dts for tegra platforms do that…
<emersion>
so you mean the device tree leaves host1x compatible to NULL?
aravind has quit [Ping timeout: 480 seconds]
<linkmauve>
Even if I set a compatible string it doesn’t get displayed in drm_info -j, weird.
<emersion>
linkmauve: linked above is the drm_info code, which doesn't support reporting host1x
<dottedmag>
w.r.t. plane sizes: there is a display controller (in Apple's M1/M2) with planes that cannot be placed partially offscreen. 1) is there a way to provide a hint about it to userspace? 2) is it useful, or _all_ userspace already assumes that cursor planes can be placed partially offscreen? 3) is it a good idea to "fix" it in driver by clipping and passing the clipped piece to the controller?
<linkmauve>
Ah right, I’ll have a look there, thanks. :)
<emersion>
dottedmag: (1) no, just a way to reject atomic commits (2) user-space does assume cursor planes can be offscreen partially
<emersion>
(3) yeah probably, if you can crop. amd is doing the same kind of thing iirc
illwieckz has quit [Ping timeout: 480 seconds]
<linkmauve>
Speaking of which, Weston never places the cursor plane at negative locations even if it means falling back to GL compositing.
<jannau>
the overlay (cursor) plane can be partially off-screen but 32 pixels have to remain on-screen horizonatally
<jannau>
i.e. this is mostly a problem at the right screen edge
<emersion>
hm, that sounds cumbersome
<dottedmag>
jannau: and left screen edge for the X root cursor :)
<emersion>
maybe allocations matching the cursor size can be padded on the left?
illwieckz has joined #dri-devel
junaid has joined #dri-devel
<jannau>
not sure how I would enforce the padding if I can guarantee that the plane is allocated via the display kms driver
<emersion>
yeah, it'd be super hacky in any case…
<emersion>
no user-space is prepared to see the cursor plane fail when moved around
<zamundaaa[m]>
emersion: KWin does handle such things
<jannau>
s/can/can't/
<emersion>
intresting
<zamundaaa[m]>
It does an atomic test for any and all cursor updates, and if it fails then KWin disables the plane and falls back to a sw cursor for the next frame
<emersion>
wlroots handles drmSetCursor failures, but doesn't fallback to GL when drmMoveCursor fails
smilessh has quit [Ping timeout: 480 seconds]
<emersion>
hm, actually on atomic it's worse for wlroots :/
<emersion>
it doesn't expect the cursor plane to fail because of constraints
<jannau>
it's probably more efficient if the driver copies, crops and pads the cursor plane if it is too much off-screen than falling back to SW cursors
<jannau>
just ugly and annoying
<agd5f_>
linkmauve, at the time hw cursors on most hardware had a fixed size, so the CAPs just exposed the size that usespace should use
<agd5f_>
i.e., if the cap says 128x128 and you used 64x64, it wouldn't work
<emersion>
linkmauve: ty! so, with that fixed, does the kernel expose a compatible string or is it still empty?
Daanct12 has quit [Quit: How would you be so reckless with someone's heart!?]
Danct12 has joined #dri-devel
<linkmauve>
emersion, it does, it was defined in arch/arm64/boot/dts/nvidia/tegra210.dtsi actually, which I hadn’t read before.
<linkmauve>
"available_nodes": 5,
<linkmauve>
"compatible": [
<linkmauve>
"device": {
<linkmauve>
"bus_type": 3,
<linkmauve>
"device_data": {
<linkmauve>
"nvidia,tegra210-host1x"
<linkmauve>
]
<linkmauve>
},
<linkmauve>
"bus_data": {
<linkmauve>
}
<linkmauve>
"fullname": "\/host1x@50000000"
<linkmauve>
},
<linkmauve>
Oops, I forgot we aren’t on XMPP here.
<emersion>
nice!
<emersion>
i will update drmdb as well, unless you have time for that
<linkmauve>
Feel free to, I still have a bunch of driver porting to do from 4.9 here, plus some more RE for the things we have no driver for yet.
<airlied>
mlankhorst: fixes?
<DavidHeidelberg[m]>
robclark: Hey! Is the `iommu/arm-smmu-qcom: Fix missing adreno_smmu's` patch still latest solution available (will be doing kernel uprev tomorrow)
<robclark>
DavidHeidelberg[m]: I think if you rebase that patch should drop out
<robclark>
it should be on ToT already
<DavidHeidelberg[m]>
robclark: on 6.3.4? it's still there
<robclark>
it should be in drm-fixes.. possibly linus ToT.. not sure about stable branches
oneforall2 has quit [Remote host closed the connection]
<linkmauve>
In pretty much the same configuration as the Switch, except YUV formats are only available on one of the two overlay planes, while on the Switch they are available on both.
<linkmauve>
And on Intel they are available on both the primary and the overlay.
<linkmauve>
On AMD there is no non-primary plane whatsoever.
<linkmauve>
And that’s the extent of the hardware I have powered on around me. ^^
oneforall2 has joined #dri-devel
<linkmauve>
emersion, small suggestion for duplicated uploads, in addition to saying this has already been uploaded you could return the URL of said upload.
<emersion>
yeah, would be nice indeed
<linkmauve>
Uh, there is a bug in pretty.c, the JSON now says 254 because I modified the driver, but the pretty still says UINT8_MAX.
<linkmauve>
But that shouldn’t be possible, hmm…
<linkmauve>
Wut, now it’s correct.
<linkmauve>
Haha, I was still looking at my previous ssh session, before the reboot. ^^'
<emersion>
ahah
<linkmauve>
Ok, so that’s now fixed.
<linkmauve>
Ah, the 255->254 can already be applied to mainline.
JohnnyonF has joined #dri-devel
<linkmauve>
There, sent to the maintainers and the MLs.
rasterman has quit [Quit: Gettin' stinky!]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<Hi-Angel>
Oh, my Mesa commit marked with "cc: stable" that was merged 6 days ago didn't make it into the 23.1.0 release :c
<karolherbst>
Hi-Angel: I think the prober way is "cc: mesa-stable"
<DavidHeidelberg[m]>
karolherbst: I really hope stable works, I recently reviewed some commit with it as OK
<karolherbst>
yeah.. I don't know...
<karolherbst>
the docs say `Cc: mesa-stable`
<karolherbst>
you all might want to double check :D
<karolherbst>
mareko: seems like your commit 60a3f0667f7bffcc1667396f3aa1fc891dcba3a0 with Cc: stable, didn't make it into 23.0
tursulin has quit [Ping timeout: 480 seconds]
<karolherbst>
eric_engestrom, dcbaker: seems like some patches are tagged with `Cc: stable`, and it looks like those aren't picked automatically
<dcbaker>
yeah, it needs to be mesa-stable IIRC
<dcbaker>
eric_engestrom: has some patches to do away with the CC: stable and just have a `stable: X.Y` I think
<dcbaker>
or maybe it's backport: X.Y?
<dcbaker>
can't remember
<dcbaker>
if they're for 23.0 let me know if there's any more shas and I'll get them pulled
<dcbaker>
* If there are any more
<karolherbst>
04699cc3aa1c3037b4b6d15f88e5157d31adda1a, 60a3f0667f7bffcc1667396f3aa1fc891dcba3a0, da7dfbe3b85089fa242d076f4e4306431f69b084 are all I think
<karolherbst>
there are some patches from last year, but that's all before 23.0
bgs has quit [Remote host closed the connection]
<Hi-Angel>
Anyway, my commit 275cf62e is properly tagged as Cc: mesa-stable but didn't make it into 23.1 (which was created 5 days after my commit), so I'm just a bit worried if it will make it into 23.0.4. My friend kind of depends on the fix
<karolherbst>
ahh yeah.. I think we have some latency on that side
<karolherbst>
dunno, but the tag is like 2 weeks old :)
<Hi-Angel>
Gotcha
fab has quit [Quit: fab]
<dj-death>
lol
<dj-death>
I just noticed some of my commit message have : Part-of: <f{merge_request.web_url}>
<jenatali>
Well that's not great
<dj-death>
seems to have affect only one MR
Leopold_ has quit []
<eric_engestrom>
Hi-Angel: 🤦
<eric_engestrom>
I forgot the docs when I did the 23.1.0 release and tried to backdate them, but clearly I messed up :]
<Hi-Angel>
eric_engestrom: mhm?
<Hi-Angel>
Oh, I see
<Hi-Angel>
No worries, nice that everything cleared up ☺
Leopold_ has joined #dri-devel
<eric_engestrom>
also, 23.1.1 was supposed to be tonight, but I haven't had time, it'll be tomorrow
<airlied>
eric_engestrom: would be good to get the fix from 23221 landed into it
<airlied>
since it's a big regression in 23.1
dcz_ has quit [Ping timeout: 480 seconds]
<eric_engestrom>
Hi-Angel: 275cf62e is in staging/23.1 and will be in 23.1.1 :)
<Hi-Angel>
Nice, thanks!
<eric_engestrom>
airlied: ack; marge it by tomorrow morning and i'll make sure I include it
<airlied>
mareko: ^ got time to fast track it?
<eric_engestrom>
mareko: btw the last commit of that MR isn't tagged for backport; just making sure that's not a mistake :)
<eric_engestrom>
(from the commit title it sounds like this was intentional)
<eric_engestrom>
dcbaker: thanks for mentioning the backport tag again, I had forgotten about it (again). it's too late for me to look at it tonight but I'll try to remember tomorrow
Anorelsan has quit [Quit: Leaving]
<daniels>
dj-death: yeah, that was the only MR which had that