ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<karenw>
whot: I thought that, but them emersion pointed out that would come with a version bump regardless. Now if YKB gets added, then the version is bumped again for something else in the wl_seat heirachy... pain will occur.
<whot>
problem with the version bump only means every client has to support every XKB/YKB format, so it's still not great
<karenw>
But anyway. How do I get animated cursors when using wl_cursor. 'Just' wait wl_cursor_image::delay ms, then move to the next image in the wl_cursor (looping when no more images)?
<whot>
and as you said, if there's any other feature that's useful, you're forcing the clients to support YKB just to get the next feature
<karenw>
But to update the hotspot, which is per-image, I have to have a serial from an enter event to pass? Can I keep reusing the same enter event?
<karenw>
Also isn't there a race between wl_pointer_set_cursor with the new hotspot and wl_surface_commit?
<karenw>
Is it acceptable to send requests to the compositor from multiple threads, or do I need to make a separate wl_client queue?
Calandracas has quit [Ping timeout: 480 seconds]
<karenw>
Ah, you can move the hotspot in attach according to the documentation for set_cursor... but then the documentation for attach says I should always pass 0,0?
<karenw>
I currently only support compositor v4. Hee hoo.
<ManMower>
queues are for events, not requests. I think the request marshalling code is thread safe by virtue of having a display wide mutex. if you want events to be handled by specific threads you'll need event queues and proxy wrappers.
<ManMower>
oops :D
<karenw>
Blame Mir (or rather, blame my method of picking versions to support by looking at the compositors listed on wayland.app)
<karenw>
So the separate request for offset was added because of vulkan/opengl/etc. doing the attach internally.
<karenw>
I do use vulkan, but not for the cursor surface, so it is mooted. It will need changing if I ever bump to wl_compositor v5
<wlb>
wayland Merge request !413 closed (src: properly use sendmsg(2))
Company has quit [Ping timeout: 480 seconds]
Company has joined #wayland
<karenw>
Hmm, odd. implementing the 'Wait' cursor with wl_cursor (kwin, weston, mutter), it spins faster than using cursor shape (sway)?
garnacho has quit [Ping timeout: 480 seconds]
<karenw>
Wonder if it's rounding up to vsync (33ms)
nerdopolis has quit [Ping timeout: 480 seconds]
Calandracas has quit [Remote host closed the connection]
Calandracas has joined #wayland
mxz_ has joined #wayland
mxz has quit [Ping timeout: 480 seconds]
mxz__ has quit [Ping timeout: 480 seconds]
mxz_ is now known as mxz
Brainium has quit [Quit: Konversation terminated!]
Moprius has quit [Quit: bye]
karenw has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
eroc1990 has joined #wayland
mxz_ has joined #wayland
sima has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
Company has quit [Quit: Leaving]
rv1sr has joined #wayland
<emersion>
it shouldn't be...
<emersion>
it just does a dumb timer pushing a new cursor image at the specified interval
<emersion>
it does round at ms precision, but should be fine
Calandracas has quit [Read error: Connection reset by peer]
andyrtr has joined #wayland
Calandracas has joined #wayland
<DodoGTA>
Is there a way to get non-current display modes on Wayland (or do I need to hardcode some)?
kts has joined #wayland
<emersion>
DodoGTA: why do you need this information?
kts has quit []
vova has quit [Remote host closed the connection]
<DodoGTA>
emersion: It's definitely helpful for Win32 applications which rely on certain non-native modes being present
<emersion>
ah, legacy? what Xwayland does is just expose a bunch of standard modes
linkmauve has left #wayland [Error from remote client]
linkmauve has joined #wayland
<emersion>
what happens when a Win32 app selects a mode? viewporter?
kts has joined #wayland
kts has quit []
linkmauve has left #wayland [#wayland]
<ofourdan>
yes, under certain conditions (window being fullscreen etc.), Xwayland will use a viewport to emulate XRandR.
linkmauve has joined #wayland
<ofourdan>
it is not possible to add non-standard modes though.
mvlad has joined #wayland
vova has joined #wayland
coldfeet has joined #wayland
leon-anavi has joined #wayland
garnacho has joined #wayland
coldfeet has quit [Remote host closed the connection]
tanty has quit [Quit: Ciao!]
tanty has joined #wayland
Calandracas has quit [Remote host closed the connection]
Calandracas has joined #wayland
coldfeet has joined #wayland
rasterman has joined #wayland
garnacho has quit [Quit: garnacho]
garnacho has joined #wayland
kts has joined #wayland
kts has quit []
kts has joined #wayland
<colinmarc>
<kennylevinsen> "it's tricky to send post-..." <- To me, the ideal api would be to send both the physical key (a big enum, based on the w3c input spec for example) and optionally a logical symbol, if the keypress resulted in one. As you say, not every keypress results in a symbol. Some apps (games) could ignore the symbol, but most apps would just use it. The client wouldn't need xkbcommon at all.
<kennylevinsen>
colinmarc: the keyboard state is not just symbol or no symbol
<kennylevinsen>
During composition, you have temporary display of input that is later replaced by the final character for example
<colinmarc>
sorry, you mean for IME?
<kennylevinsen>
no, XCompose
<kennylevinsen>
handled by libxkbcommon, without IME
<kennylevinsen>
If I click compose key and 'a', the client will usually show an a but with an underline to signal that composition is ongoing
<kennylevinsen>
Then, if I click 'a' again, the character changes to å without underline
<colinmarc>
huh, I thought that was just text-input. I didn't know there was another facility for that
<kennylevinsen>
of course one could argue that this could be pushed to the IME nowadays, but point was that XKB isn't just a stateless transform of input
<emersion>
some keyboards also have a key for bare accents, and writing a letter afer will merge it
<emersion>
sometimes you get multiple keysyms out of a single keycode
<emersion>
etc etc
<kennylevinsen>
yeah dead keys couldn't really be pushed to IME unless we start to consider IME's mandatory and reponsible for all keyboard input...
<colinmarc>
all text input, not all keyboard input, right?
<colinmarc>
anyway point taken
<kennylevinsen>
it wouldn't be impossible for a "default" text-input implementation to exist
<kennylevinsen>
colinmarc: but it wouldn't really help with any use case I know of - it would just save a dependency in clients needing text input
nerdopolis has joined #wayland
<DodoGTA>
emersion: I definitely noticed this when running `xrandr` (the modes listed there are more extensive than the ones listed in the KDE display settings)
<colinmarc>
<kennylevinsen> "Colin Marc: but it wouldn't..." <- The issue I faced is that the keyboard/keymap in my case is on a remote machine, which might be a mac or a windows desktop or whatever. so translating the remote keymap to xkbcommon and keeping it in sync is difficult bordering on impossible
<colinmarc>
right now I send the logical + physical keys over the network and then, in the compositor, check if there's a text-input for the surface. if there is one, I send the logical symbol and if not (or if there's no symbol) I send the keypress
<colinmarc>
so in my case, having text input be mandatoryish would be quite helpful
kts has quit [Quit: Konversation terminated!]
<colinmarc>
(also, I think not requiring all clients to link a C lib has some obvious advantages)
<kennylevinsen>
Being mandatory won't really help in your case. The remote server can already if it wanted to expose a dummy text-input, and clients supporting that can use it
<kennylevinsen>
clients not supporting text-input won't use it regardless of how mandatory support is
<kennylevinsen>
and it only solves wayland-to-wayland
<kennylevinsen>
(which waypipe can of course do perfectly as-is)
<colinmarc>
sorry, I was referring to your suggestion of having a default impl of text input instead of requiring xkbcommon (if I understood correctly)
<kennylevinsen>
having a default impl of text input only sorts the problem for clients implementing the text input protocol
<kennylevinsen>
trying to push the responsibility to the host gives more issues in your example
<kennylevinsen>
e.g., on mac, pressing and holding a button presents a UI to select a character (a default IME of sorts) - so now you need to bridge that IME to the remote session, tying it to text_input and the proper cursor position and such
<kennylevinsen>
if instead you rely on the IME within the server, then that sort of conflicts with letting the mac do the translation
<kennylevinsen>
remote stuff is "fun"
<colinmarc>
kennylevinsen: well, no, because the remote client isn't acting as a text input, it's working with raw keycodes. but it definitely breaks down at some level. my point is just that even the very basic case of dvorak keypresses on the mac isn't really doable with the wl_keyboard that exists today
<kennylevinsen>
For Windows RDP, I suspect the approach is to let the accessed system handle physical keys and just use the client’s keymap preference as a hint. Not the exact keymap and its settings, but just “US” for example.
<colinmarc>
Yeah, I considered just having a small enum with "dvorak", etc. The problem there is that it's actually nontrivial to even access the keymap as a client (on mac eg)
<kennylevinsen>
colinmarc: we already send key codes - that’s trivial - anything with text input is about sending translated symbols.
<kennylevinsen>
And sending translated symbols from a remote client means wiring *their* IME through the stack
<colinmarc>
that's one type of key mapping, but the most common is just "the s key works as an o key", no?
<kennylevinsen>
If you still want to work on key codes, then you still want the remote server to manage the keymap, and then we’re back to there not being a difference between client-side libxkbcommon or text-input.
<colinmarc>
what I want, ideally, is to present both sets of information to the remote server, linked by serial or in the same event. here are the key codes, here is the text that was committed
<colinmarc>
then the server doesn't have to manage a keymap, and it can give all that information to the client
<colinmarc>
which also doesn't have to manage a keymap
<colinmarc>
I recognize that there's a fair bit of complexity there that's squirreled away by xkbcommon right now
<kennylevinsen>
colinmarc: well, I only see there being two levels: scan codes ("Key number 48 was pressed"), and text input ("the user generated an Å")
anarsoul|2 has joined #wayland
<daniels>
usually where this breaks down is in shortcut processing
anarsoul has quit [Read error: Connection reset by peer]
<kennylevinsen>
The latter extends fast past "key with the 'o' printed on it". On Mac in particular, the entire keyboard layout and its reliance on IME differs
<daniels>
e.g. for ctrl+C you don't want to inject ASCII BRK into the text stream, but you want the client to detect that Ctrl has been held down whilst the key corresponding to 'c' in the ASCII layout present in your keymap has just been pressed
<daniels>
even more trivially without including non-Latin layouts - even English alone - you don't get to say 'UK is US layout with the following key swaps', because shift+2 is @ in US and " in UK
<daniels>
so yeah, by the time you've unbroken non-Latin layouts and shortcut handling, you're back to sending the entire keymap and doing pretty complex interpretation
<kennylevinsen>
(There's also fun platform differences: Danish Mac and PC layouts are completely different for anything outside the alphanumerics, which ultimately drove me to a US layout)
<kennylevinsen>
(point being that what you see on your keyboard and what happens when you press won't match unless the remote client does *all* the text input handling)
<kennylevinsen>
colinmarc: As trying to plumb text-input all the way up to a remote client on a different platform is not realistic, I suspect what you want is just a way for the remote client to give a keyboard configuration preference for the session
<kennylevinsen>
e.g. "us dvorak"
<daniels>
++
flom84 has joined #wayland
privacy has joined #wayland
<colinmarc>
(sorry, made a quck trip to the playground) I will definitely have that option, but just as an override. I think having transparent logical keymapping on the remote client is actually quite nice as a feature, even if all the bits and bobs of IME aren't expressed via the network protocol. as long as I can have it work on the wayland side in a way that's reasonably not-broken, it's nice for people using US dvorak on the remote client to just
<colinmarc>
have text input work out of the box.
<colinmarc>
the 95% of text input that's actually possible/realistic to plumb out to the client is actually quite nice to have, I think. and I already built that and it works
<kennylevinsen>
Well, you either *have* to plumb through the entirety of IME *and* fix the issues daniels mention by making shortcuts work differently in the clients
<kennylevinsen>
or not do any of this and just the remote client specify which keymap/keyboard config to use but not at all be involved in text input
f_ has quit [Remote host closed the connection]
f_ has joined #wayland
<daniels>
yeah, that's a load-bearing 'as long as' ;)
<kennylevinsen>
now, doing *both* a proper keymap, and plumbing through remote IME would be kinda cool
<kennylevinsen>
but the IME wouldn't be to solve your problem, it would just be a cool feature
<colinmarc>
well, that's why I was saying in the beginning it would be cool if wayland had more of these concepts in the protocol itself instead of farming out to xkbcommon. I know it's not realistic to expect a change there, obviously.
<daniels>
there's only so much you can usefully encode in the protocol
<daniels>
for example if you press tab followed by typing 'if', then in your text editor you want 'if' tabbed in; in a classic GUI app, you want to move the focus to the next element (completely resetting your IME state) and then type 'if' into it
<daniels>
so in that case the client would have to respond to the compositor to tell it that the IME state was reset after tab, and can it please replay everything after that
<daniels>
which is a great deal of extra complexity, and what benefit are you gaining from it?
<daniels>
fwiw, the original aim was that the protocol should be based on keysyms/text with only the bare minimum of physical-key parts added to make things work; we ended up with a physical-key-centric protocol because doing a keysym-only protocol was looking to be pretty infeasible
<kennylevinsen>
I suppose it is possible to have a combination of text-input as the *only* way for clients to manage text inputs + a translated keysym event that must only be used for stuff like hotkeys...
<kennylevinsen>
but then someone wants their remote software to use physical keys to let the other end do all the IME processing, and then we're back to square one
<colinmarc>
<daniels> "for example if you press tab..." <- I'm not sure I follow this example. you're saying if the client didn't have a keymap, it would have to use the text-input protocol for everything, and then the text-input protocol would have to grow to accommodate some of that extra complexity, right?
<colinmarc>
I'm not saying wayland should have a text-focused protocol, I'm saying it should get rid of the concept of a keymap in wl_keyboard, and that the edge-casey stuff in xkbcommon is redundant with text-input anyway
<colinmarc>
so instead of sending a keymap, wl_keyboard would send the keymapped logical symbol in addition to the physical key, if one exists. for anything more complicated, that would be considered text input
<kennylevinsen>
text-input tells the client exactly what the content of a text input field should be at any given point
<kennylevinsen>
it doesn't send key presses or events, but "text field now contains the following string", or "text field now contains this pre-edit string"
<colinmarc>
colinmarc: (this would be wl_keyboard)
<daniels>
colinmarc: what does the client receive when a Russian layout is active, for a client who has RU+UK?
<daniels>
*RU+US
<colinmarc>
how does that work now? I've never used a russian keyboard :)
<daniels>
the spoiler to the obvious-gotcha question is that it receives Ctrl + Cyrillic 'es', which is meaningless to it: the client wants to look at the keymap, say 'ah, this key is C in the Latin layout', then do what Ctrl+C would do
<mclasen>
there are many non-solvable problems in this area
<LaserEyess>
what does windows and/or macOS do? or android? or iOS?
<LaserEyess>
are these problems really unsolved on other OSes?
<colinmarc>
daniels: wow, that seems pretty magical. do terminal emulators really try to do that today? map by key location on a third layout?
<colinmarc>
macos apps do not have access to the currently selected keyboard layout, fwiw
<daniels>
yeah
<daniels>
it's not theoretical; those are things we had to deal with to not massively regress current desktop use
f_ has quit [Max SendQ exceeded]
f_ has joined #wayland
<colinmarc>
well, if clients having access to the keymap is a hard requirement then it's a hard requirement :)
feaneron has joined #wayland
<colinmarc>
that seems way harder than just configuring the client to take a different keyboard shortcut if there's no C key though
Moprius has joined #wayland
<dottedmag>
daniels: wait, what? How does it work if the mapping is not injective? If I mapped cyrillic 'es' to two keys that carry latin labels X and C, how does the application decide if Ctrl + Cyrillic 'es' is cut or copy?
<daniels>
I haven't seen that problem come up, so I assume the answer is that you get semi-random behaviour
<mclasen>
colinmarc: gtk does such cross-layout heuristics too
iconoclasthero has joined #wayland
<colinmarc>
<mclasen> "Colin Marc: gtk does such cross..." <- also because of backwards compatibility with x11 apps? or for some other reason?
<mclasen>
meeting user expectations, basically
<DemiMarie>
When dealing with legacy Windows or X11 applications, at what point should I give up and use a virtual desktop?
<DemiMarie>
Qubes OS will need to support them, and I want to get rid of the current GUI protocol eventually.
<DemiMarie>
There are many applications that will never be ported to Wayland or have a legitimate need for ext-zones or similar.
psykose has quit [Remote host closed the connection]
psykose has joined #wayland
flom84 has quit [Ping timeout: 480 seconds]
Moprius_ has joined #wayland
Moprius has quit [Read error: Connection reset by peer]
flom84 has joined #wayland
ity1 has quit []
Company has joined #wayland
leon-anavi has quit [Quit: Leaving]
coldfeet has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
<llyyr>
would it be somehow possible to see debug messages for an already running program somehow?
<vyivel>
llyyr: attach with gdb and set debug_client to 1?
<llyyr>
hmm
privacy has quit [Ping timeout: 480 seconds]
kts has joined #wayland
<JoshuaAshton>
cd codingkoopa3218 /
<JoshuaAshton>
oops
<JoshuaAshton>
wrong window ^^'
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
Moprius_ has quit [Remote host closed the connection]
kts has quit [Quit: Konversation terminated!]
garnacho has quit [Quit: garnacho]
garnacho has joined #wayland
coldfeet has quit [Remote host closed the connection]
flom84 has quit [Quit: Leaving]
<sewn>
stupid question: is it *safe* to assume a wl_buffer will immediately recieve a 'release' event regardless if it is safe to reuse or not? or is a dual-buffer 'swapchain' system required?
flom84 has joined #wayland
danieldg has quit [Ping timeout: 480 seconds]
<kennylevinsen>
sewn: it is not safe to reuse unless it is released, and that’s all there is to it
<kennylevinsen>
In some cases it is released fast and you can avoid double-buffering - that is something you just evaluate when you need to render again - if you got your buffer back, use it. Otherwise make a new one.
<kennylevinsen>
If you always use the youngest buffer that is available, you’ll automatically use just a single buffer when possible (specifically when the compositor implements wl_shm buffer fast release)