APMD-List:
Archives

  From: Avery Pennarun <apenwarr@worldvisions.ca>
  To  : Jont Allen <jba@research.att.com>
  Date: Sat, 2 Oct 1999 12:03:10 -0400

priorities (was Re: Questions/comments about apmsleep)

On Fri, Oct 01, 1999 at 11:35:36PM -0400, Jont Allen wrote:

> MY first priority would be to nail down all the reliability issues,
> which abound. Not because of the linux code, rather because of the
> apm-bios bugs and various MFDR idiosyncrasy. What is needed is
> a uniform experience across all notebooks, and better integration
> with the desktop. 

Sure, that would be nice.  Unfortunately, the other issues that we work on
are much smaller and easier to deal with.  That's because we don't have time
to tackle the major issues.

Why doesn't Linux work well on many laptops?  You hit the nail on the head
in the above paragraph: APM BIOS bugs and various laptop idiosyncrasies. 
The Linux device driver model works great when there are lots of people
using the same device (e.g. Sound Blaster cards, IDE CD-ROMs, or NE2000
ethernet clones).  The model falls apart when you have to tweak all your
drivers for every single little arbitrary change in every laptop.

In Windows, I need a different driver disk for every different NE2000 clone
I own - not because the cards are actually very different, but because the
vendor didn't test any other cards and didn't want to support them. 
One driver in Linux runs _all_ the NE2000 clone cards.  That means that the
user goes through extra hassle in Windows if they buy a 'normal' NE2000 card,
and (lots of) extra hassle in Linux if they buy an unusual one.

> I just helped a friend install Linux (over the last 3 weeks) on an Toshiba
> 7020. The sound (OSS) barely works. No stereo (mono only), no record. The
> suspend/resume seems to work. However after I installed the latest PCMCIA
> software (complements of Dave), and after plugging in the NIC, cardctl
> eject, apm -s, resume, plug in the NIC, the SYSTEM hangs hard. Hard reboot
> required. Bummer. This is a $4000 computer. 1024x768. 100 MBs of memory.
> Top of the line.
[...]
> We needed to install a 2.2.12 kernel to get the sound to work at all.

So it didn't work before, but now it works in a 2.2.12 kernel?  That sounds
like people are making progress to me.

Brand new, top of the line laptops work in Windows because they were tested
that way.  The vendor also includes in their "slightly modified Windows"
system, some interesting components:

	- a custom video driver
	- a custom netcard driver
	- a custom PCMCIA driver
	- a custom sound driver
	- a custom APM driver
	- (nowadays) a custom ACPI driver
	
Some of these "custom" drivers are just standard ones relabelled with
the vendor's brand name.  Others have necessary tweaks in order to work at
all.  The important thing though, is that the day the first person buys his
first laptop, these tools are available.

Naturally, Linux developers have to wait until _after_ the laptop is out for
a while before they can hope to support its weird incompatibilities.  The
fact that 2.2.12 is getting there, while earlier kernels failed completely,
is a good sign.

> We need to make sure this type of stuff cannot happen. I expect I will
> figure out why it happened, but it shouldn't (and can't if Linux is going
> to make it).

Linux developers are already working at full capacity, and it's impossible
to solve problems they've never seen because they only happen on your
particular brand/model of laptop.  Your problem is actually a political
problem.  One of the following solutions might help:

  - somehow convince vendors to stop shipping products with weird bugs
    (especially in the APM BIOS) - yeah right.  But it's worth a try.
    
  - somehow convince vendors to test their systems with Linux before they
    ship, and if they don't work, fix Linux until they do.  This might
    actually happen, the way things are going lately.  But it won't happen
    immediately.

  - fix it yourself and send in the patch.  Even if you can blame the
    particular laptop, the kernel people will still almost always accept a
    workaround patch.  Try to make it general, so that Linux can work around
    a whole class of problems similar to yours.
	  
  - send really, really detailed bug reports to the right people (they might
    be on this mailing list, but they probably aren't me).  Debug it as far
    as you can, then report what you've learned and ask for help.  It's
    possible to debug a system-specific problem remotely - I've done it lots
    of times - but it's a serious pain and often no one feels it's worth the
    effort.
    
Finally, keep in mind that my laptop works fine, so it's not every laptop in
the whole world that's failing.  (It's not just yours, either.)

Have fun,

Avery