Re: Mouse movement speed
I haven't used wsmoused in ages, but I tend to think ideas like (by default) scaling to the font size have great merit. There should be a debugging toggle (maybe) to get raw values. It should work out-of-the-box preferably. ;)
Re: Mouse movement speed
Ok, that works -- I could not tell what that parsing code did in wsconsctl, and I thought the scaling code in wscons only got applied to touchpads. In that case, how about just allowing wsconsctl to accept mouse.speed as a special floating point parameter that sets both the DX and DY scales appropriately? I'll make a patch to the code and man page, and add a comment about the debug interface format. The scaling code in the USB HUD driver is definitely dropping low order bits, and seems to be completely subsumed by the newer parm based code, so removing WSMOUSEIO_SRES still seems like a good idea. Original Message Subject: Re: Mouse movement speed From: Ulf Brosziewski Date: Mon, May 18, 2020 12:16 pm To: jo...@armadilloaerospace.com, "tech@openbsd.org" Hi John, you can slow down mice via wsconsctl, but this possibility is "hidden" in a debug and testing interface. You have seen the WSMOUSECFG_D*_SCALE parameters, two parameters in *.12 fixed-point format that determine the scaling of DX- and DY-deltas. You can read the values with $ wsconsctl mouse.param=0,1 and change them by issuing, for example, $ wsconsctl mouse.param=0:401,1:401 This should reduce the speed to 10% of its "raw" value. (You don't need the device number in the commands if they apply to wsmouse0.) wsmouse tracks remainders when scaling, and slow movements shouldn't cause noticeable rounding errors at this layer. The effects, however, will also depend on what the receiving drivers make of the coordinates. On 5/18/20 01:17, jo...@armadilloaerospace.com wrote: > I enabled wsmoused for console mouse support, but the cursor was > unusably fast. This is a high resolution, high update rate USB gaming > mouse, but it was off by well over an order of magnitude. > > I searched for a global mouse speed setting, but the only thing I > found was a "mouse.scale=0,0,0,0,0,0,0" in wsconsctl, and I couldn't > figure out how to use it even after reading all the source. > > There is an ioctl for mouse resolution, but it only applies to PS/2 > mice: > > /* Set resolution. Not applicable to all mouse types. */ > #define WSMOUSEIO_SRES _IOW('W', 33, u_int) > > The wsmousecfg values for WSMOUSECFG_DX_SCALE and WSMOUSECFG_DY_SCALE > are only used for touchpads, and are zero for mice. > > The USB mouse driver can apply scaling to mouse delta movements if it > is taken out of raw mode and the wsmouse_calibcoords are set to > reasonable values, but the comments don't seem to be correct: > > /* Set/get sample coordinates for calibration */ > #define WSMOUSE_CALIBCOORDS_MAX 16 > #define WSMOUSE_CALIBCOORDS_RESET -1 > struct wsmouse_calibcoords { > int minx, miny; /* minimum value of X/Y */ > int maxx, maxy; /* maximum value of X/Y */ > int swapxy; /* swap X/Y axis */ > int resx, resy; /* X/Y resolution */ > int samplelen; /* number of samples available or > WSMOUSE_CALIBCOORDS_RESET for raw mode */ > struct wsmouse_calibcoord { > int rawx, rawy; /* raw coordinate */ > int x, y; /* translated coordinate */ > } samples[WSMOUSE_CALIBCOORDS_MAX]; /* sample coordinates */ > }; > > No kernel code uses the samples[] array, and the samplelen field is > interpreted as raw mode when non-0, and scaled by the other values > when it is 0. > > This explains wsconsctl's mouse.rawmode and mouse.scale[7] values, > but I still couldn't set them, getting > WSMOUSEIO_SCALIBCOORDS: Invalid argument for everything I tried. > > If I called the ioctl with my own code, I could clear raw mode and > scale the mouse speed down by 10x. > > That slows the mouse down, but the behavior is terrible. > > The scaling applied in hidms_input() would be reasonable for an > absolute referenced touch screen, but it isn't for integer valued > relative motion, because information is permanently lost in the > scaling -- you can slowly move the mouse an arbitrary distance > without the pointer moving at all, as the deltas are rounded to > zero, and it is done per-axis, so slight angles turn into strictly > axial motion. > > Mouse scaling needs to maintain a fractional residual for each axis. > > The user visible behavior I want to see is: > > wsconsctl mouse.speed=0.6 > > This could overload the existing DX_SCALE value, but that may still > need to be used independently for touchpad configuration, so I > think it would be better to define a new WSMOUSECFG_SPEED > parameter with the same *.12 fixed point format as > WSMOUSECFG_DX_SCALE. > > If this sounds reasonable, I will go ahe
Re: Mouse movement speed
Hi John, you can slow down mice via wsconsctl, but this possibility is "hidden" in a debug and testing interface. You have seen the WSMOUSECFG_D*_SCALE parameters, two parameters in *.12 fixed-point format that determine the scaling of DX- and DY-deltas. You can read the values with $ wsconsctl mouse.param=0,1 and change them by issuing, for example, $ wsconsctl mouse.param=0:401,1:401 This should reduce the speed to 10% of its "raw" value. (You don't need the device number in the commands if they apply to wsmouse0.) wsmouse tracks remainders when scaling, and slow movements shouldn't cause noticeable rounding errors at this layer. The effects, however, will also depend on what the receiving drivers make of the coordinates. On 5/18/20 01:17, jo...@armadilloaerospace.com wrote: > I enabled wsmoused for console mouse support, but the cursor was > unusably fast. This is a high resolution, high update rate USB gaming > mouse, but it was off by well over an order of magnitude. > > I searched for a global mouse speed setting, but the only thing I > found was a "mouse.scale=0,0,0,0,0,0,0" in wsconsctl, and I couldn't > figure out how to use it even after reading all the source. > > There is an ioctl for mouse resolution, but it only applies to PS/2 > mice: > > /* Set resolution. Not applicable to all mouse types. */ > #define WSMOUSEIO_SRES _IOW('W', 33, u_int) > > The wsmousecfg values for WSMOUSECFG_DX_SCALE and WSMOUSECFG_DY_SCALE > are only used for touchpads, and are zero for mice. > > The USB mouse driver can apply scaling to mouse delta movements if it > is taken out of raw mode and the wsmouse_calibcoords are set to > reasonable values, but the comments don't seem to be correct: > > /* Set/get sample coordinates for calibration */ > #define WSMOUSE_CALIBCOORDS_MAX 16 > #define WSMOUSE_CALIBCOORDS_RESET -1 > struct wsmouse_calibcoords { > int minx, miny; /* minimum value of X/Y */ > int maxx, maxy; /* maximum value of X/Y */ > int swapxy; /* swap X/Y axis */ > int resx, resy; /* X/Y resolution */ > int samplelen; /* number of samples available or > WSMOUSE_CALIBCOORDS_RESET for raw mode */ > struct wsmouse_calibcoord { > int rawx, rawy; /* raw coordinate */ > int x, y; /* translated coordinate */ > } samples[WSMOUSE_CALIBCOORDS_MAX]; /* sample coordinates */ > }; > > No kernel code uses the samples[] array, and the samplelen field is > interpreted as raw mode when non-0, and scaled by the other values > when it is 0. > > This explains wsconsctl's mouse.rawmode and mouse.scale[7] values, > but I still couldn't set them, getting > WSMOUSEIO_SCALIBCOORDS: Invalid argument for everything I tried. > > If I called the ioctl with my own code, I could clear raw mode and > scale the mouse speed down by 10x. > > That slows the mouse down, but the behavior is terrible. > > The scaling applied in hidms_input() would be reasonable for an > absolute referenced touch screen, but it isn't for integer valued > relative motion, because information is permanently lost in the > scaling -- you can slowly move the mouse an arbitrary distance > without the pointer moving at all, as the deltas are rounded to > zero, and it is done per-axis, so slight angles turn into strictly > axial motion. > > Mouse scaling needs to maintain a fractional residual for each axis. > > The user visible behavior I want to see is: > > wsconsctl mouse.speed=0.6 > > This could overload the existing DX_SCALE value, but that may still > need to be used independently for touchpad configuration, so I > think it would be better to define a new WSMOUSECFG_SPEED > parameter with the same *.12 fixed point format as > WSMOUSECFG_DX_SCALE. > > If this sounds reasonable, I will go ahead and make a diff for the > kernel and wsconsctl to implement it that with proper residuals. > > For additional cleanup to make it net-negative-LoC, could everything > relating to struct wsmouse_calibcoords go away completely? It looks > like all the fields are now replicated as wsmousecfg parms and > handled at the wsmouse level for the touchpad case, so doing it at > the usb device or other level is redundant, as well as being broken > for relative moves. > > It would be nice to use parms for everything, also getting rid of > WSMOUSEIO_GTYPE and WSMOUSEIO_SRES. > >
Re: Mouse movement speed
On Sun, 17 May 2020 at 16:17:46 -0700, jo...@armadilloaerospace.com wrote: > I enabled wsmoused for console mouse support, but the cursor was > unusably fast. This is a high resolution, high update rate USB gaming > mouse, but it was off by well over an order of magnitude. > > I searched for a global mouse speed setting, but the only thing I > found was a "mouse.scale=0,0,0,0,0,0,0" in wsconsctl, and I couldn't > figure out how to use it even after reading all the source. That was added for touchscreens, to be manipulated with xtsscale(1). > No kernel code uses the samples[] array, and the samplelen field is > interpreted as raw mode when non-0, and scaled by the other values > when it is 0. Yes I think samples can go away, it's been there since importing from NetBSD and isn't used. > This explains wsconsctl's mouse.rawmode and mouse.scale[7] values, > but I still couldn't set them, getting > WSMOUSEIO_SCALIBCOORDS: Invalid argument for everything I tried. It's up to the driver (uts(4) for touchscreens, ums(4) for mice) to do something with that ioctl, and ums doesn't support it. > The user visible behavior I want to see is: > > wsconsctl mouse.speed=0.6 > > This could overload the existing DX_SCALE value, but that may still > need to be used independently for touchpad configuration, so I > think it would be better to define a new WSMOUSECFG_SPEED > parameter with the same *.12 fixed point format as > WSMOUSECFG_DX_SCALE. > > If this sounds reasonable, I will go ahead and make a diff for the > kernel and wsconsctl to implement it that with proper residuals. In X11 one can adjust mouse speed with xset(1), maybe it's easier to work with the raw values in wsmoused and add a scaling knob there? I see there's already code in wsmoused's normalize_event() to adjust speed. > For additional cleanup to make it net-negative-LoC, could everything > relating to struct wsmouse_calibcoords go away completely? It looks > like all the fields are now replicated as wsmousecfg parms and > handled at the wsmouse level for the touchpad case, so doing it at > the usb device or other level is redundant, as well as being broken > for relative moves. > > It would be nice to use parms for everything, also getting rid of > WSMOUSEIO_GTYPE and WSMOUSEIO_SRES. WSMOUSEIO_GTYPE is used by a few X11 input drivers that talk to wscons. I think WSMOUSEIO_SRES can be removed.
Mouse movement speed
I enabled wsmoused for console mouse support, but the cursor was unusably fast. This is a high resolution, high update rate USB gaming mouse, but it was off by well over an order of magnitude. I searched for a global mouse speed setting, but the only thing I found was a "mouse.scale=0,0,0,0,0,0,0" in wsconsctl, and I couldn't figure out how to use it even after reading all the source. There is an ioctl for mouse resolution, but it only applies to PS/2 mice: /* Set resolution. Not applicable to all mouse types. */ #define WSMOUSEIO_SRES _IOW('W', 33, u_int) The wsmousecfg values for WSMOUSECFG_DX_SCALE and WSMOUSECFG_DY_SCALE are only used for touchpads, and are zero for mice. The USB mouse driver can apply scaling to mouse delta movements if it is taken out of raw mode and the wsmouse_calibcoords are set to reasonable values, but the comments don't seem to be correct: /* Set/get sample coordinates for calibration */ #define WSMOUSE_CALIBCOORDS_MAX 16 #define WSMOUSE_CALIBCOORDS_RESET -1 struct wsmouse_calibcoords { int minx, miny; /* minimum value of X/Y */ int maxx, maxy; /* maximum value of X/Y */ int swapxy; /* swap X/Y axis */ int resx, resy; /* X/Y resolution */ int samplelen; /* number of samples available or WSMOUSE_CALIBCOORDS_RESET for raw mode */ struct wsmouse_calibcoord { int rawx, rawy; /* raw coordinate */ int x, y; /* translated coordinate */ } samples[WSMOUSE_CALIBCOORDS_MAX]; /* sample coordinates */ }; No kernel code uses the samples[] array, and the samplelen field is interpreted as raw mode when non-0, and scaled by the other values when it is 0. This explains wsconsctl's mouse.rawmode and mouse.scale[7] values, but I still couldn't set them, getting WSMOUSEIO_SCALIBCOORDS: Invalid argument for everything I tried. If I called the ioctl with my own code, I could clear raw mode and scale the mouse speed down by 10x. That slows the mouse down, but the behavior is terrible. The scaling applied in hidms_input() would be reasonable for an absolute referenced touch screen, but it isn't for integer valued relative motion, because information is permanently lost in the scaling -- you can slowly move the mouse an arbitrary distance without the pointer moving at all, as the deltas are rounded to zero, and it is done per-axis, so slight angles turn into strictly axial motion. Mouse scaling needs to maintain a fractional residual for each axis. The user visible behavior I want to see is: wsconsctl mouse.speed=0.6 This could overload the existing DX_SCALE value, but that may still need to be used independently for touchpad configuration, so I think it would be better to define a new WSMOUSECFG_SPEED parameter with the same *.12 fixed point format as WSMOUSECFG_DX_SCALE. If this sounds reasonable, I will go ahead and make a diff for the kernel and wsconsctl to implement it that with proper residuals. For additional cleanup to make it net-negative-LoC, could everything relating to struct wsmouse_calibcoords go away completely? It looks like all the fields are now replicated as wsmousecfg parms and handled at the wsmouse level for the touchpad case, so doing it at the usb device or other level is redundant, as well as being broken for relative moves. It would be nice to use parms for everything, also getting rid of WSMOUSEIO_GTYPE and WSMOUSEIO_SRES.