<dnkl>
There's never been a specification for the protocol between the terminal and the client. The other way around - yes. But not from the terminal to the client.
<dnkl>
This is in general, and not limited to the terminator
<dnkl>
I'll take a look at mirroring the terminator from the query. If tmux uses BEL when it sends the query, then everything will work
<dnkl>
On the other hand, if they use ST in the query, but then expect BEL in the reply, then I'd say it's tmux that needs to be fixed
<cbb>
ah I guess not, that seems to be for pasting rather than copying
<dnkl>
cbb: I don't think so. Nowadays we have a "data manager" protocol (at least that's what I think wl-clipboard uses). Before that, it needed a window, to get a serial, to be able to access the clipboard
<cbb>
dnkl: yeah, I should have read that whole thread
<cbb>
I'm just browsing the wl-clipboard repo looking for clues
<cbb>
in case it might be cause by wl-copy doing something wierd
<cbb>
caused*
<dnkl>
cbb: the compositor uses the serial to validate the clipboard access. The idea being that only focused windows are allowed access. Preferably only in response to a user interaction
<dnkl>
How the serial is validated is up to the compositor
<dnkl>
So, I don't _think_ your issue is caused by wl-copy specifically
<dnkl>
Would be interesting to run your experiment on e.g mutter, with an un-patched foot
<cbb>
dnkl: makes sense
<cbb>
I assumed it was for something like that
<cbb>
I wonder what it is exactly that wl-copy does that then stops OSC 52 working
<cbb>
time for me to do a lot of reading about Wayland I think
<ifreund>
cbb: wl-copy is very much a hack on compositors that don't implement wlr-data-control
<ifreund>
with only the core wayland protocol, you need a surface to access the clipboard
<ifreund>
so wl-copy tries to create and map an empty surface or something like that
<ifreund>
(mutter doesn't implement wlr-data-control, most wlroots based compositors do)
* ifreund
actually goes back to read context he was missing
<cbb>
ifreund: I posted that link before reading the whole thread
<cbb>
it was unrelated to what I was talking about
<cbb>
just me being dumb
<ifreund>
well, wl-copy is very much doing something weird, so I don't think it's dumb to suspect it :D
<ifreund>
I see from that issue that it works in river though which does implement wlr-data-control, perhaps sway does some addtional validation that I'm not doing in river
<dnkl>
ifreund: if you're referring to the issue for foot, then cbb's example failed on river too
<ifreund>
dnkl: are you seeing one of those two wlr_log messages show up in debug logs?
<ifreund>
(just to confirm that this is indeed the code causing this behavior)
<dnkl>
ifreund: haven't had time to test yet, but will do before I merge the foot PR, just to be sure
* dnkl
is on the phone
<ifreund>
cool
<ifreund>
dnkl: I'm pretty sure it's the `serial - seat->selection_serial > UINT32_MAX / 2` there that's failing
<ifreund>
which is testing that the serial provided by foot when it tries to paste is more recent than the serial provided by wl-copy when creating the data source
<dnkl>
ifreund: yeah, sounds very reasonable... :)