vllt liegt es an den diamnond treibern, zitat von der HP:
"Diamondback HID Drivers
First, a couple of facts ...
Windows XP and the USB low speed HID protocol supports an 8 BYTE data packet = 64 bits maximum size.
Windows XP restricts the USB low speed HID protocol to a 8ms-polling rate contrary to USB spec. Windows 2000 and ME comply with the USB spec. This is why we had to find another way around instead of increasing polling rate; it won’t work in WinXP (but it will work, in OSX and Linux, for instance).
The “8 bit” data packet is just a convention that most mice use to report X/Y information. There is in fact no such restriction in Windows, as long as the total information sent, including things like button presses etc, does not exceed 64 bits. How much data is apportioned to X/Y is determined by the FIRMWARE of the mouse, the default drivers on the OS will take their cue from the firmware and receive data accordingly (the beauty of USB plug and play).
The problem with 8 bits for X/Y info is well known. -127/+127 (left/right) is the maximum info that can be sent, resulting in a very low maximum top speed of around 11” per second at 800dpi and 6400 frames per second.
On top of this problem, the old MX500 did not have buffer overflow protection, so if it exceeded +127 instead of staying at +127, it would either error and reset to zero, or worse, reset to -127, resulting in the mouse going in the OPPOSITE direction as fast as possible! With 12 bits, the maximum is -2048/+2048; with 16bits the maximum is -32k/+32k."
da steht was von win2k und winXP.
hab nicht recht kapiert ob sie das prob unter winXP nun gelöst haben oder wie.
in XP ist glaub auch die mausbeschleunigung schwerer abzustellen...
