I bet the problem is that the process doesn't get scheduled often enough to smoothly dim the display - if the scheduling timer runs at 100hz (which used to be the standard and is kinda likely on here), then at best, the program can switch the backlight at 50hz (first timer tick on, next off) - and this is only if you want exactly 50% brightness... if other percentages are desired, the flickering would get worse since there must be times when the backlight is on or off for 2 or more cycles in a row to attain the percentage.
A "fully compatable" fix would be writing a kernel module to use a 2nd timer (if there is one) to give a higher interrupt rate, and then this can be used as a way to switch the backlight faster. It would come at a slight cost in system performance, since every interrupt will by nature do a little cache trashing and use up a little processing time, but it probably wouldn't be too noticeable.
A hack could be increasing the scheduling timer rate, but context switches are a lot more expensive processing wise than just handling an interrupt, so this probably isn't desirable.
An application specific, but easier to implement way would be using the 940 as a backlight switcher - if the program doesn't use it at all, it could run constantly switching the light, but probably this would cause a lot more power usage from the 940 than is saved on the backlight. Again, if a 2nd timer can be activated and routed to the 940, this could be an efficient solution, but otherwise it would be best reserved for demos and "special effects".
