On Tue, May 30, 2017 at 02:56:18PM +0200, Michal Suchánek wrote:

quoted

quoted

quoted

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.
  

quoted

quoted

quoted

And if it is not rejected by the kernel.      

It should not. setkeycodes definitely works on atkbd.
    

quoted

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.

quoted

quoted

quoted

quoted

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.

quoted

quoted

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.

quoted

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.

quoted

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.

quoted

quoted

quoted

quoted

quoted

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/

quoted

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.

quoted

quoted

quoted

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.

quoted

quoted

quoted

quoted

quoted

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.

quoted

quoted

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.

quoted

quoted

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).

quoted

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