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 ahead and make a diff for the
> kernel and wscon
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.
