3

I have a Tcl/Tk program (C and script) which processes X-input events from a graphics tablet (Wacom). XSelectExtensionEvent() is called such that the X server reports these events (like pen motion), and Tk_CreateGenericHandler() is used to register a handler function (which then invokes a Tcl proc).

Everything was working fine up to Ubuntu 20.04 with Tk 8.6.10, but the callback function is not called any longer for these events (like motion events of the pen) in Ubuntu 22.04 with Tk 8.6.12. However, if I use XNextEvent() to get the events directly, I see the motion events. xev also sees the events, so it doesn't seem to be a driver problem.

However, I need to use the Tk event handling to integrate the events into the Tcl/Tk script, so using XNextEvent() is not a solution.

Does anyone know whether the event handling was changed in Tk lately? Or any other idea what could have changed? Thanks a lot!

Ralf
  • 1,203
  • 1
  • 11
  • 20
  • 1
    Nothing's changed recently like that in Tk as far as I know. Try putting a debug print immediately after the `XNextEvent()` call in the bottom of Tk's code. (You'll need to build your own from source to do this.) – Donal Fellows Apr 10 '23 at 07:47
  • @DonalFellows: Thanks. I found the call to `XNextEvent()` in `unix/TkUnixEvent.c`, function `TransferXEventsToTcl()` (8.6.10); is that the one? I also saw that there is a comment mentioning the possibility of missing events (something about the focus). – Ralf Apr 10 '23 at 09:05
  • 1
    That's the one, it's where events enter Tk's processing pipeline (there's a few bits below that that shouldn't matter, providing the event really is coming from the server; that should be the case here). – Donal Fellows Apr 11 '23 at 06:57
  • @DonalFellows: We followed your suggestion. The `XNextEvent()` in `TransferXEventsToTcl()` reports the pen motion events, but our handler is not called. Any idea why this could happen? – Ralf Apr 13 '23 at 09:34
  • @DonalFellows: There's a strange mechanism in Tk_QueueWindowEvent(), the comment says: "The new event is a motion event so don't queue it immediately; save it around in case another motion event arrives that it can be collapsed with it". Could that fail? – Ralf Apr 13 '23 at 14:16
  • @DonalFellows: It doesn't seem to be related to the collapsing of motion events. We switched this on and off using `Tk_CollapseMotionEvents()`, but it doesn't have an effect. Collapsing was also off by default. – Ralf Apr 14 '23 at 07:29

1 Answers1

1

I might have found the issue. Since commit 3682b41 (Feb 5, 2020), all X-input events with a type greater than MappingNotify are ignored. However, this also ignores some/all events of the X input extension, since the extension event types are not constants as described in X Input Device Extension Library:

Extension event types are not constants. Instead, they are dynamically allocated by the extension's request to the X server when the extension is initialized.

Accordingly, the problem could be solved by adjusting the following condition in tk/unix/tkUnixEvent.c and (re)compiling Tk.

if (event.type > MappingNotify) {
    continue;
}

This is possibly a bug and will (hopefully) be fixed in a future version of Tk.

Adrian Mole
  • 49,934
  • 160
  • 51
  • 83
Jan O.
  • 26
  • 4