Comment 19 for bug 297962

Revision history for this message
Žygimantas Beručka (zygis) wrote :

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
+++ drivers/input/keyboard/atkbd.c 2009-07-13 00:35:19.000000000 +0100
@@ -1550,6 +1550,15 @@
                .driver_data = atkbd_samsung_forced_release_keys,
        },
        {
+ .ident = "Samsung Q320/P320",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Q320/P320"),
+ },
+ .callback = atkbd_setup_forced_release,
+ .driver_data = atkbd_samsung_forced_release_keys,
+ },
+ {
                .ident = "Samsung SQ45S70S",
                .matches = {
                        DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),

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.