Advices for a lcd driver design. (suite)

Advices for a lcd driver design. (suite)

[moreau francis]

Hello,

I posted an email 1 month ago because I was looking for advices to design
a driver for a lcd device (128x64 pixels) with a t6963c controller.

I have finally choosen a console implementation to interact with the lcd. It
allows me to reuse code that deals with escape character or to start a getty on
it. Unfortunately this implemenatation doens't support lcd's graphical mode.
So I wrote another small driver that can be accessed through "/dev/lcd". It
drives the lcd only in graphical mode. That means that a "echo foo > /dev/lcd"
command won't work as expected.

So now I'm wondering how to synchronize access to the lcd. Because a user appli
that is sending an image to "/dev/lcd" may want to prevent other access from
other application to the lcd either from "/dev/ttyX" or "/dev/lcd" but still
should be able to send char to "/dev/ttyX"

Any idea ?

Thanks for your answers,

         Francis


	

	
		
_____________________________________________________________________________ 
Découvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vidéos ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com

Re: Advices for a lcd driver design. (suite)

[Pavel Machek]

Hi!

> 
> I posted an email 1 month ago because I was looking for advices to design
> a driver for a lcd device (128x64 pixels) with a t6963c controller.

Ugh, whats wrong with standard handling via framebuffer?

> I have finally choosen a console implementation to interact with the lcd. It
> allows me to reuse code that deals with escape character or to start a getty on
> it. Unfortunately this implemenatation doens't support lcd's graphical mode.
> So I wrote another small driver that can be accessed through "/dev/lcd". It
> drives the lcd only in graphical mode. That means that a "echo foo > /dev/lcd"
> command won't work as expected.

Look at framebuffer, that's what you want. See for example vesafb.

									Pavel

Re: Advices for a lcd driver design. (suite)

[moreau francis]

--- Pavel Machek <pavel@ucw.cz> a écrit :

> Hi!
> 
> > 
> > I posted an email 1 month ago because I was looking for advices to design
> > a driver for a lcd device (128x64 pixels) with a t6963c controller.
> 
> Ugh, whats wrong with standard handling via framebuffer?
> 

well I already looked at framebuffers and choose to not use them because
t6963c controller does not have a frame buffer memory that can be accessed
by using mmap. It must be accessed through data write commands. So I decided
to not use them in order to save code space and speed up things.

am I wrong in my choice ?

> > I have finally choosen a console implementation to interact with the lcd.
> It
> > allows me to reuse code that deals with escape character or to start a
> getty on
> > it. Unfortunately this implemenatation doens't support lcd's graphical
> mode.
> > So I wrote another small driver that can be accessed through "/dev/lcd". It
> > drives the lcd only in graphical mode. That means that a "echo foo >
> /dev/lcd"
> > command won't work as expected.
> 
> Look at framebuffer, that's what you want. See for example vesafb.
> 

Does frame buffer have such mechanism ? if so could you point me the code that
handles it ?

cheers,

           Francis



	

	
		
_____________________________________________________________________________ 
Découvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vidéos ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com

Re: Advices for a lcd driver design. (suite)

[Lukasz Stelmach]

[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]

moreau francis napisał(a):

>>>I posted an email 1 month ago because I was looking for advices to design
>>>a driver for a lcd device (128x64 pixels) with a t6963c controller.
>>
>>Ugh, whats wrong with standard handling via framebuffer?
>>
> well I already looked at framebuffers and choose to not use them because
> t6963c controller does not have a frame buffer memory that can be accessed
> by using mmap.
[...]
> am I wrong in my choice ?

I think the "buffer" could be shadowed in kernel and updated periodically.

>>>So I wrote another small driver that can be accessed through "/dev/lcd". It
>>>drives the lcd only in graphical mode. That means that a 
>> "echo foo > /dev/lcd"
>>
>>>command won't work as expected.
>>
>>Look at framebuffer, that's what you want. See for example vesafb.
> 
> Does frame buffer have such mechanism ? if so could you point me the code that
> handles it ?

Yes and no. No because framebuffer is about drawing graphics not text
and yest for there is fbcon console driver on top of the framebuffer. At
least AFAIK.

BTW, have you seen these
http://www.skippari.net/lcd/t6963c_prog.html
http://wwwthep.physik.uni-mainz.de/~frink/lcd-t6963c-0.1/README.html

-- 
Było mi bardzo miło.                    Trzecia pospolita klęska, [...]
>Łukasz<                      Już nie katolicka lecz złodziejska.  (c)PP


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: Advices for a lcd driver design. (suite)

[moreau francis]

--- Lukasz Stelmach <stlman@poczta.fm> a écrit :

> moreau francis napisał(a):
> 
> > well I already looked at framebuffers and choose to not use them because
> > t6963c controller does not have a frame buffer memory that can be accessed
> > by using mmap.
> [...]
> > am I wrong in my choice ?
> 
> I think the "buffer" could be shadowed in kernel and updated periodically.
>

Ok I can try using frame buffer, but I'm afraid to use such code for such
small graphic device. Maybe for the start I can forget use "mmap" and use only
"write" method ?
Do you know if I can find an example in kernel code for such implementation ?
 
> 
> Yes and no. No because framebuffer is about drawing graphics not text
> and yest for there is fbcon console driver on top of the framebuffer. At
> least AFAIK.
> 

does that mean once there is fbcon console driver set up on top of framebuffer
I can't use anymore /dev/fb for drawing graphics ?

> BTW, have you seen these
> http://www.skippari.net/lcd/t6963c_prog.html
> http://wwwthep.physik.uni-mainz.de/~frink/lcd-t6963c-0.1/README.html
> 

yeah, but there's only one driver that uses text console implementation
and it can't be accessed for drawing graphics.

thanks

           Francis


	

	
		
_____________________________________________________________________________ 
Découvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vidéos ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com

Re: Advices for a lcd driver design. (suite)

[Lukasz Stelmach]

[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]

moreau francis napisał(a):

>>I think the "buffer" could be shadowed in kernel and updated
>> periodically.
> Ok I can try using frame buffer, but I'm afraid to use such code for such
> small graphic device.
[...]
> Do you know if I can find an example in kernel code for such implementation ?

I am afraid I don't know much about fb internals. I haven't used it much
  as a user nor written any fb code.

>>Yes and no. No because framebuffer is about drawing graphics not text
>>and yest for there is fbcon console driver on top of the framebuffer. At
>>least AFAIK.
> 
> does that mean once there is fbcon console driver set up on top of framebuffer
> I can't use anymore /dev/fb for drawing graphics ?

Of course not! :) As I stated I haven't used fb much but I have ran
mplayer right on top of the content of the output of "ls -l /dev".

Try to find something in:
/usr/src/linux/drivers/video/console/fbcon.c

-- 
Było mi bardzo miło.                    Trzecia pospolita klęska, [...]
>Łukasz<                      Już nie katolicka lecz złodziejska.  (c)PP


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: Advices for a lcd driver design. (suite)

[moreau francis]

--- Lukasz Stelmach <stlman@poczta.fm> a écrit :
>
> Try to find something in:
> /usr/src/linux/drivers/video/console/fbcon.c
> 

hmm I already looked at it...and I can't find out an answer to my initial
question: can a process which is using a fb console prevent another process
for accessing /dev/fb ?

cheers.

           Francis


	

	
		
_____________________________________________________________________________ 
Découvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vidéos ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com

framebuffer driver for an LCD display

[Lukasz Stelmach]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

moreau francis napisał(a):
> --- Lukasz Stelmach <stlman@poczta.fm> a écrit :
> 
>>Try to find something in:
>>/usr/src/linux/drivers/video/console/fbcon.c
> 
> hmm I already looked at it...and I can't find out an answer to my initial
> question: can a process which is using a fb console prevent another process
> for accessing /dev/fb ?

I don't know.

If I understand it correctly thie situation can be described like this


      GFX hardware
      -----+------
           |
        ---+---
           fb
       +-------+
       |       |
    fbcon     mplayer
    /   \
  vcs1  vcs2
  tty1
  bash

So I belive there might be no way for bash to prevent mplayer from
running. Please someone who knows more about framebuffer divers
correct me because quite probably I'am wrong.

-- 
Było mi bardzo miło.                    Trzecia pospolita klęska, [...]
>Łukasz<                      Już nie katolicka lecz złodziejska.  (c)PP


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]