Difference between revisions of "Talk:ASUS Eee PC 901"
(→Stock-Kernel 2.26.32: re stock kernel)
(http -> https://aur.archlinux.org)
|Line 40:||Line 40:|
I have created a new wiki entry for the 1000: [[Asus_Eee_PC_1000]]. I also created a package for ACPI events which should supports all the different models. You can find [
I have created a new wiki entry for the 1000: [[Asus_Eee_PC_1000]]. I also created a package for ACPI events which should supports all the different models. You can find [://aur.archlinux.org/packages.php?ID=23318 acpi-eeepc-generic in AUR]. Can anybody test this for me on other models then the 1000? Thank you! :)
--[[User:big_gie|big_gie]] 12:30, 21 January 2009 (EDT)
--[[User:big_gie|big_gie]] 12:30, 21 January 2009 (EDT)
Revision as of 20:36, 24 March 2012
Because it doesn't belong to the necessary parts of the articel (every 901-model should be the same) I would suggest removing it or for the sake of completness of the articel moving it at the end of the articel. If noone objects I will move it at the end in the next few days. -- Rorschach
Stock-Kernel VS. recompiled one
What dependencies do people supposedly need to recompile the stock kernel for? (section Option 1: Compile and customize the stock kernel) I didn't recompile my kernel on my 901 and everything I can think of works fine. I think this section should be changed or clarified to explain why its recommended to recompile.
--Chori 13:29, 23 September 2008 (EDT) There are some patches applied to the kernel source: in particular, to the acpi driver, to the mouse driver, to the rt2860sta driver, to improve them, fix bugs, and add functionality. It's true that you can run ArchLinux on the EEE 901 with just the stock kernel; but it's not optimized for it, and many users have experienced problems. Your point is well-taken, however, I'll clarify that section.
--Andyroid 14:05, 20 April 2009 (EDT) Are all the custom kernel methods really necessary at this point when the 2.6.29 kernel makes them pretty much reduntant? At least I think the stock kernel should be presented as option #1 as it is easier to set up and a lot easier to maintain.
--big_gie 14:10, 20 April 2009 (EDT) @Andyroid: The only thing which might not work out of the box would be, I think, some wireless chips, like the rt2860sta. But these are available in AUR, so stock kernel should work. I agree it should be moved as first option since it is the simpler option. Building a custom kernel would be useful to include all modules in-kernel to speedup boot, which is not the priority when installing.
--Andyroid 14:17, 21 April 2009 (EDT) big_gie: The rt2860sta module is now included in mainline kernel as well. I added that info to the wiki yesterday. Even ACPI, hotkeys, webcam and so forth seems to be working pretty much out of the box (provided that the kernel is updated to 2.6.29). I've yet to try out bluetooth but will do that tonight. Therefore it would make sense to bump the stock kernel option to prime position and move the custom kernel options to a section below. Actually the stock kernel option should probably have its own headline as well as it doesn't make much sense to have it under "customized kernel installation" as it is now. Please let me know if anyone opposes to these changes or I'll try to implement them in a few days.
Apart from renaming the interface from ra0 to wlan0, the stock kernel works fine with rt2860sta - I removed the edit that suggested installing 2.26.30 and marking the kernel an ignored package as it was a) unsubstantiated and b) a needlessly retrograde step.
Jasonwryan 13:06, 23 January 2010 (EST)
--Cordovanblues 22:45, 4 January 2011 (EST) The wiki still has a note at the beginning of the "Installation" section that warns against using the current kernel. Like Jasonwryan I have no problem with the wifi module and the current module, but only after I blacklist !usblp !rt2800pci !rt2x00pci !rt2800usb !rt2x00usb in rc.conf. I was reluctant to alter the wiki, since I am a relatively inexperienced user. Could someone either confirm this and change the wiki or bless me with the power to change it myself?
- I only have to blacklist rt2800pci. Other than that, go for it! Jasonwryan 22:58, 4 January 2011 (EST)
What about the 1000/1000H?
In all the article only the 901 model is commented. In my opinion, as all the things also apply to the 1000/1000H models (I guess) it should be corrected, for example, writing 901/1000/1000H where 901 is.
--Chori 16:08, 9 October 2008 (EDT) There are some subtle differences in the hardware between the 901 and 1000 models. If someone wants to take on highlighting the 1000(H) specific idiosyncrasies, I'd be happy to expand the scope of this wiki page.
Afaik just the bigger display is the difference but I have a 1000H so if you tell me what you think should be different, I'll check it. I could follow this articel without any problems with my 1000H. --Rorschach
The hardware differences might be more subtle than just the screen size. I just got a 1000 (not H nor HA) and started a new thread on the forum for this: http://bbs.archlinux.org/viewtopic.php?pid=476341 We could also merge the 4 pages on EeePCs into one big, or one generic and smaller ones for specific details on each models. What do you think? --big_gie
I have created a new wiki entry for the 1000: Asus_Eee_PC_1000. I also created a package for ACPI events which should supports all the different models. You can find acpi-eeepc-generic in AUR. Can anybody test this for me on other models then the 1000? Thank you! :) --big_gie 12:30, 21 January 2009 (EDT)
Any chance of a summary of the kernels available from: http://robertek.brevnov.net/files/linux/arch eg the git ones?
And why does searching the wiki for 901 result in zero page title matches and zero page text matches?!?
Bluetooth (de)activation on 2.6.32
Hi all, I'm writing in talk because I just tried kernel 2.6.32 on the EEE 901 and I have something to report. I'm actually not using archlinux, I just found this wiki very helpful for my setup, so feel free to ignore this comment (and even delete it) if the situation here doesn't apply to you.
In my case, bluetooth was toggled via an rfkill interface, pretty much like wireless, except that rfkill[bluetooth] = rfkill[wlan+1]:
echo 1|0 > /sys/devices/platform/eeepc/rfkill/rfkill1/state
The problem that I found is that the numbers of the rfkill interfaces sometimes change, therefore I'm using the following script (to be run as root) for bt toggling:
#!/bin/bash # enumerate rfkill devices for rfkillDir in /sys/devices/platform/eeepc/rfkill/rfkill* do # check for bluetooth device if grep -q 'bluetooth' "$rfkillDir/name" then echo "Found bluetooth in $rfkillDir" read state < "$rfkillDir/state" if [ "$state" = "0" ] then echo "State was OFF. Turning ON" echo 1 > "$rfkillDir/state" else echo "State was ON. Turning OFF" echo 0 > "$rfkillDir/state" fi fi done
I'm sorry if this is OT and if it doesn't help you, I just thought that it might. --IngFrancesco 08:11, 29 April 2010 (EDT)