lcd-linux-users — Mailing list where users can post problems, suggestions ....

Re: [Lcd-linux] state of this project / effort to get into mainline linux

[Mattia Jona-L. <mat...@gm...>]

Hi,

finally the project never went into the mainline kernel and lived
parallel but outside the kernel sources.

The project is not dead and chances are that the last release of
LCD-Linux still compiles and works with a recent kernel with little or
no modification.
The project is however old and technologically outdated. Parallel
ports are no longer available on modern computers and one would have
at least to adapt the code dealing with the parallel port to the GPIO
interface, which is doable and not difficult. Also, the idea of
LCD-Linux was to write an optimized driver for alphanumeric displays
including terminal emulation. Only the HD44780 driver was written and
developed but other drivers could be developed with little effort
because basically you only need to write the elementary functions of
how to write a single character on the particular display and how to
open the communication channel between computer and display. The
problem of what to display where has already been solved once and for
all.

To my knowledge there is no modern replacement of LCD-Linux. LCDproc
is a userspace program that gathers information from the system and
displays it on an LCD. It supports lots of displays but as far as I
know there is no simple way to make it display some user generated
input. Another program is LCD4Linux, which by the way supports
LCD-Linux among the possible connection types, which features a sort
of LCD-Linux emulation since one can open a FIFO special file and
everything written on the FIFO is output on the LCD. Still no terminal
emulation though.

LCDProc should still be alive. The status of LCD4Linux is unknown to me.

Try to identify the controller of your display and find the
correspondent datasheet. Then you can decide whether lcd-linux suits
your needs.

Best,

Mattia




On Tue, Oct 7, 2014 at 4:33 PM,  <ha...@cc...> wrote:
> Hi,
>
> I see that about 4 years ago there was a effort to get lcd-linux into
> the mainline kernel. What became of this?
>
> Is this project still alive and useful or has it been obsoleted by
> something new?
>
> My reason for looking into lcd-linux is that I want to write a driver
> for a 1x9 14-segment display, but am unsure where such a driver belongs.
>
> Do you have any advice about handling alphanumeric lcd displays from
> linux?
>
> TIA,
> Harald
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Lcd-linux-users mailing list
> Lcd...@li...
> https://lists.sourceforge.net/lists/listinfo/lcd-linux-users

[Lcd-linux] state of this project / effort to get into mainline linux

[<ha...@cc...>]

Hi,

I see that about 4 years ago there was a effort to get lcd-linux into
the mainline kernel. What became of this?

Is this project still alive and useful or has it been obsoleted by
something new?

My reason for looking into lcd-linux is that I want to write a driver
for a 1x9 14-segment display, but am unsure where such a driver belongs.

Do you have any advice about handling alphanumeric lcd displays from
linux?

TIA,
Harald

Re: [Lcd-linux] Fwd: Re-vitalizing lcd-linux for Raspberry Pi?

[Sven G. <sv...@ge...>]

Mattia Jona-Lasinio schrieb am Dienstag, den 17. September um 16:49 Uhr:

> Anyway, just edit the lcd-linux Makefile and define KERNEL_VERSION to
> 3.7.9 and KERNEL_SRC_DIR to the correct kernel source path (seems to be
> /lib/modules/3.7.9-01010-gc1bd951/build). This should fix the compiler
> issue. I tried with no problems with a pristine 3.7.9 kernel.

Hm, looks like create_proc_read_entry function is not available on 3.10.x
anymore:

/home/sven/download/lcd-linux-0.13.9/lcd-linux/lcd-linux.c: In function ‘create_driver_proc_entries’:
/home/sven/download/lcd-linux-0.13.9/lcd-linux/lcd-linux.c:1926:2: error:
/implicit declaration of function ‘create_proc_read_entry’ [-Werror=implicit-function-declaration]

Sven

-- 
"The term "any key" does not refer to a particular key on the keyboard. It
simply means to strike any one of the keys on your keyboard or handheld
screen." (Compaq FAQ Entry 2859)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

Re: [Lcd-linux] Fwd: Re-vitalizing lcd-linux for Raspberry Pi?

[Mattia Jona-L. <mat...@gm...>]

Could be. It was also missing in 2.2 kernels. There is an internal version
in the file lcd-linux.c line 1800. If that doesn't work you can either
disable the /proc support or write a new create_proc_read_entry function.
Maybe taking the one from Linux 3.7.9 to start with.


On Tue, Sep 17, 2013 at 5:06 PM, Sven Geggus <sv...@ge...> wrote:

> Mattia Jona-Lasinio schrieb am Dienstag, den 17. September um 16:49 Uhr:
>
> > Anyway, just edit the lcd-linux Makefile and define KERNEL_VERSION to
> > 3.7.9 and KERNEL_SRC_DIR to the correct kernel source path (seems to be
> > /lib/modules/3.7.9-01010-gc1bd951/build). This should fix the compiler
> > issue. I tried with no problems with a pristine 3.7.9 kernel.
>
> Hm, looks like create_proc_read_entry function is not available on 3.10.x
> anymore:
>
> /home/sven/download/lcd-linux-0.13.9/lcd-linux/lcd-linux.c: In function
> ‘create_driver_proc_entries’:
> /home/sven/download/lcd-linux-0.13.9/lcd-linux/lcd-linux.c:1926:2: error:
> /implicit declaration of function ‘create_proc_read_entry’
> [-Werror=implicit-function-declaration]
>
> Sven
>
> --
> "The term "any key" does not refer to a particular key on the keyboard. It
> simply means to strike any one of the keys on your keyboard or handheld
> screen." (Compaq FAQ Entry 2859)
> /me is giggls@ircnet, http://sven.gegg.us/ on the Web
>

