3 ms·
I don't think this is as much about Red Hat not caring as it is people in general not caring. This issue is affecting many ThinkPads. I've seen it on T25, T470
by Liskni_si 6y ago
I don't think this is as much about Red Hat not caring as it is people in general not caring. This issue is affecting many ThinkPads. I've seen it on T25, T470 and T440p, which happens to be the most popular laptop of /r/thinkpad these days as it's easy to take apart and switch components, and as we've seen in this thread it affects many other ThinkPads as well. So we're talking about thousands, possibly tens of thousands of hackers having a suboptimal touchpad experience, every one of them being able to fix it in a day of coding. No one did yet. Why?
My best guess is that it just isn't annoying enough to most people. Another way to understand this is to imagine what happens when you put someone with bad visual acuity in charge of font rendering: they'll think it's good enough, and you can't blame them. It _is_ good enough, as far as they can see (pun intended).
- tsss 6y agoI would fix it if I knew how. Commenting out that line sounds like a bandaid to me. I don't know enough about the input stack to tell.
- Liskni_si 6y agoThere are some suggestions here: https://gitlab.freedesktop.org/libinput/libinput/-/issues/286#note_158783 https://gitlab.freedesktop.org/libinput/libinput/-/issues/28...
- acabal 6y agoPersonally, I see my laptop as a tool, and I have a day job. I don't want to spend my precious spare time fixing my tools, which for something as basic and ubiquitous as a trackpad should just work already. For how many decades have trackpads existed? Why are we still shipping broken trackpad experiences, and why is it me, the end user, who is being told that if I don't fix it myself then I don't care enough? In any case, a non-kernel developer fixing it in a day of coding is IMHO wildly unrealistic. While I have 20 years of programming experience, I have zero experience with kernel development--which some of the most complex software in existence--let alone input stack development. I don't even have the domain vocabulary to describe the problem. A lumberjack might know how to cut wood, but that doesn't automatically make him a carpenter.
- Liskni_si 6y ago> I don't want to spend my precious spare time fixing my tools… You get the entire GNU/Linux desktop for free, so you aren't in a position to complain. If you value your precious spare time, part with some of your money. Pay someone to fix this for you. Ask your employer to pay someone so that your "tool" works. Whatever. > In any case, a non-kernel developer fixing it in a day of coding is IMHO wildly unrealistic. Please... at least read the linked issue to see what the problem really is. This isn't kernel development. This is a userspace library, and the problem in question is isolated to a single C function that spans one or two screens. This really isn't rocket science. I wouldn't hesitate to ask students to fix an issue like this in a followup programming course.
- acabal 6y ago> You get the entire GNU/Linux desktop for free, so you aren't in a position to complain. I would buy that argument if we were talking about some new technology that still has some warts. But we're talking about trackpads here. Technology deployed on the scale of billions of units over many decades. At some point users must demand a basic standard of quality for technology that is not only old, but ubiquitous. If libinput shipped a version that randomly duplicated keystrokes on a keyboard, I'd be the one on the hook to fix it and I'm not allowed to complain because it's free? Really? > This isn't kernel development. This perfectly illustrates my point. My day job is not in this sector and I don't even know the right place to start looking. And I'm supposed to fix this in just a day, like any old amateur student supposedly could, otherwise it's my fault? Give me a break. Edit: In this very thread we have one user who submitted a kernel patch that possibly might solve this (but who knows), and another user who points to a year-old libinput bug that possibly might be what I'm talking about (but who knows). Not even the experts agree on where the problem even lies, but I'm supposed to fix it in a day. OK, right.