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.