Distribuce pro PC bez monitoru

Re:Distribuce pro PC bez monitoru
« Odpověď #15 kdy: 01. 04. 2025, 10:21:20 »
na to by bylo lepsi poridit cinskej co lze (udajne a navic sem si asi neulozil konkretni link kde v komentari to nekdo potvrdil vcetne postupu :) programovat jen uzivatelem pres i2c...
Jo tyhle cinske jdou preprogramovat, tady je navod pro raspberry pi ale fungovat asi bude i na necem jinem
https://walmsley.tech/re-writing-edids-on-hdmi-dummy-plugs/
ja presne tyhle pouzivam (viz take https://www.aliexpress.com/item/1005002930378948.html) a zapsal jsem si do nej svuj (mirne upraveny) monitor protoze
- jsem si odpalil i2c na hdmi vstupu meho monitoru, hdmi video vstup funguje ale musi se hardcodovat, autodetekce nefunguje (spravny EDID jsem pak vycetl pres DisplayPort nebo VGA konektor, tam to porad funguje), tenhle dongle to vyresil
- nejake AMD grafiky v linuxu jsou moc chytre a zvoli jine kodovani barev nez RGB protoze monitor rika ze to umi, ale musi se jit rucne v monitoru do menu a prepnout to jinak, a pak pro neco jineho nebo reboot do Windows na stejne masine to je treba zase rucne prepnout zpet na RGB coz je hodne otravne, nenasel jsem jak to v linuxu vypnout.


Re:Distribuce pro PC bez monitoru
« Odpověď #16 kdy: 01. 04. 2025, 10:25:18 »
Vnutit linuxovému kernelu (jeho Direct Rendering subsystému) aby držel konkrétní video port zapnutý, a dokonce v konkrétním rozlišení, lze poměrně triviálně argumentem video= na kernel command line, jak už psal @k3dAR. Akorát pořizovat lokální klon EDIDu mi přijde jako kanón na vrabce a potenciálně "more rope to hang yourself with", pokud si třeba pořídíte jinou televizi apod. Tento hodnotící soud je ale dost nejednoznačný, ještě se k tomu vrátím na konci.

Zmíněnému argumentu video= se dá nacpat prostě jenom žádané rozlišení a snímková obnovovací frekvence.

video=HDMI-A-2:1920x1080@50D

Řetězec HDMI-A-2 je jméno výstupního portu. V dnešním PC jich bývá na výběr víc. XWindows používá mírně jiná jména než linuxový kernel (DRM). Pro použití v kernel command line mohu např. doporučit, jednou na začátku při zprovozňování konfigurace přidat na kernel command line zaklínadlo drm.debug=0xe , a pak se podívat v dmesg, jaké výstupy si DRM subsystém sám automaticky našel a jak jim říká. A zvolený pak použít v zaklínadle video= .

50 za zavináčem znamená 50 Hz. Není přítomno "i", takže neprokládaných. A poslední písmenko D znamená "výstup natvrdo zapnout, ignorovat detekci připojeného monitoru a jet digitálně" (asi protože DVI-A umí alternativně analog VGA). Varianta od k3dARa má na konci "e", což znamená prakticky totéž = natvrdo zapnout výstup (a funguje i na analog VGA).

K tomu dokumentace: https://www.kernel.org/doc/Documentation/fb/modedb.txt

Následně XWindows mají svoji vlastní databázi režimů a režim z kernelu nepřevezmou. A dá se nacpat modeline do xorg.conf. Což je asi nakonec užitečné. Ona totiž geometrie videorežimu není jednoznačně daná rozlišením - a u full HD a UHD existují např. nuance mezi "počítačovým" videorežimem dle CVT a "Consumer Electronics" variantou téhož rozlišení... televize bude patrně preferovat CE režim. Použití "počítačové" CVT varianty videorežimu (nebo nějaké vlastní tvorby) může mít všelijaké důsledky. Třeba mně se občas cukalo přehrávání videa - asi jsem přesně netrefil pixel clock. Později jsem vygooglil modeline, která funguje bez cukání. Nebo (teoreticky) pokud tohle televize rozliší, mohla by na CE režim nasadit jinou sadu "vylepšovacích" filtrů, než na CVT režim (scale + crop, zvýraznění hran, zvýšení saturace barev). Zde bych zaslepil případnou odbočku na téma, "jak zabránit televizi ve vylepšování obrazu na vstupu od počítače".

Obecně mechanika videorežimu nechává autorovi v jistých mezích volnou ruku, kolik řádek a sloupců ponechá na "temné místo" a jakou přesně frekvenci použije na základní pixel clock. Typické geometrie CVT vs. CE (nebo třeba starobylé GTF) jsou jenom konkrétní standardní "souřadnice" v tom nepříliš jasně ohraničeném prostoru přípustných kombinací... Ve velmi obecné rovině "co je správně a co už je za čárou" posuzuje každý monitor či televize podle svého a výrobce zobrazovacího zařízení nemá podrobnosti nikde dokumentovány...

V této souvislosti, pokud Vám tahle bezbřehá svoboda nevyhovuje, tak použijte postup, který popsal @k3dAR: zazálohujte si EDID, který kernel koupil od Vaší reálné televize, a prostě ho vnuťte při bootu natvrdo ze souboru. Tohle by se mělo televizi přesně líbit. Taky by ten EDID s trochou štěstí mohly z kernelu zdědit Xwindows.
Nebo si vygooglete standardní CE modeline pro žádané televizní rozlišení - to by teoreticky mělo chutnat kterékoli televizi. Nebo zřejmě by se aktuální modeline měla dát i zjistit za jízdy (xrandr nebo tak něco).

Deníček z mých vlastních pokusů před pár lety: https://frr.g6.cz/htpc/htpc.htm#k-cmd

Řešil jsem tehdy, že počítače tíhnou spíš k 60Hz refreshi, což je cca soudělné s americkou TV normou NTSC, kdežto u nás PAL má tradičně 50i, tzn. pro přehrávání televize dává o měličko lepší smysl 50 Hz (i neprokládaných). Je mimochodem zábavné, že většina historického materiálu u nás je zaznamenána v PAL@50i, ale rozhodlo se, že HD streamy v rámci DVB-T2 budou u nás vysílány v 1080@50p. Přitom mnoho zemí a satelitních HD kanálů vysílá 1080@50i, a v době přechodu na T2 mnohé starší full HD televize 50p neuměly, resp. tuto schopnost neoznamovaly ve svých EDID - takže když člověk připojil STB, tak on převáděl 1080p zpátky na 1080i, aby ho mohl poslat televizi... Navazuje nekonečná debata o algoritmech správného deinterlacingu, kompenzaci pohybu, závěrky atd.

Reálně nejen v internetech, ale i v některých televizních pořadech (!) potkáte materiál, který byl někde cestou od kamery skrz záznam a prodej / předání do studia lajdácky konvertován mezi nesoudělnými snímkovými kmitočty a už mu nejde pomoct (cuká ale nezabere na něj IVTC apod.) A dnešní ploché televizní přijímače zcela rutinně materiál ve formátu 1920x1080 o pár procent natáhnou a oříznou, což je zvyk zděděný z dřívějších analogových dob, kdy těsně na hraně temného místa bylo přenášeno pár bajtů nějakých metadat, a bez ořezu se to vrtělo na prvním viditelném řádku nebo tak něco... takže tomu zcela zbytečnému ořezu jdou dnešní vysílací pracoviště "naproti" tím, že materiál předem o pár procent smrští, aby na obrazovku hezky pasoval... takže přesné rozlišení 1920x1080 nikdy nedosáhnete, obraz je naschvál mírně mázlý, aby ty několikanásobné nesoudělné konverze nebyly vidět... A televizní přijímače už poměrně dlouho umí všelijaké vylepšovače typu "inference ostrého rozlišení z pomalu se pohybující scény" (takže občas z té mazanice na okamžik "vyskočí obraz jako břitva") nebo TV interně umí poslat na stínítko násobek Hertzů co má materiál, a aby to vůbec k něčemu bylo, tak televize umí i nádherně interpolovat pohyb, takže se pak starý filmový materiál pohybuje jak čerstvý záznam z televizního studia nejmodernější technikou apod.
« Poslední změna: 01. 04. 2025, 10:28:57 od František Ryšánek »

Re:Distribuce pro PC bez monitoru
« Odpověď #17 kdy: 01. 04. 2025, 10:30:20 »
pokud nepripojis tak se vyresetuje na nejaky 27" 4K LCD takze na LCD 24" FHD mam pak fialovej obraz ;-)
Mozna je to ten samy problem co jsem mel ja viz vyse? vic info o tehle vlastnosti
https://gist.github.com/RLovelett/171c374be1ad4f14eb22fe4e271b7eeb

k3dAR

  • *****
  • 3 149
  • porad nemam telo, ale uz mam hlavu... nobody
    • Zobrazit profil
    • E-mail
Re:Distribuce pro PC bez monitoru
« Odpověď #18 kdy: 01. 04. 2025, 16:45:35 »
pokud nepripojis tak se vyresetuje na nejaky 27" 4K LCD takze na LCD 24" FHD mam pak fialovej obraz ;-)
Mozna je to ten samy problem co jsem mel ja viz vyse? vic info o tehle vlastnosti
https://gist.github.com/RLovelett/171c374be1ad4f14eb22fe4e271b7eeb
No asi tam nejaka podobnost bude, LCD mam "Dell U2412M" (on ma "Dell U2413") a grafika je z "AMD Ryzen 5 PRO 2400GE" (on ma RX570) :-) Ale problem je ze nahradit EDID nepomuze, protoze kdyz v Digitus HDMI Emulatoru mam flashlej EDID z toho LCD, tak vse OK, fialove je to jen kdyz se Digitus vyresetuje na svuj vychozi EDID, prave tim ze mu nelze zakazat auto reflash/reset pri odpojeni kabelu z vystupu (coz mi dela ten 8port HDMI Switch)...
Kazdopadne diky za potvrzeni ze ten cinskej jde pres i2c flashnout vlastnim (ten postup z tveho linku pouziva eeprog ten postup co sem cetl tehdy ja pouzival primo (myslim) i2cset nastroj z i2c-tools jen mel nejakou adresu kam zapsat, ale vysledek je pocitam stejny :)

k3dAR

  • *****
  • 3 149
  • porad nemam telo, ale uz mam hlavu... nobody
    • Zobrazit profil
    • E-mail
Re:Distribuce pro PC bez monitoru
« Odpověď #19 kdy: 01. 04. 2025, 17:04:31 »
EDIT: nedalo mi to a jeste sem zkusil hledat flashnuti pres i2cset, nasel zajimavost - za $1 DIY reseni z HDMI 90° Redukce a pripajeni 24C02 :-) (pro zapis tam pouziva edid-rw v pythonu)

a pak k eeprog dalsi alternativu "write-edid", coz je ciste bash script pouzivajici i2cset :-)


Re:Distribuce pro PC bez monitoru
« Odpověď #20 kdy: 02. 04. 2025, 08:20:41 »
ja pouzivam ubuntu s lxde, co mi bezi ako server a startuje to bez klavesnice, bez monitora a kedykolvek to tam pripojim, tak normalne vidim plochu. Len mam taky pocit, ze som musel nastavovat v biose, resp. uefi integrovanu grafiku a hdmi vystup

Re:Distribuce pro PC bez monitoru
« Odpověď #21 kdy: 02. 04. 2025, 09:50:27 »
EDIT: nedalo mi to a jeste sem zkusil hledat flashnuti pres i2cset, nasel zajimavost - za $1 DIY reseni z HDMI 90° Redukce a pripajeni 24C02 :-) (pro zapis tam pouziva edid-rw v pythonu)

a pak k eeprog dalsi alternativu "write-edid", coz je ciste bash script pouzivajici i2cset :-)
Dik, do toho usetreni bych asi nesel vzhledem k cene toho hotoveho, ale je tam dost zajimaveho infa. Taky jsem se pres to dostal na https://github.com/bulletmark/edid-rw/issues/5 - ocividne clovek muze spatne mirenym zapisem pres i2c prepsat DDR pametovy modul a pak se divit ze pocitac nebootuje :-)

Re:Distribuce pro PC bez monitoru
« Odpověď #22 kdy: 02. 04. 2025, 13:20:34 »
ocividne clovek muze spatne mirenym zapisem pres i2c prepsat DDR pametovy modul a pak se divit ze pocitac nebootuje :-)

To jsou pěkné hacky https://github.com/bulletmark/edid-rw/issues/5#issuecomment-170708562 :-)