Input device design (3)
rjshaw at netspace.net.au
Mon Aug 29 11:24:05 PDT 2005
Russell Shaw wrote:
> Olivier Galibert wrote:
>> On Tue, Aug 30, 2005 at 02:45:07AM +1000, Russell Shaw wrote:
>>> The X server could monitor a special device such as /dev/sysconfig or
>>> a known ip address or socket so that if the user was to unplug/plug
>>> mice, keyboards, or any other hardware, the kernel or user-space
>>> programs or a daemon could write notification messages to it.
>> Sounds weird. You'd like to have in the X server all the
>> system-dependant code to be able to read the state of the input
>> devices, but not the code to be notified of their existence? Strange.
>> It's unclear to me what your problem is, exactly. Is it
>> getting/handling hotplug events, or is it the routing decisions (as is
>> this mouse goes to this server only, or this keyboard uses this
>> keymap) ? These are two different and somewhat orthogonal problems.
> If the X server was listening to a well known unix socket, the
> messages written to that point by anything in the system would
> need to be in a special format the X server understands.
> That makes the X server independant of platform specifics. There
> would need to be messages for screen size and scan rates etc, which
> are pretty generic parameters common to most hardware. Does that
I fear i might have come full circle. Another option is this:
The user can start an X client on their local machine that is
notified by the system when a hardware change happens. This
client can then send "hardware changed" events to the local
X server. The X server adapts to whatever the change is, then
optionally sends the same or new events to all other clients
running locally or remotely.
This cuts out the work of adding a specific system monitoring
function to the X server. OTOH, this addition is probably trivial
to add anyway.
Either being notified with events from a local hardware monitoring
client, or monitoring a well-known file/socket for X events is equivalent.
It boils down to the X server seeing something in its
If the X server was implemented with a small microcontroller with
limited memory, just monitoring a file descriptor for hardware-change
messages is probably easier, because a local X client hardware
monitor isn't needed. The format of these hardware notification
messages could also be in the form of X events, even tho the
program generating them is not an X client. This saves space
by not needing X libs.
More information about the xorg