On 08/02/2010 06:39 PM, Dmitry Torokhov wrote: > On Mon, Aug 02, 2010 at 03:03:15PM +0200, Henrik Rydberg wrote: >> On 08/02/2010 02:46 PM, Éric Piel wrote: >> >> [...] >> >>>> >>>> We can do better in the sense that since the device cannot comply with MT-A, we >>>> can do as close as possible to MT-B with less cpu usage. But frankly, the best >>>> solution at this stage seems to be to drop MT handling altogether, since there >>>> does not seem to be any plan to use it. >>> Ah, this alternative solution is a bit boring ;-) In addition it's not >>> compatible with my own master plan to eventually have the "pinch to >>> zoom" and "rotate to rotate" gestures work on my laptop, like in Windows ;-) >> >> >> Since rotational symmetry is what prevents us from implementing proper MT >> support, it is not likely going to work anyways. >> > > Not work at all or not work as good as with other devices? "Not as good" > is still OK, hardware is different and we have to make the best of it. > The same elantech does not export pressure (at lest the version in > mainline does not) and thus users are unable to adjust sensitivity. > Still the device is useable with Synaptics X. This whole thread started off as a question how the ABS_X/Y should be reported in the presence of two fingers. Given that the elantech driver can report _some_ point via ABS_X/Y, and the number of fingers, the device should be usable with Synaptics X. If there is a problem with a jumping cursor, I have a feeling this is a bug that should be fixed in Synaptics X. As far as I can tell, the MT events are not needed for this case. >>> So, let's agree on just the two patches I'm going to send to support >>> "better than nothing" MT-protocol for now. When, later, someone has >>> better ideas, he can send patches to improve MT-protocol >>> support/compliance. Fine? >> >> >> No. I think it is fair to say we tried to make it work properly, but the (known) >> information about the device is simply not enough. As long as MT does not work >> properly, there is no point in adding it at all - in particular not an elaborate >> solution. I can see that zoom would work even with a poor MT implementation, but >> that is not what the MT protocol is about. Maybe one day someone will find the >> missing information somewhere in the packets. >> >> For your usecase, perhaps one should add ABS_ZOOM etcetera instead, and patch up >> synaptics to use those values. > > No, I do not believe that this is the direcion we should be taking. I'd > prefer we export as much information as we can for MT to be useful. And > if we discover some missing pieces in proocol (or future firmware > revisioons will be smarter) we can improve MT support. > That is fine per se, I was simply looking for other options. The question then is how much MT support is needed. For existing applications (read Synaptics X), there should be no need for MT, so we should be able to wait with that part until the firmware gets smarter. If the idea is to use something like the Multitouch X Driver to enable zoom and rotate, this is where I am hesitant, given the current capabilities of the device. Henrik -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
