graphlcd (base, vdr-plugin) touchcol branch (archiv)

naehere erlaeuterungen? fotos?
damit vielleicht andere einen 'plan' davon haben koennen, wo's spiesst?

screenshots kann man btw. bequem via sdl-treiber machen:
einfach in graphlcd anhaengen:

[test_sdl]
Driver=serdisp
Device=out:
Controller=sdl
Options=depth=1;width=128;height=64

und dann "test_sdl" verwenden bei -d

der touchcol-skin ist auch nicht wirklich auf skalierbarkeit ausgelegt sondern zieml. auf 320x240 hingearbeitet. sieht man auch an den einander ueberlappenden schriftzuegen.
am besten, du nimmst dir den default-skin als grundlage. der sollte viel besser skalieren.

sdl: da wird dann nicht auf ein physikalisches display ausgegeben, sondern auf der x11-oeberflaeche ein SDL-fenster aufgemacht, welches man dann mit einem screenshot-programm (z.b. ksnapshot) 'abfotografieren' kann. beispiele gibt es in diesem thread einige (fast alle bilder von mir).

news (graphlcd-base):

• Image/GraphicsMagick: use much more relieable sample() instead of scale() for scaling images:
  problems with distorted scaled icons/images or other display errors should now be history.
• monochrome images: fix monochrome bug in imagefile.c:
  bgcolor and color should be working again for monochrome icons/symbols
