02:54 wlb: weston Issue #850 opened by liang zhou (snow) Multi-GPU hot plug https://gitlab.freedesktop.org/wayland/weston/-/issues/850
07:25 E_Megas: Simple question: How do I show the names of all available displays in Wayland? I'm trying to get conky to run wayland-native and need to feed nvidia_display the proper display name.
07:27 E_Megas: kinfocenter has given me some names, but none of them are working. I need some kind of specific display identifier that this information isn't providing.
07:55 davidre: E_Megas: Without knowing what you want or if you are using some toolkit, wl_output has name and description events
07:55 davidre: Darn to slow
08:13 davidre: robert.mader: Sorry for ignoring you on chromium-review. Seems I misconfigured emails somewhere, I just saw your messages from August/October...
09:15 robertmader[m]: David Redondo: No worries, thanks for working on that protocol!
09:23 wlb: weston Merge request !1411 opened by Philipp Zabel (pH5) man: Document VNC --address argument https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1411
09:59 Martin42: Hello Wayland team, I am looking for the documentation of weston.ini, but specific for version 10. I found only this manpage, but it doesn't specify the specific version: https://www.mankier.com/5/weston.ini. Thanks for the help :-)
10:00 kennylevinsen: Martin42: https://gitlab.freedesktop.org/wayland/weston/-/blob/main/man/weston.man?ref_type=heads, you can select whatever release you want in the drop-down that says "main"
10:01 kennylevinsen: to read it, download it and do `man ./path/to/file`
10:04 Martin42: @kennylevinsen found it, thanks for your help, have a great day!
10:56 wlb: weston Issue #838 closed \o/ (Launching application in Weston Kiosk from systemd service https://gitlab.freedesktop.org/wayland/weston/-/issues/838)
11:24 wlb: weston/main: Philipp Zabel * man: Document VNC --address argument https://gitlab.freedesktop.org/wayland/weston/commit/ddf432711605 man/weston-vnc.man
11:24 wlb: weston Merge request !1411 merged \o/ (man: Document VNC --address argument https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1411)
11:42 wlb: weston Issue #834 closed \o/ (Weston dual screen issue at imx8 https://gitlab.freedesktop.org/wayland/weston/-/issues/834)
12:22 wlb: weston/main: Daniel Stone * 7 commits https://gitlab.freedesktop.org/wayland/weston/compare/ddf4327116059a0522f2625e2a136377b7a9f7db...a5c5702112a9ccbf6abbbaac6078982f5f84bb2e
12:22 wlb: weston Merge request !1401 merged \o/ (Yet more surface/view mapping cleanups https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1401)
16:07 romangg: Is wl_display_add_socket_fd used in practice? It was added for some systemd feature https://gitlab.freedesktop.org/wayland/weston/-/commit/265aeb31, but when looking at the source of some wlroots compositors, I didn't see it being implemented there.
16:07 emersion: it's used by security-context iirc
16:08 romangg: It's server-side interface though. How would this relate to security-context? Server gets the socket fd from some trusted source?
16:10 romangg: Ah, the client sends a new fd, then server should add it?
16:21 emersion: yea
16:30 riteo: mh, quick dumb question: should I manually call `wl_surface_commit`?
16:30 vyivel: yes?
16:31 riteo: It looks like obviously when I set a new buffer scale after scaling and commit later for whatever reason before rendering it messes up
16:31 vyivel: no requests are made automatically
16:31 riteo: sorry, should've been clearer
16:31 vyivel: ah
16:31 riteo: like, we have a vulkan/EGL render loop that internally calls wl_surface_commit
16:31 vyivel: you have set the buffer scale and the corresponding buffer in the same commit
16:31 riteo: we can't really do that with Godot
16:32 riteo: the rendering is done in a whole different place and we don't have any sort of fancy hook for that
16:32 vyivel: not sure what to do here then
16:32 riteo: mh, _maybe_ I can set the buffer scale without committing right before drawing
16:32 riteo: now that you let me think about it
16:33 riteo: but it feels kinda weird to me. I'm wondering if I should just not call `wl_surface_commit` at every single dumb windowing Godot API call and simply wait for the next frame
16:33 vyivel: you can, assuming you only commit on render and the next buffer is guaranteed to have the new scale
16:33 vyivel: "if I should just not call `wl_surface_commit` at every single dumb windowing Godot API call" most probably yes
16:34 riteo: yes as in "not calling" or yes as in "you should call"
16:34 vyivel: not calling
16:34 riteo: mh I see
16:34 vyivel: i think that's what is usually done actually
16:34 riteo: it actually makes a lot of sense loll
16:35 vyivel: just store the new state and remember that a new frame is required or something
16:35 riteo: mh we've got a pretty generic abstraction
16:35 riteo: since cross-platform and all that
16:36 riteo: I _think_ I can just let that queue up in the native wayland event queue and call it a day?
16:36 riteo: let's see how this goes, thanks for the help!
16:36 vyivel: until a commit, the pending state will stay pending
16:37 vyivel: np, good luck
17:03 riteo: all right, status update: libdecor commits on every operation probably for the same reason we do it too, to make it feel "snappier", as we have no control on whether the drawing thread will stall or slow down for whatever reason
17:04 riteo: so I just called `wl_surface_set_buffer_scale` right after marking the window for drawing in the frame callback and it seems to work fine, at least on sway!
17:05 riteo: so, yeah, weird stuff. Maybe one day we'll be able to make rendering better integrated with Wayland, but this will do :)
17:10 MrCooper: committing every state change separately defeats the purpose of atomic state commits
17:17 riteo: weirdly libdecor does too
17:17 riteo: I suppose that it's to avoid for the state to, well, change only between frames
17:19 MrCooper: it means the user may see inconsistent state, violating the Wayland "every frame is perfect" motto
17:20 riteo: how can it be inconsistent?
17:22 riteo: the only inconsistency I've noticed is this buffer scaling one.
17:23 Company: opaque region can be visible, too, but it's harder to spot
17:23 Company:knows because he fixed a bug with opaque regions yesterday
17:26 riteo: mh
17:26 riteo: thinking about it, I worked so hard on a separate wayland event thread exactly to uncouple the backend from the renderer (it's currently main-thread and it was giving various issues regarding to event thread overflow)
17:26 emersion: for instance you were setting the scale separately from the new buffer earlier
17:27 riteo: I think I can commit during frame callbacks
17:27 riteo: also I'm not so sure anymore that the WSI actually commits
17:27 emersion: without atomicity, the user might see a frame with the old buffer scaled
17:27 MrCooper: riteo: nothing can be presented without a commit :)
17:27 emersion: for instance, if your window is 100x100 scale 1, then you set scale 2, the window will appear as 50x50
17:27 emersion: on-screen
17:28 riteo: emersion: the user will sadly always see some inconsistincies for now as we don't really have much choice when it comes to hooking up with the renderer
17:28 emersion: later on, your client will commit a proper 200x200 buffer, and the appearance will revert to 100x100
17:28 emersion: nonetheless, there will be an intermediate bad state
17:28 riteo: like, if the user has a viewport available and fracscale, it will probably see a frame of a stretched out fame
17:28 riteo: frame
17:28 wlb: weston Merge request !1412 opened by Derek Foreman (derekf) clients/simple-egl: Allow setting the swapinterval https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1412 [Clients]
17:28 Company: to be fair, getting rendering right on Wayland sucks
17:29 Company: because GL/Vulkan just randomly call commit()
17:29 emersion: not randomly
17:29 Company: and hook random properties
17:29 emersion: on eglSwapBuffer only
17:29 emersion: and it's a guarantee
17:29 riteo: we currently have pretty much only a main thread renderer, so we're handling rendering in a pretty funky way through some signalling and cleverness
17:30 riteo: hopefully we'll be able to sort this out, perhaps with the multithreaded renderer but I'm not really that experienced with rendering
17:30 Company: yeah, but feels kinda random - I'd like to have a way where they just attach a buffer and I can call commit myself()
17:30 ManMower: why?
17:31 Company: because it forces me to engineer my code around that, by ensuring that I have everything properly set up before calling into the rendering code
17:32 riteo: yeah I'm having a similar issue
17:32 emersion: i'd also prefer a WSI which lets you handle the buffers
17:32 riteo: rn we have backend ticking before the rendering loop
17:32 emersion: vulkan kinda-of does this
17:32 riteo: so I don't really have much of a choice on when to commit I think
17:33 ManMower: istr vulkan mandates a commit in vkQueuePresent
17:33 riteo: I could do some cleverness at the start but I'd really like to handle this at the frame callback since we also tick independently and also have a separate event handling queue
17:34 Company: ManMower: yeah, but you can always queue some fancy new extension into it that makes it not do that
17:34 riteo: mh I think I can definitely reduce the amount of commits though, but I'll still have to be careful and send buffer-related data _after_ my own "custom" commit
17:34 Company: threaded rendering is another issue - I'd like to have a nice interface at the thread boundary
17:34 MrCooper: riteo: BTW, I suspect libdecor commits only the synchronized sub-surfaces it uses for the decorations separately, which takes effect only the next time the application commits the parent surface
17:35 Company: and passing wl_buffers would be a nice interface
17:35 riteo: MrCooper: nope, it has a special event for committing the toplevel it's attached to
17:35 riteo: and it calls it every time it changes the title or whatever
17:35 riteo: it's quite explicitly called `libdecor_frame_toplevel_commit`
17:35 MrCooper: sounds wonky
17:35 Company: ie the rendering thread renders to a wl_buffer, hands that off to the main thread, and the main thread can commit() it with everything else
17:36 riteo: mh, so it looks like it's not really possible to have an absolutely atomic surface update logic, at least with some architectures
17:36 riteo: am I understanding correctly?
17:37 Company: currently that doesn't work, both because vkQueuePresent() calls commit() but also because it fiddles with other surface properties - like damage region
17:37 riteo: (by architecture I'm referring to the actualy way the program is structured)
17:37 MrCooper: Company: you can do all the Wayland protocol handling yourself if you don't need an EGLsurface
17:38 Company: MrCooper: yeah, I'm aware - but Mesa has a ton of code around format negotiation that I don't want to copy - because I'll end up with slight differences and then random compositors start breaking
17:39 MrCooper: another option might be an EGLsurface with the GBM platform
17:39 MrCooper: guess that won't help for format negotiation though
17:39 Company: that might change when Vulkan gets more common
17:40 Company: and GL + Vulkan + another Vulkan config + another Vulkan config + ... start existing
17:44 riteo: so, I've tried moving all window commits to its frame callback and it's a bit wonky when it comes to viewport scaling :(
17:45 riteo: it looks like it has a bit of trouble catching up with the flow of reconfigurations
17:45 riteo: wait I'm making sure
17:54 riteo: nvm, was always like that. Got influenced by the idea that it might've been worse
17:54 riteo: it genuinely looks like committing only on frames and only then prepping up buffer-dependant data in preparation for the renderer might be a good compromise
17:55 riteo: not ideal but I think that it might be better for the whole atomicity thing, right?
17:55 riteo: oh wait but what about titles changing while the window is tabbed/minimized?
17:56 riteo: that might be another reason that libdecor instantly commits stuff like title changes, to let them show up when the window is "hidden"
17:56 MrCooper: show up where, if it's hidden?
17:57 riteo: dunno, like in the tabbed container of Sway or the icon bar on KDE
17:57 riteo: there's no actual frame callback getting, well, called, but there's still useful metadata that _has_ to be given through surface committing
17:57 MrCooper: for consistency, ideally the only surface commit should be the one in eglSwapBuffers / vkQueuePresent
17:58 riteo: yeah, but it's impossible without losing functionality
17:58 riteo: stuff like max-min sizes I think could be deferred to the frame callback, but stuff like app id and title must be instantly committed
17:59 MrCooper: is that double-buffered state in the first place?
17:59 riteo: mh, IIRC yes, lemme double check
18:00 riteo: uh
18:00 riteo: looks like it isn't
18:00 riteo: sorry
18:01 riteo: well, this sounds pretty sweet then!
18:01 riteo: like, all double-buffered state is always visible only per frame so committing it at least there should already improve stuff a lot
18:02 riteo: I'm not sure if I can get rid of the frame callback commit as for some reason it looks like it doesn't "restart", but that might be just me being dumb
18:03 riteo: I'd argue that it'd pretty darn close to atomic though if you ask me, so it'd definitely be an improvement I think
18:03 ManMower: restart? you get one frame callback per wl_surface_frame()+wl_surface_commit()
18:03 riteo: yeah, but I then destroy it an allocate a new one with wl_surface_frame
18:04 ManMower: that's appropriate, yeah
18:04 riteo: but that's the thing, I'd have to commit to "register it" properly
18:04 ManMower: yeah, it's double buffered state
18:04 riteo: so we're at two commits, one before rendering and one at buffer presentation
18:04 riteo: because godot's rendering architecture, and this was already a stretch in some ways
18:05 riteo: I'd assume that it'd get registered at the buffer presentation but I feel like something goes wrong, probably because we actually use MAILBOX
18:05 riteo: yeah this gets into cursed stuff territory
18:05 riteo: basically we "emulate" vsync by messaging to godot when to draw by listening to the frame request
18:05 riteo: it's ugly ugly ugly _ugly_ but it works good enough for now
18:13 riteo: yeah all right just realized we can't do better than two commits
18:13 riteo: I think mostly because the renderer is "lazy", especially in UI only projects, so we're done I think
18:14 riteo: well, thanks a lot, folks! This was a very educational and useful discussion!
18:15 ManMower: so you do frame+commit, wait for that, then render+commit, then at some point in the future some kind of event tells you you'd like to generate an image again and you repeat?
18:16 riteo: so, the new state of things is as such: we frame+commit, set buffer-dependant data and send a message to the main thread to draw which in turn comes to the attention of the main loop that we should draw at this iteration instead of just ticking
18:16 riteo: thing is, it's not even guaranteed that we'll have a new buffer, unless we tell it that the window size e.g. changed (this includes scaling because we have our own scaling logic)
18:17 riteo: or the content changes obv
18:17 riteo: that's not always turned on (e.g. in games its not), but godot has also a lot of UI only projects, such as the editor itself, which use a lazier render mode
18:18 riteo: as I said this is mostly a hack to not stall the whole main loop since otherwise the driver will wait forever until it gets a frame event
18:18 ManMower: starting to get that. cursed indeed. :(
18:19 ManMower: isn't the first frame+commit only really required to get things rolling, and from that point on you could add the wl_surface_frame() call before the render commit?
18:19 riteo: that's the thing
18:19 riteo: we _could_
18:19 riteo: but then it's not _guaranteed_ that we'll actually get a new frame
18:19 riteo: since lazy rendering
18:19 riteo: like, if it's a game and doesn't have that feature turned on, cool, but the editor and project manager has it turned on by default
18:20 riteo: no new frame, no commit
18:20 ManMower: I mean, you could also post MAX_INT,MAX_INT damage :(
18:20 riteo: on a "stale" buffer :(
18:20 riteo: or are you implying that it'd call a new frame event
18:21 riteo: that would still not unlock the main loop to ask a new draw iteration
18:21 riteo: consider though that the backend is currently a floating branch PR/MR something, it's not yet merged
18:21 ManMower: yeah maybe don't do that. I'm not sure what a compositor will make of it.
18:21 riteo: once it will be we'll perhaps be able to adapt godot better to wayland's particular rendering architecture
18:21 ManMower: "I never released this buffer, yet you're tellilng me it's dirty? die." seems reasonable
18:21 riteo: ManMower: indeed
18:22 riteo: as I said this cursed hack works kinda well, as long as we tick at a reasonable rate
18:22 riteo: hopefully either with the MT renderer (if that's even a proper solution for this issue) or with some other solution we'll be able to make it cleaner
18:22 riteo: but we gotta first merge it, which is going to happen soon since 4.3 started a week ago or something
18:24 riteo: it's a pull-push thing really. "Wayland adapts" a bit, godot "adapts" a bit too
18:24 riteo: we also have like 5 platforms to support too with the same API after all
18:24 riteo: maybe more
18:27 riteo: BTW I'd really be curious to know why libdecor has this whole "let's commit the toplevel" thing
18:28 riteo: I'm pretty darn sure that it shouldn't care
18:31 riteo: tbh libdecor's a bit funky, it has some weird bugs, one of which I recently reported. Most of those aren't exactly trivial to fix I think, hence why I didn't make a MR
20:29 wlb: weston Merge request !1413 opened by Loïc Molinari (molinari) Improve clipper tests https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1413