01:07wlb: wayland-protocols Merge request !285 opened by Peter Hutterer (whot) Draft: tablet: add support for scrolling, relative dials and bustype https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/285
10:53wlb: wayland-protocols Merge request !286 opened by Simon Ser (emersion) tablet-v2: clarify that name/id events are optional https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/286 [tablet]
11:19wlb: weston Issue #883 opened by kw avnet (kwavnet) Can't move virtual mouse to different display https://gitlab.freedesktop.org/wayland/weston/-/issues/883
11:57wlb: weston Issue #883 closed \o/ (Can't move virtual mouse to different display https://gitlab.freedesktop.org/wayland/weston/-/issues/883)
14:24wlb: weston Merge request !1470 opened by Witold Lipieta (witold.lipieta) desktop-shell: shell: Capture input on fade animation curtain https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1470
14:41wlb: weston Issue #147 closed \o/ (Can click through the lock screen https://gitlab.freedesktop.org/wayland/weston/-/issues/147)
14:41wlb: weston Merge request !1470 merged \o/ (desktop-shell: shell: Capture input on fade animation curtain https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1470)
14:41wlb: weston Issue #569 closed \o/ (application get first touch event while the screen is locked https://gitlab.freedesktop.org/wayland/weston/-/issues/569)
14:41wlb: weston/main: Witold Lipieta * desktop-shell: shell: Capture input on fade animation curtain https://gitlab.freedesktop.org/wayland/weston/commit/215cceb45d39 desktop-shell/shell.c
15:05swick[m]: emersion: sorry for kicking off even more discussions on the explicit sync protocol... I'd like to see it land as is but those things crossed my mind when checking the mutter impl.
15:12wlb: weston Merge request !738 closed (compositor: fix input events propagated through locked screen)
15:22wlb: weston Issue #884 opened by Jordan Williams (jwillikers) Cannot link to Wayland Cursor statically https://gitlab.freedesktop.org/wayland/weston/-/issues/884
17:37MrCooper: swick[m]: what new discussions? I'm only seeing new threads from Julian Orth, not you
21:03Company: robertmader[m]: https://chaos.social/@rmader@floss.social/112016252581915214 - are you saying that it's beneficial to do an upload to dmabufs even when using cpu-decoding?
21:03Company: because I had wondered about that
21:03Company: if it makes sense to use the offloading codepath for GdkMemoryTexture
21:04emersion: i would say that a compositor is in a better position to make this decision
21:05Company: but you'd need to get the memory to the compositor first
21:05emersion: via wl_shm, yes
21:06emersion: and then the compositor can decide what the best way is to upload this to the GPU
21:06Company: right, but that may require copying it into shared memory
21:06emersion: cpu decoders can't decode to wl_shm memory directly?
21:06Company: which would also be an entirely different codepath more or less
21:06emersion: that would surprise me
21:06Company: technically they can, but there lots of libraries inbetween
21:08Company: GTK basically has 2 code paths atm: either composite it with the GTK rendering engine, or use the graphics offload with dmabufs
21:09Company: and video buffers in CPU memory always go through the rendering engine
21:10Company: so the question was if it's worthwhile to memcpy them into a (linear) dmabuf and use the offload path
21:10emersion: right, what you're saying is that you need to upload to GPU for client-side composition anyways
21:10emersion: why linear?
21:11Company: because that's the simple way
21:11emersion: i don't see why non-linear would be more difficult
21:11Company: because that needs the rendering engine
21:11Company: and linear can mmap + memcpy
21:12emersion: you need a way to allocate DMA-BUFs
21:12emersion: that way is probably GBM, no?
21:12Company: my goal was to use Vulkan
21:12Company: if I was going to do this dmabuf stuff
21:12emersion: that's a good plan, i think, except for dma-buf feedback integration
21:12emersion: you wouldn't be able to pass the scanout hint
21:13emersion: and with Vulkan linear is no more difficult than non-linear
21:13Company: I've decided that the scanout hint is not something we're gonna implement
21:13emersion: er, the other way around
21:13emersion: both are easy
21:13emersion: vkMapMemory works on non-linear
21:14Company: yeah, I'd need to look into how to plumb that through GTK
21:14Company: because we have infra for fds, but no way to attach the VkMemory to it
21:15emersion: the good thing about Vulkan is that your "upload to pass DMA-BUF to compositor" code-path is not very different from the "upload for client-side composition" one
21:15Company: yeah, that was the reason for Vulkan over gbm
21:15Company: because I have code to create dmabuf memory anyway, for sharing with GL
21:18Company: GTK has a pixel data object (called GdkTexture) that has implementations for regular memory, for a GL texture and 4.14 will have one for dmabufs (because using GL textures sucks, as it's never clear what state that texture is in wrt mipmaps and parameters and internal format and such)
21:18Company: (oh, and because it can't be shared with Vulkan)
21:20Company: but I don't have one for Vulkan and I don't want one, because that'd require tracking the Vulkan state - device etc - which in the dmabuf case is all neatly encapsulated in the fd
22:08bwidawsk: does wl_region::substract remove a previously added rectangle, or can it operate on the set of rectangles and modify those to achieve subtraction?
22:11bwidawsk: I believe it's the latter
22:16bwidawsk: nvm, it's the latter for sure
22:50robertmader[m]: Meh, can't write here from matrix right?
22:57Company: robertmader[m]: I can read it
22:58zamundaaa[m]: robert.mader: as long as you're identified with NickServ you can
23:02robertmader[m]: Ah ok, thanks - now we switched to #gtk :)
23:29Arsen: is there an XEmbed equivalent?
23:29Arsen: or, if not equivalent, something similar (i'd like to embed an arbitrary window into some other window)
23:30Company: no
23:31Company: best we can do is https://wayland.app/protocols/xdg-foreign-unstable-v2