workrave doesn't get any xrecord events

Bug #332716 reported by Martin Pool on 2009-02-21
This bug affects 1 person
Affects Status Importance Assigned to Milestone
workrave (Ubuntu)

Bug Description

Binary package hint: workrave

Workrave is a program to encourage you to take typing breaks. It's meant to monitor when you're typing or idle, a bit like xscreensaver might do.

This seems to be a new regression in Jaunty: workrave simply doesn't notice any keyboard or mouse input. The countdown stays at 5:00 even as I'm typing, and it doesn't show any mouse usage or keystrokes in the Statistics dialog. So for me, workrave is completely broken. I've checked that it is in Normal mode, and tried changing it in and out of that mode. My settings are attached.

Regular interaction with it's gtk dialogs works ok. It's just that it's not getting any RECORD events from the server.

Martin Pool (mbp) wrote :
Martin Pool (mbp) wrote :

I tried "gconftool-2 --recursive-unset /apps/workrave" and that did not help. I also shut down workrave, deleted ~/.workrave and restarted it and that did not help either. There are no messages on its stdout/stderr.

Martin Pool (mbp) wrote :

I rebuilt this with DEB_BUILD_OPTIONS='debug nostrip' and amongst other things it emits the following:

>>> X11InputMonitor::run
>>> X11InputMonitor::run_xrecord
>>> X11InputMonitor::init_xrecord
    X11InputMonitor::init_xrecord use_xrecord= 1
<<< X11InputMonitor::init_xrecord
>>> X11InputMonitor::terminate
>>> X11InputMonitor::stop_xrecord
<<< X11InputMonitor::run_xrecord
<<< X11InputMonitor::run
<<< X11InputMonitor::stop_xrecord
<<< X11InputMonitor::terminate
>>> X11InputMonitor::~X11InputMonitor
<<< X11InputMonitor::~X11InputMonitor

It does seem to be trying to use XRecord but not getting anywhere.
I wonder if this could be a configuration problem on my machine or interference with some other program, like if only one is allowed to use that at once?

Martin Pool (mbp) wrote :

Running gdb on this it seems that X11InputMonitor::handle_xrecord_callback is in fact being called, just once, and then it gets no further input.

Martin Pool (mbp) wrote :

It's called for the event XRecordStartOfData.

Tracing through init_xrecord shows:

the server claims to support version 1.13. It seems to pass plausible parameters to create the context and it then opens a separate datalink, which also seems correct. Then it enables the context on that datalink, and that immediately runs the callback with reasonable values to say XRecordStartOfData. Then after that the callback's not run again and we XRecordEnableContext doesn't return either.

Martin Pool (mbp) wrote :

OK, so it turns out that I did not have the "record" module loaded in my xorg.conf file. That file claims to have been generated by dexconf, but it may be wrong, or it may at least be an unusual setup. I'm going to add it and see if that helps.

If it does, I'd say this is still a workrave bug though maybe a minor one: it tries to detect whether or not the server supports XRecord, but apparently not successfully. Or arguably it's a xorg bug if it claims to support XRecord even when the module's not loaded.

This is a bit similar to <>.

Martin Pool (mbp) wrote :

Not quite so simple; X.0.log shows that record is loaded by default even if it's not specified there. That explains why the server reports that it supports the extension.

Martin Pool (mbp) wrote :

Downgrading to 1.8.5-6 from intrepid doesn't help.

Martin Pool (mbp) wrote :

I also tried running workrave in a fallback session, ie with only an xterm, and that didn't work either.

Martin Pool (mbp) wrote :

Bryce suggested running xtrace, and a trace is attached.

My interpretation of it is this: xtrace can't totally decode the RECORD extension messages but it can see them happening. Workrave opens a separate server connection for the callbacks, which seems to be how XRecord is documented to work, and in this trace that's (I think) the lines starting with 003:

Around line 998 after initializing connection 003, it sends a RECORD-Request(137, 5) gets a reply, and nothing more on that channel. So that would be consistent with what I saw in gdb in comment 5 above, and seems to show it's not just something in the client or libraries causing the events to be ignored.

