Date: Tue, 3 Mar 1998 12:30:19 -0600 (CST) From: Jim Lowe <james@miller.cs.uwm.edu> To: hasty@rah.star-gate.com, luigi@labinfo.iet.unipi.it Cc: multimedia@FreeBSD.ORG Subject: Re: Video ioctl interface Message-ID: <199803031830.MAA07082@miller.cs.uwm.edu>
next in thread | raw e-mail | index | archive | help
> From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> > Subject: Re: Video ioctl interface > To: hasty@rah.star-gate.com (Amancio Hasty) > Date: Tue, 3 Mar 1998 17:20:10 +0100 (MET) > Cc: multimedia@FreeBSD.ORG, james@miller.cs.uwm.edu > > not really new interface, but... An extensible interface which can handle hardware Mpeg and sychnronizing audio/video would really be nice. > > I was trying to make vic use the brightness/contrast/etc controls which > are available on the meteor&bt848 and ran across a few probolems in > grabber-meteor.cc, ui-grabber.tcl, and also brooktree848.c ! I have some patches for vic which will allow access to the controls for the meteor card. Do you want these? I sent them into vic@ee.lbl.gov quite some time ago, but I don't think there has been a recent release of vic. > > Problems related to brooktree848.c : > > some ioctl are questionably located in tuner_ioctl(), e.g. > BT848_SCSAT, BT848_SVSAT etc. Some of them are duplicates of > the METEORxxx functions in video_ioctl(), but i do believe they > still belong to video_ioctl(). > > My understanding from the driver code is that only a single open is > allowed on the video (grabber) section, while multiple open() are > possible for the tuner section. If we want to keep applications > using the grabber simple, one possibility is to > - give access to ALL ioctl() from /dev/bktr ; > - give access to all non-capture related options from /dev/tuner > (i.e. brightness, contrast, etc). > This would enable the development of control-panel applications > (much like xmixer etc.) to set the brightness etc, while still > making applications which want to implement their controls able to > do it without having to carry around two file handles. > Yes, having the mixer (or control) capability would be a nice feature. There is always the problem of when to reset back to default values, but I suppose that could be solved by keeping an open count. The audio drivers seem to just leave whatever the last value of the mixer was. I am not certain this is the correct thing to do. It makes debugging problems difficult if you don't have a common starting point. As Amancio suggested, a common multimedia interface for these devices would be very useful. I will try and dig up that old frame work we discuss some time ago and maybe we can work that into something useful. Do you think that old frame work is a reasonable starting point? -Jim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803031830.MAA07082>