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 ... 59 60 [61] 62 63 ... 84
901
Software / Re:UDP paket server
« kdy: 06. 05. 2019, 07:01:52 »
Gratuluji k vlastnoručnímu řešení a k pečlivé práci.
A děkuji za sondu do zákulisí, "jak se to dneska dělá".
Už si nebudu tolik lámat hlavu, proč některým rádiím tady "na severu" slyšitelně skáče buffer dopředu a zpátky, inteligentně o celé slabiky v mluveném slově nebo o čtvrt taktu v hudbě - to není výtka vůči Vašemu řešení, v rámci rozpočtu jste nejspíš udělal víc než bylo možné.
Přeji Vaší konektivitě nulové ztráty paketů. (Ztráty paketů a případné TCP retransmise nejsou jediný faktor, ono to může souviset taky s kvalitou hodin ve "studiu" a na vysílačích, což je další záležitost, která není levná.)

902
Ještě pár příloh...

903
A co hlasi femon ve VDR? Mozna je spatne nejaky parametr u kanalu ve VDR (modulace, coderate, ...).
Take bych zkusil pridat dvbv5-zap parametr -r a data z /dev/dvb/adapter0/dvr0 postval treba do ffplay.

Díky za postrčení :-) Jsem zas o kousek dál.

Jednak jsem s noťasem vylezl na kopeček, odkud je přímá viditelnost na Bukovou horu, vzdálenost do 10 km. Takže jsem měl s pasivní anténou rázem mnohem čistší signál, CNR vylezl přes 30 dB a BER trvale na nule. Ona i síla signálu -26 dBmW je zřejmě dost dobrá. Druhak jsem na kopečku spíš náhodou přišel na to, že když ffplay nechám chvíli pátrat, tak se nakonec chytí i na T2, a hraje bezvadně. Ale když jsem to pak zkusil zpátky doma, tak ze zásuvky v bytě stejně ani ťuk (nedostavil se sync demodulátoru) a na odposlechu z PA to jevilo určitou snahu, obraz se objevil, ale totálně se sypal, demodulátor ztrácel sync - při síle asi -33 dBmW a CNR asi 23dB.

Hehe přitom DVB-T z téhož vysílače jsem chytil na pasivní anténku v údolí za barákem, udávaná síla signálu asi -60 dBmW a CNR asi 23 dB, BER nebyl čistá nula, ale obraz dost dobrý, občas jsem s trochou soustředění zahlédl čtvereček.

=> odhadem u mě doma není v pohodě, že na sousedním kanále svítí něco o 20 dB silněji a celé to prolézá skrz kaskádu několika zesilovačů, z nichž ten poslední je vybuzený těsně pod hranici, při které začínají vynechávat i silné "téčkové" muxy = nějaká intermodulace tam určitě bude. Ale když to stáhnu, tak přijímače na vzdáleném downstream konci STA začnou vypadávat na příliš slabý signál stávajícího DVB-T. Takže ohledně "ostrého provozu" se musím smířit s tím, že T2 začne být chytatelné až ve chvíli, kdy zhasnou DVB-T a na jeho místě rozsvítí definitivní T2 muxy plnou silou (a z éteru zmizí část té přechodové bramboračky).

Mimochodem zajímavé je chování různých playerů, když je pověsím na /dev/dvb/adapter0/dvr0:

Distribuční Mplayer 1.3 se chytí na klasické DVB-T asi během 4s, hraje jako lusk bez cukání, mrznutí apod. - ale DVB-T2 ani náznakem nedává, prostě zůstane čučet jak trubka. Mplayer 1.3 je z 2016. Koukám před dvěma týdny vyšla verze 1.4, ke které je přibalený aktuální development master FFMPEGu...

ffplay 4.1.1. je údajně z r.2019.
Na DVB-T se chytí během asi 10 sekund, a po dalších asi 10 sekundách zamrzne. Vypnete, zapnete, 10 sekund počkáte, pak 10 sekund hraje, pak zamrzne. A tak dokola. Není zamrzlé GUI, jenom obraz, player reaguje na povel "q" (quit).
Na DVB-T2 nejdřív asi 30 sekund mlčky visí, pak vyplivne stránku hlášek že "Error parsing NAL" a "PPS id out of range" (od HEVC dekodéru), a za dalších 10 sekund se otevře okno s obrazem a zvukem. Tzn. od spuštění asi 40 sekund, než naběhne obraz a zvuk. Napoprvé zřejmě od naladění muxu vydrží běžet asi 10 sekund a zamrzne. Vypnete zapnete, a pak už běží bez záseků (vydržel jsem koukat asi 10 minut).

Přehrávat klasické DVB-T (MPEG2) v QHD formátu sežere asi 20-25% CPU (napříč oběma jádry). DVB-T2 H.265 HEVC v QHD sežere asi 60% CPU (napříč oběma jádry). Stařeček 65nm Core2Duo na 1.8 GHz to dává myslím velmi důstojně. Ty soft kodeky v FFMPEGu jsou zřejmě dost vymazlené.

Asi bych se měl porozhlédnout po nějakém železe s modernějším procesorem, který zvládne HEVC hardwarově akcelerovat. Protože výstupní pluginy pro VDR dost možná vyžadují VAAPI, jinak to končí černou obrazovkou nebo coredumpem. Takhle kdyby byl nějaký výstupní plugin, který by hrál skrz soft-kodek z FFMPEGu... 

Totiž já momentálně nemám k VDR použitelný obrazový výstup. V Xine mi nefunguje OSD, jenom ho občas zahlídnu při startu, ale nedokážu ho ovládat. Asi do něj Xine nesype úhozy z klávesnice (Xine si je interpretuje po svém) - do VDR backendu propadnou jenom čísílka pro volbu kanálů. Takže femon plugin ve VDR zatím nevyužiju. Zkusil jsem starý femon v příkazové řádce, ale to je zřejmě už hodně slabý odvar. To je jedno - on naštěstí důležitá čísla sype na stderr přímo dvbv5-zap, a mám už slušný obrázek. Ten plugin se může hodit do budoucna, pokud se mi podaří VDR rozhýbat.

Přiložím pár souborů (sesbíraných hlášek ze stdout/stderr).

904
Hehe upřesnění: objevil jsem balík dvb-tools, v rámci něho dvbv5-scan (bez něj sourozenci v balíku nedají ani ránu) a především "dvbv5-zap" - maličký a velice užitečný nástroj, kterému na příkazové řádce řeknete název programu, on naladí front-end na příslušný kanál a pak ve smyčce hásí sílu signálu, odstup CNR (užitečný obsah od šumu) a BERT po aplikaci FEC.

A zjistil jsem, že ten můj DVB-T2 mux na frekvenci 554 zřejmě není žádná sláva. Pokud mám mít jasno, zda "the TS is scrambled" je chyba softwarová nebo známka nekvalitního signálu, budu muset s počítačem někam blíž k vysílači, na přímou viditelnost.

Kód: [Vybrat]
## Zásuvka v bytě ve zdi:

root@plechovka:/home/frr/Downloads# dvbv5-zap -c ./dvb_channel.conf "NOVA | T2"
using demux 'dvb0.demux0'
reading channels from file './dvb_channel.conf'
service has pid type 05:  4011
tuning to 554000000 Hz
video pid 4001
  dvb_set_pesfilter 4001
dvb_dev_set_bufsize: buffer set to 6160384
audio pid 4002
  dvb_set_pesfilter 4002
       (0x00)
Lock   (0x1f) C/N= 23.25dB UCB= 208513 postBER= 380x10^-6
  Layer A: C/N= 46.55%
Carrier(0x03) Signal= -61.00dBm
Carrier(0x03) Signal= -61.00dBm
Carrier(0x03) Signal= -61.00dBm
Carrier(0x03) Signal= -61.00dBm
Carrier(0x03) Signal= -61.00dBm
       (0x00) Signal= -61.00dBm
       (0x00) Signal= -61.00dBm
       (0x00) Signal= -61.00dBm C/N= 20.50dB UCB= 224213 postBER= 500x10^-3
       (0x00) Signal= -61.00dBm
       (0x00) Signal= -61.00dBm C/N= 20.75dB UCB= 224213 postBER= 1.90x10^-3
       (0x00) Signal= -61.00dBm
       (0x00) Signal= -61.00dBm C/N= 23.25dB UCB= 224213 postBER= 1.00
       (0x00) Signal= -61.00dBm C/N= 23.25dB UCB= 224213 postBER= 1.90x10^-6
       (0x00) Signal= -61.00dBm
       (0x00) Signal= -61.00dBm
       (0x00) Signal= -61.00dBm C/N= 23.50dB UCB= 224213 postBER= 3.90x10^-6
       (0x00) Signal= -61.00dBm C/N= 23.50dB UCB= 224213 postBER= 0
       (0x00) Signal= -61.00dBm C/N= 23.00dB UCB= 224213 postBER= 990x10^-9
       (0x00) Signal= -61.00dBm C/N= 23.50dB UCB= 224213 postBER= 0
       (0x00) Signal= -61.00dBm C/N= 23.00dB UCB= 224213 postBER= 990x10^-9
       (0x00) Signal= -61.00dBm C/N= 23.50dB UCB= 224213 postBER= 990x10^-9
       (0x00) Signal= -61.00dBm C/N= 23.25dB UCB= 224213 postBER= 0
       (0x00) Signal= -61.00dBm C/N= 23.00dB UCB= 224213 postBER= 495x10^-9
       (0x00) Signal= -61.00dBm C/N= 23.00dB UCB= 224213 postBER= 1.90x10^-6
       (0x00) Signal= -61.00dBm C/N= 22.75dB UCB= 224213 postBER= 0
       (0x00) Signal= -61.00dBm C/N= 22.75dB UCB= 224213 postBER= 1.90x10^-6
       (0x00) Signal= -61.00dBm C/N= 23.00dB UCB= 224213 postBER= 1.90x10^-6
       (0x00) Signal= -61.00dBm C/N= 22.75dB UCB= 224213 postBER= 1.90x10^-6
       (0x00) Signal= -61.00dBm
  Layer A: Signal= 39.04%

^C       (0x00) Signal= -61.00dBm C/N= 22.75dB UCB= 224213 postBER= 1.00
  Layer A: Signal= 39.04% C/N= 45.55%


### Domovní zesilovač odposlech -30dB na koncovém stupni:

root@plechovka:/home/frr/Downloads# dvbv5-zap -c ./dvb_channel.conf "NOVA | T2"
using demux 'dvb0.demux0'
reading channels from file './dvb_channel.conf'
service has pid type 05:  4011
tuning to 554000000 Hz
video pid 4001
  dvb_set_pesfilter 4001
dvb_dev_set_bufsize: buffer set to 6160384
audio pid 4002
  dvb_set_pesfilter 4002
       (0x00)
Lock   (0x1f) C/N= 24.00dB UCB= 224213 postBER= 0
  Layer A: C/N= 48.05%
Carrier(0x03) Signal= -33.00dBm
  Layer A: Signal= 67.07%

^CLock   (0x1f) Signal= -33.00dBm C/N= 23.75dB UCB= 232903 postBER= 0
  Layer A: Signal= 67.07% C/N= 47.55%

... a stejně mi to obrázek neukáže, že prej scrambled.

905
Trochu mi vrtá hlavou, co přesně znamená hláška "skipped (transponder already known)". To jako že když chytí tentýž mux na jiném kanálu, tak se na něj vykašle? Tady bych si rád vybral kanál s nejvyšší sílou signálu... Takže prohlídnout pásmo pomocí rtl_sdr a nadiktovat konkrétní frekvence.
Je možné, že těch duplicitních kanálů vidí *tolik*? Vždyť to nahlásil asi dvacetkrát... tomu se mi nechce věřit.

Muxy se na sebe umi odkazovat. Pokud mu tedy mux na kanale 20 poradi, ze by mel zkusit take kanal 35, tak to w_scan udela a az pak dojde sam ke kanalu 35, tak uz ho znovu nezkousi.

Děkuji za potvrzení mého neblahého tušení, a postrčení správným směrem. Tahle heuristika zní určitě jako příliš zjednodušená / nesprávně aplikovaná.

Naštěstí w_scan má zřejmě své publikum, ten neblahý dojem už měl někdo přede mnou, a zdrojáky opravil.

w_scan2 mi vyrobil konečně správnou tabulku programů. Teď ještě zjistit, proč mi VDR u T2 programů hlásí "the TS is scrambled". Mux na 530 MHz (k28? PS13) je přitom docela silný a zcela jistě není šifrovaný.

906
Studium a uplatnění / Re:Povolání projektového manažera
« kdy: 04. 05. 2019, 08:20:49 »
Náplň práce projektového managera = mít hlavu na špalku za celý projekt = za práci ostatních lidí. Lidí na tu samotnou práci bývá nedostatek, nebo třeba nemáte pokryto všechno od A do Z, časově nebo co do know-how... takže si lámete hlavu, sháníte externě, improvizujete, buzerujete. Nesete odpovědnost za realizaci věcí, které byste sám v detailech ani realizovat neuměl. Ono to začíná už při uzavření smlouvy o dílo (nebo o jakou smlouvu se jedná) nebo ještě dřív, při tvorbě nabídky (pre-sales) = co zákazníkovi slíbíte. Možná jste slíbili o fous víc než konkurence, což je Vaše přidaná hodnota navíc, ale možná měla pravdu konkurence a z Vaší strany to bylo neuvážené :-) atd. Co je reálné dodat, s jakými náklady a v jakém časovém horizontu, a co je čirá halucinace, to v lepším případě zjistíte mnohaletou praxí, díky které získáte obrovský rozhled, pokud máte schopnost zkušenosti vstřebávat a stavět na nich. V horším případě se do projekťácké profese hrnou ambiciózní rychlokvašky...
Bude dost rozdílná situace v nadnárodní korporaci, kde je spousta ustálených procesů, vnitřních lidských a technických zdrojů a všelijaké dokumentace a know-how a snad i nějaké slesitelné časové horizonty (a občas taky absurdní představy kolegů v marketingu a obchodě, a vytížení technici / rozvojáři) vs. v malé firmě, která potřebuje urvat zakázku třeba i s "inovativními parametry" a pak ji nějakým způsobem dodat, aby byla zákazníkem zaplacena... Nebo se zakázka dohodla na vyšší managersko-politické úrovni někde u oběda a projekťáku zařiď to, ať to nevypadá úplně blbě...

907
Zdravíčko vespolek,

tak jsem se pokusil po svém popasovat s user space součástkami, a poměrně jsem pohořel. Asi na to nemám dost zkušeností.

Nakonec jsem celé to svoje snažení beletristicky pojednal v cizím jazyce a třesoucí se rukou poslal do mailing listu linux-media. Nevím jestli na tu moji dlouhou tapetu někdo zareaguje, je to takový neadresný výkřik do tmy, ale aspoň to teď visí ve webových archivech a třeba to někoho časem inspiruje k vývojové nebo testovací činnosti...

Nakonec se mi docela líbí VDR - ještě bych měl vyzkoušet ten jeho plugin vaapidevice, jestli by se nechytil na modernějším grafickém hardwaru (než i965GM), jestli v tom není celý problém s tím pluginem.

A taky se zkusím začíst do zdrojáků prográmku w_scan, třeba z nich pochopím, co ta věc vlastně dělá, na základě čeho některé frekvence přeskakuje, podle čeho si vybírá který mux dumpne na výstup a který ne, jak to ladící API vůbec vypadá, jestli by ten prográmek nešel v něčem vylepšit apod.

908
Distribuce / Re:Nevím co si mám počít s kernelem
« kdy: 02. 05. 2019, 17:30:43 »
@k3dAR: díky za vysvětlivku.
Jasně, snaží se přikompilovat 3rd-party modul do distribučního jádra - o tom žádná.

Teď jak jste to sesumíroval, tak mě teprve trknul ten rozdíl: 4.4 je OK, 3.10 padne kompilace. To je totiž už dost velký rozdíl verzí, přestože dneska Linus počítá "druhé číslo" už jenom do dvaceti. Řekněme 14 major verzí, jedna vyjde jak často, každé dva měsíce? To je tak dva a půl roku. Za tu dobu se v interním API můžou změnit drobnosti, na které externí modul odkazuje... sám na to pravidelně narážím, u těch ultra-primitivních miniatur co tu a tam napíšu. Přesto zrovna v tomhle případě ta chybová hláška nevypadá, že vůbec došlo na kompilaci nějakého .c ...

OT: Máte pravdu, DKMS neznám a nepoužívám. Automatizace buildování out-of-tree driverů pro nové kernely, zajímavé... 1) Dokáže to nějak automaticky opravovat kosmetické změny interního API v oblasti modulů?  Rozuměl bych, že je to užitečné pro styl práce, kdy dostáváte rekompilované distribuční jádro poměrně často, ale inkrementární změny mezi nimi jsou maličké... a máte hafo svých modulů mimo hlavní strom. 2) Řeší to nějak "the kernel is tainted" u modulů kompilovaných "out of tree"?

909
Distribuce / Re:Nevím co si mám počít s kernelem
« kdy: 02. 05. 2019, 14:07:28 »
Je to hodně dávno, co jsem se naposledy snažil něco přikompilovat k distribučnímu kernelu. Znamená to nainstalovat kernel-headers a nejspíš taky kernel-src pro příslušné jádro... a tehdy jsem narazil na to, že tuším verze modulů v běžícím kernelu (bzImage a /lib/modules) nesedí s balíčkem kernel-src... prostě bez rekompilace a reinstalace celého kernelu jsem se nepohnul. Pokud na tom záleží, tak rekompilovat zdrojáky z distribučního balíčku (SRPM) - a věřit, že jsou shodné s binárním kernelovým RPM, na kterém bazírujete.
Osobně na základě nějakých "svých" důvodů často volím spíš nějaký čerstvý vanilkový kernel s vysokým patch-levelem, kterému jenom nechám čuchnout originální konfigurace (případně ji ořežu podle svého).
Pak nainstalovat a reboot do tohoto kernelu.

A následně všemožné auto-build skripty prostě nemůžou ten kernel minout. Běží, má zabydlený /lib/modules, k nalezení podle symlinků z /lib/modules jsou kompletní zdrojáky včetně kompletního posledního buildu (existuje modversions.h, případně nějaké modernější kryptopodepisovací příslušenství, a všechny objektové soubory a linking-stage meziprodukty).

910
Hardware / Re:Přechod na jiné distro s lepší podporou DVB-S2
« kdy: 01. 05. 2019, 13:13:53 »
Pokud řešíte podporu ve smyslu security updates, tak si sám vyhodnoťte, jak moc Vám na bezpečnostním cirkusu záleží - Vaše věc co všecko na tom noťasu děláte. Osobně vidím jako závažnější zásadu "jestli to funguje, tak to neopravuj".

Jiná věc je, pokud Vám spíš než o bezpečnost jde o užitečné vlastnosti nových verzí softwaru - a nové verze 3rd-party softwaru na starším distru jsou čím dál obtížněji zkompilovatelné. Pokrok je svinstvo :-)

Ohledně media/v4l mám zrovna já ten problém, že CrazyCatovy ovladače se možná v detailech už odchýlily od vanilkového "media ABI", takže je potřeba v lepším případě aspoň rekompilovat aplikace ze zrojáků... (= v lepším případě nechybí podpora DVB-T2 přímo v aplikaci). Zdá se, že DVB-S2 je na tom možná líp.

911
Hardware / Re:Přechod na jiné distro s lepší podporou DVB-S2
« kdy: 30. 04. 2019, 15:42:14 »
Zrovna si hraju s DVB-T2 a hardwarem T230C2... ovladače od CrazyCata fungujou do té míry, že w_scan najde programy i v Debianu, ale user space je oříšek, přičemž část těch problémů je jistě mezi židlí a klávesnicí, protože dokumentace je... útržkovitá a prostě ten ekosystém nemám ještě úplně v krvi.

Debian 9.8 jsem zrovna včera poslal k šípku, jakožto stabilní leč opožděné distro (moje oblíbené). Protože jsem kompiloval jako vzteklej nejnovější verze spousty věcí ze zdrojáků a stejně to nechtělo dohromady fungovat.

I rozhodl jsem se, skočit po hlavě směrem k bleeding edge, kde mezi silnými majoritními distry vidím hodně vepředu Ubuntu = otestováno na relativně velkém počtu živých zvířátek. Takže 19.04. A zdá se, že mám první pozitivní výsledek: distribuční vdr 2.4.0 se chytlo (hint: jako závislost instalovaný lirc chce neprázdný konfigurák, do té doby nedoběhne post-install script) a distribuční Xine jsem skrz plugin dokázal propojit do té míry, že vidím v Xine z vdr jak pohyblivé obrázky, tak OSD. Je tam ještě dost otřepů, které je potřeba srazit... ale touto cestou asi nakonec nepůjdu, je to zbytečně šroubované, spíš si zkusím zkompilovat nějaký plugin pro "přímý výstup" z VDR na obrazovku (a doufám že v disco.dingovi nebudu muset kompilovat ze zdrojáků všechny tlusté závislosti, jako vaapi a ffmpeg - proto jsem Disco zvolil).

Hraju si s tím zatím na starém noťasu (i965, C2D) který Windowsům už nestačí, protože DDR2 je drahá - ale na promiskuitní linuxový distro-turismus je to příjemný hardware. Slabá/zastaralá HW akcelerace videa není ani moc na závadu, na základní test úplně stačí frame rate stylem "slide show". (Hint: i965 potřebuje video=SVIDEO-1:d, jinak drhne page-flipping téměř do bezvědomí.)  Konečný výsledek asi popíšu vedle v tom dlouhém vlákně o DVB-T2. Tady jsem tímto jenom krátce ucintnul svůj názor ohledně distribucí.

912
Vývoj / Re:Jak je to s kompilací
« kdy: 25. 04. 2019, 09:13:05 »
Pro Váš binární program je OS vlastně externí "knihovna funkcí", v obecném slova smyslu. Pro Váš binární program je to pomůcka, abyste si nemusel všechno řešit sám - jak už psali ostatní výše. Nic Vám nebrání se toho pohodlí vzdát, tzn. zkompilovat si program do podoby, kterou lze flashnout místo BIOSu do SPI Flash ROM, nebo do podoby přímo startovatelné jako diskový bootloader - ale z hlediska užitečnosti si moc nepomůžete :-)

Různé dnešní rodiny OS pokrývají částečně tytéž funkce, ale mají je různě pojmenované a liší se zcela určitě únavné podrobnosti = "prototypy funkcí" (počet/pořadí/typy argumentů), formáty předávaných datových struktur, očekávané chování (interní logika) = "programátorské rozhraní" včetně "kontraktu". Dokonce různé verze téhož OS se budou v detailech lišit a zpětná kompatibilita má své meze, takže v zásadě kompilujete dokonce proti konkrétní verzi OS.

A dál to má spoustu nuancí a návazností... stabilita user-space API/ABI a kernel API/ABI napříč verzemi, jazyky kompilované do generického bajtkódu pro "svůj vlastní" softwarový VM (a tedy na OS do jisté míry nezávislé), omezující pravidla pro malé aktualizace low-level C-čkových knihoven tak, aby rozhraní zůstalo kompatibilní s programy zkompilovanými proti starší verzi, pak vedle kernelu a jeho syscallů tu máme standardní user-space knihovnu a individuálně instalované další knihovny pro specifické účely (a jejich verzování) apod. Dependency hell a jeho krocení. Release engineering a jeho best practices...

Jako další čtení bych doporučil třeba něco o volacích konvencích funkcí v C/C++: 1, 2

913
Desktop / Re:Dotyková obrazovka má invertovaný dotek
« kdy: 20. 04. 2019, 21:57:03 »
Btw, toto jsi viděl?
https://forums.fedoraforum.org/showthread.php?320779-Touchscreen-(Input)-trouble-on-Trekstor-Surftab-Twin-11-6&p=1820237#post1820237

Za tento odkaz děkuji. Hezkypěkně - kalibrace skrz udev = ještě o něco hlouběji pod kapotou.
Wayland sice neprovozuji, ale ono se to nejspíš hodí i na další věci, prakticky cokoli co neběží pod X.
Trochu mě mate, že ta transformační matice má jenom 6 členů. Matice v Xinputu má 9 členů. Až se jednou budu opravdu nudit, měl bych si o tom něco přečíst...

914
Tak jsem se rozhoupal a pořídil Evolveo Sigma T2. Spíš na hraní a na cesty, na seznámení s DVB-T2... a pokud by se časem podařilo nějaké trochu komfortní HTPC, bylo by to fajn.

Začal jsem tím, že jsem vzal patch od no_bodyho a vmasíroval ho do vanilky 5.0.8, kterou jsem předem usadil na svůj systém = vzít distribuční .config, protáhnout ho menuconfigem aby se "přisál na aktuální verzi kernelu",
vyhodit "expert options" a vyhodit "kernel debugging", případně vyhodit
"kernel versioning" (verzování může být trochu klacek pod nohy, pokud mastíte drivery out of tree apod.) A zakončit make modules_install && make install .

Čili ten patch od nobodyho: jasně, přidat USB IDčka. Hlavičkový soubor s USB IDčky se nám přestěhoval do include/linux, jinak žádný skandál, je třeba přidat řádek nebo dva pro T230C a T230C2. Zíív. Nepatrně zajímavější to je v cxusb.c : oproti no_bodyho patchi je třeba přidat ještě záznam(y) do "indexového enumu" (nebo co to je) a pak se dají přidat dva další bloky (po jednom pro T230C a T230C2) do
cxusb_mygica_t230_properties.devices
(a nezapomenout zvednout .num_device_descs z 1 na 3 - já to dal až napodruhé).

A ta úprava v konfiguraci front-endu si2168 je jasná věc.

No a když jsem ty ovladače rekompiloval (po úpravě hlavičkového souboru s IDčky se díky závislostem rekompilují prakticky všecky DVB ovladače), nainstaloval a natáhnul, firmware jsem si stáhnul, zasunul dongle, a... všecko vypadalo bezvadně, až na poslední věc: chybová hláška o tuneru. Driver si2157.ko čekal zřejmě čip si2141, místo toho ale zakrákoral že "neznámý tuner si21128" - k čemuž mi Google nabídl dva roky starou poznámku od CrazyCata (asi na to taky narazil) že ten tuner nejspíš hledá na špatné i2c adrese (podle mého možná spíš na špatném i2c portu, soudě podle pozdějších CrazyCatových vlastních úprav ve zdrojácích - viz níže).

No takže jsem se začal pídit, jak se dostat ke CrazyCatovým ovladačům. Mimochodem CrazyCat svoje repo linux_media zřejmě dost nedávno přestěhoval z GitHubu na BitBucket (odkaz níže). Takže odkazy v debatách rok-dva starých už nefungují. Mrknul jsem nejdřív na repo linux_media,
https://bitbucket.org/CrazyCat/linux_media
což je zřejmě celý kernel cca 5.0-RC7. Prohrábnul jsem se ovladači, zkusil jsem porovnat s patchem od no_bodyho... vida, u CrazyCata vidím dvě oddělené verze frontend_attach:
cxusb_mygica_t230_frontend_attach()
cxusb_mygica_t230c_frontend_attach()
navzájem asi dva drobné rozdíly, jednak se CrazyCat zřejmě postavil čelem k tomu nastavení hodin (zde ts_clock_mode) o kterém mluvil no_body, druhak je tam jakási dynamická detekce tuneru (model tuneru vrací hezky opouzdřená "probe" funkce) - ovšem oproti vanilkové verzi (5.0.8) téže funkce je rozdíl poměrně obrovský (hluboký). Nemá smysl uvažovat, že bych tohle všechno jenom po svém transplantoval do vanilky. Není to na pár selektivních zásahů.

Takže celý balík CrazyCatových ovladačů. Nebo spíš celý kernel? Ale mě se nechce fungovat na 5.0-RC7 bůhví od koho... Aha, ono to vypadá, že doporučený postup je takový, že se jenom "out of tree" přeloží prakticky celý subsystém Video4linux. to je taky baťoh, ale aspoň to není celý kernel. A CrazyCat zřejmě udržuje svoje ovladače rozumně kompatibilní s aktuální vanilkou.

Takže kudy na to:

Postup jsem nalezl nečekaně na produktové stránce CZC.
https://www.czc.cz/evolveo-sigma-t2/218951/produkt

Zákazník mradosta zakomponoval správný postup přímo do hodnocení produktu :-D Borec. Copy+paste:

git clone https://bitbucket.org/CrazyCat/media_build
cd media_build
./build
sudo make install
sudo make rmmod
sudo modprobe dvb_usb_cxusb

Zasunout...
"media: loading out-of-tree module taints kernel."
Ach jo.
"WARNING: You are using an experimental version of the media stack."

Ale našel demodulátor, front-end i tuner. To zní slibně.

w_scan -c CZ > channels.conf
w_scan --output-VLC >>vlc.xspf

A sviští. Sype nalezené kanály.
Trochu mi vrtá hlavou, co přesně znamená hláška "skipped (transponder already known)". To jako že když chytí tentýž mux na jiném kanálu, tak se na něj vykašle? Tady bych si rád vybral kanál s nejvyšší sílou signálu... Takže prohlídnout pásmo pomocí rtl_sdr a nadiktovat konkrétní frekvence.
Je možné, že těch duplicitních kanálů vidí *tolik*? Vždyť to nahlásil asi dvacetkrát... tomu se mi nechce věřit.

Podařilo se mi vyloudit obrázek z VLC. VLC 3.0.6 v Debianu 9. DVB-T MUX1.
Zvláštní je, že tak v 50% pokusů o spuštění TV streamu nebo o přepnutí programu VLC spadne.

To by pro dnešek stačilo, pokračování někdy příště. Na řadě je user space.

915
Desktop / Re:Dotyková obrazovka má invertovaný dotek
« kdy: 19. 04. 2019, 19:18:30 »
Nemohl byste prosím dodat vzorek toho konfiguráku, co Vám navrhl xinput_calibrator ?

Momentální obsah aktivní kalibrační matice (resp. matic, ono jich může být víc) by měl ukázat příkaz

xinput list-props

Neznám podrobnosti, jak se chová xinput_calibrator konkrétně v Ubuntu 18.04. Pokud je mi známo, xinput_calibrator je už několik let unmaintained, a přestože je teoretická šance, že drobné oděrky fixnou balíčkoví maintaineři v distrech, moje dosavadní zkušenost byla, že v distribučním repu bývá nadrzo stará verze, s aktuálním stylem konfigurace vrstvy xinput již nekompatibilní.

Historicky xinput_calibrator navrhoval útržek konfiguráku (xorg.conf) ve dvou různých formátech pro klasické kartézské souřadnice (min_X, max_X, min_Y, max_Y) - dnešní X tuto konfiguraci ignorují. Naposledy když jsem se v tom vrtal (pár měsíců zpátky) tak platilo, že xinput_calibrator neuměl vypotit přímo "matici" (devět hodnot v jednom řádku). Kromě toho jak správně říkáte, různá distra můžou mít ten modulární konfigurák v různých adresářích. Takže pokud Vám konfigurace doporučená konkrétní verzí xinput_calibratoru "nefunguje", tak není divu.

Proto znovu uvádím odkaz na svůj perlový skript, který zneužije xinput_calibrator jako zdroj vstupních dat (dotyků) a spočítá "matici". Tuším i navrhne správnou cestu a název souboru pro Debian/Ubuntu. Ten skript je destilát mých mnoha pokusů a omylů (a pokročilé matematiky z pera pana Mikšeho). Na konci toho webu je pár odkazů na výživné návazné čtení, podle kterého jsem to lepil dohromady.

Stran: 1 ... 59 60 [61] 62 63 ... 84