[Intel-gfx] [PATCH] uxa: Do not use RandR in hotplug if not available
When using Xinerama, RandR is automatically disabled, and calling RR routines will trigger an assert() because the RR keys/resources are not set, leading to an Xserver abort. Hotplug makes little sense without RandR, so it's safer to just return if RandR is not available. Signed-off-by: Olivier Fourdan --- src/uxa/intel_display.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/src/uxa/intel_display.c b/src/uxa/intel_display.c index a95b3de..e42a59d 100644 --- a/src/uxa/intel_display.c +++ b/src/uxa/intel_display.c @@ -2516,6 +2516,13 @@ intel_mode_hotplug(struct intel_screen_private *intel) Bool found; Bool changed = FALSE; struct intel_mode *mode = intel->modes; + +#ifdef HAS_DIXREGISTERPRIVATEKEY + /* Without RR, nothing we can do here */ + if (!dixPrivateKeyRegistered(rrPrivKey)) + return; +#endif + mode_res = drmModeGetResources(intel->drmSubFD); if (!mode_res) goto out; -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] uxa: Do not register hotplug without RandR
When using Xinerama, RandR is automatically disabled, and calling RR
routines will trigger an assert() because the RR keys/resources are
not set, leading to an Xserver abort.
Hotplug makes little sense without RandR, so no need to install a
udev monitor if RandR is not available, as done in sna.
Signed-off-by: Olivier Fourdan
---
v2: Do not register udev monitor without RandR as done in sna.
src/uxa/intel_driver.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/uxa/intel_driver.c b/src/uxa/intel_driver.c
index 6e64b8c..7cd770f 100644
--- a/src/uxa/intel_driver.c
+++ b/src/uxa/intel_driver.c
@@ -775,6 +775,12 @@ I830UeventInit(ScrnInfoPtr scrn)
Bool hotplug;
MessageType from = X_CONFIG;
+#ifdef HAS_DIXREGISTERPRIVATEKEY
+ /* Without RR, nothing we can do here */
+ if (!dixPrivateKeyRegistered(rrPrivKey))
+ return;
+#endif
+
if (!xf86GetOptValBool(intel->Options, OPTION_HOTPLUG, &hotplug)) {
from = X_DEFAULT;
hotplug = TRUE;
--
2.3.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH] sna: Fix build with gcc 5.0
gcc generates an error at build time because it fails to inline some
functions:
blt.c: In function 'affine_blt':
blt.c:980:1: error: inlining failed in call to always_inline
'bilinear_weight': optimization level attribute mismatch
bilinear_weight(pixman_fixed_t x)
blt.c:1164:7: error: called from here
fy = bilinear_weight(y1);
^
blt.c:980:1: error: inlining failed in call to always_inline
'bilinear_weight': optimization level attribute mismatch
bilinear_weight(pixman_fixed_t x)
blt.c:1163:7: error: called from here
fx = bilinear_weight(x1);
^
blt.c:989:1: error: inlining failed in call to always_inline
'bilinear_interpolation': optimization level attribute mismatch
bilinear_interpolation(uint32_t tl, uint32_t tr,
^
blt.c:1207:11: error: called from here
b[i] = bilinear_interpolation(tl, tr, bl, br, fx, fy);
^
Do not force inlining of these functions and let the compiler decide to
avoid the compilation failure.
Signed-off-by: Olivier Fourdan
---
Note: It could be a gcc bug, I am not sure, I don't know enough of
gcc internals to tell, that's why I post this patch as "RFC".
src/sna/blt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/sna/blt.c b/src/sna/blt.c
index a2472c1..687fb40 100644
--- a/src/sna/blt.c
+++ b/src/sna/blt.c
@@ -976,7 +976,7 @@ memcpy_xor(const void *src, void *dst, int bpp,
}
#define BILINEAR_INTERPOLATION_BITS 4
-static force_inline int
+static inline int
bilinear_weight(pixman_fixed_t x)
{
return (x >> (16 - BILINEAR_INTERPOLATION_BITS)) &
@@ -985,7 +985,7 @@ bilinear_weight(pixman_fixed_t x)
#if BILINEAR_INTERPOLATION_BITS <= 4
/* Inspired by Filter_32_opaque from Skia */
-static force_inline uint32_t
+static inline uint32_t
bilinear_interpolation(uint32_t tl, uint32_t tr,
uint32_t bl, uint32_t br,
int distx, int disty)
--
2.3.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] sna: Fix build with gcc 5.0
Hi Chris, On 24/04/15 10:11, Chris Wilson wrote: On Fri, Apr 24, 2015 at 09:43:37AM +0200, Olivier Fourdan wrote: gcc generates an error at build time because it fails to inline some functions: blt.c: In function 'affine_blt': blt.c:980:1: error: inlining failed in call to always_inline 'bilinear_weight': optimization level attribute mismatch Does this mean anything more specific (than just it not being able to inline)? Note: It could be a gcc bug, I am not sure, I don't know enough of gcc internals to tell, that's why I post this patch as "RFC". Since bilinear_weight() is trivial and bilinear_interpolation() is only called from one location, I wonder what is up? Humm, that looks definitely dodgy, now the build fails a bit further when _FORTIFY_SOURCE is set to 2: In file included from /usr/include/string.h:639:0, from /usr/include/xorg/os.h:53, from /usr/include/xorg/misc.h:115, from /usr/include/xorg/xf86str.h:37, from sna.h:43, from blt.c:32: blt.c: In function 'memcpy_from_tiled_x__swizzle_9_10_11': /usr/include/bits/string3.h:50:42: error: inlining failed in call to always_inline 'memcpy': optimization level attribute mismatch __NTH (memcpy (void *__restrict __dest, const void *__restrict __src, ^ blt.c:474:1314: error: called from here In file included from /usr/include/string.h:639:0, from /usr/include/xorg/os.h:53, from /usr/include/xorg/misc.h:115, from /usr/include/xorg/xf86str.h:37, from sna.h:43, from blt.c:32: /usr/include/bits/string3.h:50:42: error: inlining failed in call to always_inline 'memcpy': optimization level attribute mismatch __NTH (memcpy (void *__restrict __dest, const void *__restrict __src, ^ blt.c:474:1605: error: called from here In file included from /usr/include/string.h:639:0, from /usr/include/xorg/os.h:53, from /usr/include/xorg/misc.h:115, from /usr/include/xorg/xf86str.h:37, from sna.h:43, from blt.c:32: /usr/include/bits/string3.h:50:42: error: inlining failed in call to always_inline 'memcpy': optimization level attribute mismatch __NTH (memcpy (void *__restrict __dest, const void *__restrict __src, ^ blt.c:474:1865: error: called from here Makefile:650: recipe for target 'blt.lo' failed Yet, *not* setting _FORTIFY_SOURCE seems to work around the issue. I find it weird the error is with the inlining of memcpy() ... I'll double check on the gcc side and report back once I know more :) Cheers, Olivier ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] sna: Fix build with gcc 5.0
On 24/04/15 10:43, Olivier Fourdan wrote: [...] Yet, *not* setting _FORTIFY_SOURCE seems to work around the issue. I find it weird the error is with the inlining of memcpy() ... I'll double check on the gcc side and report back once I know more :) Quick follow-up, I checked with Jakub and he confirmed this is a gcc issue: http://gcc.gnu.org/PR65873 So we should be all set, once this gcc bug is addressed. Thanks! Olivier ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] backlight: Do not hang forever if helper pid is -1
Backlight helper PID is set to -1 by default, if for some reason it's
not set, we may end up with waitpid(-1, ...) which will hang forever.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90230
Signed-off-by: Olivier Fourdan
---
src/backlight.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/backlight.c b/src/backlight.c
index 84d8f76..c65e466 100644
--- a/src/backlight.c
+++ b/src/backlight.c
@@ -523,7 +523,7 @@ void backlight_disable(struct backlight *b)
void backlight_close(struct backlight *b)
{
backlight_disable(b);
- if (b->pid)
+ if (b->pid > 0)
waitpid(b->pid, NULL, 0);
}
--
2.3.6
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] build error with GCC5.1.1
Hey,
> gcc5.1.1 generates an error at build time.
>
> sna_accel.c: In function 'sna_poly_zero_line_blt':
> sna_accel.c:9207:10: warning: variable 'intersects' set but not used
> [-Wunused-but-set-variable]
>bool intersects;
>^
> sna_accel.c:9107:6: warning: variable 'degenerate' set but not used
> [-Wunused-but-set-variable]
>bool degenerate = true;
>^
Well, those are "unused variable warnings" so not an error. Could be easily
fixed though.
>CC sna_cpu.lo
> In file included from /usr/include/string.h:635:0,
> from /usr/include/xorg/os.h:53,
> from /usr/include/xorg/misc.h:115,
> from /usr/include/xorg/xf86str.h:37,
> from sna.h:43,
> from blt.c:32:
> blt.c: In function 'memcpy_from_tiled_x__swizzle_9_10_11':
> /usr/include/bits/string3.h:50:42: error: inlining failed in call to
> always_inline 'memcpy': optimization level attribute mismatch
> __NTH (memcpy (void *__restrict __dest, const void *__restrict __src,
Right, this is a known issue in gcc 5.1, see here:
http://gcc.gnu.org/PR65873
The (easy) workaround is to avoid the "-Ofast" optimization.
E.g. something like that in src/sna/compiler.h:
--- a/src/sna/compiler.h
+++ b/src/sna/compiler.h
@@ -63,7 +63,7 @@
#define sse4_2 __attribute__((target("sse4.2,sse2,fpmath=sse")))
#endif
-#if HAS_GCC(4, 6) && defined(__OPTIMIZE__)
+#if HAS_GCC(4, 6) && !HAS_GCC(5, 0) && defined(__OPTIMIZE__)
#define fast __attribute__((optimize("Ofast")))
#else
#define fast
But I do not think this is something suitable for upstream as the bug lies in
gcc, so it's just a workaround until the issue is fixed in gcc.
HTH
Cheers,
Olivier.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
