lcd4linux-devel — lcd4linux development team

[Lcd4linux-devel] New device target for lcd4linux

[Jeroen D. <je...@sp...>]

Hi,

Because this is my first post, I'll introduce myself: I'm Jeroen, a 
hardware hacker who runs a site with electronics stuff at 
http://spritesmods.com. Please do check out my projects if you're 
interested in that kind of stuff :)

I recently got my hands on a cheap (E10) photoframe, which sported a nice 
128x128 color LCD and a USB-connection, all based on a ST2205 or ST2203 
microchip. To make a long story short: I hacked the firmware and put 
together a library so the display becomes directly accessable via the 
USB-port. The long story is on my site: 
http://spritesmods.com/?art=picframe&f=l4l .

One of the things I have written is a patch for lcd4linux to support the 
picture frame. For now, I distribute it as a diff along with the firmware 
patches and the library, but I'd like them to end up in the lcd4linux code 
itself.

I followed the driver_howto ('grats for a good explanation of how to write 
a driver, btw, it was quite helpful) and I ended up with a diff that 
should add the st2205 driver to lcd4linux. I uploaded it here:
http://spritesmods.com/picframe/patch-lcd4linux.diff
A warning: it seems that the indent.sh-script changed a bit more than just 
my patch. No idea if that's intentional or not.

The driver is, as far as I've tested it, stable: my server has a nice 
screen telling me its load, disk I/O etc all on a nice jpg backdrop with 
alpha shading for about a week now, without a hitch.

So, the question is: is my patch OK to be incorporated in the lcd4linux 
svn-tree, or is there still something I should attend to?

Jeroen/Sprite_tm

[Lcd4linux-devel] Gen III Cobalt Raq Support.

[David W S. <avi...@ai...>]

 Hello, I was wondering what I would have to do to get lcd4linux to work
with these. The Gen III units include Raq, 3 and 4 and I believe Qube 3 as
well. They are a parallel port connected device in the winamp fashion and
the port is 0x378. Anything I've tried so far with lcd4linux ends up with
garbage on the display and the winamp driver is the only one that even does
that. I also substituted a Sure Electronics DE-LM003 which is yet another
16x2 HD44780 compatible device and the results are identical. So far only
two things have resulted in clean text. Having the Cobalt LCD driver
compiled with the other Cobalt drivers and using the LCD Panel binaries
that write to the lcd with very boring perl scripts that don't show much
and the other was using perl scripts that drive the lcd directly with no
driver at all but perl has a bit of overhead. I'm involved in a very humble
project to run the IPCop firewall on these units since the i and r models
both contain two built in nics plus a pci slot. The Symantec Velociraptors
models 500 up through at least 1100 are also Gen III Raq units. I have a
few Raq 4i's and a few Velociraptor 500's and the only difference is the
lack of usb port on the Velociraptors. I do have a development version of
IPCop running on one where I made a version that keeps the entire build
environment intact but should not be used as a firewall, just to compile
and test. Getting IPCop to run on these by patching the kernel for Cobalt
support was easy and getting the e100 driver to ignore the hardware
checksum error that is all too common on 82559er chipped device was easy as
well. I like the LCD4Linux concept. I have gotten lcdproc to run on these
but the text garbages on me there as well. 
 I don't really like the Panel Utilities that are from the old Cobalt
sources even though I have gotten them to compile and run with IPCop. How
hard would it be to make a driver similar to the lcdlinux driver where it
uses an existing kernel driver? In my devel version, the kernel source has
the Cobalt driver sources in it. Not sure which way to go here.


Dave 

Re: [Lcd4linux-devel] new plugin: button_exec

[Wolfgang H. <wo...@wo...>]

On Jan 21, 2008, at 18:35 , Robert Buchholz wrote:

> On Monday, 21. January 2008, Wolfgang Hennerbichler wrote:
>> Where should I send my patch to?
>
> This list is fine.

Allright. Here it is.
I had to comment out this AM_ICONV section in plugins.m4 here:

232 fi
233 if test "$PLUGIN_ICONV" = "yes"; then
234    dnl AM_ICONV
235    if test "$am_cv_func_iconv" = "yes"; then
236       PLUGINS="$PLUGINS plugin_iconv.o"

