@xuetianweng any update?

I wanted to test it, but I'm not sure how to.
kcmshell5 input doesn't give me anything, am I looking at the right place?

$ kcmshell5 mouse
kcm_input: Using X11 backend

$ kcmshell5 touchpad
kcm_touchpad: Using X11 backend

The file on disk is at /usr/lib/x86_64-linux-gnu/qt5/plugins/kded_touchpad.so (on KDE Neon and other Ubuntu-based distros)

In D8798#169155, @ngraham wrote:

$ kcmshell5 touchpad
kcm_touchpad: Using X11 backend

The file on disk is at /usr/lib/x86_64-linux-gnu/qt5/plugins/kded_touchpad.so (on KDE Neon and other Ubuntu-based distros)

Are you sure? because this is modifying files in kcms/input that creates a kcm_input.so... Is it a kcm that extends kcm_touchpad.so?

In D8798#169156, @apol wrote:

In D8798#169155, @ngraham wrote:

$ kcmshell5 touchpad
kcm_touchpad: Using X11 backend

The file on disk is at /usr/lib/x86_64-linux-gnu/qt5/plugins/kded_touchpad.so (on KDE Neon and other Ubuntu-based distros)

Are you sure? because this is modifying files in kcms/input that creates a kcm_input.so... Is it a kcm that extends kcm_touchpad.so?

It's called mouse. kcmshell5 mouse

@apol got a chance to test it?

on kcm touchpad I still get "No touchpad found" (on my KDE Slimbook), this isn't a surprise as your patch doesn't touch the touchpad kcm. Should it?

In D8798#170879, @jriddell wrote:

on kcm touchpad I still get "No touchpad found" (on my KDE Slimbook), this isn't a surprise as your patch doesn't touch the touchpad kcm. Should it?

That would be probably be handled by a different patch. And FYI this request is tracked by https://bugs.kde.org/show_bug.cgi?id=387153.

But yes, I was hoping @xuetianweng would do that too. :)

This disables the input kcm if libinput x11 plugin is not found. I expect this is fine, it is for ubuntu distros at least, but it might be worth asking distros if it causes them a problem.

Using the patch the acceleration profile box doesn't show. I have a KDE Slimbook with and xinput reports this:

⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ ImExPS/2 Generic Explorer Mouse id=14 [slave pointer (2)]
⎜ ↳ BluetoothMouse3600 id=15 [slave pointer (2)]
⎜ ↳ SIGMACHIP USB Keyboard id=10 [slave pointer (2)]

Will it not work with this hardware?

Whether it shows up reallys depends on your system. Especially when there's multiple mouse driver available and you may using evdev.

For example, here's one output on my system, when you see something like this, you'll know it's using libinput's xf86 driver. On ubuntu the relavant package I found is:
https://packages.ubuntu.com/artful/xserver-xorg-input-libinput

$ xinput list-props 16
Device 'Newmen1100 MOUSE':
   Device Enabled (142):   1
   Coordinate Transformation Matrix (144): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
   libinput Natural Scrolling Enabled (285):       0
   libinput Natural Scrolling Enabled Default (286):       0
   libinput Left Handed Enabled (287):     0
   libinput Left Handed Enabled Default (288):     0
   libinput Accel Speed (289):     0.000000
   libinput Accel Speed Default (290):     0.000000
   libinput Accel Profiles Available (435):        1, 1
   libinput Accel Profile Enabled (436):   1, 0
   libinput Accel Profile Enabled Default (437):   1, 0
   libinput Scroll Methods Available (291):        0, 0, 1
   libinput Scroll Method Enabled (292):   0, 0, 0
   libinput Scroll Method Enabled Default (293):   0, 0, 0
   libinput Button Scrolling Button (438): 2
   libinput Button Scrolling Button Default (439): 2
   libinput Middle Emulation Enabled (297):        0
   libinput Middle Emulation Enabled Default (298):        0
   libinput Send Events Modes Available (262):     1, 0
   libinput Send Events Mode Enabled (263):        0, 0
   libinput Send Events Mode Enabled Default (264):        0, 0
   Device Node (265):      "/dev/input/event17"
   Device Product ID (266):        7119, 41
   libinput Drag Lock Buttons (301):       <no items>
   libinput Horizontal Scroll Enabled (302):       1

In D8798#170892, @jriddell wrote:

This disables the input kcm if libinput x11 plugin is not found. I expect this is fine, it is for ubuntu distros at least, but it might be worth asking distros if it causes them a problem.

FYI on ubuntu the package is https://packages.ubuntu.com/xenial/xserver-xorg-input-libinput-dev .

Actually it only contains some macro string definition, but I would still prefer to use the macro from header instead of duplicate them here. After all, we're also depending on https://packages.ubuntu.com/artful/xserver-xorg-input-evdev-dev . And kwin's wayland mode will use libinput anyway.

@jriddell ping?

This is my output from xinput which suggests it's using evdev, how do I get it to use libinput?

>xinput list-props 14
Device 'ImExPS/2 Generic Explorer Mouse':
        Device Enabled (140):   1
        Coordinate Transformation Matrix (142): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
        Device Accel Profile (266):     0
        Device Accel Constant Deceleration (267):       1.000000
        Device Accel Adaptive Deceleration (268):       1.000000
        Device Accel Velocity Scaling (269):    10.000000
        Device Product ID (260):        2, 6
        Device Node (261):      "/dev/input/event13"
        Evdev Axis Inversion (270):     0, 0
        Evdev Axes Swap (272):  0
        Axis Labels (273):      "Rel X" (150), "Rel Y" (151), "Rel Horiz Wheel" (265), "Rel Vert Wheel" (291)
        Button Labels (274):    "Button Left" (143), "Button Middle" (144), "Button Right" (145), "Button Wheel Up" (146), "Button Wheel Down" (147), "Button Horiz Wheel Left" (148), "Button Horiz Wheel Right" (149), "Button Side" (289), "Button Extra" (290), "Button Unknown" (263), "Button Unknown" (263), "Button Unknown" (263), "Button Unknown" (263)
        Evdev Scrolling Distance (275): 1, 1, 1
        Evdev Middle Button Emulation (276):    0
        Evdev Middle Button Timeout (277):      50
        Evdev Middle Button Button (278):       2
        Evdev Third Button Emulation (279):     0
        Evdev Third Button Emulation Timeout (280):     1000
        Evdev Third Button Emulation Button (281):      3
        Evdev Third Button Emulation Threshold (282):   20
        Evdev Wheel Emulation (283):    0
        Evdev Wheel Emulation Axes (284):       0, 0, 4, 5
        Evdev Wheel Emulation Inertia (285):    10
        Evdev Wheel Emulation Timeout (286):    200
        Evdev Wheel Emulation Button (287):     4
        Evdev Drag Lock Buttons (288):  0

On Ubuntu:

sudo apt install xserver-xorg-input-libinput
sudo apt remove xserver-xorg-input-mouse xserver-xorg-input-evdev  xserver-xorg-input-[anything else]
[reboot]

Package names may be slightly different on non-Ubuntu distros.

Or maybe just, "Pointer Acceleration:"?

+1 to Pointer Accelaration

Sorry for the long delay on a review.

Can you give a short overview on how the switching works between Xlib and libinput backend on X? So what's the runtime detection if libinput is available or not? Somebody above said mouse kcm is not available without libinput anymore with this patch. But this should not happen of course.

Naming the config option Pointer Acceleration is problematic, because libinput names another property "pointer acceleration". I think we should not change the name. Unneeded deviation from upstream. Maybe better add a tooltip with a description if people complain.

In the touchpad kcm the backends for libinput and xlib are in different files (in the same backend/x11 subfolder). Is this possible here as well?

In D8798#175698, @subdiff wrote:

Sorry for the long delay on a review.

Can you give a short overview on how the switching works between Xlib and libinput backend on X? So what's the runtime detection if libinput is available or not? Somebody above said mouse kcm is not available without libinput anymore with this patch. But this should not happen of course.

Naming the config option Pointer Acceleration is problematic, because libinput names another property "pointer acceleration". I think we should not change the name. Unneeded deviation from upstream. Maybe better add a tooltip with a description if people complain.

In the touchpad kcm the backends for libinput and xlib are in different files (in the same backend/x11 subfolder). Is this possible here as well?

Well, there's nothing changed for X11 and things only get better. X11 doesn't use libinput directly, it uses a xf86 input driver called xf86-input-libinput. This change enables the kcm to configure the mouse option using this driver. Otherwise, the old kcm does nothing when people use this driver (it means some configuration in kcm doesn't work for them).

From the dependency point of view, it only introduce a build time dependency on xf86-input-libinput (by using some string macro in it), just like we already depend on xf86-input-evdev as build dependency. While it is possible to to hardcode those strings directly, I don't feel comfortable doing so because it introduces risk of breakage that we will not notice.

In D8798#175698, @subdiff wrote:

Sorry for the long delay on a review.

Can you give a short overview on how the switching works between Xlib and libinput backend on X? So what's the runtime detection if libinput is available or not? Somebody above said mouse kcm is not available without libinput anymore with this patch. But this should not happen of course.

Naming the config option Pointer Acceleration is problematic, because libinput names another property "pointer acceleration". I think we should not change the name. Unneeded deviation from upstream. Maybe better add a tooltip with a description if people complain.

In the touchpad kcm the backends for libinput and xlib are in different files (in the same backend/x11 subfolder). Is this possible here as well?

The touchpad's libinput backend is only for wayland. And it also has some different code to support xf86-input-libinput under its x11 directory. As I said before they are different things.

We haven't get to the point to support wayland in this kcm yet.

If people has better idea about the naming we can change later.. right now, we seems to use pointer acceleration for "rate". The profile is more clear.

Also if you check the Mouse navigation tab there's another "acceleration profile". I guess that's somewhat matching in the meaning.