recordstr.h has

52 #define X_RecordEnableContext 5 /* Enable interception and reporting */

description: updated
Bryce Harrington (bryce) wrote :

Comparing Xorg.0.logs from a working session (e.g. intrepid) with one from the current broken case might show something of use.

xtrace output to see what's getting communicated between server and client could be of use too. This could help show whether the xserver is delivering keyboard hit data or not. If it's delivering output to the client, then we know for certain the bug's in the client; otherwise, the bug is at a lower level (xserver, kernel, whatever.)

Since Hardy there's been a huge amount of change in the input subsystem of X. A lot of code and functionality has moved out of keyboard drivers and X, into the kernel via the 'evdev' module, and HAL is used to manage, coordinate, and configure it. This has been a pretty massive change, and a LOT of the recent keyboard/mouse regressions we've seen in the last two releases have been due to some aspect of this change. While this bug doesn't fit the normal symptoms of hal/evdev bugs, it is worth a mention. You could try forcing X to use the old non-hal/non-evdev keyboard/mouse handling and see if the issue goes away; if it does, that proves it's a bug in this new subsystem.

Bryce Harrington (bryce) wrote :

If you'd like to pursue this as an Xserver issue (which the evidence collected so far seems to point to), then please add an 'xorg-server' task and attach some additional debug info we need for X by running `apport-collect 332716`. I can push it upstream from there, and we can see if they have some useful suggestions.

I'd also encourage you to report this bug to the workrave upstream, in case they have insights. If it does turn out to be an Xserver problem, they may still appreciate knowing about the issue.

Bryce Harrington (bryce) wrote :

I think this is a dupe of bug 315456, which I've forwarded upstream to

Martin Pool (mbp) wrote :

The xserver side of this is probably bug 315456 as you suggested. I can't actually run the example there because it depends on other code but the symptoms are very similar.

Martin Pool (mbp) wrote :

> From the upstream bug:
> "RECORD is heavily broken at the moment and in desperate need of love. The whole event delivery changed under it. How quickly that'll get fixed, I don't know."

workrave supports another monitoring method to xrecord controlled by ifdefs. It would be nice if it were rebuilt in jaunty to do this...

Michael Rooney (mrooney) wrote :

I've duped this to the report with an upstream task which has been fixed. There is a link to the commit which addressed the issue so we should apply that patch or pull in a new upstream.

nanotube (nanotube) wrote :

Michael Rooney: you say the upstream has a fix? do you mean the workrave workaround, or the actual underlying xserver fix? and where can I find it?

On Sun, May 17, 2009 at 5:54 AM, nanotube <email address hidden> wrote:
> Michael Rooney: you say the upstream has a fix? do you mean the workrave
> workaround, or the actual underlying xserver fix? and where can I find
> it?

The issue has been fixed in Jaunty, if you are still seeing the bug
something is wrong and we'd need to debug that. Are you, and if so
what version of Ubuntu and workrave are you using? Let me know the
output of "lsb_release -a" and "apt-cache policy workrave". Thanks!

nanotube (nanotube) wrote :

Thanks for your quick response.

I'm not yet running jaunty, i'll grab a livecd and give it a shot...

That said, on the upstream xserver bug, they say they haven't fixed xrecord yet:

So is there some jaunty fix to that, that hasn't yet made it upstream?

Martin Pool (mbp) wrote :

2009/5/19 nanotube <email address hidden>:
> So is there some jaunty fix to that, that hasn't yet made it upstream?

I believe the fix in workrave makes it use a different xrecord event
type(??) to avoid the xorg breakage. An earlier comment on one of
these bugs links to the diff.

Martin <>

nanotube (nanotube) wrote :

Hm well, i was looking for an xrecord fix, since i'm using xrecord in another project.
I'll take a look at the workrave code change to see if that's something i could do as well. The exact diff would be helpful, but I can't see a link to it, would you post one if you have it on hand?

here's the diff. Looks to me (in my limited glance) that it uses the xrecord device events for key and mouse presses.

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

Other bug subscribers

Remote bug watches

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