Hi Daniel,
On Friday 13 May 2011 18:16:30 Daniel Vetter wrote:
Hi Jesse,
Discussion here in Budapest with v4l and embedded graphics folks was
extremely fruitful. A few quick things to take away - I'll try to dig
through all
the stuff I've learned more in-depth later (probably in a blog
On Fri, May 13, 2011 at 8:02 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Fri, 13 May 2011 18:16:30 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Hi Jesse,
Discussion here in Budapest with v4l and embedded graphics folks was
extremely fruitful. A few quick things to take away -
On Fri, 13 May 2011 18:16:30 +0200
Daniel Vetter daniel.vet...@ffwll.ch wrote:
Hi Jesse,
Discussion here in Budapest with v4l and embedded graphics folks was
extremely fruitful. A few quick things to take away - I'll try to dig
through all
the stuff I've learned more in-depth later
2011/4/25 Stéphane Marchesin stephane.marche...@gmail.com:
On Mon, Apr 25, 2011 at 16:22, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, 25 Apr 2011 16:16:18 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Tue, Apr 26, 2011 at 5:01 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
A lot of older hardware had one overlay that could be sourced to any
crtc, just not simultaneously. The tricky part is the formats and
capabilities: alpha blending, color/chromakey, gamma correction, etc.
Even the
On Mon, Apr 25, 2011 at 5:12 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
Looking for comments on this. Obviously if we're going to add a new type
of KMS object, we'd better get the ioctl more or less right to begin with,
which means having all the attributes we'd like to track, plus some
On Wed, Apr 27, 2011 at 11:12 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Wed, 27 Apr 2011 14:19:05 +0200
Daniel Vetter dan...@ffwll.ch wrote:
Hi Jesse,
I like it. It's a bit of a chicken-egg api design problem, but if a
proof-of-concept
implementation exists for an embedded chip
On Thu, Apr 28, 2011 at 12:03:32PM -0500, Rob Clark wrote:
On Mon, Apr 25, 2011 at 5:12 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Looking for comments on this. Obviously if we're going to add a new type
of KMS object, we'd better get the ioctl more or less right to begin with,
Hi Jesse,
I like it. It's a bit of a chicken-egg api design problem, but if a
proof-of-concept
implementation exists for an embedded chip plus something to check whether
it's good enough to implement Xv on ancient hw (intel overlay or for the qemu
kms driver, if that could do this), that should
On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter dan...@ffwll.ch wrote:
Hi Jesse,
I like it. It's a bit of a chicken-egg api design problem, but if a
proof-of-concept
implementation exists for an embedded chip plus something to check whether
it's good enough to implement Xv on ancient hw
On Wed, Apr 27, 2011 at 3:32 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter dan...@ffwll.ch wrote:
float scale_x, scale_y;
No float in kernel. Would have to use fixed point.
Bleh, of course ;-) 32bit with a 16 bit shift should be good enough
for all
On Wed, 27 Apr 2011 16:27:55 +0200, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Apr 27, 2011 at 3:32 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Wed, Apr 27, 2011 at 8:19 AM, Daniel Vetter dan...@ffwll.ch wrote:
float scale_x, scale_y;
No float in kernel. Would have to use fixed
On Wed, Apr 27, 2011 at 4:34 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
Or just specify the source size. You already know the output size...
Hm, I've thought that x, y are fb offsets, not width/height of the
target ... Maybe we need that,
too?
-Daniel
--
Daniel Vetter
On Wed, 27 Apr 2011 14:19:05 +0200
Daniel Vetter dan...@ffwll.ch wrote:
Hi Jesse,
I like it. It's a bit of a chicken-egg api design problem, but if a
proof-of-concept
implementation exists for an embedded chip plus something to check whether
it's good enough to implement Xv on ancient hw
I was planning on adding a new fb ioctl to allow us to create fbs with
specific surface format types. We could either enumerate all of the
ones we support (a list which will grow as drivers and devices are
added) or try to factor out commit bits into a separate surface struct:
struct
A lot of older hardware had one overlay that could be sourced to any
crtc, just not simultaneously. The tricky part is the formats and
capabilities: alpha blending, color/chromakey, gamma correction, etc.
Even the current crtc gamma stuff is somewhat lacking in in terms of
what hardware is
On Mon, Apr 25, 2011 at 8:33 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, 25 Apr 2011 20:28:20 -0400
Alex Deucher alexdeuc...@gmail.com wrote:
On Mon, Apr 25, 2011 at 7:22 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Mon, 25 Apr 2011 16:16:18 -0700
Keith Packard
having a list per hardware. uint32_t would give enough room to add all
formats even if one format is only supported by one hardware only (at
It would indeed. A point realised by the Amiga designers in 1985 and
turned into a standard of sorts with a registry and process and adopted
by folks like
On Tue, Apr 26, 2011 at 10:16 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
having a list per hardware. uint32_t would give enough room to add all
formats even if one format is only supported by one hardware only (at
It would indeed. A point realised by the Amiga designers in 1985 and
turned
On Tue, 26 Apr 2011 11:01:30 +0100
Alan Cox a...@lxorguk.ukuu.org.uk wrote:
A lot of older hardware had one overlay that could be sourced to any
crtc, just not simultaneously. The tricky part is the formats and
capabilities: alpha blending, color/chromakey, gamma correction, etc.
Even
I think 4cc it bit useless with RGB stuff (or maybe i just don't
understand 4cc). For instance i think we want uniq different id for
RGB555, RGB565,RGBX, RGBA, BGRA ... it seems 4cc just says
rgb and than rely on additional informations for color order or
components size.
Yes -
On Mon, Apr 25, 2011 at 04:16:18PM -0700, Keith Packard wrote:
On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Overlays are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
On Tue, 26 Apr 2011 18:20:03 +0300
Ville Syrjälä syrj...@sci.fi wrote:
On Mon, Apr 25, 2011 at 04:16:18PM -0700, Keith Packard wrote:
On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Overlays are a bit like half-CRTCs. They have a location and fb, but
And what if you don't have a default plane as such. For example, OMAP3
has one graphics plane and two video planes, and two output paths. Each
of the planes can be assigned to zero or one outputs. To accomodate this,
the design should allow for CRTCs without any scanout buffers.
Some TV type
On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Overlays are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Are overlays/underlays not associated with a specific
On Mon, 25 Apr 2011 16:16:18 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Overlays are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to
On Mon, 25 Apr 2011 16:22:16 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Yes, that matches my understanding as well. I've deliberately made the
implementation flexible there though, under the assumption that some
hardware allows a plane to be directed at more than one CRTC (though
On Mon, 25 Apr 2011 16:35:20 -0700
Stéphane Marchesin stephane.marche...@gmail.com wrote:
On Mon, Apr 25, 2011 at 16:22, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, 25 Apr 2011 16:16:18 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
On Mon, 25 Apr 2011 16:37:46 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 25 Apr 2011 16:22:16 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Yes, that matches my understanding as well. I've deliberately made the
implementation flexible there though, under the assumption
On Mon, Apr 25, 2011 at 16:22, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, 25 Apr 2011 16:16:18 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Overlays are a bit like half-CRTCs. They have a location
On Mon, Apr 25, 2011 at 7:22 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, 25 Apr 2011 16:16:18 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Overlays are a bit like half-CRTCs. They have a
On Mon, 25 Apr 2011 20:28:20 -0400
Alex Deucher alexdeuc...@gmail.com wrote:
On Mon, Apr 25, 2011 at 7:22 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Mon, 25 Apr 2011 16:16:18 -0700
Keith Packard kei...@keithp.com wrote:
On Mon, 25 Apr 2011 15:12:20 -0700, Jesse Barnes
On Mon, 25 Apr 2011 16:52:58 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
struct drm_mode_surface {
enum components; /* YUV, VUY, RGB, BGR, ARGB, ... */
int depth;
enum packing; /* some list of packing types? */
...
};
Might just make a uint32_t 'type',
33 matches
Mail list logo
