On Mon, 4 Dec 2000, Stefan Seefeld wrote:
> But I agree with the proposition: why not provide a function
> to specify scaling factors (possibly independently for X/Y)
> to be used *inside* gii such that the reported event position
> already contains that scaling.
Basically to avoid bloat... If you support any kind of simple scaling,
then someone will want to support more complex scaling, e.g. scaling that factors in
the size or dpi of the visual, or that adds dead-zones or sensitivity curves
for joysticks, etc. Then you have to either add that into LibGII, or you
have to deal with one way of doing it being in LibGII and another way being
external.
> Should be fairly trivial to add,
> but makes a nice convenience function...
What you're wanting is a "event filter". EvStack, which was planned
to be eventually both a userspace and kernelspace solution, had
filters that you could insert between the raw event source and your program.
LibGII considered using filters for things as basic as separating press
from release events, but they were discarded in favor of the event mask.
With the exception of LibGIC, which you can find in the snapshots but it
is not exactly what you want, input filters have managed to fall through
the cracks.
They could easily be re-implemented as an "input-lib" that wraps the
GGI "input-lib" in a way much like the palemu and trueemu targets do for
visuals. E.g.
export GGI_INPUT="filter:/etc/myprog/giifilters.conf"
Where giifilters.conf has a list of types of events to act on and how to
act on them. This has the advantage of perhaps later being movable to
kernel space so that things like simulated autorepeat can be timer driven.
--
Brian
