Libinput's bus factor is 1 (2019) | Hacker News Reader

Libinput's bus factor is 1 (2019)

who-t.blogspot.com

187 pointsluu129 comments

I said it before, will say it again:

this should be a problem of Red Hat management. I'm sure they are very much aware Hutterer is overwhelmed (what with blog posts, talks even, and all), but they won't hire anyone to work with him.

In that blog post, there's a call to share the load but do it as free labor:

"Anyway, I'm largely writing this blog post in the hope that someone gets motivated enough to dive into this. Right now, if you get 50 patches into libinput you get the coveted second-from-the-top spot, with all the fame and fortune that entails (i.e. little to none, but hey, underdogs are big in popular culture)."

I believe if that position came with a Red Hat paycheck, finding a #2 wouldn't be such a problem.

Red Hat is part of IBM now. Another post on the homepage right now is "IBM to cut thousands of jobs as coronavirus plays out" https://news.ycombinator.com/item?id=23268191

Not saying that these IBM jobs are from the Red Hat part of IBM, but not the best time to hope they will hire more.

The blog post went out back when COVID-19 wasn't a thing.

It went out not too long after Red Hat became part of IBM. But now that that is the case, IBM's dividends, through whatever turns the world and economy take, may be more important to them than the small subset of their Linux offering that is the desktop.

Not that I want this to be true! I writing these comments from a laptop that I special ordered without even a Windows license since I planned to only run Linux on it.

You don't need to wait for Red Hat management to decide to do something, it's open source. If your company is a heavy user of libinput and isn't already paying for Red Hat subscriptions, then it's perfectly reasonable for your company to consider paying their own engineer to upstream some changes.

I work for Red Hat but not on that stuff and I'm not commenting as a RH employee (and have zero insight into how that area of the company works).

Red Hat doesn't make much if any money on desktop, yet as you mentioned RH does employ people to work on it. It's already largely a charitable service to the community. As much as I do wish they'd hire more people and make the touchpad amazing, it seems a little entitled to criticize them for not digging even deeper into the charity pockets.

First, I agree with you. Redhat has no obligations here, and if they did increase their "charity" contibutions there are several areas that could use help. That said, it's not charity. They have an interest in keeping the desktop useful for developers who also do some free work for them. I would also argue that making Linux a first-rate desktop operating system would be incredibly beneficial to Redhat/IBM. They also shouldn't be the only ones working toward that, so keeping it minimal might be a good way to get others to contribute - weather paid by someone or not.

You make some fair points. It's not pure charity since RH does receive indirect benefits from it, but I'd still say it's mostly charity. Maybe you have specifics in mind, but the "free work" I can think of (open source upstreams) is something that equally benefits RH competitors. It's more of a "rising tide lifts all boats" sort of thing. So while RH does receive some benefit from it, it still seems largely charitable to me.

RH doesnt really have competitors at the moment. None of comparable size anyway, and that's prior to IBM. Microsoft seems to be interested though.

Go big or go home?

> It's already largely a charitable service to the community.

Now that they have a deal with Lenovo to have Fedora preinstalled on their P-series laptops, I do think they have a vested interest in creating a market-worthy workstation OS.

I just hope people won't be writing in about it, "Nice try, but palm rejection on the touchpad sucks camel's balls!"

It‘s a Thinkpad, who cares for the touch pad /s

Related: The "linux touchpad like a macbook" discussions: https://news.ycombinator.com/item?id=23235609

https://bill.harding.blog/2020/05/17/linux-touchpad-prelimin...

https://github.com/sponsors/gitclear

Given how ubiquitous the capacitive touch senors have become I'm surprised no one has put together an open source option. I've gone down something of a rabbit hole searching and haven't found any prior work.

The closest I have seen is the Snowpad[1] but it's been discontinued by the maker and they pulled down the source as well.

I'd try duplicating it but it used the Microchip MTCH6301 and it's been marked `Not recommended for use in new designs.` I'm hunting for an easy to use alternative if anyone knows one. I may still take a stab at the MTCH6301 just because of how easy it looks to use.

