You are not logged in.

#26 2009-02-04 19:42:34

kiberlynx
Member
Registered: 2009-02-03
Posts: 5

Re: Arch on Asus EeePC 1000

<i>  I changed the default config file in 0.7.0: Now COMMANDS_SCREEN_OFF (which is Fn+F7) will call the bluetooth toggle script. Please verify that you use the new configuration file (check pacsave or pacnew files) </i>

You're right, I'm using 0.6.3-1, How do you get yaourt to inform you that an aur package was updated, I was expecting it when I did -Su but seems to mirror pacman exactly, and not check aur tongue
I'll check 0.7.0 when I get the time, soon.

<i> I would say it is a wicd problem, because I can open wicd, click "connect" and it will reconnect correctly. Have you tried networkmanager? </i>

It's worse for me, when I open wicd it doesn't find any networks, and if I run
#iwlist ra0 scan
I get no results, even when I'm sure there are APs available. Only cured with a reboot so far.
And I definately am not thinking about trying network manager, it's way too inefficient for now, and yet not all that convenient has it will be when it's stable.


When I said that I'd really like to toggle the camera and the cardmgr, to save power, but am not sure how to do it, I wasn't talking about rfkill, because obviously they don't have rf (radio frequency), but they do have some kind of acpi on/off control, which would be useful once they do consume power when on and are seldom used.

About the pdf reading setup, that's a very nice setup you got going, never thought of that, now only if it didn't crash my Xorg. Yours works fine?

about the evdev synaptics conundrum, I skimmed trough Xorg.0.log, and got a bit confused as to which driver is actually using. check it here:
http://pastebin.com/m4ae330fa
and the Xorg.conf here:
http://pastebin.com/m4ccb1932
And I am able to toggle the touchpad on or off, and use all elantech functions except for zooming and rotating, although that maybe lack of software support.

About the fan, yes the bios algorithm in all laptops totally suck, and keeps the fan running, unnecessarily draining precious watts/hr from the battery that should be used for something else. And the only reason that eee-control hasn't yet build for me is because i2c-python-something is: file not found, and is a dependency of eee-control.
But i definitely want some form of fan control.

about kernels, what did you think of the one in my last post.
Could you describe in broad strokes what did and didn't you include in yours, and would you recommend it? Is it fast and furious? lol!

Offline

#27 2009-02-04 20:13:28

big_gie
Member
Registered: 2005-01-19
Posts: 637

Re: Arch on Asus EeePC 1000

kiberlynx wrote:

How do you get yaourt to inform you that an aur package was updated, I was expecting it when I did -Su but seems to mirror pacman exactly, and not check aur tongue

I don't know about yaourt... I don't use it :S

kiberlynx wrote:

It's worse for me, when I open wicd it doesn't find any networks, and if I run
#iwlist ra0 scan
I get no results, even when I'm sure there are APs available. Only cured with a reboot so far.

That's weird... Which kernel are you using?

kiberlynx wrote:

When I said that I'd really like to toggle the camera and the cardmgr, to save power, but am not sure how to do it, I wasn't talking about rfkill, because obviously they don't have rf (radio frequency), but they do have some kind of acpi on/off control, which would be useful once they do consume power when on and are seldom used.

Do they have an on/off control? If they are not in use, they should _not_ drain any power. Maybe when their respective module gets loaded they are initialized, but after that they should just be idle. Have you used powertop to check this? I never saw uvcvideo in powertop...

kiberlynx wrote:

About the pdf reading setup, that's a very nice setup you got going, never thought of that, now only if it didn't crash my Xorg. Yours works fine?

Well it worked when I created the script. I'm using compiz now (executing it from 'compiz-manager' instead of from 'fusion-icon' fixed a problem on mine) and when I tried it last week it did crash also!! Damn tongue But its not vital anyway....

kiberlynx wrote:

about the evdev synaptics conundrum, I skimmed trough Xorg.0.log, and got a bit confused as to which driver is actually using. check it here:
http://pastebin.com/m4ae330fa
and the Xorg.conf here:
http://pastebin.com/m4ccb1932
And I am able to toggle the touchpad on or off, and use all elantech functions except for zooming and rotating, although that maybe lack of software support.

Looks like X is not using evdev: it is using the synaptics driver:

http://pastebin.com/m4ae330fa wrote:

(II) UnloadModule: "evdev"
(EE) PreInit returned NULL for "VX Nano"
(II) evaluating device (synaptics)
(II) XINPUT: Adding extended input device "synaptics" (type: TOUCHPAD)
(--) synaptics touchpad found
(II) config/hal: Adding input device ETPS/2 Elantech Touchpad
(**) ETPS/2 Elantech Touchpad: always reports core events
(**) ETPS/2 Elantech Touchpad: Device: "/dev/input/event9"
(II) ETPS/2 Elantech Touchpad: Found 3 mouse buttons
(II) ETPS/2 Elantech Touchpad: Found x and y relative axes
(II) ETPS/2 Elantech Touchpad: Found x and y absolute axes
(II) ETPS/2 Elantech Touchpad: Found absolute touchpad
(II) ETPS/2 Elantech Touchpad: Configuring as mouse
(**) ETPS/2 Elantech Touchpad: YAxisMapping: buttons 4 and 5
(**) ETPS/2 Elantech Touchpad: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) XINPUT: Adding extended input device "ETPS/2 Elantech Touchpad" (type: MOUSE)

