toolchains has quit [Remote host closed the connection]
frankbinns has joined #dri-devel
nvishwa1 has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
toolchains has joined #dri-devel
jkrzyszt has joined #dri-devel
nvishwa1_ has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
MrCooper has joined #dri-devel
lynxeye has joined #dri-devel
rasterman has joined #dri-devel
MajorBiscuit has joined #dri-devel
<pq>
danvet, emersion, nope, I didn't reach conclusion with zackr on the virtual cursor UAPI, and I don't think there is anything more I can say for now than what I just replied. I'm already repeating myself.
wv has quit []
wv has joined #dri-devel
<danvet>
pq, ok I'll try to come up with some kind of summary
gawin has quit [Ping timeout: 480 seconds]
<emersion>
i fully agree with pq fwiw
<emersion>
and also some of the existing properties are really lacking docs…
<emersion>
like, in what coordinate space is suggested_x/y?
<jadahl>
suggest_x/y is incompatible with todays compositors
<pq>
I never noticed suggested_x even exists.
<danvet>
yeah I have no idea what this does
pcercuei has joined #dri-devel
wv has quit []
<jadahl>
they are set by vm drivers to position virtual monitors so they "match" how they are placed on the viewing system
wvanhauwaert has joined #dri-devel
<emersion>
jadahl: how incompatible?
<jadahl>
so that if you have one next to the other when viewing, they are placed the same way in the virtualized system
<jadahl>
emersion: coordinate system incompatibilities
<jadahl>
they assume the X like coordinate system
<emersion>
so physical pixels?
<jadahl>
yes
<jadahl>
so falls apart with weston/wlroots/mutter+fractional-scaling=on
<emersion>
i wonder, could user-space convert to logical pixels?
<jadahl>
for trivial setups yes, for non-trivial no
<jadahl>
there can be overlaps etc
<emersion>
yeah, that doesn't really work in the general case
<emersion>
at some point VM will likely want to relay scale as well…
<emersion>
reinventing Wayland on top of KMS
<jadahl>
so add a cursor plae scale property? :P
<danvet>
emersion, imma seriously going to stop folks if they try to pass more than primary + funny cursor through kms for virtual setups
<danvet>
that really stops making any kind of sense
<emersion>
yeah… KMS is good to have as a baseline, but for fancy stuff a proper separate protocol like RDP is really the proper solution
<jadahl>
KMS for VMs for testing is IMO a very good use case, but for actual remote access to production desktop envs it's not
<jadahl>
and arguably, only the latter needs things like suggested_x/y
camus has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
<pq>
I'd be happy to see all those comments poured into the email thread ;-)
<jadahl>
pq: I sent one email with my opinions a few minutes ago
<pq>
thanks!
<jadahl>
to summarize, i think emersion's suggestion sounds most sane
<jadahl>
not going to bring up suggested_x/y...
Haaninjo has joined #dri-devel
<danvet>
pq, emersion jadahl I replied with a top post fairly high up in the thread
<pq>
jadahl, wait, Simon suggested *what*?
<danvet>
jadahl, I think you're not on cc there, holler if you need me to bounce it
<danvet>
the one thing I've left open is putting down some suggestion for how far this virtualized kms business goes and when it should definitely be RDP instead
<jadahl>
pq: a client cap, if not set, no cursor plane, if set, cursor plane has no x/y but has hotspot_x/y
<danvet>
yeah that part we need
<danvet>
oh I didn't include the "no x/y" part
<danvet>
that makes a lot of sense to do
<danvet>
since there really is no x/y
<jadahl>
right
<pq>
jadahl, I completely missed the removal of CRTC_X/Y in that before, but seems ok.
<pq>
but I also believe there is no need to hide cursor planes completely ever, if they honour CRTC_X/Y when not in commandeer-mode
<jadahl>
danvet's name for the client cap is better though :P
<danvet>
pq, I think the problem is there is no non-commandeer mode
<pq>
danvet, the non-commandeer-mode is the default.
<danvet>
pq, how does that work?
<danvet>
like hotspot_x/y == 0 means non-commandeer mode
<emersion>
pq: right, VM drivers could still advertise them and manually blend them onto the primary plane
<pq>
danvet, the driver honors CRTC_X/Y just like all hardware drivers do, too.
<emersion>
basically doing what the compositor would do without a cursor plane
<danvet>
imo that's a bit silly
<emersion>
yeah…
<emersion>
advertising support for something you don't really support
guptasa2_ has quit [Ping timeout: 480 seconds]
<emersion>
plus it'd be very tempting to just do more crazy heuristics breaking the uAPI contract…
<pq>
moving a cursor without changing anything else is a very frequent operation, so even if a VM viewer needs to composite the cursor image itself into the desktop image, it's still less data to send over network.
<danvet>
emersion, should I reply to my mail with your suggestion that these planes also must not have CRTC_X/Y?
<danvet>
or will you
<jadahl>
in emersions suggestion, you wouldn't introduce DRM_PLANE_TYPE_VIRTUAL_CURSOR but change the bahior of DRM_PLANE_TYPE_CURSOR
<danvet>
pq, they all have damage support
<pq>
danvet, even with pixel-precise damage support.
<danvet>
pq, yeah but cursors are small :-)
<emersion>
jadahl: yeah, but i don't mind an explicit separate plane type
<jadahl>
yea, would work too
<pq>
coordinates are much smaller than a 1-pixel edge of a cursor
saurabhg has joined #dri-devel
<pq>
but now we are all in the weeds again, talking about UAPI details
<pq>
My point is that the VM stack needs to know whether it is allowed to commandeer a cursor plane (if one exists), or not. I don't understand why that is controversial.
<danvet>
pq, I agree on that, but I think folks simply didn't bother to make the non-commandeered version work
<pq>
who folks?
<danvet>
the vm folks
<pq>
yeah
<danvet>
like this started for Xorg, and Xorg really only ever uses the cursor for cursor
<danvet>
and then always commandeering is "fine"
<pq>
right, and that's my first problem
<danvet>
ofc breaks at the edges, hence hotspot and I guess whatever that suggested property does
gawin has joined #dri-devel
<danvet>
pq, yup, that's why I put "we need to hide this non-plane cursors" in
<danvet>
for legacy cursor it was kinda ok, but not for universal planes
<pq>
cool
<danvet>
because it's just not a universal plane really
<danvet>
also, those two patches should be backported to all stable kernels
<danvet>
since all virtualized aware compositors refuse to use atomic/universal planes on these right now anyway there's not going to be a regression for them
<danvet>
but it does fix the busted uapi for everyone else
<danvet>
I also put "document everything around virtualized kms" as the 3rd thing to do
<pq>
thank you :-)
<jadahl>
just make sure that suggested_x/y is documented as problematic ..
<danvet>
hm maybe I should put in a request for a demo-style igt (we can do that with interactive testing breakpoints) to demonstrate these flows
mbrost__ has joined #dri-devel
<danvet>
jadahl, I'll let you folks bikeshed the docs to full glory :-)
<danvet>
I did include that the docs should explain how the user experience detoriates/changes if a compositor doesn't do this stuff
<emersion>
i think jadahl is talking about the suggested_x/y shortcomings
<emersion>
ie, it being incompatible with compositors
<jadahl>
iirc what mutter does is look at suggested-x/y, sees if it works, and if it didn't ignore it
<emersion>
how do you "see if it works"?
apinheiro has joined #dri-devel
<danvet>
jadahl, yeah what is suggested x/y supposed to do?
<danvet>
oh so just some offset in the framebuffer to make things easier for the vm?
<jadahl>
well, whether it's an offset in some framebuffer is a different question
<emersion>
it's for multi-output support
<jadahl>
in mutter each monitor has its own framebuffer
<jadahl>
right
<jadahl>
it's the layout of multiple monitors in the global display server coordinate space
<emersion>
place one output to the right of another for instance
<pq>
danvet, imagine you have two VM viewer windows on your screen, both going to the same guest desktop in the same VM, acting as two (extended) outputs for the one desktop.
<danvet>
oh
<pq>
...is what I understood, could be completely off
<jadahl>
no thats correct
<danvet>
well that sounds really silly
<pq>
lol
<emersion>
i don't even know how the VM viewer knows how to configure the outputs
<jadahl>
emersion: x11
<emersion>
right :P
<pq>
emersion, X11 tells you the viewer window positions, duh!
<jadahl>
at one point there were requests in w-p to get information that one windows position relative to another to get this working withotu x11
<danvet>
ah we can blame this beauty on airlied
<danvet>
so you can like resize and zoom your windows around and you see different parts of the desktop?
<danvet>
(if the compositor doesn't react to the hotplug events)
<jadahl>
danvet: it's not about resizing. resizing is just new modes isn't it
<pq>
oh, I never thought of that, that's.... "interesting"
<jadahl>
it's about that one viewer window's position relative to another, so that in the X server /wayland compositor the virtual monitors have similar positions
<danvet>
pq, I'm just trying to imagine how much you're tripping when you do that a few levels deep
<danvet>
probably a bit like a caleidoscope or so
<danvet>
jadahl, I think pq got what I mean
<jadahl>
what you talk about sounds like the xorg panning thing
<danvet>
jadahl, yeah
<pq>
panning, yeah
<pq>
panning controlled by the viewer window position in the host winsys
<jadahl>
i don't think that what it's used for generally
<emersion>
so, when do we add support for arbitrary window rotation in addition to panning?
<jadahl>
i've fixed enough panning related bugs already, no more please
<emersion>
weston can rotate windows, i don't see why this shouldn't rotate the view inside the VM viewer
<jadahl>
we need KMS fire API too so we can burn windows via KMS
<linkmauve>
I want my wiimote-controlled cursor to rotate the same way it did on the Wii!
<danvet>
emersion, 45° windows ftw
<jadahl>
linkmauve: it should be stereo too so that it can be really in front of the monitor!
<linkmauve>
Yes!
<emersion>
i had a project to put an accelerometer on my monitor to auto-rotate windows in sync with the monitor
<emersion>
never got it done sadly
<linkmauve>
I even have a series for Weston which needs to be rebased now that atomic got merged in, five years ago.
<danvet>
jadahl, pq emersion I think in that doc section we need a paragraph "this is it! use RDP if you need anything more. Really."
<linkmauve>
emersion, you could start with mobile hardware, which already have accelerometers and gyroscopes and such!
Haaninjo has quit [Quit: Ex-Chat]
<pq>
danvet, +1
pjakobsson_ is now known as pjakobsson
<danvet>
emersion, so looks like greg didn't reply, I guess kernel version check it officially is
<danvet>
disappointing, but oh well
<javierm>
danvet: how that would work for distros LTS kernels ?
<emersion>
danvet, yep, i've just sent an email mentionning this
jagan_ has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
<emersion>
and yeah i've implemented the kernel version check
srslypascal has joined #dri-devel
tursulin has quit [Quit: Konversation terminated!]
<danvet>
javierm, the kernel version check?
<javierm>
danvet: yes, since you may have a different kernel version but backport the support
<danvet>
javierm, yeah then you just don't get the added cool feature
<danvet>
sucks, but oh well
<danvet>
as long as you don't rip it out it should be all fine
<javierm>
danvet: yeah
saurabhg has quit [Ping timeout: 480 seconds]
<airlied>
danvet, emersion I still think just having a drm cap is better
mclasen has joined #dri-devel
<danvet>
airlied, that's what I put down in my summary/proposed plan
<danvet>
airlied, plus actual docs for all this stuff
<danvet>
mripard, I'll try to come up with some coherent thoughts on drmm vs devm for bridges
<danvet>
just seen your patch set iow
<mripard>
danvet: thanks :) I'll send a patch to add it to the todo items so that we keep track of it
<mripard>
and yeah, the discussion was related to that massive vc4 series
<danvet>
uh geez is the existing devm vs drmm a mess around bridges
mclasen_ has joined #dri-devel
<mripard>
I wouldn't say a mess, but our current solution indeed doesn't address the bridges
Daanct12 has joined #dri-devel
srslypascal has quit [Ping timeout: 480 seconds]
mclasen has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
heat has joined #dri-devel
tursulin has joined #dri-devel
devilhorns has joined #dri-devel
dviola has quit [Ping timeout: 480 seconds]
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
toolchains has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Quit: WeeChat 3.5]
<emersion>
vk question: what is a good way to "duplicate" a VkFence?
<bnieuwenhuizen>
export to sync file and import twice?
<bnieuwenhuizen>
not sure I know of another way
mbrost__ has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
MajorBiscuit has quit [Quit: WeeChat 3.5]
bmodem has quit [Ping timeout: 480 seconds]
<jani>
daniels: is there any way to prevent people from filing "confidential" issues or adding "internal" replies to issues in gitlab? people seem to have optimistic misconceptions about how confidential or internal those really are
<emersion>
ok, thx
icecream95 has quit [Quit: rcirc on GNU Emacs 28.1]
hansg has joined #dri-devel
dviola has joined #dri-devel
MajorBiscuit has joined #dri-devel
technopoirot has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has quit [Remote host closed the connection]