Subject: New design for mouse support
To: None <email@example.com>
From: Julio Merino <firstname.lastname@example.org>
Date: 05/10/2002 17:01:22
Content-Type: text/plain; charset=us-ascii
As somebody said in this list, mouse support would be done in another
way. I've been looking at wscons' sources and found the following ioctl:
VT_GETACTIVE. This seems a good ioctl to query the kernel to know which
console is active (I have tried it and returns a single number). Then,
the mouse daemon would open that console directly, using /dev/ttyE?,=20
(where ? is the number returned by VT_GETACTIVE - 1) and call ioctl's on
them. Those would support VT_GETWSCHAR and VT_PUTWSCHAR to draw the mouse.
Having that file descriptor I guess we could also call TIOCSTI directly,
without having a WSDISPLAY_STIOF ioctl as I did before (which seems a
bit weird to me). Although, I see a problem here. Even if using independent
ttyE? devices, it would be difficult to write to only one, as the functions
I wrote work on "active" screen (the ones controlled by the underlying
device, pcdisplay). I haven't figured yet how wscons stores screens
contents... if anybody would enlightent me here...
This desing seems better to me, as getting/putting characters suit
better ttyE? devices than ttyEcfg. Then, ioctl's should be added to
compat_usl file... btw, what does usl mean?
Any objections until here?
The only problem I see is that the daemon will need to open each ttyE?
device, so mouse can work on all virtual terminals. This would be done
"on the fly", that is, if you switch to another terminal open the device
and don't close it until the program has finished (so it doesn't need to
open/close devices every time).
Well, what do you think?
Of course it runs NetBSD - http://www.netbsd.org
HispaBSD member - http://www.hispabsd.org
Julio Merino <email@example.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (NetBSD)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----