and:

http://pastebin.com/m4ccb1932 wrote:

Section "InputDevice"
   Identifier  "synaptics"
   Driver      "synaptics"
   Option      "Device"           "/dev/psaux"
...

You don't even have xorg.conf set to use evdev... tongue So that's why you can toggle it on and off. And I want a Nano VX too!!! big_smile

kiberlynx wrote:

About the fan, yes the bios algorithm in all laptops totally suck, and keeps the fan running, unnecessarily draining precious watts/hr from the battery that should be used for something else.

I agree... I still prefer to be on the safe side by not playing with it too much. The battery on the 1000 is still pretty good wink

kiberlynx wrote:

And the only reason that eee-control hasn't yet build for me is because i2c-python-something is: file not found, and is a dependency of eee-control.
But i definitely want some form of fan control.

Then that's another (packaging) problem smile

kiberlynx wrote:

about kernels, what did you think of the one in my last post.
Could you describe in broad strokes what did and didn't you include in yours, and would you recommend it? Is it fast and furious? lol!

Oups sorry I did not see that post smile I build my own kernel. Right now I'm using 2.6.28.3. I'm patching the Arch's stock PKGBUILD (see http://bugs.archlinux.org/task/12384?pr … pened=1928 ) so I can have a custom kernel side by side with Arch's. What I did was to build all drivers needed in-kernel. That way you don't need to load the modules, so should be a faster boot time. I posted my config file on the wiki (http://pastebin.com/f32e1c5d3)  I also applied 2 patches so bluetooth toggles work. See http://code.google.com/p/acpi-eeepc-gen … /Bluetooth

The kernel26-eee901 config has some difference from mine. You can see the diff here: http://pastebin.com/m1354be83 Too many to comment smile
On mine, I only have a couple of modules loaded. I did not included them in the kernel image because I wanted to be able to remove them, for example the uvcvideo. All the rest is built in.

As for the patches included in kernel26-eee901, you have:
eee_patch1.patch: seems to make it possible to send events to Xorg. If so, I don't think its that useful.
eee_patch2.patch: seems related to rfkill switches for wlan and bluetooth. I don't have this, and it works. But maybe it can solve some problem... I don't know where it comes from.
eee_patch3.patch: I don't know also where it comes from...

I'm waiting eagerly for 2.6.29 which should include the two patches for bluetooth, but most importantly, kernel mode setting!

Offline

#28 2009-02-04 22:28:49

Pox
Member
From: Melbourne, AU
Registered: 2007-10-04
Posts: 66

Re: Arch on Asus EeePC 1000

I'm using kernel26-eee901 (customised with acpi procfs, joystick support) with eee-control (installed hotkey-setup from aur as it seemed to be an unspecified dependency?) on a 1000H, and everything's working great - all I had to do to get things the way I wanted was to add the codes for volume control and sleep to xmodmap.  All the other hotkeys are properly handled by eee-control smile

Also, I'm not sure whether it's .29, the staging wifi driver or something else, but I can now suspend and resume without disabling wifi, and it's back up immediately - with zen-eee I had to disable the wireless or it wouldn't resume.

Offline

#29 2009-02-04 23:01:11

Blind
Member
From: Desert mountain
Registered: 2005-02-06
Posts: 386

Re: Arch on Asus EeePC 1000

big_gie wrote:

As for the patches included in kernel26-eee901, you have:
eee_patch1.patch: seems to make it possible to send events to Xorg. If so, I don't think its that useful.
eee_patch2.patch: seems related to rfkill switches for wlan and bluetooth. I don't have this, and it works. But maybe it can solve some problem... I don't know where it comes from.
eee_patch3.patch: I don't know also where it comes from...

I'm waiting eagerly for 2.6.29 which should include the two patches for bluetooth, but most importantly, kernel mode setting!

eee_patch1 is important if you want to get your silver keys working under xorg.
The patches are provided by a kernel hacker on lkml (see the kernel26-eee901 package in AUR for URLs).

Offline

#30 2009-02-04 23:19:44

big_gie
Member
Registered: 2005-01-19
Posts: 637

Re: Arch on Asus EeePC 1000

Ok thanx smile
Let's hope they will be merge in .29...

http://lkml.indiana.edu/hypermail/linux/kernel/0901.2/01829.html wrote:

They are now in git://git.iksaif.net/acpi4asus.git acpi4asus and I'll re-send
them soon to Len because this serie is a litle outdated now that the drivers
have been moved into drivers/platform/x86/ .

