Hi Andreas,
On Thu, Jan 23, 2014 at 09:00:11PM +0100, wettstein...@solnet.ch wrote:
The goal of the following patches is to make ISOLock work. The most
severe issues addressed were in the server, where the code used the
incorrect byte to look for the affect flags, and where the ClearLocks
Hi,
On 02/03/2014 01:07 AM, Peter Hutterer wrote:
On Fri, Jan 31, 2014 at 05:30:58PM +0100, Hans de Goede wrote:
Hi,
On 01/31/2014 12:36 AM, Peter Hutterer wrote:
On Thu, Jan 30, 2014 at 09:40:33AM +0100, Hans de Goede wrote:
Hi,
On 01/30/2014 12:51 AM, Peter Hutterer wrote:
Just forcing
Keith Packard kei...@keithp.com writes:
There's no reason to advertise this extension unless one of the
hardware drivers actually supports it. Not listing it means it's
slightly easier for users to tell what's going on.
On the other hand, not listing it means we may have applications that
Signed-off-by: Eric Anholt e...@anholt.net
---
configure.ac | 3 +
glamor/glamor.c| 11 ++
glamor/glamor.h| 2 +
hw/kdrive/ephyr/Makefile.am| 20 ++-
hw/kdrive/ephyr/ephyr.c| 36 +++--
hw/kdrive/ephyr/ephyr.h
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/glamor/glamor_core.c b/glamor/glamor_core.c
index 5246c98..5883809 100644
--- a/glamor/glamor_core.c
+++ b/glamor/glamor_core.c
@@ -215,6 +215,7 @@
If you're building a new X Server and trying to light up glamor, one
of the first things you want to do is get it rendering the screen to a
texture so you can later draw that to some real output (or possibly
not draw it at all, if it's Xvfb-like). Don't just leave it in a
segfaulting MEMORY
The GLX side just gets the context from the current state. That's
also something I want to do for EGL, so that the making a context is
separate from initializing glamor, but I think I need the modesetting
driver in the server before I think about hacking on that more.
The previous code was
If there's a swap already outstanding, don't bother queueing another
one until this one has completed. The assumption here is that our
screen paints are cheap compared to everything else going on, so we
don't need to queue them up way ahead of time. The swap events also
give us information we
This is the same thing that Qt ended up doing to get DRI2's event
mangling to happen despite using an XCB event loop.
Signed-off-by: Eric Anholt e...@anholt.net
---
hw/kdrive/ephyr/ephyr.c| 3 +++
hw/kdrive/ephyr/ephyr_glamor_glx.c | 39 ++
It used to be the thing that returned your dispatch table and happeend
to set up the context, but now it just sets up the context.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor.c | 8
glamor/glamor_copyarea.c | 18 +-
glamor/glamor_core.c
Additionally, there's a rendering bug when you run some Render-using
applications (cairogears -xrender TRAP shows it off very well) that I
think is fallback-related but I haven't quite tracked it down yet.
You can see some fallback fixes in glamor-server I wrote while trying
to fix this.
This
gl_ModelViewProjection and friends aren't used in our shaders, so this
setup didn't do anything.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_pixmap.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/glamor/glamor_pixmap.c b/glamor/glamor_pixmap.c
index 9fe2b2e..41d5f5a
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor.c | 4 ++--
glamor/glamor_priv.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/glamor/glamor.c b/glamor/glamor.c
index f1c71ea..ba2a1f4 100644
--- a/glamor/glamor.c
+++ b/glamor/glamor.c
@@ -308,10 +308,10
Now that we're using epoxy, we can write code using both desktop and
ES symbols and decide what to use at runtime.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor.c | 40 +++-
glamor/glamor_copyarea.c | 15 ++-
There's nothing dependent on the presence of DRI3 code in the server
for this, but it does rely on GBM.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_egl.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
Those calls are only for enabling texture handling in the fixed
function pipeline, while everything we do is with shaders.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_copyarea.c | 4
glamor/glamor_pixmap.c| 6 --
glamor/glamor_putimage.c | 2 --
We only ask for GL_RGB on desktop GL as far as I can see, but now if
GLES2 did happen to ask for GL_RGB it would return a cache index
instead of -1.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_priv.h | 4
glamor/glamor_utils.h | 18 ++
2 files changed, 2
This should be useful for glamor development, so you can test both
paths (which are significantly different, and apparently
glamor_gradient.c was broken on GLES2 as of the import).
Signed-off-by: Eric Anholt e...@anholt.net
---
hw/kdrive/ephyr/ephyr_glamor_glx.c | 24 +++-
There's no way these should be in a header file, but I'll leave that
cleanup until later.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_pixmap.c | 50 +-
1 file changed, 29 insertions(+), 21 deletions(-)
diff --git
This is the last desktop-versus-ES2 build ifdef in core glamor.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_priv.h | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/glamor/glamor_priv.h b/glamor/glamor_priv.h
index 81b46b6..e28a021 100644
---
Assuming it was the first attribute assigned by the GL, it would have
ended up with location 0 anyway.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_gradient.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/glamor/glamor_gradient.c b/glamor/glamor_gradient.c
A pair of 150 lines of inlined switch statements in a header file is
crazy.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_pixmap.c | 303 +
glamor/glamor_utils.h | 303 -
2 files
They never get reattached to any other program, so saving them to
unreference later is a waste of code.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_gradient.c | 88
glamor/glamor_priv.h | 9 -
2 files changed, 6
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_copyarea.c | 7 ---
glamor/glamor_fill.c | 4 ++--
glamor/glamor_pixmap.c | 17 +++--
glamor/glamor_priv.h | 2 +-
glamor/glamor_tile.c | 4 ++--
5 files changed, 20 insertions(+), 14 deletions(-)
diff
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor.c | 6 +++---
glamor/glamor_picture.c | 3 +--
glamor/glamor_pixmap.c | 4 ++--
glamor/glamor_utils.h | 26 --
4 files changed, 18 insertions(+), 21 deletions(-)
diff --git a/glamor/glamor.c
GLES2 sensibly doesn't allow you to attach multiple shaders for the
same stage to a single program. This means we have to attach the
whole thing in one glShaderSource call.
Signed-off-by: Eric Anholt e...@anholt.net
---
glamor/glamor_gradient.c | 68
Hello Ran,
Do you happen to have a keymap which is using any of the ISO stuff?
I do not have a keymap that use ISOLock. Furthermore, bugzilla does not
seem to have any bug report on ISOLock. xkeyboard-config removed it
from the compat section about two years ago, which means ISOLock cannot
be
Mark Kettenis mark.kette...@xs4all.nl writes:
From: Eric Anholt e...@anholt.net
Date: Mon, 27 Jan 2014 11:36:09 -0800
We all know that XIDs are 32 bits, even if 32-bit headers call them
long.
---
test/hashtabletest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
When using xvideo on alignement critical architectures (for example a sparc64
with the XVR100 graphics adapter) some screen positions (easily reproducable
with xfce and gmplayer by moving the video window partly out of the screen
on the left side) cause misaligned pointers being passed to
Le lundi 03 février 2014 à 11:03 -0800, Eric Anholt a écrit :
-#ifndef GLAMOR_GLES2
-if (gl_version GLAMOR_GL_VERSION_ENCODE(1, 3)) {
-ErrorF(Require OpenGL version 1.3 or latter.\n);
-goto fail;
-}
-#else
-if (gl_version GLAMOR_GL_VERSION_ENCODE(2, 0)) {
-
On Mon, 2013-12-30 at 09:15 -0600, Andrew Eikum wrote:
If there is a selection left over from a previous execution of the
main loop, and that selection has privates allocated for it, the X
server will crash. This is because dixResetPrivates() resets the
privates refcounts to zero without
On Wed, 2014-01-22 at 15:08 -0800, Eric Anholt wrote:
Jon TURNEY jon.tur...@dronecode.org.uk writes:
Commit be668096 glx: convert to direct GL dispatch (v2) removes glthread.c
from Makefile.am along with the rest of the dispatch table code, but doesn't
remove glthread.c itself.
On Thu, 2014-01-23 at 10:19 +0100, Clemens Eisserer wrote:
I recently saw Keith's video about tear-free X11 applications using
the present extension and would like to work use this extension in
OpenJDKs's Xrender backend.
However I had a hard time to find information how to use it and which
On Mon, 2014-02-03 at 11:03 -0800, Eric Anholt wrote:
Those calls are only for enabling texture handling in the fixed
function pipeline, while everything we do is with shaders.
Signed-off-by: Eric Anholt e...@anholt.net
Series is:
Reviewed-by: Adam Jackson a...@redhat.com
On Mon, 2014-01-27 at 11:36 -0800, Eric Anholt wrote:
In theory, the linux libGL ABI exposes just GL 1.2 plus GLX 1.3. But,
thanks to libglapi, we're letting glGetCompressedTexImageARB() be
exposed too. The GLX code was inappropriately relying on it by using
GL_GLEXT_PROTOTYPES.
1-4 of this
Introduced in fecc7eb1cf66db64728ee2d68cd9443df7e70879 and reverts most of
that but it's helpfully mixed with other stuff.
InputAttributes are not const, they're strdup'd everywhere but the test code
and freed properly. Revert the const char changes and fix the test up instead.
Signed-off-by:
Fixes Solaris Studio compiler warning error:
glxext.c, line 557: warning: assignment type mismatch:
pointer to void = pointer to function(void) returning void
glxext.c, line 559: error: operands have incompatible types:
pointer to void : pointer to function(void)
The function RRCrtcSet call checks to see if the config being set is
already configured, but, doesn't check that the selected outputs are
connected to the crtc before skipping. This means that the following
sequence will omit the final CrtcSet call to the driver:
CRTC c1 connect to output o
On Mon, 2014-02-03 at 20:36 +0100, Martin Husemann wrote:
When using xvideo on alignement critical architectures (for example a sparc64
with the XVR100 graphics adapter) some screen positions (easily reproducable
with xfce and gmplayer by moving the video window partly out of the screen
on the
On Mon, 2014-02-03 at 11:03 -0800, Eric Anholt wrote:
Now that we're using epoxy, we can write code using both desktop and
ES symbols and decide what to use at runtime.
Nice.
diff --git a/glamor/glamor_copyarea.c b/glamor/glamor_copyarea.c
index 498a06e..8cc7cad 100644
---
40 matches
Mail list logo