From owner-cvs-all@FreeBSD.ORG Fri Dec 30 02:30:27 2005 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD76F16A41F; Fri, 30 Dec 2005 02:30:26 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from bugor.portaone.com (bugor.portaone.com [65.61.200.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id B253443D6E; Fri, 30 Dec 2005 02:30:22 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.1.2] (S0106000f3d63befd.vs.shawcable.net [70.71.19.119]) (authenticated bits=0) by bugor.portaone.com (8.13.4/8.13.4) with ESMTP id jBU2UIhQ063846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Dec 2005 02:30:18 GMT (envelope-from sobomax@portaone.com) Message-ID: <43B49BBA.9070801@portaone.com> Date: Thu, 29 Dec 2005 18:30:18 -0800 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Maksim Yevmenkin References: <200512292011.jBTKBkVa073791@repoman.freebsd.org> <43B45653.5050606@portaone.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1219/Wed Dec 28 22:57:59 2005 on bugor.portaone.com X-Virus-Status: Clean X-Spam-Status: No, score=0.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL,SPF_SOFTFAIL autolearn=no version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on bugor.portaone.com Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/usr.sbin/kbdcontrol kbdcontrol.1 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Maxim.Sobolev@portaone.com List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2005 02:30:27 -0000 Maksim Yevmenkin wrote: > [...] > >>> thanks for doing this! unfortunately, the sequence of command you have >>> put into the man page not entirely correct. >>> >>> it will work, if you do all the commands from the scripts and do it >>> fast enough. note that syscons(4) will try to grab the first available >>> keyboard when it does not have one, and, the first thing you do is to >>> release current keyboard. >> Actually I think you not quite correct - such syscons(4) behaviour is >> optional (opt in) and depends on 0x100 flags to sc(4). > > yes, it depends on the flag you have mentioned and the flag is set by > default :) from GENERIC.hints > > hint.sc.0.at="isa" > hint.sc.0.flags="0x100" > >> At least that sequence works here with GENERIC kernel/hints just fine. > > i never said it would not :) i just only pointed out that you have to > put this commands in the script. otherwise how are you going to type > after you have released the keyboard with "kbdcontrol -K"? :) Well, since there are < /dev/console everywhere it's probably assumed that those commands are executed from script or the pseudo-tty. >> In fact I believe the better way to handle this problem is to allow >> kbdmux(4) to be reconfigured on the fly, that is when it's already >> attached to the console. This way you will be able to attach it to the >> console first and then add/remove actual keyboards as you see fit. I >> don't think it will be very hard to do. >> >> What do you think? > > that is why syscons(4) has to support KBD{ADD,DEL}KB ioctl(2)s. you > see, in order to issue ioctl(2) one must open /dev/kdbmux0 device. the > problem is that once keyboard was "kbd_allocate()"d, open(2) calls on > /dev/Xkbd will fail. so you see, once you switched keyboard to > kbdmux(4) you can not open /dev/kbdmux anymore. the only way to > reconfigure kdbmux(4) is to pass ioctl(2)s via syscons(4). just like > any other keyboard ioctl(2). > > so the sequence i sent allows you to reconfigure kbdmux(4) on-the-fly. But you can easily do what most other drivers do to workaround this problem - create separate management device node, through which it will be possible to inject ioctls regardless of the current state of the particular kbdmux instance. There are lot of such examples in the tree - ata(4) and md(4) drivers come into the mind instantly. > however, all of this is really a band-aid to allow people to at least > try kbdbux(4). i have patches to syscons(4) and kbd code that will > make kbdmux(4) to automatically take over any keyboard attached to the > system. everything done in kernel. i did not commit these because > kbdmux(4) has issues that i still need to figure out and fix. It's funny but appears that keyboard and mouse support are going in the entirely opposite directions - I've seen that somebody is working on moving as much mouse code out of the kernel as possible. Perhaps we need some unified HID framework like most of the modern operating systems do? -Maxim