<HTML dir=rtl><HEAD><TITLE>Re: New approach to multitouch using DIDs and bitmasked events</TITLE> <META content="text/html; charset=unicode" http-equiv=Content-Type> <META name=GENERATOR content="MSHTML 8.00.6001.18904"></HEAD> <BODY><FONT color=#000000 size=2 face=Arial> <DIV dir=rtl> <TABLE border=0 cellSpacing=0 cellPadding=0> <TBODY> <TR> <TD vAlign=top> <DIV dir=ltr>Hi All,</DIV> <DIV dir=ltr>My name is Micki , I works at N-trig. <BR>I am responsible on the Linux development at N-trig. </DIV> <DIV dir=ltr>I would like to participle the discussion of adapting multi-touch protocol into Xorg server and share my knowledge regards this issue. </DIV> <DIV dir=ltr>I had read the posts and I would like to raise a question: </DIV> <DIV dir=ltr>Is there any distinguish between single touch and multi-touch events?<BR>I think, there are some scenarios need to take into account:</DIV> <DIV dir=ltr>a. Touching the screen with one finger and then after a while you touch the screen with another finger.</DIV> <DIV dir=ltr>b.  Gestures for example zoom , rotate. </DIV> <DIV dir=ltr><BR>I think that before sending an event to the server, there should be an application which handles all touch events and transfer the right message to server according to movement type </DIV> <DIV dir=ltr>(like Mohamed Ikbel Boulabiar suggested) an application which analyze current movement: <BR>a single touch or multi –touch movements (more than one finger). </DIV> <DIV dir=ltr>For example: In N-trig we developed gesture engine which analyze the current message received from the sensor, analyze the data and transfer it as multi-touch events.</DIV> <DIV dir=ltr><BR>Do you supports that kind of application, is there a set of new multi-touch commands?<BR>Is there a code I can download for testing to add my feedbacks as well?</DIV> <DIV dir=ltr> </DIV> <DIV dir=ltr>Regards,<BR>Micki </DIV></TD></TR></TBODY></TABLE></DIV></FONT> <DIV dir=rtl><BR></DIV> <DIV dir=rtl> <HR tabIndex=-1> </DIV> <DIV dir=rtl><FONT size=2 face=Tahoma><B>מאת:</B> xorg-devel-bounces+micki=n-trig.com@lists.x.org בשם Peter Hutterer<BR><B>נשלח:</B> ב 19/07/2010 08:17<BR><B>אל:</B> Simon Thum<BR><B>עותק לידיעה:</B> xorg-devel@lists.x.org<BR><B>נושא:</B> Re: New approach to multitouch using DIDs and bitmasked events<BR></FONT><BR></DIV> <DIV> <P><FONT size=2>On Sun, Jul 18, 2010 at 12:38:04PM +0200, Simon Thum wrote:<BR>> Am 06.07.2010 22:39, schrieb Peter Hutterer:<BR>> >>> what changes did you have planned?<BR>> >> Well, I thought I'd make a function which does common<BR>> >> post-initialization (post = after driver inited structs). To be<BR>> >> sensible, this must be in xf86 so we can parse/access options.<BR>> >> Currently, it's hacked into xf86InitValuatorAxis because of that.<BR>> >><BR>> >> It you're moving toward server-inited structs, I guess such a post-init<BR>> >> point will come to live?<BR>> ><BR>> > well, there's already xf86ProcessCommonOptions and there is no reason<BR>> > another one couldn't exist. Possibly one automatically called after a<BR>> > successful PreInit().<BR>> Yes, I just checked back and that's exactly what I would need. Same for<BR>> a static configuration of input transforms, I guess.<BR>><BR>> Are you already working on this? I want to make sure we get this fixed.<BR><BR>haven't started yet, no.<BR><BR>> I'd problby do something naive like the attached stuff, though a hook in<BR>> dix might be preferable. (Just for communicating my idea of it, don't<BR>> apply!)<BR><BR>I don't think slotting it on top is just the way to go. Look at the driver<BR>init process as a whole, it's a mess. some stuff is in the DIX, other stuff<BR>in the DDX, rather randomly distributed in parts. I think mapping out a more<BR>streamlined init process and then figuring out where to put the post init is<BR>probably a better approach.<BR><BR>> (And sorry for letting this rot in my inbox!)<BR>><BR>> Cheers,<BR>><BR>> Simon<BR><BR>> From ec32ed5b747934d9d066cd6b8019b2af45915f5c Mon Sep 17 00:00:00 2001<BR>> From: Simon Thum <simon.thum@gmx.de><BR>> Date: Sun, 18 Jul 2010 12:31:26 +0200<BR>> Subject: [PATCH] fix xf86 backend-specific input initialization<BR>><BR>> Instead of shoving it in rather unrelated places,<BR>> move acceleration init into xf86NewInputDevice.<BR>><BR>> Caveat: It's not clear atm how relevant other callers of ActivteDevice<BR>> (like OpenDevice) actually are.<BR>> ---<BR>>  hw/xfree86/common/xf86Xinput.c |   27 ++++++++++++++++++++++++---<BR>>  1 files changed, 24 insertions(+), 3 deletions(-)<BR>><BR>> diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c<BR>> index 76d2d00..684b3c7 100644<BR>> --- a/hw/xfree86/common/xf86Xinput.c<BR>> +++ b/hw/xfree86/common/xf86Xinput.c<BR>> @@ -108,6 +108,9 @@<BR>> <BR>>  EventListPtr xf86Events = NULL;<BR>> <BR>> +static int<BR>> +xf86InputDeviceAfterDriverInit(DeviceIntPtr dev);<BR><BR>why not just call it xf86PostInitDevice?<BR><BR>Cheers,<BR>  Peter<BR><BR>> +<BR>>  /**<BR>>   * Eval config and modify DeviceVelocityRec accordingly<BR>>   */<BR>> @@ -733,6 +736,19 @@ IgnoreInputClass(const IDevPtr idev, const InputAttributes *attrs)<BR>>      return ignore;<BR>>  }<BR>> <BR>> +/*<BR>> + * Apply backend-specific initialization. Invoked after ActiveteDevice(),<BR>> + * i.e. after the driver successfully completed DEVICE_INIT and the device<BR>> + * is advertised.<BR>> + * @param dev the device<BR>> + * @return Success or an error code<BR>> + */<BR>> +static int<BR>> +xf86InputDeviceAfterDriverInit(DeviceIntPtr dev) {<BR>> +    ApplyAccelerationSettings(dev);<BR>> +    return Success;<BR>> +}<BR>> +<BR>>  /**<BR>>   * Create a new input device, activate and enable it.<BR>>   *<BR>> @@ -807,6 +823,14 @@ xf86NewInputDevice(IDevPtr idev, DeviceIntPtr *pdev, BOOL enable)<BR>>          goto unwind;<BR>>      }<BR>> <BR>> +    rval = xf86InputDeviceAfterDriverInit(dev);<BR>> +    if (rval != Success)<BR>> +    {<BR>> +     xf86Msg(X_ERROR, "Couldn't post-init device \"%s\"\n", idev->identifier);<BR>> +     RemoveDevice(dev, TRUE);<BR>> +     goto unwind;<BR>> +    }<BR>> +<BR>>      /* Enable it if it's properly initialised and we're currently in the VT */<BR>>      if (enable && dev->inited && dev->startup && xf86Screens[0]->vtSema)<BR>>      {<BR>> @@ -1323,9 +1347,6 @@ xf86InitValuatorDefaults(DeviceIntPtr dev, int axnum)<BR>>       dev->valuator->axisVal[1] = screenInfo.screens[0]->height / 2;<BR>>          dev->last.valuators[1] = dev->valuator->axisVal[1];<BR>>      }<BR>> -<BR>> -    if(axnum == 0)  /* to prevent double invocation */<BR>> -     ApplyAccelerationSettings(dev);<BR>>  }<BR>> <BR>> <BR>> --<BR>> 1.7.1<BR>><BR><BR>_______________________________________________<BR>xorg-devel@lists.x.org: X.Org development<BR>Archives: <A href="http://lists.x.org/archives/xorg-devel">http://lists.x.org/archives/xorg-devel</A><BR>Info: <A href="http://lists.x.org/mailman/listinfo/xorg-devel">http://lists.x.org/mailman/listinfo/xorg-devel</A><BR></FONT></P></DIV></BODY></HTML>