Hi all, I have a fix for the issue detailed in the following bug report:
https://bugs.openjdk.java.net/browse/JDK-8150954 The issue is does not affect JDK9 so I guess my primary target for the bug is jdk8u-dev and the backports will go into 7 and 6 as needed. The fix basically checks the _NET_WM_CM_Sn atom (where n is the screen number), since the composite manager *MUST* acquire ownership of this selection, if there's a selection we're running a compositor and at this point, wecan get the window root where the actual compositing takes places and get a screenshot of that. JDK9 is not affected since the implementation seems to have moved to GTK, I see there's some code referring to the old path, but it's unlikely to be used in composited desktop anyway, I didn't stress test it though. The bug report contains images describing various configurations, and a simple test case. The proposed fix webrevs can be found here: http://cr.openjdk.java.net/~neugens/8150954/ I tried the fix on RHEL 7.2 locally and over a remote x11 connection with and without a composite desktop. There are two parts, one pertaining the configure machinery (to include the necessary XRender/XComposite stuff) and the other is the actual awt Robot fix. If accepted, the configure should be regenerated, the patch contains this as well, but I'm not sure how to deal with the closed bits, so some guidance is welcomed. Any comments? Cheers, Mario
