Login
Newsletter
Werbung

Thema: USB-Monitore mit Linux in greifbarer Nähe

62 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von lachender Pirat am Mo, 18. Mai 2009 um 20:33 #
sehr gut!
[
| Versenden | Drucken ]
  • 0
    Von Udo am Mo, 18. Mai 2009 um 20:46 #
    Wirklich sehr gut. Fedora 12 wird Multiseat unterstützen. Ich denke mit vielen 2010 Distros wird man einfach an einen Rechner viele Monitore, Mäuse und Tastaturen anschliessen.

    Vielleicht gibts es dann doch noch Anwendungdszenarien für AMDs und Intels 2010 CPUs.

    [
    | Versenden | Drucken ]
    • 0
      Von McNerl am Mo, 18. Mai 2009 um 21:04 #
      Was sind 2010 Distros bzw. CPUs? Prozessoren im Jahr 2010?!
      [
      | Versenden | Drucken ]
      • 0
        Von Jasager am Mo, 18. Mai 2009 um 21:16 #
        1) Die jeweiligen Distributionsreleases im Jahr 2010, also beispielsweise Ubuntu 10.4 und Ubuntu 10.10.

        2) Sowohl Intel als auch AMD haben Prozessoren für den Massenmarkt angekünsigt, die neben der CPU auch einen Grafikprozessor im Package integrieren, die Grafikeinheit im Chipsatz entfällt dann.

        [
        | Versenden | Drucken ]
        • 0
          Von asdasd am Mo, 18. Mai 2009 um 21:48 #
          @2. wird auch zeit, in modernen computern frisst die GPU sowieso mehr strom als die cpu
          [
          | Versenden | Drucken ]
          • 0
            Von Kartoffel200 am Mo, 18. Mai 2009 um 22:32 #
            Dafür können die GPUs teilweise auch weitaus mehr leisten.
            [
            | Versenden | Drucken ]
            • 0
              Von Arrrtoffel am Mo, 18. Mai 2009 um 23:37 #
              Egal, wer braucht das schon, wenn man mal von der Wissenschaft und ganz wenigen Grafikfanboys absieht.
              [
              | Versenden | Drucken ]
              • 0
                Von wer am Di, 19. Mai 2009 um 00:15 #
                Immerhin kann man die GPU, bei einer guten Busanbindung, auch als doppelt genauen Fließkommaprozessor nutzen. Das kann z.B das Encoden von Filmen beschleunigen, erlaubt komplexere Verschlüsselungen, und kann so manches Image Manipulation Programm schneller machen. (immer vorausgesetzt es gibt eine einheitliche Schnittstelle.)
                [
                | Versenden | Drucken ]
              0
              Von Jupp am Sa, 23. Mai 2009 um 13:54 #
              Jein. Für Sachen, die sich gut vektorisieren lassen, sind sie super.
              [
              | Versenden | Drucken ]
      0
      Von Jasager am Mo, 18. Mai 2009 um 21:14 #
      Leider ist die Kernel-Crew doch recht serverorientiert, Desktopkisten und deren Erfordernisse spielen dort eine eher untergeordnete Rolle.

      Für die kommenden CPUs mit integrierter Grafikeinheit wüsste ich neben Multi-Monitor-Setups auf Anhieb eine Anwendung, wo man sich mal innovativ zeigen könnte: Stromsparen

      Nvidia hat es unter dem Namen Hybrid-Power vorgeführt, bei entsprechendem Nvidia-Chipsatz mit integrierter GPU und Windows Vista konnten bestimmte dezidierte Grafikkarten (z.B. 9800GTX) im Desktopmodus abgeschaltet werden. Den Desktopkram erledigte dann die Chipsatz-GPU, das stromfressende 3D-Monster wurde nur für Spiele und 3D-Anwendungen geweckt. Durchgesetzt hat sich das natürlich nicht, nur Vista und nur Nvidia-Chipsätze mit ausgewählten Grafikkarten, das war wohl etwas viel Abschottung auf einmal.

      Hier wäre es schön, wenn man einen offenen Standard etablieren könnte, die dezidierten Grafikkarten werden in der heutigen Form sowieso verschwinden, sie werden entweder als reine GPGPU-Hardware ohne eigene Grafikausgabe weiterexistieren (Revenge of the MPEG-Decoder Cards... LOL) oder gleich vollends mit kommenden CPUs verschmolzen. Bis letzterer Fall eingetreten ist, wäre etwas wie Hybrid-Power als offener Standard ein Segen. Das Ganze zunächst unter Linux einzuführen würde sogar Sinn machen, da Microsoft sich dagegen sperrt und das Windows-Treibermodell das Umschalten des Treibers im laufenden Betrieb derzeit nicht erlaubt.

      [
      | Versenden | Drucken ]
      • 0
        Von Niels P. am Di, 19. Mai 2009 um 00:38 #
        Das gibt es auch von ATI/AMD aber leider besteht keine nachfrage von den Kunden und die Kombinationen sind derzeit noch mager.
        [
        | Versenden | Drucken ]
        • 0
          Von Jasager am Di, 19. Mai 2009 um 03:39 #
          Das wäre mir neu, von ATI gibt es nur die Möglichkeit, die lahme Chipsatzgrafik mit einer lahmen LowEnd-Karte zu einem Crossfire-Gespann zu verbinden. Abschalten der Grafikkarte geht nicht, ansonsten Link!
          [
          | Versenden | Drucken ]
          • 0
            Von thebohemian am Di, 19. Mai 2009 um 10:35 #
            Doch, das hat mein Kollege in seinem Lenovo-Laptop. Unter GNU/Linux läßt sich jeweils eine Karte benutzen, indem per Kernelparameter die eine oder andere Karte aktiviert wird. Bei dem proprietärem Betriebssystem lässt sich, wie von jemand anderes erläutert, im laufenden Betrieb umschalten. Aber wie immer halten sich die Firmen bedeckt mit Spezifikationen zum Ansprechen dieser Funktionen. Ist ja sicher auch der heilige Gral der Computertechnik und wir freien Softwarepeoples sind einfach nicht würdig so etwas nutzen zu dürfen. Scheissvereine!
            [
            | Versenden | Drucken ]
            • 0
              Von Hiebu am Di, 19. Mai 2009 um 18:17 #
              Nur unter GNU/Linux? Also bei mir gehts auch unter Busybox/Linux.
              [
              | Versenden | Drucken ]
              • 0
                Von EeGoh am Di, 19. Mai 2009 um 18:19 #
                Jepp, vor wenigen Jahren war die Notation GNU/Linux noch valide, mittlerweile ist sie aber obsolet, seitdem man komplette unixoide Systeme (insbesondere Linux) ohne jedweder GNU-Programme aufsetzen kann.
                [
                | Versenden | Drucken ]
        0
        Von Neuer am Di, 19. Mai 2009 um 11:25 #
        Hallo Du,

        denkst Du, dass jemand wirklich auf seinem Desktop den Monitor über USB anschliessen will? Das ist doch quasi _nur_ geeignet für Server und bestenfalls Drittmonitore am Desktop.

        Na, aber mal sehen, ob hier Linux ein Pionieer sein kann. :-)

        Gruss,
        Kay

        [
        | Versenden | Drucken ]
        0
        Von nahcei am Di, 19. Mai 2009 um 18:21 #
        Sowas gibt es auch von ARM. Sehr interessant das ganze. Damit sind angeblich HD-Filme trotz niedriger Taktung der CPU kein Problem mehr.
        [
        | Versenden | Drucken ]
      0
      Von Quoh am Di, 19. Mai 2009 um 18:15 #
      Warum wird 2010 alles anders bzw. besser sein? So schnell (für freie Software ist das eine extrem kurze Zeit) wird sich nicht viel ändern. Zum Beispiel Ubuntu, seit Jahren sagen die, dass bei der nächsten Version die UI komplett überarbeitet und viel benutzerfreundlicher ist. Was ist geschehen? Seit Version 8.10 gibt es keine wirklichen Innovationen mehr. Schade eigentlich, denn Ubuntu konnte schon viele Leute in die Linux-Welt verhelfen.
      [
      | Versenden | Drucken ]
      0
      Von phnord am Mi, 20. Mai 2009 um 12:16 #
      Mhh...

      Schon vor Jahren haben wir Multiseat Systeme (bis zu 12 Seats) mit XFree86 und Debian raus gebracht.

      Das neue ist nicht das Multiseat, sondern die Übertragung der Signale über USB. Das ist für industrielle Anwendungen allerdings total uninteressant, sondern lediglich "mal eben" für eine Präsi gut, oder wenn man mal eben schnell einen Monitor brauch.

      Ich hoffe dass diese Technik weiter entwickelt wird. Mit den neuen AMD-CPUs mit integrierter GPU könnte ich mir so einige interessante Szenarien vorstellen...
      Aber das wird wohl frühestens in 3 Jahren was.

      [
      | Versenden | Drucken ]
