#149 Occasionally assumes incorrect cursor coordinates

[qwach]

Sometimes, Xournal's interface seems to stop responding - the "hover glow" when the cursor is positioned on a UI element is still there, but no amount of clicking will actually activate them, and the canvas can't be drawn on in the normal manner either. After some experimenting, I figured out that the cause was Xournal somehow using incorrect cursor coordinates - if I position the mouse cursor outside of the Xournal window to the bottom left, click and drag, I can draw, select etc. perfectly. The offset stays constant, and the incorrect coordinates can apparently be corrected by maximizing and unmaximizing the window, but I'm not 100% sure. Hard to reproduce too.

[Denis Auroux]

That is interesting and disturbing. Obviously I'd like to fix this, but
can't reproduce the problem on my system.
What kind of device are you using to draw when things freeze -- a tablet
device (wacom or other kind, what driver?)? something else? I assume
this is in linux, or is it in windows? I assume this would never happen
if "Use xinput" were disabled in Options (though that's of course not a
viable setting for pen users because of the low quality of the inking
without xinput).
Anyway, any further information you can gather on how to reproduce this
would be very useful. Thanks in advance!

[qwach]

Sometimes, selecting another window and then the Xournal window again also solves the problem, for those in need of a workaround. Using Ubuntu 14.04 + tablet PC with Wacom pen, going to test with disabled xinput.
I think the problem only occurs if the screen dimensions change/have changed at some point (rotate tablet PC screen, switch to external screen, ...). Still haven't managed to reliably reproduce the problem, will give it another try.

[qwach]

I've found one simple partial test case:

- open Xournal
- snap Xournal to one side of the screen by dragging with the mouse
- try to draw with the pen, the mouse or anything else

Result: pen strokes aren't drawn at the position the pen/cursor actually is at, but where they would have been drawn in the Xournal window before it was snapped. Switching to another window and back fixes this one, and it indeed does not happen with XInput disabled. The interface is unaffected - I've also seen the positioning being correct on the canvas, but incorrect in the interface, so this looks like two separate bugs.
This happened using just the tablet PC through Ubuntu/Unity. Also, any useful debug options?

[Denis Auroux]

Hmm, can anyone else reproduce this bug? (presumably only on Unity --
this seems to me likely to be either a Unity bug or a GTK bug exposed by
some change in behavior by Unity).

My guess based on what you describe is that Unity sometimes fails to
notify xournal properly that the position of its window changed (in that
case it would be a Unity issue), or does it in a way such that not all
interface sub-elements know they have moved (in that case it would be a
GTK issue) -- though I am surprised that it would specifically affect
XInput events only.

There is one thing you can try doing: in src/xournal.h, try uncommenting
the line

define ENABLE_XINPUT_BUGFIX

(i.e., remove the "//" at the beginning) and recompiling, then running
the freshly recompiled version of xournal and seeing if it fixes this
particular issue.

This is not a good general solution: this setting works around issues in
old versions of the GTK libraries (got fixed around 2010, so shouldn't
be needed anymore), but doesn't handle screen reconfiguration (e.g.
attaching an external monitor or rotating the display) properly. Still,
it'd be good to see if the bug occurs with it or not. (In particular,
this triggers re-asking the X server about the position of the window,
so if it still gets the wrong origin that means everyone is very
confused -- not just xournal and GTK but also Unity and even the X server.)

If the bug disappears upon enabling the alternative bugfix code in
xournal, this gives useful information: my bugfix asks the X server for
the position of the window each time, whereas in the "standard" GDK
XInput code, gdk_input_translate_coordinates() trusts the contents of
the variables impl_window->input_window->root_x and root_y (these get
set at initialization time and also upon receiving ConfigureNotify
events -- which we should always get, but if Unity sometimes doesn't
send them properly or they don't propagate properly down GTK's chain of
subwindows, we might lose it).

Denis

[qwach]

And another case that causes problems when using XInput:

- Select the text tool
- Click on the canvas
- Select a different tool (example: the pen)
- Try to move the scrollbars/select a UI element

Result: The UI will be "frozen" if you try to execute an action in the next few
seconds (hover glow, but no reaction when clicking/dragging).
If you try to move the scrollbar, the pen will draw on the canvas below the
scrollbar instead. Problem seems to be less severe/obvious when no scrollbar is present.

[qwach]

Haven't tried with ENABLE_XINPUT_BUGFIX, will tomorrow. This is all using the newest code from the Git repository.

[qwach]

Test results: ENABLE_XINPUT_BUGFIX fixes the window snapping case, but not the text tool case.

[Denis Auroux]

Test results: ENABLE_XINPUT_BUGFIX fixes the window snapping case, but
not the text tool case.

Indeed, this bugfix in xournal's code can't fix the responsiveness of
scrollbars or other interface elements -- it only affects how the
drawing area processes events. If a scrollbar is also confused about its
position on screen then it won't get clicks properly either...