because aclocal was complaining about "something" (I can not  
remember), that had to do with this entry.
so this might be the reason why the diff is rather huge-ish (it  
affects more files than it should). Other than that, I just sticked to  
the instructions in the wiki, the plugin_button_exec.c is the "real  
stuff". I'd really like to document my work in the wiki, so other  
people can use my plugin. Feel free to correct my code in any way you  
want, it's been ~5 years since my last c program.

> Rob


Get my patch here (I don't want to send 116 kb to every person on this  
ML):
http://tiny.wogri.at/JI

thx,
wogri


-- 
wo...@wo...
http://www.wogri.com
http://www.einradfilm.at

Re: [Lcd4linux-devel] new plugin: button_exec

[Robert B. <rb...@ge...>]

On Monday, 21. January 2008, Wolfgang Hennerbichler wrote:
> Where should I send my patch to?

This list is fine.


Rob

Re: [Lcd4linux-devel] new plugin: button_exec

[Andrew C. <an...@or...>]

On Mon, 2008-01-21 at 14:06 +0100, Wolfgang Hennerbichler wrote:
> Hi,
> 
> I've written a plugin that works a little different than the "stock"  
> exec-plugin.
> exec-plugins are called every timeinterval, my plugin forks off a  
> command and runs that command only once. Very useful in case you want  
> to trigger an action once a button is pressed. The plugin eats a  
> command and an unlimited number of parameters to that command.

Ah, nice.  You can imagine my surprise when I first tried the exec
command without reading the docs carefully. :)

> 
> Where should I send my patch to?
> 
> wogri
> 
-- 
Regards,
Andrew Clunis

[Lcd4linux-devel] new plugin: button_exec

[Wolfgang H. <wo...@wo...>]

Hi,

I've written a plugin that works a little different than the "stock"  
exec-plugin.
exec-plugins are called every timeinterval, my plugin forks off a  
command and runs that command only once. Very useful in case you want  
to trigger an action once a button is pressed. The plugin eats a  
command and an unlimited number of parameters to that command.

Where should I send my patch to?

wogri

-- 
wo...@wo...
http://www.wogri.com
http://www.einradfilm.at

Re: [Lcd4linux-devel] [lcd4linux] Evaluating conditional expression on strings

[yvecai <yv...@gm...>]

I would go for the tilde!

Michael Reinelt a écrit :
>> In my example,
>>     visible xmms(Status)=='Playing'?0:1
>> desn't work: the conditional test 'a'=='b'?0:1 desn't seem to work if 
>> 'a' and 'b' are strings.
>
> You are right: the operators '==' and '<>' are working on numbers only 
> (same as it is in Perl)
>
> Adding 'perlish' string tests 'eq' and 'ne' isn't that easy, for the 
> evaluator does not support alphanumeric operator tokens.
>
> Hmmm....
>
> any ideas anyone? Is there a senseful operator token for string compare?
>
> probably the tilde? a ~ b (equal) or a !~ b (not equal) ???
>
>
> bye, Michael
>
>

Re: [Lcd4linux-devel] [lcd4linux] Evaluating conditional expression on strings

[Michael R. <mi...@re...>]

> In my example,
>     visible xmms(Status)=='Playing'?0:1
> desn't work: the conditional test 'a'=='b'?0:1 desn't seem to work if 
> 'a' and 'b' are strings.

You are right: the operators '==' and '<>' are working on numbers only 
(same as it is in Perl)

Adding 'perlish' string tests 'eq' and 'ne' isn't that easy, for the 
evaluator does not support alphanumeric operator tokens.

Hmmm....

any ideas anyone? Is there a senseful operator token for string compare?

probably the tilde? a ~ b (equal) or a !~ b (not equal) ???


bye, Michael


-- 
Michael Reinelt <mi...@re...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Re: [Lcd4linux-devel] Adding I2C based LCD support

[Luis C. <lui...@gm...>]

Michael Reinelt wrote:
> Hi Eran,
> 
>> I plan adding to the lcd4linux package a support with another I2C LCD (ST7032i controller). 
> That sounds great!
> 
>> I base on the HD44780-I2C driver in my implementation.
>> I saw that you recommend in your website to contact you in case someone wants to add an I2C base LCD support.
>> Is there any problem with it ? Do I need to do something extra ?
> 
> I'm not sure (I never played with i2c), but some stuff may be missing in 
> the "new driver howto" and in the skeleton driver. But as you use the 
> HD44780-I2C, everything should work.
> 
> 
> happy new year!
> 

