This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 451182 - Fn keys in eeePC not working OOTB. need manual tweaks
Fn keys in eeePC not working OOTB. need manual tweaks
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FedoraMini/Mobility
  Show dependency treegraph
 
Reported: 2008-06-13 04:51 EDT by Carlo Raudino
Modified: 2013-01-10 02:56 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-04 13:32:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Add input support to eeepc hotkey driver (5.01 KB, patch)
2008-06-15 08:58 EDT, Matthew Garrett
no flags Details | Diff
Updated patch (6.87 KB, patch)
2008-06-16 10:03 EDT, Matthew Garrett
no flags Details | Diff
Add bluetooth support to eeepc-laptop (1.07 KB, patch)
2008-10-04 17:08 EDT, Adam McDaniel
no flags Details | Diff

  None (edit)
Description Carlo Raudino 2008-06-13 04:51:47 EDT
Description of problem: FN keys in eeePC don't work out of the box, there is the
need to write down some scripts to handle these events

  
Actual results:
we got working wireless on/off, display to external monitor, volume controls,
with these scripts (just workarounds):
http://fedoraproject.org/wiki/EeePc#ACPI_support_in_Fedora_9

Expected results:
OOTB Acpi support in fedora, without need of manual tweaking
Comment 1 Bastien Nocera 2008-06-13 14:25:40 EDT
This should be done in the kernel, with the module handling the Eeepc using the
input layer to push the events to user-space.
Comment 2 Chuck Ebbert 2008-06-14 04:21:31 EDT
(In reply to comment #1)
> This should be done in the kernel, with the module handling the Eeepc using the
> input layer to push the events to user-space.

I've replaced the preliminary eeepc driver in F9 with the final eeepc-laptop
driver from rawhide/2.6.26.  If that one doesn't work by using the input layer
to push the events then you are asking for a rewrite of the driver.
Comment 3 Chuck Ebbert 2008-06-14 04:22:29 EDT
(In reply to comment #0)
> Description of problem: FN keys in eeePC don't work out of the box, there is the
> need to write down some scripts to handle these events
> 
>   
> Actual results:
> we got working wireless on/off, display to external monitor, volume controls,
> with these scripts (just workarounds):
> http://fedoraproject.org/wiki/EeePc#ACPI_support_in_Fedora_9

Is there any way you can test rawhide to see if it works any better out of the box?
Comment 4 Carlo Raudino 2008-06-14 05:41:50 EDT
1-rawnhide kernel
2-F9 upgraded to rawhide
3-Rawhide fresh install

which one?
Comment 5 Carlo Raudino 2008-06-14 06:57:54 EDT
Tried kernel-2.6.26-0.67.rc6.git1 (rawihide)
reverted tweaks, acpid, etc. So stock fedora setup.

Fn+F1 (suspend) WORKS...also backlight resume (yeah!! very nice)

Fn+F2 (WIFI TOGGLE) NOT WORK... :-( (this is very useful...)

Fn+F3 and Fn+F4 (BACK LIGHT ADJUST) WORK

Fn+F5 (LCD/EXTERNAL MONITOR SWITCH) I don't know if works..because I can't test
it out... My ext monitor is broken

Fn+F6 (originally was for opening terminal in xandros) OBVIOUSLY doesn't
work..This fn is unuseful with stock linux distributions.... I used it in
scripts, to toggle webcam (as mandriva and other distributions do)...so it
should be an idea to let this key toggle webcam....

Fn+F7 (Toggle MUTE) NOT WORK
Fn+F8 (VOLUME DOWN) NOT WORK
Fn+F9 (VOLUME UP ) NOT WORK

Thanks for attention :)
Comment 6 Bastien Nocera 2008-06-14 08:50:59 EDT
(In reply to comment #5)
> Tried kernel-2.6.26-0.67.rc6.git1 (rawihide)
> reverted tweaks, acpid, etc. So stock fedora setup.
> 
> Fn+F1 (suspend) WORKS...also backlight resume (yeah!! very nice)
<Snip>
> Fn+F3 and Fn+F4 (BACK LIGHT ADJUST) WORK
<nip>
> Fn+F7 (Toggle MUTE) NOT WORK
> Fn+F8 (VOLUME DOWN) NOT WORK
> Fn+F9 (VOLUME UP ) NOT WORK

The backlight and suspend keys working is good (I guess this gets through ACPI,
and is captured by hal and passed onto gnome-power-manager). Do the backlight
keys show a popup when in GNOME?

The other keys not working is a bit of a problem, but they're not expected to
work out-of-the-box for the most part.

I checked out the eeepc-laptop driver in the linux-next git tree, and it doesn't
pass those extra keys through the input layer (so the keys aren't visible in
user-space).

Could you check whether you see any error messages in dmesg when using the keys,
or whether the keys work using "xev" while running X?
Comment 7 Carlo Raudino 2008-06-14 09:30:29 EDT
No...I think backlight keys are bios handled...they work also in grub, kernel
booting, etc....
No popup..... 

no xev output for Fn keys and no dmesg ....

because of this, we used acpid and some scripts to handle these events....I
don't remember what we used to read the keyevents.

So... the "lamer" scripts + acpid must continue to exist.... I don't think
someone will handle this events in kernel or with an official rpm.....
Comment 8 Bastien Nocera 2008-06-14 10:11:19 EDT
(In reply to comment #7)
> No...I think backlight keys are bios handled...they work also in grub, kernel
> booting, etc....
> No popup..... 
> 
> no xev output for Fn keys and no dmesg ....
> 
> because of this, we used acpid and some scripts to handle these events....I
> don't remember what we used to read the keyevents.
> 
> So... the "lamer" scripts + acpid must continue to exist.... I don't think
> someone will handle this events in kernel or with an official rpm.....

The kernel module will need some work then. I copied Matthew and Richard that
could help. It would certainly be easier if they had access to an EeePC ;)
Comment 9 Matthew Garrett 2008-06-15 08:58:53 EDT
Created attachment 309396 [details]
Add input support to eeepc hotkey driver

Would be helpful if someone could give this a go - I don't have an eee. The
radio handling is going to be suboptimal until either madwifi gains rfkill
support or ath5k works on this hardware.
Comment 10 Matthew Garrett 2008-06-15 09:01:49 EDT
Though, looking at it, it should be possible to implement rfkill in the eee
driver itself. That would almost certainly be preferable.
Comment 11 Matthew Garrett 2008-06-16 09:33:14 EDT
The wifi handling code is, it turns out, insane. I'll do a new patch now.
Comment 12 Matthew Garrett 2008-06-16 10:03:08 EDT
Created attachment 309502 [details]
Updated patch

This cleans up the rfkill handling. An rfkill device is registered (and so the
wlan entry is removed from sysfs) and the wireless button generates KEY_WLAN.
If rfkill-input is loaded (which really ought to be the default, but doesn't
seem to be yet?) then the default behaviour will be for the state to be toggled
on button presses. Again, entirely untested beyond building. Could someone try
this on real hardware?
Comment 13 Carlo Raudino 2008-06-16 13:26:00 EDT
Can you build this patch in a kernel build on koji?  madwifi isn't compiling in
2.6.26....I'm searching a solution for this...so you have all the time you want :)

Comment 14 Chuck Ebbert 2008-06-16 22:48:17 EDT
(In reply to comment #12)
> Created an attachment (id=309502) [edit]
> Updated patch
> 

Are you submitting this upstream too?
Comment 15 Matthew Garrett 2008-06-17 05:50:31 EDT
Once I've got some confirmation that it works, sure :) I don't have an eee.
Comment 16 Carlo Raudino 2008-06-17 07:58:55 EDT
I managed to install madwifi in 2.6.26, and now I'm using only the 2.6.26 git2
kernel..... I can't patch and compile the kernel myself, because my home pc is
broken (sigh) and the celeron cpu in my eeepc will burn in compiling it....

Can anyone build a testing kernel rpm for me? so I can test out your changes...

thankyou all for the great work you are doing in eeepc support...I'm sure this
will be helpful for us!
Comment 17 Matthew Garrett 2008-08-04 13:32:52 EDT
Added to Rawhide kernel, should hit the archive later today. Verified to work on a 900, but should be fine on the 700 series as well. Wifi now handled by rfkill (make sure that the rfkill-input module is loaded). Keys are sent via the input layer.
Comment 18 Chuck Ebbert 2008-08-12 13:06:16 EDT
Should this patch be backported to F9 as well?
Comment 19 Sitsofe Wheeler 2008-09-21 07:02:31 EDT
Chuck: possibly although the wifi patch changes the nature of how things worked a bit so that my be an unwanted surprise (it is no longer possible to disable wifi before shutdown and expect it to be off when you next boot the machine as it will be toggled back on during boot).

On a related note, if you do decide to use this patch make sure you boot the kernel with the pciehp.pciehp_force=1 kernel parameter (at least on an Eee 900). Failure to do so will result in the inability to start the wifi after it has been stopped once (e.g. by hitting the wifi toggle hotkey while the wifi is on).
Comment 20 Sitsofe Wheeler 2008-09-21 07:03:36 EDT
(I forgot to mention that the pciehp information was found over on http://www.nathancoulson.com/proj_eee.shtml )
Comment 21 Sitsofe Wheeler 2008-10-04 10:04:05 EDT
In testing against linux-tip this patch breaks the resume part of suspend to RAM on my EeePC 900...
Comment 22 Matthew Garrett 2008-10-04 10:30:13 EDT
If you remove the rfkill registration, does it work?
Comment 23 Sitsofe Wheeler 2008-10-04 11:47:29 EDT
mjg:
Yes, if I remove rfkill registration then it works.
Comment 24 Matthew Garrett 2008-10-04 12:03:54 EDT
Ok. Can you readd the rfkill registration and then edit net/rfkill/rfkill.c and remove the

        .suspend        = rfkill_suspend,
        .resume         = rfkill_resume,

lines and see if that works?
Comment 25 Sitsofe Wheeler 2008-10-04 12:44:47 EDT
Readding the registration and commenting out the above lines allows suspend and resume to work but trying to toggle the wifi power via the hotkey no longer works (even before suspending).
Comment 26 Adam McDaniel 2008-10-04 17:08:59 EDT
Created attachment 319477 [details]
Add bluetooth support to eeepc-laptop

The following patch adds bluetooth toggle support to eeepc-laptop.ko, through /sys/devices/platform/eeepc/bt (the same way that the deprecated eeepc-acpi module did.)

This patch is based upon the original import of the eeepc-laptop driver, committed e59f87966adef2cb03d419530e3ade5159487d6d by Eric Cooper at 2008-03-13 for v2.6.26-rc1. 

It straddles code modified by the latest patch attached to this bug (add rfkill wlan support), but there's only one chunk which adds just two lines. Very easy to apply by hand :)
Comment 27 Matthew Garrett 2008-10-04 17:27:00 EDT
No, this needs to be done via rfkill. Hang on, let me try to generate a patch.
Comment 28 Matthew Garrett 2008-10-04 17:39:22 EDT
Wait, I already added code to control bluetooth via rfkill. Can you check whether it works? It should be in /sys/class/rfkill, with the type set to bluetooth.
Comment 29 Adam McDaniel 2008-10-04 18:54:07 EDT
Can do. However shouldn't there be an equivalent line like: "rfkill_allocate( &device->dev, RFKILL_TYPE_BLUETOOTH )" somewhere in eeepc-laptop.c, too?

For example, the 1000 has 4 special hotkeys (acpi codes 0x1a..0x1d) which some users have customized to provide bluetooth enable/disable.

Shouldn't applying something like that be handled by eeepc-laptop?
Comment 30 Adam McDaniel 2008-10-04 18:56:02 EDT
Regardless if the answer is yes or no, I'll retract my patch ;)
Comment 31 Adam McDaniel 2008-10-04 18:57:13 EDT
Comment on attachment 319477 [details]
Add bluetooth support to eeepc-laptop

Obsollete, already handled by rfkill
Comment 32 Matthew Garrett 2008-10-04 19:05:38 EDT
        if (get_acpi(CM_ASL_BLUETOOTH) != -1) {
                ehotk->eeepc_bluetooth_rfkill =
                        rfkill_allocate(&device->dev, RFKILL_TYPE_BLUETOOTH);

is already in there in the Rawhide kernel?
Comment 33 Adam McDaniel 2008-10-04 19:50:02 EDT
You'd know better than I. I'm coming from the ubuntu side, I'm just checking in because I'm interested in the rfkill/wlan patch you developed.

Incidentally, I had the same problem described in comment #21 last night, and the fix from #24 did appear to solve it. However, Sitsofe's comment #25 is still a problem (Fn-F2 wifi key doesn't toggle wifi). BUT, wifi does correctly respond if I manually inject 0 or 1 to "/sys/class/rfkill/.../state" type wlan.

There appears to be a disconnect, possibly with nothing actually using NOTIFY_WLAN_ON, or KEY_WLAN in 'static struct key_entry eeepc_keymap[]'

> is already in there in the Rawhide kernel?

That's a very good question. Google and I couldn't find a git repo for rawhide's kernel.  If you can direct me where to grab it, I can probably find the answers to my problem myself ;)
Comment 34 Matthew Garrett 2008-10-04 20:19:31 EDT
Fedora kernel is kept in CVS - patches are at http://cvs.fedoraproject.org/viewvc/rpms/kernel/devel . The key will do nothing unless you have the rfkill-input module loaded. We've tracked down the issue with it failing to work on boot - I'm getting a fix into rfkill upstream now.
Comment 35 Sitsofe Wheeler 2008-10-05 05:53:06 EDT
The "broken" wifi toggling hotkey turned out to be due to rfkill hotkeys not working until five minutes after the system has booted. Matthew has already posted a patch to fix this on http://lkml.org/lkml/2008/10/4/151 .
Comment 36 Adam McDaniel 2008-10-05 16:18:08 EDT
That's odd. I'm probably OTL but I left my EeePC 900 online for a few hours last night. Even with the 5-minute known issue, Fn-F2 still never triggered wireless. (I was trying roughly every 30 min.)

I saw [PATCH v3] on the LKML, I'll give it a shot next, plus the unique bits still in fedora's linux-2.6-eeepc-laptop-update.patch and linux-2.6-wireless-pending.patch.

I assume that if a patch is committed to Fedora's CVS server, it's been signed-off and tested by Fedora's team and they're promoting it for linux-tip?

Thx :)
Comment 37 Matthew Garrett 2008-10-05 16:29:53 EDT
Adam,

You have rfkill-input loaded, right?
Comment 38 Adam McDaniel 2008-10-05 17:44:48 EDT
Sorry, I forgot to mention that I did. However it didn't autoprobe on bootup like rfkill did c/o the eeepc-laptop dependency.

Shouldn't eeepc-laptop also depend on rfkill-input?
Comment 39 Sitsofe Wheeler 2008-10-06 00:31:19 EDT
Adam:
I believe someone posted a patch for the rfkill dependency on http://lkml.org/lkml/2008/9/15/159 . I wouldn't have seen module issues as I don't build modules for my kernel...
Comment 40 Carlo Raudino 2008-10-10 04:41:29 EDT
I'm testing out the kernel 2.6.27.0-3 ...

rfkill-input and ath5k need manual modprobe. So I hope they will be automagically modprobed soon...

They SEEM to work... network manager doesn't like rfkill...it's unable to reload wifi...

maybe I'll try a rawhide network manager release... I'm with the fedora 9 stable one.

Note You need to log in before you can comment on or make changes to this bug.