0
Von Erik am Mo, 18. Mai 2009 um 20:44 #
So geht das, ganz große Klasse.


lg
Erik

[
| Versenden | Drucken ]
0
Von Pffft... am Mo, 18. Mai 2009 um 21:22 #
Grundproblem ist, dass die "kleinen Geräte" zu langsam sind, um so viele Bilddaten ruckelfrei durch die Gegend zu schieben. Ausgelegt sind die Dinger z.B. für 640x480 Punkte. Schon 1024x768, eine heutzutage lächerlich geringe Auflösung, bedeutet die ca. 3-fache Datenmenge, die im Speicher umgeschaufelt werden muss. 1600x1200 Pixel wären schon das 6,25-fache.

Wenn überhaupt bieten sich solche Monitore für Systeme an, die sehr viele Screens ansteuern müssen, z.B. Infoterminals. Wenn über die USB-Schnittstelle auch noch ein Touchscreen angeschlossen wäre, wäre das sicher sinnvoll. Letztlich ist das aber eine Preisfrage, denn irgendwo fangen auch die X-Terminals mit Ethernetanschluss an, die sich mit Linux-Geräten ganz treiberlos und unkompliziert verbinden lassen.

[
| Versenden | Drucken ]
  • 0
    Von Crass Spektakel am Mo, 18. Mai 2009 um 23:52 #
    Wo ist das Problem? Schon mein Amiga1000 hatte einen Monitor mit 1024x800 und konnte ihn recht flüssig bedienen. Das brauchte auch nur 200kByte RAM und das konnte ein 7Mhz/16Bit Rechner in ca. 100 bis 200ms Sekunden komplett bearbeiten. Jede OMAP/ARM/MIPS-embedded-CPU hat zehnmal mehr Rechenleistung und RAM.

    Und wer jetzt sagt "Amiga 1000 mit Grafikkarte?" - der Monitor hatte einen Framebuffer integriert, war extrem lange nachleuchtend (50ms für Leuchthalbierung), 1024x800/vier Graustufen, 63hz, 15 Zoll und absolut flimmerfrei, stammte von CBM und hies A2024 und wurde für 300-400DM verkauft.

    [
    | Versenden | Drucken ]
    • 0
      Von Pffft... am Di, 19. Mai 2009 um 00:04 #
      Hmmja. 4 Graustufen (2 Bit) versus 32 Bit oben im Text. Ok, für übliche Farb-TFTs reichen auch 18 Bit, aber selbst das wäre 9mal so viel Daten wie in deiner Rechnung. Außerdem entsprechen 200ms gerade mal 5 Bildern pro Sekunde, was genau dem herumstottern entspricht, das ich beschrieben habe.
      [
      | Versenden | Drucken ]
      0
      Von thomasg am Di, 19. Mai 2009 um 00:27 #
      1600H*1200V*16bit*30Hz(fps) = 878 Mbit/s
      1600H*1200V*24bit*60Hz(fps) = 2.6 Gbit/s
      USB2.0 = 480 Mbit/s (brutto) bzw. <400 Mbit/s netto.
      <400 Mbit/s ^~ 1600H*1200V*8bit*24Hz(fps)

      Wie man sieht ist Rechenleistung nicht das Problem, wie du sagst schafft das jede vernünftige CPU locker in Software (bei so hohen Auflösungen bei ARM zumindest ARM11).
      Um also einen solchen USB-Bildschirm halbwegs vernünftig nutzen zu können muss man starke Kompromisse in der Grafikleistung eingehen, oder aber - und ich vermute genau das wird bei den USB-Displays gemacht - die Bilddaten komprimieren und im Display selbst dann neben USB-Controller einen Bildprozessor oder DSP zum dekomprimieren sowie eigenen Framebuffer und Displaycontroller verwenden.
      Allerdings würde das bedeuten, dass der Treiber des Displays einiges an Overhead und dadurch Last auf der Host-CPU macht, wodurch Rechenleistung wieder zum Problem wird.

      [
      | Versenden | Drucken ]
      • 0
        Von Erik am Di, 19. Mai 2009 um 07:24 #
        <400 Mbit/s ^~ 1600H*1200V*8bit*24Hz(fps)
        Allerdings würde das bedeuten, dass der Treiber des Displays einiges an Overhead und dadurch Last auf der Host-CPU macht, wodurch Rechenleistung wieder zum Problem wird.
        Achwo. 24fps sind fast PAL. Wenn man dann noch einen halbwegs intelligenten Treiber hat, weiss der, welche Bildinhalteseit der letzten Übertragung invalidiert wurden. Dann überträgst Du zeilenweise/spaltenweise das Bild über die Leitung und schickst für unmodifizierte Zeilen/Spalten einfach nur ein Zeilensync/Spaltensync. Wenn Dein Bildinhalt nicht gerade mit 100Hz flackernde Vollfarbwechsel sind, kommst Du damit in nahezu jedem gängigen Szenario zu einer deutlich höheren Framerate.

        Wenn Du dann noch ein zeilenweises Interlacing oder ähnliche Verfahren anwendest, wird die ganze Situation noch um einiges entspannter. Und an Host-CPU kostet das mit Sicherheit nichts relevantes.


        lg
        Erik

        [
        | Versenden | Drucken ]
        • 0
          Von thomasg am Di, 19. Mai 2009 um 15:24 #
          Wir reden hier nicht von Filmübertragung wo man von konstanter Bildrate ausgeht und auch sonst noch tricksen kann.
          Es geht hier um Computermonitore, die 24Hz waren nur das niedrigste erträgliche Maß das in Frage käme.
          Da es hier allerdings um Interaktivität geht, also nicht um eine normale Bildfolge sondern Interaktion des Anwenders und Reaktions am Display funktionieren Filmtricks nicht. Interlacing kommt schon gleich gar nicht in Frage.
          [
          | Versenden | Drucken ]
          • 0
            Von Erik am Di, 19. Mai 2009 um 17:21 #
            > Da es hier allerdings um Interaktivität geht
            Das Problem bei Interaktivität ist das gleiche wie bei maximaler Framerate: Du musst so schnell wie möglich einen Frameinhalt übertragen. Da Nutzerinteraktion in der Regel einer Desktopanwendung heisst, dass sich nur Teilbereiche des Bildschirminhalts ändern, kann man, wenn man einen Bildwiederholspeicher auf Monitorseite hat, sich darauf beschränken, diese Teilbereiche zu übertragen. Im Idealfall ist dann ein Frame binnen kürzester Zeit vollständig.

            > funktionieren Filmtricks nicht
            Das sind doch keine Filmtricks. Das ist eine Lösung für die Frage, wie man einen Bildpuffer schnellstmöglich mit einem zweiten abgleicht: Durch Reduktion redundanter Informationen.

            > Interlacing kommt schon gleich gar nicht in Frage.
            Aber natürlich. Da das Auge bei 24 Hertz nicht in der Lage ist, den Inhalt zu erfassen, könnte man durch Interlacing für eine noch kürzere Reaktionszeit sorgen, während der eigentliche Inhalt dann eben ein Halbbild später erst erfassbar ist.


            lg
            Erik

            [
            | Versenden | Drucken ]
            • 0
              Von thomasg am Di, 19. Mai 2009 um 18:22 #
              Und wieder zitierst du Funktionalität gängiger moderner Videocodecs: Erfassung unveränderter Daten und Reduktion der Datenmenge dadurch ist allerdings wiederum sehr rechenaufwändig und lässt sich hier kaum anwenden. Immerhin bedeutet das on-the-fly-encoding bei einer Bildgröße von hier 1600x1200, das bringt selbst eine sehr viel schnellere CPU in's schwitzen (und ich rede hier auch von simpleren Codecs, nicht von High-End wie h264).

              Zudem muss auch das hier als Filmtrick gelten, es ist zwar machbar es auch für die direkte Bildübertragung zu verwenden, allerdings kann man hier nicht davon ausgehen, dass es die Datenrate konstant so weit reduziert, dass eine Übertragung bei einem stark limitierten Bus immer funktioniert.
              Selbst bei Filmen geht man nicht davon aus, weswegen man bei Streamung und Co. zu noch drastischeren Methoden wie Framedropping greifen muss.

              Dass 24 Hz die Limits des Auges sind ist ein weitverbreiter Irrglauben. In der Filmproduktion wird viel Zeit und Know-How aufgewendet um schon beim Filmen (aber vor allem Schnitt und sonstiger Bearbeitung) zu verhindern, dass die gewünschte 24p Produktion optisch wahrnehmbar ist. NTSC nutzt gar 30p und als kleinen optischen Trick 60i, da die Grenzwerte damit weit weniger Problematisch sind. Das Auge aber selbst hier nicht am Ende angelangt, selbst 50 Hz können hier negativ wahrgenommen werden (selbstverständlich unter bestimmten Vorraussetzungen), weswegen 60 Hz allgemein als Mindeststandard gelten.

              [
              | Versenden | Drucken ]
              • 0
                Von Johkai am Di, 19. Mai 2009 um 18:30 #
                Inwiefern unterscheidet sich die Wahrnehmung in Bezug auf den Hz-Wert? Die Hz geben doch den Bildaufbau/s an?!
                [
                | Versenden | Drucken ]
                0
                Von Erik am Di, 19. Mai 2009 um 18:57 #
                Erfassung unveränderter Daten und Reduktion der Datenmenge dadurch ist allerdings wiederum sehr rechenaufwändig und lässt sich hier kaum anwenden.
                Der PC-Treiber weiß doch, welche Graphikoperationen auf seinem Buffer ausgeführt wurden, seitdem er zum letzten mal Daten übertragen hat. Zur Information, welche Zeilen dadurch invalidiert wurden, ist nur noch ein kleiner Schritt.

                Zudem muss auch das hier als Filmtrick gelten, es ist zwar machbar es auch für die direkte Bildübertragung zu verwenden, allerdings kann man hier nicht davon ausgehen, dass es die Datenrate konstant so weit reduziert, dass eine Übertragung bei einem stark limitierten Bus immer funktioniert.
                Muss es auch nicht. Wie wir festgestellt haben, ist bei der Übertragung von Vollbildern eine Framerate nahe PAL möglich. Da das DisplayLink-Empfangsgerät (der Monitor) einen separaten Empfangspuffer haben muss, aus dem es die Darstellung der Daten auf dem Bildschirm realisiert, reduziert sich das Problem auf die Latenz zwischen Aktion und Reaktion.

                Selbst bei Filmen geht man nicht davon aus, weswegen man bei Streamung und Co. zu noch drastischeren Methoden wie Framedropping greifen muss.
                Der typische Anwendungsfall eines Desktopmonitors sind halt nicht Vollfarbwechsel bei 25 fps. Ein einfacher Algorithmus wie oben beschrieben würde dafür sorgen, dass nur in den seltensten Fällen mehr als ein paar zig Zeilen pro Image übertragen werden müssten, bei sehr niedriger Latenz.
                Der Versuch, Videostreams in hoher Qualität über die USB-Leitung an den Monitor zu schicken, würde natürlich mit Framedrops quittiert werden, allerdings ebenfalls nie unterhalb von 25fps und daher kaum wahrnehmbar. Wer mehr braucht, muss eben auf USB 3.0 warten.


                lg
                Erik

                [
                | Versenden | Drucken ]
              0
              Von Chiqu am Di, 19. Mai 2009 um 18:28 #
              > Das sind doch keine Filmtricks. Das ist eine Lösung für die Frage, wie man einen Bildpuffer schnellstmöglich mit einem zweiten abgleicht: Durch Reduktion redundanter Informationen.
              Wird nicht dadurch das Bild unscharf? Oder werden doppelte Zeilen gelöscht? Wie funktioniert das genau?
              [
              | Versenden | Drucken ]
              • 0
                Von Erik am Di, 19. Mai 2009 um 19:14 #
                Denkbar ist folgende Vorgehensweise:

                Du hast zwei Geräte, die über DisplayLink miteinander kommunizieren. Jedes dieser Geräte hat zwei separate Bildpuffer plus einen Lese- und einen Schreibpointer.

                Der Sender (der Treiber auf dem Host-PC) arbeitet ständig Zeichenoperationen der Anwendungen auf dem ersten Puffer ab. Beginnt ein Übertragungszeitfenster, hängt der Treiber den Schreibpointer für die Zeichenoperationen auf den zweiten Puffer und den Lesepointer für die Datenübertragung auf den ersten Puffer und beginnt, die Daten des ersten Puffers über die Leitung zu übertragen. Wenn er damit fertig ist und das nächste Übertragungsfenster beginnt, werden die Pointer wieder zurückgehängt und die Prozedur beginnt von vorn.

                Der Empfänger (die Logik im Monitor) arbeitet ständig Leseoperationen ab, um in hoher Frequenz die Darstellung auf dem Bildschirm zu gewährleisten. Kommt ein Dateneingangsinterrupt von der USB-Schnittstelle, beginnt er, Daten in den zweiten Puffer zu lesen. Ist die Übertragung eines Frames fertig, hängt er die Pointer um. Die Darstellung auf dem Bildschirm wird dann aus dem jetzt aktualisierten Puffer gewährleistet.

                Aufgrund dieser Sende- und Empfangspuffer kann man nicht nur die ungestörte Zeichnung und Darstellung während der Übertragung sicherstellen, sondern man kann sich auch darauf konzentrieren, nur die Zeileninhalte zu übertragen, die sich tatsächlich geändert haben. Für alle anderen Zeilen sendet der Host-PC einfach ein "leeres" Zeilensynchronisationssignal, ohne vorher Daten gesendet zu haben. Der Empfänger inkrementiert dadurch einfach seinen Zeilenzähler und lässt ansonsten die Daten der vorigen Zeile im Puffer unberührt.


                lg
                Erik

                [
                | Versenden | Drucken ]
        0
        Von Schlaumischlumpf am Do, 21. Mai 2009 um 13:05 #
        Um also einen solchen USB-Bildschirm halbwegs vernünftig nutzen zu können muss man starke Kompromisse in der Grafikleistung eingehen

        Kein Problem. USB 3 steht doch vor Tür! 2-4 GBit! Prototyp lief (vor ein paar Monaten) unter Linux :p
        Soweit ich mich erinnern kann, war es eine Frau...
        Oh Shit, mir fällt gerade auf, das Ding ist ja schneller als der FSB (oder alles Andere) von meinem Rechner, ups! ...serielle Schnittstellen dringen in Galaxien vor, die nie zuvor ein Bit gesehen hat ;)

        [
        | Versenden | Drucken ]
      0
      Von taejah am Di, 19. Mai 2009 um 18:24 #
      Immer häufiger liest man hier von Amigas. Stamme leider nicht aus der Zeit, deshalb meine Frage: Was war/ist an dem Gerät so innovativ? Soweit ich weiß, setzt es noch niemals auf freie Software.
      [
      | Versenden | Drucken ]
      • 0
        Von Erik am Di, 19. Mai 2009 um 20:33 #

        • Das Hardwaredesign mit den Custom Chips, die Aufgaben bei Grafik, Sound, Interrupts, Timing, Blitting usw. übernehmen und damit die CPU entlasten.
        • ein Bussystem mit Autokonfiguration (variabler Verteilung von Interrupts und Registeradressen)
        • grafisches Betriebssystem im Kickstart-ROM, der Rest (inklusive einfacher Anwendungen) auf einer einzigen Diskette
        • preemptives Multitasking mit Time Slice Verfahren und Prozessprioritäten
        • ausgezeichnete Grafik- und Multimediafunktionen mit Sprachausgabe, der CDTV war ein vollwertiges Multimediasystem für Heimanwendungen (1991!!)
        • innovative Softwarekonzepte (Commodities, ARexx, DataTypes, UNIX-ähnliche Shell, ...)

        Alles weit seiner Zeit voraus, innovativ und pfeilschnell. Leider begleitet von einem tödlichen Marketing, der Verniedlichung im Homecomputersegment für Spieler und einer Marktmacht von IBM und Microsoft, der man einfach nicht gewachsen war.


        lg
        Erik

        [
        | Versenden | Drucken ]
        • 0
          Von taejah am Di, 19. Mai 2009 um 20:52 #
          Achso, das erklärt Einiges. Danke dafür.

          Interessant finde ich, dass das System trotz der (aus heutiger Sicht) ,,schlechten'' Hardware so gut lief. Komisch ist doch, dass bei immer schneller werdender Hardware, die Programme langsamer werden... Wieso hält man nicht an den alten Konzepten fest?

          [
          | Versenden | Drucken ]
          0
          Von Hinterfrager am Do, 21. Mai 2009 um 23:00 #
          Hm Erik, kann es sein, daß Du Dir selbst Fragen stellst, um sie dann "großartig" beantworten zu können?
          [
          | Versenden | Drucken ]
          • 0
            Von Erik am Fr, 22. Mai 2009 um 11:40 #
            > Hm Erik, kann es sein, daß Du Dir selbst Fragen stellst
            Nein. Sowas käme mir auch nicht in den Sinn. Aber Du solltest mal darüber nachdenken, warum Du auf sowas kommst. ;-)

            > um sie dann "großartig" beantworten zu können?
            Falls an den Antworten etwas nicht in Ordnung sein sollte, korrigiere doch einfach.


            lg
            Erik

            [
            | Versenden | Drucken ]
