-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
|>>> With the latest kernel we can use the Touchscreen with no further |>>> user-space filtering. I'd like to test this. |>> What is the benefit? |> Briefly stated: We think it's better if the driver sends only good data to |> the applications. If there are multiple distributions for a device (there | Ouch, this looks like a huge step backward. tslib has the stackable plugin | architecture for a reason. Where is the connection between the input_handler | for evdev and the calibration data? It's a good point, is there a way to associate the input event device that sends coordinates with the way that you set its calibration? | It has so many layering violations that I don't know where to start and can Cleaning of touchscreen data in kernel itself violates nothing; before the decimation in-kernel that we have now was done, there was a dumb and inadequate 32-sample averaging action in-kernel anyway, followed by tslib. Now the arrangements in kernel that are specific to the touchscreen shipped give great data already, tslib seems needless. If I understood what Nelson is asking, it's just about removing tslib from inbetween the input subsystem data and XGlamo. Not --> | just propose to do right mouse button emulation and sending of relative | coordinates in kernel as well... But then you could just write another | input_handler sending out PS2 compatible coordinates... | | Where was this discussed? All of this other stuff just got invented on this thread: kernel touchscreen filter stack has been discussed on kernel list several times. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAklVQLYACgkQOjLpvpq7dMo2zwCeNPR4j2MDzXPBHRVFx853iW0M BkIAn2kNZfitsxM3zcI0Mb2Z77oOSy2g =hbLo -----END PGP SIGNATURE----- _______________________________________________ devel mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/devel
