ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
nerdopolis has quit [Ping timeout: 480 seconds]
boud has left #wayland [#wayland]
fmuellner has quit [Ping timeout: 480 seconds]
mblenc has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
sevz17 has joined #wayland
sevz has quit [Ping timeout: 480 seconds]
Narrat has quit []
Brainium has quit [Quit: Konversation terminated!]
nerdopolis has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
mblenc has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
crazybyte has quit [Ping timeout: 480 seconds]
crazybyte has joined #wayland
QBasicBitchX has joined #wayland
junaid has joined #wayland
sevz17 has quit [Quit: WeeChat 4.0.4]
crazybyte has quit [Ping timeout: 480 seconds]
slim has quit [Quit: slim]
crazybyte has joined #wayland
rv1sr has joined #wayland
jmdaemon has joined #wayland
slim has joined #wayland
junaid has quit [Remote host closed the connection]
<wb9688>
Are there any Wayland compositors that do not use libinput?
<kennylevinsen>
not to my knowledge, and that would be a lot of manual work... Why?
mblenc has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
dcz_ has joined #wayland
kts has quit [Ping timeout: 480 seconds]
<emersion>
maybe the one that runs in a web browser
<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
<wb9688>
emersion: Hmm… what one is that? I don't think I've ever heard of one
<psykose>
libinput is probably one of the best parts of wayland
<psykose>
in the sense of every compositor uses it and it works
<wb9688>
I agree that libinput works fine
<bl4ckb0ne>
event x11 uses it
iomari892 has quit [Ping timeout: 480 seconds]
<wb9688>
Can use it, yes, but X11 also has all those device specific thingies
<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
<kennylevinsen>
It's just that no sensible wayland server author would chose otherwise
<wb9688>
Yes, I thought so too
<Ermine>
Another piece of anti-wayland bs got debunked
Ampera has quit [Quit: Don't look at my quit message, steve30 has a better one anyways.]
iomari892 has quit [Read error: Connection reset by peer]
iomari892 has joined #wayland
d42 has joined #wayland
<Company>
wb9688: if you want to hate on Wayland's input stuff, a better thing to hate on is seats
sevz has joined #wayland
<Company>
and if you want a simple example, use wayland's idea that all cursors are handled by the client
<Company>
which means that if GTK and Qt and the compositor have different cursor themes, jsut moving the mouse will change the cursor
<kennylevinsen>
cursor_shape changes that
<kennylevinsen>
Not sure what that has to do with seats (input device grouping) though
<Company>
nothing
<Company>
those were just 2 different things to hate on
<wb9688>
What's hateable about seats though?
<bl4ckb0ne>
what isnt /s
<Company>
wb9688: how many apps can deal with 2 seats?
<Company>
wb9688: howmany apps can deal with the seat going away?
<soreau>
yea, it's probably a path that's hardly ever tested too
<Company>
wb9688: and then reappearing
<wb9688>
I am not sure as I don't use multiple seats, does GTK support that?
<Company>
seats are overengineered - they might be an interesting idea as an extension maybe
<Company>
wb9688: I am on a quest to ban seats from the GTK API
<soreau>
all users must stand
<Company>
wb9688: and you don't use multiple seats
iomari892 has quit [Ping timeout: 480 seconds]
<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)
<wb9688>
soreau: Well, wf-panel can't handle monitors going away and reappearing either… and that's quite common here
<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
<Company>
yeah, that sounds like such a cool concept in theory
<Company>
until you go "wait a minute, how much code does it require to properly support it across the stack?"
<Company>
and all you get is split-screen co-op
<psykose>
developers then: yeah do whatever get all the cool niche features
<any1>
It eliminates to need for controll-passing with remote desktop software
<psykose>
developers now: think of all the code we can delete to support 1 thing only
<psykose>
:D
<wb9688>
Uhuh, but is it possible to achieve in another way? Is is possible to run multiple Wayland compositors simultaneously?
<any1>
the need*
<Company>
any1: assuming that ends up working properly
<any1>
It works.
<clamps>
i use 3 seats to play minecraft with my kids, but i had to resort to three separate xorg servers
<Company>
clamps: yeah, I can see that use case - but trying to manage multiple devices in the same application is a mess
<Company>
especially because often, UI elements are connected to device actions
<soreau>
psykose: heh
<Company>
like right-click context menus
<Company>
also, if things are unique, you can have one global property
<Company>
"get me the focus widget"
<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
<Company>
with 2 seats, you now need 2 focus indicators - and probably with different colors
<Company>
which means you need a different styling language so you can indicate that
<Company>
also, you need to rewrite apps
<Company>
because apps assume that if a widget has a grab, that widget receives all mouse input
<Company>
like, with 2 seats you can close windows that have an ongoing dnd operation
<Company>
bet nobody handles that
<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.
<Company>
another fun thing was the GTK testsuite
<Company>
because somebody finally found a headless compositor to run it on
<Company>
instead of running it only with xvfb
<Company>
result: it instacrashed, because headless compositors are geniuses
<Company>
so they come up with 0 seats
<any1>
This is turning into a blog entry
<wb9688>
Lol
<Company>
hey, but people worked hard to fix it
<Company>
so now the GTK testsuite could deal with no mouse
<Company>
which is obviously the most important thing to test
<soreau>
clearly
<Company>
seats are awesome
<Company>
good news is that the headles compositor gained seat emulation support
<Company>
so the GTK testsuite started crashing again
<Company>
because people had assumed there was no mouse in the newest tests
<orowith2os[m]>
sounds like the tests need tests
<Company>
or the environment the tests run on needs to be more realistic
<orowith2os[m]>
or both
<orowith2os[m]>
all the tests
<Company>
testing on a headless compositor with no monitor, no input and no GL support is kinda useless
<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.
<soreau>
and then that code is copied around and they all fail
<Company>
kennylevinsen: depends on what you mean by "support"
<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
<Company>
kennylevinsen: adding if (seat != default_seat) ignore(); is easy enough of course
<kennylevinsen>
why would you need to do that?
<Company>
because nobody tests that the release event corresponds to the seat that sent the press event
<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.
<kennylevinsen>
Saving any input state on a per seat object is not hard though :)
<Company>
suuuuure
<Company>
you just have to carry around the current seat everywhere
<Company>
so that you can call all the GTK APIs that now need a seat argument with that seat
<Company>
which is not a lot of extra work at all
<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
<kennylevinsen>
Not something you have to carry around, you have it handed to you
<kennylevinsen>
When you register your wl_pointer listener, you specify a user data pointer
<any1>
Does it matter who clicked the button?
<Company>
any1: potentially?
<kennylevinsen>
this is Wayland, not Gtk - if there are issues with the Gtk abstractions, open an issue?
<Company>
there aren't issues with GTK
<Company>
there are issues with Wayland
<soreau>
famous last words
<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"
<any1>
For a remote assistance scenario, it definitely does not matter who clicked the button.
<Company>
because that way you end up with terribly clunky APIs
<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.
<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
<soreau>
Company: it seems that a client library can make the abstractions so that all the extra passing (if needed) under the hood
<Company>
kennylevinsen: no, wayland will not track the currently focused GtkWidget per seat
<kennylevinsen>
Company: that is a Gtk thing, not a Wayland thing
<Company>
kennylevinsen: correct, but Wayland wants to require that GTK carries around focus per-seat, so that different seats can work
<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.
<Company>
soreau: it's not really possible to make such an API
<Company>
soreau: because that's always leaky
<Company>
kennylevinsen: yes, it's now per-seat instead of global, which means the seat is an additional thing to carry around
<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
<kennylevinsen>
... stupid phone
<kennylevinsen>
"to work with"
<Company>
the concept is insanely complex, because tons of things that were really simple now become really complicated
<kennylevinsen>
The concept is different, not odd or complicated
<Company>
it's insanely complicated
<Company>
take a widget on the screen, start dragging it.
<Company>
Now start dragging it.
<Company>
What happens?
<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
<Company>
it's very different
<Company>
which item has focus?
<Company>
the one that has a focus indicator or the one that has a focus indicator?
<kennylevinsen>
even if there are cases that require more logic, I do not feel that it justifies "insanely"
<soreau>
what decides that an extra seat is introduced anyway? and what input devices are part of that seat?
<kennylevinsen>
You only specified one widget, so what items are options?
<kennylevinsen>
soreau: compositor configuration usually, with sway it is set as per man 5 sway-input
<soreau>
I mean why support multiple seats in the client when most clients don't support it anyway?
<soreau>
could just side step the issue
<Company>
it justifies "insanely" for me for 2 reasons:
<Company>
1. I've seen people trying to implement it and spectacularly failing
<Company>
2. I've never seen any toolkit support it
<Company>
I'm sure there's some tiny ones, but no serious ones I can think of
<kennylevinsen>
Counter: people spectacularly fail ar implementing simple non-multi-seat input, so by that logic the alternative bus also "insanely complex"
<Company>
I should have phrased that better
<Company>
I've seen other toolkit developers trying that I conside capable developers
<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*
<kennylevinsen>
But rather just not fitting what was already there
<Company>
I haven't seen any other reasonably complex system where multiseat worked
<kennylevinsen>
Retrofitting new stuff is always hard when it differs from the original design assumptions...
<Company>
the only places where multiseat worked are places where there's a clear separation between seats
<soreau>
like multiple display servers with different outputs..
<Company>
or split-screen co-op games
<Company>
where each half of the screen belongs to one seat
<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
<kennylevinsen>
soreau: that's... Unfortunately also called multi-seat
<soreau>
are there any wayland compositors that can choose what outputs it uses? so that you can use a compositor per output?
<kennylevinsen>
The naming here sucks
<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.
<kennylevinsen>
Wayland seats are a grouping of input devices within those accessible to it
<Company>
(side note: Why are Wayland outputs not per-seat?)
<kennylevinsen>
Without getting into drm lease tricks, parallel display servers on multi-seat require distinct GPUs
<kennylevinsen>
Company: ^ because that :P
<soreau>
kennylevinsen: on wayland, not on X?
<kennylevinsen>
?
<Company>
kennylevinsen: I'm pretty sure that has nothing to do with it, but our friend Melvin Conway is at fault again
<kennylevinsen>
Hardware seats affect X and Wayland the same
<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.
<kennylevinsen>
Yeah usability and necessity is questionable
<Company>
daniels: the thing IMO that GTK suffers the most from is not having "the mouse" and "the keyboard" as global objects
<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
<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)
<Company>
and I'm aware that mobile phones have neither a mouse nor a keyboard, but I'd still have them as global objects
<soreau>
kennylevinsen: so you are saying that running multiple display servers on a single gpu with multiple outputs is not possible?
<soreau>
Company: they certainly can..
<Company>
I believe the problem with a single GPU is that somebody has to modeset it
<orowith2os[m]>
not me looking into all of this and devising one of the most cursed setups someone has ever attempted
<kennylevinsen>
The modeset is not per GPU, but indeed there can only be one master per display device for which there is (usually?) one
<kennylevinsen>
Only master can control outputs
<Company>
I've wondered if I can run 2 sessions on my 2 GPUs
<clamps>
one display server per output would have been fantastic, i've got a bit of a monstrosity with 3 gpus
<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
<Company>
that would help when developing when I could let Vulkan kill one of the GPUs/sessions and use the other one for debugging
<soreau>
clamps: hm, maybe wayland compositor with nested compositors, one for each output? idk
<clamps>
interesting idea, hadn't thought of that
<orowith2os[m]>
soreau: a compositor made *only* to do DRM leasing would certainly be An Experience™
<orowith2os[m]>
(and I imagine would be the cleanest way to get multiseat going?)
<orowith2os[m]>
or whatever this is called
<orowith2os[m]>
wait
<orowith2os[m]>
let me
<orowith2os[m]>
just
<orowith2os[m]>
maybe try it out
<orowith2os[m]>
doing a thing
<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
nerdopolis has joined #wayland
<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
<soreau>
but can nested instances choose what input devices they use exclusively? seems like maybe not
<soreau>
since the input comes from the parent/host compositor
<soreau>
would be an interesting experiement though
<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
<soreau>
I think it would need some sort of support from the host compositor
<orowith2os[m]>
Ehhh
<soreau>
like 'constrain these input devices to output-xyz'
<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?
<soreau>
yea
<orowith2os[m]>
I'd assume just a minor privilege escalation
<orowith2os[m]>
Or adding the user to the input group
<soreau>
no, the wayland backend/nested instance gets input like any other client, so it doesn't really know or understand hw input devices
<soreau>
at least in wlroots
<orowith2os[m]>
Hence "having the same level of device privileges as the host compositor"
<soreau>
you would need to teach the wl backend this concept I believe
<orowith2os[m]>
Afaik normally a compositor goes through logind for that escalation, so its the only one that can access them directly
<soreau>
and I don't think it would be simple
<orowith2os[m]>
Mm
<orowith2os[m]>
I'd assume the ability to use libinput isn't tied to whether a compositor is running nested or directly on DRM
<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
<orowith2os[m]>
s/libinput/logind or whatever
<orowith2os[m]>
The idea is out there
<orowith2os[m]>
It might be better to draw it out, or wait - I seem to be talking over you
<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
<kennylevinsen>
Only one display server gets to control the (physical) seat, which is needed to open input devices
<soreau>
almost seems like you'd want to use gamescope as the nested children
<orowith2os[m]>
Joyful
<orowith2os[m]>
Seems like we need some input leasing interface somewhere :p
<soreau>
overkill
<kennylevinsen>
But you could have a custom protocol forward them - or just have the parent implement the routing logic
<kennylevinsen>
A bit wonky indeed
gspbirel5687340886706 has joined #wayland
Brainium has joined #wayland
floof58 has quit [Ping timeout: 480 seconds]
floof58 has joined #wayland
manuel1985 has quit [Quit: Leaving]
glennk has quit [Remote host closed the connection]
glennk has joined #wayland
glennk has quit [Remote host closed the connection]
glennk has joined #wayland
sima has quit [Ping timeout: 480 seconds]
i509vcb has joined #wayland
rv1sr has quit []
mblenc has joined #wayland
mblenc1 has quit [Read error: Connection reset by peer]
junaid has quit [Remote host closed the connection]
junaid has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
x0x0 has joined #wayland
mblenc1 has joined #wayland
mblenc has quit [Read error: Connection reset by peer]
x1x1 has joined #wayland
x0x0 has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
x1x1 has quit []
mblenc has joined #wayland
junaid has quit [Remote host closed the connection]
x0x0 has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
x0x0 has quit []
tristianc6704 has quit [Read error: Connection reset by peer]
tristianc6704 has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
sunrise890 has joined #wayland
sunrise890 has left #wayland [#wayland]
fmuellner has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]