0
Von Lord am Mo, 18. Mai 2009 um 22:12 #
Also ich habe schon vor ein paar Monaten ein Multihead Multidisplay Setup unter Linux aufgebaut, das unter anderem auch einen Monitor an USB Grafik nutzt dazu haben wir neben einer Quadro einen:

http://tinyurl.com/qvalrl

angeschlossen. Das coole ist es laufen bei meiner Konfiguration 3 Monitore mit 2 KDEs (KDE mit Xinerama + KDE normal) die Maus lässt sich von Links nach rechts über alle 3 Monitore bewegen von einem KDE auf das andere :-)

[
| Versenden | Drucken ]
  • 0
    Von Brendo am Di, 19. Mai 2009 um 08:19 #
    Hab ich kürzlich auch gemacht. Allerdings taugt das nicht recht, da man keine Applikationen vom einen zum anderen KDE schieben kann.

    Bei Xinerama mit 3 Monitoren in einem Display sind mir dann aber alle Applikationen sofort gecrasht, also auch jeder beliebige Windowmanager (auch wenn X und der Mauszeiger durchaus funktioniert haben).

    [
    | Versenden | Drucken ]
    • 0
      Von haha am Di, 19. Mai 2009 um 08:42 #
      > Allerdings taugt das nicht recht, da man keine Applikationen vom einen zum anderen KDE schieben kann.

      Das ist meineserachtens xorg-Konfigurationssache. Da habe ich bei mir extra so eingerichtet.
      Der Vorteil ist, die Applikationen werden auf dem KDE ausgeführt, auf dem sie gestartet weerden...

      [
      | Versenden | Drucken ]
      0
      Von Lord am Di, 19. Mai 2009 um 17:53 #
      >>Hab ich kürzlich auch gemacht. Allerdings taugt das nicht recht, da man keine Applikationen vom einen zum anderen KDE schieben kann.

      Ja ich benötige das aber so, da diese USB Adapter keine ordentliche 3D Beschleunigung haben, wir aber auf 2 Monitoren mit der Quadro hohe 3D Leistung benötigen und auf dem zweiten KDE respektive 3. Monitor eine Kontrolleinheit am laufen haben, bei der keine Beschleunigung nötig ist:-)

      [
      | Versenden | Drucken ]
      • 0
        Von GooK am Di, 19. Mai 2009 um 18:35 #
        Interessant zu wissen wäre ja, ob überhaupt eine gute 3D-Performance erreicht werden kann. KDE ist doch sehr ressourcenintensiv (und funktioniert ohne Direct Rendering heutzutage nicht mehr so schnell wie vor 10 Jahren, leider).
        [
        | Versenden | Drucken ]
    0
    Von siyman am Di, 19. Mai 2009 um 08:22 #
    Jetzt bin ich aber stutzig. Was für Hardware nutzt du denn genau? Ich hab hier nen R70 von Samsung mit nVidia G84 8600m GS und damit ein internes Display sowie VGA und HDMI Aschluss. Wie viele Monitore kann ich gleichzeitig ansteuern? Richtig, lediglich 2, egal in welcher Konfiguration. Liegt angeblich an den nur verbauten zwei RamDACs - was das ist, hab ich nicht mehr recherchiert, wichtig war ja nur, ob es geht.
    Solche SVGA-Adapter hatte ich vor einem Jahr auch schon mal im Fokus, dachte mir jedoch, dass ja die Ausgabe auch via Grafikhardware gehen muss - und wie soll ich dann einen weiteren Monitor ansteuern, wenn es schon über eingebaute Schnittstellen nicht geht? Gibts dazu irgendwelche Informationen, funktioniert das dann via GPU oder wie kann man sich das vorstellen?
    Über Informationen wär ich echt dankbar, ich vermisse einen dritten Monitor ;c)
    [
    | Versenden | Drucken ]
    • 0
      Von thebohemian am Di, 19. Mai 2009 um 10:43 #
      Das vorgestellte Modul ist IMO ein "USB2VGA"-Adapter. Drin steckt eine Grafikkarte von SIS. Für das Ding fühlt sich ein Kernelmodul namens sisusbvga zuständig.

      Die DisplayLink-Geräte scheinen mir einen leicht anderen Focus zu haben. Da gibt die Möglichkeit an ein DL-Gerät mehrere Monitore anzuschliessen. Für den Rechner kann das dann wie ein Bildschirm aussehen aber auch wie mehrere, wenn das gewünscht ist. Das hat sich zumindest beim Lesen der API Spec von libdlo für mich so ergeben.

      [
      | Versenden | Drucken ]
    0
    Von Kevin Krammer am Di, 19. Mai 2009 um 12:17 #
    Also ich habe schon vor ein paar Monaten ein Multihead Multidisplay Setup unter Linux aufgebaut, das unter anderem auch einen Monitor an USB Grafik nutzt...

    Hat mich auch gleich stutzig gemacht, weil ein Freund von mir auch schon seit Jahren sowas im Einsatz hat.

    Ich denke der Titel des Artikels müsste eher in Richtung "USB-Monitore von DisplayLink..." gehen, d.h. darauf hinweisen, dass es um Monitore einer bestimmten Firma geht, die bisher nicht unterstützt wurden.

    [
    | Versenden | Drucken ]
    0
    Von georg am Di, 19. Mai 2009 um 13:50 #
    Interessant, hab mir das Ding von delock mal angesehen, was natürlich sofort auffällt ist, daß es offiziell nur für Windows Treiber gibt.

    Wie läuft das bei dir?

    Und, was mich am meisten interessiert, funktioniert das dann auch von Linux aus wenn ich einen Projektor ansteuern will?

    Danke, Georg

    [
    | Versenden | Drucken ]
    • 0
      Von Lord am Di, 19. Mai 2009 um 17:58 #
      Also bei der eingesetzten Suse 10.3 sind alle Treiber für den delock Adapter bereits dabei, man muss lediglich per Hand die xorg.conf anpassen, wenn man so eine spezielle Konfig haben möchte, dass kann kein config Tool das ich kenne.

      Projektor oder Monitor ist ganz egal, läuft alles über den Standard VGA Anschluss.

      [
      | Versenden | Drucken ]
      • 0
        Von aeCu am Di, 19. Mai 2009 um 18:40 #
        Klingt kompliziert. IMHO sollten wir schon vor Jahren von xorg.conf rid geworden sein. Das ist viel zu umständlich, wenn kleine Änderungen benötigt werden.

        Besser noch waere, X.org einzustellen und alles zum Kernel nach KML portieren, sodass wir alle Wayland nutzen könnten.

        [
        | Versenden | Drucken ]
        • 0
          Von Lord am Di, 19. Mai 2009 um 22:06 #
          >>>Klingt kompliziert.

          Weitaus einfacher als mal unter Windows die Nvidia Treiber zu überreden grundsätzlich ein Signal aus der Karte zu senden, auch wenn kein Monitor direkt angeschlossen ist, betrifft GF ab 8000. Ab der 8000er Serie sind die Karten so dämlich und schalten den Monitorausgang z.B. dann ab, wenn ein KVM Switch dran hängt und man nicht gerade die Karte auf den Monitor geschalten hat, ändern kannst du das Ganze dann nur, wenn du in der Treiber inf Datei die richtigen Optionen setzt, dazu musst du diese Datei und den enthaltenen Beispielen erstmal studieren und ohne Doku draufkommen:-)

          Das schöne unter Linux ist, es ist ja alles in xorg dokumentiert. Ich hab mir das ja auch nicht aus den Fingern gesaugt. Wer sowas spezielles benötigt, der sollte auch in der Lage sein, sowas zu konfigurieren.

          [
          | Versenden | Drucken ]
          • 0
            Von aeCu am Mi, 20. Mai 2009 um 02:37 #
            Ich stimme dir generell schon zu. Mit X.org komme ich persönlich auch bestens zurecht, allerdings ist es doch umständlicher als in einem Menü die entsprechenden Optionen zu setzen. Allerdings muss man sich bei X.org etwas einarbeiten (u.a. Google-Recherche nach verfügbaren Optionen etc.) Einem Laien würde ich es keinesfalls zumuten. Daher wäre es doch sinnvoller, zusätzlich noch eine grafische Methode anzubieten bzw. die Konfiguration etwas zu erleichtern?
            [
            | Versenden | Drucken ]
            • 0
              Von Lord am Mi, 20. Mai 2009 um 11:01 #
              >>>Einem Laien würde ich es keinesfalls zumuten. Daher wäre es doch sinnvoller, zusätzlich noch eine grafische Methode anzubieten bzw. die Konfiguration etwas zu erleichtern?

              Eine Standardkonfiguration erstellt xorg ja schon automatisch, Nvidia und Ati bringen ja ihrerseits schon die entsprechenden Config Tools mit, die 99% aller User zufrieden stellen sollten. Was mich etwas nervt ist z.B., dass man die Farbeinstellungen von Windows und Linux nicht austauschen kann, wobei hier auch wieder Linux vorteilhafter ist, ich kann hier die Nvidia Settingsdatei einfach auf nen anderen Rechner kopieren und sie automatisch beim Login nutzen.

              [
              | Versenden | Drucken ]
0
Von Thorsten am Mi, 20. Mai 2009 um 11:32 #
Was ? Gemeinsam mit Novell ?

Ich hoffe dieses "Klicki Bunti" bleibt aus Ubuntu raus

[
| Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung