Byla vydána nová stabilní verze 24.05 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Uakari. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
Byla vydána nová verze 1.48.0 sady nástrojů pro správu síťových připojení NetworkManager. Novinkám se v příspěvku na blogu NetworkManageru věnuje Fernando F. Mancera. Mimo jiné se v nastavení místo mac-address-blacklist nově používá mac-address-denylist.
Před 25 lety, 31. května 1999, započal vývoj grafického editoru Krita (Wikipedie). Tenkrát ještě pod názvem KImageShop a později pod názvem Krayon.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 24.05.0 editoru videa Kdenlive (Wikipedie). Ke stažení brzy také na Flathubu.
David Revoy, autor mj. komiksu Pepper&Carrot, se rozepsal o své aktuální grafické pracovní stanici: Debian 12 Bookworm, okenní systém X11, KDE Plasma 5.27, …
Wayland (Wikipedie) byl vydán ve verzi 1.23.0. Z novinek lze vypíchnout podporu OpenBSD.
Craig Loewen na blogu Microsoftu představil novinky ve Windows Subsystému pro Linux (WSL). Vypíchnout lze GUI aplikaci pro nastavování WSL nebo správu WSL z Dev Home.
V sobotu 1. června lze navštívit Maker Faire Ostrava, festival plný workshopů, interaktivních činností a především nadšených a zvídavých lidí.
Webový server Caddy (Wikipedie) s celou řadou zajímavých vlastností byl vydán ve verzi 2.8 (𝕏). Přehled novinek na GitHubu.
Byla vydána verze 3.0 (@, 𝕏) svobodného softwaru HAProxy (The Reliable, High Performance TCP/HTTP Load Balancer; Wikipedie) řešícího vysokou dostupnost, vyvažování zátěže a reverzní proxy. Detailní přehled novinek v příspěvku na blogu společnosti HAProxy Technologies.
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: