As of now, the latest disk image available online is "build 168". To have X server start, I need to replace a config file from older version (which is understandable as they seem to be preparing for the deployment with actual display). And, the boot precess fails sometimes (such as saying "Resetting OLPC Wireless" and hang). But if it boots up, eToys runs as expected. eToys doesn't interfere other apps sound playback (but other appls interfere eToys sound playback.) As long as they work out the low-level stuff right, the eToys part is are fine.
-- Yoshiki
They changed the artwork of buttons in TamTam from grayscale to full-color. Nobody seems to be interested in "freezing" and stabilize software...
I also just tested build 168 - found a way to directly use the downloaded disk image with Parallels on my Mac. It started up fine, but in 640x480 - maybe your monitor cannot handle this?
Anyway, etoys ran fine, except of course that the projects won't work correctly at 640x480.
- Bert -
On Nov 11, 2006, at 19:02 , Yoshiki Ohshima wrote:
As of now, the latest disk image available online is "build 168". To have X server start, I need to replace a config file from older version (which is understandable as they seem to be preparing for the deployment with actual display). And, the boot precess fails sometimes (such as saying "Resetting OLPC Wireless" and hang). But if it boots up, eToys runs as expected. eToys doesn't interfere other apps sound playback (but other appls interfere eToys sound playback.) As long as they work out the low-level stuff right, the eToys part is are fine.
-- Yoshiki
They changed the artwork of buttons in TamTam from grayscale to full-color. Nobody seems to be interested in "freezing" and stabilize software...
Bert,
I also just tested build 168 - found a way to directly use the downloaded disk image with Parallels on my Mac. It started up fine, but in 640x480 - maybe your monitor cannot handle this?
Interesting. I assumed that (from the mode line in xorg.conf) it is trying to start in 1200x900, but may be yes. OTOH, the monitor should take 640x480...
-- Yoshiki
Ah, turns out the frame buffer default size is 640x480 in the ext3 images. Changing the VGA mode in /boot/grub/grub.conf from 0x311 to 0x317 solved that:
res | 640x480 800x600 1024x768 1280x1024 ----+------------------------------------- 256 | 0x301 0x303 0x305 0x307 32k | 0x310 0x313 0x316 0x319 64k | 0x311 0x314 0x317 0x31A 16M | 0x312 0x315 0x318 0x31B
I tested image 172, works as fine as 168 (although I could not test sound in the virtual box). Hope there won't be any more surprises - the "drop-dead" OS release time is tonight 8pm pacific time (http:// tinyurl.com/yk5n7o).
- Bert -
On Nov 11, 2006, at 23:31 , Bert Freudenberg wrote:
I also just tested build 168 - found a way to directly use the downloaded disk image with Parallels on my Mac. It started up fine, but in 640x480 - maybe your monitor cannot handle this?
Anyway, etoys ran fine, except of course that the projects won't work correctly at 640x480.
- Bert -
On Nov 11, 2006, at 19:02 , Yoshiki Ohshima wrote:
As of now, the latest disk image available online is "build 168". To have X server start, I need to replace a config file from older version (which is understandable as they seem to be preparing for the deployment with actual display). And, the boot precess fails sometimes (such as saying "Resetting OLPC Wireless" and hang). But if it boots up, eToys runs as expected. eToys doesn't interfere other apps sound playback (but other appls interfere eToys sound playback.) As long as they work out the low-level stuff right, the eToys part is are fine.
-- Yoshiki
They changed the artwork of buttons in TamTam from grayscale to full-color. Nobody seems to be interested in "freezing" and stabilize software...
etoys-dev@lists.squeakfoundation.org