Re: OSD bugging me....

[MK <amk@befree.ch>]

Hi,

I can confirm having the very same problems with OSD.
Less than a dozen or so manipulations of full screen OSD (like loading 
"menu" and then "channels" then changing channel) will silently kill it: 
the card stops responding.
Zapping with the "up" and "down" arrows doesn't kill the driver as often.
The usual cure works for me: unload vdr, full unload and reload of the 
drivers, reload vdr.
Nothing in /var/log/messages.

The driver also endures a different kind of death when trying to set it to 
some specific frequencies: Astra 19E / 12670 V 22000 289 290   for example..

system: Asus K7M, Athlon 600, 128 MB Ram
Mandrake kernel 2.2.17 recompiled, latest i2c and lirc drivers.

MK


At 15:35 30.08.00 +0200, Plamen Ganev wrote:
>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.