Bug 461465

Summary: vmmouse driver not picked automatically by Xorg input hotplug
Product: [Fedora] Fedora Reporter: Denis Leroy <denis>
Component: xorg-x11-drv-vmmouseAssignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: mcepl, peter.hutterer
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-09-10 09:25:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Denis Leroy 2008-09-08 09:52:35 UTC
When running Xorg in a guest VM without an xorg.conf file, Xorg does not pick the vmmouse driver automatically, but rather loads the default "mouse" driver. It does pick the correct "vmware" driver for the screen however.

Comment 1 Matěj Cepl 2008-09-09 23:37:06 UTC
Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Comment 2 Peter Hutterer 2008-09-10 09:25:18 UTC
We can get the PCI info from the video card and thus load the vmware video driver automatically. For input devices we do not have this possibility.

While the vmmouse driver has functionality to detect if it is running in a client machine, this functionality would have to be in the server to pick the driver correctly.
This again is further complicated by the fact that the vmmouse driver does not cooperate well with hotplugging mechanisms now used for loading input devices.
An additional flag is needed in the xorg.conf to disable input hotplugging.

So in short, an xorg.conf is required anyway for vmmouse to work correctly, at which point the automagic picking becomes futile.

Marking as WONTFIX.

Comment 3 Denis Leroy 2008-09-10 09:55:23 UTC
Thanks for the answer,

Indeed currently the only way to make vmmouse work is to hardcode it into xorg.conf AND turn off hotplugging with "AutoAddDevices off".

Bug 434807 is also related (possibly a duplicate ?) and there is an upstream bug filed at freedesktop.org.

One thing I don't understand though. I agree you have the PCI info to detect the vmware video drive automatically, but how does input hotplugging work then ? What mechanism do they use to pick one keyboard or mouse driver versus another ? Can't a simple piece of logic such as 

  if carddriver == "vmware" then mousedriver = "vmmouse"

work ? And if vmmouse can detect whether it runs in a client VM, can't the server detect it also by using the exact same code ?

> So in short, an xorg.conf is required anyway for vmmouse
> to work correctly, at which point the automagic picking
> becomes futile

no offense but isn't this circular reasoning ? We need an xorg.conf because of this bug :-)

Comment 4 Peter Hutterer 2008-09-10 10:10:11 UTC
(In reply to comment #3)
> One thing I don't understand though. I agree you have the PCI info to detect
> the vmware video drive automatically, but how does input hotplugging work then
> ? What mechanism do they use to pick one keyboard or mouse driver versus
> another ? Can't a simple piece of logic such as 
> 
>   if carddriver == "vmware" then mousedriver = "vmmouse"
> 
> work ? And if vmmouse can detect whether it runs in a client VM, can't the
> server detect it also by using the exact same code ?

we know the PCI info because the xserver parses the pci bus.
input is provided to us from HAL, we merely add the devices we are told to.

The above logic would work, except that you'd then load the vmmouse driver which would be dead in the water if evdev is used at the same time (Bug 434807#31). So you'd have to build into the logic that you also deactivate hotplug if vmware is deactivated.
That adds a lot of code that needs to be maintained just for the sake of saving a few lines in an xorg.conf. As far as I can tell, no other input driver has these requirements.

> > So in short, an xorg.conf is required anyway for vmmouse
> > to work correctly, at which point the automagic picking
> > becomes futile
> 
> no offense but isn't this circular reasoning ? We need an xorg.conf because of
> this bug :-)

hehe. It's more like we need an xorg.conf anyway to deactivate hotplug, so we might as well add the config there instead of dumping the code into the server.

Comment 5 Denis Leroy 2008-09-10 10:22:53 UTC
Understood on the hal-hotplug relationship.

Obviously we need the vmmouse driver to work with evdev in the first place, but hopefully we can that fixed eventually. However this is merely the 2nd step. If I understand things correctly, the first step is to improve HAL to make it detect a virtual machine guest situation (which could also apply to Xen), then we can write a HAL VM guest specific rule to address this. I'm curious how much work that would require...

This is constructive, thanks.

Comment 6 Peter Hutterer 2008-09-10 10:32:16 UTC
vmmouse has the code to detect if it's running in a client machine. I presume the same code should work in HAL as well.

In that case however you'd need to modify the device list that you only export one device instead of the many devices (to avoid needing AutoAddDevices false). if this device has a identifiable name, you can adjust the HAL fdi files to load vmware for this device - at which point everything magically works again. In theory, anyway.