[Mouse KCM] Add X11 libinput exclusive backend and UI
ClosedPublic

Authored by romangg on Mar 18 2018, 10:25 PM.

Details

Summary

This patch splits up the current X11 backend into one for systems with
installed X libinput driver and systems with only evdev driver.

The evdev backend is used together with the old QWidget based UI. The
libinput backend is based on the KWin Wayland one and controlled by a
very similar QML based UI. One difference is that values are always
propagated to all pointer like devices and can not be set for
individual devices.

As for the evdev backend values are saved to a config file in the user
directory and reapplied on every session start.

Note that the libinput backend always takes precedence to the evdev one.
If an user wants to force the evdev backend, the X libinput driver needs
to be removed.

Depends on D11468

BUG: 350688

Test Plan

Tested X session with and without libinput driver.

Diff Detail

Repository
R119 Plasma Desktop
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
romangg requested review of this revision.Mar 18 2018, 10:25 PM
romangg created this revision.
romangg edited the summary of this revision. (Show Details)Mar 18 2018, 10:33 PM
romangg set the repository for this revision to R119 Plasma Desktop.
romangg added a project: Plasma.
romangg added a subscriber: plasma-devel.

Ah, people are really going to like this.

Instead of "acceleration", could we make the label say "speed"? I know "acceleration" is technically what it's controlling, but I think "speed" gets the point across just as well and it's more natural language--more in tune with what people are going to go looking for when they decide they want their mouse to go faster or slower.

ngraham added a comment.EditedMar 19 2018, 3:37 AM

Some more UI comments:

  • Right now it looks pretty awkward with everything left-justified. Centering would seem to be more natural.
  • Since the speed/acceleration is the most commonly-changed settings, let's move it up to the top.
  • I think we could put the bottom checkbox on the top, unifying all the "behavior"-style settings in one place.
  • This would seem like a good candidate for using Marco's FormLayout, or at least copying the style. That means aligning all the controls and putting labels to the left of them (except for checkboxes, which always have labels only on the right.

Here's an exceptionally crude ASCII mockup of what I'm imagining:

               Speed: -----------|-----------
Acceleration profile: ( ) Flat
                      (o) Adaptive

                      [ ] Left-handed mode
                      [ ] Emulate middle button
                      [x] Invert scroll direction
ngraham edited the summary of this revision. (Show Details)Mar 19 2018, 3:38 AM
abetts added a subscriber: abetts.Mar 19 2018, 3:41 AM

Some more UI comments:

  • Right now it looks pretty awkward with everything left-justified. Centering would seem to be more natural.
  • Since the speed/acceleration is the most commonly-changed settings, let's move it up to the top.
  • I think we could put bottom checkbox on the top, unifying all the "behavior"-style settings in one place.
  • This would seem like a good candidate for using Marco's FormLayout, or at least copying the style. That means aligning all the controls and putting labels to the left of them (except for checkboxes, which always have labels only on the right.

    Here's an exceptionally crude ASCII mockup of what I'm imagining:

    ` Speed: -----------|----------- Acceleration profile: ( ) Flat (o) Adaptive
    • Left-handed mode
    • Emulate middle button
    • Invert scroll direction `

+1 on this!

ngraham added inline comments.Mar 19 2018, 3:49 AM
kcms/input/kcm/libinput/main_deviceless.qml
63

Do you really need to define each individual column like this? Seems like a code small to me.

Thanks for your feedback guys. I maybe should have noted that I see the UI more as a placeholder right now and didn't bother about the design. This patch is only about the technical bits. Making the UI beautiful should then go in a separate one ASAP. And I hope someone else might tackle this cause I need to do some KWin work in the imminent future.

  • This would seem like a good candidate for using Marco's FormLayout, or at least copying the style. That means aligning all the controls and putting labels to the left of them (except for checkboxes, which always have labels only on the right.

That's exactly what I expect it (and the Wayland UI and the Touchpap UI) to be built upon in the end.

I volunteer to do the UI part. Hopefully @mart or @hein can help me with my first FormLayout KCM, then maybe I can do more in the future...

mart added a comment.Mar 19 2018, 2:15 PM

I volunteer to do the UI part. Hopefully @mart or @hein can help me with my first FormLayout KCM, then maybe I can do more in the future...

sure

@romangg so is this more of a request just for code review review, then?

@romangg so is this more of a request just for code review review, then?

Yes. You can also just compile and test it to see if there are no regressions. And in case not accept it.

davidedmundson added inline comments.
kcms/input/backends/x11/libinput_settings.cpp
27

KConfig("foo")
will load foo and parse it every time.

kcms/input/backends/x11/libinput_settings.h
27

this use of templates doesn't match the implementation

romangg added inline comments.Mar 27 2018, 2:15 PM
kcms/input/backends/x11/libinput_settings.h
27

Do you mean in the cpp file? There are two template specializations defined.

davidedmundson accepted this revision.Mar 29 2018, 3:39 PM
This revision is now accepted and ready to land.Mar 29 2018, 3:39 PM
This revision was automatically updated to reflect the committed changes.
romangg marked an inline comment as done.