5 ms·

He could also not have written libinput to begin with. libinput became the default because of political pressure from Red Hat and now we can’t complain if it’s

by bsjks 5y ago

He could also not have written libinput to begin with. libinput became the default because of political pressure from Red Hat and now we can’t complain if it’s worse than the project it is replacing?

Robin_Message 5y ago
Sounds like your complaint is with Red Hat and not the developer?
BrazzVuvuzela 5y ago
> libinput became the default because of political pressure from Red Hat I don't know if this is true, but when comparing the KDE configuration screens for both, it sure seems like it must be true. libinput is missing much that synaptics has and doesn't seem to do anything better as far as I can tell. Unfortunately, just because a developer is working hard and pouring his heart and soul into something, doesn't mean the result is actually worthwhile.
- shatteredgate 5y ago
  It's not really true at all. The libinput developer blogged about why having more configuration options has historically not actually been good for the project, or for users of the synaptics driver: https://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-lot-of-config.html https://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-... Particularly, once you add a configuration option, you're now on the hook to support that option indefinitely as long as the project exists and users expect that option to be there. With more maintainers and testers, it may become feasible to have more configuration options, but it's still not a good idea to just keep piling them in. It might be satisfying to see a big configuration panel with a lot of settings but it's a lot less satisfying when you figure out a lot of the configuration options don't work correctly because the underlying system has bugs or is under-maintained or was just never tested with your specific configuration because input is hard and requires near constant testing against an extremely large number of hardware devices.
  - BrazzVuvuzela 5y ago
    One-size-all doesn't fit me. synaptics gets the job done and libinput doesn't, it's really that simple as far as I'm concerned. An example from elsewhere in this thread: "In libinput the edge scrolling is hard coded to 7mm" Somebody please tell this dude that the size of a human finger varies dramatically from person to person. Not everybody has his hands. As for developer workload, the libinput developer could save himself a lot work by not starting his project in the first place. It doesn't seem to do anything better than synaptics so I don't see why it even exists.
    - shatteredgate 5y ago
      >synaptics gets the job done and libinput doesn't, it's really that simple as far as I'm concerned. From a maintenance perspective it is unfortunately not that simple. I sympathize with your frustration and personally I too wish it was that simple but it is not. The synaptics driver might be able to do some things better but those things can also cause bugs to manifest in other areas, and have historically done so. >An example from elsewhere in this thread: "In libinput the edge scrolling is hard coded to 7mm" Somebody please tell this dude that the size of a human finger varies dramatically from person to person. Not everybody has his hands. Well this is an open source project so you (or anyone else) can tell him if you really want. Have you checked if there is an open feature request on the tracker for this? Or better, can you propose a configuration API that would work well here, and can you help maintain it and test it on the hundreds of devices that it might potentially affect? I checked and I couldn't find any feature requests or proposals for this but maybe I missed something. If you don't want to do this then you may have to wait until somebody else makes the proposal and until the maintainer gets bandwidth to do that non-trivial amount of work, which is prioritized against all the other feature requests that might have been received. >As for developer workload, the libinput developer could save himself a lot work by not starting his project in the first place. It doesn't seem to do anything better than synaptics so I don't see why it even exists. But that's not the case at all. I'm sure you understand, there are a lot of other devices out there besides your particular touchpad and synaptics touchpads in general. You may want to read the rest of the libinput developer's blog about some of the motivations behind libinput, it solves very real problems that were directly caused by the synaptics driver. If you never encountered those bugs, that's great for you and you can continue to use it, but this was not how it was for a lot of other users. Remember we're still in this area where a critical project like this is only really being maintained by one developer, if they quit then you're left with no developers working on the input stack at all.
shatteredgate 5y ago
There isn't any political pressure from Red Hat. They're often the only company that does any work on the input stack in userspace, without them it would probably not even exist or be stuck in a very old state. You can complain but it's unlikely to be of much use when the real issue is lack of manpower and there just aren't enough people to respond to all the complaints users have. A surefire way to solve that would be to start contributing, Red Hat won't stand in your way.

