There are several user visible "warts" with wsmoused: Wsmoused conflicts with X's use of the mouse, you can't ctrl-alt-screen between X and text consoles and use the mouse in both of them.
The cursor location is in character cells instead of pixels, so the cursor moves twice as fast vertically as horizontally, and you need to scale down the mouse to get a reasonable speed. Wsmoused makes an attempt to address this by setting MSMOUSEIO_SRES to WSMOUSE_RES_MIN, but that only does anything on PS/2 mice. There is also a really strange (not even monotonically increasing or directionally invariant!) coordinate scaling function in normalize_event(). Wsmoused is enabled with rcctl and configuration options are set with wsmoused_flags= in /etc/rc.local instead of wsconsctl / wsconsctl.conf. I propose: Wsdisplay would have a mouse device associated with it as keyboards are associated, with "just works" defaults and wsconsctl options. Console cursor work would be automatically supressed when X is active. Cursor position would be tracked in pixels. If no additional scaling is done in X, the cursor would move at the same speed across the graphics or text console screens. The possibility is also then open to draw a pixel addressed bitmap cursor on any of the rasops consoles, which is more user friendly than a text block cursor for both disambiguation from the typing cursor, and avoidance of the unknown block boundary jitter problem. This would also save a couple thousand lines of code, remove a "moving part" from the system, and allow additional improvements like drag selection into the scrollback to be implemented. This would lose the support wsmoused has for some ancient serial mouse protocols parsed in user space. I would argue that if those mice are actually important, they should get a kernel driver. However, I suspect that the intersection of wsmoused users with 25 year old mice is small enough to neglect. Sound ok to pursue?
