Re: ABI mismatch

it means ddx driver (in this case radeon_drv.so) was compiled against a different version of xserver than you are trying to run it against... BR, -R On Sat, Oct 17, 2015 at 7:46 PM, Christopher Barry wrote: > Hi all, > > I've gotten everything to compile now, but

Re: XDC 2016 : Call for paper

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

Re: XDC 2016 : Call for paper

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

X.Org Foundation Membership Renewal

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

2018 X.Org Board of Directors Elections Nomination period is NOW

of 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

Re: 2018 X.Org Board of Directors Elections Nomination period is NOW

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 <robdcl...@gmail.com> wrote: > We are seeking nominations for candidates for

2018 X.Org Foundation Election Candidates

. 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 Eric

Re: 2018 Election voting OPEN

On Wed, Mar 21, 2018 at 8:40 PM, Rob Clark <robdcl...@gmail.com> 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 Thu

Re: 2018 Election voting OPEN

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 <robdcl...@gmail.com> wrote: > To all X.Org Foundatio

2018 Election voting OPEN

, 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 current boa

Re: 2018 X.Org Board of Directors Elections Nomination period is NOW

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

[PATCH xserver] EXA: fix typo

From: Rob Clark robdcl...@gmail.com 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

Re: [PATCH xserver] EXA: fix typo

On Tue, Jun 14, 2011 at 11:45 AM, Rob Clark r...@ti.com wrote: From: Rob Clark robdcl...@gmail.com 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

RFC: video with DRI2

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

Re: RFC: video with DRI2

On Wed, Jul 20, 2011 at 5:53 PM, Younes Manton youne...@gmail.com wrote: On Wed, Jul 20, 2011 at 6:28 PM, Corbin Simpson mostawesomed...@gmail.com wrote: On Wed, Jul 20, 2011 at 3:15 PM, Rob Clark robdcl...@gmail.com wrote: Anyone have some opinions on the best approach to take?  Anyone else

Re: RFC: video with DRI2

On Wed, Jul 20, 2011 at 11:26 PM, Younes Manton youne...@gmail.com wrote: On Wed, Jul 20, 2011 at 11:40 PM, Rob Clark robdcl...@gmail.com wrote: On Wed, Jul 20, 2011 at 5:53 PM, Younes Manton youne...@gmail.com wrote: On Wed, Jul 20, 2011 at 6:28 PM, Corbin Simpson mostawesomed...@gmail.com

[PATCH dri2proto] RFC: video support for dri2

From: Rob Clark r...@ti.com 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

Re: [PATCH dri2proto] RFC: video support for dri2

On Fri, Aug 19, 2011 at 5:18 AM, Pauli Nieminen pauli.niemi...@linux.intel.com wrote: On Thu, Aug 18, 2011 at 09:58:07PM -0500, Rob Clark wrote: From: Rob Clark r...@ti.com To allow the potential use of overlays to display video content, a few extra parameters are required:  + source buffer

[PATCH] RFCv2: video support for dri2

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

Re: [PATCH] RFCv2: video support for dri2

On Thu, Sep 1, 2011 at 5:22 PM, Younes Manton youne...@gmail.com wrote: On Thu, Sep 1, 2011 at 4:52 PM, Rob Clark r...@ti.com wrote: 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

Re: [PATCH] RFCv2: video support for dri2 (Rob Clark)

2011/9/2 Christian König deathsim...@vodafone.de: 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

[PATCH dri2proto] RFCv3: video support for dri2

From: Rob Clark r...@ti.com 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

[PATCH dri2proto] Remove extra DRI2SwapBuffers

From: Rob Clark r...@ti.com 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 changed

Re: [PATCH dri2proto] Remove extra DRI2SwapBuffers

as-is. BR, -R On Mon, Sep 19, 2011 at 5:14 PM, Rob Clark rob.cl...@linaro.org wrote: From: Rob Clark r...@ti.com 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

[PATCH] RFC: refactor out dri2 proto code into libdri2

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.

Re: [Mesa-dev] [PATCH] RFC: refactor out dri2 proto code into libdri2

On Tue, Sep 27, 2011 at 12:22 PM, Eric Anholt e...@anholt.net wrote: On Thu, 22 Sep 2011 15:36:07 -0500, Rob Clark rob.cl...@linaro.org 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

[PATCH] dri2video support

From: Rob Clark r...@ti.com 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

[PATCH dri2proto] video support for dri2

From: Rob Clark r...@ti.com 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

[PATCH xserver] add dri2video

From: Rob Clark r...@ti.com 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

[PATCH xf86-video-nouveau] add dri2video support

From: Rob Clark r...@ti.com 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 - src

[PATCH libdri2] dri2video support

holder shall + * not be used in advertising or otherwise to promote the sale, use or + * other dealings in this Software without prior written authorization of + * the copyright holder. + * + * Authors: + * Rob Clark (r...@ti.com) + */ + +#ifdef HAVE_CONFIG_H +# include config.h +#endif + +#include

Re: any more pull requests or cherry picks for xserver 1.15.1 or 1.14.6 ?

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 mar...@osource.org wrote: Hey folks, Any body have any thing

[PULL] arm build fixes

/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 int10

Re: any more pull requests or cherry picks for xserver 1.15.1 or 1.14.6 ?

mar...@osource.org 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): default to stub int10 implementation on arm int10: fix

[PULL] arm build fixes (v2)

-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/stub.c | 2

Re: [PULL] arm build fixes (v2)

On Tue, Apr 29, 2014 at 12:37 PM, Keith Packard kei...@keithp.com wrote: Rob Clark robdcl...@gmail.com 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-liner fix, maybe you can

[PATCH] platform: support non-pci platform devices

for that, but this is a start. Signed-off-by: Rob Clark robdcl...@gmail.com --- 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

Re: [PATCH] platform: support non-pci platform devices

On Mon, Jun 16, 2014 at 2:49 AM, Hans de Goede hdego...@redhat.com 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 not always match

Re: [PATCH] platform: support non-pci platform devices

On Mon, Jun 16, 2014 at 7:50 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 06/16/2014 01:32 PM, Rob Clark wrote: On Mon, Jun 16, 2014 at 2:49 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 06/14/2014 09:58 PM, Rob Clark wrote: This makes things not completely fail if DDX

Re: [PATCH] platform: support non-pci platform devices

On Mon, Jun 16, 2014 at 7:46 AM, Thierry Reding thierry.red...@gmail.com 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 does

[RFC] modesetting: Add workaround for platform devices and buggy xserver

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

[RFC] xserver: add SERVER_SUPPORTS_NON_PCI_PLATFORM_DEVS

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

Re: [PATCH] platform: support non-pci platform devices

On Mon, Jun 16, 2014 at 7:50 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 06/16/2014 01:32 PM, Rob Clark wrote: On Mon, Jun 16, 2014 at 2:49 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 06/14/2014 09:58 PM, Rob Clark wrote: This makes things not completely fail if DDX

Re: [RFC] xserver: add SERVER_SUPPORTS_NON_PCI_PLATFORM_DEVS

On Mon, Jun 16, 2014 at 11:12 AM, Hans de Goede hdego...@redhat.com 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 platform device

[PATCH 1/2] platform: support non-pci platform devices

for that, but this is a start. Signed-off-by: Rob Clark robdcl...@gmail.com Reviewed-by: Hans de Goede hdego...@redhat.com --- hw/xfree86/common/xf86platformBus.c | 65 ++--- 1 file changed, 61 insertions(+), 4 deletions(-) diff --git a/hw/xfree86/common/xf86platformBus.c b/hw

[PATCH 0/2] Fixes for non-pci platform devices

are 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

Re: [PATCH 1/2] platform: support non-pci platform devices

