[PATCH] glamor: add fallback if NULL EGLConfig is not supported
Signed-off-by: Kai Guo kai@amd.com
Signed-off-by: Jammy Zhou jammy.z...@amd.com
---
glamor/glamor_egl.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index 113450c..b230e39 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor_egl.c
@@ -800,8 +800,32 @@ glamor_egl_init(ScrnInfoPtr scrn, int fd)
NULL, EGL_NO_CONTEXT,
config_attribs);
if (glamor_egl-context == EGL_NO_CONTEXT) {
-xf86DrvMsg(scrn-scrnIndex, X_ERROR, Failed to create EGL context\n);
-return FALSE;
+ /* fallback to select a EGLConfig explicitly */
+EGLint attr[] = {
+EGL_RENDERABLE_TYPE,
+#ifdef GLAMOR_GLES2
+EGL_OPENGL_ES2_BIT,
+#else
+EGL_OPENGL_BIT,
+#endif
+EGL_NONE
+};
+
+EGLConfig config;
+EGLint n;
+if (!eglChooseConfig(glamor_egl-display, attr, config, 1, n)
+|| (n != 1)) {
+xf86DrvMsg(scrn-scrnIndex, X_ERROR, Failed to choose EGL
config\n);
+return FALSE;
+}
+
+glamor_egl-context = eglCreateContext(glamor_egl-display,
+ config, EGL_NO_CONTEXT,
+ config_attribs);
+if (glamor_egl-context == EGL_NO_CONTEXT) {
+xf86DrvMsg(scrn-scrnIndex, X_ERROR, Failed to create EGL
context\n);
+return FALSE;
+}
}
if (!eglMakeCurrent(glamor_egl-display,
--
1.9.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] int10: Fix mapping the interrupt vector
pci_device_map_legacy returns 0 on success, and an errno value on
failure. It works a lot better if we don't treat 0 as failure.
Signed-off-by: Adam Jackson a...@redhat.com
---
hw/xfree86/int10/generic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/xfree86/int10/generic.c b/hw/xfree86/int10/generic.c
index 012d194..8d5c4da 100644
--- a/hw/xfree86/int10/generic.c
+++ b/hw/xfree86/int10/generic.c
@@ -104,7 +104,7 @@ readIntVec(struct pci_device *dev, unsigned char *buf, int
len)
{
void *map;
-if (!pci_device_map_legacy(dev, 0, len, 0, map))
+if (pci_device_map_legacy(dev, 0, len, 0, map))
return FALSE;
memcpy(buf, map, len);
--
1.9.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] int10: Fix mapping the interrupt vector
On Wed, 2015-03-04 at 12:51 -0500, Adam Jackson wrote: pci_device_map_legacy returns 0 on success, and an errno value on failure. It works a lot better if we don't treat 0 as failure. I already posted a similar patch about a month ago. There is an identical bug in a second file, which my patch fixes as well. http://lists.x.org/archives/xorg-devel/2015-February/045546.html http://patchwork.freedesktop.org/patch/41957/ Regards, Jürg ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] glamor: Perform texture2D() separately from swizzle.
The texture2D() happens in each branch, so we may as well do it as early
as possible and hide some of its latency in the branching instructions.
Moving it outside the (uniform) control flow reduces the number of
instructions in the fs_source shader from 64 to 46 and in the
set_alpha_source shader from 69 to 47 on Haswell.
---
Untested. Given a short primer on benchmarking glamor I'd be happy
to run some benchmarks.
glamor/glamor_core.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/glamor/glamor_core.c b/glamor/glamor_core.c
index 737b274..a26f8f9 100644
--- a/glamor/glamor_core.c
+++ b/glamor/glamor_core.c
@@ -173,46 +173,48 @@ glamor_init_finish_access_shaders(ScreenPtr screen)
const char *fs_source =
void main()\n
{\n
+ vec4 color = texture2D(sampler, source_texture);\n
if (revert == REVERT_NONE) \n
{ \n
if ((swap_rb != SWAP_NONE_DOWNLOADING) (swap_rb !=
SWAP_NONE_UPLOADING)) \n
- gl_FragColor = texture2D(sampler,
source_texture).bgra;\n
+ gl_FragColor = color.bgra;\n
else \n
- gl_FragColor = texture2D(sampler,
source_texture).rgba;\n
+ gl_FragColor = color.rgba;\n
} \n
else \n
{ \n
if (swap_rb == SWAP_DOWNLOADING) \n
- gl_FragColor = texture2D(sampler,
source_texture).argb;\n
+ gl_FragColor = color.argb;\n
else if (swap_rb == SWAP_NONE_DOWNLOADING)\n
- gl_FragColor = texture2D(sampler,
source_texture).abgr;\n
+ gl_FragColor = color.abgr;\n
else if (swap_rb == SWAP_UPLOADING)\n
- gl_FragColor = texture2D(sampler,
source_texture).gbar;\n
+ gl_FragColor = color.gbar;\n
else if (swap_rb == SWAP_NONE_UPLOADING)\n
- gl_FragColor = texture2D(sampler,
source_texture).abgr;\n
+ gl_FragColor = color.abgr;\n
} \n
}\n;
const char *set_alpha_source =
void main()\n
{\n
+ vec4 color = texture2D(sampler, source_texture);\n
if (revert == REVERT_NONE) \n
{ \n
if ((swap_rb != SWAP_NONE_DOWNLOADING) (swap_rb !=
SWAP_NONE_UPLOADING)) \n
- gl_FragColor = vec4(texture2D(sampler,
source_texture).bgr, 1);\n
+ gl_FragColor = vec4(color.bgr, 1);\n
else \n
- gl_FragColor = vec4(texture2D(sampler,
source_texture).rgb, 1);\n
+ gl_FragColor = vec4(color.rgb, 1);\n
} \n
else \n
{ \n
if (swap_rb == SWAP_DOWNLOADING) \n
- gl_FragColor = vec4(1, texture2D(sampler,
source_texture).rgb);\n
+ gl_FragColor = vec4(1, color.rgb);\n
else if (swap_rb == SWAP_NONE_DOWNLOADING)\n
- gl_FragColor = vec4(1, texture2D(sampler,
source_texture).bgr);\n
+ gl_FragColor = vec4(1, color.bgr);\n
else if (swap_rb == SWAP_UPLOADING)\n
- gl_FragColor = vec4(texture2D(sampler,
source_texture).gba, 1);\n
+ gl_FragColor = vec4(color.gba, 1);\n
else if (swap_rb == SWAP_NONE_UPLOADING)\n
- gl_FragColor = vec4(texture2D(sampler,
source_texture).abg, 1);\n
+ gl_FragColor = vec4(color.abg, 1);\n
} \n
}\n;
GLint fs_prog, vs_prog, avs_prog, set_alpha_prog;
--
2.0.5
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xf86-input-libinput] Up the scroll dist value for touchpads
On Wed, Mar 04, 2015 at 01:15:31PM +0100, Hans de Goede wrote:
Hi,
On 04-03-15 06:00, Peter Hutterer wrote:
For source FINGER and CONTINUOUS, the axis value is the same as relative
motion - but scrolling in X usually doesn't have the same speed as finger
movement, it's a lot coarser.
We don't know ahead of time where we'll get the scroll events from. Set a
default scroll distance of 15 and multiply any wheel clicks we get by this
value.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
15 is more-or-less a magic value, it feels just right on my box here
Hmm, this is somewhat different from what we discussed in our mail
conversation.
indeed, I had that first, then compared it to the evdev driver and decided
that this one is the better approach after all, explanation below.
First of all the problem most users are reporting and I'm seeing myself is not
that mouse wheel scrolling is too slow (which this patch seems to imply), but
rather that finger scrolling is much too fast, see e.g.:
https://bugzilla.redhat.com/show_bug.cgi?id=1198467
What I understood from our discussion on this is that the idea for
mouse wheel scrolling was to emulate discrete-value number of button
4 / 5 clicks and let X do the translation into scrolling axis, giving
us the exact same scroll wheel speed as the evdev driver.
That and for finger scroll events actually make things slower by applying
a multiplication factor 1.0 .
X has two ways for a driver to submit scroll events: buttons 4-7 or data in
a scroll valuator. Because clients may rely on either of those methods
exclusively, the server emulates the other method.
If set up, a driver defines a scroll distance. A valuator movement of that
scroll distance is equivalent to one mouse wheel click, and vice versa.
So if the driver sends a button 5 click, the server emulates a
distance motion event. If the driver sends a distance motion event, the
server emulates a button 4 click. The distance accumulates in the server, so
if you send distance/2 twice, the server will only emulate the click event
on the second event.
This is what the scroll distance does here - a movement of 15 on the
touchpad is now equivalent to a mouse wheel click. So this patch does slow
down the touchpad scrolling while leaving the mouse wheel as-is.
This is a better approach (and a smaller diff) than the button click
approach I suggested initially because it gives us some smooth scrolling on
the wheel as well. A REL_WHEEL value of 2 will now result in a single smooth
scroll event that can be used for speed calculation. Posting the button
events directly would prevent that.
Ideally we could just leave the scroll distance at 1 for devices that only
have mouse wheels but we don't know this at device init time. Hence the
default distance optimized for touchpads, then we multiply by that distance
for wheel clicks. The actual value of the scroll distance is meaningless,
it's just a reference to know how many scroll units a motion event
represents. IIRC synaptics currently uses a default of 100 and that's in
device coordinates.
So in short, this patch does what we want, it slows down touchpad scrolling
while leaving wheel scrolling as-is.
Cheers,
Peter
src/libinput.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/src/libinput.c b/src/libinput.c
index 049c15b..5e616c8 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -756,18 +756,22 @@ xf86libinput_handle_axis(InputInfoPtr pInfo, struct
libinput_event_pointer *even
axis = LIBINPUT_POINTER_AXIS_SCROLL_VERTICAL;
if (libinput_event_pointer_has_axis(event, axis)) {
-if (source == LIBINPUT_POINTER_AXIS_SOURCE_WHEEL)
+if (source == LIBINPUT_POINTER_AXIS_SOURCE_WHEEL) {
value =
libinput_event_pointer_get_axis_value_discrete(event, axis);
-else
+value *= driver_data-scroll_vdist;
+} else {
value = libinput_event_pointer_get_axis_value(event,
axis);
+}
valuator_mask_set_double(mask, 3, value);
}
axis = LIBINPUT_POINTER_AXIS_SCROLL_HORIZONTAL;
if (libinput_event_pointer_has_axis(event, axis)) {
-if (source == LIBINPUT_POINTER_AXIS_SOURCE_WHEEL)
+if (source == LIBINPUT_POINTER_AXIS_SOURCE_WHEEL) {
value =
libinput_event_pointer_get_axis_value_discrete(event, axis);
-else
+value *= driver_data-scroll_hdist;
+} else {
value = libinput_event_pointer_get_axis_value(event,
axis);
+}
valuator_mask_set_double(mask, 2, value);
}
@@ -1189,8 +1193,8 @@ xf86libinput_pre_init(InputDriverPtr drv,
if (!driver_data-valuators)
goto fail;
-driver_data-scroll_vdist = 1;
-driver_data-scroll_hdist = 1;
+
Re: [PATCH] int10: Fix mapping the interrupt vector
On Wed, 2015-03-04 at 20:08 +0100, Jürg Billeter wrote: On Wed, 2015-03-04 at 12:51 -0500, Adam Jackson wrote: pci_device_map_legacy returns 0 on success, and an errno value on failure. It works a lot better if we don't treat 0 as failure. I already posted a similar patch about a month ago. There is an identical bug in a second file, which my patch fixes as well. http://lists.x.org/archives/xorg-devel/2015-February/045546.html http://patchwork.freedesktop.org/patch/41957/ Ugh, embarassing for me. I'd even grepped to make sure I hadn't gotten it wrong more than once, clearly I just missed it. Reviewed-by: Adam Jackson a...@redhat.com - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] glx/dri2: Disable AIGLX if indirect GLX is disabled
On Thu, Mar 05, 2015 at 01:18:51PM +0900, Michel Dänzer wrote: On 04.03.2015 21:16, Chris Wilson wrote: There is no point in setting up the acceleration for indirect GLX if indirect GLX is itself disabled. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk --- glx/glxdri2.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/glx/glxdri2.c b/glx/glxdri2.c index ec86a73..7cb0f28 100644 --- a/glx/glxdri2.c +++ b/glx/glxdri2.c @@ -945,6 +945,9 @@ __glXDRIscreenProbe(ScreenPtr pScreen) size_t buffer_size; ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen); +if (!enableIndirectGLX) + return NULL; + screen = calloc(1, sizeof *screen); if (screen == NULL) return NULL; Can the GLX visual information still be probed from the DRI driver with this patch? No. This patch kills the AIGLX messages and also DRI. Sadly as probing mesa/i965 is the single most CPU expensive step in starting X. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] glx/dri2: Disable AIGLX if indirect GLX is disabled
On 04.03.2015 21:16, Chris Wilson wrote: There is no point in setting up the acceleration for indirect GLX if indirect GLX is itself disabled. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk --- glx/glxdri2.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/glx/glxdri2.c b/glx/glxdri2.c index ec86a73..7cb0f28 100644 --- a/glx/glxdri2.c +++ b/glx/glxdri2.c @@ -945,6 +945,9 @@ __glXDRIscreenProbe(ScreenPtr pScreen) size_t buffer_size; ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen); +if (!enableIndirectGLX) + return NULL; + screen = calloc(1, sizeof *screen); if (screen == NULL) return NULL; Can the GLX visual information still be probed from the DRI driver with this patch? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] glx/dri2: Disable AIGLX if indirect GLX is disabled
There is no point in setting up the acceleration for indirect GLX if indirect GLX is itself disabled. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk --- glx/glxdri2.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/glx/glxdri2.c b/glx/glxdri2.c index ec86a73..7cb0f28 100644 --- a/glx/glxdri2.c +++ b/glx/glxdri2.c @@ -945,6 +945,9 @@ __glXDRIscreenProbe(ScreenPtr pScreen) size_t buffer_size; ScrnInfoPtr pScrn = xf86ScreenToScrn(pScreen); +if (!enableIndirectGLX) + return NULL; + screen = calloc(1, sizeof *screen); if (screen == NULL) return NULL; -- 2.1.4 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xf86-input-libinput] Up the scroll dist value for touchpads
Hi,
On 04-03-15 06:00, Peter Hutterer wrote:
For source FINGER and CONTINUOUS, the axis value is the same as relative
motion - but scrolling in X usually doesn't have the same speed as finger
movement, it's a lot coarser.
We don't know ahead of time where we'll get the scroll events from. Set a
default scroll distance of 15 and multiply any wheel clicks we get by this
value.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
15 is more-or-less a magic value, it feels just right on my box here
Hmm, this is somewhat different from what we discussed in our mail conversation.
First of all the problem most users are reporting and I'm seeing myself is not
that mouse wheel scrolling is too slow (which this patch seems to imply), but
rather that finger scrolling is much too fast, see e.g.:
https://bugzilla.redhat.com/show_bug.cgi?id=1198467
What I understood from our discussion on this is that the idea for
mouse wheel scrolling was to emulate discrete-value number of button
4 / 5 clicks and let X do the translation into scrolling axis, giving
us the exact same scroll wheel speed as the evdev driver.
That and for finger scroll events actually make things slower by applying
a multiplication factor 1.0 .
Regards,
Hans
src/libinput.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/src/libinput.c b/src/libinput.c
index 049c15b..5e616c8 100644
--- a/src/libinput.c
+++ b/src/libinput.c
@@ -756,18 +756,22 @@ xf86libinput_handle_axis(InputInfoPtr pInfo, struct
libinput_event_pointer *even
axis = LIBINPUT_POINTER_AXIS_SCROLL_VERTICAL;
if (libinput_event_pointer_has_axis(event, axis)) {
- if (source == LIBINPUT_POINTER_AXIS_SOURCE_WHEEL)
+ if (source == LIBINPUT_POINTER_AXIS_SOURCE_WHEEL) {
value =
libinput_event_pointer_get_axis_value_discrete(event, axis);
- else
+ value *= driver_data-scroll_vdist;
+ } else {
value = libinput_event_pointer_get_axis_value(event,
axis);
+ }
valuator_mask_set_double(mask, 3, value);
}
axis = LIBINPUT_POINTER_AXIS_SCROLL_HORIZONTAL;
if (libinput_event_pointer_has_axis(event, axis)) {
- if (source == LIBINPUT_POINTER_AXIS_SOURCE_WHEEL)
+ if (source == LIBINPUT_POINTER_AXIS_SOURCE_WHEEL) {
value =
libinput_event_pointer_get_axis_value_discrete(event, axis);
- else
+ value *= driver_data-scroll_hdist;
+ } else {
value = libinput_event_pointer_get_axis_value(event,
axis);
+ }
valuator_mask_set_double(mask, 2, value);
}
@@ -1189,8 +1193,8 @@ xf86libinput_pre_init(InputDriverPtr drv,
if (!driver_data-valuators)
goto fail;
- driver_data-scroll_vdist = 1;
- driver_data-scroll_hdist = 1;
+ driver_data-scroll_vdist = 15;
+ driver_data-scroll_hdist = 15;
path = xf86SetStrOption(pInfo-options, Device, NULL);
if (!path)
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
