00:56 <davidawesome> Hey guys back; let me know if anyone can help :) Sorry for no bouncer

01:02 <mstoeckl> davidawesome: I have seen no previous replies. Regarding your question: if you want similar features to gamescope (rendering application into a single window with e.g. scaling, frame rate control) then I'd recommend modifying gamescope. If you _only_ want to e.g. toggle on/off mouse input, a dedicated subcompositor that rewrites/filters the few relevant protocol messages and passes on the rest may work.

01:05 <mstoeckl> I've implemented two very specific protocol editors (https://gitlab.freedesktop.org/mstoeckl/windowtolayer, gitlab.freedesktop.org/mstoeckl/wborder), and find there is a lot of setup/boilerplate code you need whether or not you implement this using libwayland or with a custom protocol parser

02:18 <davidawesome> Hi mstoeckl, Thanks for the response, I was eating so just saw it :) I was thinking of modifying gamescope and submiting as a patch, but they never responed to my issue https://github.com/ValveSoftware/gamescope/issues/1771 on how it should be done, so I was unsure. Do you think a program like this should be a wrapper for libinput calls / callbacks, or would you suggest I directly

02:18 <davidawesome> modify the source code? Also, I assume libinput its self by default would not work with caputiring all keyboard events (I have not checked) so would I need to parse evdev my self, and process those events, or is there some common protocal I can build on other than those of libinput? I will take a look at yours soon, but if you have any ideas on how I should continue for this project

02:18 <davidawesome> I would be happy to get some pointers :). In gamescope, /src/LibInputHandler.cpp seams to process libinput data, so I assume I could proxy those calls, or modify here to use evdev, but I also saw gamescopes --force-grab-cursor (I dont see it on the main page anymore, but #1285 mentions it) exists, and am unsure if that means what I think it means. I assume that would be just aquring

02:18 <davidawesome> a lock in the wayland server side though, and not applicable to this. If you have any ideas on how I should do this in a wayland friendly way, for gamescope or just any program in general I am really appreciative of your help :)

02:18 <davidawesome> If you know of a easier than evdev parsing way also that would be helpfull

03:03 <mstoeckl> Sorry, I'm not that familiar with libinput and other libraries, so can only be of limited help. The way input events are sent from a Wayland compositor to a client is typically through https://wayland.app/protocols/wayland#wl_seat, which abstracts away individual input devices; so nested Wayland compositors will not be able to tell, from the protocol, which specific input device did what.

03:04 <mstoeckl> A non-nested compositor would directly use libinput, and I suspect (not having seen it) the gamescope code related to libinput is used when running gamescope directly/as the root compositor.

03:09 <mstoeckl> There are proposals to more directly expose input devices through the Wayland protocol; see for example https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/110, but I haven't looked into them

03:11 <mstoeckl> Ultimately: I think the issue you've linked may require new Wayland protocol to implement cleanly, which could take a while and a lot of work. (Or maybe someone's already set up the needed pieces; I don't know the area that well.)

03:24 <davidawesome> 1. I dont think seats directly expose input devices to subcompositors because that would allow them to esencialy take over the main session; I think its a kind of hidden thing, but mby I am wrong, I was looking into that a bit but wayland seats are slightly confusing. Yes, I think direct version would directly use libinput and do that, but I belive gamescope uses libinput to proxy

03:24 <davidawesome> events to a new wayland session exposed to the inner windows. Basing this off of my probably incorrect understanding of the code in /src/ with libinput and "inputemulation.cpp". If I do this project, I will most likely use evdev then, because I will not be getting into wayland dramma for protocals lol, and this is a 3 year old (not that old in wayland time) merge request (1+ years

03:24 <davidawesome> into the need acks phase, with people arguing about the steamdeck too now lol) I feal if I want to implement currenly I have to know it wont be clean, but thats fine, the requirement for evdev raw will be a problem in a lot of cases for this, but it should *work*, the root requirement to access evdev, or adding udev rules will be phrobitiory, but if included in a package, would be

03:24 <davidawesome> configured on install anyway. This would erode some of the wayland trust thats normaly used, but for somthing as small as this it honestly is fine, much better than x11 too. If I am mistaken, let me know, but I feal this is prob going to be what I have to do if I want it to work, do it in gamescope and run as admin, or host a dameon to talk to gamescope, or do the damean and abuse

