Red Hat Bugzilla – Bug 172250
Mouse tracking not synchronized - Dell Server Remote Administration (Browser Applet)
Last modified: 2009-06-18 10:22:31 EDT
Description of problem:
Dell provides a remote administration capability with their servers which allows
the video/keyboard/mouse functions to be viewed and operated remotely via a
There is a problem in RHEL4 U2 where the mouse pointers do not sync-up on the
remote console. The pointer for the local mouse does not coincide with the
pointer for the remote mouse. This can be traced back to the Radeon driver
which requires a fix to translate a given mouse movement on the remote console
to the correct movement on the actual server.
This fix is described in the announcement attached. The patch is Patch1216:
This problem does not exist in RHEL3 U6 (as per ATI testing).
Steps to Reproduce:
1. Use a Dell server with this capability eg. Power Edge 6800 with DRAC4 card.
2. Connect remotely
3. make the local video resolution different from the remote (server) resolution.
4. Run the mouse pointer accross the remote video displayed in the browser.
The pointers will not coincide.
Created attachment 120627 [details]
patch for mouse pointer issue
Created attachment 120628 [details]
Linux release advisory from ATI - Mouse tracking
Filed against incorrect component (XFree86). RHEL 4 contains xorg-x11.
The patch attached in comment #1 contains a large amount of unnecessary
stuff. Please supply a patch that just fixes the reported problem in X,
without any extra stuff, along with an explanation of how the proposed
fix solves the problem.
Was the fix for this issue submitted to X.Org yet? Please supply the upstream
X.Org bug ID for this issue so we can track it there also.
Thanks in advance.
Created attachment 126348 [details]
disable RMX for dell server
Fix for mouse tracking issue
(In reply to comment #6)
> Created an attachment (id=126348) 
> disable RMX for dell server
> Fix for mouse tracking issue
This forces DDC to be true always. I'm curious what the real underlying
problem is, as this seems like a hackish workaround for a bigger problem.
It would be nice if we can find a fix for the real problem than to keep
adding vendor specific ugly hacks to the Radeon driver.
Can someone provide the details of the problem that is happening? My
assumption from the above description of the problem, and the functionality
the attached patch is adding, is that the DPI is incorrect in the no-DDC
case, and that by forcing DDC to be enabled all the time, the proper
DPI gets used, thereby resolving the problem.
When DDC is not used, the DPI must be manually specified to the X server
either via the commandline, or by using the DisplaySize option in the
config file. If the DisplaySize is not being set correctly, I would like
to try and figure out why and try to resolve that problem in a clean
manner if we can, as it is potentially a problem on more hardware than
the specific one reported in this report.
Any additional information you can provide which could help us to address
this, would be greatly appreciated.
Setting bug status to "NEEDINFO_REPORTER". We'll review this again once
the report has been updated.
Thanks in advance.
(In reply to comment #0)
> This problem does not exist in RHEL3 U6 (as per ATI testing).
This further implies that there is a real bug somewhere which was introduced
some time after XFree86 4.3.0, but before X.Org 6.8.2, possibly in the
Radeon driver itself, or in the generic X server code responsible for
I missed that comment somehow in my first few passes through the bug.
This is a regression per comment #0 above. ATI would like to see it fixed in 4.5.
1) See NEEDINFO in comment #6 above.
2) Is this a problem in RHEL3.8 as well (you say it works in 3.6).
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
This is correct...ish. It's certainly more correct than without the patch anyway.
Built as xorg-x11 6.8.2-1.EL.13.47, -> MODIFIED
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.