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 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
