OSDev.org

Posted: **Mon Jan 11, 2016 4:43 am**

I have a little programme which doesn't need Windows (all those little pictures are so childish), doesn't need either Unix or Linux, and doesn't even need a file system. The data is simply copied to sectors on a USB stick, from which my tiny programme is booted. Four gigabytes of memory are available to it in flat real mode for data.

All this works well on older computers: if the screen is too bright I can simply press the appropriate function key to make it dimmer. No fuss, no drama, no difficulty.

But in the case of some recent computers there is one so far insuperable difficulty: it is impossible (so far) to reduce the glare; the intensity of the brightness is extreme and tropical. Great fuss, great drama, enormous and so far insuperable difficulty.

Consider, for instance, my Toshiba Satellite C850, purchased about a year ago. When running Windows on it the brightness can be adjusted satisfactorily. And also when running Slackware on it I can happily adjust the brightness using the following incantation:

echo 600 > /sys/class/backlight/intel_backlight/brightness

That is fine if one wishes to run Linux. (An alternative incantation I have seen is

setpci -s 00:02.0 F4.B=10

but that gives no response at all - no message, and no change in the brightness.) Also the BIOS on this Toshiba offers no way of disabling ACPI, if that matters.

So, here is my question: can some one please translate this:

/sys/class/backlight/intel_backlight/brightness

which is, for me, a jumble of alphanumeric symbols, into a simple, real sequence of port numbers and memory addresses? I say simple, because I believe it must be. Please bear in mind that my little programme uses no file system.

And many thanks in advance to any experts in this field who can come up with the answer. I've been programming since 1961 and it certainly looks like we are being taken backwards at present!

Posted: **Mon Jan 11, 2016 5:15 am**

You can start here:
http://lxr.free-electrons.com/source/dr ... v=3.2#L225

