From dl9sec at gmx.net  Tue Dec  1 19:17:09 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Tue, 01 Dec 2009 20:17:09 +0100
Subject: [Lcdproc] Can't get this thing working...
Message-ID: <20091201191709.262770@gmx.net>

Hi all,

i spent several days to get this quite simple thing going to work, but
it will NOT!

I use a simple EA DIP204-4 (using KS0073 controller) and want to use
it in 4bit-mode. Have a look at http://www.dl9sec.de/LCDproc_LPT_1V0.pdf
to see the schematic ( btw. R4 is omitted and replaced by 0R).
The parallel port is connected via a 26-pin header directly with a 
1:1 ribbon cable.
I used the suggested connection for "4bit" from the documentation
including backlight connected to D5 and a matrix of keys.

That's my LCDd.conf which should IMHO work:

# LCDd.conf -- configuration file for the LCDproc server daemon LCDd
[server]
DriverPath=/usr/lib/lcdproc/
Driver=hd44780
Bind=127.0.0.1
Port=13666
ReportLevel=2
ReportToSyslog=no
User=nobody
Foreground=no
WaitTime=5
ServerScreen=no
Backlight=open
Heartbeat=open
TitleSpeed=10
ToggleRotateKey=Enter
PrevScreenKey=Left
NextScreenKey=Right
ScrollUpKey=Up
ScrollDownKey=Down

[menu]
MenuKey=Menu
EnterKey=Enter
UpKey=Up
DownKey=Down
LeftKey=Left
RightKey=Right

[hd44780]
Port=0x278
ConnectionType=4bit
Speed=0
Charmap=ea_ks0073
Keypad=yes
Backlight=yes
OutputPort=no
Lastline=no
Size=20x4
ExtendedMode=yes
DelayMult=4
DelayBus=yes
RefreshDisplay=5
KeyMatrix_2_7=Menu
KeyMatrix_3_8=Enter
KeyMatrix_1_8=Up
KeyMatrix_3_7=Down
KeyMatrix_4_8=Left
KeyMatrix_4_7=Right
KeyMatrix_1_7=User

I want to have it running on a Debian 5 stable. I installed the lcdproc
package version 0.5.2-3 via apt from the testing repository (all the rest
of my distribution is "stable"!).

The result is, that the backlight is flickering and the display shows 
4x20 black blocks (seems to be uninitialized). I checked all the
connections and wiring, all ok so far. I used a scope and examined the
signals. I expected digital toggling on D0..D3, D4 and D6 and a static
low (backlight on) on D5, no toggling on D7. But all data pins D0..D7
are showing data signals and the display shows nothing than black blocks.

I am afraid i am going nuts soon! :-(

I tried a lot of configuration change and hardware change (pulling D0..D3
to low, pulling RES explicit to high...) but with no success.

I tried to search the web for my problem, but nothing. So it seems that
no one has such a problem.

Here ist the stdout, when i called LCDd from the command line:

Server running in foreground
Listening for queries on 127.0.0.1:13666
screenlist_init()
driver_load(name="hd44780", filename="/usr/lib/lcdproc/hd44780.so")
HD44780: Matrix key 0 6: "User"
HD44780: Matrix key 0 7: "Up"
HD44780: Matrix key 1 6: "Menu"
HD44780: Matrix key 2 6: "Down"
HD44780: Matrix key 2 7: "Enter"
HD44780: Matrix key 3 6: "Right"
HD44780: Matrix key 3 7: "Left"
hd44780: Using ea_ks0073 charmap
Key "Menu" is now reserved in exclusive mode by client [-1]
Key "Enter" is now reserved in shared mode by client [-1]
Key "Up" is now reserved in shared mode by client [-1]
Key "Down" is now reserved in shared mode by client [-1]
Key "Left" is now reserved in shared mode by client [-1]
Key "Right" is now reserved in shared mode by client [-1]
screenlist_process()
screenlist_switch(s=[_server_screen])
screenlist_switch: switched to screen [_server_screen]
screenlist_process()
screenlist_process()
screenlist_process()
:

Seems to be ok. I am completely despreate with that thing.

Any ideas or help?

Thanks in advance.

Regards, Thorsten

From ethan.dicks at gmail.com  Tue Dec  1 19:51:41 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Tue, 1 Dec 2009 14:51:41 -0500
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <20091201191709.262770@gmx.net>
References: <20091201191709.262770@gmx.net>
Message-ID: <f4eb766f0912011151w40c204dbh524b35af1ea2f4b2@mail.gmail.com>

On 12/1/09, Thorsten Godau <dl9sec at gmx.net> wrote:
> to see the schematic ( btw. R4 is omitted and replaced by 0R).

> The result is, that the backlight is flickering and the display shows
> 4x20 black blocks (seems to be uninitialized).

The flickering backlight suggests to me that you are underpowering it.
 Try disconnecting the backlight and getting characters to work first,
then worry about lighting the backlight.

As for "all black", does it matter where you position R5?  It's
possible to set the contrast such that there are no clear pixels.
Also, check to see if you have an "extended temp LCD" module - those
are identical to "standard temp LCD" modules except the Vee probably
needs to be a few volts in the *negative* to set the contrast.  I had
a couple of those modules go by over the years - the easy way to use
them is rig up a 7660 negative voltage supply, or just use a
multi-voltage source (though recent PCs stopped providing the -5V
"white" wire to the PSU).

The other possibility is that you are driving the display faster than
it can keep up with and you are getting bus garbage not valid bytes.
Those old LCD controllers are not particularly fast - ISTR they are
designed to work happily as bus-interfaced devices on 1-4MHz 8-bit
microprocessors.

-ethan

From dl9sec at gmx.net  Wed Dec  2 17:40:11 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Wed, 02 Dec 2009 18:40:11 +0100
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <f4eb766f0912011151w40c204dbh524b35af1ea2f4b2@mail.gmail.com>
References: <20091201191709.262770@gmx.net>
	<f4eb766f0912011151w40c204dbh524b35af1ea2f4b2@mail.gmail.com>
Message-ID: <20091202174011.87960@gmx.net>

Hi Ethan,

thanks for the reply.

> The flickering backlight suggests to me that you are underpowering it.

Definitely not. The flickering is the result of the toggling BL-control
signal D5. I can track this with a scope.

>  Try disconnecting the backlight and getting characters to work first,
> then worry about lighting the backlight.

Nevertheless a good idea to get no brain damage while searching for
the characters ;-))

> As for "all black", does it matter where you position R5?  It's
> possible to set the contrast such that there are no clear pixels.

Yep. I can adjust the contrast from clear to black. So R5 works.

> Also, check to see if you have an "extended temp LCD" module - those
> are identical to "standard temp LCD" modules except the Vee probably
> needs to be a few volts in the *negative* to set the contrast.  I had
> a couple of those modules go by over the years - the easy way to use
> them is rig up a 7660 negative voltage supply, or just use a
> multi-voltage source (though recent PCs stopped providing the -5V
> "white" wire to the PSU).

Checked. It's a common EA DIP204-4HNLED
(see http://www.lcd-module.com/eng/pdf/doma/dip204-4e.pdf)

> The other possibility is that you are driving the display faster than
> it can keep up with and you are getting bus garbage not valid bytes.
> Those old LCD controllers are not particularly fast - ISTR they are
> designed to work happily as bus-interfaced devices on 1-4MHz 8-bit
> microprocessors.

As you can see, i already use the
DelayMult=4
DelayBus=yes
parameters. I use a SBC with a Celeron 733MHz CPU. The parallel port 
is set to "EPP & ECP" (already checked all modes SPP and ECP only without
success).

The fact that makes me pensive is, that i can see digital data on D0..D7.
I expected a static signal on D5 because of the "Backlight=yes" in the
[hd44780]-section of LCDd.conf and no data signalling on D7.
I can not see any difference of the signals on the data lines D0..D7
if i e.g use the "serialLpt" (just for testing) or the "4bit"-mode.
It seems that another process is using my parallel port and puts
out some data on it (but never got a message that the pp is already
occupied when i started LCDd!) .

Any ideas if there is a daemon in the background that occupies the
parallel port (i use a standard Debian Lenny in runlevel 2)?
Or how can i find out if any process than LCDd is using the pp?

Thanks in advance.

Regards, Thorsten

From dl9sec at gmx.net  Wed Dec  2 17:46:59 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Wed, 02 Dec 2009 18:46:59 +0100
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <f4eb766f0912011151w40c204dbh524b35af1ea2f4b2@mail.gmail.com>
References: <20091201191709.262770@gmx.net>
	<f4eb766f0912011151w40c204dbh524b35af1ea2f4b2@mail.gmail.com>
Message-ID: <20091202174659.87950@gmx.net>

Short addition:

When i "killall LCDd", the signalling on D0..D7 stops and when i
"LCDd -f -r 5 -s 0" the signalling starts again.

So the theory of another process that uses the pp is invalid...

:-(

Thorsten

From ethan.dicks at gmail.com  Wed Dec  2 18:22:44 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Wed, 2 Dec 2009 13:22:44 -0500
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <20091202174011.87960@gmx.net>
References: <20091201191709.262770@gmx.net>
	<f4eb766f0912011151w40c204dbh524b35af1ea2f4b2@mail.gmail.com>
	<20091202174011.87960@gmx.net>
Message-ID: <f4eb766f0912021022p9722b00u7df10c0d164944a@mail.gmail.com>

On 12/2/09, Thorsten Godau <dl9sec at gmx.net> wrote:
> Hi Ethan,
>
> thanks for the reply.

You bet.

> ...I use a SBC with a Celeron 733MHz CPU. The parallel port
> is set to "EPP & ECP" (already checked all modes SPP and ECP only without
> success).
>
> The fact that makes me pensive is, that i can see digital data on D0..D7.
> I expected a static signal on D5 because of the "Backlight=yes" in the
> [hd44780]-section of LCDd.conf and no data signalling on D7.
> I can not see any difference of the signals on the data lines D0..D7
> if i e.g use the "serialLpt" (just for testing) or the "4bit"-mode.

Try running LCDd in full debug mode and capturing the output - it
might tell you something interesting about what it's doing or what
it's seeing during initialization and right after.

Also, as for the flicker... try disabling 'heartbeat" - I find that
when I'm debugging connection and initialization problems with a new
module that the constant chatter of setting the filled/unfilled heart
character make too much noise to find what I'm trying to debug.

If you are seeing randomish pulses on D5-D7, it sounds like your
connection *isn't* really 4-bit.  Go through the init code with
debugging on and make sure you see the right branches in the code
logging output.

-ethan

From bsdfan at nurfuerspam.de  Wed Dec  2 18:46:41 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Wed, 02 Dec 2009 19:46:41 +0100
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <f4eb766f0912021022p9722b00u7df10c0d164944a@mail.gmail.com>
References: <20091201191709.262770@gmx.net>	<f4eb766f0912011151w40c204dbh524b35af1ea2f4b2@mail.gmail.com>	<20091202174011.87960@gmx.net>
	<f4eb766f0912021022p9722b00u7df10c0d164944a@mail.gmail.com>
Message-ID: <4B16B611.0@nurfuerspam.de>

Ethan Dicks wrote:
> On 12/2/09, Thorsten Godau <dl9sec at gmx.net> wrote:
>   
>> ...I use a SBC with a Celeron 733MHz CPU. The parallel port
>> is set to "EPP & ECP" (already checked all modes SPP and ECP only without
>> success).
>>
>> The fact that makes me pensive is, that i can see digital data on D0..D7.
>> I expected a static signal on D5 because of the "Backlight=yes" in the
>> [hd44780]-section of LCDd.conf and no data signalling on D7.
>> I can not see any difference of the signals on the data lines D0..D7
>> if i e.g use the "serialLpt" (just for testing) or the "4bit"-mode.
>>     
>
> Also, as for the flicker... try disabling 'heartbeat" - I find that
> when I'm debugging connection and initialization problems with a new
> module that the constant chatter of setting the filled/unfilled heart
> character make too much noise to find what I'm trying to debug.
>
> If you are seeing randomish pulses on D5-D7, it sounds like your
> connection *isn't* really 4-bit.  Go through the init code with
> debugging on and make sure you see the right branches in the code
> logging output.
>
>   

Hi,

have you tried with the keypad turned off in LCDd.conf? Although you
have not connected your keypad to D5 the function which scans for keys
may be putting this port low/high.

Additionally, when you power on the display, you should see block
characters in row 1 and 3 and no characters in row 2 and 4. Does this
change if you start LCDd?

Regards
Markus

From bsdfan at nurfuerspam.de  Wed Dec  2 19:15:18 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Wed, 02 Dec 2009 20:15:18 +0100
Subject: [Lcdproc] wrapping around to last menu entry issues
In-Reply-To: <32d052790911190641i11bc0afbi24580aeafea7ecf4@mail.gmail.com>
References: <32d052790911190641i11bc0afbi24580aeafea7ecf4@mail.gmail.com>
Message-ID: <4B16BCC6.8060109@nurfuerspam.de>

Michael K. wrote:
> 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 <http://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
>
> -- 
Hi,

I tried reproducing your problem, but cannot find exactly the error.
Here is what I observed:

First, I enter the menu by and then go to the 'screens' submenu. It
lists all available screens to select one. The menu looks like this (Fig.1):

       +--------------------+
       |## Screens #########|
       |>_server_screen >   |
       | C >                |
       | I >               v|
       +--------------------+

As I scroll down, if I reach the end of the currently visible screen
(fig 1), the whole screen is moved up one row and the title disappears
(Fig.2):

       +--------------------+
       | _server_screen >  ^|
       | C >                |
       | I >                |
       |>M >               v|
       +--------------------+

Now I scroll down more until I reach the bottom of the list (Fig. 3):

       +--------------------+
       | M >               ^|
       | L >                |
       | T >                |
       |>N >                |
       +--------------------+

If I now press the 'down' key again, LCDd jumps to the top of the list
and shows fig 1 again!

Now I started the other way round. I moved down to the bottom of the
list (like fig. 3) and the press the UP key until I reached the top of
the list (Fig. 4)

       +--------------------+
       |>_server_screen >  ^|
       | C >                |
       | I >                |
       | M >               v|
       +--------------------+

On pressing the 'up' key again, LCDd jumps to the bottom of the list
(Fig. 5):

       +--------------------+
       | M >               ^|
       | L >                |
       | T >                |
       |>N >                |
       +--------------------+

Note the position of the caret character '>'.

The above was made using the curses driver (although I replaced the
graphic characters), but I tried with real displays as well and got the
same result.

To sum up: I can see LCDd wrapping around in the menu on pressing the UP
key. The only thing is that the title is not displayed if I reach the
top of the menu. I didn't see the title line scrolling down to row 2 as
you saw it.

Regards,
Markus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20091202/87e2466a/attachment.htm>

From dl9sec at gmx.net  Wed Dec  2 19:24:11 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Wed, 02 Dec 2009 20:24:11 +0100
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <4B16B611.0@nurfuerspam.de>
References: <20091201191709.262770@gmx.net>
	<f4eb766f0912011151w40c204dbh524b35af1ea2f4b2@mail.gmail.com>
	<20091202174011.87960@gmx.net>
	<f4eb766f0912021022p9722b00u7df10c0d164944a@mail.gmail.com>
	<4B16B611.0@nurfuerspam.de>
Message-ID: <20091202192411.87960@gmx.net>

Hi Markus,

> have you tried with the keypad turned off in LCDd.conf? Although you
> have not connected your keypad to D5 the function which scans for keys
> may be putting this port low/high.

I tried to turn off the keypad in LCDd.conf, the result is the same.
My keypad is connected as shown in the schematic (see my first mail).

I use exactly the connection scheme from the documentation:

D4 6   RS 4 
   GND RW 5 
D6 8   EN 6 
D0 2   D4 11 
D1 3   D5 12 
D2 4   D6 13 
D3 5   D7 14 

(from table 5.4)

My keypad is using the following X- and Y- lines:

nSTRB     1   Y7 
nLF      14   Y8 
nACK     10   X1 
BUSY     11   X2 
PAPEREND 12   X3 
SELIN    13   X4 

(from table 5.6)

And used D5 as mentioned:
"The optional backlight wiring should be connected to D5, pin 7."

> Additionally, when you power on the display, you should see block
> characters in row 1 and 3 and no characters in row 2 and 4. Does this
> change if you start LCDd?

When i power up the display it shows 4 lines of 20 blocks. This does
not change if i start LCDd.
Seems to leave in the uninitialized state, which would be plausible
if the LCDd isn't in 4bit-mode.

How can i check if the server uses 4bit-mode?
As mentioned, i can not see a real difference when i change 
the connection type.

Very strange...

Regards, Thorsten

From bsdfan at nurfuerspam.de  Wed Dec  2 19:39:22 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Wed, 02 Dec 2009 20:39:22 +0100
Subject: [Lcdproc] Serial port programming
Message-ID: <4B16C26A.3020003@nurfuerspam.de>

Hi everyone,

during the last days I had a look at the way we initialize serial ports
to track down the remaining issues with QNX.

I found that most drivers initialize a serial port smiliar to this:

  p->fd = open(device, O_RDWR | O_NOCTTY | O_NDELAY);
  tcgetattr(p->fd, &portset);
#ifdef HAVE_CFMAKERAW
  cfmakeraw(&portset);
#else
  portset.c_iflag &= ~( IGNBRK | BRKINT | PARMRK | ISTRIP
            | INLCR | IGNCR | ICRNL | IXON );
  portset.c_oflag &= ~OPOST;
  portset.c_lflag &= ~( ECHO | ECHONL | ICANON | ISIG | IEXTEN );
  portset.c_cflag &= ~( CSIZE | PARENB | CRTSCTS );
  portset.c_cflag |= CS8 | CREAD | CLOCAL ;
#endif
  cfsetospeed(&portset, speed);
  cfsetispeed(&portset, speed);
  tcsetattr(p->fd, TCSANOW, &portset);

Now what's wrong with that?

In our own implementation we clear CRTSCTS and set CREAD and CLOCAL. I
looked at cfmakeraw() from glibc, FreeBSD, NetBSD and QNX and none of it
modifies CRTSCTS and CLOCAL. Only FreeBSD sets CREAD.

Therefore these flags may not be in the desired state after cfmakeraw,
depending how they are configured at the time tcgetattr is used. While
CRTSCTS may be off by default, CLOCAL is usually not set. As most
drivers currently work, I suspect that neither CRTSCTS nor CLOCAL are
really needed.

Additionally it is a mistake to believe /portset/ cannot be modified
after using cfmakeraw - it can be modified, especially to set the
timeout values! Some drivers (serialPOS, MtxOrb) refuse to use cfmakeraw
(by commenting it out) because the author wanted to set timeouts. In the
CrystalFontz drivers, the complete init routine if contained even twice:
One time for serial ports using the above code and a second time for USB
connected displays.

O_NDELAY should probably read O_NONBLOCK, but it seems to work fine on
our supported platforms.

Therefore, I am short to re-writing the drivers which don't use
cfmakeraw correctly.

Comments?

Regards,
Markus


From ethan.dicks at gmail.com  Wed Dec  2 20:23:40 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Wed, 2 Dec 2009 15:23:40 -0500
Subject: [Lcdproc] Serial port programming
In-Reply-To: <4B16C26A.3020003@nurfuerspam.de>
References: <4B16C26A.3020003@nurfuerspam.de>
Message-ID: <f4eb766f0912021223l31bd4b6cqe3ba2d6296b74399@mail.gmail.com>

On 12/2/09, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
> Hi everyone,
>
> during the last days I had a look at the way we initialize serial ports
> to track down the remaining issues with QNX....

Having mucked around in there in years past, let me say, *what fun*!

> Therefore, I am short to re-writing the drivers which don't use
> cfmakeraw correctly.

I have worked on a few of the serial-port-based drivers in the past
(MtxOrb and PIC-an-LCD, among others).  I still have all that hardware
(including the PIC-an-LCD), so I would like to see things cleaned up
and can test multiple drivers in various environments as needed.  I
can also assist with more than just testing if needed, but at a slower
pace.

-ethan

From bsdfan at nurfuerspam.de  Wed Dec  2 21:01:12 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Wed, 02 Dec 2009 22:01:12 +0100
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <20091202192411.87960@gmx.net>
References: <20091201191709.262770@gmx.net>	<f4eb766f0912011151w40c204dbh524b35af1ea2f4b2@mail.gmail.com>	<20091202174011.87960@gmx.net>
	<f4eb766f0912021022p9722b00u7df10c0d164944a@mail.gmail.com>
	<4B16B611.0@nurfuerspam.de> <20091202192411.87960@gmx.net>
Message-ID: <4B16D598.6000208@nurfuerspam.de>

Thorsten Godau wrote:
> Hi Markus,
> 
>> have you tried with the keypad turned off in LCDd.conf? Although you
>> have not connected your keypad to D5 the function which scans for keys
>> may be putting this port low/high.
> 
> I tried to turn off the keypad in LCDd.conf, the result is the same.
> My keypad is connected as shown in the schematic (see my first mail).
> 
> I use exactly the connection scheme from the documentation:
> 
> D4 6   RS 4 
>    GND RW 5 
> D6 8   EN 6 
> D0 2   D4 11 
> D1 3   D5 12 
> D2 4   D6 13 
> D3 5   D7 14 
> 
> (from table 5.4)
> 
> My keypad is using the following X- and Y- lines:
> 
> nSTRB     1   Y7 
> nLF      14   Y8 
> nACK     10   X1 
> BUSY     11   X2 
> PAPEREND 12   X3 
> SELIN    13   X4 
> 
> (from table 5.6)
> 
> And used D5 as mentioned:
> "The optional backlight wiring should be connected to D5, pin 7."
> 
>> Additionally, when you power on the display, you should see block
>> characters in row 1 and 3 and no characters in row 2 and 4. Does this
>> change if you start LCDd?
> 
> When i power up the display it shows 4 lines of 20 blocks. This does
> not change if i start LCDd.
> Seems to leave in the uninitialized state, which would be plausible
> if the LCDd isn't in 4bit-mode.
> 
> How can i check if the server uses 4bit-mode?
> As mentioned, i can not see a real difference when i change 
> the connection type.
> 
> Very strange...
> 
> Regards, Thorsten
> 

Hi again,

I just tried the connection type (only the display though, no keypad).

When I power up my display it looke like 4bit-1.jpg. If I start LCDd, it
looks like 4bit-2.jpg.

Here is the hd44780 section from LCDd.conf.

[hd44780]
ConnectionType=4bit
Port=0x378
Keypad=no
Backlight=no
OutputPort=no
Size=20x4
Charmap=hd44780_default

I copied in the settings you used and received some garbage on the
screen (my display doesn't use extended mode), but it showed most chars
correctly.

What really puzzles me is that you see 4 lines of blocks after powerup.

Additionally, I tried with a switchable backlight and do see the same
flickering, if "Keypad=yes" is set in LCDd.conf. It is gone if I set
"Keypad=no", which supports what I guessed.

Regards,
Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4bit-1.jpg
Type: image/jpeg
Size: 16218 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20091202/22ecac23/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4bit-2.jpg
Type: image/jpeg
Size: 15462 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20091202/22ecac23/attachment-0003.jpg>

From bsdfan at nurfuerspam.de  Wed Dec  2 21:07:33 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Wed, 02 Dec 2009 22:07:33 +0100
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <20091202192411.87960@gmx.net>
References: <20091201191709.262770@gmx.net>	<f4eb766f0912011151w40c204dbh524b35af1ea2f4b2@mail.gmail.com>	<20091202174011.87960@gmx.net>
	<f4eb766f0912021022p9722b00u7df10c0d164944a@mail.gmail.com>
	<4B16B611.0@nurfuerspam.de> <20091202192411.87960@gmx.net>
Message-ID: <4B16D715.4080607@nurfuerspam.de>

Thorsten Godau wrote:
> Hi Markus,
> 
>> have you tried with the keypad turned off in LCDd.conf? Although you
>> have not connected your keypad to D5 the function which scans for keys
>> may be putting this port low/high.
> 
> I tried to turn off the keypad in LCDd.conf, the result is the same.
> My keypad is connected as shown in the schematic (see my first mail).
> 
> I use exactly the connection scheme from the documentation:
> 
> D4 6   RS 4 
>    GND RW 5 
> D6 8   EN 6 
> D0 2   D4 11 
> D1 3   D5 12 
> D2 4   D6 13 
> D3 5   D7 14 
> 
> (from table 5.4)
> 
> My keypad is using the following X- and Y- lines:
> 
> nSTRB     1   Y7 
> nLF      14   Y8 
> nACK     10   X1 
> BUSY     11   X2 
> PAPEREND 12   X3 
> SELIN    13   X4 
> 
> (from table 5.6)
> 
> And used D5 as mentioned:
> "The optional backlight wiring should be connected to D5, pin 7."
> 
>> Additionally, when you power on the display, you should see block
>> characters in row 1 and 3 and no characters in row 2 and 4. Does this
>> change if you start LCDd?
> 
> When i power up the display it shows 4 lines of 20 blocks. This does
> not change if i start LCDd.
> Seems to leave in the uninitialized state, which would be plausible
> if the LCDd isn't in 4bit-mode.
> 
> How can i check if the server uses 4bit-mode?
> As mentioned, i can not see a real difference when i change 
> the connection type.
> 
> Very strange...
> 
> Regards, Thorsten
> 

Hi again,

I just tried the connection type (only the display though, no keypad).

When I power up my display it looke like
http://mdolze.gmxhome.de/images/4bit-1.jpg. If I start LCDd, it looks
like http://mdolze.gmxhome.de/images/4bit-2.jpg.

Here is the hd44780 section from LCDd.conf.

[hd44780]
ConnectionType=4bit
Port=0x378
Keypad=no
Backlight=no
OutputPort=no
Size=20x4
Charmap=hd44780_default

I copied in the settings you used and received some garbage on the
screen as my display doesn't use extended mode, but it showed most chars
correctly.

What really puzzles me is that you see 4 lines of blocks after powerup.

Additionally, I tried with a switchable backlight and do see the same
flickering, if "Keypad=yes" is set in LCDd.conf. It is gone if I set
"Keypad=no", which supports what I guessed.

Regards,
Markus

From epooch at cox.net  Thu Dec  3 03:22:43 2009
From: epooch at cox.net (Eric Pooch)
Date: Wed, 2 Dec 2009 19:22:43 -0800
Subject: [Lcdproc] Serial port programming
In-Reply-To: <4B16C26A.3020003@nurfuerspam.de>
References: <4B16C26A.3020003@nurfuerspam.de>
Message-ID: <507C9811-6BFD-43ED-B5CE-4D89147C3754@cox.net>

I just copied the MtxOrb serial code in serialPOS.  Feel free to  
change it and I will test serialPOS.

--Eric


On Dec 2, 2009, at 11:39 AM, Markus Dolze wrote:

> Hi everyone,
>
> during the last days I had a look at the way we initialize serial  
> ports
> to track down the remaining issues with QNX.
>
> I found that most drivers initialize a serial port smiliar to this:
>
>   p->fd = open(device, O_RDWR | O_NOCTTY | O_NDELAY);
>   tcgetattr(p->fd, &portset);
> #ifdef HAVE_CFMAKERAW
>   cfmakeraw(&portset);
> #else
>   portset.c_iflag &= ~( IGNBRK | BRKINT | PARMRK | ISTRIP
>             | INLCR | IGNCR | ICRNL | IXON );
>   portset.c_oflag &= ~OPOST;
>   portset.c_lflag &= ~( ECHO | ECHONL | ICANON | ISIG | IEXTEN );
>   portset.c_cflag &= ~( CSIZE | PARENB | CRTSCTS );
>   portset.c_cflag |= CS8 | CREAD | CLOCAL ;
> #endif
>   cfsetospeed(&portset, speed);
>   cfsetispeed(&portset, speed);
>   tcsetattr(p->fd, TCSANOW, &portset);
>
> Now what's wrong with that?
>
> In our own implementation we clear CRTSCTS and set CREAD and CLOCAL. I
> looked at cfmakeraw() from glibc, FreeBSD, NetBSD and QNX and none  
> of it
> modifies CRTSCTS and CLOCAL. Only FreeBSD sets CREAD.
>
> Therefore these flags may not be in the desired state after cfmakeraw,
> depending how they are configured at the time tcgetattr is used. While
> CRTSCTS may be off by default, CLOCAL is usually not set. As most
> drivers currently work, I suspect that neither CRTSCTS nor CLOCAL are
> really needed.
>
> Additionally it is a mistake to believe /portset/ cannot be modified
> after using cfmakeraw - it can be modified, especially to set the
> timeout values! Some drivers (serialPOS, MtxOrb) refuse to use  
> cfmakeraw
> (by commenting it out) because the author wanted to set timeouts.  
> In the
> CrystalFontz drivers, the complete init routine if contained even  
> twice:
> One time for serial ports using the above code and a second time  
> for USB
> connected displays.
>
> O_NDELAY should probably read O_NONBLOCK, but it seems to work fine on
> our supported platforms.
>
> Therefore, I am short to re-writing the drivers which don't use
> cfmakeraw correctly.
>
> Comments?
>
> Regards,
> Markus
>
> _______________________________________________
> LCDproc mailing list
> LCDproc at lists.omnipotent.net
> http://lists.omnipotent.net/mailman/listinfo/lcdproc


From dl9sec at gmx.net  Thu Dec  3 18:41:19 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Thu, 03 Dec 2009 19:41:19 +0100
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <4B16D598.6000208@nurfuerspam.de>
References: <20091201191709.262770@gmx.net>
	<f4eb766f0912011151w40c204dbh524b35af1ea2f4b2@mail.gmail.com>
	<20091202174011.87960@gmx.net>
	<f4eb766f0912021022p9722b00u7df10c0d164944a@mail.gmail.com>
	<4B16B611.0@nurfuerspam.de> <20091202192411.87960@gmx.net>
	<4B16D598.6000208@nurfuerspam.de>
Message-ID: <20091203184119.145560@gmx.net>

Hi,

> When I power up my display it looke like 4bit-1.jpg. If I start LCDd, it
> looks like 4bit-2.jpg.

Lucky you ;-)

> Here is the hd44780 section from LCDd.conf.
> 
> [hd44780]
> ConnectionType=4bit
> Port=0x378
> Keypad=no
> Backlight=no
> OutputPort=no
> Size=20x4
> Charmap=hd44780_default

I also tried this settings but with no success. 

> What really puzzles me is that you see 4 lines of blocks after powerup.

I don't really care about that. Maybe the EA DIPs RAM is initialized
with other values than the HD44780.

What puzzles me is, that a change of the connection type doesn't seem to
change the behaviour of D0..D7, so i am not sure if the LCDd really
uses the 4bit-mode.
I also tried to compile the package 0.5.3 from the sources but with the
same success. It behaves exactly like the 0.5.2 so i switched back to
the APT-package because the startup scripts are provided and installed
automatically. So maybe it's a general problem with Debian, don't know.

Next i will re-check the ribbon cable against shorts and then maybe i will
try to use an old-style 44780 16x2 LCD just to see if the server works
in general on my SBC.

Maybe someone can take a scope and have a look what happens on D7 in
4bit-mode with no BL and no keypad. Is there a signal?

Regards, Thorsten


From luciusmare at gmail.com  Fri Dec  4 19:43:10 2009
From: luciusmare at gmail.com (Lucius Mare)
Date: Fri, 4 Dec 2009 20:43:10 +0100
Subject: [Lcdproc] Sparkfun
Message-ID: <b617e7c50912041143n389752b2x25f24f7f5d42c33a@mail.gmail.com>

Hello,is it possible to use lcdproc along with the LCDs sold on sparkfun? (
http://www.sparkfun.com/commerce/categories.php?c=148 )
They claim it to be "basic LCD" but I am not sure, I will be making an order
soon, and shipping is costy today, so I want to know it, it would be nice to
buy something along so i wont waste so much on shipping.
Lucius
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20091204/afed196d/attachment.htm>

From ethan.dicks at gmail.com  Fri Dec  4 21:12:50 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Fri, 4 Dec 2009 16:12:50 -0500
Subject: [Lcdproc] Sparkfun
In-Reply-To: <b617e7c50912041143n389752b2x25f24f7f5d42c33a@mail.gmail.com>
References: <b617e7c50912041143n389752b2x25f24f7f5d42c33a@mail.gmail.com>
Message-ID: <f4eb766f0912041312o52e0980ep8b9eef173d2b9eb3@mail.gmail.com>

On 12/4/09, Lucius Mare <luciusmare at gmail.com> wrote:
> Hello,is it possible to use lcdproc along with the LCDs sold on sparkfun? (
> http://www.sparkfun.com/commerce/categories.php?c=148 )
> They claim it to be "basic LCD" but I am not sure, I will be making an order
> soon, and shipping is costy today, so I want to know it, it would be nice to
> buy something along so i wont waste so much on shipping.

The "Basic LCDs" on Sparkfun are ordinary-HD44780-interface LCDs, but
the graphical ones may have controller chips that LCDproc supports -
check the LCDproc documentation for how to attach one of those to your
computer.  If your computer does not happen to have a parallel port,
you will also need to choose and purchase (and possibly construct) a
microcontroller-based "backpack" to do the formatting.   There are
many flavors of those supported by LCDproc - I have built several.
For those, typically, you would need a free serial port or USB port,
depending on which "backpack" interface you decide to go with.  The
"Serial Enabled LCDs" sold by Sparkfun probably do not have an LCDproc
driver at this time (they appear to use ASCII codes below 0x20 for
some cursor functions and codes above 0x80 for positioning, and do not
appear to allow the host to set custom characters).

I do not know anything about the "Graphic LCD Serial Backpack", so I
cannot recommend if it does or does not accept a command set that
LCDproc understands, but if I had to guess, I'd expect it does not.

-ethan

From eldavidillo at hotmail.com  Sun Dec  6 13:29:53 2009
From: eldavidillo at hotmail.com (David Lopez Perez)
Date: Sun, 6 Dec 2009 13:29:53 +0000
Subject: [Lcdproc] FW: [PATCH] spanish "ntilde" in HD44780 driver charmap
Message-ID: <BLU102-W131A1A8541FCEEE04EC513BE910@phx.gbl>


Hello list,

Some time ago, I submitted a patch for lcdproc 0.5.2 to replace three mappings in the default hd44780 charmap with more suitable glyphs. They were:
-the micro symbol (Greek character '?')
-the lowercase ntilde (Spanish character '?')
-the uppercase ntilde (Spanish character '?')

I just tried 0.5.3 and I'm glad to see the mapping for the micro symbol was updated.
However, the issue with the spanish ntilde still stands; it's being mapped as a standard 'n'.
The '?' is a very common letter in Spanish, Portuguese and Galician; the 'n' is not the same and it just wasn't good enough for me ;D so I made another patch for 0.5.3. This time I added a separate mapping in hd44780-charmap.h instead of modifying the default charmap. I'm attaching it here.

--- hd44780-charmap.h-original    2009-12-06 13:00:38.000000000 +0100
+++ hd44780-charmap.h    2009-12-06 13:56:37.000000000 +0100
@@ -241,6 +241,59 @@
         175, 151, 163, 150, 129, 121,  32, 253
 };
 
+/*
+ * HD44780 charset with spanish '?' (ntilde)
+ *
+ * Over the default charmap, the following translations
+ * are being performed:
+ * - map lowercase '?' (ntilde) to the corresponding character
+ * - map uppercase '?' (ntilde) to the same character as above
+ * 
+ */
+
+const unsigned char HD44780_spa_charmap[] = {
+        /* #0 */
+          0,   1,   2,   3,   4,   5,   6,   7,
+          8,   9,  10,  11,  12,  13,  14,  15,
+         16,  17,  18,  19,  20,  21,  22,  23,
+         24,  25,  26,  27,  28,  29,  30,  31,
+        /* #32 */
+         32,  33,  34,  35,  36,  37,  38,  39,
+         40,  41,  42,  43,  44,  45,  46,  47,
+         48,  49,  50,  51,  52,  53,  54,  55,
+         56,  57,  58,  59,  60,  61,  62,  63,
+        /* #64 */
+         64,  65,  66,  67,  68,  69,  70,  71,
+         72,  73,  74,  75,  76,  77,  78,  79,
+         80,  81,  82,  83,  84,  85,  86,  87,
+         88,  89,  90,  91,  47,  93,  94,  95,
+        /* #96 */
+         96,  97,  98,  99, 100, 101, 102, 103,
+        104, 105, 106, 107, 108, 109, 110, 111,
+        112, 113, 114, 115, 116, 117, 118, 119,
+        120, 121, 122, 123, 124, 125, 126, 127,
+        /* #128 */
+        128, 129, 130, 131, 132, 133, 134, 135,
+        136, 137, 138, 139, 140, 141, 142, 143,
+        144, 145, 146, 147, 148, 149, 150, 151,
+        152, 153, 154, 155, 156, 157, 158, 159,
+        /* #160 */
+        160,  33, 236, 237, 164,  92, 124, 167,
+         34, 169, 170, 171, 172, 173, 174, 175,
+        223, 177, 178, 179,  39, 228, 247, 165,
+         44, 185, 186, 187, 188, 189, 190,  63,
+        /* #192 */
+         65,  65,  65,  65, 225,  65,  65,  67,
+         69,  69,  69,  69,  73,  73,  73,  73,
+         68, 238,  79,  79,  79,  79, 239, 120,
+         48,  85,  85,  85, 245,  89, 240, 226,
+        /* #224 */
+         97,  97,  97,  97, 225,  97,  97,  99,
+        101, 101, 101, 101, 105, 105, 105, 105,
+        111, 238, 111, 111, 111, 111, 239, 253,
+         48, 117, 117, 117, 245, 121, 240, 255
+};
+
 #define MAX_CHARMAP_NAME_LENGTH 16
 
 struct charmap {
@@ -251,6 +304,7 @@
 const struct charmap available_charmaps[] = {
     { "hd44780_default", HD44780_charmap      },
     { "hd44780_euro",    HD44780_euro_charmap },
+    { "hd44780_spanish", HD44780_spa_charmap  },
     { "ea_ks0073",       EA_KS0073_charmap    },
     { "sed1278f_0b",     SED1278F_0B_charmap  }
 };


 		 	   		  
_________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20091206/9cb54589/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hd44780-charmap.patch
Type: text/x-patch
Size: 2615 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20091206/9cb54589/attachment-0001.bin>

From dl9sec at gmx.net  Sun Dec  6 17:51:25 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Sun, 06 Dec 2009 18:51:25 +0100
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <20091203184119.145560@gmx.net>
References: <20091201191709.262770@gmx.net>
	<f4eb766f0912011151w40c204dbh524b35af1ea2f4b2@mail.gmail.com>
	<20091202174011.87960@gmx.net>
	<f4eb766f0912021022p9722b00u7df10c0d164944a@mail.gmail.com>
	<4B16B611.0@nurfuerspam.de> <20091202192411.87960@gmx.net>
	<4B16D598.6000208@nurfuerspam.de> <20091203184119.145560@gmx.net>
Message-ID: <20091206175125.324450@gmx.net>

Hi again,

> Next i will re-check the ribbon cable against shorts and then maybe i
> will try to use an old-style 44780 16x2 LCD just to see if the server
> works in general on my SBC.

Done. The ribbon cable is OK, no shorts, no opens.
5 years ago i built a 20x4 usb-driven display for use with jaLCDs.
I disassembled the box and wired the Displaytech 204B as given in the
online help. The result was the same as with my EA DIP204-4.
I can not get the server screen being displayed :-(

Next i played around with the sources and tried to do the initialization
as described in a thread from the german mikrocontroler.net.
I managed to get a weird displaying of changing characters after i
delayed the pauses between the commands. But also no server screen.
The result was not really reproduceable.

It seems, that my parallel port doesn't behave "normal". Maybe my problem
has to do with the idle level of the data pins: they are all pulled high
with 2k2 resistors (described in the manual). When i measure at my 
desktop PC i can see, that the data lines are all low in the idle state.
Maybe that causes the display to fetch the wrong enabling edge and
therefore the wrong data.

Really don't know how to solve this...

Regards, Thorsten

From manio at skyboo.net  Mon Dec  7 06:12:17 2009
From: manio at skyboo.net (Manio)
Date: Mon, 07 Dec 2009 07:12:17 +0100
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <20091206175125.324450@gmx.net>
References: <20091201191709.262770@gmx.net>	<f4eb766f0912011151w40c204dbh524b35af1ea2f4b2@mail.gmail.com>	<20091202174011.87960@gmx.net>	<f4eb766f0912021022p9722b00u7df10c0d164944a@mail.gmail.com>	<4B16B611.0@nurfuerspam.de>
	<20091202192411.87960@gmx.net>	<4B16D598.6000208@nurfuerspam.de>
	<20091203184119.145560@gmx.net> <20091206175125.324450@gmx.net>
Message-ID: <4B1C9CC1.5050801@skyboo.net>

Thorsten Godau wrote:
> It seems, that my parallel port doesn't behave "normal". Maybe my problem
> has to do with the idle level of the data pins: they are all pulled high
> with 2k2 resistors (described in the manual). When i measure at my 
> desktop PC i can see, that the data lines are all low in the idle state.
> Maybe that causes the display to fetch the wrong enabling edge and
> therefore the wrong data.
>
> Really don't know how to solve this...
>   
if you're right about above, so it should work on different hardware, so 
connect
it to some other pc's parallel port and see if it works...

regards,
-- 
manio
jabber/e-mail: manio at skyboo.net
http://manio.skyboo.net

From bsdfan at nurfuerspam.de  Thu Dec 10 21:28:36 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 10 Dec 2009 22:28:36 +0100
Subject: [Lcdproc] Parallel port keyboard issue
Message-ID: <4B216804.7050207@nurfuerspam.de>

Hi,

the hd44780 driver's connection types 4bit and 8bit (lcdtime) currently
do show a flickering backlight if a switchable backlight is used and the
keypad is enabled.

This happens because the pin controlling the backlight is toggled during
the scan for pressed keys as well.

One option is to exclude the backlight pin from the keypad scans. This
means that the available keys are reduced by one line of a matrix keypad
(from 11 to 10 lines) and that users will perhaps have to change their
current wiring IF a keypad with more than 5 lines is used.

Is there any way to handle this in hardware, e.g. using capacitors?

How shall we handle this?

If it is not possible to do solve this in hardware or we do not want to
change the wiring, we have to tell users not to use a switchable
backlight if a keypad is used.

Regards,
Markus

From dl9sec at gmx.net  Sun Dec 13 08:34:47 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Sun, 13 Dec 2009 09:34:47 +0100
Subject: [Lcdproc] Parallel port keyboard issue
In-Reply-To: <4B216804.7050207@nurfuerspam.de>
References: <4B216804.7050207@nurfuerspam.de>
Message-ID: <20091213083447.245570@gmx.net>

Hi,

> Is there any way to handle this in hardware, e.g. using capacitors?

IMHO that is not a real solution.

> How shall we handle this?

My interpretation of the lcdproc-documentation was the following:

Basically all lines are used as Xn and Yn to build a matrix (only
Xn if used as direct key input). According to the used connection 
type, the number of usable keypad lines is reduced.
And so was my understanding for the backlight line too. If "backlight=yes"
then this line is not available for keypad usage and should be masked
out.

For me the actual behaviour of the backlight signal is a bug.

By defining KeyMatrix_X_Y it should be clear, which lines must be 
masked out and scanned.

I think the point is how to handle a double-usage of lines. Who wins?

> If it is not possible to do solve this in hardware or we do not want to
> change the wiring, we have to tell users not to use a switchable
> backlight if a keypad is used.

The software should be de-buged in my opinion, to only use the defined
key-lines...

Regards, Thorsten

From bsdfan at nurfuerspam.de  Sun Dec 13 23:07:03 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 14 Dec 2009 00:07:03 +0100
Subject: [Lcdproc] Parallel port keyboard issue
In-Reply-To: <20091213083447.245570@gmx.net>
References: <4B216804.7050207@nurfuerspam.de> <20091213083447.245570@gmx.net>
Message-ID: <4B257397.8040304@nurfuerspam.de>

Thorsten Godau wrote:
> My interpretation of the lcdproc-documentation was the following:
>
> Basically all lines are used as Xn and Yn to build a matrix (only
> Xn if used as direct key input). According to the used connection 
> type, the number of usable keypad lines is reduced.
> And so was my understanding for the backlight line too. If "backlight=yes"
> then this line is not available for keypad usage and should be masked
> out.
>
> For me the actual behaviour of the backlight signal is a bug.
>
> By defining KeyMatrix_X_Y it should be clear, which lines must be 
> masked out and scanned.
>
> I think the point is how to handle a double-usage of lines. Who wins?
>
>   
>> If it is not possible to do solve this in hardware or we do not want to
>> change the wiring, we have to tell users not to use a switchable
>> backlight if a keypad is used.
>>     
>
> The software should be de-buged in my opinion, to only use the defined
> key-lines...
>
> Regards, Thorsten
>   

Hi,

attached is a patch which corrects the behaviour by excluding the
backlight line when scanning for a keypad. It affects CT '4bit' and
'8bit'. Up to now I have only tested the 4bit CT.

For the 8bit CT the last keypad line is lost, but nothing else has to be
changed. For the 4bit CT however, any existing keypad wirings using more
than 5 rows have to be changed.

Right now the patch does not do it, but if necessary it could be
extended so that the previous behaviour could be restored by setting
some option.

Regards,
Markus
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-hd44780-keypad.diff
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20091214/89a282c8/attachment.asc>

From bsdfan at nurfuerspam.de  Sun Dec 13 23:11:08 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 14 Dec 2009 00:11:08 +0100
Subject: [Lcdproc] Serial port programming
In-Reply-To: <4B16C26A.3020003@nurfuerspam.de>
References: <4B16C26A.3020003@nurfuerspam.de>
Message-ID: <4B25748C.4050904@nurfuerspam.de>

Markus Dolze wrote:
> ...
>
> Additionally it is a mistake to believe /portset/ cannot be modified
> after using cfmakeraw - it can be modified, especially to set the
> timeout values! Some drivers (serialPOS, MtxOrb) refuse to use cfmakeraw
> (by commenting it out) because the author wanted to set timeouts. In the
> CrystalFontz drivers, the complete init routine if contained even twice:
> One time for serial ports using the above code and a second time for USB
> connected displays.
>
> ...
>
> Therefore, I am short to re-writing the drivers which don't use
> cfmakeraw correctly.
>   

Hi,

as said above, I have rewritten the serial initialization for several
drivers to use cfmakeraw: CFontz, CFontz633, CFontzPacket, CwLnx,
EyeboxOne, MtxOrb, hd44780-lis2, serialPOS.

Before committing this, I ask you to test it if you own one of the named
devices.

I have tested a MtxOrb LK202-25 myself for now.

Regards,
Markus
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-serial.diff
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20091214/b175556d/attachment.txt>

From bsdfan at nurfuerspam.de  Sun Dec 13 23:13:07 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 14 Dec 2009 00:13:07 +0100
Subject: [Lcdproc] Removing win32 support
In-Reply-To: <4AC76E58.9080401@nurfuerspam.de>
References: <4AC76E58.9080401@nurfuerspam.de>
Message-ID: <4B257503.30808@nurfuerspam.de>

Markus Dolze wrote:
> Hi,
>
> when was the last time someone successfully compiled LCDproc natively
> for win32?
>
> There are several conditionals scattered across the code for win32,
> but I doubt anyone is using them. Note that I am talking about
> compiling it natively, not using Cygwin!
>
> For Windows there are far more advanced solutions available (i.e.
> LCDHype, LCD Smartie).
>
> Instead of trying to catch up on the latest Windows version I'd like
> to remove these parts from LCDproc.
>
> So - if nobody requires win32 support for LCDproc, I am going to
> remove it.
>
> Regards,
> Markus

Hi,

here is a patch that removes win32 support. If I receive no objections I
will commit it.

Regards,
Markus

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-remove-win32.diff
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20091214/28c71811/attachment.asc>

From bsdfan at nurfuerspam.de  Sun Dec 13 23:28:51 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Mon, 14 Dec 2009 00:28:51 +0100
Subject: [Lcdproc] [PATCH] 2 wrong symbols in HD44780 driver charmap
In-Reply-To: <4AB6A72A.31441.2D04E7@joris.robijn.net>
References: <BLU102-W12B64077869F2E4C1E9543BEE00@phx.gbl>,
	<20090918074700.5B6381C9DB6@wizard.robijn.net>,
	<BLU102-W6D60ECC9CF0CAFD95D4B5BEDE0@phx.gbl>
	<4AB6A72A.31441.2D04E7@joris.robijn.net>
Message-ID: <4B2578B3.9000700@nurfuerspam.de>

Joris Robijn wrote:
> Hi David,
>
> You're right about the chars. 
> standard and default maps sounds good.
>
> In the past a lot of displays with an "inverted P" as char 255 came up... 
> I do not remember which "compatible" controller that was, but I'm sure it 
> has a completely different charset.
>
>   
>>> Some years ago we defined to translate from ISO 8859-1. Since -15 is
>>> practically compatible maybe that one is better. You can always add your
>>> own translation char set. Maybe more of these should exist to choose
>>> from for "almost compatible" displays. Why don't these manufacturers
>>> just stick to the existing standard ?
>>>       
>> That's the beautiful thing about standards: there are so many to choose
>> from...
>>     
>
> Ah yes I see, so they add more to make us happy ;)
>
> Joris
>
>   
Hi,

I only followed that discussion loosely until David submitted a 'spanish
charmap' a few days ago. Looking at our available charmaps, I see no
reason why not to map ? or ? to the 'n with above dash' character.

The datasheet for HD44780U from Hitachi shows this character. I have
checked with all displays available to me, and they show that character,
even if the use different controllers.

Beside that, to help testing character sets, I added a 'none' charmap
(patch attached), which does not translate anything. Use this in
combination with the charset demo from the testmenu (./configure
--enable-testmenus). You need a keypad to make use of it!

Additionally I found a typo in the euro_charmap and the charset demo
code which I will fix soon.

Regards,
Markus
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-charmap-none.diff
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20091214/1c06bfcf/attachment.txt>

From satzklauer at googlemail.com  Mon Dec 14 07:44:00 2009
From: satzklauer at googlemail.com (Satz Klauer)
Date: Mon, 14 Dec 2009 08:44:00 +0100
Subject: [Lcdproc] Removing win32 support
In-Reply-To: <4B257503.30808@nurfuerspam.de>
References: <4AC76E58.9080401@nurfuerspam.de> <4B257503.30808@nurfuerspam.de>
Message-ID: <2c26506d0912132344p80e53d3uaff07786d2c831bc@mail.gmail.com>

Not a good idea in my opinion. What is the advantage of losing support
for a platform completely (while patches that offer support for other
platforms are ignored)? Or what is the advantage for somebody who
would try to re-implement the W32 parts some times? That person would
have to start from scratch...

On 12/14/09, Markus Dolze <bsdfan at nurfuerspam.de> wrote:
> Markus Dolze wrote:
>> Hi,
>>
>> when was the last time someone successfully compiled LCDproc natively
>> for win32?
>>
>> There are several conditionals scattered across the code for win32,
>> but I doubt anyone is using them. Note that I am talking about
>> compiling it natively, not using Cygwin!
>>
>> For Windows there are far more advanced solutions available (i.e.
>> LCDHype, LCD Smartie).
>>
>> Instead of trying to catch up on the latest Windows version I'd like
>> to remove these parts from LCDproc.
>>
>> So - if nobody requires win32 support for LCDproc, I am going to
>> remove it.
>>
>> Regards,
>> Markus
>
> Hi,
>
> here is a patch that removes win32 support. If I receive no objections I
> will commit it.
>
> Regards,
> Markus
>
>

From dl9sec at gmx.net  Mon Dec 14 19:51:38 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Mon, 14 Dec 2009 20:51:38 +0100
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <4B1C9CC1.5050801@skyboo.net>
References: <20091201191709.262770@gmx.net>
	<f4eb766f0912011151w40c204dbh524b35af1ea2f4b2@mail.gmail.com>
	<20091202174011.87960@gmx.net>
	<f4eb766f0912021022p9722b00u7df10c0d164944a@mail.gmail.com>
	<4B16B611.0@nurfuerspam.de>	<20091202192411.87960@gmx.net>
	<4B16D598.6000208@nurfuerspam.de>	<20091203184119.145560@gmx.net>
	<20091206175125.324450@gmx.net> <4B1C9CC1.5050801@skyboo.net>
Message-ID: <20091214195138.317610@gmx.net>

Hi,

good and a bad news!

The good news: i got my display (mostly) running at the parallel port.
The bad news: i did it with lcd4linux and NOT with lcdproc.

It was a desperate try with another similar LCD-driver. So i did a
quich'n'dirty minimal configuration for my display and used the
HD44780/model HD66712 driver (the HD66712 seems to be a similar LCD
with a KS0073 on it).

After uninstall the lcdproc i installed lcd4linux via apt-get, put
my conf-file to /etc and started lcd4linux.

Tadaaaa! Readable characters appearing on my display. It seems that the
model-specific driver doesn't fit exactly to my display, anyway there
were meaningful characters on it.

So my pp is running and my display-hardware doesn't seem to have serious
bugs.

lcd4linux isn't a real alternative for me because it doesn't support
the EA DIP204-4 directly with its specialities and (the worse thing) it
doesn't really support a freely configurable keypad matrix. So my final
aim is to have lcdproc running on my machine, not lcd4linux.

But the question is now, what's going wrong with the EA DIP204-4 and
LCDd? Is there any user out there, who gets this LCD working with LCDd
in 4bit-mode?

Regards, Thorsten

From bsdfan at nurfuerspam.de  Thu Dec 17 10:14:44 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 17 Dec 2009 11:14:44 +0100
Subject: [Lcdproc] Parallel port keyboard issue
In-Reply-To: <4B257397.8040304@nurfuerspam.de>
References: <4B216804.7050207@nurfuerspam.de> <20091213083447.245570@gmx.net>
	<4B257397.8040304@nurfuerspam.de>
Message-ID: <4B2A0494.9030705@nurfuerspam.de>

Markus Dolze wrote:
> Thorsten Godau wrote:
>   
>> My interpretation of the lcdproc-documentation was the following:
>>
>> Basically all lines are used as Xn and Yn to build a matrix (only
>> Xn if used as direct key input). According to the used connection 
>> type, the number of usable keypad lines is reduced.
>> And so was my understanding for the backlight line too. If "backlight=yes"
>> then this line is not available for keypad usage and should be masked
>> out.
>>
>> For me the actual behaviour of the backlight signal is a bug.
>>
>> By defining KeyMatrix_X_Y it should be clear, which lines must be 
>> masked out and scanned.
>>
>> I think the point is how to handle a double-usage of lines. Who wins?
>>
>>   
>>     
>>> If it is not possible to do solve this in hardware or we do not want to
>>> change the wiring, we have to tell users not to use a switchable
>>> backlight if a keypad is used.
>>>     
>>>       
>> The software should be de-buged in my opinion, to only use the defined
>> key-lines...
>>
>> Regards, Thorsten
>>   
>>     
>
> Hi,
>
> attached is a patch which corrects the behaviour by excluding the
> backlight line when scanning for a keypad. It affects CT '4bit' and
> '8bit'. Up to now I have only tested the 4bit CT.
>
> For the 8bit CT the last keypad line is lost, but nothing else has to be
> changed. For the 4bit CT however, any existing keypad wirings using more
> than 5 rows have to be changed.
>
> Right now the patch does not do it, but if necessary it could be
> extended so that the previous behaviour could be restored by setting
> some option.
>   
Hi,

I updated the patch. It now takes into account if a switchable backlight
is configured or not. If it is, it's line is excluded from the keypad scan.

So, for anyone who is currently using a keypad with more than 5 rows but
no switchable backlight nothing changes.

Also, I was asking myself why nobody complained about the flickering
backlight before. It turns out that usually the keypad checks run too
fast to see the effect on the backlight. In this specific case
DelayBus=true and DelayMult=4 were set. This makes the problem more visible.

Regards,
Markus
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch-hd44780-keypad-v2.diff
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20091217/44094ad0/attachment.asc>

From bsdfan at nurfuerspam.de  Thu Dec 17 10:19:25 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Thu, 17 Dec 2009 11:19:25 +0100
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <20091214195138.317610@gmx.net>
References: <20091201191709.262770@gmx.net>	<f4eb766f0912011151w40c204dbh524b35af1ea2f4b2@mail.gmail.com>	<20091202174011.87960@gmx.net>	<f4eb766f0912021022p9722b00u7df10c0d164944a@mail.gmail.com>	<4B16B611.0@nurfuerspam.de>	<20091202192411.87960@gmx.net>	<4B16D598.6000208@nurfuerspam.de>	<20091203184119.145560@gmx.net>	<20091206175125.324450@gmx.net>
	<4B1C9CC1.5050801@skyboo.net> <20091214195138.317610@gmx.net>
Message-ID: <4B2A05AD.7030002@nurfuerspam.de>

Thorsten Godau wrote:
> But the question is now, what's going wrong with the EA DIP204-4 and
> LCDd? Is there any user out there, who gets this LCD working with LCDd
> in 4bit-mode?
>
>   

Hi,

searching with Google shows that several other people have problems with
this display, most times because of the different initialization
sequence for the KS0073 and for the reset pin that display has (found
this http://www.mikrocontroller.net/topic/79603, in german only).

The KS0073's init sequence should already be supported by lcdproc's
ExtendedMode=yes option.

I'm thinking of getting a DIP204 myself for testing, but this will not
happen within the next two weeks.

Regards,
Markus


From ronc at depauw.edu  Fri Dec 18 07:03:44 2009
From: ronc at depauw.edu (Ron Croonenberg)
Date: Fri, 18 Dec 2009 02:03:44 -0500
Subject: [Lcdproc] lcdproc with sureelec driver
Message-ID: <4B2B2950.1030209@depauw.edu>

Hello,

I am trying to compile lcdproc with the SureElec driver.
When I download it from http://lcdproc.org/download.php3 the driver 
doesn't seem to be in there (neither for 0.5.2 nor 0.5.3)

I tried to install the SureElec patch, but that one seems to not run 
completely correct.

what version do I download to compile lcdproc with the SureElec driver? 
(Or what patch do I use for 0.5.2 or 0.5.3?)

thanks,

Ron


From bsdfan at nurfuerspam.de  Fri Dec 18 07:49:56 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Fri, 18 Dec 2009 08:49:56 +0100
Subject: [Lcdproc] lcdproc with sureelec driver
In-Reply-To: <4B2B2950.1030209@depauw.edu>
References: <4B2B2950.1030209@depauw.edu>
Message-ID: <4B2B3424.6050707@nurfuerspam.de>

Ron Croonenberg wrote:
> Hello,
>
> I am trying to compile lcdproc with the SureElec driver.
> When I download it from http://lcdproc.org/download.php3 the driver 
> doesn't seem to be in there (neither for 0.5.2 nor 0.5.3)
>
> I tried to install the SureElec patch, but that one seems to not run 
> completely correct.
>
> what version do I download to compile lcdproc with the SureElec 
> driver? (Or what patch do I use for 0.5.2 or 0.5.3?)
>
> thanks,
>
> Ron

Hi,

the SureElec driver is only available from CVS. You may get a snapshot 
of CVS from http://lcdproc.sourceforge.net/nightly/. Use the "current" 
branch.

Regards,
Markus

From ronc at depauw.edu  Fri Dec 18 07:59:05 2009
From: ronc at depauw.edu (Ron Croonenberg)
Date: Fri, 18 Dec 2009 02:59:05 -0500
Subject: [Lcdproc] lcdproc with sureelec driver
In-Reply-To: <4B2B3424.6050707@nurfuerspam.de>
References: <4B2B2950.1030209@depauw.edu> <4B2B3424.6050707@nurfuerspam.de>
Message-ID: <4B2B3649.4070308@depauw.edu>

Markus Dolze wrote:
> Ron Croonenberg wrote:
>> Hello,
>>
>> I am trying to compile lcdproc with the SureElec driver.
>> When I download it from http://lcdproc.org/download.php3 the driver 
>> doesn't seem to be in there (neither for 0.5.2 nor 0.5.3)
>>
>> I tried to install the SureElec patch, but that one seems to not run 
>> completely correct.
>>
>> what version do I download to compile lcdproc with the SureElec 
>> driver? (Or what patch do I use for 0.5.2 or 0.5.3?)
>>
>> thanks,
>>
>> Ron
>
> Hi,
>
> the SureElec driver is only available from CVS. You may get a snapshot 
> of CVS from http://lcdproc.sourceforge.net/nightly/. Use the "current" 
> branch.
>
> Regards,
> Markus
Hi Markus,

I figured out it was in CVS,  I downloaded it.  However the driver 
doesn't get compiled.
(I am wonderng if that is a bug or my brain at late hours).

thanks for your reply !

Ron


-- 
==================================================================
main(p){printf(p,34,p="main(p){printf(p,34,p=%c%s%c,34); }",34); }
==================================================================
 Ron Croonenberg                   |
                                   | Phone: 1 765 658 4761
 Lab Instructor &                  | Fax:   1 765 658 4732
         Technology Coordinator    |
                                   |
 Department of Computer Science    | e-mail: ronc at DePauw.edu
 DePauw University                 |
 275 Julian Science & Math Center  |
 602 South College Ave.            |
 Greencastle, IN  46135            |
================================================================== 


From ronc at depauw.edu  Fri Dec 18 08:14:04 2009
From: ronc at depauw.edu (Ron Croonenberg)
Date: Fri, 18 Dec 2009 03:14:04 -0500
Subject: [Lcdproc] lcdproc with sureelec driver
In-Reply-To: <4B2B3424.6050707@nurfuerspam.de>
References: <4B2B2950.1030209@depauw.edu> <4B2B3424.6050707@nurfuerspam.de>
Message-ID: <4B2B39CC.1070309@depauw.edu>

Markus Dolze wrote:
> Ron Croonenberg wrote:
>> Hello,
>>
>> I am trying to compile lcdproc with the SureElec driver.
>> When I download it from http://lcdproc.org/download.php3 the driver 
>> doesn't seem to be in there (neither for 0.5.2 nor 0.5.3)
>>
>> I tried to install the SureElec patch, but that one seems to not run 
>> completely correct.
>>
>> what version do I download to compile lcdproc with the SureElec 
>> driver? (Or what patch do I use for 0.5.2 or 0.5.3?)
>>
>> thanks,
>>
>> Ron
>
> Hi,
>
> the SureElec driver is only available from CVS. You may get a snapshot 
> of CVS from http://lcdproc.sourceforge.net/nightly/. Use the "current" 
> branch.
>
> Regards,
> Markus
I messed around in the configure a bit (not that elegant)  but I get it 
to compile now.

Ron

From ronc at depauw.edu  Sat Dec 19 00:04:26 2009
From: ronc at depauw.edu (Ron Croonenberg)
Date: Fri, 18 Dec 2009 19:04:26 -0500
Subject: [Lcdproc] lcdproc with sureelec driver
In-Reply-To: <4B2B3424.6050707@nurfuerspam.de>
References: <4B2B2950.1030209@depauw.edu> <4B2B3424.6050707@nurfuerspam.de>
Message-ID: <4B2C188A.5020605@depauw.edu>

I have the SureElec driver working now.

is there a manual/guide somewhere with a bunch of examples that show how 
to get text on the LCD with lcdproc? (I know there are some examples in 
the LCDproc distribution, but like to see a few good examples. (either a 
few telnet sessions, c code examples etc.)

thanks,

Ron


From kyle at lodge.glasgownet.com  Sat Dec 19 21:23:52 2009
From: kyle at lodge.glasgownet.com (Kyle Gordon)
Date: Sat, 19 Dec 2009 21:23:52 +0000
Subject: [Lcdproc] SureElec minor bug
Message-ID: <1261257832.26812.17.camel@localhost>

Hi all,

I was just playing around with the SureElec driver, and it's all working
beautifully... except one little bit :-)

It understandably defaults to /dev/ttyUSB0, but it refuses to listen to
the Port= directive in /usr/local/etc/LCDd.conf. Setting it
to /dev/ttyUSB1 would be handy in my situation.

I'm not a programmer, but I'm sure someone might know how to fix it. In
the meantime I've tweaked SureElec.h to get me by :-)

Cheers

Kyle


From bsdfan at nurfuerspam.de  Sat Dec 19 21:47:58 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sat, 19 Dec 2009 22:47:58 +0100
Subject: [Lcdproc] SureElec minor bug
In-Reply-To: <1261257832.26812.17.camel@localhost>
References: <1261257832.26812.17.camel@localhost>
Message-ID: <20091219214758.130490@gmx.net>


-------- Original-Nachricht --------
> Datum: Sat, 19 Dec 2009 21:23:52 +0000
> Von: Kyle Gordon <kyle at lodge.glasgownet.com>
> An: lcdproc at lists.omnipotent.net
> Betreff: [Lcdproc] SureElec minor bug

> Hi all,
> 
> I was just playing around with the SureElec driver, and it's all working
> beautifully... except one little bit :-)
> 
> It understandably defaults to /dev/ttyUSB0, but it refuses to listen to
> the Port= directive in /usr/local/etc/LCDd.conf. Setting it
> to /dev/ttyUSB1 would be handy in my situation.
> 
> I'm not a programmer, but I'm sure someone might know how to fix it. In
> the meantime I've tweaked SureElec.h to get me by :-)
> 
> Cheers
> 
> Kyle
> 

Hi,

Ups. Using 'Device=' instead of 'Port=' will work.

@Laurent: How should it correctly be named? 'Device' sounds a bit more reasonable, as one puts in a device name there.

Regards,
Markus

From kyle at lodge.glasgownet.com  Sat Dec 19 22:53:53 2009
From: kyle at lodge.glasgownet.com (Kyle Gordon)
Date: Sat, 19 Dec 2009 22:53:53 +0000
Subject: [Lcdproc] SureElec minor bug
In-Reply-To: <20091219214758.130490@gmx.net>
References: <1261257832.26812.17.camel@localhost>
	<20091219214758.130490@gmx.net>
Message-ID: <1261263233.26812.19.camel@localhost>

On Sat, 2009-12-19 at 22:47 +0100, Markus Dolze wrote:
> -------- Original-Nachricht --------
> > Datum: Sat, 19 Dec 2009 21:23:52 +0000
> > Von: Kyle Gordon <kyle at lodge.glasgownet.com>
> > An: lcdproc at lists.omnipotent.net
> > Betreff: [Lcdproc] SureElec minor bug
> 
> > Hi all,
> > 
> > I was just playing around with the SureElec driver, and it's all working
> > beautifully... except one little bit :-)
> > 
> > It understandably defaults to /dev/ttyUSB0, but it refuses to listen to
> > the Port= directive in /usr/local/etc/LCDd.conf. Setting it
> > to /dev/ttyUSB1 would be handy in my situation.
> > 
> > I'm not a programmer, but I'm sure someone might know how to fix it. In
> > the meantime I've tweaked SureElec.h to get me by :-)
> > 
> > Cheers
> > 
> > Kyle
> > 
> 
> Hi,
> 
> Ups. Using 'Device=' instead of 'Port=' will work.
> 
> @Laurent: How should it correctly be named? 'Device' sounds a bit more reasonable, as one puts in a device name there.
> 
> Regards,
> Markus
> 
Ah, excellent, that does the job!

For the record, the example LCDd.conf uses Port=, so that would be an
easy fix to start with :-)

Many thanks

Kyle


From laurent at latil.nom.fr  Sun Dec 20 09:58:49 2009
From: laurent at latil.nom.fr (Laurent Latil)
Date: Sun, 20 Dec 2009 10:58:49 +0100
Subject: [Lcdproc] SureElec minor bug
In-Reply-To: <20091219214758.130490@gmx.net>
References: <1261257832.26812.17.camel@localhost>
	<20091219214758.130490@gmx.net>
Message-ID: <200912201058.59584.laurent@latil.nom.fr>

  Hi,

> Ups. Using 'Device=' instead of 'Port=' will work.

Yes, the right option to use is 'Device' actually    :-)

I noticed that the documentation of the driver was wrong  (as it describes a 
Port= option    :-(   ).

Sorry about that,  I didn't check correctly the options in the doc. 

> @Laurent: How should it correctly be named? 'Device' sounds a bit more
>  reasonable, as one puts in a device name there.

Well, I have no strong idea on how to name it.  It chose the Device name for 
the option as it sounded reasonable (as you wrote), and others drivers use 
this option name as well  (like the Matrix Orbital driver).

But the doc. for this driver option is screwed sadly. 


So for the actual option name, we can either:

- Continue to use the Device=   (and fix the documentation accordingly, of 
course)
- Use the Port= name
- Accept both options (Device and/or Port) in the configuration file.


So do not hesitate to tell me your opinion.  And according to the chosen 
option name I will send you a patch today Markus.

   BTW: Thanks Kyle for your (minor ;-) ) bug report and feed-back.

-- 

	- Laurent Latil -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20091220/51a6cb47/attachment.pgp>

From bsdfan at nurfuerspam.de  Sun Dec 20 11:21:31 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 20 Dec 2009 12:21:31 +0100
Subject: [Lcdproc] SureElec minor bug
In-Reply-To: <200912201058.59584.laurent@latil.nom.fr>
References: <1261257832.26812.17.camel@localhost>
	<20091219214758.130490@gmx.net>
	<200912201058.59584.laurent@latil.nom.fr>
Message-ID: <20091220112131.113150@gmx.net>

-------- Original-Nachricht --------
> Datum: Sun, 20 Dec 2009 10:58:49 +0100
> Von: Laurent Latil <laurent at latil.nom.fr>
> An: "Markus Dolze" <bsdfan at nurfuerspam.de>
> CC: Kyle Gordon <kyle at lodge.glasgownet.com>, lcdproc at lists.omnipotent.net
> Betreff: Re: [Lcdproc] SureElec minor bug

> So for the actual option name, we can either:
> 
> - Continue to use the Device=   (and fix the documentation accordingly, of
> course)
> - Use the Port= name
> - Accept both options (Device and/or Port) in the configuration file.
> 

Hi,

I changed LCDd.conf and documentation to use 'Device'. This is now fixed in latest CVS and will appear in the next nightly snapshot.

Regards,
Markus

From laurent at latil.nom.fr  Sun Dec 20 17:05:42 2009
From: laurent at latil.nom.fr (Laurent Latil)
Date: Sun, 20 Dec 2009 18:05:42 +0100
Subject: [Lcdproc] SureElec minor bug
In-Reply-To: <20091220112131.113150@gmx.net>
References: <1261257832.26812.17.camel@localhost>
	<200912201058.59584.laurent@latil.nom.fr>
	<20091220112131.113150@gmx.net>
Message-ID: <200912201805.47344.laurent@latil.nom.fr>


> I changed LCDd.conf and documentation to use 'Device'. This is now fixed in
>  latest CVS and will appear in the next nightly snapshot.

Many thanks for your involvement Markus.


-- 

	- Laurent Latil -
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20091220/4936065f/attachment.pgp>

From kyle at lodge.glasgownet.com  Mon Dec 21 17:35:48 2009
From: kyle at lodge.glasgownet.com (Kyle Gordon)
Date: Mon, 21 Dec 2009 17:35:48 +0000
Subject: [Lcdproc] Bignum and Python
Message-ID: <1261416948.2567.12.camel@localhost>

Evening all,

Well, so far so good with pylcd borrowed from the Freevo CVS tree. My
next step is bigger characters. I'm having some troubles even finding
out whether it's supported or not with the SureElec driver, or PyLCD. I
see from SmartieLCD that it is supported in Windows, and it works well. 

Is anyone able to provide some examples or links to Python examples? I
see from the dev guide that I should be able to use a widget type of
num, and I think you just set the data with an X coordinate. Is it
possible to have the first half of the screen a 4 line character or two,
and the last half be 4 normal lines or 2 double height lines?

Many thanks :-)

Kyle


From marco-glatz at web.de  Tue Dec 22 16:14:52 2009
From: marco-glatz at web.de (Marco Glatz)
Date: Tue, 22 Dec 2009 17:14:52 +0100
Subject: [Lcdproc] SED1300F
Message-ID: <4B30F07C.8020905@web.de>

hello,

i have here an Epson 40x4 EA-Y40047AT lcd-display with two SED1300F 
controllers on it.

- i have only the pinout for the controllers. does anybody has a 
datasheet for this display?

- can i use this display with lcdproc? i only found SED1330 and SED1520 
drivers.

- can someone help me with wiring a 40x4 display on the parallel port?



regards,
marco

From ethan.dicks at gmail.com  Tue Dec 22 20:12:10 2009
From: ethan.dicks at gmail.com (Ethan Dicks)
Date: Tue, 22 Dec 2009 15:12:10 -0500
Subject: [Lcdproc] SED1300F
In-Reply-To: <4B30F07C.8020905@web.de>
References: <4B30F07C.8020905@web.de>
Message-ID: <f4eb766f0912221212j4e304b3bq2dc8356d32d5dfe3@mail.gmail.com>

On Tue, Dec 22, 2009 at 11:14 AM, Marco Glatz <marco-glatz at web.de> wrote:
> i have here an Epson 40x4 EA-Y40047AT lcd-display with two SED1300F
> controllers on it.
>
> - i have only the pinout for the controllers. does anybody has a datasheet
> for this display?

I could not find any documentation for this display.  Can you post the
pinout you have?

> - can i use this display with lcdproc? i only found SED1330 and SED1520
> drivers.

The SED1330 and SED1520 are graphic drivers.  If your display is
character-cell, not graphical, it's likely (but not guaranteed) that
you need some variety of the HD44780 driver.

> - can someone help me with wiring a 40x4 display on the parallel port?

If you have a textual display, have a look in the LCDproc docs on how
to wire up a display with two enable lines.  From there, you have to
have the right entry in your LCDd.conf to tell LCDd that you have two
"panels" and if they are top-bottom or left-right for stitching them
together (your clients don't see this because LCDd presents a single,
intact virtual screen surface).

Post your pinout and that should help direct the help towards what
sort of cable/interface adapter you'd need to build.

-ethan

From marco-glatz at web.de  Tue Dec 22 20:24:21 2009
From: marco-glatz at web.de (Marco Glatz)
Date: Tue, 22 Dec 2009 21:24:21 +0100
Subject: [Lcdproc] SED1300F
In-Reply-To: <f4eb766f0912221212j4e304b3bq2dc8356d32d5dfe3@mail.gmail.com>
References: <4B30F07C.8020905@web.de>
	<f4eb766f0912221212j4e304b3bq2dc8356d32d5dfe3@mail.gmail.com>
Message-ID: <4B312AF5.7020406@web.de>

Ethan Dicks schrieb:
> On Tue, Dec 22, 2009 at 11:14 AM, Marco Glatz <marco-glatz at web.de> wrote:
> If you have a textual display, have a look in the LCDproc docs on how
> to wire up a display with two enable lines.  From there, you have to
> have the right entry in your LCDd.conf to tell LCDd that you have two
> "panels" and if they are top-bottom or left-right for stitching them
> together (your clients don't see this because LCDd presents a single,
> intact virtual screen surface).
> 
> Post your pinout and that should help direct the help towards what
> sort of cable/interface adapter you'd need to build.


hello,

first message was sent directly to ethan, sorry my fault.
these are the pinouts of the controller from the SED1300F datasheet:

1 Vdd (5V)
2 CD
3 ENB
4 RD
5 WR
6 A0
7 D0
8 D1
9 D2
10 D3
11 D4
12 D5
13 D6
14 D7
15 NC
16 Reset
17 Vout (?)
18 Vss (?)

from what i understood from the datasheet is pin 17 is for contrast and 
pin18 is simply ground.


regards
marco

From bsdfan at nurfuerspam.de  Wed Dec 23 14:50:36 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Wed, 23 Dec 2009 15:50:36 +0100
Subject: [Lcdproc] SED1300F
In-Reply-To: <4B30F07C.8020905@web.de>
References: <4B30F07C.8020905@web.de>
Message-ID: <4B322E3C.4020001@nurfuerspam.de>

Hi,

Marco Glatz wrote:
> hello,
>
> i have here an Epson 40x4 EA-Y40047AT lcd-display with two SED1300F 
> controllers on it.
>
> - i have only the pinout for the controllers. does anybody has a 
> datasheet for this display?
No, the best thing I could bring up is 
http://www.dougrice.plus.com/hp/LCD1300/index.html. He has an example of 
how to connect a smiliar display to an microprocessor and a scanned 
datasheet for the EA X-series of displays which are said to use the same 
controller.

>
> - can i use this display with lcdproc? i only found SED1330 and 
> SED1520 drivers.
The SED1330/1520 are used for graphical displays, something different.

> - can someone help me with wiring a 40x4 display on the parallel port?
>
I am not sure if it will work. Besides the 8 data pins, several control 
pins are used. This is what I read from the EA X-series datasheet:

    * It uses two active low pins for write (-WR) and read (-RD)
      operations. -RD should be connected to +5V.
    * -CS (active low) selects the display, much like the 'E' line on
      HD44780, but this one is active low as well.
    * You may get away with connecting -CS to GND and use -WR as 'E' for
      our hd44780 driver. If this does not work, you will have to
      connect -WR to GND and use -CS _and an inverter_ as 'E'.
    * A0 pin distincts between instructions and data operations like the
      'RS' line on a HD44780.
    * RESET can be left open, as it is said to have an internal pull-up.
    * ENB will be difficult. According to the datasheet it supplies an
      external clock signal of 500KHz to 2MHz. This is nothing that can
      be created with LCDproc.
    * The instruction set is similar to HD44780, but there is no
      information on the memory adressing and initialization rountine
      available. It may work with the hd44780 driver, or not.

Good luck,
Markus


From marco-glatz at web.de  Wed Dec 23 15:59:27 2009
From: marco-glatz at web.de (Marco Glatz)
Date: Wed, 23 Dec 2009 16:59:27 +0100
Subject: [Lcdproc] SED1300F
Message-ID: <179585235@web.de>

> -----Urspr?ngliche Nachricht-----
> Von: "Markus Dolze" <bsdfan at nurfuerspam.de>
> Gesendet: 23.12.09 15:49:26
> An: Marco Glatz <marco-glatz at web.de>
> CC: lcdproc at lists.omnipotent.net
> Betreff: Re: [Lcdproc] SED1300F


> I am not sure if it will work. Besides the 8 data pins, several control 
> pins are used. This is what I read from the EA X-series datasheet:
> 
>     * It uses two active low pins for write (-WR) and read (-RD)
>       operations. -RD should be connected to +5V.
>     * -CS (active low) selects the display, much like the 'E' line on
>       HD44780, but this one is active low as well.
>     * You may get away with connecting -CS to GND and use -WR as 'E' for
>       our hd44780 driver. If this does not work, you will have to
>       connect -WR to GND and use -CS _and an inverter_ as 'E'.
>     * A0 pin distincts between instructions and data operations like the
>       'RS' line on a HD44780.
>     * RESET can be left open, as it is said to have an internal pull-up.
>     * ENB will be difficult. According to the datasheet it supplies an
>       external clock signal of 500KHz to 2MHz. This is nothing that can
>       be created with LCDproc.
>     * The instruction set is similar to HD44780, but there is no
>       information on the memory adressing and initialization rountine
>       available. It may work with the hd44780 driver, or not.


hello,

after some more searching, i found this: http://www.netikka.net/ville.vieri/ele/lcd.htm

there is a small schematic for the ENB line using a 74HC14, i have some of them laying around here, so i will give it a try.


regards,
marco


___________________________________________________________
Preisknaller: WEB.DE DSL Flatrate f?r nur 16,99 Euro/mtl.! 
http://produkte.web.de/go/02/


From dl9sec at gmx.net  Wed Dec 23 19:29:40 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Wed, 23 Dec 2009 20:29:40 +0100
Subject: [Lcdproc] 4bit-HD44780 and keymatrix...
In-Reply-To: <179585235@web.de>
References: <179585235@web.de>
Message-ID: <20091223192940.107220@gmx.net>

Hi all,

as described in a thread above, i am using a EA DIP204-4 (HD44780->KS0073)
connected the "4bit"-way to the parallel port.
As i undestood the documentation, the other signals, that are not used
for display control can be used for a keymatrix and defined and enabled
as per an entry "keymatrix_X_Y" in the configuration file.

My keymatrix is the following:

  +5V ----------+---------+--------+---------+
                |         |        |         |
               22k       22k      22k       22k
                |         |        |         |
   Y7 -|<|--+---------+--------+---------+   |
            |   |     |   |    |   |     |   |
            o   |     o   |    o   |     o   |
          S1 \  |   S2 \  |  S3 \  |   S4 \  |
            o   |     o   |    o   |     o   |
            |   |     |   |    |   |     |   |
            +---+     +---+    +---+     +---+
                |         |        |         |
                |         |        |         |
   Y8 -|<|--+------------------+---------+   |
            |   |         |    |   |     |   |
            o   |         |    o   |     o   |
          S5 \  |         |  S6 \  |   S7 \  |
            o   |         |    o   |     o   |
            |   |         |    |   |     |   |
            +---+         |    +---+     +---+
                |         |        |         |
   X1 ----------+         |        |         |
                          |        |         |
   X2 --------------------+        |         |
                                   |         |
   X3 -----------------------------+         |
                                             |
   X4 ---------------------------------------+ 

After being not very successful getting my LCD to work with LCDd,
i tested the function of the keys in debug mode.

Unfortunately S1/S5, S3/S6 and S4/S7 are delivering the same keycode
(letter) if being pressed.
So for me it seems, that the Y-lines are not really toggling from high
to low and vice versa round robin to get the scanning-effect.
They seem both to be statically low.

Can anyone confirm that behaviour?

BTW: Is it possible to have the display controlled e.g. with the I2C
connection type and the keypad active on the parallel port?
What are the correct configuration paramteres for that?

Thanks in advance.

Cheers, Thorsten

From bsdfan at nurfuerspam.de  Wed Dec 23 21:11:19 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Wed, 23 Dec 2009 22:11:19 +0100
Subject: [Lcdproc] 4bit-HD44780 and keymatrix...
In-Reply-To: <20091223192940.107220@gmx.net>
References: <179585235@web.de> <20091223192940.107220@gmx.net>
Message-ID: <20091223211119.24590@gmx.net>

Hi,

-------- Original-Nachricht --------
> Datum: Wed, 23 Dec 2009 20:29:40 +0100
> Von: "Thorsten Godau" <dl9sec at gmx.net>
> An: lcdproc at lists.omnipotent.net
> Betreff: [Lcdproc] 4bit-HD44780 and keymatrix...

> Hi all,
> 
> as described in a thread above, i am using a EA DIP204-4 (HD44780->KS0073)
> connected the "4bit"-way to the parallel port.
> As i undestood the documentation, the other signals, that are not used
> for display control can be used for a keymatrix and defined and enabled
> as per an entry "keymatrix_X_Y" in the configuration file.

You can use all lines, except those used as Enable-signal and backlight switch. In case of the 4bit-wiring, you *can* use D0-D4 on the parallel port, even if the are connected to the display.

> 
> My keymatrix is the following:
> 
>   +5V ----------+---------+--------+---------+
>                 |         |        |         |
>                22k       22k      22k       22k
>                 |         |        |         |
>    Y7 -|<|--+---------+--------+---------+   |
>             |   |     |   |    |   |     |   |
>             o   |     o   |    o   |     o   |
>           S1 \  |   S2 \  |  S3 \  |   S4 \  |
>             o   |     o   |    o   |     o   |
>             |   |     |   |    |   |     |   |
>             +---+     +---+    +---+     +---+
>                 |         |        |         |
>                 |         |        |         |
>    Y8 -|<|--+------------------+---------+   |
>             |   |         |    |   |     |   |
>             o   |         |    o   |     o   |
>           S5 \  |         |  S6 \  |   S7 \  |
>             o   |         |    o   |     o   |
>             |   |         |    |   |     |   |
>             +---+         |    +---+     +---+
>                 |         |        |         |
>    X1 ----------+         |        |         |
>                           |        |         |
>    X2 --------------------+        |         |
>                                    |         |
>    X3 -----------------------------+         |
>                                              |
>    X4 ---------------------------------------+ 
> 
> After being not very successful getting my LCD to work with LCDd,
> i tested the function of the keys in debug mode.
> 
> Unfortunately S1/S5, S3/S6 and S4/S7 are delivering the same keycode
> (letter) if being pressed.
> So for me it seems, that the Y-lines are not really toggling from high
> to low and vice versa round robin to get the scanning-effect.
> They seem both to be statically low.
> 
> Can anyone confirm that behaviour?

No, I explicitly tried this with my 3x4 matrix keypad and it did work.

Note that when using the 'keymatrix_x_y' with the wiring above you have to use it like this:

keymatrix_2_8=S1
keymatrix_3_8=S2
...

The 'keymatrix' setting counts from '1' whereas the Y# and X# lines are counted from '0' in the documentation.

The keypad is not scanned in a round robin fashion, but like this:

1. Check with all Y = '1' to detect direct keys.
2. Check with all Y = '0' to detect if any key has been pressed.
3. Do a binary seach on Y to find the key actually pressed.
4. Do a final read (not strictly necessary in some cases, but it doesn't hurt).

I added some more comments recently to document what I read: http://lcdproc.cvs.sourceforge.net/viewvc/lcdproc/lcdproc/server/drivers/hd44780.c?r1=1.94&r2=1.95

Regards,
Markus

From bsdfan at nurfuerspam.de  Thu Dec 24 23:13:45 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Fri, 25 Dec 2009 00:13:45 +0100
Subject: [Lcdproc] 4bit-HD44780 and keymatrix...
In-Reply-To: <20091223211119.24590@gmx.net>
References: <179585235@web.de> <20091223192940.107220@gmx.net>
	<20091223211119.24590@gmx.net>
Message-ID: <20091224231345.113140@gmx.net>

Hi,

-------- Original-Nachricht --------
> Datum: Wed, 23 Dec 2009 22:11:19 +0100
> Von: "Markus Dolze" <bsdfan at nurfuerspam.de>
> An: "Thorsten Godau" <dl9sec at gmx.net>, lcdproc at lists.omnipotent.net
> Betreff: Re: [Lcdproc] 4bit-HD44780 and keymatrix...

> > 
> > My keymatrix is the following:
> > 
> >   +5V ----------+---------+--------+---------+
> >                 |         |        |         |
> >                22k       22k      22k       22k
> >                 |         |        |         |
> >    Y7 -|<|--+---------+--------+---------+   |
> >             |   |     |   |    |   |     |   |
> >             o   |     o   |    o   |     o   |
> >           S1 \  |   S2 \  |  S3 \  |   S4 \  |
> >             o   |     o   |    o   |     o   |
> >             |   |     |   |    |   |     |   |
> >             +---+     +---+    +---+     +---+
> >                 |         |        |         |
> >                 |         |        |         |
> >    Y8 -|<|--+------------------+---------+   |
> >             |   |         |    |   |     |   |
> >             o   |         |    o   |     o   |
> >           S5 \  |         |  S6 \  |   S7 \  |
> >             o   |         |    o   |     o   |
> >             |   |         |    |   |     |   |
> >             +---+         |    +---+     +---+
> >                 |         |        |         |
> >    X1 ----------+         |        |         |
> >                           |        |         |
> >    X2 --------------------+        |         |
> >                                    |         |
> >    X3 -----------------------------+         |
> >                                              |
> >    X4 ---------------------------------------+ 
> > 
...
> 
> The 'keymatrix' setting counts from '1' whereas the Y# and X# lines are
> counted from '0' in the documentation.
> 

Your description in the drawing uses the names for Y#/X# like in the HTML documentation. Counting starts from '1' there as well. I was looking at the code comments, where Y#/X# are counted from '0'. I should change this eventually.

Can you try what happens if you connect Y7 to 'D0' and Y8 to 'D1' on the parallel port?

Regards,
Markus

From dl9sec at gmx.net  Fri Dec 25 17:55:58 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Fri, 25 Dec 2009 18:55:58 +0100
Subject: [Lcdproc] 4bit-HD44780 and keymatrix...
In-Reply-To: <20091224231345.113140@gmx.net>
References: <179585235@web.de> <20091223192940.107220@gmx.net>
	<20091223211119.24590@gmx.net> <20091224231345.113140@gmx.net>
Message-ID: <20091225175558.20010@gmx.net>

Hi again,

first of all, i still could NOT get the display working with LCDproc,
so i concentrated my efforts to get the keypad running correctly
(my next approach for the display is to use the i2c-tiny-usb adapter
and the i2c-connection type with the PCF8574 as described in the
documentation...)

> > > My keymatrix is the following:

I substituted the Sx with the real names to make it easier to read.

> > > 
> > >   +5V ----------+---------+--------+---------+
> > >                 |         |        |         |
> > >                22k       22k      22k       22k
> > >                 |         |        |         |
> > >    Y7 -|<|--+---------+--------+---------+   |
> > >             |   |     |   |    |   |     |   |
> > >             o   |     o   |    o   |     o   |
> > >          User\  |  Menu\  | Down\  | Right\  |
> > >             o   |     o   |    o   |     o   |
> > >             |   |     |   |    |   |     |   |
> > >             +---+     +---+    +---+     +---+
> > >                 |         |        |         |
> > >                 |         |        |         |
> > >    Y8 -|<|--+------------------+---------+   |
> > >             |   |         |    |   |     |   |
> > >             o   |         |    o   |     o   |
> > >            Up\  |         |Enter\  |  Left\  |
> > >             o   |         |    o   |     o   |
> > >             |   |         |    |   |     |   |
> > >             +---+         |    +---+     +---+
> > >                 |         |        |         |
> > >    X1 ----------+         |        |         |
> > >                           |        |         |
> > >    X2 --------------------+        |         |
> > >                                    |         |
> > >    X3 -----------------------------+         |
> > >                                              |
> > >    X4 ---------------------------------------+ 
> > > 

> Your description in the drawing uses the names for Y#/X# like in the HTML
> documentation. Counting starts from '1' there as well. I was looking at > the code comments, where Y#/X# are counted from '0'. I should change this
> eventually.

Yes, i used the docs as the base for the numbering starting with 1.

These are the definitions of my keys:

KeyMatrix_2_7=Menu
KeyMatrix_3_8=Enter
KeyMatrix_1_8=Up
KeyMatrix_3_7=Down
KeyMatrix_4_8=Left
KeyMatrix_4_7=Right
KeyMatrix_1_7=User

That's what the log says:

Dec 25 18:20:35 LinuxPLC LCDd: LCDd version 0.5.2 starting
Dec 25 18:20:35 LinuxPLC LCDd: Built on Jan 13 2009, protocol version 0.3, API version 0.5
Dec 25 18:20:35 LinuxPLC LCDd: Using Configuration File: /etc/LCDd.conf
Dec 25 18:20:35 LinuxPLC LCDd: Set report level to 5, output to syslog
Dec 25 18:20:35 LinuxPLC LCDd: Server running in foreground
Dec 25 18:20:35 LinuxPLC LCDd: Listening for queries on 127.0.0.1:13666
Dec 25 18:20:35 LinuxPLC LCDd: HD44780: Matrix key 0 6: "User"
Dec 25 18:20:35 LinuxPLC LCDd: HD44780: Matrix key 0 7: "Up"
Dec 25 18:20:35 LinuxPLC LCDd: HD44780: Matrix key 1 6: "Menu"
Dec 25 18:20:35 LinuxPLC LCDd: HD44780: Matrix key 2 6: "Down"
Dec 25 18:20:35 LinuxPLC LCDd: HD44780: Matrix key 2 7: "Enter"
Dec 25 18:20:35 LinuxPLC LCDd: HD44780: Matrix key 3 6: "Right"
Dec 25 18:20:35 LinuxPLC LCDd: HD44780: Matrix key 3 7: "Left"
Dec 25 18:20:35 LinuxPLC LCDd: hd44780: Using ea_ks0073 charmap
Dec 25 18:20:39 LinuxPLC LCDd: Key "Menu" is now reserved in exclusive mode by client [-1]
Dec 25 18:20:39 LinuxPLC LCDd: Key "Enter" is now reserved in shared mode by client [-1]
Dec 25 18:20:39 LinuxPLC LCDd: Key "Up" is now reserved in shared mode by client [-1]
Dec 25 18:20:39 LinuxPLC LCDd: Key "Down" is now reserved in shared mode by client [-1]
Dec 25 18:20:39 LinuxPLC LCDd: Key "Left" is now reserved in shared mode by client [-1]
Dec 25 18:20:39 LinuxPLC LCDd: Key "Right" is now reserved in shared mode by client [-1]
Dec 25 18:20:39 LinuxPLC LCDd: screenlist_switch: switched to screen [_server_screen]

That's the output after pressing "Left":
Dec 25 18:22:54 LinuxPLC LCDd: HD44780_get_key: Key pressed: D (4,0)
Dec 25 18:22:54 LinuxPLC LCDd: Driver [hd44780] generated keystroke D

That's the output after pressing "Right":
Dec 25 18:23:08 LinuxPLC LCDd: HD44780_get_key: Key pressed: D (4,0)
Dec 25 18:23:08 LinuxPLC LCDd: Driver [hd44780] generated keystroke D

That's the output after pressing "Down":
Dec 25 18:23:14 LinuxPLC LCDd: HD44780_get_key: Key pressed: C (3,0)
Dec 25 18:23:14 LinuxPLC LCDd: Driver [hd44780] generated keystroke C

That's the output after pressing "Enter":
Dec 25 18:23:16 LinuxPLC LCDd: HD44780_get_key: Key pressed: C (3,0)
Dec 25 18:23:16 LinuxPLC LCDd: Driver [hd44780] generated keystroke C

That's the output after pressing "Menu":
Dec 25 18:23:40 LinuxPLC LCDd: HD44780_get_key: Key pressed: B (2,0)
Dec 25 18:23:40 LinuxPLC LCDd: Driver [hd44780] generated keystroke B

That's the output after pressing "Up":
Dec 25 18:23:12 LinuxPLC LCDd: HD44780_get_key: Key pressed: A (1,0)
Dec 25 18:23:12 LinuxPLC LCDd: Driver [hd44780] generated keystroke A

That's the output after pressing "User":
Dec 25 18:23:45 LinuxPLC LCDd: HD44780_get_key: Key pressed: A (1,0)
Dec 25 18:23:45 LinuxPLC LCDd: Driver [hd44780] generated keystroke A

As you can see, the keys that are connected to the same X-line are
delivering the same keystroke. IMHO the Y-lines are not switched 
correctly. I checked the Y-lines with the scope and they are both
statically low. There are no high-pulses.

> Can you try what happens if you connect Y7 to 'D0' and Y8 to 'D1' on the
> parallel port?

I can try it, yes. What is your intention with that test?

Regards, Thorsten

From dl9sec at gmx.net  Fri Dec 25 19:35:47 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Fri, 25 Dec 2009 20:35:47 +0100
Subject: [Lcdproc] 4bit-HD44780 and keymatrix...
In-Reply-To: <20091224231345.113140@gmx.net>
References: <179585235@web.de> <20091223192940.107220@gmx.net>
	<20091223211119.24590@gmx.net> <20091224231345.113140@gmx.net>
Message-ID: <20091225193547.19990@gmx.net>

Hi Markus,

> Can you try what happens if you connect Y7 to 'D0' and Y8 to 'D1' on the
> parallel port?

I rewired the Y-lines: Y7 to Y1 (D0) and Y8 to Y2 (D1) and changed the
key definitions as followed:

KeyMatrix_2_1=Menu
KeyMatrix_3_2=Enter
KeyMatrix_1_2=Up
KeyMatrix_3_1=Down
KeyMatrix_4_2=Left
KeyMatrix_4_1=Right
KeyMatrix_1_1=User

The log output:

:
Dec 25 20:27:43 LinuxPLC LCDd: HD44780: Matrix key 0 0: "User"
Dec 25 20:27:43 LinuxPLC LCDd: HD44780: Matrix key 0 1: "Up"
Dec 25 20:27:43 LinuxPLC LCDd: HD44780: Matrix key 1 0: "Menu"
Dec 25 20:27:43 LinuxPLC LCDd: HD44780: Matrix key 2 0: "Down"
Dec 25 20:27:43 LinuxPLC LCDd: HD44780: Matrix key 2 1: "Enter"
Dec 25 20:27:43 LinuxPLC LCDd: HD44780: Matrix key 3 0: "Right"
Dec 25 20:27:43 LinuxPLC LCDd: HD44780: Matrix key 3 1: "Left"
Dec 25 20:27:43 LinuxPLC LCDd: hd44780: Using ea_ks0073 charmap
Dec 25 20:27:47 LinuxPLC LCDd: Key "Menu" is now reserved in exclusive mode by client [-1]
Dec 25 20:27:47 LinuxPLC LCDd: Key "Enter" is now reserved in shared mode by client [-1]
Dec 25 20:27:47 LinuxPLC LCDd: Key "Up" is now reserved in shared mode by client [-1]
Dec 25 20:27:47 LinuxPLC LCDd: Key "Down" is now reserved in shared mode by client [-1]
Dec 25 20:27:47 LinuxPLC LCDd: Key "Left" is now reserved in shared mode by client [-1]
Dec 25 20:27:47 LinuxPLC LCDd: Key "Right" is now reserved in shared mode by client [-1]
Dec 25 20:27:47 LinuxPLC LCDd: screenlist_switch: switched to screen [_server_screen]

When i press a key, NOTHING happens, no message in the log...

Regards, Thorsten

From bsdfan at nurfuerspam.de  Sat Dec 26 00:00:20 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sat, 26 Dec 2009 01:00:20 +0100
Subject: [Lcdproc] 4bit-HD44780 and keymatrix...
In-Reply-To: <20091225175558.20010@gmx.net>
References: <179585235@web.de>
	<20091223192940.107220@gmx.net>	<20091223211119.24590@gmx.net>
	<20091224231345.113140@gmx.net> <20091225175558.20010@gmx.net>
Message-ID: <4B355214.9030004@nurfuerspam.de>

Thorsten Godau wrote:
> That's the output after pressing "Left":
> Dec 25 18:22:54 LinuxPLC LCDd: HD44780_get_key: Key pressed: D (4,0)
> Dec 25 18:22:54 LinuxPLC LCDd: Driver [hd44780] generated keystroke D
>
> That's the output after pressing "Right":
> Dec 25 18:23:08 LinuxPLC LCDd: HD44780_get_key: Key pressed: D (4,0)
> Dec 25 18:23:08 LinuxPLC LCDd: Driver [hd44780] generated keystroke D
>
> That's the output after pressing "Down":
> Dec 25 18:23:14 LinuxPLC LCDd: HD44780_get_key: Key pressed: C (3,0)
> Dec 25 18:23:14 LinuxPLC LCDd: Driver [hd44780] generated keystroke C
>
> That's the output after pressing "Enter":
> Dec 25 18:23:16 LinuxPLC LCDd: HD44780_get_key: Key pressed: C (3,0)
> Dec 25 18:23:16 LinuxPLC LCDd: Driver [hd44780] generated keystroke C
>
> That's the output after pressing "Menu":
> Dec 25 18:23:40 LinuxPLC LCDd: HD44780_get_key: Key pressed: B (2,0)
> Dec 25 18:23:40 LinuxPLC LCDd: Driver [hd44780] generated keystroke B
>
> That's the output after pressing "Up":
> Dec 25 18:23:12 LinuxPLC LCDd: HD44780_get_key: Key pressed: A (1,0)
> Dec 25 18:23:12 LinuxPLC LCDd: Driver [hd44780] generated keystroke A
>
> That's the output after pressing "User":
> Dec 25 18:23:45 LinuxPLC LCDd: HD44780_get_key: Key pressed: A (1,0)
> Dec 25 18:23:45 LinuxPLC LCDd: Driver [hd44780] generated keystroke A
>   
...
> As you can see, the keys that are connected to the same X-line are
> delivering the same keystroke. IMHO the Y-lines are not switched 
> correctly. I checked the Y-lines with the scope and they are both
> statically low. There are no high-pulses.
>   

The key presses return "A" to "D" which are the default key mappings for 
direct keys. If the Y-pins _are_ low, LCDd will detect that key press 
when checking for direct keys.

This is really weird, as the code is working (at least for me), but read 
below as well. And I used 10k resistors.

>   
>> Can you try what happens if you connect Y7 to 'D0' and Y8 to 'D1' on the
>> parallel port?
>>     
>
> I can try it, yes. What is your intention with that test?
>
>
>   
The hd44780-4bit driver dated before 12.12.2009 had a bug not setting 
pins Y7-Y10 correctly during keypad scans. Additionally, those lines are 
only set conditionally (there is a check for the number of attached 
controllers), so I wanted to be sure about it.

Thus, you may try your original wiring with Y7/Y8, but use a lcdproc 
version later than that date (a 'current' nightly build should have the 
change).

Regards,
Markus


From dl9sec at gmx.net  Sat Dec 26 09:36:44 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Sat, 26 Dec 2009 10:36:44 +0100
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <20091203184119.145560@gmx.net>
References: <20091201191709.262770@gmx.net>
	<f4eb766f0912011151w40c204dbh524b35af1ea2f4b2@mail.gmail.com>
	<20091202174011.87960@gmx.net>
	<f4eb766f0912021022p9722b00u7df10c0d164944a@mail.gmail.com>
	<4B16B611.0@nurfuerspam.de> <20091202192411.87960@gmx.net>
	<4B16D598.6000208@nurfuerspam.de> <20091203184119.145560@gmx.net>
Message-ID: <20091226093644.255210@gmx.net>

Hi,

now i get the display working. Not directly connected to the parallel
port, but a bit more complicated:

I used an i2c-tiny-usb to get a i2c-* device. Then i used a little
piggy back pcb with the i2c-connection as described in the docs and
put it at my existing panel-pcb (fortunately all signals are fed
through 10R resistors and can therefore be cut :-) ). I changed the
LCDd.conf hd44780-section to:

