From owner-svn-src-head@FreeBSD.ORG Wed Jul 20 10:37:51 2011 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66C2A1065672; Wed, 20 Jul 2011 10:37:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4BAAE8FC0C; Wed, 20 Jul 2011 10:37:49 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA28500; Wed, 20 Jul 2011 13:37:45 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E26AFF8.8080107@FreeBSD.org> Date: Wed, 20 Jul 2011 13:37:44 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <201107132107.p6DL7ojq099900@svn.freebsd.org> <4E242C9E.6010604@FreeBSD.org> <201107181610.49443.hselasky@c2i.net> In-Reply-To: <201107181610.49443.hselasky@c2i.net> X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "svn-src-head@FreeBSD.org" , "svn-src-all@FreeBSD.org" , "src-committers@FreeBSD.org" Subject: Re: svn commit: r223989 - head/sys/dev/usb/input X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 10:37:51 -0000 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