Series2 OSD

[dah31]

Introduction

This is libosd 0.1, a library containing on-screen display (OSD)
routines for Series1 and Series2 TiVo units, tested on a Philips
DSR7000 running 4.0.

The API is intended to be more or less backwards compatible with the
one(s) used in tivovbi, elseed, yac, and newtext2osd, with
enhancements for slanted and coloured text. (I have successfully
ported elseed, yac, and newtext2osd to Series2 with this library.)
See the example for usage.

The Series2 code came from disassembling /tvbin/osdwriter from 4.0.
Some of the variable and function names refer to addresses in
osdwriter (which I have also reconstructed source for).


Notes:

Series2 colours are 32-bit unsigned quantities of the form 0xAARRGGBB.

I have hard-coded an offset of 6 pixels into the bSurfacePosition()
routine in brcm.c to compensate for the `ghost' image noted at
<URL:http://www.dealdatabase.com/forum/sh...86&postcount=1>.
On Live TV and TiVo Central, anyway; Now Playing doesn't have the
offset.

You can forget the return value of setupBrcmDisplay() (0 for failure)
unless you want to call the bSurface* routines yourself.

Due to that `ghost' image, the opacity values don't work linearly:
there are effectively two copies of the image overlaid.

I haven't actually been able to test elseed yet, as the phone hasn't
rung for several days!


Todo^H^H^H^HExercises for the reader:

o test Series1 support. I'm pretty sure it doesn't work just
now....

o fix bugs

o colour name to value mapping, something like X's rgb.txt?

o changeable fonts

o certainly, a font encoded for (say) Latin-1, rather than MS-DOS
codepage 437.

o FreeType would probably work well for those last two.

[alldeadhomiez]

I have hard-coded an offset of 6 pixels into the bSurfacePosition()
routine in brcm.c to compensate for the `ghost' image noted at
<URL:http://www.dealdatabase.com/forum/sh...86&postcount=1>.
On Live TV and TiVo Central, anyway; Now Playing doesn't have the
offset.

Nice work. A separate library is just what we needed to bring the S1/S2 codebases together.

In my trials, I was able to use (0,0) in bSurfacePosition() as long as I killed off the calls to bSurfaceShow() and bcmGfxSetAntiFlutFilter(). I have no idea why that worked though.

Since the cat is out of the bag now, we may as well combine efforts and fill in any gaps in our knowledge/implementations. I'm attaching the patch I made against newtext2osd 1.4.

Edit 2005/02/02:
I have added Series2.5 OSD support to my tivovbi fork: link

[dah31]

In my trials, I was able to use (0,0) in bSurfacePosition() as long as I killed off the calls to bSurfaceShow() and bcmGfxSetAntiFlutFilter(). I have no idea why that worked though.

It seems that bSurfaceShow() shows the `main' image: not calling it leaves only the `ghost' image, which is not movable with bSurfacePosition().

All this is because we're sharing TiVo's surface. The joke's on us, it seems, for assuming TiVo knew what they were doing when they wrote osdwriter. ;-)

Since the cat is out of the bag now, we may as well combine efforts and fill in any gaps in our knowledge/implementations. I'm attaching the patch I made against newtext2osd 1.4.

Yes, looks mildly familiar. :-D

(I delayed release as well because of the legal issues. But then I decided
that TiVo didn't exactly make osdwriter hard to follow, so it's not like they
were trying to keep us out. Not to detract from Xybyre's work with fly &c.,
but that does seem a bit klugey when we're sitting on basically the same
code TiVo are using.)

I've made a few changes to my code based on my latest experiments. Like
thusly:

Don't Get a SharedSurface; Create your own and don't Share it.

Now you have a Surface all of your very own to play with. It won't
interfere with the TiVo menus or on-screen displays (even the Play
bar), *and* the Zordering works! (It appears TiVo displays its
displays somewhere around zorder 4 or 5. 4, I reckon, based on the
DirecTV banners (e.g., channel 88), which are apparently redisplayed
every few seconds, appearing in front of our surface at zorder 4.) So
I've changed the surface acquisition code in setupBrcmDisplay() to
call only bSurfaceCreate() and removed the +6 from bSurfacePosition().

Now, there is presumably only a limited number of surfaces available,
so I've still got the bSurfaceGetSharedSurface() in there as a
fallback.

I've refrained from memset()ing the new surface's buffer to 0s in example1.c
in order to show up the zordering better.

I've also added example2.c, the code I used to test my OSD code the night I
got it working.

[tivomaster]

Thanks dah31 this is a breakthough. We S2 folks can run a lot of S1 apps that were missing the osd stuff.......

Is the future newtext2osd going to support the normal S1 style color codes?

I see where you say:

"Series2 colours are 32-bit unsigned quantities of the form 0xAARRGGBB"

I take it the RRGGBB are Red,Green,and Blue but what is the AA?

[dah31]

This is libosd 0.2, a library containing on-screen display (OSD)
routines for Series1 and Series2 TiVo units, tested on a Philips
DSR7000 running 4.0.

The API is intended to be more or less backwards compatible with the
one(s) used in tivovbi, elseed, yac, and newtext2osd, with
enhancements for slanted and coloured text. (I have successfully
ported elseed, yac, and newtext2osd to Series2 with this library.)
See the example for usage.

The Series2 code came from disassembling /tvbin/osdwriter from 4.0.
Some of the variable and function names refer to addresses in
osdwriter (which I have also reconstructed source for).


Notes:

Series2 colours are 32-bit unsigned quantities of the form 0xAARRGGBB.

