-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
| Maybe later, if that's done, people will start to wonder why tslib is | still necessary when we have a clean input device, but it's not today's | problem directly for us. | |> the problem is - a newer device or some other device not made by om then may |> or may not use tslib and thus now configuration etc. etc. all works |> differently. it makes life harder to maintain a consistent distribution across |> multiple devices. maintaining consistency is GOOD. :) move as much as possible |> to config. :) Somehow the story that providing clean data to input event device is wrong thing to do is failing to make sense to me :-) I also imagine that I was telling people to add a new userspace library to everything because I had dirty data coming out of the kernel, and the new and exotic flames that would generate. Right-click emulation being done there instead of a generic in-kernel filter doesn't sounds like a reason that could be leveraged into that infrastructure being created if it didn't already exist. The two things about ~ - cleaning up the touchscreen data in kernel, and ~ - whether to maintain tslib linkage in userspace for basically API compatability reasons are separate issues... the first is the right thing to do IMO and the second is a useful option we're looking at because we think it might help get the kernel filter stuff upstream, but not proposing to get changed in OM userspace. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAklYxQQACgkQOjLpvpq7dMr/0wCeOF8gEx3PtDYzayG/nfRrzWgy CdcAn0qwMR4tozU1nNy6eAZvKkff2a4e =p7Ky -----END PGP SIGNATURE----- _______________________________________________ devel mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/devel
