01:14 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.
01:56 stooov: I made a bug report: https://bugs.kde.org/show_bug.cgi?id=478462
06:59 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.
07:00 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
07:17 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.
07:25 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
07:25 JoshuaAshton: And that isn't new, this has been done for a while.
07:29 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.
07:35 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.
07:39 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.
09:13 wlb: weston Merge request !1417 opened by Michael Olbrich (mol) ivi-shell: clear seat focus if necessary when a surface is destroyed https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1417
09:36 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.
09:38 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
09:49 pq: JoshuaAshton, I understand what I'm proposing cannot be retrofitted into existing games. That's fine.
09:50 pq: "every game is written by someone who doesn't know what event loop is" is the core problem in making advances.
09:51 pq: oh sorry, I missed a "not".
09:51 kennylevinsen: a very important one :D
09:53 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.
09:54 pq: JoshuaAshton, precise timestamps of when keys were pressed come with the input events, thought.
09:56 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).
09:56 pq: *one must run
09:56 pq: like it kicks yet another thread to run rendering
09:57 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.
09:59 pq: the main point is that the main loop is never blocked or spending great amounts of time in anything else than epoll() equivalent.
09:59 pq: which indeed makes my "main loop" sound like the "input event loop"
10:01 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.
10:03 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.
10:03 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
10:04 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.
12:04 pq: swick[m], would you like to clean up some of the left-over branches in your wayland-protocols?
12:30 swick[m]: pq: can do
12:30 pq: thanks!
18:11 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
18:12 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
18:14 ManMower: depth buffer readback is "very fast"?
18:15 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
18:15 pac85: ManMower: assuming you do the simulation on the gpu
18:17 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
18:19 ManMower: fair enough, I just did a quick read and a hot take. ;)
18:25 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.
18:27 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...
18:28 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
18:29 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)
18:29 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
18:30 pac85: kennylevinsen I think it helps to know what a game looks like to understand whether an idea is good or not.
18:31 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
18:33 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?
18:35 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
18:35 kennylevinsen: Between two very opinionated groups
18:35 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)
18:35 kennylevinsen: Nothing about Wayland at all really :)
18:36 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
18:38 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
18:41 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
18:43 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
18:44 riteo: ManMower: it all popped up because of issues I stumbled upon while working on a Wayland backend for godot
18:44 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...
18:44 ManMower: I guess lock ups on occlusion has been the center of a lot of this kind of discussion over the years
18:45 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?)
18:45 riteo: indeed, it's all related to lock up on occlusion, at least from my PoV
18:45 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
18:45 riteo: also tangentially frame timing as apparently the fact that we don't have a proper queue makes frame times kinda jittery
18:46 ManMower: riteo: is testing my proposed fix for this something you'd be interested in doing?
18:46 riteo: absolutely!
18:46 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
18:47 ManMower: kennylevinsen: FIFO requires every committed state to be made visible. without additional protocol wayland is a bit too mailbox for that?
18:47 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
18:47 ManMower: riteo: what compositor do you test under?
18:47 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?
18:48 ManMower: kennylevinsen: spec requires commit in present
18:48 riteo: ManMower: sway-git usually, the one I have on both my laptop and my desktop
18:48 riteo: I can setup something else though if that's needed
18:49 ManMower: riteo: ah, sadly I only have mutter working right now
18:49 riteo: eh, I can use mutter
18:49 kennylevinsen: ManMower: yes? I mean it's not *nice* to have autonomous surface commits...
18:51 kennylevinsen: Hmm well that would require dispatching
18:52 kennylevinsen: And then we're getting back to the former discussion lol
18:52 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
18:52 kennylevinsen: ugh I don't like WSIs and I never will
18:52 ManMower: kennylevinsen: haha, I'm starting to wonder if anyone likes WSIs.
18:53 soreau: ManMower: but doesn't this require compositor 'support' for not sending frame events to occluded clients in the first place?
18:54 kennylevinsen: compositors not sending frame events to occluded clients is the baseline, although how fancy occlusion is differs
18:55 ManMower: soreau: sorry, I don't understand the question. but I don't change how frame events work
18:55 ManMower: weston sends frame events to occluded clients :(
18:55 soreau: right, I don't really know which compositors don't
18:55 ManMower: but I think with last release cycle's changes, that's become very easy to fix
18:55 kennylevinsen: what about minimized clients?
18:55 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)
18:55 kennylevinsen: there's a difference in how fancy the occlusion is of course
18:56 soreau: kennylevinsen: I don't understand what you mean by fancy occlusion
18:56 ManMower: I guess "fancy" == still in the scene graph and not just minimized away?
18:56 ManMower: (the general definition of "occluded" really)
18:56 kennylevinsen: Yeah, e.g. hidden behind an opaque surface
18:57 kennylevinsen: Opaque region, or buffer format that does not support transparency
18:58 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)
18:58 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'?
18:58 ManMower: eh, it's just abstractions we're using right now to discuss how some compositors may behave, it's nothing in the spec :)
18:59 soreau: well, the spec seems to overstep the boundaries of a spec in some cases
18:59 ManMower: :)
18:59 kennylevinsen: Yeah, wlroots' wlr_scene does reasonably fancy occlusion in the scene graph
18:59 soreau: like requiring compositors to render black behind fullscreen semi-transparent surfaces
18:59 ManMower: I'm not going to step into the ring for that fight
18:59 ManMower: I think that's a security idea
18:59 soreau: ManMower: Ring Ding Ding! FIGHT!
18:59 kennylevinsen: Black behind fullscreen is not security, it's an optimization for video players and such IIRC
18:59 soreau: xD
19:00 kennylevinsen: And it's codified in the spec so...
19:00 soreau: kennylevinsen: yes but it's an overstep of a spec IMHO
19:00 ManMower: I'm not sure I've heard a complaint about that before. is there a use case it harms?
19:01 kennylevinsen: A usecase black harms? People wanting transparency in fullscreen primarily.
19:01 ManMower: if the intent is that fullscreen mean "exclusive fullscreen", then I think it makes sense to make such a requirement
19:01 soreau: I think when surface scanout is happening, you can't even have this? or what?
19:01 soreau: if the surface that's being scanned out is semi-transparent, what is 'behind' it?
19:01 kennylevinsen: You could directly scanout an overlay
19:01 kennylevinsen: On top of a composited primary plane
19:02 ManMower: depends on the video hardware. many have a concept of a solid color behind the scanout planes
19:02 ManMower: whether a compositor is "smart" enough to deal with such a thing... eh
19:02 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
19:04 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. :)
19:04 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
19:04 soreau: in this case, it should be compositor choice, not spec-required
19:04 soreau: and that's my two bits
19:06 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
19:08 soreau: kennylevinsen: maybe for semi-transparent lock screens or something? idk
19:10 kennylevinsen: It is not made for security sensitive applications, no
19:10 kennylevinsen: and the protocols for that explicitly disallow transparency for security
19:11 soreau: now that part makes sense..
19:31 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
19:32 zamundaaa[m]: kennylevinsen: as not all compositors honor that, maybe we should just remove it from the spec?
19:32 i509vcb: ara1307: you need to register with chanserv from element
19:32 i509vcb: you'll need to PM chanserv over the matrix bridge for that
19:33 zamundaaa[m]: Apps can implement the same thing with subsurface + single pixel buffer now without requiring the compositor to special case fullscreen
19:36 ManMower: where is this "black surface" text we're discussing anyway? xdg-shell?
19:37 soreau: zamundaaa[m]: that's a good point
19:37 soreau: ManMower: yes IIRC, fullscreen request?
19:37 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
19:38 soreau: https://wayland.app/protocols/xdg-shell#xdg_toplevel:request:set_fullscreen
19:38 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."
19:38 ManMower: I'm clearly looking in the wrong place. :)
19:39 soreau: :D
19:39 ManMower: ah, I managed to find an old unstable version of xdg-shell.
19:42 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)
19:43 soreau: yea, it's just kinda silly to dictate
19:44 ara1307: i509vcb could you reference some step by step tutorial? Googling for "chanserv matrix element" gives very confusing results
19:44 zamundaaa[m]: ManMower: I'm referring to the border fill as well
19:46 i509vcb: ara1307: I think you can initate the PM via the OFTC Bridge Status room you get invited to when joining from Matrix
19:46 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? :)
19:46 ManMower: "should be assumed to blend into the surrounding area" is pretty nebulous
19:46 zamundaaa[m]: KWin doesn't do border fill, or scaling fullscreen clients
19:46 i509vcb: I think @oftc-irc:matrix.org is the user you need to PM from matrix to get to the bridge status
19:46 zamundaaa[m]: So I can say with confidence that no client relies on it :)
19:47 ManMower: :D
19:49 soreau: heh
19:49 kennylevinsen: I wouldn't oppose a change, but more people needs to be convinced that there's no one depending on it
19:50 kennylevinsen: KDE users not complaining might not be enough on its own :)
19:52 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. ;)
19:52 ManMower: (nobody uses these protocols through toolkits, right?)
19:57 Arnavion: The only stable toolkit is winapi through wine anyway :D
20:01 soreau: though I doubt anyone cares to make it a real issue, so long as it works - https://streamable.com/nihxyt
20:08 RobertAyrapetyan[m]: hello, how to obtain "key" need to be sent into zwp_virtual_keyboard_v1_key? Here is an example from X11 world:... (full message at <https://matrix.org/_matrix/media/v3/download/matrix.org/tonwZeCLzlpWunCJOzvFiHSO>)
20:24 soreau: RobertAyrapetyan[m]: https://lists.freedesktop.org/archives/wayland-devel/2015-June/022409.html
20:56 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
20:59 soreau: RobertAyrapetyan[m]: why are you needing to do this? can you not use keycodes directly?
21:01 RobertAyrapetyan[m]: soreau: I need to simulate a key press using zwp_virtual_keyboard_v1_key which seems accepts only keycodes
21:01 soreau: RobertAyrapetyan[m]: yes but can't you use keycodes as input instead of keysyms in the first place?
21:07 RobertAyrapetyan[m]: <soreau> "Robert Ayrapetyan: yes but can't..." <- unfortunately no, keys are coming from the web browser (https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/code) where codes are keysym-s.
21:08 RobertAyrapetyan[m]: RobertAyrapetyan[m]: there is no way to obtain keycodes within a browser either as far as I know
21:10 soreau: you can get keycodes from within a client
21:12 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
21:13 soreau: https://docs.gtk.org/gtk3/signal.Widget.key-press-event.html https://developer-old.gnome.org/gdk3/stable/gdk3-Event-Structures.html#GdkEventKey <-- for example the hardware_keycode field in gtk3 is the keycode
21:13 RobertAyrapetyan[m]: RobertAyrapetyan[m]: I'm trying to avoid creating hand-made mappings in all possible ways.
21:14 RobertAyrapetyan[m]: soreau: but gdk is not available in a browser. The client is a browser, it's a strict requirement
21:14 soreau: well, keycode + 8
21:14 soreau: RobertAyrapetyan[m]: you might have to ask the developers of the client to expose such API
21:14 soreau: it's possible but if you're not the client dev, you will need to ask them
21:15 soreau: the other way might be to just get the wl_display and setup listeners yourself
21:15 soreau: but idk what privs you have with the code/API you're using
21:17 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
21:18 Arnavion: You're creating a browser VNC client thing?
21:18 RobertAyrapetyan[m]: keysym to keycode conversion will never become a part of Web API standard as it's too low level
21:18 RobertAyrapetyan[m]: Arnavion: kind of, webrtc based
21:28 Arnavion: You could check GTK Broadway source if it handles that somehow
21:29 Arnavion: https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gdk/broadway/broadway.js#L2952-2957 -> https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gdk/broadway/broadway.js#L2804-2809
21:32 RobertAyrapetyan[m]: Arnavion: yeah, they use conversion tables for keysyms which they copy-pasted from noVNC, which in turn borrowed same from somewhere else...
21:32 Arnavion: Yeah
21:32 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
21:32 RobertAyrapetyan[m]: it).
21:33 daniels: it's not really the question you want to ask though
21:34 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'
21:34 daniels: but then you need to look at the key definition to understand that to generate @, you need Shift+AE03, not just raw AE03
21:34 daniels: for some other symbols you might need to be generating AltGr instead of shift as the modifier ... or sometimes both!
21:36 daniels: https://github.com/xkbcommon/libxkbcommon/blob/master/tools/how-to-type.c shows you how to get the modifier+keycode, but then you need to go figure out how to generate the modifier in the first place, which is mindblowingly tedious
21:41 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
21:43 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
21:44 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 ...
21:45 daniels: (also if you type 'color' it'll output 'colour', but that's objectively an improvement)
21:46 RobertAyrapetyan[m]: The layout must be specified during the session establishment process to ensure consistent layouts on both the server and client.
21:58 daniels: right, in that case you want how-to-type
22:11 soreau:colors daniels always-correct
22:56 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
23:03 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.
23:03 ManMower: sigh. wait. it didn't happen that way at all.
23:10 daniels: hahaha