[hd44780]
ConnectionType=i2c
Device=/dev/i2c-1
Port=0x21
Keypad=no
Backlight=yes
OutputPort=no
Extendedmode=yes
Delaymult=1
Delaybus=false
Size=20x4
Charmap=ea_ks0073

et voila, the display starts with

HD44780 20x4
LPT 0x21 bl

and after a few seconds the server screen starts with the puming heart in
the upper right corner. So the i2c-driver seems to work perfect even it
is a bit slow (that's the drawback when using a "10-parts-single-chip"
USB2I2C-bridge that gives a throghput of only 50kBits/s). But it's ok
so far.

One open question:

Can i use the keymatrix connected to the LPT in parallel?
How do i have to extend my LCDd.conf (somewhere i read, that i can use
more than one devices in the hd44780-section...)?

Regards, Thorsten

From bsdfan at nurfuerspam.de  Sat Dec 26 10:30:01 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sat, 26 Dec 2009 11:30:01 +0100
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <20091226093644.255210@gmx.net>
References: <20091201191709.262770@gmx.net>	<f4eb766f0912011151w40c204dbh524b35af1ea2f4b2@mail.gmail.com>	<20091202174011.87960@gmx.net>	<f4eb766f0912021022p9722b00u7df10c0d164944a@mail.gmail.com>	<4B16B611.0@nurfuerspam.de>
	<20091202192411.87960@gmx.net>	<4B16D598.6000208@nurfuerspam.de>
	<20091203184119.145560@gmx.net> <20091226093644.255210@gmx.net>
Message-ID: <4B35E5A9.6030706@nurfuerspam.de>

Thorsten Godau wrote:
> Hi,
>
> now i get the display working. Not directly connected to the parallel
> port, but a bit more complicated:
>
> I used an i2c-tiny-usb to get a i2c-* device. Then i used a little
> piggy back pcb with the i2c-connection as described in the docs and
> put it at my existing panel-pcb (fortunately all signals are fed
> through 10R resistors and can therefore be cut :-) ). I changed the
> LCDd.conf hd44780-section to:
>   
That's sounds good. Is the i2c-tiny-usb the one from Till Harbaum or 
your own design? I am a happy user of his lcd2usb devices.

> et voila, the display starts with
>
> HD44780 20x4
> LPT 0x21 bl
>
> and after a few seconds the server screen starts with the puming heart in
> the upper right corner. 
> One open question:
>
> Can i use the keymatrix connected to the LPT in parallel?
> How do i have to extend my LCDd.conf (somewhere i read, that i can use
> more than one devices in the hd44780-section...)?
>   
I don't think this is possible. There is currently no 'input only' 
driver for parallel port connected keypads. Out of those drivers using a 
parallel port only hd44780 supports keypads, but you cannot use two 
hd44780 drivers. If at all, you can only use different drivers.

Regards,
Markus

From dl9sec at gmx.net  Sat Dec 26 16:23:38 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Sat, 26 Dec 2009 17:23:38 +0100
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <4B35E5A9.6030706@nurfuerspam.de>
References: <20091201191709.262770@gmx.net>
	<f4eb766f0912011151w40c204dbh524b35af1ea2f4b2@mail.gmail.com>
	<20091202174011.87960@gmx.net>
	<f4eb766f0912021022p9722b00u7df10c0d164944a@mail.gmail.com>
	<4B16B611.0@nurfuerspam.de> <20091202192411.87960@gmx.net>
	<4B16D598.6000208@nurfuerspam.de> <20091203184119.145560@gmx.net>
	<20091226093644.255210@gmx.net> <4B35E5A9.6030706@nurfuerspam.de>
Message-ID: <20091226162338.142560@gmx.net>

Hi,

> That's sounds good. Is the i2c-tiny-usb the one from Till Harbaum or 
> your own design? I am a happy user of his lcd2usb devices.

Yes, it is Till's design and firmware. I only did my own layout combined
with the PCF8574 as a piggy pack board. Really great stuff!

> I don't think this is possible. There is currently no 'input only' 
> driver for parallel port connected keypads. Out of those drivers using a 
> parallel port only hd44780 supports keypads, but you cannot use two 
> hd44780 drivers. If at all, you can only use different drivers.

It's a pity. I really like the LCDproc package and the final aim is
still to have the display running directly via parallel port.
IMHO it is an unfortunate combination of things that makes my 
display not running corrctly with LCDproc.
One thing could be a critical timing together with a bad initalisation
sequence and the other thing could be, that most of the signals on my
parallel port are high in idle state (pulled up with a resistor according
to the manual of the SBC). I also can see this with my scope. Most of the
time all the display controlling signals are high, going low for short
pulses. I expected an opposite beaviour. Maybe that's the crux.
Something in the inialisation phase confuses the display and corrupts
the init sequence. Othewise it would not run with ldc4linux...

Regards, Thorsten

From joris at robijn.net  Sat Dec 26 17:56:09 2009
From: joris at robijn.net (Joris Robijn)
Date: Sat, 26 Dec 2009 18:56:09 +0100
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <20091226093644.255210@gmx.net>
References: <20091201191709.262770@gmx.net>, <20091203184119.145560@gmx.net>,
	<20091226093644.255210@gmx.net>
Message-ID: <4B365C49.8999.1D4559D@joris.robijn.net>

On 26 Dec 2009 at 10:36, Thorsten Godau wrote:

> Can i use the keymatrix connected to the LPT in parallel?
> How do i have to extend my LCDd.conf (somewhere i read, that i can use
> more than one devices in the hd44780-section...)?

Hi Thorsten,

I think you can. The driver should (repeat: should) be capable of 
instantiating twice. In the the config file you can indicate for each 
driver what module (.so file) to load. That way, you can load the same 
module twice. This is done with the File= parameter of a driver. By 
default it loads the same filename as the drivername. For example:

Drivers=hd44780,hd44780keypad

[hd44780]
# this one loads hd44780.so because filename is unspecified
# ... here specify your ususal parameters
type=lcd2usb #or whatever

[hd44780keypad]
File=hd44780.so    # forced filename
Port=0x278
key_direct_0="Menu"
key_matrix_1_4="A"

The first driver loaded is the primary driver and this one determines 
things like display size reported to clients. Keys can come from any 
driver. You can also load the curses driver only to generate keypresses 
for your hd44780 display.

I hope all this information is still true, I haven't played with this 
stuff very much lately.

Regards,
Joris

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



From bsdfan at nurfuerspam.de  Sat Dec 26 22:46:56 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sat, 26 Dec 2009 23:46:56 +0100
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <4B365C49.8999.1D4559D@joris.robijn.net>
References: <20091201191709.262770@gmx.net>, <20091203184119.145560@gmx.net>,
	<20091226093644.255210@gmx.net>
	<4B365C49.8999.1D4559D@joris.robijn.net>
Message-ID: <4B369260.80605@nurfuerspam.de>

Joris Robijn wrote:
> On 26 Dec 2009 at 10:36, Thorsten Godau wrote:
>
>   
>> Can i use the keymatrix connected to the LPT in parallel?
>> How do i have to extend my LCDd.conf (somewhere i read, that i can use
>> more than one devices in the hd44780-section...)?
>>     
>
> Hi Thorsten,
>
> I think you can. The driver should (repeat: should) be capable of 
> instantiating twice. In the the config file you can indicate for each 
> driver what module (.so file) to load. That way, you can load the same 
> module twice. This is done with the File= parameter of a driver. By 
> default it loads the same filename as the drivername. For example:
>
> Drivers=hd44780,hd44780keypad
>
> [hd44780]
> # this one loads hd44780.so because filename is unspecified
> # ... here specify your ususal parameters
> type=lcd2usb #or whatever
>
> [hd44780keypad]
> File=hd44780.so    # forced filename
> Port=0x278
> key_direct_0="Menu"
> key_matrix_1_4="A"
>
> The first driver loaded is the primary driver and this one determines 
> things like display size reported to clients. Keys can come from any 
> driver. You can also load the curses driver only to generate keypresses 
> for your hd44780 display.
>
> I hope all this information is still true, I haven't played with this 
> stuff very much lately.
>
> Regards,
> Joris
>
>   
Markus Dolze wrote:
> I don't think this is possible. There is currently no 'input only' 
> driver for parallel port connected keypads. Out of those drivers using 
> a parallel port only hd44780 supports keypads, but you cannot use two 
> hd44780 drivers. If at all, you can only use different drivers.
>
I was wrong about this (thanks Joris for pointing this out). I looked it 
up and it seems the necessary code is still there, although I think it 
is not

Drivers=hd44780,hd44780keypad

but

Driver=hd44780
Driver=hd44780keypad

(multiple "Driver=" lines). Everything else should work like described 
by Joris.

Regards,
Markus


From bsdfan at nurfuerspam.de  Sun Dec 27 10:26:21 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 27 Dec 2009 11:26:21 +0100
Subject: [Lcdproc] Renewed server input buffer
Message-ID: <20091227102621.24610@gmx.net>

Hello,

back in February I started a discussion about how to improve LCDd's way to buffer incoming client messages (see http://lists.omnipotent.net/pipermail/lcdproc/2009-February/012744.html).

I now completely rewrote the input buffer handling and introduced a circular buffer for incoming messages.

As I would like to commit this soon, I encourage everybody to try it. It runs stable for days on my displays right now.

One additional improvement could be to have such a buffer per client. Right now there is one such buffer for the whole server and the buffer is cleared when it exits sock_read_from_client() for a single client.

Regards,
Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-server-sock-sring.diff
Type: application/octet-stream
Size: 13151 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20091227/bb133096/attachment-0001.obj>

From dl9sec at gmx.net  Sun Dec 27 15:37:45 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Sun, 27 Dec 2009 16:37:45 +0100
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <4B369260.80605@nurfuerspam.de>
References: <20091201191709.262770@gmx.net>, <20091203184119.145560@gmx.net>, 
	<20091226093644.255210@gmx.net>
	<4B365C49.8999.1D4559D@joris.robijn.net>
	<4B369260.80605@nurfuerspam.de>
Message-ID: <20091227153745.255230@gmx.net>

Hi Joris, hi Markus,

brilliant! Thanks a million for the hints. It seems to work.

Maybe that could be a suggestion for a further improvement:

- Either a new driver type keypad.so
- or a new connection type "keypad" within the HD44780 driver

which does nothing than checking the keypad connected to the
paralell port and giving the pressing information. No display
control, only keypad control...

Another question:

Where are the keys bound to the letters? Is it possible to trigger
a shell command like e.g. "poweroff" with a button.
Is there a documentation for the button handling or where can i find
further infos about that? 

Regards, Thorsten

From dl9sec at gmx.net  Sun Dec 27 17:11:31 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Sun, 27 Dec 2009 18:11:31 +0100
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <20091227153745.255230@gmx.net>
References: <20091201191709.262770@gmx.net>, <20091203184119.145560@gmx.net>, 
	<20091226093644.255210@gmx.net>	<4B365C49.8999.1D4559D@joris.robijn.net>
	<4B369260.80605@nurfuerspam.de> <20091227153745.255230@gmx.net>
Message-ID: <20091227171131.246640@gmx.net>

Hi again,

> Another question:
> 
> Where are the keys bound to the letters? Is it possible to trigger
> a shell command like e.g. "poweroff" with a button.
> Is there a documentation for the button handling or where can i find
> further infos about that? 

Think i found the answer myself. "lcdexec" seems to be the solution ;-)

Regards, Thorsten

From dl9sec at gmx.net  Sun Dec 27 18:32:35 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Sun, 27 Dec 2009 19:32:35 +0100
Subject: [Lcdproc] Feedback for CVS nightly build (20091227)...
Message-ID: <20091227183235.246650@gmx.net>

Hi,

Markus suggested to use a more recent version of LCDproc to get
my keypad running correctly.

So i did. I downloaded the nighly snap (20091227), decompressed
it and configured it ( ./configure --enable-lcdproc-menus --enable-drivers='all').

"make" stops at the hd44780-i2c module with the following messages:

hd44780-i2c.c: In function ?i2c_out?:
hd44780-i2c.c:103: error: ?drvthis? undeclared (first use in this function)
hd44780-i2c.c:103: error: (Each undeclared identifier is reported only once
hd44780-i2c.c:103: error: for each function it appears in.)
make[3]: *** [hd44780-hd44780-i2c.o] Fehler 1

I compared the file with that one from a stabel version and found a
difference in line 57 of hd44780-i2c.c:

#include "report.h" instead of #include "shared/report.h"

I corrected the line and the package compiles.

With this version the keymatrix is running great! All keys are correctly
recognized.

I discovered, that sometimes the keys are not shown in the debug log. I
had to press two times and stay a bit longer on the button to get an 
output. Then i switched the heartbeat off via the menu and then the
key recognition runs much faster. All keys appear with their first push.

Does somebody knows how to configure the package to get the same
configuration as the debian package (all the pathes and startup
scrips...)?

Regards, Thorsten

From bsdfan at nurfuerspam.de  Sun Dec 27 21:45:25 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 27 Dec 2009 22:45:25 +0100
Subject: [Lcdproc] Feedback for CVS nightly build (20091227)...
Message-ID: <20091227214525.182170@gmx.net>

-------- Original-Nachricht --------
> Datum: Sun, 27 Dec 2009 19:32:35 +0100
> Von: "Thorsten Godau" <dl9sec at gmx.net>
> An: lcdproc at lists.omnipotent.net
> Betreff: [Lcdproc] Feedback for CVS nightly build (20091227)...

> Hi,
> 
> Markus suggested to use a more recent version of LCDproc to get
> my keypad running correctly.
> 
> So i did. I downloaded the nighly snap (20091227), decompressed
> it and configured it ( ./configure --enable-lcdproc-menus
> --enable-drivers='all').
> 
> "make" stops at the hd44780-i2c module with the following messages:
> 
> hd44780-i2c.c: In function ?i2c_out?:
> hd44780-i2c.c:103: error: ?drvthis? undeclared (first use in this
> function)
> hd44780-i2c.c:103: error: (Each undeclared identifier is reported only
> once
> hd44780-i2c.c:103: error: for each function it appears in.)
> make[3]: *** [hd44780-hd44780-i2c.o] Fehler 1
> 
> I compared the file with that one from a stabel version and found a
> difference in line 57 of hd44780-i2c.c:
> 
> #include "report.h" instead of #include "shared/report.h"
> 
> I corrected the line and the package compiles.

Would you mind trying the attached patch with the downloaded nightly snapshot? I cannot test this myself as I am using a non-Linux OS.

BTW: This means no Linux user has tried a nightly snapshot for 3 months or they don't have the linux/i2c-dev.h file!

> 
> With this version the keymatrix is running great! All keys are correctly
> recognized.
> 

Great!

> I discovered, that sometimes the keys are not shown in the debug log. I
> had to press two times and stay a bit longer on the button to get an 
> output. Then i switched the heartbeat off via the menu and then the
> key recognition runs much faster. All keys appear with their first push.

This might be a drawback of the way LCDd works. It is single threaded and does reading from the client, input processing, and rendering one after another. As updating the screen may take a while, you have to press the key longer than that to be recognized.

> 
> Does somebody knows how to configure the package to get the same
> configuration as the debian package (all the pathes and startup
> scrips...)?
> 
> Regards, Thorsten

Within scripts/debian there is a version of the debian files needed to create a package. I synced these with the official ones for 0.5.3 release. But as we lack somebody who builds snapshot debian packages, I don't know if it works today or is in sync with the official package files.

Regards,
Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-hd44780-i2c.diff
Type: application/octet-stream
Size: 752 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20091227/fafc451d/attachment.obj>

From bsdfan at nurfuerspam.de  Sun Dec 27 21:55:34 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 27 Dec 2009 22:55:34 +0100
Subject: [Lcdproc] Can't get this thing working...
In-Reply-To: <20091227153745.255230@gmx.net>
References: <20091201191709.262770@gmx.net>, <20091203184119.145560@gmx.net>, 
	<20091226093644.255210@gmx.net>	<4B365C49.8999.1D4559D@joris.robijn.net>
	<4B369260.80605@nurfuerspam.de> <20091227153745.255230@gmx.net>
Message-ID: <20091227215534.182160@gmx.net>

-------- Original-Nachricht --------
> Datum: Sun, 27 Dec 2009 16:37:45 +0100
> Von: "Thorsten Godau" <dl9sec at gmx.net>
> An: lcdproc at lists.omnipotent.net
> Betreff: Re: [Lcdproc] Can't get this thing working...

> Hi Joris, hi Markus,
> 
> brilliant! Thanks a million for the hints. It seems to work.
> 
> Maybe that could be a suggestion for a further improvement:
> 
> - Either a new driver type keypad.so
> - or a new connection type "keypad" within the HD44780 driver
> 
> which does nothing than checking the keypad connected to the
> paralell port and giving the pressing information. No display
> control, only keypad control...

The hd44780 driver requires an output function, so just having a input only connection type will not work. (Except we create an empty one - ugly hack).

Additionally, the keypad scan need to take into account which lines to exclude. Having an independent parallel port input driver will only work, if no display is connected to the parallel port. Otherwise strange things might happen.

Looking at recent computers (SBCs may be an exception) many don't have a parallel port anymore. A real advantage would be a small and easy to build device using the USB port for which we could create a driver.

> 
> Another question:
> 
> Where are the keys bound to the letters? Is it possible to trigger
> a shell command like e.g. "poweroff" with a button.
> Is there a documentation for the button handling or where can i find
> further infos about that? 
> 
> Regards, Thorsten

a) The "key text" is bound using the KeyDirect_ or KeyMatrix_ options.
b) you found that yourself already (lcdexec)

Regards,
Markus

From bsdfan at nurfuerspam.de  Sun Dec 27 22:42:15 2009
From: bsdfan at nurfuerspam.de (Markus Dolze)
Date: Sun, 27 Dec 2009 23:42:15 +0100
Subject: [Lcdproc] Improved hd44780 output buffering
Message-ID: <20091227224215.182160@gmx.net>

Hello,

after working on LCDd's input buffering I had a look at the output part and the LCD2USB driver I'm using.

I found that the hd44780 driver outputs one byte after another using senddata. While this is fine for its original use with a parallel port. However we have more advanced devices like lcd2usb which may transmit more than just one byte at once (4 for lcd2usb).

Therefore I extended the hd44780 subdriver interface by a 'flush' function and implemented an output buffer for the lcd2usb.

The results are quite good (example with my 20x4). Without the output buffer:

HD44780: flushed 80 chars (12 moves) in 0.275909 sec
HD44780: flushed 39 chars (8 moves) in 0.140945 sec

With the output buffer:

HD44780: flushed 80 chars (12 moves) in 0.095992 sec
HD44780: flushed 39 chars (8 moves) in 0.056988 sec

(The first one is a worst case update during startup).

I found that on average, the screen update times are cut in half. It is not a quarter, because each move (which occurs at least every 8 chars with the current screen buffering implementation) requires a buffer flush which is not optimal. But the change is visible!

Have a try!

Regards,
Markus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-hd44780-lcd2usb-buffer.diff
Type: application/octet-stream
Size: 6573 bytes
Desc: not available
URL: <http://lists.omnipotent.net/pipermail/lcdproc/attachments/20091227/efa7680f/attachment.obj>

From dl9sec at gmx.net  Wed Dec 30 18:15:54 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Wed, 30 Dec 2009 19:15:54 +0100
Subject: [Lcdproc] Question about LCD2USB...
Message-ID: <20091230181554.230710@gmx.net>

Hi,

i have some questions about LCD2USB used together with LCDproc.

How do i have to specify the device (/dev/...) for the LCD2USB adaptor?
Or is the adaptor defined by the VendorID/ProductID? If yes, what is
the correct VID/PID for the LCD2USB?

What is the difference between the both USB-implementations
(avrusb/tinyusb) of the LCD2USB firmware apart from the licensing?
Is there a difference in performance? Which firmware should be used
for best results with LCDproc?

Thanks in advance.

Regards, Thorsten

From dl9sec at gmx.net  Wed Dec 30 18:43:36 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Wed, 30 Dec 2009 19:43:36 +0100
Subject: [Lcdproc] Feedback for CVS nightly build (20091227)...
In-Reply-To: <20091227214525.182170@gmx.net>
References: <20091227214525.182170@gmx.net>
Message-ID: <20091230184336.230690@gmx.net>

Hi Markus,

> Would you mind trying the attached patch with the downloaded nightly
> snapshot? I cannot test this myself as I am using a non-Linux OS.

No problem.

> BTW: This means no Linux user has tried a nightly snapshot for 3 months > or they don't have the linux/i2c-dev.h file!

SHAME on them ;-))

I used the nightly distribution 20091230 and pathed the sources with
patch-hd44780-lcd2usb-buffer.diff and patch-hd44780-i2c.diff.

Configured with

./configure --enable-lcdproc-menus --enable-drivers='all'

and doing a "make" gaves no errors. Just the following warnings that
have also been in the version 20091227:

hd44780-uss720.c:289: warning: ignoring #pragma mark
hd44780-uss720.c:290: warning: ignoring #pragma mark
hd44780-uss720.c:331: warning: ignoring #pragma mark
hd44780-uss720.c:332: warning: ignoring #pragma mark

Seems not to be really serious, no further warnings at all.

Regards, Thorsten

From dl9sec at gmx.net  Wed Dec 30 19:01:16 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Wed, 30 Dec 2009 20:01:16 +0100
Subject: [Lcdproc] Improved hd44780 output buffering
In-Reply-To: <20091227224215.182160@gmx.net>
References: <20091227224215.182160@gmx.net>
Message-ID: <20091230190116.230690@gmx.net>

Hi again,

Addendum: I tried to run the freshly built LCDd, but it giving the
folowing error message in the log:

12~Dec 30 19:51:21 LinuxPLC LCDd: LCDd version CVS-current-20091230 starting
Dec 30 19:51:21 LinuxPLC kernel: [ 3389.417499] LCDd[9256]: segfault at 2 ip b7e6338b sp bfbfb088 error 4 in libc-2.7.so[b7ded000+155000]
Dec 30 19:51:21 LinuxPLC LCDd: Built on Dec 30 2009, protocol version 0.3, API version 0.5
Dec 30 19:51:21 LinuxPLC LCDd: Using Configuration File: ../LCDd.conf
Dec 30 19:51:21 LinuxPLC LCDd: Set report level to 5, output to syslog
Dec 30 19:51:21 LinuxPLC LCDd: Server running in foreground
Dec 30 19:51:21 LinuxPLC LCDd: Listening for queries on 127.0.0.1:13666
Dec 30 19:51:21 LinuxPLC LCDd: HD44780: using ConnectionType: i2c
Dec 30 19:51:21 LinuxPLC LCDd: hd44780i2c: Using ea_ks0073 charmap

That's new for me.

I rebooted and tried again, but with the same result.

Any ideas?

Regards, Thorsten

From dl9sec at gmx.net  Wed Dec 30 19:04:20 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Wed, 30 Dec 2009 20:04:20 +0100
Subject: [Lcdproc] Feedback for CVS nightly build (20091227)...
In-Reply-To: <20091230184336.230690@gmx.net>
References: <20091227214525.182170@gmx.net> <20091230184336.230690@gmx.net>
Message-ID: <20091230190420.230700@gmx.net>

Hi again,

Addendum: I tried to run the freshly built LCDd, but it giving the
folowing error message in the log:

12~Dec 30 19:51:21 LinuxPLC LCDd: LCDd version CVS-current-20091230 starting
Dec 30 19:51:21 LinuxPLC kernel: [ 3389.417499] LCDd[9256]: segfault at 2 ip b7e6338b sp bfbfb088 error 4 in libc-2.7.so[b7ded000+155000]
Dec 30 19:51:21 LinuxPLC LCDd: Built on Dec 30 2009, protocol version 0.3, API version 0.5
Dec 30 19:51:21 LinuxPLC LCDd: Using Configuration File: ../LCDd.conf
Dec 30 19:51:21 LinuxPLC LCDd: Set report level to 5, output to syslog
Dec 30 19:51:21 LinuxPLC LCDd: Server running in foreground
Dec 30 19:51:21 LinuxPLC LCDd: Listening for queries on 127.0.0.1:13666
Dec 30 19:51:21 LinuxPLC LCDd: HD44780: using ConnectionType: i2c
Dec 30 19:51:21 LinuxPLC LCDd: hd44780i2c: Using ea_ks0073 charmap

That's new for me.

I rebooted and tried again, but with the same result.

Any ideas?

(Sorry, first posted to the wrong thread...)

From dl9sec at gmx.net  Thu Dec 31 09:35:05 2009
From: dl9sec at gmx.net (Thorsten Godau)
Date: Thu, 31 Dec 2009 10:35:05 +0100
Subject: [Lcdproc] Feedback for CVS nightly build (20091227)...
In-Reply-To: <20091230190420.230700@gmx.net>
References: <20091227214525.182170@gmx.net> <20091230184336.230690@gmx.net>
	<20091230190420.230700@gmx.net>
Message-ID: <20091231093505.24610@gmx.net>

Hi,

i did some further experiments:

the I2C-patch causes the segmentation fault.
Without this patch and by changing "#include "report.h"
to "#include "shared/report.h" in hd44780-i2c.c it works.

Sorry Markus, the patch doesn't work :-(

Regards, Thorsten