Bug 397584

Summary:	Hold for rightclick and libinput
Product:	[Plasma] kwin	Reporter:	Oruriz
Component:	input	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	CLOSED NOT A BUG
Severity:	normal	CC:	kde, Oruriz
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Oruriz 2018-08-18 13:21:15 UTC

There is no hold for rightclick functionallity in libinput. So it's hard to use plasma on some touchscreens after updating to libinput (e.g. eVgalax touchscreen in my Acer W500). Also xorg-libinput detects my touchscren not as touchscreen but as pointing device. Gnome somehow add rightclick emulation in their mousetweaks even for this case. I suggest they done it as a tweak on top of everything. And it's not work well with plasma.
So could you please add hold-to-click for kwin (something like hold to click for any pointer device just as gmome team did).

Comment 1 Oruriz 2018-08-18 13:44:27 UTC

I'm sorry It detected as touchscreen but with no capatabilities avable. It works in tap-to-click mode and there is no way to get right click input when using libinput on this device. 

Device:           eGalax Inc. USB TouchController
Kernel:           /dev/input/event11
Group:            7
Seat:             seat0, default
Capabilities:     touch 
Tap-to-click:     n/a
Tap-and-drag:     n/a
Tap drag lock:    n/a
Left-handed:      n/a
Nat.scrolling:    n/a
Middle emulation: n/a
Calibration:      identity matrix
Scroll methods:   none
Click methods:    none
Disable-w-typing: n/a
Accel profiles:   n/a
Rotation:         n/a

Comment 2 Martin Flöser 2018-08-18 14:59:21 UTC

We cannot implement functionality like that. This needs to be provided by libinput directly.

Comment 3 David Edmundson 2018-08-18 20:39:39 UTC

I dont' think we/they should. Synthesised events at a compositor level is problematic for clients. click and hold does things in many apps, like drag/drop. Sometimes internal to the client so we can't see.

Hold to right click if done anywhere, needs to be inside the client(s)

Comment 4 Oruriz 2018-08-20 17:22:16 UTC

I've made a bug on freedesctop.org https://gitlab.freedesktop.org/libinput/libinput/issues/113 
And here Peter Hutterer's answer "No plans to add right-click emulation to libinput, it's the wrong layer of the stack. This wouldn't be something we could expose unconditionally (or even based on device quirks) so we'd need a config option. Since the config options are handled in the compositor, you'd need support for that there. And if you're writing support for a right-click-emulation config option, you might as well write the support for the right-click emulation itself, it's a relatively trivial feature - at least in it's basic form."

Comment 5 David Edmundson 2018-08-20 17:34:02 UTC

I agree it's terrible at the libinput layer. I also think it's terrible at a compositor layer. See #3. Sorry.

Comment 6 Oruriz 2018-08-20 18:14:38 UTC

So what the users like me should do ? Switch to gnome ?

Comment 7 Christoph Feck 2018-09-13 19:05:17 UTC

I suggest to ask Qt developers if they can add support in the Qt libraries, to avoid that every application needs to add support for the required logic. For example, the timeout should be centrally configured, not in each application.