01:41kchibisov: For which surfaces `text_input::enter`/`wl_keyboard::enter` should be sent? I think that most compositors only sent focus like that for top-levels? It's not like if I have a text-entry field as a separate surface compositor will know how to send an 'enter' for it?
03:13RAOF: kchibisov: That is gloriously underspecified! You are guaranteed that a grabbing xdg_popup will receive "wl_keyboard::enter" (because it's guaranteed to have keyboard focus), but other than that, 🤷♀️.
03:19RAOF: In practice, of course, it _generally_ shouldn't matter?
03:39kchibisov: My main issue is that how input-method v2 popup works, since it's basically created and you dynamically move it around in compositor.
04:18RAOF: Ah, yes. Everyone's favourite xml-copied-from-_somewhere_ protocol :)
04:24kchibisov: the only way for some people to actually type anything.
04:25RAOF: Oh, yeah. It's not great!
07:20kchibisov: I've noticed that on wayland.app virtual keyboard has `destroy` for manager, however sway uses the xml without destroy for manager? How it end up diversing and what is correct?
07:21emersion: really? virtual keyboard canonical source is wlr-proto, is it there?
07:22kchibisov: https://wayland.app/protocols/virtual-keyboard-unstable-v1 they have destroy and the source doesn't match what I have in local checkout of sway.
07:22kchibisov: Maybe my checkout is old, but it would be strange that we have a new request without a version bump.
07:23kchibisov: No, the source of virtual-keyboard on wlroots doesn't have destroy for manager.
07:24vyivel: wayland.app's link to the xml is a patch on lists.fd.o, not the best source probably
07:24vyivel: though it's strange that there's no destroy request
07:25kchibisov: it's just could be surprising since compositor could error when getting unknown request.
07:26kchibisov: And one could clearly grab the virtual-keyboard from wayland.app instead of finding the one in wlr-protocols.
07:27vyivel: fwiw mir's copy of the xml doesn't have the request either
07:28kchibisov: Well, I guess so, I just got surprised that I don't have destroyed handled.
07:28kchibisov: Since I was reading XML on the site, because it's a bit nicer when they are rendered.
07:29vyivel: there's also https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/211
07:29vyivel: would be better to "just" merge that
07:37kchibisov: I guess I'll just open issue on wayland.app repo so they change the protocol to the actual one.
07:37vyivel: good idea
08:06kchibisov: Hm, text-input v3 doesn't prohibit calling methods without getting `enter` and doing `enable`?
09:17heeen: what are the apis one would need to study to implement drm/kms compositing
09:18heeen: is drm dumb buffers the right thing?
09:21daniels: heeen: the direct answer is atomic modesetting, but the real answer is to use libliftoff
09:21heeen: what is dumb buffers in this context
09:24heeen: can you use kms planes with gles simultaneously
09:24heeen: I guess you need to instruct your gles context to use a specific plane is you start assuming control over planes?
09:28heeen: https://github.com/emersion/glider/blob/master/gl_renderer.c
09:49kennylevinsen: heeen: that's rendering. The part that drives the planes is KMS/DRM. You configure the planes and attach buffers as part of an atomic commit.
09:50kennylevinsen: libliftoff helps you with plane allocation and assignment, but you still need the rest of a drm/kms backend to manage things
09:52kennylevinsen: (and unless it's a very controlled environment, you will still have to fall back to conventional composition when plane configurations get rejected)
10:04pq: dumb buffers in any KMS context are buffers that are CPU-writable and display scanout-able. That's literally the only thing you should ever do with a dumb buffer: write with CPU and put it on a KMS plane.
10:06pq: heeen, GLES/GL (EGL really) has no idea about any KMS planes. You just use them to draw into a buffer that happens to be compatible with KMS, and then you use KMS yourself to show that buffer.
10:07pq: there are a couple different ways to go about that.
11:21wlb: weston Issue #828 opened by Link Mauve (linkmauve) Segfault when clicking on a button in Ghidra https://gitlab.freedesktop.org/wayland/weston/-/issues/828
12:27wlb: wayland Issue #413 opened by Tony Advantaged (tony.advantaged) wayland_include-clippboard-functions-4_qemu-kvm https://gitlab.freedesktop.org/wayland/wayland/-/issues/413
12:28wlb: wayland Issue #413 closed \o/ (wayland_include-clippboard-functions-4_qemu-kvm https://gitlab.freedesktop.org/wayland/wayland/-/issues/413)
12:29kennylevinsen: what does ext4 vs. btrfs vs. zfs have to do with Wayland...
12:31daniels: I thought from the title it was just going to be Markov spam
12:32davidre: I think the problem is that spice-vdagent doesnt have a surface
12:32davidre: /not active one
19:39wlb: weston Merge request !1374 opened by Nicholas Niro (nniro) compositor: Add the command line options --autolaunch-path and --autolaunch-watch https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1374