Backlighting

parsec · 2014-04-14 18:55:20

PROBLEM:
After an pacman update, the screen brightness on my Dell Latitude D830 laptop was so dim that it is barely able to be seen.

I had a problem with the backlight on my Arch Linux system after a "pacman -Syu" on Friday, April 11th.

WHAT I DID:
This is the pacman log for all the stuff that was updated and then I experienced the problem with the backlight:

[2014-04-11 11:19] [PACMAN] Running 'pacman -Syu'
[2014-04-11 11:19] [PACMAN] synchronizing package lists
[2014-04-11 11:19] [PACMAN] starting full system upgrade
[2014-04-11 11:20] [PACMAN] Running 'pacman -Syu'
[2014-04-11 11:20] [PACMAN] synchronizing package lists
[2014-04-11 11:20] [PACMAN] starting full system upgrade
[2014-04-11 11:22] [PACMAN] upgraded coreutils (8.22-3 -> 8.22-4)
[2014-04-11 11:22] [PACMAN] upgraded x265 (0.8-2 -> 0.9-1)
[2014-04-11 11:22] [PACMAN] upgraded ffmpeg (1:2.2-2 -> 1:2.2.1-1)
[2014-04-11 11:22] [PACMAN] upgraded fftw (3.3.3-2 -> 3.3.4-1)
[2014-04-11 11:22] [PACMAN] upgraded kmod (16-1 -> 17-1)
[2014-04-11 11:22] [PACMAN] upgraded libdrm (2.4.52-1 -> 2.4.53-1)
[2014-04-11 11:22] [PACMAN] upgraded libjpeg-turbo (1.3.0-4 -> 1.3.1-1)
[2014-04-11 11:22] [PACMAN] upgraded libsystemd (212-1 -> 212-2)
[2014-04-11 11:22] [PACMAN] upgraded libutil-linux (2.24.1-4 -> 2.24.1-6)
[2014-04-11 11:22] [ALPM-SCRIPTLET] >>> Updating module dependencies. Please wait ...
[2014-04-11 11:22] [ALPM-SCRIPTLET] >>> Generating initial ramdisk, using mkinitcpio.  Please wait...
[2014-04-11 11:22] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
[2014-04-11 11:22] [ALPM-SCRIPTLET] ==> Starting build: 3.14.0-4-ARCH
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [base]
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [udev]
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [autodetect]
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [modconf]
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [block]
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [keymap]
[2014-04-11 11:22] [ALPM-SCRIPTLET] ==> WARNING: keymap: hook specified, but no KEYMAP found in configuration
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [encrypt]
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [lvm2]
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [consolefont]
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [fsck]
[2014-04-11 11:22] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2014-04-11 11:22] [ALPM-SCRIPTLET] ==> Creating gzip initcpio image: /boot/initramfs-linux.img
[2014-04-11 11:22] [ALPM-SCRIPTLET] ==> Image generation successful
[2014-04-11 11:22] [ALPM-SCRIPTLET] ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
[2014-04-11 11:22] [ALPM-SCRIPTLET] ==> Starting build: 3.14.0-4-ARCH
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [base]
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [udev]
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [modconf]
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [block]
[2014-04-11 11:22] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: aic94xx
[2014-04-11 11:22] [ALPM-SCRIPTLET] ==> WARNING: Possibly missing firmware for module: smsmdtv
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [keymap]
[2014-04-11 11:22] [ALPM-SCRIPTLET] ==> WARNING: keymap: hook specified, but no KEYMAP found in configuration
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [encrypt]
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [lvm2]
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [consolefont]
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
[2014-04-11 11:22] [ALPM-SCRIPTLET]   -> Running build hook: [fsck]
[2014-04-11 11:22] [ALPM-SCRIPTLET] ==> Generating module dependencies
[2014-04-11 11:22] [ALPM-SCRIPTLET] ==> Creating gzip initcpio image: /boot/initramfs-linux-fallback.img
[2014-04-11 11:23] [ALPM-SCRIPTLET] ==> Image generation successful
[2014-04-11 11:23] [PACMAN] upgraded linux (3.13.8-1 -> 3.14-4)
[2014-04-11 11:23] [PACMAN] upgraded nss (3.15.5-2 -> 3.16-1)
[2014-04-11 11:23] [PACMAN] upgraded openvpn (2.3.2-2 -> 2.3.3-1)
[2014-04-11 11:23] [PACMAN] upgraded s-nail (14.6.2-1 -> 14.6.4-1)
[2014-04-11 11:23] [PACMAN] upgraded util-linux (2.24.1-4 -> 2.24.1-6)
[2014-04-11 11:23] [PACMAN] upgraded systemd (212-1 -> 212-2)
[2014-04-11 11:23] [PACMAN] upgraded systemd-sysvcompat (212-1 -> 212-2)
[2014-04-11 11:23] [PACMAN] upgraded xfburn (0.5.0-1 -> 0.5.2-1)

