Message-ID: <20170531042652.GA6625@jelly>
Date:   Wed, 31 May 2017 14:26:52 +1000
From:   Peter Hutterer <peter.hutterer@...-t.net>
To:     Michal Suchánek <msuchanek@...e.de>
Cc:     Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        linux-kernel@...r.kernel.org, linux-input@...r.kernel.org
Subject: Re: [PATCH] macintosh: move mac_hid driver to input/mouse.

On Tue, May 30, 2017 at 02:56:18PM +0200, Michal Suchánek wrote:
> > > > I concede userspace doesn't have the feature, but you should
> > > > really have a look at libinput (i.e. open a bug on
> > > > bugs.freedesktop.org) and request the feature here.
> > > >   
> > > > >     
> > > > > >     
> > > > > > > And if it is not rejected by the kernel.      
> > > > > > 
> > > > > > It should not. setkeycodes definitely works on atkbd.
> > > > > >     
> > > > > > > And if it does not
> > > > > > > crash your X server which is very picky about receiving
> > > > > > > pointer events from a keyboard or the other way
> > > > > > > around.      
> > > > > > 
> > > > > > Sounds like you want to make X server more resilient ;)    
> > > > > 
> > > > > This is an inherent design flaw in the X server known for
> > > > > years. It has separate keyboard and pointer devices and while
> > > > > people are trying to patch it up occasionally a bug pops out
> > > > > that crashes the Xserver when an event is received from
> > > > > non-matching device type.

fwiw, the pointer/keyboard split problem was fixed in xf86-input-libinput
with 1f43f3921f6c in late 2015. it's possible to fix it in the same manner
for the evdev driver, but someone would have to be very motivated.

> > > > > 
> > > > > Once X server dies and is replaced be Y server or Z server or
> > > > > whatever it will make life easier in so many ways.    
> > > > 
> > > > We already have libinput that tends to replace the Xorg input
> > > > part (at least everything which is not protocol).   
> > > 
> > > And the protocol still has the split to pointer and keyboard. It is
> > > technically possible to map mouse button presses with XKB but it
> > > only works in X and is undocumented and really difficult to do. And
> > > it does not work outside of X.  
> > 
> > I never talked about XKB. Libinput has a view on all input devices and
> > can redirect whatever events it sees into any other input device.
> > From a X perspective it's as if the emulated button would have been
> > generated by the touchpad itself.
> > 
> > >   
> > > > So if the feature is in
> > > > libinput, it should be available in X.org directly, and you will
> > > > be saved.  
> > > 
> > > Not everything uses libinput. So no, using libinput is not the
> > > answer.  
> > 
> > If you do not want to upgrade and use the latest development tools,
> > then sure, you can always use the mac_hid emulation. But we will not
> > resurrect it because it's something from the past.
> > 
> > > 
> > > Also libinput people suggest to use hwdb for mapping which is back
> > > to where we were:
> > > https://lists.freedesktop.org/archives/wayland-devel/2015-December/026223.html  

Note: in this thread I specifically say that remapping for *broken* keys
should go in the hwdb, anything else needs to go into userspace.

> > Libinput people are basically Peter Hutterer alone. And in the
> > keyboard layout mapping, yes users should use hwdb/systemd for that.
> > In your precise case, libinput should have a setting that redirect
> > the incoming key onto a button of a different device. It's not
> > implemented, it's doable, but you won't receive a NACK as you get
> > here, because you have a valid use case for it.
> 
> Libinput is not the place either. Libinput is a library for using the
> input subsystem, not the input subsystem. So while it might be
> advisable to use it when you can there will always be applications that
> do not use it and those should receive correct input as well.

I'm gonna chime in here and say that emulating button events from keys +
mouse events is (probably) not something I'd merge into libinput anyway.
I'd like to see the touchpads that are unable to even detect two fingers
first. I haven't seen one of those released in 8 years and the ones that are
left are probably at the end of their lifecycle. [However, you'll be happy to
know that with libiput 1.7 and 1.6.2 we added clickfinger support for the
apple onebutton touchpads. And that was only January this year. Both users
have been partying non-stop since, I suspect.]

Almost all touchpads these days are clickpads, i.e. they only have a single
(left) button and anything else is software emulated. So anything that
handles touchpads will have to deal with this before too long.

Spoiler alert: libinput was started not just because "Woo Wayland!" but
because the Wayland compositor model requires each compositor to reimplement
input handling. And handling input is hard, even if it doesn't look like it
from a high vantage point. So having this in one central place, ready to be
re-used is the way to go. Anything that doesn't want to use libinput is
welcome to do so but you'll have to mix the ingredients yourself before you
get to eat the cake.

> > > > > > But really, it all is better solved in userspace, where you
> > > > > > can surface all options to the user. For example Chrome OS
> > > > > > uses Alt + mouse button (or tap) to do right click, I am sure
> > > > > > Gnome or KDE has similar support for right and middle
> > > > > > buttons.    
> > > > > 
> > > > > I do not consider Gnome or KDE more suitable driver for my
> > > > > keyboard than the Linux kernel. In fact I find both very
> > > > > unsuitable as a driver, heavyweight, and causing problems with
> > > > > graphical desktop usability. Not    
> > > > 
> > > > Well, with wayland, the compositor embeds the input stack and
> > > > part of the graphic stack, and it's actually faster than X.  
> > > 
> > > That's pointless when it does not work as a desktop in practice.
> > > 
> > > And it does not make GNOME or KDE a suitable driver for keyboard,
> > > even if you run Wayland.  
> > 
> > I am just not following what is your use case. Do you want to enable
> > this feature in a TTY, in a full blown desktop, in a plain X that you
> > launched with "/usr/bin/Xorg"?
> 
> All of them. Why should my pointer behave differently depending on the
> application I run? Is that the 'usability' you had in mind?
> 
> Yes, current X server and Wayland uses libinput so those are covered.
> Hopefully I will never need to test anything with X server so old that
> it does not have libinput based drivers but who knows.
> 
> However, not all is X and there are applications using gpm or reading
> events directly or whatever which do not run under X. Granted, I do not
> use them often but do I have to figure out why the mouse is not working
> in those every time I try?
> 
> I want a solution that works as uniformly across all system as possible.

that puts you in a pickle. you want emulation of features not supported by
the hardware to be pushed into the kernel. I face a similar request most
days where users want features not supported by their toolkit or application
to be pushed into libinput because it's easier. It's not always a good case,
and often the answer is 'no' because long-term, it makes everything harder.

gpm *should* be able to handle this, and applications that read input
directly should handle input. Because there are plenty of other features
that have similar requirements. Have a look at consolation for example which
uses libinput to be similar to gpm
https://alioth.debian.org/projects/consolation/

> > And if you just want Xorg with whatever desktop manager/environment,
> > you should already be using libinput given that xorg-xf86-libinput is
> > now the only maintained X driver for keyboards and touchpads.
> > 
> > >   
> > > >   
> > > > > to mention they cannot be used at all when not running a
> > > > > graphical desktop and often cause system crashes due to
> > > > > stressing the graphics hardware.    
> > > > 
> > > > If you experience crashes, they are probably bugs, and please
> > > > report them to the appropriate project.  
> > > 
> > > And the answer is they know it crashes but it's too much work to
> > > fix. Or that it works for them and you are just unlucky that all of
> > > your half dozen cards crash with their driver and they cannot do
> > > anything about it.
> > > Maybe next year. Or the year after. Or with different piece of
> > > hardware. Who knows?

I don't know why you presume all these answers, but this is not a 
good way to improve the discussion. We don't just exist to make your
hardware work for free, any of us has more than enough work so we have to
select what we work on. This should not come as a surprise.

> > > > > > Solving this at kernel is wrong place, similarly how we avoid
> > > > > > parsing user gestures (edge scrolling, 2-finger scrolling,
> > > > > > pitch/zoom, etc) in kernel. Yes, we have legacy drivers (like
> > > > > > mousedev) that are artefacts of times when userspace support
> > > > > > was not there and it made sense to covert everything to
> > > > > > emulated PS/2, but that time is long gone.    
> > > > > 
> > > > > Unlike 2-finger scrolling, pitch/zoom, and whatnot key mapping
> > > > > is something kernel can do, does, and should do.    
> > > > 
> > > > Looks like we are all on the same page. Kernel does key mapping
> > > > already and doesn't do 2-finger scrolling and other gestures.
> > > > 
> > > > The difference in approach is that you want the kernel to emulate
> > > > devices when userspace has much more information to know how to
> > > > emulate those devices.  
> > > 
> > > Any piece of software has the information when the user tells it.
> > > The thing is the kernel is also able to emulate the device and the
> > > userspace is not. And seriously, this is a hardware problem which is
> > > simple to solve once for good in kernel. Do you advocate that
> > > instead  
> > 
> > It is a hardware problem that is not solvable in the kernel (or should
> > not). Would the keyboard had specific keys designed to send buttons,
> > yes, we would have do our best. But here you are trying to counter a
> > hardware design issue by using a hack at the wrong level. That's all
> > we are saying.
> 
> And if the vendor put a LMB and RMB stickers on some keyboard keys then
> it would be fine? I mean then it would be designed to send mouse
> buttons even if it sends key events in practice, right :>
> 
> Then I can fix it and put a sticker on the key myself :>

vendors already put a visual marker on touchpads to signal the left/right
button split but rely on software (libinput or xf86-input-synaptics) to
actually convert it to a right button click. I'm not sure what you're
expecting to achieve with these arguments.

> > > everyone should set up mouse emulation in N application frameworks
> > > and implement it in those that miss it?  
> > 
> > Well, given the amount of people involved in the input community, you
> > can be sure that adding this in libinput is just enough.
> > 
> > >   
> > > > 
> > > > The kernel job is to forward events from the devices to userspace
> > > > without losing information and in a standard way. Anything beyond
> > > > that should be handled in userspace.  
> > >  
> > > Then why do you do keycode translation at all?   
> > 
> > Because keycode translations are used for fixing hardware when the
> > keycode sent is non standard, and instead of requiring people to send
> > kernel patches for it, it's better to ask them to drop a hwdb entry
> > for them. This doesn't contradict what I said: it helps forwarding a
> > random event from the device into a standard one.
> > 
> > keycode translation also helps setting layouts on TTY. Because when
> > you are on a TTY there is not much you can do in userspace to fix it.
> 
> So the kernel *is* responsible for translating the keys to whatever the
> user sets up. Because it is the only place possible to make it work for
> all applications.

within reason. The kernel fixes keys that send *wrong* key events, but it
doesn't remap keys (well, layouts, but that's not the same).

> > Luckily, Peter is also in charge of XInput, so I guess if it crashes
> > the server, it will be detected/fixed way before it is public.
> 
> Sadly, such bugs escaped more than once and were only found by users
> because the mappings which send key presses on a mouse or mouse button
> presses on a keyboard are uncommon and not well tested.

sorry, but if you're expecting bug-free software, you're in the wrong
business. I'm not sure  what you're trying to achieve with these types of
arguments, software that doesn't crash will never happen. And it's
impossible to test all hardware combinations, though I'm sure you'll be
happy to know that libinput has several thousand test cases more than
the X input stack.

Cheers,
   Peter

Powered by blists - more mailing lists