[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