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

[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) that does
> "proper" polling?  What do we win when using this special case that seems
> to depend on the scheduler?

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 starts 
and polling stops. It is not enough just to enable/disable polling around each 
key-press like currently done.

Please test any patches that it works in the filesystem mount prompt after 
boot: Edit /etc/fstab and put some non-existing device there for root 
partition. Reboot. Make sure USB keyboard works in the prompt which appears.

> 
> Unfortunately I couldn't fully understand commit log of r203896.
> 
> One of the reasons I am asking about this is that soon-ish we may have
> changes that disable scheduler in a context where panicstr != NULL.

Ok. Please make sure that USB keyboard works reliably in boot prompt when 
asking for file-system and in KDB and after dump during shutdown. An of course 
after logged in like a normal user :-)

--HPS