Lefagyott a rendszer, kapcsold ki a monitort!

Monitor (CRT, TFT, ...), projektor, ...

Olyan metodust/kulso eszkozt keresek, amely pl. Linux kernel crash (vagy Windows kekhalal) eseteben lekapcsolja a monitort (akar azonnal)!

Kioszkoknal nem szerencses, ha latjak, az OP rendszer ujraindul, vagy lefagy. Inkabb sotetuljon el ezesetben a kijelzo.

Otletek?

  • 2282 megtekintés

( b10up | 2025. 08. 29., p – 09:26 )

Vegyél egy Gen2 vagy újabb shelly okos konnektort. Tegyél a gépre egy web szervert egy sima hello world html-lel, és tegyél egy scriptet a shellyre ami bekapcsol ha eléri és ki, ha nem sikerül neki egymás után 3x.  Pinget nem mondom, mert arra tud offloadolva a hálókártya is válaszolni lefagyott gép mellett is. 

ezt a megoldast ismerem, de sajna it is van 3-5 masodperces delay...nekem olyan kellene, ami tizedmasodpercen belul reagal...miert?  mert egy demonstracios kiosknal, vagy kivetitonel meg a 2 masodperces crash is rosszul nez ki, ha egyszerre 30-an nezik, pl.

Valahol lattam olyan eszkozt - csak sajna nem talalom, amin kamera figyeli a monitort es realtime kepelemzest csinal, ha eszleli az adott crash kepernyot (konfiguralhato), akkor megszakitja a hdmi vonalat.

De azert kosz

Ezutobbival kapcsolatosan nekem az a gyanum hogy a gyakorlatban mind a fals pozitiv, mind a fals negativ eselye relative nagy lehet. Raadasul az alapfilozofiat is neked kell kidolgozni (azaz akkor kapcsolja le a monitort ha kekhalalt lat vagy akkor nem kapcsolja le ha a főműsort detektalja). 

Mert ugye oke hogy a kékhalal relative jellegzetes de azert mas tipusu panikot is el tudok kepzelni (lasd pl tetszoleges python szkript tetszoleges crash-enek tetszoleges unhandled exception/call backtrace-e). 

Szoval igen, nem egyszeru a problema :)

Most egy konzumer OS-en, konzumer HW-en full out-of-band megoldásban gondolkodni, olyan, mintha 5 másodperc alatti kerékcserét akarnék az autómon...

Én Windowson, Linuxon real time priorityvel (vagy hát ami a legmagasabb) pingelnék valamit, ami kikapcsolja a monitort, ha nem jön ping, visszakapcsolja, ha jön. Ha egy ilyen megáll 2 másodperce, akkor az a rendszer már úgyis használhatatlan. Ez a monitorozzuk kamerával a képet szerintem nevetséges.

Azert nem vetnem el teljesen. Pl: UART-on 115k2-vel adsz ki 8n1-en 0x55-oket. Egy RCCR savszuro + tranzisztor + dioda es meg 1-2 passziv. A latency is egy passziv taggal allithato.

Nem mondom hogy ez most egy "kitesztelt megvasarolhato termek", de ha nincs ilyen akkor csinalok belole :] Muholdakon hasznalunk hasonlo (nem teljesen ilyen celra, de analog analog elven mukodo) alrendszereket. Mission-saver is volt mar. 

Egy RC tagnak :) Ami kiszűri a DC-t, majd egy egyeniranyitas utan feltolt egy kondit. Az meg ki tud nyitni egy tranzisztort. Ami behuzza azt a relet, ami arammal latja el a monitort. A minimal valtozat (ami nem is savszuro, hanem felulatereszto) az 3 ellenallas, 2 kondi, 2 dioda es egy tranzisztor (egy soros ellenallas utan egy CR felulaterszto, majd reverz ill soros dioda, ezutan egy parhuzamos RC a tranzisztor bazisara/gate-jere es kesz). Ha van sok 0x55, behuz a rele, egyebkent nem. A szuro CR tagok erteket nyilvan a soroos port baud rate-jehez, a parhuzamos feltoltott RC idoallandojat pedig a latency-hez allitod be.

De. A RC tagnak a C elemét folyamatosan kisüti a soros port jelével meghajtott tranzisztor. Amennyiben leáll a soros kommunikáció, akkor t idő (mikor az RC tag feszültsége eléri az 555 tápfeszültségének a 2/3-át) elteltével a kimenet lemegy nullába. Az áramkör előnye, hogy a benne lévő komparátorok és RS tároló miatt elég precíz és elegendő kimenőárama van, hogy egy 5V/1kOhmos relét direktben meghajtson.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Ah, ertem! Igen, igy valoban... en csak maradtam a sima tranzisztor + kondi kisutes valtozatnal, es a feltoltest vegzi egy dc-blokkolt egyeniranyito amit a soros portrol hajtasz meg. 

De igen, barhogyis, sok jo megoldas van a problemara :) Ha mar a digitalis vilagban maradnank teljesen akkor en valami kelloen hosszu (30-40 bites) LFSR-t etetnek az UART-tal, es ha az azonosan 0-ra megy ki egy ido utan akkor megvan a lock. Egyebkent meg szetesik a jel es old. De ezek a full analog megoldasok azert egyszerubbek :] 

Zseniális!

Na ez az amikor egy fél marék maradék alkatrészből egy egyszerű, de nagyszerű megoldás születik!

Aztán a másik véglet, természetesen túlozva: felhúzni egy kubernetes AI klasztert, ami feldolgozza a képernyőképet!

Az elsőn megoldásnál nem sok, ami elromolhat.

A második esetben? 😁

Korai CHxxx driverek fenomenálisan rosszak voltak, különösen 10x feletti soros portot kellett valós időben kihajtani lassan.
A WIN még rosszabb. Kiküldesz adatot, aztán valamikor kiesik a porton vagy nem.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Jobb konverterekkel nincs annyi gond. FTDI-vel meg sosem volt gondom. Igaz neha finomhangolni kellett a krokodilon, de az inkabb rx, nem tx. De igen, az FTDI sem CHxxx arban van, sajna, az igaz.

Mondjuk ha mission critical az egesz akkor nyilvan nem ez az arkulonbseg fog szamitani. Es ha meg annyira mission critical akkor az USB is felejtos ugy enbloc. Csak van valami felesleges UART azon az alaplapon... azokat mar egyszerubb bennehagyni legacy-kent mint kitervezni :)

Barhogyis, ennel az esetnel elesben nyilvan kell FIFO meretekkel, queuing-al, throttling-gal is foglalkozni. De a jo kompromisszum sztem konnyen megtalalhato. 

( persicsb | 2025. 08. 29., p – 09:49 )

Mi vezérli ezt a kijelzőt? Mert én megfordítanám a dolgot: nem akkor kapcsolod ki a kijelzőt, amikor baj van, hanem akkor tartod bekapcsolva, amikor minden oké.

Például egy processznek folyamatosan írnia kell mondjuk soros porton, vagy bármin egy jelet, tizedmásodpercenként, és ha nem érkezik be a jel, akkor egy relé megszakítja az áramellátását a kijelzőnek.

 

ha az OP rendszer tulterhelt, elkepzelheto, hogy 2 maspodpercig nem lesz soros port iras

Akkor viszont siman lehet hogy egyebkent is kapnal egy ~2 masodperces latency-t... Ez a 2 sec eleg durvan soknak tunik. Nalam (durvan terhelt laptop) az 1 millisec-et nem tudom mindig tartani, a 10 millisec szokott menni. Szoval ezt azert megneznem alaposabban :)

Illetve hümm: a HDMI-n akad I2C busz. Soha nem hasznaltam, nem tudom hogy a HDMI kontroller I2C master-e ki van exponalva az operendszer fele (valahogy), lehet-e hasznalni valamire, de meg az is lehet hogy azzal megoldhato a problema. 

Sajna mindig a legrosszabbra kell gondolni, a reaktiv hozaallas neha jobb, mint a proaktiv. Magyarul, nem tudod kiszamolni ezeknel az OP rendszereknel, milyen taskokat hogyan prioritalnak.

Egy kiosknal ha pl. nagyfelbontasu videot jatszol, sokszor 90%-on megy a CPU meg a memory, nem bizhatunk a soros portos triggerben. Jobb mint a semmi, de nem kielegito.

 

Az i2c busz lehet egy jo orany, de eszkoz kellene, ami megveheto. Nem akarok ujra kereket feltalalni.

Írd bele a posztodba, hogy kész, megvehető eszközt keresel, mert ez nincs benne egyértelműen.
Lehet, hogy nem létezik ilyen eszköz, vagy csak speciális kioszkhoz illeszthetően létezik csak, és a te kioszkodhoz nem.

Ileltve azt nem értem, hogy hogyan gondolod működni azt, hogy valami tizedmásodperc alatt vegye észre, hogy nem az elvárt állapotban van a rendszer, ha azt mondod, a rendszer nem tud kiadni magából megbízhatóan tizedmásodperces sűrűséggel olyan jelet, hogy elvárt állapotban van. Akkor mégis hogyan kellene felismerni azt kívülről, hogy a rendszer elvárt állapotban van?

Írd bele a posztodba, hogy kész, megvehető eszközt keresel

Kesz, megveheto termek lenne olyan kioszkra optimalizalt monitor ami lekapcsol ha ~3 (N=2..10, allithato) egyforma video frame erkezik be egymas utan.

