fn-Keys (fn-F10 thru fn-F12) on notebook stop working after kernel upgrade
 

Hi, I recently upgraded my Fedora 12 kernel to find my fn keys from fn-F10 thru to Fn-F12 no longer work. These keys control the following:
fn-F10 (Webcam)
fn-F11 (Wireless radio)
fn-F12 (Bluetooth)

My problem is I cannot activate the bluetooth device, and this notebook (Clevo W765T) does not have any hardware or bios options to force the bluetooth on.

Fortunately the camera and wireless radio are on by default, so that is not a major issue, but it would be nice if these would work also.

The kernel that worked was Fedora 2.6.31.5-127.fc12.i686.PAE
while all the kernels since then have broken the keyboard fn-Key.

The output from lsusb when using the 2.6.31.5-127.fc12.i686.PAE kernel is:


# lsusb
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 003: ID 5986:0241 Acer, Inc
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 062a:0000 Creative Labs Optical mouse
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 147e:2016 Upek Biometric Touchchip/Touchstrip Fingerprint Sensor
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 002: ID 1410:2420 Novatel Wireless


The information from dmesg for the same kernel is:

# dmesg
usb 7-2: new full speed USB device using uhci_hcd and address 3
usb 7-2: New USB device found, idVendor=0a12, idProduct=0001
usb 7-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 7-2: configuration #1 chosen from 1 choice
Bluetooth: Core ver 2.15
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: Generic Bluetooth USB driver ver 0.6
usbcore: registered new interface driver btusb
Bluetooth: L2CAP ver 2.13
Bluetooth: L2CAP socket layer initialized
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bridge firewalling registered
Bluetooth: SCO (Voice Link) ver 0.6
Bluetooth: SCO socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM ver 1.11

I thought the following information might also help?

/var/log/messages (output when enabling the bluetooth adapter)

Mar 17 10:15:11 localhost kernel: usb 7-2: new full speed USB device using uhci_hcd and address 8
Mar 17 10:15:11 localhost kernel: usb 7-2: New USB device found, idVendor=0a12, idProduct=0001
Mar 17 10:15:11 localhost kernel: usb 7-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Mar 17 10:15:11 localhost kernel: usb 7-2: configuration #1 chosen from 1 choice
Mar 17 10:15:11 localhost bluetoothd[3885]: Bluetooth daemon 4.58
Mar 17 10:15:11 localhost bluetoothd[3886]: Starting SDP server
Mar 17 10:15:11 localhost bluetoothd[3886]: Parsing /etc/bluetooth/network.conf failed: No such file or directory
Mar 17 10:15:11 localhost bluetoothd[3886]: bridge pan0 created
Mar 17 10:15:11 localhost bluetoothd[3886]: Parsing /etc/bluetooth/input.conf failed: No such file or directory
Mar 17 10:15:11 localhost bluetoothd[3886]: Parsing /etc/bluetooth/audio.conf failed: No such file or directory
Mar 17 10:15:11 localhost bluetoothd[3886]: HCI dev 0 registered
Mar 17 10:15:11 localhost NetworkManager: <WARN> device_creator(): /sys/devices/virtual/net/pan0: couldn't determine device driver; ignoring...
Mar 17 10:15:11 localhost bluetoothd[3886]: HCI dev 0 up
Mar 17 10:15:11 localhost bluetoothd[3886]: Starting security manager 0
Mar 17 10:15:11 localhost bluetoothd[3886]: probe failed with driver input-headset for device /org/bluez/3885/hci0/dev_00_22_A5_32_90_A2
Mar 17 10:15:11 localhost bluetoothd[3886]: Adapter /org/bluez/3885/hci0 has been enabled


/var/log/messages (output when disabling the bluetooth adapter)

Mar 17 10:17:40 localhost kernel: usb 7-2: USB disconnect, address 8
Mar 17 10:17:40 localhost kernel: btusb_intr_complete: hci0 urb f09c9300 failed to resubmit (19)
Mar 17 10:17:40 localhost kernel: btusb_bulk_complete: hci0 urb f09c9700 failed to resubmit (19)
Mar 17 10:17:40 localhost kernel: btusb_bulk_complete: hci0 urb f09c9f00 failed to resubmit (19)
Mar 17 10:17:40 localhost kernel: btusb_send_frame: hci0 urb f00a0700 submission failed
Mar 17 10:17:40 localhost bluetoothd[3886]: HCI dev 0 down
Mar 17 10:17:40 localhost bluetoothd[3886]: Adapter /org/bluez/3885/hci0 has been disabled
Mar 17 10:17:40 localhost bluetoothd[3886]: Stopping security manager 0
Mar 17 10:17:41 localhost bluetoothd[3886]: HCI dev 0 unregistered
Mar 17 10:17:41 localhost bluetoothd[3886]: Unregister path: /org/bluez/3885/hci0
Mar 17 10:17:41 localhost NetworkManager: bluez_manager_bdaddr_removed_cb: BT device 00:22:A5:32:90:A2 removed
Mar 17 10:17:41 localhost dbus-daemon: Rejected send message, 2 matched rules; type="error", sender=":1.41" (uid=500 pid=2034 comm="bluetooth-applet) interface="(unset)" member="(unset)" error name="org.freedesktop.DBus.Error.UnknownMethod" requested_reply=0 destination=":1.78" (uid=0 pid=3885 comm="/usr/sbin/bluetoothd))
Mar 17 10:18:11 localhost bluetoothd[3886]: bridge pan0 removed
Mar 17 10:18:11 localhost bluetoothd[3886]: Stopping SDP server
Mar 17 10:18:11 localhost bluetoothd[3886]: Exit



