a) Do windows still have a titlebar?
b) Can you move them using "Alt+Left Mousebutton"?
c) Can you switch focus using Alt+Tab?
d) Can you interact with the remaining windows (with the mouse) at all?

a) Yes, I have titlebars and can use the minimize, maximize and close buttons as well.
b) No
c) No
d) Yes, all functions of the remaining windows are normal, the only thing is, I can not move any windows and alt+tab does not work.

can you
a) effectively run eg. "xprop" (from konsole. it'll try to grab the mouse and ask you to click a window) - otherwise there's an error message
b) ping kwin via dbus ("qdbus org.kde.KWin /KWin supportInformation" should print a list of settings and not timeout)

Created attachment 92961 [details]
output of xprop

Created attachment 92962 [details]
output of qdbus

a) No error message. (attachment 1 [details])
b) It prints a list. (attachement 2)

I mentioned an additional problem. The clipboard seems to be affected, too by this problem. When I tried to copy the console output from Konsole to a text file via Edit -> Copy and middle click paste, the marked text doesn't go into the clipboard. From Chrome to Konsole works.

Funny thing, it somehow seems to f*** up the timestamps regarding input grabs (for at least running clients, might be xcb related as well)

diff --git a/geometry.cpp b/geometry.cpp
index ea7b587..53aa2de 100644
--- a/geometry.cpp
+++ b/geometry.cpp
@@ -2556,7 +2556,7 @@ bool Client::startMoveResize()
     const xcb_grab_pointer_cookie_t cookie = xcb_grab_pointer_unchecked(connection(), false, m_moveResizeGrabWindow,
         XCB_EVENT_MASK_BUTTON_PRESS | XCB_EVENT_MASK_BUTTON_RELEASE | XCB_EVENT_MASK_POINTER_MOTION |
         XCB_EVENT_MASK_ENTER_WINDOW | XCB_EVENT_MASK_LEAVE_WINDOW,
-        XCB_GRAB_MODE_ASYNC, XCB_GRAB_MODE_ASYNC, m_moveResizeGrabWindow, Cursor::x11Cursor(m_cursor), xTime());
+        XCB_GRAB_MODE_ASYNC, XCB_GRAB_MODE_ASYNC, m_moveResizeGrabWindow, Cursor::x11Cursor(m_cursor), XCB_CURRENT_TIME);
     ScopedCPointer<xcb_grab_pointer_reply_t> pointerGrab(xcb_grab_pointer_reply(connection(), cookie, NULL));
     if (!pointerGrab.isNull() && pointerGrab->status == XCB_GRAB_STATUS_SUCCESS) {
         has_grab = true;

But we should first seek to figure *what* is going wrong there (this might, as mentioned, be an xcb issue, thus the Qt5 problem to update selection and clipboard buffers)

I'm having a similar issue after updating to Fedora 22 (via fedup). Cluster SSH now seems to break kwin.  Yesterday it was causing this issue when merely bringing the CSSH window into focus by clicking on it, but I'm also having it happen when I close the window.  I've tried both clusterssh-3.28 compiled from source, and also clusterssh-4.02.03-2.fc21 rpm package.  Both seem to cause the same issue.

Linux latitude 4.0.6-300.fc22.x86_64 #1 SMP Tue Jun 23 13:58:53 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Fedora release 22 (Twenty Two)
kf5-kwindowsystem-5.11.0-1.fc22.x86_64
kwin-5.3.1-2.fc22.x86_64
kwin-libs-5.3.1-2.fc22.x86_64
KDE Platform Version 4.14.9

If I restart kwin (kwin --replace), errors that come out that relate to resizing/moving windows after this bug manifests are below:

Move attempt:
QXcbConnection: XCB error: 3 (BadWindow), sequence: 49297, resource id: 21015296, major code: 18 (ChangeProperty), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 49629, resource id: 21015388, major code: 18 (ChangeProperty), minor code: 0

Resize attempt:
QXcbConnection: XCB error: 3 (BadWindow), sequence: 50441, resource id: 21015593, major code: 18 (ChangeProperty), minor code: 0
QXcbConnection: XCB error: 3 (BadWindow), sequence: 50607, resource id: 21015637, major code: 18 (ChangeProperty), minor code: 0

Also seeing the problem Miller reports, but on Debian Sid.  Reported to the Debian package maintainer, and was told to report it upstream, so reposting that bug report here:

Package: kwin-x11
Version: 4:5.3.2-1
Severity: important

Dear Maintainer,

kwin_x11 stops handling window move and resize requests for all windows when using clusterssh.  This seems to happen when clicking inside the main CSSH control window, but only after clusterssh has opened and placed xterm windows.  Before any xterms have been created by clusterssh, it's interface can be used without breaking kwin_x11.  Running kwin_x11 --replace fixes the issue, but breaks again once you try to use the main clusterssh window again.  The problems are not experience when using the xfwm4 or metacity window managers (via xfwm4 --replace and metacity --replace respectively).  I'm not aware of any other applications that use the X11 protocol to control window geometry and placement.  If there are others, they may be affected as well.

The following are the message displayed from kwin_x11 just after creating a terminal and clicking in the CSSH control window:

	 kwin_core: screens:  2 desktops:  4
	 kwin_core: Done.
	 kwin_core: Rule found: [ "Window settings for xterm" : "xterm" ] : 'ID: 67108878 ;WMCLASS: "xterm" : "xterm" ;Caption: "CSSH: root@smb01" '
	 kwin_core: User timestamp, ASN: 4294967295
	 kwin_core: User timestamp, final: 'ID: 67108878 ;WMCLASS: "xterm" : "xterm" ;Caption: "CSSH: root@smb01" ' : 8197253
	 kwin_core: Activation, compared: 'ID: 67108878 ;WMCLASS: "xterm" : "xterm" ;Caption: "CSSH: root@smb01" ' : 8197253 : 8182851 : true 

	 kwin_core: screens:  2 desktops:  4
	 kwin_core: Done.
	 kwin_core: screens:  2 desktops:  4
	 kwin_core: Done.
	 kwin_core: Rule found: [ "Window settings for xterm" : "xterm" ] : 'ID: 67108878 ;WMCLASS: "xterm" : "xterm" ;Caption: "CSSH: root@smb01" '
	 kwin_core: User timestamp, ASN: 4294967295
	 kwin_core: User timestamp, final: 'ID: 67108878 ;WMCLASS: "xterm" : "xterm" ;Caption: "CSSH: root@smb01" ' : 4294967295
	 kwin_core: Activation: No timestamp at all
	 kwin_core: screens:  2 desktops:  4
	 kwin_core: Done.
	 kwin_core: 0x20084: Texture state usage warning: Texture 0 is base level inconsistent. Check texture size.
	 kwin_core: screens:  2 desktops:  4
	 kwin_core: Done.
	 kwin_core: User timestamp, ASN: 4294967295
	 kwin_core: User timestamp, final: 'ID: 65011756 ;WMCLASS: "cssh" : "cssh" ;Caption: "CSSH [1]" ' : 4294967295
	 kwin_core: Activation: No timestamp at all
	 kwin_core: screens:  2 desktops:  4
	 kwin_core: Done.
	 kwin_core: Raising: Belongs to active application
	 kwin_core: 0x20084: Texture state usage warning: Texture 0 is base level inconsistent. Check texture size.
	 QXcbConnection: XCB error: 6 (BadCursor), sequence: 22177, resource id: 23068796, major code: 2 (ChangeWindowAttributes), minor code: 0
	 QXcbConnection: XCB error: 6 (BadCursor), sequence: 22188, resource id: 23068796, major code: 2 (ChangeWindowAttributes), minor code: 0
	 areKeySymXsDepressed:  any of  2
	 0 : keySymX=0x "ffe9"  i= 8  mask=0x "1"  keymap[i]=0x "1" 

	 kwin_core: 0x20071: Buffer detailed info: Buffer object 3 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations.
	 kwin_core: 0x20071: Buffer detailed info: Buffer object 4 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations.
	 kwin_core: 0x20071: Buffer detailed info: Buffer object 5 (bound to GL_ARRAY_BUFFER_ARB, usage hint is GL_STATIC_DRAW) will use VIDEO memory as the source for buffer object operations.
	 kwin_core: 0x20084: Texture state usage warning: Texture 0 is base level inconsistent. Check texture size.
	 kwin_core: 0x20092: Program/shader state performance warning: Fragment Shader is going to be recompiled because the shader key based on GL state mismatches.
	 kwin_core: 0x20084: Texture state usage warning: Texture 0 is base level inconsistent. Check texture size.
	 kwin_core: 0x20084: Texture state usage warning: Texture 0 is base level inconsistent. Check texture size.
	 kwin_core: 0x20084: Texture state usage warning: Texture 0 is base level inconsistent. Check texture size.
	 kwin_core: 0x20084: Texture state usage warning: Texture 0 is base level inconsistent. Check texture size.
	 areKeySymXsDepressed:  any of  2
	 0 : keySymX=0x "ffe9"  i= 8  mask=0x "1"  keymap[i]=0x "1" 


It should be noted that I have been using window rules to force KDE4's kwin to use the application's requested geometry and placement.  The windows management breakage happened with an empty set of rules immediately after installing kwin_x11, and after creating windows rules.  

	 Steps reproduce:
	 1) start clusterssh and add ssh connections with it
	 2) click in the CSSH windows again, window management is now broken.

	 Expected outcome:
	 kwin_x11 should be able to handle X11 geometry and window events generated by clusterssh.  



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.0.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages kwin-x11 depends on:
ii  kwin-common          4:5.3.2-1
ii  libc6                2.19-18
ii  libkf5i18n5          5.11.0-1
ii  libkf5windowsystem5  5.11.0-1
ii  libqt5core5a         5.4.2+dfsg-4
ii  libqt5gui5           5.4.2+dfsg-4
ii  libqt5widgets5       5.4.2+dfsg-4
ii  libqt5x11extras5     5.4.2-2
ii  libstdc++6           5.1.1-6
ii  libxcb1              1.10-3+b1

kwin-x11 recommends no packages.

kwin-x11 suggests no packages.

-- no debconf information

The actual bug is in clusterssh, see comment #7 (what) and #6 (breaks clipboard)

Are you suggesting these are two separate bugs: one triggered by use of
the X copy buffer and/or clipboard, and the other triggered by clicking
anywhere within the clusterssh frame (as reported in comments 8 and 9)?

I don't think this is a bug with clusterssh, as the bug is not triggered
when using a different window manager, and it ran fine in kwin4 as
well.  You might convince me that the bug of comments 8 and 9 is
different than the original bug report, and I would be happy to file it
as a new bug. 

I suspect none of the three reports has anything to do with the
clipboard, but more likely an X11 window event being mishandled in
kwin_x11 (in the case of the original bug, raising the main window
before giving it the clipboard/buffer data).  Skimming over the
clusterssh source, I don't see anywhere where the clipboard or X copy
buffer is referenced.  The only thing I see is keyboard events being
duplicated and sent to each window using X11::SendEvent.  If needed, I
would be happy to step through the clusterssh code next week and
identify which line triggers the broken window management.  Perhaps that
would help narrow down the the actual cause.

No.
clusterssh somehow screws event times - i haven't checked whether our grab request is dropped inside xcb or actually rejected by the x11 server, but because of the "patch" to simply use the events arrival queue instead of the current server time, it sounds as if clusterssh passes some future timestamp to some mouse event.