I found the Arch Wiki article on backlighting:
https://wiki.archlinux.org/index.php/Backlight

When you pressed one of the key combinations on the Dell keyboard, the small Dell brightness display window would appear on the laptop screen and I could see the brightness bar move up and down, but the screen still stayed really dim.

The aforementioned wiki article mentioned a number of steps. One of which was to use the "xbacklight" command which seems tied to Xorg. I followed those directions but it appeared that it was already set to the highest level possible. Making changes with "xbacklight" at this stage of trouble shooting didn't affect any change with the actual brightness of the display.

The wiki article also referenced going to the /sys/class/backlight directory where I actually found *two* entries. (I am not sure how many entries there were or their values before the pacman update.)

# ls /sys/class/backlight
dell_backlight
intel_backlight

# ls -alh /sys/class/backlight
total 0
drwxr-xr-x  2 root root 0 Apr 12 07:34 .
drwxr-xr-x 45 root root 0 Apr 12 07:34 ..
lrwxrwxrwx  1 root root 0 Apr 12 07:28 dell_backlight -> ../../devices/platform/dell-laptop/backlight/dell_backlight
lrwxrwxrwx  1 root root 0 Apr 12 07:28 intel_backlight -> ../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-LVDS-1/intel_backlight

This returned two entries and I had also noticed during the boot process that the display was normal brightness until it reached a line that noted something about an "Intel" backlight setting and then went really dim.

By looking at the files in the directory I notice that the "actual_brightness"
value was at "0" and the "max_brightness" value was really high:

# cat /sys/class/backlight/intel_backlight/max_brightness 
	255000

So I did an "echo 1 > bl_power" field and that seemed to fix it. The problem is that the setting does not seem to persist across reboot.

There also seemed to be a repeat of the directory structure underneath the intel_backlight directory where I found the same file again:
/sys/class/backlight/intel_backlight/device/intel_backlight

# ls -alh /sys/class/backlight/intel_backlight/device/intel_backlight/ 
total 0
drwxr-xr-x 3 root root    0 Apr 14 10:52 .
drwxr-xr-x 4 root root    0 Apr 14 10:52 ..
-r--r--r-- 1 root root 4.0K Apr 14 10:52 actual_brightness
-rw-r--r-- 1 root root 4.0K Apr 14 11:04 bl_power
-rw-r--r-- 1 root root 4.0K Apr 14 10:52 brightness
lrwxrwxrwx 1 root root    0 Apr 14 10:52 device -> ../../card0-LVDS-1
-r--r--r-- 1 root root 4.0K Apr 14 10:52 max_brightness
drwxr-xr-x 2 root root    0 Apr 14 10:52 power
lrwxrwxrwx 1 root root    0 Apr 14 08:58 subsystem -> ../../../../../../../class/backlight
-r--r--r-- 1 root root 4.0K Apr 14 10:52 type
-rw-r--r-- 1 root root 4.0K Apr 14 10:52 uevent

So I rebooted and then tried doing a "echo 1 > /sys/class/backlight/intel_backlight/device/intel_backlight/bl_power". It did bring the screen to full brightness it did to the similar file before, but it did not persist on a reboot.

Interestingly, after I did the "echo 1 > bl_power" and the screen brightness went to full then I was able to use the hardware keys on the Dell laptop to actuate the brightness. Also, after doing the "echo 1 > bl_power" command I was able to actuate the brightness using the "xbacklight" listed in the wiki page on backlighting.

Also on the backlight wiki page were a number of kernel parameters that were listed. I tried all of the following in addition to combinations of them:

video.use_native_backlight=1
acpi_osi=Linux acpi_backlight=vendor
acpi_osi=Linux acpi_backlight=legacy

As well as creating a /etc/X11/xorg.conf.d/20-intel.conf file mentioned at the bottom of the wiki article:

	Section "Device"                                                                 
		Identifier  "Backlight fix"                                              
		Driver      "intel"                                                      
		Option      "Backlight"  "intel_backlight"                               
	EndSection

Finally, since the laptop seems to start the BIOS in bright mode, go through grub in bright mode, and enter my LUKS password in bright mode but becomes really dim through the rest of the boot sequence I copied and pasted the sctions of the boot logs since the last boot using "sudo journalctl -b" and these are the only lines that deal with backlighting:

