Re: svn commit: r223989 - head/sys/dev/usb/input

2011-08-29 Thread Bruce Evans
On Mon, 29 Aug 2011, Andriy Gapon wrote: Having got my feet a little bit wet in this code I have only the following to add: on 20/07/2011 18:32 Bruce Evans said the following: [snip] A non-broken API needs cn_open() and cn_close() functions which would normally switch the driver in an out of

Re: svn commit: r223989 - head/sys/dev/usb/input

2011-08-29 Thread Andriy Gapon
on 29/08/2011 17:54 Hans Petter Selasky said the following: > On Monday 29 August 2011 16:33:00 Andriy Gapon wrote: >> Not sure if this answers my question, which is not about pause vs >> ukbd_yield, but is about ukbd_yield vs kern_yield. >> In other words, why you couldn't simply use kern_yield wh

Re: svn commit: r223989 - head/sys/dev/usb/input

2011-08-29 Thread Hans Petter Selasky
On Monday 29 August 2011 16:33:00 Andriy Gapon wrote: > Not sure if this answers my question, which is not about pause vs > ukbd_yield, but is about ukbd_yield vs kern_yield. > In other words, why you couldn't simply use kern_yield where you used > ukbd_yield? Is this a new function. I think I use

Re: svn commit: r223989 - head/sys/dev/usb/input

2011-08-29 Thread Andriy Gapon
on 29/08/2011 17:27 Hans Petter Selasky said the following: > On Monday 29 August 2011 15:25:08 Andriy Gapon wrote: >> Another question - why ukbd_yield() is needed? >> Why kern_yield() would not be good here? >> What are the priority manipulations in ukbd_yield? >> Not saying that the code is inco

Re: svn commit: r223989 - head/sys/dev/usb/input

2011-08-29 Thread Hans Petter Selasky
On Monday 29 August 2011 15:25:08 Andriy Gapon wrote: > Another question - why ukbd_yield() is needed? > Why kern_yield() would not be good here? > What are the priority manipulations in ukbd_yield? > Not saying that the code is incorrect, just that this is not explained in > the commit message. T

Re: svn commit: r223989 - head/sys/dev/usb/input

2011-08-29 Thread Andriy Gapon
on 14/07/2011 00:07 Hans Petter Selasky said the following: > Author: hselasky > Date: Wed Jul 13 21:07:50 2011 > New Revision: 223989 > URL: http://svn.freebsd.org/changeset/base/223989 > > Log: > Fix for dump after shutdown with USB keyboard plugged in. It appears that > the > system timer

Re: svn commit: r223989 - head/sys/dev/usb/input

2011-08-29 Thread Andriy Gapon
Having got my feet a little bit wet in this code I have only the following to add: on 20/07/2011 18:32 Bruce Evans said the following: [snip] > A non-broken API needs cn_open() and cn_close() functions which would > normally switch the driver in an out of polling mode. Given these > interfaces

Re: svn commit: r223989 - head/sys/dev/usb/input

2011-07-22 Thread Alexander Leidinger
On Fri, 22 Jul 2011 13:46:28 +0300 Andriy Gapon wrote: > I think that your suggestion makes a lot of sense and is the proper > approach to fixing this issue. Now we need some sole to actually do > the work :-) Or at least someone who documents the need to do it (and either the explanation or a

Re: svn commit: r223989 - head/sys/dev/usb/input

2011-07-22 Thread Andriy Gapon
on 20/07/2011 18:32 Bruce Evans said the following: [snip] > The low-level console driver should switch to polling mode to read the > keystrokes. However, its API is broken as designed, so it can only > [tell the driver level to] do this around each poll for a character. > Polling involves polling

Re: svn commit: r223989 - head/sys/dev/usb/input

2011-07-20 Thread Bruce Evans
On Wed, 20 Jul 2011, Hans Petter Selasky wrote: On Wednesday 20 July 2011 12:37:44 Andriy Gapon wrote: This special code is a workaround. The problem is that when not polling the key presses will be fed into syscons I think, and not returned via the polling function. That's why there is a time

Re: svn commit: r223989 - head/sys/dev/usb/input

2011-07-20 Thread Hans Petter Selasky
On Wednesday 20 July 2011 12:37:44 Andriy Gapon wrote: > > This special code is a workaround. The problem is that when not polling > > the key presses will be fed into syscons I think, and not returned via > > the polling function. That's why there is a timer there to distinguish > > when polling

Re: svn commit: r223989 - head/sys/dev/usb/input

2011-07-20 Thread Andriy Gapon
on 18/07/2011 17:10 Hans Petter Selasky said the following: > Hi, > >> The question is: why this special subcase is needed at all. > > Yes, according to the current keyboard implementation in the kernel. > >> If I understand correctly, the polling mode is used only in some special >> situations/

Re: svn commit: r223989 - head/sys/dev/usb/input

2011-07-18 Thread Hans Petter Selasky
Hi, > The question is: why this special subcase is needed at all. Yes, according to the current keyboard implementation in the kernel. > If I understand correctly, the polling mode is used only in some special > situations/contexts. > So why not always use the generic code (after this if-block)

Re: svn commit: r223989 - head/sys/dev/usb/input

2011-07-18 Thread Andriy Gapon
on 14/07/2011 00:07 Hans Petter Selasky said the following: > Author: hselasky > Date: Wed Jul 13 21:07:50 2011 > New Revision: 223989 > URL: http://svn.freebsd.org/changeset/base/223989 > > Log: > Fix for dump after shutdown with USB keyboard plugged in. It appears that > the > system timer

svn commit: r223989 - head/sys/dev/usb/input

2011-07-13 Thread Hans Petter Selasky
Author: hselasky Date: Wed Jul 13 21:07:50 2011 New Revision: 223989 URL: http://svn.freebsd.org/changeset/base/223989 Log: Fix for dump after shutdown with USB keyboard plugged in. It appears that the system timer is stopped during shutdown and that the pause() statement in ukbd causes infi