Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Aug 2016 21:54:10 +0200
From:      Oliver Pinter <oliver.pinter@hardenedbsd.org>
To:        Bruce Evans <bde@freebsd.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org,  svn-src-head@freebsd.org
Subject:   Re: svn commit: r304699 - head/sys/dev/usb/input
Message-ID:  <CAPQ4fftiGySXa%2BMx3P28J4wqyJBxyLsgFLLYbq0Buu4CNe9fLA@mail.gmail.com>
In-Reply-To: <201608231950.u7NJoGD8035436@repo.freebsd.org>
References:  <201608231950.u7NJoGD8035436@repo.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 8/23/16, Bruce Evans <bde@freebsd.org> wrote:
> Author: bde
> Date: Tue Aug 23 19:50:16 2016
> New Revision: 304699
> URL: https://svnweb.freebsd.org/changeset/base/304699
>
> Log:
>   Fix key delay and repeat, part 1.
>
>   kbdcontrol -r fast is documented to give a non-emulated atkbd's fastest
>   rate of 250.34, but is misimplemented to request this as 0.0.  ukbd
>   supports many nonstandard rates, although it is currently too inaccurate
>   by a factor of several hundred for non-huge nonstandard rates to be
>   useful.  It mapped 0.0 to 200.0.  A repeat delay of 0 means a rate of
>   infinity which is quite fast, but physical constraints limit this to
>   a few MHz and the inaccuracies made it almost usable.
>
>   Convert 0.0 to the documented 250.34.
>
>   Also convert negative args and small args to the 250.34 minimal ones,
>   like atkbd does.  This is for KDSETREPEAT -- the 2 versions of the
>   deprecated KDSETRAD have bounds checking.  Keep not doing any bounds
>   checking or conversions for upper limits since nonstandard large
>   delays are useful for testing.
>
>   The inaccuracies are dependent on HZ and the timeout implementation.
>   With the old timeout implementation and HZ = 1000, 200.0 probably
>   worked better to emulate 250.34 than 250.34 itself.  HZ = 100 gives
>   roundoff errors that accidentally reduce the inaaccuracies, and
>   event timers reduce the inaccuracies even more, so 200.0 was giving
>   more like itself (perhaps 215.15 on average but sometimes close to
>   10 msec repeat which is noticebly too fast).  This commit makes 0.0
>   noticeably too slow, like 250.34 always was.
>
> Modified:
>   head/sys/dev/usb/input/ukbd.c
>
> Modified: head/sys/dev/usb/input/ukbd.c

Hi Bruce!

Do you plan to MFC these changes to 10-STABLE? It would be really nice
to see all of these improvements.


> ==============================================================================
> --- head/sys/dev/usb/input/ukbd.c	Tue Aug 23 19:41:49 2016	(r304698)
> +++ head/sys/dev/usb/input/ukbd.c	Tue Aug 23 19:50:16 2016	(r304699)
> @@ -1887,17 +1887,14 @@ ukbd_ioctl_locked(keyboard_t *kbd, u_lon
>  		if (!KBD_HAS_DEVICE(kbd)) {
>  			return (0);
>  		}
> -		if (((int *)arg)[1] < 0) {
> -			return (EINVAL);
> -		}
> -		if (((int *)arg)[0] < 0) {
> -			return (EINVAL);
> -		}
> -		if (((int *)arg)[0] < 200)	/* fastest possible value */
> -			kbd->kb_delay1 = 200;
> -		else
> -			kbd->kb_delay1 = ((int *)arg)[0];
> -		kbd->kb_delay2 = ((int *)arg)[1];
> +		/*
> +		 * Convert negative, zero and tiny args to the same limits
> +		 * as atkbd.  We could support delays of 1 msec, but
> +		 * anything much shorter than the shortest atkbd value
> +		 * of 250.34 is almost unusable as well as incompatible.
> +		 */
> +		kbd->kb_delay1 = imax(((int *)arg)[0], 250);
> +		kbd->kb_delay2 = imax(((int *)arg)[1], 34);
>  		return (0);
>
>  #if defined(COMPAT_FREEBSD6) || defined(COMPAT_FREEBSD5) || \
> _______________________________________________
> svn-src-head@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-head
> To unsubscribe, send any mail to "svn-src-head-unsubscribe@freebsd.org"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPQ4fftiGySXa%2BMx3P28J4wqyJBxyLsgFLLYbq0Buu4CNe9fLA>