Re: kern/55103: /dev/wsmouse returns EINVAL

[Paul Goyette <paul%whooppee.com@localhost>]

The following reply was made to PR kern/55103; it has been noted by GNATS.

From: Paul Goyette <paul%whooppee.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: mlelstv%serpens.de@localhost
Subject: Re: kern/55103: /dev/wsmouse returns EINVAL
Date: Fri, 3 Apr 2020 05:58:56 -0700 (PDT)

 On Fri, 3 Apr 2020, Michael van Elst wrote:
 
 > The following reply was made to PR kern/55103; it has been noted by GNATS.
 >
 > From: mlelstv%serpens.de@localhost (Michael van Elst)
 > To: gnats-bugs%netbsd.org@localhost
 > Cc:
 > Subject: Re: kern/55103: /dev/wsmouse returns EINVAL
 > Date: Fri, 3 Apr 2020 06:05:08 -0000 (UTC)
 >
 > mrg%eterna.com.au@localhost (matthew green) writes:
 >
 > >i think the only real solution we have here is the sysctl
 > >that changes the default, and having the depend on whether
 > >there is a path for compat or not -- eg, if it is present,
 > >then use it, or if it's possibly available (MODULAR) then
 > >use it, but with no baked in compat or modules, the default
 > >should be the only working method.
 >
 > I have prepared
 >
 > http://ftp.netbsd.org/pub/NetBSD/misc/mlelstv/wsevent.diff
 >
 > Default is now the new version but you can configure it with sysctl.
 > This also means that you now must configure it to get the compat
 > behaviour (in addition to building with COMPAT_50 or loading the
 > module).
 
 Yes, this looks good to me.
 
 
 > I thought about chosing the default default version depending on
 > build parameters.
 >
 > For the COMPAT_50 case that's easy, just set the default based
 > on that parameter.
 >
 > For the modular case it's difficult because you don't know if the
 > module will be loaded later.
 
 Yes, that's why my changes were going to include a new module_hook,
 to determine if the module was available or not.
 
 > Just using the new version seems to be the least confusing mode
 > because its very clear what you get and what you need to do for
 > the extremly rare case that you need the old protocol version.
 
 Agreed.
 
 > You can add more complexity to the decision process (i.e. by
 > loading the module earlier, even when not needed). But that
 > contradicts why the compat code is separated into a module
 > in the first place.
 
 Yup.
 
 > So, if absolute compatibility with the old protocol version
 > is wanted, it's probably easier, and safer, to just reintegrate
 > the code back (it's a single function of about 20 lines) and
 > drop the module.
 
 It's a bit more complex than that, since using the old protocol
 also means using old 32-bit time-stamps.  In order to reintegrate
 we'd also have to include (some of) the other compat_50 code for
 manipulating 32-bit timevals.
 
 I'm quite happy with your changes.  Do you want to commit, or
 would you prefer that I do it?
 
 
 +--------------------+--------------------------+-----------------------+
 | Paul Goyette       | PGP Key fingerprint:     | E-mail addresses:     |
 | (Retired)          | FA29 0E3B 35AF E8AE 6651 | paul%whooppee.com@localhost     |
 | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette%netbsd.org@localhost   |
 +--------------------+--------------------------+-----------------------+