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
lxsameer has quit [Ping timeout: 480 seconds]
Moprius has quit [Quit: Konversation terminated!]
Company has quit [Quit: Leaving]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
maxzor has joined #wayland
floof58 is now known as Guest137
floof58 has joined #wayland
Guest137 has quit [Ping timeout: 480 seconds]
cvmn has joined #wayland
duxsco has quit [Quit: duxsco]
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
duxsco has joined #wayland
zebrag has quit [Quit: Konversation terminated!]
duxsco has quit [Quit: duxsco]
maxzor has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #wayland
tlwoerner has quit [Remote host closed the connection]
dcz_ has joined #wayland
tlwoerner has joined #wayland
danvet has joined #wayland
CodeSpelunker has joined #wayland
rv1sr has joined #wayland
jgrulich has joined #wayland
hardening has joined #wayland
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #wayland
eroux has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
eroux has joined #wayland
eroux has quit []
eroux has joined #wayland
jgrulich has quit [Remote host closed the connection]
CodeSpelunker has quit [Quit: CodeSpelunker]
vyivel has quit [Read error: Connection reset by peer]
vyivel has joined #wayland
reillybrogan has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
reillybrogan has joined #wayland
ppascher has quit [Quit: Gateway shutdown]
caveman has quit [Ping timeout: 480 seconds]
jgrulich has joined #wayland
lxsameer has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
jgrulich has quit [Remote host closed the connection]
<wlb>
wayland.freedesktop.org Merge request !5 closed (Simplify and update the wayland.fd.o index page)
caveman has joined #wayland
<emersion>
i wonder what it would take to automate this
<emersion>
hm i guess do like libinput?
<pq>
I guess so
<pq>
the reason it wasn't done a long long time ago was that there was some wrinkle in gitlab that it wasn't reliable, but I guess that got fixed a long time ago too?
<emersion>
there are still reliability issues
<pq>
mmh
jgrulich has joined #wayland
<pq>
ideally the docbook would be published from the wayland repository gitlab pages...
<emersion>
not really possible
<pq>
why?
cvmn has quit [Ping timeout: 480 seconds]
<emersion>
the job has to run in the wayland.freedesktop.org repo
<pq>
why?
jmabr has joined #wayland
<emersion>
i don't know
<emersion>
it seems like pages deploy is triggered with a magical "deploy" step with a magical "public" artifact
<emersion>
talk about implicit behavior
<emersion>
ofc can't find docs, can only find "copy the template" guides
<emersion>
i don't feel like breaking all links to docs
<emersion>
just because of some gitlab limitation
<pq>
and I suppose redirects in wayland.freedesktop.org just don't work because Gitlab?
duxsco has joined #wayland
<emersion>
even with a 💩 <meta> redirect, anchors would be lost
<pq>
I feel it's silly to have to keep a copy of the generated HTML in a git repo to begin with. We are not keeping a history of all docs per release like libinput does.
<emersion>
yes, i agree
<pq>
so yeah, trade-offs
<emersion>
but it's not necessary to move the CI job to the wayland repo to fix this
<pq>
no, if the wayland repo will trigger jobs in the www repo, which is hacky in itself to do?
<emersion>
what daniels suggested iirc is to add a job in the wayland.fdo repo to pull/build the wayland docs
<emersion>
yeah, that
<pq>
that's also what libinput does, right?
<emersion>
it's hacky on the inside, but at least the outside (users) don't see the hackyness in any visible way (no redirect)
<emersion>
also it would only happen during a release
<pq>
oh, only for releases, that seems better
<pq>
then it's not prone to fail on every MR merge and you'll be there hand-holding it if it does fail
<emersion>
yup
<emersion>
i don't think we want to publish docs for unreleased wayland patches?
<emersion>
or i am missing something?
<emersion>
am i*
<pq>
don't we? They are accepted and merged and sans reverts, they will also be released.
<LaserEyess>
I have sort of a pedanctic question about what constitutes "a copy" for a compositor, let's assume I have a surface that's on the GPU, and using dmabuf to pass the buffer so it's direct scanout
<LaserEyess>
so here there are no copies, neither CPU->GPU copies nor GPU->GPU copies
<LaserEyess>
but then I have an overlay for that surface, as a subsurface, but it's rendered on the CPU via wlshm
<LaserEyess>
so, obviously, a CPU->GPU copy is needed
<LaserEyess>
but if that subsurface, once uploaded to the GPU, is able to be put on a separate overlay plane, does it *also* require a GPU->GPU copy?
<pq>
a "copy" is any memory-to-memory operation, I'd say
<emersion>
yes. and then a GPU→GPU copy to blend it to the final buffer
<LaserEyess>
ok so that is now two copies
<emersion>
ah, in general the uploaded surface can't be put in a KMS plane
<LaserEyess>
why not?
<emersion>
it's just a GL texture
<pq>
GL textures generally are not scanout-able
<LaserEyess>
hm
<pq>
I mean, if they are created as "just a normal GL texture"
<pq>
like with glTexImage2D
<pq>
(glTexImage2D in itself is at least one copy, likely two)
<LaserEyess>
so the compositor does this internally to the wlshm buffer, and then also needs to do a copy for the final compositing step
<pq>
yup
<LaserEyess>
ok, that at least makes sense
<pq>
lotsa copies
<pq>
One might even say that GL textures are not really exportable even, not in a useful way, so no exporting of a GL texture to be imported to KMS for direct scanout.
<pq>
dmabuf handle OTOH is already exported and can be imported with various APIs, like EGL and KMS.
<pq>
import and export are not copies (in a useful implementation), they are merely creating and using handles into the underlying storage
jgrulich has quit [Remote host closed the connection]
zebrag has joined #wayland
jgrulich has joined #wayland
erc_ has quit [Ping timeout: 480 seconds]
<LaserEyess>
guess subtitle users with mpv are just gonna have to deal with it
<LaserEyess>
that or libass is re-written to render on the GPU
<emersion>
a compositor could choose to copy wl_shm buffers to a GBM buffer
<pq>
or, you blit the sub-titles with OpenGL or Vulkan. Like mpv already does when it burns sub-titles into an RGB image with OpenGL.
<LaserEyess>
pq: well, they might as well use --vo=gpu --gpu-dumb-mode for that
<pq>
what's that do?
<LaserEyess>
basically just runs openGL/vulkan with the least amount of features possible to put an image on the display
<LaserEyess>
aka: the least amount of power
<pq>
sub-titles change relatively seldom, right? Not even every other frame. It would still be beneficial if the video itself didn't go through a GPU rendering pass in mpv.
<LaserEyess>
that's true
<LaserEyess>
I think, however, the point of vaapi-wayland would be to not use openGL/vulkan at all if possible
<pq>
for the video, sure, but literally at all?
<LaserEyess>
and honestly, it's not that I have any proof that wlshm subtitles "totally ruin performance" or anything, I'm just curious about the options
<LaserEyess>
pq: well, yes? I mean in mpv at least
<LaserEyess>
it's wlshm and vaapi
<LaserEyess>
besides whatever the compositor does it shouldn't use it at all
<pq>
I don't understand why avoid OpenGL even for sub-titles. I do understand to avoid it for video.
<ramcq>
if you're lucky your subtitle sub-surface could be also given a hardware plane
<ramcq>
then the 2d display controller would be blitting from it, as well as the video, to the output, avoiding any copy or composition step in the GPU
<ramcq>
but... you might need a fancy display controller for this
<ramcq>
it's the type of thing that is very normal in a STB or something so you can do subtitles/overlays/PIP/etc without killing the performance of the main video
<pq>
LaserEyess, I wouldn't expect the performance difference to be noticeable on a desktop, but I think would be measurable.
<LaserEyess>
pq: avoiding 'the GPU' with the --vo=vaapi-wayland is also a goal for simplicity, mpv technically keeps all GPU rendering stuff in --vo=gpu/gpu-next, I don't think there's any openGL/vulkan rendering code outside of those vos
<LaserEyess>
it's not impossible, but at the very least the first pass of this new vo will a) just not include subtitles (some vos don't have them), or b) use wlshm
<pq>
that's fine, I thought were talking about the possibilities :-)
<LaserEyess>
we are, and yes I'm aware of that particular option
<LaserEyess>
still waiting to learn about wl_shm_upload_this_buffer_but_also_make_it_scanout_able()
<LaserEyess>
but I guess it doesn't exist :')
<pq>
that's something a compositor could decide to do internally if it wanted to
<pq>
mostly we haven't seen why bother yet
<emersion>
i'm not 100% sure of the possible implications
<pq>
it could be just a dumb buffer
<LaserEyess>
ramcq: I'm actually curious about that actually, for things like bluray players and the like, subtitles are transparent images, but surely they do some fancy hardware tricks to display them efficiently
<LaserEyess>
obviously that's a very, very special case
<emersion>
are dumb buffers more or less fast than GL uploads?
<pq>
I mean that a compositor could decide to copy the contents of a wl_shm buffer into a KMS dumb buffer to scan that out.
<emersion>
yup
<pq>
dumb buffers are directly usable in KMS, GL uploads are not, so
<emersion>
or even a GBM buffer
<emersion>
hm
<LaserEyess>
to be clear, we're talking about skipping GPU->GPU copy(-ies?) here?
<LaserEyess>
(all of them?)
<pq>
gbm_bo_map(), write, unmap; can essentially be equivalent to glTexImage2D
<emersion>
LaserEyess: yes. the main motivation is to unlock direct scanout for the video underlay
<emersion>
pq, hm, right, i wonder if one can do a GL upload to a texture created from a EGLImage created from a GBM buffer
<LaserEyess>
and this is all compisitor implementation details?
<emersion>
whether or not you get the optimized fast path is compositor-specific yes
<LaserEyess>
interesting
<emersion>
it's a matter of what's implemented in the compositor really
bindu has quit [Ping timeout: 480 seconds]
<pq>
emersion, I don't think you're allowed upload to an EGLImage with glTexSubImage*...
<pq>
emersion, however, the gbm_bo_map() path can do all the same fast path copy tricks as glTexImage might
<pq>
with the exception that gbm_bo_map might allow you to write directly into a staging buffer rather than glTexImage2D internally doing a CPU copy into a staging buffer.
<pq>
..and then GPU pulls from the staging buffer into VRAM, for instance
<emersion>
i've been wondering for a while whether it would be worth it to offload wl_shm GPU uploads to a helper thread (ugh)
<emersion>
it's a bit annoying to block the whole compositor
<pq>
does it show up in profiles? :-)
<emersion>
and e.g. with a 4k screen there are a lot of pixels to copy
bindu has joined #wayland
<emersion>
cc dnkl
<pq>
GL PBO exists, too
<emersion>
PBO doesn't fix it
<emersion>
PBO is essentially the same as gbm_bo_map
<emersion>
you need to manually memcpy
<pq>
mmhm
<emersion>
host_ptr might help
<pq>
apps producing VGEM dmabuf instead? :-)
<emersion>
that wouldn't help, would it?
<pq>
depends if those buffers are usable
<pq>
as in, GPU readable without compositor doing a CPU copy
<pq>
scanout-able almost surely not, but GPU readable?
<emersion>
but maybe inefficient
<pq>
(almost, because virtual KMS drivers exist)
<emersion>
doesn't re-upload just the damaged areas, etc
<pq>
ah, damage
ahartmetz has joined #wayland
ahartmetz has quit [Remote host closed the connection]
ahartmetz has joined #wayland
floof58 is now known as Guest186
floof58 has joined #wayland
Guest186 has quit [Ping timeout: 480 seconds]
sychill has quit [Ping timeout: 480 seconds]
sychill has joined #wayland
Guest26 is now known as bluepenquin
___nick___ has joined #wayland
maxzor has joined #wayland
Azem has joined #wayland
tzimmermann has quit [Quit: Leaving]
MajorBiscuit has joined #wayland
Moprius has joined #wayland
___nick___ has quit []
maxzor has quit [Ping timeout: 480 seconds]
___nick___ has joined #wayland
___nick___ has quit []
___nick___ has joined #wayland
MajorBiscuit has quit [Quit: WeeChat 3.4]
mort_ has quit [Quit: Ping timeout (120 seconds)]
mort_ has joined #wayland
duxsco has joined #wayland
MajorBiscuit has joined #wayland
duxco has joined #wayland
duxsco has quit [Quit: duxsco]
duxco is now known as duxsco
duxco has joined #wayland
duxsco has quit [Read error: Connection reset by peer]
duxco is now known as duxsco
duxco has joined #wayland
duxco has quit []
duxsco has quit [Read error: Connection reset by peer]
hex[m]1 has joined #wayland
jmdaemon has joined #wayland
lxsameer has quit [Ping timeout: 480 seconds]
d_ed has quit [Ping timeout: 480 seconds]
jgrulich has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]
swick has quit [Ping timeout: 484 seconds]
go4godvin has joined #wayland
duxco1 has joined #wayland
psydroid[m] has joined #wayland
go4godvin is now known as Guest205
duxco1 has quit []
eroc1990 has joined #wayland
swick has joined #wayland
duxco1 has joined #wayland
duxco1 is now known as duxsco
rasterman- has joined #wayland
rasterman- has quit []
rasterman has quit [Remote host closed the connection]
duxsco has quit []
duxsco has joined #wayland
___nick___ has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
jmabr has quit [Remote host closed the connection]
jmabr has joined #wayland
maxzor has joined #wayland
d_ed has joined #wayland
d_ed has quit []
jmabr has quit [Remote host closed the connection]
lxsameer has joined #wayland
Azem has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
sych1ll has quit [Read error: Connection reset by peer]
sychill has joined #wayland
popeishere[m] has joined #wayland
hardening has quit [Ping timeout: 480 seconds]
zebrag has quit [Quit: Konversation terminated!]
maxzor has quit [Ping timeout: 480 seconds]
Lucretia has quit []
rasterman has quit [Quit: Gettin' stinky!]
rv1sr has quit []
lxsameer has quit [Ping timeout: 480 seconds]
dcz_ has quit [Ping timeout: 480 seconds]
<everfree>
is there a standard for detecting user activity in wayland? like, say i want to write an app that doesn't send push notifications to someone's phone if they're active at their computer. With X i might ask for all keystrokes/mouse events to check when the last was sent, but this is basically keylogging so not ideal. Is there a way I can detect user activity by asking the window manager or some other way,
<everfree>
without having to capture the actual contents of those input events