02:43 bl4ckb0ne: seems like sent the admin link to the doodle, awesome
02:45 bl4ckb0ne: anyhow, here's the correct link https://nuudel.digitalcourage.de/IOVnQl2K3LEkZuHR
02:53 orowith2os[m]: ugh
02:53 orowith2os[m]: well
02:53 orowith2os[m]: I'm here for third party inputfd thoughts
02:53 orowith2os[m]: come get me if you need me, I'm not touching mailing lists with a 10 foot pole
02:54 bl4ckb0ne: oh wait no there's already another one!
02:54 bl4ckb0ne: https://nuudel.digitalcourage.de/CLME9a2WRJRHpd5I
02:55 bl4ckb0ne: missed it, it went right under the first one in the ML archive
04:53 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...
09:27 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?
09:28 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.
09:29 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.
13:36 wlb: wayland-protocols Issue #155 opened by Ivan Molodetskikh (YaLTeR) xdg-shell: clarify behavior when only one dimension is set to zero in configure https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/155
14:48 orowith2os[m]: drakulix: ooc could you build your libgamepad on top of inputfd?
14:49 orowith2os[m]: inputfd is pretty damn generic, so it might be feasible to just redirect a gamepad fd to libgamepad and use that
14:49 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.
14:50 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.
14:51 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
14:52 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.
14:52 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."
14:53 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
14:53 drakulix[m]: Right. And I have thought about that use-case as well. 😅
14:54 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.
14:54 orowith2os[m]: fwiw why not have two ways of using libgamepad?
14:55 orowith2os[m]: one via a socket, like you would access pipewire directly
14:55 orowith2os[m]: and another which gives you access via a wayland protocol
14:55 drakulix[m]: It has multiple ways to get device access abstracted away.
14:55 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.
14:56 drakulix[m]: I have been silently chipping away at the project for quite some time, because I wanted to have something to show off.
14:56 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.
14:59 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
14:59 swick[m]: With the exception of steam input/openxr input like systems
15:00 orowith2os[m]: a main motivator for direct access via a fd is latency
15:01 orowith2os[m]: no need to go through the chain of kernel -> libinput -> compositor -> client
15:01 orowith2os[m]: it instead goes right from kernel -> client
15:01 orowith2os[m]: (more or less)
15:01 drakulix[m]: Which is why I don’t want to make some network protocol mandatory.
15:03 drakulix[m]: File descriptors should be an option with some abstraction to unify the approaches in the game process.
15:04 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.
15:04 dottedmag: drakulix[m]: Is library in your design compositor-side or client-side?
15:04 emersion: the compositor is the input event multiplexer
15:04 drakulix[m]: Both kinda.
15:05 emersion: no need for yet another daemon
15:06 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?
15:06 dottedmag: drakulix[m]: Please consider non-C compositors. Any additional required library is a pain.
15:06 dottedmag: *required C library
15:06 emersion: drakulix[m]: I don't know about libei
15:06 emersion: I have Wayland protocols instead
15:07 drakulix[m]: ok, do you want to attempt to translate all possible controller inputs into a wayland protocol then?
15:07 orowith2os[m]: no, that's why the inputfd protocol exists
15:07 drakulix[m]: I think this problem needs a common abstraction layer.
15:08 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
15:08 drakulix[m]: But you can’t emulate a file descriptor that accepts ioctls.
15:08 drakulix[m]: And gamestreaming is a real use-case.
15:08 orowith2os[m]: why can't this fd go kernel -> compositor -> client -> "libgamepad"?
15:09 drakulix[m]: As are accessibility features like xbox adaptive controllers or combining two controllers into one.
15:09 drakulix[m]: I don’t see every game implementing that either.
15:10 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.
15:10 orowith2os[m]: your libgamepad can't take in an fd and expose a controller-like API from that?
15:10 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.
15:11 drakulix[m]: orowith2os[m]: It can. It doesn’t assume there is a daemon.
15:11 orowith2os[m]: then why not use that? then the emulation could be handled in libgamepad too
15:12 orowith2os[m]: no need to get all icky with emulating file descriptors and w/e
15:12 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?
15:12 dottedmag: s/for only/only/
15:12 drakulix[m]: because this means sometimes, when a user might want to remap the controllers, the fd should be in the daemon.
15:12 drakulix[m]: Which breaks focus semantics, because its the wrong process.
15:12 orowith2os[m]: and not a config file for the library?
15:12 orowith2os[m]: or env variable or smth?
15:13 drakulix[m]: I guess another way would be to only serialize configuration via the daemon and let the logic reside completely in the client…
15:13 drakulix[m]: I feel that would be less powerful though.
15:14 orowith2os[m]: I'm still not quite seeing why a daemon is necessary here
15:14 drakulix[m]: I need to write down the more complex use-case I have in mind to bring that point across.
15:16 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.
15:17 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.
20:06 bwidawsk: AFAICT, it is a violation of the spec to set_fullscreen prior to an initial commit. Can someone confirm?
20:06 bwidawsk: (unfullscreen similarly)
20:07 bwidawsk: because XDG specifies after creating the surface, an initial commit must come next... [un]fullscreen require a configure event is sent
20:07 bwidawsk: but that shouldn't be the initial configure
20:07 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
20:08 emersion: bwidawsk: that doesn't sound like a violation to me
20:08 bwidawsk: emersion: so then the fullscreen/unfullscreen counts as the initial commit?
20:08 bwidawsk: s/commit/configure
20:08 emersion: no
20:09 emersion: hm, can you elaborate?
20:09 bwidawsk: `After requesting that the surface should be fullscreened, the compositor will respond by emitting a configure event.`
20:09 bwidawsk: so if you create the surface, and fullscreen it before commit, the expected ordering seems broken
20:10 emersion: we should really get rid of that requirement :(
20:10 emersion: but i think it's fine?
20:10 bwidawsk: I don't see a problem perse, but I think the spec is contradicting itself a bit
20:10 emersion: the compositor can wait an arbitrary amount of time before sending the configure event
20:10 orowith2os[m]: swick: re the inputfd stuff with Steam, I made a libei issue asking for comments to see if that's *really* where it would be done: https://gitlab.freedesktop.org/libinput/libei/-/issues/40
20:11 orowith2os[m]: I don't think it would be, as inputfd expects something like an actual input device, and libei explicitly isn't that
20:11 emersion: hm, but the initial configure doesn't count as the set_fullscreen reply, is what you mean?
20:12 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
20:13 emersion: this is a gray area, would need to check what compositors do
20:13 emersion: i'd expect no configure
20:13 emersion: things would be simpler if that sentence wouldn't exist at all
20:14 emersion: and it wouldn't give clients the illusion that they can match a particular request with a configure
20:15 bwidawsk: emersion: no configure from the set_fullscreen request you mean?
20:15 emersion: yea
20:15 bwidawsk: this is what I do now, and it does work
20:15 bwidawsk: for chromeos stuff
20:17 drakulix[m]: swick: I plan to do so. gimme a few days
20:19 swick[m]: I mean, whot might be awake right now
20:21 swick[m]: drakulix: tbh I think I'm gonna be hard to convince but let's see...
20:24 drakulix[m]: I don’t mind being proven wrong.
20:30 orowith2os[m]: drakulix: can't remember, is your lib a theoretical thing right now, or is there some wip implementation of it somewhere?
20:30 orowith2os[m]: I'd love a peek if the latter
20:31 drakulix[m]: WIP on my hard drive 😅
20:31 drakulix[m]: Nothings working yet and mostly explorative, so not really worth a peek.
20:32 drakulix[m]: I actually think writing everything down to sort my thoughts is more productive than any code at this stage.
20:32 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
20:32 drakulix[m]: I just want to make sure all use-cases are covered.
20:32 drakulix[m]: As I said, I will have time to work on it next week. So maybe some code then.
20:33 orowith2os[m]: alsoooo would you happen to know of any decent Rust crates I could use to emulate devices?
20:33 orowith2os[m]: I wanna see if I can put together a custom steam input-like thingy
20:35 orowith2os[m]: (I don't feel like working with C right now)
23:20 i509vcb: xdg_toplevel.configure_bounds seems to be allowed to send a size larger than the actual configured size?
23:20 i509vcb: Obviously the configure bounds can't be followed if the maximized state is set then
23:21 i509vcb: bwidawsk: I'd think it sounds reasonable for something like mpv to start in fullscreen if you configured it that way?
23:21 i509vcb: configured as in mpv config
23:25 llyyr: mpv can't actually start as fullscreened on wayland
23:26 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
23:26 i509vcb: I've definitely noticed I find issues when I starting implementing protocols in my compositor...