XChangeDeviceControl/XGetDeviceControl ?

[Aivils Stoss]

On Trešdiena, 19. Aprīlis 2006 16:45, Daniel Stone wrote:
> On Wed, Apr 19, 2006 at 05:43:07PM +0400, Andrew Zabolotny wrote:
> > Daniel, see what happens when there's no easy way for programmers
> > to get what they want? :) I wonder how much time will pass until
> > we'll see x11 drivers sending local emails with config data...
>
> 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.

It is done. If You will download and unpack this one:
http://www.ltn.lv/~aivils/files/xdevice-0.01.tar.bz2
then You can see generic protocol implementation.
xentity protocol use public ASCII key to access X server internals.
When client got access to entity, then comming up key-value simple
usage, where key is integer and value is character buffer.
Client side knows only 4 functions:
XEntityOpen();
XEntityClose();
XEntitySetControl();
XEntityGetControl();

Server side internals, drivers and so on must know only 2 functions:
XentRegister();
XentUnregister();

If server entity register himself , then entity allow call it own control
function
int (*func) (unsigned long data, const int cmd,
		char * buffer, const int buffer_length);
where
data - pointer to entity static data,
cmd - interger command or "key" to set or get
buffer - pointer to buffer which commes from/to wire
buffer_length - length of wired buffer

After entity registering client side can "open" that entity with
XEntityOpen(Display *dpy, char *name)
where
dpy - display of current X connection,
name - entity public key or name.
Entity names are not predefined right now. I suggest human readable
"core.drivers.input.aiptek.00"
"core.layout.screen.01"

If entity is "opened" client side have entity handle and can call
XEntitySetControl(dpy, handle, COMMAND-1, send_to_server_buffer, len);
XEntityGetControl(dpy, handle, COMMAND-2, receive_from_server_buffer, len2);
functions to control entity.

If controling is done, then client side calls
XEntityClose(dpy, handle)
to close entity. Also server automatic clean up opened handles if client
dies.

Neither server side nor client side take care about wired protcol. Both
client and server implementations must care about buffer and buffer length
harmony.

Of course xentity is not input or driver specific. It allows control all
X internals, which can register entity. I should agree that is very
ioctl like solution. I don't have 30+ years programming seniority, so i
could not proper determine is obvious and simple solution beter that
existing hundreds of Xproto structures and variables. I cannot see these
underwater riffs which hides into simple solutions. I developed this
one to control some parameters of X for experiments. I was make experiments
a bit longer and clean up xentity code. Single xentity code is not
usable at all and i add xdevice and xmodule client side implementations.

I know xinput hotplug have "case" around 18 months in the bugs.freedesktop.org 
by Reporter:   	 Kristian Hogsberg.

Aivils Stoss

> Xi has been a wasteland since its introduction, mainly since the current
> DIX and DDX do their best to pointedly ignore it.  Not any more.
>
> Which means, on that note, that if I suck as a maintainer, I expect you
> to tell me that I'm being far too idealistic, and to just shut up 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.
>
> Cheers,
> Daniel