On configuration and things like xdevice.

[Aivils Stoss]

On Ceturtdiena, 27. Aprīlis 2006 06:35, Zephaniah E. Hull wrote:
> 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].

I have belief in my bones when Xinput developers create that piece of code
they do it from the heart. But time changes and changes manner of thinking.
This discusion about ioctl is more programmer's psychology or psychology
of mass communication society related. I will agree ioctl was born in the
dark ages of computing equipment.

I didn't say ioctl like wired protocol of X server is my last words.
I will bother X developers with my short code. New feature of X is
fine distinction. It is not so easy request it and after requesting got
that feature in.
Also philosophical is question about new features exigency at all. 

> 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.

For dirvers will be good automatic public key generation. Public key
must be easy predictable without full listing of accessable entities.
Today a have no ideas how to define roles for each client. Standard
OS roles will not go throgh wired protocol. As result is security holes
created by optimistic developers wich will allow more than is necessary.

>
> 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.
>
> Type is probably on the order of ((8|16|32|64 bit) (signed|unsigned)
> int|float|double|string).
>
> 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.

During development having a "red button" will be prety nice. Obviously
maintainer must be brute to delete these "red buttons" in release.

>
> 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.

Is need for matrix of config values in the each driver caused by
not-be-call feature?

>
> 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.

Having user-specific ~/xorg.conf will be nice or tweaking is meaningless.
Seems ~/xorg.conf must be stored automatic after commit of changes.
Keeping of existing format must be avisable.
I recall i read Nvidia complaint about lack of registry under Linux long
time ago.

How about things like server layout - nowadays and future things will
be allways outside of driver/device scope space. Allowed these outsiders
in your steering protocol? 

>
> 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.

Well, well. ioctl is a devil's finger ;o)

Aivils Stoss