[1][https://www.kitronyx.com/snowpad.html]

What does "Open Source" mean in this context? Isn't the goal "just" to have an understandable interface?

Also: Can you recommend some reading material as an introduction to using a capacitive digitizer? I am planning to use one in an upcoming project (either one from a tablet glass replacement or a stand alone one) and really have no idea what to look out for yet in terms of communication with my Linux board (bonus: Something about DIYing one because I need a special format, but I guess that's especially hard because it's supposed to go on to a screen).

Having a tidy interface is certainly a primary goal but there are others.

- Control over the size/shape of the sensor pad.

- Control over communication (i2c/spi/usb)

- Ability to explore gesture behaviors and expose simplified interfaces to the OS.

- Control over click feel/behaviors by customizing snap switch style, mount, and locations.

- Control over the touch surface finish. (Did you know you can laser cut glass screen protectors? Why are none of these touch pads glass outside of macbooks?)

- Open documentation on all of the above.

As for reading material I can't recommend anything as a summery (see my last bullet). Manufacture design guidelines are probably where you should start.

Case in point: MTCH6301: https://www.microchip.com/wwwproducts/en/MTCH6301 Microchip Sensor design guide: http://ww1.microchip.com/downloads/en/DeviceDoc/FAQs%20-%20S...

It's not just the sensor. I'd warn people trying to DIY from scratch to make sure you really think of the full gestalt of a touch / gesture experience which spans:

- Mechanics (a good surface, sensing)

- Robustly designed state machines to track states even before your finger lands.

- Math (to deal with finger acceleration, stabilization)

- Feedback! Mechanical clicking, piezo, weight actuation, etc. I cringe when I see projects lacking feedback.

As a teaser here's my messy breakdown of the macbook trackpad states, based on things done back around 2008/2009 (http://blog.sendapatch.se/2009/november/multitouch-on-unibod...):

    enum RawTouchStateOneValues {
        TOUCH_STARTED_STATE = 1,       // initial touch started state - i.e. first frame of a touch. warning on this state: StateTwoValues seem invalid here
        TOUCH_HOVERING_STATE = 2,      // multi-frame: typically occurs when a touch is about to land. 
        TOUCH_LANDED_ON_PAD_STATE = 3, // usually single-frame, but can occur multiple times if a touch hovers and returns (from state 6,2,1) - you can also go here from state 6, which means a hanging touch can 'return'
        TOUCH_ON_PAD_STATE = 4,        // typical duration of a touch - moving around on pad
        TOUCH_LEAVING_PAD_STATE = 5,   // usually single-frame - 
        TOUCH_LEFT_NOW_HOVERING_STATE = 6, // multi-frame: occurs when a touch occurred but then left pad (state 5), and is now hovering
        TOUCH_ENDED_STATE = 7          // single-frame: touch finally ends
    };

    enum RawTouchStateTwoValues {
        TOUCH_DETECTED_ALTSTATE = 0, //state only seems to occur on initial touch (stateOne's TOUCH_STARTED_STATE), which I filter out 
        TOUCH_RESTING = 1,
        TOUCH_NON_RESTING = 2,
        TOUCH_NON_RESTING_AGAIN = 3,
        TOUCH_THIRD_TOUCH = 4,
        TOUCH_EDGE_REGION = 5, //only observed on magic trackpad - seems to occur when starting at the edge.
        TOUCH_SIXTH_TOUCH = 6,
        TOUCH_GROWING_FROM_EDGE = 7, //both cases 12 and 7 seem be used for palm-rejection scenarios
        TOUCH_EIGHTH_TOUCH = 8,
        TOUCH_NINTH_TOUCH = 9,
        TOUCH_TENTH_TOUCH = 10,
        TOUCH_ELEVENTH_TOUCH = 11,
        TOUCH_COMING_FROM_EDGE = 12 //both cases 12 and 7 seem be used for palm-rejection scenarios
        
        //other states observed but unknown - 4 (seems to consistently occur when I have three fingers down. 
        //                                         likely occurs in certain pad regions)
        // 
    };

I personally think it's the hardware. I've run Linux on a MacBook Air 11 Late 2012 from the day I purchased the machine and it feels identical to macOS.

Luckily, for those using desktops who still want to use a trackpad, the Magic Trackpad works really well out of the box too. And there are not many other options in the market.

I used to prefer trackballs from Logitech, but current models are nowhere as smooth as those from the 1990s and early 2000s.

I agree that's a very large part of it. I have booted Ubuntu on innumerable PCs and Macs while working in repairs, and touchpads vary hugely even when running the same software. The recentish "Precious Touchpad" standard Microsoft has for PCs tend to work better in my experience, even under Linux.

As a former Mac user, I can also recommend whatever is in the HP EliteBook I'm using now.

Clearly meant "Precision Touchpad" …

It is most definitely not the hardware. Apple's macOS palm rejection and especially the crispness & smoothness of the gestures are unparalleled, and using the same touchpad on Linux feels like the touchpad has dropped down into some sort of safe mode where all the fancy extras have been disabled. I mean, its understandable, Apple has been developing this since the original unibody Macs of 2007 so they have nearly a decade of progress vs Windows or Linux touchpad developement, but acting as if they're on par is simply false.

I have a 13" MacBook Air from 2012, and found the trackpad terrible with libinput (around Ubuntu ~18.04). One example that I still remember: When you've started scrolling with two fingers on macOS, you can tap again with both fingers to "brake". The same gesture would trigger a right-click on Linux. Kinetic scrolling without a way to stop means that I've always either scrolled too far, or dealt with unwanted context menus.

I guess the problem is that nobody is generating revenue in a meaningful way with desktop Linux.

Firms running Linux on servers can pay their employees to contribute to open source.

But a peripheral input driver? Ubuntu had a shot at being "Desktop Linux" but it didn't pan out.

Especially when remote desktop on Linux is not very good. (I've only used VNC and XRDP) not to mention a lot of extra packages.

Its probably also because people are motivated to help out when they see work to be done. For me, my mouse and trackpad work just fine. I don't even know what I could work on with such a project. It all just works.

Go read Microsoft's mouse ballistics from way back, if you can find it, then use a mouse on any Windows desktop since XP for a week. Then come back and try a Linux or Mac with an actual mouse instead of a touchpad. You can fix that.

It's here: https://web.archive.org/web/20101222190833/http://www.micros...

Please, god no. If anybody really does implement this, at least be kind enough to leave the old behaviour behind a configuration switch.

This is the single worst input decision ms has ever made. The first thing you do is to turn that hellish thing of.

Windows has by far the best mouse input of any OS. What exactly do you want to turn off?

The acceleration (aka ballistics). I want 1:1 mapping of mouse motion to cursor. It is easy to disable on Windows though, just uncheck the "Enhance pointer precision" (award for the most misleading title because it actually makes precision worse).

It is annoying in other OSes that you have to jump through hoops to disable that stuff.

> "Enhance pointer precision" (award for the most misleading title because it actually makes precision worse)

I would argue that it does enhance the precision if it's correctly implemented. (I haven't used Windows in a decade, so I can't comment on that point.)

Example: on a laptop, move the cursor to the bottom left corner of the screen. In one very slow continuous swipe, drag your finger from the bottom left to the top right of your touchpad. How far across your screen do you get? In my case, I get only about 1/3 of the way across the diagonal.

Assume I have no acceleration feature on my touchpad driver. This means I have two options to make the touchpad usable. Either (a) I can get used to dragging across the entire touchpad 3+ times to get the cursor across the screen, or (b) I can turn the touchpad speed way up. Suppose I do the latter.

Now suppose my cursor is 10px away from some target and I want to hit that target with a quick movement on the touchpad. Because of the very high speed required by the previous change, my accuracy is greatly reduced. I have trouble hitting small targets with tiny movements on the touchpad.

On the contrary, acceleration gets me the best of both worlds. With one quick swipe, I can get the cursor all the way across the screen. This is the "expected" behavior most people have for a laptop the first time they pick it up. On the other hand, when I'm trying to hit a small target with a slow cursor movement, I have a much easier time doing that. This feels like "enhanced precision" to your average user - the cursor moves more slowly and accurately when I need it to.

Mind that you're replying to someone talking about using a mouse, and you're talking about using a trackpad.

Different input modalities deserve different affordances.

They aboslutely do. I've never really thought about it but this is obviously why a Mac trackpad feels smooth as butter but even booting into windows on the same hardware makes it feel awful.

I think that applies to mice, too. The ‘natural’ range of mouse motion is larger than for a trackpad, but not that much larger. The width of a typical mouse pad is about 8-10 inch, so if you use one, the range of motion is a bit smaller.

Apple’s Magic Trackpad is over 6 inch, the latest MacBooks have a trackpad of over 5 inch.

Mice don't have boundaries, trackpads do. The most awkward thing on a trackpad is initiating a drag and hitting an edge.

I think mousepads are mostly an artifact of pre optical & laser mice, if someone uses one today it's either because they have a glass desktop or they want wrist support.

> if someone uses one today it's either because they have a glass desktop or they want wrist support.

Or they just want a good surface where the mouse glides smoothly, without any rubbing or scraping or pits that affect tracking..

I've never had a desk that felt good without a pad. I imagine glass would be smooth as long as it's clean.

Your desk may have plenty of space, but arms do have boundaries. If you have to move your mouse a foot to move the mouse pointer to its destination, you’ll lift the mouse halfway through that motion, and if, on modern displays, you don’t have to move a foot, pointing at specific pixels becomes hard for lots of people.

Even the original Mac, with its 512 pixel screen width, had a setting that enabled mouse acceleration (fairly rudimentary. It doubled distance travelled when the sum of horizontal and vertical displacement exceeded 6 pixels).

I think the discussion is more about tuning the acceleration curve than about whether to have one or not, for both mice and trackpads. There probably isn’t a single answer that suits everybody, either.

I think a subtle acceleration effect may be worthwhile, but the actual acceleration curve is far too crude, and I too turn it off.

Acceleration works much better on trackpads though.

Unchecking "Enhanced pointer precision" doesn't disable acceleration entirely. Actually I doubt you would enjoy a 1:1 acceleration profile unless you have a very low resolution monitor.

Actually true 1:1 is very enjoyable. I use it on a 1920x1080 windows computer. You need some registry hacks to get it working.

I've tried 1:1 and it is awful. To get from one side of the screen to the other you have to move your entire arm all the way across your desk. Not very practical.

fair, although you can modify the DPI of your mouse to get it to where you are comfortable with the speed

I'm on 2560x1440. In normal desktop use, it's about 17cm to get from left to right edge. Roughly 400 dpi. For graphics work and gaming, I reduce my mouse's DPI further.

1:1 is all I ever wanted.

Because it makes the mouse input worse. I always turn it off.

I don't know from this comment on what side of the fence you are but plugging a mouse into a mac has always felt horrible to me, like I was mousing through mud, I would always feel like the pointer slowed down too early and then I would have to reach a long way to actually get to the target. May just be my muscle memory was attuned to Windows/Linux.

When I used a mouse on macOS, the first thing I did was install the Microsoft mouse drivers,[1] which had Windows acceleration curves built in as an option. Unfortunately they stopped updating them beyond 10.7 Lion.

Now I’ve just gone over to Apple’s trackpads for 100% of my cursor needs.

[1] http://download.microsoft.com/download/B/1/0/B109F931-70E2-4...

Yeah, I did the same, I always wondered if that was by design, like: "You don't need an ugly mouse next to your macbook, we'll make sure of that". But the touchpad was also indeed that good that I didn't feel I needed a mouse. Opposite on Linux/Windows where I love my external mouse. I'm a bit on the fence about what I prefer, Linux with mouse or mac with touchpad. Both (as in MacBook touchpad on my Linux laptop) would be nice...

Mouse acceleration has always been different on Macs, just like font rendering, keyboard shortcuts and menu bar position.

Apple is very opinionated about all the parts of User Interfaces (including inputs), it's great if you agree with their opinions.

I use Steelseries ExactMouse to get rid of that odd acceleration curve. It works for any mouse brand and it still works on Mac OS 10.13, maybe newer OS'es too.

https://downloads.steelseriescdn.com/drivers/tools/steelseri...

I have the same with the mouse, had to install http://triq.net/mac/mouse-acceleration to tune mouse acceleration to 2.3 (!). Now it is fine, though it forgets the setting every reboot (despite showing up as 2.3), so I have to touch the slider every time I restart. Fortunately that's not too often.

The mouse on Apple has been horrible since at least 2005 or so (and I haven't used older macs than that). Low update rate, laggy, imprecise. Windows and Linux have had it right for a long time, Windows probably since 2000 or so.

The trackpad, it's the opposite.

I absolutely agree, but it’s a personal preference thing.

Years ago I had this argument with a coworker, and I tried to take the position that the Windows curve is better for games. He politely disagreed, I implied that he was a casual gamer, and he gently told me of the year his Quake III team won the world championship. We spent the next while watching demo videos of him doing 360 noscopes with the rail gun against a target in the air.

I handily lost that disagreement.

My xinitrc starts with xset m 0 0. I want input from my mouse to map 1:1 to pixels. Nothing more.

(I think libinput breaks that -- or at some point did break it -- and I solve it by removing libinput. Coincidentally, I started having issues with my trackpad when someone somewhere made libinput the new default. I fixed that by removing libinput)

I think you can still achieve the same using xinput to set the appropriate accel profile and speed. (And coordinate transformation matrix should be identity matrix)

I'm not clear on what exactly you're advocating. If it's just pointer acceleration, Linux operating systems have that already. Every input driver I've ever used on a Linux laptop (for over a decade) has supported it. It works very well - it would be difficult to use a touchpad on a typical laptop otherwise.

Is there something else you'd like to see?

I boot between Windows and Linux every day, same hardware (logitech G703 mouse)

I have never even noticed a difference, let alone registered a preference.

I think it's better to simply buy a very high resolution laser mouse (which are commonplace now) and map sensor displacement to screen displacement in a trivial linear way.

This is what I did, originally for gaming, but now I can't imagine gong back to mouse acceleration. A DPI button on the mouse lets me quickly toggle the sensitivity if I need more or less control for a particular task.

Yep. There is a reason why everyone plays FPS games that way, and it applies just the same to the desktop

This! X11 "synaptics" driver seems to be very high quality already. Personally I really like the great amount parameters that can be tuned. Why do we need jet another duplicated effort like libinput?

> Why do we need jet another duplicated effort like libinput?

That's the mentality of the Freedesktop-Redhat-Gnome-Poettering-Wayland-whichever-comes-next crowd.

Take a piece of software that's been working for years and fulfils pretty much every need (after a couple of decades of bug fixing and feature completing), declare it deprecated, and propose/impose a replacement that you push as 'better'. Better for what, in which way? It doesn't matter, just say it is 'modern' and the present system if a messy pile of cruft. Don't forget to make 1 or 2 blog posts which will be pasted as the definitive authoritative reference on the subject each of the 1000 time someone raises a problem with the new tool or its approach.

If you want to make the tactic more efficient, first become the handler of the present system and then 'actively' stop maintaining it and refuse to add the few features that new usages may demand, so that that you can justify your claim of deprecation.

Then you just have to spend 10 to 15 years getting your brand new toy to an equal condition as the former, and achieve feature parity. When you are done, the super lean and clean model you advertised 10 years before has become the same kind of old farts' mess you ranted against, sometimes more messy because you started by actively fighting against the extensibility which, according to you, was the root of all the mess in the older tool, in order to impose a clean, reduced set of functions, so you had to resort to dirty hacks to add the requested functions. After boasting the first couple of years from conference to conference, don't forget to whine all along the next decade when real and boring work and rework has to be done to reach feature parity.

Then, you're finally done, pick another part of the ecosystem (that users had voluntarily picked because they like it or because it was doing the job well for their use case) and repeat the same procedure.

I believe libinput's and synaptic's maintainer is the same person, and he started libinput because the synaptic codebase was a mess without tests whatsoever. I'm also using synaptics btw, as libinput gives me physical pain ...

What your saying is consistent with your parent's hypothesis. Compare GP's

> declare it deprecated, and propose/impose a replacement that you push as 'better'. Better for what, in which way? It doesn't matter, just say it is 'modern' and the present system if a messy pile of cruft.

with your's

> the synaptic codebase was a mess without tests whatsoever

Is there some other explanation that would please you? I am trying to parse that GP post for an argument and I can't find one. Your old drivers are all still there, they're not going away. You can continue using them but it would be wise to remain aware of the associated caveats, in this case, that the synaptics driver is unmaintained, hard to test, and is at a large risk of having regressions introduced after any changes.

There is a pattern of deprecating working software and trying to replace it with experimental stuff, with the design of that experimental stuff often being oriented largely toward less-technical users, with some detriment to old/power users and the ecosystem in general. For example, Wayland compositors, unlike X Windows window managers, are complicated to implement and on top of that the Wayland protocol standardizes little. This hurts the Wayland compositor ecosystem (again, as compared to X Window managers), and the lack of standardization hurts users directly, too (because then we have to rely on compositor-specific features, thus being tied to that compositor implementation). Last time I looked there still was not any prevalent solution to injecting or logging input events, and even capturing the screen (screen shot) was dependent on the specific compositor implementation. Remember the excuse for ditching X Windows? It was X having too many extensions to the standard. But even that is better than not standardizing on expected features at all. (I know the Wayland folks excuse a lot of that stuff with "security", but that is just security theater as their security model does not makes sense. If two Linux processes are owned by the same user there is no point in restricting what one can know about the other.)

EDIT3: also see the section on this ArchWiki page: https://wiki.archlinux.org/index.php/Wayland#Input_grabbing_...

Edit: also, even breakage for users that can be fixed by adapting to the next technology (e.g., evdev -> libinput, or X Windows -> Wayland) still costs users time.

EDIT4: Note that I am not saying X Windows is "good", but the fact is Wayland's design is hostile to a lot of things that work with X Windows, instead of Wayland improving on X Windows. So how could I be content with Wayland possibly replacing Xorg?

Hutterer is surely not some evil genius nor is he part of a conspiracy; but I think that Red Hat's (or, now, IBM's) business model indeed may present some adverse incentives to software maintainers: I think Red Hat's main source of revenue is from support, but they deal in open-source software - which should be (in principle), and actually is, much easier to modify, adapt, fork, just plain use without paying Red Hat. Thus it it is necessary to have almost all relevant software maintainers on your payroll, but that is not enough, to protect their business their software needs to be "safe" from forks, that means making it unnecessarily (from a technical standpoint) complicated and reinventing everything so only your employees are familiar with the code. I am sure Red Hat employees would let the technical and power user perspective prevail given a sufficient and independent cash source, but alas, they are in IBM's employ and don't want to get fired and do want a periodical raise; so it is hard for me to believe that they don't do what is good for their employer's business.

I am not comfortable airing speculation like this given that some people will feel hurt, but I am in real fear for open-source and Linux (because, what could I use instead ...), so there's my opinion. EDIT5: my child commenter correctly pointed out that my speculation about programmers employed at companies with certain business models is FUD-y, because of the lack of evidence and appeal to fear. I guess the only thing I can say about that is that my fears are honest, I am not aiming to harm Red Hat or anybody I just observed a pattern, but have no proof, of course. Otherwise, aside from my "FUD", the core idea I was trying to get across was to think about how the design choices in creating open-source software or protocols that have the potential to become monopolistic may affect us as users. I.e., please do not accept breakage just because of some undefined "modernity", as a lot of people in fact do. Also, I think there may be some systemic societal problems that I am not smart enough to propose a solution to if Red Hat is really bad for open-source. In other words, maybe another open-source business model is needed?

EDIT2: I rambled too far off the primary topic here (libinput), so let me just say that libinput very well might be the best we can have given the requirement to support both mices and other, less efficient, input devices; and also both X Windows and Wayland. Not that I'm happy about those requirements, obviously.

>There is a pattern of deprecating working software and trying to replace it with experimental stuff

This is par for the course. Open source does not have any warranty, it can break or be deprecated at any time. I don't care to discuss Wayland right now, if you don't want to use it you don't have to.

>If two Linux processes are owned by the same user there is no point in restricting what one can know about the other.

This is wrong on several levels. For example, namespacing and SELinux policies still work even when processes share the same user, and there are valid reasons why you would want to do that.

>I am not comfortable airing speculation like this given that some people will feel hurt, but I am in real fear for open-source and Linux

Please do not allow yourself to succumb to FUD that is spread on social media. This type of speculation comes up constantly in these threads and it's completely unfounded. Sorry. It's open source, anyone can pay for support/warranties for it from any company that they like, or you can not pay for support from anyone at all. It's your decision.

> This is par for the course. Open source does not have any warranty, it can break or be deprecated at any time. I don't care to discuss Wayland right now, if you don't want to use it you don't have to.

There is no relation between open-source licensing or culture and careless breakage. Even if there was, what would be the justification for it (Red Hat's behavior).

> This is wrong on several levels. For example, namespacing and SELinux policies still work even when processes share the same user, and there are valid reasons why you would want to do that.

I know about cgroups, namespacing, SELinux and how they could hypothetically provide other means of privilege separation than users and groups already provide; but I don't see how that applies to Wayland. I doubt anyone has actually set up a system with sandboxed untrusted processes in a way that would justify the Wayland security model. The way I see it, Wayland will over time gain even more extension protocols than X Windows has to accomodate things that were not thought out during the design phase. I also doubt the user namespace implementation in the kernel will be solid enough for secure usage for many years. Or that compositor and application programmers will understand the security implications of their software on the possible security models well enough for users to actually have a usable and feature-complete system where the Wayland-implied security model could shine.

>There is no relation between open-source licensing or culture and careless breakage.

There is no relation between open-source licensing or culture and working software either. Go take a look around on github and you will see tons of broken, outdated and unmaintained software. (I am not saying there is anything wrong with this, eventual death is a fundamental part of any product lifecycle)

>I doubt anyone has actually set up a system with sandboxed untrusted processes in a way that would justify the Wayland security model.

There already is one, called Flatpak.

> There already is one, called Flatpak.

I said "a system", making a sandboxing program like Flatpak is the easy part. Also, why is it that neither https://flatpak.org nor https://github.com/flatpak/flatpak mention security or "secure"? I think that is because Flatpak is not meant for running untrusted/malicious processes (without using additional protection; such as a virtual machine, another OS user, or another physical machine). I am not sure why that is, but it may be because, as I said, it is simply too complicated to think through everything while satisfying relevant security models, or because Flatpak programmers know that for real security you do not want user namespaces in your Linux (attack surface increase, etc.).

Also, even if Flatpak and the kernel were perfect, if you want to sandbox a complex application with only Flatpak; using the app and configuring its sandbox would then be an impractical nightmare for either administrators or users. See the article linked here about the problems with Flatpak-sandboxing complex real-world programs: https://news.ycombinator.com/item?id=18180017.

And this comment is also informative: https://news.ycombinator.com/item?id=14409234

Basically, for real secure and robust sandboxing I think one needs to use the Chromium setuid + seccomp + multiple processes approach. This implies thinking about security while designing the program, and it being open-source; so it is only applicable to trusted software that deals with untrusted data, or executes Javascript or something. So, if a program is designed with security in mind (e.g., Chromium), Flatpak provides nothing beneficial. On the other hand, if one needs to execute real-world untrusted software, it again seems it is necessary to use another user account or another machine.

Sandboxing is part of an overall security solution and also has other uses besides security. And as you know there are many other parts to securing your system. Of course if you already implement sandboxing yourself then you probably don't need to use Flatpak to make security guarantees.

I think you have made a lot of wild assumptions from reading those posts you linked, and those assumptions don't apply to everyone. Regardless of your feelings on Flatpak/Wayland in certain applications, they are being used for security purposes right now. The Chromium security model also makes a lot of assumptions and only applies to certain applications.

Just out of curiosity, do you have to completely force removal of libinput and then add synaptics, which will replace everything libinput did? Because last time I tried it, libinput had so many dependencies, it wanted to remove the whole desktop environment.

I think one would just change the precedence of relevant Xorg configuration files (in xorg.conf.d directories).

No, I remember having just used something like "sudo apt-get install synaptics" on Debian/Ubuntu.

A pattern definitely appears to exist ;)

People complain about Systemd the most; but I fear Wayland more, it will be horrible for power-users if it pushes out X Windows.

Care to explain why you think so?

Wayland is trouble for users who

* do not want just the big Windows-like inefficient and bloated Gnome and KDE desktop environments. And also for those that like or need having various "desktop environments" to switch between.

* like to programmatically grab and inject input events. I.e., AFAIK you will not be able to implement atbswp for Wayland environments using pure Wayland, if at all. Even if you do succeed (by depending on a Wayland extension, working with specific compositors or talking directly to the kernel), it will be more difficult than for X Windows.

Quoting my comment from this thread, near yours:

> Wayland compositors, unlike X Windows window managers, are complicated to implement and on top of that the Wayland protocol standardizes little. This hurts the Wayland compositor ecosystem (again, as compared to X Window managers), and the lack of standardization hurts users directly, too (because then we have to rely on compositor-specific features, thus being tied to that compositor implementation). Last time I looked there still was not any prevalent solution to injecting or logging input events, and even capturing the screen (screen shot) was dependent on the specific compositor implementation. Remember the excuse for ditching X Windows? It was X having too many extensions to the standard. But even that is better than not standardizing on expected features at all.

> Note that I am not saying X Windows is "good", but the fact is Wayland's design is hostile to a lot of things that work with X Windows, instead of Wayland improving on X Windows. So how could I be content with Wayland possibly replacing Xorg?

Also see these (sub)threads:

https://old.reddit.com/r/wayland/comments/85q78y/why_im_not_...

https://news.ycombinator.com/item?id=20376316

https://news.ycombinator.com/item?id=20379423

What about Steam? They certainly need inputs drivers to play games.

Well I think the weakness in Linux is mostly touchpad, which isn't ready a gaming thing. I think.

Libinput isn't just for touchpads though, it's an abstraction of input devices for wayland compositors (even if it's also available for Xorg).

Try TurboVNC - it's usable enough for me to use all day long to do typical devops things remotely. Sure, there's a little input lag, but by and large it does a good job. There's multimonitor and OpenGL acceleration in there now, too.

> Especially when remote desktop on Linux is not very good. (I've only used VNC and XRDP) not to mention a lot of extra packages.

You mean using linux to connect to remote PCs? What are the issues you are facing?

I've been happily using remmina (it does use something else for the actual RDP connection IIRC) on Ubuntu to connect to headless Windows box via RDP for CAD/ECAD work for the last year or so.

The windows box is in local gigabit network though.

Oh no the other way around.

Having a remote Linux box that I want to get a remote desktop into.

Remmina is really good, I agree.

Back then I simply used x forwarding from ssh. It felt snappy and native enough, assuming your bandwidth and latency is good enough.

Try NoMachine or Teradici, both of these are getting a lot of use in Film & TV post production where are alot of artists work on Linux workstations running Nuke or Flame or Baselight.

ThinLinc is freeware for most small users; it is good enough for 3D design work (think Blender) on the remote Linux host and has multiplatform clients. It's a modified version of turbovnc with, imo, a moderately enlightened company behind it.

I have used NX for this in the past.

Also there is a serious problem: It is often not fun at all.

Abstracting hardware as an open-source API is definitely a more painful job then other kind of projects like a web project. It's because you have absolutely no control over how the hardware works, and each hardware vendors work differently.

The worst moment is when the maintainer receives a reaction like this: "Oh it doesn't work on my hardware. Plz fix it". How the hell to fix it when the maintainer doesn't have the hardware? But there are people complain and criticize that the maintainer doesn't do the job for them. You can easily see these kinds of cases in desktop related project like Sway Wayland compositor. (mainly because of Nvidia of course.)

> It's because you have absolutely no control over how the hardware works, and each hardware vendors work differently.

Replace 'hardware' with 'browser' and you are in the same situation.

As someone with a degree in embedded systems engineering, I have a lot more sympathy for hardware quirks than browser quirks. Hardware can't easily be updated, browsers can.

> It is often not fun at all.

I'd rather spend weeks researching a hardware bug than spending hours on SO to find CSS hacks to make some browser render my page properly.

> I'd rather spend weeks researching a hardware bug

I would too, but only if it is my hardware. But for other guy's hardware who want to use your project? I will loose an interest if it is a free job.

At least web browsers work in the same way in many cases. Of course there are some cross-browser incompatibilities but workarounds are not as hard as hardware.

I skimmed through the issues at https://gitlab.freedesktop.org/libinput/libinput/-/issues

I wondered how a single person can verify, fix and test issues related to touchpads on a number of different laptops. Either Hutterer has a room filled with hardware or the people opening the issues become testers of the fix.

I looked at the closed issues and it's probably the latter case. This means that there is an extra filter compared to the Linux projects I raised issues to: know about issue trackers, find the issue tracker, be able to test a fix.

On the software development side, this looks like a difficult project to keep running because the interactions with so many occasional testers.

Having worked with Peter, he indeed has a room full of laptops (Red Hat mails them to him every time they run into a customer issue!), but it's still a lot of work to test all of them and new laptop models get cranked out every day. It's a very difficult task for a single person.

It has happened twice during my career that a colleague got actually, literally hit by a bus.

Both of them were back at work after a week, one of them had problems with their arm for a while longer but this risk is way overblown.

It's a metaphor to illustrate than someone can suddenly disappear. It can be a bus, a plane crash, a murder, jail time. It happens once a while.

Of course. I just thought it was funny how it turned out in reality. Don't get hit by a bus, you'll be the butt of programmer jokes for years.

I think you would have got a different reception if you didn't include the "the risk is way overblown" bit. Up till that point, yeah it's morbid but funny. After that point it seems even confusing - how can this person not realise the bus number is not meant to be taken literally?

But yeah, I don't even walk out in front of vehicles that I'm not certain will stop when I have a green light and they have a red light. This surely pisses some drivers off when I stop in the middle of the road waiting for them to stop. They seem to be like "I'm not going to kill you and I'm offended you act like I will".

When I'm creating hypotheticals which test our project's resiliency, I prefer to imagine my colleagues suddenly deciding to retire early and travel the world or something like that. But "sudden early retirement factor" doesn't quite have the same punchiness as "bus factor".

Unfortunately jail time has an outsized effect, look at Hans Reiser. That incident pretty much killed reiser4, which was on track to become a very popular filesystem for Linux, despite having 10s of developers working on it.

It didn't helped that the system was named after him.

> a murder, jail time

Obligatory: https://en.wikipedia.org/wiki/Hans_Reiser

We have been instructed to use the phrase "lottery factor" during our cynical rants. Everyone feels much better. I guess it's because of the "if I won the $70 million jackpot I'd just come back to work" meme.

I'd buy a bus with my winnings and put the lottery factor into effect for my former coworkers.

The problem with the "lottery factor" is that if someone wins the lottery, you can still theoretically go to their new mansion with a wrench and beat the information out of them.

Or, more commonly, and at my work, they leave the company with 1 months notice and there isn't time to do proper handover of the plethora of projects they babysit. Whoever picks it up ends up learning everything from scratch and stale documentation

I've found that this article was really illuminating with respect to some of the issues around `libinput`: https://lwn.net/Articles/801767/

When I read about this stuff a part of me says "why does this stuff keep getting rewritten?" I was using Xorg years and years ago and never had any kind of input issues.

Example from the lwn article:

> The xf86-input-evdev driver is in maintenance mode at this point. The last commit was in May 2018 and, since the 2.10.0 release four years ago, there have been a total of 19 commits.

Maybe that's actually a sign that it's good enough and doesn't need major adjustments? But here it is presented as if it is a problem.

It's probably fine for keyboards and regular mice, but touchpads are... well... touchy. I've never had reliable palm rejection on a touchpad under Linux. The situation with kinetic scrolling is ridiculous (to be fair, Hutterer has decided that sort of thing doesn't go in libinput, because it doesn't have enough context to implement it properly, which I agree with). Drag-and-drop on a touchpad has poor UX, and god forbid you need to drag with multiple fingers. Even two-finger and three-finger click (right and middle click, respectively) are unreliable at times.

I say this not to criticize, but only to point out that the driver is not "done". I am incredibly impressed with Peter Hutterer's skills that things work as well as they do, given that he's essentially the only person working on it. It could use more eyes and hands.

You seem to be in agreement that keyboards and mice driver is, indeed, done.

Yes, that's... what I said. But xf86-input-evdev also handles touchpads. xf86-input-synaptics, the other driver mentioned by TFA that is either unmaintained, or done, depending on your point of view, is definitely for touchpads. They're certainly not "done" when it comes to touchpads.

Perhaps the solution should have been to split the touchpad specific bits and focus on that and leave the keyboard and input code alone instead of wasting time to rewrite code that works? It sounds like they made their life harder for no reason.

> I've never had reliable palm rejection on a touchpad under Linux.

I'm curious what hardware and drivers you've tried. I'm using a fairly large Synaptics touchpad on a Dell laptop with the xf86-input-synaptics driver. It's so good that I literally had to test it just now to see if it was possible to fool it at all. Even very light touches with the edge of my palm are unable to convince the driver to click. I can't move the cursor at all. At least in my case, it works perfectly... maybe I'm just lucky. (Or maybe the new libinput driver is still not up to snuff.)

For drag-and-drop I usually press down with my index and hold, than drag with the middle finger. This has been working flawlessly on Macs since forever. It also works on a T480s with Ubuntu right now. But I remember being frustrated with my touchpad before, so it probably didn't work on Ubuntu at one point.

> The situation with kinetic scrolling is ridiculous (to be fair, Hutterer has decided that sort of thing doesn't go in libinput, because it doesn't have enough context to implement it properly, which I agree with).

Unless he's planning some way to get that context and implement it later, that pretty much makes libinput unusable for me. Relying on every individual program to implement their own kinetic scrolling guarantees it'll act differently across all of them - or just be nonexistent, as is the case now.

IIRC, the one bug introduced by the synaptics way of handling it is if the mouse is moved from one window to another during the period while it's still scrolling, it then scrolls the newly-focused window instead. This annoyance is so extremely minor I simply do not care.

A lot has happened since "years and years ago", for example smartphones (touchscreens), and more advanced functionality for laptop touchpads being introduced by vendors.

It is probably because Hutterer was also one of the maintainer of xf86-input-evdev, xf86-input-synaptics and now libinput. (AFAIK)

Ok, now I see why there is so less (or basically none) progress on my feature request of having mouse wheel acceleration (since 2010, even with a patch, https://bugs.freedesktop.org/show_bug.cgi?id=29905 and https://gitlab.freedesktop.org/xorg/xserver/issues/405 and https://gitlab.freedesktop.org/libinput/libinput/-/issues/7).

this fits my theory that the average bus factor is ~1:

https://anarc.at/blog/2019-10-16-bus-factor/

Cynics have also suggested the average is closer to zero, but I still have hope that we at least need buses for a catastrophe to happen. ;)

> Lobby governments and research institutions to sponsor only free software projects.

Good idea!

It's too bad that such important pieces of the Linux desktop are so underfunded and neglected, though I can understand there just isn't enough revenue for even Redhat, Suse, etc. to justify hiring more developers.

But with all these little issues that cause problems for individual users on all the different scrollpads and touchpads and other non-standard hardware, nobody knows the true harm it may cause and how many users decided to get a Mac or even Windows because some esoteric hardware they owned just wouldn't work, but could have been fixed with just a small patch had the developers been available. This will become even more true as WSL2 becomes a more viable alternative.

Personally, my 'jumpy' touchpad on a new Dell Latitude I'd purchased a few years ago was my final straw in using Linux for development work. It was nearly useless with several different distros without an external mouse, and after getting used to Macbook's touchpad, I just couldn't rationalize using Linux when the touchpad is something I use so much.

Fonts are another one of these issues that I think could be solved more easily than even a few years ago - several important patents have expired and Google and others donated very high quality fonts to the community. Unfortunately, there just isn't the amount of paid developers working to ensure that things look good out of the box on every monitor, and so fonts often look horrible, especially to new users who are coming from Mac and Windows, where the issue was solved by full time UI experts a decade ago.

If I may ask, why do you care about your touch pad? At least for me, it pains me to use a touchpad while knowing I could interface with the computer faster with a mouse.

BTW, the jumpiness is probably configurable, see https://wiki.archlinux.org/index.php/Mouse_acceleration

For example (if you want to use X Windows), when I do

  xinput list

I get

  ...
  ⎜   ↳ ETPS/2 Elantech Touchpad                  id=15   [slave  pointer  (2)]
  ...

and then I would do

  xinput list-props 15

and play with "Coordinate Transformation Matrix", or "libinput Accel Speed" for speed and acceleration.

Anyone know of a site that tracks bus factor for open source software projects? Would be useful in seeing where vulnerabilities are and where financial support is needed.

I suppose Github and other repositories would be an ideal place to do that since they already have visibility into commits.

The bash shell is maintained by a single unpaid volunteer.

That's good. So there is a high chance this project is high quality.

Also previous experience burned him, when he said yes way too often. What if Stroustrup would not have been that notorious yea sayer?

It's not good if the author of the project himself is raising this issue.

> What if Stroustrup would not have been that notorious yea sayer?

Perhaps we wouldn't have to deal with C++ in the first place? His tactics were part of what made the language popular.

Agreed. C# had for a short time higher momentum. C++ is okay, just the hodgepodge of weird and abnormal syntax decisions did long lasting harm. Got much better recently though.

Syntax isn't even the worst thing.

Eg they still import modules via (automated) copy-and-paste.

As I have asked a few coworkers, sometimes repeatedly, over the years:

Do you have a bus number of one because nobody cares, or because nobody cares enough to put up with the code (or worse, you).

You have to entice people in sometimes, and many of us are great at other things but terrible at this.

Are those the only two options? What about because everybody is already stretched thin and worried about covering their own self for performance reviews in a few weeks?

If nobody cared wouldn’t it be zero?

I've gotten trapped taking over a project/tool that 'needed to be done' but nobody wanted to do it.

The worst one, my recommendation was to get rid of it and do something else. I worked on making it more approachable but it was slow going and thankless work, as the previous maintainer had tried to do (he swapped out a grammatically unsound DSL for a set of functions and macros in Python)

When I had succeeded in getting the bus number on my other responsibilities above 3, I left. And this is when one of my coworkers noticed that all but one former team member were associated with this code when they left, so maybe we should listen.

I think the takeaway from this is sometimes it's you, sometimes it's the situation, but unless you change something, nothing will change. And even if you do change something, you can't always win. I strongly believe starting over is the last resort, but it is a resort.

Or maybe because it works well enough that nobody feels the need to pitch in and fix it? It looks to me like the reward for good work is more work here.

And the people who think it's everyone else who has the problem, not them, bristle when you bring it up.

Reply on news.ycombinator.com