From bsdfan at nurfuerspam.de  Sun Nov  1 16:18:50 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 01 Nov 2009 17:18:50 +0100
Subject: [Lcdproc] Patch: Refactoring min/max macros
Message-ID: <20091101161850.22830@gmx.net>

Hi,

while working on the QNX patch I found that in the current code min() and max() macros are defined in several places.

I introduced a new file shared/defines.h into which I moved those macros and removed them from all other places. I thought of using config.h for this, but it is not #ifdef protected.

Currently only min/max macros are there, but others could be moved to it as well.

Comments?

Regards,
Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minmax.diff
Type: application/octet-stream
Size: 4380 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20091101/86bb1b93/attachment.obj>

From bsdfan at nurfuerspam.de  Mon Nov  2 19:15:47 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 02 Nov 2009 20:15:47 +0100
Subject: [Lcdproc] Changed picoLCD IR handling
In-Reply-To: <1255330315.17197.3.camel@droids>
References: <35687.88.159.85.214.1252165003.squirrel@webmail.onsneteindhoven.nl>	
	<4AC7678F.3050904@nurfuerspam.de> <1255330315.17197.3.camel@droids>
Message-ID: <4AEF2FE3.1030308@nurfuerspam.de>

Hi,

the patch was committed yesterday.

Regards,
Markus

Nicu Pavel wrote:
> Hi,
> 
> The 20x4 lcd will have a hardware review, maybe we can solve that
> usb_clear_halt when receiving packets with a firmware update. Till then
> the patch for 20x2 can be applied.
> 
> Thanks,
> 
> Nicu Pavel
> 
> 
>> the patch compiles cleanly. For the docbook part a small change is 
>> needed to make it work.
>>
>> Before committing this, I'd like to hear from the PicoLCD guys whether 
>> it still works on 20x4 displays.
>>
>> Regards
>> Markus
>> _______________________________________________
>> LCDproc mailing list
>> LCDproc at lists.omnipotent.net
>> http://lists.omnipotent.net/mailman/listinfo/lcdproc
>>
> 
> 
> 
> 

From pcfe at unix-ag.uni-kl.de  Thu Nov  5 23:03:02 2009
From: pcfe at unix-ag.uni-kl.de (Patrick C. F. Ernzer)
Date: Fri, 6 Nov 2009 01:03:02 +0200
Subject: [Lcdproc] problems with 0.5.3 and BWCT USB LCD
In-Reply-To: <20090811160845.1f0f0409@bofferding-pcfe.dyndns.org>
References: <20090811160845.1f0f0409@bofferding-pcfe.dyndns.org>
Message-ID: <20091106010302.29a0b8d2@morn.internal.paranoid.com>

Hello,

sorry to bump this, but I am still stumped. Any hints appreciated.

PCFE

On Tue, 11 Aug 2009 16:08:45 +0300
"Patrick C. F. Ernzer" <pcfe at unix-ag.uni-kl.de> wrote:

> Hello,
> 
> while 0.5.2 works just fine on my box, 0.5.3 is giving me trouble.
> 
> # LCDd -f -r 5 -s 0
> LCDd version 0.5.3 starting
> Built on Jul 26 2009, protocol version 0.3, API version 0.5
> Using Configuration File: /etc/sysconfig/lcdproc/LCDd.conf
> Set report level to 5, output to stderr
> LCDd 0.5.3, LCDproc Protocol 0.3
> Part of the LCDproc suite
> Copyright (C) 1998-2009 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.
> 
> 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., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301, USA.
> 
> Server running in foreground
> Listening for queries on 127.0.0.1:13666
> screenlist_init()
> driver_load(name="joy", filename="/usr/lib/lcdproc/joy.so")
> joy: using Device /dev/input/js0
> joy: Joystick (Gravis GamePad Pro USB ) has 2 axes and 10 buttons.
> Driver version is 2.1.0 joy: map Button1 to Escape
> joy: map Button2 to Down
> joy: map Button3 to Enter
> joy: map Button4 to Up
> joy: map Button5 to Left
> joy: map Button6 to Right
> joy: map Button7 to Left
> joy: map Button8 to Right
> joy: init() done
> driver_load(name="hd44780", filename="/usr/lib/lcdproc/hd44780.so")
> HD44780: using ConnectionType: bwctusb
> hd44780: Using hd44780_default charmap
> hd_init_bwct_usb: interface may be claimed by kernel driver,
> attempting to detach it hd_init_bwct_usb: unable to re-claim
> interface: No route to host Driver [hd44780] init failed, return code
> -1 Module /usr/lib/lcdproc/hd44780.so could not be loaded
> Could not load driver hd44780
> There is no output driver
> Critical error while initializing, abort.
> 
> 
> What else is needed to debug this?
> 
> Before installing 0.5.3 (from RPM), I stopped the LCDd cleanly and
> with LCDd stopped, /proc/bus/usb/devices shows me Driver=(none)
> As such I'm not quite sure how to determine why 0.5.3 thinks the
> interface is claimed and what to do about it.
> 
> FWIW: system is Fedora 11 i386
> 
> Kind regards,
> 
> Patrick
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc



-- 
------------------------ http://www.pcfe.net/ ------------------------
     Patrick C. F. Ernzer          |     e-mail: pcfe at pcfe.net
--go-and-make-your-own-disclaimer--+----------------------------------
Black holes are where God divided by zero...

From ethan.dicks at gmail.com  Tue Nov 10 06:08:11 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Tue, 10 Nov 2009 01:08:11 -0500
Subject: [Lcdproc] Patch: Refactoring min/max macros
In-Reply-To: <20091101161850.22830@gmx.net>
References: <20091101161850.22830@gmx.net>
Message-ID: <f4eb766f0911092208u3de4ea3bjb649707989d0c82@mail.gmail.com>

On 11/1/09, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
> Hi,
>
> while working on the QNX patch I found that in the current code min() and
> max() macros are defined in several places.

Not desirable, obviously.

> I introduced a new file shared/defines.h into which I moved those macros and
> removed them from all other places. I thought of using config.h for this,
> but it is not #ifdef protected.
.
.
.
> Comments?

I have yet to see much variation from machine to machine for min() and
max() definitions though I grant there could be some.  Would it be
reasonable to put definitions of min() and max() in config.h inside
#ifndef's?  Is that likely to trip up any of the required definitions
for compilers for supported environments?

-ethan

From luciusmare at gmail.com  Tue Nov 10 16:21:36 2009
From: luciusmare at gmail.com (Lucius Mare)
Date: Tue, 10 Nov 2009 17:21:36 +0100
Subject: [Lcdproc] Using lcdproc as a driver for displaying any information?
Message-ID: <4AF99310.2060507@gmail.com>

Hello,i am interested in buying these VFD displays,but i think i wouldnt 
want to have it just output system information.So,could be lcdproc used 
to output any text?Thank you.

From bsdfan at nurfuerspam.de  Thu Nov 12 18:39:38 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 12 Nov 2009 19:39:38 +0100
Subject: [Lcdproc] Patch: Refactoring min/max macros
In-Reply-To: <f4eb766f0911092208u3de4ea3bjb649707989d0c82@mail.gmail.com>
References: <20091101161850.22830@gmx.net>
	<f4eb766f0911092208u3de4ea3bjb649707989d0c82@mail.gmail.com>
Message-ID: <4AFC566A.6010402@nurfuerspam.de>

Ethan Dicks wrote:
> On 11/1/09, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
>> I introduced a new file shared/defines.h into which I moved those macros and
>> removed them from all other places. I thought of using config.h for this,
>> but it is not #ifdef protected.
> .
> .
> .
>> Comments?
> 
> I have yet to see much variation from machine to machine for min() and
> max() definitions though I grant there could be some.  Would it be
> reasonable to put definitions of min() and max() in config.h inside
> #ifndef's?  Is that likely to trip up any of the required definitions
> for compilers for supported environments?
> 

I put those the macro definitions in defines.h and used #ifndef, similar
to what clients/lcdproc/main.[ch] did.

I thought of using config.h for this, but config.h itself is not #ifdef
protected so it cannot be included several times (some files use min/max
in LCDd and their header files reference each other).

This way we may also move some of our own commonly used macros like
chain(), TRUE and FALSE into defines.h.

Regards,
Markus

From 4freefinders at gmail.com  Sun Nov 15 07:19:37 2009
From: 4freefinders at gmail.com (grant donald)
Date: Sun, 15 Nov 2009 00:19:37 -0700
Subject: [Lcdproc] display debug hex data on a 2x24
Message-ID: <d221061e0911142319x48de9f4em4a3d9c6a59a2ad00@mail.gmail.com>

Hello World,

This is the question, been looking for 2 days for the lcd interface to a
Atmega168 for new code debug. So strange I found 4 places that say they do
it, but none that say how. I've got the wiring ok to the lcd for displaying
temps etc. but something so simple, i don't get it. thx :|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20091115/7e323f94/attachment.html>

From shamnaik at yahoo.com  Thu Nov 19 13:05:29 2009
From: shamnaik at yahoo.com (sham)
Date: Thu, 19 Nov 2009 13:05:29 +0000 (UTC)
Subject: [Lcdproc] XPC target porting
Message-ID: <loom.20091119T133001-66@post.gmane.org>

Hi,

We have a PC104 based embedded system . It is running XPC target kernel from
Mathworks. We have a HMI device (CFA635-TFE-KS from Crystal Fontz, 20 x 4
charecter LCD, 6 buttons) connected to the RS232 COM port. We need to create HMI
which could include pull down menus, text boxes... etc.

I have the following questions:

1. Do you have support for XPC target? (From the knowledge I have, it is a
propriatory kernel. I know how to read and write data to the COM port... that is
it).

2. If not, for the short term do you have some source code which I can use to
create pull down menus, text boxes...etc easily?

Regards
Sham


From meikster at gmail.com  Thu Nov 19 14:41:36 2009
From: meikster at gmail.com (Michael K.)
Date: Thu, 19 Nov 2009 15:41:36 +0100
Subject: [Lcdproc] wrapping around to last menu entry issues
Message-ID: <32d052790911190641i11bc0afbi24580aeafea7ecf4@mail.gmail.com>

Hi;

  I'm using a CrystalFontz CFA 635 LCD, and since I don't have any other LCD
to test, I don't know if this problem can be easily reproduced.

Here is the problem: there is no wrapping up to the last menu entry when I
press "UP" while my cursor is on the first menu entry: actually, the "title"
line shifts to the second line and I get a very weird result.

I made a little fix, which doesn't wrap, but actually prevents the title bar
from shifting in a dirty manner. That's in "server/menu.c" around line 712
(I used CVS-current-20091103 version, but I  had the same problem with
Ubuntu's packaged version):

else if (menu->data.menu.selector_pos == 0)
{
  menu->data.menu.selector_pos = 0;
  menu->data.menu.scroll = 0;
}

I know that this workaround is very dirty, but since I just wanted to fix my
problem, I just spent 5 minutes in the code (actually I hacked some code
that did the right thing, but the title bar wasn't displayed when I pressed
the "up" key while having the cursor on the first line, before jumping to
the last line)

By the way, I have another question: Let's say that I want to create a menu
which permits me to input an IP address using CIDR notation (i.e. "
192.168.31.5/16"), is there a way to do so ? Or is there any documention
explaining how to add custom menu types in LCDd ? (or someone who can
explain this maybe ? :))

Thanks.

Regards, Michael

-- 
Michael Kandharsingh.
"SoftIce est avant tout un desassembleur."
       E.D au proces en appel de Guillermito
Stephen Leacock<http://www.brainyquote.com/quotes/authors/s/stephen_leacock.html>
- "I detest life-insurance agents: they always argue that I shall some
day
die, which is not so."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20091119/fbaa5659/attachment.htm>

From bsdfan at nurfuerspam.de  Sun Nov 22 19:54:51 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 22 Nov 2009 20:54:51 +0100
Subject: [Lcdproc] Patch: Refactoring min/max macros
In-Reply-To: <4AFC566A.6010402@nurfuerspam.de>
References: <20091101161850.22830@gmx.net>
	<f4eb766f0911092208u3de4ea3bjb649707989d0c82@mail.gmail.com>
	<4AFC566A.6010402@nurfuerspam.de>
Message-ID: <4B09970B.2090306@nurfuerspam.de>

Markus Dolze wrote:
> Ethan Dicks wrote:
>   
>> On 11/1/09, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
>>     
>>> I introduced a new file shared/defines.h into which I moved those macros and
>>> removed them from all other places. I thought of using config.h for this,
>>> but it is not #ifdef protected.
>>>       
>> .
>> .
>> .
>>     
>>> Comments?
>>>       
>> I have yet to see much variation from machine to machine for min() and
>> max() definitions though I grant there could be some.  Would it be
>> reasonable to put definitions of min() and max() in config.h inside
>> #ifndef's?  Is that likely to trip up any of the required definitions
>> for compilers for supported environments?
>>
>>     
>
> I put those the macro definitions in defines.h and used #ifndef, similar
> to what clients/lcdproc/main.[ch] did.
>
> I thought of using config.h for this, but config.h itself is not #ifdef
> protected so it cannot be included several times (some files use min/max
> in LCDd and their header files reference each other).
>
>   
Hi,

I commited this change. Report any problems you encounter.

Regards
Markus

From bsdfan at nurfuerspam.de  Mon Nov 30 06:46:32 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 30 Nov 2009 07:46:32 +0100
Subject: [Lcdproc] Driver for the SURE Electronics LCD device
In-Reply-To: <200911162358.46881.laurent@latil.nom.fr>
References: <200907312216.15507.laurent@latil.nom.fr>
	<4AC768D8.4070602@nurfuerspam.de>
	<200911162358.46881.laurent@latil.nom.fr>
Message-ID: <4B136A48.4090904@nurfuerspam.de>

Laurent Latil wrote:
>    Hi,
> 
> I am terribly sorry for this very late answer, your email has been (sadly) 
> automatically classified as spam by my filters...   (that's why I take the 
> freedom to answer you directly and not through the ML)
> 
> I noticed it only because someone answered to your mail...
> 
> 
>> the driver looks good and compiles cleanly.
> 
> Good news!   :-)
> 
>  
>> One comment says "this is an initial release". Do you consider the
>> driver ready for inclusion?
> 
> Yes this comment was just to say that...   first release.
> 
> But the driver supports most of the interesting features of this LCD device 
> (including the custom chars for example), so I do not really plan any update.
> 
> Beside, this driver has been only tested on just one kind of device, and I 
> thought it could be better if someone test it on another kind of SureElec 
> device  (like the larger 20x4 screen).
> But nobody reported any good / bad working until now apparently,  so the 
> driver can probably be included 'as is' I think.
> 
>     Best regards.
> 

Hi,

the new driver has been committed to CVS yesterday.

Thank you for your contribution.

Regards,
Markus