From: Pavel Machek <pavel@ucw.cz>
To: Miguel Ojeda Sandonis <maxextreme@gmail.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.19-rc1 V9] drivers: add LCD support
Date: Sun, 8 Oct 2006 18:24:38 +0000 [thread overview]
Message-ID: <20061008182438.GA4033@ucw.cz> (raw)
In-Reply-To: <20061006002950.49b25189.maxextreme@gmail.com>
Hi!
> Andrew, I think this can be the final review.
> Updated to 2.6.19-rc1. Please apply.
No, I'm sorry. And I have to apologize for being blind.
I was going to say 'this is very important, because cellphones *do*
have secondary displays, and we want to use them'. And yes it is
important, but you got the interface wrong.
> + The cfag12864b LCD driver defines two ways to communicate
> + with the lcd.
> +
> + 1. Use seek and write syscalls. Bytes written appear on
> + the screen without any formatting on the position pointed
> + by the file offset.
> +
> + It is hardware dependent. It should be use to modify
> + specific display's pixels to achieve higher refreshing
> + rates.
> +
> + 2. Use ioctl syscall. The magic number is 0xFF.
> + There are four ioctls:
> +
> + 2.0. off _IO(0xFF,0)
> +
> + Power off display.
> +
> + It doesn't clear the display.
> + It doesn't stop the controllers.
> +
> + 2.1. on _IO(0xFF,1)
> +
> + Power on display.
> +
> + 2.2. clear _IO(0xFF,2)
> +
> + Clear the display.
> +
> + 2.3. format _IOW(0xFF,3,void *)
> +
> + Read the given buffer, transform it to the hardware
> + dependent format and show it on the screen.
> +
> + The argument must point to a userspace buffer of
> + size 128*64 bytes (the display's size).
> +
> + Each buffer's byte (unsigned) represent a pixel:
> + 0 = pixel will turn off
> + >0 = pixel will turn on
> +
> + For more information and examples, see
> + Documentation/auxdisplay/cfag12864b
So you have 128x64 pixels b/w display, and invented completely new
interface to control it.
Fortunately we already have good interface for the display... It is
called fbcon, and is more flexible than 128x64 b/w... but can do
128x64 b/w just fine.
Please use it. It is way more flexible, and it is right thing to do.
Pavel
--
Thanks for all the (sleeping) penguins.
next prev parent reply other threads:[~2006-10-08 18:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-06 0:29 [PATCH 2.6.19-rc1 V9] drivers: add LCD support Miguel Ojeda Sandonis
2006-10-08 18:24 ` Pavel Machek [this message]
2006-10-08 18:37 ` Miguel Ojeda
2006-10-08 19:12 ` Pavel Machek
[not found] ` <653402b90610081312m32fcf7ecx9929ae9dc4768c17@mail.gmail.com>
[not found] ` <20061008211550.GE4152@elf.ucw.cz>
2006-10-08 21:36 ` Miguel Ojeda
2006-10-08 22:07 ` Pavel Machek
2006-10-08 22:45 ` Miguel Ojeda
2006-10-09 13:33 ` Stefan Richter
2006-10-09 13:56 ` Miguel Ojeda
2006-10-10 10:37 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2006-10-05 16:26 Miguel Ojeda Sandonis
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=20061008182438.GA4033@ucw.cz \
--to=pavel@ucw.cz \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.