Hi!

I do have now a working hd4780 lcd4linux with i2c.
It's kinda working, it becomes corrupted after a while, but I think it's 
something to do with it not being a true hd44780. it's an hd66710, which 
is essentialy compatible but not 100%.

Timings are critical in my platform (PcEngines wrap1c).

I'll help in whichever way you need.

Luis Correia


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: [Lcd4linux-devel] Adding I2C based LCD support

[Michael R. <mi...@re...>]

Hi Eran,

> I plan adding to the lcd4linux package a support with another I2C LCD (ST7032i controller). 
That sounds great!

> I base on the HD44780-I2C driver in my implementation.
> I saw that you recommend in your website to contact you in case someone wants to add an I2C base LCD support.
> Is there any problem with it ? Do I need to do something extra ?

I'm not sure (I never played with i2c), but some stuff may be missing in 
the "new driver howto" and in the skeleton driver. But as you use the 
HD44780-I2C, everything should work.


happy new year!

-- 
Michael Reinelt <mi...@re...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

[Lcd4linux-devel] Adding I2C based LCD support

[Eran Ben-A. <era...@ya...>]

Hi,

I plan adding to the lcd4linux package a support with another I2C LCD (ST7032i controller). I base on the HD44780-I2C driver in my implementation.
I saw that you recommend in your website to contact you in case someone wants to add an I2C base LCD support.
Is there any problem with it ? Do I need to do something extra ?


Thanks,
Eran.




      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

[Lcd4linux-devel] lcm162 keypad patch

[Dirk J. <do...@cu...>]

Hello,

the attachted patch maps the four keypad buttons of the lcm162 module to 
the Keypad widget. You are free to include this patch in future releases 
of lcd4linux.

-- 
---> Dirk Jagdmann
----> http://cubic.org/~doj
-----> http://llg.cubic.org

Re: [Lcd4linux-devel] [lcd4linux] Can i use the Image widget with Serdisplib?

[Gilles v. d. H. <gil...@gm...>]

Hey Till,

About the contrast, that is also what i thought. Maybe i can use other
transistors to control the brightness in another way. ;)

Anyway, the thing i want to use lcd4linux for is an aquarium computer.
Basicly it is a linux box without monitor, and i want to "display" graphs,
clocks etc. the basic GLCD stuff on it. I want a script to constantly
generate "png" files, since that is what i've learnt from the TRAC pages,
unless you have a better idea. I am open for suggestions and willing to test
off course. I don't have the KS0108 GLCD yet, but i was thinking about
buying
a) 192x64
b) 128x64
and driving them using a parralel port.

So my new questions are:
- can both versions be controlled with the future version
- does the new driver also support parralel port or is that to slow for what
you want?
- is PNG images still the way to go or is there another way?

Btw, A refresh rate of >20hz means +/-20fps?

Thanx
Gilles

On 10/24/07, Till Harbaum / Lists <li...@ha...> wrote:
>
> Hi,
>
> i just finished the first prototypes for my glcd2usb, the graphic
> version of the lcd2usb. And the first display type to be supported
> by glcd2usb is the ks0108 family. And with that the image widget
> is working fine and i get a screen refresh rate of >20Hz, sufficient
> for fluid animations ...
>
> I'll soon publish all the necessary parts. But the contrast is not
> software
> controllable. It would be quite complicated to make this part software
> configurable for the ks0108 as this requires to handle a negative voltage
> generated by the ks0108 internally. This is justr not worth the effort as
> most people will never change the contrast, anyway.
>
> Till
>
> Am Mittwoch 24 Oktober 2007 schrieb Gilles van den Hoven:
> > Hello,
> >
> > I am looking to buy an LCD which has the KS0108 controller. This is a
> > Graphic LCD display 128x64.
> > This display has to be controlled by LCD4Linux with the Serdisplib (that
> > supports the KS0108 controller). - Is it then still possible to use the
> > image widget?
> >
> > Is it also possible (after the LCD program has started) to change the
> > contrast programmaticly?
> >
> > Thanx
> > Gilles
>
>
>

Re: [Lcd4linux-devel] [lcd4linux] Can i use the Image widget with Serdisplib?

[Till H. / L. <li...@ha...>]

Hi,

i just finished the first prototypes for my glcd2usb, the graphic
version of the lcd2usb. And the first display type to be supported
by glcd2usb is the ks0108 family. And with that the image widget
is working fine and i get a screen refresh rate of >20Hz, sufficient
for fluid animations ...

I'll soon publish all the necessary parts. But the contrast is not software
controllable. It would be quite complicated to make this part software
configurable for the ks0108 as this requires to handle a negative voltage
generated by the ks0108 internally. This is justr not worth the effort as
most people will never change the contrast, anyway.

Till

Am Mittwoch 24 Oktober 2007 schrieb Gilles van den Hoven:
> Hello,
>
> I am looking to buy an LCD which has the KS0108 controller. This is a
> Graphic LCD display 128x64.
> This display has to be controlled by LCD4Linux with the Serdisplib (that
> supports the KS0108 controller). - Is it then still possible to use the
> image widget?
>
> Is it also possible (after the LCD program has started) to change the
> contrast programmaticly?
>
> Thanx
> Gilles

Re: [Lcd4linux-devel] Proper return value drv_generic_keypad_real_press callback on key release AND addition of new key constants.

[Michael R. <mi...@re...>]

Hi Andrew,

> I'm working on keypad support for the PicoLCD, and while I basically
> have it all working now, I'd just like to confirm what should be
> returned from the drv_generic_keypad_real_press callback:
> 
> Should I return WIDGET_KEY_RELEASED *plus* the constant of the key being
> released, or should I return WIDGET_KEY_RELEASED all on it's own?
Whil looking at the other drivers that support keypads, I think you 
should add WIDGET_KEY_RELEASED to the keycode.

> PS.  This keypad device supports more keys than are found in
> widget_keypad.c/.h.  I propose adding:
> 
> WIDGET_KEY_F1
> WIDGET_KEY_F2
> WIDGET_KEY_F3
> WIDGET_KEY_F4
> WIDGET_KEY_F5
> WIDGET_KEY_PLUS
> WIDGET_KEY_MINUS

Feel free to do so, patches are welcome. Thanks in advance!

OTOH,  personaly I'm not very happy with the current design of keypad 
handling. These hardcoded key codes may be a neverending story.... If 
you or anybode else has a better idea, please stand up!


bye, Michael

-- 
Michael Reinelt <mi...@re...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

[Lcd4linux-devel] Proper return value drv_generic_keypad_real_press callback on key release AND addition of new key constants.

[Andrew C. <an...@or...>]

Hi!

I'm working on keypad support for the PicoLCD, and while I basically
have it all working now, I'd just like to confirm what should be
returned from the drv_generic_keypad_real_press callback:

Should I return WIDGET_KEY_RELEASED *plus* the constant of the key being
released, or should I return WIDGET_KEY_RELEASED all on it's own?

PS.  This keypad device supports more keys than are found in
widget_keypad.c/.h.  I propose adding:

WIDGET_KEY_F1
WIDGET_KEY_F2
WIDGET_KEY_F3
WIDGET_KEY_F4
WIDGET_KEY_F5
WIDGET_KEY_PLUS
WIDGET_KEY_MINUS

-- 
Regards,
Andrew Clunis

Re: [Lcd4linux-devel] Pyramid LCD

[Michael R. <mi...@re...>]

Hi Stefan,

please note that this is an english mailing list.

> ich m=F6chte gerne lcd4linux mit einem pyramid display benutzen.
> ist das m=F6glich?

translation: is it possible to use a pyramid display with lcd4linux?

answer: I don't know because I've never heard of pyramid displays. Can=20
you post a link, a data sheet or something else?

TIA, Michael

--=20
Michael Reinelt <mi...@re...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

[Lcd4linux-devel] Pyramid LCD

[<swu...@wu...>]

Guten Tag
=20
ich m=F6chte gerne lcd4linux mit einem pyramid display benutzen.
=20
ist das m=F6glich?
=20

Mit freundlichen Gr=FCssen
W=FCthrich Stefan

  _____ =20

W=FCthrich Electronic | RC-Fly =20
W=FCthrich Stefan swu...@wu...=20
Weidweg 5b =20
5702 Niederlenz  =20
  =20
Tel : 062 5112 117 Direkt : 062 511 22 17=20
www.wuethrich-electronic.ch | www.rc-fly.ch

  =20

=20

=20

Re: [Lcd4linux-devel] asm/msr.h inclusion and RDTSC stuff removed

[Robert B. <rb...@ge...>]

On Thursday, 4. October 2007, Robert Buchholz wrote:
> Did you test the changes? I'd like to include the patch in Gentoo
> soon before the 2.6.22 headers are going stable.

Oh, and I forgot. For testing, one should own any of
* HD44780
* LPH7508
* M50530
* Noritake
* RouterBoard
* T6963

-R.

Re: [Lcd4linux-devel] asm/msr.h inclusion and RDTSC stuff removed

[Robert B. <rb...@ge...>]

On Monday, 1. October 2007, Michael Reinelt wrote:
> The rdtsc stuff worked fine, but had two major disadvantages: It did
> not work with variable CPU frequencies, and latest kernels do no
> longer offer the rdtsc() macro.

Thanks for taking care of this.

> The changeset has been committed to trunk, and will be backported to
> the 0.10.1 branch as soon as I get some positive feedback 8or at
> least I don't get any negative feedback)

I pulled the changes minus the keypad stuff into lcd4linux-0.10.1-RC2=20
and it compiled and worked fine. That doesn't mean a lot though because=20
my two test displays (LUIse and PicoLCD) don't use the udelay stuff (I=20
wonder why the header is included in their drv_*.c) :-/

Did you test the changes? I'd like to include the patch in Gentoo soon=20
before the 2.6.22 headers are going stable.

Regards,
Robert

Re: [Lcd4linux-devel] Keypad support

[Michael R. <mi...@re...>]

Hi Andrew,

> I've been trying to figure out how exactly one is supposed to use the
> keypad support (from both a user's and developer's perspective)
> mentioned in the source code.

Well, the problem is that there is no real design for keypad handling 
yet (Except the keypad widget)

>  My idea is to get my D-Bus plugin for
> lcd4linux to raise signals whenever a button is pushed.

Fropm the current point of view, I'd recommend writing a function in the 
D-Bus plugin which raises a signal, and call this function from the 
keypad widget.


HTH, Michael

-- 
Michael Reinelt <mi...@re...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

Re: [Lcd4linux-devel] HD44780 RS and R/W states

[Michael R. <mi...@re...>]

Hi Yves,

> In the How-to http://ssl.bulix.org/projects/lcd4linux/wiki/Howto
> RS and RW states (low and high) are inverted compared to the HD447800 page.

Thanks a lot for pointing this out! Should be corrected.


bye, Michael

-- 
Michael Reinelt <mi...@re...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781

[Lcd4linux-devel] HD44780 RS and R/W states

[Yves <y.c...@fr...>]

In the How-to http://ssl.bulix.org/projects/lcd4linux/wiki/Howto
RS and RW states (low and high) are inverted compared to the HD447800 page.

My attempts with an Everbouquet LCD module makes me believe that the 
second one is OK.

Yves

[Lcd4linux-devel] Everbouquet MC2004-SYL supported LCD

[Yves <y.c...@fr...>]

Hi,
Just to say th HD44780 driver works fine with an Everbouquet MC2004E-SYL 
(avaiable at Farnell.com).

No trace if its a HD44780 driven module either.

Very good job with LCD4L!INUX, many thanks !

[Lcd4linux-devel] asm/msr.h inclusion and RDTSC stuff removed

[Michael R. <mi...@re...>]

Hi there,

I just committed a changeset where I removed the whole RDTSC delay loop 
stuff, and therefore lcd4linux does no longer need asm/msr.h

Instead, a gettimeofday() delay loop will be used when necessary.

The rdtsc stuff worked fine, but had two major disadvantages: It did not 
work with variable CPU frequencies, and latest kernels do no longer 
offer the rdtsc() macro.

The changeset has been committed to trunk, and will be backported to the 
0.10.1 branch as soon as I get some positive feedback 8or at least I 
don't get any negative feedback)


bye, Michael

-- 
Michael Reinelt <mi...@re...>
http://home.pages.at/reinelt
GPG-Key 0xDF13BA50
ICQ #288386781