On Tue, 07 May 2002 04:03:03 -0400
Roland Dowdeswell <elric@imrryr.org> wrote:

> 
> 	1.  changing vt's while highlighting text, or
> 	2.  text output while highlighting text?
> 
> It seems to me that right now it may not be strictly possible to
> do that, as the moused can't really ask for the information it
> might need to take care of these situations.
> 
> One could take a `locking' approach, but that is probably a little
> heavy and would probably expose one to `borking the console' if
> moused exits without cleaning up properly.
> 
> Also consider that moused holds in its memory information that is
> required to properly reconstruct the state of the screen, i.e. what
> the characters that it changed were before the change.  The kernel
> has none of this information.

That is part of why I previously suggested to have ws support optional
mouse pointer capability...

Other reasons were that I beleive that wscons and wsmouse are portable
among ports using the ws system, and that it's actually the kernel that
controls what happens there... It would prevent annoyances like gpm on
linux, where data read from the mouse device has to be copied into a fifo
in order to have another application also access mouse data as well,
/dev/wsmouse would still be sent the mouse data no matter what happens
with the internal state of the console mouse pointer... Without allowing
userspace to interfere into the process, it would also help on general
security IMHO.

Of course this implies a totally other design, I was replied that
supposedly OpenBSD did something like this which many people did not
like... Any particular reason why people don't like an approach which
could happen to be more logical? Are there other reasons why userspace
should be allowed to interfere with general console I/O?

Matt