[gpm] RFC: new event protocol

[Enrico Weigelt]

* Piotr Sawuk <a9702387@unet.univie.ac.at> wrote:

Hi,

> what about additional wheels? 

They simply get their own IDs. It's then up to the application to
handle them.

> what kind of acceleration will be provided?

none. those things are handled within the driver, nothing of 
interest to the application.

> does "angle", "linear" and logarithmic have anything to do with 
> acceleration?

no, that's just a hint to the app how the value is measured.
eg. an (analog) joystick will measure angles, same as some
force sensors (eg. gravitometer).

> >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? 

When the device has additional buttons (beside the touchscreen itself).

> 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? 

hmm, good point. I somehow mixed up mouse-emu and native mode ;-o
perhaps it's better to treat it like a mouse where touching 
equals button 0.

> 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.

ACK.
The translation to mouse-emu would simply leave out the button up/down.

Maybe we could even leave out the click-message on the raw interface
and let the upper layers (mouse-emu, etc) handle it.

> >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.

ACK. That would probably move us to some minimal gui ;-)

Actually, I intend to go this road someday:
I'm planning an new GUI system where the application simply describes
it's graphical structure (instead of contigious repaints) and can 
receive pointing within some graphics object (window, widget, whatever)
via exactly that protocol (just by reading an appropriate file!).

> 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? 

Totally different. The linux evdev is an userland interface to 
the kernel's input core subsystem (not just for receiving but 
also enqueing new events). So platform specific and not 
network transparent.

The proposed 9P interface is platform and network agnostic
(all you need is to access the server's exported files - now 
matter how it's done under the hood). And it just allows to
receive input device events. Nothing more, nothing less.

*Maybe* we someday could extend it to things like force feedback
or status LEDs, but that's far out of scope for now ;-p

> why should I use gpm instead of the platform-specific event-device 
> -- except fo portability? 

Exactly: portability.
And: network transparency.
And: have a *simple* interface - without the need for big APIs.
And: no need for huge client libraries - a few LOC are enough

> what functionality will gpm provide in addition
> to what is already provided by the OS? 

First of all: an platform independent interface, so application
developers don't have to care about that anymore.

> 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.

Yes, of course. But I dislike the idea of "plugins" in the way
this term is normally used: dozens of dynamic libraries which
hook up deeply into the main program. Better: strict modules
and process/data flow. In our case: separate services.

> for this protocol it means: please no "mouse-mode" or other
> translations blocking event-flow from the device to the programs
> interested.

Just to make it clear: with "mouse-mode" i meant devices (eg.
touchpads) which send the same signals/events as an mouse would do.
For example my notebook's touchpad presents itself as any standard
PS2 mouse.

> if someone wants to translate the signals, a new device must be 
> created and the data must be sent by that translator.

Exactly. Imagine an touchpad which does _NOT_ behave like mouse,
but tells exactly where the surface is pressed. If we want to
use it as a mouse replacement, we need some translator, which 
computes the move and click messages.

> let gpm offer default-translators and remove all mention of "modes"
> from this RFC. 

Yet another clarification: these "modes" were just meant as an
classification, which device types would send which messages.
Whether some device class is simulated on another one (eg. from
raw touchpad to mouse) is done by system configuration.

An program accepting mouse events will connect to an mouse device,
while an program accepting touchpad events will connect to an
touchpad device.

> and remove the logarithmic type of coordinates, again something 

hmm, the logarithmic type was just meant as an hint on the
type of scale. probably not necessary.

> 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).

These metadata will be provided through separate info files
within the device's filesystem hierachy.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------