Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux touchpad: preliminary project funding, survey results

bill.harding.blog

Post reply on HN
Print view View original

61–70 of 174 posts

Re: Linux touchpad: preliminary project funding, survey results

#61

Post by viseztrance »

WalterGR wrote: post #52
viseztrance wrote: post #32

I can hardly tell the difference between my razer stealth linux touchpad and my workprovided macbook. Even based on the feedback, it seems that most people are okay with their touchpad experience and are more interested in advanced features like multitouch. Having this said, for myself this is a tough sell. I'm concerned that I would donate and I won't be able to tell the difference between this and some placebo driv…

I can hardly tell the difference between my razer stealth linux touchpad and my workprovided macbook. How much of the surface of the Linux touchpad is clickable? I.e. how much of it depresses when you press on it, vs. the MacBook? I’ve never seen a non-Apple touchpad that didn’t have a big dead zone in the back (closest to the display) 1/4 to 1/3 of the surface.

Well, I'm using tap to click which is what I prefer.

On the macbook pro I'm using clicks because tapping doesn't work as well as reliably, for example tap and drag.

Later edit - I tried comparing the clickable area, and indeed, the upper region is not clickable on my razer (TIL). I realized this only just now, because this not how I usually use touchpads.

Re: Linux touchpad: preliminary project funding, survey results

#62

Post by zozbot234 »

cycloptic wrote: post #60
zozbot234 wrote: post #18

Earlier quoted context omitted.