This behavior *also* breaks the selection buffer (unrelated to kwin, which has no play in that system)

Since chromium -> konsole seems unaffected, it'll rather be an optimization drop in xcb ("i know some newer event has been  passed"

=> I bet your right arm on this being a bug in clusterssh, exposed by xcb.

Hello,

i had the same bug report, but first i thought it was a konsole bug although suspecting kwin too, bug opened against both kde/konsole and fedora/kde/konsole:

https://bugs.kde.org/show_bug.cgi?id=351490

Now as i was about to open a kwin bug i came across this report, which definitely is my problem too.

I dont want to spam here, you can check my reports here:

https://bugs.kde.org/show_bug.cgi?id=351490
https://bugzilla.redhat.com/show_bug.cgi?id=1254254

Like Daniel, i too think it's strange that only kwin is affected by this problem. And the copy and paste problem associated with this bug affects only kde programs.

Maybe xcb / qt ?

Anyhow, some questions:

1) is there some fix for this problem? Even if i have to patch clusterssh (actually this will be what I'll search next)
2) Is there any info i can provide here to pinpoint the problem?

I'll be glad to help, right now i'm avoiding konsole and got an alias for "cd /tmp; nohup kwin --replace" ....



Thanks in advance

*** Bug 351490 has been marked as a duplicate of this bug. ***

See comment #7 for a workaround in kwin, this will however not fix cnp in (other) Qt5 clients.

I'm not aware of patches/fixes/stuff to clusterssh (I frankly only have a remote idea what that application actually is ;-)

"Unfortunately, clusterssh is written in perl, so it's probably not something they do, but in some perl function they use.
It *looks* like it screws event timings (therefore replacing the actual time with "NOW!" works around it)

Thanks Thomas,

i see. I'm trying the patch right now (although i'm quite used to compiling / patching sources , i'm not as good to souce rpm -> rpm building), i'll update here when done.

What bugs me though, is why this happens only on qt programs.

I'll try to follow this on clusterssh side too, maybe changing perl version or such can change thigs.

But troubleshooting X issues for me is difficult so suggestions welcome :-)



Right now

Possibly related: http://sourceforge.net/p/clusterssh/bugs/35/
I'll check whether we maybe get jumps in the sever time.

Errrr.... locally no more reproducible?
Might be one of the two dozen local kwin patches or an update to clusterssh/perl.
I'll try a vanilla kwin 5.4 later.

Sorry Thomas, this days I was really busy at work (even during weekend), I hope to have some time tomorrow to follow.

afaics, it's not a problem on a "somewhat recent™" archlinux installation

perl: 5.22.0
qt: 5.5.0
kwin: 5.4.1
cssh: 4.03.06

I can confirm this bug.
I'm on kubuntu 15.10, kwin 5.4.2, clusterssh 4.03.06.

A workaround is:
  * open krunner with Alt+F2
  * kwin_x11 --replace

clusterssh upstream has accepted a patch to fix the issue:

https://github.com/duncs/clusterssh/issues/46

@Rex Dieter, ok for the clusterssh bug, but there's something i'm missing. Shouldn't kwin be more robust too?
I mean, with gnome's window manager and others i can't reproduce this issue ...

I'll leave that for kwin maintainers to decide.

see comment #7 - clusterssh screws xserver times, forcing everything to ignore them as well and act as if X11 was sync, iow: other WMs not affected would be simply "limited" (to avoid the term "broken" in terms of X11 while it's not a problem in a "all clients local" world)

It also affects (at least) Qt5 selection buffers (clipboard) - this *may* be due to how xcb handles things in contrast to Xlib (looks like cssh simply causes future timestamps which make xcb skip putting events on the server)

*** Bug 351225 has been marked as a duplicate of this bug. ***

@Thomas Lübking, that makes sense, thanks for the explanation. X11 is such a complicated beast :-)

And indeed i had the copy & paste problem too, for me kde was nearly useless (windows cant move unless i restarted kwin, copy and paste terminally broken on qt apps).

With the new clusterssh version it's working fine now finally!

Out of curiosity and if someone has the time to answer, isn't X11 (xcb / xlib or such) then who needs to "filter" the bad time values somehow?

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)


Dev note, @Martin

Errr... this sucks.
We read the time from events to spare the (now) hyperexpensive query, but a broken/malicious client can make us believe to live in the future. Bad.
Once in the future, we won't return (because there's a sanity check in setX11Time)

=> We query the server from time to time, so we could enforce backdating here:
(geometry.cpp is only a showcase)

diff --git a/geometry.cpp b/geometry.cpp
index ab73001..6d48e12 100644
--- a/geometry.cpp
+++ b/geometry.cpp
@@ -2657,6 +2657,8 @@ bool Client::doStartMoveResize()
     m_moveResizeGrabWindow.map();
     m_moveResizeGrabWindow.raise();
     updateXTime();
