> Khimenko Victor wrote:
> > This is all great but IMNSHO in fact just VERY few applications should be
> > aware about multihead at all. X server, GPM server, may be few others (like
> > GDB). All other must NOT be aware about multihead thing at all. If multihead
> > support requires rewriting of each and every program it's BAD thing.
On Fri, 11 Feb 2000, James A Simmons wrote:
> No way. To require that would be insane. It's true that only a few apps
> will take advantage of this. Under normal use you want to see each head
> behave as independent console. The people in each office shouldn't realize
> that other people in other offices are using the same machine. Everything
> should behave as if the machine was their own. So no you will not have to
> rewrite every normal program just to use it on a multihead machine. This
> defeats the above purpose. This is the normal default behavior. The only
> time a program needs to be aware of multihead is when you want to take
> advatange of it.
Sounds to me like you two are saying the same thing essentially... If the
X server (or svgalib or GGI library) is made multihead-aware, that means
all your X (or svgalib or GGI) apps can be happily spread across all the
monitors in your room if you like without changing a line of the
applications' code.
Right now I'm running XFree86 3.9 in Xinerama mode over two monitors as a
single unified virtual screen - Xterm and Gimp doen't know that, nor do
they need to. X does, so it handles the multihead for them. If the console
system changes a bit to add better support for multihead, just update X to
grok the new system.
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...
Of course any app that needs or wants specific control over how to use
multihead should be able to get it... Say, an image or video viewer which
displays files on the second monitor while keeping controls and thumbnail
lists on the first. Or a 3d game which uses three monitors to show you
side views to your left and right as well as straight ahead (the original
version of Doom could do this by using three networked hosts).
But the general-purpose usage of multihead is going to be either:
A) Separately controllable heads, with apps on each head not needing to
know or care about the other heads
or
B) Multiple monitors combined into a virtual large screen - can be done by
an appropriately knowledgable intermediary layer without specific apps
running under them needing to know or care about the multihead
situation
I certainly don't think that combining consoles together should be a job
for the kernel... But it might be nice to be able to assign which console
pieces (screens, keyboards, maybe mice) a virtual console uses so that
complementary VCs (leftmost screen & PS/2 keyb/mouse vs rightmost screen
& USB keyb/mouse) can coexist happily but switching to my dual-head X VC
(both monitors, combine input from both PS/2 and USB) is sure to make BOTH
text consoles go away properly WITHOUT interfering with my potential third
console with yet-another-USB keyboard on the TV-out strung across the
room. Or am I being incoherent at... 6 am? (Ack! time to go to sleep...
too much linux-kernel...) Well it makes perfect sense to me right now...
:)
-- brion vibber (brion@pobox.com)
-
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 : Tue Feb 15 2000 - 21:00:22 EST