KDE Has Made Much Progress On Usability/Productivity, But They're Still Aiming For More

[phoronix]

Phoronix: KDE Has Made Much Progress On Usability/Productivity, But They're Still Aiming For More

Excellent KDE blogger Nate Graham has blogged about the work done over the past roughly two years be he and others on improving the usability and productivity of this Linux desktop. Long story short, a lot of progress has been made by the KDE development community but more work remains...

http://www.phoronix.com/scan.php?page=news_item&px=KDE-Usability-Productivity-2019

[tildearrow]

• Full support for configuring mice and touchpads using the Libinput driver on both X11 and Wayland

Awesome! Last time I upgraded my system and noticed that the cursor was faster, I tried configuring it, and was surprised by a total lack of settings when compared to evdev:
- No pointer emulation with keyboard
- Pointer speed was a slider without fine-tune control
- Too much air

[ngraham]

Awesome! Last time I upgraded my system and noticed that the cursor was faster, I tried configuring it, and was surprised by a total lack of settings when compared to evdev:
- No pointer emulation with keyboard
- Pointer speed was a slider without fine-tune control
- Too much air

Libinput flat-out doesn't support the kind of configurability that the older drivers did, which is why the UI for configuring it lacks features you might be accustomed to. If this bugs you, you can always just uninstall Libinput and use the older evdev (for mouse) or synaptics (for touchpad) drivers. The older configuration interfaces for them are still perfectly functional.

[shmerl]

Libinput flat-out doesn't support the kind of configurability that the older drivers did, which is why the UI for configuring it lacks features you might be accustomed to. If this bugs you, you can always just uninstall Libinput and use the older evdev (for mouse) or synaptics (for touchpad) drivers. The older configuration interfaces for them are still perfectly functional.

But xinput somehow provides a ton more options, than those exposed by KDE's configuration. Aren't those going through libinput? So how is it different? xinput is useless in Wayland case, so having proper config would be a replacement.

Also, do you know how active is KWin development lately? I got an impression it slowed down a lot. Some major issues aren't moving forward (subsurfaces handling), and new features like Freesync or Vulkan support are even further away. Is KWin lacking developers?

[ngraham]

But xinput somehow provides a ton more options, than those exposed by KDE's configuration. Aren't those going through libinput? So how is it different? xinput is useless in Wayland case, so having proper config would be a replacement.

What options in xinput are you lacking? If I do `xinput list-props [id of my touchpad]` it looks to me like all the properties that the device actually exports are mapped to options in the UI as of Plasma 5.16 (which is unreleased, but will be out in a week).

Also, do you know how active is KWin development lately? I got an impression it slowed down a lot. Some major issues aren't moving forward (subsurfaces handling), and new features like Freesync or Vulkan support are even further away. Is KWin lacking developers?

Yes, the former maintainer stepped down. Others have worked to pick up the slack, but there are big shoes to fill. Progress is being made--slowly, but it is happening. The absolute best thing that can happen is for it to get more developers. Since it seems that you have some understanding of the technical details, would you like to help out and contribute?

[zanny]

But xinput somehow provides a ton more options, than those exposed by KDE's configuration. Aren't those going through libinput? So how is it different? xinput is useless in Wayland case, so having proper config would be a replacement.

Libinput is tunable, but it doesn't have a configuration utility to access those functions (and wouldn't be able to load them if it did, it doesn't look for config files or anything - the library itself is stateless). It relies on its upstream consumer (Xinput, Wayland compositors, etc) to call library functions according to configurations that they store.

[shmerl]

What options in xinput are you lacking? If I do `xinput list-props [id of my touchpad]` it looks to me like all the properties that the device actually exports are mapped to options in the UI as of Plasma 5.16 (which is unreleased, but will be out in a week).

