Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - František Ryšánek

Stran: 1 ... 58 59 [60] 61 62 ... 90
886
Server / Re:Reverzný DNS záznam
« kdy: 05. 10. 2019, 15:10:05 »
Asi nejlepší tutorial k ISC BINDu si vybavuju ze staré knihy "Linux - Internet Server" od autorů Satrapy a Randuse.
Tam je tohle všechno vysvětleno polopatě ve velmi slušné míře podrobností, a oproti internetovým tutorialům přehledně vysázeno.

887
Nevyznám se v KDE, ale nedávno jsem se snažil trochu ladit jednu nebo dvě multi-display sestavy... bohužel mám pocit, že se x.org dost vyvíjí, včetně stylů konfigurace xorg.conf, takže některé tutorialy jsou zastaralé apod... Začněme ale od začátku.

Osobně bych začal explicitním zapnutím kýžených dvou (či více) výstupů natvrdo pomocí přesně mířených argumentů na kernel cmdline = je potřeba je přidat do konfigurace bootloaderu. Případně v Grubu je možnost je přidat přímo při bootu jednorázově = otestovat "nasucho". Následně např. v Debianu/Ubuntu lze přidat trvale do /etc/default/grub (a update-grub). Příklad z nějaké mojí konfigurace:

Kód: [Vybrat]
video=eDP-1:e video=eDP-1:1280x1024@60 video=HDMI-A-2:e video=HDMI-A-2:1920x1080@50

Přesná jména výstupů lze najít s trochou štěstí v dmesg. Pokud je driver [drm] při bootu nezmíní, možná bude třeba zvýšit debug level. Hledejte zmínky o cmdline argumentu drm.debug= . Aktuální popis jednotlivých bitwise voleb (pro čerstvé vanilkové jádro) je k nalezení zřejmě jedině ve zdrojákách kernelu. Tzn. je třeba se z DMESG domáknout, jak se jmenují jednotlivé výstupní porty.

Jakmile se Vám tohle podaří, jako další krok bych zkusil nechat xserver, ať se v tom zorientuje sám = z xorg.conf bych smazal veškerou konfiguraci grafických výstupů = ať zabere automatika xserveru.

Pokud automatika nezabere, tak se tomu dá pomoct v xorg.conf. Např. já mám na tomtéž stroji následující /etc/X11/xorg.conf.d/20-intel.conf :
Kód: [Vybrat]

Section "Monitor"
  Identifier    "eDP1"
  Option        "LeftOf" "HDMI2"
  Option        "DPMS" "false"
EndSection

Section "Monitor"
  Identifier    "HDMI2"
  Modeline      "1920x1080_50" 141.50  1920 2032 2232 2544  1080 1083 1088 1114 -hsync +vsync
  Modeline      "1920x1080_60" 173.00  1920 2048 2248 2576  1080 1083 1088 1120 -hsync +vsync
  Modeline      "1920x1080_24" 63.00  1920 1976 2160 2400  1080 1083 1088 1098 -hsync +vsync
  Option        "PreferredMode" "1920x1080_50"
  Option        "RightOf" "eDP1"
  Option        "DPMS" "false"
EndSection

Section "Screen"
  Identifier    "Screen0"
  Device        "Device0"
  Monitor       "HDMI2"
  DefaultDepth   24
  SubSection   "Display"
    Depth       24
    #Modes      "1920x1080_50" "1920x1080_60" "1920x1080_24"
  EndSubSection
EndSection

Section "Device"
  Identifier    "Device0"
  Driver        "intel"
  BusID         "0:2:0"
  Option        "Monitor-eDP-1" "eDP1"
  Option        "Monitor-HDMI-2" "HDMI2"
  Option        "TearFree" "true"
EndSection


Je tam pár věcí, které nepotřebujete...
Všimněte si, že jména zařízení v X.org jsou podobná jako v kernelovém DRM ovladači, ale kupodivu nikoli zcela stejná...

Bohužel nerozumím Xrandr = s tím neporadím.

888
Hardware / Re:SuperMicro X8SIE-F sem tam zapípá
« kdy: 27. 09. 2019, 22:56:39 »
@RDa: díky za ten dump... jednak jsem vyštrachal v archivu datasheet přesně pro Váš čip (ale on zrovna ten Beep asi funguje stejně u DGH i DHG-P) a druhak jsem bližším prolistováním zjistil, že ty konfigurační registry nežijou v tom hlavním SuperIO konfiguračním registru, ale v prostoru "health manageru" - který je dostupný přes dva IO porty (index/data) na bázové adrese 0xA10 . Než začnu vymejšlet, jak na to šáhnout holýma rukama (skriptem) tak mám jeden nápad na "low hanging fruit":

Nemám bohužel po ruce živý stroj s Linuxem a w83627, kam bych se na dálku dostal, ale našel jsem v jedné mašině jeho mladšího příbuzného NCT6776, a když pro něj loadnu HWMON ovladač, tak vidím v sysfs soubor /sys/class/hwmon/hwmon2/beep_enable . V mém případě má hodnotu "1".