Vagy kesz, megveheto termek lenne egy framegrabberes kozbulso pc/szamitogep/barmi, ami megcsinalja a fenti dolgot. Persze hogy a szoftver hozza kesz, megveheto termek az jo kerdes.

> Ileltve azt nem értem, hogy hogyan gondolod működni azt, hogy valami tizedmásodperc alatt vegye észre, hogy nem az elvárt állapotban van a rendszer, ha azt mondod, a rendszer nem tud kiadni magából megbízhatóan tizedmásodperces sűrűséggel olyan jelet, hogy elvárt állapotban van. Akkor mégis hogyan kellene felismerni azt kívülről, hogy a rendszer elvárt állapotban van?

 

Nem eretetted meg az elozo kommentemet, ugy latszik. A monitorozo eszkoznek semmi koze a  futo rendszerhez, nem az alapjan mukodik, hogy jeleket ad ki a kiosk. Olvass vissza, irtam, egy kameras megoldasrol.

A monitorozo eszkoznek semmi koze a  futo rendszerhez, nem az alapjan mukodik, hogy jeleket ad ki a kiosk.

De a monitorozó rendszer is a kiosk jeléből dolgozik. Az, hogy ez egy videojel, audiojel, soros porti jel, az tök mindegy. Valamilyen jelet érzékel, és ha az eltér az elvárttól, akkor van gond. Minden monitorozás abból indul ki, hogy egy jelet ad ki magából a monitorozandó rendszer.

Olvass vissza, irtam, egy kameras megoldasrol.

Az is a kioszk jeléből dolgozik (csak éppen videojelből). Tizedmásodperc alatt el tudja dönteni, hogy a rendszer nem elvárt állapotban van? 

> Az is a kioszk jeléből dolgozik (csak éppen videojelből). Tizedmásodperc alatt el tudja dönteni, hogy a rendszer nem elvárt állapotban van? 

igen, ez volt vele anno a cel, de nem talalom a celhardvert ra

Ha egy monitoron megjelenik egy kep, annak az elemzesi ideje tizedmasodpercben merheto egy kulso kameras rendszernel, foleg ha "egyszerubb" keprol van szo, mint pl. a Windows kernel crash, aminek nagy resze bizonyos szinskala elem

 

Sajna mas megoldast nem tudok, ezert gondoltam erre

Kameraképen színt felismerni egy fekete dobozban oké, de valós fényviszonyok között sose lesz megbízható. És a problémához mérten rohadt bonyolult is. Plusz nem tudod elindítani, mert ameddig nincs kép nincs engedélyező jel sem. Hogy döntöd el, hogy indulhat a kép? És ha egyből rossz?

És mi a tartalom? Ha volna egy tökéletes stream grabed, arról hogy döntenéd el, hogy helyes-e?

Miért ennyire fontos ez? Titok?

Mint mondtam, kepelemzo eljarast csinal a celhardver, nem(csak) szineket ismer fel. Egy Windows kernel crash eleg jellegzetes kepernyot dob vissza, meghatarozott koordinatakon. Mar 10 eve is csinaltam ilyen grabbeket kamerarol, de azt Windows progibol, erre itt nincs szukseg. Sima celhardver kell, ami csak erre van specializalva.

>Mar 10 eve is csinaltam ilyen grabbeket kamerarol

Én meg már annál is régebben csináltam az első kameraképen objektumot felismerő rendszeremet. Több rendszert is készítettem kamerával és ráadásul még működtek is. És konkrét tapasztalat alapján mondom, hogy igen nehéz feladat megbízhatóra megcsinálni egy kamerakép feldolgozását. A hangsúly a megbízhatón van, olyat hogy demó működik összedobhat neked egy ügyes programozó 1-2 nap alatt is.

Ha viszont nem megbízható, akkor ez a rendszer amit a megbízhatóság miatt akarsz építeni, éppen ez lesz az Achilles sarka az egésznek, emiatt fog folyton leállni például.

Ellenben amit apal meg én javaslunk azt meg lehet csinálni megbízhatóra: a host OS és a processz futását tudja öndiagnosztizálni a PC-n egy program. Ha nem működik, akkor megszűnik az életjel és egy mikrovezérlős rendszer lekapcsolhatja az áramot. A vas minimális egy képelemző célhardverhez képest, az biztos. És meg lehet csinálni megbízhatóra. A kernel pánikot biztosan megfogja, mert kernel pánik mellett a processz nem fog tudni futni, és akkor a live signal számlálója és hash-je nem fog stimmelni. (Sima periodikus jel szerintem nem elegendő live signalnak, mert az akár be is tud ragadni, mint amikor lefagy a gép, és a hangkártya egy buffernyi hangot tovább játszik periodikusan örökké. Ez előfordulhat elvben az UART csip kimeneti pufferével is, persze megvalósításfüggő, és valójában nem fordul elő, de az ördög nem alszik.) Ízlés szerint állíthatod a timeoutot, akár a life signal megszűnésétől kezdve 16ms-on belül (1 frame ideje 60FPS-en) el tudod venni az áramot: a tápegység kisülése lesz a domináns az időzítésben.

 

Csak azért válaszoltam még egyet, mert bzt effektet érzek: kérdezel, aztán leoltod azt aki tapasztalat alapján segíteni próbál. Ez nem túl szép.

>  kérdezel, aztán leoltod azt aki tapasztalat alapján segíteni próbál. Ez nem túl szép.

Csak a trollokat. Bizz bennem.

Minden konstruktiv valasz erdekel, de ha valaki eleve ugy kezdi, hogy "hulye vagy vazze, eleve elvi hibas az otleted", azt nem szeretem. Itt semmi sen elvi hibas, egyelore brainstorming megy.

A hozzaszolasodhoz...igen, a false pozitiv dolgokat nehez kiszurni, de nem lehetetlen. Mint irtam, a jelkuldes megallhat amiatt is, hogz a rendszer overloadban van, nemcsak kernel panicnal. Ezesetben is joh a hiba. Nerm vitatom, a dolog komplex, de hat azert vagyunk itt, hogy kitalaljuk a leheto legjobb megoldast.

Nem csak kékhalál lehet egy kioskon, pl.:

https://www.coretechnologies.com/products/AlwaysUp/Apps/kiosk-crash1-10…

És ilyenből millió+1-et találsz a neten.

Ha ilyen van, az nem arcvesztés?

Vagy ha csak megfagy a gép, és csak a reset segít?

Egy egyszerű watchdog problémából akarsz ilyen kamerás-AIs förmedvényt csinálni, na ezért elvi hibás az elgondolás.

Pedig agyon fogja vágni, ha böngészőből nyomatják egy tonna JS-sel, hardvergyorsítás nélkül, mert azt túl milliárdos volt valamelyik multi implementálni. Vagy mert lusták elolvasni az mplayer manualt, meg felrakni a vaapi drivereket.

>Ne feledd, ha az OP rendszer tulterhelt, elkepzelheto, hogy 2 maspodpercig nem lesz soros port iras, de a kijelzo kikapcsol mert a kulso eszkoz nem kap jelet.

Rétegigényre nem fogsz tesztelt megoldást kapni "Raspberry" mellé. Én is második display portra tenném a cuccot ahol nem látszik a boot. Ha ez nem játszik, akkor mikrovezérlő board USB-s csatlakozással (gyk.: Arduino vagy hasonló) + relé boardot tennék fel (ez annyira kész megoldásnak tekinthető, hogy csak össze kell dugdosni, és dobozba tenni), és az Ardunio csak  akkor kapcsolna, ha van "live signal" a PC-től. A live signalba kell egy számláló, plusz egy CRC, és akkor véletlenül nem tud előállni. A live signalt adó program monitorozza a videólejátszó processzt, és ha az elakad, akkor nem ad szignált.

Eszembe jutott, mégis van "kész" megoldás: https://www.controllino.com/product/controllino-mini/ Ebben a családban van olyan is ami TCP-vel is elérhető lehet.

A latency nem lesz nagy, vagy ha mégis az, akkor alulméretezett vagy egyéb szempontból rossz a rendszer. Ha belegondolsz ha nem lehet elvárni, hogy 10ms-enként jöjjön live signal, akkor lehetetlen ilyen időn belül detektálni a hibát. Emberi fogyasztásra szerintem egy 100ms latency is sokkal jobb mint ami kell, és azt már a gépnek gyerekjáték tartani.

Mi az elvárt képernyő felbontás, és mi adja a megjenelítendő dolgot? Videó? Web? Valami egyéb?

Amúgy felismerni amikor valami nem működik, az sem mindig triviális. A programok tudnak olyat, hogy a processz fut, csak éppen nem csinálja azt amit kellene... A hibaállapot felismerése annál bonyolultabb mennél inkább tilos hibázni.

USB-ből létezik ipari csavarós csatlakozó, de nyilván az aljzatod se olyan, úgyhogy sajnos az USB csatlaozó lesz a rendszer gyenge pontja.

( KoGa v | 2025. 08. 29., p – 10:04 )

Gonosz vagyok, de stabil rendszert alárakni nem opció?

100%-ban nem is.

De a rendszer ismerete nélkül, szerintem ha annyi energiát beleraksz az instabilitás megoldásába, mint az ilyen workaroundokba, akkor sokkal jobb eredményt kapsz.

