http://bugzilla.novell.com/show_bug.cgi?id=604966 http://bugzilla.novell.com/show_bug.cgi?id=604966#c15 Michel Dänzer <daenzer@vmware.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED InfoProvider|daenzer@vmware.com | --- Comment #15 from Michel Dänzer <daenzer@vmware.com> 2010-06-02 08:32:12 UTC --- Philip doesn't have an account here but can be reached at plangdale at vmware dot com. Here's his initial response:
Anyway, the issue here was slightly convoluted. The standard detection mechanism we use has always been to do this port-poke, and if it's not a VM, you get a segfault - and you do need iopl() set to allow that to work. When I published the vmmouse source, I had the iopl() call in there and that was an issue for non-Linux operating systems, but I also observed that it wasn't really necessary because the X server did iopl() itself - not really a surprise. Later on, I added vmmouse_detect to allow the HAL/udev based device detection to work, and those are standalone and so what the X server does is irrelevant.
Now, why isn't this an issue for anyone else? It does the detection correctly on Ubuntu and other distros (and no one cares about the segfault in the failure case). I guess they have funny core handling going on?
Anyway, it seems the right fix is to add the iopl() call in, perhaps only in vmmouse_detect as it's still irrelevant in the X server. It also doesn't matter in the X server now as the driver isn't loaded unless the device is detected.
It also needs to be properly guarded for LINUX. Who knows what's up on BSD or similar.
-- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.