Jaderné noviny - Video4Linux2 - 3: základní práce s ioctl()

29. 11. 2006 | Robert Krátký

Články - Jaderné noviny - Video4Linux2 - 3: základní práce s ioctl()  

Dotazování se na možnosti zařízení: Video ovladače tradičně obsahují ioctl() funkce přibližně stejně dlouhé jako romány Neala Stephensona; ačkoliv ty funkce obyčejně dospějí k uspokojivějším závěrům než zmíněné romány, mají tendenci být uprostřed dost rozvláčné.

Kdokoliv strávil nějakou dobu studiem specifikace Video4Linux2 API, si určitě všiml, že V4L2 velmi využívá rozhraní ioctl(). Video hardware se - snad nejvíce ze všech druhů periferií - vyznačuje velkým množství možných nastavení. Video streamy mívají velmi mnoho parametrů a často je značná část zpracování prováděna v hardwaru. Snahy o provozování video hardwaru jinak než v běžných, dobře podporovaných režimech mohou vést ke slabému výkonu a často také k žádnému výkonu. Takže není jiné možnosti, než koncové aplikaci zpřístupnit všechny funkce a manýry hardwaru.

Video ovladače tradičně obsahují ioctl() funkce přibližně stejně dlouhé jako romány Neala Stephensona; ačkoliv ty funkce obyčejně dospějí k uspokojivějším závěrům než zmíněné romány, mají tendenci být uprostřed dost rozvláčné. Takže V4L2 API bylo v jádře 2.6.18 změněno; nekonečná funkce ioctl() byla nahrazena velkou sadou zpětných volání, která implementují jednotlivé funkce ioctl(). V 2.6.19-rc3 jich je 79. Naštěstí je většina ovladačů nemusí všechny implementovat.

Ve skutečnosti byla ta dlouhá ioctl() funkce přesunuta do drivers/media/video/videodev.c. To je kód, který se stará o přenos dat mezi uživatelským prostorem a jádrem, a odesílá ovladači jednotlivá ioctl() volání. Aby ho mohl využívat, musí ovladač jako svou ioctl() metodu ve struktuře video_device používat video_ioctl2(). Nakonec by to však většina ovladačů měla mít možnost používat jako unlocked_ioctl(); zamykání v rámci vrstvy Video4Linux2 si s tím umí poradit a ovladače by měly mít řádné zamykání také ošetřeny.

První zpětné volání, které bude váš ovladač pravděpodobně implementovat, je:

    int (*vidioc_querycap)(struct file *file, void *priv, 
                           struct v4l2_capability *cap);

Tato funkce se stará o VIDIOC_QUERYCAP ioctl(), tj. pokládá jednoduchou otázku: "co jsi zač a co umíš?" Implementace je u V4L2 ovladačů povinná. V této funkci je, stejně jako u všech ostatních zpětných volání V4L2, parametr priv stejný jako obsah pole file->private_data; běžná praxe je nasměrovat ho na interní strukturu ovladače, která reprezentuje zařízení při open().

Ovladač by měl reagovat vyplněním struktury cap a vrácením běžné hodnoty: nula nebo záporný chybový kód. Při úspěšné návratové hodnotě se V4L2 vrstva postará o zkopírování reakce zpět do uživatelského prostředí.

Struktura v4l2_capability (definovaná v <linux/videodev2.h>) vypadá takto:

    struct v4l2_capability
    {
	__u8	driver[16];	/* např. "bttv" */
	__u8	card[32];	/* např. "Hauppauge WinTV" */
	__u8	bus_info[32];	/* "PCI:" + pci_name(pci_dev) */
	__u32   version;        /* měla by se použít KERNEL_VERSION() */
	__u32	capabilities;	/* schopnosti zařízení */
	__u32	reserved[4];
    };

Pole driverby mělo být vyplněno názvem ovladače zařízení, zatímco pole card by mělo obsahovat popis hardwaru skrývajícího se za daným zařízením. Ne všechny ovladače se obtěžují vyplňovat pole bus_info; ty, které se obtěžují, obyčejně provedou něco jako:

    sprintf(cap->bus_info, "PCI:%s", pci_name(&my_dev));

Pole version značí číslo verze ovladače a pole capabilities je bitmask popisující, co všechno ovladač umí:

• V4L2_CAP_VIDEO_CAPTURE: zařízení umí zachytávat video data.
• V4L2_CAP_VIDEO_OUTPUT: zařízení umí provádět video výstup.
• V4L2_CAP_VIDEO_OVERLAY: umí dát overlay na frame buffer.
• V4L2_CAP_VBI_CAPTURE: umí zachytávat nezpracovaná data z video blanking intervalu.
• V4L2_CAP_VBI_OUTPUT: umí VBI výstup.
• V4L2_CAP_SLICED_VBI_CAPTURE: umí zachytávat sliced VBI.
• V4L2_CAP_SLICED_VBI_OUTPUT: umí sliced VBI výstup.
• V4L2_CAP_RDS_CAPTURE: umí zachytávat Radio Data System (RDS) data.
• V4L2_CAP_TUNER: má počítačem ovladatelný tuner.
• V4L2_CAP_AUDIO: umí zachytávat audio data.
• V4L2_CAP_RADIO: jedná se o radiové zařízení.
• V4L2_CAP_READWRITE: podporuje systémová volání read() a/nebo write(); velmi málo zařízení podporuje obojí. Obyčejně nedává moc smysl zapisovat na kameru.
• V4L2_CAP_ASYNCIO: podporuje asynchronní I/O. V4L2 vrstva jako celek bohužel ještě asynchronní I/O nepodporuje, takže tato schopnost nemá žádný význam.
• V4L2_CAP_STREAMING: podporuje streamovaný I/O ovládaný přes ioctl().