Egyébként mennyiben rosszabb a "Kékhalálozott a kiosk, ez szar!" mint a "Nincs semmi a monitoron, ez szar!"?

akkor most olvasd el még 2-3x amit leírtam. éppen ezt írtam hogy még a próbakört se bírja ki a jelenlegi rendszered.

saját példa, talán látszik hogy nem a levegőbe beszélek: itthoni fűtés (és újabban okosotthon) vezérlés: jelenleg a második generáció fut, az első generáció 9 évet ment a mostani 4 éve megy. Egyetlen egyszer állt meg egy elromlott mmc kártya miatt. Azóta migráltam ssd-re.

zászló, zászló, szív

Gondolom ha van az orszagban itt-ott osszesen 180 ilyen vacka, az mar napi 1 lenne, ha fel evente jon elo egy eszkozon.

De amugy en sem latom ezt ekkora dolognak. Lattam mar par instabil Linuxos rendszert, mindegyikrol kiderult, hogy hardware hiba volt. (volt egy asztali gep, aminek rossz volt a hutese, egy ipari, aminek szinten, egy RPi gyenge tappal, meg egy, ami megette az SD kartyajat) Ha instabil, meg ki kell deriteni, mi a hibaja, es megoldani. Onnantol stabil lesz, felesleges hozza kulon ITAPPMONROBOT.

A strange game. The only winning move is not to play. How about a nice game of chess?

Azért nem becsüld alá a szarul megírt szoftverek képességeit. A kedvencem, mikor a tüzesróka (debian EDR) szarul megírt javascript oldal miatt elleakeli a memóriát, belerág a swapba olyan mértékben, hogy beáll a hullamerevség. Értsd, gui reakció nulla, ssh bejelentkezés ideje percekben mérhető, soros kommunikáció úgyszintén percekre elhal. Régen még nagyjából be lehetett szorítani homokozóba, de újabban nincs kedvem baszakodni vele.(Durva, hogy az idokep.hu oldala 30 körüli childeot spawnol.)

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Egyébként mennyiben rosszabb a "Kékhalálozott a kiosk, ez szar!" mint a "Nincs semmi a monitoron, ez szar!"?

Azert ha en elmegyek egy fekete kepernyo mellett akkor altalaban arra gondolok hogy "biztos kikapcsoltak", ha kekhalalt latok akkor meg arra hogy "ah, erre is ilyen microsoft-szinvonalu dolgot tettek, lol". Kernel panikot meg igy nem lattam. Egyetertek a kollegaval, jobb a fekete/kikapcs. 

Szerintem csak kínosnak, egyfajta arcvesztésnek érzi, hogy publikusan reklámozódik, hogy már megint lefagyott a Windows. Stabil hardware-rel szerintem ilyen környezetben manapság sem a Windows, sem a Linux nem szokott fagyni, azok az idők elmúltak már, sokat javult a kódok minősége.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igy van, a lefagyas nem tesz jot az "uzletnek".

Sajna itt a tesztjeim alapjan nem kizarhato, hogy kernel panic lesz, nem csak  a hasamra csaptam. Ha egy rosszul kodolt videot feltoltesz pl. a kioskra, azt kell lejatszani, zsebrevaghatja a stabil rendszeredet (jah, es mellesleg ki mondja meg, mi a stabil?) . Ez ez sajna nem mindig jon elo, fugg a jelenlegi allpottol is, gyakorlatilag intermittent.

Mi a feladat pontosan? Mármint az elképzelést értem, hogy ne legyen kékhalál, de na.

Milyen videók ezek, amik kernel panic-ot, meg kékhalált okoznak? Nem "potenciálisan", meg "egyszer majd", hanem már most is. Vagy milyen kiosk rendszerről beszélünk egyáltalán? Nálunk van kint az irodában egy kb. 8x2 méteres monitorfal, nem igazán szokott megdögleni, pedig gyakorlatilag 24/7 megy. Amikor költöztünk, akkor kikapcsolták, az új helyen meg visszakapcsolták.

Mi a konkrét, megoldandó probléma?

( buccaneers v | 2025. 08. 29., p – 10:28 )

Szerkesztve: 2025. 08. 29., p – 11:33

100 éve terveztem és gyártottunk zenegépet/játékgépet - ott volt egy panel sok funkciója mellett késleltetéssel kapcsolta relén keresztül a kijelzőt és villogtatta a beépített LED-eket, nyomógombokat kezelt (titkosított file rendszer kulcsát tárolta vagyis szétszedve nem tudott bootolni a PC - titkos gomb megnyomása nélkül nem adta a kulcsot) stb..

DE 2006 óta van HDMI-CEC szabvány  (Consumer Electronics Control)

2010 óta már általános, persze minden gyártó kicsit beletúrt a szabványba, de ezek alap funkciók:

- hangerő állítás

- csatorna váltás

- input select

- alvás/stand by 

 

A probléma az, hogy kell egy harmadik eszköz - mert ha Windows PC hal meg, nem biztos, hogy le tud futni az a service, ami kikapcsolja a monitort.

TV-ken több HDMI input van így a 2. HDMI-n lévő mini PC/raspberry -re át tud kapcsolni, ami egy maintance állóképet adna ki.

Gyártói elnevezések:

Samsung: Anynet+

Sharp: Aquos Link

Sony: BRAVIA Sync

Panasonic: VIERA Link

 

én így csinálnám most...

 

 

kieg:

USB - HDMI-CEC adapter

Anandtech

Ethernet - HDMI bridge: KWIKWAI

Augusztus 30:

1932 – A német birodalmi választásokon az NSDAP megszerzi a szavazatok 37%-át. Hermann Göring SA-Obergruppenführer átveszi a Reichstag elnöki tisztét.
1940 – A második bécsi döntés elfogadása, melynek alapján szeptember 5-étől magyar csapatok megkezdik a visszacsatolt Észak-Erdély megszállását.
1941 – A Wehrmacht körülzárja Leningrádot, ezzel megkezdődik a város 900 napos blokádja.

( drobert82 | 2025. 08. 29., p – 10:29 )

Virtualizálva futtani az egészet és ha nincs heartbeat, akkor a hostból dpms off?

( zeller | 2025. 08. 29., p – 10:31 )

Én megnézném, hogy tud-e a motyó két monitort kezelni, mert ha jól rémlik, van olyan felállás, amikor a boot/stacktrace csak az egyik display-en látszik, a másik ezidő alatt sötét.
 

sajna ez a kiosk eleve tobb monitort kezel, mindegyik latszik....kozule egyik a primary...de az otlet nem rossz, kellene egy kijelzo (ami nem latszik, es o a primary), akar egy kicsi jelentektelen is, ami a hibauzeneteket kezeli, a tobbi meg eleve lemegy feketebe  crash eseten

( zrubi v | 2025. 08. 29., p – 10:36 )

Ennyi erőfeszítést beletenni abba, hogy eltűntesd a szánalmas valóságot? :D

 

Hol is láttunk már ilyet?!... hmmm... megvan: vonatinfó: ha nem látszik, nem is késik, igaz? :D

jó úton jársz... csak így tovább!

 

LOL

zrubi.hu

Fene tudja, ha már fejleszt valaki egy komplett rendszert, még ha sok külső eszközt is használ, valahogy igényesség dolga (na meg rendszerfejlesztési alapelv is) egységesíteni a felületet, lényegretörő hibaüzeneteket kiíratni és a felhasználó által nem kezelhető eseményeket meg teljesen elmaszkolni.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

( bennyh | 2025. 08. 29., p – 11:20 )

Szerkesztve: 2025. 08. 29., p – 11:24

Kernelt paraméterezni/patch-elni, hogy ne nyomjon dumpot?

 

Egyébként távoli asztalnál én még nem láttam kékhalált, nem gondolnám, hogy egy Linux RDP/VNC felé utolsó erejével még dobna egy BSOD-t

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

file:///usr/share/doc/linux-doc/html/admin-guide/sysctl/kernel.html#panic

panic¶

The value in this file determines the behaviour of the kernel on a panic:

if zero, the kernel will loop forever;

if negative, the kernel will reboot immediately;

if positive, the kernel will reboot after the corresponding number of seconds.

Persze, ezek a ShitDzsípítí, csoda ÓpönÉjÁjj-unk meg... hülyeség mind erről szól, hogy nem lehet bennük bízni, amit ajánlanak, annak utána kell nézni rendesen is. Nem szabad a megoldást rájuk bízni, inkább csak iránykeresésre jók.

Ez a dump-os letiltás egyébként működik, de én nem csinálnám, szélmalomharc. Nem sok mindent old meg, ha pl. a rendszer lesz bootképtelen, akkor attól nem ment meg, hogy az UEFI/BIOS no system disk, no bootable device found hibaüzenete vagy a GRUB javítókonzol, vagy valami más elakadt bootfolyamat látszódjon a képernyőn. Szinte mindennapos jelenség, hogy látok boltok kirakatában, elektronikus hirdetőtáblákon, tömegközlekedésben járműveken, cégeknél infópanelen beragadt gépet, UEFI hibaüzenetet, elakadt Ubuntu/Debian bootfolyamatot, stb.. Ezek annyira részei lettek a mindennapi életnek, hogy igazából a nagy publikum se tojja le.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( Czo v | 2025. 08. 29., p – 12:11 )

USB-s "VGA kartya"? Pl ez? Anno, mielott lett volna a notebookokon tobb kimenet, en egy ehhez hasonlo USB-s cuccal (az meg 2.0 volt es VGA) csatlakoztattam a 2. monitort a 2008-as MBP-hez. Ezen nem latszott se a crash, se a boot kozbeni kep. Az USB 2.0 verzio nem volt tul gyors, ez ma mar valoszinuleg sokkal gyorsabb 3.0 alatt hasznalva. Ez rendes USB eszkoz, nem alt mode cucc.

( mraacz | 2025. 08. 29., p – 15:44 )

Elvi síkon szép feladat, Windowshoz, de Linuxon kernel pánik kiosk módban? Mitől? Örökélet plusz egynapig elmegy egy Porteus megbízható vason ilyesmi nélkül, rá se kell nézni.

( debtamas88 | 2025. 08. 29., p – 19:44 )

Szerkesztve: 2025. 08. 29., p – 20:00

Két dolgot külön kezelném:
1., Windows kifagyott, megállt
2., Képernyő kikapcsolás

"Windows kifagyott, megállt"
Ezt úgy lehet legjobban kezelni (szerintem), hogy a Windows debug opciót bekapcsolod, és soros portra átírányítod, itt lekérdezed az állapotot, hogy mi van ( működik vagy fagy ).

1., Windows debug port
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-a-null-modem-cable-connection

bcdedit /debug on
bcdedit /dbgsettings serial debugport:1 baudrate:115200

2., Windows ADK
https://learn.microsoft.com/en-us/windows-hardware/get-started/adk-install

3., Windows Debug Symbols Offline (PDB fájlok) 
"C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\symchk.exe" /r c:\windows /s SRV*c:\symbols\*http://msdl.microsoft.com/download/symbols

"Képernyő kikapcsolás"
Ezt úgy oldanám meg, hogy beraknék egy "video switchet", amit RS232 porton lehet vezérelni, ezt a monitor és a KIOSK közé kell berakni ( pl.: video switch 2input 1output port - ATEN VS0201).
1., pontban lévő állapot alapján ha lefagy, akkor "video switch"-nek az INPUT portját átkapcsolod az ÜRES INPUT portra, amin nem lesz jel.

 

Kész hardver erre így van, csak a "logikát" kell összerakni, pl.: minipc. 2db soros porttal.

Mondjuk olyan is lehet, hogy ez az "átkapcsoló minipc" kifagy :D
( Ki őrzi az őrzőt ? )

( tomsolo | 2025. 08. 31., v – 13:39 )

managed switch?

No rainbow, no sugar

( wyx v | 2025. 08. 31., v – 20:50 )

Szerkesztve: 2025. 08. 31., v – 20:54

Az otleteket ES a konstruktiv hozzaszolasokat nagyon koszonom, atragom magam a dolgokon, de valszeg a primary display->nem lathato minimonitor (vagy dummy) lesz a nyertes (persze tobbmonitoros kornyezetben).

Ezesetben ugyanis kifagyas eseten az  osszes tobbi kijelzo elfeketedik, igy meggatolva a csunya "panic display"-t, akar Windows akar Linux eseteben.

Hm... ha linuxod lenne, es csak egy vga (hdmi, barmi) portod van (azaz nincs lehetoseg dummy monitorra) akkor megprobalnam meg azt is hogy magat a boot konzolt iranyitanam at a ttyS0-ra (ilyen console=ttyS0,230400n8 earlycon=uart8250,... stb jelleggel). Ha van panik, akkor azt oda irja, igy a display erintetlen marad. 

Jo kerdes hogy windows rendszereken van-e ezzel analog megoldas. Ott meg csak olyat lattam hogy hdmi-dugot kellett bedugni a headless vezerlo gepbe mert ha nincs rakotve monitor akkor a windows be sem bootol... ha ugy vesszuk akkor ez a teljesen inverz problema :)

( hajbazer v | 2025. 08. 31., v – 23:26 )

Szerkesztve: 2025. 08. 31., v – 23:27

Igen, bizony nagy szégyen lehet üzemeltető maciságodnak, ha crashel a kioszkod, de amennyi energiát fecsérelsz arra, hogy nehogy lebukj az instabil szar kioszkoddal, nem inkább azon kéne pörögnöd, hogy ne pánikoljon a kernel?

Legalább akkor az egész gépet ki akarnád kapcsolni, hogy ne zabálja feleslegesen az áramot elpánikolt állapotban, de nem az nem kell, nyugodtan maradjon bekapcsolva, csak az egód ne sérüljön, mások meg ne lássák, hogy elpánikolt a cuccod.

eloszor is ha crashel valami, akkor monitor ki, majd rendszer ujraindit es monitor be..

Nem, nem "először is", mert nem ezt írtad a témaindítóban. Azt írtad, hogy nem szeretnéd, ha látnák a fagyást vagy az újraindulást. Automatikus újraindításról szó sem volt. Idézem.

Kioszkoknal nem szerencses, ha latjak, az OP rendszer ujraindul, vagy lefagy. Inkabb sotetuljon el ezesetben a kijelzo.

Ettől függetlenül pedig továbbra is igaz, hogy az egódat wellness-ezteted ezzel az egésszel, ahelyett, hogy elérnéd, hogy ne legyenek fagyások és random újraindulások az általad üzemeltetett kioszkokon.

( lcsaszar v | 2025. 09. 01., h – 11:49 )

Szerkesztve: 2025. 09. 01., h – 11:52

A kékhalál azért kék, mert nincs benne piros és zöld. Mint már javasolták, 555 timer figyelhetné ezeket, ha nincs piros és zöld jel, akkor timer indul, relé elenged (vagy meghúz), szinkronjel lekapcsol (vagy táp ki).

Szerk: ezen még agyalni kell, mert kék alapon fehér karakterekben mégis lesz mindhárom színből.

( azbest | 2025. 09. 02., k – 10:17 )

Szerkesztve: 2025. 09. 02., k – 10:33

Ahogy végigfutottam a dolgokat, lehet koncepcionális a probléma. Normál, natív kimenet esetén valami komolyabb figyelés, hardveres támogatás kéne ehhez.

Fapados megoldás lehet, ha nem natív kimenetet használsz erre, hanem léteznek usb3-as donglek, amelyek nem működnek az oprendszer nélkül.
Nem type-c alternate mód, hanem displaylink vagy kínai megfelelője. Nekem a Fresco Logic fl2000 chipsetesek váltak be (windows only), fullhd képet elég jól kezelik. Azért teljes képernyős nagyon izgő mozgó videóknál lehet tömörítési artifact vagy ha a gép procija nem elég gyors, akkor képkockaszám csökkenés. Persze lehet, hogy másodlagos hagyományos videokártya esetén sincs rajta kép boot közben vagy lehaláskor, lehet azzal is ugyanaz a hatás.

De az is lehet, hogy nem natívan a pécéről kéne lejátszani, ha videók mennek, hanem valami streaming lejátszó eszközről (akár valami pi zero2 vagy hasonló célszerszám, belső hálózaton, dobozon belül), amit csak vezérel a fő gép.

> Fapados megoldás lehet, ha nem natív kimenetet használsz erre, hanem léteznek usb3-as donglek, amelyek nem működnek az oprendszer nélkül.

 

Igen, ez fullHDig jol mukodhet, persze limitalt kepernyoszammal. De 2K 4K eseteben nem sanszos.

 

Egyebkent mik a tapasztalaid a displaylink  alternativakrol?

Linux alá az eredeti displaylink működik leginkább. Kicsit használtunk 2-3-dell dokkolóban lévő változatot. Mondjuk eleve régi, használt készülék volt, így előfordultak vele anomáliák, lehet az usb csatlakozót újra kellett volna forrasztani, mert néha eldobta magát. Elvileg létezik újabb változat, ami 4k képes is lehet.

A klón vackok linux alá nem implementáltak. Az fl2000-hez volt valami kezdetleges linux driver, amit próbáltam és volt hogy működött, de instabil volt. Win alatt használunk a cégnél párat olyan notikkal, amikhez csak így lehet második monitort kötni. Pici késleltetése van, gyengébb gépnél nagy prociterhelésnél döcöghet. Némelyik gép usb3 portja nem ad neki elég áramot és akkor néha elsötétül egy pillanatra. 

Anno jópár éve vettem aliról egy ilyet:
https://logout.hu/bejegyzes/azbest_usb3_vga_adapter_fresco_logic_fl2000…

és ehhez hasonló, de valsz valami plusz chippel hdmi kimenet tükröt is adó változatot szoktunk venni. 
VCOM CU322M https://www.pcx.hu/vcom-usb-3-0-apa-usb-hub-cu322m--00808186
A drivere jön föl pendriveként alapból és a telepítése után / vagy a pendrive mód leválasztása után vált át kimenet módra.

Viszont léteznek más fajták is. A gembird / cablexpert változat nagyon ócska. Macrosilicon chipsetes, ami valójában usb2-őt tud csak, így néhány fps képfrissítésre képes csak.
https://logout.hu/bejegyzes/azbest_usb3_hdmi_adapter_gembird_a-usb3-hdm…

Van hogy 4k képesnek hirdetik, még az is lehet, hogy képes rá, ha csak állóképet kell mutatnia.