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

[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/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.

I must admit that I failed to understand this paragraph, so I think that I should
shut up until I know the relevant code better.

> 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.

I do not plan to make any changes to USB/ukbd code at the moment.

>>
>> 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 :-)

Sure, but I do not think that my changes may affect any of the environments that
you've mentioned.  I am mostly concerned about "press any key to reboot" prompt
after (unattended) panic, but that would be a pretty minor issue IMO.

-- 
Andriy Gapon