By the way: does the window snapping issue also happen in Gimp when you
enable the pen as input device and draw with the pen (i.e., after
snapping the Gimp drawing window, does the pen start drawing in the
wrong place just as in xournal) ? This would be confirmation that the
bug is not xournal-related. (But, because Gimp sets up its window
hierarchy differently from xournal, it's also possible that it somehow
avoids the issue).

Ah, another thing you can do to test my theory that ConfigureNotify
events are not being received in a timely manner when you snap the
window is to run, from a terminal,

xournal --gdk-debug=events

Brace yourself for lots of output whenever you do anything, but in
particular as you move the window you should be seeing a bunch of lines
that look like

Gdk-Message: configure notify: window: 52428803 x,y: 10 36 w,h: 1280 800

(x,y should be the on-screen coordinates of the xournal window's
top-left corner).

(Oh, interesting, Gnome 3 also has a bug whereby the configure notify
events for snapping to the left side of a secondary monitor gives the
wrong (x,y) position in the configure-notify event. But... GTK doesn't
actually use the x,y coordinates in the configure notify event, instead
it re-queries the window position from the X server -- at least with the
version of the GTK code that I've looked at. So it doesn't matter if the
configure-notify event has wrong data in it, what matters is that it
gets sent in a timely manner.)

Do you see indeed a "configure notify" event pass by when you snap the
window and the drawing area goes into a confused state about where to
draw? Or does the "configure notify" arrive only later on, when xournal
becomes un-confused about the position of its window?

Anyway, I'd suggest eventually filing a bug report against Unity, or
perhaps GTK+ but I think it's likely to be Unity, concerning the issue
of drawing in the wrong location upon snapping/moving the window. The
other issue with interface unresponsiveness is too subtle to be
diagnosed easily; it might or might not be caused by the same bug, hard
to tell at this point. I'd like to focus first on the "main" issue with
the wrong event coordinates, which seems more pressing and easier to
diagnose. The issue is essentially something like:

---

In Ubuntu release xx.yy, with Unity version xx.yy and GTK+ 2.24.zz,
XInput-aware windows in GTK2 applications are not always aware of their
position on screen after being moved or snapped. The input event window
then translates extended input events for devices in screen mode
according to its former location on screen rather than the current one.

To reproduce in Xournal: ...
[if appropriate: To reproduce in Gimp: ...]

Technical note from the Xournal developers:
GTK2 relies on ConfigureNotify events to be notified when the window
position stored in its internal data structures needs updating. It then
updates the internal data structure by querying the X server for the
window's on-screen origin. The internal data structures are then used to
translate input event coordinates for screen mode devices (see
gdk_input_translate_coordinates() in gdk/x11/gdkinput-x11.c and
_gdk_input_configure_event() in gdk/x11/gdkinput-xfree.c). The observed
bug suggests that the ConfigureNotify event does not reach the window
properly.

The problem disappears in Xournal when recompiling with #define
ENABLE_XINPUT_BUGFIX enabled in src/xournal.h, which causes xournal to
manually convert raw extended input event coordinates using
gdk_window_get_origin() to request the window origin from the X server,
rather than relying on GTK2's event processing. This suggests that
either Unity doesn't properly send ConfigureNotify events in the manner
expected by GTK2, or for some other reason the ConfigureNotify doesn't
propagate properly to the hierarchy of XInput-aware windows.

---

But before doing this, perhaps test further the theory about
ConfigureNotify events not being sent properly when you snap.

If you have a functioning Gnome 3 or KDE installation on your system and
it's easy to try out a session under one of those, before filing a bug
report against Unity I'd also try and see just to make sure that the
problem goes away with those, as I suspect it does.

Denis

[qwach]

xournal --gdk-debug=events
If I try that, all I get is "Invalid option". configure doesn't recognize something like --enable-debug, and I can't find anything in the code either.

[Denis Auroux]

On 04/25/2015 11:30 AM, qwach wrote:

xournal --gdk-debug=events
If I try that, all I get is "Invalid option". configure doesn't
recognize something like --enable-debug, and I can't find anything in
the code either.

It's a GDK/GTK command-line option, so there's nothing in the xournal
code related to it. I assume the option not being recognized means that
Ubuntu's GTK2 packages don't have debugging enabled. Too bad. Oh well.

How about seeing whether Gimp has the same problem of getting confused
about the position of the pen rel. its window? (in Gimp, Edit -> Input
Devices, select the pen, put it in Mode: Screen, then use it to draw.
Then try to reproduce what caused xournal to be confused about the
location of the window -- was it snapping to the side of the screen?)

Denis

[qwach]

GIMP works fine. After installing various debug packages, I can now run GTK 3 programs with GDK debug enabled, but not GTK 2 programs (such as Gimp), will try to find some more.

[qwach]

So apparently -dbg packages only add symbols for debugging the libraries themselves. Instead, I've now built GTK 2/GDK from the Ubuntu sources (apt-get source/dpkg-buildpackage) with --enable-debug=yes added in debian/rules, and GDK debugging works if I LD_PRELOAD the right library. Will test more thoroughly as soon as I have time.