(really sadistic code: function "intel_panel_set_backlight" calls "intel_panel_actually_set_backlight" and there were 2 or 3 indirection levels before I've found this place)

Posted: **Mon Jan 11, 2016 5:51 am**

Hi,

sydgrew wrote:So, here is my question: can some one please translate this:

/sys/class/backlight/intel_backlight/brightness

You'd want to start by looking in "Appendix B: Video Extensions" in a recent version of the ACPI specs. It describes a "_BCM" method used to set the brightness for built-in displays.

Except for that; as far as I can tell there is no other standard, and the backlight control mechanism in one laptop can be completely different to backlight control mechanism in another laptop, even when both laptops use exactly the same video controller and exactly the same display panel.

Also note that recently there's been an "industry push" (in laptops and the ACPI specs) towards fully automated systems; where backlight brightness is determined from power management (e.g. battery vs. mains power) and ambient light sensor values. This is also described by ACPI specs (e.g. in the "9.2, Ambient Light Sensor Device" section).

Finally, for external displays none of this exists and you'd probably just use "less bright" colours (e.g. multiply each pixel's "R, G and B" with a scaling factor between 0.0 and 1.0); which is much simpler, and would also work on built-in displays (but wouldn't help battery life, which is the reason backlight control exists on laptops to begin with).

Cheers,

Brendan

Posted: **Mon Jan 11, 2016 7:07 am**

Many thanks to you both for those promising pointers. I will investigate further and post again if I get something working, or if (as is quite likely) further questions come up.

Posted: **Mon Jan 11, 2016 7:09 am**

Brendan wrote: Finally, for external displays none of this exists and you'd probably just use "less bright" colours (e.g. multiply each pixel's "R, G and B" with a scaling factor between 0.0 and 1.0); which is much simpler, and would also work on built-in displays (but wouldn't help battery life, which is the reason backlight control exists on laptops to begin with).

Except that cheap LCDs often only display 18-bit colour (262,144 colours). If you're reducing the brightness to say 10%, that leaves you with only 26,214 colours, which will produce noticeable "banding" in many images.

Despite what Brendan claims, there is in fact a standard way to control the brightness (and various other parameters) of external (and often internal) monitors from software; VESA MCCS. This is part of the DDC communication protocol (the same one that's used to get EDID data) and can be accessed via VESA VBE function 15h or a video card's "native" DDC access method. The relevant VCP (Virtual Control Panel) codes are 10h ("Luminance") and 13h ("Backlight control"). The standard seems to be reasonably well supported in hardware made in the last decade or so.

Posted: **Mon Jan 11, 2016 7:20 am**

Brendan wrote:you'd probably just use "less bright" colours (e.g. multiply each pixel's "R, G and B" with a scaling factor between 0.0 and 1.0); which is much simpler, and would also work on built-in displays (but wouldn't help battery life, which is the reason backlight control exists on laptops to begin with).

Or the gamma lookup tables, if you have access to that

Posted: **Mon Jan 11, 2016 9:01 am**

Hi,

mallard wrote:Despite what Brendan claims, there is in fact a standard way to control the brightness (and various other parameters) of external (and often internal) monitors from software; VESA MCCS. This is part of the DDC communication protocol (the same one that's used to get EDID data) and can be accessed via VESA VBE function 15h or a video card's "native" DDC access method. The relevant VCP (Virtual Control Panel) codes are 10h ("Luminance") and 13h ("Backlight control"). The standard seems to be reasonably well supported in hardware made in the last decade or so.

Except that:

For BIOS systems:
- the VBE function doesn't exist (or at least the only information I've seen is "VESA BIOS Extensions/Display Data Channel Standard" which only mentions EDID and nothing else, and no other VESA standard I've ever seen has described anything more)
- if it ever existed it would only work in "real mode" (including virtual8086 and emulation)
- if it ever existed, (based on all other VBE specs) it probably fails to handle multiple monitors and/or multiple video cards
- if it ever existed, it would have a high chance of being buggy (like all other rarely used BIOS functions)
For UEFI, it definitely doesn't exist (not even as a boot-time service)
There's no standard way to access it without firmware (different video cards are different)
If (due to miracles or perseverance/native video card drivers) you actually can use it; there's no guarantee the monitor bothers to support most/any of the commands to begin with.

Cheers,

Brendan

Posted: **Mon Jan 11, 2016 10:20 am**

Brendan wrote: Except that:
For BIOS systems:
the VBE function doesn't exist (or at least the only information I've seen is "VESA BIOS Extensions/Display Data Channel Standard" which only mentions EDID and nothing else, and no other VESA standard I've ever seen has described anything more)

VESA MCCS is entirely separate from VBE. It's part of the DDC protocol, which is available via VBE, but also via "native" card-specific mechanisms. VBE function 15h subfunctions 10h-16h (the VBE SCI standard, somewhat annoying to find information about due to SciTech's association with VBE and the resulting abbreviation conflict) provide direct access to DDC and can therefore access anything available via the protocol, not just EDID.

Brendan wrote: [*]if it ever existed it would only work in "real mode" (including virtual8086 and emulation)
[*]if it ever existed, (based on all other VBE specs) it probably fails to handle multiple monitors and/or multiple video cards
[*]if it ever existed, it would have a high chance of being buggy (like all other rarely used BIOS functions)[/list]

Yep, that's VBE... If you're using "native" drivers, they will provide a better way of accessing DDC for protected-mode operating systems.

Brendan wrote: [*]For UEFI, it definitely doesn't exist (not even as a boot-time service)
[*]There's no standard way to access it without firmware (different video cards are different)

VESA MCCS always exists, but on a UEFI system you can't access it without a native video driver (I'm not sure what firmware has to do with anything...). If you don't have a native driver by all means, fall back to hacky colour manipulation or just report that you can't change the screen's brightness from software (at which point the user will likely just use the adjustment built into the monitor).

Brendan wrote: [*]If (due to miracles or perseverance/native video card drivers) you actually can use it; there's no guarantee the monitor bothers to support most/any of the commands to begin with.[/list]

Sure, there's no guarantee that the monitor supports all the VCP codes. However, monitors are at least required to at least report the VCP codes they do support (via the GetSupportedControls request). As I said, most monitors made in the last decade or so do have the proper support. Looking at a few threads on forums related to Windows/Linux tools that adjust the brightness via this mechanism, I've seen very few reports of it not working due to hardware incompatibility and Googling for "DDC/CI" (the name that's more commonly used, even though it's technically incorrect) finds plenty of results indicating it commonly works, even finding some monitor manuals. Obviously YMMV.

Posted: **Mon Jan 11, 2016 10:42 am**

sydgrew wrote: I've been programming since 1961

Oh wow! It's really inspiring. I don't think I know someone else who's been programming for so long time.

(Sorry for the off-topic post.)

Posted: **Mon Jan 11, 2016 11:26 am**

Hi,

mallard wrote:
Brendan wrote: Except that:
For BIOS systems:
the VBE function doesn't exist (or at least the only information I've seen is "VESA BIOS Extensions/Display Data Channel Standard" which only mentions EDID and nothing else, and no other VESA standard I've ever seen has described anything more)
VESA MCCS is entirely separate from VBE. It's part of the DDC protocol, which is available via VBE, but also via "native" card-specific mechanisms. VBE function 15h subfunctions 10h-16h (the VBE SCI standard, somewhat annoying to find information about due to SciTech's association with VBE and the resulting abbreviation conflict) provide direct access to DDC and can therefore access anything available via the protocol, not just EDID.

I just tried "int 0x10, ax=0x4F15, bl=0x10" on 3 computers. The results are:

Computer 1: Function isn't supported
Computer 2: Function supported; results are:
- bx = 0x720F = can read and write to SCL clock and SDA data
- cx = 0x0102 = VBE/SCI version number 1.2
- dx = max. monitors = 0(+1)
Computer 3: Function supported; results are:
- bx = 0x0102 = can write to SDA data, but can't read from it, and can't read or write to SCL clock
- cx = 0xC125 = VBE/SCI version number 193.37
- dx = max. monitors = 0(+1)

I assume the third computer put the "version" in the wrong register and left CX unchanged (same value before and after the call).

Based on this (admittedly limited) testing; I think it's safe to say that this is a worthless/unusable pile of crap.

mallard wrote:
Brendan wrote:
For UEFI, it definitely doesn't exist (not even as a boot-time service)

There's no standard way to access it without firmware (different video cards are different)
VESA MCCS always exists, but on a UEFI system you can't access it without a native video driver (I'm not sure what firmware has to do with anything...). If you don't have a native driver by all means, fall back to hacky colour manipulation or just report that you can't change the screen's brightness from software (at which point the user will likely just use the adjustment built into the monitor).

So you're telling me that because there's no standard way to access MCCS, you have to work around the problem by implementing many native video drivers? Alternatively, are you telling me you only need one "generic native video driver" that will work in a standard way with all video cards?

Note: I really do wish that video card manufacturers provided a standard programming interface for basic things (like video mode setting, DDC, vertical refresh IRQ, etc) that could easily be implemented the same on all video cards (unlike more advanced stuff, like GPUs, that would be excluded). That way, all OSs could have a "generic native video driver" that provides basic functionality. Sadly, for this to happen we'd need some sort of video standardisation committee that wasn't run by incompetent morons.

mallard wrote:
Brendan wrote:
If (due to miracles or perseverance/native video card drivers) you actually can use it; there's no guarantee the monitor bothers to support most/any of the commands to begin with.
[/list][/list]
Sure, there's no guarantee that the monitor supports all the VCP codes. However, monitors are at least required to at least report the VCP codes they do support (via the GetSupportedControls request). As I said, most monitors made in the last decade or so do have the proper support. Looking at a few threads on forums related to Windows/Linux tools that adjust the brightness via this mechanism, I've seen very few reports of it not working due to hardware incompatibility and Googling for "DDC/CI" (the name that's more commonly used, even though it's technically incorrect) finds plenty of results indicating it commonly works, even finding some monitor manuals. Obviously YMMV.

I can't even find a monitor that supports EDID v1.4. As far as I can tell, monitor manufacturers do the least possible to meet minimum requirements and nothing else. Maybe in 20+ years (when I start implementing native video drivers) I'll find out how many monitors actually support it correctly.

Cheers,

Brendan

Posted: **Wed Jan 13, 2016 3:38 am**

Brendan wrote:Note: I really do wish that video card manufacturers provided a standard programming interface for basic things (like video mode setting, DDC, vertical refresh IRQ, etc) that could easily be implemented the same on all video cards (unlike more advanced stuff, like GPUs, that would be excluded).

Heck, I wish the industry would separate out GPUs from video controllers.

A video controller should generally be something integrated on the motherboard (unless the user needs more video outputs or a higher resolution than the controller on the motherboard supports, in which case it can be an expansion card) that controls one or more monitors and provides a framebuffer for each monitor for the computational hardware on the system to dump finished video frames into. It should not be involved in determining what the final image that gets dumped into the framebuffer should be. It should just display that image when it arrives.

