JDK-5097723 : Robot is not usable with multi-screen setup having a virtual screen, on linux
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux_redhat_9.0
  • CPU: x86
  • Submitted: 2004-09-07
  • Updated: 2006-10-04
  • Resolved: 2006-04-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b79Fixed
Related Reports
Relates :  
JDK-5097801 - Spurious mouse events are triggered on multi-mon - virtual screen linux setup
Relates :  
JDK-6287244 - Linux/Solaris robot should be rewritten
Relates :  
JDK-6190081 - Dragging a frame using Robot is not working properly on Multi-mon setup, Solaris + xinerama
Description
I have a multi-monitor setup with 2 screens connected to the same video card - Matrox DualHead G450 on a linux system (RH 9). A virtual desktop has been configured using Xinerama where the bounds of the virtual screen spans 2 monitors. I am able to drag windows across monitors. I am using robot to click one of the UI components on the secondary screen. I used the default Robot constructor. When I try to move the mouse to the second monitor, it does not work and mouse still remains at the periphery of the primary screen. but I am able to move the mouse manually across screens. 

So I am unable to use Robot to click on anything that is located on the secondary monitor. I went through the API specification for Robot and it recommends the developer to use Robot(gd) constructor for multi-screen env having 2 independent screens but does not specify anything for multi-screen ev having a virtual screen. The spec must also be enhanced to elaborate this. It does list out the multi-screen options but does not say which constructor to use for a virtual screen setup.

This is reproducible on all releases on Linux RH 9 with Xinerama. This is not reproducible on Win-XP having the same virtual screen setup.

I have attached a sample test. Execute the sample test. You would see a frame with a button. Move the frame to the secondary monitor and click on the button. You would see mouse being moved from screen1 to screen2. If the mouse cursor is not seen on the secondary monitor, the bug is reproduced.

Another issue I have noticed is, I have set a different cursor to button. When the mouse is moved by Robot within primary screen the cursor changes momentarily (reflects component's cursor) within the primary screen itself when it has not reached the actual component on the secondary screen. I could also see some mouse moved and mouse entered/exited events being triggered when mouse has not reached the actual component.
Comments
EVALUATION The notion of virtual screens is not exactly applicable to the case of Xinerama. While Xinerama offers possibility to interpret the several screens as one, into Java we report several screens(as GraphicsDevices), therefore second bullet takes place in Robot(GraphicsDevice) constructor. It might be possible to implement the behavior of Robot with the empty constructor in Xinerama case compatible to Windows, we'll try that in Mustang. ###@###.### 2004-09-07 I have stepped down to our native code, and found, that all the AWT code is correct. The problem is in XTest and XINERAMA interaction. In xinerama mode there is a single X screen, but if I try to move the mouse with XTest (using XTestFakeMotionEvent), some parts of this virtual screen are inaccessible. A simple example: screen 0 (0, 0, 1280, 1024) screen 1 rightof screen 0 (1280, 0, 2560, 1024) xinerama is on -> xdpyinfo reports about 1 single screen (0, 0, 2560, 1024) XTestFakeMotionEvent(display, 0 /*screen*/, 1300 /*x*/, 0/*y*/, CurrentTime/*no delay*/) -> mouse if left on the primary screen at (1280, 0) Thus, AWT team is unable to fix this bug until XTest is made xinerama-aware. ###@###.### 2005-03-17 14:57:14 GMT RFE 6287244 is created as an umbrella for Xtest+Xinerama bugs. ###@###.### 2005-06-17 13:00:10 GMT I'm reopening this bug as it seems that it is possible to fix it by using another native API than Xtest extension - XWarpPointer. However, it needs some investigation and should be fixed together with some other bugs, so I'm committing it to Dolphin. ###@###.### 2005-06-28 13:43:59 GMT
28-06-2005