[xserver][PATCH] Tablet to screen coordinate translation

Magnus Vigerlöf Magnus.Vigerlof at home.se
Thu Mar 8 14:10:58 PST 2007


On Wednesday 07 March 2007 23:41, Peter Hutterer wrote:
> > Hmm... I couldn't find any scaling code at all in GPE (branch
> > 'master').. Am I
> > in the same branch as you?
>
> let's call it cut-off scaling ;)

Gotcha ;)

> > Heh.. Ok, I'm just a bit careful making changes that would affect the
> > interface to the input drivers. The driver I'm working mostly with
> > (linuxwacom) need to support both Xorg and XFree86 so I wouldn't
> > mind if this
> > was solved with the current definitions of the structures. But if
> > getting a
> > better architecture will need a change, so be it. We'll cope as
> > long as we
> > can detect it.
>
> Using devPrivates could probably do it. ugly but wouldn't affect the
> interface. Personally I'd prefer having it in the struct though.

If we say that extension and core events should be generated within the same 
function I agree that the existing structs are not enough.

So.. Adding two function pointers to DeviceIntRec is the preferred way? Then 
we could initialize the pointers in two different places (at least). Copy 
over the pointers form LocalDeviceRec struct in xf86ActivateDevice, where the 
DeviceIntRec is allocated.
But that would force us to use the same interface as the old functions, maybe 
we should update the parameters to these two functions while we're at it? In 
that case the first function which could update the function pointers seems 
to be the DEVICE_INIT call for the device. We'll spread out the code for 
filling in the struct, but for initialization it should be safe enough. A bit 
confusing for the driver designer perhaps...

At the moment I'm inclined to keep the parameters of the current conversion 
functions and copy them as soon as DeviceIntRec is allocated. That would mean 
keeping the current initialization for the drivers and not adding more 
initialization in strange places. Sounds reaonable?

Cheers
  Magnus



More information about the xorg mailing list