LCDproc development and user support list

Text archives Help


[Lcdproc] HD44780-winamp gets overflooded with Hearts after upgrading to CVS


Chronological Thread 
  • From: joris AT robijn.net (Joris Robijn)
  • Subject: [Lcdproc] HD44780-winamp gets overflooded with Hearts after upgrading to CVS
  • Date: Thu Mar 10 17:59:01 2005

On 10 Mar 2005 at 13:57, Andr=E9s Trapanotto wrote:

My mailbox gets overflooded by these long messages ;)

Use your delete key to delete parts of the text that you are no longer
refering to.

Joris



> Sven Mertens escribi=F3:
>
> > Andr=E9s Trapanotto schrieb:
> >
> >> Sven Mertens escribi=F3:
> >>
> >>> Andr=E9s Trapanotto schrieb:
> >>>
> >>>>
> >>>> Sven Mertens escribi=F3:
> >>>> [For complete thread please refer to the archive]
> >>>>
> >>>>>>
> >>>>>>
> >>>>>> Well, I was looking the code and I think that the problem is
> >>>>>> that it is "clearing" the buffer with zero values
> >>>>>> hd44780.c: Line 240:
> >>>>>> memset(p->lcd_contents, 0, p->width * p->height);
> >>>>>>
> >>>>>> then, lcdproc sets the zero character to be a heart and the
> >>>>>> caracter generator show you a heart in every hole...
> >>>>>>
> >>>>>> You can try changing the above line in this way:
> >>>>>> hd44780.c: Line 240 (MODIFIED):
> >>>>>> memset(p->lcd_contents, ' ', p->width * p->height);
> >>>>>>
> >>>>>> So, the buffer will fills with spaces ascii=3D0x20 instead
> >>>>>> ascii=3D0x00
> >>>>>>
> >>>>>> Change this, recompile, test and tell us your experience.
> >>>>>>
> >>>>>> (Mantaining the right size=3D18x4 configuration)
> >>>>>>
> >>>>>
> >>>>> Hi!
> >>>>>
> >>>>> Thanks for your reply again. And sorry for the late answer.
> >>>>> I changed line 240, changed back to the lcdproc root directory and
> >>>>> did a
> >>>>>
> >>>>> make clean && ./configure --enable-drivers=3Dhd44780,curses && mak=
e
> >>>>>
> >>>>> Lcdproc configured and compiled without any complainments.
> >>>>>
> >>>>> When the daemon was started, first the display was filled up with
> >>>>> the wellknown hearts. In the second line I could "T 378" from the
> >>>>> portsetting message. After two seconds the damoen initialized the
> >>>>> serverscreen. Now I could see the "LCDProc Server" message in the
> >>>>> first line, scrolling left and right. In the second line I could s=
ee
> >>>>> "Clients: 0". The remaining parts of the the display were filled u=
p
> >>>>> with the hearts. Now, with every screenupdate, the display fills u=
p
> >>>>> with solid white blocks. Killing and starting the daemon again
> >>>>> brought the same results.
> >>>>>
> >>>>> After that I tried typing the commands for cleaning, configuring a=
nd
> >>>>> compiling one for one and didn't get another result. I even tried
> >>>>> compiling with another character rather than ' '. I set 'x' in the
> >>>>> line wich you specified to see if this changes something, but
> >>>>> without any changes in the result. (I've set the char back to ' '
> >>>>> after this experiment.) So I verified again (the third time ;) )
> >>>>> that I modified the right file, in the right directory at the righ=
t
> >>>>> line (240).
> >>>>>
> >>>>>
> >>>>>
> >>>>> Sorry to say your suggestion did not work. Is it possible that the=
re
> >>>>> is more than one line wich cleares the display/buffer? This would
> >>>>> explain the fact that there are the hearts first and than the
> >>>>> blocks.
> >>>>>
> >>>>> Greetings, Sven Mertens
> >>>>>
> >>>> Sorry, I was wrong :(
> >>>> This driver implements two buffers "framebuf" and "lcd_contents",=

> >>>> and only write to the hd44780 the differences between them to save
> >>>> resources and time.
> >>>> Then, I told you that change a line that works on "lcd_contents"
> >>>> and it had no effect over the showing text.
> >>>> I'll try to do it better this time. In first, restore the line
> >>>> 240 to original cero value :|
> >>>> If you see the HD44780_clear do the thing that I told you, It
> >>>> fills framebuf with spaces :)
> >>>>
> >>>> If you see it you'll find that the HD44780_icon function sets the=

