[Wayland-bugs] [Bug 90068] Raw, HID and Direct libInput Protocol.

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=90068

x414e54 at linux.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement

--- Comment #1 from x414e54 at linux.com ---
I came up with a quick usage scenario that may help to understand some of the
ideas:


A user has a mouse, keyboard and PS4 controller plugged in. 

The PS4 controller has a trackpad with a single click interface and the user
may have set the compositor to use the PS4 trackpad and the mouse to the
wl_pointer. 

The compositor can tell the user is using the PS4 controller based on sensor
(gyro/accelerometer) data from the controller and sets the controller as
"default" for relative/game input. The user may be sat some distance away from
the screen unable to use the mouse and keyboard.

The user opens a game which requests the "default" input device from Wayland
the game does not care what it is just that it can be used to play games or get
relative 2 axis motion. Wayland either sends a pointer to libinput events or a
fd to a marshaled evdev device.

The game can automatically map the first axis of the PS4 controller which the
user may have set up to be the right thumb stick as the axis it uses for "mouse
look". Or if the application is fully aware it can just switch to gamepad mode.
The compositor does not need to confine or lock the pointer as the trackpad is
a different device to the gamepad.

When the user uses the PS4 trackpad they move the pointer outside of the window
and click on another window such as a music application. Change the song, then
return to the game window.

The user may then press the home button on the PS4 controller and the
application becomes fullscreen or works as a task switcher. Any subsequent or
long presses of the home button will open exposay or some special full-screen
compositor overlay interface.

The user moves back to the desk and puts the controller down and moves the
mouse. The compositor then switches the default input device back to mouse and
either the game can run as keyboard and mouse mapped to gamepad axis and
buttons (bindings taken care of in the WM settings) or if programmed correctly
can switch back to keyboard and mouse mode.


If you check out something like Steam OS it would be quite nice if it could use
this functionality directly in the compositor and set up all of the input
device ids and mappings directly. Rather than having Steam as a separate
application running on-top of GNOME and then have game interpret the evdev data
by hoping it uses the correct mapping information from SDL.


The other case is where a user is using a "magic mouse" or mouse which has a
built in touch area.

The user sets up the compositor to switch the wl_pointer to the trackpad when
the game requests the "default" input device. The game does not need pointer
lock or confinement because the user can use the trackpad to move the pointer
but the mouse will be used in game. Also the relative events no-longer come
from the same device as the wl_pointer.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-bugs/attachments/20150417/adb1b28a/attachment.html>