Maybe someone can get this fixed for the upcoming Karmic?
It seems that the problem is related to the keys not sending events. Quoting the above mentioned link:
"After a while I discovered the problem was that some of the fn-keys weren’t sending key release events (easy to see in xev or with lshal -m). Turns out this is a problem with lots of laptop keyboards: look at the thousands of lines of hacks in drivers/input/keyboard/atkbd.c in the Linux kernel source. The good news is that this is easy to fix: the Q320 uses exactly the same scancodes as an earlier Samsung laptop. The bad news is that you have to compile your own kernel. Ho hum.
Apply this patch to a 2.6.30 kernel and rebuild. Voila! And the problem is gone!
I found the DMI_PRODUCT_NAME using dmidecode if you were wondering."
This patch needs hardcoding, if I understand correctly. For example, in this case it requires to set "Q320/P320" in the patch. I don't want to compile my own kernel so I'm unable to test if this works actually, however, I do have Samsung R522 and it's eveident from the output of "xev" or with "lshal -m" that at least Fn+Up/Down (brightness up/down) and Fn+F5 (brightness on/off) keys do not send any events on my laptop too. Is there any way to fix this on Samsung laptops in general, without harcoding each model in the kernel?
Besides, as my quote seems to be contain a patch for the linux kernel, it might be wise to assign this one to the kernel package.
Maybe someone can get this fixed for the upcoming Karmic?
It seems that the problem is related to the keys not sending events. Quoting the above mentioned link:
"After a while I discovered the problem was that some of the fn-keys weren’t sending key release events (easy to see in xev or with lshal -m). Turns out this is a problem with lots of laptop keyboards: look at the thousands of lines of hacks in drivers/ input/keyboard/ atkbd.c in the Linux kernel source. The good news is that this is easy to fix: the Q320 uses exactly the same scancodes as an earlier Samsung laptop. The bad news is that you have to compile your own kernel. Ho hum.
Apply this patch to a 2.6.30 kernel and rebuild. Voila! And the problem is gone!
--- drivers/ input/keyboard/ atkbd.c. old 2009-07-13 00:34:14.000000000 +0100 input/keyboard/ atkbd.c 2009-07-13 00:35:19.000000000 +0100
.driver_ data = atkbd_samsung_ forced_ release_ keys, DMI_SYS_ VENDOR, "SAMSUNG ELECTRONICS CO., LTD."), DMI_PRODUCT_ NAME, "Q320/P320"), forced_ release, forced_ release_ keys,
.ident = "Samsung SQ45S70S",
.matches = {
DMI_ MATCH(DMI_ SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+++ drivers/
@@ -1550,6 +1550,15 @@
},
{
+ .ident = "Samsung Q320/P320",
+ .matches = {
+ DMI_MATCH(
+ DMI_MATCH(
+ },
+ .callback = atkbd_setup_
+ .driver_data = atkbd_samsung_
+ },
+ {
I found the DMI_PRODUCT_NAME using dmidecode if you were wondering."
This patch needs hardcoding, if I understand correctly. For example, in this case it requires to set "Q320/P320" in the patch. I don't want to compile my own kernel so I'm unable to test if this works actually, however, I do have Samsung R522 and it's eveident from the output of "xev" or with "lshal -m" that at least Fn+Up/Down (brightness up/down) and Fn+F5 (brightness on/off) keys do not send any events on my laptop too. Is there any way to fix this on Samsung laptops in general, without harcoding each model in the kernel?
Besides, as my quote seems to be contain a patch for the linux kernel, it might be wise to assign this one to the kernel package.