Ubuntu backlight control

[bobsammers]

Slight delay, but I've finally got around to testing the Kubuntu distro on a flash stick and the xset dpms force off command.

It does seem to be the case that X11 has some way of turning the screen off completely that is not achieved by the console screen blanking controlled by setterm (certainly using the setterm commands I've tried). I tried both (whilst hiding under a dressing gown for the full "darkened room" effect) and the screen went truly black with the xset command but does not with the console blanking.

If I can find some time soon, I'm intending to have a look through the X server source to see how the DPMSForceLevel opcode is processed but this is virgin territory for me, so any pointers would be more than welcome.

[Juggler]

Delay here too Bob...

I had BuZz'z XUbuntu distro running, and after boot the screen goes completely off, as far as I can tell. So X has the ability to do it.

I dug a bit deeper into vbetool, and it depends on using old Intel real mode instructions (this is the X86 library bit, I think). Don't know yet why were getting the error message we both have. In the XUbuntu distro I tried vbetool as well, as it appears to be installed on there, but get the same error.

Fundamentally, as I see it, there is some sort of interface that the screen or some power management system presents, and it should be just a matter of sending that the right commands. I started to dig in this area, but didn't get very far.

I would like to thank Wilberforce, as I have implemented your setterm solution on my Jogglers and it is much better than what I previously had.

Slight delay, but I've finally got around to testing the Kubuntu distro on a flash stick and the xset dpms force off command.

It does seem to be the case that X11 has some way of turning the screen off completely that is not achieved by the console screen blanking controlled by setterm (certainly using the setterm commands I've tried). I tried both (whilst hiding under a dressing gown for the full "darkened room" effect) and the screen went truly black with the xset command but does not with the console blanking.

If I can find some time soon, I'm intending to have a look through the X server source to see how the DPMSForceLevel opcode is processed but this is virgin territory for me, so any pointers would be more than welcome.

[bobsammers]

Fundamentally, as I see it, there is some sort of interface that the screen or some power management system presents, and it should be just a matter of sending that the right commands. I started to dig in this area, but didn't get very far.

Presumably the power management interface should be ACPI. It does seem that the ACPI system is not running completely: I get an error message during boot, "no DMI BIOS year, acpi=force is required to enable ACPI". BuZz seems to have thought of this though because acpi=force is indeed present in the kernel command line.

However, I'm led to believe that ACPI should put a number of entries in /proc/acpi, including one for ../video, but I only see a single file in there (events, which I cannot read from) and the firmware test suite (fwts) throws up a number of errors related to zero-length ACPI tables (including the DSDT, which seems to be the most fundamental of the tables ACPI uses). Also, there should be an entry in dmesg for the video hardware ACPI has detected, which is not there.

I can only assume that the Ubuntu ACPI implementation has some difficulty with the hardware or firmware in the Joggler. I'll check to see if Xubuntu distro behaves the same. But perhaps it's not ACPI at all that we need (or that X is using).

[Juggler]

On the *buntu distros I've used on the joggler they all seem to come up with an ACPI issue at startup, which is what you have hightlighted, I think.

I'm kicking myself now as I go and do a lot of research on this and then don't update this thread, so I apologise if the following is a little vague or incorrect, as it was a few days ago and all I have is the URL's

The Ubuntu kernel link you gave was very useful.

When I looked at the power management systems, I began to wonder if the Joggler just did not have anything like this. I have a copy of the VESA standard for turning the screen off or putting it into standby, and compared to the VESA documents for controlling other aspects of the screen, it is a bit sparse. The wiki article about VESA display controllers states that there is x86 real mode code in the (v)BIOS that is executed in order to control the display. Whether this is the case or not, I'm not sure. It may explain why vbetool has to use LRMI in order to do what it has to do, or try at least ! From what I have seen, to use a video BIOS routine, you put the parameters into the appropriate registers and then generate an interrupt to execute the required routine in the video BIOS.

So I wondered, if the problem was that the Joggler didn't have some ?standard? vBIOS or display controller interface. From the link you gave it mentioned using lspci. Doing this, states that the joggler has a VGA controller, which I can only presume is some sort of standard recognised by Ubuntu.

Following wilberforce's contribution, I've looked at potentially using setterm to do what we want. Now it may be possible to issue escape codes using setterm to turn the screen off, but I haven't found anything to this end yet. This would be the simplest way, as I see it.

We know X can do it. So is there a way to put X into some sort of logging/debug mode that will state what it has done ? My guess is for what we want - no. So, how feasible would it be to setup an environment where we could step through the X code when the xset command is issued ? I'm really cringing at this. I think there can only be so many ways that X can do what it needs to do to turn the screen off, and if these can be found, may be a bit of C can be written that would do the same, or at least try one of the ways that X can do it, until the one that works for the joggler is found.

I need to find the links I have and go over them, and report back. Just wanted to give an update, even if not very good.

J

Fundamentally, as I see it, there is some sort of interface that the screen or some power management system presents, and it should be just a matter of sending that the right commands. I started to dig in this area, but didn't get very far.

Presumably the power management interface should be ACPI. It does seem that the ACPI system is not running completely: I get an error message during boot, "no DMI BIOS year, acpi=force is required to enable ACPI". BuZz seems to have thought of this though because acpi=force is indeed present in the kernel command line.

However, I'm led to believe that ACPI should put a number of entries in /proc/acpi, including one for ../video, but I only see a single file in there (events, which I cannot read from) and the firmware test suite (fwts) throws up a number of errors related to zero-length ACPI tables (including the DSDT, which seems to be the most fundamental of the tables ACPI uses). Also, there should be an entry in dmesg for the video hardware ACPI has detected, which is not there.

I can only assume that the Ubuntu ACPI implementation has some difficulty with the hardware or firmware in the Joggler. I'll check to see if Xubuntu distro behaves the same. But perhaps it's not ACPI at all that we need (or that X is using).

[Juggler]

These are the links from my last research :

https://wiki.ubuntu.com/Kernel/Debuggin ... interfaces
http://manpages.ubuntu.com/manpages/har ... ool.1.html
https://wiki.ubuntu.com/Kernel/Referenc ... cksAndTips
http://gma500booster.blogspot.co.uk/201 ... -lets.html
http://forum.tinycorelinux.net/index.php?topic=14084.0
http://www.jogglerwiki.com/wiki/Using_t ... DVI_screen
http://wuffcode.wolfpuppy.org.uk/2012/0 ... ectly.html
ftp://ftp.cis.nctu.edu.tw/pub/csie/Soft ... /DPMrA.pdf
http://www.x.org/releases/X11R7.6/doc/l ... mslib.html
http://www.x.org/releases/X11R7.7/doc/x ... /dpms.html
http://www.vesa.org/vesa-standards/standards-summaries/
http://pdos.csail.mit.edu/6.828/2012/re ... e/vbe3.pdf
http://forum.osdev.org/viewtopic.php?t=11166&p=75411
http://www.ctyme.com/intr/rb-0273.htm
http://www.ctyme.com/intr/rb-0274.htm
http://manpages.ubuntu.com/manpages/har ... did.1.html
http://www.polypux.org/projects/read-edid/
https://en.wikipedia.org/wiki/Extended_ ... ation_data
http://www.phatcode.net/res/221/files/vbe20.pdf
http://jogglerhacks.blogspot.co.uk/2010 ... fi-on.html
http://hackthejoggler.freeforums.org/re ... g-t20.html
https://en.wikipedia.org/wiki/VESA_BIOS_Extensions
https://en.wikipedia.org/wiki/VESA_Disp ... _Signaling
http://forum.linhes.org/viewtopic.php?f=5&t=7920
https://wiki.archlinux.org/index.php/Di ... _Signaling
http://linux.die.net/man/1/vbetool

[bobsammers]

I'm kicking myself now as I go and do a lot of research on this and then don't update this thread, so I apologise if the following is a little vague or incorrect, as it was a few days ago and all I have is the URL's

I've been doing this too - don't get a lot of time at the moment for fiddling around and it's compounded by my other half using the Squeezeboxes frequently (powered by the Joggler).

I'm still intending to go through the xorg source and see if it is obvious what's going on. We may even be able to lift some code from there wholesale and compile it into a simple standalone util. From what I could make out from the xset source, it would appear that the numeric opcodes used to route messages between the client and server (of which "DPMSForceLevel" is the one we're probably interested in) are assigned dynamically, at least in the case of plugins (which is the category that xset comes under).

I'll see if I can find some time in the next few days. I might also see if there is a friendly xorg forum where a question on this might receive some knowledgeable answers.

[bobsammers]

I've learned from looking at x.org source and some of the better-hidden documentation that the video driver is expected to implement a function called ChipDPMSSet() and also to call an x.org api function itself to register DPMS compatibility: xf86DPMSInit(). There's a passage on this in the x.org ddxdesign.txt document (look under "DPMS Extension").

It seems (at least sometimes) that in this sense "driver" means a part of the x.org implementation that talks to the hardware directly (i.e. bypassing any external driver) because several modules in the hw subfolder of the x.org source appear to do direct interfacing for various hardware types, including implementing DPMSSet() functions.

However, this might be to support older systems. I found an excellent PDF on the Linux graphics subsystem which suggests that the current X server resides entirely in user mode while a separate, dedicated kernel mode layer called the DRM (Direct Rendering Manager) abstracts the hardware across all the traditional access types, providing user mode access. Several .ko files in the /lib/modules/3.2.32joggler1/kernel/drivers/gpu/drm suggest this system is implemented on the distro we're using.

The doc above makes the point that the framebuffer is the simplest form of Linux graphics driver and helpfully, the x.org source provides fbdevhw.c which defines a ioctl() call named fbdevHWDPMSSet(), making clear the necessary parameters:

Code: Select all

ioctl(fPtr->fd, FBIOBLANK, (void *) fbmode)

fbmode must be 4 for DPMS off
FBIOBLANK is defined as 0x4611
fPtr points to a struct named fbdevHWRec which appears to be accessed via /dev/fb* (unsurprisingly, there is only /dev/fb0 on the Joggler):

Code: Select all

typedef struct {
    /* framebuffer device: filename (/dev/fb*), handle, more */
    char *device;
    int fd;
    void *fbmem;
    unsigned int fbmem_len;
    unsigned int fboff;
    char *mmio;
    unsigned int mmio_len;

    /* current hardware state */
    struct fb_fix_screeninfo fix;
    struct fb_var_screeninfo var;

    /* saved video mode */
    struct fb_var_screeninfo saved_var;

    /* buildin video mode */
    DisplayModeRec buildin;

} fbdevHWRec, *fbdevHWPtr;

Since the DRM should provide a framebuffer-style access point (and seems to in the shape of /dev/fb0), we might be able to access the GPU via a framebuffer interface. We need to fill the fbdevHWRec struct from /dev/fb0 and then issue an ioctl() call using it and the other info. I don't (yet) know how to do it, but it seems fairly straightforward. If it works, of course...

[bobsammers]

Based on a StackOverflow Question, I tried the following code:

Code: Select all

    #include <sys/types.h>
    #include <sys/ioctl.h>

    #include <linux/fb.h>

    #include <unistd.h>
    #include <fcntl.h>

    #include <stdio.h>
    #include <errno.h>

    int main()
    {
       int fd = -1;
       int r = 1;

       fd = open("/dev/fb0", O_RDWR);
       if (fd >= 0)
       {
          if (!ioctl(fd, FBIOBLANK, (void *) 4))
          {
            perror("Sucess!");
          }
          else
          {
            perror("ioctl");
            printf("errno:\t%d\n", errno);
          }
       }
       else
       {
          perror("open");
       }

       /*
        * Clean up
        */
       if (fd >= 0)
          close(fd);

       return r;
    }

Unfortunately, it doesn't work - ioctl() returns -1 (failure) with errno 22, which apparently means "Invalid argument". I've tried several different values (and casts) for the numeric parameter with no change. Is it possible the framebuffer implementation doesn't support FBIOBLANK? I'm not really sure how to investigate this further: I've looked at the various requests to the framebuffer for config / static info, but I can't see anything relating to DPMS.

[marctwo]

Did anyone ever figure out how to get the backlight to switch off? I am running the Ubuntu Desktop 12.04 LTS image on my Joggler and have the same issue.

[bobsammers]

No, at least I haven't. It is my intention to find out more about the DRM interface(s) (if you look in the PDF I referenced a couple of posts back, you'll see, if you didn't already know, that the Direct Rendering Manager provides graphics hardware abstraction across all the traditional disparate interfaces to user mode applications).

I'm assuming that if we know the correct API (you'll have spotted that I tried and failed with the Framebuffer interface) and how to use it, a pretty simple program should do what we need. It must be possible, because unless something weird is going on, X.Org interfaces with the DRM and we know that works.

I haven't had time yet, though, and I'm not going to in the next few weeks, I doubt. I also thought about posting to an X.Org mailing list / forum to see if anyone there could help us. If you get time to look at doing either, please don't hesitate!

[marctwo]

I just switched to Xubuntu and it works fine now.