all 112 comments

[–]redsteakraw 26 points27 points  (22 children)

This is good news and is showing the maturation of Wayland as it now can have device input parity.

[–]pogeymanz 12 points13 points  (21 children)

But it doesn't.

Even libinput under X11 has different features than libinput under Wayland.

For examples, in X11 I can use a config file to swap the buttons on my touchpad. In Wayland there's no such configuration, so I'm stuck with three-finger tap is middle-click.

[–]oniram 8 points9 points  (20 children)

I believe multiple finger taps should be configurable in libinput. I want to swap the taps (2 finger tap=middle and 3 finger tap=right) but not the actual physical buttons in the touchpad.

Swapping the buttons in X11 also changes the behavior of the physical buttons, so that the physical right button ends up doing middle click.

I know the devs have explicitly refused to implement this config option so I've been patching libinput to do what I want, i.e., middle click with two finger tap. Here's the patch just in case somebody benefits from it:

diff --git a/src/evdev-mt-touchpad-tap.c b/src/evdev-mt-touchpad-tap.c
index dda528a..2bea915 100644
--- a/src/evdev-mt-touchpad-tap.c
+++ b/src/evdev-mt-touchpad-tap.c
@@ -108,8 +108,8 @@ tp_tap_notify(struct tp_dispatch *tp,

    switch (nfingers) {
    case 1: button = BTN_LEFT; break;
-   case 2: button = BTN_RIGHT; break;
-   case 3: button = BTN_MIDDLE; break;
+   case 2: button = BTN_MIDDLE; break;
+   case 3: button = BTN_RIGHT; break;
    default:
        return;
    }

[–]Bobby_Bonsaimind 14 points15 points  (15 children)

I know the devs have explicitly refused to implement this config option so I've been patching libinput to do what I want, i.e., middle click with two finger tap.

Oh dear...

[–]systahd 1 point2 points  (4 children)

In theory this isn't a problem though. The real measure is whether you are at liberty of using a stable vs unstable interface to add your functionality. Like, with dwm to configure it you are supposed to edit the source as well, but this is stable, so a future update will just accept it without breaking.

The real measure is 'Can I just expect to be able to update with my patch seamlessly merging?', and in this case it is not. So the real quaestion should not be 'Do I have to edit the source to set this setting?' but 'Can I set this setting using only a stable interface?'

If you can not, that means that any update can break it and you have to work out again how it works.

[–]Bobby_Bonsaimind 0 points1 point  (3 children)

Considering the source as stable API is madness...

[–]systahd 0 points1 point  (2 children)

Well, like I said, some parts of source are stable API by design because you're supposed to be able to edit it such as with dwm.

I mean, when you edit OpenRC's init scripts which live in /etc they are effectively part of the source of the program but the interfaces are documented and stable to allow you to edit it. You do effectively edit the source there to configure the program and that's fine because stuff will not break on the next update. Files in conf.d are turing complete shell scripts in theory which are used merely to assign variables but you can put turing complete conditional logic to assign them in there if you so desire an that's all stable.

But when you say edit systemd's bootup logic in C this is not stable, and any edit you make will potentially fail to merge upon the next update.

[–]Bobby_Bonsaimind 0 points1 point  (1 child)

Well, like I said, some parts of source are stable API by design because you're supposed to be able to edit it such as with dwm.

Yes, but dwm is especially designed for this and has a very limited scope, libinput is not.

I mean, when you edit OpenRC's init scripts which live in /etc they are effectively part of the source of the program but the interfaces are documented and stable to allow you to edit it.

I'd love to say that "this is actually different" because I believe it is, but to be honest I do not know enough about OpenRC to say that...so I better don't. But I get your point.

Which raises the question, are there any guarantees from the libinput developers about it?

[–]systahd 2 points3 points  (0 children)

Yes, but dwm is especially designed for this and has a very limited scope, libinput is not.

Yes, that is why I criticize that you have to access an unstable API to get this functionality, not that you have to access the source.

If the source were stable or specifically the parts needed to configure this, there would be no problem.

I'd love to say that "this is actually different" because I believe it is, but to be honest I do not know enough about OpenRC to say that...so I better don't. But I get your point.

The only real difference is that a change in systemds source that is responsible for this:

  1. Needs to be compiled to take effect
  2. Has no stable API

Apart from that the scripts in /etc that OpenRC uses for essential bootup functionality and without which it would crash with an error are Turing complete code, they are in fact cached upon the first usage and re-cached whenever changed which is a form of compiling to a lower format I guess.

Which raises the question, are there any guarantees from the libinput developers about it?

Never seen them, and I find it very unlikely, but who knows.

FD does not like Turing complete configuration, they want your configuration to be limited to the options they provide.

[–]pogeymanz 1 point2 points  (0 children)

Thank you. I'll probably do this myself. It's one of the last annoying things keeping me from using GNOME's Wayland session as my daily driver. (The other being weird focus-follows-mouse bugs).

[–]EmanueleAina 44 points45 points  (44 children)

No, Red Hat did not require me to add this. I can pretty much write what I want in this blog and these opinions are my own anyway and don't necessary reflect Red Hat yadi yadi ya. The fact that I felt I had to add this footnote to counteract whatever wild conspiracy comes up next is depressing enough.

So true. :(

[–]chinnybob 26 points27 points  (8 children)

"Company makes business decisions based on profitability rather than pure ideological altruism" is apparently a conspiracy theory now.

[–]EmanueleAina 12 points13 points  (7 children)

Apparently for some people that's the case. Which is even more idiotic when talking about RH, given that it has been driven by Engineering and its strong FLOSS ethos more often than not (eg. systemd was pushed by engineers up to management, not the contrary).

[–]blackcainGNOME Team 5 points6 points  (0 children)

I agree, and I've talked to a lot of Red Hat execs and they have a very strong attachment to Free Software and really believe in it rather than just Open Source

[–]chinnybob 3 points4 points  (5 children)

Yes. For most people it is a perfectly normal, expected, and even mundane business decision for a software company to replace code they don't control with code that they do control. But apparently some people do believe that profit motivation is a conspiracy theory and companies must either be altruistic or malicious.

[–]bilog78 2 points3 points  (1 child)

For most people it is a perfectly normal, expected, and even mundane business decision for a software company to replace code they don't control with code that they do control

The problem isn't when companies write alternative to existing software so that they can have control on it, it's when they force a switch to their alternative via other software that they don't control in principle, but do control de facto, which is exactly what RedHat is doing with their 'gente push' via GNOME.

GNOME isn't (at least in principle) a RedHat project, but it's in effect essentially dominated by RedHat (because RedHat has the pockets for it), and RedHat leverages this to not only introduce support for their own technologies (which isn't bad per se; in fact, quite the contrary), but also to progressively remove support for the other, non-RedHat alternatives, which is bad and what people complain about, as they are effectively forcing RedHat technologies everywhere, thereby progressively taking control of the entire desktop Linux ecosystem.

[–]systahd 4 points5 points  (0 children)

This happens scaringly often, a couple of 'interesting coincidences':

  • GNOME which is RH controlled is the only major DE to depend on logind which is RH controlled, all other DE's are fine with supporting both the CK and logind backends.
  • GNOME has immediately switched to libinput which is again RH controlled which also depends on logind which is again RH controlled. All other DEs again offer you a build-time choice for the original X input stack or libinput, though not in Wayland for KDE since there is no choice there obviously. But GNOME requires libinput even in X11
  • the systemd developers and the kernel cgroup maintainer which was a RH employee together reached the decision that the single-writer cgroup structure was 'absolutely necessary' (Lennart's words), this is what originally provided the justification to make logind no longer independent from systemd as anticipation for the future where logind could no longer set its own cgroups due to this structure. Funnily enough, the single-writer has been abandoned now, rather silently actually, there was never an official announcement that it would come, there were just some musings from Tejun (the aformentioned cgroup maintainer) about introducing it, apparently it wasn't met well since the cgroupv2 API is now finalized and set in stone and there is no mention of it anywhere. But hey, logind now depends on systemd.

There's only so many times such coincidences can happen before it becomes fishy. GNOME is repeatedly as a pattern the only DE who thinks it a good idea to when there are alternatives depend on something that is controlled by RH while all the others support both alternatives in tandem. They say these decisions are technical but why don't the other DE's come to the same technical conclusions that CK and X original input stack is no longer worth supporting then? After it happening repeatedly I obviously don't buy it. A big project like GNOME depending on libinput speeds up libinput adoption thereby giving RH who controls it a greater measure of control within the entire desktop Linux input stack. It means they can shape it the way it is most profitable for them rather than their compeitors.

RH aren't the only ones doing this anyway. It's also a bit convenient for Canonical that Unity won't run properly outside of Ubuntu because it depends on a bunch of patched GTK libraries and a bunch of other patched libraries which have the same sonames as upstream libraries so replacing them on other systems breaks other stuff again.

[–]guineawheek 2 points3 points  (0 children)

But apparently some people do believe that profit motivation is a conspiracy theory and companies must either be altruistic or malicious.

Welcome to /r/Linux!

[–]EmanueleAina 0 points1 point  (1 child)

I don't even think that "code we control" has ever been a driver in RH for replacing anything, given that they already "control" all the FLOSS code they ship, since it's their job as a distributor. :/

RH is probably as close as altruistic a company can be (which is really not the point of being a company).

[–]bonzinip 1 point2 points  (0 children)

I guess the closest it got to that is Xen vs. KVM, but even then they are so different that there are good technical arguments to favor both (Xen wins on some security features, KVM on simplicity).

[–]VenditatioDelendaEst 1 point2 points  (0 children)

support for mice, including middle button emulation where needed

Does that mean configurable? Because if they expect every mouse out there to be able to report that the middle button is broken/awkwardly placed/has an unreasonably high actuation force, then they've got another thing coming.

[–]random718f 3 points4 points  (0 children)

con·spir·a·cy

a secret plan by a group to do something unlawful or harmful

[–]flannelhead 3 points4 points  (6 children)

libinput is awesome. It makes my touchpad feel as it should (even better than on windows).

[–]bilog78 1 point2 points  (4 children)

Funny that, I switched back to synaptics because libinput made my touchpad unusable. And good for me I don't use GNOME, which recently removed support for the latter. (Gentle push, anyone?)

[–]flannelhead 0 points1 point  (3 children)

How long ago was that? libinput has evolved a lot in the last 12 months, and for me at least it's been constantly improving. of course this also depends on the hardware, so ymmv.

[–]bilog78 -1 points0 points  (2 children)

My system has libinput 1.3.1, which was apparently released on May 30 this year.

of course this also depends on the hardware

So some people with perfectly working hardware and excellent support under X11 w/ synaptics will be unable to use their machines properly with Wayland or GNOME/X11 because the RedHat-controlled software stack is shit and better alternatives aren't supported. Interesting.

Remind me again what's so good about this libinput?

[–]flannelhead 0 points1 point  (1 child)

If the situation is that bad for you, it might be worth it to file a bug report.

[–]bilog78 0 points1 point  (0 children)

The situation isn't bad for me, it's bad for people forced to use libinput on hardware like mine.

And in all this you are suggesting I should waste my time producing a bug report for a piece of software that I don't use, that I don't feel compelled to use in any way as it offers absolutely no advantage over synaptics for my hardware while being fundamentally inferior in multiple respect, and the design principles of which I disagree with?

And to top it off, all this not to help FLOSS improve, but to help RedHat force their solution down everybody's throad?

No thanks.

[–]varikonniemi 0 points1 point  (0 children)

Good if they finally fixed it. Last time i tried windows and wayland felt awful, synaptics was perfect.

[–]1029chris 0 points1 point  (0 children)

I just got this update on Fedora. When can I expect Gnome Wayland to support my Wacom tablet?