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

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 only

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 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 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: > > https://gitlab.freedesk

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 ab

Re: backend-drm and scanning really large resolutions

On Fri, Jan 17, 2020 at 8:52 AM Matt Hoosier wrote: > > Hi all, > > I'm confronting a situation where the hardware with which I work is capable > of driving connectors at 4K or 8K, but doing so requires bonding the scanning > of multiple planes together. > > The scenario is that you'd have a big

Re: 2018 Election voting OPEN

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

Re: 2018 Election voting OPEN

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

2018 Election voting OPEN

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

2018 X.Org Foundation Election Candidates

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

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: 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 wrote: > We are seeking nominations for candidates for election to the X.

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

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

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 clic

Re: [Mesa-dev] XDC 2017 feedback

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

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, >> both the good (and what y

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 station. > > The official

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 station. > > The official

Re: [Freedreno] Freedreno Mesa with wayland support

On Wed, Jul 9, 2014 at 5:10 AM, Shrisha wrote: > Hi, > > I'm tyring to build Mesa with wayland support. Our Build system is yocto > which is a linux based build system and we are using ARM based chipset. > > When I try to compile Mesa with Wayland enabled It throws me errors as > below. > > | /bi

Re: [PATCH 2/2] compositor-drm: Add support for Tegra Jetson TK1

On Fri, Jun 20, 2014 at 12:12 PM, James Thomas wrote: > Update configure.ac to add check for libdrm_tegra > --- > configure.ac | 18 ++ > src/compositor-drm.c | 96 > ++-- > 2 files changed, 111 insertions(+), 3 deletions(-) > > dif

Re: Wayland generic dmabuf protocol

On Fri, Jun 13, 2014 at 7:04 AM, Pekka Paalanen wrote: > On Mon, 9 Jun 2014 14:06:33 +0300 > Pekka Paalanen wrote: > >> On Mon, 9 Jun 2014 11:00:04 +0200 >> Benjamin Gaignard wrote: >> >> > On my hardware the patches you have (+ this one on gstwaylandsink >> > https://bugzilla.gnome.org/show_bug

Re: Wayland generic dmabuf protocol

On Thu, Jun 12, 2014 at 2:01 AM, Pekka Paalanen wrote: > On Wed, 11 Jun 2014 12:00:57 -0400 > Rob Clark wrote: > >> On Mon, Jun 9, 2014 at 8:44 AM, Pekka Paalanen >> wrote: >> > On Mon, 9 Jun 2014 12:23:18 +0100 >> > Daniel Stone wrote: >> > &

Re: Wayland generic dmabuf protocol

On Wed, Jun 11, 2014 at 2:26 AM, Thomas Hellstrom wrote: > On 06/09/2014 01:23 PM, Daniel Stone wrote: >> Hi, >> >> On 9 June 2014 12:06, Pekka Paalanen > > wrote: >> >> On Mon, 9 Jun 2014 11:00:04 +0200 >> Benjamin Gaignard >

Re: Wayland generic dmabuf protocol

On Mon, Jun 9, 2014 at 8:44 AM, Pekka Paalanen wrote: > On Mon, 9 Jun 2014 12:23:18 +0100 > Daniel Stone wrote: > >> Hi, >> >> On 9 June 2014 12:06, Pekka Paalanen wrote: >> >> > On Mon, 9 Jun 2014 11:00:04 +0200 >> > Benjamin Gaignard wrote: >> > > One of the main comment on the latest patches

Re: [Mesa-dev] [PATCH mesa] add EGL_TEXTURE_EXTERNAL_WL to WL_bind_wayland_display spec

On Mon, Jun 9, 2014 at 5:53 AM, Pekka Paalanen wrote: > On Thu, 16 Aug 2012 17:28:19 -0500 > Rob Clark wrote: > >> From: Rob Clark >> >> Signed-off-by: Rob Clark >> --- >> docs/WL_bind_wayland_display.spec |5 + >> include/EGL/eglmesae

Re: [PATCH v4 3/3] compositor-drm: allow to be a wl_dmabuf server

On Fri, Jan 10, 2014 at 10:46 AM, Thomas Hellstrom wrote: > On 01/10/2014 04:23 PM, Rob Clark wrote: >> On Tue, Jan 7, 2014 at 1:37 PM, Thomas Hellstrom >> wrote: >>> Conclusion: Avoid using dma-buf mmap() outside of drivers that know >>> exactly what they a

Re: [PATCH v4 3/3] compositor-drm: allow to be a wl_dmabuf server

On Tue, Jan 7, 2014 at 1:37 PM, Thomas Hellstrom wrote: > Conclusion: Avoid using dma-buf mmap() outside of drivers that know > exactly what they are > doing, and avoid it at all cost. well, to be fair, if you are using a gpu on the client side and pixman backend on the server side, you probably

Re: [PATCH v4 0/3] Add support of dmabuf in wayland/weston

On Fri, Jan 10, 2014 at 9:58 AM, Rob Clark wrote: > I suspect that this is somehow on the same level as wl_drm (which is > in mesa, not wayland). The difference here is that since you can > share buffers with various things (video codecs, cameras, etc), ie. > things beyond just the g

Re: [PATCH v4 0/3] Add support of dmabuf in wayland/weston

I suspect that this is somehow on the same level as wl_drm (which is in mesa, not wayland). The difference here is that since you can share buffers with various things (video codecs, cameras, etc), ie. things beyond just the gpu, it makes sense to put the protocol in some sort of common place rath

[PATCH 1/5 weston] compositor: add support for OES_EGL_image_external

From: Rob Clark In cases where the GPU can natively handle certain YUV formats, eglQueryWaylandBufferWL() can return the value EGL_TEXTURE_EXTERNAL_WL and the compositor will treat the buffer as a single egl-image-external. See: http://www.khronos.org/registry/gles/extensions/OES

[PATCH weston 5/5] compositor: triangle fan debug

From: Pekka Paalanen Draw the borders of all the triangles. v1: original v2: add keybinding to enable/disable fan debug (super-alt-space), cycle colors to make it easier to see individual draws, and redraw undamaged region to clean up previous frames debug lines Signed-off-by: Rob

[PATCH weston 4/5] compositor: fix blending for full-surface alpha

From: Pekka Paalanen We can use and render the opaque region only, if we are not applying a full-surface alpha. Test case: weston-terminal; use super+alt+mousewheel to adjust the window transparency. Before it went black, now it blends correctly. Signed-off-by: Pekka Paalanen --- src/composit

[PATCH weston 3/5] compositor: specialised fragment shader for RGBX

From: Pekka Paalanen Remove the weston_surface::blend attribute, which really meant that the texture produced valid alpha values. This was used to override the opaque region for RGBX surfaces, which produce undefined values for alpha. Instead, compile a new shader especially for RGBX surfaces, t

[PATCH weston 2/5] compositor: simplify shaders

From: Rob Clark Re-work how the shaders and emitted vertices work. Rather than always rendering clip-rect sized quads and doing transformation in tex coords (and requiring the corresponding clipping in frag shader), instead emit transformed vertices, clipped wrt. dirty region, and use simpler

[PATCH weston 1/5] compositor: add support for OES_EGL_image_external

From: Rob Clark In cases where the GPU can natively handle certain YUV formats, eglQueryWaylandBufferWL() can return the value EGL_TEXTURE_EXTERNAL_WL and the compositor will treat the buffer as a single egl-image-external. See: http://www.khronos.org/registry/gles/extensions/OES

[PATCH weston 0/5] rendering optimizations

From: Rob Clark This patchset is an updated version of my earlier patches, plus a bunch of updates from Pekka. Some have Pekka's fixes have been squashed. Also, I have made some updates to the triangle-fan debug to enable dynamic enable/disable and a few other tweaks. Pekka Paalan

Re: [RFC weston] compositor: optimize/simplify shaders

On Thu, Aug 30, 2012 at 6:11 AM, Pekka Paalanen wrote: > On Wed, 29 Aug 2012 19:18:17 -0500 > Rob Clark wrote: > >> On Tue, Aug 28, 2012 at 8:27 AM, Pekka Paalanen wrote: >> > On Mon, 27 Aug 2012 17:03:10 +0300 >> > Pekka Paalanen wrote: >> > >&g

Re: [RFC weston] compositor: optimize/simplify shaders

On Tue, Aug 28, 2012 at 8:27 AM, Pekka Paalanen wrote: > On Mon, 27 Aug 2012 17:03:10 +0300 > Pekka Paalanen wrote: > >> Hi Rob, >> >> I've started reviewing your patch and fixing the remaining bugs. So far >> I think I got most of the blend/opaque region stuff sorted out. I >> haven't still gott

Re: [RFC weston] compositor: optimize/simplify shaders

On Wed, Aug 22, 2012 at 7:38 PM, Scott Moreau wrote: > > > On Wed, Aug 22, 2012 at 6:09 PM, Rob Clark wrote: >> >> From: Rob Clark >> >> Re-work how the shaders and emitted vertices work. Rather than always >> rendering clip-rect sized quads and doi

[RFC weston] compositor: optimize/simplify shaders

From: Rob Clark Re-work how the shaders and emitted vertices work. Rather than always rendering clip-rect sized quads and doing transformation in tex coords (and requiring the corresponding clipping in frag shader), instead emit transformed vertices, clipped wrt. dirty region, and use simpler

Re: [Mesa-dev] [PATCH weston] compositor: add support for OES_EGL_image_external

On Fri, Aug 17, 2012 at 1:09 AM, Pekka Paalanen wrote: > On Thu, 16 Aug 2012 17:28:20 -0500 > Rob Clark wrote: > >> From: Rob Clark >> >> In cases where the GPU can natively handle certain YUV formats, >> eglQueryWaylandBufferWL() can return the value E

[PATCH weston] compositor: add support for OES_EGL_image_external

From: Rob Clark In cases where the GPU can natively handle certain YUV formats, eglQueryWaylandBufferWL() can return the value EGL_TEXTURE_EXTERNAL_WL and the compositor will treat the buffer as a single egl-image-external. See: http://www.khronos.org/registry/gles/extensions/OES

[PATCH mesa] add EGL_TEXTURE_EXTERNAL_WL to WL_bind_wayland_display spec

From: Rob Clark Signed-off-by: Rob Clark --- docs/WL_bind_wayland_display.spec |5 + include/EGL/eglmesaext.h |1 + 2 files changed, 6 insertions(+) diff --git a/docs/WL_bind_wayland_display.spec b/docs/WL_bind_wayland_display.spec index 02bd6ea..ce52e2d 100644 --- a

Re: [PATCH weston 2/2] compositor: add support for OES_EGL_image_external

On Mon, Aug 13, 2012 at 5:39 PM, Rob Clark wrote: > From: Rob Clark > > In cases where the GPU can natively handle certain YUV formats, > eglQueryWaylandBufferWL() can return the value EGL_TEXTURE_EXTERNAL_OES > and the compositor will treat the buffer as a single egl-image-ex

[PATCH weston 2/2] compositor: add support for OES_EGL_image_external

From: Rob Clark In cases where the GPU can natively handle certain YUV formats, eglQueryWaylandBufferWL() can return the value EGL_TEXTURE_EXTERNAL_OES and the compositor will treat the buffer as a single egl-image-external. See: http://www.khronos.org/registry/gles/extensions/OES

[PATCH weston 1/2] compositor: a couple debug logs

From: Rob Clark Well, they were useful to me in debugging, so probably sooner or later useful to someone else. Signed-off-by: Rob Clark --- src/compositor.c |6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/compositor.c b/src/compositor.c index ed887a4..b2a3ae9

[PATCH mesa] add EGL_TEXTURE_EXTERNAL_OES to WL_bind_wayland_display

From: Rob Clark Signed-off-by: Rob Clark --- docs/WL_bind_wayland_display.spec |5 + include/EGL/eglmesaext.h |1 + 2 files changed, 6 insertions(+) diff --git a/docs/WL_bind_wayland_display.spec b/docs/WL_bind_wayland_display.spec index 02bd6ea..7b09212 100644 --- a

[PATCH weston 2/2] compositor-drm: don't attempt sprite for out of bounds dimensions

From: Rob Clark The drmModeAddFB2() call will fail anyways, and cause us to unnecessarily set sprites_are_broken. Signed-off-by: Rob Clark --- src/compositor-drm.c | 25 - 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/src/compositor-drm.c b/src

[PATCH weston 1/2] compositor-drm: skip overlay for shm buffers

From: Rob Clark They can't be imported by gbm, so no point in trying, and segfaulting in gbm when we try to import (because it tries to deref the buffer as a wl_drm_buffer). Signed-off-by: Rob Clark --- src/compositor-drm.c |3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH weston] compositor-drm: don't keep trying if hw doesn't support cursors

From: Rob Clark Not all hw supports hw cursors. Similar to the case with sprites, if the driver does not support it, don't keep trying and spamming the log with error messages. Signed-off-by: Rob Clark --- src/compositor-drm.c |6 ++ 1 file changed, 6 insertions(+) diff --git

[PATCH weston] compositor-drm: handle vblanks on secondary crtc

From: Rob Clark Signed-off-by: Rob Clark --- src/compositor-drm.c |5 + 1 file changed, 5 insertions(+) diff --git a/src/compositor-drm.c b/src/compositor-drm.c index 8ea4965..80dccfc 100644 --- a/src/compositor-drm.c +++ b/src/compositor-drm.c @@ -100,6 +100,7 @@ struct drm_output

Re: [PATCH 5/5] RFC: add eglWaitGL()

On Tue, Mar 20, 2012 at 12:45 PM, Kristian Hoegsberg wrote: > On Sun, Mar 11, 2012 at 07:48:45PM -0500, Rob Clark wrote: >> From: Rob Clark >> >> For deferred rendering GPUs, some magic under the hood of eglSwapBuffers() >> is responsible for making sure rendering has

Re: [PATCH 2/5] drm: use page-flip for sprites, in case no vblank event

On Mon, Mar 12, 2012 at 4:11 AM, David Herrmann wrote: > Hi Rob > > On Mon, Mar 12, 2012 at 1:48 AM, Rob Clark wrote: >> From: Rob Clark >> >> If the output does not support vblank events (possibly the case with >> USB or DSI command mode displays which do not

[PATCH 5/5] RFC: add eglWaitGL()

From: Rob Clark For deferred rendering GPUs, some magic under the hood of eglSwapBuffers() is responsible for making sure rendering has actually started. (glFlush() doesn't do the trick.) I've managed to make weston drm compositor work on sgx/pvr stack (plus omapdrm providing the KM

[PATCH 4/5] drm: fix issue copying supported plane formats

From: Rob Clark Originally on the first 1/4th of the plane formats were copied, leading to problems if AR24/XR24 appears later in the list. --- src/compositor-drm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/compositor-drm.c b/src/compositor-drm.c index

[PATCH 3/5] drm: plane src coords are 16.16 fixed point

From: Rob Clark --- src/compositor-drm.c |9 - 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/src/compositor-drm.c b/src/compositor-drm.c index 500ec15..cf9a937 100644 --- a/src/compositor-drm.c +++ b/src/compositor-drm.c @@ -538,13 +538,12

[PATCH 2/5] drm: use page-flip for sprites, in case no vblank event

From: Rob Clark If the output does not support vblank events (possibly the case with USB or DSI command mode displays which do not have a traditional vsync), use instead the page_flip handler to know when the display is finished scanning out a sprite. --- src/compositor-drm.c | 17

[PATCH 1/5] clients/window: fix build issues w/ gles

From: Rob Clark --- clients/window.c | 13 - 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/clients/window.c b/clients/window.c index b09de5b..5465c2d 100644 --- a/clients/window.c +++ b/clients/window.c @@ -41,7 +41,12 @@ #include +#ifdef USE_CAIRO_GLESV2

Re: Future desktop on dumb frame buffers?

On Sat, Mar 19, 2011 at 6:20 AM, Geert Uytterhoeven wrote: > As noone responded to my question in > http://www.spinics.net/lists/dri-devel/msg08851.html > (yes, it was a bit hidden in a thread), I'm asking it here again (and > also on the Wayland > mailing list). > > Basically I'm still puzzled ab