Apr 14 12:04:21 arch systemd[1]: Starting system-systemd\x2dbacklight.slice.
Apr 14 12:04:21 arch systemd[1]: Created slice system-systemd\x2dbacklight.slice.
Apr 14 12:04:21 arch systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:dell_backlight...
Apr 14 12:04:21 arch systemd[1]: Started Load/Save Screen Backlight Brightness of backlight:dell_backlight.
Apr 14 12:04:22 arch systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:intel_backlight...
Apr 14 12:04:22 arch systemd[1]: Started Load/Save Screen Backlight Brightness of backlight:intel_backlight.

It appears that it hits the "intel_backlight" entry as the last entry for backlighting and then sticks with that setting/configuration. Which would match with the fact that when I changed the "bl_power" in the "intel_backlight" directory it seemed to fix the problem.

All of which to no joy. So thought I would post this out there to see if anyone had any thoughts. I am using ext4 as my filesystem and I guess I could mark the "bl_power" file as immutable and that would probably persist across reboots but I am concerned if I do that that there will be some update in the future that needs to change that file and the update will fail.

Thanks!

ANECDOTAL:
I also had problems from that same pacman update with recognizing my USB keyboard and mouse. I quickly went to the post at the top of archlinux.org that I remembered reading about loss of keyboard support and tried booting using the command line kernel boot parameter it mentioned. I eventually solved that problem by running the "mkinitcpio -p" command to generate a new image and then it booted just fine as it always had and recognized my external USB keyboard as normal. I am betting that this is unrelated to the backlight problem but thought I would include it in case for context and in case there was anything to the backlighting changes and mkinitcpio.

Last edited by parsec (2014-04-16 19:48:09)

jasonwryan · 2014-04-14 19:03:54

Please use code tags when pasting to the boards: https://wiki.archlinux.org/index.php/Fo … s_and_Code

clfarron4 · 2014-04-14 20:42:26

Have you tried downgrading the linux package from your pacman cache?

Also, code tags...

parsec · 2014-04-14 21:48:19

I have not tried downgrading any packages from that pacman update. I couldn't determine which package would have affected the change with the backlighting.

cmlr · 2014-04-14 22:50:26

I had the same problem with a Dell Inspiron 1420. The solution given in this thread worked for me:
https://bbs.archlinux.org/viewtopic.php?id=178014
Namely, I added the following kernel parameter:

i915.invert_brightness=1

Head_on_a_Stick · 2014-04-14 23:03:23

You could try stopping systemd from loading the intel_backlight service by running

# systemctl mask systemd-backlight@backlight:intel_backlight.service

if the suggestion given by @cmlr doesn't work...

gojun077 · 2014-04-15 10:14:25

I had a similar issue on my Dell Latitude D630. This is a known kernel bug for systems using Intel mobile graphics that will be fixed in kernel 3.15:

https://bugs.freedesktop.org/show_bug.cgi?id=76276

I solved by downgrading from kernel 3.14 to 3.13:

Go to /var/cache/pacman/pkg and find your previously-installed 3.13.xxx kernel .xz file and install with

sudo pacman -U <kernel_name>

parsec · 2014-04-16 19:44:48

So, after running a pacman to update today and rebooting the backlighting behavior has changed some.

When you boot the monitor brightness on the laptop is full through the BIOS screen, GRUB, & LUKS entry screen; this is the same as before. It then gives you a login prompt and I can enter my username & password and it is dim at this point. Before, it was dim from that point through the rest of the boot. *Now* when I then enter:

$ startxfce4

as I have been doing all along, it will now boot into the XFCE desktop and the screen brightness will be full and I can actuate the brightness using the hardware controls on the laptop or the "xbacklight" tools that work with Xorg.

I did try @cmlr's suggestion and tried the kernel boot parameter but that did not have an affect for me. The laptop seems to exhibit this new "brightness in GUI mode behavior" regardless of the kernel parameter being present during boot. That parameter being:

 i915.invert_brightness=1

Thanks for the suggestion cmlr.

I was reading the systemctl man page in connection with Head_on_a_Stick's suggestion. I through I would collect some of the data on systemd events using systemctl both before and after entering XFCE.

I did the following command twice:

# systemctl list-units

Once when the laptop booted to the command prompt and was really dim and then again when I had started XFCE in full graphics mode and the display magically became bright again.

There were only two differences of items that were not there during the initial boot to runlevel 3 but that were there when I booted into a full XFCE (runlevel 5) environment:

polkit.service
upower.service

I can't imagine either of those services affecting the backlighting through.

All of the other entries for anything related to backlighting remained the same at the logon screen as well as after full boot to GUI:

# systemctl list-units
...
UNIT                                                                                     LOAD  ACTIVE SUB
sys-devices-pci0000:00-0000:00:02.0-drm-card0-card0\x2dLVDS\x2d1-intel_backlight.device loaded active plugged
sys-devices-platform-dell\x2dlaptop-backlight-dell_backlight.device                     loaded active plugged
systemd-backlight@backlight:dell_backlight.service                                      loaded active exited
systemd-backlight@backlight:intel_backlight.service                                     loaded active exited
system-systemd\x2dbacklight.slice                                                       loaded active active
...

I also did not see any change in the state of the unit files either:

# systemctl list-unit-files

UNIT FILE                                  STATE   
systemd-backlight@.service                 static

The state of the "systemd-backlight@.service" didn't change regardless of whether it was in runlevel 3 or runlevel 5.

Also I took readings from the "systemctl status" command against the three services that deal with backlighting both before and after the XFCE GUI environment:

This is what it looked like when I had booted up and was waiting at the login prompt in runlevel 3 when it was dim:

# systemctl status systemd-backlight@backlight:intel_backlight.service
systemd-backlight@backlight:intel_backlight.service - Load/Save Screen Backlight Brightness of backlight:intel_backlight
   Loaded: loaded (/usr/lib/systemd/system/systemd-backlight@.service; static)
   Active: active (exited) since Wed 2014-04-16 10:02:14 CDT; 23min ago
     Docs: man:systemd-backlight@.service(8)
  Process: 302 ExecStart=/usr/lib/systemd/systemd-backlight load %i (code=exited, status=0/SUCCESS)
 Main PID: 302 (code=exited, status=0/SUCCESS)

Apr 16 10:02:14 tux4 systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:intel_backlight...
Apr 16 10:02:14 tux4 systemd[1]: Started Load/Save Screen Backlight Brightness of backlight:intel_backlight.


# systemctl status sys-devices-platform-dellx2dlaptop-backlight-dell_backlight.device
sys-devices-platform-dellx2dlaptop-backlight-dell_backlight.device
   Loaded: loaded
   Active: inactive (dead)


# systemctl status systemd-backlight@backlight:dell_backlight.service
systemd-backlight@backlight:dell_backlight.service - Load/Save Screen Backlight Brightness of backlight:dell_backlight
   Loaded: loaded (/usr/lib/systemd/system/systemd-backlight@.service; static)
   Active: active (exited) since Wed 2014-04-16 10:02:13 CDT; 23min ago
     Docs: man:systemd-backlight@.service(8)
  Process: 250 ExecStart=/usr/lib/systemd/systemd-backlight load %i (code=exited, status=0/SUCCESS)
 Main PID: 250 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/system-systemd\x2dbacklight.slice/systemd-backlight@backlight:dell_backlight.service

Apr 16 10:02:13 tux4 systemd[1]: Started Load/Save Screen Backlight Brightness of backlight:dell_backlight.

This is what it looked like after I had booted into XFCE (runlevel 5) and the backlighting returned to the normal high brightness:

# systemctl status systemd-backlight@backlight:intel_backlight.service
systemd-backlight@backlight:intel_backlight.service - Load/Save Screen Backlight Brightness of backlight:intel_backlight
   Loaded: loaded (/usr/lib/systemd/system/systemd-backlight@.service; static)
   Active: active (exited) since Wed 2014-04-16 10:36:45 CDT; 8min ago
     Docs: man:systemd-backlight@.service(8)
  Process: 295 ExecStart=/usr/lib/systemd/systemd-backlight load %i (code=exited, status=0/SUCCESS)
 Main PID: 295 (code=exited, status=0/SUCCESS)

Apr 16 10:36:45 tux4 systemd[1]: Started Load/Save Screen Backlight Brightness of backlight:intel_backlight.


# systemctl status sys-devices-platform-dellx2dlaptop-backlight-dell_backlight.device
sys-devices-platform-dellx2dlaptop-backlight-dell_backlight.device
   Loaded: loaded
   Active: inactive (dead)


# systemctl status systemd-backlight@backlight:dell_backlight.service
systemd-backlight@backlight:dell_backlight.service - Load/Save Screen Backlight Brightness of backlight:dell_backlight
   Loaded: loaded (/usr/lib/systemd/system/systemd-backlight@.service; static)
   Active: active (exited) since Wed 2014-04-16 10:36:43 CDT; 10min ago
     Docs: man:systemd-backlight@.service(8)
  Process: 256 ExecStart=/usr/lib/systemd/systemd-backlight load %i (code=exited, status=0/SUCCESS)
 Main PID: 256 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/system-systemd\x2dbacklight.slice/systemd-backlight@backlight:dell_backlight.service

Apr 16 10:36:43 tux4 systemd[1]: Started Load/Save Screen Backlight Brightness of backlight:dell_backlight.

After collecting my data on before and after runlevel 5, I did try Head_on_a_Stick's suggestion to do the following:

# systemctl mask systemd-backlight@backlight:intel_backlight.service

That did not have any effect upon reboot. Thanks for the suggestion Head_on_a_Stick.

So then I thought what if I were to try to mask the "systemd-backlight@backlight:dell_backlight.service" since in the last collection of data from the "systemctl status" commands it appeared that the "intel_backlight.service" started two seconds after the "dell_backlight" service in the XFCE environment and the XFCE environment was the one with the correct full brightness:

# systemctl mask systemd-backlight@backlight:dell_backlight.service

That didn't seem to do anything on reboot. In a final bit of irony I rebooted, logged in, and left it at runlevel 3 then got up and didn't come back to the laptop for maybe 30 minutes. When I opened the lid the brightness was correct. Very wierd.

At this point I am not sure what else to try. At a minimum it seems to reach full brightness and when it finally boots into XFCE. I spend almost all my time in a GUI environment and then run a terminal emulator from there so it could be worse. Just hope that the problem doesn't return on a subsequent update.

Any other thoughts of what to try? Thanks again to everyone for the suggestions!

chrisp1090 · 2014-05-08 22:59:04

I had the same problem on my Dell Inspiron 15, and every kernel parameter solution would screw up my boot sequence and my computer would not fully boot. I knew there had been a solution which worked before I reinstalled my system, and I finally found it again. Remove all of the kernel parameter changes you made and add this file:

# nano /etc/X11/xorg.conf.d/20-intel.conf

Section "Device"
        Identifier  "Backlight fix"
        Driver      "intel"
        Option      "Backlight"  "intel_backlight"
EndSection

Hopefully this works for you, I found it here: https://wiki.archlinux.org/index.php/Ba … ernel_3.13

mcloaked · 2014-05-09 13:10:14

It is just possible that you may have hit a problem that caused me some weeks of similar difficulties with a screen that dims to almost nothing when booting up. I explored a lot of different possible avenues before coming to the solution which you can follow through to the solution at https://bugs.freedesktop.org/show_bug.cgi?id=78200

Basically what happened was that the brightness setting was made in the desktop (in my case KDE and in yours xfce) but that when shutting down the machine systemd was saving the brightness level to use at the next boot. The problem that I had was that during one of the kernel updates the numerical value of the max_brightness was increased by around a factor of 20 or so which meant that the loaded value that had previously been saved was then a small fraction of the max brightness which gave an extremely dim screen. The way I eventually got to that was looking at the brightness parameters using

$ ls -1 /sys/class/backlight/intel_backlight/*brightness | xargs -I % sh -c "echo % ; cat %"
/sys/class/backlight/intel_backlight/actual_brightness
3544500
/sys/class/backlight/intel_backlight/brightness
13900
/sys/class/backlight/intel_backlight/max_brightness
379312

which showed the middle value as being extremely low, and the actual brightness was above max! - the problem was that I could get the brightness back to "normal" using the keyboard shortcuts but it was not changing the value stored as above. So this persisted after reboot. What eventually fixed it was changing the value of /sys/class/backlight/intel_backlight/brightness by doing

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

which made the numerical brightness value equal the max which is then was systemd stored at shutdown and that value was then reloaded at next bootup.

Now the values after boot are normal and the screen works fine. As you will see from the bug I referenced there is a systemd patch commit that was entered a few days ago so hopefully this issue will be fixed at the next systemd update. If my bug is the same origin as yours then hopefully this will give you both a workaround as well as a fix coming in systemd.

Arch Linux

#1 2014-04-14 18:55:20

Backlighting

#2 2014-04-14 19:03:54

Re: Backlighting

#3 2014-04-14 20:42:26

Re: Backlighting

#4 2014-04-14 21:48:19

Re: Backlighting

#5 2014-04-14 22:50:26

Re: Backlighting

#6 2014-04-14 23:03:23

Re: Backlighting

#7 2014-04-15 10:14:25

Re: Backlighting

#8 2014-04-16 19:44:48

Re: Backlighting

#9 2014-05-08 22:59:04

Re: Backlighting

#10 2014-05-09 13:10:14

Re: Backlighting

Board footer