[Lcd-linux] Fwd: Re-vitalizing lcd-linux for Raspberry Pi?

[Mattia Jona-L. <mat...@gm...>]

Hi,

yes, LCD-Linux was written for HD44780 displays connected to a parallel
port but all the parallel port related functions are in the hd44780 driver.
Actually the driver assumes some sort of abstract input/output port that
happens to be the parallel port but can be the GPIO or the I2C port as
well. You just need to modify the two
__read_display/__write_displayfunctions in the hd44780 driver and of
course to provide appropriate
functions to open (init_port) and close (cleanup_port) the communication
port. No need to touch the lcd-linux file.

Coming to your compilation issue, the problem seems to be that the Makefile
script does not recognize your kernel sources as post-2.4 sources and
that's because you have "3.7.9-01010-gc1bd951" as string version. When I
wrote the script I assumed the string version to be the version number
only. Anyway, just edit the lcd-linux Makefile and define KERNEL_VERSION to
3.7.9 and KERNEL_SRC_DIR to the correct kernel source path (seems to be
/lib/modules/3.7.9-01010-gc1bd951/build). This should fix the compiler
issue. I tried with no problems with a pristine 3.7.9 kernel.

Regards,

Mattia




On Tue, Sep 17, 2013 at 2:12 PM, Sven Geggus <li...@fu...>wrote:

> Hello,
>
> looking for a more generic Solution than this one:
> http://learn.adafruit.com/drive-a-16x2-lcd-directly-with-a-raspberry-pi
> (lots of userland GPIO fiddling)
>
> I found http://lcd-linux.sourceforge.net/
>
> I would prefer using this because this would allow for running ncurses
> compatible applications on HD44780 compatible displays, right?
>
> Two Questions:
>
> * Is it possible to compile your code for recent Kernels? Raspberry Pi is
> currently at 3.6.x AFAIR
>
> For now I ended up with the following error:
>  lcd-linux-0.13.9/ > make
> - KERNEL_SRC_DIR: /lib/modules/3.7.9-01010-gc1bd951/build
> - DESTDIR: /lib/modules/3.7.9-01010-gc1bd951/misc
> make TOPDIR= wd -f  wd/Makefile -C lcd-linux lcd-linux.o
> make[1]: Entering directory /home/geg/download/lcd-linux-0.13.9/lcd-linux'
> touch /home/geg/download/lcd-linux-0.13.9/include/lcd-linux.ver
> gcc -D__KERNEL__ -DMODULE
> -I/lib/modules/3.7.9-01010-gc1bd951/build/include
> -I/home/geg/download/lcd-linux-0.13.9/include -Wall -Wstrict-prototypes
> -Wno-trigraphs -O2 -fno-common -fomit-frame-pointer -pipe
> -fno-strict-aliasing  -include
> "/home/geg/download/lcd-linux-0.13.9/include/lcd-linux.ver" -include
> "/home/geg/download/lcd-linux-0.13.9/include/ asename lcd-linux.o .o.ver"
> -DEXPORT_SYMTAB -c lcd-linux.c -o
> /home/geg/download/lcd-linux-0.13.9/modules/lcd-linux.o
> In file included from
> /lib/modules/3.7.9-01010-gc1bd951/build/include/linux/thread_info.h:11:0,
>                  from
> /lib/modules/3.7.9-01010-gc1bd951/build/include/linux/preempt.h:9,
>                  from
> /lib/modules/3.7.9-01010-gc1bd951/build/include/linux/spinlock.h:50,
>                  from
> /lib/modules/3.7.9-01010-gc1bd951/build/include/linux/semaphore.h:13,
>                  from lcd-linux.c:50:
> /lib/modules/3.7.9-01010-gc1bd951/build/include/linux/bug.h:4:21: fatal
> error: asm/bug.h: No such file or directory compilation terminated.
> make[1]: *** [lcd-linux.o] Error 1
> make[1]: Leaving directory /home/geg/download/lcd-linux-0.13.9/lcd-linux'
> make: *** [default] Error 2
>
> * Am I right in the assumption, that your code has been written for a
> HD44780 connected to a parallel port? If so, how much effort would it be to
> port your code to the generic Kernel GPIO or even I2C Interface?
>
> Regards
>
> Sven
>
> --
> Das allgemeine Persönlichkeitsrecht (Art. 2 Abs.1 i.V.m. Art.1 Abs. 1GG)
> umfasst das Grundrecht auf Gewährleistung der Vertraulichkeit und
> Integrität
> informationstechnischer Systeme. (BVerfG, 1BvR 370/07)
> /me is giggls@ircnet, http://sven.gegg.us/ on the Web
>
>
> ------------------------------------------------------------------------------
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
> SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack
> includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> _______________________________________________
> Lcd-linux-users mailing list
> Lcd...@li...
> https://lists.sourceforge.net/lists/listinfo/lcd-linux-users
>

