Re: [PATCH 2.6.19-rc1 V9] drivers: add LCD support

["Miguel Ojeda" <maxextreme@gmail.com>]

On 10/9/06, Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:
> On 10/9/2006 12:45 AM, Miguel Ojeda wrote:
> > On 10/9/06, Pavel Machek <pavel@ucw.cz> wrote:
> ...
> >> What is advantage of /dev/cfag12864bX over /dev/fbcfag12864b ?
> >>
> >> (And I guess you should invent better name... /dev/fbaux0?)
>
> If the driver exposes sensible information, udev can give names.
>
> ...
> >> I do not think it is suitable for -rc at this point, and it does not
> >> have chance before 2.6.20-rc1, anyway.
> >
> > No? Why not? Time is not a problem, I would want to know why are you
> > saying that.
>
> Linus currently has a rule for merge windows; akpm certainly doesn't.
>

I meant that time is not a problem (it is not a critical part), so the
drivers can wait peacefully until the next merge window (althought
they don't compromise any other part of the kernel :). But I thought
he could be saying that the code is not ready (because of the
framebuffer).

>
> On 10/8/2006 11:36 PM, Miguel Ojeda wrote:
> ||| I have no problem coding the fbcfag12864b module in my free time;
> ||| but I prefer to remain the other modules as they are now and add
> ||| the fbcfag12864b later in time: I'm waiting them to get into one
> ||| of the -rcs without more radical changes.
>
> An interface which promises to be future-proof, especially if it is an
> interface to userspace, is of course a requirement to get into mainline
> in the first place. (However I don't know enough about the interfaces
> discussed here nor about your requirements to say anything specifically
> about your interface or the one Pavel suggested.)
>

Sure, the point is that there is no new interface:

My thought: The cfag12864b module creates a device node
/dev/cfag12864b which represents the physical display. If you write
there, you get the pixels painted in the screen. So if I code a new
fbcfag12864b module which depends on the cfag12864b module and creates
a new device, a framebuffer one. The framebuffer interface is also
"standard", right?. This way, as there are not any new interfaces, and
as cfag12864b doesn't know anything about fbcfag12864b and
fbcfag12864b doesn't have to know about the hardware, it is
future-proof as there is not going to be any changes and no new
interfaces in any way. The cfag12864b will remain without any changes.

Pavel suggested that I should recode the cfag12864b to destroy all
about the /dev/cfag12864b, and just create the fbcfag12864b device. I
think this mixs different concepts (the framebuffer abstraction with
the hardware), create less maintanieable code (as it mixs hardware io
related code with the framebuffer code: someone could improve the
fbcfag12864b without having to read about the cfag12864b driver, for
example; or change some function to meet the new kernel release
instead of having to take care of more irrelevant code), less scalable
(as it is mixed together), more hardware specific (maybe it is
possible to create a framebuffer device for every lcd of 128x64
dimensions), etc.

      Miguel Ojeda