ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
guru_ has joined #wayland
Guru_DE has quit [Ping timeout: 480 seconds]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
carlos_ has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
<kchibisov>
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?
Company has joined #wayland
nerdopolis has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
<RAOF>
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, 🤷♀️.
<RAOF>
In practice, of course, it _generally_ shouldn't matter?
kts has joined #wayland
kts has quit [Ping timeout: 480 seconds]
MIRV_ has joined #wayland
kts has joined #wayland
<kchibisov>
My main issue is that how input-method v2 popup works, since it's basically created and you dynamically move it around in compositor.
gildekel has quit [Quit: Connection closed for inactivity]
<kchibisov>
the only way for some people to actually type anything.
<RAOF>
Oh, yeah. It's not great!
MIRV_ has quit [Remote host closed the connection]
Leopold__ has joined #wayland
Leopold_ has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
Kerr has quit []
kts has quit [Ping timeout: 480 seconds]
guru_ has quit [Remote host closed the connection]
guru_ has joined #wayland
mvlad has joined #wayland
rumpelsMongol_ has joined #wayland
Dami_Lu has quit [Quit: 离开]
Dami_Lu has joined #wayland
leon-anavi has joined #wayland
<kchibisov>
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?
<emersion>
really? virtual keyboard canonical source is wlr-proto, is it there?
<kennylevinsen>
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.
<kennylevinsen>
libliftoff helps you with plane allocation and assignment, but you still need the rest of a drm/kms backend to manage things
<kennylevinsen>
(and unless it's a very controlled environment, you will still have to fall back to conventional composition when plane configurations get rejected)
<pq>
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.
<pq>
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.
<pq>
there are a couple different ways to go about that.