> If OP were to create a pipeline which: ... That would solve the problem. The libinput project and pipeline was developed as a way of pursuing these goals, but it doesn't even have all the features of the legacy synaptics driver. It's not hard to see where the work should be going: start with bringing libinput up to feature parity (and fork the project if maintainers won't accept your changes upstream), then go furt…

Forking libinput is unwise and would likely not be productive choice. The maintainer of libinput and the synaptics driver are the same person, and he has blogged several times about why the synaptics driver was a mess and was impossible to test and maintain. https://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-...

First of all, whether a "hardware database" is a better place for a device-specific option than a "config file" is just semantics; what actually matters is that supporting device-specific quirks should be straightforward for the end-user. As for user-facing options, if the maintainer thinks they are 'too expensive' to maintain in the code, that means the existing architecture of that code is misguided and should be refactored.

Re: Linux touchpad: preliminary project funding, survey results

#63

Post by sitkack »

edjrage wrote: post #40
sitkack wrote: post #12

Earlier quoted context omitted.

Says the guy using a Mac, the best touchpad within 5 parsecs.

Actually such an aggressive response (from the GP, not you) is precisely the kind of thing I'd expect from someone who has an easy life. I live in pretty crappy conditions, including a crappy computer with crappy touchpad drivers. I just refuse to let such mundane things give me hypertension.

I have an old X1 Carbon that I use at the grunge travel laptop, like throw it in the backpack in a paper bag and go for a hike level of grunge.

Its trackpad is junk, phantom movements, zero palm rejection. I coded up some lock scripts so that it locks out the buttons if the cursor is moved. I fantasize about DeepTrack, the AGI that will finally give me trackpad bliss on a Linux desktop.

Re: Linux touchpad: preliminary project funding, survey results

#64

Post by cycloptic »

zozbot234 wrote: post #62
cycloptic wrote: post #60

Earlier quoted context omitted.

Forking libinput is unwise and would likely not be productive choice. The maintainer of libinput and the synaptics driver are the same person, and he has blogged several times about why the synaptics driver was a mess and was impossible to test and maintain. https://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-...

First of all, whether a "hardware database" is a better place for a device-specific option than a "config file" is just semantics; what actually matters is that supporting device-specific quirks should be straightforward for the end-user. As for user-facing options, if the maintainer thinks they are 'too expensive' to maintain in the code, that means the existing architecture of that code is misguided and should be r…

It was already refactored, into libinput. The issue with testability is not about the code being badly architected. The fact is if you have 100 config options and 1000 supported hardware devices, you must test all possible options and now your test matrix has something on the order of 2 ^ 100 * 1000 cases to go through. This combinatorial explosion is unsustainable.

I personally disagree that device quirks should be straightforward for the end-user. The end-user shouldn't even care about this, the point is to make it so they don't have to mess with config files or a hardware database at all.

Re: Linux touchpad: preliminary project funding, survey results

#65

Post by NikolaNovak »

edjrage wrote: post #42
ghostpepper wrote: post #25

Earlier quoted context omitted.

I also spend many hours per day on the computer, both for work and leisure, and for this reason I have invested money and time finding high quality: chair, desk, monitors, headphones, mouse and keyboard. I understand that not everyone has the luxury of space for a full WFH setup but I can't imagine doing 8-10 hours per day with only a 14" laptop at the kitchen table. This is why, for me, a Mac quality trackpad experi…

Interestingly I've been using a 12" laptop as my daily driver with a crappy chair, desk and earbuds and no monitor for over two years and I've had no cardiovascular problems so far. Stressed people are quick to blame their environment (tools and whatnot) but fail to take a hard look at themselves.

Age?

:->

Re: Linux touchpad: preliminary project funding, survey results

#66

Post by abhorrence »

abrowne wrote: post #54
WalterGR wrote: post #52

Earlier quoted context omitted.

I can hardly tell the difference between my razer stealth linux touchpad and my workprovided macbook. How much of the surface of the Linux touchpad is clickable? I.e. how much of it depresses when you press on it, vs. the MacBook? I’ve never seen a non-Apple touchpad that didn’t have a big dead zone in the back (closest to the display) 1/4 to 1/3 of the surface.

Do you click with your "aiming" finger? I usually have tap-to-click turned on and do tap that way, but on any touchpad, MacBooks primarily until recently, I always click with my thumb on the bottom quarter, where older touchpads had a separate button. Is this only because I started on those old-style touchpads?

I started on trackpads with the separate buttons, but now click with my index finger. I’ve found that the longer I’ve used the MacBook touch pads (and especially since they went fully non-mechanical) the more I dislike other touch pads.

Re: Linux touchpad: preliminary project funding, survey results

#67

Post by zozbot234 »

cycloptic wrote: post #64
zozbot234 wrote: post #62

Earlier quoted context omitted.

First of all, whether a "hardware database" is a better place for a device-specific option than a "config file" is just semantics; what actually matters is that supporting device-specific quirks should be straightforward for the end-user. As for user-facing options, if the maintainer thinks they are 'too expensive' to maintain in the code, that means the existing architecture of that code is misguided and should be r…

It was already refactored, into libinput. The issue with testability is not about the code being badly architected. The fact is if you have 100 config options and 1000 supported hardware devices, you must test all possible options and now your test matrix has something on the order of 2 ^ 100 * 1000 cases to go through. This combinatorial explosion is unsustainable. I personally disagree that device quirks should be…

> The end-user shouldn't even care about this

They may want to care because not every device will be in the hw database at the outset. Or the existing description may be incomplete, and fail to account for something that libinput supports. Good hardware support starts from users "scratching their own itch" by experimenting with "advanced", less-strictly-supported options to reach the best combination for their hardware, and perhaps their niche use cases. Testability is a red herring because only a few advanced options will ever be applicable; the issue is that they're different options for different cases.

Re: Linux touchpad: preliminary project funding, survey results

#68

Post by dmix »

Looks like the number of contributors have doubled since this post hit the frontpage.

That's great, this is one of the few things left that held back Linux desktop, and it wasn't even that bad with some tweaking but it shouldn't need tweaking. Gnome has made drastic improvements in recent years as well.

Now if only companies would fund proper open source graphics drivers then there would be no reason for developers to not use Linux. Otherwise you need to buy a laptop with Linux in mind and you'll be fine.

Re: Linux touchpad: preliminary project funding, survey results

#70

Post by wegs »

WesolyKubeczek wrote: post #58
wegs wrote: post #16

Earlier quoted context omitted.

Well, let me put it this way. I would donate $250 to fix it. I think that's how much working support for touch, trackpad, and pen input would be worth it to me. I would donate $0 for a stranger on the internet to try to fix it themselves. I would donate $0 and advise others not to donate with an approach where there isn't even a developer driving this themselves ("Give us money, and we'll hire someone to fix it" appr…

> With open source, it's easy to find people to do the fun, modular bits (acceleration curves, palm rejection, etc.). If that were true, there wouldn't be crowds of people telling that palm rejection in Linux sucks balls. Seriously. As someone who did dabble in libinput for my own needs, I probably qualify to tell you where exactly you can shove your $250 and your condescending ignorant attitude, and how deep you can…

>> With open source, it's easy to find people to do the fun, modular bits (acceleration curves, palm rejection, etc.).

> If that were true, there wouldn't be crowds of people telling that palm rejection in Linux sucks balls

Reading comprehension. Or intentionally selective misquoting. I'm not sure which one.

I said: "Provided clean, simple, documented, pluggable APIs where people could tinker around with the fun stuff (anyone can make a new algorithm in Python and see it work in 5 minutes)"

Point me to that, and I'll eat my words. My claim is that IF you provide all the plumbing and infrastructure, people will do the fun stuff. Plumbing isn't fun, though.

In either case, I don't think an inability to read "qualifies [you] to tell [me] where exactly [I] can shove [my] $250 and [my] condescending ignorant attitude, and how deep [I] can shove it, too, along with the horse [I] rode in on." It qualifies you for remedial third-grade reading classes. :) I highly recommend them.

I think I'm perfectly qualified to decide where to spend my own money, and it just went to DIGImend.

Post reply on HN