From: Ingo Molnar <mingo@elte.hu>
To: Dave Airlie <airlied@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: kms in defconfig
Date: Mon, 27 Apr 2009 10:39:35 +0200 [thread overview]
Message-ID: <20090427083935.GA20941@elte.hu> (raw)
In-Reply-To: <21d7e9970904270121s1c58365bqc8933f8a3ffc5f1a@mail.gmail.com>
* Dave Airlie <airlied@gmail.com> wrote:
> Hi guys,
>
> I just noticed CONFIG_DRM_I915_KMS is enabled for x86-64.
>
> This should never be the case, as anyone who built defconfig
> kernels before, will now get KMS enabled when really they need to
> have done userspace upgrades.
I've yet to see such a bugreport.
But i dont have particularly strong feelings about defconfigs: less
than 1% of all kernel developers use them - which transforms into
less than 0.01% of all Linux users.
KMS is off by default in 'make oldconfig', right? That's all that
matters really.
defconfigs _do_ change and there was never a compatibility rule for
defconfigs. Arch defconfig is more of a signal towards what the
architecture maintainers consider sane and supportable (or
desirable) defaults - and it is also what developers working on
arch/x86 should consider as the main thrust of features.
> KMS should default to n in the upstream kernel, for at least 4-5
> years.
That's an extremely long period of migration. I also think it's
unreasonable: we dont want to draw out the migration from
DRI1+user-space-mode-setting to DRI2+KMS that long. KMS should have
been implemented and made the default 4-5 years _ago_ i think.
KMS is the sane design for graphics and i'd go as far as to consider
user-space mode setting an outright _bug_. It look a long time to
fix but now lets look forward and fix all the bugs in KMS, ASAP ...
Ingo
next prev parent reply other threads:[~2009-04-27 8:40 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-27 8:21 kms in defconfig Dave Airlie
2009-04-27 8:39 ` Ingo Molnar [this message]
2009-04-27 8:56 ` Dave Airlie
2009-04-28 1:45 ` Tejun Heo
2009-04-28 1:59 ` Linus Torvalds
2009-04-28 6:29 ` Ingo Molnar
2009-04-28 16:54 ` david
2009-04-28 17:13 ` Linus Torvalds
2009-04-28 17:22 ` Ingo Molnar
2009-04-28 17:36 ` Steven Rostedt
2009-04-28 19:18 ` Ingo Molnar
2009-04-28 21:23 ` Steven Rostedt
2009-04-28 17:23 ` david
2009-04-28 17:50 ` Linus Torvalds
2009-04-28 21:43 ` Florian Mickler
2009-04-28 21:50 ` david
2009-04-28 23:10 ` Florian Mickler
2009-04-28 23:29 ` david
2009-04-29 6:55 ` Giacomo Catenazzi
2009-04-29 5:36 ` Andrew Morton
2009-04-29 5:59 ` Dave Airlie
2009-04-27 15:40 ` Peter Zijlstra
2009-04-28 1:54 ` Dave Airlie
2009-04-28 7:32 ` Peter Zijlstra
2009-04-28 17:04 ` Jesse Barnes
2009-04-28 23:42 ` Dave Airlie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090427083935.GA20941@elte.hu \
--to=mingo@elte.hu \
--cc=airlied@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.