I'm not quite done tucking all the corners on this laptop, but decided to start a page on it anyway to keep notes for myself, and perhaps give anyone else installing on one a leg up. If something I haven't figured out how to get working is of interest to you, be sure to check back -- I'm still plugging away.
As of this writing, you can pick these up used for $300 to $400. That's about how much it costs in electric power to run your average desktop for about 2 years, if left on. And face it, us Linux users like to leave our boxen on. If you don't need uber-performance for your everyday browsing, you might want to consider one of these, as it will pay for itself over time. It draws about 40W at full steam, compared to 250W for a desktop + monitor. (For a router though you should consider something in a lower class still. I use a Compaq LTE Elite for a router, and an Ascentia M for a webserver, and hope to eventually document those, too.)
In its day this laptop was the top of its line, most evidenced by the nice large 1280x1024 screen. These days it would be considered a beast size-wise, but that's actually a good thing for use as a desktop replacement. The other notable feature is a video capture port, and tv-out, which might make it a good pick for a set-top box if you can get them working (see below) and don't need to process any streams that the PIII 650 cannot handle. RAM, of course, is the key ingredient in any successful system, so make sure you get at least the 268M configuration, if not the full 544M upgrade.
Stock kernels/bootdisks will get you installed just fine (I installed with no problems over the network from just the four Debian Installer floppies.) Me I like to roll my own afterwards, though.
My latest kernel config can be downloaded here and a typical resulting boot log here. As we can see, ACPI enumeration works fine on this box. In addition to the lspci the unit also has fairly descriptive DMI records.
My current bootprompt options are empty.
The provided kernel config represents a good amount of fiddling to see what is and is not present as far as APIC/ACPI/timers. Note that I was a bit hawkish in choosing 1000HZ base timer and you might want to pop down to 250 if you value throughput more than multitasking, though damned if I can notice the difference.
I left the smbus driver in there even though the bus appears empty. Perhaps it isn't when docked.
What's broken among kernel-level stuff is a couple of power management features: SpeedStep cpufreq levels won't set, for one. Using speedstep-detect the "GPOs" are as such:
diff 500MHz-detect.txt 650MHz_detect.txt 36,37c36,37 < GPOs: (0x8034): 0x7f77bf1f < (0x8038): 0x63 0x48 0x21 0x00 0x1f 0xbf 0x77 0x7f --- > GPOs: (0x8034): 0x7f77be1f > (0x8038): 0x63 0x48 0x21 0x00 0x1f 0xbe 0x77 0x7f 45c45 < GPOs: (0x8034): 0x7f77bf1f 01111111011101111011111100011111 --- > GPOs: (0x8034): 0x7f77be1f 01111111011101111011111000011111...however the instructions on that page have grown stale and it's not clear how to apply this data, nor whether it would do any good. More routine solutions (use via ACPI, use relaxed-check, etc) don't seem to work.
As it now stands some fiddling with the BIOS can ensure you boot at either 500 or 650MHz and you are stuck at that thereafter, though BIOS assisted battery/ac transitions might work in the "Automatic" mode. My battery is deader than a Texas salad bar, so I wouldn't know.
In addition the es1968 sound driver barks "es1968: not attempting power management." which I haven't even looked into yet.
There's also the "Limiting direct PCI/PCI transfers." dmesg line which is linked to a PCI quirk. Said quirk may only effect certain PCI devices or hard drives -- I intend to do some digging and see if it might be the case that none of the affected devices could ever be put into a solo, in which case eliminating that quirk might make sense for this machine.
Perhaps the most pleasant surprise with this laptop is that the audio chipset is halfway decent. It's no pro-audio workhorse, but it does seem to be mixing multiple applications just fine without an esd/JACK/dmixer setup. All that is needed is ALSA drivers with OSS emulation, and you'll be wanting to add a /dev/dsp0 symlink by hand/udev for apps that don't stat /dev/dsp first like they should. Oh for the day when all the linux apps finally support and default to libasound. (By the way, if you feel like having some diversionary fun with audio, do look into DSSI/LADSPA plugins through .asoundrc they are very neat and prepackaged in Debian.)
Don't expect much in the way of output from the onboard speakers, and if you want to use the mic, very likely you'll want to turn on the boost switch with alsamixer -- without it gain is too low, though not low enough to avoid a nice feedback loop if you put the onboard mic into the mix with the built-in speakers on.
Basic Xorg auto-installs/autodetects well, but a few slight modifications to the configuration are needed to quiet some warnings and get the server started. (Scrollwheel on a USB mouse even managed to work out of the box. Things are definitely improving at a good pace with these packages.)
You'll want the ati xorg server package, and can download my working xorg.conf file here and the corresponding log can be viewed here
The DDC and i2c failure messages are par for the course for laptops -- often bits and pieces of the laptop BIOS sourced by the VESA BIOS disappear under the OS mmap because they weren't properly listed in ACPI, and I do believe that if there is a non-emulated EDID lurking in the panel the ATI drivers may not yet know to use the special extra set of registers to access it on this chipset (haven't dug to look.) Though I do note VESA DDC failing on attached CRTs as well.However X does seem to auto-acquire adequate information on the panel through other means.
I cannot recall whether any actual changes ended up being needed but you may have to follow these instructions to be found in the anti-aliasing-howto (install the package my that name) to get fonts hinting right for the LCD. That's of course a general issue not related to the Solo specifically.
Most importantly I reduced color depth to 16bpp to conserve video ram and memory bus bandwidth, the former of which is very tight on this system (8MB). Between performance and colors I can barely tell the difference between, I'll choose the latter.
DRI for the Mach64 video card (and it is a Mach64, don't let the "Rage" monicer lead you astray) can only be gotten from CVS as of this writing. I haven't bothered since I'm not sure if 3D is worth it on a card that only has 8MB, especially clunky old 3D.
Though it's an inconvenience, I do give kudos to those who drew the line in the sand as far as inclusion of this DRM in the mainstream kernel due to security issues. Someone with pull had to start raising the bar on graphics security and that's a good place to put the uprights.
Though the hardware is technically capable of it, multiple monitor "mergedfb" seems not to have been implemented as of this writing. If it is it's lurking someplace non-googlable.
Xv seems to find and use the overlay quite well.
The "Mobility M/P" chipset in this laptop is one of the many that have fallen by the wayside support-wise. Luckily I'm an old hand at prodding video hardware to life and have thus far managed to figure out how to get it mostly working. I am sending patches to appropriate people, but if you can't wait for them to fold into upstream sources, then feel free to email me.
For informational purposes: there is no tuner (that I can tell) and the i2c interface requires some tweaks to the existing genericv4l and GATOS code trees. Unfortunately because the userspace GATOS utilities seem to demand a tuner and audio be present, quite some hacks are needed to bypass the code that checks for them, and in the genericv4l case there are issues beyond the i2c. I have managed to see both motion video and take still snaps with GATOS, and hope to have genericv4l fully operational with this card eventually.
There is a mono audio connector next to all that mess on the back, but I haven't determined whether it's attached to the bttv yet in addition to the soundcard. (It does appear to be attached to the soundcard, or at least an input for it is listed in the mixer/mux.) Neither of the capture codebases seem to be able to see it, however.
The on-case connector is RCA, however the docking station does provide S-video in/out ports and I believe I have figured out the pins on the docking station connector that carry these signals to/from the bt capture unit. I'll post more about that if/when I get things working.
I haven't tested this yet but will get to it. GATOS package, "atitvout" for this, though booting with a powered-on TV connected to the port and no video/fb drivers has been known to work as a starting point with these cards.
...is hypersensitive and generates poke-click events spuriously. As I'm using a USB mouse I haven't invested any time in taming it. I do like touchpads but this one only has two buttons.
There are two sets of chassis buttons -- a bunch along the top, and some media control ones on the front with a cut-out lockswitch to keep you from accidentally hitting them. Binding them is a bit of a hassle but I'll get to it eventually. They all generate X events without any manual intervention, some of which will fall through to character keymaps until they are mapped. Some generate compound events.
At least lid close events are operational. Battery status might not be, I won't know until I replace this stone dead battery. Seems to be parked permanantly on precious IRQ9, but happy to share it.
UHCI. Yuk. Works fine for mouse/keyboard but I'm not going to push it. If I want external drives or webcams I'll use the firewire port -- both UHCI hardware and (the last time I looked) the Linux driver for it are an utter mess. Seems to have it's very own PIC IRQ line.
With no devices to test, thus far I've only been able to see the encouragingly happy kernel boot messages and paw yearningly at the device files. It seems to be in order. Shares PIC IRQ line with the soundcard, and would be best mapped to 9 or 10 via the BIOS menu, with the cardbus/audio on the other one of those.
Rips fine/no errors with cdparanoia/ide-cd, but is much slower than it should be when used in this manner. DAC is connected to a soundcard channel. Aside from the speed issue, which is likely software, that's about all one can ask of a CD-ROM.
...and sometime in the future your Solo, Tux forbid, meets with an unfortunate fate, do mail me your DVD, docking station, LS-120 or 256M RAM modules if you have them, please :-) Even when eventually I upgrade I'll likely be keeping this unit for use in the living room.
This document is Copyright (C) 2004 Brian S. Julin and may be reproduced and/or used under the terms of the GFDL version 1.2 with no invariant sections.