Firma Murena představila /e/OS verze 2.0. Jde o alternativní sestavení Androidu bez aplikací Google. Mezi novinkami je podrobnější nastavení ochrany soukromí před sledováním aplikacemi. Murena prodává několik smartphonů s předinstalovaným /e/OS (Fairphone, repasovaný Google Pixel 5).
Do 30. května lze v rámci akce Warhammer Skulls 2024 získat na Steamu zdarma hru Warhammer 40,000: Gladius - Relics of War.
HelenOS (Wikipedie), tj. svobodný operační systém českého původu založený na architektuře mikrojádra, byl vydán ve verzi 0.14.1. Přehled novinek v poznámkách k vydání. Vypíchnou lze nabídku Start. Videopředstavení na YouTube.
BreadboardOS je firmware pro Raspberry Pi Pico (RP2040) umožňující s tímto MCU komunikovat pomocí řádkového rozhraní (CLI). Využívá FreeRTOS a Microshell.
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 24.05. Přehled novinek i s náhledy a videi v oficiálním oznámení. Do balíku se dostalo 5 nových aplikací: Audex, Accessibility Inspector, Francis, Kalm a Skladnik.
Byla vydána (𝕏) nová verze 18.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
V neděli 26. května lze navštívit Maker Faire Rychnov nad Kněžnou, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Byla vydána nová stabilní verze 3.20.0, tj. první z nové řady 3.20, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Z novinek lze vypíchnou počáteční podporu 64bitové architektury RISC-V.
Společnost Jolla na akci s názvem Jolla Love Day 2 - The Jolla comeback představila telefon se Sailfish OS 5.0 Jolla Community Phone (ve spolupráci se společností Reeder) a počítač Jolla Mind2 Community Edition AI Computer.
Úvodní díl popisuje rozsah seriálu a obsahuje odkazy na dřívější články. Minule se mluvilo o tom, jak Video4Linux2 API popisuje video formáty: velikosti obrázků a reprezentace pixelů v nich.
Jak bylo řečeno již minule, existuje mnoho způsobů reprezentace obrázkových dat v paměti. Pravděpodobně se však neprodává žádné video zařízení, které by zvládalo všechny formáty, se kterými umí rozhraní Video4Linux pracovat. Od ovladačů se také neočekává, že by podporovaly formáty, které neumí hardware, pro který jsou určeny; provádět konverzi formátů v jádře je vyloženě nevhodné. Ovladač tedy musí aplikaci umožnit, aby si vybrala formát, který s hardwarem funguje.
Prvním krokem je umožnit aplikaci, aby se vyptala na podporované formáty. Pro ten účel je poskytováno ioctl() VIDIOC_ENUM_FMT; v ovladači se příkaz promění v následující zpětné volání (pokud se jedná o zařízení pro zachytávání videa):
int (*vidioc_enum_fmt_cap)(struct file *file, void *private_data, struct v4l2_fmtdesc *f);
Toto zpětné volání zachytávací zařízení požádá, aby popsalo jeden z formátů. Aplikace k tomu předá strukturu v4l2_fmtdesc:
struct v4l2_fmtdesc { __u32 index; enum v4l2_buf_type type; __u32 flags; __u8 description[32]; __u32 pixelformat; __u32 reserved[4]; };
Pole index a type nastaví aplikace. index je obyčejné celé číslo používané k identifikaci formátu; stejně jako ostatní indexy používané ve V4L2, i tento začíná nulou a zvyšuje se až na maximální počet podporovaných formátů. Aplikace tak může zvyšováním hodnoty indexu očíslovat všechny podporované formáty - dokud ovladač nevrátí EINVAL. Pole type popisuje typ datového toku [data stream]; pro zachytávací zařízení (kamera nebo tuner) to bude V4L2_BUF_TYPE_VIDEO_CAPTURE.
Pokud index odpovídá podporovanému formátu, měl by ovladač dovyplnit zbytek struktury. Pole pixelformat by měl být fourcc kód popisující způsob reprezentace videa a description krátký textový popis formátu. Jedinou definovanou hodnotou pro pole flags je V4L2_FMT_FLAG_COMPRESSED, což značí komprimovaný video formát.
Výše uvedené zpětné volání je pro zachytávací zařízení; bude voláno, pokud je type rovno V4L2_BUF_TYPE_VIDEO_CAPTURE. Volání VIDIOC_ENUM_FMT se rozdělí na různá zpětná volání podle pole type:
/* V4L2_BUF_TYPE_VIDEO_OUTPUT */ int (*vidioc_enum_fmt_video_output)(file, private_date, f); /* V4L2_BUF_TYPE_VIDEO_OVERLAY */ int (*vidioc_enum_fmt_overlay)(file, private_date, f); /* V4L2_BUF_TYPE_VBI_CAPTURE */ int (*vidioc_enum_fmt_vbi)(file, private_date, f); /* V4L2_BUF_TYPE_SLICED_VBI_CAPTURE */ */ int (*vidioc_enum_fmt_vbi_capture)(file, private_date, f); /* V4L2_BUF_TYPE_VBI_OUTPUT */ /* V4L2_BUF_TYPE_SLICED_VBI_OUTPUT */ int (*vidioc_enum_fmt_vbi_output)(file, private_date, f); /* V4L2_BUF_TYPE_VIDEO_PRIVATE */ int (*vidioc_enum_fmt_type_private)(file, private_date, f);
Typy parametrů jsou pro všechna volání stejné. Stojí za zmínku, že ovladače mohou pomocí kódů začínajících na V4L2_BUF_TYPE_PRIVATE podporovat speciální druhy bufferů, ale to by zjevně vyžadovalo pochopení i na straně aplikace. Pro účely tohoto článku se omezíme na zachytávací a výstupová video zařízení; další druhy budou probrány v příštích dílech.
Aplikace může zjistit aktuální nastavení zařízení pomocí volání VIDIOC_G_FMT. V tomto případě je předávaným parametrem struktura v4l2_format:
struct v4l2_format { enum v4l2_buf_type type; union { struct v4l2_pix_format pix; struct v4l2_window win; struct v4l2_vbi_format vbi; struct v4l2_sliced_vbi_format sliced; __u8 raw_data[200]; } fmt; };
type opět popisuje typ bufferu; vrstva V4L2 volání rozdělí na jedno z několika zpětných volání ovladače - v závislosti na typu. U zachytávacích zařízení vypadá zpětné volání takto:
int (*vidioc_g_fmt_cap)(struct file *file, void *private_data, struct v4l2_format *f);
V případě zachytávacích a výstupových video zařízení nás zajímá pole pix v union. Je to struktura v4l2_pix_format z minulého dílu; ovladač by měl strukturu dovyplnit informacemi o aktuálním nastavení hardwaru a pak vrátit. Volání by nemělo selhat, pokud nemá hardware nějaký vážný problém.
Další zpětná volání jsou:
int (*vidioc_s_fmt_overlay)(file, private_data, f); int (*vidioc_s_fmt_video_output)(file, private_data, f); int (*vidioc_s_fmt_vbi)(file, private_data, f); int (*vidioc_s_fmt_vbi_output)(file, private_data, f); int (*vidioc_s_fmt_vbi_capture)(file, private_data, f); int (*vidioc_s_fmt_type_private)(file, private_data, f);
vidioc_s_fmt_video_output() používá pole pix stejným způsobem jako zachytávací rozhraní.
Většina aplikací bude nakonec chtít hardware nakonfigurovat tak, aby poskytoval formát, který se hodí k jejich práci. Pro změnu video formátů existují dvě rozhraní. První je volání VIDIOC_TRY_FMT, které se v ovladači změní na jedno z těchto zpětných volání:
int (*vidioc_try_fmt_cap)(struct file *file, void *private_data, struct v4l2_format *f); int (*vidioc_try_fmt_video_output)(struct file *file, void *private_data, struct v4l2_format *f); /* A tak dále pro další typy bufferů */
Ovladač volání zpracuje tak, že se podívá na požadovaný video formát a rozhodne, jestli ho hardware umí nebo ne. Vyžaduje-li aplikace něco nemožného, měl by ovladač vrátit -EINVAL. Takže například fourcc kód popisující nepodporovaný formát nebo požadavek na prokládané video na zařízení, které pracuje jen s progresívním, by selhal. Na druhou stranu, ovladač může pole s velikostí upravit tak, aby odpovídala velikosti obrázku, kterou hardware podporuje; běžný postup je v případě potřeby velikost snížit. Ovladač zařízení, které zvládá pouze obrázky v rozlišení VGA, by podle toho změnil parametry width a height a vrátil úspěch. Struktura v4l2_format bude po dokončení volání zkopírována zpátky do uživatelského prostoru; ovladač by ji měl aktualizovat, aby obsahovala nové parametry a aplikace věděla, co vlastně dostane.
Obsluhy [handlers] VIDIOC_TRY_FMT jsou u ovladačů nepovinné, ale nedoporučuje se je vynechávat. Pokud jsou implementovány, může být tato funkce volána kdykoliv, dokonce i v případě, že je zařízení v právě provozu. Neměla by však měnit parametry; je to jen způsob, pomocí kterého může aplikace zjistit, jestli je to možné.
Když pak chce aplikace doopravdy změnit video formát, provede volání VIDIOC_S_FMT, které k ovladači dorazí v této podobě:
int (*vidioc_s_fmt_cap)(struct file *file, void *private_data, struct v4l2_format *f); int (*vidioc_s_fmt_video_output)(struct file *file, void *private_data, struct v4l2_format *f);
Na rozdíl od VIDIOC_TRY_FMT nemůže být toto volání prováděno kdykoliv. Je-li hardware zrovna v provozu, nebo pokud má alokované streamovací buffery (téma některého z dalších dílů), povede změna formátu k pořádným zmatkům. Představte si například, co by se stalo, kdyby byl nový formát větší než právě používané buffery. Takže ovladač by se měl vždy ujistit, že se s hardwarem nepracuje - a pokud ano, tak by měl požadavek selhat a vrátit -EBUSY.
Změna formátu by měla být atomická - měly by být změněny všechny požadované parametry nebo žádný. Opět: parametry velikosti obrazu mohou být v případě potřeby změněny. Tato zpětná volání vypadají většinou takto:
int my_s_fmt_cap(struct file *file, void *private, struct v4l2_format *f) { struct mydev *dev = (struct mydev *) private; int ret; if (hardware_busy(mydev)) return -EBUSY; ret = my_try_fmt_cap(file, private, f); if (ret != 0) return ret; return tweak_hardware(mydev, &f->fmt.pix); }
VIDIOC_TRY_FMT zabrání duplikování kódu a je odpovědí na všechny výmluvy, proč tu obsluhu neimplementovat. Pokud je úspěšná funkce "try", tak víme, že bude výsledný formát fungovat, a může být přímo naprogramován do hardwaru.
Video I/O ovlivňuje ještě celá řada dalších volání. Příští díly se na některá z nich podívají. Podpora nastavování formátů však stačí k tomu, aby mohly aplikace přenášet obrázky, což je hlavním účelem této struktury. Další díl se tedy bude věnovat podpoře pro čtení a zapisování dat.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
Vyžaduje-li aplikace něco nemožného, měl by ovladač vrátit -EINVAL. ... Na druhou stranu, ovladač může pole s velikostí upravit tak, aby odpovídala velikosti obrázku, kterou hardware podporuje...Ovladač by měl vracet -EINVAL pouze v případě, kdy nepodporuje požadovaný typ bufferu, nebo v případě S_FMT vrátit -EBUSY pokud zařízení zrovna pracuje a nemůže formát změnit. Ve všech ostatních případech by měl driver vrátit 0 a nastavit parametr VČETNĚ PIXEL FORMAT na některý z podporovaných formátů! Takže aplikace by si po tomto volání měla zkontrolovat vrácenou hodnotu a pokud vrácený pixelformat nepodporuje, zkusit požádat o jiný formát! Ve V4L2 API přímo stojí:
Very simple, inflexible devices may even ignore all input and always return the default parameters.Bohužel hodně aplikací vrácenou hodnotu nekotroluje a pokud volání vrátí nulu, předpokádají že dostanou data ve formátu, jaký požadovali. Například mplayer zavolá S_FMT třeba s pixelformat YV12, gspca driver na zařízení podporující pouze BA81 vrátí 0 a nastaví pixelformat na BA81. Mplayer vrácenou hodnotu nezkontroluje a když potom dostane data v jiném formátu "než si nastavil", tak velkým rachotem spadne...