A GPU should be a coprocessor (either on the motherboard or on an expansion card) optimized to offloading stuff like blitting and 3d graphics from the CPU (or to massively parallel workloads in general). It should solely be in the business of processing data to create images and dumping the images into a designated area of memory (which may or may not be the video controller's framebuffer. The GPU shouldn't know or care). It should not be involved in reading EDID or telling monitors what brightness or power saving settings to use or pushing images from the hardware framebuffer to the display.

Posted: **Wed Jan 13, 2016 7:22 am**

linguofreak wrote: A GPU should be a coprocessor (either on the motherboard or on an expansion card) optimized to offloading stuff like blitting and 3d graphics from the CPU (or to massively parallel workloads in general). It should solely be in the business of processing data to create images and dumping the images into a designated area of memory (which may or may not be the video controller's framebuffer. The GPU shouldn't know or care). It should not be involved in reading EDID or telling monitors what brightness or power saving settings to use or pushing images from the hardware framebuffer to the display.

That's kind of what NVidia's "Optimus" technology does. You have an Intel GPU that's actually connected to the display and an NVidia GPU that is able to "stream" output to the Intel GPU. Of course, in your scheme the Intel chip would be replaced with a dumb framebuffer display controller, but the principle is very similar.

Most modern GPUs (and even many old 2D "accelerated" graphics cards; the IBM XGA for instance) can render their output to system memory, so with the help of an IOMMU, could also output to the framebuffer of another device. There is the problem of what to do when the GPU's output is occluded; either you have to provide some sort of "occlusion mask" to the GPU or have the CPU do a (potentially very slow) blit from the GPU's output buffer to the display controller's framebuffer. Neither sounds like a good solution.

Posted: **Thu Jan 14, 2016 1:09 am**

Well I was attracted by member Mallard's suggestion of VESA MCCS (thank you!), so I've been trying that way first. Three computers responded with all four functions supported, one responded with only "can write to SCA data line" supported. Very similar to member Brendan's results in his 11:26am message. (Refer to "VESA BIOS Extension/Serial Control Interface Standard V1:0".)

So my next step was to try to issue a command, via sub-function 14h, "Write SDA Data Line". I suppose a good test is just to send 13h 00 08 (the 13h being VCP code command "backlight control", the 00 being the SH byte for "white adjustment", and the 08 being the SL byte "new backlight control value" - absolute rather than relative I believe). Refer to VESA Monitor Control Command Set Standard V3.

It seems very curious that one can send out this command only one bit at a time! I tried sending complete bytes such as 13h but always had an error response. It is hard to believe but seems to be true: the only acceptable data is a 1 or a 0. The documents do not tell us the order in which the bits (as opposed to bytes) should be sent (high order bit first or low order bit first); I tried both ways.

So I split 13h 00 08 into bits and made twenty-four calls to sub-function 14h (write SDA data line). There was no error response, but unfortunately nor was there a change in the brightness on any machine.

It's quite possible - in fact probable - that I'm doing something wrong at this stage, and further tests are needed. There don't seem to be any examples available. I presume that the "SDL clock line" is irrelevant here, but I can try inserting pauses between the bits, sending further preparatory commands, or maybe even reinitializing after sending out each bit!

But I will also go on now to look at member Nable's Free Electrons sources and member Brendan's pointer to the ACPI specifications.

Posted: **Thu Jan 14, 2016 6:01 am**

sydgrew wrote:It's quite possible - in fact probable - that I'm doing something wrong at this stage

Yep. You gotta do a bit more than toggle the SDA line to make stuff happen.

Wikipedia has a pretty good explanation of how to communicate over I²C, and VESA provides sample code in the Display Data Channel Command Interface (DDC/CI) Standard. I think those will give you enough information to make it work. (Or at least let you read the EDID. I have no idea if your laptop's backlight is controlled this way.)

As an aside, VBE/SCI is the only way to read the complete EDID from newer monitors without a native driver.

OSDev.org

For want of a function key . . .

For want of a function key . . .

Re: For want of a function key . . .

Re: For want of a function key . . .

Re: For want of a function key . . .

Re: For want of a function key . . .

Re: For want of a function key . . .

Re: For want of a function key . . .

Re: For want of a function key . . .

Re: For want of a function key . . .

Re: For want of a function key . . .

Re: For want of a function key . . .

Re: For want of a function key . . .

Re: For want of a function key . . .

Re: For want of a function key . . .