Date: Sun, 02 Mar 1997 11:56:13 -0800 From: Amancio Hasty <hasty@rah.star-gate.com> To: Randall Hopper <rhh@ct.picker.com> Cc: multimedia@freebsd.org Subject: Re: Restarting CONTINUOUS/updating during CONTINUOUS Message-ID: <199703021956.LAA05752@rah.star-gate.com> In-Reply-To: Your message of "Sun, 02 Mar 1997 09:03:24 EST." <19970302090324.40461@ct.picker.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>From The Desk Of Randall Hopper : > Amancio Hasty: > |In order to change the geometry , you must first stop the capture process. > |In the case of the SVIDEO extensions , you must: > |1. first stop the capture process, > |2. issue the new SVIDEO parameters > |3. reissue a geometry call > > |> ioctl( video, METEORSVIDEO, &meteor_video ); > | > | *THIS WILL NOT WORK* > > |> ioctl( video, METEORSVIDEO, &meteor_video ); > |> ioctl( video, METEORSETGEO, &geo ); > | > |Now this is more like it 8) > > The driver does a nice job of modeling the device as a set of capture > parameters that you set up first, and then you initiate capture. > > To hide details associated with the ordering implicit in driver's > building of the RISC program, what about rebuilding the program from > scratch using the driver parameters each time a "parameter set" ioctl is > received. Yes, this is a good idea however what we need is a high level library to hide the low level idiosyncrasies required by the hardware and to a lesser extent compatibility with the matrox meteor driver. I will tighten the existing policies by returning the appropriate error codes . 1. setting the color format requires the capture process to be stopped and a corresponding geometry call. This should not be a surprised since the color format is part of the geometry paramaters and it does require the "risc program" to be rebuilt. 2. set frame rate requires the capture process to be stopped. No geometry call is necessary to be re-issue. I will try to document all this issues on my next release of the driver. Have fun, Amancio > On that thread, which attributes can be set while capture is in > progress (i.e. during 1 frame, N frames, or continuous acquisitions), and > which required that the capture be stopped before they can be set? > (contrast, brightness, input, format, etc.)? Browsing the driver, I see > any old CAP_MASK checks are commented out, except for those in the start > and stop capture flows (unless I missed something), but wanted to check > that what this implies is actually true in general. > > Thanks, > > Randall >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703021956.LAA05752>