ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
shoragan has quit [Quit: quit]
shoragan has joined #wayland
jmdaemon has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
shoragan has quit [Read error: Network is unreachable]
<bl4ckb0ne>
missed it, it went right under the first one in the ML archive
nerdopolis has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Company has quit [Remote host closed the connection]
rv1sr has joined #wayland
ciara has quit [Read error: Connection reset by peer]
ciara has joined #wayland
<RAOF>
Bah! Disappointed that I missed the xdg-session-restore discussion - we've had experience designing such a thing in Mir, and I'm sure there's some prior-art _somewhere_ in the wayland-protocols issues list...
JakeSays has joined #wayland
JakeSays1 has quit [Ping timeout: 480 seconds]
ciara has quit [Read error: No route to host]
ciara has joined #wayland
sima has quit [Read error: No route to host]
sima has joined #wayland
molinari has joined #wayland
molinari has quit [Quit: Leaving]
ciara has quit [Ping timeout: 480 seconds]
tent405 has quit [Quit: tent405]
ciara has joined #wayland
kts has joined #wayland
jess has quit []
kts has quit [Ping timeout: 480 seconds]
<drakulix[m]>
I would love to attend a input-fd meeting, but I am on holiday for the next two weeks, any chance we could delay this?
<drakulix[m]>
I have a little prototype for something I have been calling “libgamepad” and by then this might even be in a state to be demo-ed.
<drakulix[m]>
That thing tries to cover a bunch of interesting use-cases inputfd doesn’t really consider and I would love to have a pragmatic discussion about those.
iomari892 has joined #wayland
ciara has quit [Read error: Connection reset by peer]
ciara has joined #wayland
sozuba has joined #wayland
sozuba is now known as Guest8685
fmuellner has joined #wayland
nerdopolis has joined #wayland
mohit815 has quit [Quit: mohit815]
mohit815 has joined #wayland
crazybyte has quit [Quit: Ping timeout (120 seconds)]
i509vcb has quit [Quit: Connection closed for inactivity]
glennk has quit [Read error: Connection reset by peer]
Company has joined #wayland
glennk has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
glennk has quit [Read error: Connection reset by peer]
kts has joined #wayland
glennk has joined #wayland
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
nerdopolis has joined #wayland
kts_ has joined #wayland
kts has quit [Ping timeout: 480 seconds]
<orowith2os[m]>
drakulix: ooc could you build your libgamepad on top of inputfd?
<orowith2os[m]>
inputfd is pretty damn generic, so it might be feasible to just redirect a gamepad fd to libgamepad and use that
<drakulix[m]>
The idea is pulseaudio but for gamepads. inputfd needs surface focus, so you can’t have a daemon control the gamepad nodes with the current proposal.
<drakulix[m]>
And my issue with file descriptors is, that you can’t emulate them without access to uinput (which is a much bigger security issue) or LD_PRELOAD hacks.
<orowith2os[m]>
I see a problem with any solution that isn't tied into with how the compositor works, and let the compositor revoke and manage things at will
<orowith2os[m]>
as swick said on the MR, "They are not right now because you cannot use them to control the rest of the system.... because they are not handled by the compositor.
<orowith2os[m]>
I want to be able to use joysticks to control my system and input passwords with the OSK and at that point if there is no arbitration via focus it is a security issue."
<orowith2os[m]>
and yes, I am in the same boat there - I'd like to put this to use in GNOME for some TV shenanigans
<drakulix[m]>
Right. And I have thought about that use-case as well. 😅
<drakulix[m]>
I’ve also a few accessibility use-case in mind, I have thought about how steam could use this, if they would ever choose to, etc.
<orowith2os[m]>
fwiw why not have two ways of using libgamepad?
<orowith2os[m]>
one via a socket, like you would access pipewire directly
<orowith2os[m]>
and another which gives you access via a wayland protocol
<drakulix[m]>
It has multiple ways to get device access abstracted away.
<drakulix[m]>
Honestly I don’t want to explain the whole project just know. I have quite the proposal in mind for it and I hope it will be interesting enough to the community to discuss it.
<drakulix[m]>
I have been silently chipping away at the project for quite some time, because I wanted to have something to show off.
<drakulix[m]>
In hindsight maybe not the best approach, but thats why I have a couple of ideas on the subject and I would prefer to not miss out on the meeting.
<swick[m]>
If I have learned anything it is that clients want even more low level access to devices so trying to abstract them is a fools errant
<swick[m]>
With the exception of steam input/openxr input like systems
<orowith2os[m]>
a main motivator for direct access via a fd is latency
<orowith2os[m]>
no need to go through the chain of kernel -> libinput -> compositor -> client
<orowith2os[m]>
it instead goes right from kernel -> client
<orowith2os[m]>
(more or less)
<drakulix[m]>
Which is why I don’t want to make some network protocol mandatory.
<drakulix[m]>
File descriptors should be an option with some abstraction to unify the approaches in the game process.
<drakulix[m]>
But if you sometimes want an fd and sometimes not, that still doesn’t mix well with focus semantics. I honestly think the DE should just be another (possibly privileged) client of some abstraction.
<dottedmag>
drakulix[m]: Is library in your design compositor-side or client-side?
<emersion>
the compositor is the input event multiplexer
<drakulix[m]>
Both kinda.
<emersion>
no need for yet another daemon
<drakulix[m]>
@emersion I should be able to do input emulation in user space without uinput. Do you envision every compositor doing something like libei for all the kinds of controllers out there?
<dottedmag>
drakulix[m]: Please consider non-C compositors. Any additional required library is a pain.
<dottedmag>
*required C library
<emersion>
drakulix[m]: I don't know about libei
<emersion>
I have Wayland protocols instead
<drakulix[m]>
ok, do you want to attempt to translate all possible controller inputs into a wayland protocol then?
<orowith2os[m]>
no, that's why the inputfd protocol exists
<drakulix[m]>
I think this problem needs a common abstraction layer.
<orowith2os[m]>
just a plain and simple file descriptor to the device node - from there, clients can use their own library (hell, yours can just simplify this process for them) and all is fine and dandy
<drakulix[m]>
But you can’t emulate a file descriptor that accepts ioctls.
<drakulix[m]>
And gamestreaming is a real use-case.
<orowith2os[m]>
why can't this fd go kernel -> compositor -> client -> "libgamepad"?
<drakulix[m]>
As are accessibility features like xbox adaptive controllers or combining two controllers into one.
<drakulix[m]>
I don’t see every game implementing that either.
<drakulix[m]>
orowith2os[m]: It can for cases where you directly use controllers without any remapping/emulation in place. And the idea is, that something like libgamepad can also do that.
<orowith2os[m]>
your libgamepad can't take in an fd and expose a controller-like API from that?
<drakulix[m]>
But then you have a disconnect between devices a game sees and you compositor sees, if you don’t consider libgamepad in the compositor as well.
<drakulix[m]>
orowith2os[m]: It can. It doesn’t assume there is a daemon.
<orowith2os[m]>
then why not use that? then the emulation could be handled in libgamepad too
<orowith2os[m]>
no need to get all icky with emulating file descriptors and w/e
<dottedmag>
So is libgamepad in compositor for only needed to utilize gamepad in compositor itself? And if compositor does not care it can pass the fds over some protocol, and not care?
<dottedmag>
s/for only/only/
<drakulix[m]>
because this means sometimes, when a user might want to remap the controllers, the fd should be in the daemon.
<drakulix[m]>
Which breaks focus semantics, because its the wrong process.
<orowith2os[m]>
and not a config file for the library?
<orowith2os[m]>
or env variable or smth?
<drakulix[m]>
I guess another way would be to only serialize configuration via the daemon and let the logic reside completely in the client…
nerdopolis has quit [Ping timeout: 480 seconds]
<drakulix[m]>
I feel that would be less powerful though.
<orowith2os[m]>
I'm still not quite seeing why a daemon is necessary here
<drakulix[m]>
I need to write down the more complex use-case I have in mind to bring that point across.
<drakulix[m]>
@dottedmag Yes, I don’t think a compositor would have to care about this library, if it doesn’t want to process gamepad input itself.
<drakulix[m]>
anyway, I am just asking for a delay of that meeting. I’ll be writing up all of this and hope people are interested. But gaging from the inputfd-PR prople are.
nerdopolis has joined #wayland
i509vcb has joined #wayland
nerdopolis has quit [Remote host closed the connection]
nerdopolis has joined #wayland
rv1sr has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
ciara has quit [Read error: No route to host]
ciara has joined #wayland
cool110 has joined #wayland
cool110 is now known as Guest8706
Guest8636 has quit [Ping timeout: 480 seconds]
rv1sr has quit []
nerdopolis has quit [Ping timeout: 480 seconds]
rv1sr has joined #wayland
nerdopolis has joined #wayland
CruxOfTheB has joined #wayland
rv1sr has quit []
ciara has quit [Read error: No route to host]
ciara has joined #wayland
Guest8685 has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
iomari892 has quit [Ping timeout: 480 seconds]
DodoGTA has quit [Quit: DodoGTA]
fmuellner has joined #wayland
DodoGTA has joined #wayland
DodoGTA has quit [Quit: DodoGTA]
DodoGTA has joined #wayland
sima has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
<bwidawsk>
AFAICT, it is a violation of the spec to set_fullscreen prior to an initial commit. Can someone confirm?
<bwidawsk>
(unfullscreen similarly)
nerdopolis has quit [Ping timeout: 480 seconds]
<bwidawsk>
because XDG specifies after creating the surface, an initial commit must come next... [un]fullscreen require a configure event is sent
<bwidawsk>
but that shouldn't be the initial configure
<swick[m]>
So I'm drunk at an Iranian part right now but... drakulix I really think you have to write a bit more about what you want to achieve here and why the inputfd stuff is not sufficient
<emersion>
bwidawsk: that doesn't sound like a violation to me
<bwidawsk>
emersion: so then the fullscreen/unfullscreen counts as the initial commit?
<bwidawsk>
s/commit/configure
<emersion>
no
<emersion>
hm, can you elaborate?
<bwidawsk>
`After requesting that the surface should be fullscreened, the compositor will respond by emitting a configure event.`
<bwidawsk>
so if you create the surface, and fullscreen it before commit, the expected ordering seems broken
<emersion>
we should really get rid of that requirement :(
<emersion>
but i think it's fine?
<bwidawsk>
I don't see a problem perse, but I think the spec is contradicting itself a bit
<emersion>
the compositor can wait an arbitrary amount of time before sending the configure event
<orowith2os[m]>
I don't think it would be, as inputfd expects something like an actual input device, and libei explicitly isn't that
<emersion>
hm, but the initial configure doesn't count as the set_fullscreen reply, is what you mean?
<bwidawsk>
Yes, but specifically, if the client does set_fullscreen receives a configure event, does it need to do a commit without a buffer attached to receive another configure event as described in XDG base
<emersion>
this is a gray area, would need to check what compositors do
<emersion>
i'd expect no configure
<emersion>
things would be simpler if that sentence wouldn't exist at all
<emersion>
and it wouldn't give clients the illusion that they can match a particular request with a configure
<bwidawsk>
emersion: no configure from the set_fullscreen request you mean?
<emersion>
yea
<bwidawsk>
this is what I do now, and it does work
<bwidawsk>
for chromeos stuff
<drakulix[m]>
swick: I plan to do so. gimme a few days
<swick[m]>
I mean, whot might be awake right now
<swick[m]>
drakulix: tbh I think I'm gonna be hard to convince but let's see...
<drakulix[m]>
I don’t mind being proven wrong.
<orowith2os[m]>
drakulix: can't remember, is your lib a theoretical thing right now, or is there some wip implementation of it somewhere?
<orowith2os[m]>
I'd love a peek if the latter
<drakulix[m]>
WIP on my hard drive 😅
<drakulix[m]>
Nothings working yet and mostly explorative, so not really worth a peek.
<drakulix[m]>
I actually think writing everything down to sort my thoughts is more productive than any code at this stage.
<orowith2os[m]>
I'd love a look anyways, who knows, I could maybe even help out if there's a clear path to take on designing it
<drakulix[m]>
I just want to make sure all use-cases are covered.
<drakulix[m]>
As I said, I will have time to work on it next week. So maybe some code then.
<orowith2os[m]>
alsoooo would you happen to know of any decent Rust crates I could use to emulate devices?
<orowith2os[m]>
I wanna see if I can put together a custom steam input-like thingy
<orowith2os[m]>
(I don't feel like working with C right now)
nerdopolis has joined #wayland
CruxOfTheB has quit [Ping timeout: 480 seconds]
Armada has quit [Remote host closed the connection]
Armada has joined #wayland
ciara has quit [Read error: No route to host]
ciara has joined #wayland
rv1sr has joined #wayland
tent405 has joined #wayland
kts_ has quit [Ping timeout: 480 seconds]
ohmacs^ has joined #wayland
Brainium has joined #wayland
Armada has left #wayland [#wayland]
Armada has joined #wayland
Armada has left #wayland [#wayland]
<i509vcb>
xdg_toplevel.configure_bounds seems to be allowed to send a size larger than the actual configured size?
<i509vcb>
Obviously the configure bounds can't be followed if the maximized state is set then
<i509vcb>
bwidawsk: I'd think it sounds reasonable for something like mpv to start in fullscreen if you configured it that way?
<i509vcb>
configured as in mpv config
<llyyr>
mpv can't actually start as fullscreened on wayland
<bwidawsk>
i509vcb: yeah, no issue with start as fullscreen, just the wording of configure events in XDG leads to confusion when done without an initial commit/configure
<i509vcb>
I've definitely noticed I find issues when I starting implementing protocols in my compositor...