[Lcd-linux] Re-vitalizing lcd-linux for Raspberry Pi?

[Sven G. <li...@fu...>]

Hello,

looking for a more generic Solution than this one:
http://learn.adafruit.com/drive-a-16x2-lcd-directly-with-a-raspberry-pi
(lots of userland GPIO fiddling)

I found http://lcd-linux.sourceforge.net/

I would prefer using this because this would allow for running ncurses
compatible applications on HD44780 compatible displays, right?

Two Questions:

* Is it possible to compile your code for recent Kernels? Raspberry Pi is
currently at 3.6.x AFAIR

For now I ended up with the following error:
 lcd-linux-0.13.9/ > make
- KERNEL_SRC_DIR: /lib/modules/3.7.9-01010-gc1bd951/build
- DESTDIR: /lib/modules/3.7.9-01010-gc1bd951/misc
make TOPDIR=wd -f wd/Makefile -C lcd-linux lcd-linux.o
make[1]: Entering directory /home/geg/download/lcd-linux-0.13.9/lcd-linux'
touch /home/geg/download/lcd-linux-0.13.9/include/lcd-linux.ver
gcc -D__KERNEL__ -DMODULE -I/lib/modules/3.7.9-01010-gc1bd951/build/include -I/home/geg/download/lcd-linux-0.13.9/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-common -fomit-frame-pointer -pipe -fno-strict-aliasing  -include "/home/geg/download/lcd-linux-0.13.9/include/lcd-linux.ver" -include "/home/geg/download/lcd-linux-0.13.9/include/asename lcd-linux.o .o.ver" -DEXPORT_SYMTAB -c lcd-linux.c -o /home/geg/download/lcd-linux-0.13.9/modules/lcd-linux.o
In file included from /lib/modules/3.7.9-01010-gc1bd951/build/include/linux/thread_info.h:11:0,
                 from /lib/modules/3.7.9-01010-gc1bd951/build/include/linux/preempt.h:9,
                 from /lib/modules/3.7.9-01010-gc1bd951/build/include/linux/spinlock.h:50,
                 from /lib/modules/3.7.9-01010-gc1bd951/build/include/linux/semaphore.h:13,
                 from lcd-linux.c:50: /lib/modules/3.7.9-01010-gc1bd951/build/include/linux/bug.h:4:21: fatal error: asm/bug.h: No such file or directory compilation terminated.
make[1]: *** [lcd-linux.o] Error 1
make[1]: Leaving directory /home/geg/download/lcd-linux-0.13.9/lcd-linux'
make: *** [default] Error 2

* Am I right in the assumption, that your code has been written for a
HD44780 connected to a parallel port? If so, how much effort would it be to
port your code to the generic Kernel GPIO or even I2C Interface?

Regards

Sven

-- 
Das allgemeine Persönlichkeitsrecht (Art. 2 Abs.1 i.V.m. Art.1 Abs. 1GG)
umfasst das Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität
informationstechnischer Systeme. (BVerfG, 1BvR 370/07)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

Re: [Lcd-linux] state kernel upstreaming efforts

[Mattia Jona-L. <mat...@gm...>]

Hi and thanks for your interest in LCD-Linux. Unfortunately the project is
not scheduled for inclusion in the Linux kernel mainstream. As you have
read there was some discussion around 2 years ago but even those ideas
about rewriting the virtual console management in the kernel, never saw the
light. There is probably not enough interest to modify the virtual terminal
subsystem, that is vital for many other things in the kernel.
The LCD-Linux project was definitely not rejected but it is unlikely that
it will be included in the kernel in the near future. The LCD-Linux
repository in now more than one year old since no bugs have emerged and all
the HD44780 features are implemented. So there is nothing more to develop,
only new ideas to implement or new drivers to write.

Regards,

Mattia Jona


On Tue, Nov 6, 2012 at 3:18 PM, Lars Poeschel <poe...@le...> wrote:

> Hello !
>
> Searching a solution for interfacing my 4x20 character display to linux I
> found your project.
> I then read the mailinglist archives and found the "Introducing the
> LCD-Linux
> project" thread very interesting, but the talk ended on 2010-08-04. There
> were some thoughts about restructuring linux console and vc handling,
> problems and possible solutions.
> Are there any efforts that have been made ? Are there patches or
> repositories
> where development happens ? What problems had been faced ? What is the
> current state ?
> I am very interested in this because it looks to me as very valuable
> solution.
>
> Thanks,
> Lars
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Lcd-linux-users mailing list
> Lcd...@li...
> https://lists.sourceforge.net/lists/listinfo/lcd-linux-users
>

[Lcd-linux] state kernel upstreaming efforts

[Lars P. <poe...@le...>]

Hello !

Searching a solution for interfacing my 4x20 character display to linux I 
found your project.
I then read the mailinglist archives and found the "Introducing the LCD-Linux 
project" thread very interesting, but the talk ended on 2010-08-04. There 
were some thoughts about restructuring linux console and vc handling, 
problems and possible solutions.
Are there any efforts that have been made ? Are there patches or repositories 
where development happens ? What problems had been faced ? What is the 
current state ?
I am very interested in this because it looks to me as very valuable 
solution.

