On Fri, 01 Jun 2007, Matthew Garrett wrote:

Or we could just leave the mapping up to individual users, which avoids 
the problem.

Other than the fact that it is not a piece of candy to implement correctly.

quoted

Again, it is not only about X. What if X is not running (or running but
nobody is logged in)? There are number of events (SUSPEND, WLAN switch,
undock request, etc) that should be handled by daemons not depending
on X.

The existing implementations use X. I don't think any of the desktop 
distributions really care about the non-X case for this sort of thing.

Debian does, for one.  And I am pretty sure it is not the only one.

Also, let me state right now that IMO, this "I need X to be running and
logged in" for dock, eject, suspend, wlan on/off and other *system* level
activity to work is an extremely bad idea and broken on so many levels it is
not funny.

I have nothing against allowing such activities to be *modified* to suit the
logged in user, subject to approval by the system administrator.  But to
have them implemented in that level? Yuck.

But I don't see what this means for input device keyboard maps.  Any of the
proposed solutions to the problem so far will work equally well (or not well
:) ) for console and X users, even the "lots of KEY_UNKNOWN" one...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh