Re: [Linuxconsole-dev] EvStack - 2.3.x?

[<kim...@at...>]

> 2.  Multiple input  devices (mice,  keyboards, etc.):  this needs  tight
> cooperation  with the  USB  folks to  match what  they  do with  non-USB
> drivers (to the extend applicable to the device in question). Only major
> point here is a clean-up of  the various mouse drivers (excluding serial
> mice): there should be only one  mouse protocol be spoken by /dev/mouse.
> Instead of  the different minor  devices we should  have mouse0...mouseN
> with probing  order defined at  compile time  and a kernel  command line
> override.
  The USB code uses a trimmed down version of Vojtech Pavlik's event 
interface for HID devices. That includes keyboards, mice, tablets, um, ups's 
I think, and pretty much anything that has a button on it.  The rest of his
complete input patch handles most mice, and joystickts(oh yeah, USB ones
too).  In the USB code the input interface is allready tagged as an option.
You need to enable keyboard compatibility and mouse emulation. If you don't
enable those options, then the only way to get input from those devices is
through his event interface device.
  I'm currently attempting to slap together an XFree4 driver for Vojtech's
interface in my spare time.  I'm hoping that with it you'll be able to have
X use a different keyboard than the kernel. Or, have two different X's use
different keyboards, for multiseat purposes.  
  As a matter of terminology, I think multiseat is a much better term for a
system where multiple people can sit down and have independant sessions. 
Were as multihead could also be just somebody with a 3840x1024 desktop. 
Both have their uses, and are /really/ neat, but we do need to tell the
ideas apart.
  Back to the existing code. From what I can tell of the internal kernel
interface, all handlers can get a shot at all input, if they feel like it.
Which is consistant with me being able to type and read from the keyboard
evdev at the same time.  So, if the console interface were able to handle
this style of input events the whole mess could be handled from either
userland or in the kernel, perhaps with some sort of fallover.
  userland: "cat /dev/evdev0 > /dev/consoledev0" effectivly attaches evdev0
to console0. Ugly, but functional.
  kernel: input_register_handler(&console_handler); - the same event parser
would be used, so we could get both interfaces for the price of one.
  As for that fallover, what I meant by that is, maybe, any device(s) not
explicitly claimed by anything else(any console) would just fall through to
a default. That way no configuration would need to be done in the
default/simplest case.  ei: you let the smoke out of your AT/PS2 keyboard
port. No problem, just plug in a USB keyboard and everything is happy.
  Then, of course, there is the biggest reason for considering Vojtech's
interface: It's allready in the kernel, via the USB code.
  
  -- Nick Lopez
     kim...@at...