Thanks,
Lars

Re: [Lcd-linux] lcd over gpio

[Claudio <cla...@gm...>]

Hello Mattia,
did you have some news on this topic?
I took a couple of hitachi compatible LCD and a linux gpio enabled board.

2011/1/18 Mattia Jona-Lasinio <mat...@gm...>:
> On Tue, Jan 18, 2011 at 1:12 PM, Claudio <cla...@gm...> wrote:
>> Dear mattia,
>> let me introduce a different scenario.
>>
>> The USB device are really different each other and support for its
>> could be difficult and inefficient, beside on embedded devices
>> generally you want to use the USB port for something more useful.
>
> Hmmmm, quite a lot of people might disagree with you as USB is now
> considered THE universal and preferred way to connect external devices
> to computers. Anyway, I see your point.
>
>> The gpio implementaion instread allow you to support a huge range of
>> embedded devices like router, develop board as well some routerboard
>> or industial board; moreover you can use a USB to GPIO adapter (like
>> ftdi) and then connect any kind of lcd also on you modern laptop/pc
>> (that typically don't have parport or gpio).
>
> I agree and this should in principle be very easy. If the GPIO
> implementation in the kernel is at a usable level then I'm more than
> happy to try to use it. In any case it will provide a sort of standard
> way to access the display. If this is the case then it is very easy as
> the only two functions in the HD44780 driver that need a rewrite are
> the two lowlevel read and write functions. If I write a patch, will
> you be able to test it and report on it?
>
>> The parport implementation is hacky and should be mainained just for
>> history but it is de facto obsolete(how many device you can found with
>> parport today in your home?).
>
> I agree and that's why I wanted to move to something newer. LCD-Linux
> was intended at the beginning to provide a cheap display output to old
> and obsolete hardware. These days this goal does not make any sense as
> an embedded device can run as a router much more efficiently than an
> old computer.
>
>> In this scenario the GPIO support is priority and such version of
>> lcd-linux is, in imho, also more acceptable by mainline kernel.
>
> LCD-Linux was already proposed for inclusion in the kernel mainline
> but some issues prevented this. The main reason being that LCD-Linux
> duplicates in some sense the console emulation and kernel developers
> don't like duplicate code (why reinventing the wheel?). To make a long
> story short LCD-Linux wasn't rejected but it was asked to merge some
> parts of it with the existing kernel code, which is not always easy.
> There was some traffic about this on the main linux kernel maling list
> in july 2010.
>
> Best
>
> Mattia
>
>
>>
>>

Re: [Lcd-linux] lcd over gpio

[Claudio <cla...@gm...>]

2011/1/18 Mattia Jona-Lasinio <mat...@gm...>:
> On Tue, Jan 18, 2011 at 1:12 PM, Claudio <cla...@gm...> wrote:
>> Dear mattia,
>> let me introduce a different scenario.
>>
>> The USB device are really different each other and support for its
>> could be difficult and inefficient, beside on embedded devices
>> generally you want to use the USB port for something more useful.
>
> Hmmmm, quite a lot of people might disagree with you as USB is now
> considered THE universal and preferred way to connect external devices
> to computers. Anyway, I see your point.
>
>> The gpio implementaion instread allow you to support a huge range of
>> embedded devices like router, develop board as well some routerboard
>> or industial board; moreover you can use a USB to GPIO adapter (like
>> ftdi) and then connect any kind of lcd also on you modern laptop/pc
>> (that typically don't have parport or gpio).
>
> I agree and this should in principle be very easy. If the GPIO
> implementation in the kernel is at a usable level then I'm more than
> happy to try to use it. In any case it will provide a sort of standard

I can tell you that a lot of interface are yet build on top of gpio
layer for example i2c or spi bus, as well as led, buttons (for input)

i2c http://lxr.linux.no/#linux+v2.6.37/drivers/i2c/busses/i2c-gpio.c
spi http://lxr.linux.no/#linux+v2.6.37/drivers/spi/spi_gpio.c
buttons http://lxr.linux.no/#linux+v2.6.37/include/linux/gpio_keys.h#L17

> way to access the display. If this is the case then it is very easy as
> the only two functions in the HD44780 driver that need a rewrite are
> the two lowlevel read and write functions. If I write a patch, will
> you be able to test it and report on it?
>

Yes of course!

Re: [Lcd-linux] lcd over gpio

[Mattia Jona-L. <mat...@gm...>]

On Tue, Jan 18, 2011 at 1:12 PM, Claudio <cla...@gm...> wrote:
> Dear mattia,
> let me introduce a different scenario.
>
> The USB device are really different each other and support for its
> could be difficult and inefficient, beside on embedded devices
> generally you want to use the USB port for something more useful.

Hmmmm, quite a lot of people might disagree with you as USB is now
considered THE universal and preferred way to connect external devices
to computers. Anyway, I see your point.

> The gpio implementaion instread allow you to support a huge range of
> embedded devices like router, develop board as well some routerboard
> or industial board; moreover you can use a USB to GPIO adapter (like
> ftdi) and then connect any kind of lcd also on you modern laptop/pc
> (that typically don't have parport or gpio).

I agree and this should in principle be very easy. If the GPIO
implementation in the kernel is at a usable level then I'm more than
happy to try to use it. In any case it will provide a sort of standard
way to access the display. If this is the case then it is very easy as
the only two functions in the HD44780 driver that need a rewrite are
the two lowlevel read and write functions. If I write a patch, will
you be able to test it and report on it?

> The parport implementation is hacky and should be mainained just for
> history but it is de facto obsolete(how many device you can found with
> parport today in your home?).

I agree and that's why I wanted to move to something newer. LCD-Linux
was intended at the beginning to provide a cheap display output to old
and obsolete hardware. These days this goal does not make any sense as
an embedded device can run as a router much more efficiently than an
old computer.

> In this scenario the GPIO support is priority and such version of
> lcd-linux is, in imho, also more acceptable by mainline kernel.

LCD-Linux was already proposed for inclusion in the kernel mainline
but some issues prevented this. The main reason being that LCD-Linux
duplicates in some sense the console emulation and kernel developers
don't like duplicate code (why reinventing the wheel?). To make a long
story short LCD-Linux wasn't rejected but it was asked to merge some
parts of it with the existing kernel code, which is not always easy.
There was some traffic about this on the main linux kernel maling list
in july 2010.

Best

Mattia


>
> Best regards
>

Re: [Lcd-linux] lcd over gpio

[Claudio <cla...@gm...>]

Dear mattia,
let me introduce a different scenario.

2011/1/18 Mattia Jona-Lasinio <mat...@gm...>:
> Hi,
>
> the implementation of GPIO lines would certainly be a valuable feature
> to add to lcd-linux. Presently there is no plan to go in that
> direction but it can be put in the TODO list. Another feature would be
> to add an input line by using the input pins of the parallel port but
> in my opinion the most urgent feature is to move from a parallel port
> connection to something more modern and universal like USB.

The USB device are really different each other and support for its
could be difficult and inefficient, beside on embedded devices
generally you want to use the USB port for something more useful.

The gpio implementaion instread allow you to support a huge range of
embedded devices like router, develop board as well some routerboard
or industial board; moreover you can use a USB to GPIO adapter (like
ftdi) and then connect any kind of lcd also on you modern laptop/pc
(that typically don't have parport or gpio).
The parport implementation is hacky and should be mainained just for
history but it is de facto obsolete(how many device you can found with
parport today in your home?).

In this scenario the GPIO support is priority and such version of
lcd-linux is, in imho, also more acceptable by mainline kernel.

Best regards

Re: [Lcd-linux] lcd over gpio

[Mattia Jona-L. <mat...@gm...>]

Hi,

the implementation of GPIO lines would certainly be a valuable feature
to add to lcd-linux. Presently there is no plan to go in that
direction but it can be put in the TODO list. Another feature would be
to add an input line by using the input pins of the parallel port but
in my opinion the most urgent feature is to move from a parallel port
connection to something more modern and universal like USB.
Unfortunately for this you need to connect the display to a
controlling board. There is a wide choice of these boards but there is
no standard on their implementation so it is hard to tell what can be
supported or implemented.

Best

Mattia


On Fri, Jan 14, 2011 at 1:57 PM, Claudio <cla...@gm...> wrote:
> Hi all,
> I find this pretty good driver and I believe that a valuable feature
> that should be added is a gpio extension.
>
> On threat
> http://sourceforge.net/mailarchive/forum.php?thread_name=729F0B8B-978C-478B-A85F-B6AFE1F5208A%40cs.tu-berlin.de&forum_name=lcd-linux-users
>
> a arch specific improvement is proposed but using a gpio [1]
> implementation can be portable between different system.
>
> There is some intention to add it?
>
>
> 1. http://lxr.linux.no/#linux+v2.6.37/Documentation/gpio.txt
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Lcd-linux-users mailing list
> Lcd...@li...
> https://lists.sourceforge.net/lists/listinfo/lcd-linux-users
>

[Lcd-linux] lcd over gpio

[Claudio <cla...@gm...>]

Hi all,
I find this pretty good driver and I believe that a valuable feature
that should be added is a gpio extension.

On threat
http://sourceforge.net/mailarchive/forum.php?thread_name=729F0B8B-978C-478B-A85F-B6AFE1F5208A%40cs.tu-berlin.de&forum_name=lcd-linux-users

a arch specific improvement is proposed but using a gpio [1]
implementation can be portable between different system.

There is some intention to add it?


1. http://lxr.linux.no/#linux+v2.6.37/Documentation/gpio.txt

Re: [Lcd-linux] [PATCH] Kernel fbcon UNICODE font support

[James S. <jsi...@in...>]

On Thu, 2 Dec 2010, Samuel Thibault wrote:

> James Simmons, le Thu 02 Dec 2010 13:50:28 +0000, a écrit :
> > 	This is nice and neat for vgacon but it doesn't flow so nicely with 
> > graphical consoles or text LCDs. What I like to see is the attribute 
> > buffer be split from the vc_screenbuf. The bonus is in embbeded systems we 
> > could arrange the code so we could have a light weight printk VT without 
> > the extra junk of the VC. Do we really need a attribute buffer for printk?  
> > I believe that would be the first step in the right direction.
> 
> That's exactly what I suggested privately to Microcai. Increasing the
> number of supported glyphs should then becomes way simpler, and
> double-width not so far.

The challenge would be the scrolling code. I cc'ed the LCD group to voice 
there needs as well.

Re: [Lcd-linux] Introducing the LCD-Linux project

[James S. <jsi...@in...>]

> I explored the kernel sources dealing with the console emulation,
> framebuffer support and console drivers. I do realize that if we want to fix
> all layers in a clean way there is a lot of work to do.

Yes, but the good news is I have been here before. The good news is that 
the console code has been abstracted out of most low level drivers so it 
makes life much easier this time around. Also today we are starting to 
have a greater amount of hardware that can do multi-seat. Another project 
dealing with these same issues is

http://plugable.com/2009/11/16/setting-up-usb-multiseat-with-displaylink-on-linux-gdm-up-to-2-20/
  
> But before going any further I'd like to know some preliminary things.
> We are talking about a massive rewrite of code, also including a redesign
> of the console layer and (at least) the VGA driver (vgacon) and framebuffer
> driver (fbcon), not just a couple of patches to throw in. Do we have the will
> to do this job? I mean, I personally do but I don't want to spend time and
> effort in something that will be eventually rejected.
> Linux has a console system, so we are not in a hurry and we can
> think about it. So the main question: how do we proceed?

Like before. Bit by bit to avoid massive code drops that could break lots 
of things. Do certain select changes and push them to Andrew Mortons -mm 
tree for wide testing. If we have a successful run then push it main stream.
While in the -mm tree we start the next round of changes. Once the 
previous batch from the -mm tree is pushed main stream then push the next 
batch of changes.

> In case we want to fix this, we should discuss about the design and
> implementation
> to follow. Presently the struct vc_data contains a lot of information
> common to the driver and the
> console layers. We should split this struct in order to have a more
> transparent interface
> between the two parts. Ideally the driver should not know anything
> about the console
> implementation and the members of the vc_data and it should only take care about
> displaying the right thing at the right place.
> The vt_struct should represent a physical device, like a monitor or a
> LCD display.
> Every vt_struct can have one or more vc_data associated to it. All
> available vt_struct
> are physically refreshed but for every vt_struct, only the currently
> visible vc_data on that struct is
> actually updated. The others are just "software updated". I don't know
> if all this is
> the same idea that James was suggesting.

Yes. That is exactly what I had before.

> We should avoid fixed size vectors of pointers to these structs by
> making them elements
> of linked lists.

I think for our case idrs whould be better.

> I agree on the mapping between vc and vt but I'd like to make the
> number of vc per vt
> an option to be passed at boot time or when init is launched (for
> instance), not a
> compile time option.

I had it as a module option. Now ioctl VT_GETSTATE has a problem with more 
tha 16 VCs. So original I made 16 the limitation of VCs per VT.

> I totally agree that all this must be somewhat separated from the tty
> layer, to have
> a console without a tty driver, or at least a very light one.
> 
> What do you think?

We pretty much have the same goals.

> Coming back to LCD-Linux, I will write a module to make it use the
> present framework,
> basically deactivating the terminal emulation and a bunch of other things, but
> keeping the virtual display. Let's see the result ;)

Excellent. Let me see the work once your done.

> BTW, I currently use lcd-linux with a 4x40 LCD display
> which has two controllers onboard. The possibility to drive displays
> with more than one
> (up to 7) controller onboard is a feature of the present hd44780 driver.

I can discuss with you off line about getting a hold of one of these 
boards.

Okay. I have sync my console git tree up to linus latest tree. I started 
last night on the first pass of the console changes. Mostly code cleanup 
to make the second round of changes easier to deal with. I will commit 
them in the next few days after some testing of course.  I will send out a 
email once I haev done the commit.

http://git.infradead.org/users/jsimmons/linuxconsole-2.6.git

Re: [Lcd-linux] Introducing the LCD-Linux project

[Mattia Jona-L. <mat...@gm...>]

I explored the kernel sources dealing with the console emulation,
framebuffer support and console drivers. I do realize that if we want to fix
all layers in a clean way there is a lot of work to do.

But before going any further I'd like to know some preliminary things.
We are talking about a massive rewrite of code, also including a redesign
of the console layer and (at least) the VGA driver (vgacon) and framebuffer
driver (fbcon), not just a couple of patches to throw in. Do we have the will
to do this job? I mean, I personally do but I don't want to spend time and
effort in something that will be eventually rejected.
Linux has a console system, so we are not in a hurry and we can
think about it. So the main question: how do we proceed?

In case we want to fix this, we should discuss about the design and
implementation
to follow. Presently the struct vc_data contains a lot of information
common to the driver and the
console layers. We should split this struct in order to have a more
transparent interface
between the two parts. Ideally the driver should not know anything
about the console
implementation and the members of the vc_data and it should only take care about
displaying the right thing at the right place.
The vt_struct should represent a physical device, like a monitor or a
LCD display.
Every vt_struct can have one or more vc_data associated to it. All
available vt_struct
are physically refreshed but for every vt_struct, only the currently
visible vc_data on that struct is
actually updated. The others are just "software updated". I don't know
if all this is
the same idea that James was suggesting.

We should avoid fixed size vectors of pointers to these structs by
making them elements
of linked lists.

I agree on the mapping between vc and vt but I'd like to make the
number of vc per vt
an option to be passed at boot time or when init is launched (for
instance), not a
compile time option.

I totally agree that all this must be somewhat separated from the tty
layer, to have
a console without a tty driver, or at least a very light one.

What do you think?

Coming back to LCD-Linux, I will write a module to make it use the
present framework,
basically deactivating the terminal emulation and a bunch of other things, but
keeping the virtual display. Let's see the result ;)

BTW, I currently use lcd-linux with a 4x40 LCD display
which has two controllers onboard. The possibility to drive displays
with more than one
(up to 7) controller onboard is a feature of the present hd44780 driver.

Greetings

Mattia


On Thu, Jul 29, 2010 at 8:39 PM, James Simmons <jsi...@in...> wrote:
>
>> > 3) Invert the VT layer. Currently the console/printk driver is on top of
>> >    the tty layer. It would be nice to be able to only use a very light
>> >    weight vt printk without the VT tty on top for embedded platforms.
>>
>> No. printk hits console drivers why may or may not be frame buffer
>> interfaces. Has done for a very long time. Keith Packard has also been
>> doing stuff with crash time oops displays etc over an X display.
>
> Correct. What I mean is have the ability to just register the console
> driver but not the tty driver.
>
>> > 4) Seperate out the VT emulation layer. Related to 3.
>>
>> Separate from what ?
>
> We can still have a basic tty layer without the control characters, think
> do_con_trol in vt.c, junk compiled into the kernel. Make it a options for
> userland to do the vt100 emulation.
>
>> > 5) Multiple independent VT support. Which brings up the question what
>> >    should the mapping of VCs to a VT look like.

Re: [Lcd-linux] Introducing the LCD-Linux project

[Alan C. <al...@lx...>]

> 3) Invert the VT layer. Currently the console/printk driver is on top of
>    the tty layer. It would be nice to be able to only use a very light 
>    weight vt printk without the VT tty on top for embedded platforms.

No. printk hits console drivers why may or may not be frame buffer
interfaces. Has done for a very long time. Keith Packard has also been
doing stuff with crash time oops displays etc over an X display.
 
> 4) Seperate out the VT emulation layer. Related to 3.

Separate from what ?

> 5) Multiple independent VT support. Which brings up the question what 
>    should the mapping of VCs to a VT look like. 

I would suggest we borrow the X idea and each VC is

	int display;	/* Display it is on (for console flipping) */
	struct something *vt;	/* VT which it is displaying */
	int x,y,w,h;	/* Window onto vt */

Re: [Lcd-linux] Introducing the LCD-Linux project

[James S. <jsi...@in...>]

> > 3) Invert the VT layer. Currently the console/printk driver is on top of
> >    the tty layer. It would be nice to be able to only use a very light 
> >    weight vt printk without the VT tty on top for embedded platforms.
> 
> No. printk hits console drivers why may or may not be frame buffer
> interfaces. Has done for a very long time. Keith Packard has also been
> doing stuff with crash time oops displays etc over an X display.

Correct. What I mean is have the ability to just register the console 
driver but not the tty driver.
  
> > 4) Seperate out the VT emulation layer. Related to 3.
> 
> Separate from what ?

We can still have a basic tty layer without the control characters, think 
do_con_trol in vt.c, junk compiled into the kernel. Make it a options for 
userland to do the vt100 emulation.