Maybe a git version will even be more up to date!

When you say that patch 1 is needed to make the silver keys work under xorg, what do you mean? My silver keys works with vanilla 2.6.28: they are controlled by acpid.

Offline

#31 2009-02-05 00:36:19

Blind
Member
From: Desert mountain
Registered: 2005-02-06
Posts: 386

Re: Arch on Asus EeePC 1000

The patches were not included in 2.6.29-rc3 (they applied clean in my package)

If the events subsystem is turned off, evdev reports the silver keys...
Again, please be aware that the acpi /proc/acpi/event subsytem is deprecated, so I see my buttons-eee package as work towards the future (although I am sure somebody else will come up with something better wink). But I have no problem with enabling the subsystem. Can you send me an updated PKGBUILD from your suggested changes to the current stock kernel PKGBUILD via mail?
BTW, I noticed it doesn't make much of a difference if you compile the drivers as modules or not when it comes to boot time, because of the udev scripts that take some time. That is why I made everything module - was just trying to be consistent smile

I would like to update the kernel-eee901 package with the next rc.

Last edited by Blind (2009-02-05 00:36:48)

Offline

#32 2009-02-05 04:11:23

big_gie
Member
Registered: 2005-01-19
Posts: 637

Re: Arch on Asus EeePC 1000

I have uploaded a new patch for 2.6.28.2-1 on the bug report. See http://bugs.archlinux.org/task/12384#comment38836

So compiling modules in-kernel is not faster... Are you sure? I think I see a difference between Arch's and my own. But then it could be because I compile my kernel with:
CFLAGS="-march=prescott -Os -pipe -fomit-frame-pointer"
It could also be because it is my own and I have a strong bias toward it... wink

Offline

#33 2009-02-06 07:08:49

kiberlynx
Member
Registered: 2009-02-03
Posts: 5

Re: Arch on Asus EeePC 1000

Hey, why don't we join efforts and simplify eee-any support on arch, by making a eee-any kernel and buttons support.

Big_gie you could take your expertise on eee-buttons and try to apply it to the new method Blind describes so that is generic to all eee's and easy to install

Also we should all pitch in and create a eee-generic optimized kernel, with specific optimizations for each model through dmidecode detection has implemented by Big_gie on acpi scripts
I also think that including support for eee-control ia a must, is it just me?

Finally we should clean up all the clutter in the wiki so that we get a single crystal clear eee-arch manual that fits all models and reduces the current mess that it is, so that newbies feel right at home. (May everyone else not have to go trough what we do to get our eee's optimized)

P.S.  @Blind: I'm a long-time Gentoo user, just recently switched, because of miserable  KDE4 support, and so I've been compiling my own kernels since 5 years or so on every computer I came across, and let me tell you:
Linux is a monolithic kernel Modules were created for flexibility not performance, and from experience I can assure you support in kernel is faster than module loading, definitely!
What we should do is to get the best of both worlds, like I always did with Gentoo, which is build a robust monolithic small kernel which has all required functionality required (with all our needed patches) and boots really fast (udev must not run any kind of detection on boot, we got to figure out how this is done - I'm pretty sure gentoo did that), and everything else that might be usefull like useful filesystems other than ext3/4 and vfat, and usb modules and other usefull stuff, as well as wireless modules and other stuff that needs to be reloaded once in a while, and we make them as modules so that later on, we can have a flexible system but without bloat through udev and modprobe.

P.P.S.  @Big_gie: you're right I'm an idiot and I'm using synaptics, so I'm an idiot using synaptics tongue

Yes, VX Nano rocks, got all buttons working great big_smile

Just cat /sys/devices/platform/eeepc/camera or cardmgr and you see it's status, I'm not sure if we can control'em this way or only watch, but if we could turn them off it would be a bonus, because as you should know better, usb devices on idle do irritatingly consume power.

Yaourt is great, and I just found out how to upgrade check for aur packages updated: yaourt -Syu --aur

as I repeatedly mention I'm using arch default kernel, although I'm hoping to switch to something better real soon, so lets get to work smile

P.P.P.S.  Has any of you guys benchmarked your SSDs? what did you use? Have you heard of the new Runcores PCI-E they look like much better speeds at a very good price, but I can't figure out why there seems that our eee-1000 doesn't support the faster ones which use SATA signals, but lspci says otherwise, and there shouldn't be a problem! Any of you investigated the subject?

Offline

#34 2009-02-06 10:13:19

inf
Member
From: Vantaa, Finland
Registered: 2006-07-18
Posts: 102
Website

Re: Arch on Asus EeePC 1000

I think the joined effort would be a good thing.

Now this thing is a like a time bomb which is about to explode at your feet wink There is atleast four different kernels for EEE (one for 701/900 series, zen-eee for 901, blinds kernel for 901 and big_gies kernel). Same goes for the acpi scripts smile

But I think we should keep the wiki pages separated. I mean, leave the wiki page for the eee 701/900 series alone, and edit the eee901 page for a new "fresh" start.

Offline

#35 2009-02-06 14:33:33

Blind
Member
From: Desert mountain
Registered: 2005-02-06
Posts: 386

Re: Arch on Asus EeePC 1000

I don't have a problem with that (I had a completely monolithic kernel before, which was ok, too).
So, right now, I have the following modules:

i915
fb
drm
i2c_algo_bit
cfbcopyarea
cfbimgblt
cfbfillrect
snd_seq_dummy 
snd_seq_oss
snd_seq_midi_event
snd_seq
snd_seq_device
snd_pcm_oss 
snd_mixer_oss
snd_hda_codec_realtek 
snd_hda_intel 
i2c_i801 
snd_hda_codec
uvcvideo
snd_hwdep
videodev
v4l1_compat
snd_pcm
atl1e 
snd_timer
rt2860sta 
snd
soundcore
snd_page_alloc
intel_agp 
agpgart
eeepc_laptop 
rtc_cmos
rtc_core
rtc_lib
ext3
jbd
mbcache

I would not like to give preference to any filesystem, so I would like to keep all of those a module.
Drivers (graphics, bluetooth, rtc, sound, wifi, networkcard - anything else?) I leave up to the community.
Blind

Offline

#36 2009-02-06 15:32:01

big_gie
Member
Registered: 2005-01-19
Posts: 637

Re: Arch on Asus EeePC 1000

kiberlynx wrote:

Hey, why don't we join efforts and simplify eee-any support on arch, by making a eee-any kernel and buttons support.

This was my goal of "unifying" the acpi handler scripts.

kiberlynx wrote:

Big_gie you could take your expertise on eee-buttons and try to apply it to the new method Blind describes so that is generic to all eee's and easy to install

Hum... Right now the two scripts are too different to unify them easily. I'd need to learn more about buttons-eee901. It seems it uses dbus. I was trying to avoid dbus... In the end what I think should be chosen is the fastest one, dbus or not. I though dbus might introduce some latency, but then I could be wrong.

kiberlynx wrote:

Also we should all pitch in and create a eee-generic optimized kernel, with specific optimizations for each model through dmidecode detection has implemented by Big_gie on acpi scripts

Isn't it what -zen is about? My view on this is different. I would like to see my patch merged to Arch's PKGBUILD. That way, it would be really easy to build a custom kernel. We could then just provides config files or even copy paste from make menuconfig, like often seen on gentoo's wiki. For example:

Networking  --->
     Wireless  --->
           <*> Generic IEEE 802.11 Networking Stack (mac80211)

That way we can have an explication for each configuration. I think its more clean the just give a plain config file without knowing what's inside... I know I trust only myself and expect others to not trust me... wink

kiberlynx wrote:

Finally we should clean up all the clutter in the wiki so that we get a single crystal clear eee-arch manual that fits all models and reduces the current mess that it is, so that newbies feel right at home. (May everyone else not have to go trough what we do to get our eee's optimized)

Yes indeed. The confusion might comes from the fact that "EeePC" was the model name for the 701. But it is also the line name... So installing arch on an EeePC might mean "install on a eeepc 701" or "install on any of the eeepc family". I think it should be the last one. Then all the wiki pages should be merge to Installing Arch Linux on the Asus EEE PC and everything cleaned-up. One generic page containing all (or almost) all information for all models, and maybe separate, smaller pages for specific options to each models. What do you think?

kiberlynx wrote:

What we should do is to get the best of both worlds, like I always did with Gentoo, which is build a robust monolithic small kernel which has all required functionality required (with all our needed patches) and boots really fast (udev must not run any kind of detection on boot, we got to figure out how this is done - I'm pretty sure gentoo did that), and everything else that might be usefull like useful filesystems other than ext3/4 and vfat, and usb modules and other usefull stuff, as well as wireless modules and other stuff that needs to be reloaded once in a while, and we make them as modules so that later on, we can have a flexible system but without bloat through udev and modprobe.

I agree on a monolithic kernel containing everything needed, except smaller details. This is what I was trying to achieve with my custom kernel (see wiki page). I might have missed some things, but my module list is quite small. I'll post it latter on. I think I have less then 10 modules loaded. What I did was to boot with module autoloading, took note of which modules where used, entered them in the MODULES= array, change MOD_AUTOLOAD= to no, and reboot. There might be a better way though...
As for disabling udev, I think it might not be a good idea as default. The Eee family has different hardware so one config for all is not possible. Also, I don't want module autoloading at boot, but I want it afterwards. For example, if I plug a printer or scanner or whatever, I want autodetection. But not at boot.
Ideally I'd like a static /dev at boot for speed, which gets adapted once the system is started and used. But then this is advanced stuff. Might come later on smile


kiberlynx wrote:

Just cat /sys/devices/platform/eeepc/camera or cardmgr and you see it's status, I'm not sure if we can control'em this way or only watch, but if we could turn them off it would be a bonus, because as you should know better, usb devices on idle do irritatingly consume power.

Wow omg, I did not tried them until this morning, and they work well!!! (at least on my 2.6.28.3-custom smile ) I'll create scripts for them to include in my acpi-eeepc-generic!

kiberlynx wrote:

as I repeatedly mention I'm using arch default kernel, although I'm hoping to switch to something better real soon, so lets get to work smile

Just sync abs (sudo abs), copy /var/abs/core/kernel26/ somewhere else, apply my patch for custom kernel, and configure it as you like smile I have put a link for my config on the wiki. You can go on from there.

kiberlynx wrote:

P.P.P.S.  Has any of you guys benchmarked your SSDs? what did you use? Have you heard of the new Runcores PCI-E they look like much better speeds at a very good price, but I can't figure out why there seems that our eee-1000 doesn't support the faster ones which use SATA signals, but lspci says otherwise, and there shouldn't be a problem! Any of you investigated the subject?

No I did not. I think hdparm can do simple benchark. You could try also phoronix test suite, but thats a bit overkill... smile I just upgraded my ram to 2GB (no, it wont void the warranty) and bought a SDHC 16GB card. I wont be looking at sdd replacing before long tongue

Offline

#37 2009-02-06 15:47:13

big_gie
Member
Registered: 2005-01-19
Posts: 637

Re: Arch on Asus EeePC 1000

inf wrote:

There is atleast four different kernels for EEE (one for 701/900 series, zen-eee for 901, blinds kernel for 901 and big_gies kernel).

"Mine" is not really a "mine"... tongue I just suggested a modification to the official PKGBUILD so it would be easier to create a custom kernel. So anybody could modify it to their liking. I think what we should do is provide information on each kernel option necessary for a successful kernel, and maybe provide a "default" config file. That way, we would not need to support kernels. Right now it is the case. Somebody needs to update everything and its a mess. The more support you need to provide, the less you are able to concentrate on the content. So let's concentrate on what kernel options/modules for each components, put that information on the wiki, and let users create their own kernel based on our suggestion and on Arch's stock PKGBUILD (my modifications needs to be adopted though...)
As for the wiki pages, the most confusion comes from these two pages:
http://wiki.archlinux.org/index.php/Ins … sus_EEE_PC
http://wiki.archlinux.org/index.php/Asus_Eee_PC
I think they should at least be merged, and provides basic and generic information for all eeepcs, with links pointing to the other, more specialized wiki pages for each models:
http://wiki.archlinux.org/index.php/Asus_Eee_PC_900A
http://wiki.archlinux.org/index.php/Asus_Eee_PC_901
http://wiki.archlinux.org/index.php/Asus_Eee_PC_904HA
http://wiki.archlinux.org/index.php/Asus_Eee_PC_1000
On these pages, only advanced and specific information should be included, with a link to the generic page for basic information. That would at least reduce the confusion...

inf wrote:

Same goes for the acpi scripts smile

Yes that was my goal by creating acpi-eeepc-generic. I wanted something powerful, fast and beautiful, but that was not specific to the 1000 I own, because the AUR confusion for this is even worse then the wiki confusion. I wrote to the creator/maintainer of many of these packages about a month ago about that. I had a positive response for the acpi-eeepc900 which I adopted and deprecated. I think blind also responded, but I think his way of doing it is original and could be a good path. No news for all the others though...

inf wrote:

But I think we should keep the wiki pages separated. I mean, leave the wiki page for the eee 701/900 series alone, and edit the eee901 page for a new "fresh" start.

The problem with a "fresh start", keeping the old cruft there, is that it creates confusion... Which one to use? The old one or the new one? Which one is the new one anyway? I think the problem with the "old" one might be that the name is not suggestive enough. It might just be renamed from "Installing_Arch_Linux_on_the_Asus_EEE_PC" to "Asus_Eee_PC_701" or similar.

Offline

#38 2009-02-06 15:52:53

big_gie
Member
Registered: 2005-01-19
Posts: 637

Re: Arch on Asus EeePC 1000

Blind wrote:

I would not like to give preference to any filesystem, so I would like to keep all of those a module.
Drivers (graphics, bluetooth, rtc, sound, wifi, networkcard - anything else?) I leave up to the community.

If you leave the filesystem as module, then you might need more "automatic" tools to detect it correctly. For example initramfs from mkinitcpio, udev, etc. I would suggest using one particular filesystem. Right now I use ext2 for /dev/sda1 on / and ext4 for /dev/sdb1 on /home. In 2.6.29, it will be possible to use ext4 without a journal: wouhou!!
If we don't create yet another kernel in AUR but give instead information on which options to use for each machines, then we can put a sane default (ext2/3/4 built in, others as modules) and leave it to the user to change it.

Also, less vital drivers, like the webcam, bluetooth or even wireless, should be built as module so they could be unloaded. But then again if they are not autoloaded at boot we should find a way to load them manually after boot...

Offline

#39 2009-02-06 19:26:48

kiberlynx
Member
Registered: 2009-02-03
Posts: 5

Re: Arch on Asus EeePC 1000

big_gie wrote:

This was my goal of "unifying" the acpi handler scripts.

I can see that and I definitely appreciate your effort, thank you.

big_gie wrote:

Hum... Right now the two scripts are too different to unify them easily. I'd need to learn more about buttons-eee901. It seems it uses dbus. I was trying to avoid dbus... In the end what I think should be chosen is the fastest one, dbus or not. I though dbus might introduce some latency, but then I could be wrong.

The argument against acpi-eee-generic is that it uses a deprecated interface, which means that sooner or later it will stop working, that's why I recommended that sooner, rather than later you refactor it.

big_gie wrote:

Isn't it what -zen is about?

definitely not, and if you were thinking about zen-eee901 or whatever it's called, maybe, but that's based on zen, and that's nice if you like zen, but I think that for the general population we should follow vanilla as close as possible, for stability reasons. Which is the line that Blind takes, which I appreciate.

big_gie wrote:

My view on this is different. I would like to see my patch merged to Arch's PKGBUILD. That way, it would be really easy to build a custom kernel. We could then just provides config files or even copy paste from make menuconfig, like often seen on gentoo's wiki. For example:

Networking  --->
     Wireless  --->
           <*> Generic IEEE 802.11 Networking Stack (mac80211)

That way we can have an explication for each configuration. I think its more clean the just give a plain config file without knowing what's inside... I know I trust only myself and expect others to not trust me... wink

I read your patch thread, and it's a great idea,  although I think that for someone that simply wants only to have her kernel configured to run her eeepc nicely it would be much nicer if we, besides providing your patch, additionally provided another patch which would allow stepping stones for newbies, like plugable  config patches for specific optimizations for specific hardware like for example an eeepc. And I think we should include also the selection of patches and config patches, and after that, direct calling of make menuconfig or make xconfig (which is also nice), but instead of having to interrupt normal makepkg make it all part of the default process, by questioning the user to choose an option at each of these steps.

big_gie wrote:

Yes indeed. The confusion might comes from the fact that "EeePC" was the model name for the 701. But it is also the line name... So installing arch on an EeePC might mean "install on a eeepc 701" or "install on any of the eeepc family". I think it should be the last one. Then all the wiki pages should be merge to Installing Arch Linux on the Asus EEE PC and everything cleaned-up. One generic page containing all (or almost) all information for all models, and maybe separate, smaller pages for specific options to each models. What do you think?

Couldn't agree more but having in mind a nodetree model of wiki so that you enter through the main page read the parts common to all and then follow to the specific forums instead of having to go back and forth to compare stuff like we have to do now.

big_gie wrote:

I agree on a monolithic kernel containing everything needed, except smaller details. This is what I was trying to achieve with my custom kernel (see wiki page). I might have missed some things, but my module list is quite small. I'll post it latter on. I think I have less then 10 modules loaded. What I did was to boot with module autoloading, took note of which modules where used, entered them in the MODULES= array, change MOD_AUTOLOAD= to no, and reboot. There might be a better way though...
As for disabling udev, I think it might not be a good idea as default. The Eee family has different hardware so one config for all is not possible. Also, I don't want module autoloading at boot, but I want it afterwards. For example, if I plug a printer or scanner or whatever, I want autodetection. But not at boot.
Ideally I'd like a static /dev at boot for speed, which gets adapted once the system is started and used. But then this is advanced stuff. Might come later on smile

Well static adaptable dev now you're talking.
About that, has anyone heard about when are the moblin tweaks going to be available to us archers?

big_gie wrote:

Wow omg, I did not tried them until this morning, and they work well!!! (at least on my 2.6.28.3-custom smile ) I'll create scripts for them to include in my acpi-eeepc-generic!

yeeeah smile
I've had to replace acpi-eeepc-generic for being incompatible with eee-control, which I really needed for shutting up the fracking fan, and found out that it supports all the fn buttons as well as the silver ones and controls webcam and cardmgr like I wanted.

big_gie wrote:

Just sync abs (sudo abs), copy /var/abs/core/kernel26/ somewhere else, apply my patch for custom kernel, and configure it as you like smile I have put a link for my config on the wiki. You can go on from there.

I'm still undecided has to how to proceed about the kernel.

big_gie wrote:

No I did not. I think hdparm can do simple benchark. You could try also phoronix test suite, but thats a bit overkill... smile I just upgraded my ram to 2GB (no, it wont void the warranty) and bought a SDHC 16GB card. I wont be looking at sdd replacing before long tongue

hdparm is not accurate for ssds, phoronix had several problems with the aur package that I found through yaourt, anyway I wanted something simpler and with a different kind of disk testing which I found in ATTO, but it's a windows app. I installed ATTO with wine, but probably because of wine's translation overhead it gives ludicrous results tongue

Offline

#40 2009-02-06 20:27:20

inf
Member
From: Vantaa, Finland
Registered: 2006-07-18
Posts: 102
Website

Re: Arch on Asus EeePC 1000

Hum, I tend to better trust the BIOS for fan control then myself or a third party program... The fan is there to cool down your cpu. But then I remember reading something about the BIOS algorithm for fan control which kept the fan too often on... Anyway, many utilities like this one depended on the old, deprecated kernel module "eeepc_acpi" which was written by asus (I think). This module is not included in kernel, so you need to build it yourself. The source is only available in a ~2GB tar file on Asus's &%?&)$( slow ftp server. It does'nt even compile on 2.6.28. A new module was introduced in 2.6.28 (I think), called "eeepc_laptop". It might not support all features of the old "eeepc_acpi", but at least its included in the kernel.
So I don't know exactly what "eeepc_laptop" exposes. For example, you need 2.6.29 to get bluetooth toggle correctly. So it might not include fan control yet. I would suggest opening some bug reports at http://bugzilla.kernel.org/

EEE control doesn't use eeepc_acpi, it uses  purely the new eeepc_laptop module. the new module is pretty much a better version of the first eeepc_acpi module but with better support.

with eee-control the bluetoot/webcam/cardmanager for example, do allow the status toggling. So it's pretty much a must. And of course the automatic fan control is also very good.

Offline

#41 2009-02-06 23:40:38

big_gie
Member
Registered: 2005-01-19
Posts: 637

Re: Arch on Asus EeePC 1000

kiberlynx wrote:

The argument against acpi-eee-generic is that it uses a deprecated interface, which means that sooner or later it will stop working, that's why I recommended that sooner, rather than later you refactor it.

Whic depracated interface? I am only using eeepc-laptop, not the depracated eeepc-acpi. Or is there something else I missed?

kiberlynx wrote:

I read your patch thread, and it's a great idea,  although I think that for someone that simply wants only to have her kernel configured to run her eeepc nicely it would be much nicer if we, besides providing your patch, additionally provided another patch which would allow stepping stones for newbies, like plugable  config patches for specific optimizations for specific hardware like for example an eeepc. And I think we should include also the selection of patches and config patches, and after that, direct calling of make menuconfig or make xconfig (which is also nice), but instead of having to interrupt normal makepkg make it all part of the default process, by questioning the user to choose an option at each of these steps.

Wow too many patches wink This is how I see it: we provide a default config, available somewhere on the web. This config would include nothing except modules needed for the eee (built in or module). That way compilation is faster. We can then have somewhere, on the wiki probably, where each compiled options are explained, so that users can make a proper choice.
Right now, building a custom kernel is not what Arch was meant to be. I think it would be a great addition to ease the custom kernel compilation process so users can hack it. What we can do is put our knowledge for people who wants to optimize their stuff. The stock Arch's kernel is good enough, specifically if you don't know how to compile a kernel.

The problem of "providing patches" is that they get outdated really fast and are hard to keep up to date. Look at the bug report I filled: I have 4 patches attached because the kernel keeps evolving so I need to "support" my patch to it applies to the current pkgbuild. And its only a pkgbuild... not a kernel! This is why "out of tree drivers" (drivers developped by companies in-house, then given to users as kernel patches) are not that good: then tend to be outdated really fast.

Anyway, my point here is that I think we should just suggest a sane default and show people how to modify it.

Offline

#42 2009-02-07 11:41:44

tehabe
Member
Registered: 2008-10-14
Posts: 82

Re: Arch on Asus EeePC 1000

Feature request for the ACPI scripts: when the battery is critical, the eeePC should go to sleep and not just turn off.

Offline

#43 2009-02-07 22:10:43

ChemBro
Member
Registered: 2008-10-22
Posts: 703

Re: Arch on Asus EeePC 1000

tehabe wrote:

Feature request for the ACPI scripts: when the battery is critical, the eeePC should go to sleep and not just turn off.

Going to sleep instead of turning off is very dangerous for your battery.

Offline

#44 2009-02-08 21:07:04

tehabe
Member
Registered: 2008-10-14
Posts: 82

Re: Arch on Asus EeePC 1000

ChemBro wrote:
tehabe wrote:

Feature request for the ACPI scripts: when the battery is critical, the eeePC should go to sleep and not just turn off.

Going to sleep instead of turning off is very dangerous for your battery.

Turning off instead of going to sleep is very dangerous for my data

When done correctly it shouldn't be a problem at all.

Offline

#45 2009-02-08 21:33:53

big_gie
Member
Registered: 2005-01-19
Posts: 637

Re: Arch on Asus EeePC 1000

That could be a nice addition.
I would need the acpi event though for your model...
Maybe you could make it run low on battery while you have "acpi_listen" running. If acpi toggle some events for critical battery, acpi_listen should print out the event. Post it here...

Offline

#46 2009-02-09 23:10:40

Blind
Member
From: Desert mountain
Registered: 2005-02-06
Posts: 386

Re: Arch on Asus EeePC 1000

I can't seem to upload my PKGBUILD to AUR.
So here is a bugreport:
http://bugs.archlinux.org/task/13173?type[0]=&sev[0]=&due[0]=&cat[0]=&status[0]=open&percent[0]=&opened=1140&reported[0]=
The file (and kernel) works fine for me, big_gie, please take a look at the PKGBUILD, I think there were a few things I had to change.
All the changes that were suggested have been made. I compiled the sound, graphics, i2c (needed for eee_control) and the ext filesystems drivers into the kernel. LVM added, and ACPI event system (yuck, but you wanted it).
Have fun.

Offline

#47 2009-02-10 01:54:29

big_gie
Member
Registered: 2005-01-19
Posts: 637

Re: Arch on Asus EeePC 1000

Blind wrote:

The file (and kernel) works fine for me, big_gie, please take a look at the PKGBUILD, I think there were a few things I had to change.

What did you have to change? Well I know that for release candidate kernels its a little tricky. But that's always the case with rc.
I see that you disabled the removal of firmwares. Any reason? I would say it is because you want to have installed only this kernel?

Blind wrote:

... and ACPI event system (yuck, but you wanted it).

Why yuck? Why is that not a good thing?

Also, the kernel should work on other eee then the 901. Maybe the name could be changed?

Offline

#48 2009-02-10 03:51:39

Blind
Member
From: Desert mountain
Registered: 2005-02-06
Posts: 386

Re: Arch on Asus EeePC 1000

big_gie wrote:

What did you have to change? Well I know that for release candidate kernels its a little tricky. But that's always the case with rc.

Yeah, true. Your sed magic that changes the .install and the .preset file is off in that case. I used the variable _kernelver, which IMHO is the much better choice. Also, in the .preset you first source the .kver file that you rightfully created, but then redefine the ALL_kver variable a line later...I thought that kind of defeats the purpose, but maybe I am wrong (I am not a bash hacker smile)

big_gie wrote:

I see that you disabled the removal of firmwares. Any reason? I would say it is because you want to have installed only this kernel?

Yup. I dont want to have to have the stock one installed...but I understand this is a difficult thing. I don't have a good solution for it.

big_gie wrote:
Blind wrote:

... and ACPI event system (yuck, but you wanted it).

Why yuck? Why is that not a good thing?
Also, the kernel should work on other eee then the 901. Maybe the name could be changed?

I guess I just saw the Kconfig description again - the deprecation warning is alrady 1.5 yrs old...

I have a questionfo all you eee_control users:
seems to use dbus, can one control the behavior on lid close/power button etc? That'd be cool smile

I cannot change the kernel name, because adriano is using it - seems to be popular, too.

Offline

#49 2009-02-11 16:25:00

big_gie
Member
Registered: 2005-01-19
Posts: 637

Re: Arch on Asus EeePC 1000

Blind wrote:

Yeah, true. Your sed magic that changes the .install and the .preset file is off in that case. I used the variable _kernelver, which IMHO is the much better choice. Also, in the .preset you first source the .kver file that you rightfully created, but then redefine the ALL_kver variable a line later...I thought that kind of defeats the purpose, but maybe I am wrong (I am not a bash hacker smile)

I see what you mean smile I corrected that. I did some cleanup before posting it but this one managed to escape my eyes! Thanx for the input smile

Blind wrote:

I dont want to have to have the stock one installed...but I understand this is a difficult thing. I don't have a good solution for it.

I created a pkgbuild for the firmwares. Basically you need to compile all the modules which will compile the firmwares. I stripped down the kernel26 stock PKGBUILD for this. You can find it on the bug report: http://bugs.archlinux.org/task/12384

Blind wrote:
big_gie wrote:
Blind wrote:

... and ACPI event system (yuck, but you wanted it).

Why yuck? Why is that not a good thing?
Also, the kernel should work on other eee then the 901. Maybe the name could be changed?

I guess I just saw the Kconfig description again - the deprecation warning is alrady 1.5 yrs old...

Haaaaa... I see smile What is deprecated is /proc/acpi, which I do not use. I'll try to remove it myself to verify that everything is still working.

Offline

#50 2009-02-11 17:00:47

Blind
Member
From: Desert mountain
Registered: 2005-02-06
Posts: 386

Re: Arch on Asus EeePC 1000

Glad I could help smile I think the firmware package is a good idea - I am sure other people with their own kernels will step into that trap.

About /proc/acpi: If I am not mistaken, then acpid needs the /proc/acpi/event file, which is one of the things that are deprecated.

Offline

Board footer

Powered by FluxBB