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: pgoyette%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
    mlelstv%serpens.de@localhost
Subject: Re: kern/55103: /dev/wsmouse returns EINVAL
Date: Thu, 2 Apr 2020 05:40:41 -0700 (PDT)

 On Thu, 2 Apr 2020, Michael van Elst wrote:
 
 > The following reply was made to PR kern/55103; it has been noted by GNATS.
 >
 > From: Michael van Elst <mlelstv%serpens.de@localhost>
 > To: Paul Goyette <paul%whooppee.com@localhost>
 > Cc: gnats-bugs%netbsd.org@localhost
 > Subject: Re: kern/55103: /dev/wsmouse returns EINVAL
 > Date: Thu, 2 Apr 2020 07:21:24 +0200
 >
 > On Wed, Apr 01, 2020 at 07:38:52PM -0700, Paul Goyette wrote:
 >
 > > Looking at the original code, it seems pretty clear that the intent was
 > > to restrict use of version-0 to compat code, and that without compat
 > > code one should use WSEVENT_VERSION.  And that is what the current code
 > > implements, as far as I can tell.
 >
 > So, in your opinion, everything is correct now because reading the
 > mouse without a special program that negotiates the non-default
 > protocol version is forbidden. It wasn't forbidden in the beginning,
 > it wasn't forbidden when the protocol was updated, but it is now
 > forbidden after compat code was removed from the default for
 > unrelated reasons but it was still the intent all the time and
 > must be honored and that's why autoloading the compat module
 > on some platforms, which is the opposite of that intent, also
 > exists but is also correct.
 >
 > Please understand that I cannot believe this.
 >
 > I say that the final consequence wasn't thought about then and
 > reading the mouse with simple tools like cat or hexdump is
 > something that is useful and that ability should be restored.
 
 I agree that there is a bug here, but the bug is NOT the requirement
 that use of the old-version protocol is linked to COMPAT_50.  That
 requirement has existed since the new-version protocol was created.
 
 Rather, the bug is that, when the new protocol was created, caller(s)
 were not updated to use the new protocol.  The caller(s) were left
 using the old protocol, and therefore the caller(s) require that the
 COMPAT_50 option be present.
 
 As I see it, there are three reasonable paths forward to resolve this
 issue:
 
 1. Identify and update the caller(s) of this protocol (possibly with
     a sysctl(8) variable to control selection of the protocol), or
 
 2. Add code in wsevent.c to attempt to autoload the compat_50 module
     if wsevent_copyout_events() is called with the old version, or
 
 3. Return the evbarm port (and possibly others) to include COMPAT_50
     by default.
 
 
 
 +--------------------+--------------------------+-----------------------+
 | 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   |
 +--------------------+--------------------------+-----------------------+