#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.

Discussion


  • Anonymous
    2012-08-10

    Stimulants arent successful for every a single both. For lots of little ones, it might consider lengthy to determine can be a result of stimulants. For other young children, the outcomes will occur quickly having said that they are really afflicted an too much total of from the severe unwanted outcomes. Consideration deficit hyperactivity dysfunction pure solutions depend a go.
    http://jandjbigyard.com/contactus.php

     
    Last edit: Anonymous 19 hours ago
    Attachments
  • Denis Auroux
    Denis Auroux
    2012-08-11

    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

     
  • P R
    P R
    2012-11-28

    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.

     
  • qwach
    qwach
    2013-11-29

    Updating from 0.4.7 to the latest Git version also fixed the same issue for me.

     
  • Archelon
    Archelon
    2014-01-28

    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). (Deselecting Use Xinput gets 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 the Code link at the top of this page, it takes me to
    https://sourceforge.net/p/xournal/code/ci/master/tree/
    which has at the top a link called Download Snapshot. This link ultimately gives me
    http://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 an ignore_other_devices setting. 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.

     
    • Denis Auroux
      Denis Auroux
      2014-01-29

      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

       
  • Archelon
    Archelon
    2014-01-29

    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.

     
    • Denis Auroux
      Denis Auroux
      2014-01-30

      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

       
  • Archelon
    Archelon
    2014-01-30

    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
    xorg and xserver-xorg both with version 1:7.6+12ubuntu2 and
    xserver-xorg-core with version 2:1.11.4-0ubuntu10.14; X -version gives

    archelon@ingelrayok:~$ X -version

    X.Org X Server 1.11.3
    Release Date: 2011-12-16
    X Protocol Version 11, Revision 0
    Build Operating System: Linux 2.6.42-37-generic x86_64 Ubuntu
    Current Operating System: Linux ingelrayok 3.2.0-58-generic #88-Ubuntu SMP Tue Dec 3 17:37:58 UTC 2013 x86_64
    Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-58-generic root=UUID=db956c07-4b92-4994-b2d0-005aa8f215ab ro quiet splash vt.handoff=7
    Build Date: 16 October 2013 04:41:23PM
    xorg-server 2:1.11.4-0ubuntu10.14 (For technical support please see http://www.ubuntu.com/support)
    Current version of pixman: 0.30.2
    Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.
    archelon@ingelrayok:~$

    The gtk2 libraries are, I assume, provided by libgtk2.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).

     
  • Archelon
    Archelon
    2014-01-31

    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 ButtonPress event in the latter case. Here is a typical example:

    DEBUG: leave notify (mode=0, details=3)
    DEBUG: enter notify
    DEBUG: ButtonPress (Fujitsu Component USB Touch Panel) (x,y)=(346.37,-15.04), button 1, modifier 0
    DEBUG: MotionNotify (Fujitsu Component USB Touch Panel) (x,y)=(346.06,60.35), modifier 100
    DEBUG: MotionNotify (Fujitsu Component USB Touch Panel) (x,y)=(346.69,60.92), modifier 100
    DEBUG: MotionNotify (Fujitsu Component USB Touch Panel) (x,y)=(347.00,62.04), modifier 100

    The leave notify event was apparently generated when I pressed the toolbar button to change to the pencil (from the eraser). As far as I could tell, the enter notify and ButtonPress events appeared as I began the stroke. It's hard to be as precise as I would like, but [the stylus touches the screen], [the enter notify event appears], and [the ButtonPress event 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 notify and enter notify events 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 the ButtonPress, MotionNotify, and ButtonRelease events.) 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 notify and ButtonPress; 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.)

     
    • Denis Auroux
      Denis Auroux
      2014-02-01

      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

       
      • Archelon
        Archelon
        2014-02-22

        (See reply below; I posted it incorrectly.)

         
  • Archelon
    Archelon
    2014-02-22

    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 0

    being 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 MotionNotify event? 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
    • Denis Auroux
      Denis Auroux
      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

       
      • Archelon
        Archelon
        2014-02-22

        I have now sent you the requested materials. And you have my undying gratitude for your efforts here.

         
        • Denis Auroux
          Denis Auroux
          2014-02-22

          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

           
          • Archelon
            Archelon
            2014-02-23

            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.

             
  • Archelon
    Archelon
    2014-02-22

    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 is make 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.