Cursor moves but does not show drawn line in real-time

Bug #199999 reported by Ryan Sinn
This bug report is a duplicate of:  Bug #184996: Annotation tools are broken in hardy. Edit Remove
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
xournal (Ubuntu)
New
Undecided
Unassigned

Bug Description

Binary package hint: xournal

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=8.04
DISTRIB_CODENAME=hardy
DISTRIB_DESCRIPTION="Ubuntu hardy (development branch)"

This has been a problem for me since I started using Hardy 3 weeks ago, I did not have this issue with Gutsy. I was hoping it'd just fix itself :)

I have the default X config from Hardy... the default X config in gutsy worked fine.

When trying to draw in Xournal -- when you press the pen to the tablet OR click the left-button on the mouse and move it in the journal page area... A single "point" of Ink is displayed where the pen initially touched the page or where you first clicked the mouse. However as you move the cursor around the journal page the ink line that should draw underneath the cursor does not appear.

When you pull the pen away from the tablet or release the mouse button the line that you were drawing appears.

This makes it very difficult to write because you don't know exactly how you're writing or drawing.

Revision history for this message
Ryan Sinn (ryan-sinn) wrote :

I tested the pen / drawing functionality in CellWriter and that works great... the lines are nice and smooth and they follow my cursor immediately while I'm drawing / writing...

So this must be something inside of Xournal? And not related to X? Not sure.

Revision history for this message
Ryan Sinn (ryan-sinn) wrote :

Unchecking "Use XInput" under the "Options" menu in Xournal fixed my issue.

You can close this bug.

Revision history for this message
Ryan Sinn (ryan-sinn) wrote :

Actually looks like this might be a symptom of a larger issue due to wacom drivers and Xorg 7.3...

Here's more detailed information on the bug...
http://sourceforge.net/tracker/index.php?func=detail&aid=1891727&group_id=163434&atid=827733

So maybe we don't close this or we point it at this upstream bug...

From the link above:
* Short fix without recompiling: uncheck the "Use XInput" box in the
Options menu (perhaps simplest given that high-resolution input seems to be
broken with the current version of linuxwacom). Or else, check both
"Use XInput" *and* "Discard Core Events", but this may break ability to do
anything with a mouse depending on your xorg.conf. In both cases, you won't
get better than screen resolution (the resolution of the wacom
tablet is decreased to screen resolution when using linuxwacom 0.7.9 with X
7.3). But do not keep "Use Xinput" checked and "Discard Core Events"
unchecked as is the default.

* Slightly better fix (but it won't make things any better for the time
being, it just fixes the extra ugliness, slowness, and display lag when
"Use XInput" is checked and "Discard Core Events" is unchecked -- and
should make things better once linuxwacom is fixed): add a new line after
line 2525 of src/xo-callbacks.c (in version 0.4.1; in general this goes
after the line containing a call to fix_xinput_coords() at the beginning of
on_canvas_motion_notify_event()), containing:

if (!is_core) ui.is_corestroke = FALSE;

End of the answer if all you care about is "how". If you want to know
"why", read on.

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

Other bug subscribers

Remote bug watches

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