08:10 Company: zamundaaa: in kwin, when you take screenshots, what do you get? Do you have a way to get an accurate representation of the screen/a window, when it's happening in som float16 and different colorspaces?
10:34 zamundaaa[m]: Company: right now it's just mapped to sRGB
11:22 Company: do we have a data structure that manages empty space in a 2D area?
11:23 Company: basically: How do we release space in an atlas?
11:23 Company: note: this isn't about the glyph cache, this is about the offscreen cache
11:24 Company: because it turns out having one is kinda important if you need lots of offscreens because you think color conversion is something your toolkit should do
11:46 Company: ha, this was meant to go in #gtk
16:47 wlb: weston Merge request !1575 merged \o/ (xwm: Fix input regions https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1575)
16:47 wlb: weston/main: Derek Foreman * xwm: Fix input regions https://gitlab.freedesktop.org/wayland/weston/commit/d500dbd4e2c9 libweston/compositor.c xwayland/window-manager.c
19:34 karenthedorf: Although wl_keyboard and wl_pointer leave events pass the wl_surface, it's always going to be the surface from the most recent enter event? (i.e. a keyboard/pointer can not have multiple focuses, at least not from a client PoV)
19:37 karenthedorf: As a tangent: It probabally is possible for a client to observe the keyboard and mouse focus to be different I assume?
19:41 ifreund: yes, keyboard and pointer focus may be given to different surfaces of the same client or even different clients at the same time
19:45 karenthedorf: ifreund: Thank you, do you know the answer to the first question? (I can assume a single input device will always leave() the surface from the most recent enter())
19:49 ifreund: yes, I think the surface argument of wl_keyboard.leave and wl_pointer.leave is redundant
19:49 Company: is that spec'ed?
19:49 karenthedorf: Spec only says "The leave notification is sent before the enter notification for the new focus."
19:50 ifreund: It also forbids leave with no enter I believe
19:50 ifreund: wl_keyboard is a bit more explicit about thisthan wl_pointer
19:51 karenthedorf: How so? It seems to use the same wording.
19:51 ifreund: Company: it should probably be stated more explicitly, but I don't see a way for a compositor to implement what's spec'd in wayland.xml without providing this guarantee
19:52 Company: I think there's issues wrt grabs and destroying surfaces
19:52 ifreund: karenthedorf: wl_keyboard explicitly describes the "state" of the object including the active surface and how this state is modified by events
19:52 Company: ie if enter, destroy, leave goes where?
19:53 ifreund: nowhere
19:53 karenthedorf: I do like this very hopeful comment in the xml "After this event client must assume that all keys, including modifiers, are lifted and also it must stop key repeating if there's some going on."
19:53 Company: but I'm not sure if that violates the "leave is for most recent enter" constraint
19:53 karenthedorf: Amount of applications with that bug (across all Display Servers, not just wayland): Too damn many
19:53 Company: it jsut violates "every enter will get a leave"
19:54 karenthedorf: I suppose the focus being set to null is moot if the keyboard itself is destroyed.
19:54 ifreund: Company: well, the compositor will still send a leave after the client has destroyed the surface, the client will get a null surface pointer in its callback for that leave event though
19:55 karenthedorf: wayland_client doesn't actually invoke a leave() callback in that case right?
19:55 Company: you get a leave when a device goes away, right?
19:56 karenthedorf: I'd assume you've get wl_{keyboard,pointer,touch}.leave() followed by wl_seat.capabilities()?
19:56 ifreund: in the case that the server has sent a leave event, then the client destroys the surface, then the client receives the leave event libwayland-client will indeed invoke the "leave callback"
19:57 karenthedorf: So the wl_surface could actually be null! It's a good job I'm *not* accessing it then.
19:57 ifreund: karenthedorf: the same goes for all object arguments for callbacks
19:58 ifreund: this is documented in one of the libwayland headers... in a very hard place to find
19:59 karenthedorf: So for a wayland_client callback of the form (void *data, wl_object *reciever, wl_object *other), reciever is always non-null, but other can be null?
19:59 ifreund: Company: I don't think it's explicitly specified whether a leave is guaranteed when a seat loses a capability
19:59 karenthedorf: And data is always wl_object_get_user_data(reciever)
20:00 Company: yay for me coming up with another corner case (that still doesn't violate the rule)
20:00 karenthedorf: ifreund: Reading the change in wl_seat v5, that object is defunct and can't recieve any more events anyway, so it kind of moot if it gets a leave or not, it's dead.
20:00 ifreund: yeah, I don't think it's a very interesting corner case really
20:00 ifreund: karenthedorf: yes, that's my understanding
20:01 ifreund: see this comment: https://gitlab.freedesktop.org/wayland/wayland/-/blob/fa1811ce3e1475a95aa39e00cfa083797661d651/src/wayland-util.h#L108
20:01 ifreund: the sentence "While it is a protocol violation..."
20:02 karenthedorf: I'm just going to pretend leave() has no surface parameter. It's either null, in which case I can't use it, or it's data->focus->wl_surface, in which case I can just access it that way.
20:03 karenthedorf: So we could see enter(,,NULL), I should go defend against that.
20:04 ifreund: karenthedorf: if it's null, that means that you have already destroyed the wl_surface client-side
20:04 ifreund: so you won't have a valid pointer anywhere else in your client either...
20:05 ifreund: probably you want to ignore enter/leave entirely for surfaces you have already destroyed
20:05 karenthedorf: Point taken. The best thing to do is do nothing, probabally.
20:22 karenthedorf: One day I'll work out how to implement wl_registry.global_remove() correctly as a client... There's no easy way to map from a wl_registry name to my client-side representation of wayland objects. But I imagine most globals won't get hotunplugged except wl_seat, and having extra inert Seats lying around is fine unless there's so many iterating over the linked list of them becomes a performance issue.
20:22 karenthedorf: and wl_output, but I don't track those.
20:23 ifreund: as far as the core protocol goes, wl_seat and wl_output are indeed the only globals that it makes sense for a compositor to remove
20:25 ifreund: I personally consider the way wl_seat and wl_output are handled to be a nice big design wart
20:25 ifreund: global_remove shouldn't exist at all IMO, and there shouldn't be duplicate globals
20:25 ifreund: but it's too late for that of course
20:25 karenthedorf: Every other non-core protocol I use is just a stub global that lets you call wl_fooer_get_foo_for_surface() and has no logic in it.
20:26 ifreund: and we are stuck with compositors waiting for some arbitrary amount of time after sending global_remove before they actually delete the global to mitigate races
20:27 karenthedorf: Also, a curse on libraries that make additional wl_registries on the same connection which never can be cleaned up until wl_fixes gets 1) merged, 2) implemented on compositors 3) implemented on clients.
20:28 karenthedorf: Not that there's any way for e.g. a vulkan driver to function without making yet another registry which can never be destroyed.
23:11 karenthedorf: If I don't make wl_output objects, it's expected that I shouldn't (baring race conditions) recieve wl_surface.enter() events?