On Mon, May 29, 2017 at 08:03:25PM +0200, Michal Suchánek wrote: > On Sun, 28 May 2017 10:55:40 -0700 > Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > > > On Sun, May 28, 2017 at 11:47:58AM +0200, Michal Suchanek wrote: > > > On Tue, 9 May 2017 17:43:27 -0700 > > > Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > > > > > > > If not then please do your job as maintainer and accept trivial > > > patches for perfectly working drivers we have now. > > > > I am doing my job as a maintainer right now. The driver might have > > been beneficial 15 years ago, when we did not have better options, > > but I would rather not continue expanding it's use. > > > > The main problem with the driver is that the functionality it is not > > easily discoverable by end users. And once you plumb it through > > userspace to present users with options you might as well handle it > > all in userspace. > > > ... > > > > > > > > > > > > > What hardware do you believe would benefit from this and why? > > > > > > Any touchpad hardware where you cannot press two buttons at once to > > > emulate the third button due to hardware design. And any touchpad > > > hardware on which some of the buttons are broken when it comes to > > > it. > > > > > > It is built into a notebook and works fine for moving the cursor but > > > due to lack of usable buttons you still need a mouse to use the > > > notebook. > > > > Have you tried simply redefining keymap of your keyboard to emit > > BTN_RIGHT/BTN_MIDDLE? Both atkbd and HID keyboards support keymap > > updates from userspace/udev/hwdb and if there is a driver that does > > not support it I will take patches fixing that. > > How is that more easily discoverable by users? It is not, but the benefit that it does not require a new driver and uses standard tools to update the mapping. > > More importantly how is that mapping supposed to be represented in a > hwdb file? > > The help text in the hwdb file says: > > # Scan codes are specified as: > # KEYBOARD_KEY_<hex scan code>=<key code identifier> > # The scan code should be expressed in hex lowercase. The key codes > # are retrieved and normalized from the kernel input API header. > > So they are converted in some unspecified way. > > The example below defines some mappings, presumably: > > evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pn* > evdev:atkbd:dmi:bvn*:bvr*:bd*:svnGateway*:pnA0A1*:pvr* > evdev:atkbd:dmi:bvn*:bvr*:bd*:svneMachines:pneMachines*E725:pvr* > KEYBOARD_KEY_a5=help # Fn+F1 > KEYBOARD_KEY_a6=setup # Fn+F2 > KEYBOARD_KEY_a7=battery # Fn+F3 > > /usr/include/linux/input-event-codes.h has occurence of battery in > > #define KEY_BATTERY 236 > > meaning that the unspecified conversion is probably performed by > > 1) stripping KEY_ prefix > 2) converting to lowercase > > This is what systemd hwdb check script does in reverse when checking > the keycode values. > > The BTN_LEFT 0x110 value does not conflict with KEY_* values, though. > So technically you could include it in the keymap. If you had a tool > for that. Hmm, sounds like you want a patch to udev/systemd. For the kernel there is no difference between keys and buttons, except symbolic names. They all go into dev->keybit and are reported with input_report_key(). > 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 ;) 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. 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. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
