svn commit: r195960 - in head/sys/dev/usb: . controller input
Hans Petter Selasky
hselasky at c2i.net
Mon Aug 3 18:33:13 UTC 2009
On Monday 03 August 2009 19:46:16 Bruce Evans wrote:
> On Mon, 3 Aug 2009, M. Warner Losh wrote:
> > In message: <200908030827.21108.hselasky at c2i.net>
> > : I see two solutions:
> > :
> > : 1) Disable the timekeeping if no keys are pressed.
> > :
> > : 2) Second option is to use getmicrotime. Actually what I need is just a
> > : millisecond time reference so I know when to repeat the last key.
> > :
> > : Any opinions? DELAY() or getmicrotime() ?
> DELAY(1) is somewhet usable.
I think DELAY(1) is not accurate enough.
I suggest that the DELAY(1000) is only active while a key is actually pressed.
See attached patch. Please test and report back.
> getmicrotime() is unusable because apart from the problems from it using
> microtime() (actually binuptime()), getmicrotime() has is only updated
> every 1/HZ seconds and depends on interrupts for the update. 1/HZ may
> usefully be as high as 1/10 seconds, and the update would never occur
> in ddb mode.
> microtime() is not a supported API in ddb or panic mode, but it works
> for short delays in most cases. Short means however long it takes for
> the hardware counter to wrap. See another reply for more details.
> binuptime() is better than microtime() for most purposes. Another
> problem with microtime() is that it is not guaranteed to be monotonic.
> The patch using microtime() has mounds of style bugs (mainly an empty
> line after almost every comment and statement).
> > I'd note the state at each poll, and if > 1ms has passed since the
> > down event, I'd repeat. I wouldn't use DELAY at all to see if you
> > needed to repeat: I'd let the clocking of the polling drive you here
> > (eg, you know that someone else will call it a lot, so leverage that
> > to avoid the delay).
> Determining whether 1 mS has elapsed is not supported in ddb or panic
> mode by any API, except microtime() usually works (see above).
> For polled console input (not necessarily in ddb or panic mode). It
> shouldn't be necessary for the low-level driver to spin internally,
> since cngetc() spins externally. ddb mode is the only mode that
> actually works almost right here: ddb disables all interrupts and stops
> all other CPUs, so interrupts and other CPUs can't eat the input.
> However, state changes to set up for polling, if any, should occur at
> a higher level (on entry to ddb for ddb mode), not on every call to
> cncheckc() or even on every call to cngetc(). The changes would be
> device-specific and wouldn't depend on disabling all interrupts and
> stopping all other CPUs. Then all modes would work (of fail) similarly
> to ddb mode.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 726 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-all/attachments/20090803/39e957dc/ukbd.c.bin
More information about the svn-src-all