> > 5) Multiple independent VT support. Which brings up the question what 
> >    should the mapping of VCs to a VT look like. 
> 
> I would suggest we borrow the X idea and each VC is
> 
> 	int display;	/* Display it is on (for console flipping) */
> 	struct something *vt;	/* VT which it is displaying */
> 	int x,y,w,h;	/* Window onto vt */

/dev/tty[0-16]  -> VT display 0
/dev/tty[17-31] -> VT display 1

etc.

At least that is how I handled it  several years ago.

Re: [Lcd-linux] Introducing the LCD-Linux project

[James S. <jsi...@in...>]

> <ge...@li...> wrote:
> > On Sat, Jul 24, 2010 at 16:43, Florian Tobias Schandinat
> > <Flo...@gm...> wrote:
> >> Mattia Jona-Lasinio <mattia.jona <at> gmail.com> writes:
> >>> Moreover I wanted something that COULD be used as a console but not
> >>> necessarily, that is
> >>> something that could run happily in the presence of a normal monitor
> >>> as well. It seems to me, but I may be
> >>> wrong, that through the standard console system only the current
> >>> visible console is actually updated
> >>> while other consoles are just "software" updated. An external LCD
> >>> would therefore be updated
> >>> only when you "switch" to it, so it would not be possible to use it to
> >>> display diagnostics.
> >>
> >> True, that's a general problem one has when multiple framebuffers exist.
> >> Therefore I'd be very happy if someone could come up with a general solution.
> >
> > Fixing that was (one of the) goal of the linux-console project. James?
> 
> Hmmm, the linux-console project seems to be dead. There are no file
> releases after nearly ten
> years and the CVS is three years old.

	We never did file releases. Mostly people just checked out cvs 
