lcd4linux-devel — lcd4linux development team

Re: [Lcd4linux-devel] ANNOUNCE: LCD4Linux-0.10.1-RC1 released!

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

Michael Reinelt wrote:
> Thanks to Martin Hejl (who kicked me in the ass some days ago), I
> released the first release candidate of LCD4Linux-0.10.1
> 
> Have a look at http://lcd4linux.bulix.org for details, download, and a
> (probably incomplete) list of changes.

Finally! I just bumped the version in Gentoo[1] and ran into few minor
problems:

1. ChangeLog
As you sure noticed, the ChangeLog shipped with the RC was not current.

2. Filename and URL
There's a problem with you hosting the download files in the wiki:
Besides the download being pretty slow (about 10kb/s), with a wget query
the downloaded file's name will be
"lcd4linux-0.10.1-RC1.tar.gz?format=raw". As renaming does not work with
the Gentoo package management and mirror scripts, I cannot give your
link as "source link" in the package. I worked around that problem by
manually introducing the file into the Gentoo mirroring, but if it is
possible in the future, please host the file outside the wiki.

3. gcc-Warning
Maybe you saw them yourself, but in case you missed them, here they are:

drv_BeckmannEgle.c: In function 'drv_BuE_CT_start':
drv_BeckmannEgle.c:355: warning: overflow in implicit constant conversion

drv_WincorNixdorf.c: In function 'drv_WN_start':
drv_WincorNixdorf.c:143: warning: overflow in implicit constant conversion

drv_Image.c: In function 'drv_IMG_flush_PPM':
drv_Image.c:117: warning: format '%d' expects type 'int', but argument 4
has type 'long unsigned int'
drv_Image.c:124: warning: format '%d' expects type 'int', but argument 3
has type 'long unsigned int'

plugin_mysql.c: In function 'configure_mysql':
plugin_mysql.c:93: warning: pointer targets in passing argument 6 of
'cfg_number' differ in signedness


> The 'trunk' was bumped to version 0.10.2, but there will be no
> development until 0.10.1 is released.
> 
> I'd appreciate any tests and feedback on RC1, so we can release 0.10.1
> shortly, and continue work on 0.10.2 (there are plans for scrolling,
> finally!)

Is there a reason you didn't svn-tag the rc? It's always nice to have
the old versions tagged to get the changes at the next release :-)


> So that's the main reason for releasing that seldom: every time I'm
> thinking of releasing something, someone sends me a new and unsupportd
> display :-)

Damn. I just get to see the pictures of the displays in the wiki. Must
be nice to get some examples ;-P

Anyway, nice work.

Robert

[1] http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-misc/lcd4linux/

[Lcd4linux-devel] ANNOUNCE: LCD4Linux-0.10.1-RC1 released!

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

Hi there,

Thanks to Martin Hejl (who kicked me in the ass some days ago), I
released the first release candidate of LCD4Linux-0.10.1

Have a look at http://lcd4linux.bulix.org for details, download, and a
(probably incomplete) list of changes.

The 'trunk' was bumped to version 0.10.2, but there will be no
development until 0.10.1 is released.

I'd appreciate any tests and feedback on RC1, so we can release 0.10.1
shortly, and continue work on 0.10.2 (there are plans for scrolling,
finally!)

Note that I got two cool displays recently, but I withstood to develop a
driver for them, but released RC1.

So that's the main reason for releasing that seldom: every time I'm
thinking of releasing something, someone sends me a new and unsupportd
display :-)


Have fun, Michael


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

Re: [Lcd4linux-devel] news intertriba

[Harvey C. <lis...@da...>]

Hi,


V / A G R A
V A L / U M
C / A L / S

http://www.tedrx .com

Remove space in the above link.



scarves and shawls around their heads.
Its not that cold,  said Hermione defensively. Why didnt they bring
cloaks? 

Re: [Lcd4linux-devel] Release

[Lars S. <st...@te...>]

Martin Hejl wrote:
> Hi Michael,
> 
> what are the chances that we'll see a release some time soon? I've been
> working on updating the outrageously outdated setup for Bering uClibc -
> but right now, lcd4linux is a moving target, and trying to keep a setup
> current against ever changing svn snapshots is not much fun (and, if I
> may say, not time well spent, at least for me). I would like to see a
> stable source that received bugfixes only, that a broad userbase can
> actually test before it changes again and have that released after it's
> seen some testing. After that, adding new stuff can continue, but lets
> make sure that the current release at least somewhat resembles what is
> described in the wiki.
> 
> What exactly is holding you back from declaring the svn status of a
> given point in time a "Release candidate", put that on the webpage, give
> people a chance to actually test it, and make a release? If things are
> constantly changing, you'll never get a broad userbase to test things.
> 
> Just my thoughts - the version I pulled from svn (outdated already,
> despite the fact that it's only 3 days old) works for me, so I'm in no
> dying need to update the official lcd4linux package - but if you want
> more people to use the current version of lcd4linux, it would probably
> be a good idea to give them a "current" version (svn snapshots don't
> count, IMHO).
> 
> Martin

+1.

I'm sort of waiting for a stable point to try some additions to the
Crystal 635 LCD Display. I find the code base to be somewhat of a
moving target as well, and I have to admit, it's holding us back.
/Lars

[Lcd4linux-devel] Release

[Martin H. <ma...@he...>]

Hi Michael,

what are the chances that we'll see a release some time soon? I've been
working on updating the outrageously outdated setup for Bering uClibc -
but right now, lcd4linux is a moving target, and trying to keep a setup
current against ever changing svn snapshots is not much fun (and, if I
may say, not time well spent, at least for me). I would like to see a
stable source that received bugfixes only, that a broad userbase can
actually test before it changes again and have that released after it's
seen some testing. After that, adding new stuff can continue, but lets
make sure that the current release at least somewhat resembles what is
described in the wiki.

What exactly is holding you back from declaring the svn status of a
given point in time a "Release candidate", put that on the webpage, give
people a chance to actually test it, and make a release? If things are
constantly changing, you'll never get a broad userbase to test things.

Just my thoughts - the version I pulled from svn (outdated already,
despite the fact that it's only 3 days old) works for me, so I'm in no
dying need to update the official lcd4linux package - but if you want
more people to use the current version of lcd4linux, it would probably
be a good idea to give them a "current" version (svn snapshots don't
count, IMHO).

Martin

[Lcd4linux-devel] Aggressive Investors Alert

[sustain <ce...@be...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2912" name=3D"GENERATOR">
</HEAD>
<BODY>
<DIV align=3Dleft><FONT face=3DArial size=3D2><B>TRADERS! PSUD is going through the roof next week!</B></FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2><I>WATCH OUT! </I></FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2><I>Monday January 29 IS SURE TO BE A GOOD DAY!</I></FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Company: <B>PetroSun</B> </FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Sym: <B>PSUD</B> </FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Currently: <B>$0.52 (+0.09 Close) 20.9%</B></FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2>Friday Target: <B>$1.50</B></FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2>2007-01-11 11:46 ET - News Release</FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2>PetroSun, Incorporated (PNKSHEETS: PSUD) recently announced that they have an agreement executed with New Standard Exploration NL of West Perth, Australia. It covers the Exploration Pemit 417 which is location within Western Australias Canning Basin. a Joint venture has been established to explore develop and produce oil and or gas from EP417. PetroSun was assigned a 75% working interest in the permit, intial consideration of $5Million.</FONT></DIV><BR>
<DIV align=3Dleft><FONT face=3DArial size=3D2><B><U>ADD THIS TO YOUR LIST AND WATCH IT LIKE A HAWK ON Monday January 29, 2007!!!!<U></B></FONT></DIV></BODY></HTML>

[Lcd4linux-devel] =?gb2312?Q?Join_ECVV_Free, Enjoy_trade_opportunities=2E=2E?=

[<ecv...@ec...>]

 

Welcome to the Ecvv=2Ecom!

http://www=2Eecvv=2Ecom/public/sendemail/tj=2Easp=3Fq=3D40

[Lcd4linux-devel] Test for GMANE

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

Test, please ignore

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

[Lcd4linux-devel] new driver: picuLCD

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

Hi there,

thanks to Nicu Pavel from iTuner Networks, there's a new driver
available: picoLCD!

Product page: http://www.mini-box.com/picoLCD-20x2-OEM

This is the first LCD developed by iTuner but more LCD products will
follow (graphics/text).

Documentation will soon be added to the wiki.


Enjoy!

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

Re: [Lcd4linux-devel] Subversion and/or autoconf/automake experts wanted

[FoX <fo...@gm...>]

2007/1/18, Michael Reinelt <re...@eu...>:
> Hi there,
>
> I want to have the current svn repository version (the output of
> 'svnversion') somehow automagically in the code.
>
> Anyone has ideas about how to do this in a portable way with
> autoconf/automake?
>
> This should work with the .tar.gz version, too, where we may not have a
> svn client (and therefore no 'svnversion'). Please keep this in mind!
>

You can take a look at version.sh from mplayer :
http://svn.mplayerhq.hu/mplayer/trunk/version.sh?revision=21946&view=markup

-- 
Guillaume LECERF
GeeXboX developer

[Lcd4linux-devel] Subversion and/or autoconf/automake experts wanted

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

Hi there,

I want to have the current svn repository version (the output of
'svnversion') somehow automagically in the code.

Anyone has ideas about how to do this in a portable way with
autoconf/automake?

This should work with the .tar.gz version, too, where we may not have a
svn client (and therefore no 'svnversion'). Please keep this in mind!


TIA, Michael

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

Re: [Lcd4linux-devel] GMANE

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

Hey,

>> Nevertheless, please go for option 2 where the email is concealed
>> and encripted.
>
> I agree. So Robert, go for it!
>
> Maybe you shuld as a first step just set up the list archive and  
> stuff,
> but not yet import all old archives; so we can have a look at it.

You are right, that can be done later. One has to file a support  
request like here:
http://sourceforge.net/tracker/index.php? 
func=detail&aid=935688&group_id=1&atid=200001
to get an importable version of the sourceforge mailman archives.

Besides that, I sent a request to subscribe the groups
   gmane.comp.sysutils.lcd4linux.devel
and
   gmane.comp.sysutils.lcd4linux.user

Let's see how fast they are.

Regards,

Robert

[Lcd4linux-devel] uClinux patch (fork/vfork)

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

Hi Hans,

I just had a look at your patch. You did change fork() to vfork in the
daemonize() function; this has changed to a double-fork in the current code.

And there's a 2nd area where fork is used: the thread management. Don't
you use/need it at all?

for the first daemonize: As there's no exec() after the vfork(), the
caller process would block. Is this what you want? Or should I
completely skip the daemonize stuff on uclinux?

TIA, Michael


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

Re: [Lcd4linux-devel] Fwd: Re: [lcd4linux] uClinux patch.

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

Hi Hans,

>> I will provide a special configure target "--with-drivers=HD44780-I2C"
>> which will compile the HD44780 driver withaout any parport references.
>> Please test & give feedback!
> 
> Great, i will try it. Will grab latest SVN whenever you have anything
> compiling.

already checked in!

>>> And i also needed to
>>> change fork() to vfork() since uClinux does not support fork().

> http://docs.blackfin.uclinux.org/doku.php?id=living_without_forks&s=vfork

Ok, got it.

What about the 'daemonize()' stuff in lcd4linux.c (there's a double-fork) ?

>> is there any *reliable* preporcessor constant I could use?
> 
> Use #ifdef UCLINUX
> is the commony used macro whever doing special cases for uClinux, it should
> allways be defined when compiling towards uclinux.

Ok, I will prepare a patch.


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

[Lcd4linux-devel] FW: GMANE

[Luis.F.Correia <Lui...@se...>]

Resent to the list 

-----Original Message-----
From: Michael Reinelt [mailto:re...@eu...] 
Sent: Wednesday, January 17, 2007 12:24 PM
To: Luis.F.Correia
Subject: Re: GMANE

Hi there,

>> Personally, I still like the idea, but if you have concerns, then 
>> just drop the plan. I don't want to force anything on the project :-)
> 
> Nevertheless, please go for option 2 where the email is concealed and 
> encripted.

I agree. So Robert, go for it!

Maybe you shuld as a first step just set up the list archive and stuff, but
not yet import all old archives; so we can have a look at it.


TIA, Michael

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

Re: [Lcd4linux-devel] GMANE

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

Hi there,

>> Personally, I still like the idea, but if you have concerns, 
>> then just drop the plan. I don't want to force anything on 
>> the project :-)
> 
> Nevertheless, please go for option 2 where the email is concealed
> and encripted.

I agree. So Robert, go for it!

Maybe you shuld as a first step just set up the list archive and stuff,
but not yet import all old archives; so we can have a look at it.


TIA, Michael

@Luis: sorry, the first mail was adressed to you only.

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

Re: [Lcd4linux-devel] [lcd4linux] Improvement ideas for Project a ccessibility [WAS: Re: lcd4linux - My message to the devel-list]

[Luis.F.Correia <Lui...@se...>]

 
Robert,

> -----Original Message-----
> > can we have a GMane archive without the news interface?
> 
> No, I'm afraid not.
> Personally, I still like the idea, but if you have concerns, 
> then just drop the plan. I don't want to force anything on 
> the project :-)

While i'm a 'lesser' developer in lcd4linux, i do not want to 
impose my concerns and fears to the rest of the community.

Nevertheless, please go for option 2 where the email is concealed
and encripted. It is better to 'trust' another server in which
Gmane trusts then to leave the email addresses ready to be harvested.

> 
> 
> Regards,
> 
> Robert
> 
> 

Luis Correia

Re: [Lcd4linux-devel] [lcd4linux] Improvement ideas for Project a ccessibility [WAS: Re: lcd4linux - My message to the devel-list]

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

Luis.F.Correia schrieb:
> Robert,
>=20
> can we have a GMane archive without the news interface?

No, I'm afraid not.
Personally, I still like the idea, but if you have concerns, then just
drop the plan. I don't want to force anything on the project :-)


Regards,

Robert

[Lcd4linux-devel] Fwd: Re: [lcd4linux] uClinux patch.

[Hans E. <ha...@ru...>]

tisdag 16 januari 2007 21:25 skrev du:
> Hi Hans,

Hello Michael.

> I hope you don't mind the CC'ing to lcd4linux-devel....

No problem. Maybe you can create a task in the seemingly smooth Trac system,
we are currently looking at moving over our open parts of our embedded
project to Trac. Looks promising.

> > Meaning we would really want a simple button/LCD interface for an
> > operator to handle, something very simple and easy to set up and use.
> > Ideas involving menu hierarchy in a XML or XML-like format for example(or
> > something very more light weight, a simple intentaion format may do
> > well). Would it be possible/suitable to add such functionality to
> > lcd4linux?
>
> Oh, I read the evil word "Buttons" here :-)
>
> > Saw there was a
> > button plug-in for example. Im more of a hardware/kernel guy than
> > userland/sysadmin so im not well oriented in all the aspects of user
> > interaction in uclinux, maybe/probably this has been done before. Any
> > ideas?
>
> Well, I am thinking about Buttons/keypads for years now. As I'm thinking
> about dynamic layouts....

Yes, UIs or GUIs are allways a hazzle. Im still hesitating to make a
 descition about the LCD/button or touchscreen or whatever will suit our
 project. Hope i can postpone this decision a few more weeks until i know
 what is the right(meaning flexible, not painting ourselves into a crorner)
 solution. Need to investigate more here. Anyone with ideas around this are
 very welcome to speak.

> > I should have checked out the SVN version instead, but no problem of
> > making a new patch since it was no major changes. In short i just wanted
> > to achieve a compile with no referencs to parport related functions,
> > there were a few references to it in drv_HD44780.c/.h even though not
> > allways needed when display sits on i2c (or maybe other hardware as
> > well).
>
> I will provide a special configure target "--with-drivers=HD44780-I2C"
> which will compile the HD44780 driver withaout any parport references.
> Please test & give feedback!

Great, i will try it. Will grab latest SVN whenever you have anything
compiling.

> > And i also needed to
> > change fork() to vfork() since uClinux does not support fork().
>
> erm... are you really sure? From what I know, vfork just saves a few
> cycles if fork() is immediately followed by exec(), but the caller
> blocks until the exec() is successful (so it's dangerous because if
> exec() fails, the behaviour is undefined)

Both are right. UClinux are Linux for MMU-less systems, hence it lacks the
true memory protection and also the complete VM subsystem that Linux
supports - there is NO virtual memory in uclinux and fork() works need
virtual memory to work. fork() create a parent and a child with separate taks
control structures and programs will reside in separate virtual memory
mappings(sharing memory until COW). For details, have a look here:

http://docs.blackfin.uclinux.org/doku.php?id=living_without_forks&s=vfork

> is there any *reliable* preporcessor constant I could use?

Use #ifdef UCLINUX
is the commony used macro whever doing special cases for uClinux, it should
allways be defined when compiling towards uclinux.

> > I think embedded linux is comming strong
> > now so it would be cool for lcd4linux to be the lcd software of choice
> > such systems.
>
> 1000% agree :-)

Great!

> bye, Michael

Adios!

/Hans

-------------------------------------------------------

Re: [Lcd4linux-devel] [lcd4linux] Improvement ideas for Project a ccessibility [WAS: Re: lcd4linux - My message to the devel-list]

[Luis.F.Correia <Lui...@se...>]

Robert,

can we have a GMane archive without the news interface?

if yes, I would go for the first option.


Luis Correia

Re: [Lcd4linux-devel] Improvement ideas for Project accessibility [WAS: Re: lcd4linux - My message to the devel-list]

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

Robert Buchholz schrieb:
> The list has to/should be signed up by the list admin, but it's just a
> small form. The imports are possible with the digests provided by
> mailman at https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel=


Okay, that did not work as planned: sourceforge does not have the
"standard" mail archive with mbox mails online.
Maybe it can be reached on the filesystem somehow?


Robert

Re: [Lcd4linux-devel] Improvement ideas for Project accessibility [WAS: Re: lcd4linux - My message to the devel-list]

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

Michael Reinelt schrieb:
>>> Currently, I cannot see the mail messages at sourceforge.
> Well, I think ther *is* a mailing list archive at SF...

You are right. Back when I first wrote my email, the mailman archive was
not searchable (and it not right now), but I see that the "forums" like
archive did improve a lot (concerning searching). So the issue I had
with the existing archives are smaller now, I have to agree (still, I
love the frame view of GMANE, but maybe that's just me :-)


>>> Maybe it would be a good idea to also use an alternative archiving
>>> service. There's a great one for archiving open source mailing lists =
and
>>> viewing them, called GMANE, I am sure you heard about it.
> No, I have not.
>=20
> But I think this is a good idea!
>=20
> At the moment the mailing list is the only important thing hosted at
> SourceForge, which I want to get rid of, too (the hosting, not the
> mailing lists)

When moving away from sourceforge, it would be a good idea to have a new
central place for the older and later archives.
Do you plan to abandon sf completely (as in 'remove the project')?


> For the moment it would be great if you could set up the list archive a=
t
> gmane, and probably even import the archives from sourceforge (I read
> something there that such an import should be possible).

The list has to/should be signed up by the list admin, but it's just a
small form. The imports are possible with the digests provided by
mailman at https://lists.sourceforge.net/lists/listinfo/lcd4linux-devel

Regards,

Rob

Re: [Lcd4linux-devel] [lcd4linux] Improvement ideas for Project accessibility [WAS: Re: lcd4linux - My message to the devel-list]

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

Michael Reinelt schrieb:
> Hi,
>=20
>> I have personal issues with GMANE, all of them SPAM related.=20
>>
>> Therefore I will only accept it if my (or all) email addresses are con=
cealed
>> from  the GMANE public archive.
>=20
> ok, good point, I fully agree.
>=20
> from what I remember GMANE does provide something like "address hiding"=
=2E
>=20
> @Robert: Could you please double-check that?

Luis, I totally agree on the Spam issue. If I understand it correctly,
there are two options gmane offers:
* standard protection: this will obfuscate the mail address in the web
  interface, but the news service they offer will contain the plain text
  addressess (as it usually is in usenet)
* total encryption: all email addresses will be encrypted and will go
  over the gmane server, being filtered there and all who sustain the
  filter, will still get a response in which they have to click a link
  to get their (private) mail through to you.

See also http://gmane.org/tmda.php on the second option.

Robert

Re: [Lcd4linux-devel] [lcd4linux] uClinux patch.

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

Hi Hans,

I hope you don't mind the CC'ing to lcd4linux-devel....

> Meaning we would really want a simple button/LCD interface for an operator to 
> handle, something very simple and easy to set up and use. Ideas involving 
> menu hierarchy in a XML or XML-like format for example(or something very more 
> light weight, a simple intentaion format may do well). Would it be 
> possible/suitable to add such functionality to lcd4linux? 
Oh, I read the evil word "Buttons" here :-)