+    kwinApp()->setX11Time(xTime()+10000);
+    updateXTime();
     const xcb_grab_pointer_cookie_t cookie = xcb_grab_pointer_unchecked(connection(), false, m_moveResizeGrabWindow,
         XCB_EVENT_MASK_BUTTON_PRESS | XCB_EVENT_MASK_BUTTON_RELEASE | XCB_EVENT_MASK_POINTER_MOTION |
         XCB_EVENT_MASK_ENTER_WINDOW | XCB_EVENT_MASK_LEAVE_WINDOW,
diff --git a/main.h b/main.h
index a345cd3..cc391b3 100644
--- a/main.h
+++ b/main.h
@@ -94,8 +94,8 @@ public:
     xcb_timestamp_t x11Time() const {
         return m_x11Time;
     }
-    void setX11Time(xcb_timestamp_t timestamp) {
-        if (timestamp > m_x11Time) {
+    void setX11Time(xcb_timestamp_t timestamp, bool force = false) {
+        if (force || timestamp > m_x11Time) {
             m_x11Time = timestamp;
         }
     }
diff --git a/utils.cpp b/utils.cpp
index 991539c..17d5e2a 100644
--- a/utils.cpp
+++ b/utils.cpp
@@ -82,7 +82,7 @@ void updateXTime()
     // NOTE: QX11Info::getTimestamp does not yet search the event queue as the old
     // solution did. This means there might be regressions currently. See the
     // documentation above on how it should be done properly.
-    kwinApp()->setX11Time(QX11Info::getTimestamp());
+    kwinApp()->setX11Time(QX11Info::getTimestamp(), true);
 }
 
 static int server_grab_count = 0;

*** Bug 358202 has been marked as a duplicate of this bug. ***

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)

(In reply to Roland Pallai from comment #30)
> Xorg session was started at Mar30, 19 days before.

Oops. So ~50 days before..

It's a bug in clusterssh and should have been fixed there:
https://github.com/duncs/clusterssh/issues/46

For KWin there's nothing to actually "fix" - just to keep in mind that we might want to seek for protection against stupid clients, but - and that's important - clusterssh does not only break kwin, every client operating X11 asynchronously (ie. "as it was meant") is affected (notably copy+paste for at least Qt5)
The only solution was to nuke all timestamp considerations and pretend X11 was synchronous (what's *nearly* true for strictly local sessions, w/o any remote clients)

Thank you, I understand. Some kind of protection against buggy clients would be nice, the session should stay usable at least. I would be pleased even if the workaround involves kwin restart.

BTW I do not use clusterssh, not installed. I suspect NetBeans as it has a known timestamp problem (#347153).

On 05/19/2016 07:33 AM, Thomas Lübking via KDE Bugzilla wrote:
> https://bugs.kde.org/show_bug.cgi?id=348569
>
> --- Comment #32 from Thomas Lübking <thomas.luebking@gmail.com> ---
> It's a bug in clusterssh and should have been fixed there:
> https://github.com/duncs/clusterssh/issues/46
>
> For KWin there's nothing to actually "fix" - just to keep in mind that we might
> want to seek for protection against stupid clients, but - and that's important
> - clusterssh does not only break kwin, every client operating X11
> asynchronously (ie. "as it was meant") is affected (notably copy+paste for at
> least Qt5)
> The only solution was to nuke all timestamp considerations and pretend X11 was
> synchronous (what's *nearly* true for strictly local sessions, w/o any remote
> clients)
>
Speaking of which, several months ago a slightly newer version of KDE
Frameworks5 (on Debian Testing) fixed the issue for me.  At the time I
tried to figure out which updated library fixed the issue, but couldn't
narrow it down in the limited time I had.

I don't know the clusterssh code base, nor am I more than passingly
familiar with a really old version of the X11 protocol.  But I do
question if it would be wise to protect against "stupid" clients.  There
is no telling how many stupid/smart clients are using such esoteric,
asynchronous features.

(In reply to Roland Pallai from comment #33)

> BTW I do not use clusterssh, not installed.
Sure you're facing *this* bug then? The particular problem is caused by clients (cssh in this very case) sending future timestamps around (causing a failure in grabs and pastes)
The netbeans bug is largely different (depite also concerning timestamps) - it's just extremely picky about the timestamp in a "legacy" focus distribution protocol and seems to require sync action. That does not (necessarily) mean it would /use/ wrong timestamps (but actually rather operate on XCB_CURRENT_TIME only)

(In reply to Daniel Fussell from comment #34)
> On 05/19/2016 07:33 AM, Thomas Lübking via KDE Bugzilla wrote:
> Speaking of which, several months ago a slightly newer version of KDE
> Frameworks5 (on Debian Testing) fixed the issue for me. 
Unless debian picked the patch in comment #28, I'd rather say you picked up a fixed clusterssh version. There's nothing but kwin that could impact this on this end. If copy & paste (in Qt5 clients) isn't broken anymore either, it's pretty certain that the cssh fix hit your disk.


> is no telling how many stupid/smart clients are using such esoteric,
> asynchronous features.
It's not "esoteric" but actually the principal X11 design. Synchronous action is just a special case.

(In reply to Thomas Lübking from comment #35)
> Sure you're facing *this* bug then? The particular problem is caused by
> clients (cssh in this very case) sending future timestamps around (causing a
> failure in grabs and pastes)
> The netbeans bug is largely different [...]

The first 8 comments _exactly_ described the symptoms, including error messages reported by Miller at #c8, so I commented here, but yes, as I learn more about this issue, I cannot rule out that it might be a different bug with same symptoms.

My desktop environment mostly stable, same apps are running all the time and I have never experienced this bug before. X session uptime often reaches 20-30 days but there is a chance that this was the first time when went further than 50 days - first time when the X server's timestamp wrapped. It is suspicious for me.
What do you think? Should I open a new report?

*** Bug 377846 has been marked as a duplicate of this bug. ***

Git commit 0bec9ad7337536e319c17c5684d97e1156399fdb by Martin Gräßlin.
Committed on 03/05/2017 at 19:36.
Pushed by graesslin into branch 'Plasma/5.8'.

Improve the x11 timestamp handling

Summary:
So far KWin only updated the x11 timestamp if the new timestamp is larger
than the existing one. While this is a useful thing it creates problems
when the 32 bit msec based time stamp wraps around which happens after
running an X server for 49 days. After the timestamp wrapped around KWin
would not update the timestamp any more and thus some calls might fail.
Most prominent victims are keyboard and pointer grab which fails as the
timestamp is either larger than the server timestamp or smaller than the
last grab timestamp.

Another problem related to timestamp handling is KWin getting broken by
wrong timestamps sent by applications. A prominent example is clusterssh
which used to send a timestamp as unix time which is larger than the
x timestamp and thus our timestamp gets too large.

This change addresses these problems by allowing to reset the timestamp.
This is only used from updateXTime (which is normally invoked before we
do things like grabKeyboard). Thus we make QX11Info::getTimestamp the
ultimate trusted source for timestamps.
Related: bug 377901
FIXED-IN: 5.8.7

Test Plan: As I cannot wait 50 days: unit tests for the two conditions added.

Reviewers: #kwin, #plasma

Subscribers: plasma-devel, kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D5704

M  +11   -0    autotests/CMakeLists.txt
A  +123  -0    autotests/test_x11_timestamp_update.cpp     [License: GPL (v2)]
M  +6    -2    main.h
M  +1    -1    utils.cpp
M  +3    -3    utils.h

https://commits.kde.org/kwin/0bec9ad7337536e319c17c5684d97e1156399fdb

I'm experiencing what I believe to be a special case of this issue in Plasma 5.12.9. After my session was running for ~50 days (I don't have the exact time, unfortunately), I became unable to copy to the clipboard from Konsole, either by selecting text into the selection buffer or by explicitly copying using keyboard shortcuts or the context menu. In all cases, ~/.xsession-errors states:

> QXcbClipboard::setMimeData: Cannot set X11 selection owner

All other applications are able to copy without issues. I'm also not experiencing other previously observed symptoms like being unable to move windows. Since this is similar but not identical to the original incarnation of the issue, I'm leaving the status alone; please let me know if you'd like me to file a new issue or re-open this, or if more information would be helpful.

Dan, which Qt version are you using? The QxcbClipboard issue was fixed for Qt 5.12.3, see https://bugreports.qt.io/browse/QTBUG-65145

Thanks Christopher, I'm stuck back on 5.9.5. Good to know that was already taken care of - I should've thought to check Qt as well.