...ale ne, to je pech... W83627DHG je podporován ovladačem w83627ehf.ko, který nemá opšnu beep_enable. Přitom jeho starší příbuzní w83781.ko a w83627hf.ko oba tuto opšnu obsahují :-(
Ach jo, je to tak doteď...

Zkuste prosím ještě mrknout na přiložený skript.
Je k tomu potřeba napřed nainstalovat tuto pomůcku.
V tom mém skriptu je opět jenom dump registrů. Všimněte si pár řádků, které patrně mají moc tu "beep funkci" vypnout - ale jsou uzavřené v bloku "if false", který se nikdy neprovede. Případně podle svého uvážení odšpuntujte.

889
Hardware / Re:SuperMicro X8SIE-F sem tam zapípá
« kdy: 27. 09. 2019, 11:55:04 »
Jestli je to v Linuxu, tak zkusit Superiotoolem dumpnout registry SuperIO švába. Třeba bych z toho hexdumpu něco vykoukal. Jestli je zapnutý ten "beep alarm" a případně jaké má nastavené prahy. Pokud kolem něj kroužím správně, tak je to myslím zcela autonomní funkce SuperIO švába, která se ani nemusí promítnout do nějakého logu v IPMI BMC nebo tak něco. Ten SuperIO šváb rozhodně nemá interní log událostí nebo něco v tom smyslu - leda snad by dokázal při aktivaci alarmu generovat interrupt (můj odhad). Jestli by něco dokázal "out of band" zahoukat směrem k BMC... no nevím. Spíš kdyby se BMC pořád dokolečka přes I2C koukal, tak by si možná stihl toho alarmu všimnout, kdyby měl kliku...

890
Hardware / Re:SuperMicro X8SIE-F sem tam zapípá
« kdy: 27. 09. 2019, 10:57:10 »
Kdysi na nějakém cizím boardu jsem záhadné pípání dohledal k SuperIO švábovi. V manuálu X8SIE-F na straně "1-10"(22 of 113) je v panákovi vidět SuperIO šváb W83627DHG - což je z téže rodiny. V datasheetu W83627DHG na str.74-75 PDF souboru (64-65 v tisku) je popsáno, jak ten šváb kvíká, pokud je nespokojen: střídá pískání 600 a 1200 Hz po půl sekundě (střída 50%). Tzn. Vašemu popisu to myslím neodpovídá... Tušímže to v mém případě bylo sdruženo s výstupem pro PC speaker pomocí nějakého diskrétního OR hradla, takže jsem slyšel kvíkat "hoří" rozkonfigurované SuperIO a do toho se míchal POST beep ze south bridge (šlo to oboje z jediného repráčku/bzučáku).

Pokud se to projevuje náhodně za jízdy, nebude se jednat o spokojený POST beep. Ten se totiž objeví pouze jednou krátce po startu. Taky to nebude nějaký nespokojený BEEP code BIOSu, protože ty bývají jednak při startu, druhak jsou delší, a počítač při nich není schopen nabootovat.

Pokud to leze z PC speakeru, muselo by to dělat něco v operačním systému.

Ta deska má patrně IPMI BMC, ale nikdy jsem neslyšel, že by pípal zrovna BMC - ať už skrz hlavní PC speaker, nebo skrz nějaký svůj vlastní bzučák.

Říkáte SuperMicro motherboard... má to šasi šuplíky? SASové s funkčními failure LEDkami? Tzn. nějaká varianta TQ nebo dokonce něco s expandérem? Pokud ano, vězte že backplane kastlíku se šuplíkama obsahuje svůj vlastní bzučák, kterému vládne "enclosure manager" (šváb na tom backplanu). Tenhle šváb může mít nějaké autonomní hlídání teploty a třeba otáček ventilátorů (pokud má diskový kastlík svoje vlastní). S enclosure managerem se může bavit RAIDový řadič - buď pokud se jedná o slušný HW RAID s vlastním autonomním firmwarem (Areca/Adaptec), nebo v dnešní době umí SGPIO komunikaci i SAS HBA integrované v serverových čipsetech Intel (na to je ale 3420 PCH zřejmě trochu starý). Pokud správně chápu, Vaše varianta boardu nemá ani onboard LSI2008 HBA - a i kdyby měla, patrně by neuměl SGPIO.

Mimochodem RAIDové řadiče mívají svůj vlastní bzučák (Areca určitě).
Pokud říkáte dva různé tóny, mohlo by se velmi teoreticky jednat o následující sekvenci:
1) kvíkne RAIDový řadič. Zahlásí nějakou přechodnou událost - třeba přehřátí? nebo odchylku v napájení? Nedejbože něco s některým diskem? Ale to by spíš nebylo přechodné? Prostě kvíkne a hned zase dobrý.
2) stihnul ale zasignalizovat skrz SGPIO enclosure manageru, že se něco děje, ať taky ztropí poplach. A enclosure manager je "zpožděnej", takže si kvíkne svým tónem o fous později...

