On Thu, Nov 11, 2010 at 11:01:11AM -0800, Ping Cheng wrote: > On Thu, Nov 11, 2010 at 12:26 AM, Dmitry Torokhov > <dmitry.torokhov@xxxxxxxxx> wrote: > > > > I do not believe that current protocol design has an issue. MT protocol > > is really for representing devices reporting multiple touches on the same > > working surface which means that size stays the same for all touches. > > When we say multiple touches, do we mean multiple touches of the same > type or different types? If we mean different types (pen and finger), > the size could be different due to the differences in technology. For > Bamboo, the size is different for pen and touch. > I want to say that generally for same tool, when it makes sense we can scale so that different tools could pretend to have the same range. If there are really 2 vastly different devices superimposed together then maybe the best option is to treat them as 2 separate input devices. > >> I am asking because to me it does not make any sense to scale the values. > >> > >> Devices that have a touch layer superimposed over LCD screen have to > >> be calibrated for the system to know which ABS_X/Y corresponds to > >> which pixel. I suspect that Bamboo P&T may have similar issue with its > >> two superimposed input devices. Alos somebody suggested that the input > >> area usable for pen might be smaller than area usable for touch. > >> > >> This means we are most likely talking apples and oranges, even if we > >> scale them to be the same size. > >> > > > > No, I do not believe this is true. Consider touchscreen that you can > > touch with either stylus or finger, with stylus having better > > resolution suited for drawing/writing and finger just used for selecting > > UI objects. Obviously they work with the same number of pixels even > > though ranges reported by the hardware might differ. > > > >> So I think it is most sensible to leave the scales are reported by the > >> hardware because that gives a hint to the application which receives > >> the event that the inputs are in fact different. They will still be > >> when the events are scaled, it will be just harder to see from the > >> client point of view. > > > > It really depends on the device in question and we have several options: > > > > 1. Single multitouch device - unified working surface with the same > > characteristics, kernel scales properly. > > > > 2. 2+ logical devices - may have different size/resolutions, userspace > > will have to do arbitration if they are in the same physical package. > > > > With Bamboo I think option 1 makes more sense and is easier on everyone. > > I agree with you on "different size/resolutions" and "unified working > surface" for the two opitons above. And I also agree with you that we > should leave the arbitration to the userland for MT events for both > opitons. > > But, I think ABS_X/Y arbitration should be considered in the kernel to > reduce the overhead in userland. With option 1 you have natural ST arbitration - the first touch gets to report (ABS_X, ABS_Y), the rest will have to report ABS_MT_* till the first touch is lifted, right? Thanks. -- Dmitry -- 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
