Vývojáři webového prohlížeče Ladybird dnes oznámili, že mění způsob vývoje. S blížícím se vydáním alfa verze přestávají přijímat veřejné pull requesty. Všechny otevřené veřejné pull requesty budou uzavřeny. Tým nedokáže garantovat bezpečnost AI generovaných pull requestů.
OpenLogi (GitHub) je open source náhrada aplikace Logi Options+ pro přizpůsobení myší od společnosti Logitech. Zatím běží pouze na macOS.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za květen (YouTube).
Úřad pro ochranu osobních údajů řeší desítky stížností na jednotné měsíční hlášení zaměstnavatele, které stát spustil počátkem dubna. Systém, jenž má firmám odlehčit od desítek formulářů, nejenže výrazně zatížil jejich účetní oddělení, ale docházelo v něm i k únikům osobních dat zaměstnanců k firmám, kde nepracovali. Podle ministerstva práce a sociálních věcí stála za problémem technická chyba. „Incident se týkal několika stovek
… více »Byla vydána (𝕏, Bluesky) nová verze 22.0.0 open source webového aplikačního frameworku Angular (Wikipedie). Přehled novinek v příspěvku na blogu.
Vim Classic byl vydán ve verzi 8.3. Drew DeVault oznámil tento fork editoru Vim (verze 8.2.0148, tj. těsně před zavedením Vim9 skriptování) v březnu letošního roku. Důvodem forku bylo, že vývojáři editorů Vim a Neovim začali při vývoji využívat LLM.
Open source konference DevConf.CZ 2026 proběhne 18. a 19. června v Brně na FIT VUT. Publikován byl program a spuštěna byla registrace.
Společnost JetBrains uvolnila verzi 2 svého open-source velkého jazykového modelu (LLM) pro vývojáře Mellum.
Probíhá konference Microsoft Build 2026. Microsoft představuje své novinky: kvantový čip Majorana 2, Surface Laptop Ultra a Surface RTX Spark Dev Box s NVIDIA RTX Spark, Intelligent Terminal, Coreutils for Windows (fork Rust Coreutils), AI modely MAI, AI agenta Scout, platformu pro agent-first zařízení Project Solara, …
Google Chrome 149 byl prohlášen za stabilní. Nejnovější stabilní verze 149.0.7827.53 přináší řadu novinek. Podrobný přehled v poznámkách k vydání. Vylepšeny byly také nástroje pro vývojáře.
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?