Right-click emulation of Onboard does not work

Computer is the Lenovo Thinkpad Twist, a convertible with touch screen and Intel Core i& processor with on-chip GPU. System is 64-bit with 64-bit Ubuntu.

There are two keys showing a pointer arrow pointing to the left on the Onboard layout. The key with only the pointer is to show and hide the click buttons. The key with a small clock (disk) on its left is to enable and disable automatic click. The automatic click is an accessibility feature that performs automatically a click each time the pointer stops moving.

If the automatic click is enabled, Onboard does not replace a manual left click with a right click. In this case, the click conversion only acts on automatic clicks. Since you are using a touch screen, you should keep the automatic click disabled.

If you get right clicks after holding your finger for a small lapse of time motionless on the touch screen, you might have the Simulated Secondary Click running. You can find the option to enable and disable the Simulated Secondary Click in the Universal Access panel of the System Preferences of Ubuntu.

OK. I had never enabled automatic click.

Now I have opened the system settings, entered the Universal Access section, and selected the Pointing and Clicking tab. On this tab I have now turned on "Simulated Secondary Click" and then I tried again on the desktop background. Independent how I adjust the slider I do not get a right-click menu. On which package do I have to report this?

I might not have been completely clear.

The automatic click, also called hover click or dwell click, is provided by the mousetweaks package. (1)

The Simulated Secondary Click is also provided by the mousetweaks package. (2)

The translation of a left click into another click type by using the click buttons on Onboard is done by Onboard itself, if the automatic click is disabled. (3)

I don't think that using (1) can make sense on a touch screen; you should leave the Hover Click in the Universal Access panel disabled. Option (2) should be usable on a touch screen; but it is some drawbacks (for example it is not possible to perform a right click with it on a multiple selection). Option (3) should work universally.

Option (2) does not have to be enabled for (3) to work. These are two independent ways to perform a right click. Are both options to perform a right click broken on your system?

I had never turned on anything on the Pointing and Clicking tab of Universal Accessibility. I always never turned on automatic clicking in Onboard, I even never tested this.

When I saw that with a touch screen I cannot right-click, I tried at first the right-click emulation of Onboard. From the mouse control keys it is the one with the mouse pointer pointing to the upper right. I NEVER clicked the mouse pointer with the clock.

To do a right click I clicked this mouse pointer pointing to the upper right and after this I clicked on the desktop background, getting no reaction and the right-click key on Onboard staying pressed. On a second click on the desktop background the background's right-click menu appeared and the right-click key on Onboard released. Sometimes I need to do several clicks until finally the right-click menu opens and the key releases.

Then I tried the other alternative: In Universal Access under Pointing and Clicking I turned on the long-press right click, the second of the three options. After that I did long presses and never got a menu, even after moving the slider to a shorter long-press time. I NEVER turned on Hover Click.

Thanks for the detailed explanation; my questions were intended to eliminate possible causes and to narrow down the problem. It is weird, that the system gets problems reacting to clicks, after the right click has been activated in Onboard.

Marmuta might have to look into this. Thanks for reporting the problem.

Note that the right-click emulation problems only occur when touch-clicking on the touch screen. When using a mouse all works as intended, both the Onboard right-click key method and the Universal Accessibility long-press right click.

Till, could you please run
xev | tee taps.txt
and tap like 5 times right in the middle of that xev window. Try to perform the taps like you always do them when trying to use Onboard's right click.
Attach taps.txt here, maybe there's a clue in there.

I'm currently working on a replacement for the middle and right click conversion (for bug #1191098) that would probably sidestep your problem too. It has yet to be tested on touch-screens, though...

Attached is the result of simple taps (= left clicks).

Attached is the result for Onboard-based right clicks. I have tapped the right-click button of Onboard first and then tapped xev. Only with the fifth tap on xev the right-click button of Onboard released. On a second attempt I tapped first the right-click button of Onboard and then I needed 10 taps on xev for the right-click button to release.

Attached is the result of long-pressing xev. This I did to find out about the problem of the long-press right click of Universal Accessibility not working. I have this functionality activated and the other features of Universal Accessibility turned off. I did 5 long presses of varying times.

See also

https://bugzilla.gnome.org/show_bug.cgi?id=315645

Thanks for the logs. No right click at all, but apart from that I don't notice anything unusual. I believe Onboard's passive grab is successful, but then for some reason press events don't seem to arrive in the event filter.