> Saw there was a 
> button plug-in for example. Im more of a hardware/kernel guy than 
> userland/sysadmin so im not well oriented in all the aspects of user 
> interaction in uclinux, maybe/probably this has been done before. Any ideas?

Well, I am thinking about Buttons/keypads for years now. As I'm thinking
about dynamic layouts....

> I should have checked out the SVN version instead, but no problem of making a 
> new patch since it was no major changes. In short i just wanted to achieve a 
> compile with no referencs to parport related functions, there were a few 
> references to it in drv_HD44780.c/.h even though not allways needed when 
> display sits on i2c (or maybe other hardware as well).
I will provide a special configure target "--with-drivers=HD44780-I2C"
which will compile the HD44780 driver withaout any parport references.
Please test & give feedback!

> And i also needed to 
> change fork() to vfork() since uClinux does not support fork().
erm... are you really sure? From what I know, vfork just saves a few
cycles if fork() is immediately followed by exec(), but the caller
blocks until the exec() is successful (so it's dangerous because if
exec() fails, the behaviour is undefined)

is there any *reliable* preporcessor constant I could use?

> I think embedded linux is comming strong 
> now so it would be cool for lcd4linux to be the lcd software of choice such 
> systems.

1000% agree :-)


bye, Michael

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

Re: [Lcd4linux-devel] [lcd4linux] uClinux patch.

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

Hi Luis,

>> OTOH, if you like to have your 'own' driver, we could do so; 
>> but they would share some common code... maybe we could 
>> backport your changes later... just let me know what you prefer.
> 
> what I had in mind was something even less stressfull but maybe hard
> to make. and it is split the HD44780 driver even further so that
> the actual 'bus' connection is fully separated from the HD44780 core.
> 
> which would make things like supporting different connections even simpler

You are right, I've been thinking about such a solution, too. But let's
do this after a 0.10.1 (or 0.11) has been released :-)

OTOH, different HD44780 drivers do not share that much code.. If I think
about the various USB2HD44780 adapters, the only thing in common is the
display ram addressing scheme, and some CGRAM stuff. But with USB you
don't care about 4/8 bit, timings, wirings, and all that stuff that
makes the current HD44780.c *that* complicated.

Probably it would be easiest just to split the driver into bus-dependant
parts, and don't care about the common code. As a second step, take the
HD44780 drivers that are already extra files into account, and look for
common code, and try to find a clean and simple way to unify it.

For the time being, I'll implement the "HD44780-I2C" configure option;
which may be removed again.


bye, Michael

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