ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
lbia_ has joined #wayland
Dami_Lu has quit [Remote host closed the connection]
Dami_Lu has joined #wayland
lbia has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
sgdr has joined #wayland
sgdr has quit []
privacy has quit [Quit: Leaving]
phryk has quit [Ping timeout: 480 seconds]
phryk has joined #wayland
mxz_ has joined #wayland
mxz has quit [Ping timeout: 480 seconds]
mxz__ has quit [Ping timeout: 480 seconds]
andymandias_ has quit [Quit: ZNC 1.9.0 - https://znc.in]
mxz_ is now known as mxz
andymandias has joined #wayland
kts_ has joined #wayland
bittin has joined #wayland
andymandias_ has joined #wayland
andymandias has quit [Remote host closed the connection]
mclasen has quit [Ping timeout: 480 seconds]
andymandias has joined #wayland
garnacho has joined #wayland
glennk has joined #wayland
glennk has quit [Remote host closed the connection]
Company has quit [Read error: Connection reset by peer]
<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?
<KarenTheDorf>
From what I've seen in other client code... you don't?
kts_ has quit [Ping timeout: 480 seconds]
<kennylevinsen>
KarenTheDorf: all - they represent multiple distinct input sources
andymandias_ has quit [Quit: ZNC 1.9.0 - https://znc.in]
<kennylevinsen>
Each seat being e.g. keyboard and mouse with its own cursor, focus and input capabilities. Could be two different people.
<KarenTheDorf>
Yeah, that's what I mean. If I've been launched by $user on $seat, I shouldn't just assume $seat == seat0.
<KarenTheDorf>
But I've checked gtk, qt, glfw and sdl and none of them actually do that check.
<KarenTheDorf>
Or if they do, I can't find it.
mxz_ has joined #wayland
<kennylevinsen>
You don't know what seat something was launched on
<kennylevinsen>
Just what seats are available and what they're doing to your window.
<KarenTheDorf>
Hmm, okay, I will load an array of wl_seat instead of a singleton and try to handle all of the events.
<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.
<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.
<kennylevinsen>
KarenTheDorf: You cannot compare the two - they're unrelated concepts
<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.
<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
<kennylevinsen>
wayland seats are "logical seats", within the same display server session
<kennylevinsen>
All devices visible to the wayland compositor will always be from the same logind seat, which can then be subdivided into wayland seats
<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
<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?
<kennylevinsen>
No
<kennylevinsen>
If you have 2 wl_seats, it's from the same logind seat
<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
<Dami_Lu>
Generally there is only one wl_seat, and the other is a logical seat that is manually configured by the user.
<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
<whot>
and very few support that because it's very niche and a nightmare to get right
<kennylevinsen>
^ yes it's rather niche
<KarenTheDorf>
Yeah, the first description is the only description of 'seat' I understand.
<kennylevinsen>
yeah, it's also rather unfortunate that two similar yet distinct things are called the same :(
<KarenTheDorf>
And both default to seat0, for added confusion
<kennylevinsen>
indeed
<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
<kennylevinsen>
(any1 has been working on a protocol for that)
andymandias has quit [Remote host closed the connection]
andymandias has joined #wayland
<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
<KarenTheDorf>
So like... helpdesk remoting to your machine to help you! That's a good example of multiple-wl_seat I think.
<KarenTheDorf>
If I'm understanding right
<kennylevinsen>
yeah I should have made that example earlier, but had forgotten lol
<kennylevinsen>
That protocol is for such remote desktop servers to create temporary (transient) seats for that purpose
<kennylevinsen>
which will show up as a distinct wl_seat
<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"
<KarenTheDorf>
And break a lot of applications that just take the first and/or last seat reported by wl_registry
<kennylevinsen>
whot: ... an article explaining seats have been on my todo-list for years :/
<whot>
it's so niche that barel anyone cares about it outside the remote desktop approach
<kennylevinsen>
yeah that might revive it though
<whot>
things get really fun when you have multiple keyboard foci etc :)
<whot>
and by "fun" I mean "start a hobby farm instead" fun
<kennylevinsen>
Yeah, a *proper* implementation has independent focus and xkbcommon state and...
<KarenTheDorf>
I was going to say, multiple wl_seat reporting keyboards means multiple instances of xkb stuff.
<kennylevinsen>
... but just accepting the input from everything and just taking the last input for focus is good enough in most cases
<whot>
kennylevinsen: it's much worse, every GUI widget now needs to track state independently and ideally show it correctly
<whot>
kennylevinsen: together with the whole "can I pop up a menu? because someone else is working where I'd display it"
* whot
did way too much of this 20y ago
<kennylevinsen>
my condolences :P
<whot>
hehe
egg_cream has quit [Remote host closed the connection]
kts_ has joined #wayland
<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.
<whot>
all your input devices belong to one seat anyway so you don't need to?
<Dami_Lu>
If I have multiple keyboards and mice, I set different keyboards and mice to different seatX
<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.
<KarenTheDorf>
Oh, no, they'd just have a wl_keyboard or the like, hmph
<KarenTheDorf>
Still something that can be implemented clientside.
<Dami_Lu>
If there are multiple screens, it can support multiple users to use it together.
<whot>
the wl_keyboard implies the seat since you got it from the corresponding wl_seat objects
<whot>
so you need to keep the relation somewhere if you care about it but every device is uniquely identified to a given seat
<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.
<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
kts_ has quit [Ping timeout: 480 seconds]
<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
<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?
<whot>
unless you care about that particular use-case you don't have to care about physical seats
<whot>
logical seats are "multiple users interacting with my screen", collaboratively
<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.
<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.
<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.
<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
<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
<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.)
<whot>
also, fwiw libinput defaults to "seat0" for physical seats and "default" for logical seats, they shouldn't both be seat0
<kennylevinsen>
yeah we should move away from calilng it seat0 by default in wayland servers
<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.
<kennylevinsen>
seat0 isn't mentioned in wayland or wayland-protocols, but maybe there's a guide somewhere that says that?
sima has joined #wayland
<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.
<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
<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`
<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
<Dami_Lu>
Add the seat attribute to the input event in wayland server. For example, add a parameter seat_name to the input event.
<KarenTheDorf>
There is already enough information in a wayland input event for the application to map to a specific wl_seat.
<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
<kennylevinsen>
indeed
<kennylevinsen>
it's not a wayland protocol issue, just client bugs (and a pinch of unreasonable expectations)
<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.
mvlad has joined #wayland
mart has joined #wayland
tzimmermann has joined #wayland
iomari891 has joined #wayland
iomari892 has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
leon-anavi has joined #wayland
iomari891 has joined #wayland
iomari893 has joined #wayland
iomari892 has quit [Ping timeout: 480 seconds]
iomari891 has quit [Ping timeout: 480 seconds]
kts has joined #wayland
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
KDDLB has quit [Remote host closed the connection]
KDDLB has joined #wayland
paulk has joined #wayland
iomari891 has joined #wayland
iomari893 has quit [Ping timeout: 480 seconds]
rasterman has joined #wayland
kts has quit [Remote host closed the connection]
kts has joined #wayland
cool110 has joined #wayland
Guest5962 has quit [Remote host closed the connection]
<emersion>
… or maybe "ACK" was meant as "i've reviewed in depth"?
kts has quit [Quit: Leaving]
<jadahl>
I don't think so, but if it was then it should say "Acked and reviewed in depth"
<jadahl>
I can only imagine the terms comes from the git tags we're all so familiar with
<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
<jadahl>
d_ed[m]: the icon thing is was triggered it, but should be clarified either way
<d_ed[m]>
sure, my understanding of the current state is what Simon is writing more explicitly in 312
<jadahl>
right, proper in depth review by some member is what I've assumed too, and didn't realize it wasn't specified anywhere
Company has joined #wayland
sima has quit [Quit: Leaving]
sima has joined #wayland
manmower is now known as ManMower
privacy has quit [Quit: Leaving]
privacy has joined #wayland
<pq>
for wayland-protocols governance, is it obvious enough that one cannot ack or review one's own MR?
<emersion>
it's not obvious for the ACKs
<emersion>
review, sure
<davidre>
hwen you say "own" do you mean project or person?
<pq>
umm, or was self-ack a thing? I just assumed it wasn't.
<emersion>
if i send a new protocol, i do count the wlroots ACK in the requirements
<zzag>
davidre: in this case, I don't think member vs project matters
<zzag>
because a project can be represented by a single person
<davidre>
Yeah but is it different if you ACK d_ed's change or if he does it himself
<davidre>
At least it's another person looking over it
<davidre>
But I am not against self acks
<pq>
I was assuming the person is also representing a project, otherwise there would be no ambiguity.
<emersion>
imho it's already difficult enough to push protocols
<emersion>
and the ACK system is to count the by-in
<davidre>
If a non-member submits change it needs ACKS from three members (for xdg)
<emersion>
buy-in*
<zzag>
if a member submits a change, imho it's okay to count that as an ack as well
<davidre>
So if a member submits something and wouldn't be allowed to self ack that would effectively increase the required numbers
<emersion>
indeed
<pq>
yes, and I was no longer sure how they count
<davidre>
Of course a member is also allowed to not self ack a change if they are not super convinced :)
<pq>
if self-ack is ok, why is self-review not ok? :-)
<zzag>
self-ack = I support this idea
<zzag>
self-review = this is technically correct
<pq>
maybe would be good to write both down
<zzag>
I don't think that self-review would be good
<emersion>
i've updated my MR to make the review bit clear
<pq>
thanks!
<pq>
the "approve" button is a bit inconvenient, need to click it twice after changes
<davidre>
5 ACKS are enough according to my maths
<pq>
mine too
<davidre>
So need one more
<pq>
and 30 days
<mclasen>
from an outside point of view, it isn't waylands problem that things get rushed in without sufficient scrutiny
paulk has quit [Ping timeout: 480 seconds]
<pq>
are things rushed in?
<mclasen>
no, they aren't
<mclasen>
my view is that the problem is rather that even minor and uncontroversial things take very long to land
<emersion>
i don't think the governance is the issue though
<emersion>
but yeah, they indeed do
<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
coldfeet has quit [Remote host closed the connection]
mart has quit [Quit: Konversation terminated!]
luna__^ has joined #wayland
f_ has joined #wayland
privacy has quit [Remote host closed the connection]
kts_ has quit [Ping timeout: 480 seconds]
AJ_Z0 has quit [Quit: I have to return some videotapes]
AJ_Z0 has joined #wayland
bittin has quit [Remote host closed the connection]
paulk has quit [Quit: WeeChat 3.0]
Ps1-Jack has quit []
mclasen has quit [Quit: mclasen]
mclasen has joined #wayland
Psi-Jack has joined #wayland
paulk has joined #wayland
kts_ has joined #wayland
kasper93_ has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
mvlad has quit [Remote host closed the connection]
kasper93 has quit [Ping timeout: 480 seconds]
tzimmermann_ has joined #wayland
kasper93 has joined #wayland
kasper93_ has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Ping timeout: 480 seconds]
kts has joined #wayland
kts_ has quit [Ping timeout: 480 seconds]
tzimmermann_ has quit []
wanderer has joined #wayland
columbarius has quit [Read error: Connection reset by peer]
kts has quit [Quit: Konversation terminated!]
columbarius has joined #wayland
wanderer has quit [Quit: Page closed]
<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?
<Company>
and then you can stop the nvidia driver from doing dumb things
<Company>
and you learn about win32 and macos wsi in the process, too!
<Company>
but if you did that, you'd be busy now implementing explicit sync
<Company>
or GTK would not work with nvidia
mart has joined #wayland
<Company>
(how) does qemu do explicit sync?
Narrat has joined #wayland
<Company>
I guess I should poke feaneron about it wrt webkit's dmabuf stuff
<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
<Company>
because afaik webkit is using the does-not-fail approach to syncing using glFenceSync(); glClientWaitSync();
<Company>
and then he can solve that and teach me how to peel the fd out of the GLsync
<daniels>
use EGL_KHR_fence_sync instead to get an EGLFenceKHR, then EGL_ANDROID_native_fence_sync to get a FD from it
<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
<zamundaaa[m]>
With OUT_FENCE_PTR you could materialize the release point earlier, which may allow the client to reuse the buffer earlier though
rv1sr has joined #wayland
Brainium has joined #wayland
iomari891 has joined #wayland
<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.
glennk has joined #wayland
___nick___ has joined #wayland
Brainium has quit [Quit: Konversation terminated!]
Brainium has joined #wayland
aktaboot has joined #wayland
<aktaboot>
is it possible to listen for all keyboard events in wayland? or does it completely depend on the compositor
<aktaboot>
I'm more interested in the number of events rather than the events themselves
Narrat has quit []
privacy has joined #wayland
<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.
<aktaboot>
id1024: thanks! oh, so I can get that info through libinput, and not necessarily a wayland client, is that correct
<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.
___nick___ has quit []
<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
___nick___ has joined #wayland
lbia_ has joined #wayland
lbia has quit [Read error: Connection reset by peer]
coldfeet has quit [Remote host closed the connection]
___nick___ has quit []
___nick___ has joined #wayland
rv1sr has quit []
<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
<kennylevinsen>
Unless a particular app is getting input from a side channel, like opening a HID device directly (game controllers)
___nick___ has quit [Ping timeout: 480 seconds]
<aktaboot>
okay thanks!
mart has quit [Quit: Konversation terminated!]
kasper93 has quit [Ping timeout: 480 seconds]
aktaboot has quit [Quit: nyaa~]
iomari891 has quit [Ping timeout: 480 seconds]
privacy_ has joined #wayland
privacy has quit [Ping timeout: 480 seconds]
lbia_ has quit [Quit: lbia_]
privacy has joined #wayland
privacy_ has quit [Ping timeout: 480 seconds]
lbia has joined #wayland
kasper93 has joined #wayland
aswar002_ has quit [Remote host closed the connection]
aswar002 has joined #wayland
glennk has quit [Ping timeout: 480 seconds]
alice has joined #wayland
sgdr has joined #wayland
AJ_Z0 has quit [Quit: I have to return some videotapes]