On configuration and things like xdevice.

Wed Apr 26 20:35:36 PDT 2006

In the past week or so while I've had a fever off and on, I've given
some thought to the whole matter and done some talking with Daniel
Stone.

While I understand the reasons why some believe that some sort of ioctl
like interface might be a good idea, I disagree.  Honestly, I believe
that going with such an interface would be actively harmful in a number
of ways[0].

So I came up with an alternate proposal, and I can't find anything that
we wish to promote which we think would be done better with an ioctl
type interface.

There are still some areas that have not yet been specified, the most
glaring of which is the question of how do you identify which
driver/device you're talking to, but there are a few ways to deal with
this.

This interface should integrate with the current configuration
handling, however from what I recall of the code behind it this may not
be easy, it should still be done.

For every configuration value we currently have, at minimum, a name, a
type, and sometimes even a default value.

To extend this we need type, name, value, flags, an optional
description, and an optional callback.

We might want to reduce that somewhat.

Name and value are obvious.

Flags that come to mind at the moment are RO, RW, Button, and not
immediate.

RO: Read only by clients.
RW: Read write by clients.
Button: Not really a configuration setting, though the value may matter
changing this triggers an action such as a reset of the device instead
of changing a setting.
Not immediate: Needs a better name, but indicates that changing this has
no immediate effect, something else has to trigger this change.

I would _very_ strongly suggest that people give a lot of thought before
using either button or not immediate flags.

The description is obvious, just describes what it is, though some
thought should be given to how to handle i8tn.

Callback should be equally obvious, it is a function pointer that the
driver can specify to be told when the value is changed by the user.

Note that the callback may not be called if the value is not changed and
the button flag is not set.

Anything in the config section for the device in xorg.conf should be
available through this interface, and pretty much likewise the other way
around. (Though Button triggers might not make sense in a config file.)

We would want a call to get a list of configuration settings for a given
device, and since this is not limited to input devices probably one to
get a list of devices in the first place.

We are also likely to put a list of commonly used settings for types of
drivers, with names, types, and values specified to make things
consistent and easier for people to write nice GUIs that let people
tweak things.

We are still undecided on the best way to give notification events to
clients that settings have been changed, either by userspace or by the
driver itself, but that's pretty much a given.

This allows us to be sure that we handle byte-swapping properly in all
cases, it's fully extendable, it has none of the evil mess of ioctls.

It's still a work in progress, but I firmly believe that this allows
everything favorable that ioctls allows, but quite a bit more as well.

Comments would be appreciated.

Zephaniah E. Hull.

0: ioctls might be used in lots of unix systems, but to my knowledge
everyone who actually has to deal with support hates them utterly.
The issues range from it being literally impossible for X itself to make
sure that byte-swapping is done properly when needed, to having no
defined way to indicate what version of the struct you're using, to
having no standard way to query what controls are available and what
they do.

This is not an improvement, this is a disaster that we would be dealing
with for decades to come, and I just can't support putting something
like that in the tree.

-- 
	  1024D/E65A7801 Zephaniah E. Hull <warp at aehallh.com>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

}>No.  I just point out to troublemakers that I have an English degree,
}>which means that I am allowed to make changes to the English language.
}>(What _else_ could it possibly be for?)
}Wow; in that case, my physics degree is *WAY* more useful than I
}had thought.
This just proves how useless a computer science degree is:  there is hardly
any useful science involved at all.  I want my computer black magic degree!
	-- Victoria Swann, Jonathan Dursi, and D. Joseph Creighton on ASR
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20060426/788cb295/attachment.pgp>