Bug 224378

Summary:	moused goes crazy when there are USB mouses and no PS2 mouses
Product:	Base System	Reporter:	Slawomir Wojciech Wojtczak <vermaden>
Component:	usb	Assignee:	freebsd-usb (Nobody) <usb>
Status:	Closed Not A Bug
Severity:	Affects Many People	CC:	hselasky, sergey
Priority:	---
Version:	11.1-RELEASE
Hardware:	Any
OS:	Any

Description Slawomir Wojciech Wojtczak 2017-12-16 12:48:20 UTC

I have several 'mouse' type devices attached to FreeBSD box, a 'normal' mouse, an air mouse, but I do not have any PS2 mouse. All of them work properly on FreeBSD. There is only problem with /etc/rc.d/moused script that always relies on PS2 mouse for PID and status.

Here are USB mouses:

# grep '^ums' /var/run/dmesg.boot 
ums0 on uhub4
ums0: <AliTV Remote V1 Airmouse, class 0/0, rev 1.10/10.01, addr 4> on usbus0
ums0: 5 buttons and [XYZ] coordinates ID=0
ums1 on uhub4
ums1: <AliTV Remote V1 Airmouse, class 0/0, rev 1.10/10.01, addr 4> on usbus0
ums2 on uhub4
ums2: <AliTV Remote V1 Airmouse, class 0/0, rev 1.10/10.01, addr 4> on usbus0
ums3 on uhub5
ums3: <Logitech Logitech BT Mini-Receiver, class 0/0, rev 2.00/49.00, addr 8> on usbus0
ums3: 14 buttons and [XYZT] coordinates ID=2
ums3: 8 buttons and [XYZT] coordinates ID=5



Here are PS2 mouses (none):

#  grep '^pms' /var/run/dmesg.boot



There are moused processes that were started at boot:

# ps ax | grep moused
  362  -  Is      0:00.37 /usr/sbin/moused -p /dev/ums0 -t auto -I /var/run/moused.ums0.pid
  379  -  Is      0:00.00 /usr/sbin/moused -p /dev/ums1 -t auto -I /var/run/moused.ums1.pid
  396  -  Is      0:00.00 /usr/sbin/moused -p /dev/ums2 -t auto -I /var/run/moused.ums2.pid
  413  -  Is      0:00.00 /usr/sbin/moused -p /dev/ums3 -t auto -I /var/run/moused.ums3.pid



But the moused script 'thinks' its not running:

# /etc/rc.d/moused status
moused is not running.


I can even 'start' it but it does not changes anything:

# /etc/rc.d/moused start
Starting default mousedmoused: unable to open /dev/psm0: No such file or directory



But I can not stop it:

# /etc/rc.d/moused stop  
moused not running? (check /var/run/moused.pid).

# ps ax|grep moused      
  362  -  Is      0:00.37 /usr/sbin/moused -p /dev/ums0 -t auto -I /var/run/moused.ums0.pid
  379  -  Is      0:00.00 /usr/sbin/moused -p /dev/ums1 -t auto -I /var/run/moused.ums1.pid
  396  -  Is      0:00.00 /usr/sbin/moused -p /dev/ums2 -t auto -I /var/run/moused.ums2.pid
  413  -  Is      0:00.00 /usr/sbin/moused -p /dev/ums3 -t auto -I /var/run/moused.ums3.pid



Regards,
vermaden

Comment 1 Hans Petter Selasky freebsd_committer

2017-12-16 16:58:23 UTC

FYI:

USB moused instances are started by devd's rules.

grep -r ums /etc/

--HPS

Comment 2 Slawomir Wojciech Wojtczak 2017-12-16 17:08:04 UTC

(In reply to Hans Petter Selasky from comment #1)

So I do not need moused_enable=YES in /etc/rc.conf?

They will be started anyway by devd(8)?

Comment 3 Hans Petter Selasky freebsd_committer

2017-12-16 17:09:34 UTC

Hi,

I'm not entirely sure. It is up the the moused rc.d script what will happen. It should be easy enough to test.

--HPS

Comment 4 Slawomir Wojciech Wojtczak 2017-12-17 16:28:58 UTC

I just rebooted the box and without 'moused_enable=YES' (moused not enabled) and all USB 'mouse like devices' has moused process started.

Is that a bug or a feature? That moused is not enabled and FreeBSD starts it for these devices?

Rdgards,
vermaden

Comment 5 Sergey Akhmatov 2017-12-17 20:01:42 UTC

(In reply to vermaden from comment #4)
Look into /etc/defaults/rc.conf:
>moused_nondefault_enable="YES" # Treat non-default mice as enabled unless
>                               # specifically overriden in rc.conf(5).

As HPS wrote above, non-default moused instances are invoked by devd as, e.g.:
/etc/rc.d/moused start ums0

So, if you want to start, stop or know status of particular mouse device, you should run rc.d/moused with device name as second argument. e.g:
/etc/rc.d/moused status ums0

If you want to disable particular mouse device, you should put to rc.conf:
moused_ums0_enable="no"

See also: man 5 rc.conf

It seems too me that what you described is expected behavior and not a bug.

Comment 6 Slawomir Wojciech Wojtczak 2017-12-17 21:10:42 UTC

Ok, thank you for explanation.

You can close this one now as 'not bug'.