From owner-freebsd-current@FreeBSD.ORG Thu Jun 23 20:12:45 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 A837216A41C for ; Thu, 23 Jun 2005 20:12:45 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65DDF43D48 for ; Thu, 23 Jun 2005 20:12:45 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (localhost.xcllnt.net [127.0.0.1]) by ns1.xcllnt.net (8.13.3/8.13.3) with ESMTP id j5NKCiRK004377; Thu, 23 Jun 2005 13:12:44 -0700 (PDT) (envelope-from marcel@ns1.xcllnt.net) Received: (from marcel@localhost) by ns1.xcllnt.net (8.13.3/8.13.3/Submit) id j5NKCipf004376; Thu, 23 Jun 2005 13:12:44 -0700 (PDT) (envelope-from marcel) Date: Thu, 23 Jun 2005 13:12:44 -0700 From: Marcel Moolenaar To: Maksim Yevmenkin Message-ID: <20050623201244.GA4184@ns1.xcllnt.net> References: <42BAFE37.4080504@savvis.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42BAFE37.4080504@savvis.net> User-Agent: Mutt/1.4.2.1i 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: Thu, 23 Jun 2005 20:12:45 -0000 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". > - locking: right now the code relies on Giant mutex (just like the rest > keyboard drivers do); Keep it that way. It's better to make locking changes in seperate commits, especially when it affects multiple components. > - code duplication: there are a pieces of code that were stolen from > atkbd.c. very similar pieces of code exist in ukbd.c, vkbd.c and now in > kbdmux.c. imo that is three times too many. perhaps these pieces could > be moved into some common shared place? I think it's best to look at the release schedule. If this is worthy to get into 6.0, then don't worry about the duplication. Just make sure it works and get it committed soon (without forcing it of course). Then, when the 6 branch has been created, work on refactoring and locking to get it perfect in 7.0. You can always MFC if such would be beneficial. > - need comments/input from "non-intel" folks; make that non-i386... This won't be useful on ia64 because syscons doesn't work there and I don't plan to try to makee it work there ever. I'm working on a replacement where the multiplexing of the keyboard (as well as the graphics adapter) is inherently part of the framework. In particular, the user will be able to control how input and output devices get multiplexed and/or untied into seperate consoles. This all goes beyond what you're doing, so don't worry about it. > - should kbdmux(4) be merged with kbd/syscons and used by default? I think that would make sense, given that syscons is pretty much single-head. > - 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. > - if kbdmux(4) is not default keyboard then what syscons(4) should do? > look for "kbdmux" keyboard first and the look for any ("*") keyboard? This quickly gets complex. I would say that if kbdmux(4) is configured into the kernel, it will always be used. The question is whether kbdmux should be optional or not. > - what kbdcontrol(8) behavior should be? should it be smart enough to > recognize if current keyboard is kbdmux and behave differently? That depends on whether there's anything special or different it needs to do. Since your question seems to imply it does, could you explain how, where and why? > - 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. Note: I don't speak for re@, so don't take my yes as an approval to do so. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net