Changing Laptop Screen Brightness from the command-line

My new Dell Studio 15's laptop screen is great. It is bright, and by bright I mean that on full brightness I can use it outside on a sunny day with my sunglasses on and still read the screen comfortably. This brightness is great except for cases when I don't want it so bright, like when I'm working in a darker room. One night I discovered that the lower third of my vision had a dark blind spot after doing some work while watching a movie. That can't be good.

Problem is, I don't always remember to adjust the brightness, and from what I can tell, it always boots into Ubuntu af full brightness, so I dug around for a way to change the brightness automatically. Thanks to google I found a post over on LinuxScrew that talks about changing the brightness for a dell inspiron 1501. Turns out the Studio 15 has a similar method using /proc. Cat'ing the file shows me the acceptable brightness levels:

# cat /proc/acpi/video/M86/LCD/brightness 
levels:  6 12 18 24 30 36 42 48 54 60 66 72 78 84 90 100
current: 100

Echo'ing something to the file (as root) sets the value:

# echo -n 18 > /proc/acpi/video/M86/LCD/brightness 

There's lots of places to go with this, but for now I'm going to pop it into rc.local and run with it.

No more blind spots, excellent.

Ubuntu 9.10 and sticky java dialog boxes.

I'm running Ubuntu 9.10 in my laptop and have been suffering from an unusual problem. The buttons on dialog boxes created by the eclipse ide 'stick'. When I click on any button in a dialog, it gets stuck in the down position and never activates. The only solution is to tab over to the button if possible and activate it with the return key. Very irritating.

I finally tracked down the fix today. The problem is caused by something related to the way in which GDK renders its windows in the latest version. The solution is to set the environment variable GDK_NATIVE_WINDOWS=1 prior to launching eclipse. Apparently this is also a problem on newer versions of Fedora as well. Indeed it is probably an issue with anything running gdk 2.18 or newer, where the switch to 'client side windows' was made.

I've fixed this by renaming eclipse to eclipse.bin and placing the following script named eclipse in the same directory:

#!/bin/bash
BASE=$(dirname $0)
export GDK_NATIVE_WINDOWS=1
exec $BASE/eclipse.bin

don't forget to chmod +x it so that it is executable. You'll also have to rename eclipse.ini to eclipse.bin.ini -- eclipse finds its ini based on the binary name.

sheesh.

For an explanation of what GDK_NATIVE_WINDOWS is all about, check out the post "What GDK_NATIVE_WINDOWS=1" means over on Dax's blog.

Verizon Bluetooth EVDO on Ubuntu

I managed to get my Verizon KRZR k1m connected to my ubuntu laptop via bluetooth for dialup EVDO access. The BluetoothDialup help page on help.ubuntu.com was essential to figuring it out, along with the carrier specific information for Verizon

I did not have any luck getting EVDO dialup to work with the k1m connected to the laptop via USB. Apparently the usb configuration on Verizon's k1m doesn't cause the cdc-acm usb driver to load for the device and I ended up getting stuck with uhci instead. So, it appears that I'm out of luck as far as using it over a usb connection is concerned.

The interesting thing is that the speeds I got via Bluetooth in linux vs. USB using Verizon's access manager software in windows were quite similar. At my location, in the suburbs of the Washington DC area, I managed to get ~480k down and ~128k up. I wonder how that compares to the speeds that others have received elsewhere.

Now the only minor annoyance is that this doesn't work via NetworkManager at all, and I'm stuck with using pon and poff from the command line. I can set up the call via NetworkManager 's ppp control, but nothing is notified that the ppp connection has succeeded, so I can't for instance use the NetworkManager applet to start my vpn connection once the connection is set up.