In XInput mode Keyboard responds to drags with delay and jumps

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.

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.

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?

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.

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.

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.

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

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!

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.