Hi,
On 18-04-15 03:35, x414e54 wrote:
A big problem with just saying "the game must use the joystick api" is that
the game won't work on a machine without a joystick unless the joystick api
is emulated for the mouse. This seems to me to be exactly the same problem
and requiring exactly the same solutions, except you have moved the code
from the client to the compositor, which is usually a bad idea. Also you
have made it a pain in the ass to create simple toolkits since they now have
to provide the joystick api.
By joystick I mean "generic axis device with buttons" we do not mean
an actually joystick, "controller api" may be a better word. If my
gaming mouse has 40 buttons, and a 7000+ dpi laser 3D mouse wheel (not
just the movement sensor), I want ALL of that information not just
what the wayland protocol designers think is best.
Obviously a "joystick" is confusing and more restrictive than allowing
the full access to the device marshalled by the compositor and then
the user can run it though whichever api they want this is why I
prefer Jonas' idea of using the actual evdev device but the compositor
can MITM the char buffer or something similar.
This is EXACTLY how games work on other platforms when using mouse,
they either use a raw USB/HID input api or in the case of older games
older than windows xp they use directinput. Obviously on windows you
would use xinput (which will do more abstracting for you) and rawinput
but on mac you use HIDManager for everything which also supports raw
mouse input. The point is using a well abstracted api you can do not
care what you get as long as it has at least 2 relative axis and 2
buttons.
You want the compositor todo this because the game knows nothing about
which evdev input device is associated with which seat, how does it
know what to open? Also this would be good from a security side as you
do not have to allow full user access to the evdev device which
another user on the same system may want to use. You can have the
compositor refer to a security or sandboxing api.
Right.
This has been discussed before, and as mentioned before I really
believe that we should not define a joystick API at all,
rather we should define an API which will allow an app to:
1) List devices which it can get raw access to
2) Request raw access, if this succeeds the app will be handled
an evdev fd for the device
3) Notify the app that the compositor is revoking access (e.g.
because the app lost focus), when this happens the compositor
will do a revoke ioctl on the evdev fd rendering it useless
to the app, so the app cannot keep using this (so no security
issue).
4) Hand a new evdev fd to the app when it regains access.
This will allow whatever gaming crazy devices pop up to work,
and will allow force feedback to work too.
I think that trying to define a wayland "controller" protocol for
this is not a good idea, we will just end up wrapping evdev and
adding a whole lot of unnecessary indirection. Currently
games (e.g. libSDL) already are used to opening raw evdev nodes,
by moving the enumeration + actual opening into the compositor
we are fixing the security concerns of the old approach while
keeping all the good bits of it (mainly giving games raw
access to complex input devices), and this also solves the
seat assignment problem neatly.
Regards,
Hans
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
