11:31 wb9688: Are there any Wayland compositors that do not use libinput?
11:37 kennylevinsen: not to my knowledge, and that would be a lot of manual work... Why?
11:53 emersion: maybe the one that runs in a web browser
12:01 wb9688: Well, some people on the internet (I should really ignore that, I know) hated on Wayland because it uses libinput, but as far as I know the protocol does not require that at all, so I was wondering if there are any implementations that do not use libinput
12:01 wb9688: emersion: Hmm… what one is that? I don't think I've ever heard of one
12:02 wb9688: Ah, is it https://github.com/udevbe/greenfield?
12:03 psykose: libinput is probably one of the best parts of wayland
12:03 psykose: in the sense of every compositor uses it and it works
12:04 wb9688: I agree that libinput works fine
12:08 bl4ckb0ne: event x11 uses it
12:11 wb9688: Can use it, yes, but X11 also has all those device specific thingies
12:14 kennylevinsen: wb9688: Nothing in wayland assumes libinput. The protocol sends high-level decoded events, except for keyboard where thr client uses xkb (through libxkbcommon) to decode
12:14 kennylevinsen: It's just that no sensible wayland server author would chose otherwise
12:14 wb9688: Yes, I thought so too
12:17 Ermine: Another piece of anti-wayland bs got debunked
15:41 Company: wb9688: if you want to hate on Wayland's input stuff, a better thing to hate on is seats
15:49 Company: and if you want a simple example, use wayland's idea that all cursors are handled by the client
15:50 Company: which means that if GTK and Qt and the compositor have different cursor themes, jsut moving the mouse will change the cursor
15:52 kennylevinsen: cursor_shape changes that
15:53 kennylevinsen: Not sure what that has to do with seats (input device grouping) though
15:54 Company: nothing
15:55 Company: those were just 2 different things to hate on
15:59 wb9688: What's hateable about seats though?
16:01 bl4ckb0ne: what isnt /s
16:01 Company: wb9688: how many apps can deal with 2 seats?
16:02 Company: wb9688: howmany apps can deal with the seat going away?
16:02 soreau: yea, it's probably a path that's hardly ever tested too
16:02 Company: wb9688: and then reappearing
16:02 wb9688: I am not sure as I don't use multiple seats, does GTK support that?
16:03 Company: seats are overengineered - they might be an interesting idea as an extension maybe
16:03 Company: wb9688: I am on a quest to ban seats from the GTK API
16:03 soreau: all users must stand
16:03 Company: wb9688: and you don't use multiple seats
16:04 Company: if I connect a bluetooth mouse to my laptop, I don't get 2 mouse pointers, one for the touchpad and one for the bt mouse (thank god)
16:04 wb9688: soreau: Well, wf-panel can't handle monitors going away and reappearing either… and that's quite common here
16:06 wb9688: Company: Well, I've always wanted to try multiple seats, e.g. to play an online multiplayer game with a friend on 1 PC, as I do have multiple monitors, keyboards and mice
16:06 Company: yeah, that sounds like such a cool concept in theory
16:07 Company: until you go "wait a minute, how much code does it require to properly support it across the stack?"
16:07 Company: and all you get is split-screen co-op
16:09 psykose: developers then: yeah do whatever get all the cool niche features
16:09 any1: It eliminates to need for controll-passing with remote desktop software
16:09 psykose: developers now: think of all the code we can delete to support 1 thing only
16:09 psykose: :D
16:10 wb9688: Uhuh, but is it possible to achieve in another way? Is is possible to run multiple Wayland compositors simultaneously?
16:10 any1: the need*
16:11 Company: any1: assuming that ends up working properly
16:12 any1: It works.
16:12 clamps: i use 3 seats to play minecraft with my kids, but i had to resort to three separate xorg servers
16:13 Company: clamps: yeah, I can see that use case - but trying to manage multiple devices in the same application is a mess
16:14 Company: especially because often, UI elements are connected to device actions
16:14 soreau: psykose: heh
16:14 Company: like right-click context menus
16:15 Company: also, if things are unique, you can have one global property
16:15 Company: "get me the focus widget"
16:15 clamps: we just run three completely separate client processes, it never occurred to me that multiple seata used by one application was a thing even in theory
16:15 Company: with 2 seats, you now need 2 focus indicators - and probably with different colors
16:16 Company: which means you need a different styling language so you can indicate that
16:16 Company: also, you need to rewrite apps
16:16 Company: because apps assume that if a widget has a grab, that widget receives all mouse input
16:17 Company: like, with 2 seats you can close windows that have an ongoing dnd operation
16:17 Company: bet nobody handles that
16:17 any1: There do exist collaborative editors and such. Anyway, applications don't really need to support collaboration, they just need to be aware of multiple seats.
16:18 Company: another fun thing was the GTK testsuite
16:18 Company: because somebody finally found a headless compositor to run it on
16:18 Company: instead of running it only with xvfb
16:18 Company: result: it instacrashed, because headless compositors are geniuses
16:18 Company: so they come up with 0 seats
16:19 any1: This is turning into a blog entry
16:19 wb9688: Lol
16:19 Company: hey, but people worked hard to fix it
16:19 Company: so now the GTK testsuite could deal with no mouse
16:19 Company: which is obviously the most important thing to test
16:19 soreau: clearly
16:20 Company: seats are awesome
16:20 Company: good news is that the headles compositor gained seat emulation support
16:20 Company: so the GTK testsuite started crashing again
16:21 Company: because people had assumed there was no mouse in the newest tests
16:21 orowith2os[m]: sounds like the tests need tests
16:21 Company: or the environment the tests run on needs to be more realistic
16:22 orowith2os[m]: or both
16:22 orowith2os[m]: all the tests
16:22 Company: testing on a headless compositor with no monitor, no input and no GL support is kinda useless
16:22 kennylevinsen: Company: quite frankly, supporting multiple seats is rarely a lot of work for clients. The reason it sometimes doesn't work is just because it is never tested, and so one ends up with code storing 1 wl_seat object and similar.
16:23 soreau: and then that code is copied around and they all fail
16:23 Company: kennylevinsen: depends on what you mean by "support"
16:23 kennylevinsen: if anything I'd have gone the other way, making clients deal with all input devices directly instead of grouping them as a logical pointer and keyboard
16:23 Company: kennylevinsen: adding if (seat != default_seat) ignore(); is easy enough of course
16:24 kennylevinsen: why would you need to do that?
16:24 Company: because nobody tests that the release event corresponds to the seat that sent the press event
16:24 kennylevinsen: A seat only has so many things it can do. You can accept input and get focus. Nothing hard about doing that per seat.
16:25 kennylevinsen: Saving any input state on a per seat object is not hard though :)
16:27 Company: suuuuure
16:27 Company: you just have to carry around the current seat everywhere
16:27 Company: so that you can call all the GTK APIs that now need a seat argument with that seat
16:28 Company: which is not a lot of extra work at all
16:28 kennylevinsen: You get a user pointer back on every event, so in a reasonable use you have your own, correcr seat object pointer right there on every input event for free
16:28 kennylevinsen: Not something you have to carry around, you have it handed to you
16:28 Company: ?
16:29 Company: https://docs.gtk.org/gtk3/signal.Button.clicked.html
16:29 Company: now what?
16:29 Company: who clicked that button?
16:29 kennylevinsen: When you register your wl_pointer listener, you specify a user data pointer
16:30 any1: Does it matter who clicked the button?
16:30 Company: any1: potentially?
16:30 kennylevinsen: this is Wayland, not Gtk - if there are issues with the Gtk abstractions, open an issue?
16:31 Company: there aren't issues with GTK
16:31 Company: there are issues with Wayland
16:31 soreau: famous last words
16:32 Company: it's always easy to say "we provide all the information, the apps just gotta carry it around with them so they can hand it back to us later, where we take all the information back as arguments"
16:33 any1: For a remote assistance scenario, it definitely does not matter who clicked the button.
16:33 Company: because that way you end up with terribly clunky APIs
16:34 kennylevinsen: Company: I don't understand your argument about carrying things around being a Wayland problem. If done with libwayland, it will "carry things around" for you.
16:34 kennylevinsen: When you bind the seat, allocate a seat object of choosing and pass it as user data when you listen for events, so it always hands you the appropriate one when things happen
16:34 soreau: Company: it seems that a client library can make the abstractions so that all the extra passing (if needed) under the hood
16:35 Company: kennylevinsen: no, wayland will not track the currently focused GtkWidget per seat
16:35 kennylevinsen: Company: that is a Gtk thing, not a Wayland thing
16:35 Company: kennylevinsen: correct, but Wayland wants to require that GTK carries around focus per-seat, so that different seats can work
16:36 kennylevinsen: That is not carrying around more info, it is placing that info in a per-seat state instead of global state. For one seat, it's the same amount of data to carry.
16:36 Company: soreau: it's not really possible to make such an API
16:37 Company: soreau: because that's always leaky
16:37 Company: kennylevinsen: yes, it's now per-seat instead of global, which means the seat is an additional thing to carry around
16:37 kennylevinsen: I get that this is different than other platforms and as such may mismatch pre-existing frameworks, but I cannot get behind the concept being complex .to woek
16:37 kennylevinsen: ... stupid phone
16:38 kennylevinsen: "to work with"
16:38 Company: the concept is insanely complex, because tons of things that were really simple now become really complicated
16:38 kennylevinsen: The concept is different, not odd or complicated
16:38 Company: it's insanely complicated
16:39 Company: take a widget on the screen, start dragging it.
16:39 Company: Now start dragging it.
16:39 Company: What happens?
16:39 kennylevinsen: I disagree: storing e.g. focus information in 1 global struct is no different to me as a dev from storing it in seat specific struct
16:39 Company: it's very different
16:39 Company: which item has focus?
16:40 Company: the one that has a focus indicator or the one that has a focus indicator?
16:40 kennylevinsen: even if there are cases that require more logic, I do not feel that it justifies "insanely"
16:40 soreau: what decides that an extra seat is introduced anyway? and what input devices are part of that seat?
16:40 kennylevinsen: You only specified one widget, so what items are options?
16:40 kennylevinsen: soreau: compositor configuration usually, with sway it is set as per man 5 sway-input
16:41 soreau: I mean why support multiple seats in the client when most clients don't support it anyway?
16:41 soreau: could just side step the issue
16:41 Company: it justifies "insanely" for me for 2 reasons:
16:42 Company: 1. I've seen people trying to implement it and spectacularly failing
16:42 Company: 2. I've never seen any toolkit support it
16:43 Company: I'm sure there's some tiny ones, but no serious ones I can think of
16:43 kennylevinsen: Counter: people spectacularly fail ar implementing simple non-multi-seat input, so by that logic the alternative bus also "insanely complex"
16:43 Company: I should have phrased that better
16:44 Company: I've seen other toolkit developers trying that I conside capable developers
16:44 kennylevinsen: As for toolkits, you're probably right. Although this would probably be due to predating the concept and as such having an impedance mismatch, and as such is not evidence of *complexity*
16:44 kennylevinsen: But rather just not fitting what was already there
16:44 Company: I haven't seen any other reasonably complex system where multiseat worked
16:45 kennylevinsen: Retrofitting new stuff is always hard when it differs from the original design assumptions...
16:45 Company: the only places where multiseat worked are places where there's a clear separation between seats
16:45 soreau: like multiple display servers with different outputs..
16:46 Company: or split-screen co-op games
16:46 Company: where each half of the screen belongs to one seat
16:46 kennylevinsen: Assuming not stuck behind a toolkit that doesn't handle it, I would suspect the main reason for poor support would be because nobody tested or developed for it, because... Well, who the heck uses multi-seat :P
16:46 kennylevinsen: soreau: that's... Unfortunately also called multi-seat
16:46 soreau: are there any wayland compositors that can choose what outputs it uses? so that you can use a compositor per output?
16:46 kennylevinsen: The naming here sucks
16:47 kennylevinsen: logind and seatd deal with "physical seats", which are input and output devices that a display server can get access to. You can run independent display servers om such seats, completely unaware of each other.
16:48 kennylevinsen: Wayland seats are a grouping of input devices within those accessible to it
16:48 Company: (side note: Why are Wayland outputs not per-seat?)
16:48 kennylevinsen: Without getting into drm lease tricks, parallel display servers on multi-seat require distinct GPUs
16:48 kennylevinsen: Company: ^ because that :P
16:49 soreau: kennylevinsen: on wayland, not on X?
16:49 kennylevinsen: ?
16:49 Company: kennylevinsen: I'm pretty sure that has nothing to do with it, but our friend Melvin Conway is at fault again
16:49 kennylevinsen: Hardware seats affect X and Wayland the same
16:50 daniels: wl_seat still needs to exist as a container for input things, but yeah, in hindsight allowing multiple was probably an error. no-one supports it well.
16:50 kennylevinsen: Yeah usability and necessity is questionable
16:51 Company: daniels: the thing IMO that GTK suffers the most from is not having "the mouse" and "the keyboard" as global objects
16:51 kennylevinsen: Re: per-screen hardware seats, it should be possible to use drm lease to run a display server on a single *monitor* rather than gpu - I need to try that in seatd one day
16:52 Company: (in fact GTK doesn't even have "mouse" or "keyboard" objects, because it's all "devices", but I blame that on the people who added support for XInput)
16:55 Company: and I'm aware that mobile phones have neither a mouse nor a keyboard, but I'd still have them as global objects
16:55 soreau: kennylevinsen: so you are saying that running multiple display servers on a single gpu with multiple outputs is not possible?
16:55 soreau: Company: they certainly can..
16:56 Company: I believe the problem with a single GPU is that somebody has to modeset it
16:57 orowith2os[m]: not me looking into all of this and devising one of the most cursed setups someone has ever attempted
16:57 kennylevinsen: The modeset is not per GPU, but indeed there can only be one master per display device for which there is (usually?) one
16:57 kennylevinsen: Only master can control outputs
16:58 Company: I've wondered if I can run 2 sessions on my 2 GPUs
16:58 clamps: one display server per output would have been fantastic, i've got a bit of a monstrosity with 3 gpus
16:58 kennylevinsen: But with drm leases - meant for VR headsets mostly - one could have seatd be the master and give out leases that work like a master but for only 1 output
16:58 Company: that would help when developing when I could let Vulkan kill one of the GPUs/sessions and use the other one for debugging
17:00 soreau: clamps: hm, maybe wayland compositor with nested compositors, one for each output? idk
17:03 clamps: interesting idea, hadn't thought of that
17:07 orowith2os[m]: soreau: a compositor made *only* to do DRM leasing would certainly be An Experience™
17:07 orowith2os[m]: (and I imagine would be the cleanest way to get multiseat going?)
17:07 orowith2os[m]: or whatever this is called
17:08 orowith2os[m]: wait
17:08 orowith2os[m]: let me
17:08 orowith2os[m]: just
17:08 orowith2os[m]: maybe try it out
17:08 orowith2os[m]: doing a thing
17:10 clamps: i don't know much about drm leases, but if you had the host compositor just mapping one nested compositor filling each output and then juggle pointer/keyboard inputs appropriately, it wouldn't be that much on top of something like tinywl
17:11 kennylevinsen: the trick with drm leases would be the the compositor doesn't need to know - it would just get what looks like a display device with "less stuff" from seatd
17:15 soreau: but can nested instances choose what input devices they use exclusively? seems like maybe not
17:16 soreau: since the input comes from the parent/host compositor
17:16 soreau: would be an interesting experiement though
17:21 orowith2os[m]: soreau: in this case it would need some configuration to send over specific devices for each display - normally, it would be a normal Wayland client, and would just map the Wayland events that it gets from the host
17:22 soreau: I think it would need some sort of support from the host compositor
17:22 orowith2os[m]: Ehhh
17:22 soreau: like 'constrain these input devices to output-xyz'
17:23 orowith2os[m]: Is there anything stopping a nested compositor from having the same level of device privileges as the host compositor, and just saying which ones it should use?
17:23 soreau: yea
17:23 orowith2os[m]: I'd assume just a minor privilege escalation
17:23 orowith2os[m]: Or adding the user to the input group
17:24 soreau: no, the wayland backend/nested instance gets input like any other client, so it doesn't really know or understand hw input devices
17:24 soreau: at least in wlroots
17:25 orowith2os[m]: Hence "having the same level of device privileges as the host compositor"
17:25 soreau: you would need to teach the wl backend this concept I believe
17:25 orowith2os[m]: Afaik normally a compositor goes through logind for that escalation, so its the only one that can access them directly
17:26 soreau: and I don't think it would be simple
17:26 orowith2os[m]: Mm
17:27 orowith2os[m]: I'd assume the ability to use libinput isn't tied to whether a compositor is running nested or directly on DRM
17:27 soreau: better to just have a way for the host instance to say 'constrain pointer to this output and keyboard events to clients on this output' or so
17:27 orowith2os[m]: s/libinput/logind or whatever
17:27 orowith2os[m]: The idea is out there
17:28 orowith2os[m]: It might be better to draw it out, or wait - I seem to be talking over you
17:29 soreau: I'm thinking about pointer contraint protocol for the client/game, no idea how it would handle this in a nested instance if it supports the constraint protocol
17:30 kennylevinsen: Only one display server gets to control the (physical) seat, which is needed to open input devices
17:30 soreau: almost seems like you'd want to use gamescope as the nested children
17:30 orowith2os[m]: Joyful
17:30 orowith2os[m]: Seems like we need some input leasing interface somewhere :p
17:31 soreau: overkill
17:31 kennylevinsen: But you could have a custom protocol forward them - or just have the parent implement the routing logic
17:31 kennylevinsen: A bit wonky indeed