[Brion Vibber <brion@gizmo.usc.edu>]
> Huge, multi-screen text consoles might be nice too (right now I'm
> stuck on one monitor with VesaFB for text, should've bought Matrox),
> but could again be handled in userspace with something along the
> lines of 'screen' as long as the kernel can handle each console
> individually, without any specific multihead support built into vi or
> emacs - though someone will add it to Emacs I'm sure...
Yep, been done.
M-x make-frame-on-display
M-x make-frame-on-tty
The latter, I believe, is XEmacs only. In any case, I use it all the
time (I usually have an XEmacs process sitting on /dev/vc/{1,20,19,18}.
This message, for example, is being typed on /dev/vc/19.)
* * *
My vision of multihead is that you associate a given keyboard with a
given output device. Something like `losetup' -- you run a utility
that grabs a spare VC and ties it to the FB and the USB keyboard or
whatever.
If an app opens a VC that hasn't been bound to a particular video card
or input device, it gets the default keyboard and video hardware....
Most console apps, you can just point at a VC. (Or, in the case of
XEmacs, any number of VC's. GDB can possibly work this way too.)
Multiple-keyboard-aware programs? They will need low-level keyboard
access anyway so just point them at the relevant keyboard devices.
Ditto multi-mouse programs, ditto multi-video-card programs.
I'm not sure what to do with mice. gpm already knows how to demux
mouse events across multiple VC's -- maybe gpm just needs to become
multi-mouse aware (or is it already?) and gpm configuration needs to
grow the necessary flexibility to be able to tell it where to route
events from different devices. Or perhaps mice should be bound to a
set of VC's, like keyboards currently are. Shades of GGI EvStacks..
And then there's the Linux joystick API.............. Which suddenly
makes me think -- perhaps Vojtech already has all this stuff formalized
and coded up as part of his 2.5-era input device overhaul. Haven't
checked....
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:17 EST