ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
tzimmermann has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
leon-p has quit [Quit: leaving]
<ishitatsuyuki>
it concerns me how we have a million ways now to configure input sensitivity depending on what compositor one is using
<ishitatsuyuki>
perhaps we should have something similar to wlr-output-management but for xinput configurations?
txtsd has quit [Ping timeout: 480 seconds]
<whot>
ishitatsuyuki: it's unlikely that you'll get gnome to sign up for it
<ishitatsuyuki>
:(
<ishitatsuyuki>
because they're gsettings purist?
leon-p has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
dcz has joined #wayland
leon-p_ has joined #wayland
leon-p has quit [Ping timeout: 480 seconds]
Lyude has quit [Quit: WeeChat 3.2]
Lyude has joined #wayland
<ishitatsuyuki>
whot: actually, why do you think gnome would be reluctant about this?
<whot>
ishitatsuyuki: it's a can of worms that doesn't allow for a good UI. you have a lot of input devices (some of which you never want to expose to the user anyway) and each of those has different settings
<whot>
ishitatsuyuki: on those settings you need different UIs depending on the device, you need to store those settings in some special way so they correctly apply to the various devices lter, etc.
<whot>
ishitatsuyuki: it's a suprisingly difficult thing to do right (esp. with a GUI) and it only improves things very slightly for a lot of effort
<ishitatsuyuki>
whot: are you referring to xinput by "it's a can of worms"?
<ishitatsuyuki>
I guess there are device specific quirks that need handling, but the key value interface should still work decently in practice
<whot>
xinput the commandline tool?
<whot>
xinput is basically an X compatible version of sysfs. You need to know which value you can pipe into which key, with virtually no discoverability and very little feedback if you do it wrong
<whot>
it's powerful, in the same way as echo "foo" > /sys/whatever is powerful
dcz_ has joined #wayland
dcz has quit [Ping timeout: 480 seconds]
<ishitatsuyuki>
fair
leon-p_ has quit []
jgrulich_ has joined #wayland
agners has quit [Read error: Connection reset by peer]
hardening has joined #wayland
pnowack has joined #wayland
danvet has joined #wayland
rgallaispou has joined #wayland
hill has joined #wayland
rasterman has joined #wayland
<romangg>
Is there some DRM way to know when the back buffer for the next vblank has been updated? So not the time the vblank happens, but when (hopefully) before we have updated what comes onto the next front buffer.
<romangg>
My current assumption is I need to measure the rendering time with the graphics API. But maybe there is another way?
<ishitatsuyuki>
sounds like you want explicit sync, but idk
<romangg>
It sounds at least somewhat related.
<romangg>
I need to know that btw in the compositor, not as a client.
<emersion>
i don't understand exactly what you're looking for
<jadahl>
romangg: are you trying to avoid committing non-ready buffers to kms?
<romangg>
jadahl: no, it's for timing/delaying the commit to reduce latency.
<romangg>
need to know how long it took to put the last 1-100 buffers on the screen to make an estimate how much I can delay the next submission.
<jadahl>
romangg: mutter does that, I can link you to the MR that implements it
<romangg>
or not "how long it took to put it on the screen" but "how long it took to be ready to put on the screen".
<emersion>
do you want to measure the time between "buffer ready because rendering is finished" and "buffer programmed into hw so that it'll soon be displayed on screen"?
<romangg>
yes, but also how long the (async) rendering before that needs, what I assume is much longer usually than between "rendering finished" and "programmed into hw so that it'll soon be displayed on screen".
<emersion>
ok, then look at mutter yeah, it does exactly this
<emersion>
it measures the rendering time
<romangg>
Is there a way to know the second?
<emersion>
it doesn't measure the time it takes to program the hw, because that's quick and there's no way to find out rn
<romangg>
ah ok. :)
<emersion>
or maybe with a synchronous kms commit?
<emersion>
would be unfortunate, and maybe would include other things
<romangg>
Quickly looking at the explicit sync protocol would sync fences not also be a (more generic) method to measure the rendering?
<emersion>
fences can help, but could be less precise?
<zzag>
emersion: you can query timestamps though, no? glGetInteger64v(GL_TIMESTAMP, ×tamp);
<emersion>
yes, timestamps with an undefined base
<zzag>
romangg: there is another merge request that kwin take gpu render time into account
<zzag>
that makes kwin*
hendursa1 has joined #wayland
<emersion>
they might be aligned with the CPU clock if you're lucky (iGPU maybe?), but might not
<pq>
zzag, is glGetInteger64v(GL_TIMESTAMP, ×tamp); what you called "cpu timestamp"?
<romangg>
emersion: They are sufficient for measuring time durations though, so I guess if that's what he is doing (comparing a cpu to cpu timestamp with a gpu to gpu timestamp) then it's fine.
<romangg>
zzag: got a link?
<emersion>
yes, as long as you're not mixing apples and bananas it's fine
<emersion>
but zzag said that "start = cpu time" and "end = gpu time"
<pq>
...hence it's important to not call a banana "an apple" ;-)
<emersion>
so "end - start" is an invalid operation
<emersion>
ahah :P
<romangg>
I'm eating a banana and grapes a the moment. So check mate time dimensions!
<zzag>
pq: ah, sorry, I call it "cpu timestamp" because it's the gl time after a specific cpu instruction has been executed
<zzag>
i.e. it's not necessarily CLOCK_MONOTONIC
<pq>
zzag, so it's a gpu timestamp, it is just from an immediate read.
hendursaga has quit [Ping timeout: 480 seconds]
<zzag>
yeah, I guess you could put it that way. it just makes it easier for me to reason about timestamps
<pq>
it confuses the hell out of everyone else :-)
<zzag>
sorry! xD
<zzag>
for clarity sake, maybe a start and an end timer queries can be inserted, but I remember pq saying something about timer queries not working as expected
<pq>
With timestamps, the clock domain is important, and mixing timestamps from different domains is a common mistake and a very easy one to do. What that timestamp corresponds to is another thing. and how it was read is usually less interesting.
<zzag>
maybe start and end*
<pq>
zzag, the thing that does not work is inserting a *fence* at the beginning of a GPU job.
<romangg>
At the moment my assumption is that gl timer queries are the way to go for measuring the rendering time. It's also what the gnome mr does from what I can see.
<romangg>
pq: why is that again?
<pq>
romangg, because some drivers return the fence timestamp for the latest GPU job that did complete, and you didn't give any work to the GPU yet, so who knows what that timestamp is about.
<romangg>
ah, bad drivers! thank you.
<emersion>
submitting a no-op rendering operation might avoid this…
<zzag>
there are a couple of interesting open questions though
<pq>
it's just a piece of API you simply cannot use for one particular thing that would seem like an obvious use case (getting GPU job starting timestamp)
<zzag>
the direct scanout problem is solved by attaching dmabufs to fbos in mutter
<zzag>
another one is the transfer time between gpus
<pq>
zzag, I do not suggest to replacing the immediate GL timestamp read with a timer query. The read is fine (GL time right now). Just don't call it cpu timestamp. :-)
<zzag>
yeah, I will call it "current gl time when compositing starts"
<pq>
yes!
<pq>
I don't know how timer queries work, so I can't say anything about them, particularly the special case of a query without other commands first.
<MrCooper>
pq: a timer query is like a GPU command which records a timestamp, it should work for "GPU finished drawing no later than" even if there are no other pending commands
<pq>
MrCooper, well, I thought the same was obviously true with fences as well, by reading the spec. What stops drivers from optimizing that away? :-)
<pq>
I guess the question is, what does "finished drawing" mean if there is no drawing to be done first.
<MrCooper>
then that command doesn't need to wait for anything before recording the GPU timestamp
<pq>
or maybe it doesn't even query the gpu timestamp at all, just returns the timestamp from the last finished job ages ago?
<pq>
what makes that illegal?
<MrCooper>
it boils down to sampling some GPU registers, not sure what "the last finished job" has to do with it
<pq>
to optimize avay the need to read registers
<MrCooper>
it appears to be working as intended with Mesa and nvidia drivers
<pq>
i.e. to optimize away the need to touch the GPU at all
<pq>
ok
<MrCooper>
I'm afraid you're overthinking this
<pq>
the "begin fence" seemed to work fine on intel too, IIRC
<pq>
I am paranoid about the API guarantees, yes, because being burned before
<MrCooper>
fences are coupled to flushes, timer queries are not
<pq>
and also because gfx drivers are known for bending the rules to get more performance.
hill has quit [Remote host closed the connection]
<pq>
flushing had nothing to do with the fence problem though
<pq>
flushing a command buffer that only contains a "fence command" (which doesn't exist) will then deliver a timestamp from the end of an earlier GPU job that could could be any time in the past, on amd I was told.
<pq>
so no, I do not trust common sense here
<romangg>
zzag: Thanks for the link. I'll likely copy over the libkwineffects changes. Regarding you mentioning direct scanout in the MR: isn't mutter's fbo solution also kind of wasteful? After all the idea of direct scanout is to not wake up the renering infrastructure of the compositor at all.
hill has joined #wayland
<romangg>
jadahl: What do you think?
kennylevinsen has quit [Remote host closed the connection]
<romangg>
I mean the idea itself is cool. But just for measuring the client's rendering being finished doing context switch and all that kind of defeats the purpose of direct scanout, not?
kennylevinsen has joined #wayland
<MrCooper>
what context switch?
kennylevinsen has quit [Remote host closed the connection]
<romangg>
As in to not wake up the compositor rendering pipeline at all.
<romangg>
MrCooper: Ok, thanks. Would you please explain some more why that is?
<MrCooper>
even without caching as in my follow-up MR, the CPU work should be minimal compared to actually compositing, and it saves the GPU compositing work
<romangg>
MrCooper: So all the rendering calls in meta_drm_buffer_gbm_fill_timings are negligible?
<MrCooper>
there are no rendering calls, only the timestamp query
<romangg>
Yea, I meant gl commands. What about cogl_egl_texture_2d_new_from_image?
<romangg>
Inexpensive?
<romangg>
Sorry, not an expert but I like to learn. :)
gryffus has quit [Remote host closed the connection]
gryffus has joined #wayland
zebrag has joined #wayland
gryffus has quit [Remote host closed the connection]
gryffus has joined #wayland
hendursa1 has quit []
hendursaga has joined #wayland
tdeo has quit [Remote host closed the connection]
tdeo has joined #wayland
dvlbr^ has joined #wayland
leon-p has joined #wayland
leon-p_ has quit [Ping timeout: 480 seconds]
pnowack has quit [Quit: pnowack]
autistic has joined #wayland
autistic has left #wayland [#wayland]
papojari[m] has joined #wayland
autistic has joined #wayland
<autistic>
Hello there! I am trying to get my way into wayland code, for fun at first, but I am struggling with wl_display_connect always returning NULL
<autistic>
Then I ended up wondering: am I really running wayland?
<wb9688>
Is $WAYLAND_DISPLAY set?
<autistic>
No, and that´s what got me wondering
<autistic>
I am connected to the machine I´m using for test using xrdp
<autistic>
It should be running wayland
<autistic>
And I´m kinda struggling to get what I might be doing wrong
<wb9688>
Well, xrdp uses X
<autistic>
Ohhh, that explains then
<autistic>
Is there any alternative available using wayland?
pnowack has joined #wayland
<autistic>
I´m connecting from a W10 client, I am currently in a place where I don´t have a Linux environment installed locally
HAL_6900 has joined #wayland
HAL_6900 has left #wayland [#wayland]
jgrulich_ has quit [Ping timeout: 480 seconds]
gryffus_ has joined #wayland
gryffus has quit [Read error: Connection reset by peer]
<danieldg>
autistic: you need a wayland server somewhere to connect to. If that server is remote, you can use waypipe and/or wayvnc
<danieldg>
if W10 only provides an X server (no idea if it does that or not) then you'll need to run a wayland server yourself
FbioPacheco[m] has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
<autistic>
danieldg, it doesn´t, and I don´t want to run it on W10, I just mentioned W10 because the solution must have a client widely available, like in case xrdp, but I will do everything on a Linux machine
<autistic>
I´ll take a look at wayvnc, it seems like VNC must be supported on W10 machines