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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
