svn commit: r223989 - head/sys/dev/usb/input
Andriy Gapon
avg at FreeBSD.org
Wed Jul 20 10:37:51 UTC 2011
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
More information about the svn-src-all
mailing list