mouse problems....

[Polytropon]

On Mon, 11 Oct 2010 12:49:07 -0700, Gary Kline <kline at thought.org> wrote:
> 	I got a reply from grepping ums and a truckload from usbdev -s.
> 	Copied to my `posit' notes or whatever:
> 
> 
> 	ethic# dmesg | grep ums
> 	ums0: <rand Combo Free KVM, class 0/0, rev 1.10/0.00, addr 3> on uhub4
> 	ums0: 5 buttons and Z dir.
> 	ethic# 

The mouse is detected. Good.

A problem that now comes to my mind is that switching from / to
the "ethic" machine might confuse the USB subsystem, as a device
disappears and later appears. Although USB is capable of hot plug,
the USB subsystem might not be able to pick up the mouse correctly.

You could try:

	# moused -d -f -p /dev/ums0 -t auto

Then debugging messages should appear on the console, and a moving
mouse cursor should be visible.



> 	I was able to balanced anf get forward enough to see what my
> 	friend did.  The keyboard *is* a PS/2; it is plugged into a new
> 	adaptor that plugs into the USM slot.  The (`Logitech') mouse is
> 	already a USB and plugs nto the second USB slot/jack on the KVM.

So it's a "pure USB" solution for the mouse - should be no problem.



> 	As noted, things are happy on my linux desktop, but not on my
> 	FBSD boxen.  Any ideas how to rebuild things to the new USB
> 	protocol?

Which "new" protocol? USB 3.0 for the three buttons? :-)

No, honestly: I think the problem is somewhere in the interaction
of the KVM switch and the FreeBSD USB subsystem which has influence
on how moused handles the mouse.

Can you check "forcing the mouse on" as described above? If it is
present in dmesg (from boot time on, and NOT switched away and on
again), and also listed in the current state per usbdevs command,
it should be picked up.

As far as I understood in regards of X, there is

	a) X using the mouse provided through moused, or

	b) X detecting it "itself" by HAL and DBUS.

Do you use HAL and DBUS with X?



-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...