From owner-freebsd-current@FreeBSD.ORG Fri Jun 24 03:40:30 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95B0A16A41C for ; Fri, 24 Jun 2005 03:40:30 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F9A143D4C for ; Fri, 24 Jun 2005 03:40:30 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5O3cY2j077272; Thu, 23 Jun 2005 21:38:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 23 Jun 2005 21:40:06 -0600 (MDT) Message-Id: <20050623.214006.22018233.imp@bsdimp.com> To: marcel@xcllnt.net From: "M. Warner Losh" In-Reply-To: <20050623201244.GA4184@ns1.xcllnt.net> References: <42BAFE37.4080504@savvis.net> <20050623201244.GA4184@ns1.xcllnt.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: request for comments: kbdmux(4) (long) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2005 03:40:30 -0000 In message: <20050623201244.GA4184@ns1.xcllnt.net> Marcel Moolenaar writes: : On Thu, Jun 23, 2005 at 11:23:51AM -0700, Maksim Yevmenkin wrote: : > : > - kbdmux model: kbdmux(4) is "super-keyboard" driver that consumes input : > (raw scancodes) from slave keyboards. the side effect is that _all_ : > keyboards attached to the kbdmux share the _same_ state. basically user : > can press ctrl on one keyboard and "C" on another keyboard and it still : > will work. is that good enough? : : I think one can argue both ways. Personally I think shift states should : be kept private to the keyboard. However, when processes are given : access to led- and shift states and are allowed to modify them, then : per-keyboard state doesn't pan out. Not unless the API has support for : multiple keyboards. So, go with what makes sense for this particular case. : Chances are that what you have now is already the most sensible, even : if it's not exactly "right". This is as right as we can get with our current model. If we're really mapping everything into one keyboard, I think it is the best we can do for now. It is also likely 'good enough' from a user point of view so long as the following works: Press control on kbd0 Press control on kbd1 C should produce ^C Release control on kbd0 D should produce ^D release control on kbd1 E should produce E. But I'd not hold up integrating it if this edge case doesn't work, so long as it doesn't crash the system... : > - kbdmux(4) switches all keyboards into K_RAW mode, so if kbdmux(4) is : > the default keyboard then perhaps all keyboard drivers could be : > simplified and just return K_RAW scancodes? : : Yes, if kbdmux(4) becomes default and non-optional, then it makes sense : to simplify and refactor. This would also be beneficial for the syscons : replacement I'm writing. The key here is 'and non-optional'. It might make sense for kbdmux(4) to keep doing this through the transition period. I think it must remain optional, however. It is useful to have multiple keyboards on machines that do not map into one. I've setup machines in the past with two video cards and two keyboards to have a two person workstation. It is also useful in certain embedded systems to allow similar things (since there are USB keyboard devices that produce ascii output, and you need to know which of the keyboard devices generated the sequence to know what the user actually did). : > - if kbdmux(4) is not default keyboard then what syscons(4) should do? : > - should kbdmux(4) go into 6.x? : : I would say: yes. It's an open issue for a while and it's good to : get it closed. It's one of those topics that hardcore developers may : not care too much about, but which is highly valued by the average : user. I'd put it into 6.0 even. I'd make it default during the beta releases. If there are issues, we turn it off by default for 6.0 and then early adapters can turn it on and the bugs can be worked out. For 6.1 we can reverse the default if there'd be no user visible changes from doing that for the typical user. 'Special needs' people, like I give in the example above, are in the vast minority and will be sophisticated enought to know what to do. The above assumes that all the /etc/rc goo, if any, can be worked out in time. I'm not the re@ and don't speak for them. The above is my two cents. Warner