From: Chris Wilson <chris@chris-wilson.co.uk>
To: Daniel Vetter <daniel@ffwll.ch>, James Simmons <jsimmons@infradead.org>
Cc: Tomasz Stanislawski <t.stanislaws@samsung.com>,
linux-fbdev@vger.kernel.org,
Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>,
Marcus Lorentzon <marcus.lorentzon@linaro.org>,
Pawel Osciak <pawel@osciak.com>,
Magnus Damm <magnus.damm@gmail.com>,
dri-devel@lists.freedesktop.org,
Alexander Deucher <alexander.deucher@amd.com>,
Rob Clark <rob@ti.com>,
linux-media@vger.kernel.org,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
Date: Wed, 22 Feb 2012 16:36:32 +0000 [thread overview]
Message-ID: <e39f63$3q903a@fmsmga002.fm.intel.com> (raw)
In-Reply-To: <20120222162424.GE4872@phenom.ffwll.local>
On Wed, 22 Feb 2012 17:24:24 +0100, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Feb 22, 2012 at 04:03:21PM +0000, James Simmons wrote:
> > Fbcon scrolling at be painful at HD or better modes. Fbcon needs 3
> > possible accels; copyarea, imageblit, and fillrect. The first two could be
> > hooked from the TTM layer. Its something I plan to experiment to see if
> > its worth it.
>
> Let's bite into this ;-) I know that fbcon scrolling totally sucks on big
> screens, but I also think it's a total waste of time to fix this. Imo
> fbcon has 2 use-cases:
> - display an OOSP.
> - allow me to run fsck (or any other desaster-recovery stuff).
3. Show panics.
Ensuring that nothing prevents the switch to fbcon and displaying the
panic message is the reason why we haven't felt inclined to accelerate
fbcon - it just gets messy for no real gain.
For example: https://bugs.freedesktop.org/attachment.cgi?idH933
which doesn't handle flushing of pending updates via the GPU when
writing with the CPU during interrupts (i.e. a panic).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
WARNING: multiple messages have this Message-ID (diff)
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Daniel Vetter <daniel@ffwll.ch>, James Simmons <jsimmons@infradead.org>
Cc: Tomasz Stanislawski <t.stanislaws@samsung.com>,
linux-fbdev@vger.kernel.org,
Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>,
Marcus Lorentzon <marcus.lorentzon@linaro.org>,
Pawel Osciak <pawel@osciak.com>,
Magnus Damm <magnus.damm@gmail.com>,
dri-devel@lists.freedesktop.org,
Alexander Deucher <alexander.deucher@amd.com>,
Rob Clark <rob@ti.com>,
linux-media@vger.kernel.org,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
Date: Wed, 22 Feb 2012 16:36:32 +0000 [thread overview]
Message-ID: <e39f63$3q903a@fmsmga002.fm.intel.com> (raw)
In-Reply-To: <20120222162424.GE4872@phenom.ffwll.local>
On Wed, 22 Feb 2012 17:24:24 +0100, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Feb 22, 2012 at 04:03:21PM +0000, James Simmons wrote:
> > Fbcon scrolling at be painful at HD or better modes. Fbcon needs 3
> > possible accels; copyarea, imageblit, and fillrect. The first two could be
> > hooked from the TTM layer. Its something I plan to experiment to see if
> > its worth it.
>
> Let's bite into this ;-) I know that fbcon scrolling totally sucks on big
> screens, but I also think it's a total waste of time to fix this. Imo
> fbcon has 2 use-cases:
> - display an OOSP.
> - allow me to run fsck (or any other desaster-recovery stuff).
3. Show panics.
Ensuring that nothing prevents the switch to fbcon and displaying the
panic message is the reason why we haven't felt inclined to accelerate
fbcon - it just gets messy for no real gain.
For example: https://bugs.freedesktop.org/attachment.cgi?id=48933
which doesn't handle flushing of pending updates via the GPU when
writing with the CPU during interrupts (i.e. a panic).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
WARNING: multiple messages have this Message-ID (diff)
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Daniel Vetter <daniel@ffwll.ch>, James Simmons <jsimmons@infradead.org>
Cc: Tomasz Stanislawski <t.stanislaws@samsung.com>,
linux-fbdev@vger.kernel.org,
Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>,
Marcus Lorentzon <marcus.lorentzon@linaro.org>,
Pawel Osciak <pawel@osciak.com>,
Magnus Damm <magnus.damm@gmail.com>,
dri-devel@lists.freedesktop.org,
Alexander Deucher <alexander.deucher@amd.com>,
Rob Clark <rob@ti.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
linux-media@vger.kernel.org
Subject: Re: Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes
Date: Wed, 22 Feb 2012 16:36:32 +0000 [thread overview]
Message-ID: <e39f63$3q903a@fmsmga002.fm.intel.com> (raw)
In-Reply-To: <20120222162424.GE4872@phenom.ffwll.local>
On Wed, 22 Feb 2012 17:24:24 +0100, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Feb 22, 2012 at 04:03:21PM +0000, James Simmons wrote:
> > Fbcon scrolling at be painful at HD or better modes. Fbcon needs 3
> > possible accels; copyarea, imageblit, and fillrect. The first two could be
> > hooked from the TTM layer. Its something I plan to experiment to see if
> > its worth it.
>
> Let's bite into this ;-) I know that fbcon scrolling totally sucks on big
> screens, but I also think it's a total waste of time to fix this. Imo
> fbcon has 2 use-cases:
> - display an OOSP.
> - allow me to run fsck (or any other desaster-recovery stuff).
3. Show panics.
Ensuring that nothing prevents the switch to fbcon and displaying the
panic message is the reason why we haven't felt inclined to accelerate
fbcon - it just gets messy for no real gain.
For example: https://bugs.freedesktop.org/attachment.cgi?id=48933
which doesn't handle flushing of pending updates via the GPU when
writing with the CPU during interrupts (i.e. a panic).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
next prev parent reply other threads:[~2012-02-22 16:36 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <201201171126.42675.laurent.pinchart@ideasonboard.com>
[not found] ` <1654816.MX2JJ87BEo@avalon>
2012-02-16 23:25 ` Kernel Display and Video API Consolidation mini-summit at ELC 2012 - Notes Laurent Pinchart
2012-02-16 23:25 ` Laurent Pinchart
2012-02-17 9:55 ` Daniel Vetter
2012-02-17 9:55 ` Daniel Vetter
2012-02-17 18:46 ` Laurent Pinchart
2012-02-17 18:46 ` Laurent Pinchart
2012-02-22 16:03 ` James Simmons
2012-02-22 16:03 ` James Simmons
2012-02-22 16:24 ` Daniel Vetter
2012-02-22 16:24 ` Daniel Vetter
2012-02-22 16:28 ` Rob Clark
2012-02-22 16:28 ` Rob Clark
2012-02-23 7:34 ` Michel Dänzer
2012-02-23 7:34 ` Michel Dänzer
2012-02-23 7:34 ` Michel Dänzer
2012-02-22 16:36 ` Chris Wilson [this message]
2012-02-22 16:36 ` Chris Wilson
2012-02-22 16:36 ` Chris Wilson
2012-02-22 16:40 ` Clark, Rob
2012-02-22 16:40 ` Clark, Rob
2012-02-22 17:26 ` James Simmons
2012-02-22 17:26 ` James Simmons
2012-02-23 0:15 ` Alan Cox
2012-02-22 17:00 ` Adam Jackson
2012-02-22 17:00 ` Adam Jackson
2012-02-20 16:09 ` Guennadi Liakhovetski
2012-02-20 16:09 ` Guennadi Liakhovetski
2012-02-20 16:19 ` David Airlie
2012-02-20 16:19 ` David Airlie
2012-05-17 2:46 ` Jun Nie
2012-05-17 2:46 ` Jun Nie
2012-05-17 7:53 ` Hans Verkuil
2012-05-17 7:53 ` Hans Verkuil
2012-02-17 11:07 ` Semwal, Sumit
2012-02-17 11:19 ` Semwal, Sumit
2012-02-17 18:49 ` Laurent Pinchart
2012-02-17 18:49 ` Laurent Pinchart
2012-02-17 19:42 ` Adam Jackson
2012-02-17 19:42 ` Adam Jackson
2012-02-18 17:53 ` Clark, Rob
2012-02-18 17:53 ` Clark, Rob
2012-02-18 0:56 ` Keith Packard
2012-02-18 0:56 ` Keith Packard
2012-02-18 0:56 ` Keith Packard
2012-02-20 16:40 ` Guennadi Liakhovetski
2012-02-20 16:40 ` Guennadi Liakhovetski
2012-03-02 14:23 ` Heiko Stübner
2012-03-02 14:23 ` Heiko Stübner
2012-03-02 15:56 ` Marcus Lorentzon
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='e39f63$3q903a@fmsmga002.fm.intel.com' \
--to=chris@chris-wilson.co.uk \
--cc=alexander.deucher@amd.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=jsimmons@infradead.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=magnus.damm@gmail.com \
--cc=marcus.lorentzon@linaro.org \
--cc=pawel@osciak.com \
--cc=rob@ti.com \
--cc=sakari.ailus@maxwell.research.nokia.com \
--cc=t.stanislaws@samsung.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.