Enrico Weigelt wrote:
Hi folks,
Device class: Mouse
* linear coords, positions are device/config dependent
(acc.factor, etc)
* simple movement produces MOVE messages, buttons produce BUTTON messages
* axis-ids: are X and Y, optional wheel for Z
* CONNECT should not happen
what about additional wheels? what kind of acceleration will be provided?
does "angle", "linear" and logarithmic have anything to do with acceleration?
Device class: Touchpad/Touchscreen/Lightpen (when not in mouse emulation)
* has abs and rel coords
* simple touch produces MOVE to the touched position
* tapping produces MOVE and BUTTON click message
* the first button (tapping) most likely has no up/down messages
* additional send may produce BUTTON messages
what does the last point mean? how is touch-move-untouch messaged?
shouldn't tapping actually produce "down" upon touching and "up"
upon untouching (stopping to touch), at least retroactively with
the old timestamp? I think since those devices have an own class
(and are not in mouse-emulation) every touch should be sent as
a button-down message and everytime the touch does stop a button-up
should be sent -- tapping would then produce button-click.
Device class: keyboard
* no MOVE messages, only BUTTON (up/down/click)
* simple keyb input just checks for BUTTON click
All these device classes (except keyboard) should be mappable to
as Bill McConnaughey implied, shouldn't ocr allow for mapping
lightpen to keyboard? funny would be mapping keyboard to
touchscreen by interpreting key-press as touching the screen.
would require exact key-coordinates in the config-file though.
in general I have the basic question, since I and others probably
missed the discussion on this: how does this protocol compare to
the event-driver already provided by the linux-kernel? why should
I use gpm instead of the platform-specific event-device -- except
fo portability? what functionality will gpm provide in addition
to what is already provided by the OS? in above questions I assumed
gpm is supposed to be a high-level driver translating all the
low-level stuff. but then some sort of plugin-structure would
be nice for example providing custom mouse-accelerator technology.
also "mapping" of one device-class to another could be provided
as plugins. for example joystick to key mapping could be handled
by such a plugin which just translates joystick-coordinates into
repeadedly sent key-events. or (if that's a problem) a plugin could
send raw keyboard-data to some application upon joystick-movement.
for this protocol it means: please no "mouse-mode" or other
translations blocking event-flow from the device to the programs
interested. if someone wants to translate the signals, a new
device must be created and the data must be sent by that translator.
let gpm offer default-translators and remove all mention of "modes"
from this RFC. instead you should make a small program which does
serve textual info about the individual ptr-id and which device-class
it provides (for script-based event-access in text-mode). let the
user-space program handle the interpretation of the data instead
of assuming all user-space programs expect only mouse as input-device.
just standardize input-range for each device-class (i.e. 0..2pi
for angle, -1..1 for a new "bounded" type, and -inf..+inf for
the linear type of move-coordinates). and remove the logarithmic
type of coordinates, again something which should be handled
by plugins creating a new "translated" device. and add a new
protocol for device-info (i.e. if it's physical device or
virtually created, what type of device it is, dpi-info for
mice and Radial field sensor, and info about the type of
coordinates sent and whatever plugins used -- all through
some kind of external program which is a wrapper for libgpm).
at least this is my own wishlist for gpm2, this would make
gpm2 more pleasant/attractive for a device-driver in X.
P
_______________________________________________
gpm mailing list
gpm@xxxxxxxxxxxxxx
http://lists.linux.it/listinfo/gpm