• improved relieability of eq()/ne()/gt()/lt()/ge()/le() if comparing 'mixture' of string / bool / value
• fixed a bug which could lead to an infinite loop under rare circumstances (if a content part contains a spare # without a variable name)
• permit and evaluate $( )$ expressions to enable direct embedding of functions in the content part of elements such as <text/>:
  eg: <text>$(add(#SomeVar,#SomeOtherVar))$</text>
  attention: $()$ is not verified (yet) when parsing the skin. if it contains syntactical errors, the unprocessed term will be displayed at runtime.
• clang can now be used instead of g++.
  'CXX=clang make' now compiles the whole graphlcd-base using clang.
• added support for fontconfig font name representations:
  eg.: <font id="FontInfo" url="fc:Sans Serif:bold:size=12"/>
  attention: specifying a size term (eg. 'size=12') is mandatory!

news (vdr-plugin-graphlcd):

• fixed a bug that has been introduced in a former update and rendered some services unusable

du verwendest ja dieses wiring:

Strobe (01)   nWR   (17)   (Write)
nSEL   (17)   R/S   (19)   (Register Select, C/D)
Line	(14)   nRD   (21)   (Read)

dann bitte auf das aendern des folgenden abschnittes beschraenken:

const unsigned char kWindowsWRHI = 0x00; // 01 / nSTRB
const unsigned char kWindowsWRLO = 0x01; //
const unsigned char kWindowsRDHI = 0x00; // 14 / nLINEFEED
const unsigned char kWindowsRDLO = 0x02; //
const unsigned char kWindowsCDHI = 0x00; // 17 / nSELECT
const unsigned char kWindowsCDLO = 0x08; //

(da brauchts dann auch keine mask. mit ein bisschen bool'scher algebra sollten die zeilen oben leicht angepasst werden koennen)
und deine version benoetigt noch eine zusaetzliche zusaetzliche signalschaltung (port->WriteControl() + nSleep())

der GU256X64_372-treiber ist leider noch immer nicht verifiziert ob er funktioniert nach der touchcol-umstellung .. (wenn er von keinem vermisst wird, wandle ich ihn in einen 355er um ...)
ich kann leider weder noch (372 vs. 355) testen (habe nur ein paar gu128x18 oder so herumliegen die noch auf ansteuerung warten ...)

nachtrag:

eigentlich sollten 372 und 355 zueinander kompatibel sein (lt. div. beitraegen im netz). kann es sein, dass du ein etwas laengeres kabel + schlechte abschirmung hast, so dass dein display die etwas schnellere ansteuerung (mit 3 statt 4 pegelschaltungen) nicht vertraegt? (ist nur geraten, aber ich habe ja selber schon viel mit solchen signalansteuerungen herumgespielt und da haengt es immer wieder mal von kabellaenge/schirmung/... ab).

hab das ganze mal am papier durchgespielt (testen kann ich wie gesagt das ganze nicht an einem display).

so wie's im bestehenden code fuer das windows-wiring definiert ist, kann's gar nicht gehen.

eventuell reicht eine kleine aenderung, und es sollte funktionieren (nicht vergessen: im graphlcd.conf Wiring=Windows setzen bei [gu256x64-372]):

alt:

const unsigned char kWindowsWRHI = 0x00; // 01 / nSTRB
const unsigned char kWindowsWRLO = 0x01; //
const unsigned char kWindowsRDHI = 0x00; // 14 / nLINEFEED
const unsigned char kWindowsRDLO = 0x02; //
const unsigned char kWindowsCDHI = 0x00; // 17 / nSELECT
const unsigned char kWindowsCDLO = 0x08; //

neu:

const unsigned char kWindowsWRHI = 0x00; // 01 / nSTRB
const unsigned char kWindowsWRLO = 0x01; //
const unsigned char kWindowsRDHI = 0x02; // 14 / nLINEFEED
const unsigned char kWindowsRDLO = 0x00; //
const unsigned char kWindowsCDHI = 0x00; // 17 / nSELECT
const unsigned char kWindowsCDLO = 0x08; //

(es werden nur die definitionen fuer RDLO und RDHI ausgetauscht. denn die koennen im vorliegenden code nicht stimmen. nehme an, dass der urspruengliche entwickler ausschliesslich mit standard-wiring getestet hat.)

ist dann zwar immer noch nicht sauber (eigentlich gehoeren bei den signalfolgen RDHI und RDLO ausgetauscht, aber das mache ich dann, wenn positive rueckmeldung von dir kommt.

bitte testen!

naja. die maske invertiert ja nur die signale. und davon gibt es in diesem fall 3 (/RD, /WR, C/D). die maske ist mit 11 angegeben = 1011. die null kannst du ignorieren, da parport 16 (INIT) nicht verwendet wird => mask = 1#11

und damit kannst du dann genauso die 6 HI/LO-folgen wie im originalcode hinbasteln.

warum das mit RDHI bzw. RDLO nicht funktioniert hat:
/RD (oder auch nRD geschrieben) ist active low (heisst, dass RD aktiv ist, wenn es auf 0 gesetzt ist. der parport invertiert auf pin 14 aber ebenfalls (weil auch dieser active low ist) -> dh will man, dass NICHT vom display gelesen wird (RD also nicht aktiv ist), muss man im code RD auf 0 setzen. RD = 0, parport pin 14 macht 1 daraus, 1 heisst: RD ist nicht aktiv.
weil aber RD im originalcode auf 1 gesetzt worden ist, konnte dein display mit windows-wiring nicht funktionieren, da dem display dadurch mitgeteilt worden ist: bitte vom display etwas auslesen!
beim standard-wiring ist dieser fehler deshalb nicht aufgefallen, weil sowohl RDHI als auch RDLO mit 0x00 definiert sind ...

anmerkung (der vollstaendigkeit halber):
eigentlich ist die beruecksichtigung von RD im code ohnedies ueberfluessig, da es sich sowieso nie aendert bei der ganzen ansteuerung. es wuerde daher ausreichen, RD 'hardwired' auf high zu ziehen (= direkt mit +5V (via vorwiderstand) zu verbinden). dann wuerde man mit 2 anzusteuernden signalleitungen im code auskommen ...
aber die 2 wirings haben sich nun mal so eingebuergert ...

ist im git. die definitionen selber waren korrekt, es waren nur die signalfolgen im code falsch (wie oben angedeutet). und das habe ich jetzt ausgebessert.
bitte nochmal testen, dann kann ich das gu256x64 in die liste der getesteten treiber aufnehmen.

wenn du mit den fonts in plugins/graphlcd/fonts auslangen findest: fein, ansonsten noch ein wenig warten (moechte in der doku noch ein paar fontconfig-beispiele inkl. moeglichkeiten fuer fall backs usw. hineinschreiben).

den skin bitte nicht nach dem treiber benennen (ein spezialisierter 256x64-skin wird auch fuer andere displays interessant sein). 'mentox' oder so wuerde sich anbieten. ausser du hast vor, meherer skins zu entwerfen

den skin entw. irgendwo downloadbar machen oder mir mailen. ich werde ihn dann ins GIT werfen (muss aber vorher noch ein paar dinge bereinigen (zb. symbols aus der skin-definition wegbringen)).