ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<jekstrand>
karolherbst: That's fair. Without the wrapper object containing a ref, however, we now have to make one at the start of every function call. It's fine for now but maybe not great long-term.
eukara has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
mclasen has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
pcercuei has quit [Quit: dodo]
tzimmermann__ has joined #dri-devel
mhenning has quit [Quit: mhenning]
tzimmermann_ has quit [Ping timeout: 480 seconds]
iive has quit []
jewins has joined #dri-devel
rgallaispou1 has joined #dri-devel
rgallaispou has quit [Ping timeout: 480 seconds]
rgallaispou1 has quit [Read error: Connection reset by peer]
rgallaispou has joined #dri-devel
shankaru has quit []
shankaru has joined #dri-devel
shankaru has quit []
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
camus has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
OftenTimeConsuming has quit []
OftenTimeConsuming has joined #dri-devel
OftenTimeConsuming has quit []
OftenTimeConsuming has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
linearcannon has quit [Read error: Connection reset by peer]
linearcannon has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
gnuiyl has quit [Remote host closed the connection]
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
yogesh_mohan has joined #dri-devel
shashanks has joined #dri-devel
macromorgan has quit [Quit: Leaving]
shashanks has quit [Remote host closed the connection]
shankaru has joined #dri-devel
shashanks has joined #dri-devel
shashanks has quit [Ping timeout: 480 seconds]
ppascher has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
sarnex has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
kts has joined #dri-devel
sarnex has joined #dri-devel
aravind has joined #dri-devel
mszyprow has joined #dri-devel
pnowack has joined #dri-devel
thellstrom has joined #dri-devel
dllud has quit []
dllud has joined #dri-devel
danvet has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.4]
mlankhorst has joined #dri-devel
thellstrom has quit [Quit: thellstrom]
Duke`` has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
tzimmermann__ has quit []
jkrzyszt has joined #dri-devel
frieder has joined #dri-devel
tzimmermann has joined #dri-devel
i-garrison has quit []
Daanct12 has joined #dri-devel
OftenTimeConsuming is now known as Guest1515
OftenTimeConsuming has joined #dri-devel
yogesh_mohan has quit [Quit: WeeChat 2.3]
Guest1515 has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Remote host closed the connection]
kts has quit [Read error: Connection reset by peer]
kts has joined #dri-devel
shashanks has joined #dri-devel
ahajda has joined #dri-devel
mszyprow_ has joined #dri-devel
mszyprow has quit [Read error: Connection reset by peer]
Haaninjo has joined #dri-devel
shashanks has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
Daanct12 has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
jfalempe has joined #dri-devel
MajorBiscuit has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
tursulin has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
sarahwalker has joined #dri-devel
shashanks has joined #dri-devel
lemonzest has joined #dri-devel
mvlad has joined #dri-devel
Daanct12 has joined #dri-devel
lynxeye has joined #dri-devel
kj has joined #dri-devel
slattann has joined #dri-devel
gnuiyl has joined #dri-devel
rasterman has joined #dri-devel
<pq>
columbarius, from who's perspective? Continuous in what address space?
pcercuei has joined #dri-devel
<columbarius>
my perspective is dmabuf transport via pipewire. The attributes per plane are fd, offset, stride and size. My question is if there is some well defined size per plane (eg. in the sense of some linear memory array, or another one) or if it should just be documented to never touch this wrt. dmabufs
<pq>
Those concepts are defined as if the memory was a single linear chunk, but why would you modify those in pipewire?
<columbarius>
i don't modify them, pipewire has some metadata attached to a buffer. The question is what the instance allocating the buffers should fill in there
<pq>
The correct values of course... I don't think I understand the question.
<columbarius>
ok rephrased: gbm won't tell me the size of a specific plane. and it only needs strides and offsets (+dimentions) for import, same es opengl
<pq>
ah
frankbinns has joined #dri-devel
sarahwalker has quit [Remote host closed the connection]
frankbinns1 has joined #dri-devel
<columbarius>
is there some reason to (by some other means i don't know) to query it, or should the documentation should just say leave it empty
sarahwalker has joined #dri-devel
frankbinns1 has quit []
<pq>
sorry, leave what empty? If that is pipewire API, then I have no idea. But I'm looking at GBM API now.
<columbarius>
the size property
<columbarius>
PipeWire will only pass that value to the other clients, no logic done on it
<pq>
sounds like pipewire API docs should say something about those other clients can use the value
<pq>
anyway, you can get an approximation as height * stride in bytes
<pq>
the allocated size will definitely not be smaller than that, but it might be bigger
<pq>
*say something about HOW those other clients can use the value
<columbarius>
even when modifier planes are used (compression, eg.) and not "color" ones like luma, etc.?
<columbarius>
The HOW is what i want to document ;) For shm it's clear but for dmabufs I just wanted to ask if there is a difference
<pq>
I would assume so, but then again, compression e.g. planes are not something one would peek into anyway, so their true size is kinda irrelevant
<pq>
btw. when you have a dmabuf fd, you can use stat functions to get the file size. That should be the total size of the dmabuf, I think.
<pq>
ah, hm, well... I can't think of any use for the size per se. The one thing it can be used is to check all the other paramters are within bounds, but then you would stat the dmabuf fd to find the real size and not trust the sender.
<columbarius>
ok so the gist is: When all fds are mapped the size is the usual stride * height, when the modifier is linear each plane is it's canonic size like it would for shm buffers and if modifiers are used the size of a plane is sth. complicated depending on hardware stuff and nobody sane should touch it?
<daniels>
columbarius: you can get the size of a dmabuf by seeing what you get from seeking to SEEK_END
<mlankhorst>
Yeah, that's deliberately implemented for that
<pq>
The seek pointer is a file description property, so other processes can mess with it if the fd is shared.
<pq>
Doesn't statting the df not work?
<pq>
*fd
<columbarius>
daniels: thanks
<daniels>
pq: the use for the size is so you can mmap() it; modifier-aware users should obviously be able to calculate the relevant size themselves, but yeah
<pq>
columbarius, yeah... though even in the same of non-linear modifiers, the stride * height probably should work out, but that I'm less sure of.
<daniels>
the lseek trick only works if you assume that no-one's trying to read() or write() the dmabuf fd, and ... fine, don't ever do that
<pq>
*in the case
<pq>
daniels, until someone does and produces a totally msyterious bug report in a completely unrelated component. :-P
<columbarius>
so my intention was to just document, that clients should just ignore the size of a plane and the one allocating should just be allowed to set it to 0, since it is not realy relevant. Is this reasonable, since if someone realy want's to mess with individual planes they probably have other means to get those values.
<pq>
daniels, asking in another way, is there any reason to use seek instead of stat?
rkanwal has joined #dri-devel
<daniels>
pq: no idea, just that Mesa uses lseek() exclusively so it's what I'm familiar with, heh
<pq>
columbarius, I don't have any argument against that.
<daniels>
columbarius: yeah, I think that's a good resolution - just pass width + height + format + modifier + {fd,stride,offset}[num_planes] - as the only meaningful value, anyone who needs to derive size for mmap can do so locally
tanty has quit [Remote host closed the connection]
tanty has joined #dri-devel
rkanwal1 has joined #dri-devel
rkanwal has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
<columbarius>
ok thanks
<MrCooper>
pq: height needs to be aligned to the tile height as well
JohnnyonFlame has joined #dri-devel
<pq>
MrCooper, if you gbm_bo_alloc, you have to use gbm_bo_get_height() and not trust the height you put in? But then, the image content is not that high? So how does that work?
<MrCooper>
it requires knowledge of the tile height
<pq>
just "understand that modifier"? But you probably got that modifier from somewhere else, did not choose it yourself.
<MrCooper>
I'd expect gbm_bo_get_height() to return the original height, not the one aligned to tile height?
<pq>
yes, that makes more sense
<pq>
ah, but the size is irrelevant unless you intend to mmap the dmabuf directly, and then you have to understand the modifier anyway
<MrCooper>
yep
rkanwal has joined #dri-devel
rkanwal1 has quit [Read error: Connection reset by peer]
kts has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
ahajda has quit [Read error: Connection reset by peer]
tanty has quit []
MajorBiscuit has quit [Ping timeout: 480 seconds]
tanty has joined #dri-devel
tanty has quit []
tanty has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
rkanwal1 has joined #dri-devel
rkanwal has quit [Read error: Connection reset by peer]
<daniels>
++
kts has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
sarahwalker is now known as Guest1532
rkanwal1 has quit []
rkanwal has joined #dri-devel
pcercuei has quit [Ping timeout: 480 seconds]
shashanks has quit [Remote host closed the connection]
shashanks has joined #dri-devel
<pq>
mripard, for half a dozen times I tried to send https://gitlab.freedesktop.org/-/snippets/4819 to the mailing list, and gmail refuses it without explanation. So here's to you at least.
kts has joined #dri-devel
Daanct12 has quit [Quit: Quit]
shashanks has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
Daanct12 has quit [Quit: Quit]
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
shashanks has joined #dri-devel
tzimmermann has joined #dri-devel
March-123 has joined #dri-devel
mszyprow_ has quit [Remote host closed the connection]
<robertfoss>
pinchartl:having a look
<pinchartl>
robertfoss: thanks
<mripard>
pq: thanks
linearcannon has quit [Remote host closed the connection]
<pq>
mripard, maybe I'll try to send it again tomorrow, in case it's a temporary failure
<mripard>
pq: I think part of the issue is that the internal pipeline of vc4 doesn't carry the alpha once the composition has been done, so it will fill X with either 0xff or 0x00, but that would ignore whatever was in the input buffer
<mripard>
so if we use a random value for X, we'll have the same issue: the hashes won't match and we will not get the test to pass
<mripard>
while the frame is entirely correct if we were to ignore X
<pq>
mripard, no no. X must always be ignored, both by KMS *and* by IGT image comparisons.
<mripard>
ok, so I guess that was my question :)
<mripard>
it was my initial thought as well, but I wasn't sure if I was overlooking something that would create some side effect somewhere
<pq>
seeding X channel with random garbage is just to make sure the compositor result does not depend on any specific value in it.
<pq>
*composited
kts has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
linearcannon has joined #dri-devel
fxkamd has joined #dri-devel
ahajda has joined #dri-devel
<robertfoss>
pinchartl, airlied, danvet: I'd like to revert an anx7625 series
<pinchartl>
I'm sorry to have caught the issue so late
mbrost has joined #dri-devel
<robertfoss>
I'm having a real not good time trying to create revert patches, since other things have landed ontop of this.
<robertfoss>
Is reverting the DT change + the commit that depends on it an option?
<robertfoss>
Then we can clean up the anx7625 usage of V4L2_FWNODE_BUS_TYPE_PARALLEL for the next kernel version?
<pinchartl>
if you're confident it won't break the rest, that's fine with me
<pinchartl>
(I don't really care personally if it breaks something else in the driver, as I'm not using it, but it's still not a good idea :-))
<robertfoss>
I could also intentionally disable+remove the code that interacts with the V4L2_FWNODE_BUS_TYPE_PARALLEL flags, so that it never is a part of the ABI
camus has joined #dri-devel
<pinchartl>
I'd feel better if you could at least revert the DT bindings
<robertfoss>
definitely reverting the dt bindings, but is there any point to doing the above to?
camus1 has quit [Ping timeout: 480 seconds]
<pinchartl>
that would work for me, but I'm not sure how easier/cleaner it would be
<pq>
mripard, btw. you would never compare input FB crc to writeback crc, right? You'd compare writeback crc to another writeback crc with a different KMS configuration but the same expected end result.
sdutt has joined #dri-devel
<mripard>
pq: that's what IGT is doing in its writeback test (and chamelium)
<mripard>
and it does have value, to make sure that the pipeline is somewhat working
<pq>
which one? :-)
<mripard>
a broken pipeline would be consistent :)
<mripard>
writeback-check-output
<pq>
yes, that is true, but then you shouldn't be comparing crc but actual pixels
rkanwal has quit [Read error: Connection reset by peer]
rkanwal has joined #dri-devel
Viciouss has quit [Remote host closed the connection]
Viciouss has joined #dri-devel
JohnnyonFlame has joined #dri-devel
frieder has quit [Remote host closed the connection]
March-123 has quit [Remote host closed the connection]
March-123 has joined #dri-devel
shankaru has quit [Quit: Leaving.]
Guest1088 has left #dri-devel [#dri-devel]
ajax has joined #dri-devel
<ajax>
ngh. we don't have _any_ test coverage of swr in ci, do we.
March-123 has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
RSpliet has quit [Quit: Bye bye man, bye bye]
MajorBiscuit has joined #dri-devel
RSpliet has joined #dri-devel
Duke`` has joined #dri-devel
March-123 has joined #dri-devel
nchery has joined #dri-devel
shankaru has joined #dri-devel
slattann has quit []
March-123 has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
gawin has quit [Ping timeout: 480 seconds]
adjtm has quit [Remote host closed the connection]
rkanwal has quit [Quit: rkanwal]
rkanwal has joined #dri-devel
adjtm has joined #dri-devel
<kbingham>
dianders, I'm puzzled about some of the conversion to drm_err() while looking through the sn65dsi86 and updating the IRQ/HPD series.
rgallaispou has quit [Read error: Connection reset by peer]
<kbingham>
For instance, in ti_sn_bridge_attach, there is a usage of drm_err(bridge->dev, "Failed to register DP AUX channel: %d\n", ret); ... but this prints "[ 2.572620] rcar-du feb00000.display: [drm] *ERROR* FAKE Failed to register DP AUX channel: 0" (sorry , the FAKE is because I duplicated the line outside of the conditional to make it print)
<kbingham>
A dev_err against the TI sn65dsi86 device would print "[ 2.577489] ti_sn65dsi86 1-002c: FAKE: From 'pdata->bridge.dev'"
<kbingham>
Isn't the report with drm_err() misleading if it ends up looking like it comes from the display driver, rather than the bridge?
slattann has joined #dri-devel
<kbingham>
Other references with "DRM_DEV_ERROR" use "DRM_DEV_ERROR(pdata->dev," ... this would give the correct device print, and reference the SN65DSI86 I beleive, but if it were converted to use drm_err( (struct drm_device) ...) ... which device would you expect to be passed in ?
Guest1532 has quit [Ping timeout: 480 seconds]
<vsyrjala>
i would expect to see the top level device (pci devfn/equivalent for other bus types). with that you can actually filter the debug output based on the device
<kbingham>
vsyrjala, I'm sorry, I'm not sure I understand your statement. By top level device, are you meaning you /would/ expect to see the rcar_du display driver as the leading device for the failure ?
<vsyrjala>
yes
<kbingham>
Doesn't that make it look like the error is being generated in a different component/module?
<vsyrjala>
if you need to identify some sub-device then imo that should be printed in addition to the top level device id
aravind has quit [Ping timeout: 480 seconds]
<dianders>
kbingham: Probably it should have been converted to just dev_err() then. I'd definitely be happy with a patch to fix it! I
camus1 has joined #dri-devel
rkanwal has quit [Ping timeout: 480 seconds]
<kbingham>
Ok- I'm happy enough with dev_err() as that states the actual device with the failure, but now that contests with vsyrjala's statement above :-(
<javierm>
kbingham: you could also have two printouts. If is important enough to warrant an error message, it could be made more verbose
<dianders>
kbingham: this is why the comments for DRM_DEV_ERROR() say `this is deprecated in favor of drm_err() or dev_err()`. As far as I could tell there were places where we really didn't have a good drm dev.
<kbingham>
dianders, Aha, ok - I'd missed that part, and I thought your request was to move to drm_xxx only.
<kbingham>
Certainly in part of the probes, we don't even have the drm_device yet, so it's not even possible. But I'm not even sure where drm_xxx() would make sense in the bridge driver at all.
camus has quit [Ping timeout: 480 seconds]
<dianders>
kbingham: :-) Yeah, I think only the SHOUTING ones are deprecated. I actually don't have a great instinct for when we have a reasonable "drm dev" vs not. I may have picked drm_xxx instead of dev_xxx incorrectly in the past. :( I mostly was just trying for consistency. I wrote the documentation patch when I was told by one person to switch from DRM_DEV_ERROR to dev_err and a different person to swtich from dev_err to DRM_DEV_ERROR.
<kbingham>
dianders, Ok thanks, that clears up my path anyway.
lynxeye has quit []
MajorBiscuit has quit [Ping timeout: 480 seconds]
<wens>
robertfoss, pinchartl: Thanks! My previous inquiries on the DT patch went unanswered.
iive has joined #dri-devel
slattann has quit []
tpalli has quit [Remote host closed the connection]
mhenning has joined #dri-devel
idr has joined #dri-devel
ybogdano has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
i-garrison has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.4]
nchery has joined #dri-devel
tjaalton has quit [Remote host closed the connection]
rkanwal has joined #dri-devel
gouchi has joined #dri-devel
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
simon-perretta-img_ has joined #dri-devel
i-garrison has quit [Read error: Connection reset by peer]
simon-perretta-img_ has quit []
simon-perretta-img_ has joined #dri-devel
i-garrison has joined #dri-devel
simon-perretta-img is now known as Guest1550
simon-perretta-img_ is now known as simon-perretta-img
Guest1550 has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Quit: Leaving]
simon-perretta-img has joined #dri-devel
shankaru1 has joined #dri-devel
shankaru has quit [Ping timeout: 480 seconds]
<robclark>
danvet: so dianders and I were chatting about system suspend.. afaict the drm/sched kthread is not freezable, unless I'm overlooking something.. which means it could race with pm_runtime_force_suspend().. am I missing something or have we all just been lucky(ish) so far?
<robclark>
how does that not explode badly?
<danvet>
robclark, maybe?
<danvet>
I guess you're supposed to call drm_sched_stop/start yourself somewhere?
<danvet>
ofc not for runtime pm :-)
<robclark>
hmm, I guess we should be doing that in the force_suspend path.. but doesn't look like anyone actually is
<robclark>
we apparently need better suspend/resume test, I guess
macromorgan has joined #dri-devel
FireBurn has quit [Quit: Konversation terminated!]
jkrzyszt has quit [Ping timeout: 480 seconds]
shankaru1 has quit []
Haaninjo has quit [Quit: Ex-Chat]
Haaninjo has joined #dri-devel
March-123 has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
rkanwal has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
March-123 has quit [Ping timeout: 480 seconds]
natto has joined #dri-devel
shashanks has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
camus has quit [Ping timeout: 480 seconds]
adavy has joined #dri-devel
nchery has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
nchery is now known as Guest1558
Guest1558 has quit [Read error: Connection reset by peer]
nchery has joined #dri-devel
gouchi has quit [Remote host closed the connection]
rasterman has joined #dri-devel
kts has quit [Read error: Connection reset by peer]
kts has joined #dri-devel
ybogdano has quit [Remote host closed the connection]
nchery has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
pnowack has quit [Quit: pnowack]
mhenning has quit [Quit: mhenning]
mvlad has quit [Remote host closed the connection]
nchery has quit [Read error: Connection reset by peer]