Re: [Multihead] was Re: [PATCH] devfs v99.11 available

From: James A Simmons (jsimmons@acsu.buffalo.edu)
Date: Thu Feb 17 2000 - 10:38:54 EST


> 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/



This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:18 EST