Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!newsserver.jvnc.net!gmd.de!mururoa!veit
From: veit@mururoa.gmd.de (Holger Veit)
Subject: Re: Q about future console driver
Message-ID: <1993Jul14.151359.16771@gmd.de>
Sender: veit@mururoa (Holger Veit)
Nntp-Posting-Host: mururoa
Organization: GMD - German National Research Center for Computer Science
References: <2213cfINNiam@harpo.uccs.edu>
Date: Wed, 14 Jul 1993 15:13:59 GMT
Lines: 70
In article <2213cfINNiam@harpo.uccs.edu>, jmward@elbert.uccs.edu (Joel M. Ward) writes:
|> I know that there is a group working to get the best of all
|> possible worlds in a console driver for 386/netbsd, but i just have one
|> question/requet:
|>
|> Is there a mouse driver? I think there should be. Just becasue
|> someone doesn't have the facilites to run X (like, say *me*) does mean
|> that they shouldn't be able to use thier mouse if they want.
|>
|> Imagine how handy it would be to have a mouse in screen! (yeah,
|> i know someone would have to hack it up in a big way, but you KNOW it's
|> not gonna happen w/out mouse funcs in the driver.
The point is not if it is handy (or if Linux has something like this,
which could be another argument thrown in). The point is whether it
is a good solution to do it in the kernel. I don't care if it is a big hack
to implement it. Anyway, there is too much hacking around, so we might
think over to do this right.
I think this should be done (and can be done) by an external application
rather than putting everything in the kernel. An application like
'screen' comes to mind. The reasons for that are the following:
- Mouse driver and console driver are two different drivers; you may have
systems with a console, but no mouse. The console driver must be able to
access the internal structures of the mouse driver to get the position.
- Also the mouse driver must inform the console driver that there has been
a movement. This effectively binds both drivers together. But there is not
only one mouse driver, but different ones. So you have to write a common
mouse interface, to avoid case handling in the console driver. We currently
have even more mouse drivers than console drivers, and the latter is already
a mess.
- It is unclear what a mouse movement should produce. It is possible to
emulate cursor movement by making the console driver insert
cursor ESC codes into the keyboard queue. This looks nice for editors,
but gives unexpected results for a shell, for instance. As an example,
"tcsh" uses cursor horizontal for editing the line (nice), but cursor
vertical not for moving on the screen, but instead for history traversing.
The neat effect in an xterm that you can mark a screen area with the mouse
and paste it in with a mouse click would need buffering in the kernel
(to make this persist when switching VTYs) and is state and application
dependent: e.g. for tcsh you must first disable emission of cursor ESCs
to make the mouse free movable, capture the text, then enable it again, or
lose the cursor movement in a line later. In an editor you may not want
this. Also one might want to program the mouse buttons to perform a
function, e.g. right-button: goto next VTY. In an editor you want to have
right-button to abort an action, so unless you have built special applications
that interact with the server/kernel (like X applications), how would you
make these specials known to the system. You end up having well-behaved,
bad-programmed, and "old" applications with respect to mouse usage, which
is as bad as not having mouse support at all.
Back to the "screen"-like application idea. You might look out for a recently
established standard named ALPHA-Windows, which emulates some of the X11
facilities on (slightly more intelligent, in terms of color/font loading)
video terminals in text mode. To get the standard and write a "screen"-like
server for this would be a good idea and a project for several programmers
interested in contributing something to *BSD and becoming well-known (hint!).
|>
|> --
|> ++Joel;
--
Dr. Holger Veit | INTERNET: Holger.Veit@gmd.de
| | / GMD-SET German National Research | Phone: (+49) 2241 14 2448
|__| / Center for Computer Science | Fax: (+49) 2241 14 2342
| | / P.O. Box 13 16 | Had a nightmare yesterday:
| |/ Schloss Birlinghoven | My system started up with
53731 St. Augustin, Germany | ... Booting vmunix.el ...