by bsjks 5y ago

Robin_Message 5y ago

Sounds like your complaint is with Red Hat and not the developer?

BrazzVuvuzela 5y ago

> libinput became the default because of political pressure from Red Hat I don't know if this is true, but when comparing the KDE configuration screens for both, it sure seems like it must be true. libinput is missing much that synaptics has and doesn't seem to do anything better as far as I can tell. Unfortunately, just because a developer is working hard and pouring his heart and soul into something, doesn't mean the result is actually worthwhile.

shatteredgate 5y ago
It's not really true at all. The libinput developer blogged about why having more configuration options has historically not actually been good for the project, or for users of the synaptics driver: https://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-lot-of-config.html https://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-... Particularly, once you add a configuration option, you're now on the hook to support that option indefinitely as long as the project exists and users expect that option to be there. With more maintainers and testers, it may become feasible to have more configuration options, but it's still not a good idea to just keep piling them in. It might be satisfying to see a big configuration panel with a lot of settings but it's a lot less satisfying when you figure out a lot of the configuration options don't work correctly because the underlying system has bugs or is under-maintained or was just never tested with your specific configuration because input is hard and requires near constant testing against an extremely large number of hardware devices.
- BrazzVuvuzela 5y ago
  One-size-all doesn't fit me. synaptics gets the job done and libinput doesn't, it's really that simple as far as I'm concerned. An example from elsewhere in this thread: "In libinput the edge scrolling is hard coded to 7mm" Somebody please tell this dude that the size of a human finger varies dramatically from person to person. Not everybody has his hands. As for developer workload, the libinput developer could save himself a lot work by not starting his project in the first place. It doesn't seem to do anything better than synaptics so I don't see why it even exists.
  - shatteredgate 5y ago
    >synaptics gets the job done and libinput doesn't, it's really that simple as far as I'm concerned. From a maintenance perspective it is unfortunately not that simple. I sympathize with your frustration and personally I too wish it was that simple but it is not. The synaptics driver might be able to do some things better but those things can also cause bugs to manifest in other areas, and have historically done so. >An example from elsewhere in this thread: "In libinput the edge scrolling is hard coded to 7mm" Somebody please tell this dude that the size of a human finger varies dramatically from person to person. Not everybody has his hands. Well this is an open source project so you (or anyone else) can tell him if you really want. Have you checked if there is an open feature request on the tracker for this? Or better, can you propose a configuration API that would work well here, and can you help maintain it and test it on the hundreds of devices that it might potentially affect? I checked and I couldn't find any feature requests or proposals for this but maybe I missed something. If you don't want to do this then you may have to wait until somebody else makes the proposal and until the maintainer gets bandwidth to do that non-trivial amount of work, which is prioritized against all the other feature requests that might have been received. >As for developer workload, the libinput developer could save himself a lot work by not starting his project in the first place. It doesn't seem to do anything better than synaptics so I don't see why it even exists. But that's not the case at all. I'm sure you understand, there are a lot of other devices out there besides your particular touchpad and synaptics touchpads in general. You may want to read the rest of the libinput developer's blog about some of the motivations behind libinput, it solves very real problems that were directly caused by the synaptics driver. If you never encountered those bugs, that's great for you and you can continue to use it, but this was not how it was for a lot of other users. Remember we're still in this area where a critical project like this is only really being maintained by one developer, if they quit then you're left with no developers working on the input stack at all.

shatteredgate 5y ago

There isn't any political pressure from Red Hat. They're often the only company that does any work on the input stack in userspace, without them it would probably not even exist or be stuck in a very old state. You can complain but it's unlikely to be of much use when the real issue is lack of manpower and there just aren't enough people to respond to all the complaints users have. A surefire way to solve that would be to start contributing, Red Hat won't stand in your way.