Generalized Input Server Discussion
This session will be an open discussion about the future of input systems that are more generalized for all types of devices.
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- Chase Douglas
- Definition:
- Discussion
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Whiteboard
Problem:
New input device appear each day, most of them take a lot to get supported inside applications
Kernel drivers goes quicker just because they are are just broadcasting information.
Routing problem from device into applications through what?
Any app can read from a recognized input device directly, but the problem is in multiplexing events
Moving OIF stack to wayland ?
Fixed protocol for input
Scientific Research:
ICon: http://
Istar: Multiple input support in a model-based interaction framework
not so scientific, and in French, but about Linux: L'évolution de Linux vers les nouvelles formes d'ordinateurs personnels
Industry:
Khronos Input Standard: http://
Performance:
Implenting a "Router" for events not a full server (through a special filesystem)
Possible features:
Virtual devices which can be sub-inputs from 2 others
Add filters blocks between input and apps.
Kinect as an example, provides depth input, add
Wayland Transition:
Still very similar to evdev, kernel broadcasting
Factorizing some parts from X (libxkbcommon, ...)
Actions
Don't take design action cause of legacy usage (mouse/app)
Build kernel input with a extensible protocol
Make the input server modular from the start (don't read only from udev/kernel, allow to build new input module like tuio, network, optical tracker, local file, custom app...)
Come with a semantics that legacy device can be built on (mouse)
=> Start a group, invite some people and write a proof-of-concept
