ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
<wt>
whot: I would be interested to try to make the case for them to be integrated.
<wt>
Where is the place to do that?
<wt>
I am also willing to do the work to get libinput supporting it.
<whot>
EV_LED is the type (==category) and then you have the various LED_FOO that are the actual LEDs exposed via evdev
wt has joined #wayland
glennk has joined #wayland
sima has joined #wayland
karenw has quit [Ping timeout: 480 seconds]
tzimmermann has joined #wayland
azerov has quit []
garnacho has joined #wayland
leon-anavi has joined #wayland
bindu_ has joined #wayland
<wt>
whot: thanks for the feedback
rasterman has joined #wayland
bindu has quit [Ping timeout: 480 seconds]
kts has joined #wayland
<whot>
wt: np
ivyl has quit [Remote host closed the connection]
ivyl has joined #wayland
<wt>
whot: I have a question if you have a sec. It seems like something like this would need a lot of the infra that is in libinput. Is there any reason to think that pulling some of the stuff out of libinput (like seats) might be useful for something like this?
<whot>
seats are mostly wrapper structs that don't do much in libinput and i'm not sure how much of those would be useful for a second library (assuming we're talking about a proposed libndof)
<whot>
having said that, libinput is MIT so it's free for the taking :)
<wt>
Well, I am trying to figure out what infra I would need. It seems like there is a lot of stuff for interacting with udev and whatnot.
<wt>
And the concepts seem very similar.
<whot>
so, those bits are easy because they've been done before, so to get off the ground you'd have to figure out the tricky bits: device handover and the API itself
<whot>
and convincing at least one big app to want to use it evenutally :)
<wt>
Yeah, that makes sense.
<wt>
libinput seems to deliver on standardizing events and configuration twiddles to it's users (e.g. compositors).
<wt>
It seems like libndof would have to do something similar.
<wt>
And in reality, I think we are talking about 6dof. I didn't see any devices in the wild that are something different.
<wt>
so, I guess lib6dof
<wt>
or lib6dofinput :p
<whot>
lib0.1047radof
<wt>
lol
<wt>
I think that the compositor issue is a little more complicated. I think that there would need to be some kind of ptotocol like idle-inhibit-unstable-v1 with the additional context of the device to be watching for events.
<wt>
And like, not every event.
<wt>
If I change the LED state on the device, I get an event, but that probably shouldn't delay locking the screen
<wt>
Also, if no app is using the 6dof dev, I would also expect that to not delay locking as well.
<whot>
so that's the handover I've been talking about - if no app is using it, should it move the ointer?
<wt>
I don't think that would make much sense for a default. I could maybe see a feature for that at some point...maybe
ivyl has quit [Remote host closed the connection]
ivyl has joined #wayland
<wt>
If I rely on the spacenavd interface, that covers the api except for that handoff piece.
<wt>
So, I guess I have a question. Would something like the protocol for wayland be a useful thing to pursue?
<wt>
And if so, do you have any suggestions for where to think about doing that.
<whot>
it'd say the first thing to figure out is what currently happens with inputfd because that'll heavily influence any design decisions. but i've lost track of this a while ago so not sure what the current state and/or plan is
<whot>
i don't know if that still a plan or if this is going to be a portal or ...?
<wt>
I can't find anything about it beyond August 2018
<wt>
You have been really way more helpful than I ever expected. Thank you for that.
<whot>
no worries
akimoto has joined #wayland
feaneron has joined #wayland
kts has quit [Ping timeout: 480 seconds]
<wt>
That was quite a read. Was there any kind of meeting after the end of the comments?
<wt>
If there's anything I could do to help with that bug, I would love to chip in some effort.
<wt>
The protocol sounds like it handles the handoff pretty well.
<wt>
However, the api for dealing with the device comes back into focus a bit.
<wt>
The good news is that there is a library all these apps use to talk to the socket. I bet that library (or one with a compatible API) could be adapted to read the fd directly instead.
tokyovigilante_ has joined #wayland
<zamundaaa[m]>
Does an input device as simple as a space mouse really need inputFd? It seems like something that could just be passed through the compositor like all other input events?
gaweringo has joined #wayland
gaweringo has quit []
<wt>
I mean, it probably could, but there would need to be a new protocol regardless.
<wt>
AFAICT, there is no way to plumb those event though.
<wt>
no way currently
tokyovigilante has quit [Ping timeout: 480 seconds]
<wt>
If one could get a raw fd to the device, it seems like a library could do that rest.
<zamundaaa[m]>
Yes, but I don't think we should throw everything into inputfd if it can be avoided
<zamundaaa[m]>
For example it means that the compositor and the app will both separately read from the device, and the compositor can't do remapping or global shortcuts
<zamundaaa[m]>
Or at least not without potentially still triggering events on the app side, because it can't filter the events
slim has joined #wayland
<wt>
Could BPF not be used to filter?
<zamundaaa[m]>
A lot of things are hypothetically possible
<zamundaaa[m]>
But not a good idea
<wt>
Also, I agree that not everything belongs in libinput.
<zamundaaa[m]>
The library the compositor uses to parse the events is irrelevant
<zamundaaa[m]>
You can put it in libinput, or in a new library, the part I have issue with is how the events would be passed to the app
<wt>
Do you have any thoughts on something that could work?
<wt>
I am just trying to find out how I can help.
<wt>
I like the idea of the fd for devices that aren't sspecifically handled by other wayland protocols.
<zamundaaa[m]>
Yeah, make a protocol like the tablet one, except much, much simpler, and implement it
<zamundaaa[m]>
If apps need to be updated to support these devices anyways, you don't have the backwards compatibility worries that inputfd concerns itself with (for gamepads) anyways
<wt>
With the inputfd idea, I think that a libary with the same api as libspnavd could probably be slotted in to make any app updates much smaller.
<wt>
I get your concern about filtering.
<wt>
However, the apps using the current tech aren't doing any filtering either.
<wt>
@zamundaaa[m] are you a dev on this stuff?
<zamundaaa[m]>
<wt> "With the inputfd idea, I think..." <- You can do the exact same with listening to input events, instead of input fd
<zamundaaa[m]>
<wt> "@zamundaaa[m] are you a dev on..." <- Yes, I'm a compositor developer. One that's very annoyed about gamepads working like they do right now
<wt>
which compositor do you work on?
<zamundaaa[m]>
KWin
<wt>
I love KWin except that kicad currently only crashes in Plasma for me.
<wt>
I've been using KDE since 1998
<wt>
Do you want all events to go through the compositor?
<zamundaaa[m]>
For input devices where it's feasible at least, yes
<wt>
So, are y'all working on anything in that vein?
<wt>
honestly, my original idea was closer to yours
gusnan has quit []
<wt>
however, I can see the merits of not wanted to context switch multiple times for every event.
<zamundaaa[m]>
There are a few protocol proposals for routing gamepad inputs through Wayland already, yes
<wt>
Do they also route 3d mouse inputs?
<zamundaaa[m]>
No
<zamundaaa[m]>
But as gamepads are so incredibly diverse and 3d mice are not (afaik at least), it would be a much simpler problem to solve
<zamundaaa[m]>
Especially when you can ignore backwards compatibility
<wt>
Yeah, that makes sense. But ignoring backward compat may make it difficult to get any takers on the api.
<wt>
I think that if there were a protocol available, I don't think that it would take a lot to get the rest working.
<zamundaaa[m]>
wt: Maybe I understood you wrong, but I thought the devices were currently not working on Wayland at all?
<zamundaaa[m]>
Because that background daemon relies on X11?
<wt>
It does not
<wt>
the input in blender and FreeCAD works
<wt>
they talk to a daemon over a Unix domain socket
<wt>
t
<zamundaaa[m]>
Oh, then that's a different story
<wt>
that daemon talks to the event device
<wt>
I don't think the daemon+lib would be impossible to replace with a lib that provides an identical api.
<wt>
It's pretty small.
<zamundaaa[m]>
Right, so if the client-side library of that were to interface with the Wayland protocol, you could probably do it without breaking backwards compat
<wt>
yes.
<wt>
And if it didn't need the extra daemon, and could have basic settings set via KDE configuration, that would kinda cool.
<wt>
At the very least, it would allow different settings for different users. The daemon currently doesn't allow that.
mripard has joined #wayland
<wt>
The daemon literally writes the file /etc/spnavd.cfg when you save the config.
<Consolatis>
if using something like the input-fd protocol and some client side library the idle activity notifications might become an issue. There is currently no official way for a client to tell the compositor about "activity", the idle inhibitor does not specify the idle timers being reset when activated. I guess one could work around it by said library creating an inhibitor and destroying it after some internal timeout after the last user-input but that
<Consolatis>
is kind of ugly. The library would then also need a pointer to the wl_surface
<wt>
I think abusing the idle inhibitor is not the right way to handle that.
sally_ has joined #wayland
<wt>
with inputfd, I would think that the compositor could watch the event stream as well and do the same thing idle inhibitor does when input comes in.
<wt>
That was more or less my original idea.
<wt>
not with input fd
<wt>
but just letting the compositor know which event device you'd be watching via some new protocol
akimoto has quit [Ping timeout: 480 seconds]
<wt>
I'm basically not super tied to any particular idea. I would just like to help in whatever way is a path forward
sally has quit [Ping timeout: 480 seconds]
<wt>
I mean, to be fair, my ideas are hacky AF, so I was hoping to find some work that I could help with.
<wt>
What do you work on @Consolatis?
<zamundaaa[m]>
wt: for just your immediate problem, make libinput or some other library parse the device, and then just have compositors read from the device and process the input events
<zamundaaa[m]>
Passing the events to apps through Wayland instead of having that additional daemon can be a separate concern
<Consolatis>
that wouldn't really work in cases like gyroscopic, temperature or accelerometer sensors and whatever else could be exposes as input devices by the kernel. those things would always emit events but it should not be counted as user activity
<Consolatis>
wt: I am one of the labwc devs
<zamundaaa[m]>
We're not talking about any of these sensors though...
<wt>
libinput was where I thought the logic would go. However, I think whot wants to keep it focused on the type of in put that manipulate pointers and enter text.
<wt>
Is labwc the intel thing?
<wt>
nevermind, different wayland compositor
<Consolatis>
nope, just some independent random boring wayland compositor
fmuellner has joined #wayland
<wt>
That looks neat
<Consolatis>
zamundaaa[m]: well, we were talking about the input-fd protocol proposal. and that looks like the compositor would basically all unhandled input event fds via that protocol which would then also include sensors and the like
<Consolatis>
would basically expose*
<zamundaaa[m]>
Yeah, that just doesn't at all solve your idle problem
<wt>
yep, I think that's a correct understanding
<zamundaaa[m]>
That's why I'm saying, make a library to actually parse 3d mice, on the compositor side, and use it, in the compositor
Ariadne has quit [Read error: Connection reset by peer]
<wt>
zamundaaa[m]: I think that sounds pretty reasonable
<zamundaaa[m]>
Then it can take the device into account for whether or not the user is idle
Ariadne has joined #wayland
<wt>
I was thinking that input-fd could get there by having the compositor watching for events on the event device as well.
<Consolatis>
oh, yeah. my comment with "that wouldn't really work" was targeted at the earlier message of wt. sorry for the confusion
nerdopolis has joined #wayland
<wt>
Anyway, I need to get to bed. I would be happy to do what I can to help get something like this done
mvlad has joined #wayland
gusnan has joined #wayland
alarumbe has joined #wayland
fmuellner_ has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
wt has quit [Quit: Konversation terminated!]
leonanavi has joined #wayland
leon-anavi has quit [Read error: Connection reset by peer]
Moprius has joined #wayland
Moprius has quit []
bindu has joined #wayland
bindu_ has quit [Ping timeout: 480 seconds]
Ariadne has quit [Read error: Connection reset by peer]
AJ_Z0 has quit [Read error: Connection reset by peer]
AJC_Z0 is now known as AJ_Z0
fatal has quit [Quit: fatal]
fatal has joined #wayland
fmuellner has joined #wayland
JakeSays has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
tzimmermann has quit [Quit: Leaving]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
coldfeet has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
chiku has joined #wayland
Sid127 has quit [Ping timeout: 480 seconds]
fmuellner has quit []
fmuellner has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
selckin has quit [Quit: selckin]
fmuellner has quit []
fmuellner has joined #wayland
tokyovigilante_ has quit [Remote host closed the connection]
tokyovigilante has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
fmuellner has quit []
fmuellner has joined #wayland
selckin has joined #wayland
garnacho has quit [Quit: garnacho]
garnacho has joined #wayland
wt has joined #wayland
psykose has quit [Remote host closed the connection]
coldfeet has quit [Quit: leaving]
coldfeet has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
wt has quit [Quit: Konversation terminated!]
coldfeet has quit [Quit: Lost terminal]
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
fmuellner has quit []
fmuellner has joined #wayland
fmuellner has quit []
leonanavi has quit [Remote host closed the connection]
fmuellner has joined #wayland
feaneron has joined #wayland
mvlad has quit [Remote host closed the connection]
fmuellner has quit [Ping timeout: 480 seconds]
Brainium has joined #wayland
rasterman has joined #wayland
vsyrjala has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
vsyrjala has joined #wayland
fmuellner has joined #wayland
puck_ has quit [Remote host closed the connection]
sima has quit [Ping timeout: 480 seconds]
puck_ has joined #wayland
<whot>
zamundaaa[m]: if libinput parses those devices (ftr, I'm not against it, just a few open questions) we'll need a wayland protocol for exclusive input and/or the compositors to understand those devices are special and manage input focus accordingly. or hook it up through the inputcapture portal but that seems wrong
<whot>
the actual implementatin in libinput would be relatively trivial, possibly a fair few quirks and of course figuring out the API but the technical bits are simple enough
AJ_Z0 has quit [Quit: I have to return some videotapes]