Input device design (2)

[Jim Gettys]

I claim once we make it possible, the various desktop projects will join
in to worry about the UI for X server configuration.

And sticks in the mud (or embedded systems where space can be precious
or there may be no human involved) can do command line tools, as they
always have.

Our primary job is to get X to be able to be configured from outside
agents, rather than it presuming it is in control, in a static fashion.
				- Jim

> 
> The way i'd add hardware awareness is either:
> 
> (1)
>    Have an X window that pops up in response to a special hotkey
>    combination that has a menu of all the X server configuration
>    options such as:
>      configure mouse, and accelerations etc,
>      configure keyboard, and numlock etc,
>      configure screen properties such as size, scan-rate, gamma, etc,
>      configure video card parameters,
>      configure sound card parameters,
>      paths for user font directories and font servers, and
>      anything else configureable in an X server.
> 
>    This is analogous to the Function keys used on a normal ascii terminal.
>    It also minimizes complications by needing extra X clients.
>    The pop-up window functionality is implemented entirely in the server.
> 
>    I'd also have a menu entry to save or load the X server state from disk
>    so that the user can completely restore a session the next time the user
>    logs in or if the X link is lost due to an unreliable line.
> 
> (2)
>    Instead of using a pop-up window, the user can run a program like xrdb
>    (but is a gui) that sets all the options as in (1), as properties on
>    the root window, which would cause X property-change events to be sent
>    to clients. I've been thinking of implementing this method.
> 
> (3)
>    The X server could monitor a special device such as /dev/sysconfig
>    so that if the user was to unplug/plug mice, keyboards, or any other
>    hardware, the kernel or user-space programs can write notification
>    messages to it. There could also be a message to save and restore
>    X server state.
> 
> When any of these server parameters/properties is changed, an X event
> can be sent to all the running clients so they can adapt.
> 
> As well as saving server state between sessions, the last used hardware
> configuration can be read at the next session. At the command line, the
> user could even start X using the hardware configuration they chose if
> they have a few.
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg