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..?
> 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. > 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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
