From owner-freebsd-multimedia@FreeBSD.ORG Sun Apr 24 05:29:43 2005 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 64CF116A4CE for ; Sun, 24 Apr 2005 05:29:43 +0000 (GMT) Received: from mail231.csoft.net (resin.csoft.net [63.111.22.86]) by mx1.FreeBSD.org (Postfix) with SMTP id E024F43D2F for ; Sun, 24 Apr 2005 05:29:42 +0000 (GMT) (envelope-from jakemsr@jakemsr.com) Received: (qmail 24618 invoked from network); 24 Apr 2005 05:35:31 -0000 Received: from unknown (HELO puff.jakemsr.gom) (63.111.27.87) by mail231.csoft.net with SMTP; 24 Apr 2005 05:35:31 -0000 Received: (from jakemsr@jakemsr.com) by puff.jakemsr.gom (mini_sendmail/1.3.5 16nov2003); Sat, 23 Apr 2005 22:29:41 PDT (sender jakemsr@puff.jakemsr.gom) Date: Sat, 23 Apr 2005 22:29:41 -0700 From: Jacob Meuser To: freebsd-multimedia@freebsd.org Message-ID: <20050424052941.GA3339@puff.jakemsr.gom> Mail-Followup-To: freebsd-multimedia@freebsd.org References: <20050423225506.GA25461@puff.jakemsr.gom> <426B23BA.6060206@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <426B23BA.6060206@elischer.org> User-Agent: Mutt/1.4.2i Subject: Re: patch for bktr(4): don't reset tuner on open/close 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: Sun, 24 Apr 2005 05:29:43 -0000 On Sat, Apr 23, 2005 at 09:42:34PM -0700, Julian Elischer wrote: > Jacob Meuser wrote: > >the following is a patch that is in OpenBSD's bktr. > > > >the idea is to not reset the tuner device on open(2) and close(2). > > > >effects: > > - don't need to hold /dev/tuner open to get audio. > > - selected channelset won't get clobbered on open/close. IMO, the > > current behaviour here is idiotic. the channelset has nothing to > > do with the hardware. it is internally used by the driver. also, > > this is IMO a much cleaner fix to the problems with V4L programs > > not tuning properly because they never set the channelset. now > > the correct channelset can be set at bootup with something like > > bsdbktrtvtune or whatever, instead of rebuilding the kernel with > > the default channelset hardcoded into the driver. > > > >BTW, I haven't tested this on FreeBSD at all. it might need some > >tweaking. the diff is also set up so that BKTR_NO_OPEN_RESET must > >be defined to enable it. ultimately, I think this should be the > >default behaviour. > > > > > can you comment on what you mean by "V4L programs"? > (since we don't have V4L on freeBSD (as such)) mplayer, xawtv, etc. I guess what I meant was programs that were originally for V4L and then ported (with some pieces missing). the bktr interface is not very intuitive, and it's pretty easy, IMO, to understand why some projects that were ported from V4L to bktr don't do things quite right. probably the most common issue is with tuning via TVTUNER_SETFREQ. on the surface this looks like VIDIOCSFREQ or VIDIOC_S_FREQUENCY. however, bktr uses it's internal channelset to calculate carrier offset, etc. this does not happen in the linux bttv driver. as a result, programs like mplayer and xawtv never set the channelset. for mplayer, allowing a user to choose the channelset (because remember, as it is now, the channelset gets reset to the default everytime the tuner is opened) would require another option. xawtv has a menu box for selecting the channelset. however, the action of changing the channelset doesn't do anything but update the list pointer. the less intrusive fix would be to add TVTUNER_SETTYPE before each TVTUNER_SETFREQ. otherwise a new action would have to be added to xawtv (which I have patches for. but of course, they are for xawtv-3.x, which is now obsolete ...). also, there is (was) no documentation for bktr ioctls. some was recently added to the OpenBSD bktr manpage. your meteor(4) explains some of the METEOR_ ioctls, but it seems there are differences and some of the stuff it talks about was apparently never implemented in bktr(4)? --