evdev mice: "Fatal server error:bogus pointer event from ddx"

[Mikael Nilsson]

Binary package hint: xserver-xorg-input-evdev

The recent update to evdev (1.1.5-0ubuntu1) made it possible to start with the recommended evdev config for mice without an immediate crash (no set_bit error).

Now I get so far as seeing an "X" cursor, and then crash. Relevant part of log:

Fatal server error:
bogus pointer event from ddx

$ grep MX- Xorg.0.log
(**) MX-: Core Pointer
(II) MX-: Found 2 relative axes.
(II) MX-: Configuring as pointer.
(II) MX-: Found 3 mouse buttons
(**) MX-: Configuring 2 relative axes.
(II) MX-: Configured 3 mouse buttons
(**) MX-usb-0000:00:1d.7-7.1/input0: Core Pointer
(II) MX-usb-0000:00:1d.7-7.1/input0: Found 4 relative axes.
(II) MX-usb-0000:00:1d.7-7.1/input0: Configuring as pointer.
(**) MX-usb-0000:00:1d.7-7.1/input0: HWHEELRelativeAxisButtons: 6 7.
(**) MX-usb-0000:00:1d.7-7.1/input0: WHEELRelativeAxisButtons: 4 5.
(II) MX-usb-0000:00:1d.7-7.1/input0: Found 16 mouse buttons
(**) MX-usb-0000:00:1d.7-7.1/input0: Configuring 4 relative axes.
(II) MX-usb-0000:00:1d.7-7.1/input0: Configured 20 mouse buttons
(II) XINPUT: Adding extended input device "MX-usb-0000:00:1d.7-7.1/input0" (type: MOUSE)
(II) XINPUT: Adding extended input device "MX-" (type: MOUSE)
(**) MX-: 2 valuators.
(II) MX-: Init
(**) MX-usb-0000:00:1d.7-7.1/input0: 4 valuators.
(II) MX-usb-0000:00:1d.7-7.1/input0: Init
(II) MX-: On
(II) MX-usb-0000:00:1d.7-7.1/input0: On

So it seems to load. xorg.conf contains:

Section "InputDevice"
        Identifier "MX"
        Driver "evdev"
        Option "evBits" "+1-2"
        Option "keyBits" "~272-287"
        Option "relBits" "~0-2 ~6 ~8"
EndSection

and

        InputDevice "MX" "CorePointer"

in the ServerLayout section

Ideas?

[Fabio Massimo Di Nitto (fabbione)]

(In reply to comment #0)
> With bug #6734 out of the way, I've been investigating another problem, which
> was that I was seeing a "bogus pointer event from ddx" fatal message at server
> startup. I scratched my head over this for a while, but I'm pretty sure the
> problem occurs when you have a CorePointer defined from an evdev rule that
> matches more than one physical device.
>
> I can work around this as I know which mouse I consider to be my primary one,
> which I then set a vendor/product rule for, and then I define a second mouse
> device using SendCoreEvents to match my other devices.
>
> This is with evdev 1.1.2 compiled and running against Xorg 7.0 on ubuntu dapper.

Hi Philip,

is this the same effect as reported here?

https://launchpad.net/distros/ubuntu/+source/xserver-xorg-input-evdev/+bug/40153

i upload 1.1.2 a couple of days ago to dapper.

Thanks
Fabio

[Fabio Massimo Di Nitto (fabbione)]

(In reply to comment #0)
> With bug #6734 out of the way, I've been investigating another problem, which
> was that I was seeing a "bogus pointer event from ddx" fatal message at server
> startup. I scratched my head over this for a while, but I'm pretty sure the
> problem occurs when you have a CorePointer defined from an evdev rule that
> matches more than one physical device.
>
> I can work around this as I know which mouse I consider to be my primary one,
> which I then set a vendor/product rule for, and then I define a second mouse
> device using SendCoreEvents to match my other devices.
>
> This is with evdev 1.1.2 compiled and running against Xorg 7.0 on ubuntu dapper.

My apoligies, wrong link.

This is the one i am talking about:
https://launchpad.net/distros/ubuntu/+source/xserver-xorg-input-evdev/+bug/43100

[Xorgbugs-philipl (xorgbugs-philipl)]

No, the ubuntu bug is different - there it's failing to set up the mx1000. My
bug is when the evdev section that is the CorePointer matches multiple event
devices.

[Warp-spam+fdo (warp-spam+fdo)]

That's... Bizarre.

Could you attach your xorg.conf and your Xorg.0.log?

Thanks.

[Xorgbugs-philipl (xorgbugs-philipl)]

Created an attachment (id=5631)
Xorg log

[Xorgbugs-philipl (xorgbugs-philipl)]

Created an attachment (id=5632)
xorg.conf

The log is from the crash case. Please be assured that despite the backtrace,
this has nothing to do with the nvidia driver - I have a vmware virtual machine
where I can reproduce this case with an identical backtrace - except it has the
vmware driver in it.

The xorg.conf has a CorePointer rule that matches two mice (the external one
and the trackpoint). To work around it, I set the CorePointer device to only
match my logitech mouse and the ExtraMice device for the trackpoint (and I use
the synaptic driver for the trackpad).

From debug ouput I put in the driver, I see that an event is synthesized for
each button on each mouse at init time, and it appears that the first button
event from the second mouse caused the confusion in the server.

[Daniel Stone (daniels)]

Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.

[Mikael Nilsson (mini)]

Binary package hint: xserver-xorg-input-evdev

The recent update to evdev (1.1.5-0ubuntu1) made it possible to start with the recommended evdev config for mice without an immediate crash (no set_bit error).

Now I get so far as seeing an "X" cursor, and then crash. Relevant part of log:

Fatal server error:
bogus pointer event from ddx

$ grep MX- Xorg.0.log
(**) MX-: Core Pointer
(II) MX-: Found 2 relative axes.
(II) MX-: Configuring as pointer.
(II) MX-: Found 3 mouse buttons
(**) MX-: Configuring 2 relative axes.
(II) MX-: Configured 3 mouse buttons
(**) MX-usb-0000:00:1d.7-7.1/input0: Core Pointer
(II) MX-usb-0000:00:1d.7-7.1/input0: Found 4 relative axes.
(II) MX-usb-0000:00:1d.7-7.1/input0: Configuring as pointer.
(**) MX-usb-0000:00:1d.7-7.1/input0: HWHEELRelativeAxisButtons: 6 7.
(**) MX-usb-0000:00:1d.7-7.1/input0: WHEELRelativeAxisButtons: 4 5.
(II) MX-usb-0000:00:1d.7-7.1/input0: Found 16 mouse buttons
(**) MX-usb-0000:00:1d.7-7.1/input0: Configuring 4 relative axes.
(II) MX-usb-0000:00:1d.7-7.1/input0: Configured 20 mouse buttons
(II) XINPUT: Adding extended input device "MX-usb-0000:00:1d.7-7.1/input0" (type: MOUSE)
(II) XINPUT: Adding extended input device "MX-" (type: MOUSE)
(**) MX-: 2 valuators.
(II) MX-: Init
(**) MX-usb-0000:00:1d.7-7.1/input0: 4 valuators.
(II) MX-usb-0000:00:1d.7-7.1/input0: Init
(II) MX-: On
(II) MX-usb-0000:00:1d.7-7.1/input0: On

So it seems to load. xorg.conf contains:

Section "InputDevice"
        Identifier "MX"
        Driver "evdev"
        Option "evBits" "+1-2"
        Option "keyBits" "~272-287"
        Option "relBits" "~0-2 ~6 ~8"
EndSection

and

        InputDevice "MX" "CorePointer"

in the ServerLayout section

Ideas?

[Mikael Nilsson (mini)]

Oh, the log also contains a <default pointer>:

~$ grep "default pointer" Xorg.0.log
(**) |-->Input Device "<default pointer>"
(WW) <default pointer>: No Device specified, looking for one...
(II) <default pointer>: Setting Device option to "/dev/input/mice"
(--) <default pointer>: Device: "/dev/input/mice"
(==) <default pointer>: Protocol: "Auto"
(**) <default pointer>: always reports core events
(==) <default pointer>: Emulate3Buttons, Emulate3Timeout: 50
(**) <default pointer>: ZAxisMapping: buttons 4 and 5
(**) <default pointer>: Buttons: 9
(II) XINPUT: Adding extended input device "<default pointer>" (type: MOUSE)
(--) <default pointer>: PnP-detected protocol: "ExplorerPS/2"
(II) <default pointer>: ps2EnableDataReporting: succeeded

[Timo Aaltonen (tjaalton)]

configuration error, see http://www.chrisweldon.net/index.php?/archives/60-Xorg-7.1-and-evdev-problems-Solved.html

[Mikael Nilsson (mini)]

I'm sorry, can you be a bit more explicit about the configuration error? According to evdev(4), the following is the correct way to configure an evdev entry for *all mice*, which is what I want:

       And the following for all mice:

       Section "InputDevice"
         Identifier "mouse"
         Driver "evdev"
         Option "evBits" "+1-2"
         Option "keyBits" "~272-287"
         Option "relBits" "~0-2 ~6 ~8"
         Option "Pass" "3"
         ...
       EndSection

(I did forget the Pass option, but adding it makes *no* difference).

So, either the man page is in error, or there is a bug.

I do *not* want to statically configure every mouse I have, as I travel with my laptop and use different mice at different times. But I *do* want to use all buttons etc.

[Mikael Nilsson (mini)]

The rejection was in error, I believe.

[Timo Aaltonen (tjaalton)]

why don't you even try the solution from the url? It wouldn't be the first time when manpage is obsolete, and in that case it should be fixed. But since I've had success reports on this package and it didn't work for you before... that's why it got rejected.

[Mikael Nilsson (mini)]

tor 2007-03-29 klockan 10:17 +0000 skrev Timo Aaltonen:
> why don't you even try the solution from the url? It wouldn't be the
> first time when manpage is obsolete, and in that case it should be
> fixed. But since I've had success reports on this package and it
> didn't
> work for you before... that's why it got rejected.

I didn't try it because it doesn't solve my issue - I want *one*
configuration that works for all mice. A static config is useless for
me. I tried it, it works for that one mouse, but gives me issues when I
use other mice.

My method is the one recommended by the evdev documentation, and it
breaks. That's what this bug report is about. Viewing it as a
documentation bug might be ok, but is *not* a valid reason for
rejection.

/Mikael

[Luke Maurer (luke-maurer)]

FWIW, I'm having the same problem, but a different reason for not liking the static configuration solution: My keyboard's got a scroll wheel, so it's both keyboard and pointer. Yes, I *can* set this up statically, but it's far more sensible to avoid the keyboard/mouse dichotomy in the first place. There are other bugs involving inconsistencies between event types and input devices; I'd say it's better to quit pretending that keyboards and mice are always inherently different. (Besides, that's what's so nifty about Linux's evdev mechanism anyway - it abstracts the events from the originating devices.)

[James Michael Fultz (croooow)]

I was having the same problem and found using "SendCoreEvents" in the ServerLayout section.

The pertinent sections of my 'xorg.conf' are as follows:

Section "InputDevice"
        Identifier "mouse"
        Driver "evdev"
        Option "evBits" "+1-2"
        Option "keyBits" "~272-287"
        Option "relBits" "~0-2 ~6 ~8"
        Option "Pass" "3"
EndSection

Section "ServerLayout"
        Identifier "Default Layout"
        Screen "Default Screen"
        InputDevice "Generic Keyboard"
        InputDevice "mouse" "SendCoreEvents"
# InputDevice "Configured Mouse"
# InputDevice "stylus" "SendCoreEvents"
# InputDevice "cursor" "SendCoreEvents"
# InputDevice "eraser" "SendCoreEvents"
EndSection

[Mikael Nilsson (mini)]

For what it's worth - this issue still persists in latest gutsy. With my Logitech MX Revolution plugged in, I can't start X with the default evdev configuration, and thus I am not able to use my MX buttons.

[Mikael Nilsson (mini)]

See also

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/97643

Which I solved thanks to this bug report!

[Daniel Stone (daniels)]

i-h makes this redundant, thankfully.

[Mikael Nilsson (mini)]

Daniel: i-h = input hotplug, I assume?

Hopefully it does make this redundant - are we sure the mouse hotplug code will use evdev, though? Without evdev, the issue is moot anyway but for other reasons... please enlighten me!

[Daniel Stone (daniels)]

Yeah, i-h is the input-hotplug branch, which is in the 1.4 release. It makes this redundant because no device is a 'core pointer' anymore, but they all share it, so this sort of thing is now impossible.

[Mikael Nilsson (mini)]

Indeed, the issue is that a CorePointer cannot match multiple devices (the MX revolution exposes several devices, including some keyboard buttons).

solution: as mentioned, use SendCoreEvents for the evdev device as James said. Sorry James, I did not understand that you had solved it and how...

See the linked xorg bug report.

[Arthur (moz-liebesgedichte)]

I'm voting for the solution in comment 9 as well. Finally all my mice work happily together and I can switch from the mouse to the trackball without interruption. Even the special buttons of some of the mice work correctly.

Are there any drawbacks to that solution or could it be made the default configuration?

[Timo Aaltonen (tjaalton)]

Intrepid uses input-hotplug now, so this situation is not possible anymore and should just work.