daniel at fooishbar.org
Mon Apr 17 00:32:21 PDT 2006
On Mon, Apr 17, 2006 at 04:01:39AM +0400, Andrew Zabolotny wrote:
> On Sun, 16 Apr 2006 21:06:08 +0300
> Daniel Stone <daniel at freedesktop.org> wrote:
> > Uhm, XChangeDeviceControl has n+1 parameters. One is the control
> > (e.g. DEVICE_RESOLUTION, DEVICE_TOUCHSCREEN, DEVICE_CORE, ...), and
> > the other n is the arbitrary data structure associated with the
> > control. You can do what you like with it.
> Hmm, what's DEVICE_TOUCHSCREEN and DEVICE_CORE? By looking
> into extensions/XI.h I can see only DEVICE_RESOLUTION there. And using
> anything but DEVICE_RESOLUTION will end in getting BadValue, as you can
> clearly see from xc/programs/Xserver/Xi/getdctl.c function
> ProcXGetDeviceControl(). Besides, the protocol is tied to the specific
> 'control' values, because the structure is being serialized into the
> wires, and it contains pointers.
I added _TOUCHSCREEN and _CORE; they haven't been merged yet.
> Too bad there's no way to use that in a generic way; that would make
> prototyping and developing stuff a lot easier.
There's nothing for 'pass this structure up to the driver unmolested',
though it could be trivially added; like I said, it's not something I
want to encourage.
> > If the Wacom guys need to use their own controls, they should get in
> > touch with us, and we can get their specific needs integrated into a
> > later version of Xorg. Having an abundance of modules like SISCTRL
> > is not useful in the long term. Having widely configurable input, is.
> I don't like the idea to have specialized structures for every input
> device in the world; the structures will be different even amongst
> different tablet drivers, not speaking of more exotic devices. What I
> have now is about 50 parameters which are quite different e.g. I
> wouldn't like to have them all changed in one call.
You can either set the remaining values to -1 or NULL, or take the XKB
approach of using a mask.
> And one question still left unanswered: how do I get something back
> from the driver? Notably what I want is to have a tool that could save
> driver state to a file in order to load it later at will; the current
> implementation is that the driver itself saves and loads its state to
> /etc/wacom.dat which looks crappy.
Er, apps can get data back from the driver using XGetDeviceControl,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 191 bytes
Desc: Digital signature
More information about the xorg