https://bugs.kde.org/show_bug.cgi?id=348569
Roland Pallai <d...@rock.hu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |d...@rock.hu
--- Comment #30 from Roland Pallai <d...@rock.hu> ---
I hit this issue without cssh today. After the screen was unlocked windows are
unmoveable, alt+tab does not work, etc. kwin restart does not help. Xorg
session was started at Mar30, 19 days before. Yesterday it was working.
As a simple end-user I do not understand your explanation completely, but do
you know what is happening here and you proposed a fix here? Can I expect a
kwin upgrade will resolve this issue soon..?
(In reply to Thomas Lübking from comment #28)
> Technically, there's nothing such as a "bad" timestamp.
>
> Looking at the patch, cssh was buggy for sure - time() returns the time in
> seconds since epoch (presently sth. around 1450899519) while the function
> expects an X11 server timestamp (msecs since last server start, wraps every
> ~50 days)
> So to be accurate, your server would (presently) have to be running for 16
> days.
> If it's running longer, the grab happened in the past (until you wrap ;-),
> but I assume it's more a problem when it's in the far future (ie. the server
> recently started or wrapped)
>
> What will happen is that KWin's as well as Qt's event reader will read that
> timestamp from the event queue and update their copy of the server timestamp
> with it, then try to perform a future grab and the x11 server denies.
> (This is what one gets by "kwinApp()->setX11Time(xTime()+10000);" before the
> grab)
--
You are receiving this mail because:
You are watching all bug changes.
