Hide Forgot
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
This should be done in the kernel, with the module handling the Eeepc using the input layer to push the events to user-space.
(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.
(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?
1-rawnhide kernel 2-F9 upgraded to rawhide 3-Rawhide fresh install which one?
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 :)
(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?
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.....
(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 ;)
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.
Though, looking at it, it should be possible to implement rfkill in the eee driver itself. That would almost certainly be preferable.
The wifi handling code is, it turns out, insane. I'll do a new patch now.
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?
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 :)
(In reply to comment #12) > Created an attachment (id=309502) [edit] > Updated patch > Are you submitting this upstream too?
Once I've got some confirmation that it works, sure :) I don't have an eee.
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!
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.
Should this patch be backported to F9 as well?
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).
(I forgot to mention that the pciehp information was found over on http://www.nathancoulson.com/proj_eee.shtml )
In testing against linux-tip this patch breaks the resume part of suspend to RAM on my EeePC 900...
If you remove the rfkill registration, does it work?
mjg: Yes, if I remove rfkill registration then it works.
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?
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).
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 :)
No, this needs to be done via rfkill. Hang on, let me try to generate a patch.
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.
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?
Regardless if the answer is yes or no, I'll retract my patch ;)
Comment on attachment 319477 [details] Add bluetooth support to eeepc-laptop Obsollete, already handled by rfkill
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?
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 ;)
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.
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 .
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 :)
Adam, You have rfkill-input loaded, right?
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?
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...
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.