Re: [PATCH] Framebuffer copyarea function taught to fully support swapped pixel order in bytes

On Tue, 2007-10-09 at 13:12 +0200, Pavel Pisa wrote:
> This correct case, when source and destination X coordinates difference is not
> multiple of pixels in byte. This is probably rare case, but this case should be
> supported for completeness.
> 
> Reorganization of FB_READL and FB_WRITEL calls results in code size decrease
> for normal build without swapping support and size with support enabled
> is reasonable too.
> 
> Signed-off-by: Pavel Pisa <[email protected]>
> 
> --
> 
> Hello Tony,
> 
> thanks for forwarding two patches to MM tree.
>   fbdev-support-for-byte-reversed-framebuffer-formats.patch
>   imxfb-fast-read-flag-and-nonstandard-field-configurable.patch
> 
> What are yours plans with the third one. Do you think, that it
> can fit in 2.6.24 merge window or you want to push changes
> incremental and delay it for 2.6.25.

I can push this for 2.6.24.

>  Have you found time to test
> it on your setup?

Yes, I did. I haven't encountered any bugs yet, nor any significant
slowdown with my setup. 

>  I have planed to prepare some in kernel test
> with rectangles and copying, because functions are hard to test
> from userspace, but I have not found time for that. The code works 
> right on our HW, but the real range of FB devices is much much
> more variable.

That's okay. As long as a patch does not produce a regression, I'm fine
with it.

Tony


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/