09:50 King_DuckZ: hey all, so this week too I'll be trying to pass some parameters to weston (say, for example, "smoothness"), and I have a few questions: 1. how can I pass parameters from the outside? 2. which weston struct should hold them?
14:54 sewn: is there a way to 'cancel' a ext_idle_notification_v1?
14:59 d_ed[m]: What do you mean by cancel?
15:20 sewn: after requesting one, wl_display_dispatch blocks until the timeout or an resume event has reached
15:23 vyivel: it blocks until there's something to process
15:23 vyivel: sewn: do you have a code link?
15:24 sewn: on second thought, the only realistic way to cancel a dispatch might be to use a wl_event_loop or to poll manually with a fd canceller
15:25 vyivel: more or less yeah
15:26 sewn: thanks!
15:58 wlb: weston Issue #922 opened by n3rdopolis (n3rdopolis) [bisected] Crash in pixman renderer when closing kdialog windows https://gitlab.freedesktop.org/wayland/weston/-/issues/922
16:23 sewn: wayland-server is ok to be used by normal wayland clients right?
16:23 sewn: for using things such as wl_event_loop
16:23 sewn: it seems counterintuitive to me, since it's intended for the server
16:23 emersion: it's not supposed to
16:24 ManMower: yeah, it's counterintuitive because you shouldn't be doing that
16:26 sewn: how come swayidle uses wl_event_loop, as it's provided by wayland-server?
16:26 emersion: it's lazy and should be rewritten to not do that
16:27 sewn: haha. guess i'll stick to manuall poll'ing
16:27 sewn: are there any sort of references/examples for manual polling of wayland fd? or is there no "right" way
16:28 any1: There are definitely many wrong ways of doing it
16:31 sewn: like? i'm curious to see if anyone was doing it wrong or if i was too
16:32 ManMower: I guess you could check out clients/window.c in weston, to see how "toy toolkit" does it
16:33 sewn: i'll assuem that's the 'rightest' way
16:34 sewn: nevermind, this is very complicated
16:38 ifreund: sewn: have a look at the doc comment for wl_display_prepare_read_queue() in libwayland if you haven't yet
16:39 sewn: afaik this is more so for multi-threaded applications
16:39 ifreund: it applies to single threaded applications as well
16:40 sewn: it seems to require the client managing it's own queue; there is no simpler variant to tis?
16:40 ifreund: wl_display_prepare_read() is just a wrapper for wl_display_prepare_read_queue()
16:40 sewn: atm i'm just using a while loop, flush, poll, dispatch on wl fd POLLIN
16:40 emersion: sewn: see mako for instance
16:41 emersion: but yeah it's super annoying/confusing boilerplate
16:41 sewn: yes i'm doing something similar mako
16:41 sewn: i'm intentionally not doing a dispatch_pending loop because it doesn't seem to be called more than once
16:41 sewn: s/called/looped
16:47 kennylevinsen: sewn: wlsunset has a simple dispatch loop that also wakes on a separate timer if you want inspiration.
16:51 sewn: why so complicated?!
16:52 sewn: surely wayland would have had the idea of putting all this boilerplate somewhere
16:52 kennylevinsen: It did, it’s called an event loop and there’s numerous options :)
16:53 kennylevinsen: Having one in libwayland makes no sense when others do it better (the one in libwayland-server was a mistake made early on)
16:53 sewn: interesting
16:53 kennylevinsen: The wlsunset example is for if you don’t want an event loop, like if you really *just* need dispatch + a timer.
16:55 kennylevinsen: Otherwise just pick from libevent, libuv, sd_event, …
16:56 sewn: the way slsunset does it is very interesting
16:59 FreeFull: If you're writing Rust rather than C, smithay_client_toolkit is quite nice
16:59 FreeFull: With calloop
17:00 ifreund: looks like wlsunset has pretty much the same control flow as what I did for waylock
17:01 kennylevinsen: yeah I’m not going to win any patents on what wlsunset is doing :P
17:01 ifreund: I think it's a good sign that we wrote similar code :D
17:02 kennylevinsen: sewn: if you only need a short low-precision timeout rather than a wall clock time, you can also just specify a timeout to poll itself instead of using SIGALRM.
17:14 sewn: yep, already did that
17:20 sewn: kennylevinsen: should POLLOUT in wayland fd mean to flush?
17:20 sewn: i've noticed this in mako but not in wlsunset or any other client
17:43 kennylevinsen: sewn: wlsunset does it (https://git.sr.ht/~kennylevinsen/wlsunset/tree/master/item/main.c#L670)
17:44 kennylevinsen: it’s in case flush fails and you need to wait till there’s room to write
17:44 sewn: sorry, meant in revents
17:45 sewn: ive also noticed wl_display_dispatch_pending being called at the end of the function, which is also not present in waylock
18:19 ifreund: sewn: in waylock wl_display_dispatch_pending() is called at the start of the next iteration of the loop, it would be redundant to call it at the end of the loop as well
18:19 sewn: yeppe
18:20 ifreund: (I think it is redundant in wlsunset as well but haven't read that code as carefully as waylock's)
18:34 kennylevinsen: ifreund: without, the effect if the incoming messages won’t have taken effect when dispatch returns and the logic outside cranks forward
18:34 kennylevinsen: like new output handling
18:35 kennylevinsen: So I don’t think it’s redundant in this case, but would have been if all reactions to Wayland events happened in listeners
18:36 sewn: something tells me these things should be added to the wayland book
18:39 ifreund: kennylevinsen: ah yeah I see, waylock just doesn't have logic that would be affected by that
18:46 wlb: weston Merge request !1557 opened by Derek Foreman (derekf) pixman-renderer: Check if the shm_buffer is gone during attach https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1557 [Pixman renderer]
18:49 sewn: in waylock comments, it is mentioned that EPIPE is sent to the app to signify wayland socket closure (supposed to be handled in wl_display_flush?), but it doesn't seem to apply and only errors at wl_display_read_events with EPIPE
19:03 ifreund: sewn: libwayland sets errno to EPIPE if it finds out the compositor has closed the socket while libwayland is trying to read events
19:03 ifreund: I don't know if this is documented anywhere, I'd just grep for EPIPE in wayland-client.c if you want details
19:05 sewn: ifreund: yeah i get that but shouldn't that be handled by the flushing part
19:06 ifreund: no?
19:06 ifreund: give wl_display_flush() a read
19:06 sewn: https://git.sr.ht/~ifreund/waylock/tree/master/item/src/Lock.zig#L230
19:07 ifreund: I don't understand what you are trying to communicate with that link
19:07 sewn: errno is set to EPIPE by the flushing
19:08 ifreund: and?
19:09 sewn: you said earlier it shouldn't
19:10 ifreund: by "handled by the flushing part" I understood that you meant there is nothing left for the client to do if flush returns EPIPE
19:10 ifreund: this is however not true
19:11 ifreund: wl_display_flush() only writes to the socket, it does not read events from the server that were sent before the socket was closed
19:11 ifreund: these events which have not yet been delivered may contain a protocol error
19:12 ifreund: and so the client should use wl_connection_read_events() or whatever to read those events and log the protocol error before exiting
19:12 ifreund: does that make things more clear?
19:14 sewn: ah so a protocol error has nothing to do with a socket error
19:14 ifreund: a protocol error is a normal wayland event on the wl_display interface
19:14 sewn: yep makes sense now
19:14 sewn: thanks ^^
19:15 ifreund: no problem :)
20:54 sewn: ifreund: interestingly the 'redundant' wl_display_dispatch_pending is actually required for my program
20:55 sewn: keep in mind the wayland doc for it also has it
20:59 ifreund: sewn: for waylock it is redundant as I don't have any logic that needs to be run after processing pending events and before the next event loop iteration
21:21 sewn: interesting, for me i need it to process seat key events
23:06 mclasen: are there any protocols in the works that let me hint the compositor about the preferred colorspace for compositing, when it comes to subsurfaces ?
23:08 zamundaaa[m]: mclasen: what do you mean? Blending?
23:08 mclasen: yes
23:10 mclasen: if gtk composites the textures itself, it might do it in a linear space, and it will look jarring if we switch between offloading and not if the compositor does something else
23:10 zamundaaa[m]: I don't think you'll get to choose the blending space any time soon. At best you'd get information about what blending space the compositor uses
23:11 zamundaaa[m]: Multiple blending spaces is quite difficult / inefficient to implement. One thing we talked about at the hackfest was doing linear in the compositor and potentially some calculations to modify alpha to make it look a bit more sRGB-like for apps that are written for it
23:13 mclasen: it doesn't matter for the common case
23:13 zamundaaa[m]: Since then I've been thinking about instead doing blending in gamma 2.2 in the compositor though, idk if offloading with linear blending in the app would still work in any way with that
23:13 mclasen: (a opaque subsurface on top)