On Wed, 2017-04-05 at 10:25 +0100, Daniel Stone wrote: > Hi, > > On 5 April 2017 at 04:40, Carsten Haitzler <[email protected]> > wrote: > > On Tue, 04 Apr 2017 14:45:13 +0200 Bastien Nocera <[email protected] > > t> said: > > > There's two possible solutions to this problem: > > > - evdev gives you the ability the mask certain events. The > > > compositor > > > can keep one fd open masking everything but the power/menu/etc. > > > buttons, and pass an fd to the app with just the power/menu/etc. > > > buttons masked. The compositor can then choose to do something > > > special > > > with those buttons > > > - you can specify a new fd_type, as mentioned in the spec, which > > > your > > > application would need to know how to handle. That can be used to > > > implement the simpler protocol that got sent a couple of months > > > ago. > > > > then explain to me the argument where for example keyboard input > > should NOT > > also then do the same thing? > > Because, as stated up thread, keyboard and mouse devices involve > desktop interaction. So there we have our reason why it is essential > for the compositor to intercept _all_ keyboard and mouse events (any > keyboard event could be Alt-Tab, any mouse event could be moving out > of focus, etc: you cannot filter individual events), which does not > hold true for gamepad/joystick events (the filter suffices). > > Secondly, keyboard and mouse events work completely differently. > Mouse > events have acceleration applied, and the client's view of > acceleration _must_ match that of the compositor's in order to > achieve > the same view of position. I don't much feel like encoding an > acceleration algorithm in the protocol for all time, just because it > seemed like a good idea from 50,000ft. > > Keyboard events carry state which is longer-lived than focus. For > example, press caps lock and change your focus. (Please no-one > smartly > chime in about ctrl:nocaps, which FTR I also use.) > > The compositor _must_ interpose every single keyboard/mouse event, > and > they are simple enough that it is possibly to easily encode them with > universally-accepted concepts. Neither is true of gamepads or > joysticks. Hence, a different protocol. There's a reason the mouse support from the X DGA Extension out- survived the "direct framebuffer access". The latency through the wire whether X or Wayland for mouse input it just too high for mouse controlled high framerate 3D games. inputfd *will* be wanted for mice, and unlike keyboard there isn't the issue of state. Arbitration between desktop use and focused application utilising inputfd is the issue IMHO, and as Carsten says, I don't see why that is any different than if a game controller is your primary input device.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