Poslední pole (reserved) by mělo být ponecháno na pokoji. Specifikace V4L2 vyžaduje, aby bylo reserved nastaveno na nulu, ale protože video_ioctl2() nastavuje na nulu celou strukturu, je o to už hezky postaráno.

Typickou implementaci najdete v ovladači "vivi":

    static int vidioc_querycap (struct file *file, void  *priv,
					struct v4l2_capability *cap)
    {
	strcpy(cap->driver, "vivi");
	strcpy(cap->card, "vivi");
	cap->version = VIVI_VERSION;
	cap->capabilities =	V4L2_CAP_VIDEO_CAPTURE |
				V4L2_CAP_STREAMING     |
				V4L2_CAP_READWRITE;
	return 0;
    }

Vzhledem k přítomnosti tohoto volání by člověk očekával, že ho aplikace budou používat, a vyhnou se tomu, aby po konkrétních zařízeních žádaly provedení funkcí, kterých nejsou schopna. Z mých dosavadních zkušeností však vyplývá, že aplikace si volání VIDIOC_QUERYCAP příliš nevšímají.

Další volitelné - a ne příliš často implementované - zpětné volání je:

    int (*vidioc_log_status) (struct file *file, void *priv);

Tato funkce implementuje VIDIOC_LOG_STATUS a je myšlena jako debugovací pomůcka pro autory video aplikací. Při zavolání by měla vypsat informace o aktuálním stavu ovladače a příslušného hardwaru. Měly by to být dostatečně podrobné informace na to, aby pomohly zmatenému vývojáři aplikace zjistit, proč je video displej prázdný. Jonathan Corbet však doporučuje účinky mírnit voláním printk_ratelimit(), aby se při použití nezpomaloval systém a logy nezaplňovaly smetím.

V další části se podíváme na zbývajících 77 zpětných volání. Především se začneme zabývat dlouhým procesem stanovení sady provozních režimů hardwaru.

Seriál Video4Linux2 (dílů: 9)

První díl: Jaderné noviny - Video4Linux2 API: úvod, poslední díl: Jaderné noviny - Video4Linux2 - 7 (ovládání).
Předchozí díl: Jaderné noviny - Video4Linux2 - 2: registrace a open()
Následující díl: Jaderné noviny - Video4Linux2 - 4: vstupy a výstupy

Diskuse k tomuto článku

[pasmen]

Kolik ovladacu jsi napsal?

[Xerces]

Tak si to grepni ze zdrojáků zvědavče zvědavá Ikdyž nechápu jakou to bude mít pro tebe informační hodnotu?

[Michal Vyskočil]

Já nějak nerozumím tomu, koho se na to vlastně ptá ...

[pasmen]

Puvodne Roberta, pak mi doslo ze jde jen o preklad... Moje chyba :-I

[User682]

zdravim,

vzhledem k tomu, ze tento clanek cte a i pise zkupina lidi, kteri vidi do v4l2 a podobnych veci, tak toho trochu vyuziju k nejake odbornejsi diskusi.

Clanek jsem cetl. I kdyz specifikaci v4l2 drive. A cvicne jsem si zkonvertoval jeden driver pred 2 dny na radio z v4l na v4l2. Toto OK.

Nicmene, co jsem ze specifikace nepochopil je nasledujici vec na implementaci. A urcite predem dekuji chytre hlave, ktera to bude vedet a idealne mi to rekne v cestine.

TEA575x chipy maji feature "Fine-tuning" . To znamena, ze to automaticky vyladuje stanice za behu. Doslova to chyta nejsilnejsi signal a s tim se meni i frekvence, na ktere zrovna poslouchate.

Coz je sice super vlastnost, ale ne v dobe, kdyz radiokomunikacni urad ci jina stejne mene schopna instituce nahazi vedle sebe, co nejvice frekvenci stanic. A tak tuner ruzne obcas preladuje mezi stanicemi.

A ted chci:

- abych mohl v nastaveni parametru driveru, at jiz ioctl nebo parametr modulu rici, ze automaticke doladovani chci vypnout nebo dat jen na urcite urovni.

A jak na to podle specifikace ? Jako property (vlastnost) na to pouzit ?

A par dalsich veci:

Kdyby se nekdo zabyval/zajimal o kodeky DVExpress [MX,25] a dalsi a videl nekde specifikaci, tak mi to sem postnete. Vcelku dlouho to jiz hledam. Viz asi byvala firma C-Cube. Pripadne kdyby se nekdo podelil o zkusenosti s firmou Matrox, co se tyce vydavani dokumentace (i pod DNA), tak bych si to take rad precetl.

Jeste zajimavy tema na pokec: Mam grafiku a dovedu ji predhodit nejake efekty na video streamu pres OPENGL. Grafika to vykresli na vystupni zarizeni a samozrejme, ze je rychla. Ale jak to dostat zpatky a zda to jde? Podle me toto je tajemstvi pouzivani RT videoefektu.

Nejaky standart na audio/video efekety ? Zna nekdo ? Treba abych mohl zadat treba v xml nejake efekty, jak jdou za sebou a dalo se to i prenaset mezi masinama.

thx gf