(0.4.7) Draws horizontal and vertical lines at random.
Brought to you by:
andreasb123,
auroux
Menu
▾
▴
#112 (0.4.7) Draws horizontal and vertical lines at random.
open
nobody
None
5
2014-08-18
2012-08-10
Anonymous
No
Since upgrading to Xournal 0.4.7 I've noticed that Xournal sometimes draws strange horizontal and vertical line segments. The bug was not present in 0.4.5, but I do not know whether it was present in 0.4.6 since it doesn't compile for me.
Screenshot attached.
Assuming this is the same behavior I have on my test system: I believe this is not caused by the update to 0.4.7 but by updates to X or GTK libraries, or a change in your xournal config settings. On my system at least, the random lines come from spurious events from other xinput devices than the one you're drawing with (in my case, pressing the pen on the screen at the wrong angle sometimes activates the trackpoint or touchpad as they protrude too much).
I've just added a new behavior and a new config option, "ignore_other_devices", enabled by default. This setting causes events from devices other than that being used to draw to be discarded. It fixes my problem, I don't know if it fixes yours.
Please get the CVS or GIT code (they're identical) and let me know if the new behavior fixes things for you.
Anyone else: if you believe that ignore_other_devices should be disabled by default, not enabled, I'd be interested in hearing your arguments.
Denis
I also have the same problem in Mint Linux 13 using a thinkpad x60t after upgrading from 0.4.5 to 0.4. going to try the git version.
Updating from 0.4.7 to the latest Git version also fixed the same issue for me.
I am anxious to try
ignore_other_devices, as I have been plagued with this problem on my Fujitsu p1630 (which has an odd sort of touchscreen manufactured by Fujitsu). (DeselectingUse Xinputgets rid of it but at the cost of making everything kind of crappy.) However, I have been unable to figure out how to obtain the new version. When I click on theCodelink at the top of this page, it takes me tohttps://sourceforge.net/p/xournal/code/ci/master/tree/
which has at the top a link called
Download Snapshot. This link ultimately gives mehttp://sourceforge.net/code-snapshots/git/x/xo/xournal/code.git/xournal-code-6d4c59eb9bd2b50c661701a6c5b5fbcfc617eb17.zip
in which all the files are timestamped
13-12-03 04:49; I was confident this was the right thing until I compiled and installed it, whereupon I discovered not only that the stupid lines had not gone away but that there was still no sign of anignore_other_devicessetting. Is it supposed to be in the GUI? Am I just failing to see it? Is that archive even what I want? And, if not, how do I get the right thing? Please, have pity.The snapshot of the git repository that you downloaded does have that
option in there, and it is enabled by default (i.e. you don't need to do
anything to make it active). There's no gui interface item for it, but
if you go to Options -> Save Preferences, you'll find that a line
"ignore_other_devices=true" has been added into your .xournal/config
file. (if not then you are not running the new version you just compiled.)
Depending on what is causing the interference between different input
devices and which one gets to speak up first, the new option may or may
not filter things out well. The one case where we know it really helps
is the Lenovo X series tablets where somehow drawing on the screen
sometimes activates by accident the trackpoint or the touchpad
underneath it, which results in weird pointer motions. On your system,
if it is the same touch input device that sends the valid pen motion
events and the spurious events that cause the random lines, there's just
no easy way to separate the two.
Denis
Thank you for the remarkably prompt reply, and I apologize for the stupid question. I see that I do have that line in my ~/.xournal/config file, so apparently it just doesn't fix the problem. If there is anything you can think of that I could do to help discover what causes this infuriating behavior, please do not hesitate to request it. A notable fact about the spurious lines is that they always appear immediately after either the undo or eraser function has been invoked--i.e. the next attempted stroke produces random, straight, usually vertical or horizontal, line segments (sometimes one of each, forming a continuous track), often connected to the starting point of the intended stroke, but sometimes on the previous page--thus necessitating another click of the undo button, which in turn causes the next attempted stroke to produce crap, rinse and repeat some random number of times until it finally stops or I turn off
Use Xinput.I did consider it remotely possible that spurious events were being generated by the 'pointing stick' which this computer has instead of a trackpad; it lies directly under the display panel (tablet, I guess) when I'm using Xournal. True, the stupid lines still happen if I write on the screen without folding the computer into tablet mode first (so the pointing stick is visibly untouched), but I wasn't sure if it had to be caused by mechanical contact. As for the possibility that the touch panel is interfering with itself: Well, I'd love to know how that would be possible. It's a resistive touch panel that requires actual contact and pressure to register anything. It basically only responds to the plastic stylus or a firm press with a fingernail; in fact, pressing on the screen with my thumb just now had no effect.
I suppose this could be a different bug. Or conceivably even just a hardware fault, except that it's so strongly correlated with particular states of the software.
Is it actually the case that, whenever you click in a toolbar (using the
touchscreen or stylus) and then click in the drawing area (with the
active tool being the pen or similar), a line is drawn from the place
you clicked in the toolbar to the place you started drawing in the
drawing area? (unless the toolbar lies in the region where a different
page would be visible if the window were larger, in which case a line is
drawn on that page) ?
I suspect that the following happens, for some incomprehensible reason:
when xinput is enabled and you click in the toolbar, for some reason the
XInput button press event is passed on to the drawing area window and
processed as if that location were part of the drawing area (so xournal
thinks you're beginning to draw a line), but for some even weirder
reason the corresponding button release event is never passed on (so
xournal thinks the pen is still down, and by the time you press
somewhere in the drawing area it's line you were drawing really fast and
teleported from one place to the other).
You could probably check this by recompiling with the line #define
INPUT_DEBUG near the beginning of src/xournal.h uncommented (remove the
initial "// " so it starts with the "#"), then running xournal from a
terminal window. When you click in the drawing area it should show a
"ButtonPress ..." line, when you release it should show a "ButtonRelease
..." line, and in between there'll be some "MotionNotify ..." lines
tracking the pointer motion. In principle when you click in the toolbar
nothing at all should show up (the click doesn't get passed to the
drawing code), but I suspect that in your case you get the ButtonPress
and no ButtonRelease. This would explain the observed behavior. Also, in
principle there should be a "leave notify" record in the log each time
you go from the drawing area to something else eg the toolbar, and an
"enter notify" record in the log when you go from the toolbar back to
the drawing area. I suspect one or both may be missing since normally
"leave notify" triggers a reset of the XInput system to avoid precisely
this sort of bug with faulty versions of the GTK libraries.
I am not sure what might be causing this bug though -- event processing
in X and GTK is black magic, and it could be either an issue with the
order in which the touchscreen driver for Fujitsu's tablets sends the
"core" and "Xinput" click events, or an issue with GTK2's event
processing (either a bug in your version of GTK2, or a change in
standard behavior that requires a change to the xournal code to be
compatible with the new behavior).
What is the version of your X server (package xorg-x11-server-Xorg or
similar depending on distribution), and of your GTK2 libraries (package
gtk2 or similar) ?
Denis
This is an excellent idea; I think you're on to something. The behavior is only semi-reproducible (it seems to happen less when I'm trying to get it), but I see that it does happen only when I have just pressed a toolbar button (or other UI element, such as the scroll bar on the side). On the other hand, the unwanted line segment does not always point toward the button (or UI element) in question. When it does, it extends all the way to the edge of the page; when it does not, it tends to be horizontal, and relatively short (i.e., the ButtonPress event would be located in the drawing area). I will compile with the modification you suggest and report back as soon as possible. Maybe we can solve this!
I'm running Kubuntu 12.04, and it is using packages
xorgandxserver-xorgboth with version 1:7.6+12ubuntu2 andxserver-xorg-corewith version 2:1.11.4-0ubuntu10.14;X -versiongivesThe
gtk2libraries are, I assume, provided bylibgtk2.0-0, which has version 2.24.10-0ubuntu6.It might also be worth mentioning that the touchscreen driver is supplied by the fujitsu-tablet kernel module (version 20120404-gerlach) from Magick Rotation 1.6.2 (I hear this module was added to the kernel as of version 3.4, but I've got 3.2).
So I'm not sure how to interpret what I'm seeing. There's no difference in the log between those times when I start drawing and it doesn't make a silly line, and those times when it does, except for the implausible coordinate value on the
ButtonPressevent in the latter case. Here is a typical example:The
leave notifyevent was apparently generated when I pressed the toolbar button to change to the pencil (from the eraser). As far as I could tell, theenter notifyandButtonPressevents appeared as I began the stroke. It's hard to be as precise as I would like, but [the stylus touches the screen], [theenter notifyevent appears], and [theButtonPressevent appears] are simultaneous to within a resolution of less than half a second. The spurious line in this case points straight up, not toward the pencil button on the toolbar.I think there is at least one negative coordinate value (on the ButtonPress event) whenever this happens.
The spurious lines don't occur when drawing with the mouse ('pointing stick'), and the
leave notifyandenter notifyevents generated when I'm moving the pointer with the pointing stick appear exactly as the pointer crosses the boundary of the drawing window. (The pointing stick is identified as (PS/2 Generic Mouse) in theButtonPress,MotionNotify, andButtonReleaseevents.) This probably has something to do with the fact that there is a distinction in the case of that device between [moving the pointer] and [moving the pointer with a button depressed]; moving the pointer with the stylus is accomplished only with the stylus pressed against the screen, a state which is analogous to holding down the left button while moving the pointing stick. To clarify, this is different from the behavior of a Wacom tablet/stylus such as the one on which I've been using Xournal for years; with such a device, the pointer can be moved on the screen by hovering the stylus sufficiently near, but drawing occurs only when it is brought into contact (contact behaves analogously to depressing the left button on the mouse in other contexts as well).There is thus no distinction even at the hardware level between
enter notifyandButtonPress; I suspect now that this is the root of the problem. It may be necessary to do something special to compensate. (So, if I'm right, this is a different bug.)The likeliest explanation, then, is a bug in the X driver for the touch
panel, which causes it to send a ButtonPress XInput event with some of
the coordinates (in the example you post the y coordinate) still those
of the previous touch event (in the toolbar) rather than those of the
current touch event (or in any case, something is wrong with the event
coordinates: -15 in the y value of the event data passed by GDK/GTK
means 15 pixels above the top of the drawing area, which is within the
toolbar region, not in the drawing area; whereas the x coordinate seems
to have been updated properly).
Synaptics touchpads used to do this too, and Xournal does have an
attempted workaround: it asks the driver to confirm the location of the
button press event, by calling gdk_device_get_state() (which calls
XQueryDeviceState) to get the latest position of the device pointer.
Alas, unlike the synaptics driver, the Fujitsu touch driver seems to
persist in its error and continue to claim that the position is the old
one when queried in this manner.
I am not sure how to work around this in xournal cleanly. You should
report the issue as a bug in the touchscreen driver (perhaps including
the DEBUG output you posted, the first two paragraphs of this reply, and
a link to the relevant part of this discussion (use "link" in the
upper-right corner of the comment you posted with the DEBUG output to
get a URL that will point to this part of the discussion).
In the meantime, a dirty workaround (unsuitable for everyone's use since
it discards the starting point of all strokes after the fact, which is
just annoying for users who don't have this bug): in finalize_stroke()
in src/xo-paint.c, insert two lines as follows to discard the first
point: at line 303 of src/xo-paint.c (after the first 6 lines of
finalize_stroke()), insert the lines
if (!(ui.cur_brush->ruler) &&
(hypot(ui.cur_path.coords[0]-ui.cur_path.coords[2],ui.cur_path.coords[1]-ui.cur_path.coords[3])>10.0/ui.zoom))
{ ui.cur_path.coords[0]=ui.cur_path.coords[2];
ui.cur_path.coords[1]=ui.cur_path.coords[3]; }
Recompile and try it: the spurious segment should now disappear when you
lift the pen at the end of the stroke whenever it's 10 pixels or longer
(the meaning of the 10.0 near the end of the second line). (I hope, I
haven't tested). Try this with "Pressure sensitivity" disabled in the
options menu.
I'm not sure if the fix is suitable if you have "Pressure sensitivity"
enabled (if it's a valid option on your system at all? not sure what the
capabilities of the Fujitsu device are) -- in that case it might delete
the bad point in internal structures but not refresh the display. If you
need Pressure sensitivity I can probably figure out what else to add to
cause the refresh in that case as well.
Denis
(See reply below; I posted it incorrectly.)
So, first of all I apologize for taking so long to reply. (I unfortunately wasn't able to work on this during the winter break, so homework and such are competing with it.)
I applied the patch from your http://sourceforge.net/p/xournal/bugs/112/#000f/bf6c and, to my surprise, it seemed to make no difference; I've still got the spurious lines following button press events outside the draw area. I must admit that I don't quite understand how the patch works; does
hypot(ui.cur_path.coords[0]-ui.cur_path.coords[2],ui.cur_path.coords[1]-ui.cur_path.coords[3])mean "the length of the line from (x=ui.cur_path.coords[0], y=ui.cur_path.coords[1]) to (x=ui.cur_path.coords[2], y=ui.cur_path.coords[3])"? I.e. when the distance between two successive coordinate pairs is greater than 10, the first of the pair is discarded? But this is in
finalize_stroke(), so does that mean the second coordinate pair has to be the last one, i.e. I have to lift the stylus precisely at the end of the unwanted line segment in order for it to be deleted? That is functionally impossible, since I don't even see the unwanted line segment until I've started to draw, and by then it's too late.Is the coordinate value that appears in a debug output line like this:
DEBUG: ButtonPress (Fujitsu Component USB Touch Panel) (x,y)=(231.49,233.83), button 1, modifier 0being used as as the value of (ui.cur_path.coords[0], ui.cur_path.coords[1]), or something like that? If so, could one simply discard such an event---i.e. coordinate pair---when either coordinate differs sufficiently from the corresponding coordinate of the immediately following
MotionNotifyevent? Because if such a modification were possible, I think it would fix the problem cleanly enough to be incorporated into the main code.Last edit: Archelon 2014-02-22
Yes, the test concerns the length of the line between the first point of
the stroke (x=ui.cur_path.coords[0],y=ui.cur_path.coords[1]), and the
next point of the stroke. Unless I messed up somewhere, the first point
should correspond to the reported position of the ButtonPress event, and
the second point to the first MotionNotify event that follows it. So the
idea was that, when you lift the pen (finalize_stroke() is called upon
receiving ButtonRelease), the ButtonPress position and the MotionNotify
position received just after it are compared and, if they mismatch, the
ButtonPress position is modified a posteriori. While the modification
only occurs when the stroke is finished, it affects the first two points
of the stroke, not the last two -- so it should still work.
(There are of course other places where one could have done this fix,
e.g. in continue_stroke() that gets called at the first MotionNotify,
and arguably this would have been a more logical place to insert a
change so as to make it effective immediately; but this should be more
or less equivalent).
I am confused -- can you do the following: start drawing on a blank
page, until the bug happens once; then save the xoj file and send it to
me. I will look at the coordinates of the last stroke in the xoj file
and try to figure out why it didn't get corrected. My e-mail address =
my username at math.berkeley.edu
Thanks,
Denis
I have now sent you the requested materials. And you have my undying gratitude for your efforts here.
Try disabling Options -> Pressure sensitivity, this should make things work.
Specifically: you modified xo-paint.c just fine, but the approach used
(modifying the first point of the stroke retroactively when you lift the
pen) only works for strokes drawn without this option enabled.
This is because when Options -> Pressure sensitivity is disabled, the
whole stroke is later redrawn as a single polygonal line, so the
modification gets displayed; while when it is enabled, the stroke is
kept as separate line segments of various widths and doesn't get
redrawn. So with the option enabled, the data stored in the .xoj file
gets updated, but the display doesn't. If you re-open the .xoj file you
sent me, you will see that the long line segments are not there -- but
they never disappeared from the display because of the variable-width
behavior enabled by the "pressure sensitivity" option (even though your
pen does not have pressure sensitivity, but xournal has no easy way of
knowing that).
Can you confirm that things work when you disable Options -> Pressure
sensitivity?
In any case, this is one more reason to rewrite the patch in a better
way, so it works in all situations. (Another situation where things
wouldn't work currently is for the ruler tool; that's fixable as well.)
Note however that many other tools, like the hand tool or the selection
tools, are just not set up in a way where it is easy to catch and modify
afterwards a faulty ButtonPress location, so they won't work well with
your pen at all until the underlying bug is fixed. For this reason you
should really try to get the bug in the pen driver to be corrected.
Denis
I am delighted to report that the fix does work as expected when I have "pressure sensitivity" turned off. Marvelous!
I will talk to the people responsible for the fujitsu-tablet kernel module. I am curious, though, whether there exists any resistive touchscreen device on which Xournal is known not to exhibit this problem.
Before I disappear for a while to get some homework done, I should finally answer a question you asked a long time ago: The Fujitsu P1630 touchscreen has no pressure sensitivity.
Also, I have another question for you. The final step of the instructions in the INSTALL file is to run (as root)
make desktop-install. This does nothing for me (I'm on Kubuntu 12.04), and I don't know how to get the file associations and such; when I install Xournal from the repositories (actually I've been using the webupd8 ppa), I get a 'Xournal' item on the Kickoff menu, automatic correct handling of .xoj files from the file manager, and so forth. What ismake desktop-install, anyway? I could presumably reverse-engineer it for KDE (I'm guessing KDE is the issue) if I knew exactly what it does.