On Mon, Apr 6, 2020 at 10:04 AM Michel Dänzer wrote:
>
> On 2020-04-06 6:34 p.m., Rob Clark wrote:
> >
> > The ideal thing would be to be able to click any jobs that we want to
> > run, say "arm64_a630_gles31", and for gitlab to realize that it needs
> >
On Mon, Apr 6, 2020 at 8:43 AM Adam Jackson wrote:
>
> On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote:
> > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> > > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > > For Mesa, we could run CI only
On Sat, Apr 4, 2020 at 11:41 AM Rob Clark wrote:
>
> On Sat, Apr 4, 2020 at 11:16 AM Rob Clark wrote:
> >
> > On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne
> > wrote:
> > >
> > > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit :
> >
On Sat, Apr 4, 2020 at 11:16 AM Rob Clark wrote:
>
> On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne wrote:
> >
> > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit :
> > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> > > > On
On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne wrote:
>
> Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit :
> > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> > > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > > For Mesa, we could run CI onl
On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
>
> On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> > pre-merge CI.
>
> Thanks for the suggestion! I implemented something like this for Mesa:
>
> https://gitlab.freedesk
On Fri, Feb 28, 2020 at 3:43 AM Michel Dänzer wrote:
>
> On 2020-02-28 10:28 a.m., Erik Faye-Lund wrote:
> >
> > We could also do stuff like reducing the amount of tests we run on each
> > commit, and punt some testing to a per-weekend test-run or someting
> > like that. We don't *need* to know ab
ty to vote, we are extending the voting period by one week.
The voting period will now remain open until 23:59 UTC on 12 April
2018.
Rob Clark,
on behalf of the X.Org elections committee
On Wed, Mar 21, 2018 at 8:40 PM, Rob Clark wrote:
> To all X.Org Foundation Members:
>
> The X.Or
On Wed, Mar 21, 2018 at 8:40 PM, Rob Clark wrote:
> To all X.Org Foundation Members:
>
> The X.Org Foundation's annual election is now open and will remain
> open until 23:59 UTC on 5 April 2018.
Reminder that the elections are open until midnight on Thurs, so if
you have
valid, your votes will be recorded and the
system will show you a notice that your votes were cast.
Note that the election will close at 23:59 UTC on 5 April 2018. At
that time, the election committee will count the votes and present the
results to the current board for validation. After the curren
ction.
If you have questions of the candidates, you should feel free to ask
them here on the mailing list.
The election committee will provide detailed instructions on how the
voting system will work when the voting period begins.
Rob Clark,
on behalf of the X.Org elections committee
All,
We have extended the deadline for nominations until 9 Mar 2018. We
currently have four nominees for four seats, but we would like to have
at least another candidate or two, so please consider stepping up and
nominating yourself or a friend!
BR,
-R
On Fri, Feb 9, 2018 at 9:01 AM, Rob Clark
Just a reminder, nominations are open for a few more days. If you
would like to nominate yourself or someone else please send your
nomination to electi...@x.org
BR,
-R
On Fri, Feb 9, 2018 at 9:01 AM, Rob Clark wrote:
> We are seeking nominations for candidates for election to the X.
directors elected from the membership. Each
year, an election is held to bring the total number of directors to
eight. The four members receiving the highest vote totals will serve
as directors for two year terms.
The directors who received two year terms starting in 2017 were Rob
Clark, Martin Peres
On Feb 1st all xorg members were expired as part of the regular
process to remove inactive members. If you would still like to be a
member of the X.Org Foundation, please renew your membership. To
renew or to become a first time member, go to https://members.x.org/ .
For renewals, log in and clic
On Wed, Sep 27, 2017 at 10:49 PM, Ian Romanick wrote:
> On 09/27/2017 04:55 PM, Rob Clark wrote:
>> On Wed, Sep 27, 2017 at 7:25 PM, Ian Romanick wrote:
>>> On 09/26/2017 09:57 AM, Daniel Vetter wrote:
>>>> Hi all,
>>>>
>>>> First again big
On Wed, Sep 27, 2017 at 7:25 PM, Ian Romanick wrote:
> On 09/26/2017 09:57 AM, Daniel Vetter wrote:
>> Hi all,
>>
>> First again big thanks to Stéphane and Jennifer for organizing a great XDC.
>>
>> Like last year we'd like to hear feedback on how this year's XDC went,
>> both the good (and what y
Just a friendly reminder that now would be a good time to update the
wiki page for GSoC/EVoC ideas:
https://www.x.org/wiki/SummerOfCodeIdeas/
There are currently still some stale ideas there (and probably plenty
of missing good ideas).
Also, I've added a "Potential Mentors" section. Please ad
On Thu, May 12, 2016 at 6:56 PM, Martin Peres wrote:
> Hello,
>
> I have the pleasure to announce that the X.org Developer Conference 2016
> will be held in Helsinki from September 21 to September 23. The venue is
> located at Haaga-Helia university[0], next to the Pasila station.
>
> The official
On Thu, May 12, 2016 at 6:56 PM, Martin Peres wrote:
> Hello,
>
> I have the pleasure to announce that the X.org Developer Conference 2016
> will be held in Helsinki from September 21 to September 23. The venue is
> located at Haaga-Helia university[0], next to the Pasila station.
>
> The official
error is better than a crash so keep this extra safety-net.
Signed-off-by: Rob Clark
---
glamor/glamor_copy.c | 3 +++
glamor/glamor_dash.c | 3 +++
glamor/glamor_glyphblt.c | 3 +++
glamor/glamor_points.c | 3 +++
glamor/glamor_rects.c| 3 +++
glamor/glamor_render.c | 3 +++
g
On Fri, Oct 16, 2015 at 11:07 AM, Keith Packard wrote:
> Rob Clark writes:
>
>> On Wed, Oct 14, 2015 at 8:10 PM, Eric Anholt wrote:
>>> Rob Clark writes:
>>>
>>>> For example, in the PolyFillRect() path w/ nrect==0, we end up in
>>>> glamor
On Wed, Oct 14, 2015 at 8:10 PM, Eric Anholt wrote:
> Rob Clark writes:
>
>> For example, in the PolyFillRect() path w/ nrect==0, we end up in
>> glamor_get_vbo_space(size=0):
>
> I wonder instead if we shouldn't just have glamor_get_vbo_space() return
> NULL
of other call-sites which could in theory trigger the
same issue.
Signed-off-by: Rob Clark
---
glamor/glamor_copy.c | 3 +++
glamor/glamor_dash.c | 3 +++
glamor/glamor_glyphblt.c | 3 +++
glamor/glamor_points.c | 3 +++
glamor/glamor_rects.c| 3 +++
glamor/glamor_render.c | 3
i.e returns 0) and disable
> the cursor2 usage on EINVAL.
Might not hurt to add something to the commit msg about falling
through to drmModeSetCursor() path (which does properly handle -ENXIO
and other non-EINVAL errors properly) since you can't easily see that
from the diffstat..
eit
Fixes a build break noticed on fedora 21 on arm (although I doubt that
is in any way arch specific).
http://tinderbox.x.org/builds/2015-01-26-0012/logs/libXt/#build
Signed-off-by: Rob Clark
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b
On Sat, Jan 3, 2015 at 12:35 PM, Keith Packard wrote:
> Rob Clark writes:
>
>> hmm, what minimum gl and gles version do we need to expose instanced
>> drawing? Or any other useful extensions that glamor could use? Not
>> sure if that would make a difference betwee
On Fri, Jan 2, 2015 at 11:16 PM, Keith Packard wrote:
> Rob Clark writes:
>
>> well, adreno doesn't do native quads, and I think vc4 doesn't
>> either... so an alternative path is useful. Perhaps we should cook up
>> an extension to indicate that quads are
On Fri, Jan 2, 2015 at 4:27 PM, Keith Packard wrote:
> "Jasper St. Pierre" writes:
>
>> On a UMA system, that's effectively free. With a triangle fan and
>> glMultiDrawElements, you can get it down to four, same as a quad. Though
>> I'm not sure if mesa fully supports glMultiDrawElements.
>>
>> I
On Wed, Dec 31, 2014 at 2:52 PM, Eric Anholt wrote:
> Rob Clark writes:
>
>> On Tue, Dec 30, 2014 at 5:54 PM, Eric Anholt wrote:
>>> I've been looking into X performance on VC4 recently. The first
>>> obvious thing happening was that we're hitting som
and xorg tinderbox:
http://tinderbox.x.org/builds/2014-12-31-0019/logs/xserver/#build
Reviewed-by: Rob Clark
On Wed, Dec 31, 2014 at 12:47 PM, Jasper St. Pierre
wrote:
> This is causing build failures on GNOME Continuous:
>
> http://build.gnome.org/continuous/buildmaster/builds/201
On Tue, Dec 30, 2014 at 5:54 PM, Eric Anholt wrote:
> I've been looking into X performance on VC4 recently. The first
> obvious thing happening was that we're hitting some fallbacks in the
> driver for things like GL_QUADS, so I thought "what if I use the GLES2
> paths instead?" Turns out the GL
It only ends in tears
Signed-off-by: Rob Clark
---
src/drmmode_display.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index c533324..12aa987 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -568,17 +568,6
ending this before, but:
Reviewed-by: Rob Clark
> ---
> hw/xfree86/common/xf86platformBus.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/hw/xfree86/common/xf86platformBus.c
> b/hw/xfree86/common/xf86platformBus.c
> index 467b26b1de1a..8
p.org/patch/28494/
http://patchwork.freedesktop.org/patch/28495/
but since a display-only non-display device makes no sense, let's just
nuke that code to avoid being a problem.
Signed-off-by: Rob Clark
---
src/driver.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff -
On Wed, Jul 9, 2014 at 6:26 AM, Julien Cristau wrote:
> On Tue, Jul 8, 2014 at 10:01:52 -0400, Rob Clark wrote:
>
>> This enables the xserver to associate the drm driver name "msm" to the
>> xf86-video-freedreno driver.
>>
>> Signed-off-by: Rob Clark
&
This enables the xserver to associate the drm driver name "msm" to the
xf86-video-freedreno driver.
Signed-off-by: Rob Clark
---
Not sure if anyone has a better suggestion for how to do that videodrv
abi check in configure.ac. The problem is, we don't want to install
the .conf
On Wed, Jun 25, 2014 at 9:55 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> Use the OutputClass configuration to determine what drivers to autoload
> for a given device.
>
> Reviewed-by: Aaron Plattner
> Tested-By: Aaron Plattner
> Signed-off-by: Thierry Redin
On Wed, Jun 25, 2014 at 9:55 AM, Thierry Reding
wrote:
> From: Thierry Reding
>
> While at it also replace a tab by four spaces for consistency.
>
> Reviewed-by: Aaron Plattner
> Tested-By: Aaron Plattner
> Signed-off-by: Thierry Reding
Reviewed-by: Rob Clark
n xorg.conf(5) for more details.
>
> Reviewed-by: Aaron Plattner
> Tested-By: Aaron Plattner
> Signed-off-by: Thierry Reding
Tested-by: Rob Clark
> ---
> hw/xfree86/man/xorg.conf.man| 77 ++
> hw/xfree86/parser/Makefile.am | 1 +
> hw/xfree86
d-off-by: Thierry Reding
Reviewed-by: Rob Clark
Tested-by: Rob Clark
> ---
> hw/xfree86/os-support/linux/lnx_platform.c | 12
> include/hotplug.h | 2 ++
> 2 files changed, 14 insertions(+)
>
> diff --git a/hw/xfree86/os-support/linux/lnx_p
the same
> way as others, which makes it easier to deal with.
>
> Reviewed-by: Aaron Plattner
> Tested-By: Aaron Plattner
> Signed-off-by: Thierry Reding
Tested-by: Rob Clark (on arm / platform device)
> ---
> hw/xfree86/common/xf86AutoConfig.c | 2 +-
> hw/xfr
t;
> Signed-off-by: Thierry Reding
Reviewed-by: Rob Clark
Tested-by: Rob Clark
> ---
> hw/xfree86/common/xf86Bus.c | 3 +++
> hw/xfree86/common/xf86platformBus.c | 17 +
> hw/xfree86/common/xf86platformBus.h | 1 +
> 3 files changed, 21 insertions(+
t;
> Signed-off-by: Thierry Reding
Reviewed-by: Rob Clark
Tested-by: Rob Clark
> ---
> hw/xfree86/common/xf86Bus.c | 3 +++
> hw/xfree86/common/xf86platformBus.c | 17 +
> hw/xfree86/common/xf86platformBus.h | 1 +
> 3 files changed, 21 insertions(+
On Mon, Jun 23, 2014 at 10:54 AM, Thierry Reding
wrote:
> On Mon, Jun 16, 2014 at 02:13:16PM -0400, Rob Clark wrote:
> [...]
>> diff --git a/hw/xfree86/common/xf86platformBus.c
>> b/hw/xfree86/common/xf86platformBus.c
> [...]
>> +static int
>> +find_non_p
t a user could not
make things work even with a .conf file to explicitly specify
the driver to use.
Idea suggested by Hans de Goede.
Signed-off-by: Rob Clark
Reviewed-by: Hans de Goede
---
hw/xfree86/common/xf86Init.c | 10 +-
hw/xfree86/common/xf86str.h | 1 +
2 files changed,
against master. I also have branches
for 1.15 and 1.14:
git://github.com/robclark/xserver.git platform-dev-fixes
git://github.com/robclark/xserver.git platform-dev-fixes-1.15
git://github.com/robclark/xserver.git platform-dev-fixes-1.14
Rob Clark (2):
platform: support non-pci platform
this is a start.
Signed-off-by: Rob Clark
Reviewed-by: Hans de Goede
---
hw/xfree86/common/xf86platformBus.c | 65 ++---
1 file changed, 61 insertions(+), 4 deletions(-)
diff --git a/hw/xfree86/common/xf86platformBus.c
b/hw/xfree86/common/xf86platformBus.c
On Mon, Jun 16, 2014 at 11:12 AM, Hans de Goede wrote:
> Hi,
>
> On 06/16/2014 05:05 PM, Rob Clark wrote:
>> Give the DDX a way to know whether non-pci platform devices are
>> completley broken or not. For xserver prior to the fix, the
>> DDX should not claim a platf
On Mon, Jun 16, 2014 at 7:50 AM, Hans de Goede wrote:
> Hi,
>
> On 06/16/2014 01:32 PM, Rob Clark wrote:
>> On Mon, Jun 16, 2014 at 2:49 AM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 06/14/2014 09:58 PM, Rob Clark wrote:
>>>> This makes thin
Give the DDX a way to know whether non-pci platform devices are
completley broken or not. For xserver prior to the fix, the
DDX should not claim a platform device in platformProbe(), as
the server will fallback to old ->Probe(), which will fail if
the device is already claimed. Meaning that a use
If the xserver does not have a bug fix for a problem with auto-loading
true platform devices, then work around the issue by failing the
platformProbe(). This way the user can at least still load the driver
with a custom .conf file.
---
src/driver.c | 37 ++---
1 f
On Mon, Jun 16, 2014 at 7:46 AM, Thierry Reding
wrote:
> On Sat, Jun 14, 2014 at 03:58:53PM -0400, Rob Clark wrote:
>> This makes things not completely fail if DDX implements platformProbe()
>> but the device is not actually a PCI device. Also, the platform device
>> name
On Mon, Jun 16, 2014 at 7:50 AM, Hans de Goede wrote:
> Hi,
>
> On 06/16/2014 01:32 PM, Rob Clark wrote:
>> On Mon, Jun 16, 2014 at 2:49 AM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 06/14/2014 09:58 PM, Rob Clark wrote:
>>>> This makes thin
On Mon, Jun 16, 2014 at 2:49 AM, Hans de Goede wrote:
> Hi,
>
> On 06/14/2014 09:58 PM, Rob Clark wrote:
>> This makes things not completely fail if DDX implements platformProbe()
>> but the device is not actually a PCI device. Also, the platform device
>> name does no
this is a start.
Signed-off-by: Rob Clark
---
NOTE: I still need to figure out a sane way to workaround the existing
bug with non-pci platform devices. Currently, if DDX implements the
platformProbe() hook, then in xf86platformProbeDev() it will get claimed
in the autoAddGPU loop, resulting tha
On Tue, Apr 29, 2014 at 12:37 PM, Keith Packard wrote:
> Rob Clark writes:
>
>> Hi Keith,
>>
>> updated/rebased, and I've reviewed Thierry's patch. Of the other two,
>> one has an a-b, the other needs a r-b but is pretty simple/obvious
>> one-line
-04-27 12:02:39 -0400)
--------
Rob Clark (2):
default to stub int10 implementation on arm
int10: fix build error
Thierry Reding (1):
xfree86: int10: Fix build on ARM
configure.ac | 1 +
hw/xfree86/int10/s
t 9:58 PM, Matt Dew wrote:
> Hi Rob,
> For 1.15.1 or 1.14.6 or both?
>
> thanks,
> Matt
>
>
> On 04/04/2014 06:24 AM, Rob Clark wrote:
>> Perhaps those two little fixes I sent yesterday to get things building
>> on ARM again (with default config):
>>
&g
clark/xserver.git arm-build-fixes
for you to fetch changes up to ff7ecfdf6dbe77184bff8e1f65a590e74c83:
xfree86: int10: Fix build on ARM (2014-04-07 21:45:27 -0400)
----
Rob Clark (2):
default to stub int10 implementation on arm
Perhaps those two little fixes I sent yesterday to get things building
on ARM again (with default config):
default to stub int10 implementation on arm
int10: fix build error
BR,
-R
On Thu, Apr 3, 2014 at 10:49 PM, Matt Dew wrote:
> Hey folks,
> Any body have any thing more for xserver st
Fixes:
stub.c:66:1: error: conflicting types for 'xf86int10Addr'
In file included from stub.c:14:0:
xf86int10.h:72:53: note: previous declaration of 'xf86int10Addr' was here
---
hw/xfree86/int10/stub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/xfree86/int10/stub
known field 'xf_outw' specified in initializer
xf86x86emu.c:58:9: error: unknown field 'xf_outl' specified in initializer
which is caused by the following in compiler.h:
#define outb xf_outb
#define outw xf_outw
#define outl xf_outl
Signed-off-by: Rob Clark
---
configu
odules for everyone causes build failure for everyone else...
>
> http://tinderbox.x.org/builds/2013-11-14-0003/
>
> --Jeremy
>
> On Nov 13, 2013, at 9:59, Rob Clark wrote:
>
>> xorg.modules | 13 +
>> 1 file changed, 13 insertions(+)
>>
&
On Mon, May 13, 2013 at 11:44 AM, Daniel Stone wrote:
> Hi,
>
> On 13 May 2013 15:40, Daniel Drake wrote:
>> On Mon, May 13, 2013 at 3:15 AM, Michel Dänzer wrote:
>>> The wrapping order is supposed to be the other way around, i.e. the
>>> Damage layer is supposed to call down to EXA. I suspect y
Fixes this compile break that showed up on arm recently:
dmxinit.c:746:26: error: 'glxSupported' undeclared (first use in this function)
dmxinit.c:746:26: note: each undeclared identifier is reported only once for
each function it appears in
Signed-off-by: Rob Clark
---
hw/dmx/dmx
From: Rob Clark
Signed-off-by: Rob Clark
---
MAINTAINERS |7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ee24014..b982409 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -902,6 +902,13 @@ L: xorg-devel@lists.x.org
W: http://wiki.x.org
S
On Wed, Nov 16, 2011 at 7:36 AM, walter harms wrote:
>
>
> Am 15.11.2011 23:49, schrieb Rob Clark:
>> ---
>> Makefile.am | 16 ++-
>> include/X11/extensions/dri2.h | 52 +++-
>> src/Makefile.am | 2 +-
>>
On Wed, Nov 16, 2011 at 1:54 PM, Jamey Sharp wrote:
> On Wed, Nov 16, 2011 at 02:36:45PM +0100, walter harms wrote:
>> Am 15.11.2011 23:49, schrieb Rob Clark:
>> > + nformats = (rep.length / sizeof(*formats)) * 4;
>> > + formats = malloc(nformats * sizeof
HE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN
+ * THIS NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSE-
+ * QUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
+ * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
+ * TORTIOUS ACTION, ARIS
From: Rob Clark
TODO:
+ format advertised as I420 appears to actually be NV12
+ add non-fourcc format values for hw decode directly to VRAM
mapped buffer (skip GART->VRAM move)
+ CSC_MATRIX and OSD support..
---
src/nouveau_dri2.c| 214 -
From: Rob Clark
TODO:
+ implement OSD support.. core should register damage and automatically
re-call ScheduleSwapVid..
+ automatically re-call ScheduleSwapVid on dri2 drawable resize...
---
hw/xfree86/dri2/dri2.c| 364 +
hw/xfree86/dri2
From: Rob Clark
To allow the potential use of overlays to display video content, a few
extra parameters are required:
+ source buffer in different format (for example, various YUV formats)
and size as compared to destination drawable
+ multi-planar formats where discontiguous buffers are
From: Rob Clark
This set of patches for various trees adds support for dri2 video.
The mesa patch is not strictly required, but provides the changes to
utilize libdri2 client side lib (rather than duplicating the client
side proto code). The libdri2 patch has a simple test app.
Since I guess
On Tue, Sep 27, 2011 at 12:22 PM, Eric Anholt wrote:
> On Thu, 22 Sep 2011 15:36:07 -0500, Rob Clark wrote:
>> Since I was working on some extensions to DRI2 protocol for handling
>> video, it occurred to me that it might be easier to extend the
>> protocol if there weren&#x
Since I was working on some extensions to DRI2 protocol for handling
video, it occurred to me that it might be easier to extend the
protocol if there weren't N different copies of dri2.c floating around
in various different src trees.. also, for video, with one or two
other small extensions (ie. s
e initial version as-is.
BR,
-R
On Mon, Sep 19, 2011 at 5:14 PM, Rob Clark wrote:
> From: Rob Clark
>
> Remove duplicate DRI2SwapBuffers from 'A.2 Protocol Requests' section.
> ---
> I believe this to be a typo.. either that or I am confused and missing
> some subtl
From: Rob Clark
Remove duplicate DRI2SwapBuffers from 'A.2 Protocol Requests' section.
---
I believe this to be a typo.. either that or I am confused and missing
some subtle point (in which case a comment might be useful).
dri2proto.txt | 21 -
1 files
From: Rob Clark
To allow the potential use of overlays to display video content, a few
extra parameters are required:
+ source buffer in different format (for example, various YUV formats)
and size as compared to destination drawable
+ multi-planar formats where discontiguous buffers are
2011/9/2 Christian König :
> Hi Rob,
>
>> + flipping between multiple back buffers, perhaps not in order (to
>> handle video formats with B-frames)
> Oh, yes please. The closed source drivers seems to do this also all the
> time, and I never really understood why DRI is limiting the buffers to
On Thu, Sep 1, 2011 at 5:22 PM, Younes Manton wrote:
> On Thu, Sep 1, 2011 at 4:52 PM, Rob Clark wrote:
>> To allow the potential use of overlays to display video content, a few
>> extra parameters are required:
>>
>> + source buffer in different format (for e
To allow the potential use of overlays to display video content, a few
extra parameters are required:
+ source buffer in different format (for example, various YUV formats)
and size as compared to destination drawable
+ multi-planar formats where discontiguous buffers are used for
differen
On Fri, Aug 19, 2011 at 5:18 AM, Pauli Nieminen
wrote:
> On Thu, Aug 18, 2011 at 09:58:07PM -0500, Rob Clark wrote:
>> From: Rob Clark
>>
>> To allow the potential use of overlays to display video content, a few
>> extra parameters are required:
>>
>> +
From: Rob Clark
To allow the potential use of overlays to display video content, a few
extra parameters are required:
+ source buffer in different format (for example, various YUV formats)
and size as compared to destination drawable
+ multi-planar formats where discontiguous buffers are
On Wed, Jul 20, 2011 at 11:26 PM, Younes Manton wrote:
> On Wed, Jul 20, 2011 at 11:40 PM, Rob Clark wrote:
>> On Wed, Jul 20, 2011 at 5:53 PM, Younes Manton wrote:
>>> On Wed, Jul 20, 2011 at 6:28 PM, Corbin Simpson
>>> wrote:
>>>> On Wed, Ju
On Wed, Jul 20, 2011 at 5:53 PM, Younes Manton wrote:
> On Wed, Jul 20, 2011 at 6:28 PM, Corbin Simpson
> wrote:
>> On Wed, Jul 20, 2011 at 3:15 PM, Rob Clark wrote:
>>>
>>> Anyone have some opinions on the best approach to take? Anyone else
>>> given so
All,
I've been looking a bit at dri2 as a way to handle video display (in
addition to just GL stuff). Basically it seems like a convenient way
to share buffer handles between Xorg driver and client video player
app. (Yes, I know about Xv.. no, it isn't useful if I want to avoid a
memcpy.)
The b
On Tue, Jun 14, 2011 at 11:45 AM, Rob Clark wrote:
> From: Rob Clark
>
> The incorrect drawable deltas were applied if dst was a redirected
> window. Resulting in a bogus region passed to prepare_access_reg().
> ---
> exa/exa_unaccel.c | 2 +-
> 1 files changed, 1 inser
From: Rob Clark
The incorrect drawable deltas were applied if dst was a redirected
window. Resulting in a bogus region passed to prepare_access_reg().
---
exa/exa_unaccel.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/exa/exa_unaccel.c b/exa/exa_unaccel.c
index
89 matches
Mail list logo
