Series2 OSD

[dgi]

I put in the parity code because there is no way to be truly faithful to the CC protocol without it. Can you please go back and check where to get the parity bit on a S2? TIA (Makes me wish I had a S2 just for testing.)

[alldeadhomiez]

I have patched the modified tivovbi sources previously found in post #24 for compatibility with the Series2 OSD hardware, and attached the new version to this post.

This was a quick hack so I used my original "0x403" patch. As a result, this code does not support the improvements/refinements posted in this thread. At some point this code should probably be patched to use libosd instead.

To test: insmod pxmpegdecode.o ; ./tivovbi.mips -t -o -x -c1
Building/debugging: make ARCH=mips ; insmod pxmpegdecode.o debug=1 ; ...

The PPC binary is untested.

Edit 2005/02/02: s2vbi and tivovbi development has moved to this thread

[dgi]

Correction: in testing, you can't use -t with -o or -x with -c1! But you knew that. I have updated the zipfile to the current sources, and put dah31's ancillary files back in. I have disabled stripping in the makefile for now. Incidentally, my powerpc-TiVo-linux-gcc doesn't like the makefile, so I manually recompiled with /var/tivo/bin/gcc. The mips binary is unchanged because my cross-compile setup isn't working (I use the tivo native compiler). Recompile and repost. TIA

Edit: Here is the current version for mips and ppc. The mips binary is untested, but should work.

[dgi]

I took a quick skim over bcmosd.c, and the colors[] array leaped out at me. These are not S1-compatible colors! For one thing, red1 should be blue, and red2 should be olive. The different transparent settings should have differing alpha values. The different whites should have differing brightnesses. And what happens when my code tries to use magenta? Probably a segfault. Maybe you can find the S1 palette in tivoapp?

[alldeadhomiez]

Originally Posted by dgi

Correction: in testing, you can't use -t with -o or -x with -c1!

Why not?

Originally Posted by dgi

I took a quick skim over bcmosd.c, and the colors[] array leaped out at me. These are not S1-compatible colors! For one thing, red1 should be blue, and red2 should be olive. The different transparent settings should have differing alpha values. The different whites should have differing brightnesses. And what happens when my code tries to use magenta? Probably a segfault. Maybe you can find the S1 palette in tivoapp?

Doubt it will segfault unless the bounds check is wrong. (is it?)

My S1 is in pieces on the floor so I can't check the palette. When you get it all sorted out, post a diff.

[dah31]

Originally Posted by alldeadhomiez

My S1 is in pieces on the floor so I can't check the palette. When you get it all sorted out, post a diff.

Here's a dump of the TiVo Central and Live TV palettes from my DSR6000 running 3.1.0b . You know the drill---not a ZIP archive and all that.

Herewith the README:

-----
decode-palette-output is based on the CT_OSD_LIVETV_256[] array is
libosd.h from the jpegwriter-1.1 distribution.

results is based on kernel.log, which came from me pressing the TiVo
button from Live TV, and a minute or so later pressing the Live TV
button from TiVo Central with s1-palette-snoop.o insmodded.

decode-palette is the piece of Perl I used to convert the YUV values
the Series1 colour table uses into RGB values for Series2. The colour
table to YUV extraction code comes from build_color_table_entry() in
osd.c from the jpegwriter-1.1 distribution; the YUV->RGB coefficients
are from
<URL:http://groups.google.com/groups?q=yu....mv.net&rnum=3>.

tivo-palettes is my reckoning of the Series1 colours, taken last
October (the concert mentioned was on television at the time :-) .
-----

--
dah31

[edskee]

Is there a way to change the display font using the newtext2osd with the libosd support? I see it uses the freetype library... but how can I change the font? When using elseed with it, the number is ALWAYS chopped off the edge of the screen, I want to use a smaller font...

[edskee]

Ok, found a bug in elseed.c - There are 2 :'s next to each other in the options reading code in elseed.c, right after the 'F' for picking a font, making choosing a font unusable (always reads it as (null))

Anyway, that being said, using libosd, how do you define the size of the background around the text? Using the default font I have a nice sized box around the text, using Lucida Console (so I can resize it and make it fit my screen) the background is cropped VERY close to the edges of the actual text.

Is there a way to configure that?

[dah31]

Originally Posted by edskee

Ok, found a bug in elseed.c - There are 2 :'s next to each other in the options reading code in elseed.c, right after the 'F' for picking a font, making choosing a font unusable (always reads it as (null))

Double colon in a getopt string is supposed to mean the argument is optional. At least one of `-Ffontname', `-F fontname', or `-F=fontname' should work.

Originally Posted by edskee

Anyway, that being said, using libosd, how do you define the size of the background around the text? Using the default font I have a nice sized box around the text, using Lucida Console (so I can resize it and make it fit my screen) the background is cropped VERY close to the edges of the actual text.

Is there a way to configure that?

After you call SetupTextOSD() and osd_setupaspect(), you can poke at osd->pad.legibility_pad_top and _bottom (which are set to 1 in osd_setupaspect()). (_left and _right are set to the lesser of {half the font's nominal width} and 8.) examples/example1.c is probably the most convenient place to play around with those.

As for the bigger problem of making sure everything fits on the screen, I've implemented a configuration system for libosd. You put something like

safe-title-left 55
safe-title-top 22
safe-title-right 35
safe-title-bottom 25
safe-action-left 50
safe-action-top 13
safe-action-right 26
safe-action-bottom 16

in /etc/osd.conf . You get the numbers by experimentation with examples/safetitle ; safe-title is the largest rectangle that is completely visible, and safe-action is the smallest rectangle that completely surrounds the screen. (Anything rendered into the safe-title area is then guaranteed to be visible, while you can completely cover the screen by covering the safe-action area.)

Now, I had to make some last-minute changes to the code, so this code isn't completely tested yet....

--
dah31

[dah31]

If you've found that the configuration in /etc/osd.conf doesn't have any effect, it's probably because you're using the built-in bitmap font. The code that renders text with that font doesn't (currently) heed those settings: I'll see about changing that.

Meanwhile, you can use the FreeType option, which does recognise the settings in /etc/osd.conf . (Set the environment variable FONT_PATH to a colon-separated list of directories containing TrueType fonts, and give the -F[fontname] option to elseed.)

--
dah31

[Cheezmo]

When I do that, the phone number draws a little lower than the name. (With a funny little black "dash" over the first number that would line up with where the top of the name would be. Is one using safe action and the other using safe title for the top or something?

Originally Posted by dah31

If you've found that the configuration in /etc/osd.conf doesn't have any effect, it's probably because you're using the built-in bitmap font. The code that renders text with that font doesn't (currently) heed those settings: I'll see about changing that.

Meanwhile, you can use the FreeType option, which does recognise the settings in /etc/osd.conf . (Set the environment variable FONT_PATH to a colon-separated list of directories containing TrueType fonts, and give the -F[fontname] option to elseed.)

--
dah31

[Juppers]

Been playing with this stuff yesterday and today. Works great on my HDVR2 and DSR7000 running 4.x, but doesn't work on my SD-H400 running 5.1.1b. It gives the error "Couldn't find or create shared front buffer" for newtext2osd and yac. Is this particular to this hardware or is it something with 5.x software? Anyone tried it on a Pioneer running 5.2?

[dah31]

Originally Posted by Juppers

Been playing with this stuff yesterday and today. Works great on my HDVR2 and DSR7000 running 4.x, but doesn't work on my SD-H400 running 5.1.1b. It gives the error "Couldn't find or create shared front buffer" for newtext2osd and yac. Is this particular to this hardware or is it something with 5.x software? Anyone tried it on a Pioneer running 5.2?

It appears something's changed between 4.0 and 5.1.1b, probably either this hardware or the 5.x software. 3-)

It could be something as simple as a different magic number or a new ioctl to call. (I have a possibly related issue on 4.0.1b on my shiny new refurbished TCD240040: I can't seem to create my own surface and have to settle for a shared one. (The easiest way to see this is to look for the `ghost image' in example1 .) That means everything I draw interferes with the menus and so on, and vice versa. (And verce visa.))

I'll have to have a look at osdwriter from 5.x to figure that one out. It might take a while to figure out, though, unless anyone wants to give me a 5.x machine.... ;-)

--
dah31

[alldeadhomiez]

Originally Posted by dah31

It could be something as simple as a different magic number or a new ioctl to call. (I have a possibly related issue on 4.0.1b on my shiny new refurbished TCD240040: I can't seem to create my own surface and have to settle for a shared one. (The easiest way to see this is to look for the `ghost image' in example1 .) That means everything I draw interferes with the menus and so on, and vice versa. (And verce visa.))

I ran into the same problem with tivovbi on a SA at 4.0, which I thought was odd because it didn't happen on a DTiVo at 4.0. I was forced to use the DEFAULT_SHAREDSURFACE instead of (DEFAULT_SHAREDSURFACE + 1) for the on-screen captions (VBI_SURFACE) in bcmosd.c.

[dgi]

Originally Posted by alldeadhomiez

I ran into the same problem with tivovbi on a SA at 4.0, which I thought was odd because it didn't happen on a DTiVo at 4.0. I was forced to use the DEFAULT_SHAREDSURFACE instead of (DEFAULT_SHAREDSURFACE + 1) for the on-screen captions (VBI_SURFACE) in bcmosd.c.

I am almost ready to post another snapshot release of tivovbi. Quite a few bugs have been fixed in the protocol. I will replace the attachment to post #33. Can you send me a diff of the current bcmosd.c in preparation? TIA