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

[Lukasz Stelmach <stlman@poczta.fm>]

[-- 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 --]