Yet another "mouse doesn't work" problem

B

bunkerbsd

Setup: Raspberry Pi (not 2) model B, FreeBSD 11.0, xorg pkg installed. PS/2 keyboard and mouse connected through TrendNet PS/2-to-USB adapter. Mouse works correctly in console mode.

X will not autoconfigure; it can't seem to find video. I created an xorg.conf to tell it to use the scfb(4) driver, and that worked, except for the mouse.

The cursor starts off in the screen center, but as soon as you touch the mouse, the cursor jumps to the upper left corner and stays there forever, regardless of mouse movement. Mouse button clicks work as expected to get twm to bring up the application windows (all stacked on top of each other in the upper left). It's apparent that X can hear the mouse; it's just not paying attention to mouse movements.

I've played at adding mouse configuration to my minimal xorg.conf. I changed protocol auto to protocol PS/2, and the mouse didn't work at all. I changed device /dev/sysmouse to /dev/ums0 and the mouse didn't work at all. I'm out of ideas there.

I've tried a different PS/2 mouse without effect. I tried vtwm instead of twm, but the mouse behavior is unchanged.

(Just in case it's relevant: occasionally the keyboard is unresponsive in console mode after system startup. Unplugging and replacing the USB adapter fixes the problem. The mouse doesn't have this problem.)

Any help appreciated. Thanks.
 
Do you use the console mouse? Have you tried with a normal USB-mouse instead of the converted one ?

What if you disable the mouse daemon, moused_nondefault_enable="NO", take out all mouse stuff and the Auto*Devices from config and let Xorg just do what it sees fit?

Juha
 
> Do you use the console mouse?

Yes; either the PS/2 mouse or a USB mouse works just fine in console mode.

> Have you tried with a normal USB-mouse ...?

Yes, after removing the mouse stuff from xorg.conf. No effect on the problem.

> disable the mouse daemon
> take out all mouse stuff and the Auto*Devices from config and let Xorg just do what it sees fit?

Done and done. No effect on the problem. (I did this with a USB mouse.)

> Remove the AllowEmptyInput from your xorg.conf.

Well, it was set to off, but I removed it. No effect on the problem.

Thanks for the replies.
 
Maybe exploring your xinput devices using xinput list and xinput list <id> and comparing the values to a those on a system with a working mouse could give hints what is amiss.
 
AllowEmptyInput was cargo-culted so much that the X developers disabled it. It is ignored now.
 
Same problem with a normal USB mouse ? You mean when that converter gizmo is not involved?

I guess this is not helping, but went to the text console and moved the mouse (bog std 5$ mouse) veery little
Code: 
 $ od -c /dev/ums0
  207 001  \0 002  \0
  207 003 377 003  \0
  207 001  \0 001  \0
  207  \0  \0 001  \0
  207  \0 377 001  \0
  207 001  \0 002  \0
  207 001 \0 001  \0
  207  \0  \0 001  \0
  207 001  \0 001  \0
  207  \0  \0 001  \0
  207  \0 377 001  \0
  207 377  \0  \0 \0
  207 377 377 377  \0
  207 377 377  \0  \0
  207  \0 376 001 376
  207  \0 377  \0  \0
  207  \0 377 001  \0
  207  \0 377  \0  \0
  207  \0 377  \0  \0
  207  \0 377 001  \0
  207  \0 377  \0 377
  207  \0 377  \0  \0
  207  \0 377 001  \0
  207  \0 377  \0  \0
small positive and negative x- and y-movements. I have Xorg using the ums0 directly. Output edited to align the packets.

Juha
 
> Same problem with a normal USB mouse ? You mean when that converter gizmo is not involved?

Yes. I even switched to a USB keyboard so the converter gizmo isn't plugged in at all.

What I did this morning was to remove the window manager startup from .xinitrc, leaving just an xterm window. It conveniently started up in the upper-left corner, where X thinks the mouse is stuck, and the xterm window got focus. So I was able to fire up xev and see MotionNotify events. This yielded a clue -- the mouse movement in the MotionNotify event is *always* "(-2, -2)".

This is with an xorg.conf that doesn't mention the mouse at all.
 
> Maybe exploring your xinput devices using xinput list

Thanks; I didn't know about xinput. The output is interesting:

Code: 
% xinput list
â¡ Virtual core pointer  id=2  [master pointer  (3)]
â  â³ Virtual core XTEST pointer  id=4  [slave  pointer  (2)]
â  â³ sysmouse  id=7  [slave  pointer  (2)]
â  â³ Microsoft USB Wireless Mouse  id=8  [slave  pointer  (2)]
⣠Virtual core keyboard  id=3  [master keyboard (2)]
  â³ Virtual core XTEST keyboard  id=5  [slave  keyboard (3)]
  â³ kbdmux  id=6  [slave  keyboard (3)]
% xinput list 8
Microsoft USB Wireless Mouse  id=8  [slave  pointer  (2)]
  Reporting 3 classes:
  Class originated from: 8. Type: XIButtonClass
  Buttons supported: 5
  Button labels: "Button Left" "Button Middle" "Button Right" "Button Wheel Up" "Button Wheel Down"
  Button state:
  Class originated from: 8. Type: XIValuatorClass
  Detail for Valuator 0:
  Label: Rel X
  Range: -1.000000 - -1.000000
  Resolution: 1 units/m
  Mode: relative
  Class originated from: 8. Type: XIValuatorClass
  Detail for Valuator 1:
  Label: Rel Y
  Range: -1.000000 - -1.000000
  Resolution: 1 units/m
  Mode: relative

Note the range is given as -1 to -1 for X and Y. I don't have a working system to compare for the next few days.
 
Juha Nurmela said:
Those number pairs should be window and root relative coordinates, not movements. (I might have an outdated xev, though)

Up- or downgrade of x11-drivers/xf86-input-mouse ?
Click to expand...

pkg install says that x11-drivers/xf86-input-mouse is the latest version. Here's a typical MotionNotify event:

Code: 
MotionNotify event, serial 28, synthetic NO, window 0x600001,
  root 0x1aa, subw 0x0, time 2142835, (-2,-2), root:(0,0),
  state 0x0, is_hint 0, same_screen YES

They are all identical except for the timestamp.

Should I attempt to switch to a previous version of the xf86-input-mouse driver?
 
My xinput list was identical, except the identifiers. The mouse was like mercury, and I have ConstantDeceleration 2 in the config, but that's not related.

Ok, the -2,-2 is relative to the xev inside border, and 0,0 is the root corner. Xorg apparently sees motion, as it gives the Notifies, but something imprisons tne pointer. A misconfigured Viewport might do it. Not likely.

Not qualified to recommend any versions,
Juha
 
Will it go back to the corner if you force it out?
Code: 
#if 0
  cc -Wall -I/usr/local/include -L/usr/local/lib prisoner.c -lX11
  exit
#endif
#include <X11/X.h>
#include <X11/Xlib.h>

int
main(int argc, char **argv)
{
  Display *dpy = XOpenDisplay(NULL);
  Window root = RootWindow(dpy, DefaultScreen(dpy));

  XWarpPointer(dpy, root, None, 0, 0, 0, 0, 100, 100);
  XFlush(dpy);
}
 
Juha:

Thanks for all of your help so far. I tried the ServerFlags section without affecting the problem. I cannot link the program you provided because there is some sort of register argument use conflict (ld says: "libX11.so uses VFP register arguments, a.out does not"). So there is some sort of compilation or linking magic I don't know about; I'll have to figure that out.

I'll be out of touch for a few days, so if you have further suggestions, please send them and I will respond when I can.

Thanks again.
 
I don't think there's anything to be learned by that prog. Pointer would jump, and then most likely go back as soon as the mouse moves.

Juha

It would make sense, if there was a problem with floating point. Everything being integer-mostly, you would encounter the problem here and there, this time here.
 
> It would make sense, if there was a problem with floating point.

That's an interesting comment, since the Raspberry Pi is an ARM machine, and FreeBSD/arm is stuck on soft floating-point ...

But I thought I'd seen that other folks are successfully using Xorg on a Raspberry Pi. Maybe I'm wrong.
 
You must log in or register to reply here.
Back
Top