LCDproc development and user support list

Text archives Help

[Lcdproc] Re: hd44780: Datavision 40x4 display - timing problem?

Chronological Thread 
  • From: sexandvodka AT (Dmitry E. Mikhailov)
  • Subject: [Lcdproc] Re: hd44780: Datavision 40x4 display - timing problem?
  • Date: Fri Sep 21 19:27:02 2007

The problem was DynTick kernel option as I though earlier. I rebuilt the=20
kernel w/o dynticks and the display is working flawlessly. I'm going to=20
confirm (I hope so) this report in several days - may be I'm just too lucky=

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 Fedora=
stock kernel 2.6.21 is dyntick-enabled. Someone could just 'forget' buildin=
custom kernel for his/her server...

P.P.S. How many people have 40x4 displays (or two and more LCD's) and=20
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 disp=
> 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-w=
inamp. 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 years =
(LCD-Smartie) with
> no problem *on the same machine*. Now this server is Linux'ed: OS is Fedo=
> 7 with latest kernel.
> =A0=A0=A0=A0=A0=A0=A0=A0The display is working well under Linux if lcd-li=
nux-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 s=
> like "HD44780 <CR>
> 0x378". Start lcdproc. Screens start change. BUT I got one of these three
> behaviours:
> =A0=A0=A0=A0=A0=A0=A0=A01)It works just as designed. Probability of this =
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 displayed =
just as designed.
> Second two
> lines are frosen and constantly show the info from the very first lcdproc=
> screen. Probability =3D 1/3.
> =A0=A0=A0=A0=A0=A0=A0=A03)Top two lines Ok. Second two lines show the inf=
o 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.
> =A0=A0=A0=A0=A0=A0=A0=A0Once 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 on =
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, 1x256=
> DDR266, 'bus disconnect' northbridge power saving feature enabled. Also
> tested on Intel P4 3GHz/512/800 (Northwood) socket 478 with 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 timin=
g. 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 hours. I tried
> compiling LCDproc with 'gettimeofday' timing and is also makes things
> better. I tried compiling it with 'IO delay' timing, but compiling fails
> pointing at C99 style in asm code. I tried passing C99 style option 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 ad=
> 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-dev=
el (current).
> =A0=A0=A0=A0=A0=A0=A0=A0Please help! I'd like to try increasing delay of =
display switching
> first...
> Any ideas are welcome.

Archive powered by MHonArc 2.6.18.

Top of page