If you find any other problems, please add a new section (at H2 level).

If you have a solution (or suggestion) for any of the following, please just add the commentary in the section : someone with access to the real code will clear them up into the standard ISO for everyone.

To have a look at the actual code in the eee_tarball rpm, just go over to the Google Code pages (see below).

This now works as eth0 - it's the latest install (2.0.3) from the kernel developer at RedHat.

FYI : The previous eth0/eth1 problem was probably that the wireless 'ath5k' was improperly claiming eth0, and replacing it with a madwifi driver fixed it

This now works using the Atheros supplier patch that was (briefly) accepted by madwifi.

Hopefully, this gets into the main stream soon, but it's included here precompiled : use at your own risk (because it's based around a closed-source binary blob, essentially)

This works now.

• Thunar can be set (using Edit Preferences - Advanced) to auto-mount volumes
• hal complains of not having the right settings for …hal.devices.mount-removable
• EeeDora now amends /etc/PolicyKit/PolicyKit.conf to fix the problem

Scripts that require root privileges should prompt for the root password.

Some of the config-system-XYZ things need a root password, and it doesn't get prompted for. They can be run from a Terminal (after su), but it would be nice for it to work seamlessly.

• the kickstart file was missing the package usermode-gtk

alsamixer seems to work out of the box.

And now the sound system works - based upon the ultra-new pulseaudio

pulseaudio is rather bleeding-edge at the moment, it seems…

• pulseaudio wasn't being started ahead of XFCE on boot-up (fixed)
• pulseaudio wasn't setting up the permissions of /dev/snd* properly - this is fixed up by EeeDora automatically

Microphone is working while speaking in, we can listen sound from speakers, but using skype, it seem to be connected to wrong channel or something. Hope somebody can help.

