[linux-elitists] Laptop that doesn't suck?
Mon Jan 19 14:05:20 PST 2004
On Mon, Jan 19, 2004 at 01:12:14PM -0800, Jason Spence wrote:
> On Mon, Jan 19, 2004 at 09:32:34AM -0800, Greg KH wrote:
> > On Sun, Jan 18, 2004 at 02:50:18PM -0800, Jason Spence wrote:
> > >
> > > I have a few other things to say about laptop support: every 2 to 2
> > > 1/2 years or so the state of Linux support for newish standards in the
> > > stable kernel goes down the toilet because everyone's concentrating on
> > > the development kernel and many users aren't able or willing to do
> > > free troubleshooting with the development kernel in addition to trying
> > > to use their apps on their laptop.
> > So, to be specific, what do you mean here? ACPI? There was a patch
> > that lived a _long_ time outside of the main 2.4 kernel tree due to the
> > stable maintainer wanting to be careful about what was merged. So if
> > you needed good ACPI support on 2.4, you simply used that patch. It's
> > been successfully merged into the mainline 2.4 kernel a while ago.
> ACPI is one of the big ones, yes. Other culprits include serial ATA
> w/ tagged queuing and stable USB drivers for some of my camera
SATA has only recently gotten Linux support. I can't really talk to
that, but there are patches for 2.4 for this feature.
Remember, as developers, we are SUPPOSED to do new types of development
in the development kernel. After it's working there, do we do a
backport to the stable kernel. That's just the proper way to do new
> I'm aware of the ACPI patches, but they don't solve the underlying
> problem which is that the driver architecture isn't very friendly to
> power management. The last time I tried the bleeding edge ACPI stuff
> for 2.4, I still couldn't suspend 2 out of 3 laptops I tried it with.
ACPI does not equal device suspend. They are two totally different
things. See Pat Mochel's 2003 OLS paper for more information about
this, and for an overview of all of the problems involved in trying to
suspend a machine properly.
So please do not blame ACPI for the lack of suspend working for your
laptop. Truth is, suspend only barely works even on the 2.6 kernel.
Again, see my previous comments about lack of caring by any company...
Oh and a lack of device specs, that's another big one...
> > How about USB? USB 2.0 support was offered as a backport to 2.4, and
> > made it into the main 2.4 tree, relatively quickly (way before any other
> > OS had support for it.)
> Unfortunately, Debian doesn't support USB 2.0 in their stock kernel,
My word. What is a "stock kernel" for Debian then? Isn't it a 2.2
kernel? It's not the kernel developers fault that you are insisting on
using a 2 year old or older, kernel. So don't grumble about lack of "new"
> and at one site I deal with they're so heterogenous that it's not cost
> effective for me to maintain custom kernels for all their machines. I
> also can't use anything but Debian because the site (a school) can't
> afford RHN.
I know there are 2.6 kernels available in Debian, and the last time I
checked they had recent 2.4 kernels too. Hm, looks like it:
$ apt-cache search kernel-image | grep "^kernel-image"
kernel-image-2.2.20-reiserfs - Linux kernel binary image for version 2.2.20.
kernel-image-2.4-386 - Linux kernel image for version 2.4 on 386.
kernel-image-2.4-586tsc - Linux kernel image for version 2.4 on Pentium-Classic.
kernel-image-2.4-686 - Linux kernel image for version 2.4 on PPro/Celeron/PII/PIII/PIV.
kernel-image-2.4-686-smp - Linux kernel image for version 2.4 on PPro/Celeron/PII/PIII/PIV SMP.
kernel-image-2.4-k6 - Linux kernel image for version 2.4 on AMD K6/K6-II/K6-III.
kernel-image-2.4-k7 - Linux kernel image for version 2.4 on AMD K7.
kernel-image-2.4-k7-smp - Linux kernel image for version 2.4 on AMD K7 SMP.
kernel-image-2.4.18-bf2.4 - Linux kernel image for version 2.4.18 (bf variant) on 386.
kernel-image-2.4.22-speakup - Linux kernel image for version 2.4.22-speakup
kernel-image-2.4.22-xfs-386 - Linux kernel image for version 2.4.22 w/ XFS on 386
kernel-image-2.4.22-xfs-686-smp - Linux kernel image for version 2.4.22 w/ XFS on PPro/Celeron/PII/PIII/PIV SMP
kernel-image-2.4.23-1-386 - Linux kernel image for version 2.4.23 on 386.
kernel-image-2.4.23-1-586tsc - Linux kernel image for version 2.4.23 on Pentium-Classic.
kernel-image-2.4.23-1-686 - Linux kernel image for version 2.4.23 on PPro/Celeron/PII/PIII/PIV.
kernel-image-2.4.23-1-686-smp - Linux kernel image for version 2.4.23 on PPro/Celeron/PII/PIII/PIV SMP.
kernel-image-2.4.23-1-k6 - Linux kernel image for version 2.4.23 on AMD K6/K6-II/K6-III.
kernel-image-2.4.23-1-k7 - Linux kernel image for version 2.4.23 on AMD K7.
kernel-image-2.4.23-1-k7-smp - Linux kernel image for version 2.4.23 on AMD K7 SMP.
kernel-image-2.4.24-1-386 - Linux kernel image for version 2.4.24 on 386.
kernel-image-2.4.24-1-586tsc - Linux kernel image for version 2.4.24 on Pentium-Classic.
kernel-image-2.4.24-1-686 - Linux kernel image for version 2.4.24 on PPro/Celeron/PII/PIII/PIV.
kernel-image-2.4.24-1-686-smp - Linux kernel image for version 2.4.24 on PPro/Celeron/PII/PIII/PIV SMP.
kernel-image-2.4.24-1-k6 - Linux kernel image for version 2.4.24 on AMD K6/K6-II/K6-III.
kernel-image-2.4.24-1-k7 - Linux kernel image for version 2.4.24 on AMD K7.
kernel-image-2.4.24-1-k7-smp - Linux kernel image for version 2.4.24 on AMD K7 SMP.
kernel-image-2.6-386 - Linux kernel image for version 2.6 on 386.
kernel-image-2.6-686 - Linux kernel image for version 2.6 on PPro/Celeron/PII/PIII/PIV.
kernel-image-2.6-686-smp - Linux kernel image for version 2.6 on PPro/Celeron/PII/PIII/PIV SMP.
kernel-image-2.6-k7 - Linux kernel image for version 2.6 on AMD K7.
kernel-image-2.6-k7-smp - Linux kernel image for version 2.6 on AMD K7 SMP.
kernel-image-2.6.0-1-386 - Linux kernel image for version 2.6.0 on 386.
kernel-image-2.6.0-1-686 - Linux kernel image for version 2.6.0 on PPro/Celeron/PII/PIII/PIV.
kernel-image-2.6.0-1-686-smp - Linux kernel image for version 2.6.0 on PPro/Celeron/PII/PIII/PIV SMP.
kernel-image-2.6.0-1-k7 - Linux kernel image for version 2.6.0 on AMD K7.
kernel-image-2.6.0-1-k7-smp - Linux kernel image for version 2.6.0 on AMD K7 SMP.
kernel-image-2.6.0-test11-1-386 - Linux kernel image for version 2.6.0-test11 on 386.
kernel-image-2.6.0-test9-1-386 - Linux kernel image for version 2.6.0-test9 on 386.
But I'm running unstable on my Debian boxes :)
> > Is this what you were talking about? Or do you have other specifics of
> > stuff that during 2.4 was not available, but only present in the 2.5
> > tree?
> Those are the only ones I can think of off the top of my head; I may
> be forgetting something, though.
Ok. So Linux doesn't support suspend very well. That's a well known
issue, and might change sometime in the future... (actually Linux on
iBooks suspend quite well, but they have a limited number of devices...)
For USB 2.0 you need a newer kernel than what you are using. It is
> Well, the thing about ext3 is that it keeps the hard disk active all
> the time :) It's a big power drain to keep my 40GB driver spinning the
> entire time I have the laptop on. I've heard anecdotal reports that
> xfs and/or jfs don't do that; are those the journalling filesystems
> you're referring to?
I use ext3 and have a laptop with very good power saving support :)
> The other annoying thing is that the web browsers don't talk to the
> session manager on KDE or GNOME, so every time I get a crash I have to
> reopen all this context I had available on virtual desktops, etc.
Nothing the kernel can do there, sorry.
Comes in the main 2.6 kernel now. 2.4 support will always need the
external kernel modules for a variety of different reasons.
What are these two? Haven't heard of them before.
> In defense of NVidia: SGI owns a buttload of 3-D patents on various
> things, and it's rather difficult to put together a hardware
> accelerated OpenGL implementation that performs at competitive speeds
> AND includes all the SGI_* ARB extensions without paying off SGI and
> using the IP. As a result, NVidia has very little choice except to
> make some of the kernel parts of their driver closed source. So if
> we're going to complain to anyone, it should be SGI, not NVidia.
> There's also another vendor that owns a bunch of IP which NVidia
> licenses, but I can't remember their name right now.
You are saying that NVidia has code that infringes on another company's
IP in their closed source module? Oh, that makes me feel even better...
> I'm rather happy that I have a commercial quality GLX/OpenGL
> implementation for my favorite operating system, regardless of the
> closed sourceness of the driver. I already know many details of the
> internals of their implementation and really wouldn't benefit from
> being able to read the source. If I have problems, I talk to their
> engineers and they're very responsive to my problem reports. I'm very
> surprised you haven't developed a relationship with one of them to
> help with situations like the one you're describing.
The situations I'm describing are where I change a PCI api, and fix up
all places in the kernel tree that use that api. As I can't see the
NVidia code, I can't fix up their usages also.
Users then grab the new kernel, and whine to me that their closed source
code is broken. There's nothing I can do about this (and don't even try
to say "don't change the api," that will _never_ happen, and is a whole
> > So besides that meager support from Intel, what vendors are you thinking
> > of? Hell, no one even cares about USB enough to fund its development,
> > even though you can't buy a server these days without a USB connection
> > for the keyboard...
> Some of the RAID card vendors (Intel/ICP comes to mind), telephony
> card vendors, data acquisition boards, and some of the industrial
> control network interfaces are the ones that I've been worrying about
> this month.
Pointers to specific drivers? Are they outside of the main kernel tree?
I keep hearing this vague "people need to convert their drivers"
argument, and it worries some people at my workplace, yet no one can
come up with specifics...
More information about the linux-elitists