XChangeDeviceControl/XGetDeviceControl ?

[Andrew Zabolotny]

On Tue, 18 Apr 2006 10:37:00 +0300
Daniel Stone <daniel at fooishbar.org> wrote:

> > This one doesn't make sense to be put into any other structure?
> > So a separate DEVICE_DEBUGLEVEL? :-)
> I don't really think it makes sense to be user-configurable, at all.
> Why not just use the standard levels provided you, and launch the
> server with -verbose and -logverbose?
Sure that's an developers-only option, so what? I still would like to
have the ability to turn on/off certain types of debug output
on-the-fly, since it makes debugging easier - I could use a debug
version all the time with logging turned off, and when I encounter a
specific bug I can enable debugging and instantly see what's up.

> > XWACOM_PARAM_BUTTON1...XWACOM_PARAM_BUTTON32
> > These definitely belong to a different structure, like
> > DEVICE_BUTTONACTIONS, and again there's the problem that you can't
> > change a single button assignment at a time. Right now it's simple:
> > call XChangeDeviceControl with DEVICE_RESOLUTION,
> > resolutions [0] = XWACOM_PARAM_BUTTONX; resolutions [1] = action;
> > and you're done.
> What exactly do they do?  Is there no way you can fit this into the
> existing button map paradigm?
Not quite, because these 'button actions' can map tablet buttons not
only to buttons, but also to keys. The parameter is really a bit mask
that describes the type and code of the event to be emited when I press
some key on the tablet, it even allows generating hotkey combinations
like Ctrl+Alt+Backspace and such. I realize this is a bit of a hack,
but there's no other way now to use tablet buttons in X11; even gtk
built-in support for extended input device keys is broken.

The worse thing with having pre-defined structures is that it's utterly
inflexible: if I want to add a single parameter to the driver that
turns to be a X11 protocol change; this means I have to convince
somebody that this option deserves to be included; then recompile X11
and so on... this is a lot of absolutely unneeded bureaucracy.

I agree that some options could be made standardized, this will allow
to have generic programs that will work with several different drivers
in the same manner; but there are always options specific to a single
driver or even to a single hardware model, and I don't see why the need
to standardize all this.

-- 
Greetings,
   Andrew