Input device design (3)

Russell Shaw 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
> satisfy?

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

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 mailing list