[Wayland-bugs] [Bug 99212] Button areas on Lenovo Thinkpad W540

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=99212

--- Comment #10 from Markus Schmidt <schmidt at boomshop.net> ---
Hey Peter,

thanks a lot for your explanations.

(In reply to Peter Hutterer from comment #9)
> both of those are end-user applications. libinput is a library used by the
> compositor and users don't have direct access to it. having a GUI to
> libinput would be akin to having a GUI for glibc - it just doesn't make
> sense this way. the GUI for libinput is the gnome control panel, or the KDE
> settings panel, or ...

Probably you missed my point. You say a GUI for libinput is senseless just to
point to the different DE's control panels as GUI afterwards. So my point was
that even if there were some faders to e.g. set the touchpads sensitivity (in
whichever environment) in the past it always was far from offering a UI for
controlling input devices behavior. the different Xorg drivers have lots of
settings and even if there have been a couple of projects trying do provide
some deeper control it always was just a tiny fraction of the possibilities. So
the idea was to have a graphical interface developed in direct cooperation with
the libs dev to reflect the whole power/settings of the driver without using
meaningless numerical values as an interface while preventing the user to shoot
oneself in the foot by using their text based config files as a playground.

> The problem is: unless you go full "yes to anything", you always have some
> limit of where you draw the line in further configuration options. And each
> option increases the required test scenarios (and guess who has to write
> those tests :) but right now we're just arguing about where the line is
> drawn and that's just a subjective argument, as maintainer I just have to
> say no to a lot of people ("yes is forever...")

I fully understand your point.

> problem is: you can't separate things this way with libinput, as said above
> the configuration is controlled by the compositor (or the xorg driver)

libinput already separates things - there's the plug-and-play-like behavior
("wow, it just ... works!") and there are some configuration values for deeper
control or special use cases.

For Xorg the configuration is just a simple text file or some console-driven
control interface like synclient which suits the pro- to hardcore users. I'm
not familiar with the way wayland handles things.

>From my POV a UI shouldn't care about what it controls or manipulates in the
end - a config file, an API, a command line tool or whatever. xplanetFX for
example generates different config files for xplanet and is doing some
graphical manipulation on the renderings via imagemagick afterwards. If I would
switch over to GIMP for the graphical part the UI of the program simply
wouldn't care since the interface between UI and back-end is just a config
file.

> simple answer: more options == less testing == less stable code == more time
> spent bugfixing after releases
> other answer: more options == more effort to maintain == less time for
> actual development

Exactly.

> In your case: this touchpad was present in a single series from early 2014
> (with a refresh in Oct 2014) and got replaced because of user complaints in
> the 2015 models. No device since had this touchpad and no device will have
> it. So my motivation to put a new option in that I'll have to support
> forever for a device that's 3 years old and won't come back is... limited ;)

There are lots of external clickpad-like devices available, Macbooks have this
kind of control, too. But as I said I completely understand your point. So to
me it seems that a single person obviously is not enough to bring full support
and control to all input devices. If you manage to bring some
"one-size-fits-all" solution which makes most of the users happy most of the
time it still is a master stroke.

> I'll fix the bug in that you can't click unless you lift the finger, once
> that one's fixed we can look at what else is needed.

Great, thanks a lot! I will love to test it and if it still doesn't fit my
needs I have to switch back to the self-compiled evdev/synaptics cocktail in
hope that I make it work again.

> Meanwhile: let's not
> have more philosophical discussions on options here, you can move that to
> the wayland-devel list if you want. Here it's just me replying to it, which
> could get boring after a while.

No, I don't want to steal anyones time discussing my personal opinions, better
invested in coding the world a better place .) Since you are the dev you decide
what to build into your software and what not. If I disagree I'm free to switch
to another software or to build my own - that's what "freedom" in FOSS really
means. So no need to go on with this discussion at all.

Thanks a lot for your time and your efforts,

best Markus

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-bugs/attachments/20170116/dc51af4d/attachment.html>