From owner-freebsd-multimedia@FreeBSD.ORG Fri Jul 11 12:58:57 2003 Return-Path: Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D16537B401 for ; Fri, 11 Jul 2003 12:58:57 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA59C43F85 for ; Fri, 11 Jul 2003 12:58:56 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc12) with ESMTP id <200307111958550140063j6le>; Fri, 11 Jul 2003 19:58:56 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id MAA51027; Fri, 11 Jul 2003 12:58:55 -0700 (PDT) Date: Fri, 11 Jul 2003 12:58:53 -0700 (PDT) From: Julian Elischer To: Sean_Welch@alum.wofford.org In-Reply-To: <752678.1057948500755.JavaMail.nobody@kermit.psp.pas.earthlink.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: John-Mark Gurney cc: multimedia@freebsd.org Subject: Re: BSD video capture emulation question X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jul 2003 19:58:57 -0000 On Fri, 11 Jul 2003, Sean Welch wrote: > > John-Mark, could you clarify your concept of the kernel/ > > userland split for a new video API? More particularly, what > > parts would be handled by the kernel and how do you envision > > the userland interacting with that part? Are we talking about > > creating a new device node (a la v4l) or a new way of interacting > > with existing device nodes? > > For the most part, the kernel would just export many different device > nodes, one for each part of the card. I've started work on a design > document. It is VERY rough and incomplete, but I'll put it up. > I'm hoping htere is a good compatibility with v4l since mot of the apps will be written to that spec. if not an exact match, at least something that can be 'logically' similar and thus portable with a simple shim.