On Tue, Apr 04, 2017 at 08:52:03AM +0100, Steven Newbury wrote: > On Tue, 2017-04-04 at 13:42 +1000, Peter Hutterer wrote: > > On Mon, Apr 03, 2017 at 10:19:16PM -0500, Joshua Watt wrote: > > > > > > > > > On 04/03/2017 07:22 PM, Peter Hutterer wrote: > > > > On Tue, Apr 04, 2017 at 08:16:03AM +0900, Carsten Haitzler wrote: > > > > > On Fri, 31 Mar 2017 17:29:19 +1000 Peter Hutterer <peter.hutter > > > > > [email protected]> > > > > > said: > > > > > > > > > > If you're going to do this ... why not just do it for > > > > > keyboards, mice, touch > > > > > panels etc. too? > > > > > > > > all these have desktop interactions that the compositor needs. > > > > joysticks > > > > generally don't, the compositor doesn't care about the events. > > > > > > Is that really true? It seems like there are certainly use cases > > > where a > > > compositor *would* use the Joystick or gamepad as a primary > > > navigation > > > device (think SteamOS or some IVI shell). Maybe it could be said > > > that these > > > are all going to be custom compositors at this point, but I > > > wouldn't want > > > discount that such behavior could be desired in the future. > > > > yes, you're right, but let me be more precise: keyboards/mice/... > > always [1] > > have desktop interaction, the need to pipe them through to an > > application is > > relatively niche. So unlike joysticks, the compositor cannot ignore > > them. > > (and this was mostly in reply to the "sticking your head in the sand" > > accusation) > > > Couldn't it be possible to snoop on the inputfd stream and listen for > "compositor events", i.e. system global buttons. Obviously modifying > the stream would add undesirable latency so it probably wouldn't be > possible to filter out those "compositor event" buttons, not sure how > much that matters..?
evdev supports masking events, so the solutoin for that would be to open the device twice, once masking everything but BTN_FOO and once masking only BTN_FOO - that's the one to pass to the client. Then you don't get wakeups for other buttons in the compositor and you know the client won't ever receive BTN_FOO. > > inputfd only gives you access to a device, it doesn't dictate how the > > device > > is used otherwise. IOW inputfd lets you use the joystick in the > > compositor, > > all you have to do is implement correct focus management. > > That's an improvement over the current situation where you have > > multiple > > processes accessing the device working with a cooperative model. > > > This is why it's really needed, games need the minimum latency they can > get, an input arbitration model is essential. I wonder if a new > inputfd X extension wouldn't be possible too? Currently, many games > just directly open evdev or input/js devices which isn't really ideal. maybe, but that's a lot more complicated that it would seem at first, and in the X world of everyone having access to everything directly opening the evdev node isn't much worse than the situation we already have :) > > Note that it is also possible with this protocol to have a > > keyboard/mice/... > > fd passed to the client if the latency of going through the > > compositor is > > too high. Not in the immediate draft, but it's just one > > get_seat_keyboards() > > or get_seat_mice() away. > Getting especially mice through inputfd is something people are > definitely going to want, especially for FPS type games, and > particularly now "serious" gamers are using extremely high screen > refresh rates ie 120/144Hz. good point. Cheers, Peter _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
