bin/95698: Software control of sysmouse

Eugene Grosbein eugen at
Thu Apr 13 15:20:24 UTC 2006

>Number:         95698
>Category:       bin
>Synopsis:       Software control of sysmouse
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Thu Apr 13 15:20:22 GMT 2006
>Originator:     Eugene Grosbein
>Release:        FreeBSD 6.1-PRERELEASE i386
Svyaz-Service JSC
System: FreeBSD 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #5: Fri Mar 3 22:26:24 KRAT 2006 root at i386
	Applies for RELENG_4, RELENG_5, RELENG_6 and HEAD.

	moused(8) uses kernel drivers to virtualize several
	physical devices to translate their manipulations to the kernel
	using generic interface and the kernel supplies processed data
	to the userland using sysmouse(4) interface.

	It's a pitty, moused(8) cannot be controlled with software.
	It would be nice to control kernel's notion of mouse evolutions
	and affect console or X that way. Such interface to moused(8)
	would make it possible to create userlevel drivers for nonstandard
	peripherial devices and make them be like another 'mouse'.
	Think of infrared dongle and userlevel program that uses it
	to read data from infrared remote control and translate this data
	to mouse movements and button events.

	The following patch introduces this possibility.
	It creates new mouse type as argument for -t option: software.
	With the patch you may run moused this way:

	moused -t software -p /path/to/object ...

	When an argument of new option -p exists, moused opens it and
	uses to obtain 'softmouse' events. If it does not, moused
	creates a FIFO at this place. Only owning group is permitted to write
	to this FIFO. The name (or the number) of this group may be
	supplied with new option -g.

	When -g is not supplied, moused uses 'mop' (mouse operator)
	group, if it exists. If there is no such group, it uses 'operator'.
	If 'operation' is missing too, owner of parent directory will
	be owning group - it's a default.

	It is possible to run software controlled copy of moused
	and your old good moused for physical mouse simultaneously.
	You should use '-I' option for the second copy of moused
	to prevent it from destroying PID-file of first copy:

	So, the recommended command line looks like this:

	moused -t software -p /var/run/mfifo -I /var/run/

	Protocol used to control software mouse is unidirectional:
	moused waits for 8-bytes sequences:

byte 0:             0xbf (synchro-byte)
byte 1:             flags1 (buttons 1-8)
byte 2:             flags2 (buttons 9-16)
byte 3:             flags3 (buttons 17-24)
byte 4:             flags4 (buttons 25-32)
byte 5:             X-axis movement
byte 6:             Y-axis movement
byte 7:             Z-axis movement

	Byte 0 must be equal to value 0xbf, it defines start of the sequence.

	Bytes 1-4 are for button states.
	The lowest bit of byte 1 corresponds to the button 1,
	the highest bit of byte 4 corresponds to the button 32.
	A bit must be 1 for pressed button and 0 for released.
	Left mouse button is button 1, middle is number 2, right is 3.
	Bytes 5-7 inform of mouse movements, they range from -128 to 127.

	The following URL contains patches of moused.c

	It also contains a little example smtest.c - the program
	that randomly moves mouse pointer and Makefile to compile smtest.

	Run it: ./smtest [-b] -p /var/run/mfifo
	Use the same -p option that was used to run moused -t sofware.
	With '-b' option smtest will sometimes press, hold and release
	first three buttons of mouse while keep moving it.


	The patch for src/usr.sbin/moused.c is here:

	It is written to be easily understood.
	Because of this, it violates some style and code guidelines.
	That may be fixed if the whole idea is accepted,
	think of it as of 'proof of concept' code.
	However, it is fully functional.

Eugene Grosbein

More information about the freebsd-bugs mailing list