This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

My video output goes blank after 10 minutes and nothing can be displayed any more until EVM is re-booted

 

Framebuffer driver now (DVSDK 1.30) implements the fb_blank method to disable/enable windows, you may see a window get blanked unexpectedly if your kernel includes the framebuffer console driver or if you are running a GUI (like X Windows) on top of a framebuffer.  The fb_blank method is commonly used to implement a 'screen saver' function.The default behavior of the kernel framebuffer console driver is to blank the screen after 10 minutes of inactivity.  Inactivity is defined as no input from the keyboard or mouse.  The astute observer will notice that the DaVinci normally has neither a keyboard nor a mouse connected to it, so 10 minutes of inactivity is typically equivalent to 10 minutes after you boot the kernel.  At this point the kernel framebuffer console driver will blank virtual console 0, which corresponds to OSD0 on the DaVinci.  If you booted with the default window configuration, you will be left staring at whatever image happens to be in the VID1 framebuffer and wondering where your OSD0 window went.There are a couple of things you can do to avoid unexpected screen blanking.

 

First, you can disable framebuffer console support in the kernel by building a kernel with the CONFIG_FRAMEBUFFER_CONSOLE option disabled.  It is highly unlikely you would ever actually want to use a framebuffer console with a DaVinci anyway.

 

If you don't want to disable the framebuffer console, you can disable blanking via the setterm application as follows:             setterm -blank 0 > /dev/vc/0

 

  • What are the dependencies of setterm?  I can run the command w/o a problem on a target that uses NFS, but as soon as I try to migrate from that to a ramdisk, the setterm command returns an error:

    'linux': unknown terminal type.

    I can't turn off framebuffer console support because then I lose my kernel splash screen.  Is there another way to have a kernel splash screen w/o using the framebuffer console?  If not, then I'll have to go the route of discovering what exactly is going wrong with the setterm command. 

     

  • have you checked to see if "/dev/vc/0 " is present on your ramdisk.

  • Yes, it's there.

  • additionally, it doens't even matter which option i choose, or where I try to redirect the output of seterm. Even trying 'setterm -initialize' gives the same error.

  • Nothing else to offer on this front?

  • Juan,

    This issue is really starting to become quite annoying for our product.  We can't update the entire system without the screen going blank after 5 minutes.  I CAN NOT run setterm on the ramdisk and have no clue what's going wrong.  Running the 'env' command I see that the TERM variable is set to 'linux'

    # env
    USER=root
    HOME=/root
    PS1=#
    LOGNAME=root
    TERM=linux
    PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/local/sbin:/usr/sbin:/sbin
    SHELL=/bin/sh
    PWD=/root
    # setterm -blank 0
    'linux': unknown terminal type.

    I can't stop the display from blanking without this command?  I set the blanking interval to 0 in vt.c but that doesn't stop the display from going blank.  Looking at the RGB signals, they all go high after 5 minutes and the display just shows a black screen.  I really find it hard to believe that I'm the only one having this problem trying to run setterm from a non-nfs mounted system.

    I also tried to run the command:   echo -n -e "\\033[9;0]" >/dev/vc/0   which I saw in a post related to this problem on the davinci- develoers mailing list but that did nothing either.

    BJ


  • BJ,

    The fact that you cannot run setterm from ramdisk you are using tells me that perhaps the ramdisk file system is missing the necessary components to do this.  You can always add support for setterm to file-system, but my understanding is that this can be quite complex unless you are using a tool such as DevRocket to help you resolve all dependencies.

    That said, the issue you are seeing is likely due to the screen saver feature kicking in; if you were to connect a mouse or keyboard via USB-HID interface (so that you can move it when screen goes blank), this could be a potential work-around.  Otherwise, we may need to dig deeper in adding setterm support or perhaps modifying drivers to disable screen saver feature.

  • I tried connecting a usb keyboard and mouse to the board to counteract the problem.  It doesn't bring the screen back from the dead.

    Modifying the drivers to disable the screen saver feature is exactly what i'd like to do, but I've been rummaging through the kernel for a coulpe of days now and can't find where the call to blank the screen is even happening.  I went so far as to put printk statements in every function of davincifb.c, vt.c, and fbcon.c to see what was gettign called when the blanking happened...none of those functions are the culprit.

     

  • Hi,

    I have a same problem with you. I have enabled framebuffer console support to get splash screen but it changes osd0 usage unexpectedly.  How did you solve the problem?

    Thanks and best regards,

    Ferhat

  • It was an issue with the screen saver turning on because there was no 
    console activity. I was using the 2.6.10 montavista kernel and changed
    the 'blankinterval' variable to 0 (static int blankinterval = 0*60*HZ).
    This was in drivers/char/vt.c.

    Hope this helps,
    -b
  • Thank you for the suggestion. I could disable the screen saver property. 

    I could also able to put a splash screen by changing the .PPM logo in /drivers/video/logo.  However, for my 480x272 LCD there remains a 8x8 blue background image on upper-left corner. It appears with the splash screen and remains thorough my application using osd0 layer.

    How could I remove this 8x8 background image shown on my left-upper corner?

    Thanks again and best regards.

    Ferhat

  • Hi,BJ,

    why dont you try with dump_stack to see where does the problem come form ?

    i had tried to put it at _davinci_disp_disable_layer and see:

    [<c008c5f4>] (dump_backtrace+0x0/0x114) from [<c039db50>] (dump_stack+0x18/0x1c)  
     r7:c2001000 r6:00000000 r5:00000000 r4:00000000  
    [<c039db38>] (dump_stack+0x0/0x1c) from [<c02bbb9c>] (_davinci_disp_disable_layer+0x14/0x98)  
    [<c02bbb88>] (_davinci_disp_disable_layer+0x0/0x98) from [<c02bc360>] (davinci_disp_disable_layer+0x60/0x90)  
     r5:00000000 r4:20000013  
    [<c02bc300>] (davinci_disp_disable_layer+0x0/0x90) from [<c0217690>] (davincifb_blank+0x70/0x78)  
     r7:c2001000 r6:00000001 r5:c2083400 r4:00000000  
    [<c0217620>] (davincifb_blank+0x0/0x78) from [<c020641c>] (fb_blank+0x44/0x70)  
     r5:c2083400 r4:c2083400  
    [<c02063d8>] (fb_blank+0x0/0x70) from [<c020d62c>] (fbcon_blank+0xf4/0x204)  
     r5:c2083400 r4:c04f27d4  
    [<c020d538>] (fbcon_blank+0x0/0x204) from [<c022ea0c>] (do_blank_screen+0x1c0/0x268)  
    [<c022e84c>] (do_blank_screen+0x0/0x268) from [<c022f878>] (console_callback+0xec/0x11c)  
     r7:c04bcccc r6:c20003a0 r5:c04f27d4 r4:c04f27d4  
    [<c022f78c>] (console_callback+0x0/0x11c) from [<c00aff88>] (worker_thread+0x138/0x1f8)  
     r7:c2034000 r6:c20003a0 r5:c04bcd00 r4:c04bcd04  
    [<c00afe50>] (worker_thread+0x0/0x1f8) from [<c00b3a8c>] (kthread+0x88/0x90)  
    [<c00b3a04>] (kthread+0x0/0x90) from [<c00a0d88>] (do_exit+0x0/0x668)  
     r7:00000000 r6:00000000 r5:00000000 r4:00000000