Nevíte-li si rady, zavolejte nám :-)
Veřejně dostupné databáze IDček:
Základní výrobci čipů podle Vendor ID (USB, PCI, HDAudio):
Výrobci touchscreenů:
Hlavní výrobci počítačů, které zastupujeme:
Ovladače jsou zpravidla dostupné z několika zdrojů:
Názory, v jakém pořadí vzít zavděk uvedenými zdroji, se liší.
Záleží koho se zeptáte, záleží na generaci a edici Windowsů
o které je řeč (retail/embedded apod.), záleží na situaci:
zbrusu novou instalaci na pilotním kusu zařízení budete
řešit jinak než opakovanou instalaci starých Windowsů
na starý hardware v dávno otestované konfiguraci.
Záleží, o jak obskurní hardware a jak starý OS se jedná
(pro některé kombinace HW+OS ovladače neexistují
a nikdy neexistovaly, nebo jsou velmi těžko k nalezení).
Může do toho vstupovat taky bezpečnostní hledisko
a v této souvislosti požadavek na aktualizace Windowsů
(pokud je stroj vystaven v divokém internetu,
což je reálně málokdy, zejm. pokud se nepoužívá
na brouzdání / maily / kancelářskou práci).
Sáhnout po lisovaném CDčku může být cesta nejmenšího odporu.
CDčko je přibaleno, netřeba složitě hledat na webu.
I tady už stojí za úvahu, zda spustit globální "uživatelské
rozhraní" (autorun.exe), nebo si sáhnout ručně z device manageru
pro konkrétní ovladač (INF+SYS+CAT, viz níže) do konkrétního
adresáře na CD.
Hlavně ale na CDčkách bývají verze staré a kulaté, nedostatečně
prověřené testováním na živých uživatelích. Obecné pravidlo
(ze kterého existují výjimky) zní, že lisované CD je staré
nejpozději ve chvíli, kdy vyjede z lisu.
Potažmo je třeba mít se na pozoru - pokud se vyskytnou problémy
(ovladač bezdůvodně nejde nainstalovat, nebo systém padá do modré
smrti), je třeba jako první věc zkusit nahradit "CDčkový" ovladač
něčím čerstvějším, zejm. pokud modrá smrt ukazuje právě na soubor
CDčkového ovladače.
Pravda je, že u obskurních výrobců někdy ovladač není dostupný
jinou cestou, než právě z přibaleného CDčka. Toto je častý problém
levných čínských USB cetek.
Pozor ať bezhlavě neinstalujete příbalové proprietární nekvalitní
ovladače pro zařízení, které má ve Vašem OS kvalitní class-based
ovladač. Historicky se toto týkalo například USB flashek
a Windowsů "95tkové řady" (95, 98) kde infrastruktura class-based
ovladačů nebyla v základní výbavě Windows tolik dotažená.
Dodnes se to týká Linuxu, kde spousta zařízení má kvalitní
vanilkový ovladač, jenom třeba nezafunguje Plug'n'Play,
protože nenatažený modul apod.
Do svého archivu sáhnete samozřejmě ve chvíli, kdy opakovaně
instalujete známou verzi Windows a máte pro ni na daném hardwaru
vyzkoušenou konkrétní verzi ovladače, kterou jste si zaarchivovali.
Pozor, staré ovladače se často rozbijí instalací novějšího service packu,
často i nějakým "menším" průběžným updatem Windows (pokud máte
zapnuty automatické aktualizace, nebo je po instalaci Windows
z CDčka jednorázově stáhnete). Některé verze ovladačů fungují
správně v jedné verzi Windows, a v sousední se ovladač chová
divně. Slušně vychované ovladače mají v release notes přímo
uvedeno, jaký minimální service pack popř. update (KB[číslo])
je nutným předpokladem pro fungování ovladače.
Historických příkladů je nepočítaně - namátkou wifiny,
advanteší ovladače pro sériové karty s UARTy Oxford
(jinak skvělý a jednoduchý hardware), broadcastová autodetekce
zařízení v utilitách Advantech, různé kategorie hardwaru
od firmy Intel...
V dnešní době naprostá většina hardwaru má ovladače specifické
pro použité čipy. Ovladače píše výrobce čipu/čipsetu, málokdy výrobce
motherboardu. (U periferních karet je situace složitější / různorodá.)
Proto obecně platí, že nejčerstvější a nejlépe udržované ovladače
bývají k dispozici u výrobce čipu/čipsetu. Platí to stoprocentně
o výrobcích systémového čipsetu na motherboardu (dnes často
integrovaný v pouzdře procesoru), o výrobcích síťovek,
grafik a zvukových čipů.
V našem "průmyslovém" portfoliu jsou zdaleka nejvíce zastoupeny
systémové čipsety od výrobce Intel (v mnohem menší míře VIA,
AMD a další). Pravda je, že systémové čipsety jsou dnes obslouženy
převážně class-based ovladači přibalenými v moderních generacích OS,
a trochu starší hardware má pod Windows i specifické ovladače.
V grafikách a síťovkách je situace podobná: Intel kraluje,
ostatní jsou v menšině.
Pokud se týče audio kodeků, tady je situace maličko složitější:
v čipsetech Intel je už pár generací zpátky integrován port/bridge
sběrnice "HD Audio". Ten má pod Windows class-based ovladač
z dílny Intel/Microsoft (kdysi dávno se musel doinstalovávat
dodatečně). Tzn. HDA port na PCI sběrnici má VID=8086.
Druhou polovinou je samotný HDA kodek, který může pocházet
od různých výrobců: Realtek, Analog Devices, snad i Intel.
Na HDA "sběrnici" je vidět přinejmenším jeho VID, takže výrobce
je opět dohledatelný.
Podobu HDA kodeku má i HDMI audio - tento kodek je k nalezení
buď na HDA sběrnici vedoucí ze systémového čipsetu (u integrovaných
grafik) nebo na druhém HDA portu (který se objeví po instalaci
ovladače přídavné grafiky).
Příbalové ovladače Windows pro specifický hardware (třeba taková
hloupost jako tiskárny) často fungují zcela bez problému,
ale někdy v nich můžete postrádat nějakou konfigurační volbu,
nebo odhalíte chybu... pak pomůže čerstvý download od výrobce.
Prakticky totéž platí pro ovladače z Windows Update - s tím rozdílem,
že když odkývete Windowsům, aby se podívaly po ovladači na serveru
Windows Update, můžete si jít uvařit kafe.
Je to maličko nepochopitelné, rodin hardwaru není na trhu zas tak moc.
Databáze oindexovaná podle hardware ID's musí být maličká a prohledatelná
během zlomku vteřiny, ovladače proteklé Microsoftem bývají štíhlé
(očištěné od bloatwaru) takže ani download by neměl být problém...
V souvislosti s ovladači dostupnými jako součást Windows narazíte
občas také na příjemné překvapení: ovladač pro nejčerstvější Windows
marně sháníte u výrobce čipu nebo počítače, a s překvapením zjistíte,
že je ovladač k dispozici buď od přírody ve Windows, nebo prostřednictvím
Windows Update. Bohužel se takové překvapení nekoná právě často - opačný
případ (= totální smůla) je bohužel mnohem častější.
Ovladače dávají k dispozici na svých webech také výrobci motherboardů
či periferních karet. Jsou u nich k nalezení například i ovladače pro
systémové čipsety, grafiky a síťovky, což je jinak velice generický hardware
- a je třeba říci, že zrovna v případě těchto generických periferií bývají
ovladače na webu výrobce motherboardu/počítače zásadně více či méně
zaostalé za webem výrobce čipsetu.
Problém ale nastává v případě čipů, pro které výrobce čipu ovladač
sám na svém webu nevystavuje. Obvykle má takový postup výrobce čipu
racionální důvod: čipy obsahují zakázkově konfigurovatelné funkce,
případně počítají s externím board-specific hardwarem, což znemožňuje
vydat generický ovladač. Výrobce čipu případně dává výrobcům desek
(počítačů) k dispozici "téměř hotový polotovar", do kterého
výrobce desky dopíše pár potřebných maličkostí, zakomentuje nepoužité
bloky, upraví PCI IDčka na svoje hodnoty, výsledek zkompiluje, podepíše
a vystaví na svém webu. Výsledkem je ovladač specifický pro výrobce
desky, potenciálně s generickými vnitřnostmi od výrobce čipu.
Toto je třeba případ sériových karet od Advantechu s čipy Oxford,
ale taky některých věcí v noteboocích (ovladače touchpadu,
klávesnice, údajně také wifiny).
No a pak je případ karet, kde generický čip tvoří pouze PCI
rozhraní karty, nebo je použit generický jednočipový mikroprocesor
(MCU), nebo CLDD/FPGA, jemuž "vdechne duši" teprve firmware,
napsaný komplet výrobcem karty.
Pak samozřejmě z principu nemá smysl pátrat po generickém ovladači.
Toto je případ většiny I/O karet firmy Advantech a dalších.
Totéž platí třeba o RAIDových řadičích.
Obávané žluté otazníky ve správci zařízení.
Obávané našimi zákazníky, ve kterých vyvolávají strach z neznámého.
Potažmo, unaveně obávané našimi techniky, kteří tohle musí řešit.
Nejlíp v kombinaci s kategorickým požadavkem na historickou verzi Windows,
který zase může plynout z dalších celkem pochopitelných omezení
(nejsou nové ovladače pro staré průmyslové periferie, aplikace
je vyvinuta pro starou verzi SCADA softwaru apod.)
Žlutý otazník v device manageru znamená, že Windows vidí na sběrnici
(PCI, USB apod.) zařízení, pro které nemají ovladač.
Co z toho plyne? V zásadě pouze tolik, že dotyčné zařízení, jeho
funkce, nejsou systému k dispozici.
Užírá takové zařízení nějaké systémové prostředky? Zvyšuje zátěž
procesoru? Užírá kapacitu sběrnice? Vyvolává neobsloužené interrupty?
Nikoli. Slušně vychovaná PCI nebo USB periferie by se takto chovat neměla.
Dokud ji ovladač neinicializuje, měla by sedět tiše ve svém koutku
jako pěna, nejlíp v nějakém úsporném režimu. V dávné historii
se vyskytly případy, kdy se některé periferie takto slušně
nechovaly (zejm. diskrétní čipy na PCI sběrnici) - ale v posledních
letech, zejm. při dnešní úrovni integrace periferií v systémovém
čipsetu, k takovým situacím nedochází. To spíš narazíte na případ,
že vinou výrobce motherboardu je v BIOSu něco špatně v tabulce DSDT,
podle které se routují interrupty - což Vám žádný žlutý otazník
či vykřičník zpravidla neoznámí a přijdete na to nejsnáz odhadem,
podle divné funkce postižené periferie, nebo podle vysoké zátěže
v interruptu apod.
Je jistě vada, pokud by se k zákazníkovi dostal počítač od nás
předinstalovaný, kde nefungují síťovky, zvukový výstup a např.
USB3 porty (opakuje se historická situace okolo USB2)
a žluté otazníky jasně ukazují na jádro pudla.
Snažíme se žluté otazníky svědomitě odstranit, je to věc
naší profesní cti a interní pravidlo - ale jsou případy,
kdy ovladač prostě není a prakticky to ničemu nevadí.
V moderních čipsetech roste počet "zbytných" periferií
a i dost virtuálních funkcí, které vlastně nikomu nescházejí,
ale způsobují (zejm. ve starších Windowsech) žluté otazníky,
a odpovídající "držhubné ovladače" jsou těžko k nalezení,
pokud pro danou starou verzi Windows vůbec existují.
"Ovladač" je v tomto případě často jenom INF, který řekne
systému "toho si nevšímej, a schovej proboha ten žlutý otazník".
Toto se týká například SMBus rozhraní, které v moderních
čipsetech Intel dostalo svou vlastní PCI identitu...
Dále můžeme jmenovat periferie, jejichž reálný přínos
je problematický či nulový, přestože ovladač možná jakési
API do hostitelského systému exportuje: jedná se zejména
o různá okénka do "Management Engine" subsystému
(Intel IPMI/AMT) - různé HECI, MEI, LMS_SOL apod.
Kdyby ta věc aspoň fungovala pro potřeby vzdálené správy
(což prakticky moc nefunguje). Přínos možnosti koukat do ní z
lokálního hostitelského systému je poměrně záhadný.
Kromě toho nové generace procesorů přinášejí stále nové a nové
úsporné fičury, třeba stále agresivnější uspávací stavy,
drobnější granularitu uspávání jednotlivých bloků apod.
Tyto věci správně mají spolupracovat s hostitelským operačním
systémem, pokud mají dosahovat maximálních energetických úspor.
Problém je, že tyto "klimbací frameworky", vznikající ve spolupráci
výrobců hardwaru a výrobců OS, vyžadují změny interních stavových
mechanismů OS, jdoucí napříč celým OS, vyžadují úpravy interních
API na několika vrstvách. Toto není věc, která by šla
snadno backportovat do starších verzí OS. Vyžadovalo
by to service pack, který by rozbil všecky staré ovladače
třetích stran.
Microsoft s Intelem k tomu přistupují tak, že nové šetřící stavy
a vlastnosti implementují v příští generaci Windows. Staré generace
Windows na novém hardwaru fungují v režimu jakési zpětné kompatibility
= starý OS sice nešetří až tolik, kolik by teoreticky mohl,
ale pořád funguje zcela normálně a využívá úsporné funkce/stavy
staršího data vzniku. Jediným vnějším projevem jsou právě
zatoulané žluté otazníky, pro které neexistuje náhubkový ovladač.
Pokud se podíváte na Hardware ID's, zjistíte například, že ta
neobsloužená zařízení visí na virtuální "ACPI sběrnici".
Tzn. nejedná se ani o hardwarový device na PCI nebo USB sběrnici.
Hardwarově se jedná o např. o nějaké flagy v MSR registrech
nových procesorových jader.
Škarohlídi a nepoučení komentátoři mohou vnímat PR prohlášení
ohledně tohoto problému jako projev monopolního přístupu firmy
Microsoft, která těží ze svého dominatního postavení na trhu
(vendor lock-in) a snaží se "prodávat nám pořád nové a nové
Windowsy" - ale ono to má v tomto případě velmi dobrý technický
smysl a další věc je, že na komerčního výrobce softwaru se nelze
spravedlivě zlobit, pokud se chce uživit, spíš než aby
navěky podporoval rozsáhlými updaty prehistorické retailové licence
na geologicky zastaralý operační systém.
Pro srovnání: Linux toto řeší postupnými průběžnými aktualizacemi
kernelu. Díky tomu měl Linux např. Message-Signaled Interrupty
dávno před tím, než Microsoft vydal XP SP4 alias Windows Vista
(měly nový model ovladačů, přešly od WDM na WDK, což údajně
znamenalo významné zjednodušení práce pro autory ovladačů).
Všimněte si ale, že v Linuxu, na rozdíl od Windows, kategoricky
nelze do dané verze kernelu zavést ovladač/modul zkompilovaný
pro odlišnou verzi kernelu. Ani o fous starší - prostě liší
se verze kernelu na třetím místě nebo "přídomek", a máte smůlu
s binární kompatibilitou ovladačů! Ovladače ve vanilce jsou
při drobných změnách interního kernel API upravovány průběžně
týmem vanilkových údržbářů, ale správci ovladačů "out of tree"
se musí o svá dítka postarat sami. Jedná se o daň za svobodu
open-source ovladačů, o druhou stranu mince.
Závěrem této kapitoly stojí za zmínku jeden související problém: ovladače grafiky. Pokud Windows nenajdou nativní akcelerovaný ovladač pro grafickou kartu, nainstalují ovladač univerzální, který renderuje vše softwarově do VideoRAM a pro inicializaci videorežimu používá VESA BIOS. Generický VESA ovladač je tedy pomalejší (hlavně pro náročnější úlohy), ale pro základní zprovoznění systému stačí. Zbývá jeden zádrhel: že systém používá pomalý generický VESA ovladač grafiky, není indikováno žlutým otazníkem :-)
I v průmyslové odnoži počítačového řemesla začíná konečně platit, že pominula doba sběrnice ISA bez PnP, kde bylo třeba ovladače shánět ručně, podle modelu karty nebo čipů, a doufat, že budou fungovat. Skanzenem před-PnP temna zůstávají snad jen ovladače touchscreenů, zejm. modelů s rozhraním RS232. Model řadiče není zjistitelný z OS (jinak než pokus/omyl) a i pokud sundáte víko, bývá v počítači ukrytý hluboko ve střevech, nebo má podobu nenápadného švába na motherboardu apod. Jakmile ale jednou zjistíte výrobce, máte většinou vyhráno.
Sběrnice jako PCI nebo USB (a další, třeba HD Audio, Bluetooth apod.)
mají přímo standardem dáno, že součástí povinné hlavičky každého
zařízení (uzlu na sběrnici) jsou hardwarové identifikátory.
Na sběrnici PCI se jedná o Vendor ID, Device ID, Subsystem Vendor ID, Subsystem Device ID.
Takže se do IDček dá zakódovat výrobce a model čipsetu, plus ještě varianta specifická
pro výrobce a model motherboardu nebo periferní desky, na které je čip osazen.
Na sběrnici USB se jedná o Vendor ID a Product ID (VID/PID).
Na sběrnici HD Audio je opět rozeznatelné Vendor ID kodeku (obvykle shodné
se světem PCI a USB), další hardwarová IDčka už nejsou tak snadno rozeznatelná
(není veřejná databáze), což ale prakticky nevadí, protože ovladače HD Audio
kodeků bývají v rámci výrobce univerzální.
Reálně tedy stačí zjistit ve "vlastnostech žlutého otazníku" Hardware ID's a už podle Vendor ID zpravidla vidíte, kde máte hledat ovladače.
V operačním systému Windows je "balík ovladače" tvořen několika základními soubory:
Pokud tedy stáhnete nějaký balík s ovladačem a jste zvědavi, zda podporuje Váš hardware,
nemusíte se hned snažit ovladač nainstalovat - stačí najít INF soubor a podívat se do
seznamu podporovaných IDček a verzí Windows (a porovnat s tím, co máte).
Můžete se také pokusit ovladač "přemluvit" úpravou INF souboru, aby vzal i lehce jinou
verzi Windows, nebo zjevně příbuznou variantu čipu. Někdy to zabere, někdy nikoli.
Vedle faktické kompatibility bináru s hardarem a OS je tu další problém,
částečně kosmetický: INF soubor je krytý podpisem (CAT), takže pokud změníte INF,
bude instalátor Windows nadávat, že ovladač nemá platný podpis.
Což v některých verzích Windows vůbec nevadí, a v jiných je to docela problém.
Jeden čas to vypadalo, že Microsoft úplně zakáže instalaci nepodepsaných ovladačů,
ale naštěstí se zdá, že to omezení dodnes není úplně striktní, přestože oficiální
FUD proti nepodepsaným ovladačům je pořád dost agresivní.
Tento problém řeší například vlastníci wifin značky Atheros, které pod Windows
mají podpis jenom do Windows 8 (včetně) a to ještě nikoli pro všechny varianty
subvendor/subdevice, které se reálně na trhu dají koupit.
Různé ovladače (a jejich INFy) mohou mít obecně různou míru "tolerance"
k různým verzím Windows a přesným modelům hardwaru. INF lze totiž navázat
na konkrétní třímístnou verzi NT kernelu (viz příkaz "ver" v příkazovém řádku),
nebo se na ni INF vůbec nemusí odkázat (pak se ovladač pokusí nastartovat
pod libovolnou verzí Windows od NT4 po 10). Podobně v seznamu podporovaného
hardwaru může INF specifikovat přesné kombinace VENDOR:DEVICE:SUBVENDR:SUBDEVICE,
nebo třeba jenom VENDOR:DEVICE, nebo může být ovladač omezený jenom na
určitou třídu zařízení (PCI device class / USB device class).
Class-based ovladače dávají smysl u hardwaru, kde je pro danou třídu
přesně definovaná sada HW registrů, jejich položek, významů a chování.
Pak je jedno, od kterého výrobce dané PCI resp. USB zařízení pochází
a univerzální ovladač by s ním měl každopádně fungovat
(alespoň teoreticky - reálně výrobci čipů testují svůj hardware proti
již existujícím class-based ovladačům pod Windows, a pod Linuxem
i class-based ovladače "přihlížejí" k Vendor/Device ID
a obcházejí různé "quirky").
Jako příklady class-based ovladačů uveďme USB UHCI/OHCI/EHCI/XHCI,
USB LPT (USB tiskárna), USB HID (klávesnice/myši/joysticky),
USB Mass Storage, ACM CDC (USB Modem), SATA AHCI.
U PCI IDE kompatibilita moc nefungovala, a třeba převodníky USB/RS232
ani žádnou třídu nemají (některé se tváří jako ACM CDC).
Z podobného soudku jsou generické ovladače tiskáren = generátory
tiskových formátů PostScript nebo PCL5/6, až na to, že ovladače
tisku jsou pod Windows čistě user-space záležitost a kompatibilita
se odehrává na úrovni datových formátů tiskových úloh, nikoli
na úrovni sady registrů na systémové sběrnici.
Historicky existovala jistá míra zaměnitelnosti u telefonních modemů
pro JTS na sériovém portu, některé INFy se daly použít poměrně
univerzálně, buď nastojato nebo s malými úpravami, i zde je ovladač
většinou čistě user-space záležitost. Bohužel dialer
vyvinutý pro JTS není příliš použitelný pro GSM/GPRS/EDGE/UMTS/LTE modemy
s AT/PPP rozhraním, protože neočekává některé nahnilé stavy,
kterými tyto moderní paketové sítě oplývají. Navíc emulace asynchronní
sériové linky a PPP je při dnešních kapacitách UMTS/LTE (jednotky Mbps)
už poměrně obstarožní - dnešní mobilní modemy proto na USB rozhraní
emulují spíš síťový adaptér, plus případně nějaká další rozhraní pro
out-of-band konfiguraci. Celé dohromady se to pak chová obvykle jako
USB composite device = jedna instance USB VID/PID s více endpointy,
proprietární hybridní ovladač vůči OS softwarově prezentuje
více virtuálních rozhraní různých tříd.