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] [day] [month] [year] [list]

Date:	Tue, 10 Oct 2006 12:37:23 +0200
From:	Pavel Machek <pavel@....cz>
To:	Miguel Ojeda <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!

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

No, having two different interfaces when one would be enough is
stupid.

Face it... you are writing driver for framebuffer. (Small, slow,
black&white, but still framebuffer).

> 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

Wrong, I think you only need to change 1bit, so framebuffer device
actually performs better.

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

Bad user<->kernel interface is good enough reason for the patch not to
be merged anywhere.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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/