ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Narrat has quit []
privacy has joined #wayland
karolherbst has quit [Quit: Konversation terminated!]
karolherbst has joined #wayland
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #wayland
soreau has quit [Ping timeout: 480 seconds]
soreau has joined #wayland
lsd|2 has joined #wayland
<stooov>
Im using kwin-wayland and KDE plasma (apparently the only compositor it works with), it came in debian 12. trying an alternative seems a bit much for today. I'll put in a bug somewhere.
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
kelnos has quit [Remote host closed the connection]
nerdopolis has quit [Ping timeout: 480 seconds]
kelnos has joined #wayland
kts has joined #wayland
Dami_Lu has quit [Remote host closed the connection]
Dami_Lu has joined #wayland
rv1sr has joined #wayland
kts has quit [Quit: Leaving]
kts has joined #wayland
psykose has quit [Remote host closed the connection]
psykose has joined #wayland
kts has quit [Ping timeout: 480 seconds]
<JoshuaAshton>
pq: > Maybe one day someone designs a game engine in a more modern design that separates screen updates from all the rest. I did read the game-loop pattern article, and I think it stops where we would only begin.
<JoshuaAshton>
I already explained exactly this and how engines do this when it happens. Doing screen updates like this *also* requires doing simulation/prediction. It is inherent
<JoshuaAshton>
What you are describing is just inherently wrong from a design perspective. The reason games do not do that is not because every game is written by someone who doesn't know what an event loop is, it's because it's the right design for the problem.
<JoshuaAshton>
The only way in which an event loop is beneficial to the design of a game engine is on a separate thread to record inputs and their times in order to feed into a fixed tick part for unlagging
<JoshuaAshton>
And that isn't new, this has been done for a while.
<JoshuaAshton>
Your hypothetical "modern" event-loop game engine design, where rendering is entirely split off from simulation, only works if the simulation state == render state for a given frame, which is not true -- unless you want to render the same state over and over again. As I said before, games are integration driven, let's say pressing W sets your speed -- the effects of that is only seen next integration cycle.
garnacho has joined #wayland
<JoshuaAshton>
And just to be clear, there are plenty of designs where screen updates are separated out from simulation and everything else (like how I described before with Source 1's fixed tick system) -- and that's basically how game servers work after all. It's just that the way you are describing by using an event loop doesn't actually solve any problems, and actually introduces many more.
<JoshuaAshton>
Anyway, when you have simulations that can potentially take 16+ms, you are actually not gaining anything by using an event loop on your main thread -- in fact you are loosing stuff I mentioned before like knowing precise time stamps of when keys were pressed, etc in order to more effectively integrate inputs.
sima has joined #wayland
mvlad has joined #wayland
bindu_ has joined #wayland
bindu has quit [Ping timeout: 480 seconds]
Leopold has quit [Remote host closed the connection]
Leopold has joined #wayland
Leopold has quit [Remote host closed the connection]
i509vcb has quit [Quit: Connection closed for inactivity]
leon-anavi has joined #wayland
manuel1985 has joined #wayland
Leopold has quit [Remote host closed the connection]
<kennylevinsen>
JoshuaAshton: I don't believe it's so black-and-white - at least from my experience in HPC land which has relatable issues and solutions.
<kennylevinsen>
When the suggestion is made that a good design could be achieved with an event loop, we are also not implying that existing devs do not know what an event loop is, or that there are some large unrealised performance benefit to be had in heavy games
Nefsen402 has quit [Remote host closed the connection]
bl4ckb0ne has quit [Remote host closed the connection]
emersion has quit [Remote host closed the connection]
Nefsen402 has joined #wayland
bl4ckb0ne has joined #wayland
emersion has joined #wayland
<pq>
JoshuaAshton, I understand what I'm proposing cannot be retrofitted into existing games. That's fine.
<pq>
"every game is written by someone who doesn't know what event loop is" is the core problem in making advances.
<pq>
oh sorry, I missed a "not".
<kennylevinsen>
a very important one :D
leon-anavi has quit [Quit: Leaving]
<pq>
JoshuaAshton, maybe what you call "input loop ina separate thread" is what I call "the main event loop". It very much sounds like the same thing, with only very little differences in how other parts are sequenced.
leon-anavi has joined #wayland
<pq>
JoshuaAshton, precise timestamps of when keys were pressed come with the input events, thought.
<pq>
JoshuaAshton, I never said one must one e.g. simulation *in* the main event loop thread. I was thinking that the main event loop only kicks the simulation to run in another thread(s).
<pq>
*one must run
<pq>
like it kicks yet another thread to run rendering
<pq>
and if simulation uses the GPU, that's fine. GPU can be accessed from multiple threads, it does not need to be an integral part of the rendering task.
<pq>
the main point is that the main loop is never blocked or spending great amounts of time in anything else than epoll() equivalent.
<pq>
which indeed makes my "main loop" sound like the "input event loop"
<pq>
simulation could even run on its own in its own threads without needing the main event loop to kick it, but then there might be mutex contention and jittery timings.
<pq>
what I imagine is, the main event loop accumulates input (network included), and when it's time, kicks a simulation tick with all the input gathered.
<kennylevinsen>
yeah I'd definitely also consider heavy compute threads like simulation/render to be non-main threads, but it's just a random label
<pq>
similarly, it watches the window system events and kicks a rendering at a suitable time, perhaps as soon as an on-going simulation tick can give some fences for the renderer to wait for.
cmichael has joined #wayland
Leopold has joined #wayland
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
kts has joined #wayland
kts has quit []
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
kts has joined #wayland
kts has quit []
rasterman has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
kts has joined #wayland
zvarde1988303206779191685 has quit [Read error: Connection reset by peer]
zvarde1988303206779191685 has joined #wayland
fmuellner has joined #wayland
kts has quit [Ping timeout: 480 seconds]
qaqland is now known as Guest10179
qaqland has joined #wayland
Guest10179 has quit [Ping timeout: 480 seconds]
<pq>
swick[m], would you like to clean up some of the left-over branches in your wayland-protocols?
kts has joined #wayland
ckinloch has joined #wayland
<swick[m]>
pq: can do
<pq>
thanks!
stooov has quit [Remote host closed the connection]
Moprius has joined #wayland
Brainium has joined #wayland
Moprius has quit [Quit: bye]
nerdopolis has joined #wayland
kts has quit [Ping timeout: 480 seconds]
suntory has joined #wayland
suntory_ has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
kts has joined #wayland
nerdopolis has joined #wayland
rgallaispou1 has joined #wayland
rgallaispou2 has joined #wayland
rgallaispou1 has quit [Read error: Connection reset by peer]
rgallaispou has quit [Ping timeout: 480 seconds]
JakeSays1 has quit [Ping timeout: 480 seconds]
Brainium has quit [Ping timeout: 480 seconds]
lanodan has joined #wayland
mvlad has quit [Remote host closed the connection]
bindu_ has quit [Remote host closed the connection]
adia has quit []
adia has joined #wayland
adia has quit []
adia has joined #wayland
rv1sr has quit [Ping timeout: 480 seconds]
cmichael has quit [Remote host closed the connection]
cmichael has joined #wayland
Company has quit [Quit: Leaving]
cmichael has quit []
mvlad has joined #wayland
sevz has quit [Quit: Client quit]
sevz has joined #wayland
leon-anavi has quit [Quit: Leaving]
kts has quit [Quit: Leaving]
kts has joined #wayland
kts has quit []
rv1sr has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
pac85 has joined #wayland
<pac85>
pq: yes I actually touched on the fact that there would be multiple conditions to meet to begin simulation and rendering and on the example we had yestarday that would have been basically draining the event queue. Now regarding the idea you propose of splitting of rendering from simulation: I brought the example of particles that mifht be simulatrd on thr gpu. Another common technique is to use the depth buffer as a mean to have
<pac85>
have very fast collision detection and resolution. In that case rendering itself is part of the simulation. Also forcing to split GPU work into multiple submission might have it's on disadvantages and you don't want a design that forces you to do it as well as the fact that you might want to eg. Do simulation and prepare indirect arguments in one CS to keep data on chip. A design that forces you to split things is not a good fi
<ManMower>
depth buffer readback is "very fast"?
<pac85>
Also, in your design, where would you actually kick off the simulation? What do you do in response to an event (from eg. the keyboard) precisely? Also I guess the simulation terminating would be what kicks off rendering? Otherwise how do you make sure the simukation result is showed in the right frame
<pac85>
ManMower: assuming you do the simulation on the gpu
<pac85>
Sorry I didn't make it cleat I was still referring to the particle system simulation example, using the depth buffer foe any other type of collision is probably not a good idea since it is a rough approximatikn
<ManMower>
fair enough, I just did a quick read and a hot take. ;)
<kennylevinsen>
pac85: An input event handler could do anything from just recording the last input, to doing input damping or extrapolation, to updating state directly. It's purely dependent on what the application needs and what fits with the design. Plenty of options though.
<kennylevinsen>
Having render follow simulation seems logical in most cases, but in that case frame scheduling is done by timing the simulation start, which should then be driven by e.g. frame events...
<pac85>
kennylevinsen: yes, but this is a game we are talking about, really the input for a game is more of a continuos function that you want to integrate over the time taken while rendering the previous frame that happens to be represented by events. So really I need to know all the events that have happened until right before beginning the simulation. This a fundamental difference between simulations and state machines where for a st
<pac85>
where for a state machine I can know the next state given an input and the current state whereas in a simulation the input migjr not even be there and if it is there it is a discretized representation of somethinf continuous (eg. The state of the keyboard)
<kennylevinsen>
i don't really see how that matters, nor how interrogating on the exact implementation details of a hypothetical game is productive to be honest
Guest9915 has quit [Remote host closed the connection]
<pac85>
kennylevinsen I think it helps to know what a game looks like to understand whether an idea is good or not.
cool110 has joined #wayland
cool110 is now known as Guest10223
<kennylevinsen>
You can know all events that happened until right before by just recording them as they happen for example. Whether you record do that as the events from a main event loop occur or in bulk reads before each simulation hardly affects the viability of the design IMO
<ManMower>
tbh, I'm having a hard time following these game dev discussions over the last few days. can we distil this all down to "why is this relevant to #wayland"? what is unaccounted for in the wayland protocols that these discussions are intended to fix?
<kennylevinsen>
Well the particular multi-day game discussion is just about whether using event loops in games vs. more traditional "while(1){dispatch();tick();}" loops is a good idea
<kennylevinsen>
Between two very opinionated groups
<pac85>
kennylevisen: you can indeed, however if it is functionally equivalent to reading them in bulk then you don't want to pay the price in complexity to implement the event driven design (assumjng you overcoem the otoher challenges I've mentioned)
<kennylevinsen>
Nothing about Wayland at all really :)
<kennylevinsen>
pac85: in any situation where it is functionally identical you cannot also say it is a bad design. It's just a different architecture then
<pac85>
ManMower: I wanted to address those ideas of event driven games that are propping up. I thought it might be helpful to bring my (limited) knowledge about games here to address why it might not work out. From what I gather from yesterday's discussion the problems are around games getting locked up when occluded (to which the event driven desogn has been proposed as a solution) and fifo semantics not being implemetable
<kennylevinsen>
An event driven design would indeed not have that issue, but it's not really a solution to the problem as we cannot rewrite all existing games
<soreau>
if I'm running a game and switch to another workspace, I expect it to still run, emit audio and handle network input. When I hover over the window-list button for it in the panel, I expect a live preview of the surface
<riteo>
ManMower: it all popped up because of issues I stumbled upon while working on a Wayland backend for godot
<ManMower>
pac85: sorry, not trying to single you out at all, you're just speaking on the topic while I'm at my keyboard. I want to approach this from a "what can I fix/improve" angle...
<ManMower>
I guess lock ups on occlusion has been the center of a lot of this kind of discussion over the years
<riteo>
and this is related to wayland because we use a very simple dumbity dumb loop that is timed by the graphics stack, which in turn uses the Wayland protocol which might have some "deficiencies" (is that the right word?)
<riteo>
indeed, it's all related to lock up on occlusion, at least from my PoV
<soreau>
The easiest thing I can think of is, a compositor option to put the user in control. If the surface is occluded, stop frame events unless app-id is matched by some setting
<riteo>
also tangentially frame timing as apparently the fact that we don't have a proper queue makes frame times kinda jittery
<ManMower>
riteo: is testing my proposed fix for this something you'd be interested in doing?
<riteo>
absolutely!
<kennylevinsen>
Not entirely sure why FIFO cannot be implemented based on a brief read of the spec without nore protocol work, but I assume there was a reason behind that statement... The other present modes look funky though
<ManMower>
kennylevinsen: FIFO requires every committed state to be made visible. without additional protocol wayland is a bit too mailbox for that?
<riteo>
I'd /love/ to unblock this situation and make native wayland games or anything else that requires a similar loop structure work properly OOTB
<ManMower>
riteo: what compositor do you test under?
<kennylevinsen>
It only seems to suggest that each state is popped on vblank though. What's wrong with committing the first state and popping on present?
Moprius has joined #wayland
<ManMower>
kennylevinsen: spec requires commit in present
<riteo>
ManMower: sway-git usually, the one I have on both my laptop and my desktop
<riteo>
I can setup something else though if that's needed
<ManMower>
riteo: ah, sadly I only have mutter working right now
<riteo>
eh, I can use mutter
<kennylevinsen>
ManMower: yes? I mean it's not *nice* to have autonomous surface commits...
<kennylevinsen>
Hmm well that would require dispatching
<kennylevinsen>
And then we're getting back to the former discussion lol
<ManMower>
well, with wayland-protocols MRs 256 and 248 + mesa MRs 26528 + 26150, and mutter MR 3355, you can have gl or vulkan clients that don't stop when occluded
<kennylevinsen>
ugh I don't like WSIs and I never will
<ManMower>
kennylevinsen: haha, I'm starting to wonder if anyone likes WSIs.
<soreau>
ManMower: but doesn't this require compositor 'support' for not sending frame events to occluded clients in the first place?
Brainium has joined #wayland
<kennylevinsen>
compositors not sending frame events to occluded clients is the baseline, although how fancy occlusion is differs
<ManMower>
soreau: sorry, I don't understand the question. but I don't change how frame events work
<ManMower>
weston sends frame events to occluded clients :(
<soreau>
right, I don't really know which compositors don't
<ManMower>
but I think with last release cycle's changes, that's become very easy to fix
<kennylevinsen>
what about minimized clients?
<pac85>
ManMower: I think joshua is the person with the best knowledge about the intersection of games and wayland, I could give you my ideas but those sound way to obvious to myself (eg. Some event beinf sent at the completion of a present with some id or timestamp to make them identifiable between commit and event and that being done regardless of surface occlusion)
<kennylevinsen>
there's a difference in how fancy the occlusion is of course
<soreau>
kennylevinsen: I don't understand what you mean by fancy occlusion
<ManMower>
I guess "fancy" == still in the scene graph and not just minimized away?
<ManMower>
(the general definition of "occluded" really)
<kennylevinsen>
Yeah, e.g. hidden behind an opaque surface
<kennylevinsen>
Opaque region, or buffer format that does not support transparency
<kennylevinsen>
(Checking if a surface that supports transparency is not transparent would be further than any reasonable compositor would go, so some seemingly occluded cases will not trigger occlusion)
<soreau>
so there's 'fancy occlusion' which means occluded by other surfaces, and then 'regular occlusion' which means 'not in the scenegraph because minimized or other workspace'?
<ManMower>
eh, it's just abstractions we're using right now to discuss how some compositors may behave, it's nothing in the spec :)
<soreau>
well, the spec seems to overstep the boundaries of a spec in some cases
<ManMower>
:)
<kennylevinsen>
Yeah, wlroots' wlr_scene does reasonably fancy occlusion in the scene graph
<soreau>
like requiring compositors to render black behind fullscreen semi-transparent surfaces
<ManMower>
I'm not going to step into the ring for that fight
<ManMower>
I think that's a security idea
<soreau>
ManMower: Ring Ding Ding! FIGHT!
<kennylevinsen>
Black behind fullscreen is not security, it's an optimization for video players and such IIRC
<soreau>
xD
<kennylevinsen>
And it's codified in the spec so...
<soreau>
kennylevinsen: yes but it's an overstep of a spec IMHO
<ManMower>
I'm not sure I've heard a complaint about that before. is there a use case it harms?
<kennylevinsen>
A usecase black harms? People wanting transparency in fullscreen primarily.
<ManMower>
if the intent is that fullscreen mean "exclusive fullscreen", then I think it makes sense to make such a requirement
<soreau>
I think when surface scanout is happening, you can't even have this? or what?
<soreau>
if the surface that's being scanned out is semi-transparent, what is 'behind' it?
<kennylevinsen>
You could directly scanout an overlay
<kennylevinsen>
On top of a composited primary plane
<ManMower>
depends on the video hardware. many have a concept of a solid color behind the scanout planes
<ManMower>
whether a compositor is "smart" enough to deal with such a thing... eh
<soreau>
however, wayfire manages to ignore this and do the expected thing of giving users an option for what's behind fullscreen surfaces, if anything
<ManMower>
I see no harm in that, but if people file bug reports against weston because it doesn't do that, there will be a race amongst several devs to see who can close the ticket first. :)
<soreau>
my point is, just because the spec makes some specific statement, doesn't mean the compositor is required to obey it, if it doesn't break desktop flow
<soreau>
in this case, it should be compositor choice, not spec-required
<soreau>
and that's my two bits
<kennylevinsen>
The point of the spec requirement is to allow the application to expect it and e.g. not draw black on its own, but yeah - don't think that was necessary
fmuellner has quit []
<soreau>
kennylevinsen: maybe for semi-transparent lock screens or something? idk
<kennylevinsen>
It is not made for security sensitive applications, no
<kennylevinsen>
and the protocols for that explicitly disallow transparency for security
<soreau>
now that part makes sense..
Leopold has quit [Remote host closed the connection]
i509vcb has joined #wayland
zvarde1988303206779191685 has joined #wayland
Leopold has joined #wayland
ara1307 has joined #wayland
<ara1307>
hi, how to properly connect to this channel from matrix client (element)? There is one public room - wayland on martrix.org, but it has only 22 people, looks not official
<zamundaaa[m]>
kennylevinsen: as not all compositors honor that, maybe we should just remove it from the spec?
<i509vcb>
ara1307: you need to register with chanserv from element
<i509vcb>
you'll need to PM chanserv over the matrix bridge for that
<zamundaaa[m]>
Apps can implement the same thing with subsurface + single pixel buffer now without requiring the compositor to special case fullscreen
V has quit [Ping timeout: 480 seconds]
<ManMower>
where is this "black surface" text we're discussing anyway? xdg-shell?
V has joined #wayland
<soreau>
zamundaaa[m]: that's a good point
<soreau>
ManMower: yes IIRC, fullscreen request?
<ManMower>
it doesn't appear to care about what's *behind* the surface at all. it forces drawing of black borders outside of the surface in the areas the client didn't cover
<soreau>
"If the fullscreened surface is not opaque, the compositor must make sure that other screen content not part of the same surface tree (made up of subsurfaces, popups or similarly coupled surfaces) are not visible below the fullscreened surface."
<ManMower>
I'm clearly looking in the wrong place. :)
<soreau>
:D
<ManMower>
ah, I managed to find an old unstable version of xdg-shell.
<ManMower>
I think it'd be fair for the content behind a non-opaque surface to be treated in the same way as the border fill. (implementation defined - so could just be the rest of the scene graph, shrug, you do you)
<soreau>
yea, it's just kinda silly to dictate
<ara1307>
i509vcb could you reference some step by step tutorial? Googling for "chanserv matrix element" gives very confusing results
<zamundaaa[m]>
ManMower: I'm referring to the border fill as well
<i509vcb>
ara1307: I think you can initate the PM via the OFTC Bridge Status room you get invited to when joining from Matrix
<ManMower>
zamundaaa[m]: I think border fill is definely loosely enough that you can do whatever you want with it right now without anyone being able to claim you're out of spec? :)
<ManMower>
"should be assumed to blend into the surrounding area" is pretty nebulous
<zamundaaa[m]>
KWin doesn't do border fill, or scaling fullscreen clients
<i509vcb>
I think @oftc-irc:matrix.org is the user you need to PM from matrix to get to the bridge status
<zamundaaa[m]>
So I can say with confidence that no client relies on it :)
<ManMower>
:D
<soreau>
heh
<kennylevinsen>
I wouldn't oppose a change, but more people needs to be convinced that there's no one depending on it
<kennylevinsen>
KDE users not complaining might not be enough on its own :)
<ManMower>
just rev bump the protocol at the same time so people have to make sure they're not depending on it before they update. ;)
<ManMower>
(nobody uses these protocols through toolkits, right?)
fmuellner has joined #wayland
<Arnavion>
The only stable toolkit is winapi through wine anyway :D
<RobertAyrapetyan[m]>
<soreau> "Robert Ayrapetyan: https://lists..." <- Hm, it suggests to use xkb_keymap_keycodes_from_keysym which is not part of the modern xkbcommon.h
sima has quit [Ping timeout: 480 seconds]
<soreau>
RobertAyrapetyan[m]: why are you needing to do this? can you not use keycodes directly?
<RobertAyrapetyan[m]>
soreau: I need to simulate a key press using zwp_virtual_keyboard_v1_key which seems accepts only keycodes
andreasbackx has joined #wayland
<soreau>
RobertAyrapetyan[m]: yes but can't you use keycodes as input instead of keysyms in the first place?
<RobertAyrapetyan[m]>
RobertAyrapetyan[m]: there is no way to obtain keycodes within a browser either as far as I know
<soreau>
you can get keycodes from within a client
<RobertAyrapetyan[m]>
soreau: but how? The client is a browser, to obtain keycodes which zwp_virtual_keyboard_v1_key accepts there must be a mapping created in JS. I would rather do it on the server
<RobertAyrapetyan[m]>
RobertAyrapetyan[m]: I'm trying to avoid creating hand-made mappings in all possible ways.
<RobertAyrapetyan[m]>
soreau: but gdk is not available in a browser. The client is a browser, it's a strict requirement
<soreau>
well, keycode + 8
<soreau>
RobertAyrapetyan[m]: you might have to ask the developers of the client to expose such API
<soreau>
it's possible but if you're not the client dev, you will need to ask them
<soreau>
the other way might be to just get the wl_display and setup listeners yourself
<soreau>
but idk what privs you have with the code/API you're using
<RobertAyrapetyan[m]>
Ah, no, in my scenario wayland server is running remotely and a client (chromium browser) sends keysyms, there is no access to wl_display on the client side
<Arnavion>
You're creating a browser VNC client thing?
<RobertAyrapetyan[m]>
keysym to keycode conversion will never become a part of Web API standard as it's too low level
<RobertAyrapetyan[m]>
Arnavion: kind of, webrtc based
mvlad has quit [Remote host closed the connection]
caveman has quit [Remote host closed the connection]
caveman has joined #wayland
<Arnavion>
You could check GTK Broadway source if it handles that somehow
<RobertAyrapetyan[m]>
Arnavion: yeah, they use conversion tables for keysyms which they copy-pasted from noVNC, which in turn borrowed same from somewhere else...
<Arnavion>
Yeah
<RobertAyrapetyan[m]>
Will leave this conversion table here for reference: https://developer.mozilla.org/en-US/docs/Web/API/UI_Events/Keyboard_event_code_values#code_values_on_linux_x11. X11 enables the conversion between these values, a functionality currently absent in Wayland. In my opinion, implementing this feature in Wayland should be considered a task for the future (using BFS or any other suitable method, as Wayland currently lacks support for
<RobertAyrapetyan[m]>
it).
<daniels>
it's not really the question you want to ask though
<daniels>
I mean, on a US keyboard layout, you can ask which keycode generates @, and the answer will be 'the third key in the number row'
<daniels>
but then you need to look at the key definition to understand that to generate @, you need Shift+AE03, not just raw AE03
<daniels>
for some other symbols you might need to be generating AltGr instead of shift as the modifier ... or sometimes both!
privacy has quit [Remote host closed the connection]
<RobertAyrapetyan[m]>
In the browser, when user presses "Shift" and then "2" (to print @ symbol) you can send "Shift_L" (is_pressed), "2" (is pressed), "2" (not pressed), "Shift_L" (not pressed) chain of events and both X11 and wayland handle it properly. So you don't have to deal with modifiers at all
azerov has quit []
azerov has joined #wayland
<daniels>
right, in that case, how-to-type is probably what you want, and just hope that you have a perfectly compatible mapping between the two
<daniels>
because if your browser sends Shift+2 for @ (because it's a US keyboard) and you replay that on your host with a UK layout, the output will be " because that's what Shift+2 generates there ...
<daniels>
(also if you type 'color' it'll output 'colour', but that's objectively an improvement)
<RobertAyrapetyan[m]>
The layout must be specified during the session establishment process to ensure consistent layouts on both the server and client.
<daniels>
right, in that case you want how-to-type
narodnik has quit [Remote host closed the connection]
andreasbackx has quit [Remote host closed the connection]
<daniels>
jadahl: ftr, I asked ManMower to eyeball your MR instead of me since he had co-ords rather more fresh in his head and I had the same questions as him; I assumed I was just being dense, but apparently not :P
nerdopolis has joined #wayland
<ManMower>
well, I'm glad your interpretation was present in existing comments, and that I read all of those comments before making my own, because otherwise someone might notice I don't know how to read.
<ManMower>
sigh. wait. it didn't happen that way at all.