and then built and tested out the kernel. At first it was a massive
project which covered several areas. That tree was used as a staging 
ground for the input api and the new fbdev api. We even for a time had had 
the serial api that you find drivers/serial. All of that has been made 
main stream :-) Then we saw graphics cards all becoming agp and mother 
boards with multiple apg slots where extremely rare. So interest in the 
project died off. Now with usb and pcie plus graphics cards with multiple 
crtcs its is becoming possible again. 
	Recently I have been looking at and working on the DRI mode setting api
since it covers the bulk of the graphics cards out there for the PC market which
are pcie which means the possiblity of multiple graphics cards in 
parrallel. You are not the only one looking at this solution.  

> Implementing this  in the standard Linux terminal emulation
> would require
> a rewrite of most of the code, which I personally would do only if
> there is some interest from
> the community in improving the standard Linux console, and I don't
> think it is the case
> looking at the age of the Linux console project. So I decided to keep
> it separate.
> But never say never! In the future the two consoles could merge in a
> single one. ;)

Hum. Only in the last year have I started to see a interest in this area 
again. A few months ago someone else was discussing with me the 
limitations of the linux console system. I have a few drm changes I like 
to push first for the next merge widow. Perhaps if Andrew Morton is 
willing to merge the my linuxconsole git tree into his -mm branch for wide 
area testing then I can start the linux console stuff up again. Currently 
my console git tree has no commits. Its just a raw tree. BTW yes it is 
alot of work to cleanup the console system.