Well, for example I see this for my mouse, which seems a lot more than KDE system settings expose (though I'm still on Plasma 5.14.5 since Debian testing is stalled due to freeze), and may be most of those options aren't really useful:

Device 'Logitech G400s Optical Gaming Mouse'
        Device Enabled (147):   1
        Coordinate Transformation Matrix (149): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
        libinput Natural Scrolling Enabled (283):       0
        libinput Natural Scrolling Enabled Default (284):       0
        libinput Scroll Methods Available (285):        0, 0, 1
        libinput Scroll Method Enabled (286):   0, 0, 0
        libinput Scroll Method Enabled Default (287):   0, 0, 0
        libinput Button Scrolling Button (288): 2
        libinput Button Scrolling Button Default (289): 2
        libinput Middle Emulation Enabled (290):        1
        libinput Middle Emulation Enabled Default (291):        0
        libinput Accel Speed (292):     0.000000
        libinput Accel Speed Default (293):     0.000000
        libinput Accel Profiles Available (294):        1, 1
        libinput Accel Profile Enabled (295):   1, 0
        libinput Accel Profile Enabled Default (296):   1, 0
        libinput Left Handed Enabled (297):     0
        libinput Left Handed Enabled Default (298):     0
        libinput Send Events Modes Available (268):     1, 0
        libinput Send Events Mode Enabled (269):        0, 0
        libinput Send Events Mode Enabled Default (270):        0, 0
        Device Node (271):      "/dev/input/event2"
        Device Product ID (272):        1133, 49740
        libinput Drag Lock Buttons (299):       <no items>
        libinput Horizontal Scroll Enabled (300):       1

Yes, the former maintainer stepped down. Others have worked to pick up the slack, but there are big shoes to fill. Progress is being made--slowly, but it is happening. The absolute best thing that can happen is for it to get more developers. Since it seems that you have some understanding of the technical details, would you like to help out and contribute?

I'd be interested in looking at it, though I wouldn't have time to contribute much. My personal preference would be Vulkan backend for it, but that is a huge project really. Is KWin in general developed by volunteers now, or there are paid developers who work on it (and who sponsors them?).

[shmerl]

Libinput is tunable, but it doesn't have a configuration utility to access those functions (and wouldn't be able to load them if it did, it doesn't look for config files or anything - the library itself is stateless). It relies on its upstream consumer (Xinput, Wayland compositors, etc) to call library functions according to configurations that they store.

Is there a way to dynamically figure out all tunable parameters and expose them in UI, in order not to create a static UI with just a few limited options? xinput itself reads them somehow for each device. Something like that for KDE would be very useful.

[ngraham]

Well, for example I see this for my mouse, which seems a lot more than KDE system settings expose (though I'm still on Plasma 5.14.5 since Debian testing is stalled due to freeze), and may be most of those options aren't really useful:

Device 'Logitech G400s Optical Gaming Mouse'
Device Enabled (147): 1
Coordinate Transformation Matrix (149): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
libinput Natural Scrolling Enabled (283): 0
libinput Natural Scrolling Enabled Default (284): 0
libinput Scroll Methods Available (285): 0, 0, 1
libinput Scroll Method Enabled (286): 0, 0, 0
libinput Scroll Method Enabled Default (287): 0, 0, 0
libinput Button Scrolling Button (288): 2
libinput Button Scrolling Button Default (289): 2
libinput Middle Emulation Enabled (290): 1
libinput Middle Emulation Enabled Default (291): 0
libinput Accel Speed (292): 0.000000
libinput Accel Speed Default (293): 0.000000
libinput Accel Profiles Available (294): 1, 1
libinput Accel Profile Enabled (295): 1, 0
libinput Accel Profile Enabled Default (296): 1, 0
libinput Left Handed Enabled (297): 0
libinput Left Handed Enabled Default (298): 0
libinput Send Events Modes Available (268): 1, 0
libinput Send Events Mode Enabled (269): 0, 0
libinput Send Events Mode Enabled Default (270): 0, 0
Device Node (271): "/dev/input/event2"
Device Product ID (272): 1133, 49740
libinput Drag Lock Buttons (299): <no items>
libinput Horizontal Scroll Enabled (300): 1

Everything there is supported in 5.16. Many of the entries there are read-only "am I supported?" properties that exist only so configuration UIs know what they can present to the user. For example:

libinput Scroll Methods Available (285): 0, 0, 1
libinput Scroll Method Enabled (286): 0, 0, 0
libinput Scroll Method Enabled Default (287): 0, 0, 0

This is fancy way of saying the mouse has a scroll wheel with only one scrolling mode. So obviously there's nothing that can be configured there so we don't show a "scroll mode" interface with just one option, since that would be silly.

I'd be interested in looking at it, though I wouldn't have time to contribute much. My personal preference would be Vulkan backend for it, but that is a huge project really. Is KWin in general developed by volunteers now, or there are paid developers who work on it (and who sponsors them?).

Both. Blue systems (my own employer) is currently sponsoring one full-time KWin developer and several others contribute part-time. Please do give it a shot!

[shmerl]

Both. Blue systems (my own employer) is currently sponsoring one full-time KWin developer and several others contribute part-time. Please do give it a shot!

Good to know, thanks!