i.mx6q sabresd and DirectFB

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.mx6q sabresd and DirectFB

Jump to solution
1,996 Views
alexanderz
Contributor I

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.

Labels (4)
1 Solution
1,062 Views
Martin1z
Contributor III

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.

View solution in original post

7 Replies
1,062 Views
PrabhuSundarara
NXP Employee
NXP Employee

Do you see any problems with the surface which are not preallocated?

0 Kudos
1,062 Views
Martin1z
Contributor III

I have detected that there is an option to adjust alignment in direcftb. But unfortunatly this feature wasn't available in directfb 1.4.0.

git.directfb.org Git - core/DirectFB.git/commit

0 Kudos
1,062 Views
Martin1z
Contributor III

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?!

0 Kudos
1,062 Views
ChucoChe
NXP Employee
NXP Employee

Have you tried to increase the size of the frame buffer virtual size?

Vivantes directfb implementation takes the size of the surfaces from the frame buffer.

Michel

0 Kudos
1,063 Views
Martin1z
Contributor III

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.

1,062 Views
karina_valencia
NXP Apps Support
NXP Apps Support

no response.

0 Kudos
1,062 Views
Martin1z
Contributor III

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?

0 Kudos