Solved After upgrade to 15.0-STABLE mouse does not get recognized in Xorg

grep -i mouse /var/log/Xorg.0.log
Does that show anything?
Do you have any X config files that specify a mouse?
For the console, do you have moused enabled?
 
For the console, do you have moused enabled?
No.
Do you have any X config files that specify a mouse?
No.
xf86-input
# pkg info -x xf86-input
xf86-input-evdev-2.10.6_8
xf86-input-keyboard-1.9.0_6
xf86-input-libinput-1.3.0_1
xf86-input-mouse-1.9.3_5
grep -i mouse /var/log/Xorg.0.log
444: [ 13561.793] (II) config/udev: Adding input device Logitech USB Gaming Mouse (/dev/input/event6)
445: [ 13561.793] (**) Logitech USB Gaming Mouse: Applying InputClass "evdev pointer catchall"
446: [ 13561.793] (**) Logitech USB Gaming Mouse: Applying InputClass "libinput pointer catchall"
447: [ 13561.793] (II) Using input driver 'libinput' for 'Logitech USB Gaming Mouse'
448: [ 13561.793] (**) Logitech USB Gaming Mouse: always reports core events
450: [ 13561.796] (II) event6 - Logitech USB Gaming Mouse: is tagged by udev as: Mouse
451: [ 13561.797] (II) event6 - Logitech USB Gaming Mouse: device is a pointer
452: [ 13561.800] (II) event6 - Logitech USB Gaming Mouse: device removed
453: [ 13561.810] (II) libinput: Logitech USB Gaming Mouse: Step value 0 was provided, libinput Fallback acceleration function is used.
454: [ 13561.810] (II) libinput: Logitech USB Gaming Mouse: Step value 0 was provided, libinput Fallback acceleration function is used.
455: [ 13561.810] (II) libinput: Logitech USB Gaming Mouse: Step value 0 was provided, libinput Fallback acceleration function is used.
457: [ 13561.810] (II) XINPUT: Adding extended input device "Logitech USB Gaming Mouse" (type: MOUSE, id 12)
459: [ 13561.811] (**) Logitech USB Gaming Mouse: (accel) selected scheme none/0
460: [ 13561.811] (**) Logitech USB Gaming Mouse: (accel) acceleration factor: 2.000
461: [ 13561.811] (**) Logitech USB Gaming Mouse: (accel) acceleration threshold: 4
462: [ 13561.813] (II) event6 - Logitech USB Gaming Mouse: not tagged as supported input device
465: [ 13561.824] (EE) Couldn't init device "Logitech USB Gaming Mouse"
There: (EE) Couldn't init device "Logitech USB Gaming Mouse"
 
  • Like
Reactions: mer
Ahh. Thanks. I don't have anything else to add, but my questions are the "obvious" ones.
I understand you want to use this specific mouse, but if you have a different mouse (especially a simple USB hardwired) have you tried it? Just to verify that "yes I can get a mouse to work".

I thought that in the console, one needed to have moused running. It may have changed, but worth checking.
 
Hm... Does the mouse USB channel show something if you move it?
To listen: stdbuf -o 0 usbdump -d ugen<x>.<y>
 
I understand you want to use this specific mouse, but if you have a different mouse (especially a simple USB hardwired) have you tried it? Just to verify that "yes I can get a mouse to work".
Oh yes, that is a valuable device that I want to use. It did work well on RELEASE-14.3. I did try a spare mouse and that works.
To listen: stdbuf -o 0 usbdump -d ugen<x>.<y>
Output like this from the mouse not working with xfce:
17:55:50.315747 usbus0.5 SUBM-INTR-EP=00000081,SPD=FULL,NFR=1,SLEN=0,IVAL=1
17:55:50.988734 usbus0.5 DONE-INTR-EP=00000081,SPD=FULL,NFR=1,SLEN=12,IVAL=1,ERR=0
 
  • Like
Reactions: mer
Output like this from the mouse not working with xfce (captured with xfce4-terminal!!):
That's normal. I have similar data from it. I think it's a USB mouse protocol problem but not sure. What I did read from AI source is that xf86-input-mouse and xf86-input-evdev can conflict if they try to use the same device, so trying only 1 of both might be a good idea.
 
What I did read from AI source is that xf86-input-mouse and xf86-input-evdev can conflict if they try to use the same device, so trying only 1 of both might be a good idea.
Tried every possible combination. No solution, AI hallucinating? :'‑(
The Gamer mouse causes this error in /var/log/Xorg.0.log when plugged in:
[ 23258.909] (EE) Couldn't init device "Logitech USB Gaming Mouse"
Does that device need to be configured for Xorg? What the hell has changed from FreeBSD 14.3 to 15.0?
 
There: (EE) Couldn't init device "Logitech USB Gaming Mouse"
It looks like this device is not libinput compatible for some reasons.

As this driver is the default you may either try uninstalling it (you already have the legacy evdev, mouse and keyboard drivers installed) and see which driver claims your device; if this works you may optionally create a "logitech.conf" where you specify which driver you want to use accordingly.

At the end you may even want to reinstall libinput, which should ignore this Logitech mouse.
 
I have the same problem, but with a virtual device that I create programmatically writing to /dev/uinput.

When I name my virtual device "HeliMouse pointing device",
- it creates successfully,
- no ioctl() returns -1, no write() returns anything less than the writable size,
- "evtest" shows it and reports motion and click events,
- "libinput debug-events" correctly receives evdev motion events,
- but Xorg.0.log says:
[ 8261.617] (II) event13 - HeliMouse pointing device: not tagged as supported input device
[ 8261.617] (II) event13 - not using input device '/dev/input/event13'.
... and no way for my fake device to move the pointer on screen.

BUT

When I name it "Helimouse pointing device 2"
with the EXACT SAME bus/device ID/product ID configuration and the EXACT SAME capabilities
... it works.

Looking through libinput's source code (src/evdev.c line 2330) I see the offending message:
C:
    enum evdev_device_udev_tags udev_tags =
        evdev_device_get_udev_tags(device, device->udev_device);
    if ((udev_tags & EVDEV_UDEV_TAG_INPUT) == 0 ||
        (udev_tags & ~EVDEV_UDEV_TAG_INPUT) == 0) {
        evdev_log_info(device, "not tagged as supported input device\n");
        goto err;
    }

The call to evdev_device_get_udev_tags() leads me 2 hops down in src/evdev.c line 101 to:
C:
static inline bool
parse_udev_flag(struct evdev_device *device,
        struct udev_device *udev_device,
        const char *property)
{
    const char *val;
    bool b;
    val = udev_device_get_property_value(udev_device, property);
    if (!val)
        return false;
    if (!parse_boolean_property(val, &b)) {
        evdev_log_error(device,
                "property %s has invalid value '%s'\n",
                property,
                val);
        return false;
    }
    return b;
}

And the property that is tested is defined line 80:
{ "ID_INPUT", EVDEV_UDEV_TAG_INPUT },

Yet, I can't seem to locate the implementation of udev_device_get_property_value() !?

*edit* Sorry for the multiple edits. I just wanted to add that it seemed to work well with FreeBSD 14.3 (but that might perfectly be a sort of side effect). I just happen to stumble upon it after I upgraded to FreeBSD 15.0-RELEASE-p2.

*edit again* OK I found it. It's in libudev (libudev-devd-0.6.0) So I think there might be a problem somewhere in libudev-devd/udev-utils.c line 388 (that's the only code path I see where the device property could fail to be set).
 
Pierre-Marie Baty just to make clear what solved my problem:
Just delete x11-drivers/xf86-input-libinput because it is conflicting with x11-drivers/xf86-input-evdev as fmc000 correctly pointed to in his post above.

My created Section "InputDevice" is at least not necessary here.
Oh, that totally makes sense!
$ pkg info|grep xf86-input
xf86-input-evdev-2.10.6_8 X.Org event device input driver
xf86-input-joystick-1.6.3_5 X.Org joystick input driver
xf86-input-keyboard-1.9.0_6 X.Org keyboard input driver
xf86-input-libinput-1.3.0_1 X.Org libinput input driver
xf86-input-mouse-1.9.3_5 X.Org mouse input driver
xf86-input-vmmouse-13.1.0_7 X.Org vmmouse input driver


There are way too many things here. Thank you!
 
Just FYI as this is marked as "solved".

FreeBSD has in-kernel evdev support on 15.0 (not 100% sure but from 13.0 or 14.0).
And x11-drivers/xf86-input-libinput wants to grab evdev as its backend, so conflicting with x11-drivers/xf86-input-evdev.

When I've encountered problem at quite early phase in-kernel evdev was introduced, I've added below in my /etc/sysctl.conf and switched uncommented line one by one to find working configuration.
Code:
## evdev event generation settings for keyboards and mice.
## Set correlated bits to enable.
## The value is defined in sys/dev/evdev/evdev.h as
##    #define    EVDEV_RCPT_SYSMOUSE    (1<<0)
##    #define    EVDEV_RCPT_KBDMUX    (1<<1)
##    #define    EVDEV_RCPT_HW_MOUSE    (1<<2)
##    #define    EVDEV_RCPT_HW_KBD    (1<<3)
##    extern int evdev_rcpt_mask;
## respectively.
#
# kern.evdev.rcpt_mask=1    # bit0 (1<<0), via sysmouse
# kern.evdev.rcpt_mask=2    # bit1 (1<<1), via kbdmux
# kern.evdev.rcpt_mask=4    # bit2 (1<<2), direct USB mouse (ums)
# kern.evdev.rcpt_mask=8    # bit3 (1<<3), direct keyboard (atkbd and ukbd)
# kern.evdev.rcpt_mask=5    # Both bit2 and 0 (sysmouse and ums, no kbd)
# kern.evdev.rcpt_mask=6    # Both bit2 and 1 (ums and kbdmux)
# kern.evdev.rcpt_mask=7    # Bits2, 1, and 0 (ums, kbdmux and sysmouse)
# kern.evdev.rcpt_mask=9    # Bits3 and 0 (direct keyboard and sysmouse)
# kern.evdev.rcpt_mask=10    # Both bit3 and 1 (direct kbd and kbdmux)
# kern.evdev.rcpt_mask=11    # Bits3, 1, and 0 (HW kbd, kbdmux, sysmouse)
kern.evdev.rcpt_mask=12    # Both bit3 and 2 (direct kbd and ums) default
# kern.evdev.rcpt_mask=13    # Bits 3, 2 and 0 (HW kbd, ums and sysmouse)
# kern.evdev.rcpt_mask=14    # Bits 3, 2 and 1 (HW kbd, ums and kbdmux)
# kern.evdev.rcpt_mask=15    # All 4 bits
 
Back
Top