XChangeDeviceControl/XGetDeviceControl ?

[Andrew Zabolotny]

On Wed, 19 Apr 2006 16:45:01 +0300
Daniel Stone <daniel at fooishbar.org> wrote:

> I agree, but I'm also trying to provide you a generic framework to do
> what you want.  Single-use config tools (SISCTRL, ATI's Catalyst
> control panel, nVidia's Detonator control panel, this) are not
> interesting.  Generic frameworks that I can access by pressing System
> -> Preferences -> Pointing Devices (or whatever) -- now that's
> interesting! That's what distributions care about.  That's the way to
> get very well-developed, well-refined, and well-maintained
> configuration tools in every desktop, and thus in every distribution.
Ok, I see now your point. But you also should agree that it should be
possible to write "nvidia/ati config tools" and such without abusing
other API, since this basically means some device will "support" that
API, but in some absolutely unexpected way (such drivers even could
crash if someone tries to use the API the "correct" way).

I think the "param=value" interface I proposed in the previous message
is generic enough to use for any "proprietary config tools" (even if you
really need to pass binary data, well, you can base64 it), and also this
interface will allow to have some generic command-line tool (like the
'xinput' tool written by someone) that can allow easy changing of any
parameter of any input driver; having a text-only interface it also
means it will be easily useable from scripting languages; and at the
same time this interface will allow for writing generic control tools.

<fantasy>

A more generic (but more complex) interface would require the driver to
be able to describe all those parameters: a human-readable
description, the type of the value (single/array, integer/float/
string, readonly/readwrite/writeonly). This way the hypotetic "control
panel" could show "known" parameters in a easy-to-use way, and have an
"extended setup" button which would bring a dialog where you can change
any of the existing parameters. But alas, the XGetDeviceControl has
just an int on input, which makes it hard to use in a generic way,
as the integers must be allocated in a centralized manner :-(

You could even set standards for a "bare minimum" that's required to be
implemented in drivers that want to be controlled in a generic manner.
There should be at least a device type query (keyboard, mouse, tablet,
touchscreen, whatever), a parameter list query (which should return a
list of supported params, a parameter type query, which should
return the size/type/access mode of the parameters, say "IRW" for
"integer, read/ write" A4SR for "array of 4 strings readonly" or
"A255FW" - "write-only array of 255 floats"). For example, the driver
I'm working on would return:

"ParamList" -> "ActiveArea,DebugLevel(hehe),PressCurve,RawFilter,Mode,
SpeedLevel,ClickForce,Accel,XYDefault,GIMP,MMT,TPCButton,ButtonActions"

"ParamDesc,ActiveArea" -> "The active area of the tablet, in tablet
units"
"ParamType,ActiveArea" -> "A4F"
"ParamDesc,ButtonActions" -> "The actions assigned to tablet buttons"
"ParamType,ButtonActions" -> "A%dS" (where %d is replaced by the
actual number of buttons on the device).
...

For making driver writer's life easier there could be some kind of
simple library that would do basic maintainance of these parameters.
The driver would just register an array of some structures at startup,
every structure somehow describing the supported parameters, and most
of the maintainance work would be done automatically by the library.

</fantasy>

> and add a DEVICE_LOCAL ioctl-style interface already.  But I'm hoping
> that we can all agree on a better, more generalised interface, for
> the things you want to do, as it's not just your driver that will
> benefit from this sort of thing.
Sure, I would be glad if this could be achieved. Basically this is the
reason why I keep flooding here, otherwise I would just quietly use
DEVICE_RESOLUTION :)

-- 
Greetings,
   Andrew