AuthorTopic: Screen Brightness For Toughbook (Read 23342 times)

I have a Panasonic Toughbook CF-T5 with 5.9 on it and i can't change the screen brightness. It is normally done with Fn+F1 but it does not work. I checked the BIOS to see if i could find something helpful there but i didn't. I tried xbacklight=x (x=0 to 100) without any success. Any ideas? Does it have to do with power management? ACPI?

Logged

“Our very lives depend on the ethics of strangers, and most of us are always strangers to other people.” -- Bill Moyers

Mash on those keys and see if there are any events showing up in that terminal. You can write scripts that get fired off when those events are picked up. If they are picked up.I can help you with this. I'm out of computer time for the night, but if you have events, I'll invest the time to get you going over the next few days.

Not mapped either? Meaning no keycode? Is there activity pressing the keys with xev? If so, good, we can map them. If no activity. Try checking dmesg after pressing. Keys that send a signal that the kernel doesn't understand will have a message logged. If no xdev activity, or dmesg... You are out of luck unless there is a module specific to your laptop you can load.

Correct. Or at least for now. /proc is depreciated, and it's moved over to /sys. But we are using both for now. The paths to the brightness file vary. Depending on the system. echoing a random value to /proc/acpi/*/*/brightness will not work. The exact accepted value needs to be used. The user can view the brightness file in a text editor to find the accepted values.

The brightness file located in /sys has been evolving with each kernel release it seems. Echoing a value to it fails with the latest kernel we have available. Now the brightness values are not in percents any longer. It is controlled by levels. This machine has 7 levels of brightness. So to make the display change to full brightness I have to echo a 7.

You may not have a brightness file. It may not be supported on your machine. I "think" most intel video cards and maybe "some" others support this. The same goes for adjusting your brightness via xbacklight. Make sure the video kernel module is loaded. This is needed.

If trying xbacklight fails, also try this in a terminal:xrandr --output LVDS --set BACKLIGHT_CONTROL native

Don't know why, but sometimes I need to do this, depending on what kernel I am using. Then try to set your brightness to half:xbacklight -d 0:0 -set 50

If you can change your brightness with echoing to a brightness file, or using xbacklight, life is good. Even if your FN+Key buttons don't send a acpi event, or aren't visible to the kernel, we can always map other keys or key combinations to get the job done.

I've written several versions of "brightness" changing scripts that might get you started if you can manually change your brightness. One of them is somewhat "smart" and will read your available brightness levels, what level is currently used, and bump up or down according to what key is pressed. I'm also working on a HAL powered one that does all the thinking and should work for all hardware that supports brightess, but I got bored with it, and didn't finish.

I once put that on a script that I mapped to a brightness key, but I don't think I was able to increase it. I mean, to check the current value, add (or subtract) 10 to it and then echo the result... I don't know enough bash for that. Instead I ended up mapping 10 keys to each of the brightness values!

# by exeterdad. No license. If ya need it, use it, change it.# Usage put in your path somewhere and name it something like brightness.sh# Make executable (chmod +x brightness.sh)## Execute like this:# "brightness.sh BrightnessUp" to go up one level of brightness.# "brightness.sh BrightnessDown" to go down one level of brightness.## You can use a script that launches those commands when a acpi event is triggered by the # appropriate Fn+Key, or you can map these commands to keys of your choice. (easily done with most wm's).# But if this is the case, you will need to adjust your sudors file to give user root permission to launch# brightness.sh. To adjust brightness root priv's are needed. This is not the case if script is triggered# by acpi.

The "levels" line shows the brightness levels (in percentages) that my hardware supports. Note they are in no particular order, and even has duplicates. (I dunno). The "current" line shows which level of brightness I'm currently running. I'm on 12 at the moment to save battery power.

This script will read the available brightness levels, remove the duplicates, then put them in numerical order. It also assigns a number to each level. One through whatever. Then it finds out the current level. When called BrightnessUp or down. It read current level and that "index" number. It then adds or subtracts one from that number depending on which way you want to adjust. Then it matches the new number to the brightness and echos it to the brightness file, thus making it the next level of brightness (up or down).

Unfortunately EVERYTHING brightness related on this machine (or sound levels for that matter) is handed to the OS for control (Some machines will adjust using bios only.) so it all has to be scripted. I have a script that is triggered when the power supply is removed to set my brightness to a very low setting. The script is also run at boot if A/C cord is unplugged. Of course it reacts the opposite if the cord is plugged in.

Hope this is helpful.

Edit: This script will absolutely not work with a brightness file located somewhere in /sys in recent kernels. The handling is completely different.

Just discovered something cool. I dug out my HAL based brightness script and was working on it some more. With HAL, normal users can adjust brightness! How cool is that?

This script is using the brightness file in /sys. The advantage of using HAL is that HAL does all the dirty work, so no matter where the location of the brightness file is (and it can and will vary depending on hardware), one script will work with all supported hardware without editing by the user. And apparently non-privileged users can adjust it. Can't explain it, I'm just excited.

This script is using the brightness file in /sys. The advantage of using HAL is that HAL does all the dirty work, so no matter where the location of the brightness file is (and it can and will vary depending on hardware), one script will work with all supported hardware without editing by the user. And apparently non-privileged users can adjust it.

Sounds cool.Those special keys in laptops are a pain, and I think one of the first things new users coming from Windows notice and get annoyed about.

OK, i'm calling it quits on this. I got want i wanted which was to change the brightness. Those brightness keys don't show up anywhere (xev, dmesg, showkey). It's going to be a lot of work and i'm sort of busy. I'll map that somewhere else some day, if ever.

Thank you guys for your help.

Gus

Logged

“Our very lives depend on the ethics of strangers, and most of us are always strangers to other people.” -- Bill Moyers

The only ways I know of mapping keys it finding out if the key emit any kind of signal or keycode:xevshowkey (needs to be run without using X)Or checking dmesg after trying a key. If the kernel can see it, and doesn't know what to do with it, it will complain here.

I believe if these three options don't work, you are out of luck unless there is a module or a driver you need loaded. If the kernel can't see it, you won't be able to do anything.

gacl: xbacklight controls brightness independent of methods we discussed earlier. It can be run as normal user. And fortunately for you, it's working! We now know we can go that route if acpi is failing you.Can you run this command on your machine and post the output here? This command uses dbus and HAL to find your current brightness. If needed modules are loaded, and you have a brightness setting, HAL will find it. I suspect it won't work, but just in case?