Přeskočit na obsah
Tech-Blog Chatujme.cz Chatujme.cz
Počítače

Kamera Dellu Latitude 7320 nešla na Linuxu pět let, senzor v ní je jiný čip, než hlásí

Přední kamera tabletu Dell Latitude 7320 Detachable z roku 2021 pod Linuxem nikdy nefungovala a dvě hlášení o ni marně žádala od roku 2022. Ukázalo se, že senzor hlášený v ACPI jako OVTI5678 je ve skutečnosti OV5675, jehož ovladač je v jádře od roku 2019. Sérii tří záplat poslal vývojář 9. srpna 2026, den nato ale požádal, aby se první z nich nepřijímala.

· aktualizováno 1. 9. 2026 · 205 zhlédnutí

Modul webkamery vymontovaný z notebooku, úzká deska plošných spojů s objektivem uprostřed
Modul webkamery z notebooku Acer TravelMate P253-M. Kamera v Latitude 7320 Detachable vypadá jinak: sedí na sběrnici MIPI za obrazovou jednotkou IPU6, a právě to je důvod, proč ji Linux nenajde. Foto: Raimond Spekking, Wikimedia Commons (CC BY-SA 4.0)

Dell Latitude 7320 Detachable je tablet s odnímatelnou klávesnicí, který se začal prodávat v roce 2021 s procesory Intel jedenácté generace Tiger Lake. Přední pětimegapixelová kamera v něm pod Linuxem nikdy nezabrala. Nejde o špatný obraz ani o trhání: systém tu kameru vůbec nezaregistruje.

V neděli 9. srpna 2026 poslal vývojář Sahan Nissanka do konference linux-media sérii tří záplat, které to mají změnit. Dohromady přidávají 105 řádků ve třech souborech. Zajímavější než ony je ale vysvětlení, proč se na ně čekalo pět let.

Dvě hlášení, která čekala od roku 2022

V repozitáři intel/ipu6-drivers na podporu toho senzoru čekají dvě otevřená hlášení. Číslo 24 je z 23. června 2022 a jmenuje se prostě „Add support for OV5678 sensor“. Číslo 402 založil v prosinci 2025 majitel Lenova IdeaPad Duet 5 12IRU8, tedy úplně jiného stroje se stejným čipem, a stálo v něm, že se čeká na specifikace senzoru OV5678 – na hodinové kmitočty a požadavky na napájení.

Ty specifikace nikdy nepřišly. V červenci 2026 do vlákna napsal vývojář, který se v něm dřív podepsal adresou u Intelu, že na úrovni registrů je OV5678 velmi podobný senzoru OV5675: stejný identifikátor čipu, stejná násobička kmitočtu, stejné registry pro čas expozice a překlopení obrazu. Doporučil proto vyjít z ovladače ov5675.c a přidat do jeho tabulky ACPI identifikátor OVTI5678.

V ACPI stojí OVTI5678, čip se hlásí jako OV5675

Nissanka to o měsíc později ověřil na hardwaru a výsledek zapsal do hlášení i do druhé záplaty série. Senzor po zapnutí hlásí v registru 0x300a identifikátor 0x005675 – přesně to číslo, které ovladač ov5675.c očekává. Ten ovladač je přitom v jádře od 7. srpna 2019.

Zbylé dva údaje, na kterých ovladači záleží, si Nissanka přečetl z tabulky ACPI ještě předtím, než se senzor vůbec poprvé rozsvítil: dvě datové linky CSI-2 a vnější hodiny 19,2 MHz. Obojí souhlasí a nativní rozlišení 2592 × 1944 odpovídá udávaným pěti megapixelům. Nový ovladač ani nové tabulky registrů tedy nejsou potřeba. Celá druhá záplata má jedenáct řádků a jen doplňuje identifikátor OVTI5678 do seznamu, který ovladač obsluhuje.

Bez dat o napájení se kamera ani neohlásí

Samotné jméno čipu by ale nestačilo. Obě kamery toho Dellu napájí obvod TPS68470, kterému se říká PMIC – řídí napěťové větve a signály pro senzor. Ovladač toho obvodu potřebuje pro každý model stroje vlastní tabulku, a když ji nemá, skončí hláškou, že pro tenhle model nenašel data.

Následek je nenápadný a přesně vysvětluje pět let ticha: senzory v ACPI deklarují závislost na téhle řídicí logice, takže dokud se neohlásí ona, nevytvoří systém pro kamery vůbec žádné zařízení na sběrnici i2c. Nemá je tedy co obsloužit, i kdyby ovladač existoval. Doplnění chybějící tabulky je první záplata série a je z nich největší, 92 řádků. Třetí pak přidá záznam do můstku ipu-bridge, aby se senzor objevil v grafu médií.