Let's try something else first. The new click mapping for bug #1191098 is ready for a test. Middle and right click work very differently now, there's a new chance they will do something on your touch-screen.

Francesco will update the snapshot repository, but you can build from source too. For example:
sudo apt-get build-dep onboard
bzr branch lp:onboard
cd onboard
debuild binary
./onboard

If you're happy with the result, install with
sudo dpkg -i ../onboard*.deb

marmuta, I have tried it but without success. It works perfectly, both for right and middle button emulation) with any type of mouse (touchpad, nipple, Bluetooth mouse, Bluetooth keyboard with touchpad) but not with the touch screen. With the touch screen the behavior is different now: First, I tap the key for right or middle mouse button emulation and after that a place on the screen. Now the emulation key releases immediately, but the click is behaving as a left click (positioning cursor in editor).

I attach the xev output for both right and middle button emulation.

Good news!

It works perfectly now! Problem was in your instructions. You told to run

./onboard

in the source directory for a first test. This started only a short portion of the new code but also a lot of the installed old code, changing the behavior somewhat but not solving the problem. Now I installed all the three newly generated .deb files and the mouse click emulation works correctly.

Bad news: With the new onboartd I get the stuck-button problem again after a few clicks.

Stopped working again. Seems to be completely random. I am back to the observations of comment #14.

So again the xev output of the state of comment #18.

Seems to be that your (and my) success is based on something messed up in the X session. I reached this state somewhere since I logged in yesterday (or even the day before) and running ./onboard in the source tree today. After that the installed Onboard behaved correctly. After another login I got the state of comment #14 again. Perhaps you are in the same state probably not having freshly logged in for hours or days and having onboard suddenly correctly working because something in X is messed up ... Only an idea ...

By the way, I did not test the double-click and drag emulation keys, probably they have the same problem.

