[Lcdproc] partially solved: hd44780: Datavision 40x4 display

[Dmitry E. Mikhailov]

Without dynticks and 300HZ kernel tick frequency the problem was solved. BU=
T=20
only for local lcdproc client. If I run lcdproc on another PC, I got the ve=
ry=20
same behaviour. Absolutely no idea, why, but that's it.

So I rebuilt the device according to 4bit schematic and it's working Ok.=20
Either locally or remotely. With and without dynticks and at any tick=20
frequency.=20

I'd like to say thanks to the developers.

I do believe that there's some cross-display timing issue in hd44780-winamp=
=20
driver. And I think we should recommend 4bit LCD connection mode to users i=
n=20
the readme file, not 8bit. On the hardware side 4bit connection looks most=
=20
timing-accurate, since all data is sent to the LCD simultaneosly by=20
programming 8bit data buffer. No delays on programming 'nINIT', 'nSEL', etc=
=20
bits of LPT port. Even in 4bit mode my 40x4 display is fast (timing=20
multiplier=3D1, delaybus=3Dfalse).

It should be mentioned in readme that RW pin of display should be grounded =
in=20
4bit mode if more than one display used. I had no success until I grounded=
=20
it.

On Saturday 22 September 2007 01:23:07 AM I wrote:
> The problem was DynTick kernel option as I though earlier. I rebuilt the
> kernel w/o dynticks and the display is working flawlessly. I'm going to
> confirm (I hope so) this report in several days - may be I'm just too luc=
ky
> today.
>
> If DynTicks are really a problem, developers could mention it in README. =
Or
> may be let's ask users if they have dyntick.
>
> P.S. dyntick is really a laptop option while LPT-display is not. But
> Fedora7 stock kernel 2.6.21 is dyntick-enabled. Someone could just 'forge=
t'
> building custom kernel for his/her server...
>
> P.P.S.  How many people have 40x4 displays (or two and more LCD's) and
> dynticks? The problem was only the second (part of) display...
>
> On Friday 14 September 2007 09:42:19 am I wrote:
> > Hi,
> > =A0=A0=A0=A0=A0=A0=A0=A0I'm a happy owner of Datavision DV40400 40x4 di=
splay,
> > HD44780-compatible, =A0
> > chipset is AFAIK "Samsung KS0066".
> > =A0=A0=A0=A0=A0=A0=A0=A0I wired the LCD to the LPT port, wiring is 8bit=
=2Dwinamp. As
> > display has actually two controllers, pin 17 of LPT is used as EN2.
> > RW-pin is also properly wired.
> > =A0=A0=A0=A0=A0=A0=A0=A0The display was used under M$Win2k for two year=
s (LCD-Smartie)
> > with no problem *on the same machine*. Now this server is Linux'ed: OS =
is
> > Fedora 7 with latest 2.6.22.6 kernel.
> > =A0=A0=A0=A0=A0=A0=A0=A0The display is working well under Linux if lcd-=
linux-0.12.5
> > driver is used.
> > But under LCDproc I got something strange.
> > =A0=A0=A0=A0=A0=A0=A0=A0Start LCDd. The display says on first two lines=
 something
> > like "HD44780 <CR>
> > 0x378". Start lcdproc. Screens start change. BUT I got one of these thr=
ee
> > behaviours:
> > =A0=A0=A0=A0=A0=A0=A0=A01)It works just as designed. Probability of thi=
s case is about
> > 1/30 (my
> > trial-and-error estimation)
> > =A0=A0=A0=A0=A0=A0=A0=A02)On the first (top) two lines info is displaye=
d just as
> > designed. Second two
> > lines are frosen and constantly show the info from the very first
> > lcdproc's screen. Probability =3D 1/3.
> > =A0=A0=A0=A0=A0=A0=A0=A03)Top two lines Ok. Second two lines show the i=
nfo from the first
> > lcdproc
> > screen on even "Screens: 0" from LCDd's screen *AND* this two bottom
> > lines are SCROLLED with the frequency of heartbeat. It's the most
> > probable case. Once I left LCD 'scrolling' for the whole night (didn't
> > shut down LCDproc),
> > but on morning is was working properly.
> > =A0=A0=A0=A0=A0=A0=A0=A0I get the same behaviour of LCD under LCDproc o=
n five PC's
> > tested. Kernels
> > were 2.6.21 (Fedora7 stock) and 2.6.22.* custom built. The server is AMD
> > AthlonXP (Palomino) 1800+ @ 1533MHz (not OC'd), VIA KT266A chipset,
> > 1x256MB DDR266, 'bus disconnect' northbridge power saving feature
> > enabled. Also tested on Intel P4 3GHz/512/800 (Northwood) socket 478 wi=
th
> > HT enabled, Intel P4 3GHz/??/800 socket 775 (with Speedstep).
> > =A0=A0=A0=A0=A0=A0=A0=A0As for me, this problem is related to LCD's tim=
ing. I tried all
> > of the LCDd.conf options. Increasing delay multiplier to 100 and
> > increasing lcdproc.conf delay to 10 and more increases the probability =
of
> > correct operation to about 1/3, but it stops working after several hour=
s.
> > I tried compiling LCDproc with 'gettimeofday' timing and is also makes
> > things better. I tried compiling it with 'IO delay' timing, but compili=
ng
> > fails pointing at C99 style in asm code. I tried passing C99 style opti=
on
> > to GCC (also edited asm code so it complies to earlier C89), but in both
> > cases it fails to find 'port' variable =3D can't try 'io delay' method.=
 I
> > tried adding artificial delays to timing code. It helps a bit but doesn=
't
> > solve the problem. Due to power saving mechanisms in CPU of machines i
> > tried the clock source is acpi_pm. When I set clock source to TSC, it
> > helps a bit. But the system time goes to hell then. It seems to me that
> > the problem is introduced
> > with 'dynticks' of 2.6.21+ kernels. OR, may be, LCDd makes low\no delay
> > when switching to the next LCD. May be, for this two-in-one LCD some
> > delay is required. I didn't check my dyntick theory as I don't really
> > want to mess with perfectly working kernels on servers until it's
> > *really* required. By the way, LCDvc shows absolutely correct 4-line
> > login page. So I guess
> > problem is related to frequent updating of the LCD.
> > =A0=A0=A0=A0=A0=A0=A0=A0Versions of LCDproc tested: 0.5.1, 0.5.2, 0.5-d=
evel (current).
> > =A0=A0=A0=A0=A0=A0=A0=A0Please help! I'd like to try increasing delay o=
f display
> > switching first...
> > Any ideas are welcome.