On Wed, 14 Jan 2009 10:01:20 +0000 Andy Green <a...@openmoko.com> babbled:
nothing to do with hardware here - all to do with software stack. the fact is there is no generic "zoom" control for apps - and apps have no concept of one. you also need to think about where in the stack you sit - if you go to /dev/input... you will be doing your own driver work specific to 1 hardware type - if that changes - you are going to have to adapt. the best bet is to do this higher up at the x level - but here you hit a problem. mouse events ONLY go to the window they are on (or to who grabbed the mouse). so in this case every app/toolkit needs to handle these themselves - OR you uxe an extension like xevie and we put in an indirector for all events - this indirector can/will be responsible for: 1. filtering (removing events, delaying and getting rid of garbage - it it wants) 2. selectively passing along some events and not others possibly with modifications (eg translate/scale the input/output - needed for a compositor if you do things like scale the window output in the compositor) 3. can interpret series of events into gestures and then produce some form of message (the protocol and standard are yet to be defined) that can be sent to the root window o the focused window - or possibly just execute some command etc. etc. :) > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Somebody in the thread at some point said: > > | Are there any hardware engineers who can verify whether or not the > | touch-screen on the Neo or FR could register or generate motion-based > | events? If not, is this something that could be done easily in > | userspace (i.e. inputproto)? > > You can just have an app eat /dev/input/event1 and figure out if it sees > such an action in the necessary timeframe to be a gesture, it won't > upset any other user of /dev/input/event1. Not sure where tslib > calibration fits in there but I guess for your purpose, you don't really > care since it is not associated with any absolute coordinate. > > - -Andy > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkltt/AACgkQOjLpvpq7dMpVxwCcCIdp3N8H+MAk2n6PQUCenclx > IjkAn0UN88xsER95XUbfh7chjj3ye0z6 > =bluP > -----END PGP SIGNATURE----- > > _______________________________________________ > devel mailing list > devel@lists.openmoko.org > https://lists.openmoko.org/mailman/listinfo/devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com _______________________________________________ devel mailing list devel@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel
