This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Generic framebuffer support
- From: Bart Veer <bartv at ecoscentric dot com>
- To: "Gábor Török" <tgabor84 at gmail dot com>
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: Sun, 09 Nov 2008 11:45:56 +0000
- Subject: Re: [ECOS] Generic framebuffer support
- References: <30c102240810301712s59e9d2e9tcc437adf2022dadc@mail.gmail.com>
>>>>> "tgabor84" == =?ISO-8859-1?Q?G=E1bor T=F6r=F6k?= <tgabor84@gmail.com> writes:
tgabor84> Hi!
tgabor84> I think I have found a bug in the generic framebuffer
tgabor84> code in function "cyg_fb_linear_move_block_16_impl" in
tgabor84> "linear.c". I think the code below should either init
tgabor84> source and dest with (height-1) or do the decrements
tgabor84> before the memcpy in the for loop.
tgabor84> // There is an overlap. Can we do a safe bottom-to-top lot of memcpy()'s ?
tgabor84> if (new_y > y) {
tgabor84> source = (cyg_uint16*)(((cyg_uint8*)source) + (height * stride8));
tgabor84> dest = (cyg_uint16*)(((cyg_uint8*)dest) + (height * stride8));
tgabor84> width <<= 1;
tgabor84> for ( ; height; height--) {
tgabor84> __builtin_memcpy(dest, source, width);
tgabor84> source = (cyg_uint16*)(((cyg_uint8*)source) - stride8);
tgabor84> dest = (cyg_uint16*)(((cyg_uint8*)dest) - stride8);
tgabor84> }
tgabor84> return;
tgabor84> }
Agreed. I have checked in a fix which does the decrement before the
memcpy().
Bart
--
Bart Veer eCos Configuration Architect
eCosCentric Limited The eCos experts http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss