ac15 and 2.4.5-pre6, pwc format conversion

ac15 and 2.4.5-pre6, pwc format conversion

[Norbert Preining]

Hi!

According to ac ChangeLog:
o       Rip format conversion out of the pwc driver     (me)
        | It belongs in user space..

This change is included in 2.4.5-pre6, but
	drivers/usb/pwc-uncompress.c
still relies on this files:
gcc -D__KERNEL__ -I/usr/src/linux-2.4.5.6-packet/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=k6 -DMODULE   -DEXPORT_SYMTAB -c pwc-uncompress.c
pwc-uncompress.c:25: vcvt.h: No such file or directory
pwc-uncompress.c: In function `pwc_decompress':
pwc-uncompress.c:158: warning: implicit declaration of function `vcvt_420i_rgb24'
pwc-uncompress.c:161: warning: implicit declaration of function `vcvt_420i_bgr24'
pwc-uncompress.c:164: warning: implicit declaration of function `vcvt_420i_rgb32'
pwc-uncompress.c:167: warning: implicit declaration of function `vcvt_420i_bgr32'
pwc-uncompress.c:171: warning: implicit declaration of function `vcvt_420i_yuyv'
pwc-uncompress.c:185: warning: implicit declaration of function `vcvt_420i_420p'

Best wishes

Norbert

PS: Please reply by email since I am not subscribed and I skim the
mailing list via the web archive.
THANKS.

-- 
ciao
norb

+-------------------------------------------------------------------+
| Norbert Preining              http://www.logic.at/people/preining |
| University of Technology Vienna, Austria        preining@logic.at |
| DSA: 0x09C5B094 (RSA: 0xCF1FA165) mail subject: get [DSA|RSA]-key |
+-------------------------------------------------------------------+

RE: ac15 and 2.4.5-pre6, pwc format conversion

[Nemosoft Unv.]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1559 bytes --]

Greetings,

On 25-May-01 Norbert Preining wrote:
> Hi!
> 
> According to ac ChangeLog:
> o       Rip format conversion out of the pwc driver     (me)
>         | It belongs in user space..
> 
> This change is included in 2.4.5-pre6, but
>       drivers/usb/pwc-uncompress.c
> still relies on this files:
> gcc -D__KERNEL__ -I/usr/src/linux-2.4.5.6-packet/include -Wall
> -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
> -mpreferred-stack-boundary=2 -march=k6 -DMODULE   -DEXPORT_SYMTAB -c
> pwc-uncompress.c
> pwc-uncompress.c:25: vcvt.h: No such file or directory
> pwc-uncompress.c: In function `pwc_decompress':
> pwc-uncompress.c:158: warning: implicit declaration of function
> `vcvt_420i_rgb24'
> pwc-uncompress.c:161: warning: implicit declaration of function
> `vcvt_420i_bgr24'
> pwc-uncompress.c:164: warning: implicit declaration of function
> `vcvt_420i_rgb32'
> pwc-uncompress.c:167: warning: implicit declaration of function
> `vcvt_420i_bgr32'
> pwc-uncompress.c:171: warning: implicit declaration of function
> `vcvt_420i_yuyv'
> pwc-uncompress.c:185: warning: implicit declaration of function
> `vcvt_420i_420p'

That´s what you get for ripping out the guts of a driver. Have a nice day.

 - Nemosoft (the pwc module maintainer)

-----------------------------------------------------------------------------
Try SorceryNet!   One of the best IRC-networks around!   irc.sorcery.net:9000
URL: never        IRC: nemosoft      IscaBBS (bbs.isca.uiowa.edu): Nemosoft
                        >> Never mind the daylight << 

Re: ac15 and 2.4.5-pre6, pwc format conversion

[Erik Mouw]