03:24 <davidawesome> ldpreload. I think gamescope mods are easier, but if anyone knows, including you, if there is a better way, please let me know.

03:26 <davidawesome> I find this intresting and honestly think it would be a good project especialy with linux gaming on the rise, the idea of playing with friends on somthing like a steamdeck on any game like a split screen one in this way seams like somthing worth making

03:29 <davidawesome> personaly thats my idea, but this concept can be used for multiple things, including single gpu multiseat support on multiple screens as the single screen thing is a option, not a requirement of such a system depending on how its implemented

03:32 <davidawesome> If anyone has any other place I should ask about this kind of stuff, please let me know, I am not used to wayland dev process nor IRC

03:43 <davidawesome> Also for IRC, do you guys use the ZNC IRC bouncer, in docker, or how do you guys deal with missed messages?

03:51 <psykose> i use soju as a bouncer i host on some server

03:51 <psykose> there's various paid bouncer services too

03:53 <davidawesome> I have a few home servers, so I dont particularly mind; just concerned when the ISP comes to yell at me for being on tor 24/7. I may just use a small server on a buisness ip so I dont have to have tor 24/7 if I dont want my IP everywhere lol

05:43 <staceee> hey Wayland folks, someone have opinion about a session-lock client that would act as a compositor, to run things like virtual keyboards, or cherry-picked clients?

05:44 <staceee> does it predate the session-lock security as a whole? is there alternatives?

06:04 <davidawesome> gn anyone on, if you see my previous questions, please answer tmr :), no bouncer still

09:31 <orowith2os[m]> staceee: the compositor can already choose to run other privileged clients like IMEs and parts of the shell

09:34 <orowith2os[m]> just run a normal session-lock client, and other programs can run just fine in the locked environment

09:49 <staceee> how?

09:57 <orowith2os[m]> that's compositor policy

09:59 <orowith2os[m]> the ime protocols work on wl_surfaces, so they'll work just fine with an ext_session_lock_surface_v1, so long as you have something providing those protocols

10:00 <orowith2os[m]> sway and friends might show some shell elements in a locked state, you'll have to bother them for answers

10:03 <orowith2os[m]> hm, actually, now I'm curious - does ibus and fcitx expose some method somewhere that puts out a wl_global that compositors can put into their own list of globals?

10:08 <kennylevinsen> hmm? they just implement the IME protocols

10:33 <orowith2os[m]> kennylevinsen: I never looked at the specifics of *how* they did so

10:35 <orowith2os[m]> since the protocols are for the apps to interact with the compositor, how do compositors usually integrate fcitx and ibus with them?

10:35 <orowith2os[m]> and I know there's also the dbus interfaces for both on top of that

10:36 <kennylevinsen> fcitx and ibus talks one protocol to the compositor to control IME state, apps talk a different protocol to the compositor to manage its text fields

11:10 <orowith2os[m]> what protocol would that be?

11:11 <orowith2os[m]> dbus, or whatever the compositor chooses to support (of fcitx or ibus)?

11:11 <kennylevinsen> I'm only talking about wayland protocols

11:11 <kennylevinsen> fcitx is a regular wayland client when using the IME protocols

11:13 <kennylevinsen> see input-method-v2 and text-input-v3

16:18 <Giffoni> Good morning

16:19 <Giffoni> I'd just like to ask, i'm making a Rust GTK4 app that makes use of gtk4-layer-shell for the Niri window manager, i'm trying to implement this functionality and i'd like to know if it's possible:

16:20 <Giffoni> I just want to detect whenever the user's cursor touches and leaves a screen edge

16:20 <Giffoni> is it possible?

16:23 <danieldg> not easily; a dedicated protocol for that would be better than the current situation. I think you can combine relative pointer and a layer shell surface along the edge

16:23 <Giffoni> that was my initial plan, just wondered if there was a more appropriate way, thanks for the answer :)

17:14 <davidawesome> Hey im back :) going to try to setup a bouncer today, if anyone is on who knows more about my previous questions, please let me know

17:42 <wlb> wayland-protocols Merge request !398 opened by Kenny Levinsen (kennylevinsen) ext-image-copy-capture: Introduce preferred_done event https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/398