No announcement yet.

Emulate display backlight control

  • Filter
  • Time
  • Show
Clear All
new posts

  • Emulate display backlight control

    I have a small Intel Atom based device - basically just a touch-screen with a minimal motherboard (one of these).

    I've replaced the stock firmware with a GUI-less Ubuntu distribution (based on 12.04). There is limited psuedo-file based backlight control available, but when the backlight is set to 'off', there is still a faint glow from the screen. The same happens using
    setterm -powersave powerdown -blank 1 -powerdown 1
    However, if X.Org is installed and running, and
    xset dpms force off
    is issued at the command line, the backlight is extinguished completely.

    Can anyone tell me what X.Org is likely to be doing?

    I've been through the xset source and I can see it's sending a message to the X server (DPMSFoceLevel() uses the GetReq() macro to create a message), but I got lost after that.

    I've also tried to write directly to the framebuffer with an ioctl call in C, but I'm getting an "Invalid Argument" returned from the ioctl call. I don't know whether I'm using it wrong or something at the other end isn't implemented.

    I'm trying to avoid having to run a X11 server just to switch the screen off, but I'm struggling to understand how X.Org is communicating with the screen hardware. For anyone who might be able to help, progress so far is detailed on this forum thread, including the code with which I attempted to interface with the Framebuffer.

    I'd be very grateful if anyone could provide any hints as to how I might be able to proceed.

  • #2
    That's a Poulsbo chip... Are you using Intel's blob driver?

    Because if your hw had open drivers, you chould just look up what your driver source does when told "DPMS off, please" by xset.


    • #3
      I would assume that the Intel driver is in use (as far as I can make out, lsmod should list gma500_gfx for the OSS driver). Can I change this (Linux drivers are not my area of expertise!)?

      Isn't this one step too far up the chain though? I don't want to see what the driver tells the hardware, I want to see what X11 tells the driver (as far as I can make out, xset tells the X server to do something, rather than the driver directly).


      • #4
        Well, you're not using Intel's blob, but the open reverse engineered driver. That's good, so you can actually trace what happens inside gma500.

        It seems to support your fbdev ioctl. You can get the same effect via sysfs, the file can be found via "find /sys -name blank" - echo 4 to that file as root. Anyway you're on the right path, now just debug why you are getting an error.


        • #5
          Sorry, I misread your post. With the Intel blob, you're out of luck. Move to the open driver, the blob doesn't support your call.

          As for how, ask in Ubuntu forums.


          • #6
            Thanks for your help. I'll have a look at doing that.

            If anyone else happens to have any insight into how the X server manages these things, please let me know!