From owner-freebsd-current@FreeBSD.ORG Thu Jun 23 21:01:56 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 5AF1216A41C for ; Thu, 23 Jun 2005 21:01:56 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14B5B43D49 for ; Thu, 23 Jun 2005 21:01:55 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id 6D0DF3BE7F; Thu, 23 Jun 2005 16:01:55 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 19950-01-25; Thu, 23 Jun 2005 16:01:55 -0500 (CDT) Received: from out001.email.savvis.net (out001.apptix.savvis.net [216.91.32.44]) by mailgate1b.savvis.net (Postfix) with ESMTP id 3452D3BE5C; Thu, 23 Jun 2005 16:01:55 -0500 (CDT) Received: from s228130hz1ew031.apptix-01.savvis.net ([10.146.4.28]) by out001.email.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Jun 2005 16:01:53 -0500 Received: from [10.254.186.111] ([64.14.1.106]) by s228130hz1ew031.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 23 Jun 2005 16:01:46 -0500 Message-ID: <42BB2339.8050101@savvis.net> Date: Thu, 23 Jun 2005 14:01:45 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Moolenaar References: <42BAFE37.4080504@savvis.net> <20050623201244.GA4184@ns1.xcllnt.net> In-Reply-To: <20050623201244.GA4184@ns1.xcllnt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jun 2005 21:01:47.0012 (UTC) FILETIME=[C47E8440:01C57836] X-Virus-Scanned: amavisd-new at savvis.net 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 21:01:56 -0000 Marcel, >>- 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. great. would this eventually replace syscons(4)/pcvt(4)/etc. on all supported platforms? or will it always be non-i386 console code? >>- 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. ok >>- 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. ok >>- 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. as a transition plan i was thinking about changing syscons(4), so it would 1) (a) have a hint to which keyboard (or keyboards) it should to use by default or (b) always try "kbdmux" first then any "*" keyboard 2) if syscons(4) found "kbdmux" keyboard (because kbdmux.ko was loaded from the loader.conf or compiled into kernel) then it would scan all available non "kbdmux" keyboards and add them to the kbdmux. the above two steps should be performed on boot and/or when syscons(4) detects no active keyboard. >>- 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? right now when usb keyboard is attached devd(8) calls kbdcontrol(1) and tries to switch active keyboard. if kbdmux(4) is active the usb keyboard should be added to the mux - not switched. in the same time, it is still might be desirable to really switch keyboards, i.e. between kbdmux and say wired ps2 keyboard that is not in the mux. so, i was thinking to change kbdcontrol(1) so it would 1) when -k (add/switch keyboard) option is given check if the current keyboard is kbdmux the add keyboard to the mux, otherwise switch keyboard. 2) provide a new option to kbdcontrol(1) that would _really_ switch keyboard (no matter if current keyboard is kbdmux or not) 3) -K (disconnect keyboard) with kbdmux should either be (a) noop or (b) delete keyboard from the mux. i kinda like (a) because user must specify keyboard index to disconnect in (b) and this is yet another api change. on the other hand it might be desirable to disconnect keyboard from the must without detaching it (another new option?) now, another case is when keyboard is disconnected. in this case devd(8) calls kbdcontrol(1) and tries to switch keyboard to kbd0 unconditionally. in theory this could work (if kbd0 is kbdmux), but may be its better to have default keyboard syscons(4) hint and then use kenv(1) to fetch it and have kbdcontrol(1) use it. does this make any sense? >>- 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. great. thanks for your comments! max