> >>>> special caracter 0 to be the heart, and then If you see the screen
> >>>> fullfilled with hearts is because the buffer is filled with zero
> >>>> values ...
> >>>> I was looking in the code but I haven't found the problem :(
> >>>> You can try to put a printf ("%s", p->framebuf) in some place (at=

> >>>> the end of HD44780_flush for example) to see the framebuffer
> >>>> contents or something better like some code that show the
> >>>> hexadecimal values :) then you can check if it is happen the weird
> >>>> things that I'm telling you ....
> >>>>
> >>>> Then ... tell us the news :)
> >>>> Best regards,
> >>>>
> >>>
> >>> Hi there!
> >>>
> >>> No matter with your wrong conclusion. Everybody makes mistakes, so
> >>> don't think about it any more. I'm glad that theres's someone who's
> >>> trying to help me. :)
> >>
> >>
> >>
> >> ok :)
> >>
> >>>
> >>> So, back to topic :)
> >>> I modified my hd44780.c like explained by you. I inserted the
> >>> 'printf' right below the DEBUG message and before the '}' wich marks
> >>> the end of HD44780_flush.
> >>
> >>
> >>
> >> Well, in this case it is fine, but in other circunstances be sure
> >> of put your modification before "return ;" line :)
> >
> >
> > Ok, I will obey that in future
> >
> >>
> >>> It compiled properly but didnt't show up with the framebuffer
> >>> content. After that I placed the command at the beginning of the
> >>> function. This gave me an error about an undeclared identifier. Sorr=
y
> >>> for beeing a bit stupid but I'm not familar with C / C++ programming=
,
> >>> I have only experience with BASIC and PHP. :/
> >>>
> >>> Btw: Compiling with "--enable-debug" didn't gave a clue whats wrong.
> >>> ;)
> >>
> >>
> >>
> >> I'm not using it but try passing -r N to LCDd when executing it
> >> where N is the report level desired.
> >>
> >>>
> >>> I also tried to place a "printf ("Test");" at some places in the
> >>> funtion but the Message didnt't show up anywhere. (I tried to learn =
C
> >>> a few months ago but failed due the lack of time. So far as I know
> >>> this should print me a "Test" at the console but maybe I'm wrong wit=
h
> >>> that. In that case just ignore it :).)
> >>
> >>
> >>
> >> Use this:
> >> fprintf (stderr, "\nTest");
> >>
> >> Or
> >> fprintf (stderr,"%s", p->framebuf);
> >>
> >> Or
> >> ---
> >> fprintf (stderr,"\n");
> >> for (i=3D0; p->framebuf[i];i++)
> >> fprintf (stderr, "0x%0X",p->framebuf[i]);
> >> ---
> >>
> >>>
> >>> Meanwhile I've resetted the display with a reboot of the PC wich it =
is
> >>> connected to. Now, as mentioned in my previous post, the display doe=
s
> >>> nothing when the daemons is started. It just shows me the two bright
> >>> and the two dark lines to tell me it is correct connected to the
> >>> power.
> >>>
> >>> I also tried to place your buffer message in various other places
> >>> instead of the end of HD44780_flush. But it never showed up somewher=
e.
> >>> Wether it is displayed on the console, nor i can see it at the
> >>> display. Let me ask a stupid question: Is this function called
> >>> somewhere? I don't know exactly what i does, but every change I made
> >>> to it didn't show up in the compiled program. I ususally recompile
> >>> with the following commandline:
> >>>
> >>> make clean && ./configure --enable-drivers=3Dhd44780,curses && make
> >>>
> >>> After that i do a cd into the server's dir and start it with
> >>>
> >>> ./LCDd -c /etc/LCDd.conf
> >>>
> >>> To be sure I downloaded a fresh new tarball from the website,
> >>> modified the hd44780.c as specified by you and compiled in a clean
> >>> directory. With the same results.
> >>>
> >>> I just placed the printf command in HD44780_string to see if it may
> >>> work. It didn't.
> >>>
> >>> So, I attached my modified hd44780.c (Sorry for any inconvinience) f=
or
> >>> you to look if I've done your modification as intended. Did I? If no=
t
> >>> so take my excuse and, please, explain me what I have done wrong. I
> >>> yes, any more ideas?
> >>>
> >> It's ok, but I think that you forgot the attachment.
> >> Please, try with the above "fprintf ()" and then we continues...
> >>
> >>
> >> Good luck!!!
> >>
> >>
> >
> > Hi!
> >
> > I'm a stupid noob, aren't I? ;)
> > First I tried 'fprintf (stderr,"%s", p->framebuf);" placed in the end =
of
> > HD44780_flush.
> >
> > This is exactly was happend:
> > server:/compile/lcdproc_cvs3/server # ./LCDd
> > LCDd version CVS-current-20050310 starting
> > Using Configuration File: /etc/LCDd.conf
> > LCDd CVS-current-20050310, LCDproc Protocol 0.3
> > Part of LCDproc
> > Copyright (C) 1998-2003 William Ferrell, Scott Scriven
> > and many other contributors
> >
> > This program is free software; you can redistribute it and/or
> > modify it under the terms of the GNU General Public License
> > as published by the Free Software Foundation; either version 2
> > of the License, or (at your option) any later version.
> >
> > This program is distributed in the hope that it will be useful,
> > but WITHOUT ANY WARRANTY; without even the implied warranty of
> > MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > GNU General Public License for more details.
> >
> > The file COPYING contains the GNU General Public License.
> > You should have received a copy of the GNU General Public License
> > along with this program; if not, write to the Free Software
> > Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
> > USA.
> >
> > Listening for queries on 127.0.0.1:13666
> > HD44780 20x4 LPT 0x378 LCDproc Server LCDproc Server
> > LCDproc Server LCDproc Server LCDproc Server LCDproc Server LCDpro=
c
> > Server LCDproc Server LCDproc Server LCDproc Server LCDproc Server
> > LCDproc Server LCDproc Server LCDproc Server LCDproc Server LCDproc
> > Server LCDproc Server LCDproc Server LCDproc Server LCDproc Server=