The hard-coded offset of 6 pixels into the bSurfacePosition() routine
in brcm.c to compensate for the `ghost' image noted at
<URL:http://alt.org/forum/index.php?t=msg...423c709f9773b7>
has now been removed. It's not needed if you have your own surface.
It's still in setupBrcmDisplay() if you have to share a surface,
though, and the (ick) global got_own_surface says whether you got your
own surface or not, so you can correct your own bSurfacePosition()
calls and opacity values.

You can forget the return value of setupBrcmDisplay() (0 for failure)
unless you want to call the bSurface* routines yourself.

When sharing TiVo's surface, due to that `ghost' image, the opacity
values don't work linearly: there are effectively two copies of the
image overlaid.

I haven't actually been able to test elseed yet, as the phone hasn't
rung for several days!


TodoExercises for the reader:

o test Series1 support. I'm pretty sure it doesn't work just
now....

o fix bugs

o colour name to value mapping, something like X's rgb.txt?

o changeable fonts

o certainly, a font encoded for (say) Latin-1, rather than MS-DOS
codepage 437.

o FreeType would probably work well for those last two.

Please note that the attached files are not ZIP archives.

[dah31]

Is the future newtext2osd going to support the normal S1 style color codes?

Mine doesn't, but alldeadhomiez's does. They wouldn't be very difficult to add; it's just that the most transparent way seems somewhat inelegant:

#ifdef __TIVO_S2__
  if (colour < 0x100) colour = s1_to_s2_colours_table[colour];
#endif  /* __TIVO_S2__ */

Ah, that's not so bad. Look for it in 0.3.

I see where you say:

"Series2 colours are 32-bit unsigned quantities of the form 0xAARRGGBB"

I take it the RRGGBB are Red,Green,and Blue but what is the AA?

opAAcity :-)

Okay, so it's `alpha', but `opacity' keeps me from confusing it with transparency. AA runs from 0x00 (for totally transparent) to 0xff (for totally opaque).

[tivomaster]

This is libosd 0.2, a library containing on-screen display (OSD)
routines for Series1 and Series2 TiVo units, tested on a Philips
DSR7000 running 4.0.

I tried the new version on my HDVR2 (3.1.0) and it works like a champ.

[RKone]

This patch will allow osdwriter to properly display grey and palettized images with alpha channels on S2 tivos.

[dgi]

I am currently extending tivovbi to handle the full closed-captioning protocol. I would be willing to work with someone that has a Series2 to broaden the source so that it could run on those machines as well. Right now the biggest holdup is the lack of a complete Latin-1 font instead of the MS-DOS codepage 437. I would welcome help with at least five things that comprise a wishlist for my current unreleased version:

1) to complete my partial Latin-1 font that I produced by rearranging the existing MS-DOS codepage 437 font
2) to make flashing text produce some kind of visual feedback in OSD mode
3) to make sure the Text Restart command is handled properly (I have not encountered this command in a captioning stream)
4) to fix the OSD bug that occurs when a preamble code specifies a different row in roll-up mode
5) to handle the Delete to End of Row command

[TheWickedPriest]

1) to complete my partial Latin-1 font that I produced by rearranging the existing MS-DOS codepage 437 font

I might be able to help there. What format is the font?

2) to make flashing text produce some kind of visual feedback in OSD mode

How about a different color?

[dgi]

I might be able to help there. What format is the font?

The original font.h file was identical to the font.h in newtext2osd. It is a bitmap in the form of an array of bytes where each character is represented on a grid of 16x26 bits. I don't know whether interlacing is taken into account.

How about a different color?

I already use seven colors to represent color captions. Flashing is an attribute on top of color, e.g. text may be yellow and blinking.

[d7o]

I did a quick test of the yac port and the libosd examples.

When I ran yac, the screen looked garbled like it was displaying a random buffer (with random alpha channels, you could sort of make out the background).

When I ran the examples, they appeared to start out with the same random buffer and then they drew their respective texts/graphics. If I then ran yac again, I would see the exact same screen as it was after running the libosd example.

It would appear that the overlay buffer is never being reset. It starts out as a random buffer. After writes occur, those areas look clean but the rest of the screen still shows the random buffer. Subsequent execution of the utilities don't appear to reset the overlay buffer.

Is it a bug or is it just something weird with my machine (hdvr2)?

d7o

[erhan]

I think it's a bug. I've played with elseed and compiled several variations and it seems like the OSD is not initialized until the first time it is actually used. So, on startup it just displays some garbled stuff. As soon as a call comes in, the screen clears.

I also tried a ClearOSD() call as soon as elseed starts and that also seemed to do the trick.

EDIT: Forgot to mention, this happens only when you start yac/elseed the first time after a reboot. Once the OSD is "cleared", subsequent restarts are fine.

Erhan

[JohnSorTivo]

Interesting. I encountered the same issue. After attempting to start the YAC listener upon startup my screen would freeze with a bunch of snow / garble, never to recover, and after some testing, I realized that as long as something was first written to the screen, then YAC launched, it would start up without a problem.

As such, to work around this, I modified my rc.sysinit.author file by adding the following at the very end:

#Start YAC Caller ID listener
/var/hack/osd/newtext2osd -s 5 -t "Launching YAC Listener"
sleep 5
/var/hack/osd/yac -t 10 &

This way, by simply first writing to the screen that I am launching YAC, and then launching it, it prevents the problem referenced above.

[erhan]

FWIW, here is an elseed binary compiled with a "elseed starting.." message to eliminate that issue. It also has a couple of additions of my own, for example formatting the log file better and additional debugging. Nothing too different from the original.