The stuck button (comment #17) I got when pressing the double-click emulation key in Onboard.

> You told to run
> ./onboard
> in the source directory for a first test. This started only a short
> portion of the new code but also a lot of the installed old code,
Right, I didn't mention this. The single instance check just shows an already running Onboard if it exists. Quit Onboard before to avoid this, or do something like
killall onboard; ./onboard

> Now I installed all the three newly generated .deb files and the
> mouse click emulation works correctly.
There should be only two deb files actually, onboard_*.deb and onboard-data_*.deb. Also you don't need to have python3-virtkey installed anymore.

> The stuck button (comment #17) I got when pressing the
> double-click emulation key in Onboard.
OK, not middle or right click, that's good. The other click buttons haven't changed and might still stay activated until you click them again, or they time out after 15s.

Please attach the output of
xinput

and let me know what ./onboard prints to the terminal when you perform a failed right click. There should be "mapping.." and "restoring..." lines.

Now I removed the packages python3-virtkey and onboard-prediction-data (latter package had no non-documentation file, should be turned into a transitional package). After that I followed your instructions of comment #25. Output files attached. In Onboard I did two failed right clicks.

xinput shows 5 physical mice: Bluetooth mouse, Bluetooth keyboard/mouse combo, internal touchpad, internal TrackPoint (nipple), and the touchscreen. It does not show an additional keyboard or mouse for Onboard and it does not show an additional keyboard for the Bluetooth keyboard/mouse combo, but typing on the Bluetooth keyboard/mouse combo is perfectly working though.

FYI: Revision 1551 of onboard is in our Snapshots PPA:
https://launchpad.net/~onboard/+archive/snapshots

If you need it in our nexus enabled PPA ( which is restricted to 10 uploads per week) simply drop me a line here.

(Concerning onboard-prediction-data, if you install Onboard from our PPA, it gets automatically removed; I have to update debian/control in trunk...)

Francesco, I have updated to the rev. 1551 snapshot now and the problem is still there. But thank you anyway.

I have yet another variant ready for testing. This one is really experimental and not fully fleshed out, but give it a try. Make sure to save what you are working on, there is a slight risk of the touch-screen to become unresponsive (until reboot).

Update your branch (bzr pull), rebuild, close the running Onboard instance and then run
CLICKSIM=CSFloatingSlave ./onboard

Ignore double and drag click for now, they just generate left clicks. I'll finish them if right and middle click work.

Without the environment variable this version should behave just like the last one.

It looks much better now: I can now make as many right and middle clicks as I want, preceding the click by the appropriate key of Onboard, but as soon as I start right and middle clicking left clicking stops working (but typing on Onboard and right and middle clicking continues to work).

Everything except the touch screen left click works. After logging out and logging in again all returns to work normal again.

OK, this looks promising, though detaching devices apparently was too risky. Device grabs are safer from what I gather, and they restore the device hierarchy even when Onboard is killed.

Try again, please. Same procedure as in comment #30. Perhaps we're lucky this time.

When left clicking the touch-screen stops working again, send me (after it happened)
xinput

It works now! the right (or middle) click action happens reliably and the keys are reliably released. Also I did a lot of right and middle clicks in different apps and they all worked and also the left click stays working. For me it seems that you have fixed it now. Also operation with a mouse continues to work.

Yay, almost there! I'm going to flesh this out a bit more and then give you one more revision to test - hopefully with the remaining buttons working and the two-device case, one for pointing the other for clicking, covered.

Done, I think, you can try it. All click buttons should work and the new click simulator is the default now. You can run Onboard without the environment variable.

bzr pull
./setup.py build
killall onboard; ./onboard

It is all working correctly now, including double click and drag emulation. Thank you very much.

Great, thank you for your patience.

Also works with Saucy in XMir mode (as described on https://wiki.ubuntu.com/Mir/Installing).

This bug was fixed in the package onboard - 0.99.0-0ubuntu1

---------------
onboard (0.99.0-0ubuntu1) saucy; urgency=low

  * Request for sponsorship for new upstream release (LP: #1215164)
  * debian/control:
    - Add libcanberra-dev, libxkbfile-dev and libhunspell-dev to Build-Depends
    - Raise Standards-Version to 3.9.4
    - Remove python3-virtkey from Depends
    - Add libxkbfile1, libcanberra0, libhunspell-1.3-0 and iso-codes to Depends
    - Define new package onboard-data package for all architectures
    - Add onboard-data to Recommends
    - Update description of onboard package
  * debian/control_python2.in: removed
  * debian/control_python3.in: removed
  * debian/onboard.install: new file to split keyboard from the prediction data
  * debian/onboard-data.install: new file with the prediction data for onboard
  * debian/rules:
    - Remove support for python2
    - Add override_dh_auto_install target to use debian/tmp
    - Add override_dh_install target
  * debian/patches/add_defaults_for_ubuntu.patch:
    - Update add_defaults_for_ubuntu.patch with values for this release
  * Long press popup:
    - Hide long press popup when keyboard gets hidden
    - Add possibility to show arbitrary layouts in popups
    - Add character alternatives for most latin based languages
  * Add key-press feedback:
    - Size of label popup stored in gsettings-key
    - Also allow images in the touch feedback
    - Don't show feedback popup when xembedded
  * Add sound feedback:
    - New dependency: libcanberra
    - Add 'Play sound' option to the Preferences dialog
  * Add word suggestions:
    - Add tools to create language models (lm) from large corpora
    - Learn from typed text by default
    - Limit over-learning in the terminal with additional filters.
    - Use UTF-8 encoding internally (cuts memory usage)
    - Fall back to hard-coded country codes if there is no lm for current locale
    - Add initial system language models for: de_AT, de_CH, de_DE, en_AU,
      en_ES, en_GB, en_US, fr_fr, it_IT, pt_BR, pt_PT, ru_RU
    - Optimize system language models for size/memory usage.
    - Use case insensitive predictions most of the time
    - Offer spelling suggestions based on the hunspell C-API
    - Auto-add word separators
    - Add word suggestion row to all layouts
    - Make word suggestion also work when using the scanning mode
    - Doctests available for English, German, Italian, Portuguese, Russian and
      Spanish
  * Add auto-capitalization
    - Off by default because very new
    - Add corresponding option to the Preferences of Onboard
    - Independent of word suggestions
  * Add XInput as a new event source and make it the default: (LP: #905636)
    - Fall back to GTK event handling if XInput 2.2 isn't available
    - Allow switching between GTK and XInput events without restarting Onboard
    - Listen only to the XInput client pointer and its slaves
    - Make XInput target specific windows instead of root window
    - Support Multi-touch
    - Don't count scroll-wheel movement as button presses
    - Grab pointer even if click is performed by different device than movement
    - Fix pointer becoming unresponsive on wetab...