Knihovna htmx (Wikipedie, GitHub), tj. knihovna umožňující vývoj dynamických webových aplikací a rozšiřující HTML o nové atributy, byla vydána ve verzi 2.0 (𝕏).
Společnosti DeepComputing a Framework Computer společně představily RISC-V základní desku pro modulární Framework Laptop 13.
Byla vydána nová verze 6.4 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.16.
Desktopové prostředí KDE Plasma bylo vydáno ve verzi 6.1 (Mastodon, 𝕏). Přehled novinek i s videi a se snímky obrazovky v oficiálním oznámení. Podrobný přehled v seznamu změn.
Qsynth dospěl do verze 1.0.0. Jedná se o Qt GUI nad softwarovým syntezátorem FluidSynth (Wikipedie).
V bezdrátových routerech od společnosti routerech D-Link, v řadách EAGLE PRO AI a AQUILA PRO AI, je zabudovaný backdoor. Jedná se o zranitelnosti CVE-2024-6044 a CVE-2024-6045. Kdokoli z lokální sítě může přístupem na konkrétní URL spustit službu Telnet a přihlásit se pomocí přihlašovacích údajů správce získaných analýzou firmwaru.
Organizace IuRe (Iuridicum Remedium) varuje před návrhem, který představilo belgické předsednictví Rady EU. Populární služby jako Messenger, WhatsApp nebo Signal by dle něj bylo možné plně používat až po odsouhlasení kontroly komunikace. Ta by měla zamezit šíření dětské pornografie. Podle IuRe by však taková kontrola přinesla hlavně závažný dopad na soukromí uživatelů.
NumPy (Wikipedie), tj. knihovna pro Python pro vědecké výpočty, byla po 18 letech vydána v nové major verzi 2.0.0. Přehled novinek v poznámkách k vydání. Důležité informace v průvodci migrací.
Vývojáři postmarketOS vydali verzi 24.06 tohoto před sedmi lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell, Phosh, KDE Plasma a Sxmo. Aktuálně podporovaných zařízení je 50.
Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE.
Pátý díl nepravidelného seriálu o psaní video ovladačů pro Linux. Pokud jste ještě nečetli první díl, možná by stálo zato začít tam.
Než může aplikace začít pracovat s video zařízením, musí se s ovladačem dohodnout na tom, jak budou video data formátována. Takové dohadování může být docela komplikovaná záležitost, protože 1) podpora formátů v různých typech video hardwaru se dost výrazně liší a 2) provádění převodu formátů v jádře není vítáno. Aplikace tedy musí zjistit, které formáty hardware podporuje, a nastavit prostředí tak, aby to všem zúčastněným vyhovovalo. Tento článek se bude zabývat základy popisu formátů; další díl probere API implementované V4L2 ovladači pro dohadování o formátech s aplikacemi.
Prostor barev [colorspace] je v podstatě koordinační systém pro popis barev. Specifikace V4L2 jich popisuje několik, ale doopravdy používány jsou jen dva:
Kromě toho pokrývá tento barevný prostor i YUV a YCbCr. Toto znázornění vychází z potřeby mít možnost zobrazovat barevný televizní signál na monochromatických televizích. Takže hodnota Y (neboli "svítivost" [luminance]) je hodnota jasu [brightness]; když je zobrazena samostatně, dostaneme obraz v odstínech šedi. Hodnoty "chrominance" [barevný rozdíl] U a V (neboli Cb a Cr) popisují modré a červené části barvy; zelenou lze odvodit odečtením těchto částí od svítivosti. Převod mezi YUV a RGB však není tak docela prostý; na výběr je z několika vzorců.
YUV a YCbCr nejsou přesně totéž, i když se ty termíny často používají ve stejném významu.
Existuje docela dost dalších prostorů barev; většinou jde o varianty standardů souvisejících s televizí. Kompletní seznam najdete ve specifikaci V4L2.
Jak jsme si řekli, hodnoty pixelů jsou vyjadřovány n-ticemi, které obyčejně obsahují RGB nebo YUV hodnoty. Pro organizaci těchto n-tic do obrazu existují dvě nejčastěji používané metody:
Packed formáty se možná používají trochu častěji, především ve spojení s RGB, ale oba druhy lze hardwarem generovat a aplikace je mohou vyžadovat. Pokud video zařízení podporuje jak packed, tak planar formáty, ovladač by je měl uživatelskému prostoru nabízet oba.
Barevné formáty jsou v V4L2 API popsány pomocí mechanismu "fourcc" kódů. Tyto kódy jsou 32bitové hodnoty generované ze čtyř ASCII znaků. Lze s nimi tedy lehce manipulovat a jsou snadno čitelné. Když například vidíte kód barevného formátu 'RGB4', není nutné vyhledávat význam v tabulkách.
Kódy fourcc jsou využívány v mnoha různých případech, z nichž některé jsou starší než Linux. MPlayer je používá interně. Fourcc však označuje pouze mechanismus a neříká nic o tom, jaké kódy jsou vlastně používány - MPlayer má překládací funkci pro převod mezi fourcc kódy a těmi, které používá V4L2.
V popisech formátů (níže) jsou bajty vždy řazeny podle paměti - na little-endian stroji jsou nejméně významné bajty první. Nejméně významný bit každého bajtu je vpravo; u každého pole barev je nejsvětlejší odstín nejvýznamnější.
Název | fourcc | Byte 0 | Byte 1 | Byte 2 | Byte 3 | ||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
V4L2_PIX_FORMAT_RGB332 | RGB1 | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_RGB444 | R444 | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_RGB555 | RGB0 | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_RGB565 | RGBP | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_RGB555X | RGBQ | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_RGB565X | RGBR | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_BGR24 | BGR3 | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_RGB24 | RGB3 | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_BGR32 | BGR4 | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_RGB32 | RGB4 | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_SBGGR8 | BA81 | ||||||||||||||||||||||||||||||||||||
Když jsou použity formáty s prázdným místem (v tabulce zobrazena jako šedá políčka), mohou to místo aplikace využít pro alfa hodnotu (průhlednost).
Jedná se o "Bayer" formát, který je obvykle dost blízko opravdovým datům ze senzorů většiny kamer. Zelené hodnoty jsou pro každý pixel, ale modré a červené jen pro každý druhý. V podstatě jde o to, že zelená nese důležitější informace o intenzitě, přičemž červená a modrá jsou - tam, kde chybějí - přes pixely interpolovány. Podobné to bude u YUV formátů.
Nejprve packed YUV formáty. Klíč pro čtení této tabulky:
= Y (intenzita) |
= U (Cb) |
= V (Cr) |
Název | fourcc | Byte 0 | Byte 1 | Byte 2 | Byte 3 | ||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
V4L2_PIX_FORMAT_GREY | GREY | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_YUYV | YUYV | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_UYVY | UYVY | ||||||||||||||||||||||||||||||||||||
V4L2_PIX_FORMAT_Y41P | Y41P | ||||||||||||||||||||||||||||||||||||
Používá se i několik planar YUV formátů. Nemá cenu je všechny vykreslovat - vystačíme si s jedním příkladem. Běžně používaný formát "YUV 4:2:2" (V4L2_PIX_FMT_YUV422, fourcc 422P) využívá tři samostatná pole. Obrázek 4x4 by byl znázorněn takto:
Y plane: | ||||||||||||||||||||||||||||||||||||
U plane: | ||||||||||||||||||||||||||||||||||||
V plane: | ||||||||||||||||||||||||||||||||||||
Stejně jako u formátu Bayer i YUV 4:2:2 má jednu hodnotu U a jednu hodnotu V na každou druhou hodnotu Y; zobrazení obrázku vyžaduje interpolaci chybějících hodnot. Ostatní planar YUV formáty jsou:
Existuje ještě pár dalších YUV formátů, ale ty se používají jen zřídka; vizte kompletní seznam.
Dva další formáty, které se mohou hodit pro některé ovladače:
Kromě toho jsou ještě další formáty, některé proprietární; seznam opět součástí specifikace.
Když už formátům barev rozumíme, můžeme se podívat na to, jak V4L2 API popisuje formáty obrazu obecně. Hlavní strukturou je struct v4l2_pix_format (definována v <linux/videodev2.h>), která obsahuje tato pole:
Dohromady tyto parametry poměrně uceleně popisují buffer video dat. Aplikace může vyplnit strukturu v4l2_pix_format a vyžadovat v podstatě jakýkoliv formát, jaký si vývojář dokáže vymyslet. Na straně ovladače však musí být omezení na formáty, se kterými hardware umí pracovat. Takže každá V4L2 aplikace s ovladačem vyjednává ve snaze najít formát obrazu, který by byl jak podporovaný hardwarem, tak vhodný pro potřeby aplikace. V dalším díle se podíváme na to, jak toto vyjednávání vypadá z pohledu ovladače.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: