04:40 KarenTheDorf: My understanding is that it is possible to have multiple wl_seat globals? How do I identify which one I should use in that case?
04:54 KarenTheDorf: From what I've seen in other client code... you don't?
05:00 kennylevinsen: KarenTheDorf: all - they represent multiple distinct input sources
05:01 kennylevinsen: Each seat being e.g. keyboard and mouse with its own cursor, focus and input capabilities. Could be two different people.
05:01 KarenTheDorf: Yeah, that's what I mean. If I've been launched by $user on $seat, I shouldn't just assume $seat == seat0.
05:02 KarenTheDorf: But I've checked gtk, qt, glfw and sdl and none of them actually do that check.
05:05 KarenTheDorf: Or if they do, I can't find it.
05:22 kennylevinsen: You don't know what seat something was launched on
05:22 kennylevinsen: Just what seats are available and what they're doing to your window.
05:24 KarenTheDorf: Hmm, okay, I will load an array of wl_seat instead of a singleton and try to handle all of the events.
05:28 Dami_Lu: KarenTheDorf: As far as I know, you need to bind the corresponding keyboard and mouse to the corresponding seat, for example, use udev to bind keyboard and mouse to seat1.
05:31 KarenTheDorf: Yeah, I was looking and I could query org.freedesktop.login1 over dbus for the current seat name and compare that to the wl_seat.name name event. But no one else does anything of the sort.
05:34 kennylevinsen: KarenTheDorf: You cannot compare the two - they're unrelated concepts
05:35 Dami_Lu: weston and sway support multiple seats. I have tried binding two sets of keyboards and mice to different seats on the same login account. But I have not tried binding them to different login accounts.
05:35 kennylevinsen: logind seats are "hardware seats" so to speak, which physically isolate devices so that you can run multiple display servers, sort of as if you had multiple computers
05:35 kennylevinsen: wayland seats are "logical seats", within the same display server session
05:36 kennylevinsen: All devices visible to the wayland compositor will always be from the same logind seat, which can then be subdivided into wayland seats
05:36 kennylevinsen: in sway for example, you configure the seats at runtime through swaymsg or through the sway configuration file, creating and naming them as you please
05:36 KarenTheDorf: So if there's 2 seats and 2 users on the same logind instance, I might see 2 wl_seats, but presumably only one will actually send me events?
05:37 kennylevinsen: No
05:37 kennylevinsen: If you have 2 wl_seats, it's from the same logind seat
05:37 kennylevinsen: If you have two logind seats, they're for two entirely separate display servers, and you client won't know about the *other* server
05:38 Dami_Lu: Generally there is only one wl_seat, and the other is a logical seat that is manually configured by the user.
05:38 kennylevinsen: Think of logind seats as "two desks with their monitors and user sessions", whereas wayland seats is a single monitor and single session - collaborative editing
05:38 whot: and very few support that because it's very niche and a nightmare to get right
05:38 kennylevinsen: ^ yes it's rather niche
05:38 KarenTheDorf: Yeah, the first description is the only description of 'seat' I understand.
05:39 kennylevinsen: yeah, it's also rather unfortunate that two similar yet distinct things are called the same :(
05:39 KarenTheDorf: And both default to seat0, for added confusion
05:39 kennylevinsen: indeed
05:40 kennylevinsen: But handling wl_seat properly is somewhat necessary - remote desktop sessions is an example, where a vnc server will have a seat for its virtual devices
05:40 kennylevinsen: (any1 has been working on a protocol for that)
05:42 kennylevinsen: but you can usually get away with just binding fetching the keyboard and pointer from all wl_seats you see, and just accepting input from the lot, not too hard
05:42 KarenTheDorf: So like... helpdesk remoting to your machine to help you! That's a good example of multiple-wl_seat I think.
05:42 KarenTheDorf: If I'm understanding right
05:42 kennylevinsen: yeah I should have made that example earlier, but had forgotten lol
05:42 kennylevinsen: https://wayland.app/protocols/ext-transient-seat-v1
05:43 kennylevinsen: That protocol is for such remote desktop servers to create temporary (transient) seats for that purpose
05:43 kennylevinsen: which will show up as a distinct wl_seat
05:44 whot: might help thinking of physical seats as "the set of input devices that have access to your compositor" and logical seats as "the set of input devices that belong together to one user"
05:44 KarenTheDorf: And break a lot of applications that just take the first and/or last seat reported by wl_registry
05:45 kennylevinsen: whot: ... an article explaining seats have been on my todo-list for years :/
05:45 whot: it's so niche that barel anyone cares about it outside the remote desktop approach
05:46 kennylevinsen: yeah that might revive it though
05:46 whot: things get really fun when you have multiple keyboard foci etc :)
05:46 whot: and by "fun" I mean "start a hobby farm instead" fun
05:46 kennylevinsen: Yeah, a *proper* implementation has independent focus and xkbcommon state and...
05:47 KarenTheDorf: I was going to say, multiple wl_seat reporting keyboards means multiple instances of xkb stuff.
05:47 kennylevinsen: ... but just accepting the input from everything and just taking the last input for focus is good enough in most cases
05:47 whot: kennylevinsen: it's much worse, every GUI widget now needs to track state independently and ideally show it correctly
05:48 whot: kennylevinsen: together with the whole "can I pop up a menu? because someone else is working where I'd display it"
05:48 whot:did way too much of this 20y ago
05:48 kennylevinsen: my condolences :P
05:49 whot: hehe
05:57 Dami_Lu: Is it possible to add the attribute of the seat to which the input device belongs in the input event? The GUI widget will only respond to events of the corresponding input device.
05:57 whot: all your input devices belong to one seat anyway so you don't need to?
05:59 Dami_Lu: If I have multiple keyboards and mice, I set different keyboards and mice to different seatX
06:00 KarenTheDorf: The events have a wl_seat pointer passed to them right? I think you can do a pointer comparison or wl_proxy_get_id. Now do applications actually handle this correctly? I doubt it.
06:00 KarenTheDorf: Oh, no, they'd just have a wl_keyboard or the like, hmph
06:00 KarenTheDorf: Still something that can be implemented clientside.
06:00 Dami_Lu: If there are multiple screens, it can support multiple users to use it together.
06:01 whot: the wl_keyboard implies the seat since you got it from the corresponding wl_seat objects
06:01 whot: so you need to keep the relation somewhere if you care about it but every device is uniquely identified to a given seat
06:02 KarenTheDorf: I think we just covered this right? Either it's multiple wl_seats meaning multiple inputs sharing a single set of wl_outputs, and you should treat all wl_seats as equivlent, or it's separate login-seats and you won't see the wl_seats for them as they are isolated from you completely.
06:04 whot: not quite? you have physical seats which are "all the devices you can have" and logical seats which are "groups of devices belonging to one user". physical seats don't really exist in the protocol, by default all physical devicecs you can access are grouped into one logical seat
06:05 whot: if you have two independent compositors because you have to share a computer, you may have two physical seats with one logical seat each. that's the "multi-seat" case you'll find, where ppl set this up for e.g. classrooms in poorer areas where they can't have a separate machine each
06:05 KarenTheDorf: But as an application, I should treat a keyboard/pointer/touch event from wl_seat seat255 the same as from wl_seat seat0, unless the user has explicitly asked me not to?
06:05 whot: unless you care about that particular use-case you don't have to care about physical seats
06:06 whot: logical seats are "multiple users interacting with my screen", collaboratively
06:06 KarenTheDorf: Yeah, when I asked my original question, that was the only meaning of "seat" I understood. A big server running multiple clients like a computer lap.
06:07 KarenTheDorf: But a wayland-wl_seat is more like the example given earlier, Helpdesk remomting to my login session to see what the problem is and fix it. We can both move the mouse cursor and type on our own keyboards and expect input to work.
06:07 kennylevinsen: Dami_Lu: If you have a GPU, keyboard and mouse for each seat, you can use logind seats and run a display server on each set. For logind, there's a udev tag to specify which logind seat a device belongs to.
06:08 whot: wayland doesnt expose individual devices (except tablets) so any logical seat shares the same input focus and keyboard layout. if you want multiple independent layouts you need to distribute the keyboards across multiple logical seats, but then you also need to worry about whether to treat them independently or slave them together. e.g. by default a separate wl_keyboard has its own
06:08 whot: focus but you could forcibly change this as compositor policy wwhenever the other one changes. so you have two independent layouts but they're always focused on the same thing
06:09 kennylevinsen: Dami_Lu: (In order to *use* a seat different from seat0, you'll need XDG_SEAT set appropriately when logging in though so the logind session is set up right.)
06:09 whot: also, fwiw libinput defaults to "seat0" for physical seats and "default" for logical seats, they shouldn't both be seat0
06:09 kennylevinsen: yeah we should move away from calilng it seat0 by default in wayland servers
06:11 KarenTheDorf: Yeah, that's probabally what sent me down the wrong way of thinking. I have a feeling the documentation for wayland says that "Seat0 will always exist" somewhere though.
06:11 kennylevinsen: seat0 isn't mentioned in wayland or wayland-protocols, but maybe there's a guide somewhere that says that?
06:12 KarenTheDorf: Maybe, I've been reading a bunch of docs before asking here so It might have been a 3rd party making an incorrect assertation.
06:15 Dami_Lu: kennylevinsen: I once tested configuring multiple sets of seats (with multiple keyboards and mice) on a GPU under the same login account. However, if multiple users operate the same application, conflicts will occur, so I asked whether it can be configured on the same GPU. Add a seat attribute to the input event so that the GUI control can only handle the input event corresponding to the seat
06:16 kennylevinsen: Dami_Lu: If the same display and display server session, but independent keyboard and mice, then you're looking at wayland (logical) seats. Their configuration is dependent on the server, e.g. sway configured as per `man 5 sway-input`
06:17 kennylevinsen: if multiple display server sessions, then that currently requires independent displays and GPUs. It is not impossible to share the GPU and hand out a display to each user using drm leases, but neither logind nor seatd does that right now
06:18 Dami_Lu: Add the seat attribute to the input event in wayland server. For example, add a parameter seat_name to the input event.
06:19 KarenTheDorf: There is already enough information in a wayland input event for the application to map to a specific wl_seat.
06:19 kennylevinsen: There is no "input event" in Wayland, there is for example a "key" event from a wl_keyboard, and that wl_keyboarrd belongs to a particular seat
06:19 kennylevinsen: indeed
06:20 kennylevinsen: it's not a wayland protocol issue, just client bugs (and a pinch of unreasonable expectations)
06:22 Dami_Lu: Yes, I am currently using the client to map key and mouse events to different seats. It would be better if gtk and qt could directly support it.
11:58 pq: KarenTheDorf, kennylevinsen, wl_seat would have been better named as "a focus group" or something.
12:18 wlb: wayland-protocols Merge request !312 opened by Simon Ser (emersion) governance: document review requirements https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/312
12:18 emersion: … or maybe "ACK" was meant as "i've reviewed in depth"?
12:31 jadahl: I don't think so, but if it was then it should say "Acked and reviewed in depth"
12:31 jadahl: I can only imagine the terms comes from the git tags we're all so familiar with
12:35 d_ed[m]: It doesn't make too much difference either way. If this is wrt the icon stuff, I'm happy to add the "and reviewed by me" line when we get the other acks
12:36 jadahl: d_ed[m]: the icon thing is was triggered it, but should be clarified either way
12:37 d_ed[m]: sure, my understanding of the current state is what Simon is writing more explicitly in 312
12:37 jadahl: right, proper in depth review by some member is what I've assumed too, and didn't realize it wasn't specified anywhere
14:01 pq: for wayland-protocols governance, is it obvious enough that one cannot ack or review one's own MR?
14:04 emersion: it's not obvious for the ACKs
14:04 emersion: review, sure
14:05 davidre: hwen you say "own" do you mean project or person?
14:05 pq: umm, or was self-ack a thing? I just assumed it wasn't.
14:05 emersion: if i send a new protocol, i do count the wlroots ACK in the requirements
14:06 zzag: davidre: in this case, I don't think member vs project matters
14:06 zzag: because a project can be represented by a single person
14:06 davidre: Yeah but is it different if you ACK d_ed's change or if he does it himself
14:07 davidre: At least it's another person looking over it
14:07 davidre: But I am not against self acks
14:07 pq: I was assuming the person is also representing a project, otherwise there would be no ambiguity.
14:07 emersion: imho it's already difficult enough to push protocols
14:07 emersion: and the ACK system is to count the by-in
14:07 davidre: If a non-member submits change it needs ACKS from three members (for xdg)
14:08 emersion: buy-in*
14:08 zzag: if a member submits a change, imho it's okay to count that as an ack as well
14:08 davidre: So if a member submits something and wouldn't be allowed to self ack that would effectively increase the required numbers
14:08 emersion: indeed
14:09 pq: yes, and I was no longer sure how they count
14:09 davidre: Of course a member is also allowed to not self ack a change if they are not super convinced :)
14:09 pq: if self-ack is ok, why is self-review not ok? :-)
14:10 zzag: self-ack = I support this idea
14:10 zzag: self-review = this is technically correct
14:10 pq: maybe would be good to write both down
14:10 zzag: I don't think that self-review would be good
14:10 emersion: i've updated my MR to make the review bit clear
14:12 pq: thanks!
14:12 pq: the "approve" button is a bit inconvenient, need to click it twice after changes
14:13 davidre: 5 ACKS are enough according to my maths
14:13 pq: mine too
14:14 davidre: So need one more
14:14 pq: and 30 days
14:16 mclasen: from an outside point of view, it isn't waylands problem that things get rushed in without sufficient scrutiny
14:17 pq: are things rushed in?
14:17 mclasen: no, they aren't
14:18 mclasen: my view is that the problem is rather that even minor and uncontroversial things take very long to land
14:18 emersion: i don't think the governance is the issue though
14:18 emersion: but yeah, they indeed do
14:19 mclasen: looking at my gtk planning, all the MRs that in the pending queue are wayland things that wait for the actual protocol work to land
14:19 emersion: what are these MRs blocked on?
14:20 emersion: the wayland MRs, that is
14:23 mclasen: here is the gtk list: https://gitlab.gnome.org/GNOME/gtk/-/milestones/8#tab-merge-requests
14:24 any1: fwiw, progress on some of the more pressing issues in my own project are also stalled by w-p.
14:24 emersion: xdg-dialog is merged
14:24 mclasen: system bell, text-input-v3, wm-gesture, xdg-dialog, edge constraints
14:24 mclasen: \o/
14:24 mclasen: I missed that one
14:29 jadahl: we're havig a call about text-input-v3 as we speak...
14:33 emersion: eh, i forgot about this completely
14:33 emersion: oh well
14:42 any1: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/368#note_2409944 - Is this enough to get the thing merged, or do I need to submit my Qt patch to the Qt project?
17:35 ids1024_: Mutter and kwin implement the linux-drm-syncobj-v1 protocol, but don't use OUT_FENCE_PTR? Is that not important for correctly handling explicit sync with direct scanout?
17:58 Company: robertmader[m], mclasen: Looking at https://wayland.app/protocols/linux-drm-syncobj-v1 - do we need API for dmabuf textures to set sync fd, release and acquire points?
17:59 Company: how does GStreamer handle that?
17:59 Company:thinking about hardware decoded video mainly atm
18:00 mclasen: I was hoping that would fall largely on the producer (gstreamer) and consumer (driver)
18:01 Company: our offloading code needs to pass that stuff on to the wl_buffer
18:01 Company: *the wl_surface
18:01 mclasen: I kinda hate how wayland protocols have this split target audience
18:01 mclasen: sometimes they are for mesa, and sometimes they are for us
18:02 Company: that's because GL/Vulkan are designed as toolkits
18:02 mclasen: and if you use the wrong thing, things will just fall apart
18:02 Company: but we're not using GL/Vulkan here, we're creating our own thing
18:03 Company: currently that's all using implicit sync, but I expect that should change
18:03 mclasen: I just hate how mesa does half the talking to wayland behind our back
18:03 Company: I have no idea how pipewire handles that either
18:03 Company: we can stop using mesa for that
18:03 mclasen: and sometimes it decides to do it in a thread
18:03 kennylevinsen:mumbles about gl/vulkan WSIs
18:04 Company: nothing stops us from creating all our own vkImages
18:04 Company: and not using swapchains
18:05 kennylevinsen: Yeah, not using WSI is very much an option and makes who owns the Wayland connection clearer
18:05 Company: you can even use https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/vkCreateHeadlessSurfaceEXT.html
18:05 Company: and then still use swapchains
18:06 Company: you'd certainly learn all the wsi stuff
18:06 Company: and then you can stop the nvidia driver from doing dumb things
18:07 Company: and you learn about win32 and macos wsi in the process, too!
18:07 Company: but if you did that, you'd be busy now implementing explicit sync
18:08 Company: or GTK would not work with nvidia
18:10 Company: (how) does qemu do explicit sync?
18:11 Company: I guess I should poke feaneron about it wrt webkit's dmabuf stuff
18:13 daniels: ids1024_: OUT_FENCE_PTR is not required for correct handling; when the DRM driver returns an atomic-commit completion event then the previous state has been fully superseded and any buffers used only in the previous state are safe to reuse
18:14 Company: because afaik webkit is using the does-not-fail approach to syncing using glFenceSync(); glClientWaitSync();
18:14 Company: and then he can solve that and teach me how to peel the fd out of the GLsync
18:16 daniels: use EGL_KHR_fence_sync instead to get an EGLFenceKHR, then EGL_ANDROID_native_fence_sync to get a FD from it
18:17 daniels: https://gitlab.freedesktop.org/wayland/weston/-/blob/main/libweston/renderer-gl/gl-renderer.c#L434-485
18:20 zamundaaa[m]: ids1024_: it's not important. The buffer is referenced by KWin for as long as it's on a plane, so the release point doesn't get signaled
18:21 zamundaaa[m]: With OUT_FENCE_PTR you could materialize the release point earlier, which may allow the client to reuse the buffer earlier though
18:44 ids1024_: Ah. https://www.kernel.org/doc/html/latest/gpu/drm-kms.html: "flip_done... Signals at the same time as when the drm event for this commit is sent to userspace, or when an out-fence is singalled." So I guess DRM_EVENT_FLIP_COMPLETE is sent at the same time the out-fence is signaled.
19:31 aktaboot: is it possible to listen for all keyboard events in wayland? or does it completely depend on the compositor
19:33 aktaboot: I'm more interested in the number of events rather than the events themselves
19:38 ids1024_: aktaboot: Compositors don't generally provide a way to get all keyboard events, but `sudo libinput debug-events` will list all the same input events the compositor is getting from the kernel.
19:41 aktaboot: id1024: thanks! oh, so I can get that info through libinput, and not necessarily a wayland client, is that correct
19:46 ids1024_: Yeah. As long as you have the privileges to read from /dev/input/event*, you can read those without any help from the compositor. Libinput is what the compositor should be using to read those events, and produce somewhat higher-level input events.
19:49 aktaboot: another question comes to mind, the desktop environment is not necessarily aware of all the inputs, and the inputs could be directed to a specific application instead, masking it from the DE
20:04 kennylevinsen: aktaboot: generally speaking, the desktop environment is not only aware of all input but is sole thing with access to it and responsible for directing it to applications with appropriately focus
20:05 kennylevinsen: Unless a particular app is getting input from a side channel, like opening a HID device directly (game controllers)
20:09 aktaboot: okay thanks!