Hi,
du meinst die CPU hat viel zu tun dadran? Oder das glcd? Ersteres ist egal, da eh nur am langweilen, Letzteres ist natürlich sehr interessant, da dann ja sehr viele Daten zu übertragen sind!
Noch mal eine Frage, die in diesen Fred eher reingehört? Kann man Parallelport-Treiber-ICs des Displays irgendwie erkennen? Also wie lsusb bloss dafür?
mfG,
Stefan
Kann es ein das mein blinkender Doppelpunkt in der Uhrzeit oben links dann die Sache komplett verlangsamt wenn z.B. der Sendungsname scollt? Weil dann das dirty-Retangle unnötig aufgebläht wird.
Genau! Ich wust es schon immer: alles was blinkt ist schlecht. 
Kann man nicht in SetPixel das Pixel direkt zum Display schicken wenn es sich geändert hat?
Weiß nicht ob das so gewollt ist. Was ich so in den bestehenden Treibern gesehen habe, wird in SetPixel() nur gesammelt und in Refresh() ans Display übertragen.
Oder können hier nur grössere Bereiche in einen Rutsch gesendet werden und der Protokolloverhead für das Pixelweise setzen wäre zu groß?
Der Hack für das Pearl-Display hat einen Blit-Befehl mit dem man ein Recheck von Pixeln auf einen Rutsch überträgt.
du meinst die CPU hat viel zu tun dadran? Oder das glcd? Ersteres ist egal, da eh nur am langweilen, Letzteres ist natürlich sehr interessant, da dann ja sehr viele Daten zu übertragen sind!
Mag sein, dass sich die CPU freut wenn sie was zu tun hat. Aber ich hab in grauer Vorzeit auch mal Embedded-Entwicklung gemacht und wenn ich dann sowas sehe, zieht sich bei mir alles zusammen. Und mal eben einen zweiten Buffer von 320 x 240 Pixel x 2 bpp macht auch schon schlappe 150 KB zusätzliche unnötige Speicherbelastung.
Gruß
superelchi
wozu 2 buffer?
einer reicht vollkommen, dazu noch bounding box, was sich geaendert hat ('dirty region') und beim refresh nur das innerhalb der bbox uebertragen. fertig.
superelchi: vorsicht: c++ und entwicklung fuer embedded devices gemeinsam in einem satz und das universum koennte explodieren 
Keine_Ahnung: den blinkenden doppelpunkt wuerde ich bei einem display, das eine nicht gerade berauschende update-zeit hat, sowieso nicht verwenden. pfuscht auch in die bounding box hinein ( zb. scrolltext: im idealfall wird nur der bereich des textes uebertragen. der doppelpunkt wuerde das aber fast immer unnoetig vergroessern -> es ruckelt unnoetig). habe zwar noch nicht das pearl-display, aber ich kanns mir vorstellen (ein wenig erfahrung mit dem thema habe ich ja inzwischen ...).
ad PLUGIN_NAME_I18N vs. PLUGIN vs. 'graphlcd' fuer logging: ok. darueber kann man diskutieren. aber SICHER nicht so:
syslog(SOMEDEFINE" some string");
da kommt mir das grausen (auch wenns der pre-processor noch so erlauben wuerde).
wenn dann so:
syslog("%s: some string", SOMEDEFINE);
auch wenns ein klein wenig overhead ist, aber es ist zumindest sauber.
das customising v. default graphlcd-config ueber make-files: darueber kann man auch diskutieren. baue ich in etwas abgeaenderter form ein.
ad GRAPHLCDMULTI-hack: spaetestens bei mehreren verschiedenen serdisplib-basierenden displays wirst du aber da auf die grenzen stossen?
und bei zwei gleichen anderen ebenso. da muesste wohl mehr geaendert werden in graphlcd-[base/plugin].
und die verschiedenen packager wuerden so einen hack heiss lieben 
@SufaceCleanerZ:
wie soll der paralellport erkennen, welches display dran haengt? so zieml. kein display meldet sich auch nur irgendwie. ausser vielleicht ein ready made display module (usb, ...). auch wenn ein display (zb t6963c) einen rueckkanal hat, ist der in der regel nur dafuer da, dass ueber (natuerlich display-IC abhaengige) commands irgendwelche statusinformationen (displaychip empfangsbereit, ...) oder, wenns heiss hergeht, pixelinfos ausgelesen werden koennen.
bei den meisten displays in dieser klasse gibt es aber sowieso nur 'write only'.
Keine_Ahnung: den blinkenden doppelpunkt wuerde ich bei einem display, das eine nicht gerade berauschende update-zeit hat, sowieso nicht verwenden.
Jup, mal sehen wie sich das entwickelt, man kann ja auch ohne blinkenden Doppelpunkt leben
Evt. ist ne Userconfig im Skin, wo man generell allen überflüssigen bewegten Bling abschalten kann generell ne gute Idee
Alles anzeigenad PLUGIN_NAME_I18N vs. PLUGIN vs. 'graphlcd' fuer logging: ok. darueber kann man diskutieren. aber SICHER nicht so:
syslog(SOMEDEFINE" some string");
da kommt mir das grausen (auch wenns der pre-processor noch so erlauben wuerde).
wenn dann so:
syslog("%s: some string", SOMEDEFINE);
Ich hatte über beide Varianten nachgedacht, uns zum Schluss gewann der minimale Laufzeitvorteil Aber egal welche Variante. Schöner sieht die letzte natürlich aus.
ad GRAPHLCDMULTI-hack: spaetestens bei mehreren verschiedenen serdisplib-basierenden displays wirst du aber da auf die grenzen stossen?
und bei zwei gleichen anderen ebenso. da muesste wohl mehr geaendert werden in graphlcd-[base/plugin].
und die verschiedenen packager wuerden so einen hack heiss lieben
Jup, ist nicht wirklich sauber Das mit der serdisplib könnte man ja genauso hinmurksen wie die Base Libs. Dann sollten auch zwei serdispllib LCDs gleichzeitig gehen.
Aber nach den Änderungen hier kann man sich das wenigsten mal ohne Quellcodeänderungen hinhacken (ist dann ja nur Makefilekram).
Ist ja nicht nur wegen zwei realen Displays, man kann ja auch das normale haben und gleichzeitig ein SimLCD, dann kann man mal basteln ohne ständig die Konfig zu ändern. Oder man hat generell nen simLCD als Remote Display auf dem Notebook.
cu
wozu 2 buffer?
einer reicht vollkommen, dazu noch bounding box, was sich geaendert hat ('dirty region') und beim refresh nur das innerhalb der bbox uebertragen. fertig.
Sag das mal den anderen Treiberentwicklern. Etwa 1/3 der Treiber machts mit einem zweiten Buffer. Ich habs inzwischen auch ohne hingekriegt.
Ergebnis beim Bewegen des Cursors im Menü einen Menüpunkt runter: vorher: Anzahl geänderte Pixel = 76.800, nachher: Anzahl geänderte Pixel = 284.
Gruß
superelchi
Hi wastl,
würds gern testen, aber dazu bräuchte ich n Paket in easyvdr 0.9 oder ne gute Step by step Anleitung...
Tut das yavdr-Paket?
Zur Erkennung: ok, schade aber dachte ich mir schon...
superelchi: klingt cool, wäre das evtl. möglich, dass dus dann im t6963c auch änderst? Der ist ja doch etwas lahm im Refresh auch...
wastl: in der graphlcd.conf sind oben in der Liste der supporteten Treiber nicht alle drin, die unten stehen (bei 0.1.9), könnte ich mal ergänzen (oder in 0.3 geschehen?).
Und beim t6963c sollte nicht Standard der default sein, sondern Windows, da alle Anleitungen, die ich kenne, das nutzen!
mfG,
Stefan
superelchi: klingt cool, wäre das evtl. möglich, dass dus dann im t6963c auch änderst? Der ist ja doch etwas lahm im Refresh auch...
Im Treiber t6963c ist die Erkennung der geänderten Pixel schon drin - allerdings mit den 2 Buffern. Ergebnis sollte aber gleich sein (soweit ich das auf den ersten Blick sagen kann).
Gruß
superelchi
SurfaceCleanerZ: easyvdr/yavdr/wasweissichvdr: keine ahnung. ich verwende kein vorpaketiertes vdr-zeug.
Geht mir genauso
Gerald
nicht dass ich jetzt falsch verstanden werde: schoen, wenn sich leute die muehe machen, fuer andere, die einfach nur vdr verwenden wollen ohne sich naeher damit auseinander zu setzen, fertige distros machen.
nur: in der laufenden entwicklung und fuers testen setze ich da lieber auf das altbewaehrte 'configure / make / make install' (gut, configure entfaellt beim VDR ...).
mit dem 'gibt es das schon als paket'-denken kann man da halt nicht so schnell testen/entwickeln/...
wird ja hoffentlich compiler & co geben bei den div. vdr-distros? (kenne keine einzige selber, habe noch nie eine ausprobiert. bleibe (vielleicht eh als einziger weit und breit in der vdr-welt bei einer stinknormalen fedora-installation.
ausserdem nervt mich ein bisschen das doch etwas verbreitete und nervende distro-denken hier im forum. schon allein deshalb muss ich da etwas in opposition gehen
nur: in der laufenden entwicklung und fuers testen setze ich da lieber auf das altbewaehrte 'configure / make / make install' (gut, configure entfaellt beim VDR ...).
Exakt das Selbe mache ich auch. Nur aus einem debian/rules-File heraus und als Endergebnis habe ich dann das Paket. Vielleicht gehe ich es ja übertrieben professionell an, aber ich trenne Entwicklungs-Maschine von Test-Maschine und in einem Paket lässt es sich eben leichter Transferieren. Auch ist ein Debian-Source-Paket einem normalen Source-Archiv überlegen, weil es die verwendeten configure-Optionen und die genauen Abhängigkeiten zu externen Paketen konserviert. Deswegen entwickle ich auch meine eigenen kleinen Dinge immer in Paketen sobald es mindestens ein Makefile gibt. Wenn ich so Sourcen weitergebe, dann hat der Empfänger deutlich größere Chancen nach dem kompilieren das selbe Ergebnis wie ich zu bekommen. Das ist für einen einzelnen Entwickler natürlich nicht so wichtig.
Gerald
genau das meinte ich mit 'distro-denken'.
ein debian-source-paket KANN nicht besser sein als ein source-archiv, weil das source-archiv (wenn es gut gemacht ist) UEBERALL funktioniert (oder soll) und auch dafuer ausgelegt ist (bzw. sein soll). das debian-zeug (natuerlich auch RPM oder was auch immer) beruecksichtigt nur die abhaengigkeiten/voraussetzungen/... der jew. umgebung (distro,...).
Das verstehe ich nicht, das Debian-Source-Paket benutzt doch das selbe configure, wie du wenn du es per Hand machst? Deswegen kann ich doch meine Pakete sowohl auf x86,amd64 oder arm kompilieren. Was ich meine ist, dass
optionen wie --prefix, oder --withlib... drinstehen und es dem nächsten ermöglichen zu vergleichbaren Ergebnissen zu kommen.
dass sich im VDR-bereich 'configure' nicht breitgemacht hat, ist etwas anderes und hat nix mit obigen zu tun (und auch, dass der vorige maintainer fuer graphlcd-base keines eingefuehrt hat).
aber ich bekomme fast einen zorn wenn ich lese, dass es ein fertiges configure gaebe, aber dieses nicht contributed wird. DAS verstehe ich dann auch unter distro-denken, welches ich verabscheue.
Hier hast du mich jetzt völlig abgehängt, ich habe doch nie behauptet, dass wir ein configure für den vdr haben. Ich habe doch nur auf deinen Post geantwortet, dort hast du von configure gesprochen. Ich habe das ganz generell verstanden. Zu behaupten wir würden etwas nicht contributen, ist ein starkes Stück. Das empfinde ich als Beleidigung.
Gerald
./configure / make / make install => configure steht hier fuer autoconf.
wenn du schreibst du verwendest configure, dann verstehe ich als 'unix-mensch' (und nicht nur ich) autoconf. dem ist wohl nicht so -> missverstaendnis
Nein kein Missverständnis. Ich verstehe darunter das Selbe. Du schreibst generell du nimmst kein vorkompiliertes Zeugs. Genau wie ich, ich kompiliere auch selber, gleich in ein Paket. Du schreibst du nimmst lieber den bekannten Dreisatz ./configure; make; make install oder eben make; make install wo das configure fehlt, genau wie ich. Wenn ich schrieb ich nehme configure dann bezog ich das auf meine Arbeitsweise und nicht auf dein graphld-base, oder bezog sich deine Aussage nichts vorkompiliertes zu verwenden auch nur auf graphlcd-base und ansonsten nimmst du schon vorkompiliertes?
Gerald
Quoted
Wenn ich schrieb ich nehme configure dann bezog ich das auf meine Arbeitsweise
? das soll jemand ausser dir also verstehen?
Zusammen mit dem Teil des Satzes, den du nicht gequoted hast, denke ich schon, dass das verständlich ist, aber lass es man es führt ja zu nix.
Gerald
Sag das mal den anderen Treiberentwicklern. Etwa 1/3 der Treiber machts mit einem zweiten Buffer.
Muss mich hier mal selber korrigieren, wenns sonst keiner tut: das ist natürlich absoluter Blödsinn! Typischer Fall von Betriebsblindheit - war viel zu sehr mit meiner Dirty-Rectangle Sache beschäftigt. In den anderen Treiber werden nicht Pixelbereiche sondern einzelne Pixel an das jeweilige Display übetragen. Da ist der Einsatz eines Doppel-Buffers zum Rausfiltern der Pixel vollkommen in Ordnung. Also: große Entschuldigung an alle Doppel-Buffer Treiberentwickler! Ihr seid genial! Und natürlich ein dreifach donnerndes HELAU! für den Entdecker der Doppel-Buffers!
Gruß
superelchi
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
