# Cannot get the USB mouse working on Laptop



## r2com (Mar 15, 2021)

I have some old laptop where I installed FreeBSD. Interesting fact is, during the first install of FreeBSD from the boot USB flash the USB mouse worked inside a setup screen just fine! As well as the laptop's touchpad.

However, once I did install the KDE5 (I don't think its KDE related) I just cannot make the USb mouse work! During a short period of time right before it jumps into KDE and you already can see mouse cursor it does not work either.

I do have hald and dbus enabled in rc.conf, I googled already each similar topic but still cannot make it work.

I saw in some similar topics that "kldload ums" helps, but for me that command says that it cannot find ums. and I do not know where to insert that setting since I do not see load.conf in /boot either!

any suggestions?


----------



## CuatroTorres (Mar 15, 2021)

Have you tried mounting procfs?


----------



## mark_j (Mar 15, 2021)

Please see section 5.7.2 of the handbook where it explains the need for /proc and dbus and how to enable them.

The handbook is your best friend, seriously.


----------



## Snurg (Mar 15, 2021)

I'd just try enabling moused in /etc/rc.conf first.
Officially it should not be necessary with USB mice.
But there are some notes that in some circumstances enabling moused helps when for some mysterious reasons USB mice don't appear/work on GUI. I had such cases and so I can confirm that these notes are correct.


```
moused_enable="YES"
dbus_enable="YES"
hald_enable="YES"
```

dbus is generally required with most GUI stuff.
hald is deprecated. But sometimes one encounters strange problems with particular hardware, and enabling hald sometimes helps.

I'd enable procfs only if absolutely necessary, i.e. if some Linux app won't work without it.
KDE does *not* need procfs!


----------



## Alexander88207 (Mar 15, 2021)

r2com said:


> I saw in some similar topics that "kldload ums" helps, but for me that command says that it cannot find ums.



`kldload /boot/kernel/ums.ko`


----------



## eternal_noob (Mar 15, 2021)

Set *kern.evdev.rcpt_mask=12* in /etc/sysctl.conf*.*
See "5.4.7.2. Mice and Pointing Devices" at https://docs.freebsd.org/en_US.ISO8859-1/books/handbook/x-config.html

No need to enable moused or hald.


----------



## Mjölnir (Mar 15, 2021)

Snurg said:


> I'd just try enabling moused in /etc/rc.conf first.
> Officially it should not be necessary with USB mice.
> But there are some notes that in some circumstances enabling moused helps when for some mysterious reasons USB mice don't appear/work on GUI. I had such cases and so I can confirm that these notes are correct.


Then please file in a bug report & upload the failing USB hardware's device IDs.  If that happens, it's because ums(4) is not autoloaded/activated, thus the following rule can not match (due to no ums* device in devfs(5)): moused(8) is started _automagically_ on device attachment via devd.conf(5)

```
notify 100 {
        match "system" "DEVFS";
        match "subsystem" "CDEV";
        match "type" "CREATE";
        match "cdev" "ums[0-9]+";

        action "service moused quietstart $cdev";
};
```
of course, unless disabled in rc.conf(5) (`sysrc moused_ums0_enable=NO`).


Snurg said:


> hald is deprecated. But sometimes one encounters strange problems with particular hardware, and enabling hald sometimes helps.


webcamd(8) still needs it.


Alexander88207 said:


> `kldload /boot/kernel/ums.ko`


You can ommit the path & .ko ending for kernel modules loaded from the standard paths.  It's only needed if different versions of a module exist in several paths (e.g. the drm-kms(7) stuff), or to load from a non-default path.


eternal_noob said:


> Set *kern.evdev.rcpt_mask=12* in /etc/sysctl.conf*.*
> See "5.4.7.2. Mice and Pointing Devices" at https://docs.freebsd.org/en_US.ISO8859-1/books/handbook/x-config.html


`pkg info -D xorg-server`.  TWIMC can search for my _Standard disclaimer_, which covers some topics that are not so clear from the Handbook & thus frequently overseen by newbies.


----------



## mickey (Mar 15, 2021)

Mjölnir said:


> webcamd(8) still needs it.


sysutils/hal is gone for good - finally - and no longer required by webcamd, at least in ports/latest.


----------



## Deleted member 30996 (Mar 15, 2021)

I alway use a USB mouse with my laptops and am ATVM using the Grandest of them all, the Microsoft Trackball Optical USB mouse:

```
jitte@obake:/ $ dmesg
ugen1.2: <Microsoft Microsoft Trackball Optical> at usbus1
ums0 on uhub2
ums0: <Microsoft Microsoft Trackball Optical, class 0/0, rev 1.10/1.21, addr 2> on usbus1
ums0: 5 buttons and [XYZ] coordinates ID=0
```

This is the only editing I've done and nothing more to get it working:

/etc/rc.conf

```
moused_enable="YES"
mouse_type="auto"
hald_enable="YES"
dbus_enable="YES"
```


----------



## r2com (Mar 15, 2021)

OK thanks for responses, here is what additionally I have done:

1) add this `mouse_type="auto"` in addition to enabled hald, dbus and I do have `moused_enable="YES"` as well - just in case
2)  Added this `kern.evdev.rcpt_mask=12` in /etc/sysctl.conf
3) I tried doing `kldload /boot/kernel/ums.ko` but couldn't since "boot" is not even a directory for me! - btw, any comments on that? why I do not see anything inside /boot and why it does not look like folder?
I found this thread:
I would like to have my USB Mouse work on the console.
where they said it worked and they just added `ums_load="YES"` to /boot/loader.conf but problem is, as described above, I do not see anything inside /boot

4)I tried it with logitech M185 mouse, I also tried another - Logitech MX Master 3. Same thing with both. don't work.
And again, I want to highlight the fact that during the install process from usb flash I could move and operate mouse normally!

I tried `dmesg | grep ums` and it returned nothing.

reading hadnbook section related to it in the meantime..


----------



## Mjölnir (Mar 15, 2021)

Please post the output of `uname -aU` & `sysctl hw.machine`.


----------



## Snurg (Mar 15, 2021)

just a note: 
Don't use `dmesg` in such use cases, because the boot stuff might have already left the circular buffer.
Rather do this:


```
% grep ums /var/run/dmesg.boot 
ums0 on uhub0
ums0: <Microsoft Microsoft 3-Button Mouse with IntelliEye(TM), class 0/0, rev 1.10/3.00, addr 2> on usbus6
ums0: 3 buttons and [XYZ] coordinates ID=0
%
```

And, what does `ll -d /boot` show you?
On my computer I see this:


```
% ll -d /boot
drwxr-xr-x  11 root  wheel  67 Feb  6 17:08 /boot/
%
```


----------



## r2com (Mar 15, 2021)

1) I also added this to proper place:
proc           /proc       procfs  rw  0   0
did not help either

2) here is output from "uname -aU &  sysctl hw.machine"
[1] 1494
FreeBSD xen 12.2-RELEASE FreeBSD 12.2-RELEASE r366954 GENERIC  amd64 1202000
hw.machine: amd64
[1]  + Done                          uname -aU

3)
# ll -d /boot
lrwxr-xr-x  1 root  wheel  13 Oct 22 23:44 /boot@ -> bootpool/boot

4) grep ums /var/run/dmesg.boot   did not return anything


----------



## Mjölnir (Mar 15, 2021)

Why did you name your machine "xen"?  Does that mean your BeaSD is not running on bare metal?


r2com said:


> FreeBSD xen 12.2-RELEASE FreeBSD 12.2-RELEASE r366954 GENERIC  amd64 1202000


^^^^^^^^​Would you mind to `freebsd-update fetch install` to 12.2-RELEASE-p4?


r2com said:


> # ll -d /boot
> lrwxr-xr-x  1 root  wheel  13 Oct 22 23:44 /boot@ -> bootpool/boot


What the f* is that?  You're running inside a VM?


----------



## Snurg (Mar 15, 2021)

To me /boot looks like a link.
I wonder whether the link is usable already in the bootstrap stage and guess that could possibly a reason for your pains.
Same for /var[/run]. Seems not yet be there when the kernel wants to write into it.

Why there are links instead of directories, you probably know better than me.


----------



## r2com (Mar 16, 2021)

Mjölnir said:


> Why did you name your machine "xen"?  Does that mean your BeaSD is not running on bare metal?
> 
> ^^^^^^^^​Would you mind to `freebsd-update fetch install` to 12.2-RELEASE-p4?
> 
> What the f* is that?  You're running inside a VM?


I named it like that, don't know why.

and no I am not on VM, I am installing it on the old asus laptop. during install I just selected ZFS, but that's pretty much it, I have no idea why the printout looks like that, what would that mean?
and no, I have no idea why there are links instead of dirs! If I knew, I'd not ask it here obviously. Again, all I did is download the flash image, burn it to usb flash and install on a laptop. then I went ahead and installed KDE.

but after some digging I found some stuff which *might* be relevant, first of all, there was some thread where guy had similar problem and then he said he wiped FreeBSD and re-installed it but with UFS file system and then his mouse worked OK after X install. There were of course comments saying that mouse has nothing to do with file system and thread ended basically with OP just being happy that problem solve (somehow).

Then I found this post:
freebsd-update Cannot identify running kernel
and a guy was showing that error which actually pops up on me too - cannot identify running kernel! and then i remembered that i actually did ZFS install in MBR, there was reason why... if I install in GPT I cannot boot from HDD on this old laptop with shitty bios, so the only way of being able to boot is having install in MBR (for example before that I was messing around with NomadBSD installer which installs itself in GPT and i could not get that one boot from HDD as well).

so, my install: ZFS in MBR.

then I see some mentionings that it might be a reason of why I cannot see /boot directory because somehow it is like "link", which might be related to above problem... and that, in its turn might be reason of why ums kernel driver cant get loaded from there...

so given this info.. does it mean I must dig into the partition and /boot directory related problem first and sorting that one out before trying to make USB mouse work?


----------



## r2com (Mar 16, 2021)

ok guess what?
inside this thread:
Missing kernel?

there were suggestion of developer - tobik


> zpool import -f bootpool
> Add to /boot/loader.conf (see Thread 42980)
> zpool_cache_load="YES"
> zpool_cache_type="/boot/zfs/zpool.cache"
> ...



now after reboot when I get to a logon screen I can move my USB mouse! 

p.s. now though, I have a new problem, for some reason after logon the KDE completely shits itself, freezes badly and this happens every reboot, during a freeze after the logon no windows perform normally, all completely halted...ironically, except the cursor which I can now move with my USB mouse 
but anyway, that is a different problem and required different thread (proly KDE related), but this specific issue of mouse not working is SOLVED.


----------



## CuatroTorres (Mar 16, 2021)

Are you starting under Wayland?


----------



## Mjölnir (Mar 16, 2021)

Which install image have you been unsing? FreeBSD or NomadBSD?
Where did you download it from?
Have you verified the official checksum of the image, after download & again of the USB thumb drive?
Check your BIOS; at least for the installation, set failsafe, conservative, compatible values.


----------



## r2com (Mar 16, 2021)

I was not starting Wayland, but just plasma.

I used this one:
https://download.freebsd.org/ftp/re.../12.2/FreeBSD-12.2-RELEASE-amd64-memstick.img

I did not verify checksum after download

BIOS is checked updated, again its oldass laptop, no failsafe conservative stuff there.


----------



## Alexander88207 (Mar 16, 2021)

r2com said:


> I was not starting Wayland, but just plasma.
> 
> I used this one:
> https://download.freebsd.org/ftp/re.../12.2/FreeBSD-12.2-RELEASE-amd64-memstick.img
> ...



Do you really have checked what session is selected on the login screen (x11/sddm) ?

The login screen (x11/sddm) selects "Plasma (Wayland" as default but it don't works.


----------



## Mjölnir (Mar 16, 2021)

Well, you should really verify the checksums of the downloaded image file & the install media itself (the USB thumb drive) against the officially published checksums.


----------

