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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <653402b90610081545n51cdfbcej469990279f6d018c@mail.gmail.com>
Date:	Mon, 9 Oct 2006 00:45:36 +0200
From:	"Miguel Ojeda" <maxextreme@...il.com>
To:	"Pavel Machek" <pavel@....cz>
Cc:	akpm@...l.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.19-rc1 V9] drivers: add LCD support

On 10/9/06, Pavel Machek <pavel@....cz> wrote:
> Hi!
>
>
> I do not understand, both /dev/fbcfag12864b and /dev/cfag12864bX are
> in /dev/...
>

I mean: I think it is better to have the cfag12864b device than doesn't.

>
> What is advantage of /dev/cfag12864bX over /dev/fbcfag12864b ?
>
> (And I guess you should invent better name... /dev/fbaux0?)
>
>
> I do not think we need a Kconfig option, and I do not think we need
> /dev/cfag12864bX . Just use /dev/fbaux0, always.
>

One is the pure device, the other one is the framebuffer device. I
think having both is better than just one. There is no advantage, they
are different.

Maybe someone doesn't need any of the framebuffer advantages and just
wants to write to it directly, for better performance, for example:
The LCD needs to change 8 pixels (1 byte) every write, if you modify a
single pixel at the framebuffer device you will write more times than
you need for the same result (right? I'm not sure of this); the LCD is
not capable of high refreshing rates.

And well, I think it is better that way. About the Kconfig activating
both modules (cfag12864b and fbcfag12864b) I really don't care. One
option = easy of use. Both options = more control. Maybe someone just
needs the pure device :-/ We can really know how the requeriments will
be, but I think having more options in the future is better than
shrinking them now.

>
> 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.

If you are talking about the code's quality, well, the modules are
working fine, they have been reviewed by many people, and I and some
friend have tested them enought times to be sure they work. They
doesn't remove or change any other's code, they doesn't get compiled
by default either...

If you are talking about the framebuffer device, it is something that
can be added later, without any withdraws; and without having to stop
or modify the other device drivers; as is an additional feature that
should be added as other module "fbcfag12864b", like:

lcd -> parport -> ks0108 -> cfag12864b -> fbcfag12864b -> fbcon -> console

This way, adding future forks/modifications is easier and doesn't
affect other modules. Right now, we are providing cfag12864b support
to Linux, then, we will be able to provide a framebuffer device for
the cfag12864b; then, ...; then, ...
-
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/