Date: Tue, 29 Jun 1999 04:09:59 +0100 From: Roger Hardiman <roger@cs.strath.ac.uk> To: Frode Vatvedt Fjeld <frodef@acm.org> Cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: bt848 channel frequencies Message-ID: <37783907.94141BC7@cs.strath.ac.uk> References: <19990627074316.A1600@ipass.net> <199906272257.QAA07116@orthanc.ab.ca> <19990627194019.A1726@ipass.net> <2hzp1ksk05.fsf@dslab7.cs.uit.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Frode, > I think that abstractions over grabber cards are not so desirable, > because in this game you really can't afford abstractions to get in > your way performance-wise. This doesn't apply to the tuner part, > though. I agree with you. > I think a much more important first step here is to have a grabber > driver that is select()-able, module-cabable, and with a consistent > interface (for bktr begin with throwing away the meteor > "compatibility"). a) select()-able. Can you explain a bit mode. b) module-cabable. Do you mean KLDs (the new version of LKMs). Then the bt848 driver in -current was converted to a loadable module 2 weeks ago. Due to memory alloation problems once memory has become fragmented, you cannot load the bt848 driver as a KLD once X has started. But you can load it in the boot loader, or imedatly after booting. c) meteor interface. I have meteor cards too, and I quite like the common interface. I can see a few places where it holds us back like having different capture sizes for even and odd fields. But if we adopt a new API, it should be V4L2 based. Bye Roger -- Roger Hardiman Strathclyde Uni Telepresence Research Group, Glasgow, Scotland. http://telepresence.dmem.strath.ac.uk 0141 548 2897 roger@cs.strath.ac.uk 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?37783907.94141BC7>