OSD bugging me....

[Plamen Ganev <pganev@com-it.net>]

Hi!

I'm currently working on extending the menu handling of VDR, however I see a
rather nasty problem with OSD that I think is related to the driver.... I
think we all need Ralph's help.

The problem is this: A big OSD windows (as seen in the VDR main menu) seems
to cause trouble in the firmware after a series of show/hide operations as
when someone is playing with the channels/menues in VDR.

The effect is that the menu will stop appearing on the screen. The OSD_Open
call fails silently as all the other operations (OSD_Text/Fill etc etc).
Only a driver reload will fix it... for a while. The weird thing is that if
I try to open a smaller menu (i.e. using less memory?) it will show up,
again for a few times.... then it will not show again. If I reduce the menu
size again it will show up again.... all this until I can only show a 1 line
high OSD window.

Someone else already reported this issue on the list, but it seems that only
few people are seeing it, so I tried to find the conditions when this
problem occurs:

1. First of all, if I tune to a random channel and open/close the big OSD
window (the VDR menu) for 100 times or more, I will never get the problem.
2. To get the problem, I have to open the big OSD window immediately *after*
a channel switch which required a new frequency to be tuned (an APID/VPID
change will not do it, you need a freq. change). After a frequency switch,
there's about 20% chance  for OSD not opening up. Sometimes it takes just a
couple of tries, sometimes you need 10 times on a row.
3. I tried to play a lot with the driver, disabling and enabling many
things, inserting debug stuff everywhere, but no luck. The problem seemed to
occur only after a freq. change (yes I tried to disable the SetDiseqC call
in the driver too).

So, the basic facts are:

1. A small OSD windows will always open, when a big one will not.
2. As time goes (and freq. switches), the maximum size of the OSD seems to
shrink.

So my guess is: The firmware is consuming memory (memory leak, heap
fragmentation ???) so that as time goes it finds it harder to allocate
enough memory for the window.

One more thing I did: I tried opening a big OSD window (i.e. almost the size
of the entire screen) with freshly loaded drivers... and guess what? I hit
the problem immediately and I could not open this window. So... is there a
maximum OSD window that can be opened and are big windows causing trouble
with memory (i.e. how's memory allocated? malloc in armlib?)...

I see that Ralph has done some fixups in OSD in the firmware between version
0.05 and 0.06 of the driver. Version 0.05 firmware will either hang
(outcommand error 1) or have noise on screen (as Klaus, the author of VDR
pointed in the past). Version 0.06 of the firmware/driver will not have
outcommand errors, but it will not show OSD.

BTW: I was thinking that there could be hardware issues, so this is the PC
I'm trying to use for VDR:

Pentium 100, VX chipset (or was it HX?.
84 Mb RAM
FireGL 1000 8Mb ram
IDE Quantum hard disk (plenty of space)
The PCI bus latency is set to 32 and the IRQ from the DVB card is not shared
with any other device.

Linux kernel 2.2.14-5 stock redhat 6.2 distribution

I can debug more if needed (Ralph? Is it possible to get sources for the
firmware so I can help? I did a lot of ARM7 programming in the past for
embedded systems, and still have access to VLSI JumpStart and Arm SDK).

Regards,
Plamen.