ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
nerdopolis has quit [Read error: Connection reset by peer]
nerdopolis has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
glennk has quit [Read error: Connection reset by peer]
glennk has joined #wayland
iomari892 has quit [Ping timeout: 480 seconds]
kode54 has joined #wayland
<whot>
Ermine: looks like some symlinks to the libinput docs are missing, s/1.28.1/latest/ will do the trick until fixed
<whot>
bluetail: best to file an issue in the libinput tracker, better than irc here (given timezones etc.) i'll need the libinput-record output because right now I'm a bit conused what is actually happening
<whot>
kennylevinsen: assign the Spam label (if you have the privs) and that will block the user and hide it
<whot>
kennylevinsen: for individual comments on issues use the :do_not_litter: emoji
<bluetail>
whot I cannot reproduce this in `libinput record`. Maybe it's a https://github.com/rvaiya/keyd issue? I opened a issue there. It's still weird, though.
<bluetail>
Because all I see when I monitor that particular Motion Sensor is motion sensor data - it comes out too fast maybe.
bitblt_ has joined #wayland
bitblt has quit [Ping timeout: 480 seconds]
<whot>
I'm guessing keyd does the usual uinput wrapper so yeah, you can get duplicate events depending on how it re-routes things
<bluetail>
Oh, so the 'its for comfort' thing another guy said is just a myth. Thanks. Relieved.
bitblt_ is now known as bitblt
<whot>
dunno, I don't know enough about keyd, it's all paged out. but basically: if it doesn't happen without keyd running it's not a kernel/libinput issue
<bluetail>
My previous issue I had solved - a keyboard randomly sending out keystrokes. So I put it through a sieve and claimed my own device. That worked. But that happens without a ds4 connected anyways. It's one of these drum 'keyboards' where it's just some cable out of a SBC out into a 'keyboard' and "sensing" through the drum.... on different points
<bluetail>
making a 'd f j k' and nothing else, but sent out more.
nerdopolis has quit [Ping timeout: 480 seconds]
Moprius has quit [Quit: bye]
Brainium has quit [Quit: Konversation terminated!]
kts has joined #wayland
naveenk2 has joined #wayland
bindu_ has quit [Remote host closed the connection]
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
naveenk2 has quit [Ping timeout: 480 seconds]
naveenk2 has joined #wayland
alarumbe has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
Tokoyami` has joined #wayland
Tokoyami has quit [Read error: Connection reset by peer]
Hypfer has quit [Read error: Connection reset by peer]
sima has joined #wayland
naveenk21 has joined #wayland
tzimmermann has joined #wayland
naveenk2 has quit [Ping timeout: 480 seconds]
juergbi has quit []
Tokoyami` is now known as Tokoyami
akimoto has quit [Remote host closed the connection]
Drakulix has joined #wayland
naveenk21 has quit [Ping timeout: 480 seconds]
naveenk2 has joined #wayland
naveenk2 has quit [Ping timeout: 480 seconds]
naveenk2 has joined #wayland
andymandias has quit [Ping timeout: 480 seconds]
naveenk2 has quit [Ping timeout: 480 seconds]
leon-anavi has joined #wayland
Tom^ has quit [Quit: WeeChat 4.5.2]
Tom^ has joined #wayland
juergbi has joined #wayland
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
rasterman has joined #wayland
kts has quit [Ping timeout: 480 seconds]
naveenk2 has joined #wayland
kts has joined #wayland
fmuellner has joined #wayland
wmlhwl has joined #wayland
wmlhwl has quit [Remote host closed the connection]
wmlhwl has joined #wayland
wmlhwl has quit [Read error: Connection reset by peer]
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
<daniels>
jadahl: given you're already shepherding experimental protocol things, could I please leave it to you to land dcz's im-next if you're happy with it?
<jadahl>
sure
<daniels>
thanks!
<jadahl>
i'll let the xx-session-management set the rules for how meson integration should look like
<dcz>
"When a configure event is received, if a client commits thesurface in response to the configure event, then the clientmust make an ack_configure request sometime before the commit"
<dcz>
what is ack_configure designed to achieve?
<dcz>
if a client doesn't commit the surface in response to the event, what is a compositor supposed to do? proceed with the change but use the old state?
<dcz>
*old surface contents?
<dcz>
or is it supposed to ignore the change?
<dcz>
(I'm trying to make input method popup work and I am not sure if the sync is applicable and why)
<dcz>
(as in, designing a protocol that makes it useful)
<vyivel>
dcz: ack_configure is to let the compositor know that the state has been changed in response to a configuration request, which is useful if you're configuring multiple windows synchronously, or want to tie something to the configuration finish
<vyivel>
if the client doesn't respond with a commit, you proceed with the old state and curse the client's developer (mandatory)
<vyivel>
for just a popup none of this is probably required
dcz has quit [Read error: Connection reset by peer]
dcz has joined #wayland
<dcz>
vyivel: about cursing the client's developer, does that mean that about all configure events expect some sort of a reply?
<dcz>
the xdg_popup sends the relative position to the parent surface, but I don't imagine a lot of applications want to respond to that. Should they also send ack_configure?
<vyivel>
popup's relative position is useful for rendering this little triangle thingy https://0x0.st/8Jpu.png
<vyivel>
but yeah imo clients should always reply with ack_configure+commit even if there's nothing to redraw (just don't attach a buffer then)
<vyivel>
that makes keeping track of whether a layout reconfiguration is done or not much simpler
<dcz>
the concrete question is: I want to give input methods the position of the cursor in the text, but as far as I can tell, none draw a triangle thingy yet. Should I put the position in configure and mandate the ack?
<vyivel>
hm for frame-perfect popup repositioning that would be needed yes
<vyivel>
so compositor sends position, client responds with ack+commit, then compositor actually moves the popup and uses the new buffer
<dcz>
thanks, I guess I'm reasonably sure I won't get burned at the stake for that now
<dcz>
how about serials vs tokens? xdg_surface.configure carries serials, but xdg_popup.reposition requires tokens
<dcz>
I have a hunch that I can respond to both with the same .configure, but that difference gives me a pause
<dcz>
*to any kind of changes in position
<vyivel>
same stuff really, serials come from the compositor and tokens come from the client (in this case)
<vyivel>
i don't think ime popup would have a .reposition equivalent?
<dcz>
why not?
<vyivel>
good point
<dcz>
heh
<dcz>
I prototyped this using xdg_popup and it worked well. Then I got some feedback that people would prefer not to be too different so I'm trying that now
<vyivel>
and yes you would reply with one configure; client sends .reposition, compositor sends .repositioned+.configure, client sends .ack_configure+commit, compositor draws new state