lcd-linux-users Mailing List for LCD-Linux (Page 2)
Brought to you by:
mjona
You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(28) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2011 |
Jan
(5) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
From: Alan C. <al...@lx...> - 2010-07-28 19:27:42
|
> 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. 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. Alan |
From: Mattia Jona-L. <mat...@gm...> - 2010-07-28 19:24:39
|
On Mon, Jul 26, 2010 at 10:11 PM, Geert Uytterhoeven <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. I downloaded your driver and explored the code a bit. Indeed there are many similarities with the very early stages of LCD-Linux. At the beginning I also wrote something very close to what you did. But then I realized that the display management part was very much intertwined with the low level details of the display (parallel port, 8 bit and 4 bit and so on....), and this made the module not so obvious to be ported to different displays. If you abstract the display management, add a framebuffer, you realize that basically you get a terminal emulator (nearly) for free, with the possibility to add custom features typical of small displays (like custom character generation). And once a framebuffer is added, you can play a bit by adding a virtual display larger than the physical one, also adding the code to keep the cursor visible in a smart way. Basically this is the way LCD-Linux 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, 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. ;) Greetings, Mattia |
From: Geert U. <ge...@li...> - 2010-07-26 20:08:50
|
On Thu, Jul 22, 2010 at 13:38, Geert Uytterhoeven <ge...@li...> wrote: > On Thu, Jul 22, 2010 at 13:21, Alan Cox <al...@lx...> wrote: >> On Wed, 21 Jul 2010 14:57:54 +0200 >> Mattia Jona-Lasinio <mat...@gm...> wrote: >>> this is to introduce the LCD-Linux project (http://lcd-linux.sourceforge.net/), >>> a kernel level implementation of a VT102 terminal emulator, optimized for small >>> alphanumeric and graphic displays. >> >> The kernel already has a console and that provides an abstract >> implementation that is used for everything from text mode displays to vga >> to assorted accelerated hardware platforms. >> >> Why do we need a VT102 as well ? >> >>> functions. A solution is therefore to provide a sort of minimal terminal >>> emulation in kernel space, that can be accessed through the standard character >>> device interface. In this way the problem of the display management is reduced >> >> If you use the existing kernel console interfaces then you don't need to >> worry about vt102 v console or having two terminal emulations running. > > Indeed, the kernel already has the console abstraction. > > I wrote a LCD console driver (for a HD44780 connected to the parallel > port) using > the standard console abstraction several years ago. As it used the standard > console abstraction, it supported multiple virtual consoles and co-operated with > the VGA text console out-of-the-box. Just use ALT-Fx to switch between different > VCs on the LCD or on VGA. > > I never published the code, though. Will do so tonight when I get back > to the machine that holds the code ;-) And so I did, to prevent it from being lost for mankind: http://users.telenet.be/geertu/Download/hd44780.tar.gz This is a Linux console driver for a HD44780 LCD connected to a PC-style parallel port. It supports both 4-bit and 8-bit interface mode. The code was developed and used with a 20x4 LCD connected to the parallel port of a standard PC and a CHRP LongTrail PowerPC box, with Linux kernel 2.2 (early development) and 2.4, from 2000 until 2004. There's no guarantee it will work with more recent kernels. The console driver has a comment suggesting to use a 20x4 window on an 80x25 virtual screen, but this has never been implemented. It consists of 4 modules: - hd44780: Mid-level HD44780 LCD driver, handling the HD44780 commands [kernel, user] - parlcd: Low-level HD44780 driver, defining how to talk to a HD44780 LCD connected to a PC-style parallel port [kernel, user] - lcdcon: Standard Linux console driver for a HD44780 LCD [kernel] - play: Interactive test program to talk to the HD44780 or to the raw parallel port [user] Modules marked [kernel] are used inside the Linux kernel only. Modules marked [user] are used with the userspace test program. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Mattia Jona-L. <mat...@gm...> - 2010-07-24 10:32:02
|
On Thu, Jul 22, 2010 at 1:38 PM, Geert Uytterhoeven <ge...@li...> wrote: > On Thu, Jul 22, 2010 at 13:21, Alan Cox <al...@lx...> wrote: >> Why do we need a VT102 as well ? >> >> If you use the existing kernel console interfaces then you don't need to >> worry about vt102 v console or having two terminal emulations running. > > Indeed, the kernel already has the console abstraction. I agree on that and at the beginning I was thinking about writing a framebuffer driver as well. But on the way I realized that the standard Linux console was not exactly what I needed. I wanted to implement some escape sequences typical of the world of small displays, like the generation of custom characters, backward writing or backlighting. This would have required a change in the standard console, and I personally wouldn't dare to do it. I thought it would have been better to have a separate console emulation dedicated to these small devices. 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. > I wrote a LCD console driver (for a HD44780 connected to the parallel > port) using > the standard console abstraction several years ago. As it used the standard > console abstraction, it supported multiple virtual consoles and co-operated with > the VGA text console out-of-the-box. Just use ALT-Fx to switch between different > VCs on the LCD or on VGA. I also wrote a very simple (and experimental) LCD console driver using the standard Linux console and LCD-Linux. More or less it works, though the "update" problem that I mentioned is still an issue. > Having a bigger virtual console where the LCD follows the region > surrounding the cursor > is indeed a nice extension to have. That's another point which would have required a modification at the console level and, as I said, I didn't want to touch at the standard console. But we can think about it! ;) Regards, Mattia |
From: Mattia Jona-L. <mat...@gm...> - 2010-07-24 09:52:55
|
On Thu, Jul 22, 2010 at 9:19 PM, Miguel Ojeda <mig...@gm...> wrote: > Someone told me once ago, when I submitted the cfag12864b/ks0108 > drivers, to make them use a framebuffer, so we could get a console on > it using a program like con2fb program in an independent manner. It > worked flawlessly and the console was quite usable! > > I see that you want to implement something more complex, but maybe > someone/you can make a use of that idea. Check it out : ) Hi, thanks for pointing this out. I'll certainly check it! :) Regards, Mattia |
From: Mattia Jona-L. <mat...@gm...> - 2010-07-24 09:44:12
|
Hi, Great! Thanks writing the patch and testing! Did you also try the "virtual screen feature", that is the possibility to have a virtual display larger than the physical one? Regards, Mattia On Fri, Jul 23, 2010 at 1:34 PM, Anselm Busse <ab...@cs...> wrote: > Hi, > > I have attached a patch for the hd44780 so that it works with the AT91RM9200. It was tested with a 2.6.34 Kernel and works perfect. The LCD is connected to the memory port and is mapped to address 0x40000000. The control lines are connected to the I/O lines. I think the code is self explaining and should be a good starting point for people who want to connect a LCD either to the memory port or the I/O ports of an ARM processor. > > Regards, Anselm > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Lcd-linux-users mailing list > Lcd...@li... > https://lists.sourceforge.net/lists/listinfo/lcd-linux-users > > |
From: Anselm B. <ab...@cs...> - 2010-07-23 11:34:29
|
Hi, I have attached a patch for the hd44780 so that it works with the AT91RM9200. It was tested with a 2.6.34 Kernel and works perfect. The LCD is connected to the memory port and is mapped to address 0x40000000. The control lines are connected to the I/O lines. I think the code is self explaining and should be a good starting point for people who want to connect a LCD either to the memory port or the I/O ports of an ARM processor. Regards, Anselm |
From: Miguel O. <mig...@gm...> - 2010-07-22 19:19:35
|
On Wed, Jul 21, 2010 at 2:57 PM, Mattia Jona-Lasinio <mat...@gm...> wrote: > Hi, > > this is to introduce the LCD-Linux project (http://lcd-linux.sourceforge.net/), > a kernel level implementation of a VT102 terminal emulator, optimized for small > alphanumeric and graphic displays. > > The possibility to connect to the computer small alphanumeric as well as graphic > displays, has always attracted some interest. These small devices are connected > to the computer and can be used to display system diagnostics like network > usage, RAM or disk usage or even to replace the usual monitor. Possible > applications can be found in embedded systems or clusters. These displays are > connected to the computer through serial lines, parallel ports and more recently > through USB connections. Appropriate programs in userspace gather the desired > information and output it on the display. However for this to work, the > userspace program has to implement some sort of display management, to determine > what must be displayed where. This has two major disadvantages. First. Every > userspace program willing to drive a display must solve the very same problems > (display scroll and refresh, for instance), resulting in an overall duplication > of code. Second. Display controllers usually require quite strict timings for > proper operation and it is not trivial neither efficient to obtain this in > userspace, whereas it is straightforward in kernel space through the usual delay > functions. A solution is therefore to provide a sort of minimal terminal > emulation in kernel space, that can be accessed through the standard character > device interface. In this way the problem of the display management is reduced > to some calls to the usual read/write/seek/ioctl routines. At the same time one > has the possibility to implement handling of escape sequences, thus opening the > way to standard applications based on the ncurses library. Someone told me once ago, when I submitted the cfag12864b/ks0108 drivers, to make them use a framebuffer, so we could get a console on it using a program like con2fb program in an independent manner. It worked flawlessly and the console was quite usable! I see that you want to implement something more complex, but maybe someone/you can make a use of that idea. Check it out : ) > > LCD-Linux aims to be a complete VT102 terminal emulation in kernel space, > optimized for small alphanumeric and graphic displays. It consists of two > distinct pieces of software. > > The first piece is the lcd-linux module in itself, implementing a (hopefully) > complete VT102 terminal with the addition of some custom escape sequences > specific to the world of small LCD displays. Care has been taken to avoid any > conflict between standard and custom escape sequences. A major feature of > lcd-linux is the possibility to define a virtual display geometry larger than > the physical one, so that one can use a small display as a normal 80x25 monitor > in an effective way. The layer takes care about display refresh and keeps the > cursor visible in a smart way. A second feature is the possibility to connect > more than one display (up to 256 different displays). Each display is assigned a > different minor number and is addressed individually. The lcd-linux module also > registers the appropriate major number character device and implements all the > relevant read/write/seek/ioctl functions allowed on the character device. > Finally it creates some /proc files for internal inspection, information and > diagnostics. > > The second piece of software is the display driver, implementing all functions > that are controller specific. Each driver registers itself with the lcd-linux > layer and behaves like a 'slave' with respect to it. The interface between > lcd-linux and the display driver is kept as simple as possible and no assumption > is made by any of the two parts on the implementation of the other part. Ideally > there will be one module for each controller. At the current stage, the driver > for the Hitachi HD44780 (and compatibles) controller is fully implemented and > optimized. Drivers for other controllers can be written in an easy way thanks to > the standard interface provided by the lcd-linux layer. > > The LCD-Linux project has been under development for several years and has now > reached a stable state. It has been succesfully compiled, tested and used on > different machines running Linux version 2.2, 2.4 and 2.6. The software can be > compiled as a module or compiled statically into the kernel. In the latter case, > the user can pass some parameters at boot time, to configure the display as soon > as possible during the boot sequence. The project comes with Documentation and > examples about how to use it. > > LCD-Linux is released under the GNU General Public License version 2. The latest > release is available at the Sourceforge website: > > http://lcd-linux.sourceforge.net/ > http://prdownloads.sourceforge.net/lcd-linux/lcd-linux-0.13.9.tar.gz?download > > The CVS version still includes some partial support for Linux 2.0 but this > support is considered obsolete and now abandoned in the official release. > > The LCD4Linux (http://ssl.bulix.org/projects/lcd4linux/) project is known to > support LCD-Linux among the possible connection types. > > I would appreciate some comments and feedback on the project. In view of the > potential applications, future developments and improvements of LCD-Linux, I > would also like to propose LCD-Linux for inclusion in the Linux kernel mainline. > > Thank you for your attention. > > With best regards, > > Mattia Jona-Lasinio > > (LCD-Linux project developer and maintainer) > |
From: Alan C. <al...@lx...> - 2010-07-22 12:05:53
|
On Wed, 21 Jul 2010 14:57:54 +0200 Mattia Jona-Lasinio <mat...@gm...> wrote: > Hi, > > this is to introduce the LCD-Linux project (http://lcd-linux.sourceforge.net/), > a kernel level implementation of a VT102 terminal emulator, optimized for small > alphanumeric and graphic displays. The kernel already has a console and that provides an abstract implementation that is used for everything from text mode displays to vga to assorted accelerated hardware platforms. Why do we need a VT102 as well ? > functions. A solution is therefore to provide a sort of minimal terminal > emulation in kernel space, that can be accessed through the standard character > device interface. In this way the problem of the display management is reduced If you use the existing kernel console interfaces then you don't need to worry about vt102 v console or having two terminal emulations running. The basic idea seems sound enough other than that. Another reason for using the kernel console/vt driver is that you can then also support mini bitmap displays because a frame buffer driver backed by a driver for a suitable LCD panel can work nicely because the vt driver can sit on the fb layer quite happily and fb then implements low level handling for the pixels. Alan |
From: Geert U. <ge...@li...> - 2010-07-22 11:38:41
|
On Thu, Jul 22, 2010 at 13:21, Alan Cox <al...@lx...> wrote: > On Wed, 21 Jul 2010 14:57:54 +0200 > Mattia Jona-Lasinio <mat...@gm...> wrote: >> this is to introduce the LCD-Linux project (http://lcd-linux.sourceforge.net/), >> a kernel level implementation of a VT102 terminal emulator, optimized for small >> alphanumeric and graphic displays. > > The kernel already has a console and that provides an abstract > implementation that is used for everything from text mode displays to vga > to assorted accelerated hardware platforms. > > Why do we need a VT102 as well ? > >> functions. A solution is therefore to provide a sort of minimal terminal >> emulation in kernel space, that can be accessed through the standard character >> device interface. In this way the problem of the display management is reduced > > If you use the existing kernel console interfaces then you don't need to > worry about vt102 v console or having two terminal emulations running. Indeed, the kernel already has the console abstraction. I wrote a LCD console driver (for a HD44780 connected to the parallel port) using the standard console abstraction several years ago. As it used the standard console abstraction, it supported multiple virtual consoles and co-operated with the VGA text console out-of-the-box. Just use ALT-Fx to switch between different VCs on the LCD or on VGA. I never published the code, though. Will do so tonight when I get back to the machine that holds the code ;-) Having a bigger virtual console where the LCD follows the region surrounding the cursor is indeed a nice extension to have. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds |
From: Mattia Jona-L. <mat...@gm...> - 2010-07-21 12:58:04
|
Hi, this is to introduce the LCD-Linux project (http://lcd-linux.sourceforge.net/), a kernel level implementation of a VT102 terminal emulator, optimized for small alphanumeric and graphic displays. The possibility to connect to the computer small alphanumeric as well as graphic displays, has always attracted some interest. These small devices are connected to the computer and can be used to display system diagnostics like network usage, RAM or disk usage or even to replace the usual monitor. Possible applications can be found in embedded systems or clusters. These displays are connected to the computer through serial lines, parallel ports and more recently through USB connections. Appropriate programs in userspace gather the desired information and output it on the display. However for this to work, the userspace program has to implement some sort of display management, to determine what must be displayed where. This has two major disadvantages. First. Every userspace program willing to drive a display must solve the very same problems (display scroll and refresh, for instance), resulting in an overall duplication of code. Second. Display controllers usually require quite strict timings for proper operation and it is not trivial neither efficient to obtain this in userspace, whereas it is straightforward in kernel space through the usual delay functions. A solution is therefore to provide a sort of minimal terminal emulation in kernel space, that can be accessed through the standard character device interface. In this way the problem of the display management is reduced to some calls to the usual read/write/seek/ioctl routines. At the same time one has the possibility to implement handling of escape sequences, thus opening the way to standard applications based on the ncurses library. LCD-Linux aims to be a complete VT102 terminal emulation in kernel space, optimized for small alphanumeric and graphic displays. It consists of two distinct pieces of software. The first piece is the lcd-linux module in itself, implementing a (hopefully) complete VT102 terminal with the addition of some custom escape sequences specific to the world of small LCD displays. Care has been taken to avoid any conflict between standard and custom escape sequences. A major feature of lcd-linux is the possibility to define a virtual display geometry larger than the physical one, so that one can use a small display as a normal 80x25 monitor in an effective way. The layer takes care about display refresh and keeps the cursor visible in a smart way. A second feature is the possibility to connect more than one display (up to 256 different displays). Each display is assigned a different minor number and is addressed individually. The lcd-linux module also registers the appropriate major number character device and implements all the relevant read/write/seek/ioctl functions allowed on the character device. Finally it creates some /proc files for internal inspection, information and diagnostics. The second piece of software is the display driver, implementing all functions that are controller specific. Each driver registers itself with the lcd-linux layer and behaves like a 'slave' with respect to it. The interface between lcd-linux and the display driver is kept as simple as possible and no assumption is made by any of the two parts on the implementation of the other part. Ideally there will be one module for each controller. At the current stage, the driver for the Hitachi HD44780 (and compatibles) controller is fully implemented and optimized. Drivers for other controllers can be written in an easy way thanks to the standard interface provided by the lcd-linux layer. The LCD-Linux project has been under development for several years and has now reached a stable state. It has been succesfully compiled, tested and used on different machines running Linux version 2.2, 2.4 and 2.6. The software can be compiled as a module or compiled statically into the kernel. In the latter case, the user can pass some parameters at boot time, to configure the display as soon as possible during the boot sequence. The project comes with Documentation and examples about how to use it. LCD-Linux is released under the GNU General Public License version 2. The latest release is available at the Sourceforge website: http://lcd-linux.sourceforge.net/ http://prdownloads.sourceforge.net/lcd-linux/lcd-linux-0.13.9.tar.gz?download The CVS version still includes some partial support for Linux 2.0 but this support is considered obsolete and now abandoned in the official release. The LCD4Linux (http://ssl.bulix.org/projects/lcd4linux/) project is known to support LCD-Linux among the possible connection types. I would appreciate some comments and feedback on the project. In view of the potential applications, future developments and improvements of LCD-Linux, I would also like to propose LCD-Linux for inclusion in the Linux kernel mainline. Thank you for your attention. With best regards, Mattia Jona-Lasinio (LCD-Linux project developer and maintainer) |
From: Viktar P. <vik...@pr...> - 2010-07-19 09:17:54
|
On my custom board I have LCD simply connected to AT91SAM9260 GPIO pins like: LCD_BACKLIGHT - AT91_PB20 LCD_RS - AT91_PB21 LCD_RW - AT91_PB22 LCD_E - AT91_PB23 LCD_D0 - AT91_PB24 ... LCD_D7 - AT91_PB31 On Mon, Jul 19, 2010 at 12:02 PM, Linus Walleij <lin...@gm...> wrote: > 2010/7/19 Mattia Jona-Lasinio <mat...@gm...>: > >> As far as I understood you work with embedded ARM based boards. This >> could be a very good testbed for lcd-linux > > I don't know, these testboards are quite expensive, they're > not easily accessible. > >> What are the hardware requirements to make the display >> work on the ARM system? > > The display is mounted on the board, and the pins are routed > onto a special FPGA which has a custom controller for > driving the LCD lines. So it comes with the box. > > Yours, > Linus Walleij > > > -- Viktar Palstsiuk |
From: Linus W. <lin...@gm...> - 2010-07-19 09:02:55
|
2010/7/19 Mattia Jona-Lasinio <mat...@gm...>: > As far as I understood you work with embedded ARM based boards. This > could be a very good testbed for lcd-linux I don't know, these testboards are quite expensive, they're not easily accessible. > What are the hardware requirements to make the display > work on the ARM system? The display is mounted on the board, and the pins are routed onto a special FPGA which has a custom controller for driving the LCD lines. So it comes with the box. Yours, Linus Walleij |
From: Mattia Jona-L. <mat...@gm...> - 2010-07-19 08:56:49
|
Hello Viktar, Linus & Ivan, I'm certainly willing to submit lcd-linux in the Linux kernel upstream. I was thinking about it, also because it is not very efficient to introduce modifications just to keep it synced with the normal kernel development. Just give me some days to prepare an official announcement to the kernel mailing list. As far as I understood you work with embedded ARM based boards. This could be a very good testbed for lcd-linux since up to now I only tested it on i386 and sparc architectures, but never on embedded systems. What are the hardware requirements to make the display work on the ARM system? Regards, Mattia On Mon, Jul 19, 2010 at 10:06 AM, Viktar Palstsiuk <vik...@pr...> wrote: > Hello, Mattia > > What do you think about lcd-linux driver submission to Linux kernel upstream? > > > -- > Viktar Palstsiuk > On Sun, Jul 18, 2010 at 12:10 AM, Linus Walleij <lin...@gm...> wrote: > 2010/7/17 Ivan Kuten <iva...@pr...>: > >> Hello Linus, >> Any chance to sync your efforts with lcd-linux project >> (http://lcd-linux.sourceforge.net/) ? > > If the LCD-linux people make an attempt to go into the mainline, I > promise I will immediately migrate my driver out of drivers/misc > and out into drivers/lcd or wherever it'll end up. > > I cannot drive it however, they seem to be using special > hardware I haven't got access to. > >> They seems to have a support for HD44780 LCD controller. > > That's not the tricky bit of this driver actually, though there > is sure code to be de-duplicated if LCD-linux is merged, > ARM have some special-purpose silicon to handle the > HD44780 e.g. to fire interrupts when the display responds > etc. > > Yours, > Linus Walleij > |
From: Viktar P. <vik...@pr...> - 2010-07-19 08:07:00
|
Hello, Mattia What do you think about lcd-linux driver submission to Linux kernel upstream? -- Viktar Palstsiuk |
From: Anselm B. <ab...@cs...> - 2010-07-14 10:08:27
|
Ah ok, I see. I was hoping there is some fancy wrapping from the lcd driver class to the specific driver, because writing to the device results in some strange behavior of the LCD. But I think the problem is the I/O-code, so I still have to work on that. I will post, if there is some progress... Regards, Anselm Am 14.07.2010 um 11:17 schrieb Mattia Jona-Lasinio: > Hi, > > I'm sorry, but what do you mean by an 'hd44780 device'? The important > point is to have in the dev directory a character device with major > number 120 and minor number 0 and this is the char device you have to > write to/read from. The name in itself is not important. In the > documentation I assumed this to be /dev/lcd but can be whatever else. > To be more precise, since lcd-linux can virtually handle up to 256 > different displays (with major number 120 and minor number from 0 to > 255) I assumed the name to be something like /dev/lcd0, /dev/lcd1 and > so on, but again, the name in itself is not important. The creation of > the char device is handled by the udev service, but for this to work > you need to install the file 60-lcd-linux.rules in the appropriate > place of your distribution. If you don't have the udev service, you > need to create the char device by hand, with mknod. > > Hope it helps. > > Regards, > > Mattia > > On Wed, Jul 14, 2010 at 10:38 AM, Anselm Busse <ab...@cs...> wrote: >> Hi, >> >> I am working on a similar setup right know. Only difference is that I use a AT91RM9200 and the data pins of the LCD are connected to the data bus of the MCU, so the LCD is memory mapped. >> >> I have already modified the read and write functions and getting "reactions" from the LCD. But right know I am a little bit confused about the device interface. I have only a hd44780 device in my /dev tree but the doc says there should be a lcd device. So do I have to write to the hd44780 device to get an output on the LCD or is there something wrong because of the missing lcd device? >> >> Oh and I have compile the driver statically into the kernel. In case this is important. >> >> I would appreciate some help about this issue and will of course post my results if they are working. I think they can be easily adapted to a completely GPIO attached LCD. >> >> Regards, Anselm >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> _______________________________________________ >> Lcd-linux-users mailing list >> Lcd...@li... >> https://lists.sourceforge.net/lists/listinfo/lcd-linux-users >> > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Lcd-linux-users mailing list > Lcd...@li... > https://lists.sourceforge.net/lists/listinfo/lcd-linux-users |
From: Mattia Jona-L. <mat...@gm...> - 2010-07-14 09:17:34
|
Hi, I'm sorry, but what do you mean by an 'hd44780 device'? The important point is to have in the dev directory a character device with major number 120 and minor number 0 and this is the char device you have to write to/read from. The name in itself is not important. In the documentation I assumed this to be /dev/lcd but can be whatever else. To be more precise, since lcd-linux can virtually handle up to 256 different displays (with major number 120 and minor number from 0 to 255) I assumed the name to be something like /dev/lcd0, /dev/lcd1 and so on, but again, the name in itself is not important. The creation of the char device is handled by the udev service, but for this to work you need to install the file 60-lcd-linux.rules in the appropriate place of your distribution. If you don't have the udev service, you need to create the char device by hand, with mknod. Hope it helps. Regards, Mattia On Wed, Jul 14, 2010 at 10:38 AM, Anselm Busse <ab...@cs...> wrote: > Hi, > > I am working on a similar setup right know. Only difference is that I use a AT91RM9200 and the data pins of the LCD are connected to the data bus of the MCU, so the LCD is memory mapped. > > I have already modified the read and write functions and getting "reactions" from the LCD. But right know I am a little bit confused about the device interface. I have only a hd44780 device in my /dev tree but the doc says there should be a lcd device. So do I have to write to the hd44780 device to get an output on the LCD or is there something wrong because of the missing lcd device? > > Oh and I have compile the driver statically into the kernel. In case this is important. > > I would appreciate some help about this issue and will of course post my results if they are working. I think they can be easily adapted to a completely GPIO attached LCD. > > Regards, Anselm > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > Lcd-linux-users mailing list > Lcd...@li... > https://lists.sourceforge.net/lists/listinfo/lcd-linux-users > |
From: Anselm B. <ab...@cs...> - 2010-07-14 08:38:16
|
Hi, I am working on a similar setup right know. Only difference is that I use a AT91RM9200 and the data pins of the LCD are connected to the data bus of the MCU, so the LCD is memory mapped. I have already modified the read and write functions and getting "reactions" from the LCD. But right know I am a little bit confused about the device interface. I have only a hd44780 device in my /dev tree but the doc says there should be a lcd device. So do I have to write to the hd44780 device to get an output on the LCD or is there something wrong because of the missing lcd device? Oh and I have compile the driver statically into the kernel. In case this is important. I would appreciate some help about this issue and will of course post my results if they are working. I think they can be easily adapted to a completely GPIO attached LCD. Regards, Anselm |
From: Mattia Jona-L. <mat...@gm...> - 2010-07-12 14:42:43
|
Hi, low level functions are contained in the driver only, not in lcd-linux.c. Therefore to make it work with (I presume) memory mapped access, you just need to rewrite __read_display() and __write_display() in hd44780.c Please tell me the outcome of your tests. It would be interesting to add more platforms to lcd-linux. Regards, Mattia On Sat, Jul 10, 2010 at 2:47 PM, Viktar Palstsiuk <vik...@pr...> wrote: > Hello, > > I want to connect WH1602 (HD44780 based LCD) to ARM controller > AT91SAM9260 running Linux 2.6.33. > > As I can see lcd-linux uses parallel port connection to HD44780, I > have WH1602 connected to AT91 using GPIO lines. > > What functions of lcd-linux need to be reworked to make driver working > on my platform. > > -- > Viktar Palstsiuk > |
From: Viktar P. <vik...@pr...> - 2010-07-10 14:25:19
|
Hello, I want to connect WH1602 (HD44780 based LCD) to ARM controller AT91SAM9260 running Linux 2.6.33. As I can see lcd-linux uses parallel port connection to HD44780, I have WH1602 connected to AT91 using GPIO lines. What functions of lcd-linux need to be reworked to make driver working on my platform. -- Viktar Palstsiuk |
From: Ashish V. <va...@LN...> - 2009-12-22 15:51:00
|
Hello, I want to interface my OLED display of Powertip having inbuilt OLED driver as S6E63D6. I am looking for its device driver in linux. Please suggest. Regards Ashish Larsen & Toubro Limited Electrical & Electronics Division - EBG http://www.LNTEBG.com This E-mail may contain confidential or privileged information for the intended recipient(s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. |
From: Thomas K. <t.k...@ar...> - 2009-04-09 18:54:35
|
Hi everybody ! I've got a problem with a hd44780 compatible display running lcd4linux. I've already installed and configured. Everything looks fine. The displays shows the configured informations. Now to the problem. My display has the format : 16 x 4 First and second line are ok but third and fourth line start writing on position 5. So it seems that there are 4 spaces in front of everything in this lines. I've already found something on google, that hd44780.c has to be patched. But I don't really know how. Could you help me about this issue ? Thanks ! |