[Megoldva] Sokmonitoros rendszer

Linux-haladó

Van egy laptopom, amit idáig Windowsal használtam. A két monitort úgy oldottam meg hogy egy a HDMI-re , egy pedig a DisplayLink USB3-al. De áttértem Linuxra, és azt tapasztaltam hogy a DisplayLinkManager bármit is csináltam, még az egér mozgásra is felpörgette a processzort 25-100% közé. Mindent elolvastam a neten amit írnak és sajnos ez ilyen szar Linux alatt.

Beugrott hogy valahol valamikor olvastam, hogy egy billentyűzet, egy egér és több gép több monitor. Rá is találtam a Barrier-re. (https://github.com/debauchee/barrier) 

Elővettem az előző laptopom, feltelepítettem az Ubuntut erre is, rádugtam a második monitort, és összekapcsoltam Barrier-el. Nagyok királyul működött, kicsit ugrált az egér, meg a billentyűzet is várt néha, ezért összedugtam etherneten a két laptopot. Nagyon állat lett, ráadásul van egy bonusz laptop kijelzőm. Szét is osztottam a processzeket a két gép között. 

Az jutott eszembe, hogy van két RPI4-esem, gigabiten összedugok mindent az asztalon, és dugok mindkettőre RPI4re egy monitort, vagy egyre kettőt, és összekapcsolom Barrier-el, és X11 forwarding-al használom, az milyen fasza lenne. Csak nem tudom hogy mennyire lenne használható. Van valakinek tapasztalata ebben? Mennyire használható egy RPI4-es és az X11 forwarding? Azt tudom hogy jó a PI4, 4GB-os mindkettő, SSD van rajtuk, tehát az IO is gyors. 

A végtelenségig bővíthetném, ha működik. Működhet ez normális sebességgel?

Előre is köszi.
 

  • 410 megtekintés

( fsanyee | 2022. 10. 10., h – 17:35 )

mi az a displaylinkmanager, és miért van rá szükség egyáltalán?

Az egy program, Linuxon ezen keresztül használható az USB3-ra dugott DisplayLink hardver (https://www.synaptics.com/products/displaylink-graphics/displaylink-pro…). 

Extensible Virtual Display Interface (EVDI https://github.com/DisplayLink/evdi) kernel modul használatával USB3 és egyéb portokból DisplayPort-ot csinál. Meg más egyéb portokat. LAN, USB, HDMI, VGA, stb.

( Foltos | 2022. 10. 10., h – 18:27 )

Szét is osztottam a processzeket a két gép között.

Ezt kifejtenéd hogyan csinálod?

RPI4 + barrier + X11 forward

Ezt nem igazán értem. Ha a barrier -rel adott gépen "kiegészíted" a display -t másik gépre, akkor mit csinál az X11 forward?

A process (erőforrás) szétosztás azt jelenit ebben az esetben nálam, hogy a rádió hallhatás, torrent, adatbázis, fut az egyik gépen, másiokon meg fejlesztés IDE, virtuális gépek, stb. Ez mindegy. Csak egy mondat. Lényegtelen volt, bocsi.

A lényeg

Hívjuk így: van laptop-1 + 1 monitor, és van laptop-2 + 1 monitor. 4 kijelző. 

A barrier megoldja hogy a laptop-1 billenytűzete és egere mind a két laptopot kezeli. 4 kijelző, egér billentyűzet ott aktív ahol kell, pixel pontosan, stabilan gyorsan.

Az X11 forward azért jön a képbe, hogy a laptop-2 gépen tudjak elindítani laptop-1 alkalmazást. Ez működik, nincs vele probléma.

A gondolat, hogy beüzemelek pri4-1 + 1 monitor, és rpi4-2 + 1 monitort, vagy rpi4-1 + 2 monitor. Mivel ezek azért ~lassúak, azt gondoltam hogy X11 forward megoldja hogy csak mint grafikus felület használom a PI-ket. A programok meg a laptop-1-en futnak. Így nem kellene a laptop-2, és szuperül működne a többmonitoros rendszer.

Nem egyszerű elmagyaráznom, mert én is összezavarodok, hogy mindegyiken van X és a barrier összekapcsolja, de akkor most melyik az X szerver és melyik az X kliens, melyik konfigot is kell melyik gépen mire módosítani. stb.

szétosztás

Aha, értem. Abban reménykedtem, hogy van valami egyszerű megoldásod az automatikus szétosztásra. Persze a "cluster" meg az "egyszerű" szavak ritkán szerepelnek egy mondatban.

X11 forwarding

Tehát a PI4 -eken nem futna barrier, csak remote desktop -pal átvinned rá a notebook -on futó process GUI -ját. Itt keveredtem meg, hogy a barrier meg az X11 forwarding együtt minek. Most már tiszta, köszi!

Ha fordított nyelven fejlesztesz (C és társai), akkor még egy distcc -t meg egy sccache -t tegyél fel mindenhová. Külön ínyencség lesz a cross compiler befűtése az x86 -os laptop és az arm -os PI4 között. De ha összejön, legalább tesztelheted, hogy a cross compiler meg a natív kompatibilis object fájlokat fordít e. Csak azért írom, mert látom, hogy szereted a kihívásokat 😉.

Tehát a PI4 -eken nem futna barrier, csak remote desktop -pal átvinned rá a notebook -on futó process GUI -ját. Itt keveredtem meg, hogy a barrier meg az X11 forwarding együtt minek. Most már tiszta, köszi!

Barrier fut mindenhol. Ez az alapja hogy 1 billenytűzettel és 1 egérrel lehessen kezelni. Az X11 Forward meg azér kell hogy az RP4 vékony kliensként működjön.

( locsemege v | 2022. 10. 10., h – 22:39 )

Barrier jó cucc, multiplatform. Meg lehet vele csinálni, hogy Windows-on húzod az egeret, lehúzod a monitor szélén, majd linuxos gép monitorán jön be, mintha csak egy másik monitor lenne, holott még az oprendszer is más. Valójában egyszerű a dolog, egy hálózati kapcsolatot fenntartó szerver-kliens páros, ami átadja a HID event-eket.

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

( locsemege v | 2022. 10. 10., h – 22:40 )

Szerintem próbáld ki, majd írd le itt egy blogban a tapasztalataidat!

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

Nem rossz az elnevezés, étem a logikát, mondanám hogy szuper, de a guglis emberek biztos nem fogják érteni, tovább megyek értetlenkedni fognak. 

Amúgy pofon egyszerű, hogyan, hogyan bővítsük végtelen monitorral a laptopunkat, vagy bármilyen gépet amire már nem lehet további monitort dugni.

  • Vegyünk egy számítógépet, jelen esetben Ubuntuval, amin van monitor, billentyűzet és egér és telepítsük fel a barrert, majd állítsuk be barrer szervernek. 
  • Vegyünk egy RP4-et, jelen esetben Ubuntuval, egy monitorral, állítsuk be barrer kliensnek. Ezt ismételjük addig amíg van pénzünk. :-)
  • Most hogy van egy monitorfalunk, amin az egeret húzva ide-oda és a nap végére izomlázunk lesz, az RP4-ekből csináljunk X11 klienseket, hogy vékony kliensként használjuk.
  • A számítógépből pedig X11 szervert.
  • Ínyencek mindenből csinálhatnak X11 szervert és klienst, hogy ott futtasanak programot ahol akarnak.

Egészítsd ki ha hibás a gondolatom.