Hi Anisee Anstier, >> 1. This can be hardware-dependent code. >> >> There are two or more types Linux MT protocol. (You can see here >> <http://www.google.co.kr/url?q=http://www.mjmwired.net/kernel/Documentation/ >> input/multi-touch-protocol.txt&sa=U&ei=BaV5Tqr5O- >> 3UmAWYhInLAQ&ved=0CBAQFjAA&sig2=U9xA2Bo40_i6yfBqEBgwLw&usg=AFQjCNFe7mFV5heDy >> IKS3IGHzr-0GFJ_eA> .) >> Protocol A, B and so on. >> >> In system whose kernel uses MT protocol A, ABS_MT_TRACKING_ID event won¡¯t >> be made. >> Then _ecore_mouse_move() won¡¯t be called in _ecore_x_input_handler() in >> your patch.
> What you say is true, but not in this case. This implementation is for > the xorg-x11-drv-mtev driver, that uses the mtdev library > (http://bitmath.org/code/mtdev/). The mtdev library takes care of the > protocol abstraction and does finger tracking. I thought you would like to patch this code to upstream. If you would, it can be problem in system which doesn’t support tracking id. If not, sorry for misunderstanding. :) >> >> >> 2. As you mentioned earlier in your mail, event for the first finger will >> be made twice. >> >> When you move with the first finger, it makes MotionNotify and >> XI_MotionNotify for the same finger. >> Both events must be made and transferred via wire by Xserver at the same >> time. >> This can make overheads for transferring both X event and XI event between >> Xserver and application for the first finger. >> Besides in evas multi_down and multi_move callback, application must check >> deviceid everytime. >> >> Multitouch device can be configured on X system in some ways. >> (1) Each finger can be configured as an XISlavePointer attached to a master >> pointer. >> (2) Each finger can also be configured as an XIFloatingSlave. >> (3) One finger can be configured as an XISlavePointer and the others can be >> XIFloatingSlave. >> I¡¯d like to recommend that you take 3rd configuration in the above ways. >> >> >> >> First finger makes only X events as SlavePointer device. >> >> The other fingers make XI events as FloatingSlave device. >> >> Currently, ecore and evas code based on this configuration. >> >> Application gets mouse event as the first finger and gets multi events as >> the other fingers. >> >> Is there any difficulty to use the 3rd configuration in your platform ? >> >> >> >> If you didn¡¯t float 2nd/3rd finger from master pointer, the fingers will >> make X events such as ButtonPress/ButtonRelease/MotionNotify. >> >> For example, in a list widget in an application just gets X events, 2nd/3rd >> finger¡¯s movement will be affected. >> >> How about your opinions ? > That would be ideal for our use case, but AFAIK, there's no way to have > multiple pointers in one X driver, nor control the type of pointer, ie > make it a SlavePointer or FloatingSlave (this could be done *after* the X > server is launched, but would require an additionnal program). IMO, there is a way to have multiple pointers in a X driver such like Benjamin Tissoire's multitouch driver. (http://cgit.freedesktop.org/~tissoire/xf86-input-evdev/ It's a little bit outdated and something like a hack but it can be useful. :) ) This can be hack of evdev driver, but evdev driver can also be used for several devices at the same time. Multitouch pointers are physically in a device but logically in each device. You can also make a pointer device as FloatingSlave just by setting SendCoreEvents option off. (Ex> pInfo->options = xf86AddNewOption(pInfo->options, "SendCoreEvents", "off"); ) > In its current form, Ecore_X's input support is MPX (Multi-pointer) > oriented. But having multiple pointers is quite different from supporting > multi-touch, and that's why XI2 is being reworked (see first email and > http://liveweb.waybackmachine.org/http://who-t.blogspot.com/2010/10/thoughts-on-linux-multitouch.html > (a bit outdated)). You're right. Current ecore x backend is based on MPX. As you mentioned, MPX is different from multitouch therefore if you want to implement multitouch stuff using MPX, IMO, you may have to make the 2nd/3rd finger uninfluential to the master pointer. That's why FloatingSlaves are only selected by XISelectEvents() in ecore x backend. Of course, Peter Hutterer is making X protocol stuff for multitouch. When it’s ready, we can get multitouch events through XI_TouchBegin/XI_TouchUpdate/XI_TouchEnd type. Thus, the attachment such as SlavePointer, FloatingSlave doesn't matter at that time because each touch device doesn't any make pointer events. Until the multitouch protocol is ready, we may use MPX for implementing multitouch. :) Best regards, Sung-Jin Park -----Original Message----- From: Anisse Astier [mailto:ani...@astier.eu] Sent: Wednesday, September 21, 2011 10:40 PM To: sj76.p...@samsung.com Cc: enlightenment-devel@lists.sourceforge.net; 이상진 Subject: Re: [E-devel] [PATCH RFC] Ecore: Ecore_X : adapt XInput2 handling to support multitouch events with mtev Hi Sung-Jin, First of all, thanks for you review, On Wed, 21 Sep 2011 21:02:21 +0900, Sung-Jin Park <sj76.p...@samsung.com> wrote : > Hi, > > > > I have several opinions about the code. > > > 1. This can be hardware-dependent code. > > There are two or more types Linux MT protocol. (You can see here > <http://www.google.co.kr/url?q=http://www.mjmwired.net/kernel/Documentation/ > input/multi-touch-protocol.txt&sa=U&ei=BaV5Tqr5O- > 3UmAWYhInLAQ&ved=0CBAQFjAA&sig2=U9xA2Bo40_i6yfBqEBgwLw&usg=AFQjCNFe7mFV5heDy > IKS3IGHzr-0GFJ_eA> .) > Protocol A, B and so on. > > In system whose kernel uses MT protocol A, ABS_MT_TRACKING_ID event won¡¯t > be made. > Then _ecore_mouse_move() won¡¯t be called in _ecore_x_input_handler() in > your patch. What you say is true, but not in this case. This implementation is for the xorg-x11-drv-mtev driver, that uses the mtdev library (http://bitmath.org/code/mtdev/). The mtdev library takes care of the protocol abstraction and does finger tracking. > > > 2. As you mentioned earlier in your mail, event for the first finger will > be made twice. > > When you move with the first finger, it makes MotionNotify and > XI_MotionNotify for the same finger. > Both events must be made and transferred via wire by Xserver at the same > time. > This can make overheads for transferring both X event and XI event between > Xserver and application for the first finger. > Besides in evas multi_down and multi_move callback, application must check > deviceid everytime. > > Multitouch device can be configured on X system in some ways. > (1) Each finger can be configured as an XISlavePointer attached to a master > pointer. > (2) Each finger can also be configured as an XIFloatingSlave. > (3) One finger can be configured as an XISlavePointer and the others can be > XIFloatingSlave. > I¡¯d like to recommend that you take 3rd configuration in the above ways. > > > > First finger makes only X events as SlavePointer device. > > The other fingers make XI events as FloatingSlave device. > > Currently, ecore and evas code based on this configuration. > > Application gets mouse event as the first finger and gets multi events as > the other fingers. > > Is there any difficulty to use the 3rd configuration in your platform ? > > > > If you didn¡¯t float 2nd/3rd finger from master pointer, the fingers will > make X events such as ButtonPress/ButtonRelease/MotionNotify. > > For example, in a list widget in an application just gets X events, 2nd/3rd > finger¡¯s movement will be affected. > > How about your opinions ? That would be ideal for our use case, but AFAIK, there's no way to have multiple pointers in one X driver, nor control the type of pointer, ie make it a SlavePointer or FloatingSlave (this could be done *after* the X server is launched, but would require an additionnal program). In its current form, Ecore_X's input support is MPX (Multi-pointer) oriented. But having multiple pointers is quite different from supporting multi-touch, and that's why XI2 is being reworked (see first email and http://liveweb.waybackmachine.org/http://who-t.blogspot.com/2010/10/thoughts-on-linux-multitouch.html (a bit outdated)). Regards, Anisse ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