> > LCDproc Server LCDproc Server LCDproc Server Server shutting down on
> > SIGINT server:/compile/lcdproc_cvs3/server # LCDproc and Linux!
> >
> >
> > I think that was intendend, since it printed out an "LCDproc" every
> > second. I noticed that it prints a lot of spaces. (Are this the hearts=
i
> > can see on my display?) Now I tried the little for-loop you suggested.
> > That happened:
> >
> > Listening for queries on 127.0.0.1:13666
> >
> > 0x480x440x340x340x370x380x300x200x320x300x780x340x200x200x200x200x200x=
20
> > 0x200x200x4C0x500x540x200x300x780x330x370x380x200x200x200x200x200x200x=
20
> > 0x200x200x200x200x200x200x200x200x200x200x200x200x200x200x200x200x200x=
20
> > 0x200x200x200x200x200x200x200x200x200x200x200x200x200x200x200x200x200x=
20
> > 0x200x200x200x200x200x200x200x20
> >
> > 0x60x60x200x4C0x430x440x700x720x6F0x630x200x530x650x720x760x650x720x20=
0x
> > 6
> > 0x60x60x200x4C0x430x440x700x720x6F0x630x200x530x650x720x760x650x720x20=
0x
> > 6
> > 0x60x60x200x4C0x430x440x700x720x6F0x630x200x530x650x720x760x650x720x20=
0x
> > 6
> > 0x60x60x200x4C0x430x440x700x720x6F0x630x200x530x650x720x760x650x720x20=
0x
> > 6
> > 0x60x60x200x4C0x430x440x700x720x6F0x630x200x530x650x720x760x650x720x20=
0x
> > 6
> > 0x60x60x200x4C0x430x440x700x720x6F0x630x200x530x650x720x760x650x720x20=
0x
> > 6
> > 0x60x60x200x4C0x430x440x700x720x6F0x630x200x530x650x720x760x650x720x20=
0x
> > 6
> > 0x60x60x200x4C0x430x440x700x720x6F0x630x200x530x650x720x760x650x720x20=
0x
> > 6Server shutting down on SIGINT
> >
> > 0x200x200x200x200x200x200x200x200x200x200x200x200x200x200x200x200x200x=
20
> > 0x200x200x200x200x540x680x610x6E0x6B0x730x200x660x6F0x720x200x750x730x=
69
> > 0x6E0x670x200x200x200x4C0x430x440x700x720x6F0x630x200x610x6E0x640x200x=
4C
> > 0x690x6E0x750x780x210x200x200x200x200x200x200x200x200x200x200x200x200x=
20
> > 0x200x200x200x200x
> >
> >
> >
> > I noticed it is printing me the hex-numbers of the framebuffer. Since
> > I'm out of time I will have a look on this later, in the evening, (its
> > afternoon here).
>
>
> Well, if you try this for-loop
> ---
> fprintf (stderr,"\n");
> for (i=3D0; p->framebuf[i];i++)
> fprintf (stderr, "0x%02X ",p->framebuf[i]);
> ---
> you'll get this
>
> (........) 0x48 0x44 0x34 0x34 0x37 0x38 0x30 0x20 0x32 0x30 0x78 0x34
> 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x4C 0x50 0x54 0x20 0x30 0x78 0x=
33
> 0x37 0x38 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x=
20
> 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x=
20
> 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x=
20
> 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x20 0x06 0x06 0x20 0x4C 0x43 0x44 0x=
70
> 0x72 0x6F 0x63 0x20 0x53 0x65 0x72 0x76 0x65 0x72 0x20 0x06 (........)
>
> so you can see that the program is filling spaces with spaces 0x20 =
:)
> At now you can remove the for-loop because we now what we wanted to
> know.
>
> I was looking for differences between the lcdproc-0.4.5 and
> lcdproc-0.5 version of this driver.
> Please change the line 442 form
>
> char ch;
> to
> unsigned char ch;
>
> .........................
>
> --
> T=E9cnico Andr=E9s Trapanotto
> INSTITUTO NACIONAL DE TECNOLOG=CDA INDUSTRIAL
> Centro de Investigaci=F3n Telecomunicaciones, Electr=F3nica e Inform=E1t=
ica
> Tel=E9fono (54 11) 4724 6300 Interno 6362
> mail AT andrestrapanotto.com.ar
> ___________________________________________ 0800 444 4004 |
> www.inti.gov.ar
>
> _______________________________________________
> LCDproc mailing list
> LCDproc AT lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc

--
Joris Robijn
<joris AT robijn.net>
Mobile: +31 6 288 41 964

// To understand recursion, we must first understand
recursion





Archive powered by MHonArc 2.6.18.

Top of page