Re: xxxVERBOSE module?
Am 20.05.10 05:52, schrieb Paul Goyette: From the comments in the GENERIC config files, the primary reason for omitting the various xxxVERBOSE options is to avoid including large text tables in the resulting kernel. And I vaguely recall some spirited discussion back when the change was made to exclude these options by default. Now that we have MODULAR kernels (at least on some architectures), I've been wondering if it might make sense to create a mod_verbose that could be loaded during start-up time and then unloaded after the machine is up and running. (For plug-and-play situations, such as USB, the module could be reloaded and unloaded whenever a new device is added.) Is this something that would be useful? To my understanding most of the VERBOSE options are compile-time switches which are used to conditionally compile debug code using #ifdefs. I am not sure how such a module should work then, changing #ifdef'ed code into code that is always compiled, but only used under certain circumstances?
Re: Adding mouse sensitivity adjustment to wsmouse
Am 18.05.10 23:17, schrieb Sverre Froyen:
I would like to adjust the sensitivity of my external mouse but leave the
sensitivity of my laptop touchpad as is. As far as I can tell, NetBSD has no
facility to do this. I found a couple of mouse ioctl definitions (but no
implementations) that seem relevant and also kern/12132 that partially
implements what I need. I propose changing wsmouse.c as indicated in the
attached diff. It adds scaling factors for x, y, z, and w into the
wsmouse_softc structure and uses a higher resolution internally in order to
handle fractions without adding floats.
WSCONS_MOUSE_RES is (the inverse of) the internal resolution and
sc_mx, sc_my, etc are the scaling factors (multiplied with WSCONS_MOUSE_RES).
It appears to work for my case with a regular bluetooth mouse but it has not
been tested for a device producing absolute positions.
If this looks OK, we need to decide how to set the scaling factors. There are
two ioctls that appear relevant (from wsconsio.h):
/* Set resolution. Not applicable to all mouse types. */
#define WSMOUSEIO_SRES _IOW('W', 33, u_int)
#define WSMOUSE_RES_MIN 0
#define WSMOUSE_RES_DEFAULT 75
#define WSMOUSE_RES_MAX 100
/* Set scale factor (num / den). Not applicable to all mouse types. */
#define WSMOUSEIO_SSCALE_IOW('W', 34, u_int[2])
WSMOUSEIO_SRES has been implemented for one driver
(sys/arch/hpcmips/vr/vrpiu.c) but I'm not sure what is does. WSMOUSEIO_SSCALE
has not been implemented for any driver (but see kern/12132). My current test
implementaion ignores WSMOUSEIO_SRES and changes WSMOUSEIO_SSCALE to take a
single integer which is used to set the x and y scaling factors. Because
WSMOUSE_RES_MAX is 100, the WSMOUSEIO_SSCALE value can be described as a
percent scaling. This is sufficient for my needs but we might want to scale x
and y differently and also set scaling factors for z and w.
If there is interest and we can reach a consensus on the ioctl question I can
clean this up and submit it. Please let me know.
In the diff you attched you set the resolution value to a constant which
you then use. That is certainly not what you intend, i.e. it should at
least be a variable.
I am not sure if applying the resolution to absolute posititioning
devices is a good idea either, but I doubt it. Have you tested your
patch on a device that does absolute positioning?
That said, I think your patch needs some more work.
Re: xxxVERBOSE module?
On Thu, May 20, 2010 at 08:13:15AM +0200, Marc Balmer wrote: To my understanding most of the VERBOSE options are compile-time switches which are used to conditionally compile debug code using #ifdefs. I am not sure how such a module should work then, changing #ifdef'ed code into code that is always compiled, but only used under certain circumstances? No, this was about PCIVERBOSE, USBVERBOSE and SCSIVERBOSE, which adds in the kernel table of strings for vendor/device names, extended error codes, etc ... -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: xxxVERBOSE module?
On Thu, 20 May 2010, Manuel Bouyer wrote: On Thu, May 20, 2010 at 08:13:15AM +0200, Marc Balmer wrote: To my understanding most of the VERBOSE options are compile-time switches which are used to conditionally compile debug code using #ifdefs. I am not sure how such a module should work then, changing #ifdef'ed code into code that is always compiled, but only used under certain circumstances? No, this was about PCIVERBOSE, USBVERBOSE and SCSIVERBOSE, which adds in the kernel table of strings for vendor/device names, extended error codes, etc ... Correct - that was my intention. - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
Re: xxxVERBOSE module?
Am 20.05.10 11:12, schrieb Manuel Bouyer: On Thu, May 20, 2010 at 08:13:15AM +0200, Marc Balmer wrote: To my understanding most of the VERBOSE options are compile-time switches which are used to conditionally compile debug code using #ifdefs. I am not sure how such a module should work then, changing #ifdef'ed code into code that is always compiled, but only used under certain circumstances? No, this was about PCIVERBOSE, USBVERBOSE and SCSIVERBOSE, which adds in the kernel table of strings for vendor/device names, extended error codes, etc ... Ah, I see. Well, the this addition makes sense, for sure ;)
Re: Adding mouse sensitivity adjustment to wsmouse
On Thu May 20 2010 00:17:43 Marc Balmer wrote:
Am 18.05.10 23:17, schrieb Sverre Froyen:
I would like to adjust the sensitivity of my external mouse but leave the
sensitivity of my laptop touchpad as is. As far as I can tell, NetBSD has
no facility to do this. I found a couple of mouse ioctl definitions (but
no implementations) that seem relevant and also kern/12132 that
partially implements what I need. I propose changing wsmouse.c as
indicated in the attached diff. It adds scaling factors for x, y, z, and
w into the wsmouse_softc structure and uses a higher resolution
internally in order to handle fractions without adding floats.
WSCONS_MOUSE_RES is (the inverse of) the internal resolution and
sc_mx, sc_my, etc are the scaling factors (multiplied with
WSCONS_MOUSE_RES).
It appears to work for my case with a regular bluetooth mouse but it has
not been tested for a device producing absolute positions.
If this looks OK, we need to decide how to set the scaling factors. There
are two ioctls that appear relevant (from wsconsio.h):
/* Set resolution. Not applicable to all mouse types. */
#define WSMOUSEIO_SRES _IOW('W', 33, u_int)
#define WSMOUSE_RES_MIN 0
#define WSMOUSE_RES_DEFAULT 75
#define WSMOUSE_RES_MAX 100
/* Set scale factor (num / den). Not applicable to all mouse types. */
#define WSMOUSEIO_SSCALE_IOW('W', 34, u_int[2])
WSMOUSEIO_SRES has been implemented for one driver
(sys/arch/hpcmips/vr/vrpiu.c) but I'm not sure what is does.
WSMOUSEIO_SSCALE has not been implemented for any driver (but see
kern/12132). My current test implementaion ignores WSMOUSEIO_SRES and
changes WSMOUSEIO_SSCALE to take a single integer which is used to set
the x and y scaling factors. Because WSMOUSE_RES_MAX is 100, the
WSMOUSEIO_SSCALE value can be described as a percent scaling. This is
sufficient for my needs but we might want to scale x and y differently
and also set scaling factors for z and w.
If there is interest and we can reach a consensus on the ioctl question I
can clean this up and submit it. Please let me know.
In the diff you attched you set the resolution value to a constant which
you then use. That is certainly not what you intend, i.e. it should at
least be a variable.
I am not sure if applying the resolution to absolute posititioning
devices is a good idea either, but I doubt it. Have you tested your
patch on a device that does absolute positioning?
That said, I think your patch needs some more work.
I probably should have been clearer. Take the x-coordinate as an example. The
mouse input is scaled by s_mx/WSCONS_MOUSE_RES. The s_mx parameter can be set
by the user. I need the WSCONS_MOUSE_RES constant for two reasons, one to be
able to specify scaling fractions and two in order to correctly accumulate
mouse input where the mouse delta-x times s_mx/WSCONS_MOUSE_RES is not equal
to an integer.
I have not tested the patch with an absolute positioning device (If I can get
my hands on one I will). As far as scaling being useful, if your device is too
sensitive (like the 1000dpi resolution mouse that I purchased), it seems like
it could be useful. In any case, you can always leave the scaling set as one-
to-one.
Regards,
Sverre
Re: Adding mouse sensitivity adjustment to wsmouse
Am 20.05.10 16:17, schrieb Sverre Froyen:
On Thu May 20 2010 00:17:43 Marc Balmer wrote:
Am 18.05.10 23:17, schrieb Sverre Froyen:
I would like to adjust the sensitivity of my external mouse but leave the
sensitivity of my laptop touchpad as is. As far as I can tell, NetBSD has
no facility to do this. I found a couple of mouse ioctl definitions (but
no implementations) that seem relevant and also kern/12132 that
partially implements what I need. I propose changing wsmouse.c as
indicated in the attached diff. It adds scaling factors for x, y, z, and
w into the wsmouse_softc structure and uses a higher resolution
internally in order to handle fractions without adding floats.
WSCONS_MOUSE_RES is (the inverse of) the internal resolution and
sc_mx, sc_my, etc are the scaling factors (multiplied with
WSCONS_MOUSE_RES).
It appears to work for my case with a regular bluetooth mouse but it has
not been tested for a device producing absolute positions.
If this looks OK, we need to decide how to set the scaling factors. There
are two ioctls that appear relevant (from wsconsio.h):
/* Set resolution. Not applicable to all mouse types. */
#define WSMOUSEIO_SRES _IOW('W', 33, u_int)
#define WSMOUSE_RES_MIN 0
#define WSMOUSE_RES_DEFAULT 75
#define WSMOUSE_RES_MAX 100
/* Set scale factor (num / den). Not applicable to all mouse types. */
#define WSMOUSEIO_SSCALE_IOW('W', 34, u_int[2])
WSMOUSEIO_SRES has been implemented for one driver
(sys/arch/hpcmips/vr/vrpiu.c) but I'm not sure what is does.
WSMOUSEIO_SSCALE has not been implemented for any driver (but see
kern/12132). My current test implementaion ignores WSMOUSEIO_SRES and
changes WSMOUSEIO_SSCALE to take a single integer which is used to set
the x and y scaling factors. Because WSMOUSE_RES_MAX is 100, the
WSMOUSEIO_SSCALE value can be described as a percent scaling. This is
sufficient for my needs but we might want to scale x and y differently
and also set scaling factors for z and w.
If there is interest and we can reach a consensus on the ioctl question I
can clean this up and submit it. Please let me know.
In the diff you attched you set the resolution value to a constant which
you then use. That is certainly not what you intend, i.e. it should at
least be a variable.
I am not sure if applying the resolution to absolute posititioning
devices is a good idea either, but I doubt it. Have you tested your
patch on a device that does absolute positioning?
That said, I think your patch needs some more work.
I probably should have been clearer. Take the x-coordinate as an example. The
mouse input is scaled by s_mx/WSCONS_MOUSE_RES. The s_mx parameter can be set
by the user. I need the WSCONS_MOUSE_RES constant for two reasons, one to be
able to specify scaling fractions and two in order to correctly accumulate
mouse input where the mouse delta-x times s_mx/WSCONS_MOUSE_RES is not equal
to an integer.
I have not tested the patch with an absolute positioning device (If I can get
my hands on one I will). As far as scaling being useful, if your device is
too
sensitive (like the 1000dpi resolution mouse that I purchased), it seems like
it could be useful. In any case, you can always leave the scaling set as one-
to-one.
So I suggest that you leave out the changes for absolute positioning
devices, I have some, and I can not imagine how this would be of any
good in this case. For relative devices, I think the approach can make
sense.
Can you provide a complete diff? Make sure the default settings are the
same as we have now, i.e. don't break existing setups.
- Marc
Re: Adding mouse sensitivity adjustment to wsmouse
fwiw, I contacted Matthieu Herrb, author of xf86-input-ws, if we could add scaling to the X input driver. It already has these MaxX, MinX etc. variables for absolute devices, so it might be a good place to add the scaling, too (and maybe it even already exists somewhere). -mb
Re: Adding mouse sensitivity adjustment to wsmouse
On Thu May 20 2010 11:47:12 Marc Balmer wrote: fwiw, I contacted Matthieu Herrb, author of xf86-input-ws, if we could add scaling to the X input driver. It already has these MaxX, MinX etc. variables for absolute devices, so it might be a good place to add the scaling, too (and maybe it even already exists somewhere). Would you be able to scale two mice differently? My Xorg log indicates a single mouse only, so I suspect wscons merges the two mouse event streams. I need to be able to scale the bluetooth mouse but not the touchpad. Regards, Sverre
Re: Adding mouse sensitivity adjustment to wsmouse
Am 20.05.10 18:58, schrieb Sverre Froyen: On Thu May 20 2010 10:49:06 Marc Balmer wrote: So I suggest that you leave out the changes for absolute positioning devices, I have some, and I can not imagine how this would be of any good in this case. For relative devices, I think the approach can make sense. Can you provide a complete diff? Make sure the default settings are the same as we have now, i.e. don't break existing setups. It is a complete diff except for the ioctls. I was hoping for some input on that aspect. Well, I more or less suggested you provide a *new* complete diff, with the absolute parts removed. As for the ioctls, I suggest you make a proposal. Looks to me like you only have to pass an X, Y, and Z factor to the driver. Also you might want to check if the scaling functionality is present in X.Org already? - Marc
Re: Adding mouse sensitivity adjustment to wsmouse
Am 20.05.10 20:02, schrieb Sverre Froyen: On Thu May 20 2010 11:47:12 Marc Balmer wrote: fwiw, I contacted Matthieu Herrb, author of xf86-input-ws, if we could add scaling to the X input driver. It already has these MaxX, MinX etc. variables for absolute devices, so it might be a good place to add the scaling, too (and maybe it even already exists somewhere). Would you be able to scale two mice differently? My Xorg log indicates a single mouse only, so I suspect wscons merges the two mouse event streams. I need to be able to scale the bluetooth mouse but not the touchpad. yes, I think that should work. On several systems I have a mouse (a normal one) and a second input device. wsmouse0 and wsmouse1. So they can be configured separately. In any case, configuring them individually is a must, I'd say.
Re: Adding mouse sensitivity adjustment to wsmouse
does X have any way to do mouse scaling, Not very, not core X at least. ChangePointerControl allows defining a threshold above which pointer motion is accelerated by a specified rational fraction (or decelerated, I suppose, if a server feels like implementing fractions 1). However, that's not much use here, and applies to only the core pointer anyway. The input extension may be more elaborate, but I really know just about nothing about it - even the relatively anciet server I use offers extensions I've been unable to find documentation on. (Indeed, of the 16 extensions offered, I've found useful documentation on two.) So yes, I think this would be appropriate for the kernel driver. how does GNOME manage it, for example? Probably by blindly assuming it's running on Linux x86. :-รพ /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: xxxVERBOSE module?
On Thu, 20 May 2010, David Young wrote: On Wed, May 19, 2010 at 08:52:52PM -0700, Paul Goyette wrote: From the comments in the GENERIC config files, the primary reason for omitting the various xxxVERBOSE options is to avoid including large text tables in the resulting kernel. And I vaguely recall some spirited discussion back when the change was made to exclude these options by default. Now that we have MODULAR kernels (at least on some architectures), I've been wondering if it might make sense to create a mod_verbose that could be loaded during start-up time and then unloaded after the machine is up and running. (For plug-and-play situations, such as USB, the module could be reloaded and unloaded whenever a new device is added.) Is this something that would be useful? Yes, it would be. ... Kewl - I plan on starting with PCIVERBOSE, followed closely with USB. ... Just an idea: we may get a lot of mileage out of a generic method for adding or augmenting, and removing kernel property lists from a kernel, either at run- or compile-time. Consider that much of the VERBOSE info is in tabular form, thus expressible by property list. So are PCI/USB/... vendor/product tables that we use to match drivers with devices---I wish we could change those tables without recompiling. I anticipate using property lists to express device locators. So it seems to me that linking property lists into the kernel could be very useful. Great idea, but I think I'll save that for a future time when I have a bit more free time! - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net | | Kernel Developer | | pgoyette at netbsd.org | -
