From: "Franck Bui-Huu" <vagabon.xyz@gmail.com>
To: "Miguel Ojeda" <maxextreme@gmail.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.19-rc1 full] drivers: add LCD support
Date: Fri, 27 Oct 2006 22:03:25 +0200 [thread overview]
Message-ID: <cda58cb80610271303p29f6f1a2vc3ebd895ab36eb53@mail.gmail.com> (raw)
In-Reply-To: <653402b90610260755t75b3a539rb5f54bad0688c3c1@mail.gmail.com>
On 10/26/06, Miguel Ojeda <maxextreme@gmail.com> wrote:
> To be clearer. And you are wrong: you can write other modules which
> want to know what the LCD is showing, or use it; without worrying
> about framebuffer things. They can read / write "cfag12864b_buffer" as
> well as cfag12864bfb do. Why not?
>
Suppose I'm writing a user space application which uses your frame
buffer driver. I would naturaly mmap your device since it's the
easiest way to use a frame buffer. Now I want to display as fast as
possible a set of images. How am I sure that each image is sent to the
lcd ? For example, suppose the application just finished to copy image
A into the buffer, and now it starts to copy image B into the buffer
but the work queue has not been scheduled yet...
Futhermore I'm not sure it's a common use case for such device, is it
? I would say that the usual case for such LCD is to display an image
every now and then. If so do we really need to give the possibility to
mmap the device ? Is a simple synchrone write() enough ?
BTW how can the application retrieve the refresh rate from the driver ?
Franck
next prev parent reply other threads:[~2006-10-27 20:03 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-13 2:32 Miguel Ojeda Sandonis
2006-10-13 12:43 ` Paulo Marques
2006-10-18 14:55 ` Franck Bui-Huu
2006-10-23 8:41 ` Franck Bui-Huu
2006-10-23 12:56 ` Miguel Ojeda
2006-10-23 15:35 ` Franck Bui-Huu
2006-10-23 16:21 ` Miguel Ojeda
2006-10-23 16:51 ` Franck Bui-Huu
2006-10-26 14:45 ` Miguel Ojeda
2006-10-27 20:08 ` Franck Bui-Huu
2006-10-27 20:38 ` Miguel Ojeda
2006-10-30 8:43 ` Franck Bui-Huu
2006-10-30 13:35 ` Miguel Ojeda
2006-10-23 16:05 ` Franck Bui-Huu
2006-10-23 16:08 ` Miguel Ojeda
2006-10-23 17:15 ` Franck Bui-Huu
2006-10-26 14:55 ` Miguel Ojeda
2006-10-27 20:03 ` Franck Bui-Huu [this message]
2006-10-27 20:25 ` Miguel Ojeda
2006-10-30 9:26 ` Franck Bui-Huu
2006-10-30 13:22 ` Paulo Marques
2006-10-30 14:11 ` Miguel Ojeda
2006-10-30 15:21 ` Paulo Marques
2006-10-30 17:32 ` Miguel Ojeda
2006-10-30 20:45 ` Paulo Marques
2006-10-31 8:10 ` Franck Bui-Huu
2006-10-31 14:12 ` Miguel Ojeda
2006-10-31 14:54 ` Paulo Marques
2006-10-30 13:47 ` Miguel Ojeda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cda58cb80610271303p29f6f1a2vc3ebd895ab36eb53@mail.gmail.com \
--to=vagabon.xyz@gmail.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxextreme@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome