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/softmoused.pid 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 for RELENG_4, RELENG_5, RELENG_6 and CURRENT. 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. Fix: The patch for src/usr.sbin/moused.c is here: http://www.kuzbass.ru/pub/freebsd/patches/softmoused.tgz 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 How-To-Repeat: N/A
Sorry, URL is ftp://www.kuzbass.ru/pub/freebsd/patches/softmoused.tgz (ftp, not http).
Responsible Changed From-To: freebsd-bugs->philip I'll take it.
I haven't looked at the input system in ages.
My PR. Source code of "softmoused" patch was lost in time. It had not get any attention, anyway. Close this.