1. 26

  2. 7

    The final line is wonderful:

    Legally, you have freedom to do almost anything with the software, so you can maintain a local fork of libinput with that extra feature applied. If that isn’t acceptable, why would it be acceptable to merge the patch and expect others to shoulder the costs?

    1. 4

      Obviously you don’t understand free software. It means free of the burden of supporting it. :)

    2. 3

      This 1000x, but for all software ever

      1. 3

        The problem is whether you should favor developer ease vs. the user’s wants/needs. In some cases, both are possible, but when the developer’s end becomes insanely complicated (aka, the curse of the incredibly specific bug), things have to change.

        1. 2

          The assumption of this post is the following:

          • More code inherently has a higher maintenance cost. The hwdb is not part of this cost, or at least an acceptable cost per hardware device supported.

          Is there any way they can increase the options for users, while not increasing their code’s surface area? What interfaces would they need so they felt that libinput’s configuration was more like it reaching out to udev’s hwdb rather than some complexity they wont be able to handle?

          User’s will always have strong opinions about input devices, as they are the number one way a user interacts with any computing system. And in fact, I know that people think that user’s get used to things - but I have an office of Mac user’s, and they all constantly bitch about random problems with their Mac keyboards, their touchpads, and whatnot.