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.