> Sounds to me like you two are saying the same thing essentially...
I think so.
> 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...
The kernel shouldn;t be responsible for what is drawn on the screen but
it should be..
> 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.
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 : Tue Feb 15 2000 - 21:00:24 EST