On Mon, Sep 15, 2008 at 2:38 PM, Ville Syrjälä <[EMAIL PROTECTED]> wrote: > On Mon, Sep 15, 2008 at 01:22:14PM -0700, Jon Dufresne wrote: >> > Using df_layer... >> >> Ok, I have been testing with this utility today and I have a question, >> >> if I dump the contents of lock->addr, for the size of a the image >> (while accounting for the pitch), should I have a copy of the image >> that is to be display in the overlay? > > If you do the dumping in FlipRegion() and the application has actually > filled the buffer with the correct data, then yes, you should get a > copy of the image. Naturally you need to take the layer's pixelformat > into account when doing the dumping. If you try to dump in SetRegion() > then you will probably get garbage since the application hasn't filled > the buffer with the correct data yet. Note that df_layer apparently > doesn't use double buffering so FlipRegion() won't be called.
I started using df_xine as a test cast, as opposed to df_layer. I certainly do see the contents of the video when I dump the lock->addr in FlipRegion. So this is reassuring. However, I still do not see the images in the actual overlay, just in the dump. I've double checked the registers and compared the dfb driver to the xv driver for the same intel device and I am at a loss. The overly correctly, turns on/off, correctly resizes and moves. It appears the only thing the overlay can't do is actually render the video image. The physical address I'm passing to the device is the the value found in lock->offset, as the device wants the offset of the overlay with respect to the framebuffer. When I do this the overlay appears as a green rectangle every time. Anyone have an idea why this might not be working? Thanks, Jon _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