On Mon, Jun 23, 2014 at 10:54 AM, Thierry Reding thierry.red...@gmail.com 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_pci_driver(const char *busid

Re: [PATCH 1/2] xfree86: Fallback to first platform device as primary

as primary device. Signed-off-by: Thierry Reding tred...@nvidia.com Reviewed-by: Rob Clark robdcl...@gmail.com Tested-by: Rob Clark robdcl...@gmail.com --- hw/xfree86/common/xf86Bus.c | 3 +++ hw/xfree86/common/xf86platformBus.c | 17 + hw/xfree86/common

Re: [PATCH 1/2] xfree86: Fallback to first platform device as primary

as primary device. Signed-off-by: Thierry Reding tred...@nvidia.com Reviewed-by: Rob Clark robdcl...@gmail.com Tested-by: Rob Clark robdcl...@gmail.com --- hw/xfree86/common/xf86Bus.c | 3 +++ hw/xfree86/common/xf86platformBus.c | 17 + hw/xfree86/common

Re: [PATCH v2 RESEND 1/5] xfree86: Make driver matching consistent

way as others, which makes it easier to deal with. Reviewed-by: Aaron Plattner aplatt...@nvidia.com Tested-By: Aaron Plattner aplatt...@nvidia.com Signed-off-by: Thierry Reding tred...@nvidia.com Tested-by: Rob Clark robdcl...@gmail.com (on arm / platform device) --- hw/xfree86/common

Re: [PATCH v2 RESEND 2/5] xfree86: Store kernel driver name in platform device attribute

-By: Aaron Plattner aplatt...@nvidia.com Signed-off-by: Thierry Reding tred...@nvidia.com Reviewed-by: Rob Clark robdcl...@gmail.com Tested-by: Rob Clark robdcl...@gmail.com --- hw/xfree86/os-support/linux/lnx_platform.c | 12 include/hotplug.h | 2 ++ 2

Re: [PATCH v2 RESEND 3/5] xfree86: Introduce OutputClass configuration

Plattner aplatt...@nvidia.com Signed-off-by: Thierry Reding tred...@nvidia.com Tested-by: Rob Clark robdcl...@gmail.com --- hw/xfree86/man/xorg.conf.man| 77 ++ hw/xfree86/parser/Makefile.am | 1 + hw/xfree86/parser/OutputClass.c | 167

Re: [PATCH v2 RESEND 5/5] xfree86: Make error message more readable

-by: Thierry Reding tred...@nvidia.com Reviewed-by: Rob Clark robdcl...@gmail.com Tested-by: Rob Clark robdcl...@gmail.com --- hw/xfree86/os-support/linux/lnx_platform.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/hw/xfree86/os-support/linux/lnx_platform.c b/hw

Re: [PATCH v2 RESEND 4/5] xfree86: Support driver loading via OutputClass

aplatt...@nvidia.com Signed-off-by: Thierry Reding tred...@nvidia.com Tested-by: Rob Clark robdcl...@gmail.com --- hw/xfree86/common/xf86platformBus.c | 78 + 1 file changed, 78 insertions(+) diff --git a/hw/xfree86/common/xf86platformBus.c b/hw/xfree86

[RFC xf86-video-freedreno] add OutputClass conf

This enables the xserver to associate the drm driver name msm to the xf86-video-freedreno driver. Signed-off-by: Rob Clark robdcl...@gmail.com --- 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

Re: [RFC xf86-video-freedreno] add OutputClass conf

On Wed, Jul 9, 2014 at 6:26 AM, Julien Cristau jcris...@debian.org 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 robdcl...@gmail.com --- Not sure

[PATCH] modesetting: don't be a GPU screen

/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 robdcl...@gmail.com --- src/driver.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff

Re: [PATCH 2/2] xfree86: Allow non-PCI devices as primary

...@nvidia.com somehow I missed sending this before, but: Reviewed-by: Rob Clark robdcl...@gmail.com --- 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

[PATCH xorg-docs] add maintainers entry for xf86-video-omap

From: Rob Clark r...@ti.com Signed-off-by: Rob Clark r...@ti.com --- 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

[PATCH xserver] hw/dmx: fix build without GLX

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 robdcl...@gmail.com --- hw

Re: EXA composite ops don't report damage

On Mon, May 13, 2013 at 11:44 AM, Daniel Stone dan...@fooishbar.org wrote: Hi, On 13 May 2013 15:40, Daniel Drake d...@laptop.org wrote: On Mon, May 13, 2013 at 3:15 AM, Michel Dänzer mic...@daenzer.net wrote: The wrapping order is supposed to be the other way around, i.e. the Damage layer

Re: modular: Changes to 'master'

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 robcl...@kemper.freedesktop.org wrote: xorg.modules | 13 + 1 file changed, 13 insertions(+) New commits: commit

Re: misc fixes for VC4

On Tue, Dec 30, 2014 at 5:54 PM, Eric Anholt e...@anholt.net 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

Re: [PATCH] modesetting: Fix build with --disable-glamor.

and xorg tinderbox: http://tinderbox.x.org/builds/2014-12-31-0019/logs/xserver/#build Reviewed-by: Rob Clark robdcl...@gmail.com On Wed, Dec 31, 2014 at 12:47 PM, Jasper St. Pierre jstpie...@mecheye.net wrote: This is causing build failures on GNOME Continuous: http://build.gnome.org

Re: misc fixes for VC4

On Wed, Dec 31, 2014 at 2:52 PM, Eric Anholt e...@anholt.net wrote: Rob Clark robdcl...@gmail.com writes: On Tue, Dec 30, 2014 at 5:54 PM, Eric Anholt e...@anholt.net wrote: I've been looking into X performance on VC4 recently. The first obvious thing happening was that we're hitting some

Re: misc fixes for VC4

On Fri, Jan 2, 2015 at 11:16 PM, Keith Packard kei...@keithp.com wrote: Rob Clark robdcl...@gmail.com 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 emulated

Re: misc fixes for VC4

On Fri, Jan 2, 2015 at 4:27 PM, Keith Packard kei...@keithp.com wrote: Jasper St. Pierre jstpie...@mecheye.net 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

Re: misc fixes for VC4

On Sat, Jan 3, 2015 at 12:35 PM, Keith Packard kei...@keithp.com wrote: Rob Clark robdcl...@gmail.com 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 between

[PATCH libXt] asprintf needs _GNU_SOURCE on some platforms

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 robdcl...@gmail.com --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH] modesetting: Fix software cursor fallback

, Reviewed-by: Rob Clark robdcl...@gmail.com References: https://bugzilla.redhat.com/show_bug.cgi?id=1205725 Signed-off-by: Adel Gadllah adel.gadl...@gmail.com --- hw/xfree86/drivers/modesetting/drmmode_display.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/xfree86

[PATCH] glamor: fix crash when drawing nothing

.so.6 #14 0x0042b3e8 in _start () Also fixed a bunch of other call-sites which could in theory trigger the same issue. Signed-off-by: Rob Clark <robdcl...@gmail.com> --- glamor/glamor_copy.c | 3 +++ glamor/glamor_dash.c | 3 +++ glamor/glamor_glyphblt.c | 3 +++ glamor/glamor_points.c

Re: [PATCH] glamor: fix crash when drawing nothing

On Fri, Oct 16, 2015 at 11:07 AM, Keith Packard <kei...@keithp.com> wrote: > Rob Clark <robdcl...@gmail.com> writes: > >> On Wed, Oct 14, 2015 at 8:10 PM, Eric Anholt <e...@anholt.net> wrote: >>> Rob Clark <robdcl...@gmail.com> writes: >>> &g

[PATCH] glamor: fix crash when drawing nothing

hat (so keep the earlier early-returns), but a GL error is better than a crash so keep this extra safety-net. Signed-off-by: Rob Clark <robdcl...@gmail.com> --- glamor/glamor_copy.c | 3 +++ glamor/glamor_dash.c | 3 +++ glamor/glamor_glyphblt.c | 3 +++ glamor/glamor_points.c

Re: [PATCH] glamor: fix crash when drawing nothing

On Wed, Oct 14, 2015 at 8:10 PM, Eric Anholt <e...@anholt.net> wrote: > Rob Clark <robdcl...@gmail.com> 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 jus

Time to update GSoC/EVoC ideas page

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

Re: XDC 2016 : Call for paper

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

Re: XDC 2016 : Call for paper

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

Re: [Mesa-dev] XDC 2017 feedback

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, >>

Re: [Mesa-dev] XDC 2017 feedback

On Wed, Sep 27, 2017 at 10:49 PM, Ian Romanick <i...@freedesktop.org> wrote: > On 09/27/2017 04:55 PM, Rob Clark wrote: >> On Wed, Sep 27, 2017 at 7:25 PM, Ian Romanick <i...@freedesktop.org> wrote: >>> On 09/26/2017 09:57 AM, Daniel Vetter wrote: >>>>

X.Org Foundation Membership Renewal

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

2018 X.Org Board of Directors Elections Nomination period is NOW

of 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

Re: 2018 X.Org Board of Directors Elections Nomination period is NOW

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 <robdcl...@gmail.com> wrote: > We are seeking nominations for candidates for

2018 X.Org Foundation Election Candidates

. 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 Eric

Re: 2018 Election voting OPEN

On Wed, Mar 21, 2018 at 8:40 PM, Rob Clark <robdcl...@gmail.com> 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 Thu

Re: 2018 Election voting OPEN

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 <robdcl...@gmail.com> wrote: > To all X.Org Foundatio

2018 Election voting OPEN

, 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 current boa

Re: 2018 X.Org Board of Directors Elections Nomination period is NOW

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

Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services

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

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

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 onl

Re: gitlab.fd.o financial situation and impact on services

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 > &g

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

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

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

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 : > >

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

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

Re: [Mesa-dev] [Intel-gfx] gitlab.fd.o financial situation and impact on services

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: > >