Re: [Lcd-linux] Introducing the LCD-Linux project

[James S. <jsi...@in...>]

> > was born. Implementing this  in the standard Linux terminal emulation
> > would require
> > a rewrite of most of the code, which I personally would do only if
> > there is some interest from
> > the community in improving the standard Linux console
> 
> There is a great deal of interest. Most of the console (as in
> framebuffer) activity moved to the 3D direct rendering world some time
> ago.

Really. I didn't expect the console to be of much interest.
 
> Let's start at the beginning. What console layer things need fixing to
> make the LCD Linux project able to use them ?
> 
> Multiple displays live at once is an obvious one - the 3D graphics folks
> also want some of that too.

Okay you asked for it. 

1) To do multiple displays will require the console tool updates.

2) Kill the big ugly console lock. One lock for not only multiple 
   VTs but even multiple types of consoles is horrible. I seen on 
   embedded board using the framebuffer device take the console
   lock thus block the serial port.

3) Invert the VT layer. Currently the console/printk driver is on top of
   the tty layer. It would be nice to be able to only use a very light 
   weight vt printk without the VT tty on top for embedded platforms.

4) Seperate out the VT emulation layer. Related to 3.

5) Multiple independent VT support. Which brings up the question what 
   should the mapping of VCs to a VT look like. 

6) A nice scrollback buffer on the VT layer level instead of the hacks we 
   have in fbcon and vgacon.

Re: [Lcd-linux] lcd-linux

[Belisko M. <mar...@gm...>]

Hi,

On Thu, Jul 29, 2010 at 11:06 AM, Mattia Jona-Lasinio
<mat...@gm...> wrote:
> On Thu, Jul 29, 2010 at 9:24 AM, Belisko Marek <mar...@gm...> wrote:
>
>> I can imagine some collaboration on coding level.
>
> Hi,
>
> what kind of platform are you interested in and want to support?
I would like to separate bus platform from driver code and then anybody
could use hd44780 connected to USB, parport, gpio ....
Similar like is done for other drivers. I'll try to think about and propose some
way how to do this. Similar thing is done for soc-alsa you have separate machine
code, driver code and codec code. And the reuse is a point ;)
> Separating the parport part from the hd44780 part is indeed
> an interesting point but it depends on a great deal on the
> hardware you want to connect the display.
>
> Regards,
>
> Mattia
>

Marek

-- 
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
icq: 290551086
web: http://open-nandra.com

Re: [Lcd-linux] Introducing the LCD-Linux project

[Mattia Jona-L. <mat...@gm...>]

On Wed, Jul 28, 2010 at 9:39 PM, Alan Cox <al...@lx...> wrote:
> Let's start at the beginning. What console layer things need fixing to
> make the LCD Linux project able to use them ?

Good to hear that! :) Just give me a few days to write a detailed todo list.

Re: [Lcd-linux] lcd-linux

[Mattia Jona-L. <mat...@gm...>]

On Thu, Jul 29, 2010 at 9:24 AM, Belisko Marek <mar...@gm...> wrote:

> I can imagine some collaboration on coding level.

Hi,

what kind of platform are you interested in and want to support?
Separating the parport part from the hd44780 part is indeed
an interesting point but it depends on a great deal on the
hardware you want to connect the display.

Regards,

Mattia

[Lcd-linux] lcd-linux

[Belisko M. <mar...@gm...>]

Hi,

first thanks for nice effort and driver. I have also done some work
for LCD but mostly connected to gpio lines not for par port, usb ....

I take a look to drivers and for me it would be nice to separate a bus
where LCD is connected from display code. e.g. for hd44780
driver you have some parport dependencies and I also see some patch to
add this controller working with gpio.

I can imagine some collaboration on coding level.

Good luck,

Marek



-- 
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
icq: 290551086
web: http://open-nandra.com