From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Daniel Stone <daniel@fooishbar.org>
Cc: Ander Conselvan de Oliveira
<ander.conselvan.de.oliveira@intel.com>,
intel-gfx <intel-gfx@lists.freedesktop.org>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Paulo Zanoni <paulo.r.zanoni@intel.com>,
Daniel Vetter <daniel.vetter@ffwll.ch>
Subject: Re: [PATCH] drm/i915: Enable atomic support by default on supported platforms.
Date: Thu, 9 Feb 2017 16:01:55 +0100 [thread overview]
Message-ID: <d80964e5-564f-9dd4-e7a4-3c1390e8669e@linux.intel.com> (raw)
In-Reply-To: <CAPj87rOnpEXTRzuFqCO++wUWOMqvTOrf4oH6-LWYk3-wFGs58g@mail.gmail.com>
Op 09-02-17 om 14:54 schreef Daniel Stone:
> Hey,
>
> On 9 February 2017 at 12:49, Maarten Lankhorst
> <maarten.lankhorst@linux.intel.com> wrote:
>> Op 02-02-17 om 17:26 schreef Daniel Stone:
>>> On 2 February 2017 at 07:41, Maarten Lankhorst
>>> <maarten.lankhorst@linux.intel.com> wrote:
>>>> Flip the switch!!
>>> Not until we have the multi-CRTC event support please. :\ I don't want
>>> to have divergent event paths for atomic-but-useless-events.
>>>
>>> I've been frantically typing up support for this in Weston (actual
>>> proper atomic modesetting, which is difficult when you have fiercely
>>> independent per-output repaint loops, but seems ~mostly done but for
>>> typing), which I'd hoped to have done a week or two ago but got
>>> derailed due to being sick. It's coming just as quickly as I can type
>>> it tho.
>> The patch for this has been shot down before, due to lack of userspace,
>> but here's a slightly earlier version.
>>
>> https://patchwork.kernel.org/patch/7025111/
>>
>> I guess it's less important now that we support out-fences, which provides
>> a nicer way of waiting for completion.
>>
>> But since this is a problem with atomic core, not i915, do you have any
>> objections specifically against this patch?
> Yeah, it's a pretty good point; we can merge this with a cap so
> userspace can probe whether or not things are usable. There are a few
> other drivers which already expose atomic by default regardless; it
> was less of a problem for them since they're far less likely to be
> used with multiple outputs, but that's not really a fair reason to
> penalise you guys ...
>
> Go for it.
>
> Cheers,
> Daniel
Pushed, thanks!
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
prev parent reply other threads:[~2017-02-09 15:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-02 7:41 [PATCH] drm/i915: Enable atomic support by default on supported platforms Maarten Lankhorst
2017-02-02 8:25 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-02-02 15:20 ` [PATCH] " Lyude Paul
2017-02-02 16:26 ` Daniel Stone
2017-02-03 8:32 ` Maarten Lankhorst
2017-02-09 12:49 ` Maarten Lankhorst
2017-02-09 13:54 ` Daniel Stone
2017-02-09 15:01 ` Maarten Lankhorst [this message]
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=d80964e5-564f-9dd4-e7a4-3c1390e8669e@linux.intel.com \
--to=maarten.lankhorst@linux.intel.com \
--cc=ander.conselvan.de.oliveira@intel.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel@fooishbar.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=paulo.r.zanoni@intel.com \
--cc=rodrigo.vivi@intel.com \
/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.