linux-kernel - Re: [PATCH 2.6.19-rc1 full] 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 for Android: free password hash cracker in your pocket

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

Message-ID: <454763B5.1050204@grupopie.com>
Date:	Tue, 31 Oct 2006 14:54:45 +0000
From:	Paulo Marques <pmarques@...popie.com>
To:	Franck <vagabon.xyz@...il.com>
CC:	Miguel Ojeda <maxextreme@...il.com>, akpm@...l.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2.6.19-rc1 full] drivers: add LCD support

Franck Bui-Huu wrote:
> Paulo Marques wrote:
>> Franck Bui-Huu wrote:
>>> An application might want to display quickly a set of images, not for
>>> doing animations but rather displaying 'fake' greyscale images.
>>
>> To do "fake" greyscale you would need to synchronize with the actual
>> refresh of the controller or you will have very ugly aliasing artifacts.
>>
>> Since there is no hardware interface to know when the controller is
>> refreshing, I don't think this is one viable usage scenario.
> 
> eh ?? Did you read my email before ? That was the point I was trying
> to raise... and starting the refresh stuff _only_ when the device is
> mmaped seems to me a good trade off.

I think we are violently agreeing about the optimal way of doing things.

But maybe I didn't explain my point about the "fake" greyscale in the 
best way, though.

There are two distinct "refresh"'s involved here: one is when the driver 
writes its software buffer into the display internal memory using the 
parallel port interface.

The other is when the actual display controller refresh that goes 
through all the common lines, etc., using the values on its internal 
memory to update the segment voltages.

The problem is that there is no way to know about the internal refresh 
that the controller does. So if you update its memory very frequently to 
try to produce a "fake" greyscale image, your updates will alias with 
the refresh rate of the actual display controller and you will see all 
sorts of strange effects on the display.

> Aynywas it seems that the discusion about the design is closed and
> won't lead to interesting things...

Only because we're mostly in agreement about what should be done ;)

But if you have other interesting things to suggest, I haven't seen 
Miguel reject any suggestions by other developers, yet (very much on the 
contrary, to be honest).

-- 
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com

"The face of a child can say it all, especially the
mouth part of the face."
-
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/