In the answer I can find:
uvcvideo
videodev
nvidia
video

Full answer to the command is:
Module
binfmt_misc
ppdev
bridge
stp
bnep
snd_hda_codec_nvhdmi
snd_hda_codec_realtek
joydev
snd_hda_intel
snd_hda_codec
snd_hwdep
snd_pcm_oss
snd_mixer_oss
snd_pcm
snd_seq_dummy
snd_seq_oss
snd_seq_midi
snd_rawmidi
snd_seq_midi_event
iptable_filter
snd_seq
ip_tables
x_tables
snd_timer
snd_seq_device
snd
uvcvideo
videodev
v4l1_compat
ndiswrapper
psmouse
serio_raw
i2c_nforce2
shpchp
soundcore
nvidia
agpgart
snd_page_alloc
lp
parport
sky2
video
output

Have you tried to change the backlight after a suspend/resume cycle?

Also, paste here the output of:

~$ ls /proc/acpi/video/IGPU
CRT0 DOS DSP0 HDMI info LCD0 POST POST_info ROM

Don't ask why some are displayed in blue...

Suspend/resume cycle does not change anything.

Check in every subdirectory if there is something that may be related to backlight control.
If you find something, try to use the 'cat' and 'echo' commands like before, to read the current value and set a new value, and see if this affects the screen brightness.

:~$ cat /proc/acpi/video/IGPU/LCD0/brightness
levels: 20 30 40 50 60 70 80 100
current: 50
xxxx@MonNetbook:~$ cat /proc/acpi/video/IGPU/CRT0/brightness
<not supported>
xxxx@MonNetbook:~$ cat /proc/acpi/video/IGPU/DSP0/brightness
<not supported>
xxxx@MonNetbook:~$ cat /proc/acpi/video/IGPU/HDMI/brightness
<not supported>

xxxx@MonNetbook:~$ ls /proc/acpi/video/IGPU/LCD0
brightness EDID info state
xxxx@MonNetbook:~$ ls /proc/acpi/video/IGPU/CRT0
brightness EDID info state
xxxx@MonNetbook:~$ ls /proc/acpi/video/IGPU/DSP0
brightness EDID info state
xxxx@MonNetbook:~$ ls /proc/acpi/video/IGPU/HDMI
brightness EDID info state

So I suppose that for the 3 last files, there is an associated "brightness" value?Am I right?
If I am, then I'l try later for CRT0 /brightness and DSP0/brightness to change the value, using your terminal commands, and see if this has any effect on real screen display.

Edit the file /etc/default/grub:
and change the line
in
Save and exit.
Then, use this command to update grub:
Reboot the system and check if the backlight control works.

Tried the grub file edition ,adding acpi-backlight=vendor.
It is worse than before ,as now the Fn/UP & DOWN do not let anymore the brightness bubble even appear on the screen, as they did before.
I'm puzzled by the fact you are always speaking about backlight control, which is not the current issue..but brightness itself.

Then go back to the previous state. Revert the changes to '/etc/default/grub', and use the command 'sudo update-grub'.
I have no other tests to do, I'm officially out of ideas.
Yes sorry, by talking about backlight control I really mean brightness control.

hey voRia,

Just to let you all know my n510 shows all the same results as Julian2010, got more or less everything working nicely under karmic except the back light control (including wifi on the realtek 8192 driver)

i Just dont get how the archlinux people get it working!
http://bbs.archlinux.org/viewtopic.php?pid=655144
Are they using the nvidia driver? Cant find which version.

Hang in there Julian, there a fix out there somewhere!

hello AMvis,
At last someone who gets the same troubles with his N510...I'm not that pleased reading it, but it shows some other people are also trying to have their N510 running with another OS than the standard one...
Well I'm not really decided to give up for the time being...although I can't do much on my own.
Did you already made your way for the WIFI driver?
There are a few unclear things for me in this archlinux report, but I have ro read it & try to understand a few things (if I'm at all able to understand them..).

@voRia:
Sorry, it is a bit long, as I can only use my own words, not the Linuxian ones..

1-Following one of your last suggestions, I tried to echo the content of the sub-folders of /proc/acpi/video/IGPU, namely LCD0, CRT0,DSP0 and HDMI.I had a try only on LCD0 before.
As already told, LCD0 can be echoed and a new value for brightness can be changed in it, although without any effect on the actual screen brightness.
For the 3 other sub-folders, echoing is not possible (error message returned by terminal) , meaning probably they are empty.That had to be done, now it is and this door is shut.
So we stay with the fact that a brightness value can be changed in /proc/acpi/video/IGPU/LCD0, but that this file and/or value is not opened or read by some part of the system which should use it.

2-Changing a GRUB command line:
and change the line
Code:
[color=#008000]GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
in
Code:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_backlight=vendor"[/color]

As already told, this change in the Grub was a regression, as then after GRUB update &rebooting, the Fn/UP&DOWN had even lost the action of displaying the brightness bubble.
So, I undo-ed that change, coming back to the previous state: Fn/UP&DOWn let the brightness bulle appear, and the brightness level can be changed (in the bubble only, of course).
However, came back to my mind this:
I: I'm puzzled by the fact you are always speaking about backlight control, which is not the current issue..but brightness itself.
You: Yes sorry, by talking about backlight control I really mean brightness control.


So I made a try in that grub command line, adding acpi_brightness=vendor instead of acpi_backlight=vendor you mentioned.

Updated GRUB & rebooting.
No miracle, but although a difference with your command:
With this change of "symbolic variable" (I'm sorry writing with my own words), Fn/UP&DOWN do let again the brightness bubble appear and can change the brightness index it shows (still without action on the real screen brightness).
So, I understand that acpi-brightness and acpi_backlight are different symbolic variables and cannot be exchanged without consequences for the system.

So 2 questions about this "acpi-brightness" symbolic variable
-a: Is it possible that somewhere/elsewhere where changes have been made, "backlight" and/or "acpi-backlight" , "xxx-backlight" is/are used when they should be more appropriately named "brightness" or "acpi-brightness" or "xxx-brightness"?
-b : If "acpi_brightness" is the right symbolic variable name to be used there, is it "enough" defined by only the vendor value itself (which refers then elsewhere to Samsung, so to all the Samsung netbooks, whatever graphic driver they use -Intel or NVIDIA), or is it possible that it can/should be more specifically defined also/or by the kind of netbook, and/or even the kind of graphic/card& driver?

Of course all this has no interest and should go directly to the wastebin if acpi_brightness does not exist as a symbolic variable and if assigning in a GRUB command line a value to a non-existent symbolic variable produces no error at all and lets the system start..which would be strange in my view.

So, what are your views on all this?

No problems at all, I always prefer a well-articulated response in place of one that might be missing some important information.
Exactly, the problem is just that: how to enable that value to be actually used?
I'll investigate the problem more, but at the moment I really have no other ideas to fix the issue.
Sorry, the fact is just that my english is far from perfect.
I used the 'backlight' word even when I meant to say 'brightness'.
But it's just my fault with english, nothing more. All the commands we used and files we touched are correct.
So, this sentence:
is true.
The 'acpi_brightness' option does not exist, passing a non-existent option on the grub kernel boot line produces just a warning in your kernel log (telling you the option does not exist). The system boot is not stopped, and this is the correct behavior, because a system has to be stopped only on critical/unrecoverable errors.
So, pass an invalid option or do not pass any has the same effect.

Anyway, the 'acpi_backlight' option can be set to 'vendor' or 'video'.
From the official linux documentation:

I have ben too logical and/or optimistic
Then,why and how adding the correct wording acpi_backlight=vendor to quiet splash in the same GRUB command line is breaking the logical link between an FN/UP or DOWN keys action and the subsequent brightness bubble display?It's not logical, as it shouls, at least, give no change for that, if not changing anything else:this action should remain, but disappears.

What means "if set to vendor, prefer vendor specific driver" ?
I mean there: where this preference should apply, and does it apply everywhere it should?Have I to check something related to that somewhere?

When 'acpi_backlight=vendor' is not specified, the generic 'video' driver is used.
The 'video' driver accepts the events from Fn-Up and Fn-Down and changes the brightness status accordingly, and the notification bubbles appear (however, we know the changes are ignored and the real brightness is not changed).
When 'acpi_backlight=vendor' is used, the system does not use the generic 'video' driver anymore, instead it tries to use the vendor acpi driver (if any).
These are acpi implementations which does not follow the standard specifications (bad thing).
In other words, they are workarounds for machines with a broken power management system.
In your case, there is no working vendor driver, the 'video' driver is not used as requested via grub kernel command line, so trying to change the brightness level with Fn-Up and Fn-Down has no effects at all.