Hello #!! I installed 0.1 on my new 160Gb AAO about one week ago now, and I'm having a great time using linux again after about the past year where I was using the MacBook Pro provided by my employer pretty much exclusively as my main machine.
I did find a couple of things that needed to be resolved, though.
Problem: When I plug in my headphones, the internal speaker does not mute.
Solution: The ACL268 in my AAO requires some quirk code. I believe it is first added in the 1.0.18 version of the alsa kernel modules or kernel 2.6.28+. Should it not auto-detect your chip, you are to add "options snd-hda-intel model=acer-aspire" to /etc/modprobe.d/alsa-base.
Problem: When I upgraded my packages (it worked when I first installed!) I lost hardware acceleration.
Solution: It appeared that chmod 666 /dev/dri/card0 fixed it temporarily...
glxinfo | grep OpenGL reported that my renderer was Software Rasterization. I had glx, but it was software emulated -- totally unworkable performance. The solution was to make a /etc/udev/rules.d/60-card.rules that read
KERNEL=="card[0-9]", MODE="0666", GROUP="video", OWNER="root"
That fixed the permissions on boot. However, performance is still not as it could be. In chatting with leak in #kukilinux (a dev for the distro... which aims to be an AAO-ready ubuntu-based distro) he walked me through examining /proc/mtrr and devising a script that would "fix" the apparently buggy mtrr registers in my AAO. (His was slightly different at least because he only had 512M ram and have 1G)
By doing this, I was able to enhance performance even further. I still get the message "Failed to initialize GEM. Falling back to classic." in STDERR first thing when I run glxinfo or glxgears. I understand getting GEM will increase my performance further yet.
I guess I'll share the "script" I have and the the desired mtrr register output. My /etc/init.d/fix_mtrr.sh reads:
#!/bin/sh
echo "disable=0" >| /proc/mtrr
echo "disable=4" >| /proc/mtrr
echo "base=0x000000000 size=0x40000000 type=write-back" >| /proc/mtrr
echo "base=0x040000000 size=0x10000000 type=write-combining" >| /proc/mtrr
It is executable, and to make it run early in boot-up, I have a symlink with a very early number in /etc/rcS.d going to it. Now, here is what leak tells me the "correct" output of cat /proc/mtrr should look like:
reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1
reg01: base=0xfffc0000 (4095MB), size= 128KB: uncachable, count=1
reg02: base=0x00000000 ( 0MB), size= 512MB: write-back, count=1
reg03: base=0x20000000 ( 512MB), size= 512MB: write-back, count=1
reg04: base=0x40000000 (1024MB), size= 256MB: write-combining, count=1
reg05: base=0x3f600000 (1014MB), size= 2MB: uncachable, count=1
reg06: base=0x3f500000 (1013MB), size= 1MB: uncachable, count=1
reg07: base=0x00000000 ( 0MB), size= 128KB: uncachable, count=1
I had some bit in the first (reg00) register that was like unwriteable or read-only or something... that was bad, I guess.
Unsolved Problem: xdpyinfo |grep resolu reports 58x135 dots per inch, a certain font a few web pages I've seen use and the quake3 installer (I bet it's gtk1 -- my gtk2 apps are fine) have vertically stretched, very difficult to read fonts, and gstreamer (totem-gstreamer and miro) have vertically stretched video.
Solution: I fixed gstreamer with identity ! xvimagesink pixel-aspect-ratio=1/1 in my custom video default output in gstreamer-properties, but it's only a bandaid. Someone in #gstreamer gave me the "identity !" hint and explained that because my video driver is broked somehow, it wasn't remembering my setting despite the preview indicating that my option fixed the aspect ratio.
I have yet to figure out how to affect those 58x135 numbers.
Woohoo linux is fun. \o/
I'm sure with time, these quirks will be learned and linux will make these experiences seamless again... but I guess at over 6 months since this netbook was released we're still not quite there.
Cheers to the #! users and devs!
Last edited by thread (2009-01-22 04:12:37)