Apply those settings in skype (menu options while connected, otherwise sound control panel won't be available) :

• sound input : HDA Intel (hw:Intel,0)
• sound output : HDA Intel (hw:Intel,0)
• Set any other to defaults.

Uncheck the Skype auto volume adjustment. Then apply settings.

Install gnome-alsamixer (by add-remove software menu using pirut interface, or typing yum install gnome-alsamixer using root account in console).

Launch the Alsa Mixer freshly installed through the menu, Multimédia, then ALSA Audio Mixer (the one with the volume button icon).

gnome alsa mixer - Level settings for skype to work :

• PCM at 95%
• LineOut full (mute uncheked)
• Capture at 80% (Rec. checked)
• Digital at 0%
• e-Mic at 0% (external mic) (mute unchecked)
• e-Mic Bo (boost) at 0%
• i-Mic at 90% (mute unchecked)
• i-Mic Bo (boost) at 50%

At the bottom of the mixer :

• Input source checked
• iSpeaker checked.

It worked great for me ! Having skype 2.0.0.63 working great that way with audio and video using integraded speakers and mic.

truecrypt is set up to work.

• mkdir /path/to/mountpoint
• truecrypt –user-mount /path/to/truecryptfile /path/to/mountpoint
  • Enter your super-secret password
  • …
• truecrypt –dismount

Have a look at this page to see how to make the SD card mount reliably in the same place (particularly for suspend/resume) - note that the Fedora syntax may well differ - I needed to put this in /etc/udev/rules.d/55-eeedora-custom.rules :

SUBSYSTEMS==“usb”, KERNEL==“sd*”, ATTRS{serial}==“146030377350”, SYMLINK+=“sdcard1”, OPTIONS+=“last_rule”, RUN+=”/bin/mount /dev/sdcard1”

(where I got the serial number from /proc/bus/usb/devices and looking for usb-storage).

And into /etc/fstab went the following :

/dev/sdcard1 /mnt/sd vfat uid=500,gid=500,user,exec 0 0

It appears that by default the way that X Windows is started it leaves port 6000 open to remote access. This is a potential security problem. (I have made some changes to my set up, but I don't think the changes I made introduced this problem.)

All working - through the magic of acpi

Note: There is one minor annoyance of the current implementation of the ACPI keys. If the key or a multitude of the ACPI keys are pressed in rapid succession by an annoying individual trying you EeePC then it will often take a long will for it to stop sending you messages. As well it is fairly laggy on the increase and decrease of volume as in comparison to other laptops using the ACPI keys for volume control under Linux. I believe a percent bar would be at least a better implementation for at least the volume.

• This required compiling in the ASUS ACPI module, and then loading it on start-up via /etc/sysconfig/modules/modules.conf
• Individual event files are created using the perl script in the source tree
• Consolidated action scripts 'eee' and notification scripts 'eee.py' are in /etc/acpi/actions/
• Using the acpi_listen command to monitor what's going on helped a lot
• Some funkiness was causes by the pynotify daemon refusing connections from root - so a 'su' was required to become the console user 'eeedora'

Since you close the screen of your eee, on resume the screen backlight level Extra keys won't work until reboot. Not found how to fix it for now. So, the key is still working, the value in /proc/acpi/asus/brn is changing, but the back light intensity not changing. So something stop working on suspend…

- To fix that problem, you have to edit the /etc/acpi/actions/eee file (eq with vi editor), finding that line :

 if [ "${acpi}" == "zzz" ]; then

You have to add lines so as to make it look like that :

 if [ "${acpi}" == "zzz" ]; then
  wifi_off
  #echo 0 >/proc/acpi/asus/wlan#Useless make unable to get wifi back, ok without this
  pm-suspend
  pm-hibernate
  echo 1 >/proc/acpi/asus/wlan
  wifi_on
  note='resume'
 fi

Then find that second line (juste under the one above normaly) :

 if [ "${acpi}" == "lid" ]; then

You have to add lines so as to make it look like that :

 if [ "${acpi}" == "lid" ]; then
  wifi_off
  #echo 0 >/proc/acpi/asus/wlan#Useless make unable to get wifi back, ok without this
  pm-suspend
  pm-hibernate
  echo 1 >/proc/acpi/asus/wlan
  wifi_on
  note='resume'
 fi

Juste save it, it should work. Try suspend, and resume, you should be able to set the backlight intensity again without the need of a reboot.

So that make some double use of standby process, but, this way (taking 15 seconds more to wake up) the management of backlight throug Fn+F3 and Fn+F4 keep working on resume. Hope this helps.

Note : You may have a warning about removable disk on resume because it has not come up fast enough, don't care it's ok, the disk bring up few second later.

Note 2 : On resume you may have to reconnect Wifi using wifi-radar since it would try to connect to any open access point on resume (btw not the one you use)

This works to some degree (the colours may be a bit strange).

• Compiled uvcvideo from the Asus source (and the SVN tree - no apparent difference)
• There's also a version of luvcview in /root/eee-setup/uvc for testing (without many dependencies)

There's a script on the desktop for this - just double-click the icon and (after asking for the root password 'eeedora') it'll go through the standard anaconda installer (accepting all the defaults work fine). There's a bogus message about '/1' that appears when it starts to copy the files - just dismiss it.

• This was a royal pain to fix - since the Eee needs an ext2 filesystem as its rootfs (to save the internal drive from too many write operations). But it's done now.

Default font clarity could be better.

Go to Menu→Settings→User Interface Settings

Check “Use sub-pixel hinting” and set it to RGB.

If the Xorg is restart (Ctrl+Alt+Backspace) then the computer shuts down, rather than rebooting the windows manager.

FIXED - required removal of a sound-related kernel module in the halt script.

The desktop effects (like compositing) need to be enabled through the XFCE desktop setup dialogs. This can give you translucent windows, etc.

I haven't tried the 3-D effects like compiz, since their inclusion would boost the initial image size by 20Mb or so.

Almost fixed…

I did some more testing on this and I was able to get the Wacom tablet to work :

• A convenient thing was that both the Wacom drivers are installed, as well as the udev rules now work properly in Fedora 8
• You can look at the Wacom Tablet wiki for how to set up the xorg.conf

• Xorg still needs to be restarted to get proper usage of the tablet. (which is annoying due to an above problem).

The XFCE panel applet (a) doesn't do a good job of determining remaining battery life, and (b) eats about 8% of the CPU. Anderson Silva has suggested that the Gnome battery monitor applet does a better job - this solution may make it into the next release.

I found that if I try to put a very long password on wifi-radar gui ( for a wpa ecrypted wlan ) it doesn't accept whole. I mean, I start to write my alphanumeric password ( 37 chars ) , at 30 about, it stops to write. Infact in /etc/wifi-radar.conf my password is not my complete password. Maybe this problem is not related with eeedora, but now I have no other computer to test it.

The kernel module building, RPM building, and ISO building are all run from scripts. These, and the full source tree are up on Google Code : http://code.google.com/p/eeedora/

If you're interested, the whole source code tree can be browsed via : http://eeedora.googlecode.com/svn/trunk/

And it can also be downloaded anonymously (without write-access) - just hunt around the Google Code thing.

To get the required stuff together to use the Fedora tools, I've been building a special RPM that brings in a tar-ball of code (modules, scripts, etc) over in /root/ on the Eee after it boots. All the scripts, etc, unfold in /root/eee-setup/

This enables every stage of the set-up to be tested, and the 'good bits' reincorporated into the next iteration of the ISO (building an ISO takes around 35mins on my ordinary laptop).

1. Download the SVN trunk
   • anonymous download should be fine, but if you'd like commit access, just let me (mdda) know.
2. Execute the following as root (the script names are rough, but the first letters should allow filename completion) :
   1. Building all kernel modules from source (not essential, since they are all in SVN) :
      • cd eee-setup
      • ./kernel-modules-update
      • Alternatively, this can be done one module at a time …
   2. Building atl2.ko from source (not essential, since atl2.ko is in SVN) :
      • cd eee-setup/atl2
      • ./rebuild_atl2-ko
   3. Building ath_pci.ko from source (not essential, since ath_*.ko are in SVN) :
      • cd eee-setup/ath
      • ./rebuild_ath-madwifi-ko
   4. Building asus_acpi.ko from source (not essential, since asus_acpi.ko is in SVN) :
      • cd eee-setup/acpi
      • ./rebuild_acpi-ko
   5. Building truecrypt.ko from source (not essential, since truecrypt.ko is in SVN) :
      • cd eee-setup/truecrypt
      • ./rebuild-truecrypt
   6. Building uvcview.ko from source (not essential, since uvcview.ko is in SVN) :
      • cd eee-setup/uvc
      • ./build-uvc…
   7. Building the splash images source (not essential, but pretty) :
      • cd eee-setup/artwork
      • ./build-artwork.bash
   8. Building the RPMs eee_tarball and eee_splash :
      • cd eee-setup
      • ./build-eee_tarball_RPM.bash
      • ./create-eee_splash_RPM.bash
   9. Building the ISO (takes around 35mins on my old laptop) :
      • ./build-eeedora.bash
   10. Copying the ISO to USB (automatically choses latest ISO, assumes /dev/sdb1, takes around 4mins) :
       • ./copy-iso-to-usb.bash
3. Of course, the above should really be in Makefiles (could someone help out?)

If any of the scripts are updated (or added to), you'll need to go into eee-setup and re-'build-eee_tarball_RPM.bash'

• Then, build the ISO again…