In XInput mode Keyboard responds to drags with delay and jumps

Bug #1210665 reported by Boris Burkov on 2013-08-09
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Onboard
Undecided
Unassigned

Bug Description

When you drag the keyboard, at first it follows your fingers, then after a ~0.1 sec. it halts and stays at one place for a variable period of time, ~0.1-0.5sec, after that it wakes up and tries to catch up with your finger. If you're constantly moving your finger atop the tablet, Onboard would leap and halt with ever-increasing duration of halt periods.

In GTK input mode the keyboard's movement is smooth and nice.

Detail:
MSI Windpad-110W tablet, AMD Brazos z-01 CPU at 1GHz, 2GiB RAM, AMD Radeon HD6250 graphics
Debian 7 with 3.2 686-pae Linux kernel, all drivers default
Gnome 3.4 in fallback mode

Onboard installed as a .deb package as described in https://bugs.launchpad.net/onboard/+bug/1207503 from revision:
$ bzr version-info
revision-id: <email address hidden>
date: 2013-08-06 19:51:36 +0200
build-date: 2013-08-10 01:31:11 +0400
revno: 1542
branch-nick: onboard

Virtkey installed as a .deb package from revision:
$ bzr version-info
revision-id: <email address hidden>
date: 2013-04-23 00:26:45 +0200
build-date: 2013-08-10 01:37:18 +0400
revno: 96
branch-nick: virtkey

marmuta (marmuta) wrote :

Thank you for the separate bug report.

I have a potential fix. Would you check if it helps?
Just update your branch with
bzr pull
and rebuild.

Btw. you can run ./onboard right from the branch's directory if you want to try the changes before installing the new packages.

Changed in onboard:
status: New → Fix Committed
Boris Burkov (vasjaforutube) wrote :

Marmuta,

the bug disappeared, thanks. Though, for some reason, the version of Onboard bzr pulls (or branches) is 0.98.2. When I debuild it, it also generates an onboard-data package, which dpkg refuses to install, cause it depends on Onboard version 0.99 or newer.

Boris Burkov (vasjaforutube) wrote :

Um, to clarify what I did: in /usr/local/src/onboard

sudo bzr pull #bzr pull applied changes to working tree
sudo debuild clean #just in case
sudo debuild binary
cd ..
sudo dpkg -r onboard
sudo dpkg -r onboard-data
sudo dpkg -i '*onboard*'.deb

got error message about onboard-data depending on onboard>=0.99, decided to repeat everything from scratch

sudo dpkg -r onboard
sudo dpkg -r onboard-data
sudo rm -rf onboard #
sudo mkdir onboard #this was unnecessary, but just not to put .deb packages right in /usr/local/src
cd onboard
sudo bzr branch lp: onboard #now have /usr/local/src/onboard/onboard
sudo debuild binary
cd .. #now in /usr/local/src/onboard, have .debs here
sudo dpkg -i onboard_0.98.2-0ubuntu1_i386.deb #ok
sudo dpkg -i onboard-data_0.98.2-0ubuntu1_all.deb #not ok, but still keyboard works even without it

Is it ok? Also, I didn't remove virtkey, but I assume, I can remove it?

Francesco Fumanti (frafu) wrote :

Sorry, that was my fault: I updated debian/control to use the new onboard-data package, but I did not update debian/changelog and setup.py in trunk with compatible version numbers. It should now be fixed in trunk. But you can also get updated packages from time to time from our PPAs.

You can remove virtkey if you are using a revision of trunk > 1539. But it does not hurt leaving it install; if for example you need it for something other than onboard.

marmuta (marmuta) wrote :

Great, thanks for testing.

> Though, for some reason, the version of Onboard bzr pulls (or branches) is 0.98.2.
It's still the future 0.99, we just usually only increment the version immediately before a release. This will happen soon hopefully.

About onboard-data, it seems Francesco just fixed the version conflict. You did nothing wrong.
Onboard-data is only interesting if you have word suggestions enabled. You'll get fewer words completed without it, that's about it.

Yes, you can remove python3-virtkey and you don't need the virtkey branch anymore.

Boris Burkov (vasjaforutube) wrote :

Marmuta, Francesco: thank you guys. Besides, marmuta, Onboard gets successfully autostarted after by gdm3 after I created a .desktop file for it in /usr/shaer/gdm/greeter/autostart.

marmuta (marmuta) wrote :

Thanks for the update, good to know it still runs in gdm3.

Changed in onboard:
status: Fix Committed → Fix Released
Boris Burkov (vasjaforutube) wrote :

marmuta, Francesco Fumanti:

Hello again, guys! I just stumbled upon a discussion in #gtk+ IRC at irc.gnome.org where guys are complaining about having to write their own custom Xevents filter due to slow motion report in gtk (30Hz compared to native 100+Hz): https://bugzilla.gnome.org/show_bug.cgi?id=702392. I thought, the problem and its solution might be similar to what we experienced with OnBoard here.

Gtk core developers (Emmanuele "ebassi" Bassi , Benjamin "Company" Otte, Matthias "mclasen" Clasen) said, they invite (encourage, rather) downstream developers to introduce a bugfix in gtk instead of creating their own X events filters. Bug reports in gtk+ seem to be filed, but not solved. So, I just thought, it might be of interest to you.

Thanks and good luck!

marmuta (marmuta) wrote :

Thanks for the link, interesting read and yes, the fix for this bug does exactly that: discarding motion events. We don't have high requirements for motion event timing, though. There's no need for an accurate motion history. Currently important is only that the latest event reliably comes through.

Good point about the X event filters. I had tried for sure to go through Gtk, but couldn't get it done, not even with the GdkDevice XInput abstraction layer.
Onboard is special, we needed pointer events unaffected by X grabs, see bug #905636. There appears to be no straight way to achieve this. Even the finished XInput event source is riddled with tricks and compromises. A bug fix for Gtk would not have been trivial at all and In fact, trying to cleanly abstract what I did there in a portable toolkit like Gtk seems out of reach to me.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.