[<prev] [next>] [day] [month] [year] [list]
Message-ID: <081P9H411@briare1.fullpliant.org>
Date: Sun, 03 Feb 2008 01:58:16 GMT
From: Hubert Tonneau <hubert.tonneau@...lpliant.org>
To: linux-kernel@...r.kernel.org
Subject: Desparately wanted: intelfb modesetting in mainline
As a probable result of Intel opening specifications,
it is now fairly easy to buy a business computer that will run Linux
without loosing weeks hacking to get it up and running:
just go with an intel graphic board since Intel X11 driver now works just fine.
Well, this apply only if you run mainstream Linux, that is X11 for the
graphics, because if your application relies on the framebuffer,
we are still at far west time.
Now that Linux is getting more professional with plenty of hackers paid to do
so, it would be nice to include active minimal completeness of the system goal,
as opposed to just passive filtering of preposed patches,
because without it, small more inovative projects (that sit on top of the
kernel instead of beeing kernel rated projects) have a hard time,
so that Linux behaviour is not that different from closed one:
favor the mainstream and ignore small players at the expense of inovation.
Same applies for user land part of some drivers. The current situation is
complete lack of consistency so that getting a working kernel (which nowdays
means kernel + many user land helpers) get's more and more complicated year
after year, as opposed to early days where user land was just achieving a
fiew simple IOCTLs to configure.
It is very understandable to reject many part of drivers to user land to avoid
too much code (with nasty well known side effects) in the kernel, but just
saying that since it is user land it does not have to follow any rule (such as
beeing part of the kernel source and linking only to kernel source provided
libraries) just means lot of work to distributions (so death of small ones
that are not just a recent fork of a big one)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists