[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061008182438.GA4033@ucw.cz>
Date: Sun, 8 Oct 2006 18:24:38 +0000
From: Pavel Machek <pavel@....cz>
To: Miguel Ojeda Sandonis <maxextreme@...il.com>
Cc: akpm@...l.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.19-rc1 V9] drivers: add LCD support
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists