The MoGo Mouse BT does not work with xf86-input-evdev 1.2.0 nor the latest git snapshot. When autoconfigured by xorg (no InputDevice sections in the xorg.conf file), the log shows: (II) LoadModule: "evdev" (II) Loading /usr/lib/xorg/modules/input//evdev_drv.so (II) Module evdev: vendor="X.Org Foundation" compiled for 1.4.0, module version = 1.2.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 2.0 (**) MoGo Mouse BT: always reports core events (II) MoGo Mouse BT: Found 8 absolute axes. (II) MoGo Mouse BT: Configuring as pointer. (II) MoGo Mouse BT: Found 3 relative axes. (II) MoGo Mouse BT: Configuring as pointer. (EE) MoGo Mouse BT: Unable to parse 'RelAxis 0' as a map specifier. (EE) MoGo Mouse BT: Unable to parse 'RelAxis 1' as a map specifier. (**) MoGo Mouse BT: Configuring 8 absolute axes. (II) MoGo Mouse BT: Checking button DIGI_STYLUS (74) (II) MoGo Mouse BT: Checking bit 330 (EE) MoGo Mouse BT: AbsoluteTouch: 'DIGI_Touch' does not exist. (II) MoGo Mouse BT: Found 2 mouse buttons (II) MoGo Mouse BT: Configured 8 mouse buttons. (II) XINPUT: Adding extended input device "MoGo Mouse BT" (type: MOUSE) (**) MoGo Mouse BT: 8 valuators. (**) MoGo Mouse BT: Configuring in Absolute mode. (**) MoGo Mouse BT: Registering 8 buttons. (II) MoGo Mouse BT: Init (II) MoGo Mouse BT: On The mouse got two physical buttons that work as button 1 and 3 but there the relative axis do not work at all, i.e. the mouse cursor does not move. The xinput utility list these axes: "MoGo Mouse BT" id=4 [XExtensionPointer] Num_buttons is 8 Num_axes is 8 Mode is Absolute Motion_buffer is 256 Axis 0 : Min_value is -1 Max_value is -1 Resolution is 1 Axis 1 : Min_value is -1 Max_value is -1 Resolution is 1 Axis 2 : Min_value is -1 Max_value is -1 Resolution is 1 Axis 3 : Min_value is -1 Max_value is -1 Resolution is 1 Axis 4 : Min_value is -1 Max_value is -1 Resolution is 1 Axis 5 : Min_value is -1 Max_value is -1 Resolution is 1 Axis 6 : Min_value is -1 Max_value is -1 Resolution is 1 Axis 7 : Min_value is -1 Max_value is -1 Resolution is 1 xinput test "MoGo Mouse BT" reports only button presses, no mouse movement: $ xinput test "MoGo Mouse BT" button press 3 button release 3 button press 1 button release 1 What can I do to make the mouse work?
(In reply to comment #0) > The MoGo Mouse BT does not work with xf86-input-evdev 1.2.0 nor the latest git > snapshot. > (II) MoGo Mouse BT: Found 8 absolute axes. > (II) MoGo Mouse BT: Configuring as pointer. > (II) MoGo Mouse BT: Found 3 relative axes. > (II) MoGo Mouse BT: Configuring as pointer. > (EE) MoGo Mouse BT: Unable to parse 'RelAxis 0' as a map specifier. > (EE) MoGo Mouse BT: Unable to parse 'RelAxis 1' as a map specifier. > (**) MoGo Mouse BT: Configuring 8 absolute axes. > (II) MoGo Mouse BT: Checking button DIGI_STYLUS (74) > (II) MoGo Mouse BT: Checking bit 330 > (EE) MoGo Mouse BT: AbsoluteTouch: 'DIGI_Touch' does not exist. > (II) MoGo Mouse BT: Found 2 mouse buttons > (II) MoGo Mouse BT: Configured 8 mouse buttons. > (II) XINPUT: Adding extended input device "MoGo Mouse BT" (type: MOUSE) > (**) MoGo Mouse BT: 8 valuators. > (**) MoGo Mouse BT: Configuring in Absolute mode. I think the last line is what causes your problems. If the mouse is configured in absolute mode (due to misleading information on the event node), the incoming packages may be parsed as absolute. Since a normal mouse usually reports in a range -1 .. 1, you'd be moving around 1 pixel on the top left corner of the screen. in the xf86-input-evdev code, try to find where it initialises the absolute axis and comment this code out. If this works, we've found the issue. If not, please put a breakpoint on EvdevReadInput and trace where the motion events disappear.
No reply since, and rel/abs axis handling has been improved a lot in git. Calling it fixed. Please try evdev 1.99.4 or later.
(In reply to comment #2) > No reply since, and rel/abs axis handling has been improved a lot in git. > Calling it fixed. Please try evdev 1.99.4 or later. > Tried git version from Date: Thu Jun 12 11:23:10 2008 +0930 (version 1.99.4) and the mouse function almost perfectly. It is now possible to move the pointer. Here is a snippet from the Xorg.0.log: (**) MoGo Mouse: always reports core events (**) MoGo Mouse: Device: "/dev/input/mogo_event" (II) MoGo Mouse: Found x and y relative axes (II) MoGo Mouse: Found mouse buttons (**) Option "Emulate3Buttons" "true" (II) MoGo Mouse: Forcing middle mouse button emulation. (II) MoGo Mouse: Configuring as mouse Not sure if it is significant, but xinput -list still reports Min and Max values both as -1, that is however true for all mice: "MoGo Mouse" id=3 [XExtensionPointer] Num_buttons is 32 Num_axes is 2 Mode is Relative Motion_buffer is 256 Axis 0 : Min_value is -1 Max_value is -1 Resolution is 1 Axis 1 : Min_value is -1 Max_value is -1 Resolution is 1 The remaining issue is middle button emulation. It is extremely difficult to do a middle click with the MoGo mouse, I can occasionally manage to press the middle button but it is rare. Maybe it is due to the default timeout 50 (which units). I tried to increase it in src/emuMB.c up to 50000 and got a much higher success rate although it seemed that button 1 must be pressed before number 3 to be recognized as button 2. Thanks, Jan
On Fri, Jun 13, 2008 at 12:11:17AM -0700, bugzilla-daemon@freedesktop.org wrote: > Not sure if it is significant, but xinput -list still reports Min and Max > values both as -1, that is however true for all mice: yes, this just means it's a relative device. > The remaining issue is middle button emulation. It is extremely difficult to do > a middle click with the MoGo mouse, I can occasionally manage to press the > middle button but it is rare. Maybe it is due to the default timeout 50 (which > units). hehe. good question. milliseconds I think. I'll update the man page. > I tried to increase it in src/emuMB.c up to 50000 and got a much higher > success rate although it seemed that button 1 must be pressed before number 3 > to be recognized as button 2. oh. that shouldn't happen. I'll look into it.
On Fri, Jun 13, 2008 at 12:11:17AM -0700, bugzilla-daemon@freedesktop.org wrote: > The remaining issue is middle button emulation. It is extremely difficult to do > a middle click with the MoGo mouse, I can occasionally manage to press the > middle button but it is rare. Maybe it is due to the default timeout 50 (which > units). I tried to increase it in src/emuMB.c up to 50000 and got a much higher > success rate although it seemed that button 1 must be pressed before number 3 > to be recognized as button 2. Ok, had a look at it. Timeout is in milliseconds (man page even says so). And it definitly works with both button 1, then button 3 and the other way round with button 3, then button 1.
(In reply to comment #5) > On Fri, Jun 13, 2008 at 12:11:17AM -0700, bugzilla-daemon@freedesktop.org > wrote: > > The remaining issue is middle button emulation. It is extremely difficult to do > > a middle click with the MoGo mouse, I can occasionally manage to press the > > middle button but it is rare. Maybe it is due to the default timeout 50 (which > > units). I tried to increase it in src/emuMB.c up to 50000 and got a much higher > > success rate although it seemed that button 1 must be pressed before number 3 > > to be recognized as button 2. > > Ok, had a look at it. Timeout is in milliseconds (man page even says so). And > it definitly works with both button 1, then button 3 and the other way round > with button 3, then button 1. > Thank you. However, the middle button emulation is practically unusable for the Mogo mouse without setting some ridiculously long timeouts (like 50000) which then result in inability to drag windows by left-click-and-hold on the title bar, for example. Could this be mouse-specific or is there some other configuration option to test? Jan
> --- Comment #6 from Jan Merka <jm@wo.cz> 2008-06-15 08:42:39 PST --- > Thank you. However, the middle button emulation is practically unusable for the > Mogo mouse without setting some ridiculously long timeouts (like 50000) which > then result in inability to drag windows by left-click-and-hold on the title > bar, for example. Could this be mouse-specific or is there some other > configuration option to test? sounds like a device-specific issue. the middle button emulation code is basically just copied from xf86-input-mouse with little changes only and it works fine here with a standard usb mouse.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.