I have tried many possible solutions to resolve this, and all have failed. I have tried to use xev and various other keyboard mapping tools such as xkeycaps to try and remap the keyboard, but can't get this to work.

Any help is welcome...

for great justice...
 

bumping this thread, i have the exact same problem with fn-f10, fn-f11, and fn-f12 on a (Clevo D900F based) Sager 9280

appreciation to who (helps) pin(s) this down. I'm about to return the notebook because of this.

Also of note,

debian squeeze/sid here, linux-image-2.6.32-trunk-amd64
Fn-F1[012] keys don't work

ubuntu karmic, stock kernel
Fn-F1[012] keys DO work.

maybe it's a kernel option? i can't find a package that seems to care about bios/usb toggle hotkeys.

not hotkeys, not hotkey-setup, nothing.

what am I (are we) missing??

thanks in advance,
-m

In desperation I copied the same kernel configuration for the kernel that works, and rebuilt the kernel using the latest source etc and the configuration from the kernel that works. This did not help, so it looks like something in the kernel source changed, not one of the configuration options.

Perhaps this needs to be posted on the Kernel list?

well, before bothering the already wildly popular LKML, it's best if we nail down exactly what the problem is, so it isn't presented as "we don't know what it is, please fix it", since they won't necessarily know (or care) what it is either.

On the other hand, if we can nail down exactly what the problem is, and (assuming it's really a kernel problem) we hit LKML with "This is the specific problem, please fix it", then it stands a far better chance of being fixed.

i'm no further to finding a solution myself. I'm yet to compile the kernel again in search for the answer, but when i do, i'll post my results, if they differ.

Another thing to try (which I can't atm) is diffing the working kernel you have (probably a /boot/config-2.6.something.gz file) with the kernel you built using the old kernel's config (probably available in /proc/config.gz, or something) and just making sure indeed all options match.

If all the options -do- match, perhaps it's a) not a kernel difference, but a kernel-related userland difference (difference in initrd maybe?), or b) a module that isn't loading which should?

If you can inspect the contents of the old (working) kernel's initrd and the new (non-working) one's initrd, maybe there's a difference in there somewhere too?

also try comparing sysctl settings. Is it possible that identical kernel configs are fine, but the -settings- of some config somewhere in the kernels runtime is different and thus disabling it?

shooting in the dark,
-m

i'm beginning to agree with you that this is some kernel regression problem.

I noticed you are/were using fedora, having problems between an older and a newer kernel..

I've seen the exact same problem on a newer version under debian (2.6.32-trunk-amd32), and the problem goes away on the stock debian 5 (lenny) kernel 2.6.26-2-amd64..

the same is true on ubuntu.. since the commonality is the kernel between all three distros, it appears it is indeed related.

one hint i've got is "rfkill" might have something to do with it. rfkill is a module used for killswitching wifi. I don't know about bluetooth and whatever else, but i wonder if that module might be related to the problem.

more pokingaroundery required i guess.

I tried (for a 2nd time) to re-compile the kernel, double checking that the .config files from the working kernel where identical to the version I was about to compile. This still did not help.

As far as the rfkill option goes, I have tried to poke around with that, but all I get is the ability switch the wifi radio off/on. The bluetooth module is not affected by the same function, as it is not integrated into the wifi radio, but is a separate piece of hardware (factory option). The other strange thing that I have noticed, with both the working and non-working kernels, is that xev doesn't detect the fn-F10 thru fn-F12 keypress...

getting a little closer,

I've narrowed down that the difference is between 2.6.31 and 2.6.32.

I haven't narrowed down -what- it is, but ubuntu karmic koala ships with 2.6.31 and the fn-keys work, and 2.6.32 is the latest available in debian, and it doesn't work there..

so when i get another chance, i'll check the changelog between the two versions and see if there's a clue maybe.

-m

I concur, Fedora 12 also ships with the 2.6.31 kernel, and as soon as I ran the upgrade to 2.6.32 kernel, things went wrong.
I'll also see what I can dig up re the changelog.

sigh
 

I'm running out of time to return my notebook.

but even if i'd found the fix for this, there's still the lack of bios upgrade for my dual-headed problem

i notice there's a lot of happy sager/clevo users on the ubuntu forums, using 2.6.31.. when they get their shiny new upgrades to 10.04, i'm sure they'll come across this thread, since they'll undoubtedly come across this issue.

hope someone finds the answer. =(

sigh, well
 

i didn't have the heart to send it back.

problem persists in 2.6.33 as well. I'm still not closer to an answer. according to (debian package named) esekeyd's "/usr/bin/keytest", the only keys to register are the volume fn keys, though GNOME seems to see the brightness fn keys too. fn-f10 thru fn-f12 still useless.

=(

found a thread about bios versions: http://forum.notebookreview.com/show...=402119&page=9

but i seem to have the latest BIOSes already installed. so that's seems like a dead end.

wtf

I have since discovered that the Kernel regression goes back into the 2.6.31.12-174.2.22-fc12 version on Fedora 12. I am trying to see if I can find a the kernel for Fedora after 2.6.31.5-127.fc12 (which works), and slowly work my way through the various versions until I find the one that breaks the fn10 to fn12 keys.

oh cool!

ok, debian doesn't have a .31 in their repos, so i've grabbed 2.6.31.12 from kernel.org instead.. they'll have the intermediate versions too. if i have the probelm in 2.6.31.12 stock, i'll work my way backwards..

meet ya in the middle i guess.

cheers,
-m

Oh no! I have discovered that the fn-F1 (to lock the touch pad) has stopped working on the latest kernel 2.62.32-11-99.fc12 |-(

I'll need to try and go back to previous kernels to see when this one broke. I'll also test all the other keys while I am about it.

Bluetooth
 

I noticed your post while Googling and was wondering what I could do to help? This problem is affecting my NP9850/M980nu. I would love to have the bluetoothey goodness, but the Fn+F12 key is not operational. I am using 10.04.

On my Windows partition, it's identified as being on:

Port_#0005.Hub_#0001

So, it seems to me that this button "plugs in" the device. Is there a way to activate it via software?

I'm not geek enough to know full well what to do, but I am geek enough to work at it if people give me the directions.

R/S,
Indymaynard

I have not yet had a chance to try and compile any of the 2.6.31 kernels yet, so if you feel that you could tackle this, it would help.

Regards

Indymaynard, just a thought though, if you can see the device, does it show up using lspci or lsusb? If so then the problem is different to what we are experiencing on this thread.

Interesting. 2.6.32-22 worked for me. It allows me to use all of the fn+ buttons on the keyboard. MY BLUETOOTH EVEN WORKS!! It's really cool to be able to control the computer locking and unlocking with your phone. Did 32-22 fix you guys? The only major thing left on my machine is the fingerprint strip, but I bet it's already been solved. I'll search for that in the future.

hey indymaynard,

would it be possible for you to attach or paste a file in your /boot folder to this thread?

the file is probably called /boot/config-2.6.32-22

or something like that.

Alternatively, there might be a file called /proc/.config.gz or /proc/config.gz that would do as well..

I'm basically looking for the specific kernel options used to build the kernel you're running. This file contains those options, so it would be supremely helpful.

thanks,
-m

/boot/config-2.6.32-22-generic
 

Okay. /boot/config-2.6.32-22:

I hope it helps. I love having the full functionality.

As of 2010/05/19, Fedora 12 does not have a 2.6.34 kernel available from the various update repositories, so I have compiled one from source tarball available at kernel.org.

IT WORKS!!!! All the fn-keys work as required 8-)

So it looks like what ever regression existed in the previous kernels have been fixed.

great news!!

can you post your /boot/config-2.6.34-whatever too?

thanks,
-m

Here it is, but I did not make any major changes to it except for compiling in a few of the newer options as modules that don't exist under the older kernel.

If you are trying to narrow down the option that fixes the fn-key problem, I'd be interested in knowing what it is.

Regards

Hi Indymaynard, did you manage to resolve your fingerprint strip issue?

I tried the fingerprint-gui stuff and that works, so it looks like the hardware is working, but the stuff that is released as standard with Fedora 12 is not working with the UPEK fingerprint reader. I think I might just open a new thread for that if I don't find one that is already open. (I'd like to use the gdm integrated software instead of hacking PAM and all the other changes that need to be made.)

I haven't even messed with it. I've been a little busy, but I had seen that drivers for the UPEK strip were available right from the UPEK website. http://www.upek.com/ Maybe the software doesn't recognize this driver? Maybe no one has really worked on this one? I don't know. All I know for sure is that I can happily report not booting into Windows for more than a week. I'm considering seeing if WINE can run Fallout 3 and then never having to run Windows again. It would be convenient.

I found the UPEK drivers are installed and working, but gdm, su, sudo etc. don't seem to recognise it once a finger print has been recorded against the user account. Perhaps the problem is not with those apps, but with PAM?

this indeed works in 2.6.34. and it seems like it was a deeper problem than just fn-f1[012].

along with the fix for those keys, it seems suspending on lid actions is also back in business..

whatever was fixed was bigger than it seemed to me. Yay, but i'm kinda curious as what it was to begin with.

as for the UPEK fingerprint scanner. This is indeed a separate problem. You will find it being tackled elsewhere in the community.

(e.g. http://swiss.ubuntuforums.org/showthread.php?p=9164088)

the symptoms in this thread do indeed seem to be functionally solved for the topic's problems. Even though the root cause never was determined.

oh well, better working than not.. til it breaks again!

-m