Přijďte si zasprintovat na Djangu, jiném Python open-source projektu, nebo jen potkat ostatní vývojáře!
… více »Letos v říjnu se v Praze uskuteční hned několik konferencí. Odehraje se zde nově vzniklá konference LinuxDays. K ní se přidá čtvrtý ročník openSUSE Conference, dvanáctý ročník SUSE Labs conference a aby to nebylo málo, přidá se i první ročník Gentoo miniconf. A to vše ve stejné dny a na stejném místě.
… více »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í:
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.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Ikdyž nechápu jakou to bude mít pro tebe informační hodnotu?