08:14 pq: kchibisov, I would always recommend client code to ack a configure from the draw path, and not from the event received code.
08:15 pq: kchibisov, I consider sending the ack from event configure handler a poor code design.
08:17 pq: *from the configure event handler
08:20 pq: kchibisov, btw. about Rust glutin and winit; can you say anything about winit maybe exposing the equivalent of a wl_surface.frame callback event?
08:21 pq: on Wayland it would be exactly the frame callback, and on other platforms if winit cares it might be anything roughly corresponding or even a timer if there is really nothing else.
08:40 vyivel: pq: the confusion might stem from xdg-shell.xml saying "A client is not required to commit immediately after sending an ack_configure request"
08:54 pq: emersion, swick[m], TIL that wxEDID is a GUI EDID editor, but apparently it has no public code repository, just release archives. Available as flatpak it seems.
10:36 kchibisov: pq: not yet. https://github.com/rust-windowing/winit/pull/2896
10:52 wlb: weston Issue #770 closed \o/ (Timeline debug scope crash at start-up / begin fence sync https://gitlab.freedesktop.org/wayland/weston/-/issues/770)
11:08 pq: swick[m], looks like edid-decode got support for SBTM block.
11:09 pq: kchibisov, oh, it's coming already, nice!
11:32 swick[m]: pq: the SBTM information isn't useful to me without more information
11:32 swick[m]: wxEDID looks nice. could be handy to craft test cases.
11:35 swick[m]: and hdmi 2.1a is still not... widely available.
11:53 zubzub: How/where is the egl implementation for wayland client done? I found: https://gitlab.freedesktop.org/wayland/wayland/-/tree/main/egl but I don't understand how it's coupled with the egl api's
11:56 zubzub: hmm this seems to give some more pointers: https://jan.newmarch.name/Wayland/EGL/
12:02 daniels: zubzub: mesa/src/egl/drivers/dri2/platform_wayland.c mostly
12:02 daniels: why?
12:08 zubzub: writing an emscripten wasm shim for wayland+egl
12:08 zubzub: was wondering how it currently works for native implementatins
12:12 zubzub: why is there an intermediate wayland-client-egl (eg. wl_egl_window_create call)
12:17 daniels: ooof
12:19 zubzub: https://tinyurl.com/3yj567y3
12:20 zubzub: I have the whole thing already working, except for the egl abstraction part
12:21 daniels: the intermediate shim is required to make sizes work
12:21 daniels: in X11, you create a Window with an innate size and then just point EGL at that - it can query to see what the size is and adjust
12:21 daniels: since surfaces don't have an innate size in Wayland, the wayland-egl lib is just there to create a tiny wrapper which holds current & user-requested size
12:22 zubzub: right makes sense
12:31 wlb: wayland-protocols Merge request !228 opened by Carlos Garnacho (carlosg) staging/dialog: Add "dialog" protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/228 [In 30 day discussion period], [Needs acks], [Needs implementations], [Needs review], [New Protocol]
12:31 wlb: wayland-protocols Merge request !229 opened by Carlos Garnacho (carlosg) staging/wm-gestures: Add WM "gestures" protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/229 [In 30 day discussion period], [Needs acks], [Needs implementations], [Needs review], [New Protocol]
12:59 pq: swick[m], when you load a display profile from an ICC file, and then a client asks for that profile, do you: a) give the original file contents as-is, or b) since you parsed it with LittleCMS, let LittleCMS re-serialize it?
13:07 pq: I'm not sure if LittleCMS would produce a byte-identical copy, especially if the ICC file had tags it doesn't parse. OTOH, if LittleCMS does not parse something, then the compositor won't understand it either.
13:21 emersion: why do we have a "Spam" label in wayland-protocols?
13:21 emersion: it seems unused
13:22 pq: emersion, it's the damspam mechanism, right?
13:22 emersion: damspam?
13:23 pq: slap it on an issue, and the author gets immediately blocked
13:23 emersion: i see
13:24 pq: rather than the "report spam" button which waits for some human to come around and look, while the spammer creates more spam
13:25 pq: wonder where it's documented...
13:25 pq: https://gitlab.freedesktop.org/freedesktop/damspam looks like
13:29 pq: actually more than blocked: it hides every issue the author had created, not just the labeled one
14:35 riteo: hi!
14:36 riteo: I'm working on godot, a FOSS game engine with a pretty complex windowing API and I'm attempting to change its API in a way that allows wayland to work with it
14:37 riteo: The reason I'm here is: is popup grabbing supposed to be used everywhere? It requires input serials and I can't seem to make it work for some reason
14:38 riteo: currently every other platform sends keyboard input to it manually, even when it looks like it grabs I can't dismiss the popup by clicking outside its geometry and it goes away when I focus out of the parent anyways
14:38 riteo: am I missing something?
14:39 jadahl: riteo: you should use grabbing popup if you want your popups to be automatically dismissed when e.g. the user clicks outside any of your windows, the lock screen appears and things like that
14:40 riteo: currently when I focus out it closes itself. That might be something that godot does
14:40 jadahl: there are some implementation details about pointer and keyboard focus, but in the end you can route however you want within your client
14:42 jadahl: running your client with WAYLAND_DEBUG=1 then looking at what requests to xdg_popup is done or what events are emitted can answer why your popup closes
14:42 riteo: yeah all right, mistery solved
14:42 jadahl: as in answer whether it's dismissed by the compositor, or the client itself
14:42 riteo: popups close themselves when focused out in godot
14:42 riteo: it's a godot thing
14:42 jadahl: \o/
14:42 riteo: like, when they receive a global focus out event they close themselves
14:42 riteo: should I still grab?
14:43 jadahl: if you want them to be auto-dismissed yes. e.g. if you click outsid, but it's on the desktop background, you wouldn't loose keyboard focus
14:43 jadahl: or wouldn't, you can't rely on loosing keyboard focus
14:44 riteo: it currently listens for a "global" application focus out event though
14:44 jadahl: (I'm assuming "global focus out" is keyboard focus or "activated" xdg-toplevel state)
14:44 riteo: oh I think it's actually pointer focus
14:44 riteo: yeah I'm not sure what would be the most reliable way
14:44 riteo: definitely not activated AFAIK
14:46 jadahl: pointer focus you loose as soon as the pointer leaves your window
14:46 riteo: that explains the weird behaviour
14:47 riteo: so I should rely on the keyboard focus, right?
14:47 riteo: sorry for all of the questions
14:47 jadahl: depends on what you're after
14:48 riteo: I'm not sure really. I'm trying to adapt an already existing, heavily Windows-like API which has only the concept of "focus"
14:48 riteo: yeah thinking about it keyboard focus would be better
14:48 jadahl: is it used for traditional File menus and such things?
14:48 jadahl: if so you can probably make it a grabbing popup and call it a day
14:49 riteo: do you mean the popups? Yeah, the ones that should auto-close are indeed dropdowns
14:49 jadahl: except you should hide when clicking outside the popup
14:49 riteo: all right, now I get the reasoning
14:49 riteo: thanks a lot for the help!
14:50 jadahl: so: makem them grabbing popup. destroy them when anything outside them gets clicked (or touched). destroy them on e.g Esc.
14:50 jadahl: destroying on keyboard focus lost I suspect is redudant, they'll probably be dismissed by the compositor before that
14:51 riteo: the weird thing is that destroying when clicked outside is platform-side, while focus out closing is engine-side
14:51 jadahl: riteo: fyi, when you create nested menus, the order of destruction is important
14:52 jadahl: riteo: doesn't hurt if you close on keyboard focus lost too I guess, if that's what you want
14:52 riteo: luckily there's some ordering so it shouldn't be an issue
14:52 jadahl: riteo: that is, keyboard of all your windows/popups, because a grabbing popup gets keybord focus when popped up
14:53 riteo: uh right
14:53 riteo: I think that the reasoning behind a global focus out is when no window is left focused that is godot's
14:54 riteo: so... I think I should be set?
14:54 jadahl: sounds like it, assuming popups are encountered for among those windows
14:54 riteo: great, thanks for the help once again!
14:54 jadahl: though, I can't remember the exact order of focus changes when going from parent to popup etc
14:55 jadahl: so might want to double check
14:55 riteo: I'm still doing a PoC so there's plenty of room for errors
14:55 jadahl: sounds like fun!
14:55 riteo: (I have to change the API, that's why)
15:01 kchibisov: Could I assume that server will immidiatelly destroy the objects, so I want to wait all objects being destroyed I could wait with wl_display.sync()? Or is it not enough and server could destroy things later on?
15:03 kchibisov: I'm trying to understand how to wait for wl_surface/toplevel being destroyed, before I 'pause' the loop.
15:14 d_ed[m]: what do you mean by pause the loop?
15:21 emersion: a wl_display.sync will ensure that the server has seen the destroy requests
15:43 riteo: well, I'll go for now. Bye!
16:08 kchibisov: d_ed[m]: I won't read connection anymore for undefined amount of time.
16:09 kchibisov: emersion: thx, that what I assumed.
16:28 Max1: I'm seeing a segfault on this line: https://gitlab.freedesktop.org/wayland/weston/-/blob/main/desktop-shell/shell.c#L1597
16:28 Max1: Because shsurf is NULL
16:28 Max1: I think it might have something to do with popups with a fullscreen parent surface?
16:29 daniels: Max1: heh yeah, I was going to ask if popups were involved :) do you have a WAYLAND_DEBUG=client trace please?
16:29 Max1: But I can look into it some more if no one is able to figure it out from this very un-detailed report :)
16:29 Max1: One second
16:31 Max1: daniels: https://pastebin.com/TrqdPGkT
16:32 Max1: Ah I don't think that was what we wanted
16:34 Max1: daniels: This is the log from the client, ignore the Chromium logs :) https://pastebin.com/FU0NqVTG
16:35 daniels: Max1: thankyou! ooi - given you're talking about fullscreen - does it also happen when you start weston with --shell=kiosk?
16:41 Max1: daniels: no, but the test also doesn't pass anymore 😅
16:43 Max1: But here's a stacktrace from Weston, if that helps: https://pastebin.com/4HWKxHbY
16:47 daniels: Max1: that helps a lot, thankyou!
17:29 paramount: emersion: Do you think you can comment on this ocaML based lem language linker script solution, many people including me are searching for better support to be added for linker script, i would have questions to you, i see you committed to this repository? https://github.com/rems-project/linksem/blob/master/src/linker_script.lem
17:48 mvlad: daniels, seems recently introduced with cc3d30c28bb.
18:15 daniels: oof yeah, we never get ->added() for popups, only for toplevels :(
18:21 emersion: paramount: this sounds completely unrelated to wayland
18:21 emersion: please contact me privately for such inquiries
18:22 emersion: (oh my, that brings back memories)
18:23 daniels: #emersion-side-quests
18:23 emersion: i do actually have #emersion over on Libera Chat :P
18:27 daniels: personal brand! :D
19:15 paramount: emersion: I am interested to have private message, but i need to think a bit before, i thing that both functionality and license wise LIEF might be better, sorry for the off-topic https://github.com/lief-project/LIEF/blob/master/LICENSE
19:42 swick[m]: pq: I would send the original bytes. it's completely valid for a profile to contain CME specific data the compositor and lcms2 don't understand
20:43 dv_: hi
20:43 dv_: I know that by default, it is not possible for an application to specify window coordinates. but what about a setup with multiple framebuffers? can an application specify which particular framebuffer to use for its window?
20:45 vyivel: dv_: do yoh mean wl_outputs?
20:45 vyivel: *you
20:47 vyivel: xdg_toplevel.set_fullscreen might be what you're looking for
20:51 paramount: But overall emersion, you know I am that Mart who is troublesome to community, but i won my trial unanimously, a hugely positive twist in my life, and this month i am finishing my life work, with immense luck that is not comprehensible to me, i managed to survive, i am no longer interested in trolling, my projects landed a success in all of them as result too, i am doing some yet small fix ups and prepare for work career
20:51 paramount: finally. I do not really bother much anymore what others say. But final off-topic link. https://people.ece.cornell.edu/land/courses/ece4760/RP2040/C_SDK_DMA_machine/DMA_machine_rp2040.html that is what i am integrating into lief with my own execution encoding called HWbird. This gets my laptops going and i write little bit es2 backends and code for this too. Some security fixes on my laptops and start my own lab too.
21:08 dv_: vyivel: fullscreen yeah, but I want to decide _which_ screen
21:08 dv_: as said, this is a setup with multiple framebuffers, one for each screen
21:10 vyivel: xdg_toplevel.set_fullscreen has an optional wl_output argument
22:53 daniels: dv_: your compositor should guide you to the right output. kiosk-shell can do this for example