New approach to multitouch using DIDs and bitmasked events

[Micki Balanga]

Hi All,
My name is Micki , I works at N-trig. 
I am responsible on the Linux development at N-trig. 
I would like to participle the discussion of adapting multi-touch protocol into Xorg server and share my knowledge regards this issue. 
I had read the posts and I would like to raise a question: 
Is there any distinguish between single touch and multi-touch events?
I think, there are some scenarios need to take into account:
a. Touching the screen with one finger and then after a while you touch the screen with another finger.
b.  Gestures for example zoom , rotate. 

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 
(like Mohamed Ikbel Boulabiar suggested) an application which analyze current movement: 
a single touch or multi –touch movements (more than one finger). 
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.

Do you supports that kind of application, is there a set of new multi-touch commands?
Is there a code I can download for testing to add my feedbacks as well?
 
Regards,
Micki 

________________________________

מאת: xorg-devel-bounces+micki=n-trig.com at lists.x.org בשם Peter Hutterer
נשלח: ב 19/07/2010 08:17
אל: Simon Thum
עותק לידיעה: xorg-devel at lists.x.org
נושא: Re: New approach to multitouch using DIDs and bitmasked events



On Sun, Jul 18, 2010 at 12:38:04PM +0200, Simon Thum wrote:
> Am 06.07.2010 22:39, schrieb Peter Hutterer:
> >>> what changes did you have planned?
> >> Well, I thought I'd make a function which does common
> >> post-initialization (post = after driver inited structs). To be
> >> sensible, this must be in xf86 so we can parse/access options.
> >> Currently, it's hacked into xf86InitValuatorAxis because of that.
> >>
> >> It you're moving toward server-inited structs, I guess such a post-init
> >> point will come to live?
> >
> > well, there's already xf86ProcessCommonOptions and there is no reason
> > another one couldn't exist. Possibly one automatically called after a
> > successful PreInit().
> Yes, I just checked back and that's exactly what I would need. Same for
> a static configuration of input transforms, I guess.
>
> Are you already working on this? I want to make sure we get this fixed.

haven't started yet, no.

> I'd problby do something naive like the attached stuff, though a hook in
> dix might be preferable. (Just for communicating my idea of it, don't
> apply!)

I don't think slotting it on top is just the way to go. Look at the driver
init process as a whole, it's a mess. some stuff is in the DIX, other stuff
in the DDX, rather randomly distributed in parts. I think mapping out a more
streamlined init process and then figuring out where to put the post init is
probably a better approach.

> (And sorry for letting this rot in my inbox!)
>
> Cheers,
>
> Simon

> From ec32ed5b747934d9d066cd6b8019b2af45915f5c Mon Sep 17 00:00:00 2001
> From: Simon Thum <simon.thum at gmx.de>
> Date: Sun, 18 Jul 2010 12:31:26 +0200
> Subject: [PATCH] fix xf86 backend-specific input initialization
>
> Instead of shoving it in rather unrelated places,
> move acceleration init into xf86NewInputDevice.
>
> Caveat: It's not clear atm how relevant other callers of ActivteDevice
> (like OpenDevice) actually are.
> ---
>  hw/xfree86/common/xf86Xinput.c |   27 ++++++++++++++++++++++++---
>  1 files changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c
> index 76d2d00..684b3c7 100644
> --- a/hw/xfree86/common/xf86Xinput.c
> +++ b/hw/xfree86/common/xf86Xinput.c
> @@ -108,6 +108,9 @@
> 
>  EventListPtr xf86Events = NULL;
> 
> +static int
> +xf86InputDeviceAfterDriverInit(DeviceIntPtr dev);

why not just call it xf86PostInitDevice?

Cheers,
  Peter

> +
>  /**
>   * Eval config and modify DeviceVelocityRec accordingly
>   */
> @@ -733,6 +736,19 @@ IgnoreInputClass(const IDevPtr idev, const InputAttributes *attrs)
>      return ignore;
>  }
> 
> +/*
> + * Apply backend-specific initialization. Invoked after ActiveteDevice(),
> + * i.e. after the driver successfully completed DEVICE_INIT and the device
> + * is advertised.
> + * @param dev the device
> + * @return Success or an error code
> + */
> +static int
> +xf86InputDeviceAfterDriverInit(DeviceIntPtr dev) {
> +    ApplyAccelerationSettings(dev);
> +    return Success;
> +}
> +
>  /**
>   * Create a new input device, activate and enable it.
>   *
> @@ -807,6 +823,14 @@ xf86NewInputDevice(IDevPtr idev, DeviceIntPtr *pdev, BOOL enable)
>          goto unwind;
>      }
> 
> +    rval = xf86InputDeviceAfterDriverInit(dev);
> +    if (rval != Success)
> +    {
> +     xf86Msg(X_ERROR, "Couldn't post-init device \"%s\"\n", idev->identifier);
> +     RemoveDevice(dev, TRUE);
> +     goto unwind;
> +    }
> +
>      /* Enable it if it's properly initialised and we're currently in the VT */
>      if (enable && dev->inited && dev->startup && xf86Screens[0]->vtSema)
>      {
> @@ -1323,9 +1347,6 @@ xf86InitValuatorDefaults(DeviceIntPtr dev, int axnum)
>       dev->valuator->axisVal[1] = screenInfo.screens[0]->height / 2;
>          dev->last.valuators[1] = dev->valuator->axisVal[1];
>      }
> -
> -    if(axnum == 0)  /* to prevent double invocation */
> -     ApplyAccelerationSettings(dev);
>  }
> 
> 
> --
> 1.7.1
>

_______________________________________________
xorg-devel at lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100721/2fcbc1af/attachment.htm>