00:57 <DemiMarie> Does wlroots always do composition, or can one use it without composition?

02:25 <soreau> DemiMarie: I guess that all depends on what you mean by composition, exactly

02:26 <soreau> it supports direct scanout of surfaces and pixman backend as opposed to gles/vulkan, at least

09:32 <kennylevinsen> DemiMarie: wlr_scene includes a renderer that will perform composition if called and if direct scanout fails. You can just not call that renderer if you don't want composition. Output layers also allow direct scanout with many surfaces.

10:46 <bluetail> Where would I need to look if I wanted to force input of a specific keyboard to a specific window? Or could I just catch all input of that specific device, and if it's input is used, to focus a specific window if it's not already done? I think wayland you cannot send keystrokes to a window while it's not in focus, correct?

10:54 <whot> bluetail: i don't think that's supported by any compositor, especially not so client-triggered (like x11 grabs) since it'd make it quite trivial to capture key events

10:55 <bluetail> whot no, through xdotool you can send keystrokes to windows even when unfocused. You could filter by specific ones

10:55 <bluetail> dotool won't send keystroke to windows

10:55 <bluetail> Tho if you focus it, it will. But not hidden

10:56 <whot> iirc the only way to send events to a specific window in X is using XSendEvent but that one is also ignored by toolkits for that reason

10:56 <whot> for normal key events xdotool will just use xtest, the closest to that would be e.g. the remote desktop portal

10:57 <whot> but that too is bound to focus, etc., so sending keystrokes to a random window is not something supported

10:57 <bluetail> I had a really old java game where I used that. But in the current use-case I just have a second game on a second table elsewhere in the room, and I want to focus that window when nearby. Maybe I should use a small proximity sensor. What do you think should I do?

10:57 <bluetail> Can't I just look with libinput if keyboard x is sending something, and then do the rest from there?

10:58 <whot> what's the exact use-case?

10:58 <bluetail> I got a taiko drum at the other end of the room running a firefox window with taiko no tatsujin. I don't want to focus it manually everytime I reseat myself

10:59 <bluetail> the drum is physically a keyboard

10:59 <bluetail> Zhong Taiko (Drum with sensing capability) but puts out with a ATMEL keyboard

11:01 <any1> In sway, you can map inputs to specific outputs or regions, but it probably doesn't work for keyboards as it's not considered meaningful

11:02 <bluetail> I am on sway :). Time for a use-case or maybe I can interface with libinput or something. Well, I just need to catch events of a specific keyboard

11:03 <any1> You could put the "keyboard" on a different seat. That way its focus doesn't change, but you would have to figure out a way to focus the seat in the first place

11:03 <bluetail> That's dumb.

11:04 <any1> Thanks?

11:04 <bluetail> I'll try to find a way for ... if keyboard ATMEL has been struck, and if a window is available that fits criteria, then focus it

11:04 <bluetail> If window already focused, do nothing

11:05 <bluetail> Sorry I didn't want to be offending. The idea that this has inherent complexity went a bit over my head

11:06 <bluetail> I am thankful for any input, but I also understand that it probably is rarely asked

11:07 <any1> "man 5 sway-input". Look for "seat". Allows you to have multiple foci

11:14 <whot> fwiw, libinput is totally the wrong level for this, it's a hw abstraction layer but you want to do logical things with the events

11:16 <whot> heh, fun idea: you could write the evdev events for alt-tab into the event node. then you put it on a different seat like any1 suggested, write the alt-tab events until it's focused on the right window and you have an uncle named robert

11:18 <whot> look for evemu-event for scripting this

11:28 <bluetail> whot I've setup the seat, and now the keyboard is only working on that workspace I've assigned it to. But it does not do any focusing. About hijacking the alt-tab... I don't like that at all. I guess, I just make a shortcut to focus said workspace.

11:29 <bluetail> If I however was using the machine with somebody else, that wouldn't work out. Dolphin-emu got background input which works with gamepad, I was hoping I could have something similar for firefox

11:31 <bluetail> `Background Input lets you use the controller or keyboard even if Dolphin isn't in focus`

11:32 <bluetail> I wonder how it still works in wayland 😕

11:33 <zamundaaa[m]> bluetail: controller inputs don't (yet) go through the compositor

11:33 <bluetail> So in other words, this will stop working once wayland has it corrected?

11:34 <bluetail> I was just curious at how that works, because it essentially is very similar to what I wanted

11:34 <zamundaaa[m]> Depends on how it's done, but binding it to window focus would be the goal

11:35 <bluetail> Well, no. You don't need window focus, thats the idea of background input

11:35 <bluetail> You could play a game, and your wife could browse youtube

11:35 <zamundaaa[m]> That's the idea of the Dolphin option, but not of routing inputs through the compositor

11:36 <zamundaaa[m]> What you want is really multi seat

11:39 <bluetail> zamundaaa[m] I have read sway man and I don't understand the seat section, I guess I am going to ask in #sway for a example configuration.