Nissanka uvádí, že se stroj s takto upraveným jádrem 7.0.0 a BIOSem 1.48.0 rozeběhl a že knihovna libcamera z kamery snímá 2584 × 1944 bodů rychlostí 29,95 snímku za vteřinu. Zadní kamera stroje na stejném obvodu zůstává mimo hru: k ní se zatím neví, které vývody ji resetují.

Barvy budou špatně a vyvážení bílé to nespraví

Autor sám v průvodním dopise píše výhradu, kterou by šlo snadno zamlčet. Ten senzor totiž není běžný bayerovský snímač. Nese barevný filtr v rastru 4 × 4, ve kterém je každý čtvrtý obrazový bod infračervený – takové uspořádání se zkratkou označuje RGB-IR a v noteboocích slouží hlavně k přihlašování obličejem. Ovladač ov5675.c ale ohlašuje formát SGRBG10, tedy obyčejnou bayerovskou masku.

Prakticky to znamená, že „modrý“ kanál je ve skutečnosti čistě infračervený a v „červeném“ se prokládá skutečná červená se skutečnou modrou. Takovou chybu vyvážení bílé neopraví. Nissanka to doložil třemi na sobě nezávislými cestami: konfigurací, kterou pro přesně tenhle modul dodává Intel do Windows a která u něj deklaruje typ senzoru RGB_IR, vlastním měřením na plném rozlišení a kalibračními daty modulu, jejichž mapa kanálů má rastr 4 × 4.

Opravit to v téhle sérii nejde, protože rozhraní V4L2 pro RGB-IR žádný kód obrazového formátu nemá – a stejnou nepřesnost už v jádře nese ovladač ox05b1s pro senzor téže třídy. Nissanka chce kódy pro RGB-IR navrhnout zvlášť a mezitím nabízí, že druhou záplatu klidně zdrží, kdyby správcům vadilo přidat podporu dřív, než půjde formát popsat poctivě.

Autor sám požádal, aby se první záplata nepřijímala

V pondělí 10. srpna, tedy den po odeslání, napsal Nissanka do vlákna vzkaz, který začíná větou, aby se první záplata nepoužívala. Přiřazení vývodů v ní je špatně.

Upozornil na to Charles Drolet, který má stejný stroj a zkoušel Nissankův repozitář mimo jádro. Zjistil, že se přední senzor ohlásí i tehdy, když mu žádný vývod přiřazený není: skutečná resetovací linka je totiž ve výchozím stavu uvolněná, takže kamera naběhne tak i tak – a chybné přiřazení se proto nijak neprojeví. Signál pro vypnutí senzoru navíc v ovladači vůbec neexistuje, ten si říká jedině o reset. A samotný reset sedí na pátém vývodu, ne na třetím; Drolet to ukázal tak, že linku podržel v nule, načež se senzor odmítl ohlásit s chybou vstupu a výstupu.

Poučný je Nissankův vlastní rozbor toho, jak k číslům 3 a 4 došel. Vzal je z tabulek pro starší modely Dellu a za potvrzení považoval to, že kamera funguje. To ale podle něj potvrzení není: dokazuje to, že senzor běží, ne že tabulka popisuje právě tuhle desku. Stroj, na kterém práce vznikla, byl navíc zapůjčený a už je vrácený, takže na opravenou verzi se čeká, až dorazí druhý kus. Druhá a třetí záplata zůstávají v platnosti – Drolet k oběma došel nezávisle stejně.

Vlákno mezitím pokračuje. Správce ovladačů médií Sakari Ailus se ptá, jestli se senzor nedá přepnout tak, aby posílal obyčejná bayerovská data, jak to většina nebayerovských snímačů umí. Nissanka odpovídá, že tvrdý důkaz nemá, ale všechno, co Intel k modulu dodává, ukazuje opačným směrem: v ovladači pro Windows je popsaný hardwarový blok obrazové jednotky se 314 registry, který převod RGB-IR na Bayer dělá až v čipu IPU6. Podíval se i do samotného ovladače od Intelu, který mu mezitím někdo poslal, a inicializační tabulky registrů v něm nejsou – načítá si konfiguraci zvenčí. Napsal to rovnou i s tím, že tím pádem odpověď zatím nezná.

Do jádra tedy zatím nic z toho nevede. Přesto se za dva dny posunulo něco, co stálo čtyři roky, a stálo to tři záplaty o 105 řádcích a jeden výpis z i2c.

Zdroje

Počítače

Linux Jádro Linuxu Ovladače Notebooky Dell

← zpět na výpis