From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 17 19:36:07 2007 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.org Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 182E516A409; Tue, 17 Apr 2007 19:36:07 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.171]) by mx1.freebsd.org (Postfix) with ESMTP id EB39213C45D; Tue, 17 Apr 2007 19:36:06 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/smtpout01/MantshX 4.0) with ESMTP id l3HJO32V007031; Tue, 17 Apr 2007 12:24:03 -0700 (PDT) Received: from [172.24.104.161] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id l3HJO0cH027667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Apr 2007 12:24:01 -0700 (PDT) In-Reply-To: <46250237.000008.20157@mfront8.yandex.ru> References: <46250237.000008.20157@mfront8.yandex.ru> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Tue, 17 Apr 2007 12:23:00 -0700 To: thIOretic@yandex.ru X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: freebsd-hackers@FreeBSD.org, philip@FreeBSD.org, thioretic@FreeBSD.org, nsouch@free.fr, freebsd-arch@FreeBSD.org Subject: Re: GSoC project community intro and sync X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2007 19:36:07 -0000 On Apr 17, 2007, at 10:21 AM, thIOretic wrote: > I would like to get info from everyone, who may take similar > efforts in FreeBSD input handling. I'm aware of > * newpsm framework > * KGI/KII > * vtc(4) was mentioned, but its code seems to do nothing from my > project thesis perspective. Or I've missed something? As for vtc(4): I've not been working on input devices because of the lack of a generic layer. Note that vtc(4) deals with the low-level console as much as it deals with user-visible terminals, so from that point of view, a user space stack will not address the need for having console input when there's no (functional) user space -- this includes early boot, the kernel debugger and single-user mode. I therefore doubt that it will sufficiently (or at all) solve problems we already have. Also, while multiplexing is an important feature I think that de- multiplexing is important too. With USB and multi-head or multiple graphics cards it's conceptually easy to turn a PC into a multi- user workstation, having multiple independent terminals. This implies that input devices need to be tied to output devices, which together form one or more terminals. In short: We do need a generic input framework, but I think we need it in the kernel, not in user space. I also think that a generic input layer should be capable of handling both focussed and non- focussed input devices to lay the foundation for configurations that do not include keyboards. -- Marcel Moolenaar xcllnt@mac.com