Hacker News Reader

Comment by Jonnax | Hacker News Reader

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.

View on HN

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

> 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.

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.

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 have used NX for this in the past.

Reply on news.ycombinator.com