Thanks for the information, Arnaud. Now I'm sure it is periodic. You can check with xev the value of the timestamp to see when it's about to wrap around, which is one clue I got for the last time's failure. It happened the same day as yours, somehow confirming your suspect about the origin of the timestamp. You've found out that it happens every 2^32, not 2^31 as I thought, milliseconds. According to my calculations the next one will be on May 19 at 07:06:16 UTC, but xev will tell.
The patch assumes that the difference between LastFocusChange and LastTimestamp is less than 2^29 milliseconds in either direction (that's about 6 days). A pitfall is that it assumes that someone will focus a window within that period. If that doesn't happen, then there'll be another 6 days during which no window can be focused. Presumably the user will have restarted wmaker by then. The condition that that comparison tries to detect is whether the last event predates the last focus change, and reject it if so. I seem to recall from reading a bug report that there was a race condition that was triggered when events came out of order or something, that this comparison fixed (creating a new problem, though). That was a lot of time ago, so my memory can fail. I will try to come with a better fix, but I don't promise anything. Perhaps assuming the unsignedness of the Time type and the implicit modulo operation in C can help improve things. Also the patch is a bit "contaminated" with my tendency to maintain compatibility with very old or very rare systems, in a way that is too overkill for this situation. -- Pedro Gimeno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
