Hi!
DirectFB reports:
DirectFB/Graphics: Vivante unknown chip model 1.0 (Vivante)
1) I'm having problem ATM to use hw acceleration for displaying/scaling preallocated I420 surfaces. At first, I've got alignment warnings like these:
(!!!) *** WARNING [Prealloc address is not aligned! | |
] *** [gc_dfb_pool.c:322 in galAllocateBuffer()] |
(!!!) *** WARNING [Failed to do blit. status: -20
After I align preallocated buffer by 64 bytes I started getting the following warning:
*** [gc_dfb_raster.c:1463 in galBlit()] |
(!!!) *** WARNING [Failed to do blit. status: -20 ]
If I disable hw acceleration (e.g. either by by removing libdirectfb_gal.so from gfxdrivers directory or by setting "no-hardware" option in directfbrc) I can create I420 surface and scale it if needed(using StretchBlit()) without any problems.
Original source code for blitting/stretch blitting:
idsc.flags = DSDESC_HEIGHT | DSDESC_WIDTH | DSDESC_PREALLOCATED | DSDESC_PIXELFORMAT;
idsc.caps = DSCAPS_NONE;
idsc.pixelformat = DSPF_I420;
idsc.preallocated[0].data = (uint8_t *)ptr; /* 64 byte aligned */
idsc.preallocated[0].pitch = idsc.width;
idsc.preallocated[1].data = NULL;
idsc.preallocated[1].pitch = 0;
DFBCHECK(dfb->CreateSurface(dfb, &idsc, &yuvsf));
DFBCHECK(primary->Blit(primary, yuvsf, NULL, x, y));
DFBCHECK(yuvsf->Release(yuvsf));
primary's format is RGB32.
2) I'm also having problems when trying to Blit RGB24 preallocated surface to RGB32 primary surface. Errors:
] *** [gc_dfb_utils.c:239 in gal_get_native_format()]
(!?!) *** BUG [unexpected pixelformat.
TIA.
Best regards.
Alex.
已解决! 转到解答。
Yes, I already did this using fbset.
After some additional investigation I resolved the problem. I think it was related to the pixel format that I compiled into QT. By default QT used ARGB pixel format where the alpha bits remain on the most significant bits. I suppose that these bits where responsible for the wrong pixel offset.
So after recompiling QT without 32bit ARGB support the problem is gone for me.
Meanwhile I have added this patch to my directfb-1.4.0 version manually, but unfortunatly it does not resolve the situation. The surfaces allocated by qt are all at a 64 byte offset. Therefore I think it is a problem surface pool handling inside gfxdriver?!
Yes, I already did this using fbset.
After some additional investigation I resolved the problem. I think it was related to the pixel format that I compiled into QT. By default QT used ARGB pixel format where the alpha bits remain on the most significant bits. I suppose that these bits where responsible for the wrong pixel offset.
So after recompiling QT without 32bit ARGB support the problem is gone for me.
I have the same problem here (using a QT based application), but I did not yet take a deeper look into this problem.
And yes, I do see a lot of display errors.
BTW: Will the source code of the gfxdriver be available in future?