From owner-cvs-all@FreeBSD.ORG Tue Nov 16 18:37:53 2004 Return-Path: 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 87BB016A4CE; Tue, 16 Nov 2004 18:37:53 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id D920743D2F; Tue, 16 Nov 2004 18:37:52 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id iAGIe0nM026039; Tue, 16 Nov 2004 11:40:00 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <419A492A.7020602@freebsd.org> Date: Tue, 16 Nov 2004 11:38:34 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maksim Yevmenkin References: <7302.1100627038@critter.freebsd.dk> <20041116180905.GA11906@odin.ac.hmc.edu> In-Reply-To: X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Brooks Davis cc: cvs-src@freebsd.org cc: Poul-Henning Kamp cc: src-committers@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/vkbd vkbd.c vkbd_var.hsrc/sys/modules/vkbd Makefile X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Nov 2004 18:37:53 -0000 Maksim Yevmenkin wrote: > On Tue, 16 Nov 2004 10:09:05 -0800, Brooks Davis > wrote: > >>On Tue, Nov 16, 2004 at 10:00:24AM -0800, Maksim Yevmenkin wrote: >> >> >> >>>On Tue, 16 Nov 2004 18:43:58 +0100, Poul-Henning Kamp >>> wrote: >>> >>>>In message , Maksim Yevmenkin writes >>>>: >>>> >>>> >>>> >>>>>On Tue, 16 Nov 2004 18:04:56 +0100, Poul-Henning Kamp >>>>> wrote: >>>>> >>>>>>In message <200411161659.iAGGxNiX087329@repoman.freebsd.org>, Maksim Yevmenkin >>>>>>writes: >>>>>> >>>>>> >>>>>> >>>>>>>emax 2004-11-16 16:59:23 UTC >>>>>>> >>>>>>> FreeBSD src repository >>>>>>> >>>>>>> Added files: >>>>>>> sys/dev/vkbd vkbd.c vkbd_var.h >>>>>>> sys/modules/vkbd Makefile >>>>>>> Log: >>>>>>> Add virtual AT keyboard driver vkbd(4). >>>>>>> Not yet connected to the build. >>>>>> >>>>>>I thought we had one of those already ? >>>>> >>>>>when? where? did i miss it? >>>> >>>>sys/dev/kbd (and various MD stuff all over the place) ? >>> >>>perhaps i'm missing something here. the idea behind vkdb(4) is to >>>create a keyboard without a keyboard. that is to create a keyboard >>>that accepts scan codes from userspace and not from real hardware. >>>that is what vkbd(4) does. it creates a new keyboard (just like >>>ukbd(4) etc) and register it with kbd(4). basically what i want to do >>>is to obtain scan codes from bluetooth keyboard and then feed them >>>into the kernel. the idea is that bluetooth hid daemon looks for the >>>bluetooth keyboard, connects to it, switches active keyboard to >>>vkbd(4) , reads scan codes and feeds them into vkbd(4). when bluetooth >>>keyboard is gone the bluetooth hid daemon switches back to wired >>>keyboard. i do not think i can do it with kdb(4), can i? >> >>Have you considered making the virtual keyboard an in kernel client of >>it's child keyboard(s)? If you don't do this, you can't use the virtual >>keyboard in single user mode or in the debugger. > > > vkbd(4) man page says that it will not work with ddb(4) :) and (at > this point) i'm not sure whether this is required. in case of > bluetooth hid all scan codes have to passed through bluetooth stack. i > definitely do not want to use bluetooth keyboard in ddb(4) or in > single user mode :) > > i think i see where you are going. you are probably thinking about > some sort of lights-out management where you use only network > connection to control box remotely, a-la pc-weasel and eric cards. am > i close? > > max I appreciate the work here, but we are starting to grow too many independent keyboard abstractions that don't seem to work together and don't seem to solve the primary problem that we have right now. What we really need is a single unified keyboard and mouse virtualization layer that allows bluetooth, usb, and at/ps2 devices to plug in at the bottom and talk to the one or more console interfaces at the top. It should allow devices to be plugged in at runtime and should insulate the real console interface from caring which keyboard is plugged in at boot, if any are at all. And yt _does_ need to work in single user mode and in DDB. I know I'm saying a lot of 'shoulds' right now, but the rise of these non-at/ps2 keyboards is causing us lots of problems and we need to fix it. Brooks had talked about working on something similar to what I've described above, so please work with him to mold your vkbd work into that model. Scott