Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: Need help understanding OSD ioctls, mostly SetColor and SetBlock.



Chris Worley wrote:
> 
> There doesn't seem to be any documentation on the OSD ioctls (or
> library calls).  If there is, please point me there and I'll RTFM.
> 
> I've been looking at VDR's use of OSD, but it seems minimal.
> 
> VDR only calls "open" with 4bpp.  The libdvb OSD.c seems to limit bpp
> in the open call to 15.  "LoadBitmap" seems to have a limit of 8bpp.
> How big can the color palette be?

You can have 1, 2, 4 or 8 bpp. However, since OSD memory is very limited,
using more than 4bpp leaves you with only a very small usable OSD area.

Another drawback of the DVB card's OSD is that it isn't very fast.
Drawing a lot of text with many separate calls is way too slow to be
useful. That's why VDR mainly uses the OSD_SetBlock call to transfer
a bitmap (or parts of it) from VDR's memory to the OSD. This works fast
enough to be useful (IMHO).

> In calling OSDSetcolor, the last argument is "blend".  Is this an
> alpha blend?  The "blend" seems to only use the top 4 bits of the byte
> in the driver. What does the range mean (i.e. is 0xf0 or 0x00 all
> graphics or all video)?

0x00 means all video and 0xF0 means all graphics. For example 0x70 will
result in 50% transparency (VDR uses this for the OSD's transparent 
background).

> In general, I don't seem to be able to set colors... as if some other
> setup is necessary before colors can be set.  Any ideas what I'm doing
> wrong?

You need to issue an OSD_Open call first with the Bpp parameter. After
that you can set colors. See VDR's dvbapi.c and dvbosd.c.

> Calling OSDSetBlock hangs the app and the driver.  I think it's in the
> LoadBitmap routine, but I need to investigate this further to be sure.
>   The driver needs to be reloaded to be usable again after a call to
> OSDSetBlock.

This may be due to the missing OSD_Open call. VDR uses OSD_SetBlock a lot,
so I know it works (at least with 4bpp, haven't tested other bpp values yet).

> VDR has a comment:
> 
>       //XXX Workaround: apparently the bitmap sent to the driver
> always has to be a multiple
>       //XXX of 8 bits wide, and (dx * dy) also has to be a multiple of 8.
>       //TODO Fix driver (should be able to handle any size bitmaps!)

I fiddled around with this for quite a while in the early stages of
VDR, until I figured this one out. It would take additional efforts
in the driver to make it accept randomly aligned bitmap data.

> I've tried this with OSDSetBlock, but it doesn't help... the hang
> still occurs.  Are there other constraints with SetBlock that aren't
> documented?

Take a look at VDR's dvbapi.c and dvbosd.c to see how this works.

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.



Home | Main Index | Thread Index