*BSD News Article 18414


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!sol.ctr.columbia.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Q about future console driver
Message-ID: <1993Jul14.194356.10137@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University, Ogden, UT
References: <2213cfINNiam@harpo.uccs.edu> <1993Jul14.151359.16771@gmd.de>
Date: Wed, 14 Jul 93 19:43:56 GMT
Lines: 154

In article <1993Jul14.151359.16771@gmd.de> veit@mururoa.gmd.de (Holger Veit) writes:
>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.

When I first saw this request, I thought it was a request for a common
mouse interface (ie: a "/dev/mouse") for all mouse drivers, so the user
view of the mouse would be consistent, even if the hardware configuration
was not.  I was about to respond that this had been discussed in the
context of the keyboard driver, until I read the last sentence.  What
is being asked for is the equivalent of the utilities shipped with the
Logitech mouse for DOS (I realize the request isn't that complicated yet;
I respond that this is simply the intial request).

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

I agree with Holger (we seem to agree on a lot when it comes to user
interaction with computer systems).  There is absolutely no reason that
this could not be implemented in a user-space application, even if we
need to support the idea of "cut and paste".  The majority of the cost
of implementation likes squarely in the realm of curses.  I see the
following engineering constraints:

1)	The curses implementation needs to have the following explicit
	functions added to it:

	mouseon()	- attach mouse input to the input stream considered
			  to come from the console.  This function will
			  return -1 if the mouse can not be attached.
	mouseoff()	- detach " ... ".

2)	The mouse input stream is multiplexed into the curses input
	stream, and a pseudo-cursor is moved around as a result of
	mouse movement.  Global variables private to curses are
	updated as to the mouse position, and can be retrieved with
	another function,

	mouseloc( &row, &col)

	Potentially, the function

	mousewinloc( win, &row, &col)

	Should also be supported.  Optionally, the ability to turn the
	"cursor" on and off using a function like:

	mousecurs( mode)

	Could be handy.

3)	Mouse buttons result in virtual escape sequences being seen by
	curses.  These have the effect on input of being identified as
	virtual keystrokes, in the same way function keys are identified.

4)	Interpretation of these virtual keystrokes is application specific.
	For instance, the UnixWare "sysadm" application accepts mouse
	input for field and virtual function key label line selection
	based on the location of the "mouse down" event.

5)	The xterm application can be extended to offer these same services
	to curses applications running in an xterm.  The proper means of
	implementing this is probably through a VMOUSEMODE, with the
	appropriate escape sequences to turn the mode on and of encoded as
	xterm termcap entries, whose output is tied to the mouseon() and
	mouseoff() functions.


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

But by the same token, if a mouse exists, it must be virtualized across
all consoles, if only for the case of running X on multiple virtual consoles,
in the same way that the keyboard requires virtualization.

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

As a suggestion, I don't believe a sophisticated interface is required,
even for cut-and-paste.  Yes, a common driver is required so that it can
be hooked at the virtualization layer; this does not require that the
"text mouse" interface bee in the kernel.  In particular, the idea of "cut
and paste" between virtual terminals should probably *not* be supported,
if only because one or more of the virtual terminals in question could
potentially be running an X server, and this would not be ICCC/ICMP
compatable, if only between multiple virtual X consoles.

The implementation of a "cut and paste" in the context of a virtual text
console is not difficult, however, given a couple of axioms.

1)	Cut-and-paste applies only to text consoles.

2)	An application is run to enable this, and the application takes
	precedence over other used of the mouse on that virtual text
	screen.

3)	The actual "cut and paste" mechanism is implemented using TIOCSTI
	for the paste, and one of three methods for the cut:

	a)	Cut using ioctl()'s to the terminal emulation layer of
		the driver.

	b)	Cut using escape sequences implemented in the terminal
		emulation layer of the driver.

	c)	Cut using direct reads of the virtual screen display
		memory (the mouse cursor is implemented using direct
		writes to the same memory) using a <TBD> interface.

	Either of the first two implementations is valid, but the mouse
	cursor display and actual screen-contents-reporting requires much
	more of the driver in the first instance, and is less reliable
	during updates of the display in the second, unless display
	manipulation strings are require to be atomic in applications so
	that multiple applications accessing the same display do not
	interrupt each other's escape sequences (the same is required if
	we are to support VT102/VT220 style transparent printing).

	This is perhaps the only necessary intrusion into kernel space in
	the display driver, and it is arguably necessary (omitting the
	mouse cursor, which can be implemented with screen memory writes).

	The third method requires no kernel intrusion other than to provide
	a relatively simple interface that should probably be there for use
	by other applications.


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.