Bug 493642 - Don't include the spurious extra screen definition in the anaconda X server config
Don't include the spurious extra screen definition in the anaconda X server c...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
5.3
All Linux
low Severity medium
: rc
: ---
Assigned To: Anaconda Maintenance Team
Release Test Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-02 09:35 EDT by john.haxby@oracle.com
Modified: 2009-07-31 10:45 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-30 14:28:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Remove the spurious screen definition and use (653 bytes, patch)
2009-04-02 09:35 EDT, john.haxby@oracle.com
no flags Details | Diff

  None (edit)
Description john.haxby@oracle.com 2009-04-02 09:35:36 EDT
Created attachment 337810 [details]
Remove the spurious screen definition and use

Description of problem:

With the various patches for correctly tracking the Xen Virtual Keyboard/Pointer in place (bug 493623, bug 493627, bug 493630 and bug 493634) there is one remaining problem stopping the mouse pointer from tracking properly.

This is the extra screen definition added to the X server configuration and used on the command line to start that server.   In /usr/(s)bin/anaconda the code says

  xserver.generateConfig()
  xserver.addExtraScreen("Anaconda")
  xserver.display = ":1"
  xserver.serverflags.extend(["-screen", "Anaconda", "-br"])
  xserver.pid = xserver.startX(...)

The offending lines are the "addExtraScreen" and the "serverflags.extend".  I believe that the extra screen was added to force the X server config file that was written out to explicitly include the required resolution (800x600, set earlier in the file).  So far as I can have been able to establish, however, that isn't needed: I'm pretty sure that if the screen defined in the config would allow a resolution greater than 800x600, then a suitable stanza would be written to the config file to restrict it.   Moreover the "-br" flag is completely unnecessary -- the X server has had a default black root for quite a while now.

Why do I care?  Well with this spurious screen, the X server ignores the extra input device needed to take events from the Xen Virtual Keyboard/Mouse and you don't get cursor tracking.   It's very annoying.  However, rather than fighting the X server it's easier to just remove some options that are no longer needed.

Version-Release number of selected component (if applicable):11.1.2.168


How reproducible: Always with a Xen PV install with the appropriate fixes added in.


Steps to Reproduce:
1. See description
2.
3.
  
Actual results: Mouse doesn't track properly


Expected results: Mouse tracks properly.


Additional info: As I said in one of the other bugs, having the mouse track properly in a Xen PV installation makes the installation so much easier and probably sorts out world peace at the same time.
Comment 1 john.haxby@oracle.com 2009-04-02 09:54:57 EDT
I did suspect when I came across this that it would also prevent the HP ilomouse from working as its InputDevice would be ignored.  Unfortunately I don't have the requisite hardware available to verify that.
Comment 2 john.haxby@oracle.com 2009-04-02 09:59:19 EDT
Related bugs: bug 493618, bug 493623, bug 493627, bug 493630, bug 493634 and bug 493642
Comment 3 Markus Armbruster 2009-07-30 14:28:53 EDT
The bug as reported is about the difficulties to manually configure X
in a certain way, to get proper pointer tracking.  It is certainly
valid.  However, the real problem users care about is that pointer
tracking works very poorly (mouse hits invisible wall).

Upstram, we solved the problem by fixing numerous issues in various
places to make it work out of the box, from Fedora 11 on.

The patches proposed by the reporter solve the problem by making
manual configuration work.  They are unrelated to the upstream
solution.

Like the upstream solution, they're fairly invasive: they touch the
kernel and several user space packages.  This is a significant risk.
Moreover, splitting the device is an ABI change.  The question is
whether there are benefits to justify that.

We already put much less invasive changes into 5.4 to improve pointer
tracking (bug 492866).  They fix the "mouse hits invisible wall"
problem.  They still require a pointer grab, which virt-viewer makes
relatively painless.

So, the benefit of the proposed patches over what we've got already is
to enable manual configuration so that the mouse grab can be avoided.
While that's certainly nice, it doesn't justify the risk, in my
opinion.

If you disagree, please reopen the bug.


Some technical background:

There are 3 pieces in the stack: VNC client, QEMU VNC server and the
guest's X.  The old, misbehaving setup has VNC client sending absolute
coordinates, which the VNC server sends through xenkbd to X.  X in
RHEL-5 doesn't have any auto-configuration of input devices, so it
just opens /dev/input/mice, and thus the guest kernel converts from
absolute to relative.  Because the VNC client has no knowledge of this
conversion, you get into situation where you hit an invisible wall in
the client when it thinks it has got to the virtual desktop boundary.

Now, if you had absolute coordinates being passed and used all the way
to X then it would trivially work, but this requires X configuration.
Recent X's do that automatically.  RHEL-5's X simply isn't capable of
that.  The patches proposed by the reporter add manual configuration
steps across a wide range of RPMs.

The fix we did for RHEL-5.4 is to make xenkbd *not* use absolute
coordinates, so the VNC server now sends relative coordinates.  This
removes the broken absolute -> relative conversion in the guest
kernel.  On its own this isn't sufficient, because you then get broken
absolute to relative conversion in the VNC server instead.  So we also
added the VNC relative mouse extension to QEMU and GTK-VNC.  Now the
VNC client is in charge of doing the absolute -> relative conversion.
This is good, as this is the only point in the stack capable of doing
the conversion correctly, to avoid hitting an invisible wall.  The
only restriction is that you must grab the host mouse pointer and hide
it, so you only see the guest drawn pointer.
Comment 4 Markus Armbruster 2009-07-31 10:45:04 EDT
By the way, RHEL-6 pointer tracking will be fine out of the box using absolute coordinates, just like upstream.

Note You need to log in before you can comment on or make changes to this bug.