Hi everyone, I've got a Qt5 client, which receives mouse input only and freezes soon and often. It gets stuck waiting for a reply from the server. Pressing a none-modifier key releases the lock and the client continues as normal until the next freeze.
I've traced the bug down to a regression implicitly introduced by: e6636b4 os: Compute timeout in milliseconds instead of struct timeval Which states "simplifies the code without affecting functionality at all". ;-) What happens is: - ServertimeBlockHandler() forwards a _big_ unsigned timeout to AdjustWaitForDelay() - AdjustWaitForDelay() takes this _big_ unsigned as int and it becomes a negative value - the negative value ends up as timeout in ospoll_wait() as parameter to epoll_wait() > epoll_wait() blocks due to the negative timeout XSyncValueSubtract() doesn't handle unsigned wraps. That's why we get a big unsigned from ServertimeBlockHandler(). Just imagine two XSyncValues: a = {.hi=1, .lo=1} and b = {.hi=0, lo=.2}. The result of XSyncValueSubtract(a - b) is presult = {.hi=0, .lo=4294967295}, where I would expect presult = {.hi=0, .lo=9}. If .lo=4294967295 is wrong and .lo=9 is what we want, could anyone provide a fix, please? I'm to dumb for the (binary?) arithmetic atm. (And if it is wrong, did I just uncovered an ancient bug?) To paper over the (mis)behaviour of XSyncValueSubtract() I would suggest to make sure that AdjustWaitForDelay() doesn't return negative values. We can't check for negatives in ospoll_wait() as the input thread calls it with -1. Other thoughts: Why does the cursor move, but neither the movement or clicks, nor pressing a modifier unlock the client? Cheers, Daniel Martin _______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel