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:
signature.asc
Description: OpenPGP digital signature
- Follow-Ups:
- Re: Advices for a lcd driver design. (suite)
- From: moreau francis <[email protected]>
- Re: Advices for a lcd driver design. (suite)
- References:
- Re: Advices for a lcd driver design. (suite)
- From: moreau francis <[email protected]>
- Re: Advices for a lcd driver design. (suite)
- Prev by Date: Re: [patch] Real-Time Preemption, -RT-2.6.12-rc6-V0.7.47-29
- Next by Date: Re: [PATCH] Dynamic tick for x86 version 050602-1
- Previous by thread: Re: Advices for a lcd driver design. (suite)
- Next by thread: Re: Advices for a lcd driver design. (suite)
- Index(es):
 |