From owner-freebsd-multimedia@FreeBSD.ORG Mon Mar 19 04:21:40 2007 Return-Path: X-Original-To: freebsd-multimedia@freebsd.org Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5410216A403 for ; Mon, 19 Mar 2007 04:21:40 +0000 (UTC) (envelope-from akm@theinternet.com.au) Received: from mail19.syd.optusnet.com.au (mail19.syd.optusnet.com.au [211.29.132.200]) by mx1.freebsd.org (Postfix) with ESMTP id E533413C487 for ; Mon, 19 Mar 2007 04:21:39 +0000 (UTC) (envelope-from akm@theinternet.com.au) Received: from camelot.theinternet.com.au (c211-30-133-243.carlnfd4.nsw.optusnet.com.au [211.30.133.243]) by mail19.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l2J4J4Zu016432; Mon, 19 Mar 2007 15:19:07 +1100 Received: by camelot.theinternet.com.au (Postfix, from userid 1000) id 3AA8E6222; Mon, 19 Mar 2007 15:19:04 +1100 (EST) Date: Mon, 19 Mar 2007 15:19:04 +1100 From: Andrew Milton To: "Greg 'groggy' Lehey" Message-ID: <20070319041904.GA2565@camelot.theinternet.com.au> Mail-Followup-To: Greg 'groggy' Lehey , Dieter , freebsd-multimedia@freebsd.org References: <200703160238.CAA03442@sopwith.solgatos.com> <20070319032038.GR32513@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070319032038.GR32513@wantadilla.lemis.com> User-Agent: Mutt/1.5.9i Cc: freebsd-multimedia@freebsd.org, Dieter Subject: Re: BIRC or FIRC (was: LIRC guide for FreeBSD) X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2007 04:21:40 -0000 +-------[ Greg 'groggy' Lehey ]---------------------- | | What I'd like to see would be a more traditional device model, where | the programs that are interested open the device and read events from | it. How that would work with multiple mplayers (for example) remains | to be seen, but clearly it's silly to expect the remote control to | know the names of the programs it's talking to. | | Any thoughts? When I wrote my one, I had (amongst the output modes) a 'udp' service clients could subscribe to, and the 'server' part simply sent the events out over that. The joy of that was I didn't have to have the application residing on the machine with the IR receiver, and I didn't have to mess with IR extenders. You could use multicast I guess if you wanted to be fancy. Remembering you can have multiple remote controls per IR receiver, if you wanted a device, I think you'd still need a userland component that read /dev/remote or and sent the events out. Rather than having applications trying to raw read from the device. So say /dev/remote just sent out the raw timing data, the userland portion could do all the decoding of that and work out which remote and which button it was and then send out the events. Although this has issues too, since the DVICO USB receiver just sends out 3 digit numbers from memory (i.e. they're pre-cooked). Not that it's hard to work around it, just something to be aware of. I don't think you want to try to do all that inside the kernel. I don't think you want to have to load a device driver everytime you get a new remote control either. One per receiver, sure. But then do you want the application to have to know which /dev/ entry to open? It would be easier to configure a userland component to deal with that. You might need multiple receivers, because some remotes are just outside the range of some receivers (and vice versa). I remember dealing with XBOX remotes and those being a real pain. I still have a bit of IR hardware here; Packard Bell Serial Receiver (strobes CD) DVICO USB Receiver Niveus USB Receiver + Blaster and heaps of different remote controls (my wife says I was obsessed), so I can definitely help out for any effort that gets launched to build an IR system, in terms of development, testing, whatever. -- Andrew Milton akm@theinternet.com.au