On Fri, May 25, 2001 at 10:48:12AM +0200, Nemosoft Unv. wrote:
> On 25-May-01 Norbert Preining wrote:
> > According to ac ChangeLog:
> > o       Rip format conversion out of the pwc driver     (me)
> >         | It belongs in user space..
> > 
> > This change is included in 2.4.5-pre6, but
> >       drivers/usb/pwc-uncompress.c
> > pwc-uncompress.c:185: warning: implicit declaration of function
> > `vcvt_420i_420p'
> 
> That´s what you get for ripping out the guts of a driver. Have a nice day.

The format conversion shouldn't be there in the first place. Format
conversion is policy, so it doesn't belong in kernel. Note for example
that none of the sound drivers does sample rate conversion although
some sound chips are locked at 48kHz only.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: ac15 and 2.4.5-pre6, pwc format conversion

[Nemosoft Unv.]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 3926 bytes --]

Greetings,

On 25-May-01 Erik Mouw wrote:
> On Fri, May 25, 2001 at 10:48:12AM +0200, Nemosoft Unv. wrote:
>> That´s what you get for ripping out the guts of a driver. Have a nice
>> day.
> 
> The format conversion shouldn't be there in the first place. Format
> conversion is policy, so it doesn't belong in kernel. Note for example
> that none of the sound drivers does sample rate conversion although
> some sound chips are locked at 48kHz only.

True, but a number of audio tools will break, because they don´t support that
samplerate (mpg123 0.59r, one of the more popular MP3 players, segfaults
when it has to do conversion of 44.1 KHz to 48 KHz). Recording from such a
source is usually less of a problem, although some post-processing is
then necessary (not all tools support samplerate conversion natively).

The situation for video devices is worse. 80% of the video tools will break
if you limit the number of available palettes per driver. Plus, you will get
severe fragmentation of which program works with which driver. Which is
unacceptable, in my opinion (and certainly NOT the idea behind a common API!)

You can blame the authors of those video tools, but that´s not really fair.
The original Video4Linux API was based upon TV grabber cards. Most of them
do YUV/RGB conversion in hardware, so most tools expected that all or most
palettes would always be available, since supporting a palette would not
require any extra CPU cycles [1]. Some tools like RGB, and others YUV, so
the authors happily selected the palette of their choice and never even
considered building in functions for doing conversion. And then I am not even
talking about the RGB/BGR mess.

Then along came parallel-port and USB webcams, which have a number of
´native´ formats which only sometimes match the defined V4L palettes. So
some conversion, albeit trivial, is necessary. Might as well do the full
conversion to various YUV/RGB palettes then, to accomodate as much programs
as possible (granted, some tools are really braindead).

Which is exactly what I did, and therefor I was quite sarcastic in my
previous mail because my driver was targeted for removal of ALL conversion
routines, while (nearly) nothing has been said about other (USB) webcam
drivers which have conversion routines.

Johannes Erdfeld (current USB maintainer) said he would go over the other
USB drivers and see which ones are eligeble for removal of YUV->RGB
conversion (which are, btw: ov511 and cpia; ibmcam flatly refuses anything
except RGB24). I warned him that if he does so, he will get a lot of angry
looks from users.

I do agree that the kernel may not be the proper place for these kind of
conversions. But as I wrote to Alan Cox earlier today that if he wanted to
fix this, he should fix the problem, which are ´simplistic´ programs and a
hardware specific API (V4L1, and V4L2 isn´t that much better), and not
target the drivers. But it will take something really radical (like removing
the V4L API altogether), that will wake up the authors of ALL video
tools and ´fix´ their programs. Alan Cox certainly isn´t going to do that
himself, and neither am I :)

In other words: if you want to break it, break it well. Don´t smash the
saucer without the cup.

 - Nemosoft


[1] There´s an additional problem, which has plagued my driver for quite
some time: TV cards can scale the image to any size, again in hardware. For
webcams which only have a few fixed sizes, some padding or cropping may be
required (this can usually be programmed very easily, and requires only a few
extra CPU cycles). Scaling on the fly is definitely out of the question, even
for me.

-----------------------------------------------------------------------------
Try SorceryNet!   One of the best IRC-networks around!   irc.sorcery.net:9000
URL: never        IRC: nemosoft      IscaBBS (bbs.isca.uiowa.edu): Nemosoft
                        >> Never mind the daylight << 

Re: ac15 and 2.4.5-pre6, pwc format conversion

[Alan Cox]

> > that none of the sound drivers does sample rate conversion although
> > some sound chips are locked at 48kHz only.
> 
> True, but a number of audio tools will break, because they don=B4t supp=

So fix the tools

> if you limit the number of available palettes per driver. Plus, you wil=
> l get
> severe fragmentation of which program works with which driver. Which is
> unacceptable, in my opinion (and certainly NOT the idea behind a common=
>  API!)

Fix the tools.

> routines, while (nearly) nothing has been said about other (USB) webcam
> drivers which have conversion routines.

I have those in my firing line too. It has always been the policy that format
conversions go in user space. The kernel is an arbitrator of resources it is
not a shit bucket for solving other peoples incompetence.

Alan

Re: ac15 and 2.4.5-pre6, pwc format conversion

[Nemosoft Unv.]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 4186 bytes --]

Greetings,

Coalescing two messages in one:

On 25-May-01 Alan Cox wrote:
> Nope. Its been policy since 2.0. Its both v4l1 and v4l2 policy. In fact its
> fairly nonsensical to handle any format conversions in kernel unless the
> device outputs a unique format of its own.

Oh come on. 2.0 has been out since, what? 1996? Methinks you have had plenty
of time to really do something about it then. You are now simply too late.

> It breaks apps by doing conversions, and it breaks important apps like H263
> codecs not silly little camera viewers, because you trash the performance

This is a NULL argument. First, it doesn´t break anything; I think H263 is
smart to pick a YUV format if it´s available. Second, conversion has to be
done at one point or another. If the native format of the camera is RGB,
H263 will have to convert to YUV. Wether or not this is done in kernel space
or user space doesn´t matter: it has to be done. And in case the native
format of the camera doesn´t resemble anything in V4L, you will have TWO
conversion: first, in kernel from native to V4L palette, and then in your
tool from V4L to whatever format you need, while maybe the driver could do
it all in one stage.

On 25-May-01 Alan Cox wrote:
>> > that none of the sound drivers does sample rate conversion although
>> > some sound chips are locked at 48kHz only.
>> 
>> True, but a number of audio tools will break, because they don=B4t supp=
> 
> So fix the tools
> 
>> if you limit the number of available palettes per driver. Plus, you wil=
>> l get
>> severe fragmentation of which program works with which driver. Which is
>> unacceptable, in my opinion (and certainly NOT the idea behind a common=
>>  API!)
> 
> Fix the tools.

Gee, ¨Fix the tools¨ seems to be your mantra :-(. Anyway, breaking the tools
doesn´t necessarely mean they are going to get fixed; not all are
being actively maintained at the moment (okay, that´s a pity; still it´s a
shame).

And you are probably not going to get the endless streams of mails to the
webcam developers which state: ¨I upgraded my kernel to 2.4.X and my webcam
broke!¨ Do you really think we will enjoy replying time after time: ¨Yes, I
know, but Alan Cox told me to do so¨. No. To a lot of users, and even
application developers, this just plainly sucks.

>> routines, while (nearly) nothing has been said about other (USB) webcam
>> drivers which have conversion routines.
> 
> I have those in my firing line too. It has always been the policy that
> format
> conversions go in user space. The kernel is an arbitrator of resources it
> is not a shit bucket for solving other peoples incompetence.

Now you are being insulting, really. There are a lot of competent people
who put a lot of time and effort into these tools. But the Video4Linux API
is not complete and not completely suitable for webcams. For example, it
misses the quite fundamental call to query the available palettes; nor does
the V4L API give any hint that the number of palettes might be severely
limited. The first tools that were created had the luxury of hardware that
did all the work for them, so why not use it? Webcams are not so lucky.
There´s no need to penalize them, because if the change goes through, a lot
of tools will not work with webcams but with TV cards.

                                         ...

Anyway, I am not going to debate this any further at this point. Johannes,
please remove my webcam driver from the USB source tree, until the software
YUV/RGB conversion has been removed from ALL other video devices (preferably
all at the same time). I will *not* have a crippled driver into the Linux
kernel. If this is going to be policy, fine. But then this policy will apply
to ALL drivers equally, not just mine because suddenly Alan realizes he has
been sleeping for the past 5 years and decides to implement a policy hardly
noone ever knew existed.

 - Nemosoft

-----------------------------------------------------------------------------
Try SorceryNet!   One of the best IRC-networks around!   irc.sorcery.net:9000
URL: never        IRC: nemosoft      IscaBBS (bbs.isca.uiowa.edu): Nemosoft
                        >> Never mind the daylight << 

Re: ac15 and 2.4.5-pre6, pwc format conversion

[Jeff Garzik]

"Nemosoft Unv." wrote:
> On 25-May-01 Alan Cox wrote:
> > It breaks apps by doing conversions, and it breaks important apps like H263
> > codecs not silly little camera viewers, because you trash the performance
> 
> This is a NULL argument. First, it doesn´t break anything; I think H263 is
> smart to pick a YUV format if it´s available. Second, conversion has to be
> done at one point or another. If the native format of the camera is RGB,
> H263 will have to convert to YUV. Wether or not this is done in kernel space
> or user space doesn´t matter: it has to be done. And in case the native
> format of the camera doesn´t resemble anything in V4L, you will have TWO
> conversion: first, in kernel from native to V4L palette, and then in your
> tool from V4L to whatever format you need, while maybe the driver could do
> it all in one stage.

Sorry this is a slippery slope argument and it won't wash.

The kernel is intended as the arbiter between userspace and hardware,
and userspace and userspace.  Format conversion has nothing to do with
arbitration.

Format conversion in kernelspace is far less flexible than userspace: 
you cannot replace your algorithms at will nor fix bugs at will.  You
cannot support assembly optimizations for format conversions without
bloating the kernel.

Finally, the example you describe is invalid.  If your tool is doing
-two- format conversions, then [again] the tool should be fixed.  The
kernel most definitely should not work around stupid shortcomings of
userspace software.


> Anyway, I am not going to debate this any further at this point. Johannes,
> please remove my webcam driver from the USB source tree,

whatever.  I don't see Alan or Linus accepting such a change, even if
Johannes does.


> until the software
> YUV/RGB conversion has been removed from ALL other video devices (preferably
> all at the same time).

Send a patch for this instead!

Format conversion should not be in the kernel...

	Jeff


-- 
Jeff Garzik      | "Are you the police?"
Building 1024    | "No, ma'am.  We're musicians."
MandrakeSoft     |

The difference between Linus's kernel and Alan Cox's kernel

[Thiago Vinhas de Moraes]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi.

Maybe lots of you already know the answer, maybe it's a really stupid 
question. If it is, please tell me. I'll not be offended.

Why there are two different kernel trees? There is always the official 
release, provided by Torvalds, and then Alan provides a patch merging Linus's 
stuff, and adding (?) tons of bug fixes.

Why aren't the -ac patches completely merged to the official tree, and you 
centralize the work on single kernel patches ?? Won't it be easier to 
administrate?

I'm so sorry if it's a really stupid question. It's because I never know what 
pre-patch to apply, the -ac* or the -pre*. In doubt, I apply Alan's, because 
it appears to be always Linus stuff, and more bug fixes, recently, the 
Linus's -pre* appears to have merges from the -ac on each release.
I just don't understand why it can all be merged.


Regards,
Thiago Vinhas de Moraes
NetWorx - A SuaCompanhia.com
Rio de Janeiro - Brazil
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7Dry8GHuTR9LK9ocRAsIIAKCs/uMrlDxZSlst8J0h0D6k6tylkACeKNMB
ESyPHbcpcbxWr48NySQYUBs=
=FotG
-----END PGP SIGNATURE-----

Re: The difference between Linus's kernel and Alan Cox's kernel

[Erik Mouw]

On Fri, May 25, 2001 at 05:12:39PM -0300, Thiago Vinhas de Moraes wrote:
> Why there are two different kernel trees? There is always the official 
> release, provided by Torvalds, and then Alan provides a patch merging Linus's 
> stuff, and adding (?) tons of bug fixes.

I just added this to the kernelnewbies FAQ:

  http://www.kernelnewbies.org/faq.php3


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: The difference between Linus's kernel and Alan Cox's kernel

[CaT]

On Fri, May 25, 2001 at 11:32:18PM +0200, Erik Mouw wrote:
> On Fri, May 25, 2001 at 05:12:39PM -0300, Thiago Vinhas de Moraes wrote:
> > Why there are two different kernel trees? There is always the official 
> > release, provided by Torvalds, and then Alan provides a patch merging Linus's 
> > stuff, and adding (?) tons of bug fixes.
> 
> I just added this to the kernelnewbies FAQ:
> 
>   http://www.kernelnewbies.org/faq.php3

Typo: First para, last sentence: s/Linux/Linus/

-- 
CaT (cat@zip.com.au)		*** Jenna has joined the channel.
				<cat> speaking of mental giants..
				<Jenna> me, a giant, bullshit
				<Jenna> And i'm not mental
					- An IRC session, 20/12/2000

Re: The difference between Linus's kernel and Alan Cox's kernel

[Erik Mouw]

On Sat, May 26, 2001 at 07:40:18AM +1000, CaT wrote:
> On Fri, May 25, 2001 at 11:32:18PM +0200, Erik Mouw wrote:
> > I just added this to the kernelnewbies FAQ:
> > 
> >   http://www.kernelnewbies.org/faq.php3
> 
> Typo: First para, last sentence: s/Linux/Linus/

Oops. Fixed, thanks.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: The difference between Linus's kernel and Alan Cox's kernel

[Alan Cox]

> Why there are two different kernel trees? There is always the official 
> release, provided by Torvalds, and then Alan provides a patch merging Linus's 
> stuff, and adding (?) tons of bug fixes.

Well it started by accident but it turns out good to have a tree that changes
are merged into, tested by those who need the fixes and reviewed by third
parties before they go to Linus.

So the -ac tree is kind of a peer review, testing and distillation process for
patches.

Re: The difference between Linus's kernel and Alan Cox's kernel

[Thiago Vinhas de Moraes]

Em Sex 25 Mai 2001 20:05, Alan Cox escreveu:
> > Why there are two different kernel trees? There is always the official
> > release, provided by Torvalds, and then Alan provides a patch merging
> > Linus's stuff, and adding (?) tons of bug fixes.
>
> Well it started by accident but it turns out good to have a tree that
> changes are merged into, tested by those who need the fixes and reviewed by
> third parties before they go to Linus.
>
> So the -ac tree is kind of a peer review, testing and distillation process
> for patches.

But will this happen forever? You (Alan) is currently the maintaner of the 
2.2 tree. Won't you be going to assume the 2.4 tree, while the 2.5 series 
development starts?

BTW, Thanks for your answer.

Regards,
-- 
________________________________
 Thiago Vinhas de Moraes
 NetWorx - A SuaCompanhia.com

Re: ac15 and 2.4.5-pre6, pwc format conversion

[Alan Cox]

> all at the same time). I will *not* have a crippled driver into the Lin=
> ux
> kernel. If this is going to be policy, fine. But then this policy will =
> apply
> to ALL drivers equally, not just mine because suddenly Alan realizes he=

I've had the others on the list for a while too, jus this one was very easy
to fix and mindbogglingly annoying

> been sleeping for the past 5 years and decides to implement a policy ha=
> rdly
> noone ever knew existed.

The policy has been there since day 1. This is a kernel not a library. You've
written some very nice conversion library routines and I do hope you contribute
those in userspace where they belong

Re: ac15 and 2.4.5-pre6, pwc format conversion

[Erik Mouw]

On Fri, May 25, 2001 at 03:22:44PM +0200, Nemosoft Unv. wrote:
> On 25-May-01 Erik Mouw wrote:
> > On Fri, May 25, 2001 at 10:48:12AM +0200, Nemosoft Unv. wrote:
> > The format conversion shouldn't be there in the first place. Format
> > conversion is policy, so it doesn't belong in kernel. Note for example
> > that none of the sound drivers does sample rate conversion although
> > some sound chips are locked at 48kHz only.
> 
> True, but a number of audio tools will break, because they don´t support that
> samplerate (mpg123 0.59r, one of the more popular MP3 players, segfaults
> when it has to do conversion of 44.1 KHz to 48 KHz). Recording from such a
> source is usually less of a problem, although some post-processing is
> then necessary (not all tools support samplerate conversion natively).

I consider that a bug in mpg123. Examples for rate conversion have been
available for years, so fix mpg123.

> The situation for video devices is worse. 80% of the video tools will break
> if you limit the number of available palettes per driver. Plus, you will get
> severe fragmentation of which program works with which driver. Which is
> unacceptable, in my opinion (and certainly NOT the idea behind a common API!)

I consider this a bug in the tools. I've been working with real-time
video on sgi IRIX machines, and they do a couple of things right:

- The hardware supports a limited set of video formats. Most high end
  stuff (Onyx+Sirius, Octane+DV, Onyx2+DIVO) only supports a couple of
  YUV or YUVA formats (in studios YUV422 or YUV422+A is the most used).
  Low end workstations (Indy, O2) supports some "consumer" formats like
  RGB or Y as well.
- There are a couple of libraries (vl, cl, dmedia, audio, audiofile)
  that allows you to do all kinds of manipulations in userland.

Fortunately sgi also recognises this, and they're porting their
libraries to Linux (see oss.sgi.com).

> You can blame the authors of those video tools, but that´s not really fair.
> The original Video4Linux API was based upon TV grabber cards. Most of them
> do YUV/RGB conversion in hardware, so most tools expected that all or most
> palettes would always be available, since supporting a palette would not
> require any extra CPU cycles [1]. Some tools like RGB, and others YUV, so
> the authors happily selected the palette of their choice and never even
> considered building in functions for doing conversion. And then I am not even
> talking about the RGB/BGR mess.

The original V4L API was *implemented* first on TV grabber cards, but
was certainy written with other video equipment in mind. I remember I
looked at the API with the sgi stuff in mind, and considered it quite
sane.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: ac15 and 2.4.5-pre6, pwc format conversion

[Alan Cox]

> According to ac ChangeLog:
> o       Rip format conversion out of the pwc driver     (me)
>         | It belongs in user space..
> 
> This change is included in 2.4.5-pre6, but
> drivers/usb/pwc-uncompress.c
> still relies on this files:

Looks like I managed to send Linus a partial patch only. My fault-will fix

Re: The difference between Linus's kernel and Alan Cox's kernel

[Wayne.Brown]

It really ought to be Linus and/or Alan who answers this, but from my own
observations, here's the way I think it goes:

Alan and Linus don't always agree on what should be in the kernel; and even when
they do, they sometimes disagree on when something is ready to be included.
Alan may think a particular set of patches are ready, while Linus thinks they
need to mature a bit more; or perhaps he thinks the whole approach is wrong and
should be scrapped.  So Alan puts it in his kernel, and Linus leaves it out of
his.  (Of course, sometimes it's Linus who adds something that Alan rejects.)
It sometimes happens that one of these new ideas turns out better than expected
(especially after going through a few bug report/new patch cycles), and the
person who rejected it changes his mind and includes it later; or maybe it
doesn't work out and gets dropped altogether.  Also, as you've already observed,
Alan regularly resyncs major parts of his tree with Linus' so they don't get too
far apart, and Linus occasionally does the same.

It used to bother me, too, to have to keep up with two different kernel trees.
But I've come to realize that this is a Good Thing.  It provides a way for
people with different viewpoints to approach an idea from more than one
direction.  If the two kernels are trying to solve a particular problem in
different ways, we get to see how each approach works in the real world, rather
than just in a theoretical discussion.  If the two kernels branch too far apart
it could be a problem, but Linus and Alan have been diligent about keeping that
from happening.  I think the interplay (is "competition" too strong a word?)
between the two branches has helped make the "official" kernel better than it
might have been otherwise.

Wayne