Messages in this thread | | | Date | Thu, 17 Feb 2000 10:38:54 -0500 (EST) | From | James A Simmons <> | Subject | Re: [Multihead] was Re: [PATCH] devfs v99.11 available |
| |
> 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.)
Pretty cool :) I will have to try this one.
> * * * > > 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.)
I have been thinking. The last email I sent about the idea of building consoles. Well I was working on the code in my head. I realized to have such a system would be insane. I realize how complex it would be. Your right. A video console should be just a keyboard and a display. If a app wants to be multihead then it should use the raw hardware devices. For input devices its /dev/event and for displays it can be /dev/fb.
> 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.
Agree. It should be a app that determines if data is shared like the keyboard input goes to two different displays etc.
> 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..
Yes the a mouse should be bound to a set of VCs. This is a little trickier since a mouse is not required for a video terminal. Another piece of hardware is the sound card. In a office with a multihead machine you might have 3 sound cards in the machine. Now each person using the machine will have headphones leading to his office. So we don't want a person blasting his music into the other two offices. So each sound card should also be bounded to a head.
> 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....
Yep. Vojtech has already been working on this. In fact Vojtech has been working on the input part and I have been working on the fbdev part.
Codito, ergo sum - "I code, therefore I am" James Simmons (o_ fbdev/gfx developer (o_ (o_ //\ http://www.linux-fbdev.org (/)_ (/)_ V_/_ http://linuxgfx.sourceforge.net
- 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/
| |