00:13 riteo: well, I'll go. I'll check the logs the next day if someone wants to answer me
00:13 riteo: bye!
08:13 pq: riteo, depends on the global. wl_compositor would never go away for what clients care. wl_seat and wl_output can and do come and go dynamically. A headless compositor as a RDP/VNC server could very well do that.
08:15 pq: It would be logical for each RDP/VNC viewer connection to exhibit its own wl_output and wl_seat. If no viewer is connected, no output or seats would exist. If multiple can connect simultaneously, it would be the natural thing to do.
08:16 pq: That could apply with head-ful compositors too. Then remote input does not get confused with local input, and remote output can repaint on its own pace.
09:07 any1: The transient-seat protocol does this for wl_seat. It's almost past the finishing line. Only needs 1 ack, afaik. :)
09:13 emersion: any1: if you have time, can you address the typo?
09:21 wlb: weston Issue #158 closed \o/ (drm_pending_state_apply_atomic: plane_add_prop() calls break amdgpu atomic modesetting https://gitlab.freedesktop.org/wayland/weston/-/issues/158)
09:31 emersion: pq, this made me chuckle a bit https://notes.dt.in.th/HDRQRCode
09:36 kennylevinsen: emersion: that person has finally found the sole and primary use-case for HDR
09:46 any1: emersion: I thought I did already. Maybe I forgot to push. I'll check after gym
09:47 any1: also changed some words wrt resource management.
09:47 pq: guess I'm too deep in it to see the joke, and I'm also somewhat aware of the W3C work to bring HDR to the web canvas and CSS.
09:48 emersion: nothing more than a creative use of HDR
10:06 MrCooper: I wonder if such a QR code could be a health hazard
10:09 mceier: it's not limited to QR codes; imagine an ad, using HDR to blind people ;)
10:10 pq: yes, and I get as soon as it starts working, it will be abused
10:10 pq: *bet
10:11 pq: so W3C or someone needs to invent some browser guidelines or something to save people from it
13:12 wlb: weston/main: Pekka Paalanen * 6 commits https://gitlab.freedesktop.org/wayland/weston/compare/ca1f6936c40edd18d1257dee6e66b7e8689b34b5...db51409b9adc7588ee96d4893675be0497878cf3
13:12 wlb: weston Merge request !1272 merged \o/ (Rework 2D coordinate handling part 6 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1272)
15:05 wlb: wayland-protocols Merge request !216 opened by Anna Figueiredo Gomes (navi_desu) [RFC] Add action binder protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/216
18:36 riteo: hi! It's me again; I've read the logs and I've just seen that somebody answered me
18:37 emersion: pekka has
18:37 riteo: pq: yeah, seats and outputs are definitely hotpluggable by design
18:37 riteo: but there's no guarantee of what is and what isn't, that's the annoying thing
18:38 riteo: I've heard multiple times the idea of using globals for a permission system (which would be really nice actually). Right now the spec allows this sort of thing but this pretty much means that almost any global might suddenly disappear as far as the client's concerned
18:39 danieldg: I'd say that 'suddenly appear' is more likely than disappear
18:39 riteo: mh yeah
18:39 riteo: perhaps the spec could guarantee no destruction for most globals?
18:39 riteo: this would still allow the permission system thing
18:40 danieldg: I would think that instead of disappearing, the server would choose to reject requests that are no longer allowed
18:40 riteo: isn't this already current behaviour?
18:40 danieldg: (and that this should be added to protocols that don't already support it)
18:40 danieldg: for some protocols, maybe
18:40 riteo: I'm pretty sure that if a global gets deleted all requests to its proxy will be rejected
18:40 emersion: i think it's fine if a global is removed, but that removal is not handled by the client
18:41 emersion: this is a situation that needs to be supported anyways because of races
18:41 danieldg: right. The server can't rely on that happening anyway, so might as well just make it harmless
18:41 riteo: yeah I'm pretty sure that the core spec already covers this part
18:41 emersion: a compositor which wants to update wl_shm formats could remove and re-create the wl_shm global
18:42 emersion: old clients continue to use the old global, new clients will use the new one
18:42 riteo: wouldn't this make the old global useless?
18:42 danieldg: that would mean the server still has to support all the old formats forever (though maybe they're inefficient)
18:43 riteo: the spec says explicitly: The object remains valid and requests to the object will be ignored until the client destroys it, to avoid races between the global going away and a client sending a request to it.
18:43 danieldg: but is that ignoring transitive?
18:43 danieldg: (for shm: would it apply to attaching buffers)
18:44 riteo: that's actually a good question
18:45 riteo: I assume no for the most part
18:45 danieldg: and does it invalidate existing buffers that haven't changed recently (say, cursors or subsurfaces that are static)
18:45 riteo: because most stuff would require some requests to be done, no?
18:46 riteo: I'm not really sure about wl_buffers creted by wl_shm but other globals would be probably affected
18:46 danieldg: this feels like the spec was only concerned with seat/output removals, where the objects don't make sense to use
18:46 riteo: yeah
18:46 danieldg: I could see things like dmabuf being unusable upon removal, though
18:46 riteo: they're pretty much event handlers
18:46 danieldg: say it's attached to a hot-unpluggable GPU
18:47 riteo: indeed, most other objects depend on being able to send messages so I presume that they would be unusable
18:47 riteo: I really feel like there's some implicit distinction between globals that's not clearly defined by the spec
18:48 emersion: i think there are two kinds indeed
18:49 riteo: I think we haven't stumbled on this before as much because there weren't as many extension protocols
18:49 emersion: one kind advertises support for a feature, there can be either 0 or 1 such globals
18:49 emersion: the other kind reflects the presence of a resource, there can be any number
18:50 riteo: but now with pointer constraints, relative pointers and tablet support I have to handle a lot of cases as they are pretty much just seat extensions
18:50 riteo: so I have to iterate in all my seat state struct to clear/populate depending on which global got removed/added
18:50 emersion: just ignore remove if you're not interested in it
18:51 riteo: emersion: regarding the distinction I'd also consider practically that the feature globals are very likely to just pop into existence and not be destroyed at all after
18:51 emersion: e.g. no need to handle remove for relative-pointer
18:51 riteo: although that could break some very very niche cases
18:52 riteo: emersion: are you sure? If a seat pops up it's gonna ask the now "empty" relative pointer global for a relative pointer
18:52 riteo: what happens then?
18:52 emersion: it creates an inert object
18:53 riteo: oh nice
18:53 emersion: that's the only non-racy way to implement it
18:53 riteo: that would probably make the code I'm working on more maintainable
18:54 riteo: a tiny bit
18:54 riteo: oh there's also another thing
18:54 riteo: like, is there some implied order of global creation?
18:54 emersion: no
18:55 riteo: wouldn't it make sense to create extension globals before actual globals or would it be too messy?
18:55 emersion: there's no such guarantee
18:56 riteo: fair
18:56 emersion: e.g. i have zwp_pointer_gestures_v1 coming after wl_seat, for instance
18:56 emersion: on my current machine
18:56 riteo: the reasoning was that rn I have to populate the seat's state both from the global handling code for the seat and for the extensions
18:56 emersion: yeah, it's a pain to handle correctly in client code
18:56 emersion: but that ship has sailed
18:57 emersion: maybe something to add in the wayland-next thread
18:57 dottedmag: At least there is an indication "no more globals for now" at startup.
18:57 riteo: rn on godot I have to handle seat extensions in the seat add/destroy event, in the extensions add/destroy event and in the actual application destructor
18:57 riteo: wayland-next?
18:57 dottedmag: riteo: ideas for incompatible Wayland 2
18:57 emersion: just a list of mistakes basically
18:58 riteo: oh that's an interesting idea to have "already" at this stage
18:58 emersion: well, we aren't planning anything, fwiw
18:58 riteo: do you have a link for said list of mistakes?
18:58 emersion: just trying to document stuff
18:58 riteo: yeah it'd be a mess to plan but interesting nonetheless
18:58 danieldg: some of them might be possible to 'backport' to wayland 1, which would end up being useful
18:59 emersion: https://gitlab.freedesktop.org/wayland/wayland/-/issues/?sort=created_date&state=opened&label_name%5B%5D=Protocol-next&first_page_size=100
18:59 riteo: oh look at it
18:59 riteo: https://gitlab.freedesktop.org/wayland/wayland/-/issues/291
18:59 emersion: aha yeah
18:59 emersion: just found that one
19:00 riteo: I had no idea it was a wayland-next thing, I stumbled on this before too if you notice the logs
19:00 emersion: well, anyways, docs for it would be welcome
19:00 riteo: what docs?
19:01 emersion: explain what the two kinds of globals are, and spell out which kind is each interface
19:01 emersion: btw, we don't even consistently document which interfaces are globals
19:02 riteo: well that wouldn't still be guaranteed by the spec
19:03 riteo: or do you mean like documenting the "mistake" better?
19:03 emersion: no
19:04 riteo: I'm not really sure why we would document something that's not guaranteed by the spec.
19:04 riteo: is it because of inert objects
19:29 riteo: well, gtg, it's been a pleasure
19:29 riteo: bye!
19:55 wlb: weston Merge request !1276 opened by Daniel Stone (daniels) Add helper for moving views on and off layers https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1276 [libweston API], [Desktop shell], [kiosk-shell]
20:12 any1: emersion: I remembered correctly. The typo is already addressed, unless there is another one that I don't know about.
20:12 emersion: cool
20:13 wlb: weston/main: Daniel Stone * 7 commits https://gitlab.freedesktop.org/wayland/weston/compare/db51409b9adc7588ee96d4893675be0497878cf3...e35977f3a0e3af2cb947e988184cde7add6587eb
20:13 wlb: weston Merge request !1275 merged \o/ (CI: Add Debian 12 (bookworm) jobs https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1275)
20:17 any1: emersion: I also changed some wording to address what we discussed: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3674
21:30 wlb: weston/main: Daniel Stone * 20 commits https://gitlab.freedesktop.org/wayland/weston/compare/e35977f3a0e3af2cb947e988184cde7add6587eb...7c8685769d62fe8ff34d8df54b0dd78db2df3249
21:30 wlb: weston Merge request !1230 merged \o/ (wet_process: Fully split wet_process and wl_client https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1230)
21:41 wlb: weston/main: Philipp Zabel * backend-vnc: use weston_region_global_to_output https://gitlab.freedesktop.org/wayland/weston/commit/8f18958cc56d libweston/backend-vnc/vnc.c
21:41 wlb: weston Merge request !1274 merged \o/ (backend-vnc: use weston_region_global_to_output https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1274)
23:31 wlb: weston Merge request !1277 opened by Daniel Stone (daniels) Be conservative about dirtying paint nodes https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1277 [Core compositor]