05:55 kennylevinsen: DemiMarie: mesa wsi implements blocking eglSwapBuffers by blocking on Wayland. It's a broken API that applications unfortunately depend on
06:21 i509vcb: I'm thinking about how to expose input events to a window management client, I'd think the least painful way to do that would be extend wl_keyboard/pointer/touch to allow being focused to an output?
06:22 i509vcb: Hand rolled protocol by the way so I can be quite flexible in the possible solutionz
06:23 i509vcb: However that seems to be an issue if the window management client also creates some of it's own surfaces that would normally conform to wl_surface focus?
06:27 i509vcb: Although if the wm knows where it's own surfaces are placed, I'd guess wl_surface focus would be redundant?
08:05 kennylevinsen: i509vcb: just make a separate protocol that sends output and surface focus events. Don't route everything to the wm process, just what is required to make the decisions you need.
08:25 Arsen: is there a way to check whether a given window is visible by the user (partially unobstructed, on current workspace, etc)
08:46 kennylevinsen: Arsen: there is a signal that the surface is not generally being repainted (suspended)
08:47 kennylevinsen: But it's compositor policy when and why it isn't repainting
08:47 Arsen: hmm, right
08:47 kennylevinsen: https://wayland.app/protocols/xdg-shell#xdg_toplevel:enum:state:entry:suspended
08:50 Arsen: thanks, I'll keep a note of this
08:59 fluix: note overlapping windows can have transparency
12:49 vyivel: i presume zmike isn't actively maintaining xdg-shell anymore? if so, should w-p/stable/xdg-shell/README be updated?
12:51 vyivel: though it doesn't seem like READMEs are generally being kept fresh hm
17:48 i509vcb: kennylevinsen: sure there is good reason to be minimal, but I see no way to implement server driven surface resize of toplevels without some way to get input on the wm side