luebking added a comment.
In https://phabricator.kde.org/D5704#106951, @cfeck wrote: > I may be totally unaware about what the changes do, but from reading the comments on the bug report, I had expected to see something like > > if (timestamp > m_X11Time || int(timestamp + INT_MAX / 2) < m_X11Time) ... There is no reasonable heuristic here. There is a reliable way to update the X11 time: ask the server (expensinve on the Qt5 design) And there's an unreliable way: track the timestamps on incoming events (for free) Times from the latter will typically be "a bit dated" and arrive in random order. If you get time far after the known one, the system might have hibernated or there might have been a network problem (if those are a remote clients) or the new value is just bullshit ("time()") If you get a time before the known one, the client might just have taken a longer time to send the event, you accepted a bullshit value before, this value is bullshit or the server time has wrapped around. Testing for a huge™ absolute difference *suggests* a wrap, but could also just mean some bullshit value is involved (and you don't know which one is true) and on the other hand, a small™ difference could stem from a stalled client/server connection across a wrap. One could probably keep timestamp stats and exclude outliers to protect agains broken clients and take "ok, everyone says it's ~120, so it's probably not 2147483648" (ie. m_x11Time being the new outlier) as factual wrap, but we're asking the server on a regular base anyway. And that time is always right. REPOSITORY R108 KWin BRANCH x11-timestamp-handling-5.8 REVISION DETAIL https://phabricator.kde.org/D5704 To: graesslin, #kwin, #plasma, davidedmundson Cc: cfeck, luebking, plasma-devel, kwin, spstarr, progwolff, Zren, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, lukas
