Strange behavior of the keyboard/mice input RRS feed

  • Question

  • I've been working for the better part of 9 months to try to track down the cause of several bizarre glitches concerning keyboard/mouse input. Where would I need to post the symptoms and my findings?

    Products I've tested are XP 32-bit Home, Vista 32-bit Home Premium, Windows 7 32-bit Starter, Windows 7 32-bit Home Premium, Windows 7 64-bit Professional, and Windows 8 beta on several systems with hardware from many different vendors.

    The problems are most significantly impacted by configuration settings for RDP and Terminal Services, Accessibility features, Virtual Machine services and write virtualization, Filesystem control options, DPI Virtualization, and miscellaneous options from older Windows versions which have become deprecated.  

    I've done as much as I can to try to solve/find the problem and am now wondering where I would be best off presenting what I have found.  I'll list some further details below if that will help to nail down where I should be asking about this.


    The short of it is that registry entries in the Accessibility sections of all NTUSER.DAT profiles, regardless of the current user, affect latency and consistency of mouse input even when all settings are disabled by manually setting flags.  Regardless of the Accessibility options  for any user, the state of the NumLock and Capslock keys significantly affect the mouse.  CTRL and Shift also affect the mouse, as if a portion of mouse events are being written/read to one buffer or several which are reset upon hitting these keys.  SmoothMouseXCurve and SmoothMouseYCurve values for any profile, not just the current user (including the system and service profiles), affect the mouse even when Enhance Pointer Precision is disabled in Pointer Options tab under main.cpl, even without restarting the system.   RDP-related services and components also significantly impact input latency, particularly the terminal services interactive delay and input/output buffer settings.  Some even more strange things occur when editing win.ini and control.ini.  Input is affected by adding dummy system files to the root drive which were supposedly deprecated several releases ago such as msdos.sys, io.sys, dosshell.ini etc. and their contents, for example there is a perceptible and qualitative difference in the mouse input depending on the lines 'mouseinfo=ignore' or 'mouseinput=disabled' are in any of these files, and those two options are different from one another as well.  This is a very brief list of the many settings, most of which are in the registry, which I have found to impact the input.

    Most of my testing has been done with Windows 7 64-bit Professional but the majority of the symptoms are evident from Vista onward.  XP exhibits the same problems with the Accessibility settings although input latency is not nearly so severe, running Windows 7 and Windows XP on the same hardware shows a considerable difference in the behavior of the input.   Note that all of these problems are present even when an application is using DirectInput or Raw Input, and regardless of video driver or DirectX version.  

    I have been unable to completely resolve these behaviors even after drastic configuration changes, and can only guess at the causes for the problems.  Things I have suspected include the sub-pixelation calculations (the remainders of the speed scaling) for the pointer that are used for Enhance Pointer Precision not being disabled when EPP is turned off but still being added to the mouse count at the driver level which then propagates to accounts on Session0, the secure desktop, etc.  I also wonder if the parts of the boot loader, logon, and session manager processes are not attempting to initialize certain device drivers independently, it seems almost as if in addition to the kernel another component is acting as some sort of background system, for example:

    If the mouclass and kbdclass drivers are set to boot start ("start"=dword:00000000) in their service key in the registry, they create the devices 'LEGACY_MOUCLASS/0000' and 'LEGACY_KBDCLASS/0000' under HKLM/SYSTEM/CurrentControlSet/Enum/Root, and those are listed in the services' respective enum subkeys along with the HID devices that are normally present.  (The consistency of the input is also much improved as compared to demand start)


    When mouclass and kbdclass are set to system start ("start"=dword:00000001) those devices are not created in CurrentControlSet/Enum/root, yet when you look at the enum subkeys in the mouclass and kbdclass services, they list that the services are handling the devices '/root/LEGACY_MOUCLASS/0000' and '/root/LEGACY_KBDCLASS/0000' and the behavior of the input is affected accordingly.  The services were obviously started with those devices connected but where are they exactly?  

    Sorry if this is too much detail but with as long as I've been working on this, there's even more to cover.  I'm just hoping somebody has an idea where/who I should address this to in hopes that there is a relatively easy solution.  I have not been able to find one so far.

    • Edited by C0932 Thursday, March 14, 2013 7:54 PM
    Thursday, March 14, 2013 7:13 PM