On Fri, Nov 5, 2010 at 12:15 PM, Ping Cheng <pingli...@gmail.com> wrote: > On Thu, Nov 4, 2010 at 6:01 PM, <ch...@cnpbagwell.com> wrote: >> From: Chris Bagwell <ch...@cnpbagwell.com> >> >> First two patches are cleanups based on feedback on mailing list. > > I am fine with the first 2 patches. So, they are: > > Acked-by: Ping Cheng <pingli...@gmail.com>
Thanks. > >> Last one is resend of MT support. This version has change such that >> it will only compile in MT support if you have 2.3.36+ kernel headers >> in /usr/include/linux or have somehow added a -I/path to find those >> headers. This is because ABS_MT_SLOT was first defined there. > > I'd like to hold on to the third one for now. I'm OK with that. > I want to see how we are > going to report the first finger data in the kernel. We need to take > care of the following cases: > > the second finger is not down; For your first two cases, I think MT spec defines it pretty good and already some applications depend on a specific behavior. For this case, we should send ST events as well as MT events for 1st finger only. Kernel side is intelligent enough not to send 2nd finger data as long as we force ABS_MT_TRACKING_ID=-1 and X/Y/PRESSURE=0 during this case in driver (which we are). > both fingers are down; For this part, we should always send ST events and *attempt* to send two sets of MT fingers. I say attempt because the slot logic on kernel side is intelligent enough to only send MT events for fingers that have changed. If back-to-back sends result in only 2nd finger changing then it will not bother sending ABS_MT_SLOT=0 message events; and its for same reason it doesn't send them during ABS_MT_SLOT=-1 and X/Y/PRESSURE=0. So the MT behavior is mostly out of our control. > pen is in prox; > pen is out prox. Yep. TBD it seems. > > I hope we can come up with a way in the kernel that supports a smooth > transition from single touch to MT. In this driver, we may want to > keep the single/first finger data and pad in the current CHANNEL based > design. Since the number of fingers will change in the future, storing > all MT data in a separate struct makes sense to me. I'd like to know > what you guys are thinking. If I understand your comment then, yes, I agree and is what the patch does. As we support more fingers then MAX_FINGERS should grow to that value and MAX_CHANNELS should be hard coded to MAX_FINGERS+1 to account for pad buttons. And for the foreseeable future, ABS_MT_SLOT should map directly to same channel #. Patch only requires those #define changes for more fingers. This patch already handles ST-only events and ST+MT combination events transparently. I think it even handles MT-only events that is being proposed while pen is in proximity (not the proposed masking though) but it needs to test to be sure. Chris > > Ping > >> Chris Bagwell (3): >> Detect generic tablets with BTN_TOOL_FINGER. >> Use self describing logic for generic touchpad btns >> Enable 2nd touch for newer Bamboo MT driver > ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
