New approach to multitouch using DIDs and bitmasked events

Peter Hutterer peter.hutterer at who-t.net
Sun Jul 18 22:17:08 PDT 2010


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
> 



More information about the xorg-devel mailing list