Pak mě napadá, že i některé napájecí zdroje (zejm. redundantní) mívají v backplanu alarmový bzučák. Sice jsem ho neslyšel nikdy dvoutónový, ale čert ví...
Pak taky kvíkat může UPSka. Viděl jsem krátké zákmity v napájení, které UPSka zaregistruje, kvíkne, ale vlastně ani nepřepne na zálohu a jede se dál, počítače přímo připojené na síť si ani nevšimnou...
Opět mě napadá sekvence dvou zdrojů. Situace: počítač s redundantním zdrojem 1+1 je připojený jedním fousem do zdi a druhým do UPS. Nastane kratičký výpadek napájení, kterého si všimne jak UPSka (a svůj výstup podrží), tak napájecí zdroj, kterému na chvíli vypadne jedna větev. UPS a zdroj reagují s různým zpožděním a kvíkají různým tónem...

Máte-li chuť experimentovat, onboard bzučáky s malou dírkou lze přelepit = umlčet. Spekulativně.

891
Vývoj / Re:C++ no default constructor exists for class
« kdy: 27. 09. 2019, 00:15:42 »
Na stacku vs. na heapu:

A) Lokální proměnné uvnitř funkce (včetně argumentů deklarovaných v prototypu) se házejí na stack. V user space v moderním OS asi není problém, že by na stacku nebylo dost místa - ale je třeba si uvědomit, že věci na stacku mají omezenou životnost. Jakmile skončí dotyčná funkce, její lokální proměnné se vypaří (out of scope), tzn. stack pointer se vrátí o jeden stack frame výš (stack tradičně roste směrem dolů). Pokud jsou lokálně deklarované nějaké skutečné objekty, proběhne v rámci ukončení funkce jejich destruktor.

B) Instance vytvořené operátorem "new" jsou alokovány na heapu. Na takovou novou instanci dostanete pointer. Pokud takový pointer máte deklarovaný jako lokální proměnnou ve funkci (běžná situace) tak samotný pointer samozřejmě skončí s touto funkcí, ale odkazovaná instance na heapu žije dál. Pokud by Vás to téma zajímalo, tak C++ sice nemá garbage collector, ale alokaci různě velkých věcí na heapu řídí tzv. allocator. Přiděluje a uvolňuje místo, vede si přehled o jednotlivých alokacích, snaží se bránit fragmentaci (ve spolupráci s memory managementem OS = záleží i na podvozku).

C) Popravdě mi není z hlavy úplně jasné, kde jsou alokovány proměnné/objekty, deklarované jako globální v konkrétním Cčkovém souboru (translation unit). Patrně se stanou součástí spustitelného binárního souboru (nebo knihovny) a mají tím alokované místo. Tzn. představte si takový objekt jako "bublinu" uvnitř nějakého toho ELF nebo PE-COFF bináru - do RAMky se dostane zavedením toho bináru ke spuštění. Jisté je, že životnost těchto globálně deklarovaných objektů je shodná se životností běžícího executable bináru - pouze se při startu na to před-alokované místo poštve konstruktor a při ukončení destruktor.


Pak jste psal, že si hrajete se strong pointery... schválně zkusím přihodit střípek své naivní tvorby. "Manuálně invazivní" reference counting šablonu a k ní komplementární "chytrý pointer" (taky šablona). Vytvoříte pointer na nějakou svoji instanci obsahující tohoto refcounting parazita, a parazit ví, že na něj někdo odkazuje. Takových pointerů může být víc. Pokud ten smart pointer projde destrukcí, refcount v odkazované instanci se automaticky sníží. Pokud spadne refcount na nulu, proběhne autodestrukce hostitelské instance refcounting parazitem. Pokud byste chtěl nesmrtelnou instanci, buď si naalokujte navrch jeden smart pointer, který nikdy nezničíte, nebo tu referenci prostě explicitně inkrementujte... (Ano, hrozně rád vynalézám kolo.)


Jojo. První krůčky s C++.

Mně osobně se v začátcích hodně líbila klasická poučka, že abstraktní třída musí mít čistě virtuální destruktor, ale musí pro něj mít definované tělo :-) Nebo jak to vlastně bylo... V původní podobě jsem tu poučku našel tady. Nicméně už Bruce Eckel ve druhém vydání Thinking in C++ tvrdí, že tahle praxe je překonaná, že dle novějšího standardu má být ten destruktor prostě jenom virtuální (s definovaným tělem = tohle platí dál).

Pak se dá dostat do situací, kde bojujete se zacyklenými deklaracemi tříd. Dalo by se ještě pochopit, že pokud B je memberem A, nelze zároveň deklarovat že A je memberem B. Nekonečná rekurzivita vnoření se nekoná. Ale do podobných lapálií se můžete dostat při použití šablonových tříd. Situaci nepomáhá, že šablony prakticky komplet žijí v hlavičkových souborech, takže nelze použít fintu "v hlavičkách se to jenom nadeklaruje a pak v těle (souboru CPP) se dořeší zbytky". Tuším jsem se asi dvakrát dostal do kouta, ze kterého jsem nenašel jinou cestu, než obalit jednu ze tříd do memberu typu void* :-)

Prostě zažívám okamžiky C++ WAT :-)

Popravdě mi šly oči trochu křížem z tohoto řádku ve Vašem zdrojáku:
  typedef function<void(KeyboardShortcut)> KeyboardCallback;
...ale nakonec pokud správně chápu, nejedná se o nic jiného než v Céčkové tradiční notaci
  typedef void (*KeyboardCallback)(KeyboardShortcut);
...čili žádné velké funkcionální utrpení :-)
Já jsem totiž krajně procedurální tvor...

892
Vývoj / Re:C++ no default constructor exists for class
« kdy: 22. 09. 2019, 23:13:54 »
Prechádzam z viacerých jazykov (C#, F#, JS, TS, PHP) všetky majú triedy na jedno kopyto, a nikde som sa nestretol s tým aby som takýmto spôsobom musel inicializovať aj vnoreného membera, vždy sa to takto robilo iba pri predkoch. A rád by som počul vysvetlenie prečo je to nutné aj pri vnorených objektoch.

...je možné, že jsem nepochopil správně otázku, protože o zmíněných jazycích toho vím málo. Zjevně postupujete od jazyků vyšší úrovně dolů, směrem ke "kvalitnímu assembleru" :-)

Tedy "proč povinně inicializovat vnořené membery" : soudím, že se jedná o základní projev zásady RAII. Rodí se instance objektu, a v okamžiku zrodu je třeba ji uvést do nějakého smysluplného/konzistentního počátečního stavu. Tzn. dát nějaký smysluplný počáteční stav všem obsaženým memberům. Třeba je všecky jenom vynulovat - ale prostě jasně definovaný stav, na který se následně můžete spolehnout. Spolu se to alokuje, tak se to má spolu taky inicializovat.
Osobně jsem se několikrát dostal do situace, kdy nebylo možné implementovat nějaké další inicializační kroky v konstruktoru. To je v pořádku, další životní oblouk či stavový mechanismus právě vzniklé instance je už Vaše odpovědnost.
Buď se dá objekt na této nízké úrovni inicializovat v konstruktoru na hodnoty "já jsem zatím jenom prázdná skořápka". Nebo se třeba problematičtí "membeři", ke kterým zatím nemáte co říct, dají vyčlenit do samostatných objektů, na které se odkážete pointerem (nebo možná C++ referencí, nebo odkazy na ně zabalíte do nějakého kontejneru, který může mít do začátku nulový počet prvků apod.) - takové "externě odkázané membery" pak nemusíte inicializovat současně s "držitelskou instancí"... čímž ovšem za ně pochopitelně přebíráte odpovědnost.
Pokud jsem otázku nepochopil, tak se omlouvám :-)

Zmínil jste, že v jiných jazycích se povinně inicializují jenom "věci zděděné od předka", nikoli vlastní membeři. Což mi off topic připomnělo kapitolu od Bruce Eckela zvanou Inheritance and Composition (možná lépe najít v obsahu kap.č.14)

893
Vývoj / Re:C++ no default constructor exists for class
« kdy: 22. 09. 2019, 22:01:06 »
C) občas je k vidění varianta "maximálně úsporná" = jména symbolů jsou 2-4 znaky dlouhé zkratky :-) Viz třeba zdrojáky Perlu.
...
( C) je samozřejmě blbost s Perlem nesouvisející, je rozdíl mezi built-in/idiomatickými proměnnými a tím, jak se pojmenovávají "uživatelské" proměnné.)
[/quote]

O nic nejde - nejsem si jist jestli si správně rozumíme, pro jistotu upřesním: měl jsem na mysli Céčkové zdrojáky samotného Perl interpretru, viz např. datový typ SV znamená Scalar Value, třeba tady na řádku 321 atd. (deklarace 'SV* sv;' a návazná užití té proměnné). Celá perlová střeva jsou špikována takto pojmenovanými elementárními typy. Připomíná to písničku "Zkratky" od Ivana Mládka.

894
Vývoj / Re:C++ no default constructor exists for class
« kdy: 21. 09. 2019, 19:32:13 »
Na tomhle serveru se pravidelně projevuje několik odborníků na jazyky a konkrétně C++. Já sám jsem hobbík a nedouk, dělám spíš do včel. A možná právě proto jsem na té správné úrovni, abych tady trochu něco okomentoval, ze své nevysoké pozorovatelny.

Takže po tomto disclaimeru ještě k bodům 2 a 3:


2.) jasně, návratovou hodnotou Vaší metody je vector, předávaný hodnotou. Inu proč ne :-) C++ to umí.

Osobně když tohle vidím, mám přirozený sklon říct "fuj, tohle se mělo předat odkazem". Ale ono ve skutečnosti záleží na situaci. V mnoha případech si řekněte "a zrovna ne, vždyť bych to o kus dál stejně musel kopírovat, a to nějak složitěji ručně/oklikou". A i kdyby to bylo trochu neefektivní... tak co? Záleží, jestli ta neefektivita něčemu vadí. Jestli si pomůžete v rovině "uživatelského dojmu", když místo předávky hodnotou předáte jenom referenci. Nebo napak v dané situaci (nějaký objektový model) je z hlediska fungování aplikace správně, předat odkaz, tzn. nikoli provádět hloubkovou kopii nějaké hierarchie instancí.

V obecnější rovině: C++ jakožto následník C má v genech takovou obecnou snahu, zamezit klasickým céčkovým nešvarům jako je opomenutí dealokace již nepotřebného objektu, nebo dereference pointeru na již dealokovaný objekt (nebo null pointeru) nebo opomenutí alokovaný objekt inicializovat na počáteční smysluplný stav apod. A snahou správců jazyka C++ vždy bylo, nabídnout základní primitiva a "programovací přístupy", která/které budou podobným situacím principielně předcházet. To že se do kontejnerů typu "vector" vkládají nejradši hodnoty (spíš než pointery nebo reference), to je přesně projev těchto snah. Nevím jestli má zásada "předávat hodnotou, nikoli odkazem" sama nějaké jméno, každopádně sousedí se zásadou RAII (1, 2). Totiž pokud používáte objekty, které se RAII drží, a předáváte si je hodnotou, tak máte v C++ prakticky po starostech s "vlastnictvím", životním cyklem instance, automatickou alokací a dealokací.

Odkud to C++ vlastně studujete? Máte nějakou představu o Céčku, umíte používat jeho pointery, nabil jste si o ně párkrát nos? Nebo znáte klasickou práci s "dynamickými daty" a ukazateli v nějakém jiném jazyce téhle generace? (Packal?) Už jste narazil na C++ reference a jejich rozdíl oproti klasickým pointerům? (C++ Reference jsou další taková finta, jak sice nepředávat hodnotou, ale zároveň se za každou cenu vyhnout situaci, kdy reference bude naplatná.) A potkáte strong pointery... a já osobně (neživím se tím) teď jak trochu dohledávám další čtení okolo, narazil jsem na dvě povídání, ze kterých mi jdou oči trochu křížem... Prostě jsem spíš nenapravitelný céčkař.

Osobně jsem i jako hobbík už tu a tam napsal nějaký kus softwaru, kde trochu rozsáhlejší datový model znemožňoval, používat prosté předávání hodnotou. Zkrátka to nedávalo smysl. Objekty na heapu byly pěkně navzájem prolinkované odkazy (často nakonec prostými pointery, nebo strong pointery) a předávání hodnotou by bylo koncepčně blbě, protože by tím vznikla pokaždé další nová instance objektu, nová kopie.

Čili osobně si z toho beru tolik, že ty syntaktické nástroje, jak si "samotížně" zajistit RAII a vyhnout se mrtvým pointerům, jsou dobré na úplně spodní vrstvu, úplně nejdrobnější součástky, ze kterých stavíte svou katedrálu. Na trochu vyšších vrstvách skladebnosti už si musíte sám nést odpovědnost za "vlastnictví" objektů a jejich životní cyklus. C++ Vám k tomu bude maximálně nápomocno - takže se můžete soustředit na těch několik momentů, kdy objekt přechází např. ze stavu "základní prázdný zhruba inicializovaný" do "plně zabydlený" do "připojený a aktivní" apod., můžete se soustředit na správný moment, kdy (a v jakém pořadí) má instance objektu automaticky dealokovat vlastněné objekty (při graceful shutdownu), držené přes nějaký kontejner pointerů apod. Došel jsem zhruba k intruzivním šablonám pro autodestrukci na bázi reference countingu... (v kombinaci se strong pointers). A jsem si vědom, že to je pořád velice "lopatí" úroveň programovací černé magie.


3.) konvence tvorby jmen... osobně vím cca o dvou rozšířených variantách:
 
A) to co je vidět v Linuxu = všechna písmenka malá a mezi slovy podtržítka
B) "maďarská notace", dost rozšířená v Microsoftím světě
C) občas je k vidění varianta "maximálně úsporná" = jména symbolů jsou 2-4 znaky dlouhé zkratky :-) Viz třeba zdrojáky Perlu.

Ona je to zřejmě podmnožina širšího "coding style". Obecně když přispíváte do nějakého projektu, měl byste se držet stávajícího stylu - vč. věcí jako kde dávat otvírací závorku bloku, kolik pevných mezer odpovídá tabulátoru apod.
Pokud začínáte na zelené louce svůj vlastní kousek softwaru, možná zvažte, ze kterého tábora bude převažující "odborné publikum".

896
Aha, tak to jsem si popletl. Nešlo o kompilaci firmware, ale o kompilaci kernelu od no_bodyho  + tvoje úpravy do vanilky 5.0.8

To se odkazujete na historické verze, se kterými jsme my dva začínali.
Verze patche, co jde momentálně do Vanilky, je učesanější, bylo zohledněno několik námitek/hledisek maintainerů,
jak to přesně navlíknout, aby se změny pro T230C2 uplatnily skutečně jenom pro T230C2 - prostě to co sám no_body zmínil jako "todo".
Plus tam byl jeden-dva další drobné cleanupy dalších řešených quirků. Kromě toho quirku s resetem bufferů jsem snad zaslechl, že díky transplantaci patche do dvbsky.c namísto cxusb.c bude líp chodit podpora pro IR dálkáč.

Obecně to vypadá, že ovladač dvbsky.c je o kus dál v pečlivé strukturalizaci kódu (směrem k plug-n-play a code reuse pro různé příbuzné modely HW). On totiž ten USB dongle obsahuje hned několik čipů, které je zvenčí vidět. Konkrétně demodulátor s USB rozhraním, a skrz něj ještě skrz I2C ovladatelný tuner. (Už si nepamatuju, jestli třeba ještě nějaký třetí šváb v RF front-endu.) Různé konstrukce tunerů se liší kombinací těchto dvou-tří švábů, jejich zadrátováním a konfigurací, ale ti švábi se dost často opakují. Takže podle toho vypadá i struktura kódu ovladačů. Maintaineři se maximálně snaží, aby se neduplikoval zdrojový kód, a co se jednou napíše pro nějaký dongle a funguje to, tak aby se s tím svezl i další hardware, který už existuje nebo se v budoucnu objeví.

Zrovna u různých modelů/revizí Mygica se tuším řešilo, že někde je potřeba z tuneru do demodulátoru posílat payload s explicitními hodinami nebo bez, a jakou hodinovou frekvenci použít apod. Nebo že v jednom modelu je tuner vidět skrz I2C z demodulátoru na I2C řadiči A a na příbuzném na řadiči B... A že "T230C rev.2" vlastně nebyla formálně oznámena, ale vypadá to, že se prostě takový hardware objevil na trhu, a vyznačuje se určitým designovým bugem/odchylkou snad na plošáku, oproti klasické T230C, takže je potřeba (a lze to) ten bug obejít, ovšem vyžaduje to drobnou odchylku v chování ovladače, což výrobce po pár tisících prodaných kusů následně zohlednil změnou USB PID... prostě žůžo. Toto vše maintaineři zjišťují převážně pokus/omyl, reverzním inženýrstvím. A takovéhle modulární techtle se odehrávají v tom jednom pitomém donglíku, na plošáku velkém jak nehet...

Moc mě to teda není jasné jak to funguje. Když přijde na trh nový HW (nemusí to být jen DVB-T2), tak nestačí když výrobce dodá fw soubory, ale ten daný produkt musí být navíc i v kernelu?

Je dobrým zvykem, že na rozhraní USB (nebo třeba PCI) je konkrétní model hardwaru jednoznačně určen nějakými přidělenými identifikačními kódy: na USB Vendor ID a Product ID. Když postupně koupíte na různých místech v různém čase dvě hračičky, které mají stejné tyto kódy, měly by ty dvě hračičky fungovat se shodným softwarovým ovladačem na hostitelském počítači. K tomu jsou ty device-ID kódy dobré. (Nebudu radši mást výjimkami a příhodami z natáčení.)

Dnešní kus periferního HW, který z hostitelského stroje vidíte jako pár "USB endpointů" a IDček, obsahuje několik čipů (viz výše). Dost často tyhle čipy obsahují MCU jádra - nějaké prťavé ARMy, 80C51 apod. Aby ten USB dongle nemusel obsahovat ještě taky hejno EEPROMek/flashek, a taky kvůli pružnosti updatů, je nutné/vhodné, uploadnout do těch pidi MCU jader firmware při startu počítače/zařízení/ovladače. Tenhle firmware je k dispozici pouze v binární podobě, a často nikoli přímo od výrobce periferní hračky, ale ještě navíc ho autoři/maintaineři linuxových driverů museli v potu tváře vypárat z windowsího binárního ovladače... Zdrojáky k tomu firmwaru nejsou a navíc je to pro velmi různé CPU/MCU architektury, takže i kdyby zdrojáky byly, je nepravděpodobné, že by bylo zvladatelné, vláčet zdrojáky firmwaru jako součást vanilkového linuxového kernelu a cross-kompilovat je současně s vlastním kódem kernelu. Takže nakonec všichni přimhouřili oko (Linus i skladatelé distribucí) a mají většinu binárních firmwarů dostupných poměrně oficiálně v balíčkovacím systému. Firmwary žijí hezky na hromádce v /lib/firmware , víme o nich, nejde bez nich fungovat, takže se kromě skalních "free software" aktivistů nikdo moc nevzteká.

No a pak je strana toho hostitelského počítače. Kolem hardwaru je obalený kernel, ten je v dnešní době modulární, ovladače pro hardware mívají podobu kernelových modulů. A od kernelu máme zdrojáky, včetně zdrojáků ovladačů pro hardware. Zdrojáky ovladačů pro všelijaký hardware jsou součástí balíku zdrojáků vanilkového linuxového kernelu, který roste na www.kernel.org. Kernel je to co běží na Vašem procesoru (nějaké Core i3 apod.) - ovladače jsou modulární kusy tohoto kernelu.

Nad kernelem se vznáší jakýsi user space, počínaje libc, dál už to znáte.


Když se vrátím k Vašemu dotazu:
Pokud výrobce USB cetek uvede na trh novou cetku, má dvě možnosti:

A) nová cetka je natolik podobná předchozí generaci cetek, z hlediska ovládání skrz USB rozhraní (nebo PCI apod.), že může mít původní USB IDčka, a fungovat s původním ovladačem. Prostě zpětná kompatibilita hardwarového rozhraní vůči ovladači.

B) nová cetka je funkčně natolik odlišná, že by se starým ovladačem nefungovala. Proto dostane přiděleno nové USB ID a musí být vydána nová verze ovladače, která s touto novou revizí hardwaru bude fungovat.
Ovladač obsahuje tabulku USB IDček ve standardizovaném formátu, při natažení kernelového modulu si ji kernel standardním způsobem přečte, a pokud se následně na stromě USB sběrnice objeví takové zařízení (USB IDčka jsou shodná), kernel přes nějaké callbacky z této tabulky "ovladač nastartuje" pro danou instanci HW zařízení.

Verze firmwaru uvnitř v inteligentních cetkách se střídají jak ponožky - ale pokud se nemění HW rozhraní vůči hostitelskému ovladači, může zůstat původní hostitelský ovladač. Viz třeba RAIDové řadiče slušných značek.
V našem případě USB tuneru je ale ten firmware zřejmě dlouhá léta neměnný.

Pokud se nepletu, ty firmwarové bloby, které je potřeba kvůli DVB-T2 donglu odněkud stáhnout do /lib/firmware, ty se netýkají snad ani demodulátoru (USB slave bridge) ale konkrétně tuneru = té maličké "analogové" blechy, co je dostupná skrz I2C. (Ona vlastně asi analogová moc nebude, ale to je opět na delší povídání.) Čili pak tentýž blob může být potřeba pro různé DVB-T2 dongly, klidně s různými USB ID's?

Pozn.: s ohledem na toto názvosloví mi připadá poměrně dementní, označovat jako firmware to, čemu se dřív několik desítek let říkalo BIOS. Běží to na hostitelském CPU, tak to u mě není firmware - ať si marketingová oddělení Intelu, AMD, Applu a Microsoftu standardizují co chtějí :-) Košer firmware je kdyžtak ten malý blob, uložený v BIOSové flashce, který se při startu počítače pokradmu uploadne do AMT BMC parazita.

Kompatibilita HW rozhraní je dost pestré pole pro všelijakou tvorbu. Zařízení od různých výrobců s natolik shodným a standardizovaným rozhraním, přitom třeba relativně pružným, že na ně funguje generický ovladač. Vemte si SATA nebo IDE disky, nebo třeba vnitřní rozhraní "legacy IDE" nebo moderního AHCI na hostitelské sběrnici (PCI, PCI-e). Nebo třeba USB mass storage. Taky má univerzální class-based ovladač, přestože USB VID a PID se patrně model od modelu liší...

a DOST :-)

897
Moc bych se divil jestli tady po tvých popisovaných problémech ještě zůstal nějaký člověk co by uvažoval o koupi Evolveo Sigma T2" alias Mygica "T230C v2" (T230C2) :) Potřeboval jsem koupit něco na LibreElec, takže problémy, které popisuješ na Debianu bych asi neměl, ale stejně jsi mě už na předchozí stránce dokonale odradil, takže jsem raději koupil DVBSky T330. :)

Že to někoho odradí, to mě vůbec neuráží - možná naopak, varování je taky užitečná informace. Jsem spíš technická podpora než apoštol. Prostě jenom podrobně popisuju, kam jsem se zatoulal a co jsem tam potkal. Pravda je, že se to snažím prošťouchnout v obecném Linuxu na x86, nesahám po hotovkách typu LibreELEC = moje blbost. VDR je zřejmě dost "známka punku", většina lidí zřejmě potká dřív Kodi a MythTV. Ty jsem zjara taky zkoušel (v Debianu) a byl to na můj vkus dost bloatware, navíc zaměřený trochu jinam, než o co se snažím. Zatím je to v té rovině, že DVB-T2 je novinka na několika vrstvách, je potřeba sehnat co nejnovější verze relevantního softwaru, tzn. nezřídka kompilovat ze zdrojáků... (ušetřil jsem obecenstvo např. zábavných nuancí kompilace FFMPEGu, VAAPI a VDR ze zdrojáků - nemluvě o Kodi a MythTV).

Mimochodem většina těch mnou popsaných "problémů" souvisí spíš s VAAPI a obecně softwarem v oblasti přehrávání videa v Linuxu, než konkrétně s tunerem a jeho ovladači. Naopak bych řekl, že Tuner je ten malý dílek skládačky, který se už nějakou dobu dá uchodit poměrně v pohodě a má stabilní API pro user space. Potažmo jestli se jedná o T230C2 nebo T330, odhadem nebude hrát až takovou roli...

Zeptám se jako laik, který nikdy žádný fw nekompiloval. Proč nejde zkopírovat soubory *.fw pro T230C2 z LibreElecu https://github.com/LibreELEC/dvb-firmware/tree/master/firmware do Debianu? Výrobce DVBSky také radí jen zkopírovat fw z jeho stránek do adresáře Firmware a mělo by to šlapat, ale Debian nepoužívám, takže nevím.
Tady jsem se trochu ztratil :-) Proč se ptáte na firmware. Zrovna s firmwarem jsem neměl žádný problém, rozhodně nevím o tom, že bych ho kompiloval ze zdrojáků. Naopak, FW bloby se obvykle odněkud stáhnou nastojato. Zcela vyjímečně zahlédnu kus firmwaru někde ve formě zdrojáku.

Co je přibaleno v LibreElec nevím, pro T230C2 jsem použil dvouřádkový postup pro download firmwaru, který loni sepsal no_body (samotné OSMC repo s FW) a tady na rootu zveřejnil odkaz. (BTW od jeho patche se JP odpíchnul, resp. dohledal ještě zpátky nějaké předchozí zdroje informací).

898
Sítě / Re:OpenVPN unáší i provoz mimo VPN
« kdy: 20. 09. 2019, 10:36:47 »
Každopádně díky za publikaci řešení, může se hodit :-)

899
Omluva za exhumaci,
vypadá to, že "Evolveo Sigma T2" alias Mygica "T230C v2" (T230C2) bude mít konečně podporu ve vanilce 5.4 . A to v driveru dvbsky (nikoli cxusb).
Protlačil to jistý Jan Pieter van Woerkom - vyrobil patche a vytrvale inspiroval maintainery v linux-media at vger. Budu držet palce, aby se tam nerozbilo něco dalšího kolem - on ten hardware má své "špecifiká", tzn. doufám že některý dílčí patch nerozbije kompatibilitu s příbuznými modely. (Patch je součástí tohoto merge requestu. Související změny proběhly také v si2168.c/.h a cxusb.c)

Jinak koukám, že jsem tady posledně nenahlásil, že se mi podařilo rozchodit VDR s playbackem skrz vaapidevice - na kusu šrotu se Skylake CPU (Gemini Lake zatím nemám k dispozici). Optimálním skenerem kanálů pro VDR je jeho "wirbelscan" plugin, pokud dohledáte čerstvou verzi. Akorát jsem měl převážně rozsypané video z DVB-T programů (MPEG2 SD) - podle podrobností toho divného chování zřejmě nějaký problém s bufferingem / resetem bufferů při přepnutí kanálu. Odhadem spíš ve VAAPI kodeku pro MPEG2 nebo tam někde kolem, než v ovladačích okolo tuneru. Tuším jsem zahlédl nějaké patche (a revoky), které se kolem toho motaly... Taky jsem viděl střípek debaty o nějakém patchi právě okolo T230C2, kde šlo taky o nějaké resety bufferů naopak tuším v demodulátoru, kde výsledkem problému byly výpadky paketů (což by mohlo vysvětlovat divné chování ffplaye apod.) Obraz DVB-T2 (HEVC) se skrz VAAPI přehrával v pohodě. Stejně tak obraz DVB-T, kódovaný v H.264 SD. Přesněji: testovací full HD HEVC kanály na full HD displej jely jako víno, ale QHD materiál jakoby nepatrně "drhnul" - pohyb nebyl stoprocentně hladký. Nevím zda to přisuzovat nekvalitnímu streamu (zrovna běžela samá americká produkce, patrně konvertovaná z NTSC) nebo nedotaženému scalingu QHD matroše na full-HD výstup po HW dekódování HECV skrz VAAPI. Jako že HW dekodér HEVC je fajn, ale upscaler odfláknutý nebo softwarový nebo asynchronní nebo co. Taky jsem viděl v éteru jeden nebo dva full-HD programy z T2, kde se živý moderátor hejbal normálně, ale občas střihli třeba reklamu, která byla natočená zjevně ve full HD, ale nevhodnou snímkovou frekvencí, takže se po pár snímcích na zlomek sekundy "pauzovala"... uff! Jo a taky mám pocit, že když mi playback MPEG2 SD náhodou chodil (po prvním přepnutí z ne-MPEG2 programu na MPEG2) tak nefungoval řádně deinterlacing.
Prostě jsem viděl docela dost všelijakých podivností, a zatím mi není jasné, jestli "jsem to jenom moc pozoroval", a některé "vady ve vysílaném materiálu" bych zřejmě našel i v obrazu z běžného externího settop boxu, vs. co z toho mám přičítat jednoznačně své "testovací stolici" na bázi PC + Linux + VAAPI.

Jo a z nějakého důvodu mi nechodil audio výstup z VAAPI do HDMI audia (skrz softwarový ffplay bez problému).
Prostě si to doufám ještě trochu sedne. Někdy později na podzim mám v plánu to znovu otestovat = poaktualizovat všechny softwarové součástky.

Předběžně to vidím tak, že otestuju software na náhradním HW (do obýváku nepasuje), a ve chvíli, kdy to začne být trochu chodivé, a u nás střihem vypnou DVB-T a zapnou T2 na finálních frekvencích, tak stejně nebude k dispozici vhodný hardware pro "all in one HTPC", protože okamžitá dostupnost těch několika reálně vyráběných boardů od AsRocku s Gemini Lake ATOMem právě prošla nulou směrem k jihu :-( Možná jsem s nákupem zaváhal, možná ne... To ukáže až historie. Ohledně Intelových problémů s výrobní kapacitou to vidím tak, že za rok v létě by mohlo být jasněji - do té doby by mohly najet asi 3 nové nebo oprášené faby buď na 14 nm nebo spíš 10 nm, prostě by to mohlo celé trochu vybřednout...

900
Sítě / Re:OpenVPN unáší i provoz mimo VPN
« kdy: 20. 09. 2019, 09:04:44 »
To je divné... jak vypadá routovací tabulka na klientu, při zhasnuté OpenVPN a po startu OpenVPN?
Zkusil jste zvednout "log file verbosity" ? Tzn. opšna "verb 3" v konfiguráku. Třeba by klient řekl, kde se to vzalo a proč to dělá.

Pátráte myslím správným směrem.
Ještě bych zkusil na klientu pull-filter ignore redirect-gateway , jestli to nepomůže.

Stran: 1 ... 58 59 [60] 61 62 ... 90