On Sat, Jun 13, 2009 at 11:51:02PM +0200, Reinhard Nissl wrote:
> > Can you (or somebody else) summarize in a few words what special
> > handling the eHD does?
> I cannot tell, what these OSD function do internally, but it
> looks to me like they are meant to avoid copying large memory
> blocks to the eHD over and over:
>     virtual void SetImagePath(u_int imageId, char const *path);
>     virtual void DrawImage(u_int imageId, int x, int y, bool
> blend, int horRepeat = 1, int vertRepeat = 1);

That was the old way... At the beginning, I haven't found the
magic/undocumented bit for accepting PCI bursts to the DeCypher memory, so
the write bandwidth was only about 10MB/s. A raw framebuffer access would be
very slow and flickery.

So the drawing commands were sent via a command pipe to the DeCypher. The
hdplayer there did an interpretation of the commands and worked on its
framebuffer. To accelerate the "fancy" stuff, there is a font and image
cache in the hdplayer, so they need to be transferred only once.

BTW: The framebuffer itself is overlayed in the hardware over the video
depending on the 8bit alpha value for each ARGB-pixel. There's also a mode
with only a global alpha and "regular" RGB-pixels available, but that
doesn't look that nice ;-)

However, all the alpha blending of the fonts and backgrounds were done in SW
on the DeCypher. As it's only a 166MHz MIPS CPU, this was relatively slow.

Now it's done different, as PCI bursts are possible and the bandwidth is
greater than 30MB/s. The hdshm kernel driver on the host linux implements a
framebuffer driver (which also can be used for X). The reelbox-PI draws all
its stuff in a shadow buffer and copies only the changed rectangle to the

         Georg Acher, ac...@in.tum.de         
         "Oh no, not again !" The bowl of petunias          

vdr mailing list

Reply via email to