<fufexan>
also limitation of what? drm? kernel? drivers? hardware?
ondracka has joined #dri-devel
mehdi-djait3397165695212282475 has quit []
YuGiOhJCJ has quit [Ping timeout: 480 seconds]
mehdi-djait3397165695212282475 has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
amarsh04 has quit []
amarsh04 has joined #dri-devel
f11f12 has joined #dri-devel
lynxeye has joined #dri-devel
Company has joined #dri-devel
kendrafreakon has joined #dri-devel
<kendrafreakon>
Lyude: would someone want to improve the GUD of mesa, have you got enough experience to do that your own?
<kendrafreakon>
FL4SHK[m]: neat point of fpga's is that you would not even need the softcore, which makes them very appealing chips or fabrics.
<kendrafreakon>
anyhow i made so agressive theory and so invasive opener, that years worth of new modern features can be worked on, and getting into fights due to your prone attitude towards that, is only going to ruin the momentum and mood on that path.
<kendrafreakon>
What we know wabout chinese is that they are skilled, but they are not smarter than say scandinavian people combined with our people, they have more humanly resources but towards the end we move closer to full automation, and very smart people handle those things, i would not say finland or estonia lacking such people overall, we have them.
sguddati has joined #dri-devel
kendrafreakon has quit [Remote host closed the connection]
factorymonkey has joined #dri-devel
<stsquad>
digetx: did you manage to replicate the VK_KHR_Display failure?
<factorymonkey>
Every society have leftovers so called birth injured monsters, you are saying to me it's time to make peace or be friends with each other in estonia, but we never were in fight either! That is only 20 people you have heard of from estonia in the world of wank spam, those are the same retards, my lines would openly laugh at them since my lines do all the scoring. Once Ahti Heinla did a
<factorymonkey>
mistake to listen to those , Estonians no longer do any of such mistakes, and now back to chinese, well even in table tennis i suffer a hige injury that hampers my movement , i have not felt my legs to do this, cause of what was done to me, and now the other part, chinese would just come sport bags full of money as well as wire huge amounts of money to buy companies up. We can make new
<factorymonkey>
ones, as to where that money comes from god knows to be exact. But that all says and points europe is not lacking competence. And god sakes i am not lacking any either, i am one of the most famous theoretician from here, i am miles above them with my achievements.
Caterpillar has joined #dri-devel
mripard has joined #dri-devel
mehdi-djait3397165695212282475 has quit [Ping timeout: 480 seconds]
factorymonkey has quit [Remote host closed the connection]
<lucaceresoli>
mripard: hi, I'm back on the DRM hotplug work, dropped all the panel_bridge patches and went back to the drawing board to give the drm_bridge.destroy callback a fresh restart
<lucaceresoli>
mripard: however I'm still trying to make the idea work, and there is something I don't grasp
<lucaceresoli>
mripard: for the panel_bridge the removal actions are, as I can understand from the code: drm_bridge_remove + dem_bridge_put -> am I missing something here?
<mripard>
the removal actions of what component ? panel_bridge itself or a panel_bridge user?
<lucaceresoli>
mripard: the remocal actions of a panel_bridge itself
<lucaceresoli>
mripard: (for hot-unplug, we need to handle the case where the panel is removed but the panel_bridge user stays)
sguddati has quit [Ping timeout: 480 seconds]
ccaione_ has left #dri-devel [#dri-devel]
<lucaceresoli>
mripard: another question is whether you prefer me to drop or keep the debugfs improvement patches from my next iteration
<mripard>
lucaceresoli: then yeah, it looks like the correct sequence
<mripard>
I'm not sure why you need to deal with panel_bridge from the get-go though, but I might miss something
<mripard>
for debugfs, I'd send it as a separate series
<lucaceresoli>
mripard: ah, so that means: drm_bridge_remove is B'3, drm_bridge_put is B'1, and so there is nothing left for the .destroy callback?
<lucaceresoli>
mripard: for debugfs I might postpone then, because the two series will likely conflict and I don't have a real testing setup without the hotplug series
<lucaceresoli>
mripard: the reason I struggle^W have to deal with panel_bridge is mainly devm_drm_of_get_bridge(). It might create a new panel_bridge or not. If it does, someone will have to call drm_bridge_remove for that panel_bridge, but the devm_drm_of_get_bridge() caller cannot know.
<mripard>
but it's not to the caller to call drm_bridge_remove anyway
<lucaceresoli>
mripard: who should do that then? If the panel is not going away, just the user is done with the bridge pointer?
<mripard>
and devm_drm_of_get_bridge() calls devm_drm_panel_bridge_add(), which calls devm_drm_panel_bridge_add_typed(), which registers a devm action that will call drm_bridge_remove()
<mripard>
so it's already dealt with?
<lucaceresoli>
mripard: but the devm action will not trigger if the user is not being removed
<lucaceresoli>
mripard: use case: the user driver is always present, the panel may disappear
<lucaceresoli>
devm_drm_panel_bridge_add_typed() adds a devm action on the user struct device
fab has quit [Quit: fab]
<mripard>
so the problem here is no longer "the lifetime of drm_bridge is broken" but "devm_drm_of_get_bridge() is fundamentally broken and should be replaced "
<mripard>
you need both to deal with hotplug, but they are orthogonal
<lucaceresoli>
mripard: I need both _what_?
<mripard>
you need to fix both problems
<mripard>
but since they are orthogonal, they don't need to be in the same series
<lucaceresoli>
mripard: meaning I need "bridge refcounting" + "replace devm_drm_of_get_bridge"?
rasterman has quit [Quit: Gettin' stinky!]
<lucaceresoli>
mripard: about fixing devm_drm_of_get_bridge, I agree it is broken, but I don't see any obvious solution.
<lucaceresoli>
(sorry in case the last message is duplicated, the matrix bridge does not seem to work very well)
guludo has joined #dri-devel
<lucaceresoli>
mripard: as I see it: some user needs a next_bridge pointer: if it already exists, the get it nd need to put it; if there is a panel they need to create it via *_panel_bridge_add() and later call *_panel_bridge_remove()
<lucaceresoli>
mripard: that's what devm_drm_of_get_bridge() does, and drivers not calling it are doing the same manually, e.g. samsung-dsim.c
<mripard>
lucaceresoli: the solution to devm_drm_of_get_bridge() is to come up with a new, safe, function, deprecate devm_drm_of_get_bridge() and call it a loss
<mripard>
there's no other way really
<lucaceresoli>
mripard: OK. Now what I'm missing is what the new functions should do. My brain failed to find a solution except the panels_always_create_panel_bridge one.
<fufexan>
my bad, my client did an oopsie earlier. what I wanted to ask was: are we allowed to tear the cursor plane while the rest is vsyncd? windows and mac both manage to make the cursor not wait an additional vblank. and also is this a drm/kernel/drivers/hardware limitation?
haaninjo has joined #dri-devel
<mripard>
lucaceresoli: A) it should be drmm and take a reference to the bridge returned. B) when the final reference to panel_bridge is dropped, we call drm_bridge_remove
<mripard>
lucaceresoli: that way you avoid the need for the caller to know if it has to call drm_bridge_remove or not, it'll just have to put the reference just like any other bridge
<lucaceresoli>
mripard: but then this would violate the idea that first of all in C'3 we unpublish the bridge, i.e. drm_bridge_remove()
<mripard>
B3 you mean?
<lucaceresoli>
mripard: yeah, sorry: s/C'3/B'3/
<lucaceresoli>
mripard: so that would mean unpublishing the bridge at the last put, possibly long after the actual B'
<mripard>
yeah, maybe
<mripard>
or maybe your solution to add a bridge to every panel is a good one too, but then we need to start the discussion about how to properly handle the panel lifetimes too, which is another can of worms
<mripard>
I'm not sure it's something we can discuss over IRC, really. Once we have the allocation / reference API mostly figured out, send a proposal for this that works, and we'll go from there
<lucaceresoli>
mripard: what about a conterpart to devm_drm_of_get_bridge() [not sure about the name, maybe devm_drm_of_unget_bridge()?] that does: `if (is_panel_bridge()) {drm_anel_bridge_remove()} else {drm_bridge_put()}`
<lucaceresoli>
mripard: and then the devm_drm_of_get_bridge() kerneldoc will say "to dispose of this bridge poitner before removal, call devm_drm_of_unget_bridge()"
<lucaceresoli>
mripard: ah, no, such a function would not be a totally correct solution. It can know whether the bridge is a panel bridge, not if it was created by the caller
<MrCooper>
fufexan: it's an atomic KMS API limitation
<MrCooper>
many drivers are handling the cursor asynchronously with the legacy cursor ioctl though
<lucaceresoli>
mripard: however it might work if it used a _nowarn version of devm_release_action(): IOW instead of `if (is_panel_bridge())` it would do `if (there is a specific devm action *added by this specific device*)`
luc has quit [Read error: Connection reset by peer]
guludo has quit [Quit: WeeChat 4.5.1]
rasterman has joined #dri-devel
<mripard>
lucaceresoli: devm_drm_of_get_bridge() just cannot work, so any solution that involves it is not the right path
<lucaceresoli>
mripard: so what should a driver looking for "a pointer to the next bridge" do?
<lucaceresoli>
mripard: especially in the case the next bridge is actually a panel, and the panel bridge for it is not yet eisting?
<lucaceresoli>
mripard: open code just like in samsung_dsim_host_attach?
<mripard>
"the solution to devm_drm_of_get_bridge() is to come up with a new, safe, function, deprecate devm_drm_of_get_bridge() and call it a loss"
<sima>
more refcounting maybe too, but it's been a while I smacked my head against this particular wall
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<lucaceresoli>
mripard: sure, I've been trying to imagine the code for that new, safe function, but I'm always circling around the same ideas; any dirty pseudocode proposal would be very welcome and help towards a pragmatic solution
<lucaceresoli>
mripard: do you have in mind a function "just returning a drm_bridge*"?
<lucaceresoli>
mripard: creating a panel_bridge on the fly if a panel is found, just like devm_drm_of_get_bridge()?
<mripard>
lucaceresoli: we already discussed this today
<mripard>
but also, I stand by what I also said earlier, I still think it's too early to discuss it at this point
<mripard>
and I'm sorry, but I won't have time to do that function myself
fab has joined #dri-devel
<lucaceresoli>
mripard: I'll be glad to implement it if I have an idea of how it may be done. But other than creating a panel_bridge on the fly, I don't have ideas of my own.
fab has quit [Ping timeout: 480 seconds]
<mripard>
then do that?
<mripard>
(and I did suggest an alternative at 12:28)
jsa1 has joined #dri-devel
<fufexan>
MrCooper: can you mix legacy and atomic KMS calls though?
<zamundaaa[m]>
fufexan: you can, but I would strongly recommend against it
<zamundaaa[m]>
If you use anything from atomic that legacy can't do, you quickly run into problems
<fufexan>
zamundaaa[m]: well then how do you recommend to solve this problem? we want the cursor updates to be done independently, just like windows and mac can do
<zamundaaa[m]>
fufexan: the only way to fully fix it is to change the atomic API
<zamundaaa[m]>
You can do a lot in userspace too though, by committing only right before vblank
<fufexan>
zamundaaa[m]: is there even a reliable way to do it though, other than guesswork, timing threads, and praying?
<zamundaaa[m]>
No, it's the same as any other time critical task
feaneron has joined #dri-devel
<fufexan>
alright, thank you!
bolson has joined #dri-devel
sally has quit [Quit: sally]
jewins has joined #dri-devel
<MrCooper>
zamundaaa[m]: since drmModeMoveCursor only affects the cursor plane position, not really seeing the big danger
<zamundaaa[m]>
Cursor plane position, and enabling/disabling the cursor plane are dangerous
<zamundaaa[m]>
Hardware rotation on AMD doesn't like the cursor plane being enabled for example
<MrCooper>
it can move the cursor even outside of vblank, resulting in ~1 refresh cycle lower average latency compared to the best case with atomic API
<MrCooper>
zamundaaa[m]: my mutter MR uses only drmModeMoveCursor, everything else still goes through the normal atomic commit machinery
<MrCooper>
even cursor moves fall back to the latter if drmModeMoveCursor fails
<llyyr>
MrCooper: I was mixing legacy and atomic API for about a year because of the amdgpu cursor plane updates issue, and it worked fine until recently when they added the overlay cursor mode. since then, mixing them up completely breaks direct scanout.
<MrCooper>
breaks direct scanout how exactly?
<llyyr>
garbled output
<llyyr>
green artifacts all over your screen if the cursor is visible
<MrCooper>
that uses more than just drmModeMoveCursor
<MrCooper>
that indeed has more potential for issues
<llyyr>
Yeah true, I could try just using drmModeMoveCursor and see if that has issues as well or not
kzd has joined #dri-devel
kts has joined #dri-devel
jfalempe has quit [Quit: jfalempe]
<MrCooper>
anyway, the current atomic API is just unusable for low latency cursor movement
jfalempe has joined #dri-devel
factorymonkey has joined #dri-devel
kts has quit [Remote host closed the connection]
f11f13 has joined #dri-devel
<llyyr>
probably better to improve it on the kernel side in any case than mixing up atomic/legacy
kts has joined #dri-devel
<MrCooper>
not so obvious to me — either it just emulates drmModeMoveCursor, in which case what's the difference?, or it might open up a can of worms in the form of lots of new corner cases
f11f12 has quit [Read error: Connection reset by peer]
<llyyr>
IMO even if it just emulates drmModeMoveCursor underneath it's probably still better purely for ease of use downstream, but I'm not familiar enough to say if there's any technical reasons for/against it.
<MrCooper>
FWIW, my mutter MR calls drmModeMoveCursor only from the KMS thread, i.e. it can't run concurrently with drmModeAtomicCommit
mripard has quit [Quit: WeeChat 4.5.1]
<digetx>
stsquad: it doesn't work with your rootfs, while works with mine arch-based one
<factorymonkey>
You come to harass me 10years in a row at my own territorial legacy, showing your power what you never had and demonstrating your supreme theories, fucking fecalists. Shit your scammers are supreme to me. Shit me not. None ever terrorised you and you still can not perform, i squeeze you do death even being tremendously injured, so for the fucking birth fecalists.
factorymonkey has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
epoch101 has joined #dri-devel
mbrost has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
chamlis has quit [Remote host closed the connection]
guludo has joined #dri-devel
chamlis has joined #dri-devel
epoch101 has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
mbrost_ has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
frankbinns has joined #dri-devel
kts has joined #dri-devel
kts_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts_ has quit []
heat is now known as Guest9145
Guest9145 has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
chewitt has quit [Quit: Zzz..]
chewitt has joined #dri-devel
chewitt has quit []
dsimic is now known as Guest9147
dsimic has joined #dri-devel
Guest9147 has quit [Ping timeout: 480 seconds]
vliaskov has quit [Read error: No route to host]
vliaskov has joined #dri-devel
ondracka has quit []
rasterman has joined #dri-devel
vliaskov_ has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
vliaskov has quit [Ping timeout: 480 seconds]
cyrinux has quit []
cyrinux has joined #dri-devel
amarsh04 has quit []
amarsh04 has joined #dri-devel
jsa1 has quit [Ping timeout: 480 seconds]
coldfeet has quit [Remote host closed the connection]
<fufexan>
hey, is it possible to query the scanline feedback for a crtc via drm? as in get where the display currently is in its scanning out of a buffer
plecra has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
feaneron has quit [Quit: feaneron]
f11f13 has quit []
jfalempe has quit [Quit: jfalempe]
feaneron has joined #dri-devel
iive has joined #dri-devel
jsa1 has joined #dri-devel
Grzesiek11_ has joined #dri-devel
Grzesiek11 has quit [Remote host closed the connection]
coldfeet has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
plecra has quit [Remote host closed the connection]