Windows Mobile 6.5 Stylus Hover Processing

Windows Mobile 6.5 processed stylus hover on specialized electromagnetic resonance (EMR) digitizers by leveraging low-level driver modifications to bypass the operating system's standard resistive touch assumptions. While the platform was primarily designed for single-point physical contact, electromagnetic digitizers detected the pen's proximity above the screen. Hardware vendors bridged this capability into the Windows CE kernel by mapping in-range proximity signals to non-clicking mouse cursor movements through custom driver layers and the Graphics, Windowing, and Events Subsystem (GWES).

At the hardware level, electromagnetic digitizers—most notably developed by Wacom—used a sensor board placed behind the display. This board emitted a low-frequency radio frequency signal that powered an LC resonant circuit inside the stylus. When the stylus approached within 10 to 15 millimeters of the screen, the sensor board detected the pen's location via inductive coupling before physical contact occurred. The digitizer controller generated data packets containing X/Y coordinates alongside status flags, explicitly distinguishing between "in-range" (hovering) and "tip-switch closed" (touching/clicking) states.

Under standard conditions, the Windows Mobile touch architecture relied on touch.dll, divided into a Model Device Driver (MDD) and a Platform Dependent Driver (PDD). The default PDD was strictly tuned for analog resistive screens that returned coordinates only under pressure. To enable hover, OEMs replaced or heavily customized the PDD to interpret continuous coordinate streams even when the tip switch was open.

When the EMR controller reported an in-range status without tip activation, the custom PDD passed these coordinates to the MDD without generating touch-down flags. The MDD then routed these positional packets to GWES, the core subsystem responsible for input handling in Windows Embedded CE 5.2 (the underlying kernel of Windows Mobile 6.5).

GWES translated these zero-pressure positional packets into standard Win32 input messages. Instead of dispatching WM_LBUTTONDOWN messages, GWES posted standard WM_MOUSEMOVE messages into the target window's message queue. The wParam field of the WM_MOUSEMOVE message contained no button-press flags (such as MK_LBUTTON), signaling to the software that the pointer had changed position without initiating a contact sequence. When the stylus physically touched the screen, the digitizer flipped the tip-switch flag, prompting the driver to dispatch the expected WM_LBUTTONDOWN event.

Because the default Windows Mobile 6.5 user interface and native shell were built almost entirely around direct touch targets, standard platform applications generally ignored hover events. Consequently, taking full advantage of hover capabilities required OEM-specific SDKs or custom Win32 applications designed to listen directly for non-click WM_MOUSEMOVE events. These specialized applications used the hover coordinates to render cursor overlays, trigger tooltips, or preview UI actions before the user committed to an input.