3

We have a use for a lot of Pis powering a monitoring wall where we have a whole lot of dashboards that we are monitoring.

This setup requires that our monitors invert their colours every 30 minutes or so, so that we minimise the burn-in on these monitors.

xcalib -d :0 -s0 -i -a works perfectly on a normal 32/64bit Linux machine, but even though there is an armhf port of xcalib, it doesn't seem to be doing anything on the Pis.

What could the problem be? Where do I need to start troubleshooting?

EDIT: According to the readme of xcalib: xcalib README

This program is intended for X11-Servers like XFree86 that come with XVidModeExtension

Tested, Raspbian Wheezy has this extension.

If you are experiencing problems with the X.org server because of missing XVidMode header files, search for the additional packages that are available for most distributions. Debian provides the headers by the package libxxf86vm-dev package.

Tested, those packages are installed.

I've tried manually loading an ICC profile using xcalib, even messing with the gammas, and xcalib just doesn't seem to do anything.

Any other ideas?

Improve this question
2
  • I would suspect that this is related to the Videocore firmware, which is closed-source. Try the command on a linux box configured with the generic framebuffer driver to see if it still works. You could also try the experimental accelerated driver: elinux.org/RPi_Xorg_rpi_Driver – M Noit Aug 28 '13 at 9:46
  • I'll try to setup that driver on a test Pi of ours, see what it does... the experimental part is a bit worrying – Tiny Aug 29 '13 at 8:56
1

I too experienced this issue and, unfortunately, I haven't been succesful in solving the problem.

Are your dashboards HTML/CSS based? Mine are, instead of invering the colors using the xcalib/driver settings, I simply wrote a bit of jQuery javascript to handle the color inverting for me in the browser.

This script inverts the colors for a duration of 10 seconds every half hour.

<script type="text/javascript">
    $(document).ready(function() {

        var myTs = new Date();
        if (myTs.getMinutes() > 30) {
            myTs.setHours( myTs.getHours() + 1 );
            myTs.setMinutes( 0 );
        } else {
            myTs.setHours( myTs.getHours() );
            myTs.setMinutes( 30 );
        }
        myTs.setSeconds( 0 );
        myTs.setMilliseconds( 0 );
        var milliSecondsToNextHalfHour = ( myTs.getTime() - new Date().getTime() );

        setTimeout(function() {
            //invert colors
            $("html").css("filter","invert(100%)");
            $("html").css("-webkit-filter","invert(100%)");
        }, milliSecondsToNextHalfHour - 10000);

        setTimeout(function() {
            //revert back to normal
            $("html").css("filter","invert(0%)");
            $("html").css("-webkit-filter","invert(0%)");
        }, milliSecondsToNextHalfHour);

    });
</script>
Improve this answer
1
  • This is a good enough answer and I can accept it. We ended up using something completely different to save the monitors, but this will work as well. – Tiny Mar 9 '15 at 9:00
2

A possible answer for other people if they want an alternative to the accepted answer:

https://stackoverflow.com/questions/4741657/javascript-for-preventing-burn-in-problem-on-lcd-screen

It's basically a piece of Javascript that "sweeps" the screen with a Red, Green and then Blue line (RGB). The theory is that the line will refresh every single pixel with one of the primary colours. It seems to work.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.