Bug 592193

Possible solution:

Check for entries in 'udevadm info -e' with 'ID_INPUT_MOUSE=1' and and use
_VENDOR/_PRODUCT for matching to MatchVendor/MatchProduct in 
/etc/X11/xorg.conf.d/11-mouse.conf, i.e. add a new snippet.

You mean like http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-input-vmmouse.git;a=commitdiff;h=8eb233c45d39e92a09cd32c4c1b5d24b644636f4;hp=d9d84bb869112cc56d49eeab012b62b84665d885 and http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-input-vmmouse.git;a=commitdiff;h=d9d84bb869112cc56d49eeab012b62b84665d885;hp=fa7267c2fb6a50be54f8e32cfa91060dbdb24822 ? :) Yeah, I'm planning to use that or something like it upstream.

Yes, this looks good. :-)

I've implemented it that way now in our xorg-x11-driver-input package. It will be available shortly in

  http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_Factory/

Make sure that you have the following entry in RPM changelog:

-------------------------------------------------------------------
Wed Mar 31 17:14:41 CEST 2010 - sndirsch@suse.de

- added udev support for vmmouse driver (bnc #592193)

Build date should be 2010-03-31 or later.

Rastislav, Johan, Robin, Isis, Vadim, please test ASAP. Thanks.

Yes, i´ll test it, but i´d appreciate, if coolo created factory liveCD iso with included patch.

I do not understand. You're not capable of updating a single RPM of your installation and restart X? Since I didn't submit the package to factory yet (it hasn't been tested at all) it doesn't make sense to create a LiveCD for this.

Hopefully Johan, Robin, Isis, Vadim can help here.

(In reply to comment #6)
> I do not understand. You're not capable of updating a single RPM of your
> installation and restart X? Since I didn't submit the package to factory yet
> (it hasn't been tested at all) it doesn't make sense to create a LiveCD for
> this.

No, i can´t. I haven´t been able to install and start LiveCD since Milestone1. I reported bug 574857 against M1 the first time and don´t remember who changed version to M3.

For the live CD, there's a workround:

- In boot menu select text mode
- select installation 

You will land in Runlevel 3.

then:
1.
zypper ar http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_Factory/ XOrg

2.
zypper dup -r XOrg

3.
init 5

(But it's has not appeared yet in the repo)

Thanks for your hint, Robin! Could you provide feedback instead?

Works!

Note: You need a "udevadm trigger" after updating the packages.

"udevadm info -e" shows "ID_INPUT.tags=vmmouse" for the mouse and event device and the xserver will be using it.

Thanks for testing, Robin! Submitted now for openSUSE:Factory.

 36546  State:new     By:sndirsch     When:2010-04-01T13:50:51
        submit:       X11:XOrg/xorg-x11-driver-input  ->  openSUSE:Factory       
        Descr: 'added udev support for vmmouse driver (bnc #592193); added udev support for vmmouse driver (bnc #592193)'

-------------------------------------------------------------------
Thu Apr  1 13:48:46 CEST 2010 - sndirsch@suse.de

- re-plug the input devices via 'udevadm trigger' in %post(un)

-------------------------------------------------------------------
Wed Mar 31 17:14:41 CEST 2010 - sndirsch@suse.de

- added udev support for vmmouse driver (bnc #592193)

Great, hope to see these fixes in M5.

I'm not sure if the udevadm trigger makes sense in package %post or is even potentially dangerous or will cause errors if udev is not running during package installation.
I haven't seen other packages doing this yet.

They might just assume that the user will reboot sometime after installation.

Found these:
http://lists.mandriva.com/cooker/2009-03/msg00835.php
https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/320200

So let's better not call udevadm trigger...

Sorry for the spam, but looking further it seems that

udevadm trigger --subsystem-match=input --action=change

seems to be a save solution (default is --action=add which may theretically cause problems)

Tested -> works!

Well, I'm running 

  udevadm trigger --subsystem-match=input

in %post(un), but if Kay tells me that this is a stupid idea, I'm going to remove
it again.

Ok. I've changed it now to

  udevadm trigger --subsystem-match=input --action=change

(In reply to comment #16)
>   udevadm trigger --subsystem-match=input --action=change

That should be fine. Stuff is usually expected to handle such synthetic events.

Guys, i´m testing factory LiveCD build 0552 and i´m finally able to start LiveCD, but installation still doesn´t work. Still hangs :-(
How are your experiences? Can we reopen this bug, or create another new one?

I suggest to open a seperate bugreport. Maybe the udev rule and the xorg.conf.d snippet are simply missing on the LiveCD.

(In reply to comment #19)
> I suggest to open a seperate bugreport.

Is there one yet?

(In reply to comment #18)
> Guys, i´m testing factory LiveCD build 0552 and i´m finally able to start
> LiveCD, but installation still doesn´t work. Still hangs :-(

Starting the installation from build 0556 results in a black screen here, however the X server is clearly running with the vmmouse driver - the VM takes/drops focus automatically when entering/leaving the VM window, and I can switch to other VTs. Any ideas why the X server is only displaying black? Is there any way I can get a shell at that point?

(In reply to comment #20)
> (In reply to comment #19)
> > I suggest to open a seperate bugreport.
> 
> Is there one yet?
> 

Yes, bug 595674, which was resolved as duplicate of bug 585432.

Michel, the blank screen issue has been fixed in M5. It has been unrelated to X/vmware drivers. YaST2 was waiting for a script to appear before running it, which was simply missing on LiveCD of M4.

(In reply to Kay Sievers from comment #17)
> (In reply to comment #16)
> >   udevadm trigger --subsystem-match=input --action=change
> 
> That should be fine. Stuff is usually expected to handle such synthetic
> events.

Seems this was a wrong assumption. See boo#1006779.