From keithp at keithp.com Sat Oct 1 05:43:59 2016 From: keithp at keithp.com (Keith Packard) Date: Fri, 30 Sep 2016 22:43:59 -0700 Subject: [PATCH xserver 0/3] glamor: Accelerate XY format images Message-ID: <20161001054402.31210-1-keithp@keithp.com> I took Adam's code to speed up XY format bitmaps and generalized that for XY format pixmaps too; that speeds up small pixmaps by a bunch. Then I went and wrote some much faster XY bitmap code which expands the image with the GPU (just like core text). That turns out to be faster for large images, but slower for small images due to GL overhead. On my Haswell laptop running Xephyr with -glamor-skip-present: 1: xy_old 2: xy_new 1 2 Operation ------------ ------------------------- ------------------------- 10900.0 99900.0 ( 9.165) PutImage XY 10x10 square 1740.0 2160.0 ( 1.241) PutImage XY 100x100 square 83.2 90.4 ( 1.087) PutImage XY 500x500 square 11800.0 351000.0 ( 29.746) PutImage XYBitmap 10x10 square 6280.0 81600.0 ( 12.994) PutImage XYBitmap 100x100 square 752.0 14300.0 ( 19.016) PutImage XYBitmap 500x500 square I'd like to know why the GPU expansion version has so much GL overhead; it "should" be faster for everything as it uploads a lot less data to the GPU. I'd also like to try writing an XYPixmap that did all of the plane merging in the fragment shader. That "should" be faster for large images than merging on the CPU. I tried just using my XYBitmap code in a loop with a rasterop, but that's actually slower than using the CPU (at least on my machine). Presumably doing 24 texture uploads isn't all that fast? From keithp at keithp.com Sat Oct 1 05:44:00 2016 From: keithp at keithp.com (Keith Packard) Date: Fri, 30 Sep 2016 22:44:00 -0700 Subject: [PATCH xserver 1/3] glamor: Accelerate PutImage for XYBitmap format In-Reply-To: <20161001054402.31210-1-keithp@keithp.com> References: <20161001054402.31210-1-keithp@keithp.com> Message-ID: <20161001054402.31210-2-keithp@keithp.com> Upload the bitmap and use a program like TE Text program to draw it, avoiding fallbacks for this case. Signed-off-by: Keith Packard --- glamor/glamor_image.c | 183 +++++++++++++++++++++++++++++++++++++++++++++++--- glamor/glamor_priv.h | 3 + 2 files changed, 176 insertions(+), 10 deletions(-) diff --git a/glamor/glamor_image.c b/glamor/glamor_image.c index 3158749..798277b 100644 --- a/glamor/glamor_image.c +++ b/glamor/glamor_image.c @@ -29,8 +29,8 @@ */ static Bool -glamor_put_image_gl(DrawablePtr drawable, GCPtr gc, int depth, int x, int y, - int w, int h, int leftPad, int format, char *bits) +glamor_put_image_zpixmap_gl(DrawablePtr drawable, GCPtr gc, int depth, int x, int y, + int w, int h, char *bits) { ScreenPtr screen = drawable->pScreen; glamor_screen_private *glamor_priv = glamor_get_screen_private(screen); @@ -52,12 +52,6 @@ glamor_put_image_gl(DrawablePtr drawable, GCPtr gc, int depth, int x, int y, if (!glamor_pm_is_solid(gc->depth, gc->planemask)) goto bail; - if (format == XYPixmap && drawable->depth == 1 && leftPad == 0) - format = ZPixmap; - - if (format != ZPixmap) - goto bail; - x += drawable->x; y += drawable->y; box.x1 = x; @@ -84,6 +78,165 @@ bail: return FALSE; } +static const char vs_vars_put_bitmap[] = + "attribute vec4 primitive;\n" + "attribute vec2 source;\n" + "varying vec2 image_pos;\n"; + +static const char vs_exec_put_bitmap[] = + " vec2 pos = primitive.zw * vec2(gl_VertexID&1, (gl_VertexID&2)>>1);\n" + GLAMOR_POS(gl_Position, (primitive.xy + pos)) + " image_pos = source + pos;\n"; + +static const char fs_vars_put_bitmap[] = + "varying vec2 image_pos;\n"; + +static Bool +glamor_put_bitmap_use(PixmapPtr pixmap, GCPtr gc, glamor_program *prog, void *arg) +{ + if (!glamor_set_solid(pixmap, gc, TRUE, prog->fg_uniform)) + return FALSE; + glamor_set_color(pixmap, gc->bgPixel, prog->bg_uniform); + return TRUE; +} + +static const char fs_exec_put_bitmap[] = + " ivec2 itile_texture = ivec2(image_pos);\n" + " uint x = uint(itile_texture.x & 7);\n" + " itile_texture.x >>= 3;\n" + " uint texel = texelFetch(font, itile_texture, 0).x;\n" + " uint bit = (texel >> x) & uint(1);\n" + " if (bit == uint(0))\n" + " gl_FragColor = bg;\n" + " else\n" + " gl_FragColor = fg;\n"; + +const glamor_facet glamor_facet_put_bitmap = { + .name = "put_bitmap", + .version = 130, + .vs_vars = vs_vars_put_bitmap, + .vs_exec = vs_exec_put_bitmap, + .fs_vars = fs_vars_put_bitmap, + .fs_exec = fs_exec_put_bitmap, + .locations = glamor_program_location_fg | glamor_program_location_bg | glamor_program_location_font, + .source_name = "source", + .use = glamor_put_bitmap_use, +}; + +/* + * Use a program like the terminal emulator text program to fetch single + * bits from the source image and expand them to full pixel values. + */ +static Bool +glamor_put_image_xybitmap_gl(DrawablePtr drawable, GCPtr gc, int x, int y, + int w, int h, int leftPad, char *bits) +{ + ScreenPtr screen = drawable->pScreen; + glamor_screen_private *glamor_priv = glamor_get_screen_private(screen); + PixmapPtr pixmap = glamor_get_drawable_pixmap(drawable); + glamor_pixmap_private *pixmap_priv = glamor_get_pixmap_private(pixmap); + uint32_t byte_stride = BitmapBytePad(w + leftPad); + GLuint texture_id; + glamor_program *prog; + char *vbo_offset; + GLshort *v; + int box_index; + int off_x, off_y; + Bool ret = FALSE; + + if (!GLAMOR_PIXMAP_PRIV_HAS_FBO(pixmap_priv)) + return FALSE; + + glamor_make_current(glamor_priv); + + prog = &glamor_priv->put_bitmap_prog; + + if (prog->failed) + goto bail; + + if (!prog->prog) { + if (!glamor_build_program(screen, prog, &glamor_facet_put_bitmap, NULL, NULL, NULL)) + goto bail; + } + + if (!glamor_use_program(pixmap, gc, prog, NULL)) + goto bail; + + glGenTextures(1, &texture_id); + glActiveTexture(GL_TEXTURE1); + glBindTexture(GL_TEXTURE_2D, texture_id); + + glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST); + glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST); + + glPixelStorei(GL_UNPACK_ALIGNMENT, 1); + glamor_priv->suppress_gl_out_of_memory_logging = true; + glTexImage2D(GL_TEXTURE_2D, 0, GL_R8UI, byte_stride, h, + 0, GL_RED_INTEGER, GL_UNSIGNED_BYTE, bits); + glamor_priv->suppress_gl_out_of_memory_logging = false; + if (glGetError() == GL_OUT_OF_MEMORY) + goto bail; + + glUniform1i(prog->font_uniform, 1); + + /* Set up the vertex buffers for the font and destination */ + + v = glamor_get_vbo_space(drawable->pScreen, (6 * sizeof (GLshort)), &vbo_offset); + + glEnableVertexAttribArray(GLAMOR_VERTEX_POS); + glVertexAttribDivisor(GLAMOR_VERTEX_POS, 1); + glVertexAttribPointer(GLAMOR_VERTEX_POS, 4, GL_SHORT, GL_FALSE, + 6 * sizeof (GLshort), vbo_offset); + + glEnableVertexAttribArray(GLAMOR_VERTEX_SOURCE); + glVertexAttribDivisor(GLAMOR_VERTEX_SOURCE, 1); + glVertexAttribPointer(GLAMOR_VERTEX_SOURCE, 2, GL_SHORT, GL_FALSE, + 6 * sizeof (GLshort), vbo_offset + 4 * sizeof (GLshort)); + + v[0] = x; + v[1] = y; + v[2] = w; + v[3] = h; + v[4] = leftPad; + v[5] = 0; + + glamor_put_vbo_space(drawable->pScreen); + glEnable(GL_SCISSOR_TEST); + + glamor_pixmap_loop(pixmap_priv, box_index) { + BoxPtr box = RegionRects(gc->pCompositeClip); + int nbox = RegionNumRects(gc->pCompositeClip); + + glamor_set_destination_drawable(drawable, box_index, TRUE, FALSE, + prog->matrix_uniform, + &off_x, &off_y); + + /* Run over the clip list, drawing the glyphs + * in each box + */ + + while (nbox--) { + glScissor(box->x1 + off_x, + box->y1 + off_y, + box->x2 - box->x1, + box->y2 - box->y1); + box++; + glDrawArraysInstanced(GL_TRIANGLE_STRIP, 0, 4, 1); + } + } + glDisable(GL_SCISSOR_TEST); + + glVertexAttribDivisor(GLAMOR_VERTEX_SOURCE, 0); + glDisableVertexAttribArray(GLAMOR_VERTEX_SOURCE); + glVertexAttribDivisor(GLAMOR_VERTEX_POS, 0); + glDisableVertexAttribArray(GLAMOR_VERTEX_POS); + + ret = TRUE; +bail: + glDeleteTextures(1, &texture_id); + return ret; +} + static void glamor_put_image_bail(DrawablePtr drawable, GCPtr gc, int depth, int x, int y, int w, int h, int leftPad, int format, char *bits) @@ -97,8 +250,18 @@ void glamor_put_image(DrawablePtr drawable, GCPtr gc, int depth, int x, int y, int w, int h, int leftPad, int format, char *bits) { - if (glamor_put_image_gl(drawable, gc, depth, x, y, w, h, leftPad, format, bits)) - return; + switch (format) { + case ZPixmap: + if (glamor_put_image_zpixmap_gl(drawable, gc, depth, x, y, w, h, bits)) + return; + break; + case XYPixmap: + break; + case XYBitmap: + if (glamor_put_image_xybitmap_gl(drawable, gc, x, y, w, h, leftPad, bits)) + return; + break; + } glamor_put_image_bail(drawable, gc, depth, x, y, w, h, leftPad, format, bits); } diff --git a/glamor/glamor_priv.h b/glamor/glamor_priv.h index 27f9552..bcbb7a7 100644 --- a/glamor/glamor_priv.h +++ b/glamor/glamor_priv.h @@ -227,6 +227,9 @@ typedef struct glamor_screen_private { glamor_program copy_area_prog; glamor_program copy_plane_prog; + /* glamor image shaders */ + glamor_program put_bitmap_prog; + /* glamor line shader */ glamor_program_fill poly_line_program; -- 2.9.3 From keithp at keithp.com Sat Oct 1 05:44:01 2016 From: keithp at keithp.com (Keith Packard) Date: Fri, 30 Sep 2016 22:44:01 -0700 Subject: [PATCH xserver 2/3] glamor: Accelerate up XY pixmap putimage a little In-Reply-To: <20161001054402.31210-1-keithp@keithp.com> References: <20161001054402.31210-1-keithp@keithp.com> Message-ID: <20161001054402.31210-3-keithp@keithp.com> Convert the image to a temporary CPU pixmap, then copy that to the destination. This is a lot faster for small images, and not any slower for large images. Signed-off-by: Keith Packard --- glamor/glamor_image.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) diff --git a/glamor/glamor_image.c b/glamor/glamor_image.c index 798277b..47968e2 100644 --- a/glamor/glamor_image.c +++ b/glamor/glamor_image.c @@ -237,6 +237,52 @@ bail: return ret; } +/* + * Create a temporary in-memory pixmap, put the image there then copy + * to the destination. + */ + +static Bool +glamor_put_image_xy_gl(DrawablePtr drawable, GCPtr gc, int depth, int x, int y, + int w, int h, int leftPad, int format, char *bits) +{ + PixmapPtr pixmap = glamor_get_drawable_pixmap(drawable); + glamor_pixmap_private *pixmap_priv = glamor_get_pixmap_private(pixmap); + ScreenPtr screen = drawable->pScreen; + PixmapPtr temp_pixmap = NULL; + DrawablePtr temp_drawable; + GCPtr temp_gc; + Bool ret = FALSE; + ChangeGCVal gcv[3]; + + if (!GLAMOR_PIXMAP_PRIV_HAS_FBO(pixmap_priv)) + return FALSE; + + temp_pixmap = (*screen->CreatePixmap)(screen, w, h, drawable->depth, GLAMOR_CREATE_PIXMAP_CPU); + if (!temp_pixmap) + goto bail; + temp_drawable = &temp_pixmap->drawable; + temp_gc = GetScratchGC(temp_drawable->depth, screen); + if (!temp_gc) + goto bail_pixmap; + + /* copy mode for the first plane to clear all of the other bits */ + gcv[0].val = GXcopy; + gcv[1].val = gc->fgPixel; + gcv[2].val = gc->bgPixel; + ChangeGC(NullClient, temp_gc, GCFunction|GCForeground|GCBackground, gcv); + ValidateGC(temp_drawable, temp_gc); + (*temp_gc->ops->PutImage)(temp_drawable, temp_gc, depth, 0, 0, w, h, leftPad, format, bits); + (*gc->ops->CopyArea)(&temp_pixmap->drawable, drawable, gc, 0, 0, w, h, x, y); + ret = TRUE; + + FreeScratchGC(temp_gc); +bail_pixmap: + (*screen->DestroyPixmap)(temp_pixmap); +bail: + return ret; +} + static void glamor_put_image_bail(DrawablePtr drawable, GCPtr gc, int depth, int x, int y, int w, int h, int leftPad, int format, char *bits) @@ -256,6 +302,8 @@ glamor_put_image(DrawablePtr drawable, GCPtr gc, int depth, int x, int y, return; break; case XYPixmap: + if (glamor_put_image_xy_gl(drawable, gc, depth, x, y, w, h, leftPad, format, bits)) + return; break; case XYBitmap: if (glamor_put_image_xybitmap_gl(drawable, gc, x, y, w, h, leftPad, bits)) -- 2.9.3 From keithp at keithp.com Sat Oct 1 05:44:02 2016 From: keithp at keithp.com (Keith Packard) Date: Fri, 30 Sep 2016 22:44:02 -0700 Subject: [PATCH xserver 3/3] glamor: Switch XY bitmap putimage function for small images In-Reply-To: <20161001054402.31210-1-keithp@keithp.com> References: <20161001054402.31210-1-keithp@keithp.com> Message-ID: <20161001054402.31210-4-keithp@keithp.com> Use the glamor_put_image_xy_gl for small images as that is quite a bit faster. Signed-off-by: Keith Packard --- glamor/glamor_image.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/glamor/glamor_image.c b/glamor/glamor_image.c index 47968e2..6a70e6a 100644 --- a/glamor/glamor_image.c +++ b/glamor/glamor_image.c @@ -306,8 +306,13 @@ glamor_put_image(DrawablePtr drawable, GCPtr gc, int depth, int x, int y, return; break; case XYBitmap: - if (glamor_put_image_xybitmap_gl(drawable, gc, x, y, w, h, leftPad, bits)) - return; + if (w * h >= 100 * 100) { + if (glamor_put_image_xybitmap_gl(drawable, gc, x, y, w, h, leftPad, bits)) + return; + } else { + if (glamor_put_image_xy_gl(drawable, gc, depth, x, y, w, h, leftPad, format, bits)) + return; + } break; } glamor_put_image_bail(drawable, gc, depth, x, y, w, h, leftPad, format, bits); -- 2.9.3 From hdegoede at redhat.com Sat Oct 1 10:01:42 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Sat, 1 Oct 2016 12:01:42 +0200 Subject: [PATCH xserver 1/3] xfree86: Immediately handle failure to set HW cursor, v5 In-Reply-To: <20160930155553.26858-1-michael.thayer@oracle.com> References: <20160930155553.26858-1-michael.thayer@oracle.com> Message-ID: Hi, On 30-09-16 17:55, Michael Thayer wrote: > Based on v4 by Alexandre Courbot > > There is currently no reliable way to report failure to set a HW > cursor. Still such failures can happen if e.g. the MODE_CURSOR DRM > ioctl fails (which currently happens at least with modesetting on Tegra > for format incompatibility reasons). > > As failures are currently handled by setting the HW cursor size to > (0,0), the fallback to SW cursor will not happen until the next time the > cursor changes and xf86CursorSetCursor() is called again. In the > meantime, the cursor will be invisible to the user. > > This patch addresses that by adding _xf86CrtcFuncs::set_cursor_check and > _xf86CursorInfoRec::ShowCursorCheck hook variants that return booleans. > This allows to propagate errors up to xf86CursorSetCursor(), which can > then fall back to using the SW cursor immediately. > > v5: Updated the patch to apply to current git HEAD, split up into two > patches (server and modesetting driver) and adjusted the code slightly > to match surrounding code. I also removed the new exported function > ShowCursorCheck(), as instead just changing ShowCursor() to return Bool > should not affect its current callers. > > Signed-off-by: Michael Thayer Series looks good to me and is: Reviewed-by: Hans de Goede As discussed this will need to wait till we start the 1.20 cycle before it can be merged (it contains a video driver ABI change) Regards, Hans > --- > hw/xfree86/modes/xf86Crtc.h | 4 +++- > hw/xfree86/modes/xf86Cursors.c | 40 ++++++++++++++++++++++++++++++---------- > hw/xfree86/ramdac/xf86Cursor.h | 16 ++++++++++++++++ > hw/xfree86/ramdac/xf86HWCurs.c | 8 ++++---- > 4 files changed, 53 insertions(+), 15 deletions(-) > > diff --git a/hw/xfree86/modes/xf86Crtc.h b/hw/xfree86/modes/xf86Crtc.h > index 14ba9d7..215eb2a 100644 > --- a/hw/xfree86/modes/xf86Crtc.h > +++ b/hw/xfree86/modes/xf86Crtc.h > @@ -195,6 +195,8 @@ typedef struct _xf86CrtcFuncs { > */ > void > (*show_cursor) (xf86CrtcPtr crtc); > + Bool > + (*show_cursor_check) (xf86CrtcPtr crtc); > > /** > * Hide cursor > @@ -993,7 +995,7 @@ static _X_INLINE _X_DEPRECATED void xf86_reload_cursors(ScreenPtr screen) {} > /** > * Called from EnterVT to turn the cursors back on > */ > -extern _X_EXPORT void > +extern _X_EXPORT Bool > xf86_show_cursors(ScrnInfoPtr scrn); > > /** > diff --git a/hw/xfree86/modes/xf86Cursors.c b/hw/xfree86/modes/xf86Cursors.c > index 1bc2b27..9543eed 100644 > --- a/hw/xfree86/modes/xf86Cursors.c > +++ b/hw/xfree86/modes/xf86Cursors.c > @@ -210,9 +210,15 @@ set_bit(CARD8 *image, xf86CursorInfoPtr cursor_info, int x, int y, Bool mask) > > /* > * Wrappers to deal with API compatibility with drivers that don't expose > - * load_cursor_*_check > + * *_cursor_*_check > */ > static inline Bool > +xf86_driver_has_show_cursor(xf86CrtcPtr crtc) > +{ > + return crtc->funcs->show_cursor_check || crtc->funcs->show_cursor; > +} > + > +static inline Bool > xf86_driver_has_load_cursor_image(xf86CrtcPtr crtc) > { > return crtc->funcs->load_cursor_image_check || crtc->funcs->load_cursor_image; > @@ -225,6 +231,15 @@ xf86_driver_has_load_cursor_argb(xf86CrtcPtr crtc) > } > > static inline Bool > +xf86_driver_show_cursor(xf86CrtcPtr crtc) > +{ > + if (crtc->funcs->show_cursor_check) > + return crtc->funcs->show_cursor_check(crtc); > + crtc->funcs->show_cursor(crtc); > + return TRUE; > +} > + > +static inline Bool > xf86_driver_load_cursor_image(xf86CrtcPtr crtc, CARD8 *cursor_image) > { > if (crtc->funcs->load_cursor_image_check) > @@ -333,16 +348,19 @@ xf86_hide_cursors(ScrnInfoPtr scrn) > } > } > > -static void > +static Bool > xf86_crtc_show_cursor(xf86CrtcPtr crtc) > { > - if (!crtc->cursor_shown && crtc->cursor_in_range) { > - crtc->funcs->show_cursor(crtc); > - crtc->cursor_shown = TRUE; > - } > + if (!crtc->cursor_in_range) > + return TRUE; > + > + if (!crtc->cursor_shown) > + crtc->cursor_shown = xf86_driver_show_cursor(crtc); > + > + return crtc->cursor_shown; > } > > -void > +Bool > xf86_show_cursors(ScrnInfoPtr scrn) > { > xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn); > @@ -352,9 +370,11 @@ xf86_show_cursors(ScrnInfoPtr scrn) > for (c = 0; c < xf86_config->num_crtc; c++) { > xf86CrtcPtr crtc = xf86_config->crtc[c]; > > - if (crtc->enabled) > - xf86_crtc_show_cursor(crtc); > + if (crtc->enabled && !xf86_crtc_show_cursor(crtc)) > + return FALSE; > } > + > + return TRUE; > } > > static void > @@ -653,7 +673,7 @@ xf86_cursors_init(ScreenPtr screen, int max_width, int max_height, int flags) > cursor_info->SetCursorPosition = xf86_set_cursor_position; > cursor_info->LoadCursorImageCheck = xf86_load_cursor_image; > cursor_info->HideCursor = xf86_hide_cursors; > - cursor_info->ShowCursor = xf86_show_cursors; > + cursor_info->ShowCursorCheck = xf86_show_cursors; > cursor_info->UseHWCursor = xf86_use_hw_cursor; > if (flags & HARDWARE_CURSOR_ARGB) { > cursor_info->UseHWCursorARGB = xf86_use_hw_cursor_argb; > diff --git a/hw/xfree86/ramdac/xf86Cursor.h b/hw/xfree86/ramdac/xf86Cursor.h > index 320ec0c..11a03b6 100644 > --- a/hw/xfree86/ramdac/xf86Cursor.h > +++ b/hw/xfree86/ramdac/xf86Cursor.h > @@ -16,6 +16,7 @@ typedef struct _xf86CursorInfoRec { > Bool (*LoadCursorImageCheck) (ScrnInfoPtr pScrn, unsigned char *bits); > void (*HideCursor) (ScrnInfoPtr pScrn); > void (*ShowCursor) (ScrnInfoPtr pScrn); > + Bool (*ShowCursorCheck) (ScrnInfoPtr pScrn); > unsigned char *(*RealizeCursor) (struct _xf86CursorInfoRec *, CursorPtr); > Bool (*UseHWCursor) (ScreenPtr, CursorPtr); > > @@ -41,6 +42,21 @@ xf86DriverLoadCursorImage(xf86CursorInfoPtr infoPtr, unsigned char *bits) > } > > static inline Bool > +xf86DriverHasShowCursor(xf86CursorInfoPtr infoPtr) > +{ > + return infoPtr->ShowCursorCheck || infoPtr->ShowCursor; > +} > + > +static inline Bool > +xf86DriverShowCursor(xf86CursorInfoPtr infoPtr) > +{ > + if(infoPtr->ShowCursorCheck) > + return infoPtr->ShowCursorCheck(infoPtr->pScrn); > + infoPtr->ShowCursor(infoPtr->pScrn); > + return TRUE; > +} > + > +static inline Bool > xf86DriverHasLoadCursorARGB(xf86CursorInfoPtr infoPtr) > { > return infoPtr->LoadCursorARGBCheck || infoPtr->LoadCursorARGB; > diff --git a/hw/xfree86/ramdac/xf86HWCurs.c b/hw/xfree86/ramdac/xf86HWCurs.c > index e8966ed..bd287fc 100644 > --- a/hw/xfree86/ramdac/xf86HWCurs.c > +++ b/hw/xfree86/ramdac/xf86HWCurs.c > @@ -90,7 +90,8 @@ xf86InitHardwareCursor(ScreenPtr pScreen, xf86CursorInfoPtr infoPtr) > if (!infoPtr->SetCursorPosition || > !xf86DriverHasLoadCursorImage(infoPtr) || > !infoPtr->HideCursor || > - !infoPtr->ShowCursor || !infoPtr->SetCursorColors) > + !xf86DriverHasShowCursor(infoPtr) || > + !infoPtr->SetCursorColors) > return FALSE; > > if (infoPtr->RealizeCursor) { > @@ -204,8 +205,7 @@ xf86ScreenSetCursor(ScreenPtr pScreen, CursorPtr pCurs, int x, int y) > > (*infoPtr->SetCursorPosition) (infoPtr->pScrn, x, y); > > - (*infoPtr->ShowCursor) (infoPtr->pScrn); > - return TRUE; > + return xf86DriverShowCursor(infoPtr); > } > > Bool > @@ -252,7 +252,7 @@ xf86SetTransparentCursor(ScreenPtr pScreen) > xf86DriverLoadCursorImage (infoPtr, > ScreenPriv->transparentData); > > - (*infoPtr->ShowCursor) (infoPtr->pScrn); > + xf86DriverShowCursor(infoPtr); > } > > static void > From xorg at esoterek.com Sat Oct 1 11:59:29 2016 From: xorg at esoterek.com (Bob Terek) Date: Sat, 1 Oct 2016 01:59:29 -1000 Subject: [PATCH] remove dead code in dummy driver In-Reply-To: <688fe323-f6f7-70d7-6284-ca5d57d1581a@nagafix.co.uk> References: <1474353280-14806-1-git-send-email-antoine@nagafix.co.uk> <20160920090719.GA3075@imgtec.com> <76d7617b-beee-4c59-c31b-625003047159@esoterek.com> <7198c8c4-ed44-550f-def3-fc6d621bdcf1@nvidia.com> <24493836-adad-7c9d-69a6-a8267c18d4c2@esoterek.com> <688fe323-f6f7-70d7-6284-ca5d57d1581a@nagafix.co.uk> Message-ID: <7cb9ae67-4934-1e8c-01b6-86f1676775a0@esoterek.com> On 09/27/2016 12:22 AM, Antoine Martin wrote: > It think it probably makes sense to apply the cleanup patches first, to > remove code before adding some more? I had planned to send them all at once, but you're right, it is a good idea to get the cleanups in separately. My problem has been that my day job has been getting in the way so far, and now I'm leaving for a 3 week vacation in a few hours. I'd be happy to address the cleanups around the 24th, if that is ok, and my proposed change shortly thereafter. I'm sure Aaron has better things to do than deal with dummy. Cheers, Bob Terek From hdegoede at redhat.com Mon Oct 3 15:59:33 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Mon, 3 Oct 2016 17:59:33 +0200 Subject: PATCH: Add xorg-xserver 1.19 support to tigervnc Message-ID: Hello tigervnc devs, As part of updating Fedora to xserver 1.19 I've written a tiger vnc patch to make tigervnc work with xserver 1.19. Since xserver 1.19 switches from select to poll the changes are non trivial and require some #ifdef-s. The new code is a lot cleaner then the old code though, which is good. And with server 1.19 the os/WaitFor.c changes are no longer necessary. Attached is a tigervnc-1.7.0 patch, as well as a patch to apply to the xserver sources to patch in the tigervnc ext and hw/vnc dir into the buidlsys. Regards, Hans -------------- next part -------------- A non-text attachment was scrubbed... Name: tigervnc-1.7.0-xserver119-support.patch Type: text/x-patch Size: 11708 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tigervnc-xserver119.patch Type: text/x-patch Size: 3681 bytes Desc: not available URL: From keithp at keithp.com Mon Oct 3 16:44:32 2016 From: keithp at keithp.com (Keith Packard) Date: Mon, 03 Oct 2016 09:44:32 -0700 Subject: PATCH: Add xorg-xserver 1.19 support to tigervnc In-Reply-To: References: Message-ID: <86oa315qmn.fsf@hiro.keithp.com> Hans de Goede writes: > +void XserverDesktop::handleSocketFd(int fd, int xevents) > +{ > + std::list sockets; > + std::list::iterator i; > + SocketServer *fd_server = NULL; > + bool is_http = false; > + > + server->getSockets(&sockets); > + for (i = sockets.begin(); i != sockets.end(); i++) { > + if ((*i)->getFd() == fd) { > + fd_server = server; > + break; > + } > + } Seems like it might be nice to avoid this loop by making this a method on fd_server instead of the top-level object? > + if (httpServer && !fd_server) { > + httpServer->getSockets(&sockets); > + for (i = sockets.begin(); i != sockets.end(); i++) { > + if ((*i)->getFd() == fd) { > + fd_server = httpServer; > + is_http = true; > + break; > + } > + } > + } > + if (!fd_server) { > + vlog.error("XserverDesktop::handleSocketFd: Error cannot find fd"); > + return; > + } > + > + if (xevents & X_NOTIFY_READ) > + fd_server->processSocketReadEvent(*i); > + > + if (xevents & X_NOTIFY_WRITE) > + fd_server->processSocketWriteEvent(*i); > + > + if ((*i)->isShutdown()) { > + vlog.debug("%sclient gone, sock %d", is_http ? "http " : "", fd); > + RemoveNotifyFd(fd); > + fd_server->removeSocket(*i); > + if (!is_http) > + vncClientGone(fd); > + delete (*i); > + } > +} > + > +void XserverDesktop::blockHandler(int* timeout) > +{ > + // We don't have a good callback for when we can init input devices[1], > + // so we abuse the fact that this routine will be called first thing > + // once the dix is done initialising. > + // [1] Technically Xvnc has InitInput(), but libvnc.so has nothing. > + vncInitInputDevice(); > + > + int nextTimeout = server->checkTimeouts(); > + if (nextTimeout > 0 && (*timeout == -1 || nextTimeout < *timeout)) > + *timeout = nextTimeout; > +} > + > +#else > + > void XserverDesktop::readBlockHandler(fd_set* fds, struct timeval ** timeout) > { > // We don't have a good callback for when we can init input devices[1], > @@ -600,10 +738,15 @@ > } > } > > +#endif > + > void XserverDesktop::addClient(Socket* sock, bool reverse) > { > vlog.debug("new client, sock %d reverse %d",sock->getFd(),reverse); > server->addSocket(sock, reverse); > +#if XORG >= 119 > + SetNotifyFd(sock->getFd(), HandleSocketFd, X_NOTIFY_READ, this); > +#endif > } > > void XserverDesktop::disconnectClients() > diff -ur tigervnc-1.7.0/unix/xserver/hw/vnc/XserverDesktop.h tigervnc-1.7.0.new/unix/xserver/hw/vnc/XserverDesktop.h > --- tigervnc-1.7.0/unix/xserver/hw/vnc/XserverDesktop.h 2016-09-08 12:31:18.000000000 +0200 > +++ tigervnc-1.7.0.new/unix/xserver/hw/vnc/XserverDesktop.h 2016-10-03 13:58:58.434844924 +0200 > @@ -38,6 +38,7 @@ > #include > #include > #include "Input.h" > +#include "xorg-version.h" > > namespace rfb { > class VNCServerST; > @@ -69,10 +70,16 @@ > const unsigned char *rgbaData); > void add_changed(const rfb::Region ®ion); > void add_copied(const rfb::Region &dest, const rfb::Point &delta); > +#if XORG >= 119 > + void handleListenFd(int fd); > + void handleSocketFd(int fd, int xevents); > + void blockHandler(int* timeout); > +#else > void readBlockHandler(fd_set* fds, struct timeval ** timeout); > void readWakeupHandler(fd_set* fds, int nfds); > void writeBlockHandler(fd_set* fds, struct timeval ** timeout); > void writeWakeupHandler(fd_set* fds, int nfds); > +#endif > void addClient(network::Socket* sock, bool reverse); > void disconnectClients(); > > diff -ur tigervnc-1.7.0/unix/xserver/hw/vnc/vncBlockHandler.c tigervnc-1.7.0.new/unix/xserver/hw/vnc/vncBlockHandler.c > --- tigervnc-1.7.0/unix/xserver/hw/vnc/vncBlockHandler.c 2016-09-08 12:31:18.000000000 +0200 > +++ tigervnc-1.7.0.new/unix/xserver/hw/vnc/vncBlockHandler.c 2016-10-03 14:06:30.461357037 +0200 > @@ -30,6 +30,23 @@ > -- -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From eric.engestrom at imgtec.com Mon Oct 3 16:57:51 2016 From: eric.engestrom at imgtec.com (Eric Engestrom) Date: Mon, 3 Oct 2016 17:57:51 +0100 Subject: PATCH: Add xorg-xserver 1.19 support to tigervnc In-Reply-To: References: Message-ID: <20161003165751.GU16844@imgtec.com> On Mon, Oct 03, 2016 at 05:59:33PM +0200, Hans de Goede wrote: > Hello tigervnc devs, > > As part of updating Fedora to xserver 1.19 I've written > a tiger vnc patch to make tigervnc work with xserver 1.19. > > Since xserver 1.19 switches from select to poll the changes > are non trivial and require some #ifdef-s. The new code is > a lot cleaner then the old code though, which is good. > > And with server 1.19 the os/WaitFor.c changes are no longer > necessary. > > Attached is a tigervnc-1.7.0 patch, as well as a patch > to apply to the xserver sources to patch in the tigervnc > ext and hw/vnc dir into the buidlsys. > > Regards, > > Hans [snip] > --- tigervnc-1.7.0/unix/xserver/hw/vnc/xorg-version.h 2016-09-08 12:31:18.000000000 +0200 > +++ tigervnc-1.7.0.new/unix/xserver/hw/vnc/xorg-version.h 2016-10-03 10:27:53.721116357 +0200 > @@ -50,8 +50,10 @@ > #define XORG 117 > #elif XORG_VERSION_CURRENT < ((1 * 10000000) + (18 * 100000) + (99 * 1000)) > #define XORG 118 > +#elif XORG_VERSION_CURRENT < ((1 * 10000000) + (19 * 100000) + (99 * 1000)) > +#define XORG 119 > #else > -#error "X.Org newer than 1.18 is not supported" > +#error "X.Org newer than 1.18 is not supported" This seems like a git bug? (Not the first time I've seen this in a patch) There doesn't seem to be a difference here, but it's obvious the change was means to be s/18/19/. This will just need to be done manually while applying this patch :) From eric at anholt.net Mon Oct 3 16:58:10 2016 From: eric at anholt.net (Eric Anholt) Date: Mon, 03 Oct 2016 09:58:10 -0700 Subject: [PATCH xserver 3/3] glamor: Switch XY bitmap putimage function for small images In-Reply-To: <20161001054402.31210-4-keithp@keithp.com> References: <20161001054402.31210-1-keithp@keithp.com> <20161001054402.31210-4-keithp@keithp.com> Message-ID: <87mvil1ial.fsf@eliezer.anholt.net> Keith Packard writes: > Use the glamor_put_image_xy_gl for small images as that is quite a bit > faster. I'd like to see some performance data in the commit messages. With that, this will all be r-b. Thanks! I'm hoping that once we do VAOs that will greatly improve our performance for the 10x10 cases (and, related, our performance for small numbers of primitives per call, which is to say the common case). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From ajax at redhat.com Mon Oct 3 18:59:09 2016 From: ajax at redhat.com (Adam Jackson) Date: Mon, 03 Oct 2016 14:59:09 -0400 Subject: [PATCH xserver 2/3] glamor: Accelerate up XY pixmap putimage a little In-Reply-To: <20161001054402.31210-3-keithp@keithp.com> References: <20161001054402.31210-1-keithp@keithp.com> <20161001054402.31210-3-keithp@keithp.com> Message-ID: <1475521149.23582.2.camel@redhat.com> On Fri, 2016-09-30 at 22:44 -0700, Keith Packard wrote: > +    /* copy mode for the first plane to clear all of the other bits */ > +    gcv[0].val = GXcopy; > +    gcv[1].val = gc->fgPixel; > +    gcv[2].val = gc->bgPixel; > +    ChangeGC(NullClient, temp_gc, GCFunction|GCForeground|GCBackground, gcv); You don't need to set GCFunction here, the scratch gc already has GXcopy set. You _do_ need to copy GCPlanemask from the source gc, because for XYPixmap PutImage that determines how many planes of data were given; if you let it stay as FB_ALLONES when it should only be, say, 0x3, you'll read in 30 planes of garbage. - ajax From keithp at keithp.com Mon Oct 3 19:26:20 2016 From: keithp at keithp.com (Keith Packard) Date: Mon, 03 Oct 2016 12:26:20 -0700 Subject: [PATCH xserver 2/3] glamor: Accelerate up XY pixmap putimage a little In-Reply-To: <1475521149.23582.2.camel@redhat.com> References: <20161001054402.31210-1-keithp@keithp.com> <20161001054402.31210-3-keithp@keithp.com> <1475521149.23582.2.camel@redhat.com> Message-ID: <86int95j4z.fsf@hiro.keithp.com> Adam Jackson writes: > On Fri, 2016-09-30 at 22:44 -0700, Keith Packard wrote: > >> +    /* copy mode for the first plane to clear all of the other bits */ >> +    gcv[0].val = GXcopy; >> +    gcv[1].val = gc->fgPixel; >> +    gcv[2].val = gc->bgPixel; >> +    ChangeGC(NullClient, temp_gc, GCFunction|GCForeground|GCBackground, gcv); > > You don't need to set GCFunction here, the scratch gc already has > GXcopy set. Thanks. > You _do_ need to copy GCPlanemask from the source gc, because for > XYPixmap PutImage that determines how many planes of data were given; > if you let it stay as FB_ALLONES when it should only be, say, 0x3, > you'll read in 30 planes of garbage. mi says no, fb says yes. I need to read the Xlib code (and the spec). -- -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From keithp at keithp.com Mon Oct 3 19:28:01 2016 From: keithp at keithp.com (Keith Packard) Date: Mon, 03 Oct 2016 12:28:01 -0700 Subject: [PATCH xserver 3/3] glamor: Switch XY bitmap putimage function for small images In-Reply-To: <87mvil1ial.fsf@eliezer.anholt.net> References: <20161001054402.31210-1-keithp@keithp.com> <20161001054402.31210-4-keithp@keithp.com> <87mvil1ial.fsf@eliezer.anholt.net> Message-ID: <86fuod5j26.fsf@hiro.keithp.com> Eric Anholt writes: > I'd like to see some performance data in the commit messages. With > that, this will all be r-b. Thanks! Sorry, the perf data was just in the 0/3 leading message. I'll move it down into the individual messages. > I'm hoping that once we do VAOs that will greatly improve our > performance for the 10x10 cases (and, related, our performance for small > numbers of primitives per call, which is to say the common case). Yeah, I sure hope so. I'll work with Adam to clean up the planemask stuff and conflict between fb and mi over XY format pixmaps, then apply your RB to the relevant portions and send out a new series. -- -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From ajax at redhat.com Mon Oct 3 20:03:27 2016 From: ajax at redhat.com (Adam Jackson) Date: Mon, 03 Oct 2016 16:03:27 -0400 Subject: [PATCH xserver 0/3] glamor: Accelerate XY format images In-Reply-To: <20161001054402.31210-1-keithp@keithp.com> References: <20161001054402.31210-1-keithp@keithp.com> Message-ID: <1475525007.23582.4.camel@redhat.com> On Fri, 2016-09-30 at 22:43 -0700, Keith Packard wrote: >        1                 2                 Operation > ------------   -------------------------   ------------------------- >      10900.0        99900.0 (     9.165)   PutImage XY 10x10 square  >       1740.0         2160.0 (     1.241)   PutImage XY 100x100 square  >         83.2           90.4 (     1.087)   PutImage XY 500x500 square  90 ops per second is still shameful. No blit should take 11ms. >      11800.0       351000.0 (    29.746)   PutImage XYBitmap 10x10 square  >       6280.0        81600.0 (    12.994)   PutImage XYBitmap 100x100 square  >        752.0        14300.0 (    19.016)   PutImage XYBitmap 500x500 square  Where does one get a copy of x11perf that has this test? Also I assume this is measuring before the whole series vs after. Would be nice to see the impact between 2/3 and 3/3 too. > I'd like to know why the GPU expansion version has so much GL > overhead; it "should" be faster for everything as it uploads a lot > less data to the GPU. On i965, at least, scissor updates are an appreciable amount of gl driver time, so small ops get punished. > I'd also like to try writing an XYPixmap that > did all of the plane merging in the fragment shader. That "should" be > faster for large images than merging on the CPU. With a trivial planemask, sure. With an interesting planemask you either need a bitwise write mask to the output fragment (and I'm not sure glsl 1.30 gives you that) or you need one of the fb fetch extensions. - ajax From keithp at keithp.com Mon Oct 3 22:18:02 2016 From: keithp at keithp.com (Keith Packard) Date: Mon, 03 Oct 2016 15:18:02 -0700 Subject: [PATCH xserver 0/3] glamor: Accelerate XY format images In-Reply-To: <1475525007.23582.4.camel@redhat.com> References: <20161001054402.31210-1-keithp@keithp.com> <1475525007.23582.4.camel@redhat.com> Message-ID: <867f9p5b6t.fsf@hiro.keithp.com> Adam Jackson writes: > On Fri, 2016-09-30 at 22:43 -0700, Keith Packard wrote: > >>        1                 2                 Operation >> ------------   -------------------------   ------------------------- >>      10900.0        99900.0 (     9.165)   PutImage XY 10x10 square  >>       1740.0         2160.0 (     1.241)   PutImage XY 100x100 square  >>         83.2           90.4 (     1.087)   PutImage XY 500x500 square  > > 90 ops per second is still shameful. No blit should take 11ms. Agreed. It's all in fb, which just sucks at XYpixmaps. So many instructions per pixel... > Where does one get a copy of x11perf that has this test? Sorry, git://people.freedesktop.org/~keithp/x11perf.git > Also I assume this is measuring before the whole series vs after. Would > be nice to see the impact between 2/3 and 3/3 too. Yeah, I can run measurements per patch. > On i965, at least, scissor updates are an appreciable amount of gl > driver time, so small ops get punished. Sounds like only changing them when necessary would be a good idea then. I think we should assume that GL at least doesn't mind having state set to the same value repeatedly, but then we should set these common state values at the top of each rendering function so we weren't resetting them at the bottom of any of them. > With a trivial planemask, sure. With an interesting planemask you > either need a bitwise write mask to the output fragment (and I'm not > sure glsl 1.30 gives you that) or you need one of the fb fetch > extensions. A non-trivial planemask is just going to suck; we can't draw that without serious pain anyways. Fallbacks are easier. -- -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From keithp at keithp.com Mon Oct 3 22:34:55 2016 From: keithp at keithp.com (Keith Packard) Date: Mon, 03 Oct 2016 15:34:55 -0700 Subject: [PATCH xserver 2/3] glamor: Accelerate up XY pixmap putimage a little In-Reply-To: <1475521149.23582.2.camel@redhat.com> References: <20161001054402.31210-1-keithp@keithp.com> <20161001054402.31210-3-keithp@keithp.com> <1475521149.23582.2.camel@redhat.com> Message-ID: <864m4t5aeo.fsf@hiro.keithp.com> Adam Jackson writes: > On Fri, 2016-09-30 at 22:44 -0700, Keith Packard wrote: > >> +    /* copy mode for the first plane to clear all of the other bits */ >> +    gcv[0].val = GXcopy; >> +    gcv[1].val = gc->fgPixel; >> +    gcv[2].val = gc->bgPixel; >> +    ChangeGC(NullClient, temp_gc, GCFunction|GCForeground|GCBackground, gcv); > > You don't need to set GCFunction here, the scratch gc already has > GXcopy set. > > You _do_ need to copy GCPlanemask from the source gc, because for > XYPixmap PutImage that determines how many planes of data were given; > if you let it stay as FB_ALLONES when it should only be, say, 0x3, > you'll read in 30 planes of garbage. That's true for GetImage, but the protocol doc is rather unclear about PutImage. The only mention of 'plane-mask' in the PutImage spec is as a relevant component in the GC. Xlib doesn't look at the plane mask; the request length is computed with: bytes_per_dest = (unsigned long)ROUNDUP((long)req->width + req->leftPad, dpy->bitmap_pad) >> 3; bytes_per_dest_plane = bytes_per_dest * req->height; length = bytes_per_dest_plane * image->depth; req->length += (length + 3) >> 2; Looks like fb has a bug. -- -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From keithp at keithp.com Mon Oct 3 22:37:03 2016 From: keithp at keithp.com (Keith Packard) Date: Mon, 3 Oct 2016 15:37:03 -0700 Subject: [PATCH xserver] fb: XYPixmap format PutImage includes all planes in depth Message-ID: <20161003223703.26758-1-keithp@keithp.com> Unlike GetImage, for which the provided planemask restricts the data delivered, for PutImage in XYPixmap format, all of the planes in the drawable depth are sent and those outside the plane mask are simply ignored. Signed-off-by: Keith Packard --- fb/fbimage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fb/fbimage.c b/fb/fbimage.c index 59daa21..bac5de6 100644 --- a/fb/fbimage.c +++ b/fb/fbimage.c @@ -63,8 +63,8 @@ fbPutImage(DrawablePtr pDrawable, fbReplicatePixel(i, pDrawable->bitsPerPixel), pGC->alu, TRUE, x, y, w, h, src, srcStride, leftPad); - src += srcStride * h; } + src += srcStride * h; } break; case ZPixmap: -- 2.9.3 From eric at anholt.net Mon Oct 3 23:21:15 2016 From: eric at anholt.net (Eric Anholt) Date: Mon, 03 Oct 2016 16:21:15 -0700 Subject: [PATCH xserver 0/3] glamor: Accelerate XY format images In-Reply-To: <1475525007.23582.4.camel@redhat.com> References: <20161001054402.31210-1-keithp@keithp.com> <1475525007.23582.4.camel@redhat.com> Message-ID: <87ponhow7o.fsf@eliezer.anholt.net> Adam Jackson writes: > On Fri, 2016-09-30 at 22:43 -0700, Keith Packard wrote: > >>        1                 2                 Operation >> ------------   -------------------------   ------------------------- >>      10900.0        99900.0 (     9.165)   PutImage XY 10x10 square  >>       1740.0         2160.0 (     1.241)   PutImage XY 100x100 square  >>         83.2           90.4 (     1.087)   PutImage XY 500x500 square  > > 90 ops per second is still shameful. No blit should take 11ms. > >>      11800.0       351000.0 (    29.746)   PutImage XYBitmap 10x10 square  >>       6280.0        81600.0 (    12.994)   PutImage XYBitmap 100x100 square  >>        752.0        14300.0 (    19.016)   PutImage XYBitmap 500x500 square  > > Where does one get a copy of x11perf that has this test? > > Also I assume this is measuring before the whole series vs after. Would > be nice to see the impact between 2/3 and 3/3 too. > >> I'd like to know why the GPU expansion version has so much GL >> overhead; it "should" be faster for everything as it uploads a lot >> less data to the GPU. > > On i965, at least, scissor updates are an appreciable amount of gl > driver time, so small ops get punished. Not sure if you've seen this, but it helped i965 a ton. Radeon already had equivalent code. https://lists.freedesktop.org/archives/mesa-dev/2016-September/129809.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From cfergeau at redhat.com Mon Oct 3 10:04:27 2016 From: cfergeau at redhat.com (Christophe Fergeau) Date: Mon, 3 Oct 2016 12:04:27 +0200 Subject: [Spice-devel] [PATCH xf86-video-qxl] Adjust xspice_wakeup_handler() prototype for building xspice with server 1.19 In-Reply-To: <20160929110301.27667-1-hdegoede@redhat.com> References: <20160929110301.27667-1-hdegoede@redhat.com> Message-ID: <20161003100427.GH12690@edamame.cdg.redhat.com> On Thu, Sep 29, 2016 at 01:03:01PM +0200, Hans de Goede wrote: > Signed-off-by: Hans de Goede > --- > src/spiceqxl_main_loop.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/src/spiceqxl_main_loop.c b/src/spiceqxl_main_loop.c > index db89b6d..0ac1f3e 100644 > --- a/src/spiceqxl_main_loop.c > +++ b/src/spiceqxl_main_loop.c > @@ -330,7 +330,11 @@ static int no_write_watches(Ring *w) > return 1; > } > > +#if ABI_VIDEODRV_VERSION >= SET_ABI_VERSION(23, 0) We have an occurrence of #if GET_ABI_MAJOR(ABI_VIDEODRV_VERSION) < 6 I'd use this here too to stay consistent (I assume they are equivalent here). Acked-by: Christophe Fergeau Christophe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From hdegoede at redhat.com Tue Oct 4 08:10:24 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Tue, 4 Oct 2016 10:10:24 +0200 Subject: PATCH: Add xorg-xserver 1.19 support to tigervnc In-Reply-To: <20161003165751.GU16844@imgtec.com> References: <20161003165751.GU16844@imgtec.com> Message-ID: <21fc82d7-701a-cc8a-297a-3bf2b7933202@redhat.com> Hi, On 03-10-16 18:57, Eric Engestrom wrote: > On Mon, Oct 03, 2016 at 05:59:33PM +0200, Hans de Goede wrote: >> Hello tigervnc devs, >> >> As part of updating Fedora to xserver 1.19 I've written >> a tiger vnc patch to make tigervnc work with xserver 1.19. >> >> Since xserver 1.19 switches from select to poll the changes >> are non trivial and require some #ifdef-s. The new code is >> a lot cleaner then the old code though, which is good. >> >> And with server 1.19 the os/WaitFor.c changes are no longer >> necessary. >> >> Attached is a tigervnc-1.7.0 patch, as well as a patch >> to apply to the xserver sources to patch in the tigervnc >> ext and hw/vnc dir into the buidlsys. >> >> Regards, >> >> Hans > > [snip] > >> --- tigervnc-1.7.0/unix/xserver/hw/vnc/xorg-version.h 2016-09-08 12:31:18.000000000 +0200 >> +++ tigervnc-1.7.0.new/unix/xserver/hw/vnc/xorg-version.h 2016-10-03 10:27:53.721116357 +0200 >> @@ -50,8 +50,10 @@ >> #define XORG 117 >> #elif XORG_VERSION_CURRENT < ((1 * 10000000) + (18 * 100000) + (99 * 1000)) >> #define XORG 118 >> +#elif XORG_VERSION_CURRENT < ((1 * 10000000) + (19 * 100000) + (99 * 1000)) >> +#define XORG 119 >> #else >> -#error "X.Org newer than 1.18 is not supported" >> +#error "X.Org newer than 1.18 is not supported" > > This seems like a git bug? No my bad (I did not use git to generate the patch as I was working on the fedora pkg/ 1.7.0 tarbal), while reviewing the patch I noticed I forgot to fix the error messages so I manually edited the patch file (something which you get handy at when mangling patches too often), and it looks like a got all the hard bits to still make the patch apply right but while focusing on that I forgot to actually update the error messages :) Regards, Hans From ofourdan at redhat.com Tue Oct 4 11:28:08 2016 From: ofourdan at redhat.com (Olivier Fourdan) Date: Tue, 4 Oct 2016 13:28:08 +0200 Subject: [PATCH RFC xserver] glamor: Fix pixmap offset for bitplane in glamor_copy_fbo_cpu Message-ID: <20161004112808.7124-1-ofourdan@redhat.com> Commit cba28d5 - glamor: Handle bitplane in glamor_copy_fbo_cpu instroduced a regression as the computed pixmap offset would not match the qactual coordinates and write data elsewhere in memory causing a segfault in fbBltOne(). Translate the pixmap coordinates so that the data is read and written at the correct location. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97974 Signed-off-by: Olivier Fourdan --- Note: This fixes the crash apparerntly and produces the expected output, as tested with xterm's contectual menu, the check boxes are drawn correctly and placed where they should be. Yet, I am not familiar with this code so I have no idea if ths is the correct fix for the problem, or even a fix at all. But it avoids the crash and the regression here. glamor/glamor_copy.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/glamor/glamor_copy.c b/glamor/glamor_copy.c index 8a329d2..1fd863a 100644 --- a/glamor/glamor_copy.c +++ b/glamor/glamor_copy.c @@ -230,19 +230,22 @@ glamor_copy_cpu_fbo(DrawablePtr src, goto bail; } + src_pix->drawable.x = - dst->x; + src_pix->drawable.y = - dst->y; + fbGetDrawable(&src_pix->drawable, src_bits, src_stride, src_bpp, src_xoff, src_yoff); if (src->bitsPerPixel > 1) fbCopyNto1(src, &src_pix->drawable, gc, box, nbox, - dst_xoff + dx, dst_yoff + dy, reverse, upsidedown, + dx, dy, reverse, upsidedown, bitplane, closure); else fbCopy1toN(src, &src_pix->drawable, gc, box, nbox, - dst_xoff + dx, dst_yoff + dy, reverse, upsidedown, + dx, dy, reverse, upsidedown, bitplane, closure); - glamor_upload_boxes(dst_pixmap, box, nbox, 0, 0, 0, 0, + glamor_upload_boxes(dst_pixmap, box, nbox, src_xoff, src_yoff, dst_xoff, dst_yoff, (uint8_t *) src_bits, src_stride * sizeof(FbBits)); fbDestroyPixmap(src_pix); } else { -- 2.9.3 From hdegoede at redhat.com Tue Oct 4 11:41:12 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Tue, 4 Oct 2016 13:41:12 +0200 Subject: [Spice-devel] [PATCH xf86-video-qxl] Adjust xspice_wakeup_handler() prototype for building xspice with server 1.19 In-Reply-To: <20161003100427.GH12690@edamame.cdg.redhat.com> References: <20160929110301.27667-1-hdegoede@redhat.com> <20161003100427.GH12690@edamame.cdg.redhat.com> Message-ID: <78255c3e-a2c1-1534-7d8a-070439f3d87c@redhat.com> Hi, On 03-10-16 12:04, Christophe Fergeau wrote: > > > On Thu, Sep 29, 2016 at 01:03:01PM +0200, Hans de Goede wrote: >> Signed-off-by: Hans de Goede >> --- >> src/spiceqxl_main_loop.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/src/spiceqxl_main_loop.c b/src/spiceqxl_main_loop.c >> index db89b6d..0ac1f3e 100644 >> --- a/src/spiceqxl_main_loop.c >> +++ b/src/spiceqxl_main_loop.c >> @@ -330,7 +330,11 @@ static int no_write_watches(Ring *w) >> return 1; >> } >> >> +#if ABI_VIDEODRV_VERSION >= SET_ABI_VERSION(23, 0) > > We have an occurrence of > #if GET_ABI_MAJOR(ABI_VIDEODRV_VERSION) < 6 > I'd use this here too to stay consistent (I assume they are equivalent > here). > > Acked-by: Christophe Fergeau Sorry, but this patch turns out to be incomplete, self NACK. I just saw that spiceqxl_main_loop also uses a BlockHandler (xspice_block_handler) and expects to be able to add fds to watch for read activity through the xserver mainloop by treating the 3th argument as a FD_SET. This is no longer supported as of xserver 1.19, instead the new NotifyFD functionality should be used. The advantage of this is that it can also properly watch fds for them becoming ready for writing. For an example patch of how to use the new NotifyFD functionality see the recent tigervnc patch to make tigervnc work with 1.19: https://lists.x.org/archives/xorg-devel/2016-October/051482.html Regards, Hans From hdegoede at redhat.com Tue Oct 4 12:08:13 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Tue, 4 Oct 2016 14:08:13 +0200 Subject: [PATCH xf86-video-qxl] Fix crash caused by attempting to access the screen pixmap before it is created Message-ID: <20161004120813.10890-1-hdegoede@redhat.com> qxl_resize_primary_to_virtual() was using pScrn->pScreen != NULL to check if createScreenResources has been called. But starting with xserver 1.19 pScrn->pScreen is non NULL even before createScreenResources is called, causing an invalid access to the screenPixmap in qxl_resize_primary_to_virtual(). This commit fixes this. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1381045 Signed-off-by: Hans de Goede --- src/qxl.h | 1 + src/qxl_driver.c | 6 +++--- src/qxl_kms.c | 1 + 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/src/qxl.h b/src/qxl.h index 5cc8d05..885048c 100644 --- a/src/qxl.h +++ b/src/qxl.h @@ -234,6 +234,7 @@ struct _qxl_screen_t struct qxl_ring * cursor_ring; struct qxl_ring * release_ring; + Bool screen_resources_created; int device_primary; struct qxl_bo * primary_bo; int num_modes; diff --git a/src/qxl_driver.c b/src/qxl_driver.c index fc1b629..8aecf3c 100644 --- a/src/qxl_driver.c +++ b/src/qxl_driver.c @@ -530,7 +530,6 @@ qxl_create_primary(qxl_screen_t *qxl) Bool qxl_resize_primary_to_virtual (qxl_screen_t *qxl) { - ScreenPtr pScreen; long new_surface0_size; if ((qxl->primary_mode.x_res == qxl->virtual_x && @@ -566,9 +565,9 @@ qxl_resize_primary_to_virtual (qxl_screen_t *qxl) qxl->primary = qxl_create_primary(qxl); qxl->bytes_per_pixel = (qxl->pScrn->bitsPerPixel + 7) / 8; - pScreen = qxl->pScrn->pScreen; - if (pScreen) + if (qxl->screen_resources_created) { + ScreenPtr pScreen = qxl->pScrn->pScreen; PixmapPtr root = pScreen->GetScreenPixmap (pScreen); if (qxl->deferred_fps <= 0) @@ -645,6 +644,7 @@ qxl_create_screen_resources (ScreenPtr pScreen) qxl_create_desired_modes (qxl); qxl_update_edid (qxl); + qxl->screen_resources_created = TRUE; return TRUE; } diff --git a/src/qxl_kms.c b/src/qxl_kms.c index fe37af0..d11b20e 100644 --- a/src/qxl_kms.c +++ b/src/qxl_kms.c @@ -235,6 +235,7 @@ qxl_create_screen_resources_kms(ScreenPtr pScreen) if (!uxa_resources_init (pScreen)) return FALSE; + qxl->screen_resources_created = TRUE; return TRUE; } -- 2.9.3 From coyote at bks.tv Tue Oct 4 12:52:05 2016 From: coyote at bks.tv (Victor V. Kustov) Date: Tue, 4 Oct 2016 15:52:05 +0300 Subject: Request changes in Compose.pre Message-ID: <20161004155205.3dd17465@bkstv.bks-tv.ru> Good day! Please approve following patch for type russian rouble symbol. --- Compose.pre.orig 2016-10-03 17:07:00.778676663 +0300 +++ Compose.pre 2016-10-03 17:09:13.570672739 +0300 @@ -190,6 +190,10 @@ : "€" EuroSign # EURO SIGN : "€" EuroSign # EURO SIGN : "€" EuroSign # EURO SIGN +

: "₽" U20bd # RUBLE-CURRENCY SIGN +

: "₽" U20bd # RUBLE-CURRENCY SIGN +

: "₽" U20bd # RUBLE-CURRENCY SIGN +

: "₽" U20bd # RUBLE-CURRENCY SIGN XCOMM "₭" U20ad KIP SIGN XCOMM "₮" U20ae TUGRIK SIGN XCOMM "₯" U20af DRACHMA SIGN -- Cheers, Victor V. Kustov +7 (952) 966 76 24 JID: coyote at bks-tv.ru I use FREE operation system: 4.4.17-calculate GNU/Linux up 4 days, 15 minutes From ossman at cendio.se Tue Oct 4 14:45:32 2016 From: ossman at cendio.se (Pierre Ossman) Date: Tue, 4 Oct 2016 16:45:32 +0200 Subject: [tigervnc-devel] PATCH: Add xorg-xserver 1.19 support to tigervnc In-Reply-To: References: Message-ID: <3d817006-8633-1228-8e60-489a7df3c89c@cendio.se> On 03/10/16 17:59, Hans de Goede wrote: > Hello tigervnc devs, > > As part of updating Fedora to xserver 1.19 I've written > a tiger vnc patch to make tigervnc work with xserver 1.19. > Nice, Thanks. :) > Since xserver 1.19 switches from select to poll the changes > are non trivial and require some #ifdef-s. The new code is > a lot cleaner then the old code though, which is good. > > And with server 1.19 the os/WaitFor.c changes are no longer > necessary. > Very nice. However I'm not a fan of the large amount of duplicate code we're dragging around now. I'd prefer to switch everything over to the new model, and put something in vncBlockHandler.c that emulates the new API on top of the old system. > Attached is a tigervnc-1.7.0 patch, as well as a patch > to apply to the xserver sources to patch in the tigervnc > ext and hw/vnc dir into the buidlsys. > > +#include "os.h" NAK on this I'm afraid. Using Xorg headers in C++ has been endless grief. Hence the wrappers in both directions. I'd say put this in vncBlockHandler.c and tie it up via vncExtInit.cc. > + SetNotifyFd(sock->getFd(), HandleSocketFd, X_NOTIFY_READ, this); I don't see any code setting X_NOTIFY_WRITE? > --- xserver/include/os.h~ 2016-10-03 09:07:29.000000000 +0200 > +++ xserver/include/os.h 2016-10-03 14:13:00.013654506 +0200 > @@ -621,7 +621,7 @@ > extern _X_EXPORT void > LogClose(enum ExitCode error); > extern _X_EXPORT Bool > -LogSetParameter(LogParameter param, int value); > +LogSetParameter(enum _LogParameter param, int value); > extern _X_EXPORT void > LogVWrite(int verb, const char *f, va_list args) > _X_ATTRIBUTE_PRINTF(2, 0); Is this a fix that's meant to go upstream at some point? Regards -- Pierre Ossman Software Development Cendio AB https://cendio.com Teknikringen 8 https://twitter.com/ThinLinc 583 30 Linköping https://facebook.com/ThinLinc Phone: +46-13-214600 https://plus.google.com/+CendioThinLinc A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? From hdegoede at redhat.com Tue Oct 4 15:45:57 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Tue, 4 Oct 2016 17:45:57 +0200 Subject: [tigervnc-devel] PATCH: Add xorg-xserver 1.19 support to tigervnc In-Reply-To: <3d817006-8633-1228-8e60-489a7df3c89c@cendio.se> References: <3d817006-8633-1228-8e60-489a7df3c89c@cendio.se> Message-ID: Hi, On 10/04/2016 04:45 PM, Pierre Ossman wrote: > On 03/10/16 17:59, Hans de Goede wrote: >> Hello tigervnc devs, >> >> As part of updating Fedora to xserver 1.19 I've written >> a tiger vnc patch to make tigervnc work with xserver 1.19. >> > > Nice, Thanks. :) > >> Since xserver 1.19 switches from select to poll the changes >> are non trivial and require some #ifdef-s. The new code is >> a lot cleaner then the old code though, which is good. >> >> And with server 1.19 the os/WaitFor.c changes are no longer >> necessary. >> > > Very nice. However I'm not a fan of the large amount of duplicate code we're dragging around now. I'd prefer to switch everything over to the new model, and put something in vncBlockHandler.c that emulates the new API on top of the old system. If been working for 7 days on a row now to get 1.19 in shape for Fedora 25, so I'm afraid that the v2 of this patch I'm working on is going to be a take it or leave it offer from my pov. You are of course more then welcome to improve upon the patch yourself. >> Attached is a tigervnc-1.7.0 patch, as well as a patch >> to apply to the xserver sources to patch in the tigervnc >> ext and hw/vnc dir into the buidlsys. >> > >> +#include "os.h" > > NAK on this I'm afraid. Using Xorg headers in C++ has been endless grief. Hence the wrappers in both directions. I'd say put this in vncBlockHandler.c and tie it up via vncExtInit.cc. See above, I'm completely out of steam for any more 1.19 related work, sorry. feel free to fix this up before merging. >> + SetNotifyFd(sock->getFd(), HandleSocketFd, X_NOTIFY_READ, this); > > I don't see any code setting X_NOTIFY_WRITE? Yes, while working on something completely unrelated I realized that I might have deleted to much code from the BlockHandler, the code that used to deal with setting X_NOTIFY_WRITE in the BlockHandler was also dealing with (*i)->isShutdown(), then I realized that (*i)->isShutdown() could / should be checked at the end of the FdNotify callback, and when removing that from the BlockHandler, I accidentally also deleted the setting of X_NOTIFY_WRITE. I was preparing a v2 of the patch which re-introduces this, when I noticed this mail (while waiting for the updated patch to compile :) I will post a v2 soon. Regards, Hans p.s. While on the subject of write-ready notification I noticed what I believe is a bug in tigervnc-1.7.0/common/rdr/FdOutStream.cxx: FdOutStream::flush(). When the stream is nonblocking and writeWithTimeout() returns 0, then flush() will simply retry again (and again and again), if I read the code correctly), so it will *busy* wait until all data is written. >> --- xserver/include/os.h~ 2016-10-03 09:07:29.000000000 +0200 >> +++ xserver/include/os.h 2016-10-03 14:13:00.013654506 +0200 >> @@ -621,7 +621,7 @@ >> extern _X_EXPORT void >> LogClose(enum ExitCode error); >> extern _X_EXPORT Bool >> -LogSetParameter(LogParameter param, int value); >> +LogSetParameter(enum _LogParameter param, int value); >> extern _X_EXPORT void >> LogVWrite(int verb, const char *f, va_list args) >> _X_ATTRIBUTE_PRINTF(2, 0); > > Is this a fix that's meant to go upstream at some point? > > Regards From hdegoede at redhat.com Tue Oct 4 15:57:38 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Tue, 4 Oct 2016 17:57:38 +0200 Subject: PATCH v2: Add xorg-xserver 1.19 support to tigervnc Message-ID: <6aa84f89-aee0-cc84-2d53-516dfbb89d88@redhat.com> Hi, Here is the promised v2 of my patch to add 1.19 support to tigervnc, this time with code to properly request write-ready notification when necessary. As mentioned in the original thread, I believe that there is a bug in tigervnc-1.7.0/common/rdr/FdOutStream.cxx: FdOutStream::flush(). When the stream is nonblocking and writeWithTimeout() returns 0, then flush() will simply retry again (and again and again), if I read the code correctly), so it will *busy* wait until all data is written. It would be good if someone who knows the code better can take a look at this. Regards, Hans -------------- next part -------------- A non-text attachment was scrubbed... Name: tigervnc-1.7.0-xserver119-support.patch Type: text/x-patch Size: 13649 bytes Desc: not available URL: From ajax at redhat.com Tue Oct 4 16:14:08 2016 From: ajax at redhat.com (Adam Jackson) Date: Tue, 04 Oct 2016 12:14:08 -0400 Subject: [PATCH xserver 2/3] glamor: Accelerate up XY pixmap putimage a little In-Reply-To: <864m4t5aeo.fsf@hiro.keithp.com> References: <20161001054402.31210-1-keithp@keithp.com> <20161001054402.31210-3-keithp@keithp.com> <1475521149.23582.2.camel@redhat.com> <864m4t5aeo.fsf@hiro.keithp.com> Message-ID: <1475597648.23582.10.camel@redhat.com> On Mon, 2016-10-03 at 15:34 -0700, Keith Packard wrote: > That's true for GetImage, but the protocol doc is rather unclear about > PutImage. The only mention of 'plane-mask' in the PutImage spec is as a > relevant component in the GC. Xlib doesn't look at the plane mask; the > request length is computed with: > >     bytes_per_dest = (unsigned long)ROUNDUP((long)req->width + req->leftPad, >     dpy->bitmap_pad) >> 3; >     bytes_per_dest_plane = bytes_per_dest * req->height; >     length = bytes_per_dest_plane * image->depth; >     req->length += (length + 3) >> 2; > > Looks like fb has a bug. You appear to be correct, I was reading fb's XYPixmap path a bit too closely. Neither xlib nor ProcPutImage make reference to the planemask when computing the image length, so they must be right regardless of the actual spec's silence. - ajax From ajax at nwnk.net Tue Oct 4 16:16:30 2016 From: ajax at nwnk.net (Adam Jackson) Date: Tue, 04 Oct 2016 12:16:30 -0400 Subject: [PATCH xserver] fb: XYPixmap format PutImage includes all planes in depth In-Reply-To: <20161003223703.26758-1-keithp@keithp.com> References: <20161003223703.26758-1-keithp@keithp.com> Message-ID: <1475597790.23582.11.camel@nwnk.net> On Mon, 2016-10-03 at 15:37 -0700, Keith Packard wrote: > Unlike GetImage, for which the provided planemask restricts the data > delivered, for PutImage in XYPixmap format, all of the planes in the > drawable depth are sent and those outside the plane mask are simply > ignored. > > Signed-off-by: Keith Packard Somewhat unfortunate that nothing in xts managed to catch this. But this makes fb match mi, and since the transmitted image length doesn't vary with the planemask fb is clearly wrong to behave as if it does. Merged: remote: I: patch #113525 updated using rev 2b6a068d21997ca812e665ed058e72eb4626c129. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver c9b8ce7..2b6a068 master -> master - ajax From ajax at redhat.com Tue Oct 4 17:34:33 2016 From: ajax at redhat.com (Adam Jackson) Date: Tue, 4 Oct 2016 13:34:33 -0400 Subject: [PATCH xserver] glamor: Use eglGetPlatformDisplayEXT not eglGetDisplay Message-ID: <20161004173433.12814-1-ajax@redhat.com> eglGetDisplay forces the implementation to guess which kind of display it's been handed. glvnd does something different from Mesa, and in general it's impossible for the library to get this right. Instead use the API where you specify what kind of display it is. The explicit call to eglGetProcAddress is to work around a bug in libepoxy 1.3, which does not understand EGL client extensions and so its resolver code will crash. Signed-off-by: Adam Jackson --- glamor/glamor_egl.c | 9 ++++++++- hw/xwayland/xwayland-glamor.c | 8 +++++++- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c index 2b9e0e1..51d8147 100644 --- a/glamor/glamor_egl.c +++ b/glamor/glamor_egl.c @@ -736,6 +736,7 @@ glamor_egl_init(ScrnInfoPtr scrn, int fd) { struct glamor_egl_screen_private *glamor_egl; const char *version; + PFNEGLGETPLATFORMDISPLAYEXTPROC getPlatformDisplay; EGLint config_attribs[] = { #ifdef GLAMOR_GLES2 @@ -768,7 +769,13 @@ glamor_egl_init(ScrnInfoPtr scrn, int fd) ErrorF("couldn't get display device\n"); goto error; } - glamor_egl->display = eglGetDisplay(glamor_egl->gbm); + + getPlatformDisplay = (PFNEGLGETPLATFORMDISPLAYEXTPROC) + eglGetProcAddress("eglGetPlatformDisplayEXT"); + + if (getPlatformDisplay) + glamor_egl->display = getPlatformDisplay (EGL_PLATFORM_GBM_MESA, + glamor_egl->gbm, NULL); #else glamor_egl->display = eglGetDisplay((EGLNativeDisplayType) (intptr_t) fd); #endif diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c index 068c224..23402f9 100644 --- a/hw/xwayland/xwayland-glamor.c +++ b/hw/xwayland/xwayland-glamor.c @@ -280,6 +280,7 @@ xwl_drm_init_egl(struct xwl_screen *xwl_screen) GLAMOR_GL_CORE_VER_MINOR, EGL_NONE }; + PFNEGLGETPLATFORMDISPLAYEXTPROC getPlatformDisplay; if (xwl_screen->egl_display) return; @@ -292,7 +293,12 @@ xwl_drm_init_egl(struct xwl_screen *xwl_screen) return; } - xwl_screen->egl_display = eglGetDisplay(xwl_screen->gbm); + getPlatformDisplay = (PFNEGLGETPLATFORMDISPLAYEXTPROC) + eglGetProcAddress("eglGetPlatformDisplayEXT"); + + if (getPlatformDisplay) + xwl_screen->egl_display = getPlatformDisplay(EGL_PLATFORM_GBM_MESA, + xwl_screen->gbm, NULL); if (xwl_screen->egl_display == EGL_NO_DISPLAY) { ErrorF("eglGetDisplay() failed\n"); return; -- 2.9.3 From cfergeau at redhat.com Tue Oct 4 13:51:24 2016 From: cfergeau at redhat.com (Christophe Fergeau) Date: Tue, 4 Oct 2016 15:51:24 +0200 Subject: [Spice-devel] [PATCH xf86-video-qxl] Fix crash caused by attempting to access the screen pixmap before it is created In-Reply-To: <20161004120813.10890-1-hdegoede@redhat.com> References: <20161004120813.10890-1-hdegoede@redhat.com> Message-ID: <20161004135124.GI6450@edamame.cdg.redhat.com> Hey Hans, On Tue, Oct 04, 2016 at 02:08:13PM +0200, Hans de Goede wrote: > qxl_resize_primary_to_virtual() was using pScrn->pScreen != NULL to check > if createScreenResources has been called. But starting with xserver 1.19 > pScrn->pScreen is non NULL even before createScreenResources is called, > causing an invalid access to the screenPixmap in > qxl_resize_primary_to_virtual(). > > This commit fixes this. > > BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1381045 > Signed-off-by: Hans de Goede Yes, this was changed in the xserver by 69b782aa75bc06f11b8f9b532d5213f252c4c6c4 "xfree86: Set pScrn->pScreen before driver ScreenInit is called" Acked-by: Christophe Fergeau Christophe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From michel at daenzer.net Wed Oct 5 03:03:15 2016 From: michel at daenzer.net (=?UTF-8?Q?Michel_D=c3=a4nzer?=) Date: Wed, 5 Oct 2016 12:03:15 +0900 Subject: [PATCH RFC xserver] glamor: Fix pixmap offset for bitplane in glamor_copy_fbo_cpu In-Reply-To: <20161004112808.7124-1-ofourdan@redhat.com> References: <20161004112808.7124-1-ofourdan@redhat.com> Message-ID: <295104e6-f49b-96a8-dd55-d65aae10df1d@daenzer.net> On 04/10/16 08:28 PM, Olivier Fourdan wrote: > Commit cba28d5 - glamor: Handle bitplane in glamor_copy_fbo_cpu > instroduced a regression as the computed pixmap offset would not match > the qactual coordinates and write data elsewhere in memory causing a > segfault in fbBltOne(). > > Translate the pixmap coordinates so that the data is read and written at > the correct location. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97974 > Signed-off-by: Olivier Fourdan > --- > Note: This fixes the crash apparerntly and produces the expected output, > as tested with xterm's contectual menu, the check boxes are drawn > correctly and placed where they should be. > Yet, I am not familiar with this code so I have no idea if ths is > the correct fix for the problem, or even a fix at all. > But it avoids the crash and the regression here. I looked into this a little yesterday as well, and was heading towards pretty much the same solution. Some cosmetic comments below, but regardless of those, this patch is Reviewed-and-Tested-by: Michel Dänzer > diff --git a/glamor/glamor_copy.c b/glamor/glamor_copy.c > index 8a329d2..1fd863a 100644 > --- a/glamor/glamor_copy.c > +++ b/glamor/glamor_copy.c > @@ -230,19 +230,22 @@ glamor_copy_cpu_fbo(DrawablePtr src, > goto bail; > } > > + src_pix->drawable.x = - dst->x; > + src_pix->drawable.y = - dst->y; I'd drop the space between the minus sign and dst->x/y. > if (src->bitsPerPixel > 1) > fbCopyNto1(src, &src_pix->drawable, gc, box, nbox, > - dst_xoff + dx, dst_yoff + dy, reverse, upsidedown, > + dx, dy, reverse, upsidedown, > bitplane, closure); > else > fbCopy1toN(src, &src_pix->drawable, gc, box, nbox, > - dst_xoff + dx, dst_yoff + dy, reverse, upsidedown, > + dx, dy, reverse, upsidedown, > bitplane, closure); The fbCopy*to* calls could be reformatted to fit in two lines now. > - glamor_upload_boxes(dst_pixmap, box, nbox, 0, 0, 0, 0, > + glamor_upload_boxes(dst_pixmap, box, nbox, src_xoff, src_yoff, dst_xoff, dst_yoff, > (uint8_t *) src_bits, src_stride * sizeof(FbBits)); OTOH this line is too long now, so this call should be reformatted to span three lines. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer From ofourdan at redhat.com Wed Oct 5 06:36:21 2016 From: ofourdan at redhat.com (Olivier Fourdan) Date: Wed, 5 Oct 2016 08:36:21 +0200 Subject: [PATCH v2 xserver] glamor: Fix pixmap offset for bitplane in glamor_copy_fbo_cpu In-Reply-To: <295104e6-f49b-96a8-dd55-d65aae10df1d@daenzer.net> References: <295104e6-f49b-96a8-dd55-d65aae10df1d@daenzer.net> Message-ID: <20161005063621.32649-1-ofourdan@redhat.com> Commit cba28d5 - "glamor: Handle bitplane in glamor_copy_fbo_cpu" introduced a regression as the computed pixmap offset would not match the actual coordinates and write data elsewhere in memory causing a segfault in fbBltOne(). Translate the pixmap coordinates so that the data is read and written at the correct location. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97974 Signed-off-by: Olivier Fourdan Reviewed-and-Tested-by: Michel Dänzer --- v2: Fix typos in commit message Reformat as per Michel's review and add Michel's R-b glamor/glamor_copy.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/glamor/glamor_copy.c b/glamor/glamor_copy.c index 8a329d2..3ca56fb 100644 --- a/glamor/glamor_copy.c +++ b/glamor/glamor_copy.c @@ -230,20 +230,22 @@ glamor_copy_cpu_fbo(DrawablePtr src, goto bail; } + src_pix->drawable.x = -dst->x; + src_pix->drawable.y = -dst->y; + fbGetDrawable(&src_pix->drawable, src_bits, src_stride, src_bpp, src_xoff, src_yoff); if (src->bitsPerPixel > 1) - fbCopyNto1(src, &src_pix->drawable, gc, box, nbox, - dst_xoff + dx, dst_yoff + dy, reverse, upsidedown, - bitplane, closure); + fbCopyNto1(src, &src_pix->drawable, gc, box, nbox, dx, dy, + reverse, upsidedown, bitplane, closure); else - fbCopy1toN(src, &src_pix->drawable, gc, box, nbox, - dst_xoff + dx, dst_yoff + dy, reverse, upsidedown, - bitplane, closure); + fbCopy1toN(src, &src_pix->drawable, gc, box, nbox, dx, dy, + reverse, upsidedown, bitplane, closure); - glamor_upload_boxes(dst_pixmap, box, nbox, 0, 0, 0, 0, - (uint8_t *) src_bits, src_stride * sizeof(FbBits)); + glamor_upload_boxes(dst_pixmap, box, nbox, src_xoff, src_yoff, + dst_xoff, dst_yoff, (uint8_t *) src_bits, + src_stride * sizeof(FbBits)); fbDestroyPixmap(src_pix); } else { fbGetDrawable(src, src_bits, src_stride, src_bpp, src_xoff, src_yoff); -- 2.9.3 From jcristau at debian.org Wed Oct 5 06:56:52 2016 From: jcristau at debian.org (Julien Cristau) Date: Wed, 5 Oct 2016 08:56:52 +0200 Subject: [PATCH libX11 1/2] The validation of server responses avoids out of boundary accesses. In-Reply-To: <20160925205049.23326-2-matthieu@herrb.eu> References: <20160925205049.23326-1-matthieu@herrb.eu> <20160925205049.23326-2-matthieu@herrb.eu> Message-ID: <20161005065652.l2f3cs6ignp3ymro@betterave.cristau.org> Hi all, Sorry I didn't get a chance to look at these before they went public... On Sun, Sep 25, 2016 at 22:50:40 +0200, Matthieu Herrb wrote: > From: Tobias Stoeckmann > > v2: FontNames.c return a NULL list whenever a single > length field from the server is incohent. > > Signed-off-by: Tobias Stoeckmann > Reviewed-by: Matthieu Herrb > --- > src/FontNames.c | 23 +++++++++++++++++------ > src/ListExt.c | 12 ++++++++---- > src/ModMap.c | 3 ++- > 3 files changed, 27 insertions(+), 11 deletions(-) > > diff --git a/src/FontNames.c b/src/FontNames.c > index 21dcafe..e55f338 100644 > --- a/src/FontNames.c > +++ b/src/FontNames.c > @@ -66,7 +66,7 @@ int *actualCount) /* RETURN */ > > if (rep.nFonts) { > flist = Xmalloc (rep.nFonts * sizeof(char *)); > - if (rep.length < (INT_MAX >> 2)) { > + if (rep.length > 0 && rep.length < (INT_MAX >> 2)) { > rlen = rep.length << 2; > ch = Xmalloc(rlen + 1); > /* +1 to leave room for last null-terminator */ > @@ -93,11 +93,22 @@ int *actualCount) /* RETURN */ > if (ch + length < chend) { > flist[i] = ch + 1; /* skip over length */ > ch += length + 1; /* find next length ... */ > - length = *(unsigned char *)ch; > - *ch = '\0'; /* and replace with null-termination */ > - count++; > - } else > - flist[i] = NULL; > + if (ch <= chend) { > + length = *(unsigned char *)ch; > + *ch = '\0'; /* and replace with null-termination */ > + count++; > + } else { > + Xfree(flist); > + flist = NULL; > + count = 0; > + break; > + } > + } else { > + Xfree(flist); > + flist = NULL; > + count = 0; > + break; > + } > } > } > *actualCount = count; I believe these new error paths are missing Xfree(ch). > diff --git a/src/ListExt.c b/src/ListExt.c > index be6b989..0516e45 100644 > --- a/src/ListExt.c > +++ b/src/ListExt.c > @@ -55,7 +55,7 @@ char **XListExtensions( > > if (rep.nExtensions) { > list = Xmalloc (rep.nExtensions * sizeof (char *)); > - if (rep.length < (INT_MAX >> 2)) { > + if (rep.length > 0 && rep.length < (INT_MAX >> 2)) { > rlen = rep.length << 2; > ch = Xmalloc (rlen + 1); > /* +1 to leave room for last null-terminator */ > @@ -80,9 +80,13 @@ char **XListExtensions( > if (ch + length < chend) { > list[i] = ch+1; /* skip over length */ > ch += length + 1; /* find next length ... */ > - length = *ch; > - *ch = '\0'; /* and replace with null-termination */ > - count++; > + if (ch <= chend) { > + length = *ch; > + *ch = '\0'; /* and replace with null-termination */ > + count++; > + } else { > + list[i] = NULL; > + } > } else > list[i] = NULL; > } This might have been more readable by just replacing the previous if (ch + length < chend) with if (ch + length + 1 < chend) ? Cheers, Julien From jcristau at debian.org Wed Oct 5 07:49:41 2016 From: jcristau at debian.org (Julien Cristau) Date: Wed, 5 Oct 2016 09:49:41 +0200 Subject: [PATCH libXi] Properly validate server responses. In-Reply-To: <20160925205049.23326-5-matthieu@herrb.eu> References: <20160925205049.23326-1-matthieu@herrb.eu> <20160925205049.23326-5-matthieu@herrb.eu> Message-ID: <20161005074941.nr2viwyvimmcedmm@betterave.cristau.org> On Sun, Sep 25, 2016 at 22:50:43 +0200, Matthieu Herrb wrote: > From: Tobias Stoeckmann > > By validating length fields from server responses, out of boundary > accesses and endless loops can be mitigated. > > Signed-off-by: Tobias Stoeckmann > Reviewed-by: Matthieu Herrb > --- > src/XGMotion.c | 3 ++- > src/XGetBMap.c | 3 ++- > src/XGetDCtl.c | 6 ++++-- > src/XGetFCtl.c | 7 ++++++- > src/XGetKMap.c | 14 +++++++++++--- > src/XGetMMap.c | 11 +++++++++-- > src/XIQueryDevice.c | 36 ++++++++++++++++++++++++++++++++++-- > src/XListDev.c | 21 +++++++++++++++------ > src/XOpenDev.c | 13 ++++++++++--- > src/XQueryDv.c | 8 ++++++-- > 10 files changed, 99 insertions(+), 23 deletions(-) > [...] > diff --git a/src/XIQueryDevice.c b/src/XIQueryDevice.c > index fb8504f..a457cd6 100644 > --- a/src/XIQueryDevice.c > +++ b/src/XIQueryDevice.c > @@ -26,6 +26,7 @@ > #include > #endif > > +#include > #include > #include > #include > @@ -43,6 +44,7 @@ XIQueryDevice(Display *dpy, int deviceid, int *ndevices_return) > xXIQueryDeviceReq *req; > xXIQueryDeviceReply reply; > char *ptr; > + char *end; > int i; > char *buf; > > @@ -60,14 +62,24 @@ XIQueryDevice(Display *dpy, int deviceid, int *ndevices_return) > if (!_XReply(dpy, (xReply*) &reply, 0, xFalse)) > goto error; > > - *ndevices_return = reply.num_devices; > - info = Xmalloc((reply.num_devices + 1) * sizeof(XIDeviceInfo)); > + if (reply.length < INT_MAX / 4) > + { > + *ndevices_return = reply.num_devices; > + info = Xmalloc((reply.num_devices + 1) * sizeof(XIDeviceInfo)); > + } > + else > + { > + *ndevices_return = 0; > + info = NULL; > + } > + > if (!info) > goto error; > > buf = Xmalloc(reply.length * 4); Should we check for allocation failure here? > _XRead(dpy, buf, reply.length * 4); > ptr = buf; > + end = buf + reply.length * 4; > > /* info is a null-terminated array */ > info[reply.num_devices].name = NULL; > @@ -79,6 +91,9 @@ XIQueryDevice(Display *dpy, int deviceid, int *ndevices_return) > XIDeviceInfo *lib = &info[i]; > xXIDeviceInfo *wire = (xXIDeviceInfo*)ptr; > > + if (ptr + sizeof(xXIDeviceInfo) > end) > + goto error_loop; > + > lib->deviceid = wire->deviceid; > lib->use = wire->use; > lib->attachment = wire->attachment; > @@ -87,12 +102,23 @@ XIQueryDevice(Display *dpy, int deviceid, int *ndevices_return) > > ptr += sizeof(xXIDeviceInfo); > > + if (ptr + wire->name_len > end) > + goto error_loop; > + > lib->name = Xcalloc(wire->name_len + 1, 1); > + if (lib->name == NULL) > + goto error_loop; > strncpy(lib->name, ptr, wire->name_len); > + lib->name[wire->name_len] = '\0'; > ptr += ((wire->name_len + 3)/4) * 4; > > sz = size_classes((xXIAnyInfo*)ptr, nclasses); > lib->classes = Xmalloc(sz); > + if (lib->classes == NULL) > + { > + Xfree(lib->name); > + goto error_loop; > + } > ptr += copy_classes(lib, (xXIAnyInfo*)ptr, &nclasses); > /* We skip over unused classes */ > lib->num_classes = nclasses; > @@ -103,6 +129,12 @@ XIQueryDevice(Display *dpy, int deviceid, int *ndevices_return) > SyncHandle(); > return info; > > +error_loop: > + while (--i >= 0) > + { > + Xfree(info[i].name); > + Xfree(info[i].classes); > + } > error: > UnlockDisplay(dpy); > error_unlocked: AFAICT this is missing Xfree(info); Xfree(buf); Cheers, Julien From michel at daenzer.net Wed Oct 5 08:29:36 2016 From: michel at daenzer.net (=?UTF-8?q?Michel=20D=C3=A4nzer?=) Date: Wed, 5 Oct 2016 17:29:36 +0900 Subject: [PATCH xserver] test: Use $XSERVER_BUILDDIR for Xvfb executable path Message-ID: <20161005082936.1985-1-michel@daenzer.net> From: Michel Dänzer Fixes make check with out-of-tree builds. Signed-off-by: Michel Dänzer --- test/scripts/xvfb-piglit.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/scripts/xvfb-piglit.sh b/test/scripts/xvfb-piglit.sh index 799f285..763599e 100755 --- a/test/scripts/xvfb-piglit.sh +++ b/test/scripts/xvfb-piglit.sh @@ -1,4 +1,4 @@ -export SERVER_COMMAND="$XSERVER_DIR/hw/vfb/Xvfb \ +export SERVER_COMMAND="$XSERVER_BUILDDIR/hw/vfb/Xvfb \ -noreset \ -screen scrn 1280x1024x24" export PIGLIT_RESULTS_DIR=$XSERVER_BUILDDIR/test/piglit-results/xvfb -- 2.9.3 From hdegoede at redhat.com Wed Oct 5 08:52:13 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Wed, 5 Oct 2016 10:52:13 +0200 Subject: [PATCH xserver] glamor: Use eglGetPlatformDisplayEXT not eglGetDisplay In-Reply-To: <20161004173433.12814-1-ajax@redhat.com> References: <20161004173433.12814-1-ajax@redhat.com> Message-ID: <32e84172-1957-e803-f4bf-636cc4e55946@redhat.com> Hi, On 04-10-16 19:34, Adam Jackson wrote: > eglGetDisplay forces the implementation to guess which kind of display > it's been handed. glvnd does something different from Mesa, and in > general it's impossible for the library to get this right. Instead use > the API where you specify what kind of display it is. > > The explicit call to eglGetProcAddress is to work around a bug in > libepoxy 1.3, which does not understand EGL client extensions and so its > resolver code will crash. > > Signed-off-by: Adam Jackson Patch looks good to me and is: Reviewed-by: Hans de Goede Regards, Hans > --- > glamor/glamor_egl.c | 9 ++++++++- > hw/xwayland/xwayland-glamor.c | 8 +++++++- > 2 files changed, 15 insertions(+), 2 deletions(-) > > diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c > index 2b9e0e1..51d8147 100644 > --- a/glamor/glamor_egl.c > +++ b/glamor/glamor_egl.c > @@ -736,6 +736,7 @@ glamor_egl_init(ScrnInfoPtr scrn, int fd) > { > struct glamor_egl_screen_private *glamor_egl; > const char *version; > + PFNEGLGETPLATFORMDISPLAYEXTPROC getPlatformDisplay; > > EGLint config_attribs[] = { > #ifdef GLAMOR_GLES2 > @@ -768,7 +769,13 @@ glamor_egl_init(ScrnInfoPtr scrn, int fd) > ErrorF("couldn't get display device\n"); > goto error; > } > - glamor_egl->display = eglGetDisplay(glamor_egl->gbm); > + > + getPlatformDisplay = (PFNEGLGETPLATFORMDISPLAYEXTPROC) > + eglGetProcAddress("eglGetPlatformDisplayEXT"); > + > + if (getPlatformDisplay) > + glamor_egl->display = getPlatformDisplay (EGL_PLATFORM_GBM_MESA, > + glamor_egl->gbm, NULL); > #else > glamor_egl->display = eglGetDisplay((EGLNativeDisplayType) (intptr_t) fd); > #endif > diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c > index 068c224..23402f9 100644 > --- a/hw/xwayland/xwayland-glamor.c > +++ b/hw/xwayland/xwayland-glamor.c > @@ -280,6 +280,7 @@ xwl_drm_init_egl(struct xwl_screen *xwl_screen) > GLAMOR_GL_CORE_VER_MINOR, > EGL_NONE > }; > + PFNEGLGETPLATFORMDISPLAYEXTPROC getPlatformDisplay; > > if (xwl_screen->egl_display) > return; > @@ -292,7 +293,12 @@ xwl_drm_init_egl(struct xwl_screen *xwl_screen) > return; > } > > - xwl_screen->egl_display = eglGetDisplay(xwl_screen->gbm); > + getPlatformDisplay = (PFNEGLGETPLATFORMDISPLAYEXTPROC) > + eglGetProcAddress("eglGetPlatformDisplayEXT"); > + > + if (getPlatformDisplay) > + xwl_screen->egl_display = getPlatformDisplay(EGL_PLATFORM_GBM_MESA, > + xwl_screen->gbm, NULL); > if (xwl_screen->egl_display == EGL_NO_DISPLAY) { > ErrorF("eglGetDisplay() failed\n"); > return; > From ossman at cendio.se Wed Oct 5 09:13:47 2016 From: ossman at cendio.se (Pierre Ossman) Date: Wed, 5 Oct 2016 11:13:47 +0200 Subject: [tigervnc-devel] PATCH: Add xorg-xserver 1.19 support to tigervnc In-Reply-To: References: <3d817006-8633-1228-8e60-489a7df3c89c@cendio.se> Message-ID: <95cc82d0-396b-ad0d-313e-7f19de34381a@cendio.se> On 04/10/16 17:45, Hans de Goede wrote: > > If been working for 7 days on a row now to get 1.19 in > shape for Fedora 25, so I'm afraid that the v2 of this > patch I'm working on is going to be a take it or > leave it offer from my pov. You are of course more then > welcome to improve upon the patch yourself. > Alright. I'll have a look at doing the finishing touches. Thanks for the patch. :) > > While on the subject of write-ready notification I noticed > what I believe is a bug in tigervnc-1.7.0/common/rdr/FdOutStream.cxx: > FdOutStream::flush(). When the stream is nonblocking and writeWithTimeout() > returns 0, then flush() will simply retry again (and again and again), > if I read the code correctly), so it will *busy* wait until all data > is written. > I'll have a look. It may simply be that flush() is defined as always blocking. I'll check who calls it. Regards -- Pierre Ossman Software Development Cendio AB https://cendio.com Teknikringen 8 https://twitter.com/ThinLinc 583 30 Linköping https://facebook.com/ThinLinc Phone: +46-13-214600 https://plus.google.com/+CendioThinLinc A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? From coyote at bks.tv Wed Oct 5 09:40:28 2016 From: coyote at bks.tv (Victor V. Kustov) Date: Wed, 5 Oct 2016 12:40:28 +0300 Subject: Request changes in Compose.pre In-Reply-To: <20161004155205.3dd17465@bkstv.bks-tv.ru> References: <20161004155205.3dd17465@bkstv.bks-tv.ru> Message-ID: <20161005124028.46d11a52@bkstv.bks-tv.ru> Good day! Sorry for noise, but I'm discouraged by silence. Maybe I need send patch by another address or maybe I doing wrong something... Please give me a tips how I may do it correctly. On Tue, 4 Oct 2016 15:52:05 +0300 "Victor V. Kustov" wrote: > Good day! > > Please approve following patch for type russian rouble symbol. > > --- Compose.pre.orig 2016-10-03 17:07:00.778676663 +0300 > +++ Compose.pre 2016-10-03 17:09:13.570672739 +0300 > @@ -190,6 +190,10 @@ > : "€" EuroSign # EURO SIGN > : "€" EuroSign # EURO SIGN > : "€" EuroSign # EURO SIGN > +

: "₽" U20bd # > RUBLE-CURRENCY SIGN +

: "₽" > U20bd # RUBLE-CURRENCY SIGN +

> : "₽" U20bd # RUBLE-CURRENCY SIGN > +

: "₽" U20bd # > RUBLE-CURRENCY SIGN XCOMM "₭" U20ad KIP SIGN XCOMM "₮" U20ae TUGRIK > SIGN XCOMM "₯" U20af DRACHMA SIGN > > -- С уважением, Виктор В. Кустов ООО "Брянск Связь-ТВ" +7 (952) 966 76 24 JID: coyote at bks-tv.ru JID: coyote at bryansktel.ru I use FREE operation system: 4.4.17-calculate GNU/Linux up 4 days, 20 hours, 57 minutes From michel at daenzer.net Wed Oct 5 09:41:36 2016 From: michel at daenzer.net (=?UTF-8?q?Michel=20D=C3=A4nzer?=) Date: Wed, 5 Oct 2016 18:41:36 +0900 Subject: [PATCH xserver 1/3] xf86Cursor: Use CursoreRec::bits->x/yhot in xf86MoveCursor In-Reply-To: <20161005094138.23641-1-michel@daenzer.net> References: <20161005094138.23641-1-michel@daenzer.net> Message-ID: <20161005094138.23641-2-michel@daenzer.net> From: Michel Dänzer xf86CursorScreenRec::HotX/Y contain 0 for PRIME slave screens. Fixes incorrect HW cursor position on PRIME slave screens. Also hoist the hotspot translation out from xf86ScreenMoveCursor to xf86MoveCursor, since the hotspot position is a property of the cursor, not the screen. Signed-off-by: Michel Dänzer --- hw/xfree86/ramdac/xf86HWCurs.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/hw/xfree86/ramdac/xf86HWCurs.c b/hw/xfree86/ramdac/xf86HWCurs.c index e8966ed..8feb767 100644 --- a/hw/xfree86/ramdac/xf86HWCurs.c +++ b/hw/xfree86/ramdac/xf86HWCurs.c @@ -263,8 +263,8 @@ xf86ScreenMoveCursor(ScreenPtr pScreen, int x, int y) xf86CursorScreenKey); xf86CursorInfoPtr infoPtr = ScreenPriv->CursorInfoPtr; - x -= infoPtr->pScrn->frameX0 + ScreenPriv->HotX; - y -= infoPtr->pScrn->frameY0 + ScreenPriv->HotY; + x -= infoPtr->pScrn->frameX0; + y -= infoPtr->pScrn->frameY0; (*infoPtr->SetCursorPosition) (infoPtr->pScrn, x, y); } @@ -272,8 +272,12 @@ xf86ScreenMoveCursor(ScreenPtr pScreen, int x, int y) void xf86MoveCursor(ScreenPtr pScreen, int x, int y) { + CursorPtr pCurs = xf86CurrentCursor(pScreen); ScreenPtr pSlave; + x -= pCurs->bits->xhot; + y -= pCurs->bits->yhot; + xf86ScreenMoveCursor(pScreen, x, y); /* ask each slave driver to move the cursor */ -- 2.9.3 From michel at daenzer.net Wed Oct 5 09:41:35 2016 From: michel at daenzer.net (=?UTF-8?q?Michel=20D=C3=A4nzer?=) Date: Wed, 5 Oct 2016 18:41:35 +0900 Subject: [PATCH xserver 0/3] xf86Cursor: Fix HW cursor positioning issues Message-ID: <20161005094138.23641-1-michel@daenzer.net> From: Michel Dänzer I wanted to enable HW cursors on PRIME slave screens in our drivers, but noticed that a few things aren't quite right yet. The series is ordered from the most obvious problem to more subtle ones. Patches 1 & 2 fix incorrect positioning of the HW cursor on PRIME slave screens. Patch 3 fixes a subtle issue which I noticed while debugging the PRIME slave screen issues, but which affects non-PRIME screens as well. Michel Dänzer (3): xf86Cursor: Use CursoreRec::bits->x/yhot in xf86MoveCursor xf86Cursor: Use CursoreRec::bits->x/yhot in xf86SetCursor xf86Cursor: Take the input lock in xf86Set/MoveCursor hw/xfree86/ramdac/xf86HWCurs.c | 32 +++++++++++++++++++++++++------- 1 file changed, 25 insertions(+), 7 deletions(-) -- 2.9.3 From michel at daenzer.net Wed Oct 5 09:41:37 2016 From: michel at daenzer.net (=?UTF-8?q?Michel=20D=C3=A4nzer?=) Date: Wed, 5 Oct 2016 18:41:37 +0900 Subject: [PATCH xserver 2/3] xf86Cursor: Use CursoreRec::bits->x/yhot in xf86SetCursor In-Reply-To: <20161005094138.23641-1-michel@daenzer.net> References: <20161005094138.23641-1-michel@daenzer.net> Message-ID: <20161005094138.23641-3-michel@daenzer.net> From: Michel Dänzer xf86CursorScreenRec::HotX/Y contain 0 for PRIME slave screens. Fixes intermittent incorrect HW cursor position on PRIME slave screens when switching between cursors with different hotspot positions. Also hoist the hotspot translation out from xf86ScreenSetCursor to xf86SetCursor, since the hotspot position is a property of the cursor, not the screen. Signed-off-by: Michel Dänzer --- hw/xfree86/ramdac/xf86HWCurs.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/hw/xfree86/ramdac/xf86HWCurs.c b/hw/xfree86/ramdac/xf86HWCurs.c index 8feb767..ddfd7c4 100644 --- a/hw/xfree86/ramdac/xf86HWCurs.c +++ b/hw/xfree86/ramdac/xf86HWCurs.c @@ -179,8 +179,8 @@ xf86ScreenSetCursor(ScreenPtr pScreen, CursorPtr pCurs, int x, int y) bits = dixLookupScreenPrivate(&pCurs->devPrivates, CursorScreenKey, pScreen); - x -= infoPtr->pScrn->frameX0 + ScreenPriv->HotX; - y -= infoPtr->pScrn->frameY0 + ScreenPriv->HotY; + x -= infoPtr->pScrn->frameX0; + y -= infoPtr->pScrn->frameY0; if (!pCurs->bits->argb || !xf86DriverHasLoadCursorARGB(infoPtr)) if (!bits) { @@ -213,6 +213,9 @@ xf86SetCursor(ScreenPtr pScreen, CursorPtr pCurs, int x, int y) { ScreenPtr pSlave; + x -= pCurs->bits->xhot; + y -= pCurs->bits->yhot; + if (!xf86ScreenSetCursor(pScreen, pCurs, x, y)) return FALSE; -- 2.9.3 From michel at daenzer.net Wed Oct 5 09:41:38 2016 From: michel at daenzer.net (=?UTF-8?q?Michel=20D=C3=A4nzer?=) Date: Wed, 5 Oct 2016 18:41:38 +0900 Subject: [PATCH xserver 3/3] xf86Cursor: Take the input lock in xf86Set/MoveCursor In-Reply-To: <20161005094138.23641-1-michel@daenzer.net> References: <20161005094138.23641-1-michel@daenzer.net> Message-ID: <20161005094138.23641-4-michel@daenzer.net> From: Michel Dänzer Prevents the HW cursor from intermittently jumping around when the cursor image is changed while the cursor is being moved. This is hardly noticeable in normal operation but can be quite confusing when stepping through these codepaths in a debugger. Signed-off-by: Michel Dänzer --- hw/xfree86/ramdac/xf86HWCurs.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/hw/xfree86/ramdac/xf86HWCurs.c b/hw/xfree86/ramdac/xf86HWCurs.c index ddfd7c4..c2ea395 100644 --- a/hw/xfree86/ramdac/xf86HWCurs.c +++ b/hw/xfree86/ramdac/xf86HWCurs.c @@ -212,12 +212,15 @@ Bool xf86SetCursor(ScreenPtr pScreen, CursorPtr pCurs, int x, int y) { ScreenPtr pSlave; + Bool ret = FALSE; + + input_lock(); x -= pCurs->bits->xhot; y -= pCurs->bits->yhot; if (!xf86ScreenSetCursor(pScreen, pCurs, x, y)) - return FALSE; + goto out; /* ask each slave driver to set the cursor. */ xorg_list_for_each_entry(pSlave, &pScreen->slave_list, slave_head) { @@ -230,10 +233,14 @@ xf86SetCursor(ScreenPtr pScreen, CursorPtr pCurs, int x, int y) * otherwise both the hw and sw cursor will show. */ xf86SetCursor(pScreen, NullCursor, x, y); - return FALSE; + goto out; } } - return TRUE; + ret = TRUE; + + out: + input_unlock(); + return ret; } void @@ -278,6 +285,8 @@ xf86MoveCursor(ScreenPtr pScreen, int x, int y) CursorPtr pCurs = xf86CurrentCursor(pScreen); ScreenPtr pSlave; + input_lock(); + x -= pCurs->bits->xhot; y -= pCurs->bits->yhot; @@ -290,6 +299,8 @@ xf86MoveCursor(ScreenPtr pScreen, int x, int y) xf86ScreenMoveCursor(pSlave, x, y); } + + input_unlock(); } void -- 2.9.3 From hdegoede at redhat.com Wed Oct 5 09:45:24 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Wed, 5 Oct 2016 11:45:24 +0200 Subject: [PATCH xserver 0/3] xf86Cursor: Fix HW cursor positioning issues In-Reply-To: <20161005094138.23641-1-michel@daenzer.net> References: <20161005094138.23641-1-michel@daenzer.net> Message-ID: <4796f04f-622a-512a-c14a-e2770b811e4b@redhat.com> Hi, On 05-10-16 11:41, Michel Dänzer wrote: > From: Michel Dänzer > > I wanted to enable HW cursors on PRIME slave screens in our drivers, but > noticed that a few things aren't quite right yet. > > The series is ordered from the most obvious problem to more subtle ones. > Patches 1 & 2 fix incorrect positioning of the HW cursor on PRIME slave > screens. Patch 3 fixes a subtle issue which I noticed while debugging > the PRIME slave screen issues, but which affects non-PRIME screens as > well. Thank you for catching this. All 3 patches look good to me and are: Reviewed-by: Hans de Goede Regards, Hans > > Michel Dänzer (3): > xf86Cursor: Use CursoreRec::bits->x/yhot in xf86MoveCursor > xf86Cursor: Use CursoreRec::bits->x/yhot in xf86SetCursor > xf86Cursor: Take the input lock in xf86Set/MoveCursor > > hw/xfree86/ramdac/xf86HWCurs.c | 32 +++++++++++++++++++++++++------- > 1 file changed, 25 insertions(+), 7 deletions(-) > From hdegoede at redhat.com Wed Oct 5 10:05:45 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Wed, 5 Oct 2016 12:05:45 +0200 Subject: [PATCH xserver 0/3] xf86Cursor: Fix HW cursor positioning issues In-Reply-To: <4796f04f-622a-512a-c14a-e2770b811e4b@redhat.com> References: <20161005094138.23641-1-michel@daenzer.net> <4796f04f-622a-512a-c14a-e2770b811e4b@redhat.com> Message-ID: Hi, On 05-10-16 11:45, Hans de Goede wrote: > Hi, > > On 05-10-16 11:41, Michel Dänzer wrote: >> From: Michel Dänzer >> >> I wanted to enable HW cursors on PRIME slave screens in our drivers, but >> noticed that a few things aren't quite right yet. >> >> The series is ordered from the most obvious problem to more subtle ones. >> Patches 1 & 2 fix incorrect positioning of the HW cursor on PRIME slave >> screens. Patch 3 fixes a subtle issue which I noticed while debugging >> the PRIME slave screen issues, but which affects non-PRIME screens as >> well. > > Thank you for catching this. All 3 patches look good to me and are: > > Reviewed-by: Hans de Goede Scrap that, this needs a v2, while debugging another issue with these 3 patches added to my local tree I'm get segfaults because pCurs->bits can be NULL in at least xf86SetCursor and we end up dereferencing a NULL pointer. Regards, Hans From emil.l.velikov at gmail.com Wed Oct 5 11:44:52 2016 From: emil.l.velikov at gmail.com (Emil Velikov) Date: Wed, 5 Oct 2016 12:44:52 +0100 Subject: [PATCH xserver] glamor: Use eglGetPlatformDisplayEXT not eglGetDisplay In-Reply-To: <20161004173433.12814-1-ajax@redhat.com> References: <20161004173433.12814-1-ajax@redhat.com> Message-ID: On 4 October 2016 at 18:34, Adam Jackson wrote: > eglGetDisplay forces the implementation to guess which kind of display > it's been handed. glvnd does something different from Mesa, and in > general it's impossible for the library to get this right. Instead use > the API where you specify what kind of display it is. > > The explicit call to eglGetProcAddress is to work around a bug in > libepoxy 1.3, which does not understand EGL client extensions and so its > resolver code will crash. > > Signed-off-by: Adam Jackson > --- > glamor/glamor_egl.c | 9 ++++++++- > hw/xwayland/xwayland-glamor.c | 8 +++++++- > 2 files changed, 15 insertions(+), 2 deletions(-) > > diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c > index 2b9e0e1..51d8147 100644 > --- a/glamor/glamor_egl.c > +++ b/glamor/glamor_egl.c > @@ -736,6 +736,7 @@ glamor_egl_init(ScrnInfoPtr scrn, int fd) > { > struct glamor_egl_screen_private *glamor_egl; > const char *version; > + PFNEGLGETPLATFORMDISPLAYEXTPROC getPlatformDisplay; > > EGLint config_attribs[] = { > #ifdef GLAMOR_GLES2 > @@ -768,7 +769,13 @@ glamor_egl_init(ScrnInfoPtr scrn, int fd) > ErrorF("couldn't get display device\n"); > goto error; > } > - glamor_egl->display = eglGetDisplay(glamor_egl->gbm); > + > + getPlatformDisplay = (PFNEGLGETPLATFORMDISPLAYEXTPROC) > + eglGetProcAddress("eglGetPlatformDisplayEXT"); > + > + if (getPlatformDisplay) > + glamor_egl->display = getPlatformDisplay (EGL_PLATFORM_GBM_MESA, > + glamor_egl->gbm, NULL); An implementation can return non NULL value even if the extension is not supported. So one needs to add something like: ext = eglQueryString(NO_DISPLAY, EGL_EXTENSIONS); if (ext && (has_extension(ext, "EGL_MESA_platform_gbm") || has_extension(ext, "EGL_KHR_platform_gbm")) { // your code ... } Fwiw one can even make this a static inline and use it in both places. Adding a note about epoxy is a good idea imho. > #else > glamor_egl->display = eglGetDisplay((EGLNativeDisplayType) (intptr_t) fd); > #endif We seem to be missing the error checking after we (attempt to) get the dpy. > diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c > index 068c224..23402f9 100644 > --- a/hw/xwayland/xwayland-glamor.c > +++ b/hw/xwayland/xwayland-glamor.c > @@ -280,6 +280,7 @@ xwl_drm_init_egl(struct xwl_screen *xwl_screen) > GLAMOR_GL_CORE_VER_MINOR, > EGL_NONE > }; > + PFNEGLGETPLATFORMDISPLAYEXTPROC getPlatformDisplay; > > if (xwl_screen->egl_display) > return; > @@ -292,7 +293,12 @@ xwl_drm_init_egl(struct xwl_screen *xwl_screen) > return; > } > > - xwl_screen->egl_display = eglGetDisplay(xwl_screen->gbm); > + getPlatformDisplay = (PFNEGLGETPLATFORMDISPLAYEXTPROC) > + eglGetProcAddress("eglGetPlatformDisplayEXT"); > + > + if (getPlatformDisplay) > + xwl_screen->egl_display = getPlatformDisplay(EGL_PLATFORM_GBM_MESA, > + xwl_screen->gbm, NULL); > if (xwl_screen->egl_display == EGL_NO_DISPLAY) { > ErrorF("eglGetDisplay() failed\n"); s/eglGetDisplay/eglGetPlatformDisplayEXT/ Regards, Emil P.S. Do you have some work on the final EGL_KHR_debug patches or we can land them ? From hdegoede at redhat.com Wed Oct 5 12:45:20 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Wed, 5 Oct 2016 14:45:20 +0200 Subject: [PATCH] inputthread: Fix inputthread not listening if a fd gets re-added immediately after removal Message-ID: <20161005124520.30712-1-hdegoede@redhat.com> When a fd is removed dev->state gets set to device_state_removed, if the fd then gets re-added before InputThreadDoWork() deals with the removal, the InputThreadDevice struct gets reused, but its state would stay device_state_removed, so it would still get removed on the first InputThreadDoWork() run, resulting in a non functioning input device. This commit fixes this by (re-)setting dev->state to device_state_running when a InputThreadDevice struct gets reused. This fixes input devices sometimes no longer working after a vt-switch. Signed-off-by: Hans de Goede --- os/inputthread.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/os/inputthread.c b/os/inputthread.c index 6aa0a9c..ab1559f 100644 --- a/os/inputthread.c +++ b/os/inputthread.c @@ -206,6 +206,8 @@ InputThreadRegisterDev(int fd, if (dev) { dev->readInputProc = readInputProc; dev->readInputArgs = readInputArgs; + /* Override possible unhandled state == device_state_removed */ + dev->state = device_state_running; } else { dev = calloc(1, sizeof(InputThreadDevice)); if (dev == NULL) { -- 2.9.3 From hdegoede at redhat.com Wed Oct 5 13:31:38 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Wed, 5 Oct 2016 15:31:38 +0200 Subject: [PATCH xf86-input-libinput] Fix crash when using threaded input and the first device goes away Message-ID: <20161005133138.9672-1-hdegoede@redhat.com> When the xserver uses threaded input, it keeps a pointer to the InputInfo passed into xf86AddEnabledDevice and calls pointer->read_input on events. But when the first enabled device goes away the pInfo we've passed into xf86AddEnabledDevice gets freed and eventually pInfo->read_input gets overwritten (or pInfo points to unmapped memory) leading to a segfault. This commit fixes this by replacing the pInfo passed into xf86AddEnabledDevice with a pointer to a global InputInfo stored inside the driver_context struct. Signed-off-by: Hans de Goede --- src/xf86libinput.c | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/src/xf86libinput.c b/src/xf86libinput.c index 21f87f5..485e212 100644 --- a/src/xf86libinput.c +++ b/src/xf86libinput.c @@ -86,6 +86,7 @@ struct xf86libinput_driver { struct libinput *libinput; + struct _InputInfoRec InputInfo; int device_enabled_count; }; @@ -582,7 +583,17 @@ xf86libinput_on(DeviceIntPtr dev) if (driver_context.device_enabled_count == 0) { #if HAVE_THREADED_INPUT - xf86AddEnabledDevice(pInfo); + /* + * The xserver keeps a pointer to the InputInfo passed into + * xf86AddEnabledDevice and calls pointer->read_input on + * events. Thus we cannot simply pass in our current pInfo + * as that will be deleted when the current input device gets + * unplugged. Instead pass in a pointer to a global + * InputInfo inside the driver_context. + */ + driver_context.InputInfo.fd = pInfo->fd; + driver_context.InputInfo.read_input = pInfo->read_input; + xf86AddEnabledDevice(&driver_context.InputInfo); #else /* Can't use xf86AddEnabledDevice on an epollfd */ AddEnabledDevice(pInfo->fd); @@ -606,7 +617,7 @@ xf86libinput_off(DeviceIntPtr dev) if (--driver_context.device_enabled_count == 0) { #if HAVE_THREADED_INPUT - xf86RemoveEnabledDevice(pInfo); + xf86RemoveEnabledDevice(&driver_context.InputInfo); #else RemoveEnabledDevice(pInfo->fd); #endif @@ -1923,7 +1934,7 @@ out: } static void -xf86libinput_read_input(InputInfoPtr pInfo) +xf86libinput_read_input(InputInfoPtr do_not_use) { struct libinput *libinput = driver_context.libinput; int rc; @@ -1934,9 +1945,8 @@ xf86libinput_read_input(InputInfoPtr pInfo) return; if (rc < 0) { - xf86IDrvMsg(pInfo, X_ERROR, - "Error reading events: %s\n", - strerror(-rc)); + xf86Msg(X_ERROR, "Error reading libinput events: %s\n", + strerror(-rc)); return; } -- 2.9.3 From hdegoede at redhat.com Wed Oct 5 13:33:45 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Wed, 5 Oct 2016 15:33:45 +0200 Subject: [PATCH xf86-input-libinput] Fix crash when using threaded input and the first device goes away In-Reply-To: <20161005133138.9672-1-hdegoede@redhat.com> References: <20161005133138.9672-1-hdegoede@redhat.com> Message-ID: Hi, On 05-10-16 15:31, Hans de Goede wrote: > When the xserver uses threaded input, it keeps a pointer to the InputInfo > passed into xf86AddEnabledDevice and calls pointer->read_input on events. > > But when the first enabled device goes away the pInfo we've passed into > xf86AddEnabledDevice gets freed and eventually pInfo->read_input gets > overwritten (or pInfo points to unmapped memory) leading to a segfault. > > This commit fixes this by replacing the pInfo passed into > xf86AddEnabledDevice with a pointer to a global InputInfo stored inside > the driver_context struct. > > Signed-off-by: Hans de Goede Forgot to add a buglink, this fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1381840 Regards, Hans > --- > src/xf86libinput.c | 22 ++++++++++++++++------ > 1 file changed, 16 insertions(+), 6 deletions(-) > > diff --git a/src/xf86libinput.c b/src/xf86libinput.c > index 21f87f5..485e212 100644 > --- a/src/xf86libinput.c > +++ b/src/xf86libinput.c > @@ -86,6 +86,7 @@ > > struct xf86libinput_driver { > struct libinput *libinput; > + struct _InputInfoRec InputInfo; > int device_enabled_count; > }; > > @@ -582,7 +583,17 @@ xf86libinput_on(DeviceIntPtr dev) > > if (driver_context.device_enabled_count == 0) { > #if HAVE_THREADED_INPUT > - xf86AddEnabledDevice(pInfo); > + /* > + * The xserver keeps a pointer to the InputInfo passed into > + * xf86AddEnabledDevice and calls pointer->read_input on > + * events. Thus we cannot simply pass in our current pInfo > + * as that will be deleted when the current input device gets > + * unplugged. Instead pass in a pointer to a global > + * InputInfo inside the driver_context. > + */ > + driver_context.InputInfo.fd = pInfo->fd; > + driver_context.InputInfo.read_input = pInfo->read_input; > + xf86AddEnabledDevice(&driver_context.InputInfo); > #else > /* Can't use xf86AddEnabledDevice on an epollfd */ > AddEnabledDevice(pInfo->fd); > @@ -606,7 +617,7 @@ xf86libinput_off(DeviceIntPtr dev) > > if (--driver_context.device_enabled_count == 0) { > #if HAVE_THREADED_INPUT > - xf86RemoveEnabledDevice(pInfo); > + xf86RemoveEnabledDevice(&driver_context.InputInfo); > #else > RemoveEnabledDevice(pInfo->fd); > #endif > @@ -1923,7 +1934,7 @@ out: > } > > static void > -xf86libinput_read_input(InputInfoPtr pInfo) > +xf86libinput_read_input(InputInfoPtr do_not_use) > { > struct libinput *libinput = driver_context.libinput; > int rc; > @@ -1934,9 +1945,8 @@ xf86libinput_read_input(InputInfoPtr pInfo) > return; > > if (rc < 0) { > - xf86IDrvMsg(pInfo, X_ERROR, > - "Error reading events: %s\n", > - strerror(-rc)); > + xf86Msg(X_ERROR, "Error reading libinput events: %s\n", > + strerror(-rc)); > return; > } > > From keithp at keithp.com Wed Oct 5 16:23:23 2016 From: keithp at keithp.com (Keith Packard) Date: Wed, 05 Oct 2016 09:23:23 -0700 Subject: [PATCH] inputthread: Fix inputthread not listening if a fd gets re-added immediately after removal In-Reply-To: <20161005124520.30712-1-hdegoede@redhat.com> References: <20161005124520.30712-1-hdegoede@redhat.com> Message-ID: <86r37uzrwk.fsf@hiro.keithp.com> Hans de Goede writes: > When a fd is removed dev->state gets set to device_state_removed, > if the fd then gets re-added before InputThreadDoWork() deals with > the removal, the InputThreadDevice struct gets reused, but its > state would stay device_state_removed, so it would still get removed > on the first InputThreadDoWork() run, resulting in a non functioning > input device. > > This commit fixes this by (re-)setting dev->state to device_state_running > when a InputThreadDevice struct gets reused. > > This fixes input devices sometimes no longer working after a vt-switch. > > Signed-off-by: Hans de Goede Reviewed-by: Keith Packard -- -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From keithp at keithp.com Wed Oct 5 16:24:43 2016 From: keithp at keithp.com (Keith Packard) Date: Wed, 05 Oct 2016 09:24:43 -0700 Subject: [PATCH xserver] test: Use $XSERVER_BUILDDIR for Xvfb executable path In-Reply-To: <20161005082936.1985-1-michel@daenzer.net> References: <20161005082936.1985-1-michel@daenzer.net> Message-ID: <86oa2yzruc.fsf@hiro.keithp.com> Michel Dänzer writes: > From: Michel Dänzer > > Fixes make check with out-of-tree builds. > > Signed-off-by: Michel Dänzer Reviewed-by: Keith Packard -- -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From ajax at redhat.com Wed Oct 5 16:34:34 2016 From: ajax at redhat.com (Adam Jackson) Date: Wed, 5 Oct 2016 12:34:34 -0400 Subject: [PATCH xserver] glamor: Use eglGetPlatformDisplay{,EXT} if we can Message-ID: <20161005163434.2367-1-ajax@redhat.com> eglGetDisplay forces the implementation to guess which kind of display it's been handed. glvnd does something different from Mesa, and in general it's impossible for the library to get this right. Add a new inline that gets the logic right, and works around a quirk in epoxy. Signed-off-by: Adam Jackson --- glamor/Makefile.am | 4 ++- glamor/glamor_egl.c | 8 ++--- glamor/glamor_egl.h | 82 +++++++++++++++++++++++++++++++++++++++++++ hw/xwayland/xwayland-glamor.c | 8 ++--- 4 files changed, 93 insertions(+), 9 deletions(-) create mode 100644 glamor/glamor_egl.h diff --git a/glamor/Makefile.am b/glamor/Makefile.am index c631c53..8c79994 100644 --- a/glamor/Makefile.am +++ b/glamor/Makefile.am @@ -54,6 +54,8 @@ libglamor_la_SOURCES += \ glamor_xv.c endif -libglamor_egl_stubs_la_SOURCES = glamor_egl_stubs.c +libglamor_egl_stubs_la_SOURCES = \ + glamor_egl_stubs.c \ + glamor_egl.h sdk_HEADERS = glamor.h diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c index 2b9e0e1..9cc0f8d 100644 --- a/glamor/glamor_egl.c +++ b/glamor/glamor_egl.c @@ -43,9 +43,7 @@ #include #endif -#define MESA_EGL_NO_X11_HEADERS -#include -#include +#include "glamor_egl.h" #include "glamor.h" #include "glamor_priv.h" @@ -768,7 +766,9 @@ glamor_egl_init(ScrnInfoPtr scrn, int fd) ErrorF("couldn't get display device\n"); goto error; } - glamor_egl->display = eglGetDisplay(glamor_egl->gbm); + + glamor_egl->display = glamor_egl_get_display(EGL_PLATFORM_GBM_MESA, + glamor_egl->gbm); #else glamor_egl->display = eglGetDisplay((EGLNativeDisplayType) (intptr_t) fd); #endif diff --git a/glamor/glamor_egl.h b/glamor/glamor_egl.h new file mode 100644 index 0000000..147aae6 --- /dev/null +++ b/glamor/glamor_egl.h @@ -0,0 +1,82 @@ +/* + * Copyright © 2016 Red Hat, Inc. + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER + * DEALINGS IN THE SOFTWARE. + * + * Authors: + * Adam Jackson + */ + +#ifndef GLAMOR_EGL_H +#define GLAMOR_EGL_H + +#define MESA_EGL_NO_X11_HEADERS +#include +#include + +/* + * Create an EGLDisplay from a native display type. This is a little quirky + * for a few reasons. + * + * 1: GetPlatformDisplayEXT and GetPlatformDisplay are the API you want to + * use, but have different function signatures in the third argument; this + * happens not to matter for us, at the moment, but it means epoxy won't alias + * them together. + * + * 2: epoxy 1.3 and earlier don't understand EGL client extensions, which + * means you can't call "eglGetPlatformDisplayEXT" directly, as the resolver + * will crash. + * + * 3: You can't tell whether you have EGL 1.5 at this point, because + * eglQueryString(EGL_VERSION) is a property of the display, which we don't + * have yet. So you have to query for extensions no matter what. Fortunately + * epoxy_has_egl_extension _does_ let you query for client extensions, so + * we don't have to write our own extension string parsing. + */ +static inline EGLDisplay +glamor_egl_get_display(EGLint type, void *native) +{ + EGLDisplay dpy = NULL; + + /* If we're EGL 1.5, the KHR extension will be there, try that */ + if (epoxy_has_egl_extension(NULL, "EGL_KHR_platform_base")) { + PFNEGLGETPLATFORMDISPLAYPROC getPlatformDisplay = + (void *) eglGetProcAddress("eglGetPlatformDisplay"); + if (getPlatformDisplay) + dpy = getPlatformDisplay(type, native, NULL); + if (dpy) + return dpy; + } + + /* Okay, maybe the EXT extension works */ + if (epoxy_has_egl_extension(NULL, "EGL_EXT_platform_base")) { + PFNEGLGETPLATFORMDISPLAYEXTPROC getPlatformDisplayEXT = + (void *) eglGetProcAddress("eglGetPlatformDisplayEXT"); + if (getPlatformDisplayEXT) + dpy = getPlatformDisplayEXT(type, native, NULL); + if (dpy) + return dpy; + } + + /* Welp, everything is awful. */ + return eglGetDisplay(native); +} + +#endif diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c index 068c224..b3d0aab 100644 --- a/hw/xwayland/xwayland-glamor.c +++ b/hw/xwayland/xwayland-glamor.c @@ -31,8 +31,7 @@ #define MESA_EGL_NO_X11_HEADERS #include -#include -#include +#include #include #include @@ -292,9 +291,10 @@ xwl_drm_init_egl(struct xwl_screen *xwl_screen) return; } - xwl_screen->egl_display = eglGetDisplay(xwl_screen->gbm); + xwl_screen->egl_display = glamor_egl_get_display(EGL_PLATFORM_GBM_MESA, + xwl_screen->gbm); if (xwl_screen->egl_display == EGL_NO_DISPLAY) { - ErrorF("eglGetDisplay() failed\n"); + ErrorF("glamor_egl_get_display() failed\n"); return; } -- 2.9.3 From keithp at keithp.com Wed Oct 5 16:42:19 2016 From: keithp at keithp.com (Keith Packard) Date: Wed, 5 Oct 2016 09:42:19 -0700 Subject: [PATCH xserver] ephyr: Leave window unmapped for -glamor-skip-present Message-ID: <20161005164219.32641-1-keithp@keithp.com> If we're never painting anything in the window, we probably don't need to map it. Signed-off-by: Keith Packard --- hw/kdrive/ephyr/hostx.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/hw/kdrive/ephyr/hostx.c b/hw/kdrive/ephyr/hostx.c index 887f654..f49ed02 100644 --- a/hw/kdrive/ephyr/hostx.c +++ b/hw/kdrive/ephyr/hostx.c @@ -95,6 +95,7 @@ char *ephyrResName = NULL; int ephyrResNameFromCmd = 0; char *ephyrTitle = NULL; Bool ephyr_glamor = FALSE; +extern Bool ephyr_glamor_gles2, ephyr_glamor_skip_present; Bool hostx_has_extension(xcb_extension_t *extension) @@ -898,7 +899,10 @@ hostx_screen_init(KdScreenInfo *screen, &size_hints); } - xcb_map_window(HostX.conn, scrpriv->win); +#ifdef GLAMOR + if (!ephyr_glamor_skip_present) +#endif + xcb_map_window(HostX.conn, scrpriv->win); /* Set explicit window position if it was informed in * -screen option (WxH+X or WxH+X+Y). Otherwise, accept the -- 2.9.3 From eric at anholt.net Wed Oct 5 17:29:39 2016 From: eric at anholt.net (Eric Anholt) Date: Wed, 05 Oct 2016 10:29:39 -0700 Subject: [PATCH xserver] glamor: Use eglGetPlatformDisplay{, EXT} if we can In-Reply-To: <20161005163434.2367-1-ajax@redhat.com> References: <20161005163434.2367-1-ajax@redhat.com> Message-ID: <87y422u2kc.fsf@eliezer.anholt.net> Adam Jackson writes: > eglGetDisplay forces the implementation to guess which kind of display > it's been handed. glvnd does something different from Mesa, and in > general it's impossible for the library to get this right. Add a new > inline that gets the logic right, and works around a quirk in epoxy. Reviewed-by: Eric Anholt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From eric at anholt.net Wed Oct 5 17:32:22 2016 From: eric at anholt.net (Eric Anholt) Date: Wed, 05 Oct 2016 10:32:22 -0700 Subject: [PATCH xserver] ephyr: Leave window unmapped for -glamor-skip-present In-Reply-To: <20161005164219.32641-1-keithp@keithp.com> References: <20161005164219.32641-1-keithp@keithp.com> Message-ID: <87vax6u2ft.fsf@eliezer.anholt.net> Keith Packard writes: > If we're never painting anything in the window, we probably don't need > to map it. > > Signed-off-by: Keith Packard Drop the extern ephyr_glamor_gles2 and it's: Reviewed-by: Eric Anholt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From eric at anholt.net Wed Oct 5 17:34:59 2016 From: eric at anholt.net (Eric Anholt) Date: Wed, 05 Oct 2016 10:34:59 -0700 Subject: [PATCH xserver] test: Use $XSERVER_BUILDDIR for Xvfb executable path In-Reply-To: <20161005082936.1985-1-michel@daenzer.net> References: <20161005082936.1985-1-michel@daenzer.net> Message-ID: <87shsau2bg.fsf@eliezer.anholt.net> Michel Dänzer writes: > From: Michel Dänzer > > Fixes make check with out-of-tree builds. > > Signed-off-by: Michel Dänzer > --- > test/scripts/xvfb-piglit.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/test/scripts/xvfb-piglit.sh b/test/scripts/xvfb-piglit.sh > index 799f285..763599e 100755 > --- a/test/scripts/xvfb-piglit.sh > +++ b/test/scripts/xvfb-piglit.sh > @@ -1,4 +1,4 @@ > -export SERVER_COMMAND="$XSERVER_DIR/hw/vfb/Xvfb \ > +export SERVER_COMMAND="$XSERVER_BUILDDIR/hw/vfb/Xvfb \ > -noreset \ > -screen scrn 1280x1024x24" > export PIGLIT_RESULTS_DIR=$XSERVER_BUILDDIR/test/piglit-results/xvfb Thanks. I tried to be careful about it when writing these scripts, but I don't do OOT myself. Once I get that Travis script done, that will do OOT builds, at least. Reviewed-by: Eric Anholt -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From ajax at nwnk.net Wed Oct 5 17:38:50 2016 From: ajax at nwnk.net (Adam Jackson) Date: Wed, 05 Oct 2016 13:38:50 -0400 Subject: [PATCH xserver 0/2] xwayland touch handling fixes In-Reply-To: <20160927170326.4213-1-carlosg@gnome.org> References: <20160927170326.4213-1-carlosg@gnome.org> Message-ID: <1475689130.18300.11.camel@nwnk.net> On Tue, 2016-09-27 at 19:03 +0200, Carlos Garnacho wrote: > Hi! > > I'm sending a couple of fixes to fix touch handling in wayland. The > first patch makes the XYToWindow proc handler friendlier to touch-driven > pointer emulation (and possibly other pointer-driving devices in the > future with standalone foci in wayland, like tablets). > > The second patch makes the coordinate space consistent in xwayland, so > it's not affected by changes in output configuration. It makes touch > events work through output geometry/mode changes. Merged (with an 80-column comment formatting fixup): remote: E: failed to find patch for rev ee526285882995289846648f3122c4295e3e8284. remote: I: patch #112413 updated using rev bbd4854f81ebba1119202c5f6ff4679c62afec1f. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver 2b6a068..bbd4854 master -> master - ajax From ajax at nwnk.net Wed Oct 5 17:54:39 2016 From: ajax at nwnk.net (Adam Jackson) Date: Wed, 05 Oct 2016 13:54:39 -0400 Subject: [PATCH xserver 01/14 v2] dix: Introduce CursorWarpedTo vfunc in Screen In-Reply-To: <1473751028-28141-1-git-send-email-jadahl@gmail.com> References: <1473751028-28141-1-git-send-email-jadahl@gmail.com> Message-ID: <1475690079.18300.13.camel@nwnk.net> On Tue, 2016-09-13 at 15:16 +0800, Jonas Ådahl wrote: > This new vfunc will be called, if set, after a client has issued a > WarpPointer request. This is necessary for implementing pointer warp > emulation in Xwayland. > > Signed-off-by: Jonas Ådahl > Reviewed-by: Peter Hutterer Merged: remote: I: patch #109450 updated using rev 0fae3be0686cae746e03d6e4592f97278cc2275d. remote: I: patch #112668 updated using rev 9037ba736a0424feee2fb6ac20cf7687613dc452. remote: I: patch #109452 updated using rev a77d0715c6272cc1778a54dccd8cb68dc28cd761. remote: I: patch #110153 updated using rev 011ada724afdba8955f1d4844b306e61390eead8. remote: I: patch #110220 updated using rev 42e8902395cb27af5c28306abd577a92c467a62d. remote: I: patch #109454 updated using rev aa9634d03bc2434dfd25476529eccb14e46fcfdc. remote: I: patch #109455 updated using rev b4644ce8d3420447a8e5a2339238968da0a59de7. remote: I: patch #109456 updated using rev c14a8c6cc0fcd56c380d1220c2a8f04b74edee93. remote: I: patch #112669 updated using rev ca7b593fbe54bc9a0b44037e62e4b4401cbd375e. remote: I: patch #109458 updated using rev 467ab142fff926e1475440dd5f649a49f45808fa. remote: I: patch #110160 updated using rev a6e85e6330adcdcbcd939c0963daaecc96d41a2a. remote: I: 11 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver bbd4854..a6e85e6 master -> master - ajax From ajax at nwnk.net Wed Oct 5 18:11:30 2016 From: ajax at nwnk.net (Adam Jackson) Date: Wed, 05 Oct 2016 14:11:30 -0400 Subject: [PATCH v2 xserver] glamor: Fix pixmap offset for bitplane in glamor_copy_fbo_cpu In-Reply-To: <20161005063621.32649-1-ofourdan@redhat.com> References: <295104e6-f49b-96a8-dd55-d65aae10df1d@daenzer.net> <20161005063621.32649-1-ofourdan@redhat.com> Message-ID: <1475691090.18300.16.camel@nwnk.net> On Wed, 2016-10-05 at 08:36 +0200, Olivier Fourdan wrote: > Commit cba28d5 - "glamor: Handle bitplane in glamor_copy_fbo_cpu" > introduced a regression as the computed pixmap offset would not match > the actual coordinates and write data elsewhere in memory causing a > segfault in fbBltOne(). > > Translate the pixmap coordinates so that the data is read and written at > the correct location. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97974 > Signed-off-by: Olivier Fourdan > Reviewed-and-Tested-by: Michel Dänzer Merged: remote: I: patch #113688 updated using rev 1c2fcb95484777ca9aa80b3f814ad64e81f825f1. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver a6e85e6..1c2fcb9 master -> master - ajax From ajax at redhat.com Wed Oct 5 18:34:44 2016 From: ajax at redhat.com (Adam Jackson) Date: Wed, 05 Oct 2016 14:34:44 -0400 Subject: [PATCH 1/3] glx: drisw is not accelerated IGLX, reflect that in log messages In-Reply-To: <20160929174119.14505-1-emil.l.velikov@gmail.com> References: <20160929174119.14505-1-emil.l.velikov@gmail.com> Message-ID: <1475692484.18300.17.camel@redhat.com> On Thu, 2016-09-29 at 18:41 +0100, Emil Velikov wrote: > The messages from glxdricommon.c (used by drisw) still have the A, but > at least we're don't have it locally. > > Cc: Adam Jackson > Signed-off-by: Emil Velikov Series merged (with fixup for win32 DRI support in configure.ac): remote: I: patch #112865 updated using rev 04ef8558a731bf070abf1b40c7e6b54aad8f5f31. remote: I: patch #112867 updated using rev 7ec350ddd42479595f0ea88f86085af941913617. remote: E: failed to find patch for rev 501d8e2beb337e072c93c9310fcd927a099b9c3b. remote: I: 2 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver 1c2fcb9..501d8e2 master -> master - ajax From ajax at nwnk.net Wed Oct 5 18:50:30 2016 From: ajax at nwnk.net (Adam Jackson) Date: Wed, 05 Oct 2016 14:50:30 -0400 Subject: [PATCH 1/4] configure.ac: default to DRI=yes on solaris platforms In-Reply-To: <20160929173504.14312-1-emil.l.velikov@gmail.com> References: <20160929173504.14312-1-emil.l.velikov@gmail.com> Message-ID: <1475693430.18300.18.camel@nwnk.net> On Thu, 2016-09-29 at 18:35 +0100, Emil Velikov wrote: > Afaict there's little-to-no reason/way one would want xserver without > DRI support on Solaris platforms. > > This will allow us to simplify/fix all the libdrm detection in the next > commit. Series merged (with trivial fixup for xwayland's libdrm req): remote: I: patch #112860 updated using rev 45e1220486139c483a69366323f8f590beffa19d. remote: E: failed to find patch for rev 74a8b320fa5068cd86d8b8b8e73fa92caae9a8a6. remote: I: patch #112862 updated using rev 962962e978e5cededc20e577a36f77eb24d14bda. remote: I: patch #112863 updated using rev cc69d4f110bd8a87b9e6c238ebebf8d85cbd93ec. remote: I: 3 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver 501d8e2..cc69d4f master -> master - ajax From ajax at nwnk.net Wed Oct 5 19:33:53 2016 From: ajax at nwnk.net (Adam Jackson) Date: Wed, 05 Oct 2016 15:33:53 -0400 Subject: [PATCH xserver 1/3] xfree86: Immediately handle failure to set HW cursor, v5 In-Reply-To: <20160930155553.26858-1-michael.thayer@oracle.com> References: <20160930155553.26858-1-michael.thayer@oracle.com> Message-ID: <1475696033.18300.22.camel@nwnk.net> On Fri, 2016-09-30 at 17:55 +0200, Michael Thayer wrote: > > > v5: Updated the patch to apply to current git HEAD, split up into two > patches (server and modesetting driver) and adjusted the code slightly > to match surrounding code.  I also removed the new exported function > ShowCursorCheck(), as instead just changing ShowCursor() to return Bool > should not affect its current callers. I really hate that I have to say this, because it's entirely our fault for not having merged this sooner in the cycle, but this is an ABI break we can't take after RC1. By changing the layout of xf86CrtcFuncsRec, drivers built against RC1 will fail when run against RC2. Even adding show_cursor_check to the end of the struct won't help, because the server then can't know if the final slot in the struct contains valid data. I have a workaround in mind that will preserve ABI, I'll send it along shortly. - ajax From ajax at nwnk.net Wed Oct 5 19:36:30 2016 From: ajax at nwnk.net (Adam Jackson) Date: Wed, 05 Oct 2016 15:36:30 -0400 Subject: [PATCH xserver] test: Use $XSERVER_BUILDDIR for Xvfb executable path In-Reply-To: <87shsau2bg.fsf@eliezer.anholt.net> References: <20161005082936.1985-1-michel@daenzer.net> <87shsau2bg.fsf@eliezer.anholt.net> Message-ID: <1475696190.18300.24.camel@nwnk.net> On Wed, 2016-10-05 at 10:34 -0700, Eric Anholt wrote: > Reviewed-by: Eric Anholt Merged: remote: I: patch #113692 updated using rev 95d3980c7c991b2cc8dcadac173635641ae15865. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver cc69d4f..95d3980 master -> master - ajax From michael.thayer at oracle.com Wed Oct 5 19:45:36 2016 From: michael.thayer at oracle.com (Michael Thayer) Date: Wed, 5 Oct 2016 21:45:36 +0200 Subject: [PATCH xserver 1/3] xfree86: Immediately handle failure to set HW cursor, v5 In-Reply-To: <1475696033.18300.22.camel@nwnk.net> References: <20160930155553.26858-1-michael.thayer@oracle.com> <1475696033.18300.22.camel@nwnk.net> Message-ID: <4be17710-4157-f1ac-a9b2-fb50171361e3@oracle.com> Hello Adam, On 05.10.2016 21:33, Adam Jackson wrote: > On Fri, 2016-09-30 at 17:55 +0200, Michael Thayer wrote: > >>> >> v5: Updated the patch to apply to current git HEAD, split up into two >> patches (server and modesetting driver) and adjusted the code slightly >> to match surrounding code. I also removed the new exported function >> ShowCursorCheck(), as instead just changing ShowCursor() to return Bool >> should not affect its current callers. > > I really hate that I have to say this, because it's entirely our fault > for not having merged this sooner in the cycle, but this is an ABI > break we can't take after RC1. By changing the layout of > xf86CrtcFuncsRec, drivers built against RC1 will fail when run against > RC2. Even adding show_cursor_check to the end of the struct won't help, > because the server then can't know if the final slot in the struct > contains valid data. > > I have a workaround in mind that will preserve ABI, I'll send it along > shortly. Thanks for looking at it. The question though, is whether it still makes sense to try to merge it for 1.19 or to wait for 1.20, which I think is Hans' preferred option. I must say that if it means it will get more testing before becoming part of a release then I tend to lean that way too. A few pairs of eyes checking the code is good, but not as good as real use. Regards, Michael > > - ajax > -- Michael Thayer | VirtualBox engineer ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher From jcristau at debian.org Wed Oct 5 20:21:04 2016 From: jcristau at debian.org (Julien Cristau) Date: Wed, 5 Oct 2016 22:21:04 +0200 Subject: [PATCH xserver] ephyr: Leave window unmapped for -glamor-skip-present In-Reply-To: <20161005164219.32641-1-keithp@keithp.com> References: <20161005164219.32641-1-keithp@keithp.com> Message-ID: <20161005202104.geqnmnqepydxnukt@betterave.cristau.org> On Wed, Oct 5, 2016 at 09:42:19 -0700, Keith Packard wrote: > If we're never painting anything in the window, we probably don't need > to map it. > > Signed-off-by: Keith Packard > --- > hw/kdrive/ephyr/hostx.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/hw/kdrive/ephyr/hostx.c b/hw/kdrive/ephyr/hostx.c > index 887f654..f49ed02 100644 > --- a/hw/kdrive/ephyr/hostx.c > +++ b/hw/kdrive/ephyr/hostx.c > @@ -95,6 +95,7 @@ char *ephyrResName = NULL; > int ephyrResNameFromCmd = 0; > char *ephyrTitle = NULL; > Bool ephyr_glamor = FALSE; > +extern Bool ephyr_glamor_gles2, ephyr_glamor_skip_present; > > Bool > hostx_has_extension(xcb_extension_t *extension) The extern ephyr_glamor_skip_present declaration should probably live in ephyr_glamor_glx.h so mismatches between it and ephyr_glamor_glx.c are caught. Cheers, Julien From ajax at redhat.com Wed Oct 5 20:38:51 2016 From: ajax at redhat.com (Adam Jackson) Date: Wed, 05 Oct 2016 16:38:51 -0400 Subject: [PATCH xserver] glamor: Use eglGetPlatformDisplay{, EXT} if we can In-Reply-To: <87y422u2kc.fsf@eliezer.anholt.net> References: <20161005163434.2367-1-ajax@redhat.com> <87y422u2kc.fsf@eliezer.anholt.net> Message-ID: <1475699931.18300.25.camel@redhat.com> On Wed, 2016-10-05 at 10:29 -0700, Eric Anholt wrote: > > Reviewed-by: Eric Anholt Merged: remote: I: patch #113802 updated using rev f4a41155479e68bf55740c1dfffafc78e4c02087. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver    95d3980..f4a4115  master -> master - ajax From keithp at keithp.com Wed Oct 5 21:24:09 2016 From: keithp at keithp.com (Keith Packard) Date: Wed, 05 Oct 2016 14:24:09 -0700 Subject: [PATCH xserver] ephyr: Leave window unmapped for -glamor-skip-present In-Reply-To: <20161005202104.geqnmnqepydxnukt@betterave.cristau.org> References: <20161005164219.32641-1-keithp@keithp.com> <20161005202104.geqnmnqepydxnukt@betterave.cristau.org> Message-ID: <86ponexzeu.fsf@hiro.keithp.com> Julien Cristau writes: > The extern ephyr_glamor_skip_present declaration should probably live in > ephyr_glamor_glx.h so mismatches between it and ephyr_glamor_glx.c are > caught. Agreed; I was following the existing practice (and being a bit lazy). -- -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From keithp at keithp.com Wed Oct 5 22:08:18 2016 From: keithp at keithp.com (Keith Packard) Date: Wed, 05 Oct 2016 15:08:18 -0700 Subject: [PATCH xserver] dix: Bump MAXHASHSIZE for the resource db In-Reply-To: <20160929151617.27347-1-ajax@redhat.com> References: <20160929151617.27347-1-ajax@redhat.com> Message-ID: <86k2dmxxd9.fsf@hiro.keithp.com> Adam Jackson writes: > From: Roberto Ragusa > > [This was originally a workaround for a client-side resource leak: > > http://lists.freedesktop.org/archives/xorg-devel/2012-November/034555.html > > Obviously that's a broken app, but the performance problem it > illustrates - that walking the linked list ends up burning all your CPU > time - is real enough. - ajax] > > Reviewed-by: Adam Jackson Can we just eliminate the silly switch and compute the "right" values to use here? This computes the same value for numBits from 6-16, except for 7 (which just looks wrong). -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-dix-Bump-MAXHASHSIZE-for-the-resource-db-v2.patch Type: text/x-diff Size: 2260 bytes Desc: not available URL: -------------- next part -------------- -- -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From michel at daenzer.net Thu Oct 6 03:22:09 2016 From: michel at daenzer.net (=?UTF-8?Q?Michel_D=c3=a4nzer?=) Date: Thu, 6 Oct 2016 12:22:09 +0900 Subject: [PATCH xserver 0/3] xf86Cursor: Fix HW cursor positioning issues In-Reply-To: References: <20161005094138.23641-1-michel@daenzer.net> <4796f04f-622a-512a-c14a-e2770b811e4b@redhat.com> Message-ID: On 05/10/16 07:05 PM, Hans de Goede wrote: > On 05-10-16 11:45, Hans de Goede wrote: >> On 05-10-16 11:41, Michel Dänzer wrote: >>> From: Michel Dänzer >>> >>> I wanted to enable HW cursors on PRIME slave screens in our drivers, but >>> noticed that a few things aren't quite right yet. >>> >>> The series is ordered from the most obvious problem to more subtle ones. >>> Patches 1 & 2 fix incorrect positioning of the HW cursor on PRIME slave >>> screens. Patch 3 fixes a subtle issue which I noticed while debugging >>> the PRIME slave screen issues, but which affects non-PRIME screens as >>> well. >> >> Thank you for catching this. All 3 patches look good to me and are: >> >> Reviewed-by: Hans de Goede > > Scrap that, this needs a v2, while debugging another issue with these > 3 patches added to my local tree I'm get segfaults because > pCurs->bits can be NULL in at least xf86SetCursor and we end up > dereferencing a NULL pointer. Ah, that's what that was. :) I saw crashes on server shutdown, but seemed to remember reading about random input thread related crashes somewhere, so I thought it was those and postponed looking into them. I'll send a v2 series, thanks for the review and testing. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer From michel at daenzer.net Thu Oct 6 09:45:15 2016 From: michel at daenzer.net (=?UTF-8?q?Michel=20D=C3=A4nzer?=) Date: Thu, 6 Oct 2016 18:45:15 +0900 Subject: [PATCH xserver v2 1/2] xf86Cursor: Use PRIME master xf86CursorScreenRec::HotX/Y for slaves In-Reply-To: <20161005094138.23641-1-michel@daenzer.net> References: <20161005094138.23641-1-michel@daenzer.net> Message-ID: <20161006094516.26155-1-michel@daenzer.net> From: Michel Dänzer xf86CursorScreenRec::HotX/Y contain 0 for PRIME slave screens. Fixes incorrect HW cursor position on PRIME slave screens. Also hoist the hotspot translation out from xf86ScreenSet/MoveCursor to xf86Set/MoveCursor, since the hotspot position is a property of the cursor, not the screen. v2: * Squash patches 1 & 2 of the v1 series, since it's basically the same problem * Use the master screen's xf86CursorScreenRec::HotX/Y instead of CursorRec::bits->x/yhot, since CursorRec::bits can be NULL (Hans de Goede) Signed-off-by: Michel Dänzer --- hw/xfree86/ramdac/xf86HWCurs.c | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/hw/xfree86/ramdac/xf86HWCurs.c b/hw/xfree86/ramdac/xf86HWCurs.c index e8966ed..c455902 100644 --- a/hw/xfree86/ramdac/xf86HWCurs.c +++ b/hw/xfree86/ramdac/xf86HWCurs.c @@ -179,8 +179,8 @@ xf86ScreenSetCursor(ScreenPtr pScreen, CursorPtr pCurs, int x, int y) bits = dixLookupScreenPrivate(&pCurs->devPrivates, CursorScreenKey, pScreen); - x -= infoPtr->pScrn->frameX0 + ScreenPriv->HotX; - y -= infoPtr->pScrn->frameY0 + ScreenPriv->HotY; + x -= infoPtr->pScrn->frameX0; + y -= infoPtr->pScrn->frameY0; if (!pCurs->bits->argb || !xf86DriverHasLoadCursorARGB(infoPtr)) if (!bits) { @@ -211,8 +211,14 @@ xf86ScreenSetCursor(ScreenPtr pScreen, CursorPtr pCurs, int x, int y) Bool xf86SetCursor(ScreenPtr pScreen, CursorPtr pCurs, int x, int y) { + xf86CursorScreenPtr ScreenPriv = + (xf86CursorScreenPtr) dixLookupPrivate(&pScreen->devPrivates, + xf86CursorScreenKey); ScreenPtr pSlave; + x -= ScreenPriv->HotX; + y -= ScreenPriv->HotY; + if (!xf86ScreenSetCursor(pScreen, pCurs, x, y)) return FALSE; @@ -263,8 +269,8 @@ xf86ScreenMoveCursor(ScreenPtr pScreen, int x, int y) xf86CursorScreenKey); xf86CursorInfoPtr infoPtr = ScreenPriv->CursorInfoPtr; - x -= infoPtr->pScrn->frameX0 + ScreenPriv->HotX; - y -= infoPtr->pScrn->frameY0 + ScreenPriv->HotY; + x -= infoPtr->pScrn->frameX0; + y -= infoPtr->pScrn->frameY0; (*infoPtr->SetCursorPosition) (infoPtr->pScrn, x, y); } @@ -272,8 +278,14 @@ xf86ScreenMoveCursor(ScreenPtr pScreen, int x, int y) void xf86MoveCursor(ScreenPtr pScreen, int x, int y) { + xf86CursorScreenPtr ScreenPriv = + (xf86CursorScreenPtr) dixLookupPrivate(&pScreen->devPrivates, + xf86CursorScreenKey); ScreenPtr pSlave; + x -= ScreenPriv->HotX; + y -= ScreenPriv->HotY; + xf86ScreenMoveCursor(pScreen, x, y); /* ask each slave driver to move the cursor */ -- 2.9.3 From michel at daenzer.net Thu Oct 6 09:45:16 2016 From: michel at daenzer.net (=?UTF-8?q?Michel=20D=C3=A4nzer?=) Date: Thu, 6 Oct 2016 18:45:16 +0900 Subject: [PATCH xserver v2 2/2] xf86Cursor: Take the input lock in xf86Set/MoveCursor In-Reply-To: <20161006094516.26155-1-michel@daenzer.net> References: <20161005094138.23641-1-michel@daenzer.net> <20161006094516.26155-1-michel@daenzer.net> Message-ID: <20161006094516.26155-2-michel@daenzer.net> From: Michel Dänzer Prevents the HW cursor from intermittently jumping around when the cursor image is changed while the cursor is being moved. This is hardly noticeable in normal operation but can be quite confusing when stepping through these codepaths in a debugger. Signed-off-by: Michel Dänzer --- v2: * Rebased on top of v2 of patch 1 hw/xfree86/ramdac/xf86HWCurs.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/hw/xfree86/ramdac/xf86HWCurs.c b/hw/xfree86/ramdac/xf86HWCurs.c index c455902..da2b181 100644 --- a/hw/xfree86/ramdac/xf86HWCurs.c +++ b/hw/xfree86/ramdac/xf86HWCurs.c @@ -215,12 +215,15 @@ xf86SetCursor(ScreenPtr pScreen, CursorPtr pCurs, int x, int y) (xf86CursorScreenPtr) dixLookupPrivate(&pScreen->devPrivates, xf86CursorScreenKey); ScreenPtr pSlave; + Bool ret = FALSE; + + input_lock(); x -= ScreenPriv->HotX; y -= ScreenPriv->HotY; if (!xf86ScreenSetCursor(pScreen, pCurs, x, y)) - return FALSE; + goto out; /* ask each slave driver to set the cursor. */ xorg_list_for_each_entry(pSlave, &pScreen->slave_list, slave_head) { @@ -233,10 +236,14 @@ xf86SetCursor(ScreenPtr pScreen, CursorPtr pCurs, int x, int y) * otherwise both the hw and sw cursor will show. */ xf86SetCursor(pScreen, NullCursor, x, y); - return FALSE; + goto out; } } - return TRUE; + ret = TRUE; + + out: + input_unlock(); + return ret; } void @@ -283,6 +290,8 @@ xf86MoveCursor(ScreenPtr pScreen, int x, int y) xf86CursorScreenKey); ScreenPtr pSlave; + input_lock(); + x -= ScreenPriv->HotX; y -= ScreenPriv->HotY; @@ -295,6 +304,8 @@ xf86MoveCursor(ScreenPtr pScreen, int x, int y) xf86ScreenMoveCursor(pSlave, x, y); } + + input_unlock(); } void -- 2.9.3 From hdegoede at redhat.com Thu Oct 6 11:00:39 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Thu, 6 Oct 2016 13:00:39 +0200 Subject: [PATCH xserver v2 1/2] xf86Cursor: Use PRIME master xf86CursorScreenRec::HotX/Y for slaves In-Reply-To: <20161006094516.26155-1-michel@daenzer.net> References: <20161005094138.23641-1-michel@daenzer.net> <20161006094516.26155-1-michel@daenzer.net> Message-ID: <846e5869-a6a7-8465-7c0d-21932e678c28@redhat.com> Hi, On 06-10-16 11:45, Michel Dänzer wrote: > From: Michel Dänzer > > xf86CursorScreenRec::HotX/Y contain 0 for PRIME slave screens. > > Fixes incorrect HW cursor position on PRIME slave screens. > > Also hoist the hotspot translation out from xf86ScreenSet/MoveCursor to > xf86Set/MoveCursor, since the hotspot position is a property of the > cursor, not the screen. > > v2: > * Squash patches 1 & 2 of the v1 series, since it's basically the same > problem > * Use the master screen's xf86CursorScreenRec::HotX/Y instead of > CursorRec::bits->x/yhot, since CursorRec::bits can be NULL (Hans de > Goede) > > Signed-off-by: Michel Dänzer v2 series looks good to me, both patches are: Reviewed-by: Hans de Goede REgards, Hans > --- > hw/xfree86/ramdac/xf86HWCurs.c | 20 ++++++++++++++++---- > 1 file changed, 16 insertions(+), 4 deletions(-) > > diff --git a/hw/xfree86/ramdac/xf86HWCurs.c b/hw/xfree86/ramdac/xf86HWCurs.c > index e8966ed..c455902 100644 > --- a/hw/xfree86/ramdac/xf86HWCurs.c > +++ b/hw/xfree86/ramdac/xf86HWCurs.c > @@ -179,8 +179,8 @@ xf86ScreenSetCursor(ScreenPtr pScreen, CursorPtr pCurs, int x, int y) > bits = > dixLookupScreenPrivate(&pCurs->devPrivates, CursorScreenKey, pScreen); > > - x -= infoPtr->pScrn->frameX0 + ScreenPriv->HotX; > - y -= infoPtr->pScrn->frameY0 + ScreenPriv->HotY; > + x -= infoPtr->pScrn->frameX0; > + y -= infoPtr->pScrn->frameY0; > > if (!pCurs->bits->argb || !xf86DriverHasLoadCursorARGB(infoPtr)) > if (!bits) { > @@ -211,8 +211,14 @@ xf86ScreenSetCursor(ScreenPtr pScreen, CursorPtr pCurs, int x, int y) > Bool > xf86SetCursor(ScreenPtr pScreen, CursorPtr pCurs, int x, int y) > { > + xf86CursorScreenPtr ScreenPriv = > + (xf86CursorScreenPtr) dixLookupPrivate(&pScreen->devPrivates, > + xf86CursorScreenKey); > ScreenPtr pSlave; > > + x -= ScreenPriv->HotX; > + y -= ScreenPriv->HotY; > + > if (!xf86ScreenSetCursor(pScreen, pCurs, x, y)) > return FALSE; > > @@ -263,8 +269,8 @@ xf86ScreenMoveCursor(ScreenPtr pScreen, int x, int y) > xf86CursorScreenKey); > xf86CursorInfoPtr infoPtr = ScreenPriv->CursorInfoPtr; > > - x -= infoPtr->pScrn->frameX0 + ScreenPriv->HotX; > - y -= infoPtr->pScrn->frameY0 + ScreenPriv->HotY; > + x -= infoPtr->pScrn->frameX0; > + y -= infoPtr->pScrn->frameY0; > > (*infoPtr->SetCursorPosition) (infoPtr->pScrn, x, y); > } > @@ -272,8 +278,14 @@ xf86ScreenMoveCursor(ScreenPtr pScreen, int x, int y) > void > xf86MoveCursor(ScreenPtr pScreen, int x, int y) > { > + xf86CursorScreenPtr ScreenPriv = > + (xf86CursorScreenPtr) dixLookupPrivate(&pScreen->devPrivates, > + xf86CursorScreenKey); > ScreenPtr pSlave; > > + x -= ScreenPriv->HotX; > + y -= ScreenPriv->HotY; > + > xf86ScreenMoveCursor(pScreen, x, y); > > /* ask each slave driver to move the cursor */ > From hdegoede at redhat.com Thu Oct 6 11:04:07 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Thu, 6 Oct 2016 13:04:07 +0200 Subject: [xserver] input: fix VT switch disabling devices In-Reply-To: <20160924175526.GA3957@localhost> References: <20160924175526.GA3957@localhost> Message-ID: <9a102cdc-fc1e-f2a7-1902-0477693521f9@redhat.com> Hi, On 24-09-16 19:55, Mihail Konev wrote: > Make sure device removes are processed before doing a VT switch, > so that no removes are "overwritten" with attachments afterwards > (before the main thread releases the input lock, letting them be > processed), which would leave affected devices disabled. > > Pass a timeout to input poll instead of telling it to wait forever, > so that no deadlock before VT switch is possible if main thread > waits for release processing only by the time input thread > is already done and does another poll. > > When preparing a VT switch, temprorarily decrease polling > timeout, so there is (likely) no noticeable stall. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97880 > Regressed-in: 52d6a1e832a5e62289dd4f32824ae16a78dfd7e8 > Signed-off-by: Mihail Konev Thank you for the patch and you're right that there is an issue here. I've posted a much simpler fix yesterday, and that has been favorably reviewed, so I think we're going to go with that fix instead, see: https://patchwork.freedesktop.org/patch/113763/ Regards, Hans > --- > > The patch could be wrong with regard to namings (InputThreadWait vs. input_wait) > and multiple input threads (struct InputThreadInfo). > > hw/xfree86/common/xf86Events.c | 4 ++++ > include/input.h | 4 ++++ > os/inputthread.c | 39 ++++++++++++++++++++++++++++++++++++++- > 3 files changed, 46 insertions(+), 1 deletion(-) > > diff --git a/hw/xfree86/common/xf86Events.c b/hw/xfree86/common/xf86Events.c > index 9a8f432a0556..8290c117116e 100644 > --- a/hw/xfree86/common/xf86Events.c > +++ b/hw/xfree86/common/xf86Events.c > @@ -430,6 +430,7 @@ xf86VTLeave(void) > * Keep the order: Disable Device > LeaveVT > * EnterVT > EnableDevice > */ > + InputThreadPollTimeoutSmall(); > for (ih = InputHandlers; ih; ih = ih->next) { > if (ih->is_input) > xf86DisableInputHandler(ih); > @@ -439,6 +440,9 @@ xf86VTLeave(void) > for (pInfo = xf86InputDevs; pInfo; pInfo = pInfo->next) > xf86DisableInputDeviceForVTSwitch(pInfo); > > + InputThreadWaitForProcessingAllRemoves(); > + InputThreadPollTimeoutNormal(); > + > input_lock(); > for (i = 0; i < xf86NumScreens; i++) > xf86Screens[i]->LeaveVT(xf86Screens[i]); > diff --git a/include/input.h b/include/input.h > index e0f6b9b01d97..1afb3f89a33a 100644 > --- a/include/input.h > +++ b/include/input.h > @@ -719,6 +719,10 @@ extern _X_EXPORT void input_lock(void); > extern _X_EXPORT void input_unlock(void); > extern _X_EXPORT void input_force_unlock(void); > > +extern _X_EXPORT void InputThreadPollTimeoutSmall(void); > +extern _X_EXPORT void InputThreadPollTimeoutNormal(void); > +extern _X_EXPORT void InputThreadWaitForProcessingAllRemoves(void); > + > extern void InputThreadPreInit(void); > extern void InputThreadInit(void); > extern void InputThreadFini(void); > diff --git a/os/inputthread.c b/os/inputthread.c > index 6aa0a9ce6fb5..fab3c30954e5 100644 > --- a/os/inputthread.c > +++ b/os/inputthread.c > @@ -90,6 +90,12 @@ static pthread_mutex_t input_mutex; > static Bool input_mutex_initialized; > #endif > > +int input_poll_timeout_ms; > + > +static Bool waiting_for_processing_all_removes = FALSE; > +static int unprocessed_removes_count = 0; > +static pthread_barrier_t all_removes_processed_barrier; > + > void > input_lock(void) > { > @@ -125,6 +131,25 @@ input_force_unlock(void) > } > } > > +void > +InputThreadPollTimeoutSmall(void) > +{ > + input_poll_timeout_ms = 4; > +} > + > +void > +InputThreadPollTimeoutNormal(void) > +{ > + input_poll_timeout_ms = 200; > +} > + > +void > +InputThreadWaitForProcessingAllRemoves(void) > +{ > + waiting_for_processing_all_removes = TRUE; > + pthread_barrier_wait(&all_removes_processed_barrier); > +} > + > /** > * Notify a thread about the availability of new asynchronously enqueued input > * events. > @@ -267,6 +292,7 @@ InputThreadUnregisterDev(int fd) > > dev->state = device_state_removed; > inputThreadInfo->changed = TRUE; > + unprocessed_removes_count++; > > input_unlock(); > > @@ -348,13 +374,19 @@ InputThreadDoWork(void *arg) > ospoll_remove(inputThreadInfo->fds, dev->fd); > xorg_list_del(&dev->node); > free(dev); > + unprocessed_removes_count--; > break; > } > } > input_unlock(); > } > > - if (ospoll_wait(inputThreadInfo->fds, -1) < 0) { > + if (waiting_for_processing_all_removes && !unprocessed_removes_count) { > + waiting_for_processing_all_removes = FALSE; > + pthread_barrier_wait(&all_removes_processed_barrier); > + } > + > + if (ospoll_wait(inputThreadInfo->fds, input_poll_timeout_ms) < 0) { > if (errno == EINVAL) > FatalError("input-thread: %s (%s)", __func__, strerror(errno)); > else if (errno != EINTR) > @@ -400,6 +432,8 @@ InputThreadPreInit(void) > if (!inputThreadInfo) > FatalError("input-thread: could not allocate memory"); > > + pthread_barrier_init(&all_removes_processed_barrier, NULL, 2); > + > inputThreadInfo->thread = 0; > xorg_list_init(&inputThreadInfo->devs); > inputThreadInfo->fds = ospoll_create(); > @@ -434,6 +468,7 @@ InputThreadPreInit(void) > pthread_setname_np ("MainThread"); > #endif > > + InputThreadPollTimeoutNormal(); > } > > /** > @@ -517,6 +552,8 @@ int xthread_sigmask(int how, const sigset_t *set, sigset_t *oldset) > > Bool InputThreadEnable = FALSE; > > +void input_wait_for_processing_all_removes(void) {}; > + > void input_lock(void) {} > void input_unlock(void) {} > void input_force_unlock(void) {} > From martin.peres at linux.intel.com Thu Oct 6 14:05:35 2016 From: martin.peres at linux.intel.com (Martin Peres) Date: Thu, 6 Oct 2016 17:05:35 +0300 Subject: [PATCH rendercheck] Report results on a per-test basis Message-ID: <20161006140535.32211-1-martin.peres@linux.intel.com> This allows a runner such as EzBench to track each test individually and not limit the resolution to groups. This feature can be triggered by using the -r parameter. Signed-off-by: Martin Peres --- main.c | 12 ++++++---- rendercheck.h | 4 ++-- tests.c | 70 +++++++++++++++++++++++++++++++++++++++++------------------ 3 files changed, 59 insertions(+), 27 deletions(-) diff --git a/main.c b/main.c index 0d3d146..e7f6e09 100644 --- a/main.c +++ b/main.c @@ -27,7 +27,7 @@ #include #include -bool is_verbose = false, minimalrendering = false; +bool is_verbose = false, minimalrendering = false, enable_report = false; int enabled_tests = ~0; /* Enable all tests by default */ int format_whitelist_len = 0; @@ -163,7 +163,7 @@ usage (char *program) { fprintf(stderr, "usage: %s [-d|--display display] [-v|--verbose]\n" "\t[-t test1,test2,...] [-o op1,op2,...] [-f format1,format2,...]\n" - "\t[--sync] [--minimalrendering] [--version]\n" + "\t[--sync] [--minimalrendering] [--report] [--version]\n" "Available tests:\n", program); print_tests(stderr, ~0); exit(1); @@ -189,6 +189,7 @@ int main(int argc, char **argv) { "tests", required_argument, NULL, 't' }, { "ops", required_argument, NULL, 'o' }, { "verbose", no_argument, NULL, 'v' }, + { "report", no_argument, NULL, 'r' }, { "sync", no_argument, &is_sync, true}, { "minimalrendering", no_argument, &longopt_minimalrendering, true}, @@ -196,7 +197,7 @@ int main(int argc, char **argv) { NULL, 0, NULL, 0 } }; - while ((o = getopt_long(argc, argv, "d:i:f:t:o:v", longopts, NULL)) != -1) { + while ((o = getopt_long(argc, argv, "d:i:f:t:o:rv", longopts, NULL)) != -1) { switch (o) { case 'd': display = optarg; @@ -276,6 +277,9 @@ int main(int argc, char **argv) case 'v': is_verbose = true; break; + case 'r': + enable_report = true; + break; case 0: break; default: @@ -345,7 +349,7 @@ int main(int argc, char **argv) while (XNextEvent(dpy, &ev) == 0) { if (ev.type == Expose && !ev.xexpose.count) { - if (do_tests(dpy, &window)) + if (do_tests(dpy, &window, enable_report)) ret = 0; else ret = 1; diff --git a/rendercheck.h b/rendercheck.h index 1c392e8..43d6f2b 100644 --- a/rendercheck.h +++ b/rendercheck.h @@ -132,7 +132,7 @@ extern struct rendercheck_test __start_test_section, __stop_test_section; extern int pixmap_move_iter; extern int win_width, win_height; extern struct op_info ops[]; -extern bool is_verbose, minimalrendering; +extern bool is_verbose, minimalrendering, enable_report; extern color4d colors[]; extern int enabled_tests; extern int format_whitelist_len; @@ -193,7 +193,7 @@ argb_fill(Display *dpy, picture_info *p, int x, int y, int w, int h, float a, float r, float g, float b); bool -do_tests(Display *dpy, picture_info *win); +do_tests(Display *dpy, picture_info *win, bool enable_report); void copy_pict_to_win(Display *dpy, picture_info *pict, picture_info *win, diff --git a/tests.c b/tests.c index 22cbfd4..253461c 100644 --- a/tests.c +++ b/tests.c @@ -315,7 +315,7 @@ create_formats_list(Display *dpy) } bool -do_tests(Display *dpy, picture_info *win) +do_tests(Display *dpy, picture_info *win, bool enable_report) { int i, j, src; int num_dests; @@ -436,6 +436,14 @@ do { \ tests_total++; \ } while (0) +#define REPORT_RESULTS(fmt, ...) \ +do { \ + RECORD_RESULTS(); \ + if (enable_report) \ + fprintf(stderr, "## " fmt ": %s\n", \ + ##__VA_ARGS__, ok ? "pass" : "fail"); \ +} while (0) + num_tests = num_colors * nformats; test_ops = malloc(sizeof(int)*num_ops); @@ -482,13 +490,23 @@ do { \ printf("Beginning testing of filling of 1x1R pictures\n"); for (i = 0; i < num_tests; i++) { ok = fill_test(dpy, win, &pictures_1x1[i]); - RECORD_RESULTS(); + REPORT_RESULTS("fill 1x1R src=(%s, %.2f:%.2f:%.2f:%.2f)", + pictures_1x1[i].name, + pictures_1x1[i].color.a, + pictures_1x1[i].color.r, + pictures_1x1[i].color.g, + pictures_1x1[i].color.b); } printf("Beginning testing of filling of 10x10 pictures\n"); for (i = 0; i < num_tests; i++) { ok = fill_test(dpy, win, &pictures_10x10[i]); - RECORD_RESULTS(); + REPORT_RESULTS("fill 10x10 src=(%s, %.2f:%.2f:%.2f:%.2f)", + pictures_1x1[i].name, + pictures_1x1[i].color.a, + pictures_1x1[i].color.r, + pictures_1x1[i].color.g, + pictures_1x1[i].color.b); } if (group_ok) success_mask |= TEST_FILL; @@ -502,7 +520,8 @@ do { \ ok = dstcoords_test(dpy, win, i == 0 ? PictOpSrc : PictOpOver, win, argb32white, argb32red); - RECORD_RESULTS(); + REPORT_RESULTS("dst coords %s", + i == 0 ? "PictOpSrc" : "PictOpOver"); } if (group_ok) success_mask |= TEST_DSTCOORDS; @@ -513,7 +532,8 @@ do { \ printf("Beginning src coords test\n"); ok = srccoords_test(dpy, win, argb32white, false); - RECORD_RESULTS(); + REPORT_RESULTS("src coords"); + if (group_ok) success_mask |= TEST_SRCCOORDS; } @@ -523,7 +543,8 @@ do { \ printf("Beginning mask coords test\n"); ok = srccoords_test(dpy, win, argb32white, true); - RECORD_RESULTS(); + REPORT_RESULTS("mask coords"); + if (group_ok) success_mask |= TEST_MASKCOORDS; } @@ -533,11 +554,12 @@ do { \ printf("Beginning transformed src coords test\n"); ok = trans_coords_test(dpy, win, argb32white, false); - RECORD_RESULTS(); + REPORT_RESULTS("transform src coord"); printf("Beginning transformed src coords test 2\n"); ok = trans_srccoords_test_2(dpy, win, argb32white, false); - RECORD_RESULTS(); + REPORT_RESULTS("transform src coord2"); + if (group_ok) success_mask |= TEST_TSRCCOORDS; } @@ -547,11 +569,11 @@ do { \ printf("Beginning transformed mask coords test\n"); ok = trans_coords_test(dpy, win, argb32white, true); - RECORD_RESULTS(); + REPORT_RESULTS("transform mask coord"); printf("Beginning transformed mask coords test 2\n"); ok = trans_srccoords_test_2(dpy, win, argb32white, true); - RECORD_RESULTS(); + REPORT_RESULTS("transform mask coord2"); if (group_ok) success_mask |= TEST_TMASKCOORDS; @@ -574,7 +596,7 @@ do { \ test_ops, num_test_ops, test_src, num_test_src, test_dst, num_test_dst); - RECORD_RESULTS(); + REPORT_RESULTS("blend %s", pi->name); } if (group_ok) success_mask |= TEST_BLEND; @@ -599,7 +621,7 @@ do { \ test_mask, num_test_mask, test_dst, num_test_dst, false); - RECORD_RESULTS(); + REPORT_RESULTS("composite mask %s", pi->name); } if (group_ok) success_mask |= TEST_COMPOSITE; @@ -624,7 +646,7 @@ do { \ test_mask, num_test_mask, test_dst, num_test_dst, true); - RECORD_RESULTS(); + REPORT_RESULTS("composite CA mask %s", pi->name); } if (group_ok) success_mask |= TEST_CACOMPOSITE; @@ -635,7 +657,10 @@ do { \ printf("Beginning render to linear gradient test\n"); ok = render_to_gradient_test(dpy, &pictures_1x1[0]); - RECORD_RESULTS(); + REPORT_RESULTS("render linear gradient %s - color %.2f:%.2f:%.2f:%.2f", + pictures_1x1[0].name, pictures_1x1[0].color.a, + pictures_1x1[0].color.r, pictures_1x1[0].color.g, + pictures_1x1[0].color.b); for (i = 0; i < num_ops; i++) { if (ops[i].disabled) @@ -654,7 +679,10 @@ do { \ for (src = 0; src < num_tests; src++) { ok = linear_gradient_test(dpy, win, pi, i, &pictures_1x1[src]); - RECORD_RESULTS(); + REPORT_RESULTS("%s linear gradient dst=%s, src=(%s, %.2f:%.2f:%.2f:%.2f)", + ops[i].name, pi->name, pictures_1x1[src].name, + pictures_1x1[src].color.a, pictures_1x1[src].color.r, + pictures_1x1[src].color.g, pictures_1x1[src].color.b); } } } @@ -683,7 +711,7 @@ do { \ */ ok = repeat_test(dpy, win, pi, i, argb32white, argb32red, argb32green, false); - RECORD_RESULTS(); + REPORT_RESULTS("%s src repeat %s", ops[i].name, pi->name); printf("Beginning %s mask repeat test on %s\n", ops[i].name, pi->name); @@ -692,7 +720,7 @@ do { \ */ ok = repeat_test(dpy, win, pi, i, argb32white, argb32red, argb32green, true); - RECORD_RESULTS(); + REPORT_RESULTS("%s mask repeat %s", ops[i].name, pi->name); } } if (group_ok) @@ -718,19 +746,19 @@ do { \ ops[i].name, pi->name); ok = triangles_test(dpy, win, pi, i, argb32red, argb32white); - RECORD_RESULTS(); + REPORT_RESULTS("%s Triangles %s", ops[i].name, pi->name); printf("Beginning %s TriStrip test on %s\n", ops[i].name, pi->name); ok = tristrip_test(dpy, win, pi, i, argb32red, argb32white); - RECORD_RESULTS(); + REPORT_RESULTS("%s TriStrip %s", ops[i].name, pi->name); printf("Beginning %s TriFan test on %s\n", ops[i].name, pi->name); ok = trifan_test(dpy, win, pi, i, argb32red, argb32white); - RECORD_RESULTS(); + REPORT_RESULTS("%s TriFan %s", ops[i].name, pi->name); } } if (group_ok) @@ -741,7 +769,7 @@ do { \ bool ok, group_ok = true; ok = bug7366_test(dpy); - RECORD_RESULTS(); + REPORT_RESULTS("bug7366"); if (group_ok) success_mask |= TEST_BUG7366; -- 2.10.0 From ajax at nwnk.net Thu Oct 6 17:07:55 2016 From: ajax at nwnk.net (Adam Jackson) Date: Thu, 06 Oct 2016 13:07:55 -0400 Subject: [PATCH xserver v2] Fix id in error when resource does not exist In-Reply-To: <1475162268-16394-1-git-send-email-pharris@opentext.com> References: <1475093820-6486-1-git-send-email-pharris@opentext.com> <1475162268-16394-1-git-send-email-pharris@opentext.com> Message-ID: <1475773675.12036.2.camel@nwnk.net> On Thu, 2016-09-29 at 11:17 -0400, Peter Harris wrote: > Always set client->errorValue before returning an error. As sensible as this seems, I think it's wrong. I ran across something similar a few years ago: https://lists.freedesktop.org/archives/xorg-devel/2011-June/023462.html BadMatch errors are specified as not filling in errorValue, so... > @@ -1220,11 +1220,13 @@ dixLookupResourceByType(void **result, XID id, RESTYPE rtype, >              if (res->id == id && res->type == rtype) >                  break; >      } > +    if (client) { > +        client->errorValue = id; > +    } >      if (!res) >          return resourceTypes[rtype & TypeMask].errorValue; >   >      if (client) { > -        client->errorValue = id; >          cid = XaceHook(XACE_RESOURCE_ACCESS, client, id, res->type, >                         res->value, RT_NONE, NULL, mode); >          if (cid == BadValue) ... imagine ChangeGC specifying more than one of {tile, stipple, font, clipmask pixmap}.  Whichever one is looked up last will be the errorValue thrown with the eventual BadMatch, which beyond being against the spec also means you might be misled about which resource is failing the match. - ajax From pharris at opentext.com Thu Oct 6 18:06:21 2016 From: pharris at opentext.com (Peter Harris) Date: Thu, 6 Oct 2016 14:06:21 -0400 Subject: [PATCH xserver v2] Fix id in error when resource does not exist In-Reply-To: <1475773675.12036.2.camel@nwnk.net> References: <1475093820-6486-1-git-send-email-pharris@opentext.com> <1475162268-16394-1-git-send-email-pharris@opentext.com> <1475773675.12036.2.camel@nwnk.net> Message-ID: On 2016-10-06 1:07 PM, Adam Jackson wrote: > On Thu, 2016-09-29 at 11:17 -0400, Peter Harris wrote: >> Always set client->errorValue before returning an error. > > As sensible as this seems, I think it's wrong. I ran across something > similar a few years ago: > > https://lists.freedesktop.org/archives/xorg-devel/2011-June/023462.html > > BadMatch errors are specified as not filling in errorValue, so... > >> @@ -1220,11 +1220,13 @@ dixLookupResourceByType(void **result, XID id, RESTYPE rtype, >> if (res->id == id && res->type == rtype) >> break; >> } >> + if (client) { >> + client->errorValue = id; >> + } >> if (!res) >> return resourceTypes[rtype & TypeMask].errorValue; >> >> if (client) { >> - client->errorValue = id; >> cid = XaceHook(XACE_RESOURCE_ACCESS, client, id, res->type, >> res->value, RT_NONE, NULL, mode); >> if (cid == BadValue) > > ... imagine ChangeGC specifying more than one of {tile, stipple, font, > clipmask pixmap}. Whichever one is looked up last will be the > errorValue thrown with the eventual BadMatch, which beyond being > against the spec also means you might be misled about which resource is > failing the match. But that's already the case with the current code. When the lookup succeeds, client->errorValue is set to whatever was looked up (by the line removed in this patch). Yes, the next BadMatch is going to have nonsense in a few bytes defined to be padding bytes, but that was already the case. This patch only moves the setting of client->errorValue above the "Resource Not Found" return. So the error definitely[1] isn't BadMatch, and we want the ID to be the thing that actually doesn't exist, instead of the previous thing that does exist. This patch only makes a difference[1] when the error value isn't BadMatch. The thing that bit me was a BadGC with errorValue set to the drawable of the offending request, which took some head-scratching to figure out. Peter Harris [1] Unless an extension calls SetResourceTypeErrorValue(resType, BadMatch). Which would be crazy. -- Open Text Connectivity Solutions Group Peter Harris http://connectivity.opentext.com/ Research and Development Phone: +1 905 762 6001 pharris at opentext.com Toll Free: 1 877 359 4866 From jon.turney at dronecode.org.uk Thu Oct 6 18:02:55 2016 From: jon.turney at dronecode.org.uk (Jon Turney) Date: Thu, 6 Oct 2016 19:02:55 +0100 Subject: [PATCH 3/3] configure.ac: remove --enable-aiglx option In-Reply-To: <20160929174119.14505-3-emil.l.velikov@gmail.com> References: <20160929174119.14505-1-emil.l.velikov@gmail.com> <20160929174119.14505-3-emil.l.velikov@gmail.com> Message-ID: <2e40463a-98fd-3bd9-6977-e065a7175a3a@dronecode.org.uk> On 29/09/2016 18:41, Emil Velikov wrote: > Presently the option guards both direct and accelerated indirect GLX. As > such when one toggles it off they end up without any acceleration. > > Remove the option all together until we have the time to split/rework > things. > > Cc: Jon Turney > Cc: Adam Jackson > Signed-off-by: Emil Velikov > --- > Jon, I've not checked the Xwin side of things but considering that the > option is enabled by default and having it for Xwin only will be > confusing I've nuked the guards throughout the tree. Sorry I didn't get around to testing this before it was committed. This breaks my build (See [1]), as the DRI2 loader is now built unconditionally, which fails without drm.h I'm not sure exactly what problem this change is fixing, so I'm not sure how to address that. Is it ok to restore the part which makes building the DRI2 loader conditional? [1] http://dronecode.duckdns.org:8010/builders/xserver/builds/821 From emil.l.velikov at gmail.com Thu Oct 6 18:15:31 2016 From: emil.l.velikov at gmail.com (Emil Velikov) Date: Thu, 6 Oct 2016 19:15:31 +0100 Subject: [PATCH 3/3] configure.ac: remove --enable-aiglx option In-Reply-To: <2e40463a-98fd-3bd9-6977-e065a7175a3a@dronecode.org.uk> References: <20160929174119.14505-1-emil.l.velikov@gmail.com> <20160929174119.14505-3-emil.l.velikov@gmail.com> <2e40463a-98fd-3bd9-6977-e065a7175a3a@dronecode.org.uk> Message-ID: On 6 October 2016 at 19:02, Jon Turney wrote: > On 29/09/2016 18:41, Emil Velikov wrote: >> >> Presently the option guards both direct and accelerated indirect GLX. As >> such when one toggles it off they end up without any acceleration. >> >> Remove the option all together until we have the time to split/rework >> things. >> >> Cc: Jon Turney >> Cc: Adam Jackson >> Signed-off-by: Emil Velikov >> --- >> Jon, I've not checked the Xwin side of things but considering that the >> option is enabled by default and having it for Xwin only will be >> confusing I've nuked the guards throughout the tree. > > > Sorry I didn't get around to testing this before it was committed. > > This breaks my build (See [1]), as the DRI2 loader is now built > unconditionally, which fails without drm.h > > I'm not sure exactly what problem this change is fixing, so I'm not sure how > to address that. > > Is it ok to restore the part which makes building the DRI2 loader > conditional? > I had a bad feeling about this, fortunately it seems pretty easy to handle. >From a quick look nothing in glx/glxdri2.c should require libdrm so we can nuke the drm.h and xf86drm.h includes, which will get you back up and going. Alternatively we can add those in a ifdef WITH_LIBDRM/endif block. Even then we can make the compilation of the DRI2 loader but let's not call it AIGLX ;-) Thanks Emil From ajax at redhat.com Thu Oct 6 18:42:34 2016 From: ajax at redhat.com (Adam Jackson) Date: Thu, 6 Oct 2016 14:42:34 -0400 Subject: [PATCH xserver] glx/dri2: Don't include drm headers Message-ID: <20161006184234.4982-1-ajax@redhat.com> They're not needed, and they won't be present on win32. Signed-off-by: Adam Jackson --- glx/glxdri2.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/glx/glxdri2.c b/glx/glxdri2.c index c2dab90..484b4ae 100644 --- a/glx/glxdri2.c +++ b/glx/glxdri2.c @@ -31,7 +31,6 @@ #include #include -#include #include #include #include @@ -40,7 +39,6 @@ #include #define _XF86DRI_SERVER_ -#include #include #include -- 2.9.3 From ajax at nwnk.net Thu Oct 6 19:01:28 2016 From: ajax at nwnk.net (Adam Jackson) Date: Thu, 06 Oct 2016 15:01:28 -0400 Subject: [PATCH xserver v2] Fix id in error when resource does not exist In-Reply-To: References: <1475093820-6486-1-git-send-email-pharris@opentext.com> <1475162268-16394-1-git-send-email-pharris@opentext.com> <1475773675.12036.2.camel@nwnk.net> Message-ID: <1475780488.12036.5.camel@nwnk.net> On Thu, 2016-10-06 at 14:06 -0400, Peter Harris wrote: > On 2016-10-06 1:07 PM, Adam Jackson wrote: > > ... imagine ChangeGC specifying more than one of {tile, stipple, font, > > clipmask pixmap}.  Whichever one is looked up last will be the > > errorValue thrown with the eventual BadMatch, which beyond being > > against the spec also means you might be misled about which resource is > > failing the match. > > > But that's already the case with the current code. When the lookup > succeeds, client->errorValue is set to whatever was looked up (by the > line removed in this patch). Yes, the next BadMatch is going to have > nonsense in a few bytes defined to be padding bytes, but that was > already the case. > > This patch only moves the setting of client->errorValue above the > "Resource Not Found" return. So the error definitely[1] isn't BadMatch, > and we want the ID to be the thing that actually doesn't exist, instead > of the previous thing that does exist. Hah, right you are. I think we might still want to clear ->errorValue on the success path, but that's a bigger thing to audit and can at any rate be a separate change. Merged: remote: I: patch #112642 updated using rev 97a8353ec1192d8d3bd2ebb99e5687cb91427e09. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver f4a4115..97a8353 master -> master - ajax From emil.l.velikov at gmail.com Thu Oct 6 22:38:40 2016 From: emil.l.velikov at gmail.com (Emil Velikov) Date: Thu, 6 Oct 2016 23:38:40 +0100 Subject: [PATCH xserver] glx/dri2: Don't include drm headers In-Reply-To: <20161006184234.4982-1-ajax@redhat.com> References: <20161006184234.4982-1-ajax@redhat.com> Message-ID: On Thursday, 6 October 2016, Adam Jackson wrote: > They're not needed, and they won't be present on win32. > > Signed-off-by: Adam Jackson > Reviewed-by: Emil Velikov Pardon the html formatting. Emil -------------- next part -------------- An HTML attachment was scrubbed... URL: From hdegoede at redhat.com Fri Oct 7 08:39:06 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Fri, 7 Oct 2016 10:39:06 +0200 Subject: Null pointer deref in FlushAllOutput with 1.19-rc1 ? Message-ID: Hi All, Multiple Fedora 25 users running 1.19-rc1 are reporting a backtrace related to an InitFonts -> SendErrorToClient -> FlushAllOutput call chain. Since there is no trivial reproducer this is somewhat hard to debug, hence this mail. Anyone have a clue / hint ? See: https://bugzilla.redhat.com/show_bug.cgi?id=1382444 Regards, Hans From jon.turney at dronecode.org.uk Fri Oct 7 12:58:05 2016 From: jon.turney at dronecode.org.uk (Jon Turney) Date: Fri, 7 Oct 2016 13:58:05 +0100 Subject: [PATCH 3/3] configure.ac: remove --enable-aiglx option In-Reply-To: References: <20160929174119.14505-1-emil.l.velikov@gmail.com> <20160929174119.14505-3-emil.l.velikov@gmail.com> <2e40463a-98fd-3bd9-6977-e065a7175a3a@dronecode.org.uk> Message-ID: <947dabc9-a478-fe76-ec42-9af14cba5e39@dronecode.org.uk> On 06/10/2016 19:15, Emil Velikov wrote: > On 6 October 2016 at 19:02, Jon Turney wrote: >> On 29/09/2016 18:41, Emil Velikov wrote: >>> >>> Presently the option guards both direct and accelerated indirect GLX. As >>> such when one toggles it off they end up without any acceleration. >>> >>> Remove the option all together until we have the time to split/rework >>> things. >>> >>> Cc: Jon Turney >>> Cc: Adam Jackson >>> Signed-off-by: Emil Velikov >>> --- >>> Jon, I've not checked the Xwin side of things but considering that the >>> option is enabled by default and having it for Xwin only will be >>> confusing I've nuked the guards throughout the tree. >> >> Sorry I didn't get around to testing this before it was committed. >> >> This breaks my build (See [1]), as the DRI2 loader is now built >> unconditionally, which fails without drm.h >> >> I'm not sure exactly what problem this change is fixing, so I'm not sure how >> to address that. >> >> Is it ok to restore the part which makes building the DRI2 loader >> conditional? >> > I had a bad feeling about this, fortunately it seems pretty easy to handle. > > From a quick look nothing in glx/glxdri2.c should require libdrm so we > can nuke the drm.h and xf86drm.h includes, which will get you back up > and going. Alternatively we can add those in a ifdef WITH_LIBDRM/endif > block. That's not quite enough, as building glxdri2.c also requires dri2proto headers. At the moment, configure.ac only requires dri2proto when --enable-dri2 turns on. So either that needs to be made unconditional, or building glxdri2.c made conditional on DRI2 (untested patch attached) > Even then we can make the compilation of the DRI2 loader but let's not > call it AIGLX ;-) -------------- next part -------------- From db2fcb2636a659abd0998d82204813fd5dcd57ff Mon Sep 17 00:00:00 2001 From: Jon Turney Date: Thu, 6 Oct 2016 22:13:07 +0100 Subject: [PATCH xserver] Don't build DRI loader if DRI2 isn't enabled --- glx/Makefile.am | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/glx/Makefile.am b/glx/Makefile.am index fc0b76a..9af7080 100644 --- a/glx/Makefile.am +++ b/glx/Makefile.am @@ -16,11 +16,10 @@ AM_CPPFLAGS = \ -I$(top_srcdir)/hw/xfree86/os-support/bus \ -I$(top_srcdir)/hw/xfree86/common \ -I$(top_srcdir)/hw/xfree86/dri \ + -I$(top_srcdir)/hw/xfree86/dri2 -I$(top_srcdir)/mi \ -I$(top_srcdir)/present -AM_CPPFLAGS += -I$(top_srcdir)/hw/xfree86/dri2 - indirect_sources = \ indirect_dispatch.c \ indirect_dispatch.h \ @@ -33,7 +32,9 @@ indirect_sources = \ indirect_table.c libglxdri_la_SOURCES = +if DRI2 libglxdri_la_SOURCES += glxdri2.c +endif libglxdri_la_LIBADD = $(DLOPEN_LIBS) -- 2.8.3 From niels_ole at salscheider-online.de Fri Oct 7 19:46:44 2016 From: niels_ole at salscheider-online.de (Niels Ole Salscheider) Date: Fri, 7 Oct 2016 21:46:44 +0200 Subject: [PATCH libXi] SizeClassInfo can return 0 even without an error Message-ID: <20161007194644.31537-1-niels_ole@salscheider-online.de> Catch the error case separately. This fixes a few crashes on my computer. Signed-off-by: Niels Ole Salscheider --- src/XListDev.c | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/src/XListDev.c b/src/XListDev.c index f850cd0..d0c6bf2 100644 --- a/src/XListDev.c +++ b/src/XListDev.c @@ -73,27 +73,27 @@ static int pad_to_xid(int base_size) return ((base_size + padsize - 1)/padsize) * padsize; } -static size_t -SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes) +static int +SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes, size_t *size) { - int size = 0; int j; + *size = 0; for (j = 0; j < num_classes; j++) { switch ((*any)->class) { case KeyClass: - size += pad_to_xid(sizeof(XKeyInfo)); + *size += pad_to_xid(sizeof(XKeyInfo)); break; case ButtonClass: - size += pad_to_xid(sizeof(XButtonInfo)); + *size += pad_to_xid(sizeof(XButtonInfo)); break; case ValuatorClass: { xValuatorInfoPtr v; if (len < sizeof(v)) - return 0; + return 1; v = (xValuatorInfoPtr) *any; - size += pad_to_xid(sizeof(XValuatorInfo) + + *size += pad_to_xid(sizeof(XValuatorInfo) + (v->num_axes * sizeof(XAxisInfo))); break; } @@ -101,11 +101,11 @@ SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes) break; } if ((*any)->length > len) - return 0; + return 1; *any = (xAnyClassPtr) ((char *)(*any) + (*any)->length); } - return size; + return 0; } static void @@ -220,8 +220,7 @@ XListInputDevices( sav_any = any; end = (char *)list + rlen; for (i = 0; i < *ndevices; i++, list++) { - s = SizeClassInfo(&any, end - (char *)any, (int)list->num_classes); - if (!s) + if(SizeClassInfo(&any, end - (char *)any, (int)list->num_classes, &s)) goto out; size += s; } -- 2.10.1 From niels_ole at salscheider-online.de Sat Oct 8 09:30:00 2016 From: niels_ole at salscheider-online.de (Niels Ole Salscheider) Date: Sat, 8 Oct 2016 11:30:00 +0200 Subject: [PATCH libXi] Set ndevices to 0 in the error case Message-ID: <20161008093000.16840-1-niels_ole@salscheider-online.de> Signed-off-by: Niels Ole Salscheider --- src/XListDev.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/src/XListDev.c b/src/XListDev.c index d0c6bf2..d29a952 100644 --- a/src/XListDev.c +++ b/src/XListDev.c @@ -189,8 +189,10 @@ XListInputDevices( XExtDisplayInfo *info = XInput_find_display(dpy); LockDisplay(dpy); - if (_XiCheckExtInit(dpy, XInput_Initial_Release, info) == -1) + if (_XiCheckExtInit(dpy, XInput_Initial_Release, info) == -1) { + *ndevices = 0; return ((XDeviceInfo *) NULL); + } GetReq(ListInputDevices, req); req->reqType = info->codes->major_opcode; @@ -199,6 +201,7 @@ XListInputDevices( if (!_XReply(dpy, (xReply *) & rep, 0, xFalse)) { UnlockDisplay(dpy); SyncHandle(); + *ndevices = 0; return (XDeviceInfo *) NULL; } @@ -212,6 +215,7 @@ XListInputDevices( _XEatDataWords(dpy, rep.length); UnlockDisplay(dpy); SyncHandle(); + *ndevices = 0; return (XDeviceInfo *) NULL; } _XRead(dpy, (char *)list, rlen); @@ -220,15 +224,19 @@ XListInputDevices( sav_any = any; end = (char *)list + rlen; for (i = 0; i < *ndevices; i++, list++) { - if(SizeClassInfo(&any, end - (char *)any, (int)list->num_classes, &s)) + if(SizeClassInfo(&any, end - (char *)any, (int)list->num_classes, &s)) { + *ndevices = 0; goto out; + } size += s; } Nptr = ((unsigned char *)list) + rlen; for (i = 0, nptr = (unsigned char *)any; i < *ndevices; i++) { - if (nptr >= Nptr) + if (nptr >= Nptr) { + *ndevices = 0; goto out; + } size += *nptr + 1; nptr += (*nptr + 1); } @@ -238,6 +246,7 @@ XListInputDevices( XFree((char *)slist); UnlockDisplay(dpy); SyncHandle(); + *ndevices = 0; return (XDeviceInfo *) NULL; } sclist = clist; -- 2.10.1 From niels_ole at salscheider-online.de Sat Oct 8 09:35:57 2016 From: niels_ole at salscheider-online.de (Niels Ole Salscheider) Date: Sat, 8 Oct 2016 11:35:57 +0200 Subject: [PATCH v2 libXi] Set ndevices to 0 in the error case In-Reply-To: <20161008093000.16840-1-niels_ole@salscheider-online.de> References: <20161008093000.16840-1-niels_ole@salscheider-online.de> Message-ID: <20161008093557.17834-1-niels_ole@salscheider-online.de> v2: Fix formating issues Signed-off-by: Niels Ole Salscheider --- src/XListDev.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/src/XListDev.c b/src/XListDev.c index d0c6bf2..f47ad97 100644 --- a/src/XListDev.c +++ b/src/XListDev.c @@ -189,8 +189,10 @@ XListInputDevices( XExtDisplayInfo *info = XInput_find_display(dpy); LockDisplay(dpy); - if (_XiCheckExtInit(dpy, XInput_Initial_Release, info) == -1) + if (_XiCheckExtInit(dpy, XInput_Initial_Release, info) == -1) { + *ndevices = 0; return ((XDeviceInfo *) NULL); + } GetReq(ListInputDevices, req); req->reqType = info->codes->major_opcode; @@ -199,6 +201,7 @@ XListInputDevices( if (!_XReply(dpy, (xReply *) & rep, 0, xFalse)) { UnlockDisplay(dpy); SyncHandle(); + *ndevices = 0; return (XDeviceInfo *) NULL; } @@ -212,6 +215,7 @@ XListInputDevices( _XEatDataWords(dpy, rep.length); UnlockDisplay(dpy); SyncHandle(); + *ndevices = 0; return (XDeviceInfo *) NULL; } _XRead(dpy, (char *)list, rlen); @@ -220,15 +224,19 @@ XListInputDevices( sav_any = any; end = (char *)list + rlen; for (i = 0; i < *ndevices; i++, list++) { - if(SizeClassInfo(&any, end - (char *)any, (int)list->num_classes, &s)) - goto out; + if(SizeClassInfo(&any, end - (char *)any, (int)list->num_classes, &s)) { + *ndevices = 0; + goto out; + } size += s; } Nptr = ((unsigned char *)list) + rlen; for (i = 0, nptr = (unsigned char *)any; i < *ndevices; i++) { - if (nptr >= Nptr) + if (nptr >= Nptr) { + *ndevices = 0; goto out; + } size += *nptr + 1; nptr += (*nptr + 1); } @@ -238,6 +246,7 @@ XListInputDevices( XFree((char *)slist); UnlockDisplay(dpy); SyncHandle(); + *ndevices = 0; return (XDeviceInfo *) NULL; } sclist = clist; -- 2.10.1 From matthieu at herrb.eu Sat Oct 8 19:45:09 2016 From: matthieu at herrb.eu (Matthieu Herrb) Date: Sat, 8 Oct 2016 21:45:09 +0200 Subject: [PATCH libX11] Don't rebuild ks_tables.h if nothing changed. In-Reply-To: <20161008180858.GA39383@watschnbaum.natano.net> References: <20161008180858.GA39383@watschnbaum.natano.net> Message-ID: <20161008194509.GC33240@nebraska.herrb.net> On Sat, Oct 08, 2016 at 08:10:34PM +0200, Martin Natano wrote: > This is my first patch to X.Org, so please tell me if there's something > wrong with the submission or the patch itself. > > natano > It looks good to me. 2 little things though: - you should use 'git commit -s' to generate a Signed-off-by: field in the commit message - the reason why this patch is needed is a limitation of BSD make GNU make doesn't trigger the extra rebuild during make install. PS: I tend to consider the BSD make behaviour as a bug, but no one ever cared to fix it :( > > From e3601d791790ee0f1d0979e4d2a3852c390cd758 Mon Sep 17 00:00:00 2001 > From: Martin Natano > Date: Sat, 8 Oct 2016 19:57:50 +0200 > Subject: [PATCH] Don't rebuild ks_tables.h if nothing changed. > > ks_tables.h is always considered out of date due to the forced rebuild > of the makekeys util. This means the file is also rebuilt during 'make > install', which is usually performed as root, which can to lead > permission problems later on. > --- > src/Makefile.am | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/src/Makefile.am b/src/Makefile.am > index 15de59b..f8c476d 100644 > --- a/src/Makefile.am > +++ b/src/Makefile.am > @@ -415,7 +415,5 @@ ks_tables.h: $(KEYSYMDEFS) $(top_builddir)/src/util/makekeys$(EXEEXT) > $(top_builddir)/src/util/makekeys $(KEYSYMDEFS) > ks_tables_h > mv ks_tables_h $@ > > -$(top_builddir)/src/util/makekeys$(EXEEXT): force > +$(top_builddir)/src/util/makekeys$(EXEEXT): $(top_builddir)/src/util/makekeys.c > cd util && $(MAKE) > - > -force: > -- > 2.9.3 -- Matthieu Herrb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From matthieu at herrb.eu Sat Oct 8 21:45:50 2016 From: matthieu at herrb.eu (Matthieu Herrb) Date: Sat, 8 Oct 2016 23:45:50 +0200 Subject: [PATCH libX11] Don't rebuild ks_tables.h if nothing changed. In-Reply-To: <20161008212245.GA22754@watschnbaum.natano.net> References: <20161008180858.GA39383@watschnbaum.natano.net> <20161008194509.GC33240@nebraska.herrb.net> <20161008212245.GA22754@watschnbaum.natano.net> Message-ID: <20161008214550.GD33240@nebraska.herrb.net> On Sat, Oct 08, 2016 at 11:22:45PM +0200, Martin Natano wrote: > On Sat, Oct 08, 2016 at 09:45:09PM +0200, Matthieu Herrb wrote: > > > > It looks good to me. 2 little things though: > > > > - you should use 'git commit -s' to generate a Signed-off-by: field in > > the commit message > > See the updated diff below. > > > > > > - the reason why this patch is needed is a limitation of BSD make > > GNU make doesn't trigger the extra rebuild during make install. > > > > PS: I tend to consider the BSD make behaviour as a bug, but no one ever > > cared to fix it :( > > Curious, What's the bug? The force target is not marked phony, so it's > always out-of-date due to the eponymous file not existing. Then force > out-of-date -> rebuild makekeys, makekeys newer than ks_tables.h -> > rebuild ks_tables.h. What should the behaviour be instead? Unless I'm wrong 'force' will force make to recurse in utils/ but if makekeys is up-to-date, it won't be rebuilt the 2nd time, its timestamp doesn't change, and so ks_tables.h should not be rebuilt. I had a small test case for that behaviour somewhere... > > natano > > > From 75d5e9b763069310cb2b0d0bac2a49175029449a Mon Sep 17 00:00:00 2001 > From: Martin Natano > Date: Sat, 8 Oct 2016 19:57:50 +0200 > Subject: [PATCH] Don't rebuild ks_tables.h if nothing changed. > > ks_tables.h is always considered out of date due to the forced rebuild > of the makekeys util. This means the file is also rebuilt during 'make > install', which is usually performed as root, which can to lead > permission problems later on. > > Signed-off-by: Martin Natano > --- > src/Makefile.am | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/src/Makefile.am b/src/Makefile.am > index 15de59b..f8c476d 100644 > --- a/src/Makefile.am > +++ b/src/Makefile.am > @@ -415,7 +415,5 @@ ks_tables.h: $(KEYSYMDEFS) $(top_builddir)/src/util/makekeys$(EXEEXT) > $(top_builddir)/src/util/makekeys $(KEYSYMDEFS) > ks_tables_h > mv ks_tables_h $@ > > -$(top_builddir)/src/util/makekeys$(EXEEXT): force > +$(top_builddir)/src/util/makekeys$(EXEEXT): $(top_builddir)/src/util/makekeys.c > cd util && $(MAKE) > - > -force: > -- > 2.9.3 -- Matthieu Herrb -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 793 bytes Desc: not available URL: From emil.l.velikov at gmail.com Sun Oct 9 14:34:28 2016 From: emil.l.velikov at gmail.com (Emil Velikov) Date: Sun, 9 Oct 2016 15:34:28 +0100 Subject: [PATCH libXi] SizeClassInfo can return 0 even without an error In-Reply-To: <20161007194644.31537-1-niels_ole@salscheider-online.de> References: <20161007194644.31537-1-niels_ole@salscheider-online.de> Message-ID: Hi Niels, On Friday, 7 October 2016, Niels Ole Salscheider < niels_ole at salscheider-online.de> wrote: > Catch the error case separately. This fixes a few crashes on my computer. > > Signed-off-by: Niels Ole Salscheider > > --- > src/XListDev.c | 21 ++++++++++----------- > 1 file changed, 10 insertions(+), 11 deletions(-) > > diff --git a/src/XListDev.c b/src/XListDev.c > index f850cd0..d0c6bf2 100644 > --- a/src/XListDev.c > +++ b/src/XListDev.c > @@ -73,27 +73,27 @@ static int pad_to_xid(int base_size) > return ((base_size + padsize - 1)/padsize) * padsize; > } > > -static size_t > -SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes) > +static int > +SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes, size_t > *size) > { > - int size = 0; > int j; > + *size = 0; No function should alter the contents of the arguments in case of an error. For your other libXi patch one might want to fix the callers, if applicable. If possible please mention a bug report/link or a bit more about how you hit this. Wondering how it has gone unnoticed for so long. That aside, nicely spotted ! Emil -------------- next part -------------- An HTML attachment was scrubbed... URL: From emil.l.velikov at gmail.com Sun Oct 9 14:42:52 2016 From: emil.l.velikov at gmail.com (Emil Velikov) Date: Sun, 9 Oct 2016 15:42:52 +0100 Subject: [PATCH 3/3] configure.ac: remove --enable-aiglx option In-Reply-To: <947dabc9-a478-fe76-ec42-9af14cba5e39@dronecode.org.uk> References: <20160929174119.14505-1-emil.l.velikov@gmail.com> <20160929174119.14505-3-emil.l.velikov@gmail.com> <2e40463a-98fd-3bd9-6977-e065a7175a3a@dronecode.org.uk> <947dabc9-a478-fe76-ec42-9af14cba5e39@dronecode.org.uk> Message-ID: On Friday, 7 October 2016, Jon Turney wrote: > On 06/10/2016 19:15, Emil Velikov wrote: > >> On 6 October 2016 at 19:02, Jon Turney >> wrote: >> >>> On 29/09/2016 18:41, Emil Velikov wrote: >>> >>>> >>>> Presently the option guards both direct and accelerated indirect GLX. As >>>> such when one toggles it off they end up without any acceleration. >>>> >>>> Remove the option all together until we have the time to split/rework >>>> things. >>>> >>>> Cc: Jon Turney >>>> Cc: Adam Jackson >>>> Signed-off-by: Emil Velikov >>>> --- >>>> Jon, I've not checked the Xwin side of things but considering that the >>>> option is enabled by default and having it for Xwin only will be >>>> confusing I've nuked the guards throughout the tree. >>>> >>> >>> Sorry I didn't get around to testing this before it was committed. >>> >>> This breaks my build (See [1]), as the DRI2 loader is now built >>> unconditionally, which fails without drm.h >>> >>> I'm not sure exactly what problem this change is fixing, so I'm not sure >>> how >>> to address that. >>> >>> Is it ok to restore the part which makes building the DRI2 loader >>> conditional? >>> >>> I had a bad feeling about this, fortunately it seems pretty easy to >> handle. >> >> From a quick look nothing in glx/glxdri2.c should require libdrm so we >> can nuke the drm.h and xf86drm.h includes, which will get you back up >> and going. Alternatively we can add those in a ifdef WITH_LIBDRM/endif >> block. >> > > That's not quite enough, as building glxdri2.c also requires dri2proto > headers. > > At the moment, configure.ac only requires dri2proto when --enable-dri2 > turns on. > > So either that needs to be made unconditional, or building glxdri2.c made > conditional on DRI2 (untested patch attached) > > You're correct. Wrapping it in DRI2 conditional is a good idea. Note creating an empty (no sources or static libs) library is likely to cause problems. Just use the form prior to my patch ? Emil -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremyhu at apple.com Sun Oct 9 19:51:03 2016 From: jeremyhu at apple.com (Jeremy Huddleston Sequoia) Date: Sun, 9 Oct 2016 12:51:03 -0700 Subject: [PATCH 2/3] randr: Initialize RandR even if there are currently no screens attached In-Reply-To: <20161009195104.47686-1-jeremyhu@apple.com> References: <20161009195104.47686-1-jeremyhu@apple.com> Message-ID: <20161009195104.47686-2-jeremyhu@apple.com> Failure to do so causes an overvlow in RRClientCallback(). ================================================================= ==41262==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000103ccfbc8 at pc 0x0001034f32b9 bp 0x7000035a94c0 sp 0x7000035a94b8 WRITE of size 4 at 0x000103ccfbc8 thread T6 #0 0x1034f32b8 in RRClientCallback randr.c:72 #1 0x1038c75e3 in _CallCallbacks dixutils.c:737 #2 0x10388f406 in CallCallbacks callback.h:83 #3 0x1038bc49a in NextAvailableClient dispatch.c:3562 #4 0x103ad094c in AllocNewConnection connection.c:777 #5 0x103ad1695 in EstablishNewConnections connection.c:863 #6 0x1038c6630 in ProcessWorkQueue dixutils.c:523 #7 0x103ab2dbf in WaitForSomething WaitFor.c:175 #8 0x103880836 in Dispatch dispatch.c:411 #9 0x1038c2141 in dix_main main.c:301 #10 0x1032ac75a in server_thread quartzStartup.c:66 #11 0x7fffc5f16aaa in _pthread_body (libsystem_pthread.dylib+0x3aaa) #12 0x7fffc5f169f6 in _pthread_start (libsystem_pthread.dylib+0x39f6) #13 0x7fffc5f161fc in thread_start (libsystem_pthread.dylib+0x31fc) Signed-off-by: Jeremy Huddleston Sequoia --- randr/randr.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/randr/randr.c b/randr/randr.c index 0138dc1..efd3859 100644 --- a/randr/randr.c +++ b/randr/randr.c @@ -387,9 +387,6 @@ RRExtensionInit(void) { ExtensionEntry *extEntry; - if (RRNScreens == 0) - return; - if (!dixRegisterPrivateKey(&RRClientPrivateKeyRec, PRIVATE_CLIENT, sizeof(RRClientRec) + screenInfo.numScreens * sizeof(RRTimesRec))) -- 2.9.3 From jeremyhu at apple.com Sun Oct 9 19:51:04 2016 From: jeremyhu at apple.com (Jeremy Huddleston Sequoia) Date: Sun, 9 Oct 2016 12:51:04 -0700 Subject: [PATCH 3/3] glx: Initialize glx even if there are currently no screens attached In-Reply-To: <20161009195104.47686-1-jeremyhu@apple.com> References: <20161009195104.47686-1-jeremyhu@apple.com> Message-ID: <20161009195104.47686-3-jeremyhu@apple.com> Failure to do so causes an overvlow in glxClientCallback Application Specific Information: X.Org X Server 1.18.99.1 Build Date: 20160911 ================================================================= ==52118==ERROR: AddressSanitizer: SEGV on unknown address 0x000102b27b80 (pc 0x000103433245 bp 0x70000de67c20 sp 0x70000de67c00 T6) #0 0x103433244 in __asan::asan_free(void*, __sanitizer::BufferedStackTrace*, __asan::AllocType) (libclang_rt.asan_osx_dynamic.dylib+0x3244) #1 0x10347aeee in wrap_free (libclang_rt.asan_osx_dynamic.dylib+0x4aeee) #2 0x102e6a5ed in glxClientCallback glxext.c:301 #3 0x102b672a3 in _CallCallbacks dixutils.c:737 #4 0x102b2f0c6 in CallCallbacks callback.h:83 #5 0x102b5c15a in NextAvailableClient dispatch.c:3562 #6 0x102d7060c in AllocNewConnection connection.c:777 #7 0x102d71355 in EstablishNewConnections connection.c:863 #8 0x102b662f0 in ProcessWorkQueue dixutils.c:523 #9 0x102d52a7f in WaitForSomething WaitFor.c:175 #10 0x102b204f6 in Dispatch dispatch.c:411 #11 0x102b61e01 in dix_main main.c:301 #12 0x10254c42a in server_thread quartzStartup.c:66 #13 0x7fffc5f16aaa in _pthread_body (libsystem_pthread.dylib+0x3aaa) #14 0x7fffc5f169f6 in _pthread_start (libsystem_pthread.dylib+0x39f6) #15 0x7fffc5f161fc in thread_start (libsystem_pthread.dylib+0x31fc) Signed-off-by: Jeremy Huddleston Sequoia --- glx/glxext.c | 21 --------------------- 1 file changed, 21 deletions(-) diff --git a/glx/glxext.c b/glx/glxext.c index d595a05..d216c9d 100644 --- a/glx/glxext.c +++ b/glx/glxext.c @@ -319,23 +319,6 @@ GlxPushProvider(__GLXprovider * provider) __glXProviderStack = provider; } -static Bool -checkScreenVisuals(void) -{ - int i, j; - - for (i = 0; i < screenInfo.numScreens; i++) { - ScreenPtr screen = screenInfo.screens[i]; - for (j = 0; j < screen->numVisuals; j++) { - if (screen->visuals[j].class == TrueColor || - screen->visuals[j].class == DirectColor) - return True; - } - } - - return False; -} - static void GetGLXDrawableBytes(void *value, XID id, ResourceSizePtr size) { @@ -371,10 +354,6 @@ GlxExtensionInit(void) *stack = &__glXDRISWRastProvider; } - /* Mesa requires at least one True/DirectColor visual */ - if (!checkScreenVisuals()) - return; - __glXContextRes = CreateNewResourceType((DeleteType) ContextGone, "GLXContext"); __glXDrawableRes = CreateNewResourceType((DeleteType) DrawableGone, -- 2.9.3 From jeremyhu at apple.com Sun Oct 9 19:51:02 2016 From: jeremyhu at apple.com (Jeremy Huddleston Sequoia) Date: Sun, 9 Oct 2016 12:51:02 -0700 Subject: [PATCH 1/3] os/connection: Improve abstraction for launchd secure sockets Message-ID: <20161009195104.47686-1-jeremyhu@apple.com> This changes away from hard-coding the /tmp/launch-* path to now supporting a generic [.] format for $DISPLAY. cf-libxcb: d978a4f69b30b630f28d07f1003cf290284d24d8 Signed-off-by: Jeremy Huddleston Sequoia CC: Adam Jackson --- os/connection.c | 31 ++++++++++++++++++++++++++----- 1 file changed, 26 insertions(+), 5 deletions(-) diff --git a/os/connection.c b/os/connection.c index a901ebf..0d42184 100644 --- a/os/connection.c +++ b/os/connection.c @@ -79,6 +79,8 @@ SOFTWARE. #include #include +#include + #ifndef WIN32 #include @@ -1112,15 +1114,34 @@ MakeClientGrabPervious(ClientPtr client) void ListenOnOpenFD(int fd, int noxauth) { - char port[256]; + char port[PATH_MAX]; XtransConnInfo ciptr; const char *display_env = getenv("DISPLAY"); - if (display_env && (strncmp(display_env, "/tmp/launch", 11) == 0)) { - /* Make the path the launchd socket if our DISPLAY is set right */ - strcpy(port, display_env); + /* First check if display_env matches a [.] scheme (eg: launchd) */ + if (display_env && display_env[0] == '/') { + struct stat sbuf; + + strlcpy(port, display_env, sizeof(port)); + + /* If the path exists, we don't have do do anything else. + * If it doesn't, we need to check for a . to strip off and recheck. + */ + if (0 != stat(port, &sbuf)) { + char *dot = strrchr(port, '.'); + if (dot) { + *dot = '\0'; + + if (0 != stat(port, &sbuf)) { + display_env = NULL; + } + } else { + display_env = NULL; + } + } } - else { + + if (!display_env) { /* Just some default so things don't break and die. */ snprintf(port, sizeof(port), ":%d", atoi(display)); } -- 2.9.3 From niels_ole at salscheider-online.de Sun Oct 9 20:31:08 2016 From: niels_ole at salscheider-online.de (Niels Ole Salscheider) Date: Sun, 09 Oct 2016 22:31:08 +0200 Subject: [PATCH libXi] SizeClassInfo can return 0 even without an error In-Reply-To: References: <20161007194644.31537-1-niels_ole@salscheider-online.de> Message-ID: <7131961.vthyBo74SY@oledesktop> Hi Emil, On Sunday, 9 October 2016, 15:34:28 CEST, Emil Velikov wrote: > Hi Niels, > > On Friday, 7 October 2016, Niels Ole Salscheider < > > niels_ole at salscheider-online.de> wrote: > > Catch the error case separately. This fixes a few crashes on my computer. > > > > Signed-off-by: Niels Ole Salscheider > > > > --- > > > > src/XListDev.c | 21 ++++++++++----------- > > 1 file changed, 10 insertions(+), 11 deletions(-) > > > > diff --git a/src/XListDev.c b/src/XListDev.c > > index f850cd0..d0c6bf2 100644 > > --- a/src/XListDev.c > > +++ b/src/XListDev.c > > @@ -73,27 +73,27 @@ static int pad_to_xid(int base_size) > > > > return ((base_size + padsize - 1)/padsize) * padsize; > > > > } > > > > -static size_t > > -SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes) > > +static int > > +SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes, size_t > > *size) > > > > { > > > > - int size = 0; > > > > int j; > > > > + *size = 0; > > No function should alter the contents of the arguments in case of an error. > For your other libXi patch one might want to fix the callers, if applicable. > > If possible please mention a bug report/link or a bit more about how you > hit this. Wondering how it has gone unnoticed for so long. I encountered the bug in chromium and all users of it, including all applications that use QtWebEngine. I now hit the error path because of the bug that is fixed by this patch. Chromium crashes in the following lines: https://chromium.googlesource.com/ chromium/src/+/master/ui/events/devices/x11/device_data_manager_x11.cc#246 Here, GetXDeviceList calls XListInputDevices: https://chromium.googlesource.com/chromium/src/+/master/ui/events/devices/x11/ device_list_cache_x11.cc#53 The chromium implementation is only correct if ndevices is set to 0 in the error case since it does not check if a null pointer is returned. I was not sure if it is supposed to do the latter since the man page for XListInputDevices doesn't mention it. > That aside, nicely spotted ! > Emil From emil.l.velikov at gmail.com Mon Oct 10 09:10:27 2016 From: emil.l.velikov at gmail.com (Emil Velikov) Date: Mon, 10 Oct 2016 10:10:27 +0100 Subject: [PATCH xf86-input-libinput] Fix crash when using threaded input and the first device goes away In-Reply-To: <20161005133138.9672-1-hdegoede@redhat.com> References: <20161005133138.9672-1-hdegoede@redhat.com> Message-ID: Hi Hans, On Wednesday, 5 October 2016, Hans de Goede wrote: > When the xserver uses threaded input, it keeps a pointer to the InputInfo > passed into xf86AddEnabledDevice and calls pointer->read_input on events. > > But when the first enabled device goes away the pInfo we've passed into > xf86AddEnabledDevice gets freed and eventually pInfo->read_input gets > overwritten (or pInfo points to unmapped memory) leading to a segfault. > > This commit fixes this by replacing the pInfo passed into > xf86AddEnabledDevice with a pointer to a global InputInfo stored inside > the driver_context struct. > > Signed-off-by: Hans de Goede > > --- > src/xf86libinput.c | 22 ++++++++++++++++------ > 1 file changed, 16 insertions(+), 6 deletions(-) > > diff --git a/src/xf86libinput.c b/src/xf86libinput.c > index 21f87f5..485e212 100644 > --- a/src/xf86libinput.c > +++ b/src/xf86libinput.c > @@ -86,6 +86,7 @@ > > struct xf86libinput_driver { > struct libinput *libinput; > + struct _InputInfoRec InputInfo; > int device_enabled_count; > }; > > @@ -582,7 +583,17 @@ xf86libinput_on(DeviceIntPtr dev) > > if (driver_context.device_enabled_count == 0) { > #if HAVE_THREADED_INPUT > - xf86AddEnabledDevice(pInfo); > + /* > + * The xserver keeps a pointer to the InputInfo passed into > + * xf86AddEnabledDevice and calls pointer->read_input on > + * events. Thus we cannot simply pass in our current pInfo > + * as that will be deleted when the current input device > gets > + * unplugged. Instead pass in a pointer to a global > + * InputInfo inside the driver_context. > + */ > + driver_context.InputInfo.fd = pInfo->fd; Reading the above comment makes me wonder about the lifetime of the fd. I take it that we're not leaking it atm ? > + driver_context.InputInfo.read_input = pInfo->read_input; > + xf86AddEnabledDevice(&driver_context.InputInfo); > #else > /* Can't use xf86AddEnabledDevice on an epollfd */ > AddEnabledDevice(pInfo->fd); Can we use the same storage for the !HAVE_THREADED_INPUT code paths ? > @@ -606,7 +617,7 @@ xf86libinput_off(DeviceIntPtr dev) > > if (--driver_context.device_enabled_count == 0) { > #if HAVE_THREADED_INPUT > - xf86RemoveEnabledDevice(pInfo); > + xf86RemoveEnabledDevice(&driver_context.InputInfo); > #else > RemoveEnabledDevice(pInfo->fd); > #endif > @@ -1923,7 +1934,7 @@ out: > } > > static void > -xf86libinput_read_input(InputInfoPtr pInfo) > +xf86libinput_read_input(InputInfoPtr do_not_use) Worth just dropping the argument and fixing the caller(s)? Emil -------------- next part -------------- An HTML attachment was scrubbed... URL: From emil.l.velikov at gmail.com Mon Oct 10 10:11:41 2016 From: emil.l.velikov at gmail.com (Emil Velikov) Date: Mon, 10 Oct 2016 11:11:41 +0100 Subject: [PATCH 1/3] os/connection: Improve abstraction for launchd secure sockets In-Reply-To: <20161009195104.47686-1-jeremyhu@apple.com> References: <20161009195104.47686-1-jeremyhu@apple.com> Message-ID: On 9 October 2016 at 20:51, Jeremy Huddleston Sequoia wrote: > This changes away from hard-coding the /tmp/launch-* path to now > supporting a generic [.] > format for $DISPLAY. > > cf-libxcb: d978a4f69b30b630f28d07f1003cf290284d24d8 > > Signed-off-by: Jeremy Huddleston Sequoia > CC: Adam Jackson > --- > os/connection.c | 31 ++++++++++++++++++++++++++----- > 1 file changed, 26 insertions(+), 5 deletions(-) > > diff --git a/os/connection.c b/os/connection.c > index a901ebf..0d42184 100644 > --- a/os/connection.c > +++ b/os/connection.c > @@ -79,6 +79,8 @@ SOFTWARE. > #include > #include > > +#include > + > #ifndef WIN32 > #include > > @@ -1112,15 +1114,34 @@ MakeClientGrabPervious(ClientPtr client) > void > ListenOnOpenFD(int fd, int noxauth) > { > - char port[256]; > + char port[PATH_MAX]; ... = {0, }; // or port[0] = 0; > XtransConnInfo ciptr; > const char *display_env = getenv("DISPLAY"); > > - if (display_env && (strncmp(display_env, "/tmp/launch", 11) == 0)) { > - /* Make the path the launchd socket if our DISPLAY is set right */ > - strcpy(port, display_env); > + /* First check if display_env matches a [.] scheme (eg: launchd) */ > + if (display_env && display_env[0] == '/') { As-is the patch will accept badly formed DISPLAY and port will end up garbage. Might be better to keep track of/override port instead. > + struct stat sbuf; > + > + strlcpy(port, display_env, sizeof(port)); > + > + /* If the path exists, we don't have do do anything else. > + * If it doesn't, we need to check for a . to strip off and recheck. > + */ > + if (0 != stat(port, &sbuf)) { Nit: !stat(...) > + char *dot = strrchr(port, '.'); > + if (dot) { > + *dot = '\0'; > + > + if (0 != stat(port, &sbuf)) { Ditto > + display_env = NULL; port[0] = 0; > + } > + } else { > + display_env = NULL; Ditto. > + } > + } > } > - else { > + > + if (!display_env) { if (!port[0]) { Regards, Emil From emil.l.velikov at gmail.com Mon Oct 10 10:24:28 2016 From: emil.l.velikov at gmail.com (Emil Velikov) Date: Mon, 10 Oct 2016 11:24:28 +0100 Subject: [PATCH libXi] SizeClassInfo can return 0 even without an error In-Reply-To: <7131961.vthyBo74SY@oledesktop> References: <20161007194644.31537-1-niels_ole@salscheider-online.de> <7131961.vthyBo74SY@oledesktop> Message-ID: On 9 October 2016 at 21:31, Niels Ole Salscheider wrote: > Hi Emil, > > On Sunday, 9 October 2016, 15:34:28 CEST, Emil Velikov wrote: >> Hi Niels, >> >> On Friday, 7 October 2016, Niels Ole Salscheider < >> >> niels_ole at salscheider-online.de> wrote: >> > Catch the error case separately. This fixes a few crashes on my computer. >> > >> > Signed-off-by: Niels Ole Salscheider > > > >> > --- >> > >> > src/XListDev.c | 21 ++++++++++----------- >> > 1 file changed, 10 insertions(+), 11 deletions(-) >> > >> > diff --git a/src/XListDev.c b/src/XListDev.c >> > index f850cd0..d0c6bf2 100644 >> > --- a/src/XListDev.c >> > +++ b/src/XListDev.c >> > @@ -73,27 +73,27 @@ static int pad_to_xid(int base_size) >> > >> > return ((base_size + padsize - 1)/padsize) * padsize; >> > >> > } >> > >> > -static size_t >> > -SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes) >> > +static int >> > +SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes, size_t >> > *size) >> > >> > { >> > >> > - int size = 0; >> > >> > int j; >> > >> > + *size = 0; >> >> No function should alter the contents of the arguments in case of an error. >> For your other libXi patch one might want to fix the callers, if applicable. >> >> If possible please mention a bug report/link or a bit more about how you >> hit this. Wondering how it has gone unnoticed for so long. > > I encountered the bug in chromium and all users of it, including all > applications that use QtWebEngine. I now hit the error path because of the bug > that is fixed by this patch. > > Chromium crashes in the following lines: https://chromium.googlesource.com/ > chromium/src/+/master/ui/events/devices/x11/device_data_manager_x11.cc#246 > Here, GetXDeviceList calls XListInputDevices: > https://chromium.googlesource.com/chromium/src/+/master/ui/events/devices/x11/ > device_list_cache_x11.cc#53 > > The chromium implementation is only correct if ndevices is set to 0 in the > error case since it does not check if a null pointer is returned. I was not > sure if it is supposed to do the latter since the man page for > XListInputDevices doesn't mention it. > Eeek, the man page does not mention anything, indeed. So even if one updates/corrects the man page there'll likely be other users which depend on ndevices being 0. That said, you can drop the odd(?) practise from this patch and use it only in the latter ? Please mention your findings (above) in the commit message/patch body. Thanks Emil From emil.l.velikov at gmail.com Mon Oct 10 10:33:40 2016 From: emil.l.velikov at gmail.com (Emil Velikov) Date: Mon, 10 Oct 2016 11:33:40 +0100 Subject: [PATCH 2/3] randr: Initialize RandR even if there are currently no screens attached In-Reply-To: <20161009195104.47686-2-jeremyhu@apple.com> References: <20161009195104.47686-1-jeremyhu@apple.com> <20161009195104.47686-2-jeremyhu@apple.com> Message-ID: Hi Jeremy, On 9 October 2016 at 20:51, Jeremy Huddleston Sequoia wrote: > Failure to do so causes an overvlow in RRClientCallback(). > s/overvlow/overflow/ Perhaps a slightly silly question: How can one end up in the callback if we haven't executed AddCallback(&ClientStateCallback, fooCallback... ? Regards, Emil From consume.noise at gmail.com Mon Oct 10 11:14:19 2016 From: consume.noise at gmail.com (Daniel Martin) Date: Mon, 10 Oct 2016 13:14:19 +0200 Subject: [PATCH xserver] os/xdmcp: Honour -once when session is dead In-Reply-To: <1475237106-30481-1-git-send-email-consume.noise@gmail.com> References: <1475237106-30481-1-git-send-email-consume.noise@gmail.com> Message-ID: Imho this could be picked for 1.19. Anyone willing to give his Rb? On 30 September 2016 at 14:05, Daniel Martin wrote: > Terminate a dead session when -once was passed. Don't restart it. > > Signed-off-by: Daniel Martin > --- > os/xdmcp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/os/xdmcp.c b/os/xdmcp.c > index 906c959..7aeb393 100644 > --- a/os/xdmcp.c > +++ b/os/xdmcp.c > @@ -797,7 +797,7 @@ XdmcpDeadSession(const char *reason) > ErrorF("XDM: %s, declaring session dead\n", reason); > state = XDM_INIT_STATE; > isItTimeToYield = TRUE; > - dispatchException |= DE_RESET; > + dispatchException |= (OneSession ? DE_TERMINATE : DE_RESET); > TimerCancel(xdmcp_timer); > timeOutRtx = 0; > send_packet(); > -- > 2.10.0 > From wharms at bfs.de Mon Oct 10 11:38:21 2016 From: wharms at bfs.de (walter harms) Date: Mon, 10 Oct 2016 13:38:21 +0200 Subject: [PATCH libXi] SizeClassInfo can return 0 even without an error In-Reply-To: References: <20161007194644.31537-1-niels_ole@salscheider-online.de> <7131961.vthyBo74SY@oledesktop> Message-ID: <57FB7DAD.4000009@bfs.de> Am 10.10.2016 12:24, schrieb Emil Velikov: > On 9 October 2016 at 21:31, Niels Ole Salscheider > wrote: >> Hi Emil, >> >> On Sunday, 9 October 2016, 15:34:28 CEST, Emil Velikov wrote: >>> Hi Niels, >>> >>> On Friday, 7 October 2016, Niels Ole Salscheider < >>> >>> niels_ole at salscheider-online.de> wrote: >>>> Catch the error case separately. This fixes a few crashes on my computer. >>>> >>>> Signed-off-by: Niels Ole Salscheider >>> > >>>> --- >>>> >>>> src/XListDev.c | 21 ++++++++++----------- >>>> 1 file changed, 10 insertions(+), 11 deletions(-) >>>> >>>> diff --git a/src/XListDev.c b/src/XListDev.c >>>> index f850cd0..d0c6bf2 100644 >>>> --- a/src/XListDev.c >>>> +++ b/src/XListDev.c >>>> @@ -73,27 +73,27 @@ static int pad_to_xid(int base_size) >>>> >>>> return ((base_size + padsize - 1)/padsize) * padsize; >>>> >>>> } >>>> >>>> -static size_t >>>> -SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes) >>>> +static int >>>> +SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes, size_t >>>> *size) >>>> >>>> { >>>> >>>> - int size = 0; >>>> >>>> int j; >>>> >>>> + *size = 0; >>> >>> No function should alter the contents of the arguments in case of an error. >>> For your other libXi patch one might want to fix the callers, if applicable. >>> >>> If possible please mention a bug report/link or a bit more about how you >>> hit this. Wondering how it has gone unnoticed for so long. >> >> I encountered the bug in chromium and all users of it, including all >> applications that use QtWebEngine. I now hit the error path because of the bug >> that is fixed by this patch. >> >> Chromium crashes in the following lines: https://chromium.googlesource.com/ >> chromium/src/+/master/ui/events/devices/x11/device_data_manager_x11.cc#246 >> Here, GetXDeviceList calls XListInputDevices: >> https://chromium.googlesource.com/chromium/src/+/master/ui/events/devices/x11/ >> device_list_cache_x11.cc#53 >> >> The chromium implementation is only correct if ndevices is set to 0 in the >> error case since it does not check if a null pointer is returned. I was not >> sure if it is supposed to do the latter since the man page for >> XListInputDevices doesn't mention it. >> > Eeek, the man page does not mention anything, indeed. So even if one > updates/corrects the man page there'll likely be other users which > depend on ndevices being 0. but someone should fix the man-page. NTL it is common practice to assume that variables are not proper initialized if the function that initialize returns any error. re, wh > > That said, you can drop the odd(?) practise from this patch and use it > only in the latter ? Please mention your findings (above) in the > commit message/patch body. > > Thanks > Emil > _______________________________________________ > xorg-devel at lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel From wharms at bfs.de Mon Oct 10 11:43:06 2016 From: wharms at bfs.de (walter harms) Date: Mon, 10 Oct 2016 13:43:06 +0200 Subject: [PATCH xserver] os/xdmcp: Honour -once when session is dead In-Reply-To: <1475237106-30481-1-git-send-email-consume.noise@gmail.com> References: <1475237106-30481-1-git-send-email-consume.noise@gmail.com> Message-ID: <57FB7ECA.7000703@bfs.de> looks good to me (and hope that helps) reviewed-by: wharms re, wh Am 30.09.2016 14:05, schrieb Daniel Martin: > Terminate a dead session when -once was passed. Don't restart it. > > Signed-off-by: Daniel Martin > --- > os/xdmcp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/os/xdmcp.c b/os/xdmcp.c > index 906c959..7aeb393 100644 > --- a/os/xdmcp.c > +++ b/os/xdmcp.c > @@ -797,7 +797,7 @@ XdmcpDeadSession(const char *reason) > ErrorF("XDM: %s, declaring session dead\n", reason); > state = XDM_INIT_STATE; > isItTimeToYield = TRUE; > - dispatchException |= DE_RESET; > + dispatchException |= (OneSession ? DE_TERMINATE : DE_RESET); > TimerCancel(xdmcp_timer); > timeOutRtx = 0; > send_packet(); From hdegoede at redhat.com Mon Oct 10 12:13:22 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Mon, 10 Oct 2016 14:13:22 +0200 Subject: [PATCH xf86-input-libinput] Fix crash when using threaded input and the first device goes away In-Reply-To: References: <20161005133138.9672-1-hdegoede@redhat.com> Message-ID: Hi, On 10/10/2016 11:10 AM, Emil Velikov wrote: > Hi Hans, > > On Wednesday, 5 October 2016, Hans de Goede > wrote: > > When the xserver uses threaded input, it keeps a pointer to the InputInfo > passed into xf86AddEnabledDevice and calls pointer->read_input on events. > > But when the first enabled device goes away the pInfo we've passed into > xf86AddEnabledDevice gets freed and eventually pInfo->read_input gets > overwritten (or pInfo points to unmapped memory) leading to a segfault. > > This commit fixes this by replacing the pInfo passed into > xf86AddEnabledDevice with a pointer to a global InputInfo stored inside > the driver_context struct. > > Signed-off-by: Hans de Goede > --- > src/xf86libinput.c | 22 ++++++++++++++++------ > 1 file changed, 16 insertions(+), 6 deletions(-) > > diff --git a/src/xf86libinput.c b/src/xf86libinput.c > index 21f87f5..485e212 100644 > --- a/src/xf86libinput.c > +++ b/src/xf86libinput.c > @@ -86,6 +86,7 @@ > > struct xf86libinput_driver { > struct libinput *libinput; > + struct _InputInfoRec InputInfo; > int device_enabled_count; > }; > > @@ -582,7 +583,17 @@ xf86libinput_on(DeviceIntPtr dev) > > if (driver_context.device_enabled_count == 0) { > #if HAVE_THREADED_INPUT > - xf86AddEnabledDevice(pInfo); > + /* > + * The xserver keeps a pointer to the InputInfo passed into > + * xf86AddEnabledDevice and calls pointer->read_input on > + * events. Thus we cannot simply pass in our current pInfo > + * as that will be deleted when the current input device gets > + * unplugged. Instead pass in a pointer to a global > + * InputInfo inside the driver_context. > + */ > + driver_context.InputInfo.fd = pInfo->fd; > > Reading the above comment makes me wonder about the lifetime of the fd. I take it that we're not leaking it atm ? The fd here actually is libinput's epoll fd, which is shared by all the devices and gets closed when we destroy the libinput context which we do already when the last libinput driven device gets removed. > + driver_context.InputInfo.read_input = pInfo->read_input; > + xf86AddEnabledDevice(&driver_context.InputInfo); > #else > /* Can't use xf86AddEnabledDevice on an epollfd */ > AddEnabledDevice(pInfo->fd); > > Can we use the same storage for the !HAVE_THREADED_INPUT code paths ? I've not looked closely at the !threaded code paths, but AFAIK the non threaded paths take just a fd; and then later lookup the pInfo in the list of devices, so in that case the pInfo must be a real pInfo. > > > @@ -606,7 +617,7 @@ xf86libinput_off(DeviceIntPtr dev) > > if (--driver_context.device_enabled_count == 0) { > #if HAVE_THREADED_INPUT > - xf86RemoveEnabledDevice(pInfo); > + xf86RemoveEnabledDevice(&driver_context.InputInfo); > #else > RemoveEnabledDevice(pInfo->fd); > #endif > @@ -1923,7 +1934,7 @@ out: > } > > static void > -xf86libinput_read_input(InputInfoPtr pInfo) > +xf86libinput_read_input(InputInfoPtr do_not_use) > > Worth just dropping the argument and fixing the caller(s)? This is a callback function called by the server, so we cannot just change the signature; and other input drivers are likely to actually use the argument. Regards, Hans From hdegoede at redhat.com Mon Oct 10 12:19:50 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Mon, 10 Oct 2016 14:19:50 +0200 Subject: [xserver PULL for 1.19] Various fixes Message-ID: <6161ecd3-0125-d062-56c8-254fe504b572@redhat.com> Hi Adam, Keith, Here is a pull-req with 2 prime hw cursor fixes from Michel Dänzer, reviewed by me and 1 fix from me reviewed by Keith. The following changes since commit 97a8353ec1192d8d3bd2ebb99e5687cb91427e09: Fix id in error when resource does not exist (2016-10-06 14:50:42 -0400) are available in the git repository at: git://people.freedesktop.org/~jwrdegoede/xserver for-server-1.19 for you to fetch changes up to 6979eb819e436416029a8ff32e7d356322939898: xf86Cursor: Take the input lock in xf86Set/MoveCursor (2016-10-10 11:14:56 +0200) ---------------------------------------------------------------- Hans de Goede (1): inputthread: Fix inputthread not listening if a fd gets re-added immediately after removal Michel Dänzer (2): xf86Cursor: Use PRIME master xf86CursorScreenRec::HotX/Y for slaves xf86Cursor: Take the input lock in xf86Set/MoveCursor hw/xfree86/ramdac/xf86HWCurs.c | 37 ++++++++++++++++++++++++++++++------- os/inputthread.c | 2 ++ 2 files changed, 32 insertions(+), 7 deletions(-) Regards, Hans From jon.turney at dronecode.org.uk Mon Oct 10 14:59:52 2016 From: jon.turney at dronecode.org.uk (Jon Turney) Date: Mon, 10 Oct 2016 15:59:52 +0100 Subject: [PATCH 3/3] configure.ac: remove --enable-aiglx option In-Reply-To: References: <20160929174119.14505-1-emil.l.velikov@gmail.com> <20160929174119.14505-3-emil.l.velikov@gmail.com> <2e40463a-98fd-3bd9-6977-e065a7175a3a@dronecode.org.uk> <947dabc9-a478-fe76-ec42-9af14cba5e39@dronecode.org.uk> Message-ID: On 09/10/2016 15:42, Emil Velikov wrote: > On Friday, 7 October 2016, Jon Turney wrote: >> >> That's not quite enough, as building glxdri2.c also requires dri2proto >> headers. >> >> At the moment, configure.ac only requires dri2proto when --enable-dri2 >> turns on. >> >> So either that needs to be made unconditional, or building glxdri2.c made >> conditional on DRI2 (untested patch attached) >> >> You're correct. Wrapping it in DRI2 conditional is a good idea. > > Note creating an empty (no sources or static libs) library is likely to > cause problems. Just use the form prior to my patch ? Yes, that seems possible. Updated patch attached. -------------- next part -------------- From 42f74bb44190be06b9630dfcaae48b27533a28cd Mon Sep 17 00:00:00 2001 From: Jon Turney Date: Thu, 6 Oct 2016 22:13:07 +0100 Subject: [PATCH xserver] glx/dri2: Don't build DRI loader if DRI2 isn't enabled This partially reverts 501d8e2b. --- glx/Makefile.am | 11 ++++++++--- hw/xfree86/dixmods/Makefile.am | 2 ++ 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/glx/Makefile.am b/glx/Makefile.am index fc0b76a..60bd84c 100644 --- a/glx/Makefile.am +++ b/glx/Makefile.am @@ -1,4 +1,8 @@ -noinst_LTLIBRARIES = libglx.la libglxdri.la +if DRI2 +GLXDRI_LIBRARY = libglxdri.la +endif + +noinst_LTLIBRARIES = libglx.la $(GLXDRI_LIBRARY) AM_CFLAGS = \ @DIX_CFLAGS@ \ @@ -16,11 +20,10 @@ AM_CPPFLAGS = \ -I$(top_srcdir)/hw/xfree86/os-support/bus \ -I$(top_srcdir)/hw/xfree86/common \ -I$(top_srcdir)/hw/xfree86/dri \ + -I$(top_srcdir)/hw/xfree86/dri2 -I$(top_srcdir)/mi \ -I$(top_srcdir)/present -AM_CPPFLAGS += -I$(top_srcdir)/hw/xfree86/dri2 - indirect_sources = \ indirect_dispatch.c \ indirect_dispatch.h \ @@ -33,7 +36,9 @@ indirect_sources = \ indirect_table.c libglxdri_la_SOURCES = +if DRI2 libglxdri_la_SOURCES += glxdri2.c +endif libglxdri_la_LIBADD = $(DLOPEN_LIBS) diff --git a/hw/xfree86/dixmods/Makefile.am b/hw/xfree86/dixmods/Makefile.am index be43e8f..d534c78 100644 --- a/hw/xfree86/dixmods/Makefile.am +++ b/hw/xfree86/dixmods/Makefile.am @@ -29,10 +29,12 @@ libwfb_la_CFLAGS = $(AM_CFLAGS) -DFB_ACCESS_WRAPPER libglx_la_LDFLAGS = -module -avoid-version $(LD_NO_UNDEFINED_FLAG) libglx_la_LIBADD = $(top_builddir)/glx/libglx.la $(GLX_SYS_LIBS) +if DRI2 libglx_la_LIBADD += $(top_builddir)/glx/libglxdri.la if NO_UNDEFINED libglx_la_LIBADD += $(LIBDRM_LIBS) $(PIXMAN_LIBS) endif +endif libglx_la_SOURCES = glxmodule.c libshadow_la_LDFLAGS = -module -avoid-version $(LD_NO_UNDEFINED_FLAG) -- 2.8.3 From jeremyhu at apple.com Mon Oct 10 16:27:14 2016 From: jeremyhu at apple.com (Jeremy Huddleston Sequoia) Date: Mon, 10 Oct 2016 09:27:14 -0700 Subject: [PATCH 2/3] randr: Initialize RandR even if there are currently no screens attached In-Reply-To: References: <20161009195104.47686-1-jeremyhu@apple.com> <20161009195104.47686-2-jeremyhu@apple.com> Message-ID: <865314E7-5857-4B31-A606-48A81F99DC24@apple.com> > On Oct 10, 2016, at 03:33, Emil Velikov wrote: > > Hi Jeremy, > > On 9 October 2016 at 20:51, Jeremy Huddleston Sequoia > wrote: >> Failure to do so causes an overvlow in RRClientCallback(). >> > s/overvlow/overflow/ Doh, corrected the typo, thanks. > Perhaps a slightly silly question: > How can one end up in the callback if we haven't executed > AddCallback(&ClientStateCallback, fooCallback... ? Not silly at all, and actually quite pointed. The same basic question applies to this and the third patch in the series. From a correctness standpoint, it makes sense that GLX and RandR should initialize even when the first display hasn't yet been configured. They should handle attachment of the first display in much the same way they'd handle attaching the second or third display. Looking at the actual change, I agree with you that one should not expect the change to have any impact on the reported problem because the removed early-exit was before AddCallback() in both cases. I developed these changes against the commit that introduced the regression (30ac7567980a1eb79d084a63e0e74e1d9a3af673), so I just took a look at the tree back at that time to see if maybe something else had changed between then and current master to explain this. Nothing obvious stands out, which begs the question of why this had any impact whatsoever on this issue. I'm curious and will trace through it more when I get some cycles to figure out what's actually going on there. In the mean time, this is still valid for correctness reasons, so I'd like to get some feedback on it from that angle while I try to figure out what was really going on in those reported overflows. Thanks, Jeremy -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4465 bytes Desc: not available URL: From ajax at nwnk.net Mon Oct 10 17:16:55 2016 From: ajax at nwnk.net (Adam Jackson) Date: Mon, 10 Oct 2016 13:16:55 -0400 Subject: [PATCH 3/3] glx: Initialize glx even if there are currently no screens attached In-Reply-To: <20161009195104.47686-3-jeremyhu@apple.com> References: <20161009195104.47686-1-jeremyhu@apple.com> <20161009195104.47686-3-jeremyhu@apple.com> Message-ID: <1476119815.11675.5.camel@nwnk.net> On Sun, 2016-10-09 at 12:51 -0700, Jeremy Huddleston Sequoia wrote: > Failure to do so causes an overvlow in glxClientCallback This patch makes no sense at all. glxClientCallback is only added to the call chain _after_ we check for a GL-capable visual. If that check is preventing GLX from initializing, then it also prevents glxClientCallback being called. More to the point, the check is still correct, Mesa still needs a TC/DC visual to work. I suppose non-Mesa systems might not have that property, but a) OSX doesn't support pseudocolor GL rendering I am like 99% sure and b) that just means the check belongs in screen init instead of being deleted entirely. What are you trying to do here? - ajax From jeremyhu at apple.com Mon Oct 10 23:30:28 2016 From: jeremyhu at apple.com (Jeremy Huddleston Sequoia) Date: Mon, 10 Oct 2016 16:30:28 -0700 Subject: [PATCH 3/3] glx: Initialize glx even if there are currently no screens attached In-Reply-To: <1476119815.11675.5.camel@nwnk.net> References: <20161009195104.47686-1-jeremyhu@apple.com> <20161009195104.47686-3-jeremyhu@apple.com> <1476119815.11675.5.camel@nwnk.net> Message-ID: <322ECAAA-5972-423B-8AD6-6441BC2903BF@apple.com> > On Oct 10, 2016, at 10:16, Adam Jackson wrote: > > On Sun, 2016-10-09 at 12:51 -0700, Jeremy Huddleston Sequoia wrote: >> Failure to do so causes an overvlow in glxClientCallback > > This patch makes no sense at all. glxClientCallback is only added to > the call chain _after_ we check for a GL-capable visual. If that check > is preventing GLX from initializing, then it also prevents > glxClientCallback being called. > > More to the point, the check is still correct, Mesa still needs a TC/DC > visual to work. I suppose non-Mesa systems might not have that > property, but a) OSX doesn't support pseudocolor GL rendering I am like > 99% sure and b) that just means the check belongs in screen init > instead of being deleted entirely. > > What are you trying to do here? As I mentioned in the other thread, I agree that this shouldn't do anything wrt to ASan report, so I'm a bit confused by that and will dig into it. However, from a correctness standpoint, I think this is still the right approach. Yes, GLX requires a GL-capable visual in order to work, but that doesn't mean that it needs to be present at the time that the extension is initialized. We be able to start with 0 screens attached and then treat adding #1 the same as we would adding #2. I agree with you that these should probably be moved into RRScreenInit / __glXScreenInit and will make such a change in the next round. I want to spend some more time trying to figure out what was going on with the ASan report because indeed it doesn't make sense that this should cause it to go away. --Jeremy From k.mvc at ya.ru Mon Oct 10 17:45:20 2016 From: k.mvc at ya.ru (Mihail Konev) Date: Mon, 10 Oct 2016 17:45:20 +0000 Subject: [PATCH] Add git format.subjectPrefix to modules Message-ID: <20161010174519.GE4675@localhost> Hello. Xserver's autogen.sh checks for format.subjectPrefix git preference to be defined, and sets a default in case there is none. Other modules are missing this feature. To generate the patches, In xorg/util/modular directory, cloned all the modules (thanks to build.sh -L). Ran the attached subject_all.sh script. Changed to patches dir ./subjectPrefix_patches/ it created. Verified the patches with "grep changed * | grep -v ' 3 insert'". Ran the attached all.sh script. Attached is the all.tar.xz result. Below is a sample for xcb-proto. > From 13713caf3194581501fa891e2da1c1c33cd47693 Mon Sep 17 00:00:00 2001 > From: Mihail Konev > Date: Mon, 10 Oct 2016 15:01:11 +0000 > Subject: [PATCH xcb/proto] add git format.subjectPrefix to autogen.sh > > Signed-off-by: Mihail Konev > --- > autogen.sh | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/autogen.sh b/autogen.sh > index fc34bd55c443..78d554b5cdc0 100755 > --- a/autogen.sh > +++ b/autogen.sh > @@ -9,6 +9,9 @@ cd $srcdir > autoreconf -v --install || exit 1 > cd $ORIGDIR || exit $? > > +git config --local --get format.subjectPrefix >/dev/null 2>&1 || > + git config --local format.subjectPrefix "PATCH xcb/proto" > + > if test -z "$NOCONFIGURE"; then > $srcdir/configure "$@" > fi > -- > 2.9.2 > - Mihail -------------- next part -------------- A non-text attachment was scrubbed... Name: subject_all.sh Type: application/x-sh Size: 1461 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: all.sh Type: application/x-sh Size: 232 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: all.tar.xz Type: application/x-xz Size: 14020 bytes Desc: not available URL: From k.mvc at ya.ru Mon Oct 10 18:20:23 2016 From: k.mvc at ya.ru (Mihail Konev) Date: Mon, 10 Oct 2016 18:20:23 +0000 Subject: Request changes in Compose.pre In-Reply-To: <20161005124028.46d11a52@bkstv.bks-tv.ru> Message-ID: <20161010182022.GG4675@localhost> On Wed Oct 5 09:40:28 UTC 2016, Victor V. Kustov wrote: > Sorry for noise, but I'm discouraged by silence. Maybe I need send > patch by another address or maybe I doing wrong something... Please > give me a tips how I may do it correctly. There are the steps supposed to be performed. http://x.org -> DeveloperStart -> Building X Window System First, clone the root repo. $ cd ~ $ git clone git://anongit.freedesktop.org/git/xorg/util/modular xorg $ cd xorg $ mkdir b List the subprojects. $ sh build.sh -L Ask it to clone (and build) the lib/libX11 (as the Compose.pre belongs to it). No problem if build fails. $ sh build.sh --clone -o lib/libX11 $(pwd)/b Or clone manually: $ mkdir lib $ git clone git://anongit.freedesktop.org/git/xorg/lib/libX11 lib/libX11 Now let's patch it. $ cd ~/xorg/lib/libX11 Prepare the repository. $ git checkout -b ruble_sign Locate the file of interest. $ find -iname "*compose*" Apply the changes. $ vim nls/en_US.UTF-8/Compose.pre Save them into repository. $ git status $ git add nls $ git diff --staged $ export EDITOR=vim $ git commit -e Follow the Xorg guidelines. $ git commit --amend --signoff $ git config --local format.subjectPrefix "PATCH libX11" Prepare the email. $ git format-patch HEAD^ Example result below. --- nls/en_US.UTF-8/Compose.pre | 1 + 1 file changed, 1 insertion(+) diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre index adc24fb5b5c2..9ea2235b4079 100644 --- a/nls/en_US.UTF-8/Compose.pre +++ b/nls/en_US.UTF-8/Compose.pre @@ -190,6 +190,7 @@ XCOMM "₪" U20aa NEW SHEQEL SIGN : "€" EuroSign # EURO SIGN : "€" EuroSign # EURO SIGN : "€" EuroSign # EURO SIGN +XCOMM

: "₽" U20bd # RUBLE-CURRENCY SIGN XCOMM "₭" U20ad KIP SIGN XCOMM "₮" U20ae TUGRIK SIGN XCOMM "₯" U20af DRACHMA SIGN -- 2.9.2 From natano at natano.net Sat Oct 8 21:22:45 2016 From: natano at natano.net (Martin Natano) Date: Sat, 8 Oct 2016 23:22:45 +0200 Subject: [PATCH libX11] Don't rebuild ks_tables.h if nothing changed. In-Reply-To: <20161008194509.GC33240@nebraska.herrb.net> References: <20161008180858.GA39383@watschnbaum.natano.net> <20161008194509.GC33240@nebraska.herrb.net> Message-ID: <20161008212245.GA22754@watschnbaum.natano.net> On Sat, Oct 08, 2016 at 09:45:09PM +0200, Matthieu Herrb wrote: > > It looks good to me. 2 little things though: > > - you should use 'git commit -s' to generate a Signed-off-by: field in > the commit message See the updated diff below. > > - the reason why this patch is needed is a limitation of BSD make > GNU make doesn't trigger the extra rebuild during make install. > > PS: I tend to consider the BSD make behaviour as a bug, but no one ever > cared to fix it :( Curious, What's the bug? The force target is not marked phony, so it's always out-of-date due to the eponymous file not existing. Then force out-of-date -> rebuild makekeys, makekeys newer than ks_tables.h -> rebuild ks_tables.h. What should the behaviour be instead? natano >From 75d5e9b763069310cb2b0d0bac2a49175029449a Mon Sep 17 00:00:00 2001 From: Martin Natano Date: Sat, 8 Oct 2016 19:57:50 +0200 Subject: [PATCH] Don't rebuild ks_tables.h if nothing changed. ks_tables.h is always considered out of date due to the forced rebuild of the makekeys util. This means the file is also rebuilt during 'make install', which is usually performed as root, which can to lead permission problems later on. Signed-off-by: Martin Natano --- src/Makefile.am | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 15de59b..f8c476d 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -415,7 +415,5 @@ ks_tables.h: $(KEYSYMDEFS) $(top_builddir)/src/util/makekeys$(EXEEXT) $(top_builddir)/src/util/makekeys $(KEYSYMDEFS) > ks_tables_h mv ks_tables_h $@ -$(top_builddir)/src/util/makekeys$(EXEEXT): force +$(top_builddir)/src/util/makekeys$(EXEEXT): $(top_builddir)/src/util/makekeys.c cd util && $(MAKE) - -force: -- 2.9.3 From k.mvc at ya.ru Sun Oct 9 23:20:00 2016 From: k.mvc at ya.ru (Mihail Konev) Date: Sun, 9 Oct 2016 23:20:00 +0000 Subject: [PATCH xserver] modesetting: add missing ifdef GLAMOR Message-ID: <20161009231959.GA17082@localhost> This fixes --disable-glamor failing to build. Regressed-in: e8695100b17b758359fc4897dbe995231ed224fc Signed-off-by: Mihail Konev --- hw/xfree86/drivers/modesetting/driver.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/xfree86/drivers/modesetting/driver.c b/hw/xfree86/drivers/modesetting/driver.c index 216388f0a36c..3da69a3962a0 100644 --- a/hw/xfree86/drivers/modesetting/driver.c +++ b/hw/xfree86/drivers/modesetting/driver.c @@ -594,6 +594,7 @@ redisplay_dirty(ScreenPtr screen, PixmapDirtyUpdatePtr dirty, int *timeout) PixmapSyncDirtyHelper(dirty); if (!screen->isGPU) { +#ifdef GLAMOR /* * When copying from the master framebuffer to the shared pixmap, * we must ensure the copy is complete before the slave starts a @@ -602,6 +603,7 @@ redisplay_dirty(ScreenPtr screen, PixmapDirtyUpdatePtr dirty, int *timeout) */ if (ms->drmmode.glamor) glamor_finish(screen); +#endif /* Ensure the slave processes the damage immediately */ if (timeout) *timeout = 0; -- 2.9.2 From k.mvc at ya.ru Sun Oct 9 21:52:10 2016 From: k.mvc at ya.ru (Mihail Konev) Date: Sun, 9 Oct 2016 21:52:10 +0000 Subject: [PATCH] inputthread: Fix inputthread not listening if a fd gets re-added immediately after removal In-Reply-To: <20161005124520.30712-1-hdegoede@redhat.com> Message-ID: <20161009215210.GA5218@localhost> Hello. On Wed, 5 Oct 2016 14:45:20 +0200, Hans de Goede wrote: > When a fd is removed dev->state gets set to device_state_removed, > if the fd then gets re-added before InputThreadDoWork() deals with > the removal, the InputThreadDevice struct gets reused, but its > state would stay device_state_removed, so it would still get removed > on the first InputThreadDoWork() run, resulting in a non functioning > input device. > > This commit fixes this by (re-)setting dev->state to device_state_running > when a InputThreadDevice struct gets reused. > > This fixes input devices sometimes no longer working after a vt-switch. > > Signed-off-by: Hans de Goede > --- > os/inputthread.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/os/inputthread.c b/os/inputthread.c > index 6aa0a9c..ab1559f 100644 > --- a/os/inputthread.c > +++ b/os/inputthread.c > @@ -206,6 +206,8 @@ InputThreadRegisterDev(int fd, > if (dev) { > dev->readInputProc = readInputProc; > dev->readInputArgs = readInputArgs; > + /* Override possible unhandled state == device_state_removed */ > + dev->state = device_state_running; > } else { > dev = calloc(1, sizeof(InputThreadDevice)); > if (dev == NULL) { > -- > 2.9.3 > On 6 Oct 2016, Hans de Goede wrote: > On 24-09-16 19:55, Mihail Konev wrote: > > <..> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97880 > > Thank you for the patch and you're right that there is an issue here. > > I've posted a much simpler fix yesterday, and that has been > favorably reviewed, so I think we're going to go with that fix > instead, <..> > Applied on top of 9e00cf0f75f286ec0e8137d91ba80ef7ba72ab2a , the patch does not solve the bug #97880 for me. Note: ./configure --disable-glamor is broken somewhere after the ade315386 (Require xproto 7.0.31), so be sure to --enable-glamor. On 9 Oct 2016, Hans de Goede wrote: > So you've tried my patch, with your patch reverted and it > does not work for you? Strange as I was hitting the exact > same problem and it did work for me. > The difference in problem is, however, that in my case result is consistent - keyboard either works or not all the time, not "sometimes". Mouse is moving alright. First, patch was applied on top of fc1c358b9 (1.19 RC1). It did not work, so log1.diff was made, applied, and log1 produced (both attached). Note: log1 is (fully) commented inline. Rebasing on top of 97a8353ec (Fix id in error) did not help. At this point (log1), nol_e.diff gives: - nol_e.log1 - bug being present Applying nol_d.diff to log1 gives: - nol_d.log1 - bug being gone Manually applied log1.diff to master 97a8353ec (gave log1m.diff). At this point (log1m) nol_e.diff gives: - nol_e.log1m - bug being present Mistake in bugzilla bug description: this shows that not locking EnableDevice is not a sufficient workaround. Applying nol_d.diff to log1m gives: - nol_d.log1m - bug being gone This is what is right in bugzilla description: not locking DisableDevice is a sufficient workaround. As I see it, The patch assumes no device state to be maintained except in the input thread dev list. The dev->state is just a flag to signal the input thread to process input state change. When it is device_state_running, input thread would not do any processing upon the dev list element (which through the dev->fd corresponds to /dev/input/eventN). Before commit 52d6a1e832a5e62289dd4f32824ae16a78dfd7e8, input thread would process events before the input_lock is called in the xf86VTLeave, (that is, as-soon-as xf86DisableDeviceForVTSwitch sets the `dev->state = device_state_removed`). Starting with the commit 52d6a1e832a5e62289dd4f32824ae16a78dfd7e8, input_lock is called in the xf86{Enable,Disable}InputDeviceForVTSwitch (actually in the dix {Enable,Disable}Device, but xf86* just wrap them). As the first thing the main thread does after calling all xf86Disable.. is to call input_lock (without an input_unlock until VT is switched back), input thread has almost no chance to process `dev->state == device_state_removed` for the last device. Note: The chance could be given by inserting something relatively long-running, like LogMessageVerb(X_INFO, 0, "[xf86VTLeave] doing input_lock...\n"). Such a line is commented out in log1.patch; before commenting, the bug was not seen. Note: Input thread would not process releases after VT switch in any case, as input_lock is released by main thread only at the very end of xf86VTEnter. (This is why not locking the EnableDevice does not help - lock is already held). So when the main thread does input_unlock at the end of xf86VTEnter, the input thread would see: - N-1 elements `dev->state == device_state_added` - One last element `dev-state == device_state_removed` (or `device_state_running` with the above patch applied) For N-1 elements the input thread would call the proper attach procedures (that is, call into xf86-input-evdev, which possibly calls into OS). For the last element, it would: - without the patch: * call into xf86-input-evdev to do proper detach procedures * remove the element from the list - with the patch: * do nothing Without the patch, X removes a device from dev list without a reason. (When it actually is supposed to add one). With the patch, X "hopes" to receive the events even through the OS could, without the xf86-input-evdev asking it for, disable the device due to VT switch (X may be involved too). It looks this way as there were no from-another-VT input events after returning from VT, regardless of input_lock/barrier modifications. Looks like the patch above would only work for some hardware configurations, but not all. As for simplicity, bugzilla patch is already lighter than it could be, as it utilises a barrier in place of condition variable under a mutex, thus assuming that no threads except main and input would want to wait for device releases to be processed (or to check whether they are). To outline: - before regression, 6 devices were fully released, then fully attached. - with regression and bugzilla patch, only 5 are released fully, but the main thread stops to wait for input thread to process the last one. - with regression and this patch, only 5 are released fully, 1 is not released neither attached, yet X input thread thinks it should be getting events from it. For me this does not work. Given the above, changing `device_state_running -> device_state_added` in the patch is not a solution either, as it would not cause a release of the device before VT switch (but only an attach upon returning to VT). - Mihail -------------- next part -------------- There Xserver starts. <..> [ 3287.050] (II) config/udev: ignoring device /dev/tty7 without property ID_INPUT set [ 3287.050] (II) config/udev: ignoring device /dev/tty8 without property ID_INPUT set [ 3287.050] (II) config/udev: ignoring device /dev/tty9 without property ID_INPUT set Now it finished detecting devices. Input thread tries to acquire the lock. [ 3287.054] (II) inputh lock ... [ 3287.054] (II) inputh locked Input thread sees the attachments. [ 3287.054] (II) dev fd=19 state=0 [ 3287.054] (II) dev fd=20 state=0 [ 3287.054] (II) dev fd=21 state=0 [ 3287.054] (II) dev fd=22 state=0 [ 3287.054] (II) dev fd=23 state=0 [ 3287.054] (II) dev fd=24 state=0 There are 6 devices total. User does Ctrl-Alt-F1 Xserver (main thread in hw/xfree86/common/xf86Events.c, in xf86DisableDevicesForVTSwitch) for each device calls InputThreadUnregisterDev, which really just sets dev->state (under an input_lock), so that input thread sees that and does the proper detach. [ 3291.194] (II) InputThreadUnregisterDev(fd=19) ... [ 3291.194] (II) InputThreadUnregisterDev: found a device: fd=19 state=1 For first device, input thread sees the dev->state change. It tries to acquire the lock. [ 3291.194] (II) inputh lock ... [ 3291.208] (II) inputh locked With lock held, input thread detaches the device. [ 3291.208] (II) dev fd=19 state=2 The same goes for device 2. [ 3291.208] (II) InputThreadUnregisterDev(fd=20) ... [ 3291.208] (II) InputThreadUnregisterDev: found a device: fd=20 state=1 [ 3291.208] (II) inputh lock ... [ 3291.220] (II) inputh locked [ 3291.220] (II) dev fd=20 state=2 The same goes for device 3. [ 3291.220] (II) InputThreadUnregisterDev(fd=21) ... [ 3291.220] (II) InputThreadUnregisterDev: found a device: fd=21 state=1 [ 3291.220] (II) inputh lock ... [ 3291.232] (II) inputh locked [ 3291.232] (II) dev fd=21 state=2 The same goes for device 4. [ 3291.232] (II) InputThreadUnregisterDev(fd=22) ... [ 3291.232] (II) InputThreadUnregisterDev: found a device: fd=22 state=1 [ 3291.232] (II) inputh lock ... [ 3291.247] (II) inputh locked [ 3291.247] (II) dev fd=22 state=2 The same goes for device 5. [ 3291.247] (II) InputThreadUnregisterDev(fd=23) ... [ 3291.247] (II) InputThreadUnregisterDev: found a device: fd=23 state=1 [ 3291.247] (II) inputh lock ... [ 3291.259] (II) inputh locked [ 3291.259] (II) dev fd=23 state=2 The same goes for device 6 in the main thread. [ 3291.259] (II) InputThreadUnregisterDev(fd=24) ... [ 3291.259] (II) InputThreadUnregisterDev: found a device: fd=24 state=1 Now the last dev->state is set. Time for input thread to acquire the lock and detach the device. [ 3291.259] (II) inputh lock ... Input thread now waits on the lock. The lock, however, is held by the main thread. Where? In the xf86VTLeave What for? So that input thread waits for lock for while on another VT. (So that there is no input processing). So input thread would not be able to process the events until VT is switched back. User does Ctrl-Alt-F7 Xserver re-initializes the monitor. [ 3292.388] (II) modeset(0): <..> <..> [ 3292.388] (II) modeset(0): <..> Xserver's main thread now attaches input devices. (By just setting the dev->state). [ 3292.501] (II) InputThreadRegisterDev(fd=19) ... [ 3292.501] (II) InputThreadRegisterDev(fd=20) ... [ 3292.501] (II) InputThreadRegisterDev(fd=21) ... [ 3292.501] (II) InputThreadRegisterDev(fd=22) ... [ 3292.501] (II) InputThreadRegisterDev(fd=23) ... It does this for first five devices. For sixth, it sees a matching dev (the unprocessed one, with dev->state == device_state_removed). And does not signal (by means of dev->state) the input thread to attach the device. [ 3292.501] (II) InputThreadRegisterDev(fd=24) ... [ 3292.501] (II) InputThreadRegisterDev: found a device: fd=24 state=2 The main thread is now done with all the six devices OS has. It releases input lock that was being held all the VT switch. Input thread acquires the long-awaited lock. [ 3292.502] (II) inputh locked Now input thread would process six dev->state-s. [ 3292.502] (II) dev fd=19 state=0 [ 3292.502] (II) dev fd=20 state=0 [ 3292.502] (II) dev fd=21 state=0 [ 3292.502] (II) dev fd=22 state=0 [ 3292.502] (II) dev fd=23 state=0 It sees five devices attached and one running. The sixth device does not get attached (by the input thread), hence the bug. Now timeout for Xserver expires, and it is sent a SIGTERM. (startx was ran as `timeout 20 startx`). [ 3306.673] (II) InputThreadUnregisterDev(fd=19) ... [ 3306.673] (II) InputThreadUnregisterDev: found a device: fd=19 state=1 [ 3306.674] (II) inputh lock ... [ 3306.684] (II) inputh locked [ 3306.684] (II) dev fd=19 state=2 [ 3306.684] (II) InputThreadUnregisterDev(fd=20) ... [ 3306.684] (II) InputThreadUnregisterDev: found a device: fd=20 state=1 [ 3306.684] (II) inputh lock ... [ 3306.696] (II) inputh locked [ 3306.696] (II) dev fd=20 state=2 [ 3306.696] (II) InputThreadUnregisterDev(fd=21) ... [ 3306.696] (II) InputThreadUnregisterDev: found a device: fd=21 state=1 [ 3306.696] (II) inputh lock ... [ 3306.708] (II) inputh locked [ 3306.708] (II) dev fd=21 state=2 [ 3306.708] (II) InputThreadUnregisterDev(fd=22) ... [ 3306.708] (II) InputThreadUnregisterDev: found a device: fd=22 state=1 [ 3306.708] (II) inputh lock ... [ 3306.720] (II) inputh locked [ 3306.720] (II) dev fd=22 state=2 [ 3306.720] (II) InputThreadUnregisterDev(fd=23) ... [ 3306.720] (II) InputThreadUnregisterDev: found a device: fd=23 state=1 [ 3306.720] (II) inputh lock ... [ 3306.732] (II) inputh locked [ 3306.732] (II) dev fd=23 state=2 [ 3306.732] (II) InputThreadUnregisterDev(fd=24) ... [ 3306.732] (II) InputThreadUnregisterDev: found a device: fd=24 state=1 [ 3306.732] (II) inputh lock ... [ 3306.744] (II) inputh locked [ 3306.744] (II) dev fd=24 state=2 [ 3306.744] (II) evdev: <..>: Close [ 3306.744] (II) UnloadModule: "evdev" [ 3306.744] (II) evdev: <..>: Close [ 3306.744] (II) UnloadModule: "evdev" [ 3306.744] (II) evdev: <..>: Close [ 3306.744] (II) UnloadModule: "evdev" [ 3306.744] (II) evdev: Power Button: Close [ 3306.744] (II) UnloadModule: "evdev" [ 3306.745] (II) evdev: Video Bus: Close [ 3306.745] (II) UnloadModule: "evdev" [ 3306.745] (II) evdev: Power Button: Close [ 3306.745] (II) UnloadModule: "evdev" [ 3306.767] (II) Server terminated successfully (0). Closing log file. -------------- next part -------------- diff --git a/hw/xfree86/common/xf86Events.c b/hw/xfree86/common/xf86Events.c index 9a8f432a0556..9c1da344c4a3 100644 --- a/hw/xfree86/common/xf86Events.c +++ b/hw/xfree86/common/xf86Events.c @@ -436,8 +436,11 @@ xf86VTLeave(void) else xf86DisableGeneralHandler(ih); } + + //LogMessageVerb(X_INFO, 0, "xf86DisableInputDevs ...\n"); for (pInfo = xf86InputDevs; pInfo; pInfo = pInfo->next) xf86DisableInputDeviceForVTSwitch(pInfo); + //LogMessageVerb(X_INFO, 0, "xf86DisableInputDevs done, doing input_lock ...\n"); input_lock(); for (i = 0; i < xf86NumScreens; i++) diff --git a/os/inputthread.c b/os/inputthread.c index ab1559fb6b95..abbf1825589b 100644 --- a/os/inputthread.c +++ b/os/inputthread.c @@ -190,8 +190,12 @@ InputThreadRegisterDev(int fd, { InputThreadDevice *dev, *old; - if (!inputThreadInfo) + LogMessageVerb(X_INFO, 0, "%s(fd=%d) ... \n", + __func__, fd); + + if (!inputThreadInfo) { return SetNotifyFd(fd, readInputProc, X_NOTIFY_READ, readInputArgs); + } input_lock(); @@ -204,6 +208,8 @@ InputThreadRegisterDev(int fd, } if (dev) { + LogMessageVerb(X_INFO, 0, "%s: found a device: fd=%d state=%d \n", + __func__, fd, (int)(dev->state - device_state_added)); dev->readInputProc = readInputProc; dev->readInputArgs = readInputArgs; /* Override possible unhandled state == device_state_removed */ @@ -246,6 +252,9 @@ InputThreadUnregisterDev(int fd) InputThreadDevice *dev; Bool found_device = FALSE; + LogMessageVerb(X_INFO, 0, "%s(fd=%d) ... \n", + __func__, fd); + /* return silently if input thread is already finished (e.g., at * DisableDevice time, evdev tries to call this function again through * xf86RemoveEnabledDevice) */ @@ -267,6 +276,8 @@ InputThreadUnregisterDev(int fd) return 0; } + LogMessageVerb(X_INFO, 0, "%s: found a device: fd=%d state=%d \n", + __func__, fd, (int)(dev->state - device_state_added)); dev->state = device_state_removed; inputThreadInfo->changed = TRUE; @@ -332,11 +343,16 @@ InputThreadDoWork(void *arg) if (inputThreadInfo->changed) { InputThreadDevice *dev, *tmp; + LogMessageVerb(X_INFO, 0, "inputh lock ...\n"); input_lock(); + LogMessageVerb(X_INFO, 0, "inputh locked\n"); + inputThreadInfo->changed = FALSE; xorg_list_for_each_entry_safe(dev, tmp, &inputThreadInfo->devs, node) { switch (dev->state) { case device_state_added: + LogMessageVerb(X_INFO, 0, "dev fd=%d state=%d \n", + (int)dev->fd, (int)(dev->state - device_state_added)); ospoll_add(inputThreadInfo->fds, dev->fd, ospoll_trigger_level, InputReady, @@ -347,6 +363,8 @@ InputThreadDoWork(void *arg) case device_state_running: break; case device_state_removed: + LogMessageVerb(X_INFO, 0, "dev fd=%d state=%d \n", + (int)dev->fd, (int)(dev->state - device_state_added)); ospoll_remove(inputThreadInfo->fds, dev->fd); xorg_list_del(&dev->node); free(dev); -------------- next part -------------- diff --git a/hw/xfree86/common/xf86Events.c b/hw/xfree86/common/xf86Events.c index 9a8f432a0556..11d49be4622f 100644 --- a/hw/xfree86/common/xf86Events.c +++ b/hw/xfree86/common/xf86Events.c @@ -436,8 +436,10 @@ xf86VTLeave(void) else xf86DisableGeneralHandler(ih); } + //LogMessageVerb(X_INFO, 0, "xf86DisableInputDevs ...\n"); for (pInfo = xf86InputDevs; pInfo; pInfo = pInfo->next) xf86DisableInputDeviceForVTSwitch(pInfo); + //LogMessageVerb(X_INFO, 0, "xf86DisableInputDevs done, doing input_lock ...\n"); input_lock(); for (i = 0; i < xf86NumScreens; i++) diff --git a/os/inputthread.c b/os/inputthread.c index 6aa0a9ce6fb5..699b2a0d283a 100644 --- a/os/inputthread.c +++ b/os/inputthread.c @@ -190,8 +190,12 @@ InputThreadRegisterDev(int fd, { InputThreadDevice *dev, *old; - if (!inputThreadInfo) + LogMessageVerb(X_INFO, 0, "%s(fd=%d) ... \n", + __func__, fd); + + if (!inputThreadInfo) { return SetNotifyFd(fd, readInputProc, X_NOTIFY_READ, readInputArgs); + } input_lock(); @@ -204,6 +208,8 @@ InputThreadRegisterDev(int fd, } if (dev) { + LogMessageVerb(X_INFO, 0, "%s: found a device: fd=%d state=%d \n", + __func__, fd, (int)(dev->state - device_state_added)); dev->readInputProc = readInputProc; dev->readInputArgs = readInputArgs; } else { @@ -244,6 +250,8 @@ InputThreadUnregisterDev(int fd) InputThreadDevice *dev; Bool found_device = FALSE; + LogMessageVerb(X_INFO, 0, "%s(fd=%d) ... \n", + __func__, fd); /* return silently if input thread is already finished (e.g., at * DisableDevice time, evdev tries to call this function again through * xf86RemoveEnabledDevice) */ @@ -265,6 +273,8 @@ InputThreadUnregisterDev(int fd) return 0; } + LogMessageVerb(X_INFO, 0, "%s: found a device: fd=%d state=%d \n", + __func__, fd, (int)(dev->state - device_state_added)); dev->state = device_state_removed; inputThreadInfo->changed = TRUE; @@ -330,11 +340,16 @@ InputThreadDoWork(void *arg) if (inputThreadInfo->changed) { InputThreadDevice *dev, *tmp; + LogMessageVerb(X_INFO, 0, "inputh lock ...\n"); input_lock(); + LogMessageVerb(X_INFO, 0, "inputh locked\n"); + inputThreadInfo->changed = FALSE; xorg_list_for_each_entry_safe(dev, tmp, &inputThreadInfo->devs, node) { switch (dev->state) { case device_state_added: + LogMessageVerb(X_INFO, 0, "dev fd=%d state=%d \n", + (int)dev->fd, (int)(dev->state - device_state_added)); ospoll_add(inputThreadInfo->fds, dev->fd, ospoll_trigger_level, InputReady, @@ -345,6 +360,8 @@ InputThreadDoWork(void *arg) case device_state_running: break; case device_state_removed: + LogMessageVerb(X_INFO, 0, "dev fd=%d state=%d \n", + (int)dev->fd, (int)(dev->state - device_state_added)); ospoll_remove(inputThreadInfo->fds, dev->fd); xorg_list_del(&dev->node); free(dev); -------------- next part -------------- diff --git a/dix/devices.c b/dix/devices.c index ea3c6c8a9a0f..c448713e3bab 100644 --- a/dix/devices.c +++ b/dix/devices.c @@ -491,7 +491,6 @@ DisableDevice(DeviceIntPtr dev, BOOL sendevent) if (dev->spriteInfo->paired) dev->spriteInfo->paired = NULL; - input_lock(); (void) (*dev->deviceProc) (dev, DEVICE_OFF); dev->enabled = FALSE; @@ -501,7 +500,6 @@ DisableDevice(DeviceIntPtr dev, BOOL sendevent) if (other->last.slave == dev) other->last.slave = NULL; } - input_unlock(); FreeSprite(dev); -------------- next part -------------- [ 13083.696] (II) config/udev: ignoring device /dev/tty7 without property ID_INPUT set [ 13083.696] (II) config/udev: ignoring device /dev/tty8 without property ID_INPUT set [ 13083.696] (II) config/udev: ignoring device /dev/tty9 without property ID_INPUT set [ 13083.696] (II) inputh lock ... [ 13083.696] (II) inputh locked [ 13083.696] (II) dev fd=20 state=0 [ 13083.696] (II) dev fd=21 state=0 [ 13083.696] (II) dev fd=22 state=0 [ 13083.697] (II) dev fd=23 state=0 [ 13083.697] (II) dev fd=24 state=0 [ 13083.697] (II) dev fd=25 state=0 [ 13088.025] (II) InputThreadUnregisterDev(fd=20) ... [ 13088.025] (II) InputThreadUnregisterDev: found a device: fd=20 state=1 [ 13088.025] (II) inputh lock ... [ 13088.025] (II) inputh locked [ 13088.025] (II) dev fd=20 state=2 [ 13088.036] (II) InputThreadUnregisterDev(fd=21) ... [ 13088.036] (II) InputThreadUnregisterDev: found a device: fd=21 state=1 [ 13088.036] (II) inputh lock ... [ 13088.036] (II) inputh locked [ 13088.036] (II) dev fd=21 state=2 [ 13088.048] (II) InputThreadUnregisterDev(fd=22) ... [ 13088.048] (II) InputThreadUnregisterDev: found a device: fd=22 state=1 [ 13088.048] (II) inputh lock ... [ 13088.048] (II) inputh locked [ 13088.048] (II) dev fd=22 state=2 [ 13088.060] (II) InputThreadUnregisterDev(fd=23) ... [ 13088.060] (II) InputThreadUnregisterDev: found a device: fd=23 state=1 [ 13088.060] (II) inputh lock ... [ 13088.060] (II) inputh locked [ 13088.060] (II) dev fd=23 state=2 [ 13088.072] (II) InputThreadUnregisterDev(fd=24) ... [ 13088.072] (II) InputThreadUnregisterDev: found a device: fd=24 state=1 [ 13088.072] (II) inputh lock ... [ 13088.072] (II) inputh locked [ 13088.072] (II) dev fd=24 state=2 [ 13088.084] (II) InputThreadUnregisterDev(fd=25) ... [ 13088.084] (II) InputThreadUnregisterDev: found a device: fd=25 state=1 [ 13088.084] (II) inputh lock ... [ 13088.084] (II) inputh locked [ 13088.084] (II) dev fd=25 state=2 [ 13088.096] (II) AIGLX: Suspending AIGLX clients for VT switch [ 13089.528] (II) AIGLX: Resuming AIGLX clients after VT switch [ 13089.546] (II) modeset(0): .. ... [ 13089.659] (II) InputThreadRegisterDev(fd=20) ... [ 13089.659] (II) InputThreadRegisterDev(fd=21) ... [ 13089.659] (II) inputh lock ... [ 13089.659] (II) InputThreadRegisterDev(fd=22) ... [ 13089.659] (II) InputThreadRegisterDev(fd=23) ... [ 13089.659] (II) InputThreadRegisterDev(fd=24) ... [ 13089.659] (II) InputThreadRegisterDev(fd=25) ... [ 13089.659] (II) inputh locked [ 13089.660] (II) dev fd=20 state=0 [ 13089.660] (II) dev fd=21 state=0 [ 13089.660] (II) dev fd=22 state=0 [ 13089.660] (II) dev fd=23 state=0 [ 13089.660] (II) dev fd=24 state=0 [ 13089.660] (II) dev fd=25 state=0 [ 13103.162] (II) InputThreadUnregisterDev(fd=20) ... [ 13103.162] (II) InputThreadUnregisterDev: found a device: fd=20 state=1 [ 13103.162] (II) inputh lock ... [ 13103.162] (II) inputh locked [ 13103.162] (II) dev fd=20 state=2 [ 13103.173] (II) InputThreadUnregisterDev(fd=21) ... [ 13103.173] (II) InputThreadUnregisterDev: found a device: fd=21 state=1 [ 13103.173] (II) inputh lock ... [ 13103.173] (II) inputh locked [ 13103.173] (II) dev fd=21 state=2 [ 13103.185] (II) InputThreadUnregisterDev(fd=22) ... [ 13103.185] (II) InputThreadUnregisterDev: found a device: fd=22 state=1 [ 13103.185] (II) inputh lock ... [ 13103.185] (II) inputh locked [ 13103.185] (II) dev fd=22 state=2 [ 13103.197] (II) InputThreadUnregisterDev(fd=23) ... [ 13103.197] (II) InputThreadUnregisterDev: found a device: fd=23 state=1 [ 13103.197] (II) inputh lock ... [ 13103.197] (II) inputh locked [ 13103.197] (II) dev fd=23 state=2 [ 13103.209] (II) InputThreadUnregisterDev(fd=24) ... [ 13103.209] (II) InputThreadUnregisterDev: found a device: fd=24 state=1 [ 13103.209] (II) inputh lock ... [ 13103.209] (II) inputh locked [ 13103.209] (II) dev fd=24 state=2 [ 13103.221] (II) InputThreadUnregisterDev(fd=25) ... [ 13103.221] (II) InputThreadUnregisterDev: found a device: fd=25 state=1 [ 13103.221] (II) inputh lock ... [ 13103.221] (II) inputh locked [ 13103.221] (II) dev fd=25 state=2 [ 13103.233] (II) evdev: .. [ 13103.233] (II) UnloadModule: "evdev" [ 13103.233] (II) evdev: .. [ 13103.233] (II) UnloadModule: "evdev" [ 13103.233] (II) evdev: .. [ 13103.233] (II) UnloadModule: "evdev" [ 13103.233] (II) evdev: Power Button: Close [ 13103.234] (II) UnloadModule: "evdev" [ 13103.234] (II) evdev: Video Bus: Close [ 13103.234] (II) UnloadModule: "evdev" [ 13103.234] (II) evdev: Power Button: Close [ 13103.234] (II) UnloadModule: "evdev" [ 13103.257] (II) Server terminated successfully (0). Closing log file. -------------- next part -------------- ... [ 14822.307] (II) config/udev: ignoring device /dev/tty7 without property ID_INPUT set [ 14822.307] (II) config/udev: ignoring device /dev/tty8 without property ID_INPUT set [ 14822.308] (II) config/udev: ignoring device /dev/tty9 without property ID_INPUT set [ 14822.308] (II) inputh lock ... [ 14822.308] (II) inputh locked [ 14822.308] (II) dev fd=20 state=0 [ 14822.308] (II) dev fd=21 state=0 [ 14822.308] (II) dev fd=22 state=0 [ 14822.308] (II) dev fd=23 state=0 [ 14822.308] (II) dev fd=24 state=0 [ 14822.308] (II) dev fd=25 state=0 [ 14828.032] (II) InputThreadUnregisterDev(fd=20) ... [ 14828.032] (II) InputThreadUnregisterDev: found a device: fd=20 state=1 [ 14828.032] (II) inputh lock ... [ 14828.032] (II) inputh locked [ 14828.032] (II) dev fd=20 state=2 [ 14828.043] (II) InputThreadUnregisterDev(fd=21) ... [ 14828.043] (II) InputThreadUnregisterDev: found a device: fd=21 state=1 [ 14828.043] (II) inputh lock ... [ 14828.043] (II) inputh locked [ 14828.043] (II) dev fd=21 state=2 [ 14828.055] (II) InputThreadUnregisterDev(fd=22) ... [ 14828.055] (II) InputThreadUnregisterDev: found a device: fd=22 state=1 [ 14828.055] (II) inputh lock ... [ 14828.055] (II) inputh locked [ 14828.055] (II) dev fd=22 state=2 [ 14828.067] (II) InputThreadUnregisterDev(fd=23) ... [ 14828.067] (II) InputThreadUnregisterDev: found a device: fd=23 state=1 [ 14828.067] (II) inputh lock ... [ 14828.067] (II) inputh locked [ 14828.067] (II) dev fd=23 state=2 [ 14828.079] (II) InputThreadUnregisterDev(fd=24) ... [ 14828.079] (II) InputThreadUnregisterDev: found a device: fd=24 state=1 [ 14828.079] (II) inputh lock ... [ 14828.079] (II) inputh locked [ 14828.079] (II) dev fd=24 state=2 [ 14828.091] (II) InputThreadUnregisterDev(fd=25) ... [ 14828.091] (II) InputThreadUnregisterDev: found a device: fd=25 state=1 [ 14828.091] (II) inputh lock ... [ 14828.091] (II) inputh locked [ 14828.091] (II) dev fd=25 state=2 [ 14828.103] (II) AIGLX: Suspending AIGLX clients for VT switch [ 14830.678] (II) AIGLX: Resuming AIGLX clients after VT switch [ 14830.692] (II) modeset(0): .. ... [ 14830.804] (II) InputThreadRegisterDev(fd=20) ... [ 14830.804] (II) InputThreadRegisterDev(fd=21) ... [ 14830.804] (II) inputh lock ... [ 14830.804] (II) InputThreadRegisterDev(fd=22) ... [ 14830.804] (II) InputThreadRegisterDev(fd=23) ... [ 14830.804] (II) InputThreadRegisterDev(fd=24) ... [ 14830.804] (II) InputThreadRegisterDev(fd=25) ... [ 14830.805] (II) inputh locked [ 14830.805] (II) dev fd=20 state=0 [ 14830.805] (II) dev fd=21 state=0 [ 14830.805] (II) dev fd=22 state=0 [ 14830.805] (II) dev fd=23 state=0 [ 14830.805] (II) dev fd=24 state=0 [ 14830.805] (II) dev fd=25 state=0 [ 14841.770] (II) InputThreadUnregisterDev(fd=20) ... [ 14841.770] (II) InputThreadUnregisterDev: found a device: fd=20 state=1 [ 14841.770] (II) inputh lock ... [ 14841.770] (II) inputh locked [ 14841.770] (II) dev fd=20 state=2 [ 14841.782] (II) InputThreadUnregisterDev(fd=21) ... [ 14841.782] (II) InputThreadUnregisterDev: found a device: fd=21 state=1 [ 14841.782] (II) inputh lock ... [ 14841.782] (II) inputh locked [ 14841.782] (II) dev fd=21 state=2 [ 14841.794] (II) InputThreadUnregisterDev(fd=22) ... [ 14841.794] (II) InputThreadUnregisterDev: found a device: fd=22 state=1 [ 14841.794] (II) inputh lock ... [ 14841.794] (II) inputh locked [ 14841.794] (II) dev fd=22 state=2 [ 14841.806] (II) InputThreadUnregisterDev(fd=23) ... [ 14841.806] (II) InputThreadUnregisterDev: found a device: fd=23 state=1 [ 14841.806] (II) inputh lock ... [ 14841.806] (II) inputh locked [ 14841.806] (II) dev fd=23 state=2 [ 14841.818] (II) InputThreadUnregisterDev(fd=24) ... [ 14841.818] (II) InputThreadUnregisterDev: found a device: fd=24 state=1 [ 14841.818] (II) inputh lock ... [ 14841.818] (II) inputh locked [ 14841.818] (II) dev fd=24 state=2 [ 14841.830] (II) InputThreadUnregisterDev(fd=25) ... [ 14841.830] (II) InputThreadUnregisterDev: found a device: fd=25 state=1 [ 14841.830] (II) inputh lock ... [ 14841.830] (II) inputh locked [ 14841.830] (II) dev fd=25 state=2 [ 14841.842] (II) evdev: .. [ 14841.842] (II) UnloadModule: "evdev" [ 14841.842] (II) evdev: .. [ 14841.842] (II) UnloadModule: "evdev" [ 14841.842] (II) evdev: .. [ 14841.842] (II) UnloadModule: "evdev" [ 14841.842] (II) evdev: Power Button: Close [ 14841.843] (II) UnloadModule: "evdev" [ 14841.843] (II) evdev: Video Bus: Close [ 14841.843] (II) UnloadModule: "evdev" [ 14841.843] (II) evdev: Power Button: Close [ 14841.843] (II) UnloadModule: "evdev" [ 14841.869] (II) Server terminated successfully (0). Closing log file. -------------- next part -------------- diff --git a/dix/devices.c b/dix/devices.c index ea3c6c8a9a0f..0b95bc494e79 100644 --- a/dix/devices.c +++ b/dix/devices.c @@ -399,11 +399,9 @@ EnableDevice(DeviceIntPtr dev, BOOL sendevent) } } - input_lock(); if ((*prev != dev) || !dev->inited || ((ret = (*dev->deviceProc) (dev, DEVICE_ON)) != Success)) { ErrorF("[dix] couldn't enable device %d\n", dev->id); - input_unlock(); return FALSE; } dev->enabled = TRUE; @@ -412,7 +410,6 @@ EnableDevice(DeviceIntPtr dev, BOOL sendevent) for (prev = &inputInfo.devices; *prev; prev = &(*prev)->next); *prev = dev; dev->next = NULL; - input_unlock(); enabled = TRUE; XIChangeDeviceProperty(dev, XIGetKnownProperty(XI_PROP_ENABLED), -------------- next part -------------- [ 12676.328] (II) config/udev: ignoring device /dev/tty63 without property ID_INPUT set [ 12676.328] (II) config/udev: ignoring device /dev/tty7 without property ID_INPUT set [ 12676.328] (II) config/udev: ignoring device /dev/tty8 without property ID_INPUT set [ 12676.328] (II) config/udev: ignoring device /dev/tty9 without property ID_INPUT set [ 12676.328] (II) inputh lock ... [ 12676.328] (II) inputh locked [ 12676.328] (II) dev fd=20 state=0 [ 12676.328] (II) dev fd=21 state=0 [ 12676.328] (II) dev fd=22 state=0 [ 12676.328] (II) dev fd=23 state=0 [ 12676.328] (II) dev fd=24 state=0 [ 12676.328] (II) dev fd=25 state=0 [ 12681.504] (II) InputThreadUnregisterDev(fd=20) ... [ 12681.504] (II) InputThreadUnregisterDev: found a device: fd=20 state=1 [ 12681.504] (II) inputh lock ... [ 12681.517] (II) inputh locked [ 12681.517] (II) dev fd=20 state=2 [ 12681.517] (II) InputThreadUnregisterDev(fd=21) ... [ 12681.517] (II) InputThreadUnregisterDev: found a device: fd=21 state=1 [ 12681.517] (II) inputh lock ... [ 12681.529] (II) inputh locked [ 12681.529] (II) dev fd=21 state=2 [ 12681.529] (II) InputThreadUnregisterDev(fd=22) ... [ 12681.529] (II) InputThreadUnregisterDev: found a device: fd=22 state=1 [ 12681.529] (II) inputh lock ... [ 12681.541] (II) inputh locked [ 12681.541] (II) dev fd=22 state=2 [ 12681.541] (II) InputThreadUnregisterDev(fd=23) ... [ 12681.541] (II) InputThreadUnregisterDev: found a device: fd=23 state=1 [ 12681.541] (II) inputh lock ... [ 12681.556] (II) inputh locked [ 12681.556] (II) dev fd=23 state=2 [ 12681.556] (II) InputThreadUnregisterDev(fd=24) ... [ 12681.556] (II) InputThreadUnregisterDev: found a device: fd=24 state=1 [ 12681.556] (II) inputh lock ... [ 12681.568] (II) inputh locked [ 12681.568] (II) dev fd=24 state=2 [ 12681.568] (II) InputThreadUnregisterDev(fd=25) ... [ 12681.568] (II) InputThreadUnregisterDev: found a device: fd=25 state=1 [ 12681.568] (II) inputh lock ... [ 12681.580] (II) AIGLX: Suspending AIGLX clients for VT switch [ 12683.746] (II) AIGLX: Resuming AIGLX clients after VT switch [ 12683.762] (II) modeset(0): .. ... [ 12683.874] (II) InputThreadRegisterDev(fd=20) ... [ 12683.874] (II) InputThreadRegisterDev(fd=21) ... [ 12683.874] (II) InputThreadRegisterDev(fd=22) ... [ 12683.874] (II) InputThreadRegisterDev(fd=23) ... [ 12683.874] (II) InputThreadRegisterDev(fd=24) ... [ 12683.874] (II) InputThreadRegisterDev(fd=25) ... [ 12683.874] (II) InputThreadRegisterDev: found a device: fd=25 state=2 [ 12683.874] (II) inputh locked [ 12683.875] (II) dev fd=20 state=0 [ 12683.875] (II) dev fd=21 state=0 [ 12683.875] (II) dev fd=22 state=0 [ 12683.875] (II) dev fd=23 state=0 [ 12683.875] (II) dev fd=24 state=0 [ 12695.794] (II) InputThreadUnregisterDev(fd=20) ... [ 12695.794] (II) InputThreadUnregisterDev: found a device: fd=20 state=1 [ 12695.794] (II) inputh lock ... [ 12695.805] (II) inputh locked [ 12695.805] (II) dev fd=20 state=2 [ 12695.805] (II) InputThreadUnregisterDev(fd=21) ... [ 12695.805] (II) InputThreadUnregisterDev: found a device: fd=21 state=1 [ 12695.805] (II) inputh lock ... [ 12695.817] (II) inputh locked [ 12695.817] (II) dev fd=21 state=2 [ 12695.817] (II) InputThreadUnregisterDev(fd=22) ... [ 12695.817] (II) InputThreadUnregisterDev: found a device: fd=22 state=1 [ 12695.817] (II) inputh lock ... [ 12695.829] (II) inputh locked [ 12695.829] (II) dev fd=22 state=2 [ 12695.829] (II) InputThreadUnregisterDev(fd=23) ... [ 12695.829] (II) InputThreadUnregisterDev: found a device: fd=23 state=1 [ 12695.829] (II) inputh lock ... [ 12695.841] (II) inputh locked [ 12695.841] (II) dev fd=23 state=2 [ 12695.841] (II) InputThreadUnregisterDev(fd=24) ... [ 12695.841] (II) InputThreadUnregisterDev: found a device: fd=24 state=1 [ 12695.841] (II) inputh lock ... [ 12695.853] (II) inputh locked [ 12695.853] (II) dev fd=24 state=2 [ 12695.853] (II) InputThreadUnregisterDev(fd=25) ... [ 12695.853] (II) InputThreadUnregisterDev: found a device: fd=25 state=1 [ 12695.853] (II) inputh lock ... [ 12695.865] (II) inputh locked [ 12695.865] (II) dev fd=25 state=2 [ 12695.865] (II) evdev: .. [ 12695.865] (II) UnloadModule: "evdev" [ 12695.865] (II) evdev: .. [ 12695.865] (II) UnloadModule: "evdev" [ 12695.866] (II) evdev: .. [ 12695.866] (II) UnloadModule: "evdev" [ 12695.866] (II) evdev: Power Button: Close [ 12695.866] (II) UnloadModule: "evdev" [ 12695.866] (II) evdev: Video Bus: Close [ 12695.866] (II) UnloadModule: "evdev" [ 12695.866] (II) evdev: Power Button: Close [ 12695.866] (II) UnloadModule: "evdev" [ 12695.889] (II) Server terminated successfully (0). Closing log file. -------------- next part -------------- ... [ 14470.539] (II) config/udev: ignoring device /dev/tty7 without property ID_INPUT set [ 14470.539] (II) config/udev: ignoring device /dev/tty8 without property ID_INPUT set [ 14470.540] (II) config/udev: ignoring device /dev/tty9 without property ID_INPUT set [ 14470.540] (II) inputh lock ... [ 14470.540] (II) inputh locked [ 14470.540] (II) dev fd=20 state=0 [ 14470.540] (II) dev fd=21 state=0 [ 14470.540] (II) dev fd=22 state=0 [ 14470.540] (II) dev fd=23 state=0 [ 14470.540] (II) dev fd=24 state=0 [ 14470.540] (II) dev fd=25 state=0 [ 14476.492] (II) InputThreadUnregisterDev(fd=20) ... [ 14476.492] (II) InputThreadUnregisterDev: found a device: fd=20 state=1 [ 14476.492] (II) inputh lock ... [ 14476.505] (II) inputh locked [ 14476.505] (II) dev fd=20 state=2 [ 14476.505] (II) InputThreadUnregisterDev(fd=21) ... [ 14476.505] (II) InputThreadUnregisterDev: found a device: fd=21 state=1 [ 14476.505] (II) inputh lock ... [ 14476.517] (II) inputh locked [ 14476.517] (II) dev fd=21 state=2 [ 14476.517] (II) InputThreadUnregisterDev(fd=22) ... [ 14476.517] (II) InputThreadUnregisterDev: found a device: fd=22 state=1 [ 14476.517] (II) inputh lock ... [ 14476.529] (II) inputh locked [ 14476.529] (II) dev fd=22 state=2 [ 14476.529] (II) InputThreadUnregisterDev(fd=23) ... [ 14476.529] (II) InputThreadUnregisterDev: found a device: fd=23 state=1 [ 14476.529] (II) inputh lock ... [ 14476.541] (II) inputh locked [ 14476.541] (II) dev fd=23 state=2 [ 14476.541] (II) InputThreadUnregisterDev(fd=24) ... [ 14476.541] (II) InputThreadUnregisterDev: found a device: fd=24 state=1 [ 14476.541] (II) inputh lock ... [ 14476.553] (II) inputh locked [ 14476.553] (II) dev fd=24 state=2 [ 14476.553] (II) InputThreadUnregisterDev(fd=25) ... [ 14476.553] (II) InputThreadUnregisterDev: found a device: fd=25 state=1 [ 14476.553] (II) inputh lock ... [ 14476.565] (II) AIGLX: Suspending AIGLX clients for VT switch [ 14477.916] (II) AIGLX: Resuming AIGLX clients after VT switch [ 14477.940] (II) modeset(0): .. ... [ 14478.053] (II) InputThreadRegisterDev(fd=20) ... [ 14478.053] (II) InputThreadRegisterDev(fd=21) ... [ 14478.053] (II) InputThreadRegisterDev(fd=22) ... [ 14478.053] (II) InputThreadRegisterDev(fd=23) ... [ 14478.053] (II) InputThreadRegisterDev(fd=24) ... [ 14478.053] (II) InputThreadRegisterDev(fd=25) ... [ 14478.053] (II) InputThreadRegisterDev: found a device: fd=25 state=2 [ 14478.053] (II) inputh locked [ 14478.053] (II) dev fd=25 state=2 [ 14478.054] (II) dev fd=20 state=0 [ 14478.054] (II) dev fd=21 state=0 [ 14478.054] (II) dev fd=22 state=0 [ 14478.054] (II) dev fd=23 state=0 [ 14478.054] (II) dev fd=24 state=0 [ 14490.006] (II) InputThreadUnregisterDev(fd=20) ... [ 14490.006] (II) InputThreadUnregisterDev: found a device: fd=20 state=1 [ 14490.006] (II) inputh lock ... [ 14490.019] (II) inputh locked [ 14490.019] (II) dev fd=20 state=2 [ 14490.019] (II) InputThreadUnregisterDev(fd=21) ... [ 14490.019] (II) InputThreadUnregisterDev: found a device: fd=21 state=1 [ 14490.019] (II) inputh lock ... [ 14490.031] (II) inputh locked [ 14490.031] (II) dev fd=21 state=2 [ 14490.031] (II) InputThreadUnregisterDev(fd=22) ... [ 14490.031] (II) InputThreadUnregisterDev: found a device: fd=22 state=1 [ 14490.031] (II) inputh lock ... [ 14490.043] (II) inputh locked [ 14490.043] (II) dev fd=22 state=2 [ 14490.043] (II) InputThreadUnregisterDev(fd=23) ... [ 14490.043] (II) InputThreadUnregisterDev: found a device: fd=23 state=1 [ 14490.043] (II) inputh lock ... [ 14490.055] (II) inputh locked [ 14490.055] (II) dev fd=23 state=2 [ 14490.055] (II) InputThreadUnregisterDev(fd=24) ... [ 14490.055] (II) InputThreadUnregisterDev: found a device: fd=24 state=1 [ 14490.055] (II) inputh lock ... [ 14490.067] (II) inputh locked [ 14490.067] (II) dev fd=24 state=2 [ 14490.067] (II) InputThreadUnregisterDev(fd=25) ... [ 14490.079] (II) evdev: .. [ 14490.079] (II) UnloadModule: "evdev" [ 14490.079] (II) evdev: .. [ 14490.079] (II) UnloadModule: "evdev" [ 14490.079] (II) evdev: .. [ 14490.079] (II) UnloadModule: "evdev" [ 14490.079] (II) evdev: Power Button: Close [ 14490.080] (II) UnloadModule: "evdev" [ 14490.080] (II) evdev: Video Bus: Close [ 14490.080] (II) UnloadModule: "evdev" [ 14490.080] (II) evdev: Power Button: Close [ 14490.080] (II) UnloadModule: "evdev" [ 14490.101] (II) Server terminated successfully (0). Closing log file. From k.mvc at ya.ru Sun Oct 9 23:59:44 2016 From: k.mvc at ya.ru (Mihail Konev) Date: Sun, 9 Oct 2016 23:59:44 +0000 Subject: [PATCH xserver] modesetting: add missing ifdef GLAMOR In-Reply-To: <20161009231959.GA17082@localhost> References: <20161009231959.GA17082@localhost> Message-ID: <20161009235943.GA31769@localhost> This seems to have been merged shortly after 1.19 RC1, i.e. non-critical bugs deadline. So it is a post-deadline fix for critical regression which occured in a non-critical fix (which happened to be merged too-close to crit line). From natano at natano.net Sat Oct 8 18:10:34 2016 From: natano at natano.net (Martin Natano) Date: Sat, 8 Oct 2016 20:10:34 +0200 Subject: [PATCH libX11] Don't rebuild ks_tables.h if nothing changed. Message-ID: <20161008180858.GA39383@watschnbaum.natano.net> This is my first patch to X.Org, so please tell me if there's something wrong with the submission or the patch itself. natano >From e3601d791790ee0f1d0979e4d2a3852c390cd758 Mon Sep 17 00:00:00 2001 From: Martin Natano Date: Sat, 8 Oct 2016 19:57:50 +0200 Subject: [PATCH] Don't rebuild ks_tables.h if nothing changed. ks_tables.h is always considered out of date due to the forced rebuild of the makekeys util. This means the file is also rebuilt during 'make install', which is usually performed as root, which can to lead permission problems later on. --- src/Makefile.am | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/Makefile.am b/src/Makefile.am index 15de59b..f8c476d 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -415,7 +415,5 @@ ks_tables.h: $(KEYSYMDEFS) $(top_builddir)/src/util/makekeys$(EXEEXT) $(top_builddir)/src/util/makekeys $(KEYSYMDEFS) > ks_tables_h mv ks_tables_h $@ -$(top_builddir)/src/util/makekeys$(EXEEXT): force +$(top_builddir)/src/util/makekeys$(EXEEXT): $(top_builddir)/src/util/makekeys.c cd util && $(MAKE) - -force: -- 2.9.3 From michel at daenzer.net Tue Oct 11 07:58:59 2016 From: michel at daenzer.net (=?UTF-8?Q?Michel_D=c3=a4nzer?=) Date: Tue, 11 Oct 2016 16:58:59 +0900 Subject: [PATCH] inputthread: Fix inputthread not listening if a fd gets re-added immediately after removal In-Reply-To: <20161009215210.GA5218@localhost> References: <20161009215210.GA5218@localhost> Message-ID: <7210eb08-9af5-758e-c674-863516b28d73@daenzer.net> On 10/10/16 06:52 AM, Mihail Konev wrote: > On 6 Oct 2016, Hans de Goede wrote: >> On 24-09-16 19:55, Mihail Konev wrote: >>> <..> >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97880 >> >> Thank you for the patch and you're right that there is an issue here. >> >> I've posted a much simpler fix yesterday, and that has been >> favorably reviewed, so I think we're going to go with that fix >> instead, <..> >> > > Applied on top of 9e00cf0f75f286ec0e8137d91ba80ef7ba72ab2a , the patch does not > solve the bug #97880 for me. The bug report status has been RESOLVED FIXED since September 23rd. If it's actually not fixed yet, please update the status. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer From coyote at bks.tv Tue Oct 11 09:15:04 2016 From: coyote at bks.tv (Victor V. Kustov) Date: Tue, 11 Oct 2016 12:15:04 +0300 Subject: Request changes in Compose.pre In-Reply-To: <20161010182022.GG4675@localhost> References: <20161005124028.46d11a52@bkstv.bks-tv.ru> <20161010182022.GG4675@localhost> Message-ID: <20161011121504.78ba88eb@bkstv.bks-tv.ru> Thank you for help, Mihail! -- Cheers, Victor V. Kustov +7 (952) 966 76 24 JID: coyote at bks-tv.ru I use FREE operation system: 4.4.17-calculate GNU/Linux up 4 days, 15 minutes From peter.hutterer at who-t.net Tue Oct 11 09:24:12 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Tue, 11 Oct 2016 19:24:12 +1000 Subject: [PATCH v2 libXi] Set ndevices to 0 in the error case In-Reply-To: <20161008093557.17834-1-niels_ole@salscheider-online.de> References: <20161008093000.16840-1-niels_ole@salscheider-online.de> <20161008093557.17834-1-niels_ole@salscheider-online.de> Message-ID: <20161011092412.GA31450@jelly> On Sat, Oct 08, 2016 at 11:35:57AM +0200, Niels Ole Salscheider wrote: > v2: Fix formating issues tbh, I usually prefer not to touch any parameters on errors. This should better be fixed in the man page to specify the exact behaviour. Cheers, Peter > Signed-off-by: Niels Ole Salscheider > --- > src/XListDev.c | 17 +++++++++++++---- > 1 file changed, 13 insertions(+), 4 deletions(-) > > diff --git a/src/XListDev.c b/src/XListDev.c > index d0c6bf2..f47ad97 100644 > --- a/src/XListDev.c > +++ b/src/XListDev.c > @@ -189,8 +189,10 @@ XListInputDevices( > XExtDisplayInfo *info = XInput_find_display(dpy); > > LockDisplay(dpy); > - if (_XiCheckExtInit(dpy, XInput_Initial_Release, info) == -1) > + if (_XiCheckExtInit(dpy, XInput_Initial_Release, info) == -1) { > + *ndevices = 0; > return ((XDeviceInfo *) NULL); > + } > > GetReq(ListInputDevices, req); > req->reqType = info->codes->major_opcode; > @@ -199,6 +201,7 @@ XListInputDevices( > if (!_XReply(dpy, (xReply *) & rep, 0, xFalse)) { > UnlockDisplay(dpy); > SyncHandle(); > + *ndevices = 0; > return (XDeviceInfo *) NULL; > } > > @@ -212,6 +215,7 @@ XListInputDevices( > _XEatDataWords(dpy, rep.length); > UnlockDisplay(dpy); > SyncHandle(); > + *ndevices = 0; > return (XDeviceInfo *) NULL; > } > _XRead(dpy, (char *)list, rlen); > @@ -220,15 +224,19 @@ XListInputDevices( > sav_any = any; > end = (char *)list + rlen; > for (i = 0; i < *ndevices; i++, list++) { > - if(SizeClassInfo(&any, end - (char *)any, (int)list->num_classes, &s)) > - goto out; > + if(SizeClassInfo(&any, end - (char *)any, (int)list->num_classes, &s)) { > + *ndevices = 0; > + goto out; > + } > size += s; > } > > Nptr = ((unsigned char *)list) + rlen; > for (i = 0, nptr = (unsigned char *)any; i < *ndevices; i++) { > - if (nptr >= Nptr) > + if (nptr >= Nptr) { > + *ndevices = 0; > goto out; > + } > size += *nptr + 1; > nptr += (*nptr + 1); > } > @@ -238,6 +246,7 @@ XListInputDevices( > XFree((char *)slist); > UnlockDisplay(dpy); > SyncHandle(); > + *ndevices = 0; > return (XDeviceInfo *) NULL; > } > sclist = clist; > -- > 2.10.1 From hdegoede at redhat.com Tue Oct 11 09:30:16 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Tue, 11 Oct 2016 11:30:16 +0200 Subject: [PATCH] inputthread: Fix inputthread not listening if a fd gets re-added immediately after removal In-Reply-To: <20161009215210.GA5218@localhost> References: <20161009215210.GA5218@localhost> Message-ID: <6ab9ba1c-adf0-eead-e9f1-1134200527d3@redhat.com> Hi, On 10/09/2016 11:52 PM, Mihail Konev wrote: > Hello. > > On Wed, 5 Oct 2016 14:45:20 +0200, Hans de Goede wrote: >> When a fd is removed dev->state gets set to device_state_removed, >> if the fd then gets re-added before InputThreadDoWork() deals with >> the removal, the InputThreadDevice struct gets reused, but its >> state would stay device_state_removed, so it would still get removed >> on the first InputThreadDoWork() run, resulting in a non functioning >> input device. >> >> This commit fixes this by (re-)setting dev->state to device_state_running >> when a InputThreadDevice struct gets reused. >> >> This fixes input devices sometimes no longer working after a vt-switch. >> >> Signed-off-by: Hans de Goede >> --- >> os/inputthread.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/os/inputthread.c b/os/inputthread.c >> index 6aa0a9c..ab1559f 100644 >> --- a/os/inputthread.c >> +++ b/os/inputthread.c >> @@ -206,6 +206,8 @@ InputThreadRegisterDev(int fd, >> if (dev) { >> dev->readInputProc = readInputProc; >> dev->readInputArgs = readInputArgs; >> + /* Override possible unhandled state == device_state_removed */ >> + dev->state = device_state_running; >> } else { >> dev = calloc(1, sizeof(InputThreadDevice)); >> if (dev == NULL) { >> -- >> 2.9.3 >> > > On 6 Oct 2016, Hans de Goede wrote: >> On 24-09-16 19:55, Mihail Konev wrote: >>> <..> >>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97880 >> >> Thank you for the patch and you're right that there is an issue here. >> >> I've posted a much simpler fix yesterday, and that has been >> favorably reviewed, so I think we're going to go with that fix >> instead, <..> >> > > Applied on top of 9e00cf0f75f286ec0e8137d91ba80ef7ba72ab2a , the patch does not > solve the bug #97880 for me. > > Note: ./configure --disable-glamor is broken somewhere after the ade315386 > (Require xproto 7.0.31), so be sure to --enable-glamor. > > On 9 Oct 2016, Hans de Goede wrote: >> So you've tried my patch, with your patch reverted and it >> does not work for you? Strange as I was hitting the exact >> same problem and it did work for me. >> > > The difference in problem is, however, that in my case result is > consistent - keyboard either works or not all the time, not "sometimes". > Mouse is moving alright. > > First, patch was applied on top of fc1c358b9 (1.19 RC1). > It did not work, so log1.diff was made, applied, > and log1 produced (both attached). > Note: log1 is (fully) commented inline. > > Rebasing on top of 97a8353ec (Fix id in error) did not help. > > At this point (log1), nol_e.diff gives: > - nol_e.log1 > - bug being present > > Applying nol_d.diff to log1 gives: > - nol_d.log1 > - bug being gone > > Manually applied log1.diff to master 97a8353ec (gave log1m.diff). > > At this point (log1m) nol_e.diff gives: > - nol_e.log1m > - bug being present > Mistake in bugzilla bug description: > this shows that not locking EnableDevice is not a sufficient workaround. > > Applying nol_d.diff to log1m gives: > - nol_d.log1m > - bug being gone > This is what is right in bugzilla description: > not locking DisableDevice is a sufficient workaround. > > As I see it, > > The patch assumes no device state to be maintained except in the input thread dev > list. No, the patch assumes that the only device state which gets delayed in processing because InputThreadDoWork() not running in time is the input thread dev list and this is correct, all InputThreadDoWork() does on device_state_removed is remove the fd from the pollfd list, and del the node from the inputhread dev list. My patch simply makes it correctly re-use the dev node on the list, instead of removing it even though the device has been re-added. Hmm, maybe the problem in your case is that the fd is the same before / after device remove / (re-)add but has been closed, so it needs to be removed from the poll list and re-added. I've attached another patch (on top of my previous one) for you to try, I've good hope that this will fix your issue. Regards, Hans -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-inputthread-Re-add-fd-to-the-inputThreadInfo-fds-pol.patch Type: text/x-patch Size: 2532 bytes Desc: not available URL: From jon.turney at dronecode.org.uk Tue Oct 11 13:34:15 2016 From: jon.turney at dronecode.org.uk (Jon Turney) Date: Tue, 11 Oct 2016 14:34:15 +0100 Subject: [PATCH 3/3] configure.ac: remove --enable-aiglx option In-Reply-To: <20161010183154.GA6622@localhost> References: <20161010183154.GA6622@localhost> Message-ID: <82cb29e9-eb10-b1f1-3ac0-ee2514c07e56@dronecode.org.uk> On 10/10/2016 19:31, Mihail Konev wrote: > Hello. > > On Mon Oct 10 14:59:52 UTC 2016, Jon Turney wrote: >> @@ -16,11 +20,10 @@ AM_CPPFLAGS = \ >> -I$(top_srcdir)/hw/xfree86/os-support/bus \ >> -I$(top_srcdir)/hw/xfree86/common \ >> -I$(top_srcdir)/hw/xfree86/dri \ >> + -I$(top_srcdir)/hw/xfree86/dri2 >> -I$(top_srcdir)/mi \ >> -I$(top_srcdir)/present > > Shouldn't there be a backslash? Absolutely! Revised patch attached. I build-tested this on linux with --enable-dri2 and --disabl-dri2 -------------- next part -------------- From 549d3d4b82009319563c42b3d0113361ded257aa Mon Sep 17 00:00:00 2001 From: Jon Turney Date: Thu, 6 Oct 2016 22:13:07 +0100 Subject: [PATCH xserver] glx/dri2: Don't build DRI loader if DRI2 isn't enabled This partially reverts 501d8e2b. Signed-off-by: Jon Turney --- glx/Makefile.am | 11 ++++++++--- hw/xfree86/dixmods/Makefile.am | 2 ++ 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/glx/Makefile.am b/glx/Makefile.am index fc0b76a..699de63 100644 --- a/glx/Makefile.am +++ b/glx/Makefile.am @@ -1,4 +1,8 @@ -noinst_LTLIBRARIES = libglx.la libglxdri.la +if DRI2 +GLXDRI_LIBRARY = libglxdri.la +endif + +noinst_LTLIBRARIES = libglx.la $(GLXDRI_LIBRARY) AM_CFLAGS = \ @DIX_CFLAGS@ \ @@ -16,11 +20,10 @@ AM_CPPFLAGS = \ -I$(top_srcdir)/hw/xfree86/os-support/bus \ -I$(top_srcdir)/hw/xfree86/common \ -I$(top_srcdir)/hw/xfree86/dri \ + -I$(top_srcdir)/hw/xfree86/dri2 \ -I$(top_srcdir)/mi \ -I$(top_srcdir)/present -AM_CPPFLAGS += -I$(top_srcdir)/hw/xfree86/dri2 - indirect_sources = \ indirect_dispatch.c \ indirect_dispatch.h \ @@ -33,7 +36,9 @@ indirect_sources = \ indirect_table.c libglxdri_la_SOURCES = +if DRI2 libglxdri_la_SOURCES += glxdri2.c +endif libglxdri_la_LIBADD = $(DLOPEN_LIBS) diff --git a/hw/xfree86/dixmods/Makefile.am b/hw/xfree86/dixmods/Makefile.am index be43e8f..d534c78 100644 --- a/hw/xfree86/dixmods/Makefile.am +++ b/hw/xfree86/dixmods/Makefile.am @@ -29,10 +29,12 @@ libwfb_la_CFLAGS = $(AM_CFLAGS) -DFB_ACCESS_WRAPPER libglx_la_LDFLAGS = -module -avoid-version $(LD_NO_UNDEFINED_FLAG) libglx_la_LIBADD = $(top_builddir)/glx/libglx.la $(GLX_SYS_LIBS) +if DRI2 libglx_la_LIBADD += $(top_builddir)/glx/libglxdri.la if NO_UNDEFINED libglx_la_LIBADD += $(LIBDRM_LIBS) $(PIXMAN_LIBS) endif +endif libglx_la_SOURCES = glxmodule.c libshadow_la_LDFLAGS = -module -avoid-version $(LD_NO_UNDEFINED_FLAG) -- 2.8.3 From coyote at bks.tv Tue Oct 11 15:34:55 2016 From: coyote at bks.tv (Victor Kustov) Date: Tue, 11 Oct 2016 18:34:55 +0300 Subject: [PATCH libX11] fix #98205: add rouble currency in Compose table Message-ID: <1476200095-28039-1-git-send-email-coyote@bks.tv> From: coyote Signed-off-by: coyote --- nls/en_US.UTF-8/Compose.pre | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre index adc24fb..012fdb2 100644 --- a/nls/en_US.UTF-8/Compose.pre +++ b/nls/en_US.UTF-8/Compose.pre @@ -190,6 +190,10 @@ XCOMM "₪" U20aa NEW SHEQEL SIGN : "€" EuroSign # EURO SIGN : "€" EuroSign # EURO SIGN : "€" EuroSign # EURO SIGN +

: "₽" U20bd # RUBLE-CURRENCY SIGN +

: "₽" U20bd # RUBLE-CURRENCY SIGN +

: "₽" U20bd # RUBLE-CURRENCY SIGN +

: "₽" U20bd # RUBLE-CURRENCY SIGN XCOMM "₭" U20ad KIP SIGN XCOMM "₮" U20ae TUGRIK SIGN XCOMM "₯" U20af DRACHMA SIGN -- 2.7.3 From ajax at nwnk.net Tue Oct 11 16:48:27 2016 From: ajax at nwnk.net (Adam Jackson) Date: Tue, 11 Oct 2016 12:48:27 -0400 Subject: [PATCH 3/3] glx: Initialize glx even if there are currently no screens attached In-Reply-To: <322ECAAA-5972-423B-8AD6-6441BC2903BF@apple.com> References: <20161009195104.47686-1-jeremyhu@apple.com> <20161009195104.47686-3-jeremyhu@apple.com> <1476119815.11675.5.camel@nwnk.net> <322ECAAA-5972-423B-8AD6-6441BC2903BF@apple.com> Message-ID: <1476204507.2311.11.camel@nwnk.net> On Mon, 2016-10-10 at 16:30 -0700, Jeremy Huddleston Sequoia wrote: > Yes, GLX requires a GL-capable visual in order to work, but that > doesn't mean that it needs to be present at the time that the > extension is initialized.  We be able to start with 0 screens > attached and then treat adding #1 the same as we would adding #2. That's a noble goal and all, but there's a pile of work needed before that's possible. Right now the ddx tells dix what kind of visuals it supports, so with "zero" screens you would have zero visuals. You probably don't want to change the visual list dynamically, because there's no way to notify already-connected clients that it has changed. We'd need to reorganize things so dix _declares_ what kind of visuals it will support, and ddx conform to that. (Which is a bit awkward if you declare 32bpp and then plug in a device that wants 16bpp... maybe we just don't care about that case.) Even then, GLX would make it complicated, because we can't peek ahead to know what kind of 3D support we'll have, so we can't know to create visuals that are stereo- or multisample-capable. Admittedly some of this is a Mesa bug, in that things like the z/s buffer are allocated at context creation based on the fbconfig rather than as needed, so you want not to just make the root window visual all-capable. All that said, if that's something you're working on, please don't let me discourage you. - ajax From k.mvc at ya.ru Wed Oct 12 01:58:20 2016 From: k.mvc at ya.ru (Mihail Konev) Date: Wed, 12 Oct 2016 01:58:20 +0000 Subject: [PATCH] inputthread: Fix inputthread not listening if a fd gets re-added immediately after removal In-Reply-To: <20161011113204.GA14417@localhost> References: <20161009215210.GA5218@localhost> <20161011113204.GA14417@localhost> Message-ID: <20161012015820.GB5103@localhost> On Tue Oct 11 09:30:16 UTC 2016, Hans de Goede wrote: > I've attached another patch (on top of my previous one) for you to try, > I've good hope that this will fix your issue. Fixes #97880, thanks. From ossman at cendio.se Wed Oct 12 09:05:31 2016 From: ossman at cendio.se (Pierre Ossman) Date: Wed, 12 Oct 2016 11:05:31 +0200 Subject: [PATCH] Handle animated cursor on shared sprite Message-ID: Sprites (and hence cursors) can be shared between multiple devices. However the animation code was not prepared for this and could wind up in a case where it would continue to animate a free:d cursor. --- include/inputstr.h | 14 ++++----- render/animcur.c | 85 +++++++++++++++++++++++++++++------------------------- 2 files changed, 51 insertions(+), 48 deletions(-) diff --git a/include/inputstr.h b/include/inputstr.h index 568f5f9..a485f5e 100644 --- a/include/inputstr.h +++ b/include/inputstr.h @@ -246,6 +246,12 @@ typedef struct _SpriteRec { ScreenPtr pEnqueueScreen; ScreenPtr pDequeueScreen; + /* keep states for animated cursor */ + struct { + ScreenPtr pScreen; + int elt; + CARD32 time; + } anim; } SpriteRec; typedef struct _KeyClassRec { @@ -509,14 +515,6 @@ typedef struct _SpriteInfoRec { DeviceIntPtr paired; /* The paired device. Keyboard if spriteOwner is TRUE, otherwise the pointer that owns the sprite. */ - - /* keep states for animated cursor */ - struct { - CursorPtr pCursor; - ScreenPtr pScreen; - int elt; - CARD32 time; - } anim; } SpriteInfoRec, *SpriteInfoPtr; /* device types */ diff --git a/render/animcur.c b/render/animcur.c index 52e6b8b..fc87e0d 100644 --- a/render/animcur.c +++ b/render/animcur.c @@ -142,35 +142,42 @@ AnimCurTimerNotify(OsTimerPtr timer, CARD32 now, void *arg) CARD32 soonest = ~0; /* earliest time to wakeup again */ for (dev = inputInfo.devices; dev; dev = dev->next) { - if (IsPointerDevice(dev) && pScreen == dev->spriteInfo->anim.pScreen) { - if (!activeDevice) - activeDevice = TRUE; - - if ((INT32) (now - dev->spriteInfo->anim.time) >= 0) { - AnimCurPtr ac = GetAnimCur(dev->spriteInfo->anim.pCursor); - int elt = (dev->spriteInfo->anim.elt + 1) % ac->nelt; - DisplayCursorProcPtr DisplayCursor; - - /* - * Not a simple Unwrap/Wrap as this - * isn't called along the DisplayCursor - * wrapper chain. - */ - DisplayCursor = pScreen->DisplayCursor; - pScreen->DisplayCursor = as->DisplayCursor; - (void) (*pScreen->DisplayCursor) (dev, - pScreen, - ac->elts[elt].pCursor); - as->DisplayCursor = pScreen->DisplayCursor; - pScreen->DisplayCursor = DisplayCursor; - - dev->spriteInfo->anim.elt = elt; - dev->spriteInfo->anim.time = now + ac->elts[elt].delay; - } - - if (soonest > dev->spriteInfo->anim.time) - soonest = dev->spriteInfo->anim.time; + if (!IsPointerDevice(dev)) + continue; + if (!dev->spriteInfo->spriteOwner) + continue; + if (!IsAnimCur(dev->spriteInfo->sprite->current)) + continue; + if (pScreen != dev->spriteInfo->sprite->anim.pScreen) + continue; + + if (!activeDevice) + activeDevice = TRUE; + + if ((INT32) (now - dev->spriteInfo->sprite->anim.time) >= 0) { + AnimCurPtr ac = GetAnimCur(dev->spriteInfo->sprite->current); + int elt = (dev->spriteInfo->sprite->anim.elt + 1) % ac->nelt; + DisplayCursorProcPtr DisplayCursor; + + /* + * Not a simple Unwrap/Wrap as this + * isn't called along the DisplayCursor + * wrapper chain. + */ + DisplayCursor = pScreen->DisplayCursor; + pScreen->DisplayCursor = as->DisplayCursor; + (void) (*pScreen->DisplayCursor) (dev, + pScreen, + ac->elts[elt].pCursor); + as->DisplayCursor = pScreen->DisplayCursor; + pScreen->DisplayCursor = DisplayCursor; + + dev->spriteInfo->sprite->anim.elt = elt; + dev->spriteInfo->sprite->anim.time = now + ac->elts[elt].delay; } + + if (soonest > dev->spriteInfo->sprite->anim.time) + soonest = dev->spriteInfo->sprite->anim.time; } if (activeDevice) @@ -192,17 +199,17 @@ AnimCurDisplayCursor(DeviceIntPtr pDev, ScreenPtr pScreen, CursorPtr pCursor) Unwrap(as, pScreen, DisplayCursor); if (IsAnimCur(pCursor)) { - if (pCursor != pDev->spriteInfo->anim.pCursor) { + if (pDev->spriteInfo->spriteOwner && + (pCursor != pDev->spriteInfo->sprite->current)) { AnimCurPtr ac = GetAnimCur(pCursor); ret = (*pScreen->DisplayCursor) (pDev, pScreen, ac->elts[0].pCursor); if (ret) { - pDev->spriteInfo->anim.elt = 0; - pDev->spriteInfo->anim.time = + pDev->spriteInfo->sprite->anim.elt = 0; + pDev->spriteInfo->sprite->anim.time = GetTimeInMillis() + ac->elts[0].delay; - pDev->spriteInfo->anim.pCursor = pCursor; - pDev->spriteInfo->anim.pScreen = pScreen; + pDev->spriteInfo->sprite->anim.pScreen = pScreen; if (!as->timer_set) { TimerSet(as->timer, TimerAbsolute, pDev->spriteInfo->anim.time, @@ -214,11 +221,8 @@ AnimCurDisplayCursor(DeviceIntPtr pDev, ScreenPtr pScreen, CursorPtr pCursor) else ret = TRUE; } - else { - pDev->spriteInfo->anim.pCursor = 0; - pDev->spriteInfo->anim.pScreen = 0; + else ret = (*pScreen->DisplayCursor) (pDev, pScreen, pCursor); - } Wrap(as, pScreen, DisplayCursor, AnimCurDisplayCursor); return ret; } @@ -231,8 +235,9 @@ AnimCurSetCursorPosition(DeviceIntPtr pDev, Bool ret; Unwrap(as, pScreen, SetCursorPosition); - if (pDev->spriteInfo->anim.pCursor) { - pDev->spriteInfo->anim.pScreen = pScreen; + if (pDev->spriteInfo->spriteOwner && + IsAnimCur(pDev->spriteInfo->sprite->current)) { + pDev->spriteInfo->sprite->anim.pScreen = pScreen; if (!as->timer_set) { TimerSet(as->timer, TimerAbsolute, pDev->spriteInfo->anim.time, @@ -296,7 +301,7 @@ AnimCurRecolorCursor(DeviceIntPtr pDev, for (i = 0; i < ac->nelt; i++) (*pScreen->RecolorCursor) (pDev, pScreen, ac->elts[i].pCursor, displayed && - pDev->spriteInfo->anim.elt == i); + pDev->spriteInfo->sprite->anim.elt == i); } else (*pScreen->RecolorCursor) (pDev, pScreen, pCursor, displayed); -- 2.7.4 From ossman at cendio.se Wed Oct 12 09:11:43 2016 From: ossman at cendio.se (Pierre Ossman) Date: Wed, 12 Oct 2016 11:11:43 +0200 Subject: [PATCH] Handle animated cursor on shared sprite In-Reply-To: References: Message-ID: This was causing crashes in TigerVNC with Chrome/Chromium. Regards -- Pierre Ossman Software Development Cendio AB https://cendio.com Teknikringen 8 https://twitter.com/ThinLinc 583 30 Linköping https://facebook.com/ThinLinc Phone: +46-13-214600 https://plus.google.com/+CendioThinLinc A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? From emil.l.velikov at gmail.com Wed Oct 12 11:45:51 2016 From: emil.l.velikov at gmail.com (Emil Velikov) Date: Wed, 12 Oct 2016 12:45:51 +0100 Subject: [PATCH 3/3] configure.ac: remove --enable-aiglx option In-Reply-To: <82cb29e9-eb10-b1f1-3ac0-ee2514c07e56@dronecode.org.uk> References: <20161010183154.GA6622@localhost> <82cb29e9-eb10-b1f1-3ac0-ee2514c07e56@dronecode.org.uk> Message-ID: On 11 October 2016 at 14:34, Jon Turney wrote: > On 10/10/2016 19:31, Mihail Konev wrote: >> >> Hello. >> >> On Mon Oct 10 14:59:52 UTC 2016, Jon Turney wrote: >>> >>> @@ -16,11 +20,10 @@ AM_CPPFLAGS = \ >>> -I$(top_srcdir)/hw/xfree86/os-support/bus \ >>> -I$(top_srcdir)/hw/xfree86/common \ >>> -I$(top_srcdir)/hw/xfree86/dri \ >>> + -I$(top_srcdir)/hw/xfree86/dri2 >>> -I$(top_srcdir)/mi \ >>> -I$(top_srcdir)/present >> >> >> Shouldn't there be a backslash? > > > Absolutely! Revised patch attached. > One could have kept the include path as-is or even wrap it in if DRI2 (like the original code). Either way, the updated patch looks correct and is Reviewed-by: Emil Velikov Emil From bernhard.miklautz at thincast.com Wed Oct 12 11:41:29 2016 From: bernhard.miklautz at thincast.com (Bernhard Miklautz) Date: Wed, 12 Oct 2016 13:41:29 +0200 Subject: [PATCH xserver] os: add an optional offset to -displayfd parameter In-Reply-To: References: <1465830370-19494-1-git-send-email-bernhard.miklautz@thincast.com> <39d0e564-3ed9-6531-3a98-00cddd3e8617@nagafix.co.uk> <575EDD5E.8010602@thincast.com> Message-ID: <20161012114128.GB2287@scheep.thinstuff.com> Hi, On Mon, Jun 13, 2016 at 11:44:55PM +0700, Antoine Martin wrote: > Reviewed-by: Antoine Martin quite some time past since my initial submit. What are the next steps to get this merged? Did I miss anything? Thank you. So long, Bernhard From hdegoede at redhat.com Wed Oct 12 14:55:08 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Wed, 12 Oct 2016 16:55:08 +0200 Subject: [PATCH xserver] inputthread: Re-add fd to the inputThreadInfo->fds pollfd set when re-added Message-ID: <20161012145508.4640-1-hdegoede@redhat.com> If the following call sequence happens: 1) InputThreadUnregisterDev(fd) 2) close(fd) 3) fd = open(...) /* returns same fd as just closed */ 4) InputThreadRegisterDev(fd, ...) Without InputThreadDoWork(); running in the mean time, then we would keep the closed fd in the inputThreadInfo->fds pollfd set, rather then removing it and adding the new one, causing some devices to not work after a vt-switch when using xf86-input-evdev. BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=97880 Reported-and-tested-by: Mihail Konev Signed-off-by: Hans de Goede --- os/inputthread.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/os/inputthread.c b/os/inputthread.c index ab1559f..c20c21c 100644 --- a/os/inputthread.c +++ b/os/inputthread.c @@ -49,6 +49,7 @@ Bool InputThreadEnable = TRUE; typedef enum _InputDeviceState { device_state_added, + device_state_re_added, device_state_running, device_state_removed } InputDeviceState; @@ -206,8 +207,8 @@ InputThreadRegisterDev(int fd, if (dev) { dev->readInputProc = readInputProc; dev->readInputArgs = readInputArgs; - /* Override possible unhandled state == device_state_removed */ - dev->state = device_state_running; + if (dev->state == device_state_removed) + dev->state = device_state_re_added; } else { dev = calloc(1, sizeof(InputThreadDevice)); if (dev == NULL) { @@ -344,6 +345,16 @@ InputThreadDoWork(void *arg) ospoll_listen(inputThreadInfo->fds, dev->fd, X_NOTIFY_READ); dev->state = device_state_running; break; + case device_state_re_added: + /* Device might use a new fd with the same number */ + ospoll_remove(inputThreadInfo->fds, dev->fd); + ospoll_add(inputThreadInfo->fds, dev->fd, + ospoll_trigger_level, + InputReady, + dev); + ospoll_listen(inputThreadInfo->fds, dev->fd, X_NOTIFY_READ); + dev->state = device_state_running; + break; case device_state_running: break; case device_state_removed: -- 2.9.3 From wharms at bfs.de Wed Oct 12 15:15:57 2016 From: wharms at bfs.de (walter harms) Date: Wed, 12 Oct 2016 17:15:57 +0200 Subject: [PATCH] Handle animated cursor on shared sprite In-Reply-To: References: Message-ID: <57FE53AD.4090409@bfs.de> Am 12.10.2016 11:05, schrieb Pierre Ossman: > Sprites (and hence cursors) can be shared between multiple devices. > However the animation code was not prepared for this and could wind > up in a case where it would continue to animate a free:d cursor. > --- > include/inputstr.h | 14 ++++----- > render/animcur.c | 85 +++++++++++++++++++++++++++++------------------------- > 2 files changed, 51 insertions(+), 48 deletions(-) > > diff --git a/include/inputstr.h b/include/inputstr.h > index 568f5f9..a485f5e 100644 > --- a/include/inputstr.h > +++ b/include/inputstr.h > @@ -246,6 +246,12 @@ typedef struct _SpriteRec { > ScreenPtr pEnqueueScreen; > ScreenPtr pDequeueScreen; > + /* keep states for animated cursor */ > + struct { > + ScreenPtr pScreen; > + int elt; > + CARD32 time; > + } anim; > } SpriteRec; > typedef struct _KeyClassRec { > @@ -509,14 +515,6 @@ typedef struct _SpriteInfoRec { > DeviceIntPtr paired; /* The paired device. Keyboard if > spriteOwner is TRUE, otherwise the > pointer that owns the sprite. */ > - > - /* keep states for animated cursor */ > - struct { > - CursorPtr pCursor; > - ScreenPtr pScreen; > - int elt; > - CARD32 time; > - } anim; > } SpriteInfoRec, *SpriteInfoPtr; > /* device types */ > diff --git a/render/animcur.c b/render/animcur.c > index 52e6b8b..fc87e0d 100644 > --- a/render/animcur.c > +++ b/render/animcur.c > @@ -142,35 +142,42 @@ AnimCurTimerNotify(OsTimerPtr timer, CARD32 now, void *arg) > CARD32 soonest = ~0; /* earliest time to wakeup again */ > for (dev = inputInfo.devices; dev; dev = dev->next) { > - if (IsPointerDevice(dev) && pScreen == dev->spriteInfo->anim.pScreen) { > - if (!activeDevice) > - activeDevice = TRUE; > - > - if ((INT32) (now - dev->spriteInfo->anim.time) >= 0) { > - AnimCurPtr ac = GetAnimCur(dev->spriteInfo->anim.pCursor); > - int elt = (dev->spriteInfo->anim.elt + 1) % ac->nelt; > - DisplayCursorProcPtr DisplayCursor; > - > - /* > - * Not a simple Unwrap/Wrap as this > - * isn't called along the DisplayCursor > - * wrapper chain. > - */ > - DisplayCursor = pScreen->DisplayCursor; > - pScreen->DisplayCursor = as->DisplayCursor; > - (void) (*pScreen->DisplayCursor) (dev, > - pScreen, > - ac->elts[elt].pCursor); > - as->DisplayCursor = pScreen->DisplayCursor; > - pScreen->DisplayCursor = DisplayCursor; > - > - dev->spriteInfo->anim.elt = elt; > - dev->spriteInfo->anim.time = now + ac->elts[elt].delay; > - } > - > - if (soonest > dev->spriteInfo->anim.time) > - soonest = dev->spriteInfo->anim.time; > + if (!IsPointerDevice(dev)) > + continue; > + if (!dev->spriteInfo->spriteOwner) > + continue; > + if (!IsAnimCur(dev->spriteInfo->sprite->current)) > + continue; > + if (pScreen != dev->spriteInfo->sprite->anim.pScreen) > + continue; > + > + if (!activeDevice) > + activeDevice = TRUE; why the check here ? just set. > + > + if ((INT32) (now - dev->spriteInfo->sprite->anim.time) >= 0) { > + AnimCurPtr ac = GetAnimCur(dev->spriteInfo->sprite->current); > + int elt = (dev->spriteInfo->sprite->anim.elt + 1) % ac->nelt; > + DisplayCursorProcPtr DisplayCursor; > + > + /* > + * Not a simple Unwrap/Wrap as this > + * isn't called along the DisplayCursor > + * wrapper chain. > + */ > + DisplayCursor = pScreen->DisplayCursor; > + pScreen->DisplayCursor = as->DisplayCursor; > + (void) (*pScreen->DisplayCursor) (dev, > + pScreen, > + ac->elts[elt].pCursor); > + as->DisplayCursor = pScreen->DisplayCursor; > + pScreen->DisplayCursor = DisplayCursor; > + > + dev->spriteInfo->sprite->anim.elt = elt; > + dev->spriteInfo->sprite->anim.time = now + ac->elts[elt].delay; > } > + > + if (soonest > dev->spriteInfo->sprite->anim.time) > + soonest = dev->spriteInfo->sprite->anim.time; > } > if (activeDevice) > @@ -192,17 +199,17 @@ AnimCurDisplayCursor(DeviceIntPtr pDev, ScreenPtr pScreen, CursorPtr pCursor) > Unwrap(as, pScreen, DisplayCursor); > if (IsAnimCur(pCursor)) { > - if (pCursor != pDev->spriteInfo->anim.pCursor) { > + if (pDev->spriteInfo->spriteOwner && > + (pCursor != pDev->spriteInfo->sprite->current)) { > AnimCurPtr ac = GetAnimCur(pCursor); > ret = (*pScreen->DisplayCursor) > (pDev, pScreen, ac->elts[0].pCursor); > if (ret) { > - pDev->spriteInfo->anim.elt = 0; > - pDev->spriteInfo->anim.time = > + pDev->spriteInfo->sprite->anim.elt = 0; > + pDev->spriteInfo->sprite->anim.time = > GetTimeInMillis() + ac->elts[0].delay; > - pDev->spriteInfo->anim.pCursor = pCursor; > - pDev->spriteInfo->anim.pScreen = pScreen; > + pDev->spriteInfo->sprite->anim.pScreen = pScreen; > if (!as->timer_set) { > TimerSet(as->timer, TimerAbsolute, pDev->spriteInfo->anim.time, > @@ -214,11 +221,8 @@ AnimCurDisplayCursor(DeviceIntPtr pDev, ScreenPtr pScreen, CursorPtr pCursor) > else > ret = TRUE; > } > - else { > - pDev->spriteInfo->anim.pCursor = 0; > - pDev->spriteInfo->anim.pScreen = 0; > + else > ret = (*pScreen->DisplayCursor) (pDev, pScreen, pCursor); > - } > Wrap(as, pScreen, DisplayCursor, AnimCurDisplayCursor); > return ret; > } > @@ -231,8 +235,9 @@ AnimCurSetCursorPosition(DeviceIntPtr pDev, > Bool ret; > Unwrap(as, pScreen, SetCursorPosition); > - if (pDev->spriteInfo->anim.pCursor) { > - pDev->spriteInfo->anim.pScreen = pScreen; > + if (pDev->spriteInfo->spriteOwner && > + IsAnimCur(pDev->spriteInfo->sprite->current)) { > + pDev->spriteInfo->sprite->anim.pScreen = pScreen; > if (!as->timer_set) { > TimerSet(as->timer, TimerAbsolute, pDev->spriteInfo->anim.time, > @@ -296,7 +301,7 @@ AnimCurRecolorCursor(DeviceIntPtr pDev, > for (i = 0; i < ac->nelt; i++) > (*pScreen->RecolorCursor) (pDev, pScreen, ac->elts[i].pCursor, > displayed && > - pDev->spriteInfo->anim.elt == i); > + pDev->spriteInfo->sprite->anim.elt == i); > } > else > (*pScreen->RecolorCursor) (pDev, pScreen, pCursor, displayed); From emil.l.velikov at gmail.com Wed Oct 12 16:05:27 2016 From: emil.l.velikov at gmail.com (Emil Velikov) Date: Wed, 12 Oct 2016 17:05:27 +0100 Subject: [PATCH] Handle animated cursor on shared sprite In-Reply-To: References: Message-ID: Hi Pierre, On 12 October 2016 at 10:05, Pierre Ossman wrote: > Sprites (and hence cursors) can be shared between multiple devices. > However the animation code was not prepared for this and could wind > up in a case where it would continue to animate a free:d cursor. > --- > include/inputstr.h | 14 ++++----- > render/animcur.c | 85 +++++++++++++++++++++++++++++------------------------- > 2 files changed, 51 insertions(+), 48 deletions(-) > > diff --git a/include/inputstr.h b/include/inputstr.h > index 568f5f9..a485f5e 100644 > --- a/include/inputstr.h > +++ b/include/inputstr.h > @@ -246,6 +246,12 @@ typedef struct _SpriteRec { > ScreenPtr pEnqueueScreen; > ScreenPtr pDequeueScreen; > + /* keep states for animated cursor */ > + struct { > + ScreenPtr pScreen; > + int elt; > + CARD32 time; > + } anim; > } SpriteRec; Note that this changes the ABI so it might not be good for the point releases. Unless one wants to make things extra 'fun' for binary only drivers ;-) Haven't looked at the patch in detail, so I cannot comment the issue can be fixed without breaking the ABI. -Emil From peter.hutterer at who-t.net Thu Oct 13 01:12:48 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Thu, 13 Oct 2016 11:12:48 +1000 Subject: [PATCH libXi] SizeClassInfo can return 0 even without an error In-Reply-To: <20161007194644.31537-1-niels_ole@salscheider-online.de> References: <20161007194644.31537-1-niels_ole@salscheider-online.de> Message-ID: <20161013011248.GB22708@jelly> On Fri, Oct 07, 2016 at 09:46:44PM +0200, Niels Ole Salscheider wrote: > Catch the error case separately. This fixes a few crashes on my computer. others have mentioned this already, but "fixes a few crashes" is too generic for a commit message. you should always explain *why* you're doing something in as much detail as required for someone to reproduce or at least understand the issue. in a few months time, most of us will have forgotten what this patch was about and then rely on the commit message to refresh our memory. > Signed-off-by: Niels Ole Salscheider > --- > src/XListDev.c | 21 ++++++++++----------- > 1 file changed, 10 insertions(+), 11 deletions(-) > > diff --git a/src/XListDev.c b/src/XListDev.c > index f850cd0..d0c6bf2 100644 > --- a/src/XListDev.c > +++ b/src/XListDev.c > @@ -73,27 +73,27 @@ static int pad_to_xid(int base_size) > return ((base_size + padsize - 1)/padsize) * padsize; > } > > -static size_t > -SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes) > +static int > +SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes, size_t *size) > { > - int size = 0; > int j; > + *size = 0; happy to merge this with this bit removed and adjusted so that size only changes in the success case. but I will need a commit message that explains bits in more detail. Cheers, Peter > for (j = 0; j < num_classes; j++) { > switch ((*any)->class) { > case KeyClass: > - size += pad_to_xid(sizeof(XKeyInfo)); > + *size += pad_to_xid(sizeof(XKeyInfo)); > break; > case ButtonClass: > - size += pad_to_xid(sizeof(XButtonInfo)); > + *size += pad_to_xid(sizeof(XButtonInfo)); > break; > case ValuatorClass: > { > xValuatorInfoPtr v; > > if (len < sizeof(v)) > - return 0; > + return 1; > v = (xValuatorInfoPtr) *any; > - size += pad_to_xid(sizeof(XValuatorInfo) + > + *size += pad_to_xid(sizeof(XValuatorInfo) + > (v->num_axes * sizeof(XAxisInfo))); > break; > } > @@ -101,11 +101,11 @@ SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes) > break; > } > if ((*any)->length > len) > - return 0; > + return 1; > *any = (xAnyClassPtr) ((char *)(*any) + (*any)->length); > } > > - return size; > + return 0; > } > > static void > @@ -220,8 +220,7 @@ XListInputDevices( > sav_any = any; > end = (char *)list + rlen; > for (i = 0; i < *ndevices; i++, list++) { > - s = SizeClassInfo(&any, end - (char *)any, (int)list->num_classes); > - if (!s) > + if(SizeClassInfo(&any, end - (char *)any, (int)list->num_classes, &s)) > goto out; > size += s; > } > -- > 2.10.1 > > _______________________________________________ > xorg-devel at lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel > From peter.hutterer at who-t.net Thu Oct 13 01:12:33 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Thu, 13 Oct 2016 11:12:33 +1000 Subject: [PATCH libXi] SizeClassInfo can return 0 even without an error In-Reply-To: <20161007194644.31537-1-niels_ole@salscheider-online.de> References: <20161007194644.31537-1-niels_ole@salscheider-online.de> Message-ID: <20161013011233.GA22708@jelly> On Fri, Oct 07, 2016 at 09:46:44PM +0200, Niels Ole Salscheider wrote: > Catch the error case separately. This fixes a few crashes on my computer. others have mentioned this already, but "fixes a few crashes" is too generic for a commit message. you should always explain *why* you're doing something in as much detail as required for someone to reproduce or at least understand the issue. in a few months time, most of us will have forgotten what this patch was about and then rely on the commit message to refresh our memory. > Signed-off-by: Niels Ole Salscheider > --- > src/XListDev.c | 21 ++++++++++----------- > 1 file changed, 10 insertions(+), 11 deletions(-) > > diff --git a/src/XListDev.c b/src/XListDev.c > index f850cd0..d0c6bf2 100644 > --- a/src/XListDev.c > +++ b/src/XListDev.c > @@ -73,27 +73,27 @@ static int pad_to_xid(int base_size) > return ((base_size + padsize - 1)/padsize) * padsize; > } > > -static size_t > -SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes) > +static int > +SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes, size_t *size) > { > - int size = 0; > int j; > + *size = 0; happy to merge this with this bit removed and adjusted so that size only changes in the success case. but I will need a commit message that explains bits in more detail. Cheers, Peter > for (j = 0; j < num_classes; j++) { > switch ((*any)->class) { > case KeyClass: > - size += pad_to_xid(sizeof(XKeyInfo)); > + *size += pad_to_xid(sizeof(XKeyInfo)); > break; > case ButtonClass: > - size += pad_to_xid(sizeof(XButtonInfo)); > + *size += pad_to_xid(sizeof(XButtonInfo)); > break; > case ValuatorClass: > { > xValuatorInfoPtr v; > > if (len < sizeof(v)) > - return 0; > + return 1; > v = (xValuatorInfoPtr) *any; > - size += pad_to_xid(sizeof(XValuatorInfo) + > + *size += pad_to_xid(sizeof(XValuatorInfo) + > (v->num_axes * sizeof(XAxisInfo))); > break; > } > @@ -101,11 +101,11 @@ SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes) > break; > } > if ((*any)->length > len) > - return 0; > + return 1; > *any = (xAnyClassPtr) ((char *)(*any) + (*any)->length); > } > > - return size; > + return 0; > } > > static void > @@ -220,8 +220,7 @@ XListInputDevices( > sav_any = any; > end = (char *)list + rlen; > for (i = 0; i < *ndevices; i++, list++) { > - s = SizeClassInfo(&any, end - (char *)any, (int)list->num_classes); > - if (!s) > + if(SizeClassInfo(&any, end - (char *)any, (int)list->num_classes, &s)) > goto out; > size += s; > } > -- > 2.10.1 > > _______________________________________________ > xorg-devel at lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel > From peter.hutterer at who-t.net Thu Oct 13 03:58:22 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Thu, 13 Oct 2016 13:58:22 +1000 Subject: [PATCH v2 libXi 1/2] SizeClassInfo can return 0 even without an error Message-ID: <1476331103-24072-1-git-send-email-peter.hutterer@who-t.net> From: Niels Ole Salscheider Catch the error case separately. Commit 19a9cd607d added length checking to SizeClassInfo but re-used the return value of 0 for an error. A device without classes (as is initialized by xf86-input-libinput for tablets) can legitimately return 0 and erroneously triggers an error. Fix this by using a separate value for the error. Reproducible by calling XListInputDevices() with a tablet attached. This fixes a regression introduced in commit 19a9cd607d. Signed-off-by: Niels Ole Salscheider Signed-off-by: Peter Hutterer --- Changes to v1: - don't touch *size until we're sure. - expand commit message Niels: I left you as author and your signed-off-by since it's essentially your patch with a minor change. src/XListDev.c | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/src/XListDev.c b/src/XListDev.c index f850cd0..e4bd3d5 100644 --- a/src/XListDev.c +++ b/src/XListDev.c @@ -73,27 +73,28 @@ static int pad_to_xid(int base_size) return ((base_size + padsize - 1)/padsize) * padsize; } -static size_t -SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes) +static int +SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes, size_t *size) { - int size = 0; int j; + size_t sz = 0; + for (j = 0; j < num_classes; j++) { switch ((*any)->class) { case KeyClass: - size += pad_to_xid(sizeof(XKeyInfo)); + sz += pad_to_xid(sizeof(XKeyInfo)); break; case ButtonClass: - size += pad_to_xid(sizeof(XButtonInfo)); + sz += pad_to_xid(sizeof(XButtonInfo)); break; case ValuatorClass: { xValuatorInfoPtr v; if (len < sizeof(v)) - return 0; + return 1; v = (xValuatorInfoPtr) *any; - size += pad_to_xid(sizeof(XValuatorInfo) + + sz += pad_to_xid(sizeof(XValuatorInfo) + (v->num_axes * sizeof(XAxisInfo))); break; } @@ -101,11 +102,13 @@ SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes) break; } if ((*any)->length > len) - return 0; + return 1; *any = (xAnyClassPtr) ((char *)(*any) + (*any)->length); } - return size; + *size = sz; + + return 0; } static void @@ -220,8 +223,7 @@ XListInputDevices( sav_any = any; end = (char *)list + rlen; for (i = 0; i < *ndevices; i++, list++) { - s = SizeClassInfo(&any, end - (char *)any, (int)list->num_classes); - if (!s) + if(SizeClassInfo(&any, end - (char *)any, (int)list->num_classes, &s)) goto out; size += s; } -- 2.7.4 From peter.hutterer at who-t.net Thu Oct 13 03:58:23 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Thu, 13 Oct 2016 13:58:23 +1000 Subject: [PATCH v2 libXi 2/2] XListInputDevices: don't touch ndevices in case of error In-Reply-To: <1476331103-24072-1-git-send-email-peter.hutterer@who-t.net> References: <1476331103-24072-1-git-send-email-peter.hutterer@who-t.net> Message-ID: <1476331103-24072-2-git-send-email-peter.hutterer@who-t.net> We used to always set *ndevices to the number of devices returned by the server. This magically worked because we pretty much never returned an error except on faulty server or library implementations. With 19a9cd60 we now have more chances of getting an error, so the polite thing is to just leave *ndevices alone when we error out. Document it as such in the man page, just in case someone accidentally reads it. Signed-off-by: Peter Hutterer CC: Niels Ole Salscheider --- Changes to v1: - Niels' first patch set ndevices to 0, this one leaves it untouched man/XListInputDevices.txt | 12 ++++++++++-- src/XListDev.c | 21 ++++++++++++--------- 2 files changed, 22 insertions(+), 11 deletions(-) diff --git a/man/XListInputDevices.txt b/man/XListInputDevices.txt index 276660d..450f377 100644 --- a/man/XListInputDevices.txt +++ b/man/XListInputDevices.txt @@ -220,5 +220,13 @@ DESCRIPTION Floating. If the device is a master device, attached specifies the device ID of the master device this device is paired with. - To free the XDeviceInfo array created by XListInputDevices, use - XFreeDeviceList. +RETURN VALUE +------------ + + XListInputDevices returns a pointer to an array of XDeviceInfo + structs and sets ndevices_return to the number of elements in + that array. To free the XDeviceInfo array created by + XListInputDevices, use XFreeDeviceList. + + On error, XListInputDevices returns NULL and ndevices_return is + left unmodified. diff --git a/src/XListDev.c b/src/XListDev.c index e4bd3d5..dda6011 100644 --- a/src/XListDev.c +++ b/src/XListDev.c @@ -175,7 +175,7 @@ ParseClassInfo(xAnyClassPtr *any, XAnyClassPtr *Any, int num_classes) XDeviceInfo * XListInputDevices( register Display *dpy, - int *ndevices) + int *ndevices_return) { size_t s, size; xListInputDevicesReq *req; @@ -190,6 +190,7 @@ XListInputDevices( int i; unsigned long rlen; XExtDisplayInfo *info = XInput_find_display(dpy); + int ndevices; LockDisplay(dpy); if (_XiCheckExtInit(dpy, XInput_Initial_Release, info) == -1) @@ -205,8 +206,8 @@ XListInputDevices( return (XDeviceInfo *) NULL; } - if ((*ndevices = rep.ndevices)) { /* at least 1 input device */ - size = *ndevices * sizeof(XDeviceInfo); + if ((ndevices = rep.ndevices)) { /* at least 1 input device */ + size = ndevices * sizeof(XDeviceInfo); if (rep.length < (INT_MAX >> 2)) { rlen = rep.length << 2; /* multiply length by 4 */ slist = list = Xmalloc(rlen); @@ -219,17 +220,17 @@ XListInputDevices( } _XRead(dpy, (char *)list, rlen); - any = (xAnyClassPtr) ((char *)list + (*ndevices * sizeof(xDeviceInfo))); + any = (xAnyClassPtr) ((char *)list + (ndevices * sizeof(xDeviceInfo))); sav_any = any; end = (char *)list + rlen; - for (i = 0; i < *ndevices; i++, list++) { + for (i = 0; i < ndevices; i++, list++) { if(SizeClassInfo(&any, end - (char *)any, (int)list->num_classes, &s)) goto out; size += s; } Nptr = ((unsigned char *)list) + rlen; - for (i = 0, nptr = (unsigned char *)any; i < *ndevices; i++) { + for (i = 0, nptr = (unsigned char *)any; i < ndevices; i++) { if (nptr >= Nptr) goto out; size += *nptr + 1; @@ -245,10 +246,10 @@ XListInputDevices( } sclist = clist; Any = (XAnyClassPtr) ((char *)clist + - (*ndevices * sizeof(XDeviceInfo))); + (ndevices * sizeof(XDeviceInfo))); list = slist; any = sav_any; - for (i = 0; i < *ndevices; i++, list++, clist++) { + for (i = 0; i < ndevices; i++, list++, clist++) { clist->type = list->type; clist->id = list->id; clist->use = list->use; @@ -261,7 +262,7 @@ XListInputDevices( clist = sclist; nptr = (unsigned char *)any; Nptr = (unsigned char *)Any; - for (i = 0; i < *ndevices; i++, clist++) { + for (i = 0; i < ndevices; i++, clist++) { clist->name = (char *)Nptr; memcpy(Nptr, nptr + 1, *nptr); Nptr += (*nptr); @@ -270,6 +271,8 @@ XListInputDevices( } } + *ndevices_return = ndevices; + out: XFree((char *)slist); UnlockDisplay(dpy); -- 2.7.4 From michel at daenzer.net Thu Oct 13 09:43:01 2016 From: michel at daenzer.net (=?UTF-8?Q?Michel_D=c3=a4nzer?=) Date: Thu, 13 Oct 2016 18:43:01 +0900 Subject: [xserver PULL for 1.19] Various fixes In-Reply-To: <6161ecd3-0125-d062-56c8-254fe504b572@redhat.com> References: <6161ecd3-0125-d062-56c8-254fe504b572@redhat.com> Message-ID: On 10/10/16 09:19 PM, Hans de Goede wrote: > Hi Adam, Keith, > > Here is a pull-req with 2 prime hw cursor fixes from Michel Dänzer, > reviewed by me and 1 fix from me reviewed by Keith. I pushed my fixes, but I'm leaving your fix to Peter or somebody else. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer From ossman at cendio.se Thu Oct 13 10:48:21 2016 From: ossman at cendio.se (Pierre Ossman) Date: Thu, 13 Oct 2016 12:48:21 +0200 Subject: [PATCH] Handle animated cursor on shared sprite In-Reply-To: References: Message-ID: <1b3b9776-52e0-d35e-6474-2b0bc13e04d8@cendio.se> On 12/10/16 18:05, Emil Velikov wrote: > Note that this changes the ABI so it might not be good for the point > releases. Unless one wants to make things extra 'fun' for binary only > drivers ;-) > Might be a safe ABI change though as it only manipulates elements at the end of the structures, and only things drivers shouldn't access anyway. So it's only an issue if they depend on the size of those structs. Regards -- Pierre Ossman Software Development Cendio AB https://cendio.com Teknikringen 8 https://twitter.com/ThinLinc 583 30 Linköping https://facebook.com/ThinLinc Phone: +46-13-214600 https://plus.google.com/+CendioThinLinc A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? From ossman at cendio.se Thu Oct 13 10:50:48 2016 From: ossman at cendio.se (Pierre Ossman) Date: Thu, 13 Oct 2016 12:50:48 +0200 Subject: [PATCH] Handle animated cursor on shared sprite In-Reply-To: References: Message-ID: <80c3f29b-b126-020d-eb9f-e7e029f7bcf0@cendio.se> > >> + if (!activeDevice) >> + activeDevice = TRUE; > > why the check here ? just set. Historical reasons I guess. This is not code I changed, just re-indented. Regards -- Pierre Ossman Software Development Cendio AB https://cendio.com Teknikringen 8 https://twitter.com/ThinLinc 583 30 Linköping https://facebook.com/ThinLinc Phone: +46-13-214600 https://plus.google.com/+CendioThinLinc A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? From k.mvc at ya.ru Fri Oct 14 00:06:52 2016 From: k.mvc at ya.ru (Mihail Konev) Date: Fri, 14 Oct 2016 00:06:52 +0000 Subject: [PATCH modules v2] autogen: add default patch prefix In-Reply-To: <20161010174519.GE4675@localhost> Message-ID: <20161014000652.GA12465@localhost> Took correct wording from libxtrans. Removed obsolete patches. -------------- next part -------------- A non-text attachment was scrubbed... Name: all.tar.xz Type: application/x-xz Size: 14596 bytes Desc: not available URL: From k.mvc at ya.ru Fri Oct 14 02:40:59 2016 From: k.mvc at ya.ru (Mihail Konev) Date: Fri, 14 Oct 2016 02:40:59 +0000 Subject: [PATCH xserver] xwin: make glx optional again Message-ID: <20161014024033.GA2109@localhost> Commit 501d8e2b removed --enable-aiglx, but made xwin always be --enable-glx. Signed-off-by: Mihail Konev --- configure.ac | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 4bb014d0d837..25168cc67306 100644 --- a/configure.ac +++ b/configure.ac @@ -2233,7 +2233,7 @@ if test "x$XWIN" = xyes; then AC_DEFINE(DDXBEFORERESET, 1, [Use ddxBeforeReset ]) dnl XWin requires OpenGL spec files in order to generate wrapper code for native GL functions - if [test "x$XWIN" = xyes] ; then + if [test "x$XWIN" = xyes && test "x$GLX" = xyes] ; then AC_CHECK_PROG(PYTHON3, python3, python3) if test -z "$PYTHON3"; then AC_MSG_ERROR([python3 not found]) @@ -2256,7 +2256,7 @@ AM_CONDITIONAL(XWIN, [test "x$XWIN" = xyes]) AM_CONDITIONAL(XWIN_MULTIWINDOW, [test "x$XWIN" = xyes]) AM_CONDITIONAL(XWIN_MULTIWINDOWEXTWM, [test "x$XWIN" = xyes && test "x$WINDOWSWM" = xyes]) AM_CONDITIONAL(XWIN_CLIPBOARD, [test "x$XWIN" = xyes]) -AM_CONDITIONAL(XWIN_GLX_WINDOWS, [test "x$XWIN" = xyes]) +AM_CONDITIONAL(XWIN_GLX_WINDOWS, [test "x$XWIN" = xyes && test "x$GLX" = xyes]) AM_CONDITIONAL(XWIN_WINDOWS_DRI, [test "x$XWIN" = xyes && test "x$WINDOWSDRI" = xyes]) AM_CONDITIONAL(XWIN_RANDR, [test "x$XWIN" = xyes]) AM_CONDITIONAL(XWIN_XV, [test "x$XWIN" = xyes && test "x$XV" = xyes]) -- 2.9.2 From peter.hutterer at who-t.net Fri Oct 14 04:38:00 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Fri, 14 Oct 2016 14:38:00 +1000 Subject: [PATCH xserver] inputthread: Re-add fd to the inputThreadInfo->fds pollfd set when re-added In-Reply-To: <20161012145508.4640-1-hdegoede@redhat.com> References: <20161012145508.4640-1-hdegoede@redhat.com> Message-ID: <20161014043800.GA32162@jelly.local> On Wed, Oct 12, 2016 at 04:55:08PM +0200, Hans de Goede wrote: > If the following call sequence happens: > 1) InputThreadUnregisterDev(fd) > 2) close(fd) > 3) fd = open(...) /* returns same fd as just closed */ > 4) InputThreadRegisterDev(fd, ...) > > Without InputThreadDoWork(); running in the mean time, then we would > keep the closed fd in the inputThreadInfo->fds pollfd set, rather then > removing it and adding the new one, causing some devices to not work > after a vt-switch when using xf86-input-evdev. > > BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=97880 > Reported-and-tested-by: Mihail Konev > Signed-off-by: Hans de Goede > --- > os/inputthread.c | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-) > > diff --git a/os/inputthread.c b/os/inputthread.c > index ab1559f..c20c21c 100644 > --- a/os/inputthread.c > +++ b/os/inputthread.c > @@ -49,6 +49,7 @@ Bool InputThreadEnable = TRUE; > > typedef enum _InputDeviceState { > device_state_added, > + device_state_re_added, > device_state_running, > device_state_removed > } InputDeviceState; > @@ -206,8 +207,8 @@ InputThreadRegisterDev(int fd, > if (dev) { > dev->readInputProc = readInputProc; > dev->readInputArgs = readInputArgs; > - /* Override possible unhandled state == device_state_removed */ > - dev->state = device_state_running; > + if (dev->state == device_state_removed) > + dev->state = device_state_re_added; I'm wondering, especially with the other patch in mind: https://patchwork.freedesktop.org/patch/113763/ how about we just treat InputThreadDevice in state device_state_removed as "invisible" to InputThreadRegisterDev, i.e. we don't re-use the struct but allocate a new one. This way we have the old fd automatically removed and the new one added as expected, skipping the need for the device_state_re_added handling. This would be only a one-line change a bit above this hunk - if (old->fd == fd) { + if (old->fd == fd && dev->state != device_state_removed) { The only drawback is that we rely on xorg_list_append() and that the new entry is later than the previous one so we have the same remove/add order as in your device_state_re_added handling below. That needs a comment but other than that we should get the same result? Cheers, Peter > } else { > dev = calloc(1, sizeof(InputThreadDevice)); > if (dev == NULL) { > @@ -344,6 +345,16 @@ InputThreadDoWork(void *arg) > ospoll_listen(inputThreadInfo->fds, dev->fd, X_NOTIFY_READ); > dev->state = device_state_running; > break; > + case device_state_re_added: > + /* Device might use a new fd with the same number */ > + ospoll_remove(inputThreadInfo->fds, dev->fd); > + ospoll_add(inputThreadInfo->fds, dev->fd, > + ospoll_trigger_level, > + InputReady, > + dev); > + ospoll_listen(inputThreadInfo->fds, dev->fd, X_NOTIFY_READ); > + dev->state = device_state_running; > + break; > case device_state_running: > break; > case device_state_removed: > -- > 2.9.3 From peter.hutterer at who-t.net Fri Oct 14 07:13:52 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Fri, 14 Oct 2016 17:13:52 +1000 Subject: [PATCH RFC xf86-input-libinput] Swap the registered input device on DEVICE_OFF when needed In-Reply-To: <20161005133138.9672-1-hdegoede@redhat.com> Message-ID: <20161014071352.GA22436@jelly.local> If we don't swap out the pInfo previously passed to xf86AddEnabledDevice(), the thread eventually calls read_input on a struct that has been deleted. Avoid this by swapping out the to-be-destroyed pInfo with the first one we find. FIXME: incomplete, this doesn't do any driver checking. Signed-off-by: Peter Hutterer --- Hans: I'm not a big fan of copying the fields into our custom InputInfoRec, it makes the inner workings of xf86AddEnabledDevice() and the thread effectively input driver ABI. This one is a slightly nicer (yet incomplete) solution, what do you think? src/xf86libinput.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/src/xf86libinput.c b/src/xf86libinput.c index 69f7ae3..dcd3018 100644 --- a/src/xf86libinput.c +++ b/src/xf86libinput.c @@ -87,6 +87,7 @@ struct xf86libinput_driver { struct libinput *libinput; int device_enabled_count; + void *registered_InputInfoPtr; }; static struct xf86libinput_driver driver_context; @@ -583,6 +584,7 @@ xf86libinput_on(DeviceIntPtr dev) if (driver_context.device_enabled_count == 0) { #if HAVE_THREADED_INPUT xf86AddEnabledDevice(pInfo); + driver_context.registered_InputInfoPtr = pInfo; #else /* Can't use xf86AddEnabledDevice on an epollfd */ AddEnabledDevice(pInfo->fd); @@ -1138,6 +1140,28 @@ xf86libinput_destroy(DeviceIntPtr dev) struct xf86libinput *driver_data = pInfo->private; struct xf86libinput_device *shared_device = driver_data->shared_device; + /* If the device being destroyed is the one we used for + * xf86AddEnabledDevice(), we need to swap it out for one that is + * still live. xf86AddEnabledDevice() buffers some data and once the + * deletes pInfo (when DEVICE_OFF completes) the thread will keep + * calling that struct's read_input because we never removed it. + * Avoid this by removing ours and substituting one that's still + * valid, the fd is the same anyway (libinput's epollfd). + */ + if (pInfo == driver_context.registered_InputInfoPtr && + driver_context.device_enabled_count > 0) { + InputInfoPtr next = xf86FirstLocalDevice(); + while (next == pInfo) + next = pInfo->next; + + input_lock(); + xf86RemoveEnabledDevice(pInfo); + if (next) /* shouldn't ever be NULL anyway */ + xf86AddEnabledDevice(next); + driver_context.registered_InputInfoPtr = next; + input_unlock(); + } + xorg_list_del(&driver_data->shared_device_link); if (driver_data->tablet_tool) -- 2.7.4 From hdegoede at redhat.com Fri Oct 14 08:43:18 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Fri, 14 Oct 2016 10:43:18 +0200 Subject: [PATCH xserver] inputthread: Re-add fd to the inputThreadInfo->fds pollfd set when re-added In-Reply-To: <20161014043800.GA32162@jelly.local> References: <20161012145508.4640-1-hdegoede@redhat.com> <20161014043800.GA32162@jelly.local> Message-ID: <59f288ac-ecd0-78cb-c935-42c8f0f8ae8c@redhat.com> Hi, On 10/14/2016 06:38 AM, Peter Hutterer wrote: > On Wed, Oct 12, 2016 at 04:55:08PM +0200, Hans de Goede wrote: >> If the following call sequence happens: >> 1) InputThreadUnregisterDev(fd) >> 2) close(fd) >> 3) fd = open(...) /* returns same fd as just closed */ >> 4) InputThreadRegisterDev(fd, ...) >> >> Without InputThreadDoWork(); running in the mean time, then we would >> keep the closed fd in the inputThreadInfo->fds pollfd set, rather then >> removing it and adding the new one, causing some devices to not work >> after a vt-switch when using xf86-input-evdev. >> >> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=97880 >> Reported-and-tested-by: Mihail Konev >> Signed-off-by: Hans de Goede >> --- >> os/inputthread.c | 15 +++++++++++++-- >> 1 file changed, 13 insertions(+), 2 deletions(-) >> >> diff --git a/os/inputthread.c b/os/inputthread.c >> index ab1559f..c20c21c 100644 >> --- a/os/inputthread.c >> +++ b/os/inputthread.c >> @@ -49,6 +49,7 @@ Bool InputThreadEnable = TRUE; >> >> typedef enum _InputDeviceState { >> device_state_added, >> + device_state_re_added, >> device_state_running, >> device_state_removed >> } InputDeviceState; >> @@ -206,8 +207,8 @@ InputThreadRegisterDev(int fd, >> if (dev) { >> dev->readInputProc = readInputProc; >> dev->readInputArgs = readInputArgs; >> - /* Override possible unhandled state == device_state_removed */ >> - dev->state = device_state_running; >> + if (dev->state == device_state_removed) >> + dev->state = device_state_re_added; > > I'm wondering, especially with the other patch in mind: > https://patchwork.freedesktop.org/patch/113763/ > > how about we just treat InputThreadDevice in state device_state_removed as > "invisible" to InputThreadRegisterDev, i.e. we don't re-use the struct but > allocate a new one. This way we have the old fd automatically removed and > the new one added as expected, skipping the need for the > device_state_re_added handling. > > This would be only a one-line change a bit above this hunk > - if (old->fd == fd) { > + if (old->fd == fd && dev->state != device_state_removed) { > > The only drawback is that we rely on xorg_list_append() and that the new > entry is later than the previous one so we have the same remove/add order as > in your device_state_re_added handling below. That needs a comment > but other than that we should get the same result? I agree that as long as we can somehow guarantee that the ospoll_remove happens before the ospoll_add that we can then simply fix this by not re-using the struct. Regards, Hans > > Cheers, > Peter > > >> } else { >> dev = calloc(1, sizeof(InputThreadDevice)); >> if (dev == NULL) { >> @@ -344,6 +345,16 @@ InputThreadDoWork(void *arg) >> ospoll_listen(inputThreadInfo->fds, dev->fd, X_NOTIFY_READ); >> dev->state = device_state_running; >> break; >> + case device_state_re_added: >> + /* Device might use a new fd with the same number */ >> + ospoll_remove(inputThreadInfo->fds, dev->fd); >> + ospoll_add(inputThreadInfo->fds, dev->fd, >> + ospoll_trigger_level, >> + InputReady, >> + dev); >> + ospoll_listen(inputThreadInfo->fds, dev->fd, X_NOTIFY_READ); >> + dev->state = device_state_running; >> + break; >> case device_state_running: >> break; >> case device_state_removed: >> -- >> 2.9.3 > _______________________________________________ > xorg-devel at lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel > From hdegoede at redhat.com Fri Oct 14 08:45:57 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Fri, 14 Oct 2016 10:45:57 +0200 Subject: [PATCH RFC xf86-input-libinput] Swap the registered input device on DEVICE_OFF when needed In-Reply-To: <20161014071352.GA22436@jelly.local> References: <20161014071352.GA22436@jelly.local> Message-ID: <2a7ce587-58df-c1c2-b38c-13406ff2326d@redhat.com> Hi, On 10/14/2016 09:13 AM, Peter Hutterer wrote: > If we don't swap out the pInfo previously passed to xf86AddEnabledDevice(), > the thread eventually calls read_input on a struct that has been deleted. > Avoid this by swapping out the to-be-destroyed pInfo with the first one we > find. > > FIXME: incomplete, this doesn't do any driver checking. > > Signed-off-by: Peter Hutterer > --- > Hans: I'm not a big fan of copying the fields into our custom InputInfoRec, > it makes the inner workings of xf86AddEnabledDevice() and the thread > effectively input driver ABI. This one is a slightly nicer (yet incomplete) > solution, what do you think? I think your solution should work. But I like my solution more, as it seems more KISS then yours, but I see your point about it relying on the server side a bit too closely. So I'll make it your call which fix you're going to go with. Regards, Hans > > src/xf86libinput.c | 24 ++++++++++++++++++++++++ > 1 file changed, 24 insertions(+) > > diff --git a/src/xf86libinput.c b/src/xf86libinput.c > index 69f7ae3..dcd3018 100644 > --- a/src/xf86libinput.c > +++ b/src/xf86libinput.c > @@ -87,6 +87,7 @@ > struct xf86libinput_driver { > struct libinput *libinput; > int device_enabled_count; > + void *registered_InputInfoPtr; > }; > > static struct xf86libinput_driver driver_context; > @@ -583,6 +584,7 @@ xf86libinput_on(DeviceIntPtr dev) > if (driver_context.device_enabled_count == 0) { > #if HAVE_THREADED_INPUT > xf86AddEnabledDevice(pInfo); > + driver_context.registered_InputInfoPtr = pInfo; > #else > /* Can't use xf86AddEnabledDevice on an epollfd */ > AddEnabledDevice(pInfo->fd); > @@ -1138,6 +1140,28 @@ xf86libinput_destroy(DeviceIntPtr dev) > struct xf86libinput *driver_data = pInfo->private; > struct xf86libinput_device *shared_device = driver_data->shared_device; > > + /* If the device being destroyed is the one we used for > + * xf86AddEnabledDevice(), we need to swap it out for one that is > + * still live. xf86AddEnabledDevice() buffers some data and once the > + * deletes pInfo (when DEVICE_OFF completes) the thread will keep > + * calling that struct's read_input because we never removed it. > + * Avoid this by removing ours and substituting one that's still > + * valid, the fd is the same anyway (libinput's epollfd). > + */ > + if (pInfo == driver_context.registered_InputInfoPtr && > + driver_context.device_enabled_count > 0) { > + InputInfoPtr next = xf86FirstLocalDevice(); > + while (next == pInfo) > + next = pInfo->next; > + > + input_lock(); > + xf86RemoveEnabledDevice(pInfo); > + if (next) /* shouldn't ever be NULL anyway */ > + xf86AddEnabledDevice(next); > + driver_context.registered_InputInfoPtr = next; > + input_unlock(); > + } > + > xorg_list_del(&driver_data->shared_device_link); > > if (driver_data->tablet_tool) > From emil.l.velikov at gmail.com Fri Oct 14 13:10:15 2016 From: emil.l.velikov at gmail.com (Emil Velikov) Date: Fri, 14 Oct 2016 14:10:15 +0100 Subject: [PATCH xserver] xwin: make glx optional again In-Reply-To: <20161014024033.GA2109@localhost> References: <20161014024033.GA2109@localhost> Message-ID: On 14 October 2016 at 03:40, Mihail Konev wrote: > Commit 501d8e2b removed --enable-aiglx, > but made xwin always be --enable-glx. > This might have been the better idea indeed. Adding Jon just in case ;-) > Signed-off-by: Mihail Konev > --- > configure.ac | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/configure.ac b/configure.ac > index 4bb014d0d837..25168cc67306 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -2233,7 +2233,7 @@ if test "x$XWIN" = xyes; then > AC_DEFINE(DDXBEFORERESET, 1, [Use ddxBeforeReset ]) > > dnl XWin requires OpenGL spec files in order to generate wrapper code for native GL functions Nit: Xwin with GLX requires... > - if [test "x$XWIN" = xyes] ; then > + if [test "x$XWIN" = xyes && test "x$GLX" = xyes] ; then > AC_CHECK_PROG(PYTHON3, python3, python3) > if test -z "$PYTHON3"; then > AC_MSG_ERROR([python3 not found]) > @@ -2256,7 +2256,7 @@ AM_CONDITIONAL(XWIN, [test "x$XWIN" = xyes]) > AM_CONDITIONAL(XWIN_MULTIWINDOW, [test "x$XWIN" = xyes]) > AM_CONDITIONAL(XWIN_MULTIWINDOWEXTWM, [test "x$XWIN" = xyes && test "x$WINDOWSWM" = xyes]) > AM_CONDITIONAL(XWIN_CLIPBOARD, [test "x$XWIN" = xyes]) > -AM_CONDITIONAL(XWIN_GLX_WINDOWS, [test "x$XWIN" = xyes]) > +AM_CONDITIONAL(XWIN_GLX_WINDOWS, [test "x$XWIN" = xyes && test "x$GLX" = xyes]) Regardless of the nitpick Reviewed-by: Emil Velikov -Emil From emil.l.velikov at gmail.com Fri Oct 14 13:12:30 2016 From: emil.l.velikov at gmail.com (Emil Velikov) Date: Fri, 14 Oct 2016 14:12:30 +0100 Subject: [PATCH v2 libXi 1/2] SizeClassInfo can return 0 even without an error In-Reply-To: <1476331103-24072-1-git-send-email-peter.hutterer@who-t.net> References: <1476331103-24072-1-git-send-email-peter.hutterer@who-t.net> Message-ID: On 13 October 2016 at 04:58, Peter Hutterer wrote: > From: Niels Ole Salscheider > > Catch the error case separately. Commit 19a9cd607d added length checking to > SizeClassInfo but re-used the return value of 0 for an error. A device without > classes (as is initialized by xf86-input-libinput for tablets) can > legitimately return 0 and erroneously triggers an error. > Fix this by using a separate value for the error. > > Reproducible by calling XListInputDevices() with a tablet attached. > > This fixes a regression introduced in commit 19a9cd607d. > > Signed-off-by: Niels Ole Salscheider > Signed-off-by: Peter Hutterer > --- > Changes to v1: > - don't touch *size until we're sure. > - expand commit message > A lot better imho. Reviewed-by: Emil Velikov -Emil From jon.turney at dronecode.org.uk Fri Oct 14 13:14:12 2016 From: jon.turney at dronecode.org.uk (Jon Turney) Date: Fri, 14 Oct 2016 14:14:12 +0100 Subject: [PATCH xserver] xwin: make glx optional again In-Reply-To: References: <20161014024033.GA2109@localhost> Message-ID: On 14/10/2016 14:10, Emil Velikov wrote: > On 14 October 2016 at 03:40, Mihail Konev wrote: >> Commit 501d8e2b removed --enable-aiglx, >> but made xwin always be --enable-glx. >> > This might have been the better idea indeed. Adding Jon just in case ;-) Yes, I was kind of wondering where this had gone. I guess this was not quite right before. >> Signed-off-by: Mihail Konev >> --- >> configure.ac | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/configure.ac b/configure.ac >> index 4bb014d0d837..25168cc67306 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -2233,7 +2233,7 @@ if test "x$XWIN" = xyes; then >> AC_DEFINE(DDXBEFORERESET, 1, [Use ddxBeforeReset ]) >> >> dnl XWin requires OpenGL spec files in order to generate wrapper code for native GL functions > Nit: Xwin with GLX requires... > >> - if [test "x$XWIN" = xyes] ; then >> + if [test "x$XWIN" = xyes && test "x$GLX" = xyes] ; then >> AC_CHECK_PROG(PYTHON3, python3, python3) >> if test -z "$PYTHON3"; then >> AC_MSG_ERROR([python3 not found]) >> @@ -2256,7 +2256,7 @@ AM_CONDITIONAL(XWIN, [test "x$XWIN" = xyes]) >> AM_CONDITIONAL(XWIN_MULTIWINDOW, [test "x$XWIN" = xyes]) >> AM_CONDITIONAL(XWIN_MULTIWINDOWEXTWM, [test "x$XWIN" = xyes && test "x$WINDOWSWM" = xyes]) >> AM_CONDITIONAL(XWIN_CLIPBOARD, [test "x$XWIN" = xyes]) >> -AM_CONDITIONAL(XWIN_GLX_WINDOWS, [test "x$XWIN" = xyes]) >> +AM_CONDITIONAL(XWIN_GLX_WINDOWS, [test "x$XWIN" = xyes && test "x$GLX" = xyes]) > > Regardless of the nitpick > Reviewed-by: Emil Velikov Reviewed-by: Jon Turney From emil.l.velikov at gmail.com Fri Oct 14 13:28:55 2016 From: emil.l.velikov at gmail.com (Emil Velikov) Date: Fri, 14 Oct 2016 14:28:55 +0100 Subject: [PATCH v2 libXi 2/2] XListInputDevices: don't touch ndevices in case of error In-Reply-To: <1476331103-24072-2-git-send-email-peter.hutterer@who-t.net> References: <1476331103-24072-1-git-send-email-peter.hutterer@who-t.net> <1476331103-24072-2-git-send-email-peter.hutterer@who-t.net> Message-ID: On 13 October 2016 at 04:58, Peter Hutterer wrote: > We used to always set *ndevices to the number of devices returned by the > server. This magically worked because we pretty much never returned an error > except on faulty server or library implementations. With 19a9cd60 we now have > more chances of getting an error, so the polite thing is to just leave *ndevices > alone when we error out. > > Document it as such in the man page, just in case someone accidentally reads > it. > > Signed-off-by: Peter Hutterer > CC: Niels Ole Salscheider > --- > Changes to v1: > - Niels' first patch set ndevices to 0, this one leaves it untouched > Slightly split between "doing the right thing" and "the cat is out of the bag" ;-) I'm leaning towards the former, although we might want to prod Chromium devs and/or send them a patch ? Reviewed-by: Emil Velikov -Emil From k.mvc at ya.ru Fri Oct 14 15:15:20 2016 From: k.mvc at ya.ru (Mihail Konev) Date: Fri, 14 Oct 2016 15:15:20 +0000 Subject: [PATCH xserver] inputthread: Re-add fd to the inputThreadInfo->fds pollfd set when re-added In-Reply-To: <20161014043800.GA32162@jelly.local> References: <20161012145508.4640-1-hdegoede@redhat.com> <20161014043800.GA32162@jelly.local> Message-ID: <20161014151519.GA25684@localhost> On Fri, Oct 14, 2016 at 02:38:00PM +1000, Peter Hutterer wrote: > > This would be only a one-line change a bit above this hunk > - if (old->fd == fd) { > + if (old->fd == fd && dev->state != device_state_removed) { > > The only drawback is that we rely on xorg_list_append() and that the new > entry is later than the previous one so we have the same remove/add order as > in your device_state_re_added handling below. That needs a comment > but other than that we should get the same result? > > Cheers, > Peter > This works: diff --git a/os/inputthread.c b/os/inputthread.c index 6aa0a9ce6fb5..ddafa7fe8343 100644 --- a/os/inputthread.c +++ b/os/inputthread.c @@ -197,7 +197,7 @@ InputThreadRegisterDev(int fd, dev = NULL; xorg_list_for_each_entry(old, &inputThreadInfo->devs, node) { - if (old->fd == fd) { + if (old->fd == fd && old->state != device_state_removed) { dev = old; break; } @@ -218,6 +218,9 @@ InputThreadRegisterDev(int fd, dev->readInputProc = readInputProc; dev->readInputArgs = readInputArgs; dev->state = device_state_added; + + /* Do not prepend, so that any dev->state == device_state_removed + * with the same dev->fd get processed first. */ xorg_list_append(&dev->node, &inputThreadInfo->devs); } From keithp at keithp.com Fri Oct 14 20:46:47 2016 From: keithp at keithp.com (Keith Packard) Date: Fri, 14 Oct 2016 13:46:47 -0700 Subject: [PATCH xserver] inputthread: Re-add fd to the inputThreadInfo->fds pollfd set when re-added In-Reply-To: <20161014151519.GA25684@localhost> References: <20161012145508.4640-1-hdegoede@redhat.com> <20161014043800.GA32162@jelly.local> <20161014151519.GA25684@localhost> Message-ID: <86shrypsjs.fsf@hiro.keithp.com> Mihail Konev writes: > On Fri, Oct 14, 2016 at 02:38:00PM +1000, Peter Hutterer wrote: >> >> This would be only a one-line change a bit above this hunk >> - if (old->fd == fd) { >> + if (old->fd == fd && dev->state != device_state_removed) { >> >> The only drawback is that we rely on xorg_list_append() and that the new >> entry is later than the previous one so we have the same remove/add order as >> in your device_state_re_added handling below. That needs a comment >> but other than that we should get the same result? >> >> Cheers, >> Peter >> > > This works: > > diff --git a/os/inputthread.c b/os/inputthread.c > index 6aa0a9ce6fb5..ddafa7fe8343 100644 > --- a/os/inputthread.c > +++ b/os/inputthread.c > @@ -197,7 +197,7 @@ InputThreadRegisterDev(int fd, > > dev = NULL; > xorg_list_for_each_entry(old, &inputThreadInfo->devs, node) { > - if (old->fd == fd) { > + if (old->fd == fd && old->state != device_state_removed) { > dev = old; > break; > } > @@ -218,6 +218,9 @@ InputThreadRegisterDev(int fd, > dev->readInputProc = readInputProc; > dev->readInputArgs = readInputArgs; > dev->state = device_state_added; > + > + /* Do not prepend, so that any dev->state == device_state_removed > + * with the same dev->fd get processed first. */ > xorg_list_append(&dev->node, &inputThreadInfo->devs); > } Looks good to me. Reviewed-by: Keith Packard -- -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From k.mvc at ya.ru Sat Oct 15 04:09:12 2016 From: k.mvc at ya.ru (Mihail Konev) Date: Sat, 15 Oct 2016 04:09:12 +0000 Subject: [PATCH v2 xserver] modesetting: fix glamor ifdef In-Reply-To: <20161009231959.GA17082@localhost> References: <20161009231959.GA17082@localhost> Message-ID: <20161015040845.GA13278@localhost> Add a missing ifdef needed for --disable-glamor. Regressed-in: e8695100b17b758359fc4897dbe995231ed224fc Signed-off-by: Mihail Konev --- v2: edit description hw/xfree86/drivers/modesetting/driver.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/xfree86/drivers/modesetting/driver.c b/hw/xfree86/drivers/modesetting/driver.c index 216388f0a36c..3da69a3962a0 100644 --- a/hw/xfree86/drivers/modesetting/driver.c +++ b/hw/xfree86/drivers/modesetting/driver.c @@ -594,6 +594,7 @@ redisplay_dirty(ScreenPtr screen, PixmapDirtyUpdatePtr dirty, int *timeout) PixmapSyncDirtyHelper(dirty); if (!screen->isGPU) { +#ifdef GLAMOR /* * When copying from the master framebuffer to the shared pixmap, * we must ensure the copy is complete before the slave starts a @@ -602,6 +603,7 @@ redisplay_dirty(ScreenPtr screen, PixmapDirtyUpdatePtr dirty, int *timeout) */ if (ms->drmmode.glamor) glamor_finish(screen); +#endif /* Ensure the slave processes the damage immediately */ if (timeout) *timeout = 0; -- 2.9.2 From k.mvc at ya.ru Sat Oct 15 04:13:43 2016 From: k.mvc at ya.ru (Mihail Konev) Date: Sat, 15 Oct 2016 04:13:43 +0000 Subject: [PATCH v3 xserver] modesetting: fix glamor ifdef In-Reply-To: <20161015040845.GA13278@localhost> References: <20161009231959.GA17082@localhost> <20161015040845.GA13278@localhost> Message-ID: <20161015041342.GB13278@localhost> Add a missing ifdef needed for --disable-glamor. Signed-off-by: Mihail Konev --- v2,3: edit description Perhaps Regressed-in shouldn't be there. hw/xfree86/drivers/modesetting/driver.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/xfree86/drivers/modesetting/driver.c b/hw/xfree86/drivers/modesetting/driver.c index 216388f0a36c..3da69a3962a0 100644 --- a/hw/xfree86/drivers/modesetting/driver.c +++ b/hw/xfree86/drivers/modesetting/driver.c @@ -594,6 +594,7 @@ redisplay_dirty(ScreenPtr screen, PixmapDirtyUpdatePtr dirty, int *timeout) PixmapSyncDirtyHelper(dirty); if (!screen->isGPU) { +#ifdef GLAMOR /* * When copying from the master framebuffer to the shared pixmap, * we must ensure the copy is complete before the slave starts a @@ -602,6 +603,7 @@ redisplay_dirty(ScreenPtr screen, PixmapDirtyUpdatePtr dirty, int *timeout) */ if (ms->drmmode.glamor) glamor_finish(screen); +#endif /* Ensure the slave processes the damage immediately */ if (timeout) *timeout = 0; -- 2.9.2 From niels_ole at salscheider-online.de Sat Oct 15 11:48:19 2016 From: niels_ole at salscheider-online.de (Niels Ole Salscheider) Date: Sat, 15 Oct 2016 13:48:19 +0200 Subject: [PATCH libXi v2] SizeClassInfo can return 0 even without an error Message-ID: <20161015114819.31376-1-niels_ole@salscheider-online.de> With this patch we catch the error case separately. Previously, it was not possible to distinguish between a size of 0 and an error. XListInputDevices assumed that a return value of 0 indicates an error and returned an error itself. This caused a crash in any application that uses Chromium since it does not handle the error case properly. v2: Do not set size in case of an error. Signed-off-by: Niels Ole Salscheider --- src/XListDev.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/src/XListDev.c b/src/XListDev.c index f850cd0..b2bad72 100644 --- a/src/XListDev.c +++ b/src/XListDev.c @@ -73,10 +73,10 @@ static int pad_to_xid(int base_size) return ((base_size + padsize - 1)/padsize) * padsize; } -static size_t -SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes) +static int +SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes, size_t *size_out) { - int size = 0; + size_t size = 0; int j; for (j = 0; j < num_classes; j++) { switch ((*any)->class) { @@ -91,7 +91,7 @@ SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes) xValuatorInfoPtr v; if (len < sizeof(v)) - return 0; + return 1; v = (xValuatorInfoPtr) *any; size += pad_to_xid(sizeof(XValuatorInfo) + (v->num_axes * sizeof(XAxisInfo))); @@ -101,11 +101,11 @@ SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes) break; } if ((*any)->length > len) - return 0; + return 1; *any = (xAnyClassPtr) ((char *)(*any) + (*any)->length); } - - return size; + *size_out = size; + return 0; } static void @@ -220,8 +220,7 @@ XListInputDevices( sav_any = any; end = (char *)list + rlen; for (i = 0; i < *ndevices; i++, list++) { - s = SizeClassInfo(&any, end - (char *)any, (int)list->num_classes); - if (!s) + if(SizeClassInfo(&any, end - (char *)any, (int)list->num_classes, &s)) goto out; size += s; } -- 2.10.1 From niels_ole at salscheider-online.de Sat Oct 15 12:06:42 2016 From: niels_ole at salscheider-online.de (Niels Ole Salscheider) Date: Sat, 15 Oct 2016 14:06:42 +0200 Subject: [PATCH libXi] XListInputDevices: Do not modify ndevices in case of an error Message-ID: <20161015120642.3036-1-niels_ole@salscheider-online.de> Output parameters must only be modified if there is no error. Signed-off-by: Niels Ole Salscheider --- src/XListDev.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/src/XListDev.c b/src/XListDev.c index b2bad72..f4e37ba 100644 --- a/src/XListDev.c +++ b/src/XListDev.c @@ -202,8 +202,8 @@ XListInputDevices( return (XDeviceInfo *) NULL; } - if ((*ndevices = rep.ndevices)) { /* at least 1 input device */ - size = *ndevices * sizeof(XDeviceInfo); + if (rep.ndevices) { /* at least 1 input device */ + size = rep.ndevices * sizeof(XDeviceInfo); if (rep.length < (INT_MAX >> 2)) { rlen = rep.length << 2; /* multiply length by 4 */ slist = list = Xmalloc(rlen); @@ -216,17 +216,17 @@ XListInputDevices( } _XRead(dpy, (char *)list, rlen); - any = (xAnyClassPtr) ((char *)list + (*ndevices * sizeof(xDeviceInfo))); + any = (xAnyClassPtr) ((char *)list + (rep.ndevices * sizeof(xDeviceInfo))); sav_any = any; end = (char *)list + rlen; - for (i = 0; i < *ndevices; i++, list++) { + for (i = 0; i < rep.ndevices; i++, list++) { if(SizeClassInfo(&any, end - (char *)any, (int)list->num_classes, &s)) goto out; size += s; } Nptr = ((unsigned char *)list) + rlen; - for (i = 0, nptr = (unsigned char *)any; i < *ndevices; i++) { + for (i = 0, nptr = (unsigned char *)any; i < rep.ndevices; i++) { if (nptr >= Nptr) goto out; size += *nptr + 1; @@ -242,10 +242,10 @@ XListInputDevices( } sclist = clist; Any = (XAnyClassPtr) ((char *)clist + - (*ndevices * sizeof(XDeviceInfo))); + (rep.ndevices * sizeof(XDeviceInfo))); list = slist; any = sav_any; - for (i = 0; i < *ndevices; i++, list++, clist++) { + for (i = 0; i < rep.ndevices; i++, list++, clist++) { clist->type = list->type; clist->id = list->id; clist->use = list->use; @@ -258,7 +258,7 @@ XListInputDevices( clist = sclist; nptr = (unsigned char *)any; Nptr = (unsigned char *)Any; - for (i = 0; i < *ndevices; i++, clist++) { + for (i = 0; i < rep.ndevices; i++, clist++) { clist->name = (char *)Nptr; memcpy(Nptr, nptr + 1, *nptr); Nptr += (*nptr); @@ -266,6 +266,7 @@ XListInputDevices( nptr += (*nptr + 1); } } + *ndevices = rep.ndevices; out: XFree((char *)slist); -- 2.10.1 From k.mvc at ya.ru Sat Oct 15 17:59:05 2016 From: k.mvc at ya.ru (Mihail Konev) Date: Sat, 15 Oct 2016 17:59:05 +0000 Subject: [PATCH xserver] os/inputthread: Ensure pollfd refreshing In-Reply-To: <86shrypsjs.fsf@hiro.keithp.com> References: <20161012145508.4640-1-hdegoede@redhat.com> <20161014043800.GA32162@jelly.local> <20161014151519.GA25684@localhost> <86shrypsjs.fsf@hiro.keithp.com> Message-ID: <20161015175905.GA26748@localhost> When putting a device node into a poll-request list, do not overwrite a "please-remove" element with the same fd, so that a closed device file is ospoll_remove'd prior to being ospoll_add'ed. Before, the opposite order was possible, resulting in ospoll_add considering the newly opened file being already polled, should it have a fd for which the "please-remove" has not been procesed yet. In this case, no further events would be seen from the device. Signed-off-by: Mihail Konev Regressed-in: 52d6a1e832a5e62289dd4f32824ae16a78dfd7e8 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97880 Patchwork: https://patchwork.freedesktop.org/patch/113763/ Hit-and-Reduced-by: Hans de Goede Reviewed-and-Reduced-by: Peter Hutterer --- os/inputthread.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/os/inputthread.c b/os/inputthread.c index 6aa0a9ce6fb5..ddafa7fe8343 100644 --- a/os/inputthread.c +++ b/os/inputthread.c @@ -197,7 +197,7 @@ InputThreadRegisterDev(int fd, dev = NULL; xorg_list_for_each_entry(old, &inputThreadInfo->devs, node) { - if (old->fd == fd) { + if (old->fd == fd && old->state != device_state_removed) { dev = old; break; } @@ -218,6 +218,9 @@ InputThreadRegisterDev(int fd, dev->readInputProc = readInputProc; dev->readInputArgs = readInputArgs; dev->state = device_state_added; + + /* Do not prepend, so that any dev->state == device_state_removed + * with the same dev->fd get processed first. */ xorg_list_append(&dev->node, &inputThreadInfo->devs); } -- 2.9.2 From keithp at keithp.com Sat Oct 15 20:43:37 2016 From: keithp at keithp.com (Keith Packard) Date: Sat, 15 Oct 2016 13:43:37 -0700 Subject: [PATCH xserver] os/inputthread: Ensure pollfd refreshing In-Reply-To: <20161015175905.GA26748@localhost> References: <20161012145508.4640-1-hdegoede@redhat.com> <20161014043800.GA32162@jelly.local> <20161014151519.GA25684@localhost> <86shrypsjs.fsf@hiro.keithp.com> <20161015175905.GA26748@localhost> Message-ID: <86a8e5pcli.fsf@hiro.keithp.com> Mihail Konev writes: > When putting a device node into a poll-request list, do not overwrite a > "please-remove" element with the same fd, so that a closed device file > is ospoll_remove'd prior to being ospoll_add'ed. > > Before, the opposite order was possible, resulting in ospoll_add > considering the newly opened file being already polled, should it have a > fd for which the "please-remove" has not been procesed yet. In this > case, no further events would be seen from the device. > > Signed-off-by: Mihail Konev > Regressed-in: 52d6a1e832a5e62289dd4f32824ae16a78dfd7e8 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97880 > Patchwork: https://patchwork.freedesktop.org/patch/113763/ > Hit-and-Reduced-by: Hans de Goede > Reviewed-and-Reduced-by: Peter Hutterer Merged. 9cf0bd4..5dcb066 master -> master -- -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From peter.hutterer at who-t.net Mon Oct 17 03:20:37 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Mon, 17 Oct 2016 13:20:37 +1000 Subject: [PATCH libXi v2] SizeClassInfo can return 0 even without an error In-Reply-To: <20161015114819.31376-1-niels_ole@salscheider-online.de> References: <20161015114819.31376-1-niels_ole@salscheider-online.de> Message-ID: <20161017032037.GA21562@jelly> On Sat, Oct 15, 2016 at 01:48:19PM +0200, Niels Ole Salscheider wrote: > With this patch we catch the error case separately. Previously, it > was not possible to distinguish between a size of 0 and an error. > XListInputDevices assumed that a return value of 0 indicates an > error and returned an error itself. > > This caused a crash in any application that uses Chromium since it > does not handle the error case properly. > > v2: Do not set size in case of an error. > > Signed-off-by: Niels Ole Salscheider > --- did you see https://patchwork.freedesktop.org/patch/115413/? I'd rather take that one given that it already has a rev-by, I tested it and it's more precise in the commit message. Cheers, Peter > src/XListDev.c | 17 ++++++++--------- > 1 file changed, 8 insertions(+), 9 deletions(-) > > diff --git a/src/XListDev.c b/src/XListDev.c > index f850cd0..b2bad72 100644 > --- a/src/XListDev.c > +++ b/src/XListDev.c > @@ -73,10 +73,10 @@ static int pad_to_xid(int base_size) > return ((base_size + padsize - 1)/padsize) * padsize; > } > > -static size_t > -SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes) > +static int > +SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes, size_t *size_out) > { > - int size = 0; > + size_t size = 0; > int j; > for (j = 0; j < num_classes; j++) { > switch ((*any)->class) { > @@ -91,7 +91,7 @@ SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes) > xValuatorInfoPtr v; > > if (len < sizeof(v)) > - return 0; > + return 1; > v = (xValuatorInfoPtr) *any; > size += pad_to_xid(sizeof(XValuatorInfo) + > (v->num_axes * sizeof(XAxisInfo))); > @@ -101,11 +101,11 @@ SizeClassInfo(xAnyClassPtr *any, size_t len, int num_classes) > break; > } > if ((*any)->length > len) > - return 0; > + return 1; > *any = (xAnyClassPtr) ((char *)(*any) + (*any)->length); > } > - > - return size; > + *size_out = size; > + return 0; > } > > static void > @@ -220,8 +220,7 @@ XListInputDevices( > sav_any = any; > end = (char *)list + rlen; > for (i = 0; i < *ndevices; i++, list++) { > - s = SizeClassInfo(&any, end - (char *)any, (int)list->num_classes); > - if (!s) > + if(SizeClassInfo(&any, end - (char *)any, (int)list->num_classes, &s)) > goto out; > size += s; > } > -- > 2.10.1 > From peter.hutterer at who-t.net Mon Oct 17 03:21:03 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Mon, 17 Oct 2016 13:21:03 +1000 Subject: [PATCH libXi] XListInputDevices: Do not modify ndevices in case of an error In-Reply-To: <20161015120642.3036-1-niels_ole@salscheider-online.de> References: <20161015120642.3036-1-niels_ole@salscheider-online.de> Message-ID: <20161017032103.GB21562@jelly> On Sat, Oct 15, 2016 at 02:06:42PM +0200, Niels Ole Salscheider wrote: > Output parameters must only be modified if there is no error. > > Signed-off-by: Niels Ole Salscheider see this patch here please https://patchwork.freedesktop.org/patch/115414/ Cheers, Peter > --- > src/XListDev.c | 17 +++++++++-------- > 1 file changed, 9 insertions(+), 8 deletions(-) > > diff --git a/src/XListDev.c b/src/XListDev.c > index b2bad72..f4e37ba 100644 > --- a/src/XListDev.c > +++ b/src/XListDev.c > @@ -202,8 +202,8 @@ XListInputDevices( > return (XDeviceInfo *) NULL; > } > > - if ((*ndevices = rep.ndevices)) { /* at least 1 input device */ > - size = *ndevices * sizeof(XDeviceInfo); > + if (rep.ndevices) { /* at least 1 input device */ > + size = rep.ndevices * sizeof(XDeviceInfo); > if (rep.length < (INT_MAX >> 2)) { > rlen = rep.length << 2; /* multiply length by 4 */ > slist = list = Xmalloc(rlen); > @@ -216,17 +216,17 @@ XListInputDevices( > } > _XRead(dpy, (char *)list, rlen); > > - any = (xAnyClassPtr) ((char *)list + (*ndevices * sizeof(xDeviceInfo))); > + any = (xAnyClassPtr) ((char *)list + (rep.ndevices * sizeof(xDeviceInfo))); > sav_any = any; > end = (char *)list + rlen; > - for (i = 0; i < *ndevices; i++, list++) { > + for (i = 0; i < rep.ndevices; i++, list++) { > if(SizeClassInfo(&any, end - (char *)any, (int)list->num_classes, &s)) > goto out; > size += s; > } > > Nptr = ((unsigned char *)list) + rlen; > - for (i = 0, nptr = (unsigned char *)any; i < *ndevices; i++) { > + for (i = 0, nptr = (unsigned char *)any; i < rep.ndevices; i++) { > if (nptr >= Nptr) > goto out; > size += *nptr + 1; > @@ -242,10 +242,10 @@ XListInputDevices( > } > sclist = clist; > Any = (XAnyClassPtr) ((char *)clist + > - (*ndevices * sizeof(XDeviceInfo))); > + (rep.ndevices * sizeof(XDeviceInfo))); > list = slist; > any = sav_any; > - for (i = 0; i < *ndevices; i++, list++, clist++) { > + for (i = 0; i < rep.ndevices; i++, list++, clist++) { > clist->type = list->type; > clist->id = list->id; > clist->use = list->use; > @@ -258,7 +258,7 @@ XListInputDevices( > clist = sclist; > nptr = (unsigned char *)any; > Nptr = (unsigned char *)Any; > - for (i = 0; i < *ndevices; i++, clist++) { > + for (i = 0; i < rep.ndevices; i++, clist++) { > clist->name = (char *)Nptr; > memcpy(Nptr, nptr + 1, *nptr); > Nptr += (*nptr); > @@ -266,6 +266,7 @@ XListInputDevices( > nptr += (*nptr + 1); > } > } > + *ndevices = rep.ndevices; > > out: > XFree((char *)slist); > -- > 2.10.1 > From peter.hutterer at who-t.net Mon Oct 17 05:43:42 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Mon, 17 Oct 2016 15:43:42 +1000 Subject: [PATCH v2 libXi 2/2] XListInputDevices: don't touch ndevices in case of error In-Reply-To: References: <1476331103-24072-1-git-send-email-peter.hutterer@who-t.net> <1476331103-24072-2-git-send-email-peter.hutterer@who-t.net> Message-ID: <20161017054342.GA23354@jelly.local> On Fri, Oct 14, 2016 at 02:28:55PM +0100, Emil Velikov wrote: > On 13 October 2016 at 04:58, Peter Hutterer wrote: > > We used to always set *ndevices to the number of devices returned by the > > server. This magically worked because we pretty much never returned an error > > except on faulty server or library implementations. With 19a9cd60 we now have > > more chances of getting an error, so the polite thing is to just leave *ndevices > > alone when we error out. > > > > Document it as such in the man page, just in case someone accidentally reads > > it. > > > > Signed-off-by: Peter Hutterer > > CC: Niels Ole Salscheider > > --- > > Changes to v1: > > - Niels' first patch set ndevices to 0, this one leaves it untouched > > > Slightly split between "doing the right thing" and "the cat is out of > the bag" ;-) I don't think the cat is out of the bag anyway here. ndevices was *always* wrong in case of error. either it was untouched or set to the list of devices even though NULL was returned. the only reason this worked is because we never had an error. the cat remains thus firmly packaged, if (as usual) in an unclear state of vividness. > I'm leaning towards the former, although we might want to prod > Chromium devs and/or send them a patch ? the chromium code is broken, it cannot handle *any* error case. on the first call, the devices list is NULL and count is 0. XListInputDevices is fails, we currently get a NULL list but a count of != 0. Which will then crash when looping through the list and dereferencing the nonexistent members. At least with this fix, count stays on 0 and while XListInputDevices will get called every time, everything else should simply skip over any loop over the devices then (since count remains at 0). anyway, I just tried to file a bug, but "You need a Google Account associated with your email address in order to use the bug system." so there goes that idea. so now I'm just CC-ing the three most recent @chromium.org addresses from xorg-devel and cross my fingers and hope :) Cheers, Peter From drinkcat at chromium.org Mon Oct 17 06:14:18 2016 From: drinkcat at chromium.org (Nicolas Boichat) Date: Mon, 17 Oct 2016 14:14:18 +0800 Subject: [PATCH v2 libXi 2/2] XListInputDevices: don't touch ndevices in case of error In-Reply-To: <20161017054342.GA23354@jelly.local> References: <1476331103-24072-1-git-send-email-peter.hutterer@who-t.net> <1476331103-24072-2-git-send-email-peter.hutterer@who-t.net> <20161017054342.GA23354@jelly.local> Message-ID: +sadrul On Mon, Oct 17, 2016 at 1:43 PM, Peter Hutterer wrote: > On Fri, Oct 14, 2016 at 02:28:55PM +0100, Emil Velikov wrote: >> On 13 October 2016 at 04:58, Peter Hutterer wrote: >> > We used to always set *ndevices to the number of devices returned by the >> > server. This magically worked because we pretty much never returned an error >> > except on faulty server or library implementations. With 19a9cd60 we now have >> > more chances of getting an error, so the polite thing is to just leave *ndevices >> > alone when we error out. >> > >> > Document it as such in the man page, just in case someone accidentally reads >> > it. >> > >> > Signed-off-by: Peter Hutterer >> > CC: Niels Ole Salscheider >> > --- >> > Changes to v1: >> > - Niels' first patch set ndevices to 0, this one leaves it untouched >> > >> Slightly split between "doing the right thing" and "the cat is out of >> the bag" ;-) > > I don't think the cat is out of the bag anyway here. ndevices was *always* > wrong in case of error. either it was untouched or set to the list of > devices even though NULL was returned. the only reason this worked is > because we never had an error. the cat remains thus firmly packaged, if (as > usual) in an unclear state of vividness. > >> I'm leaning towards the former, although we might want to prod >> Chromium devs and/or send them a patch ? > > the chromium code is broken, it cannot handle *any* error case. on the first > call, the devices list is NULL and count is 0. XListInputDevices is > fails, we currently get a NULL list but a count of != 0. Which > will then crash when looping through the list and dereferencing the > nonexistent members. At least with this fix, count stays on 0 and while > XListInputDevices will get called every time, everything else > should simply skip over any loop over the devices then (since count remains > at 0). > > anyway, I just tried to file a bug, but "You need a Google Account > associated with your email address in order to use the bug system." so there > goes that idea. so now I'm just CC-ing the three most recent @chromium.org > addresses from xorg-devel and cross my fingers and hope :) Filed https://bugs.chromium.org/p/chromium/issues/detail?id=656506, thanks for reporting! Best, Nicolas From michel at daenzer.net Mon Oct 17 09:48:44 2016 From: michel at daenzer.net (=?UTF-8?q?Michel=20D=C3=A4nzer?=) Date: Mon, 17 Oct 2016 18:48:44 +0900 Subject: [PATCH xserver] DRI2: Sync radeonsi_pci_ids.h from Mesa Message-ID: <20161017094844.11464-1-michel@daenzer.net> From: Michel Dänzer Fixes DRI2 client driver name mapping for newer AMD GPUs with the modesetting driver, allowing the DRI2 extension to initialize. Signed-off-by: Michel Dänzer --- hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h index 4df8e9d..20c1583 100644 --- a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h +++ b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h @@ -184,12 +184,24 @@ CHIPSET(0x7300, FIJI_, FIJI) CHIPSET(0x67E0, POLARIS11_, POLARIS11) CHIPSET(0x67E1, POLARIS11_, POLARIS11) +CHIPSET(0x67E3, POLARIS11_, POLARIS11) +CHIPSET(0x67E7, POLARIS11_, POLARIS11) CHIPSET(0x67E8, POLARIS11_, POLARIS11) CHIPSET(0x67E9, POLARIS11_, POLARIS11) CHIPSET(0x67EB, POLARIS11_, POLARIS11) +CHIPSET(0x67EF, POLARIS11_, POLARIS11) CHIPSET(0x67FF, POLARIS11_, POLARIS11) CHIPSET(0x67C0, POLARIS10_, POLARIS10) +CHIPSET(0x67C1, POLARIS10_, POLARIS10) +CHIPSET(0x67C2, POLARIS10_, POLARIS10) +CHIPSET(0x67C4, POLARIS10_, POLARIS10) +CHIPSET(0x67C7, POLARIS10_, POLARIS10) +CHIPSET(0x67C8, POLARIS10_, POLARIS10) +CHIPSET(0x67C9, POLARIS10_, POLARIS10) +CHIPSET(0x67CA, POLARIS10_, POLARIS10) +CHIPSET(0x67CC, POLARIS10_, POLARIS10) +CHIPSET(0x67CF, POLARIS10_, POLARIS10) CHIPSET(0x67DF, POLARIS10_, POLARIS10) CHIPSET(0x98E4, STONEY_, STONEY) -- 2.9.3 From alexdeucher at gmail.com Mon Oct 17 14:24:16 2016 From: alexdeucher at gmail.com (Alex Deucher) Date: Mon, 17 Oct 2016 10:24:16 -0400 Subject: [PATCH xserver] DRI2: Sync radeonsi_pci_ids.h from Mesa In-Reply-To: <20161017094844.11464-1-michel@daenzer.net> References: <20161017094844.11464-1-michel@daenzer.net> Message-ID: On Mon, Oct 17, 2016 at 5:48 AM, Michel Dänzer wrote: > From: Michel Dänzer > > Fixes DRI2 client driver name mapping for newer AMD GPUs with the > modesetting driver, allowing the DRI2 extension to initialize. > > Signed-off-by: Michel Dänzer Reviewed-by: Alex Deucher > --- > hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h > index 4df8e9d..20c1583 100644 > --- a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h > +++ b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h > @@ -184,12 +184,24 @@ CHIPSET(0x7300, FIJI_, FIJI) > > CHIPSET(0x67E0, POLARIS11_, POLARIS11) > CHIPSET(0x67E1, POLARIS11_, POLARIS11) > +CHIPSET(0x67E3, POLARIS11_, POLARIS11) > +CHIPSET(0x67E7, POLARIS11_, POLARIS11) > CHIPSET(0x67E8, POLARIS11_, POLARIS11) > CHIPSET(0x67E9, POLARIS11_, POLARIS11) > CHIPSET(0x67EB, POLARIS11_, POLARIS11) > +CHIPSET(0x67EF, POLARIS11_, POLARIS11) > CHIPSET(0x67FF, POLARIS11_, POLARIS11) > > CHIPSET(0x67C0, POLARIS10_, POLARIS10) > +CHIPSET(0x67C1, POLARIS10_, POLARIS10) > +CHIPSET(0x67C2, POLARIS10_, POLARIS10) > +CHIPSET(0x67C4, POLARIS10_, POLARIS10) > +CHIPSET(0x67C7, POLARIS10_, POLARIS10) > +CHIPSET(0x67C8, POLARIS10_, POLARIS10) > +CHIPSET(0x67C9, POLARIS10_, POLARIS10) > +CHIPSET(0x67CA, POLARIS10_, POLARIS10) > +CHIPSET(0x67CC, POLARIS10_, POLARIS10) > +CHIPSET(0x67CF, POLARIS10_, POLARIS10) > CHIPSET(0x67DF, POLARIS10_, POLARIS10) > > CHIPSET(0x98E4, STONEY_, STONEY) > -- > 2.9.3 > > _______________________________________________ > xorg-devel at lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel From k.mvc at ya.ru Mon Oct 17 20:01:27 2016 From: k.mvc at ya.ru (Mihail Konev) Date: Mon, 17 Oct 2016 20:01:27 +0000 Subject: [PATCH 1/2] Compose: add ruble currency In-Reply-To: <1476200095-28039-1-git-send-email-coyote@bks.tv> Message-ID: <20161017200127.GA4835@localhost> From: Victor Kustov Signed-off-by: Victor Kustov Reviewed-by: Mihail Konev --- nls/en_US.UTF-8/Compose.pre | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre index adc24fb5b5c2..041ae0f663a0 100644 --- a/nls/en_US.UTF-8/Compose.pre +++ b/nls/en_US.UTF-8/Compose.pre @@ -190,6 +190,10 @@ XCOMM "₪" U20aa NEW SHEQEL SIGN : "€" EuroSign # EURO SIGN : "€" EuroSign # EURO SIGN : "€" EuroSign # EURO SIGN +

: "₽" U20bd # RUBLE-CURRENCY SIGN +

: "₽" U20bd # RUBLE-CURRENCY SIGN +

: "₽" U20bd # RUBLE-CURRENCY SIGN +

: "₽" U20bd # RUBLE-CURRENCY SIGN XCOMM "₭" U20ad KIP SIGN XCOMM "₮" U20ae TUGRIK SIGN XCOMM "₯" U20af DRACHMA SIGN -- 2.9.2 From k.mvc at ya.ru Mon Oct 17 20:02:22 2016 From: k.mvc at ya.ru (Mihail Konev) Date: Mon, 17 Oct 2016 20:02:22 +0000 Subject: [PATCH 2/2] Compose: cyrillic ruble sequence In-Reply-To: <20161017200127.GA4835@localhost> References: <1476200095-28039-1-git-send-email-coyote@bks.tv> <20161017200127.GA4835@localhost> Message-ID: <20161017200222.GB4835@localhost> Signed-off-by: Mihail Konev --- nls/en_US.UTF-8/Compose.pre | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre index 041ae0f663a0..2c23928a6f2e 100644 --- a/nls/en_US.UTF-8/Compose.pre +++ b/nls/en_US.UTF-8/Compose.pre @@ -194,6 +194,10 @@ XCOMM "₪" U20aa NEW SHEQEL SIGN

: "₽" U20bd # RUBLE-CURRENCY SIGN

: "₽" U20bd # RUBLE-CURRENCY SIGN

: "₽" U20bd # RUBLE-CURRENCY SIGN + : "₽" U20bd # RUBLE SIGN + : "₽" U20bd # RUBLE SIGN + : "₽" U20bd # RUBLE SIGN + : "₽" U20bd # RUBLE SIGN XCOMM "₭" U20ad KIP SIGN XCOMM "₮" U20ae TUGRIK SIGN XCOMM "₯" U20af DRACHMA SIGN -- 2.9.2 From k.mvc at ya.ru Mon Oct 17 20:25:10 2016 From: k.mvc at ya.ru (Mihail Konev) Date: Mon, 17 Oct 2016 20:25:10 +0000 Subject: [PATCH v2] Compose: add rouble currency In-Reply-To: <20161017200222.GB4835@localhost> References: <1476200095-28039-1-git-send-email-coyote@bks.tv> <20161017200127.GA4835@localhost> <20161017200222.GB4835@localhost> Message-ID: <20161017202510.GC4835@localhost> v2: fix spelling, commit message, and line order. Sorry for flood. >From ae1bf2fbd2c3893366198a80aed8743af656ee88 Mon Sep 17 00:00:00 2001 From: Victor Kustov Date: Mon, 17 Oct 2016 19:44:36 +0000 Subject: [PATCH 1/2] Compose: add rouble currency sequence Signed-off-by: Victor Kustov Reviewed-by: Mihail Konev --- nls/en_US.UTF-8/Compose.pre | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre index adc24fb5b5c2..d7dc74140989 100644 --- a/nls/en_US.UTF-8/Compose.pre +++ b/nls/en_US.UTF-8/Compose.pre @@ -190,6 +190,10 @@ XCOMM "₪" U20aa NEW SHEQEL SIGN : "€" EuroSign # EURO SIGN : "€" EuroSign # EURO SIGN : "€" EuroSign # EURO SIGN +

: "₽" U20bd # ROUBLE SIGN +

: "₽" U20bd # ROUBLE SIGN +

: "₽" U20bd # ROUBLE SIGN +

: "₽" U20bd # ROUBLE SIGN XCOMM "₭" U20ad KIP SIGN XCOMM "₮" U20ae TUGRIK SIGN XCOMM "₯" U20af DRACHMA SIGN -- 2.9.2 >From 88e2d4489be56bfb828cf18c56629ef1b9c1f415 Mon Sep 17 00:00:00 2001 From: Mihail Konev Date: Mon, 17 Oct 2016 20:17:31 +0000 Subject: [PATCH 2/2] Compose: cyrillic rouble sequence Signed-off-by: Mihail Konev --- nls/en_US.UTF-8/Compose.pre | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre index d7dc74140989..a25d40446162 100644 --- a/nls/en_US.UTF-8/Compose.pre +++ b/nls/en_US.UTF-8/Compose.pre @@ -194,6 +194,10 @@ XCOMM "₪" U20aa NEW SHEQEL SIGN

: "₽" U20bd # ROUBLE SIGN

: "₽" U20bd # ROUBLE SIGN

: "₽" U20bd # ROUBLE SIGN + : "₽" U20bd # ROUBLE SIGN + : "₽" U20bd # ROUBLE SIGN + : "₽" U20bd # ROUBLE SIGN + : "₽" U20bd # ROUBLE SIGN XCOMM "₭" U20ad KIP SIGN XCOMM "₮" U20ae TUGRIK SIGN XCOMM "₯" U20af DRACHMA SIGN -- 2.9.2 From peter.hutterer at who-t.net Tue Oct 18 01:36:00 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Tue, 18 Oct 2016 11:36:00 +1000 Subject: [PATCH:xserver] Use pthread_setname_np to set thread names if available In-Reply-To: <1473567259-19868-1-git-send-email-alan.coopersmith@oracle.com> References: <1473567259-19868-1-git-send-email-alan.coopersmith@oracle.com> Message-ID: <20161018013600.GA11419@jelly.local> On Sat, Sep 10, 2016 at 09:14:19PM -0700, Alan Coopersmith wrote: > Autoconf logic borrowed from glib > > Signed-off-by: Alan Coopersmith > --- > configure.ac | 20 ++++++++++++++++++++ > include/dix-config.h.in | 6 ++++++ > os/inputthread.c | 12 ++++++++++++ > 3 files changed, 38 insertions(+) > > I have only tested this on Solaris, not MacOS or Linux, but since the > similar code in glib works on both, hope this will too. [...] > diff --git a/os/inputthread.c b/os/inputthread.c > index 1cd1c2a..2ea39e7 100644 > --- a/os/inputthread.c > +++ b/os/inputthread.c > @@ -310,6 +310,12 @@ InputThreadDoWork(void *arg) > > inputThreadInfo->running = TRUE; > > +#if defined(HAVE_PTHREAD_SETNAME_NP_WITH_TID) > + pthread_setname_np (pthread_self(), "InputThread"); > +#elif defined(HAVE_PTHREAD_SETNAME_NP_WITHOUT_TID) > + pthread_setname_np ("InputThread"); > +#endif > + > ospoll_add(inputThreadInfo->fds, hotplugPipeRead, > ospoll_trigger_level, > InputThreadPipeNotify, > @@ -411,6 +417,12 @@ InputThreadPreInit(void) > fcntl(hotplugPipeRead, F_SETFL, O_NONBLOCK | O_CLOEXEC); > hotplugPipeWrite = hotplugPipe[1]; > > +#if defined(HAVE_PTHREAD_SETNAME_NP_WITH_TID) > + pthread_setname_np (pthread_self(), "MainThread"); > +#elif defined(HAVE_PTHREAD_SETNAME_NP_WITHOUT_TID) > + pthread_setname_np ("MainThread"); > +#endif > + this broke a few scripts here, e.g. ps -C Xorg won't work anymore because the program name is now MainThread. I understand why we'd want to label the input thread but do we get any benefit out of labelling the main thread? Cheers, Peter From peter.hutterer at who-t.net Tue Oct 18 01:47:07 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Tue, 18 Oct 2016 11:47:07 +1000 Subject: [PATCH xf86-input-libinput] Swap the registered input device on DEVICE_OFF when needed In-Reply-To: <2a7ce587-58df-c1c2-b38c-13406ff2326d@redhat.com> Message-ID: <20161018014707.GA8494@jelly.local> If we don't swap out the pInfo previously passed to xf86AddEnabledDevice(), the thread eventually calls read_input on a struct that has been deleted. Avoid this by swapping out the to-be-destroyed pInfo with the first one we find. Reproducer: sudo udevadm trigger --type=devices --action=add Signed-off-by: Peter Hutterer --- Changes to the RFC: - checking for the driver now src/xf86libinput.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/src/xf86libinput.c b/src/xf86libinput.c index 69f7ae3..061e495 100644 --- a/src/xf86libinput.c +++ b/src/xf86libinput.c @@ -87,6 +87,7 @@ struct xf86libinput_driver { struct libinput *libinput; int device_enabled_count; + void *registered_InputInfoPtr; }; static struct xf86libinput_driver driver_context; @@ -583,6 +584,7 @@ xf86libinput_on(DeviceIntPtr dev) if (driver_context.device_enabled_count == 0) { #if HAVE_THREADED_INPUT xf86AddEnabledDevice(pInfo); + driver_context.registered_InputInfoPtr = pInfo; #else /* Can't use xf86AddEnabledDevice on an epollfd */ AddEnabledDevice(pInfo->fd); @@ -1131,6 +1133,39 @@ xf86libinput_init(DeviceIntPtr dev) return 0; } +static bool +is_libinput_device(InputInfoPtr pInfo) +{ + char *driver; + BOOL rc; + + driver = xf86CheckStrOption(pInfo->options, "driver", ""); + rc = strcmp(driver, "libinput") == 0; + free(driver); + + return rc; +} + +static void +swap_registered_device(InputInfoPtr pInfo) +{ + InputInfoPtr next; + + if (pInfo != driver_context.registered_InputInfoPtr) + return; + + next = xf86FirstLocalDevice(); + while (next == pInfo || !is_libinput_device(next)) + next = next->next; + + input_lock(); + xf86RemoveEnabledDevice(pInfo); + if (next) /* shouldn't ever be NULL anyway */ + xf86AddEnabledDevice(next); + driver_context.registered_InputInfoPtr = next; + input_unlock(); +} + static void xf86libinput_destroy(DeviceIntPtr dev) { @@ -1138,6 +1173,17 @@ xf86libinput_destroy(DeviceIntPtr dev) struct xf86libinput *driver_data = pInfo->private; struct xf86libinput_device *shared_device = driver_data->shared_device; + /* If the device being destroyed is the one we used for + * xf86AddEnabledDevice(), we need to swap it out for one that is + * still live. xf86AddEnabledDevice() buffers some data and once the + * deletes pInfo (when DEVICE_OFF completes) the thread will keep + * calling that struct's read_input because we never removed it. + * Avoid this by removing ours and substituting one that's still + * valid, the fd is the same anyway (libinput's epollfd). + */ + if (driver_context.device_enabled_count > 0) + swap_registered_device(pInfo); + xorg_list_del(&driver_data->shared_device_link); if (driver_data->tablet_tool) -- 2.7.4 From alan.coopersmith at oracle.com Tue Oct 18 01:48:45 2016 From: alan.coopersmith at oracle.com (Alan Coopersmith) Date: Mon, 17 Oct 2016 18:48:45 -0700 Subject: [PATCH:xserver] Use pthread_setname_np to set thread names if available In-Reply-To: <20161018013600.GA11419@jelly.local> References: <1473567259-19868-1-git-send-email-alan.coopersmith@oracle.com> <20161018013600.GA11419@jelly.local> Message-ID: On 10/17/16 06:36 PM, Peter Hutterer wrote: > On Sat, Sep 10, 2016 at 09:14:19PM -0700, Alan Coopersmith wrote: >> I have only tested this on Solaris, not MacOS or Linux, but since the >> similar code in glib works on both, hope this will too. > > > this broke a few scripts here, e.g. ps -C Xorg won't work anymore because > the program name is now MainThread. I understand why we'd want to label the > input thread but do we get any benefit out of labelling the main thread? Oh, I didn't know it would do that on Linux - Solaris still shows the process name for the process, and the thread names only when looking at the threads. I just figured it was handy when libraries spawn their own threads, so we could tell the difference between our thread and theirs, but if it's causing problems, I don't think it's useful enough to force the issue and am okay seeing the main thread name dropped. -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc From jeremyhu at apple.com Tue Oct 18 01:58:00 2016 From: jeremyhu at apple.com (Jeremy Sequoia) Date: Mon, 17 Oct 2016 18:58:00 -0700 Subject: [PATCH:xserver] Use pthread_setname_np to set thread names if available In-Reply-To: References: <1473567259-19868-1-git-send-email-alan.coopersmith@oracle.com> <20161018013600.GA11419@jelly.local> Message-ID: <4E8535DB-6550-48B0-B658-F0045B56A3D0@apple.com> Sent from my iPhone... > On Oct 17, 2016, at 18:48, Alan Coopersmith wrote: > >> On 10/17/16 06:36 PM, Peter Hutterer wrote: >>> On Sat, Sep 10, 2016 at 09:14:19PM -0700, Alan Coopersmith wrote: >>> I have only tested this on Solaris, not MacOS or Linux, but since the >>> similar code in glib works on both, hope this will too. >> >> >> this broke a few scripts here, e.g. ps -C Xorg won't work anymore because >> the program name is now MainThread. I understand why we'd want to label the >> input thread but do we get any benefit out of labelling the main thread? > > Oh, I didn't know it would do that on Linux - Solaris still shows the process > name for the process, and the thread names only when looking at the threads. On macOS, this also just changes the name of the thread, not the process. IMO, it seems wrong that it would have such an effect on Linux. > I just figured it was handy when libraries spawn their own threads, so we could > tell the difference between our thread and theirs, but if it's causing problems, > I don't think it's useful enough to force the issue and am okay seeing the main > thread name dropped. > > -- > -Alan Coopersmith- alan.coopersmith at oracle.com > Oracle Solaris Engineering - http://blogs.oracle.com/alanc From peter.hutterer at who-t.net Tue Oct 18 04:13:47 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Tue, 18 Oct 2016 14:13:47 +1000 Subject: [PATCH xserver] inputthread: leave the main thread's name as-is In-Reply-To: <4E8535DB-6550-48B0-B658-F0045B56A3D0@apple.com> Message-ID: <20161018041347.GA21823@jelly.local> On Linux, setting the main thread's name changes the program name (/proc/self/comm). Setting it to MainThread breaks scripts that rely on the command name, e.g. ps -C Xorg. Signed-off-by: Peter Hutterer --- os/inputthread.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/os/inputthread.c b/os/inputthread.c index 4980502..65247b4 100644 --- a/os/inputthread.c +++ b/os/inputthread.c @@ -433,12 +433,6 @@ InputThreadPreInit(void) } hotplugPipeWrite = hotplugPipe[1]; -#if defined(HAVE_PTHREAD_SETNAME_NP_WITH_TID) - pthread_setname_np (pthread_self(), "MainThread"); -#elif defined(HAVE_PTHREAD_SETNAME_NP_WITHOUT_TID) - pthread_setname_np ("MainThread"); -#endif - } /** -- 2.7.4 From jeremyhu at apple.com Tue Oct 18 07:13:52 2016 From: jeremyhu at apple.com (Jeremy Huddleston Sequoia) Date: Tue, 18 Oct 2016 00:13:52 -0700 Subject: [PATCH xserver] inputthread: leave the main thread's name as-is In-Reply-To: <20161018041347.GA21823@jelly.local> References: <20161018041347.GA21823@jelly.local> Message-ID: Shouldn't glibc be fixed instead? Why punish the platforms that do it right? --Jeremy > On Oct 17, 2016, at 21:13, Peter Hutterer wrote: > > On Linux, setting the main thread's name changes the program name > (/proc/self/comm). Setting it to MainThread breaks scripts that rely on > the command name, e.g. ps -C Xorg. > > Signed-off-by: Peter Hutterer > --- > os/inputthread.c | 6 ------ > 1 file changed, 6 deletions(-) > > diff --git a/os/inputthread.c b/os/inputthread.c > index 4980502..65247b4 100644 > --- a/os/inputthread.c > +++ b/os/inputthread.c > @@ -433,12 +433,6 @@ InputThreadPreInit(void) > } > hotplugPipeWrite = hotplugPipe[1]; > > -#if defined(HAVE_PTHREAD_SETNAME_NP_WITH_TID) > - pthread_setname_np (pthread_self(), "MainThread"); > -#elif defined(HAVE_PTHREAD_SETNAME_NP_WITHOUT_TID) > - pthread_setname_np ("MainThread"); > -#endif > - > } > > /** > -- > 2.7.4 > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4465 bytes Desc: not available URL: From uli42 at gmx.de Tue Oct 18 07:33:00 2016 From: uli42 at gmx.de (Ulrich Sibiller) Date: Tue, 18 Oct 2016 09:33:00 +0200 Subject: [PATCH libX11 3/4] Fixes: warning: variable 'req' set but not, used In-Reply-To: <5752F19F.4070405@bfs.de> References: <5752F19F.4070405@bfs.de> Message-ID: On Sat, Jun 4, 2016 at 5:19 PM, walter harms wrote: > Fixes: warning: variable 'req' set but not used [-Wunused-but-set-variable] > by marking req _X_UNUSED > Solution was discussed on xorg-devel ML > Peter Hutter, Alan Coopersmith > Re: [PATCH libX11 3/5] fix: warning: pointer targets in passing argument 2 of '_XSend' differ in signedness [-Wpointer-sign] Hello, I see a lot unapplied stuff on patchwork, so is there any plan to clear the backlog? I am specially interested in the patch series by Walter Harms mentioned above. Thanks, Uli From hdegoede at redhat.com Tue Oct 18 10:14:50 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Tue, 18 Oct 2016 12:14:50 +0200 Subject: [PATCH xf86-input-libinput] Swap the registered input device on DEVICE_OFF when needed In-Reply-To: <20161018014707.GA8494@jelly.local> References: <20161018014707.GA8494@jelly.local> Message-ID: Hi, On 18-10-16 03:47, Peter Hutterer wrote: > If we don't swap out the pInfo previously passed to xf86AddEnabledDevice(), > the thread eventually calls read_input on a struct that has been deleted. > Avoid this by swapping out the to-be-destroyed pInfo with the first one we > find. > > Reproducer: sudo udevadm trigger --type=devices --action=add > > Signed-off-by: Peter Hutterer Patch looks good to me: Reviewed-by: Hans de Goede Regards, Hans > --- > Changes to the RFC: > - checking for the driver now > > src/xf86libinput.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 46 insertions(+) > > diff --git a/src/xf86libinput.c b/src/xf86libinput.c > index 69f7ae3..061e495 100644 > --- a/src/xf86libinput.c > +++ b/src/xf86libinput.c > @@ -87,6 +87,7 @@ > struct xf86libinput_driver { > struct libinput *libinput; > int device_enabled_count; > + void *registered_InputInfoPtr; > }; > > static struct xf86libinput_driver driver_context; > @@ -583,6 +584,7 @@ xf86libinput_on(DeviceIntPtr dev) > if (driver_context.device_enabled_count == 0) { > #if HAVE_THREADED_INPUT > xf86AddEnabledDevice(pInfo); > + driver_context.registered_InputInfoPtr = pInfo; > #else > /* Can't use xf86AddEnabledDevice on an epollfd */ > AddEnabledDevice(pInfo->fd); > @@ -1131,6 +1133,39 @@ xf86libinput_init(DeviceIntPtr dev) > return 0; > } > > +static bool > +is_libinput_device(InputInfoPtr pInfo) > +{ > + char *driver; > + BOOL rc; > + > + driver = xf86CheckStrOption(pInfo->options, "driver", ""); > + rc = strcmp(driver, "libinput") == 0; > + free(driver); > + > + return rc; > +} > + > +static void > +swap_registered_device(InputInfoPtr pInfo) > +{ > + InputInfoPtr next; > + > + if (pInfo != driver_context.registered_InputInfoPtr) > + return; > + > + next = xf86FirstLocalDevice(); > + while (next == pInfo || !is_libinput_device(next)) > + next = next->next; > + > + input_lock(); > + xf86RemoveEnabledDevice(pInfo); > + if (next) /* shouldn't ever be NULL anyway */ > + xf86AddEnabledDevice(next); > + driver_context.registered_InputInfoPtr = next; > + input_unlock(); > +} > + > static void > xf86libinput_destroy(DeviceIntPtr dev) > { > @@ -1138,6 +1173,17 @@ xf86libinput_destroy(DeviceIntPtr dev) > struct xf86libinput *driver_data = pInfo->private; > struct xf86libinput_device *shared_device = driver_data->shared_device; > > + /* If the device being destroyed is the one we used for > + * xf86AddEnabledDevice(), we need to swap it out for one that is > + * still live. xf86AddEnabledDevice() buffers some data and once the > + * deletes pInfo (when DEVICE_OFF completes) the thread will keep > + * calling that struct's read_input because we never removed it. > + * Avoid this by removing ours and substituting one that's still > + * valid, the fd is the same anyway (libinput's epollfd). > + */ > + if (driver_context.device_enabled_count > 0) > + swap_registered_device(pInfo); > + > xorg_list_del(&driver_data->shared_device_link); > > if (driver_data->tablet_tool) > From jon.turney at dronecode.org.uk Tue Oct 18 12:23:22 2016 From: jon.turney at dronecode.org.uk (Jon Turney) Date: Tue, 18 Oct 2016 13:23:22 +0100 Subject: [PATCH v3 xserver] modesetting: fix glamor ifdef In-Reply-To: <20161015041342.GB13278@localhost> References: <20161009231959.GA17082@localhost> <20161015040845.GA13278@localhost> <20161015041342.GB13278@localhost> Message-ID: <9782dbc5-45eb-b586-fed2-ce8e35b05f2a@dronecode.org.uk> On 15/10/2016 05:13, Mihail Konev wrote: > Add a missing ifdef needed for --disable-glamor. > > Signed-off-by: Mihail Konev Reviewed-by: Jon Turney From hdegoede at redhat.com Tue Oct 18 14:36:32 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Tue, 18 Oct 2016 16:36:32 +0200 Subject: [PATCH] xfree86: Xorg.wrap: Do not require root rights for cards with 0 outputs Message-ID: <20161018143632.17793-1-hdegoede@redhat.com> Prior to this commit the Xorg.wrap code to detect if root rights are necessary checked for DRM_IOCTL_MODE_GETRESOURCES succeeding *and* reporting more then 0 output connectors. DRM_IOCTL_MODE_GETRESOURCES succeeding alone is enough to differentiate between old drm only cards (which need ums and thus root) and kms capable cards. Some hybrid gfx laptops have 0 output connectors on one of their 2 GPUs, resulting in Xorg needlessly running as root. This commits removes the res.count_connectors > 0 check, fixing this. Signed-off-by: Hans de Goede --- hw/xfree86/xorg-wrapper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/xfree86/xorg-wrapper.c b/hw/xfree86/xorg-wrapper.c index d930962..a25e6ff 100644 --- a/hw/xfree86/xorg-wrapper.c +++ b/hw/xfree86/xorg-wrapper.c @@ -240,7 +240,7 @@ int main(int argc, char *argv[]) memset(&res, 0, sizeof(struct drm_mode_card_res)); r = ioctl(fd, DRM_IOCTL_MODE_GETRESOURCES, &res); - if (r == 0 && res.count_connectors > 0) + if (r == 0) kms_cards++; close(fd); -- 2.9.3 From hdegoede at redhat.com Tue Oct 18 14:48:40 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Tue, 18 Oct 2016 16:48:40 +0200 Subject: [PATCH xf86-video-amdgpu] amdgpu_probe: Do not close server managed drm fds Message-ID: <20161018144840.7163-1-hdegoede@redhat.com> This fixes the xserver only seeing AMD/ATI devices supported by the amdgpu driver, as by the time xf86-video-ati gets a chance to probe them, the fd has been closed. This fixes e.g. Xorg not seeing the dGPU on a Lenovo Thinkpad E465 laptop with a CARRIZO iGPU and a HAINAN dGPU. Signed-off-by: Hans de Goede --- src/amdgpu_probe.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/src/amdgpu_probe.c b/src/amdgpu_probe.c index 213d245..5d17fe5 100644 --- a/src/amdgpu_probe.c +++ b/src/amdgpu_probe.c @@ -142,6 +142,15 @@ static int amdgpu_kernel_open_fd(ScrnInfoPtr pScrn, char *busid, return fd; } +static void amdgpu_kernel_close_fd(AMDGPUEntPtr pAMDGPUEnt) +{ +#ifdef XF86_PDEV_SERVER_FD + if (!(pAMDGPUEnt->platform_dev && + pAMDGPUEnt->platform_dev->flags & XF86_PDEV_SERVER_FD)) +#endif + drmClose(pAMDGPUEnt->fd); +} + static Bool amdgpu_open_drm_master(ScrnInfoPtr pScrn, AMDGPUEntPtr pAMDGPUEnt, char *busid) { @@ -164,7 +173,7 @@ static Bool amdgpu_open_drm_master(ScrnInfoPtr pScrn, AMDGPUEntPtr pAMDGPUEnt, if (err != 0) { xf86DrvMsg(pScrn->scrnIndex, X_ERROR, "[drm] failed to set drm interface version.\n"); - drmClose(pAMDGPUEnt->fd); + amdgpu_kernel_close_fd(pAMDGPUEnt); return FALSE; } @@ -252,7 +261,7 @@ static Bool amdgpu_get_scrninfo(int entity_num, struct pci_device *pci_dev) return TRUE; error_amdgpu: - drmClose(pAMDGPUEnt->fd); + amdgpu_kernel_close_fd(pAMDGPUEnt); error_fd: free(pPriv->ptr); error: @@ -347,6 +356,7 @@ amdgpu_platform_probe(DriverPtr pDriver, pPriv->ptr = xnfcalloc(sizeof(AMDGPUEntRec), 1); pAMDGPUEnt = pPriv->ptr; + pAMDGPUEnt->platform_dev = dev; pAMDGPUEnt->fd = amdgpu_kernel_open_fd(pScrn, busid, dev); if (pAMDGPUEnt->fd < 0) goto error_fd; @@ -365,7 +375,6 @@ amdgpu_platform_probe(DriverPtr pDriver, pAMDGPUEnt = pPriv->ptr; pAMDGPUEnt->fd_ref++; } - pAMDGPUEnt->platform_dev = dev; xf86SetEntityInstanceForScreen(pScrn, pEnt->index, xf86GetNumEntityInstances(pEnt-> @@ -377,7 +386,7 @@ amdgpu_platform_probe(DriverPtr pDriver, return TRUE; error_amdgpu: - drmClose(pAMDGPUEnt->fd); + amdgpu_kernel_close_fd(pAMDGPUEnt); error_fd: free(pPriv->ptr); error: -- 2.9.3 From eric.engestrom at imgtec.com Tue Oct 18 15:20:22 2016 From: eric.engestrom at imgtec.com (Eric Engestrom) Date: Tue, 18 Oct 2016 16:20:22 +0100 Subject: [PATCH] xfree86: Xorg.wrap: Do not require root rights for cards with 0 outputs In-Reply-To: <20161018143632.17793-1-hdegoede@redhat.com> References: <20161018143632.17793-1-hdegoede@redhat.com> Message-ID: <20161018152022.GH3759@imgtec.com> On Tuesday, 2016-10-18 16:36:32 +0200, Hans de Goede wrote: > Prior to this commit the Xorg.wrap code to detect if root rights > are necessary checked for DRM_IOCTL_MODE_GETRESOURCES succeeding *and* > reporting more then 0 output connectors. > > DRM_IOCTL_MODE_GETRESOURCES succeeding alone is enough to differentiate > between old drm only cards (which need ums and thus root) and kms capable > cards. > > Some hybrid gfx laptops have 0 output connectors on one of their 2 GPUs, > resulting in Xorg needlessly running as root. This commits removes the > res.count_connectors > 0 check, fixing this. > > Signed-off-by: Hans de Goede Reviewed-by: Eric Engestrom > --- > hw/xfree86/xorg-wrapper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/xfree86/xorg-wrapper.c b/hw/xfree86/xorg-wrapper.c > index d930962..a25e6ff 100644 > --- a/hw/xfree86/xorg-wrapper.c > +++ b/hw/xfree86/xorg-wrapper.c > @@ -240,7 +240,7 @@ int main(int argc, char *argv[]) > > memset(&res, 0, sizeof(struct drm_mode_card_res)); > r = ioctl(fd, DRM_IOCTL_MODE_GETRESOURCES, &res); > - if (r == 0 && res.count_connectors > 0) > + if (r == 0) > kms_cards++; > > close(fd); > -- > 2.9.3 From ajax at redhat.com Tue Oct 18 15:31:06 2016 From: ajax at redhat.com (Adam Jackson) Date: Tue, 18 Oct 2016 11:31:06 -0400 Subject: [PATCH xserver] glamor: Isolate GLX client code to its own library Message-ID: <20161018153106.3093-1-ajax@redhat.com> This is a step towards making libglamor_egl and Xwayland not link against libGL (which brings in client-side libraries, which is just icky). Signed-off-by: Adam Jackson --- glamor/Makefile.am | 13 +++++++++++-- glamor/glamor_glx_stubs.c | 37 +++++++++++++++++++++++++++++++++++++ hw/kdrive/ephyr/Makefile.am | 1 + hw/xwayland/Makefile.am | 3 ++- 4 files changed, 51 insertions(+), 3 deletions(-) create mode 100644 glamor/glamor_glx_stubs.c diff --git a/glamor/Makefile.am b/glamor/Makefile.am index 8c79994..fd52e30 100644 --- a/glamor/Makefile.am +++ b/glamor/Makefile.am @@ -1,4 +1,8 @@ -noinst_LTLIBRARIES = libglamor.la libglamor_egl_stubs.la +noinst_LTLIBRARIES = \ + libglamor.la \ + libglamor_egl_stubs.la \ + libglamor_glx.la \ + libglamor_glx_stubs.la libglamor_la_LIBADD = $(GLAMOR_LIBS) @@ -13,7 +17,6 @@ libglamor_la_SOURCES = \ glamor_debug.h \ glamor_font.c \ glamor_font.h \ - glamor_glx.c \ glamor_composite_glyphs.c \ glamor_image.c \ glamor_lines.c \ @@ -58,4 +61,10 @@ libglamor_egl_stubs_la_SOURCES = \ glamor_egl_stubs.c \ glamor_egl.h +libglamor_glx_la_SOURCES = \ + glamor_glx.c + +libglamor_glx_stubs_la_SOURCES = \ + glamor_glx_stubs.c + sdk_HEADERS = glamor.h diff --git a/glamor/glamor_glx_stubs.c b/glamor/glamor_glx_stubs.c new file mode 100644 index 0000000..7f29386 --- /dev/null +++ b/glamor/glamor_glx_stubs.c @@ -0,0 +1,37 @@ +/* + * Copyright © 2013 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + */ + +#include +#include "glamor_context.h" + +static void +glamor_glx_make_current(struct glamor_context *glamor_ctx) +{ +} + + +Bool +glamor_glx_screen_init(struct glamor_context *glamor_ctx) +{ + return False; +} diff --git a/hw/kdrive/ephyr/Makefile.am b/hw/kdrive/ephyr/Makefile.am index 6ce0d6f..f988271 100644 --- a/hw/kdrive/ephyr/Makefile.am +++ b/hw/kdrive/ephyr/Makefile.am @@ -66,6 +66,7 @@ if GLAMOR AM_CPPFLAGS += $(XLIB_CFLAGS) XEPHYR_GLAMOR_LIB = \ $(top_builddir)/glamor/libglamor.la \ + $(top_builddir)/glamor/libglamor_glx.la \ $(top_builddir)/glamor/libglamor_egl_stubs.la \ $() endif diff --git a/hw/xwayland/Makefile.am b/hw/xwayland/Makefile.am index a3c9fce..fdb825a 100644 --- a/hw/xwayland/Makefile.am +++ b/hw/xwayland/Makefile.am @@ -46,7 +46,8 @@ glamor_built_sources = \ Xwayland_built_sources += $(glamor_built_sources) -glamor_lib = $(top_builddir)/glamor/libglamor.la +glamor_lib = $(top_builddir)/glamor/libglamor.la \ + $(top_builddir)/glamor/libglamor_glx_stubs.la Xwayland_LDADD += $(GLAMOR_LIBS) $(GBM_LIBS) -lEGL -lGL Xwayland_DEPENDENCIES = $(glamor_lib) $(XWAYLAND_LIBS) -- 2.9.3 From eric at anholt.net Tue Oct 18 16:46:53 2016 From: eric at anholt.net (Eric Anholt) Date: Tue, 18 Oct 2016 09:46:53 -0700 Subject: [PATCH xserver] glamor: Isolate GLX client code to its own library In-Reply-To: <20161018153106.3093-1-ajax@redhat.com> References: <20161018153106.3093-1-ajax@redhat.com> Message-ID: <878ttl7gg2.fsf@eliezer.anholt.net> Adam Jackson writes: > This is a step towards making libglamor_egl and Xwayland not link > against libGL (which brings in client-side libraries, which is just > icky). Is it actually necessary? Given that the epoxy GLX symbols always exist, and we're linking against epoxy, it seems like we could just drop our -lGL. libglamor_egl should pretty clearly not be linking to libGL, though, so I'm in favor of following where this leads. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From peter.hutterer at who-t.net Wed Oct 19 00:15:50 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Wed, 19 Oct 2016 10:15:50 +1000 Subject: [PATCH libX11 3/4] Fixes: warning: variable 'req' set but not,used In-Reply-To: <5752F19F.4070405@bfs.de> References: <5752F19F.4070405@bfs.de> Message-ID: <20161019001550.GA11354@jelly.local> On Sat, Jun 04, 2016 at 05:19:59PM +0200, walter harms wrote: > Fixes: warning: variable 'req' set but not used [-Wunused-but-set-variable] > by marking req _X_UNUSED > Solution was discussed on xorg-devel ML > Peter Hutter, Alan Coopersmith > Re: [PATCH libX11 3/5] fix: warning: pointer targets in passing argument 2 of '_XSend' differ in signedness [-Wpointer-sign] > > Signed-off-by: harms wharms at bfs.de just saw that float past. please use the standard s-o-b that everyone else uses (as added by git commit -s). that goes for the series. Cheers, Peter > > --- > src/GetFPath.c | 2 +- > src/GetIFocus.c | 2 +- > src/GetKCnt.c | 2 +- > src/GetPCnt.c | 2 +- > src/GetPntMap.c | 2 +- > src/GetSSaver.c | 2 +- > src/GrServer.c | 2 +- > src/LiHosts.c | 2 +- > src/ListExt.c | 2 +- > src/Macros.c | 2 +- > src/ModMap.c | 4 ++-- > src/QuKeybd.c | 2 +- > src/ReconfWM.c | 2 +- > src/Sync.c | 2 +- > src/UngrabSvr.c | 2 +- > src/XlibInt.c | 2 +- > src/xcms/cmsCmap.c | 2 +- > 17 files changed, 18 insertions(+), 18 deletions(-) > > diff --git a/src/GetFPath.c b/src/GetFPath.c > index 8c3f49c..3d87e4f 100644 > --- a/src/GetFPath.c > +++ b/src/GetFPath.c > @@ -42,7 +42,7 @@ char **XGetFontPath( > int count = 0; > register unsigned i; > register int length; > - register xReq *req; > + _X_UNUSED register xReq *req; > > LockDisplay(dpy); > GetEmptyReq (GetFontPath, req); > diff --git a/src/GetIFocus.c b/src/GetIFocus.c > index 5d43ead..0a7f36e 100644 > --- a/src/GetIFocus.c > +++ b/src/GetIFocus.c > @@ -36,7 +36,7 @@ XGetInputFocus( > int *revert_to) > { > xGetInputFocusReply rep; > - register xReq *req; > + _X_UNUSED register xReq *req; > LockDisplay(dpy); > GetEmptyReq(GetInputFocus, req); > (void) _XReply (dpy, (xReply *)&rep, 0, xTrue); > diff --git a/src/GetKCnt.c b/src/GetKCnt.c > index 17f487f..5829fbe 100644 > --- a/src/GetKCnt.c > +++ b/src/GetKCnt.c > @@ -35,7 +35,7 @@ XGetKeyboardControl ( > register XKeyboardState *state) > { > xGetKeyboardControlReply rep; > - register xReq *req; > + _X_UNUSED register xReq *req; > LockDisplay(dpy); > GetEmptyReq (GetKeyboardControl, req); > (void) _XReply (dpy, (xReply *) &rep, > diff --git a/src/GetPCnt.c b/src/GetPCnt.c > index 2c35d21..72d9495 100644 > --- a/src/GetPCnt.c > +++ b/src/GetPCnt.c > @@ -38,7 +38,7 @@ XGetPointerControl( > int *threshold) > { > xGetPointerControlReply rep; > - xReq *req; > + _X_UNUSED xReq *req; > LockDisplay(dpy); > GetEmptyReq(GetPointerControl, req); > (void) _XReply (dpy, (xReply *)&rep, 0, xTrue); > diff --git a/src/GetPntMap.c b/src/GetPntMap.c > index 29fdf21..07625f8 100644 > --- a/src/GetPntMap.c > +++ b/src/GetPntMap.c > @@ -45,7 +45,7 @@ int XGetPointerMapping ( > unsigned char mapping[256]; /* known fixed size */ > unsigned long nbytes, remainder = 0; > xGetPointerMappingReply rep; > - register xReq *req; > + _X_UNUSED register xReq *req; > > LockDisplay(dpy); > GetEmptyReq(GetPointerMapping, req); > diff --git a/src/GetSSaver.c b/src/GetSSaver.c > index 1aba3bb..7c2a306 100644 > --- a/src/GetSSaver.c > +++ b/src/GetSSaver.c > @@ -40,7 +40,7 @@ XGetScreenSaver( > > { > xGetScreenSaverReply rep; > - register xReq *req; > + _X_UNUSED register xReq *req; > LockDisplay(dpy); > GetEmptyReq(GetScreenSaver, req); > > diff --git a/src/GrServer.c b/src/GrServer.c > index 11d21e4..c4c62be 100644 > --- a/src/GrServer.c > +++ b/src/GrServer.c > @@ -32,7 +32,7 @@ in this Software without prior written authorization from The Open Group. > int > XGrabServer (register Display *dpy) > { > - register xReq *req; > + _X_UNUSED register xReq *req; > LockDisplay(dpy); > GetEmptyReq(GrabServer, req); > UnlockDisplay(dpy); > diff --git a/src/LiHosts.c b/src/LiHosts.c > index 83cf3c7..29c36ff 100644 > --- a/src/LiHosts.c > +++ b/src/LiHosts.c > @@ -77,7 +77,7 @@ XHostAddress *XListHosts ( > xListHostsReply reply; > unsigned char *buf, *bp; > register unsigned i; > - register xListHostsReq *req; > + _X_UNUSED register xListHostsReq *req; > XServerInterpretedAddress *sip; > > *nhosts = 0; > diff --git a/src/ListExt.c b/src/ListExt.c > index be6b989..b6677e9 100644 > --- a/src/ListExt.c > +++ b/src/ListExt.c > @@ -41,7 +41,7 @@ char **XListExtensions( > int count = 0; > register unsigned i; > register int length; > - register xReq *req; > + _X_UNUSED register xReq *req; > unsigned long rlen = 0; > > LockDisplay(dpy); > diff --git a/src/Macros.c b/src/Macros.c > index 394a764..dcd0380 100644 > --- a/src/Macros.c > +++ b/src/Macros.c > @@ -283,7 +283,7 @@ int XAddPixel( > int > XNoOp (register Display *dpy) > { > - register xReq *req; > + _X_UNUSED register xReq *req; > > LockDisplay(dpy); > GetEmptyReq(NoOperation, req); > diff --git a/src/ModMap.c b/src/ModMap.c > index 4263a8b..eae9736 100644 > --- a/src/ModMap.c > +++ b/src/ModMap.c > @@ -34,12 +34,12 @@ XModifierKeymap * > XGetModifierMapping(register Display *dpy) > { > xGetModifierMappingReply rep; > - register xReq *req; > + _X_UNUSED register xReq *req; > unsigned long nbytes; > XModifierKeymap *res; > > LockDisplay(dpy); > - GetEmptyReq(GetModifierMapping, req); // Never used ? > + GetEmptyReq(GetModifierMapping, req); > (void) _XReply (dpy, (xReply *)&rep, 0, xFalse); > > if (rep.length < (INT_MAX >> 2)) { > diff --git a/src/QuKeybd.c b/src/QuKeybd.c > index 4b8431d..0a2d4d0 100644 > --- a/src/QuKeybd.c > +++ b/src/QuKeybd.c > @@ -39,7 +39,7 @@ XQueryKeymap( > char keys[32]) > { > xQueryKeymapReply rep; > - register xReq *req; > + _X_UNUSED register xReq *req; > > LockDisplay(dpy); > GetEmptyReq(QueryKeymap, req); > diff --git a/src/ReconfWM.c b/src/ReconfWM.c > index 8dc3534..b3d8624 100644 > --- a/src/ReconfWM.c > +++ b/src/ReconfWM.c > @@ -105,7 +105,7 @@ Status XReconfigureWMWindow ( > */ > { > xGetInputFocusReply rep; > - register xReq *req; > + _X_UNUSED register xReq *req; > > GetEmptyReq(GetInputFocus, req); > (void) _XReply (dpy, (xReply *)&rep, 0, xTrue); > diff --git a/src/Sync.c b/src/Sync.c > index 6326de7..bc768d4 100644 > --- a/src/Sync.c > +++ b/src/Sync.c > @@ -37,7 +37,7 @@ XSync ( > Bool discard) > { > xGetInputFocusReply rep; > - register xReq *req; > + _X_UNUSED register xReq *req; > > LockDisplay(dpy); > GetEmptyReq(GetInputFocus, req); > diff --git a/src/UngrabSvr.c b/src/UngrabSvr.c > index ea00848..20ad9aa 100644 > --- a/src/UngrabSvr.c > +++ b/src/UngrabSvr.c > @@ -33,7 +33,7 @@ int > XUngrabServer ( > register Display *dpy) > { > - register xReq *req; > + _X_UNUSED register xReq *req; > > LockDisplay(dpy); > GetEmptyReq(UngrabServer, req); > diff --git a/src/XlibInt.c b/src/XlibInt.c > index 86ae1d9..78d4e5e 100644 > --- a/src/XlibInt.c > +++ b/src/XlibInt.c > @@ -196,7 +196,7 @@ void _XSeqSyncFunction( > register Display *dpy) > { > xGetInputFocusReply rep; > - register xReq *req; > + _X_UNUSED register xReq *req; > > if ((X_DPY_GET_REQUEST(dpy) - X_DPY_GET_LAST_REQUEST_READ(dpy)) >= (65535 - BUFSIZE/SIZEOF(xReq))) { > GetEmptyReq(GetInputFocus, req); > diff --git a/src/xcms/cmsCmap.c b/src/xcms/cmsCmap.c > index c5401c0..c7087ec 100644 > --- a/src/xcms/cmsCmap.c > +++ b/src/xcms/cmsCmap.c > @@ -181,7 +181,7 @@ CmapRecForColormap( > } > { > xGetInputFocusReply rep; > - register xReq *req; > + _X_UNUSED register xReq *req; > > GetEmptyReq(GetInputFocus, req); > (void) _XReply (dpy, (xReply *)&rep, 0, xTrue); > -- > 2.1.4 > > _______________________________________________ > xorg-devel at lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel > From michel at daenzer.net Wed Oct 19 02:42:32 2016 From: michel at daenzer.net (=?UTF-8?Q?Michel_D=c3=a4nzer?=) Date: Wed, 19 Oct 2016 11:42:32 +0900 Subject: [PATCH xf86-video-amdgpu] amdgpu_probe: Do not close server managed drm fds In-Reply-To: <20161018144840.7163-1-hdegoede@redhat.com> References: <20161018144840.7163-1-hdegoede@redhat.com> Message-ID: <2bc76f11-bb9e-8411-35ee-c76d535d933e@daenzer.net> [ Moving to the amd-gfx mailing list, where xf86-video-amdgpu (and -ati) patches are reviewed ] On 18/10/16 11:48 PM, Hans de Goede wrote: > This fixes the xserver only seeing AMD/ATI devices supported by the amdgpu > driver, as by the time xf86-video-ati gets a chance to probe them, the > fd has been closed. That basically makes sense, but I have one question: Why does amdgpu get probed in the first place in that case? I was under the impression that this should only happen for GPUs bound to the amdgpu kernel driver, due to Section "OutputClass" in /usr/share/X11/xorg.conf.d/10-amdgpu.conf . > diff --git a/src/amdgpu_probe.c b/src/amdgpu_probe.c > index 213d245..5d17fe5 100644 > --- a/src/amdgpu_probe.c > +++ b/src/amdgpu_probe.c > @@ -142,6 +142,15 @@ static int amdgpu_kernel_open_fd(ScrnInfoPtr pScrn, char *busid, > return fd; > } > > +static void amdgpu_kernel_close_fd(AMDGPUEntPtr pAMDGPUEnt) > +{ > +#ifdef XF86_PDEV_SERVER_FD > + if (!(pAMDGPUEnt->platform_dev && > + pAMDGPUEnt->platform_dev->flags & XF86_PDEV_SERVER_FD)) > +#endif > + drmClose(pAMDGPUEnt->fd); > +} AMDGPUFreeRec could also be refactored to call this function. > @@ -164,7 +173,7 @@ static Bool amdgpu_open_drm_master(ScrnInfoPtr pScrn, AMDGPUEntPtr pAMDGPUEnt, > if (err != 0) { > xf86DrvMsg(pScrn->scrnIndex, X_ERROR, > "[drm] failed to set drm interface version.\n"); > - drmClose(pAMDGPUEnt->fd); > + amdgpu_kernel_close_fd(pAMDGPUEnt); > return FALSE; > } > @@ -252,7 +261,7 @@ static Bool amdgpu_get_scrninfo(int entity_num, struct pci_device *pci_dev) > return TRUE; > > error_amdgpu: > - drmClose(pAMDGPUEnt->fd); > + amdgpu_kernel_close_fd(pAMDGPUEnt); > error_fd: > free(pPriv->ptr); > error: These two hunks aren't really necessary, right? These only get called from amdgpu_pci_probe, in which case pAMDGPUEnt->platform_dev remains NULL. > @@ -347,6 +356,7 @@ amdgpu_platform_probe(DriverPtr pDriver, > > pPriv->ptr = xnfcalloc(sizeof(AMDGPUEntRec), 1); > pAMDGPUEnt = pPriv->ptr; > + pAMDGPUEnt->platform_dev = dev; > pAMDGPUEnt->fd = amdgpu_kernel_open_fd(pScrn, busid, dev); > if (pAMDGPUEnt->fd < 0) > goto error_fd; > @@ -365,7 +375,6 @@ amdgpu_platform_probe(DriverPtr pDriver, > pAMDGPUEnt = pPriv->ptr; > pAMDGPUEnt->fd_ref++; > } > - pAMDGPUEnt->platform_dev = dev; > > xf86SetEntityInstanceForScreen(pScrn, pEnt->index, > xf86GetNumEntityInstances(pEnt-> These two hunks aren't really necessary either, are they? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer From au1064 at gmail.com Wed Oct 19 13:52:56 2016 From: au1064 at gmail.com (Jens Harms) Date: Wed, 19 Oct 2016 15:52:56 +0200 Subject: calibrate touchscreen Message-ID: Hi. I try to calibrate a resisitive Touchscreen. The touchscreen is a bit rotatated (3-5 degree), therefore i can not use xinput_calibrator. I try to understand how the the evdev driver works. Do i need to set "Evdev Axis Calibration" and "Coordinate Transformation Matrix" ? Or is it sufficent to set the CTM alone? How are Touch coordinates calculated? Which transformations are applied to the raw data? Regards, jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.hutterer at who-t.net Thu Oct 20 02:47:11 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Thu, 20 Oct 2016 12:47:11 +1000 Subject: [PATCH xserver] inputthread: leave the main thread's name as-is In-Reply-To: References: <20161018041347.GA21823@jelly.local> Message-ID: <20161020024711.GA10943@jelly> On Tue, Oct 18, 2016 at 12:13:52AM -0700, Jeremy Huddleston Sequoia wrote: > Shouldn't glibc be fixed instead? Why punish the platforms that do it right? at this point I'm not sure yet whether it's glibc or the kernel but I'm betting on the latter. meanwhile, fixing this would be nice so we don't release a version where this is broken. I can #ifdef this for linux if need be. Cheers, Peter > > On Oct 17, 2016, at 21:13, Peter Hutterer wrote: > > > > On Linux, setting the main thread's name changes the program name > > (/proc/self/comm). Setting it to MainThread breaks scripts that rely on > > the command name, e.g. ps -C Xorg. > > > > Signed-off-by: Peter Hutterer > > --- > > os/inputthread.c | 6 ------ > > 1 file changed, 6 deletions(-) > > > > diff --git a/os/inputthread.c b/os/inputthread.c > > index 4980502..65247b4 100644 > > --- a/os/inputthread.c > > +++ b/os/inputthread.c > > @@ -433,12 +433,6 @@ InputThreadPreInit(void) > > } > > hotplugPipeWrite = hotplugPipe[1]; > > > > -#if defined(HAVE_PTHREAD_SETNAME_NP_WITH_TID) > > - pthread_setname_np (pthread_self(), "MainThread"); > > -#elif defined(HAVE_PTHREAD_SETNAME_NP_WITHOUT_TID) > > - pthread_setname_np ("MainThread"); > > -#endif > > - > > } > > > > /** > > -- > > 2.7.4 > > > From peter.hutterer at who-t.net Thu Oct 20 05:52:19 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Thu, 20 Oct 2016 15:52:19 +1000 Subject: calibrate touchscreen In-Reply-To: References: Message-ID: <20161020055219.GA21958@jelly> On Wed, Oct 19, 2016 at 03:52:56PM +0200, Jens Harms wrote: > Hi. I try to calibrate a resisitive Touchscreen. > The touchscreen is a bit rotatated (3-5 degree), therefore i can not use > xinput_calibrator. I try to understand how the the evdev driver works. > > Do i need to set "Evdev Axis Calibration" and "Coordinate Transformation > Matrix" ? Or is it sufficent to set the CTM alone? don't use the axis calibration, use the matrix only. > How are Touch coordinates calculated? Which transformations are applied to > the raw data? the matrix is a basic transformation matrix, so you can use your normal rotational elements, etc. The values are normalized to [0, 1] where 1 represents "total width" or "total height". https://wiki.archlinux.org/index.php/Calibrating_Touchscreen https://wiki.ubuntu.com/X/InputCoordinateTransformation Cheers, Peter From martin.peres at linux.intel.com Thu Oct 20 10:55:40 2016 From: martin.peres at linux.intel.com (Martin Peres) Date: Thu, 20 Oct 2016 13:55:40 +0300 Subject: [PATCH rendercheck] Report results on a per-test basis In-Reply-To: <20161006140535.32211-1-martin.peres@linux.intel.com> References: <20161006140535.32211-1-martin.peres@linux.intel.com> Message-ID: <04bf63a4-9b9d-759a-c3f4-7bc41ccb1ef6@linux.intel.com> On 06/10/16 17:05, Martin Peres wrote: > This allows a runner such as EzBench to track each test individually > and not limit the resolution to groups. > > This feature can be triggered by using the -r parameter. > > Signed-off-by: Martin Peres Has anyone looked at this? Can I get at least an ACK before merging this? Martin From peter.hutterer at who-t.net Thu Oct 20 21:50:07 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Fri, 21 Oct 2016 07:50:07 +1000 Subject: [PATCH xserver 2/3] xfree86: swap the list of paused devices to an xorg_list In-Reply-To: <20161020215008.3103-1-peter.hutterer@who-t.net> References: <20161020215008.3103-1-peter.hutterer@who-t.net> Message-ID: <20161020215008.3103-2-peter.hutterer@who-t.net> No functional changes but it makes it easier to remove elements from the middle of the list (future patch). We don't have an init call into this file, so the list is manually initialized. Signed-off-by: Peter Hutterer --- hw/xfree86/common/xf86Xinput.c | 31 ++++++++++++++++++++----------- 1 file changed, 20 insertions(+), 11 deletions(-) diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c index e31aab3..0095272 100644 --- a/hw/xfree86/common/xf86Xinput.c +++ b/hw/xfree86/common/xf86Xinput.c @@ -110,8 +110,16 @@ static int xf86InputDevicePostInit(DeviceIntPtr dev); -static InputInfoPtr *new_input_devices; -static int new_input_devices_count; +typedef struct { + struct xorg_list node; + InputInfoPtr pInfo; +} PausedInputDeviceRec; +typedef PausedInputDeviceRec *PausedInputDevicePtr; + +static struct xorg_list new_input_devices_list = { + .next = &new_input_devices_list, + .prev = &new_input_devices_list, +}; /** * Eval config and modify DeviceVelocityRec accordingly @@ -907,11 +915,10 @@ xf86NewInputDevice(InputInfoPtr pInfo, DeviceIntPtr *pdev, BOOL enable) if (fd != -1) { if (paused) { /* Put on new_input_devices list for delayed probe */ - new_input_devices = xnfreallocarray(new_input_devices, - new_input_devices_count + 1, - sizeof(pInfo)); - new_input_devices[new_input_devices_count] = pInfo; - new_input_devices_count++; + PausedInputDevicePtr new_device = xnfalloc(sizeof *new_device); + new_device->pInfo = pInfo; + + xorg_list_append(&new_device->node, &new_input_devices_list); systemd_logind_release_fd(pInfo->major, pInfo->minor, fd); free(path); return BadMatch; @@ -1540,11 +1547,12 @@ xf86PostTouchEvent(DeviceIntPtr dev, uint32_t touchid, uint16_t type, void xf86InputEnableVTProbe(void) { - int i, is_auto = 0; + int is_auto = 0; DeviceIntPtr pdev; + PausedInputDevicePtr d, tmp; - for (i = 0; i < new_input_devices_count; i++) { - InputInfoPtr pInfo = new_input_devices[i]; + xorg_list_for_each_entry_safe(d, tmp, &new_input_devices_list, node) { + InputInfoPtr pInfo = d->pInfo; const char *value = xf86findOptionValue(pInfo->options, "_source"); is_auto = 0; @@ -1557,8 +1565,9 @@ xf86InputEnableVTProbe(void) xf86NewInputDevice(pInfo, &pdev, (!is_auto || (is_auto && xf86Info.autoEnableDevices))); + xorg_list_del(&d->node); + free(d); } - new_input_devices_count = 0; } /* end of xf86Xinput.c */ -- 2.9.3 From peter.hutterer at who-t.net Thu Oct 20 21:50:06 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Fri, 21 Oct 2016 07:50:06 +1000 Subject: [PATCH xserver 1/3] xfree86: use the right option traversal list to search for an option Message-ID: <20161020215008.3103-1-peter.hutterer@who-t.net> They're identically laid-out structs but let's use the right type to search for our desired value. Signed-off-by: Peter Hutterer --- hw/xfree86/common/xf86Xinput.c | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c index 538b110..e31aab3 100644 --- a/hw/xfree86/common/xf86Xinput.c +++ b/hw/xfree86/common/xf86Xinput.c @@ -1541,23 +1541,19 @@ void xf86InputEnableVTProbe(void) { int i, is_auto = 0; - InputOption *option = NULL; DeviceIntPtr pdev; for (i = 0; i < new_input_devices_count; i++) { InputInfoPtr pInfo = new_input_devices[i]; + const char *value = xf86findOptionValue(pInfo->options, "_source"); is_auto = 0; - nt_list_for_each_entry(option, pInfo->options, list.next) { - const char *key = input_option_get_key(option); - const char *value = input_option_get_value(option); + if (value && + (strcmp(value, "server/hal") == 0 || + strcmp(value, "server/udev") == 0 || + strcmp(value, "server/wscons") == 0)) + is_auto = 1; - if (strcmp(key, "_source") == 0 && - (strcmp(value, "server/hal") == 0 || - strcmp(value, "server/udev") == 0 || - strcmp(value, "server/wscons") == 0)) - is_auto = 1; - } xf86NewInputDevice(pInfo, &pdev, (!is_auto || (is_auto && xf86Info.autoEnableDevices))); -- 2.9.3 From peter.hutterer at who-t.net Thu Oct 20 21:50:08 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Fri, 21 Oct 2016 07:50:08 +1000 Subject: [PATCH xserver 3/3] ddx: add new call to purge input devices that weren't added In-Reply-To: <20161020215008.3103-1-peter.hutterer@who-t.net> References: <20161020215008.3103-1-peter.hutterer@who-t.net> Message-ID: <20161020215008.3103-3-peter.hutterer@who-t.net> Special case for the systemd-logind case in xfree86: when we're vt-switched away and a device is plugged in, we get a paused fd from logind. Since we can't probe the device or do anything with it, we store that device in the xfree86 and handle it later when we vt-switch back. The device is not added to inputInfo.devices until that time. When the device is removed while still vt-switched away, the the config system never notifies the DDX. It only runs through inputInfo.devices and our device was never added to that. When a device is plugged in, removed, and plugged in again while vt-switched away, we have two entries in the xfree86-specific list that refer to the same device node, both pending for addition later. On VT switch back, the first one (the already removed one) will be added successfully, the second one (the still plugged-in one) fails. Since the fd is correct, the device works until it is removed again. The removed devices' config_info (i.e. the syspath) doesn't match the actual device we addded tough (the input number increases with each plug), it doesn't get removed, the fd remains open and we lose track of the fd count. Plugging the device in again leads to a dead device. Fix this by adding a call to notify the DDX to purge any remainders of devices with the given config_info, that's the only identifiable bit we have at this point. https://bugs.freedesktop.org/show_bug.cgi?id=97928 Signed-off-by: Peter Hutterer --- Xi/stubs.c | 14 ++++++++++++++ config/config.c | 2 ++ hw/dmx/dmxinput.c | 5 +++++ hw/kdrive/src/kinput.c | 5 +++++ hw/xfree86/common/xf86Xinput.c | 19 +++++++++++++++++++ hw/xquartz/darwinXinput.c | 15 +++++++++++++++ include/input.h | 1 + 7 files changed, 61 insertions(+) diff --git a/Xi/stubs.c b/Xi/stubs.c index 39bee7c..27848a2 100644 --- a/Xi/stubs.c +++ b/Xi/stubs.c @@ -143,3 +143,17 @@ DeleteInputDeviceRequest(DeviceIntPtr dev) { RemoveDevice(dev, TRUE); } + +/**************************************************************************** + * + * Caller: configRemoveDevice (and others) + * + * Remove any traces of the input device specified in config_info. + * This is only necessary if the ddx keeps information around beyond + * the NewInputDeviceRequest/DeleteInputDeviceRequest + * + */ +void +RemoveInputDeviceTraces(const char *config_info) +{ +} diff --git a/config/config.c b/config/config.c index 1fb368c..fb60295 100644 --- a/config/config.c +++ b/config/config.c @@ -107,6 +107,8 @@ remove_devices(const char *backend, const char *config_info) if (dev->config_info && strcmp(dev->config_info, config_info) == 0) remove_device(backend, dev); } + + RemoveInputDeviceTraces(config_info); } BOOL diff --git a/hw/dmx/dmxinput.c b/hw/dmx/dmxinput.c index 4ccb439..d201034 100644 --- a/hw/dmx/dmxinput.c +++ b/hw/dmx/dmxinput.c @@ -123,3 +123,8 @@ void DeleteInputDeviceRequest(DeviceIntPtr pDev) { } + +void +RemoveInputDeviceTraces(const char *config_info) +{ +} diff --git a/hw/kdrive/src/kinput.c b/hw/kdrive/src/kinput.c index 2c39624..8b08747 100644 --- a/hw/kdrive/src/kinput.c +++ b/hw/kdrive/src/kinput.c @@ -2302,3 +2302,8 @@ DeleteInputDeviceRequest(DeviceIntPtr pDev) { RemoveDevice(pDev, TRUE); } + +void +RemoveInputDeviceTraces(const char *config_info) +{ +} diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c index 0095272..d673711 100644 --- a/hw/xfree86/common/xf86Xinput.c +++ b/hw/xfree86/common/xf86Xinput.c @@ -1119,6 +1119,25 @@ DeleteInputDeviceRequest(DeviceIntPtr pDev) input_unlock(); } +void +RemoveInputDeviceTraces(const char *config_info) +{ + PausedInputDevicePtr d, tmp; + + if (new_input_devices_list.next == NULL && + new_input_devices_list.prev == NULL) + xorg_list_init(&new_input_devices_list); + + xorg_list_for_each_entry_safe(d, tmp, &new_input_devices_list, node) { + const char *ci = xf86findOptionValue(d->pInfo->options, "config_info"); + if (!ci || strcmp(ci, config_info) != 0) + continue; + + xorg_list_del(&d->node); + free(d); + } +} + /* * convenient functions to post events */ diff --git a/hw/xquartz/darwinXinput.c b/hw/xquartz/darwinXinput.c index 3efaa2c..fea7e92 100644 --- a/hw/xquartz/darwinXinput.c +++ b/hw/xquartz/darwinXinput.c @@ -147,3 +147,18 @@ DeleteInputDeviceRequest(DeviceIntPtr dev) { DEBUG_LOG("DeleteInputDeviceRequest(%p)\n", dev); } + +/**************************************************************************** + * + * Caller: configRemoveDevice (and others) + * + * Remove any traces of the input device specified in config_info. + * This is only necessary if the ddx keeps information around beyond + * the NewInputDeviceRequest/DeleteInputDeviceRequest + * + */ +void +RemoveInputDeviceTraces(const char *config_info) +{ + DEBUG_LOG("RemoveInputDeviceTraces(%s)\n", config_info); +} diff --git a/include/input.h b/include/input.h index c7b1e91..bb58b22 100644 --- a/include/input.h +++ b/include/input.h @@ -635,6 +635,7 @@ extern _X_EXPORT int NewInputDeviceRequest(InputOption *options, InputAttributes * attrs, DeviceIntPtr *dev); extern _X_EXPORT void DeleteInputDeviceRequest(DeviceIntPtr dev); +extern _X_EXPORT void RemoveInputDeviceTraces(const char *config_info); extern _X_EXPORT void DDXRingBell(int volume, int pitch, int duration); -- 2.9.3 From peter.hutterer at who-t.net Thu Oct 20 23:55:15 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Fri, 21 Oct 2016 09:55:15 +1000 Subject: [PATCH evdev] Fix off-by-one error counting axes Message-ID: <20161020235515.GA14990@jelly.local> We stopped counting one too early, but still initialized that axis later, leading to a bug macro to trigger. https://bugs.freedesktop.org/show_bug.cgi?id=97956 Signed-off-by: Peter Hutterer --- src/evdev.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/evdev.c b/src/evdev.c index 5ace238..96fd97d 100644 --- a/src/evdev.c +++ b/src/evdev.c @@ -1238,7 +1238,7 @@ EvdevCountMTAxes(EvdevPtr pEvdev, int *num_mt_axes_total, return; /* Absolute multitouch axes: adjust mapping and axes counts. */ - for (axis = ABS_MT_SLOT; axis < ABS_MAX; axis++) + for (axis = ABS_MT_SLOT; axis <= ABS_MAX; axis++) { int j; Bool skip = FALSE; @@ -1288,7 +1288,7 @@ EvdevAddAbsValuatorClass(DeviceIntPtr device, int num_scroll_axes) goto out; /* Find number of absolute axis, including MT ones, will decrease later. */ - for (i = 0; i < ABS_MAX; i++) + for (i = 0; i <= ABS_MAX; i++) if (libevdev_has_event_code(pEvdev->dev, EV_ABS, i)) num_axes++; @@ -1456,7 +1456,7 @@ EvdevAddAbsValuatorClass(DeviceIntPtr device, int num_scroll_axes) } for (i = 0; i < num_touches; i++) { - for (axis = ABS_MT_TOUCH_MAJOR; axis < ABS_MAX; axis++) { + for (axis = ABS_MT_TOUCH_MAJOR; axis <= ABS_MAX; axis++) { if (pEvdev->abs_axis_map[axis] >= 0) { int val = pEvdev->mtdev ? 0 : libevdev_get_current_slot(pEvdev->dev); /* XXX: read initial values from mtdev when it adds support @@ -1669,7 +1669,7 @@ EvdevAddRelValuatorClass(DeviceIntPtr device, int num_scroll_axes) if (!libevdev_has_event_type(pEvdev->dev, EV_REL)) goto out; - for (i = 0; i < REL_MAX; i++) { + for (i = 0; i <= REL_MAX; i++) { if (i == REL_WHEEL || i == REL_HWHEEL || i == REL_DIAL) continue; -- 2.9.3 From ofourdan at redhat.com Fri Oct 21 08:11:45 2016 From: ofourdan at redhat.com (Olivier Fourdan) Date: Fri, 21 Oct 2016 10:11:45 +0200 Subject: [PATCH xserver] xwayland: Activate and enable touch devices Message-ID: <20161021081145.29825-1-ofourdan@redhat.com> On some random condition, a touch event may trigger a crash in Xwayland in GetTouchEvents(). The (simplified) backtrace goes as follow: (gdb) bt #0 GetTouchEvents() at getevents.c:1892 #1 QueueTouchEvents() at getevents.c:1866 #2 xwl_touch_send_event() at xwayland-input.c:652 #5 wl_closure_invoke() from libwayland-client.so.0 #6 dispatch_event() from libwayland-client.so.0 #7 wl_display_dispatch_queue_pending() from libwayland-client.so.0 #8 xwl_read_events() at xwayland.c:483 #9 ospoll_wait() at ospoll.c:412 #10 WaitForSomething() at WaitFor.c:222 #11 Dispatch() at dispatch.c:412 #12 dix_main() at main.c:287 #13 __libc_start_main() at libc-start.c:289 #14 _start () The crash occurs when trying to access the sprite associated with the touch device, which appears to be NULL. Reason being the device itself is more a keyboard device than a touch device. Moreover, it appears the device is neither enabled nor activated (inited=0, enabled=0) which doesn't seem right, but matches the code in init_touch() from xwayland-input.c which would enable the device if it was previously existing and otherwise would create the device but not activate it. Make sure we do activate and enable touch devices just like we do for other input devices such as keyboard and pointer. Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-input.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c index 4d447a5..9a7123a 100644 --- a/hw/xwayland/xwayland-input.c +++ b/hw/xwayland/xwayland-input.c @@ -1056,12 +1056,13 @@ init_touch(struct xwl_seat *xwl_seat) wl_touch_add_listener(xwl_seat->wl_touch, &touch_listener, xwl_seat); - if (xwl_seat->touch) - EnableDevice(xwl_seat->touch, TRUE); - else { + if (xwl_seat->touch == NULL) { xwl_seat->touch = add_device(xwl_seat, "xwayland-touch", xwl_touch_proc); + ActivateDevice(xwl_seat->touch, TRUE); } + EnableDevice(xwl_seat->touch, TRUE); + } static void -- 2.9.3 From hdegoede at redhat.com Fri Oct 21 09:08:04 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Fri, 21 Oct 2016 11:08:04 +0200 Subject: [PATCH xserver 3/3] ddx: add new call to purge input devices that weren't added In-Reply-To: <20161020215008.3103-3-peter.hutterer@who-t.net> References: <20161020215008.3103-1-peter.hutterer@who-t.net> <20161020215008.3103-3-peter.hutterer@who-t.net> Message-ID: <5bcd1a47-7c3f-b069-3656-199c3f536ecb@redhat.com> Hi, On 20-10-16 23:50, Peter Hutterer wrote: > Special case for the systemd-logind case in xfree86: when we're vt-switched > away and a device is plugged in, we get a paused fd from logind. Since we > can't probe the device or do anything with it, we store that device in the > xfree86 and handle it later when we vt-switch back. The device is not added to > inputInfo.devices until that time. > > When the device is removed while still vt-switched away, the the config system > never notifies the DDX. It only runs through inputInfo.devices and our device > was never added to that. > > When a device is plugged in, removed, and plugged in again while vt-switched > away, we have two entries in the xfree86-specific list that refer to the same > device node, both pending for addition later. On VT switch back, the first one > (the already removed one) will be added successfully, the second one (the > still plugged-in one) fails. Since the fd is correct, the device works until > it is removed again. The removed devices' config_info (i.e. the syspath) > doesn't match the actual device we addded tough (the input number increases > with each plug), it doesn't get removed, the fd remains open and we lose track > of the fd count. Plugging the device in again leads to a dead device. > > Fix this by adding a call to notify the DDX to purge any remainders of devices > with the given config_info, that's the only identifiable bit we have at this > point. > > https://bugs.freedesktop.org/show_bug.cgi?id=97928 > > Signed-off-by: Peter Hutterer > --- > Xi/stubs.c | 14 ++++++++++++++ > config/config.c | 2 ++ > hw/dmx/dmxinput.c | 5 +++++ > hw/kdrive/src/kinput.c | 5 +++++ > hw/xfree86/common/xf86Xinput.c | 19 +++++++++++++++++++ > hw/xquartz/darwinXinput.c | 15 +++++++++++++++ > include/input.h | 1 + > 7 files changed, 61 insertions(+) > > diff --git a/Xi/stubs.c b/Xi/stubs.c > index 39bee7c..27848a2 100644 > --- a/Xi/stubs.c > +++ b/Xi/stubs.c > @@ -143,3 +143,17 @@ DeleteInputDeviceRequest(DeviceIntPtr dev) > { > RemoveDevice(dev, TRUE); > } > + > +/**************************************************************************** > + * > + * Caller: configRemoveDevice (and others) > + * > + * Remove any traces of the input device specified in config_info. > + * This is only necessary if the ddx keeps information around beyond > + * the NewInputDeviceRequest/DeleteInputDeviceRequest > + * > + */ > +void > +RemoveInputDeviceTraces(const char *config_info) > +{ > +} > diff --git a/config/config.c b/config/config.c > index 1fb368c..fb60295 100644 > --- a/config/config.c > +++ b/config/config.c > @@ -107,6 +107,8 @@ remove_devices(const char *backend, const char *config_info) > if (dev->config_info && strcmp(dev->config_info, config_info) == 0) > remove_device(backend, dev); > } > + > + RemoveInputDeviceTraces(config_info); > } > > BOOL > diff --git a/hw/dmx/dmxinput.c b/hw/dmx/dmxinput.c > index 4ccb439..d201034 100644 > --- a/hw/dmx/dmxinput.c > +++ b/hw/dmx/dmxinput.c > @@ -123,3 +123,8 @@ void > DeleteInputDeviceRequest(DeviceIntPtr pDev) > { > } > + > +void > +RemoveInputDeviceTraces(const char *config_info) > +{ > +} > diff --git a/hw/kdrive/src/kinput.c b/hw/kdrive/src/kinput.c > index 2c39624..8b08747 100644 > --- a/hw/kdrive/src/kinput.c > +++ b/hw/kdrive/src/kinput.c > @@ -2302,3 +2302,8 @@ DeleteInputDeviceRequest(DeviceIntPtr pDev) > { > RemoveDevice(pDev, TRUE); > } > + > +void > +RemoveInputDeviceTraces(const char *config_info) > +{ > +} > diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c > index 0095272..d673711 100644 > --- a/hw/xfree86/common/xf86Xinput.c > +++ b/hw/xfree86/common/xf86Xinput.c > @@ -1119,6 +1119,25 @@ DeleteInputDeviceRequest(DeviceIntPtr pDev) > input_unlock(); > } > > +void > +RemoveInputDeviceTraces(const char *config_info) > +{ > + PausedInputDevicePtr d, tmp; > + > + if (new_input_devices_list.next == NULL && > + new_input_devices_list.prev == NULL) > + xorg_list_init(&new_input_devices_list); This bit is unnecessary, as you already initialize new_input_devices_list when you declare it at the top of the file. With these 3 lines dropped the entire series looks good to me and is: Reviewed-by: Hans de Goede Regards, Hans > + > + xorg_list_for_each_entry_safe(d, tmp, &new_input_devices_list, node) { > + const char *ci = xf86findOptionValue(d->pInfo->options, "config_info"); > + if (!ci || strcmp(ci, config_info) != 0) > + continue; > + > + xorg_list_del(&d->node); > + free(d); > + } > +} > + > /* > * convenient functions to post events > */ > diff --git a/hw/xquartz/darwinXinput.c b/hw/xquartz/darwinXinput.c > index 3efaa2c..fea7e92 100644 > --- a/hw/xquartz/darwinXinput.c > +++ b/hw/xquartz/darwinXinput.c > @@ -147,3 +147,18 @@ DeleteInputDeviceRequest(DeviceIntPtr dev) > { > DEBUG_LOG("DeleteInputDeviceRequest(%p)\n", dev); > } > + > +/**************************************************************************** > + * > + * Caller: configRemoveDevice (and others) > + * > + * Remove any traces of the input device specified in config_info. > + * This is only necessary if the ddx keeps information around beyond > + * the NewInputDeviceRequest/DeleteInputDeviceRequest > + * > + */ > +void > +RemoveInputDeviceTraces(const char *config_info) > +{ > + DEBUG_LOG("RemoveInputDeviceTraces(%s)\n", config_info); > +} > diff --git a/include/input.h b/include/input.h > index c7b1e91..bb58b22 100644 > --- a/include/input.h > +++ b/include/input.h > @@ -635,6 +635,7 @@ extern _X_EXPORT int NewInputDeviceRequest(InputOption *options, > InputAttributes * attrs, > DeviceIntPtr *dev); > extern _X_EXPORT void DeleteInputDeviceRequest(DeviceIntPtr dev); > +extern _X_EXPORT void RemoveInputDeviceTraces(const char *config_info); > > extern _X_EXPORT void DDXRingBell(int volume, int pitch, int duration); > > From hdegoede at redhat.com Fri Oct 21 09:08:42 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Fri, 21 Oct 2016 11:08:42 +0200 Subject: [PATCH evdev] Fix off-by-one error counting axes In-Reply-To: <20161020235515.GA14990@jelly.local> References: <20161020235515.GA14990@jelly.local> Message-ID: <6799db30-711b-1e60-20b7-fb5a8ba4ea3c@redhat.com> Hi, On 21-10-16 01:55, Peter Hutterer wrote: > We stopped counting one too early, but still initialized that axis later, > leading to a bug macro to trigger. > > https://bugs.freedesktop.org/show_bug.cgi?id=97956 > > Signed-off-by: Peter Hutterer LGTM: Reviewed-by: Hans de Goede Regards, Hans > --- > src/evdev.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/src/evdev.c b/src/evdev.c > index 5ace238..96fd97d 100644 > --- a/src/evdev.c > +++ b/src/evdev.c > @@ -1238,7 +1238,7 @@ EvdevCountMTAxes(EvdevPtr pEvdev, int *num_mt_axes_total, > return; > > /* Absolute multitouch axes: adjust mapping and axes counts. */ > - for (axis = ABS_MT_SLOT; axis < ABS_MAX; axis++) > + for (axis = ABS_MT_SLOT; axis <= ABS_MAX; axis++) > { > int j; > Bool skip = FALSE; > @@ -1288,7 +1288,7 @@ EvdevAddAbsValuatorClass(DeviceIntPtr device, int num_scroll_axes) > goto out; > > /* Find number of absolute axis, including MT ones, will decrease later. */ > - for (i = 0; i < ABS_MAX; i++) > + for (i = 0; i <= ABS_MAX; i++) > if (libevdev_has_event_code(pEvdev->dev, EV_ABS, i)) > num_axes++; > > @@ -1456,7 +1456,7 @@ EvdevAddAbsValuatorClass(DeviceIntPtr device, int num_scroll_axes) > } > > for (i = 0; i < num_touches; i++) { > - for (axis = ABS_MT_TOUCH_MAJOR; axis < ABS_MAX; axis++) { > + for (axis = ABS_MT_TOUCH_MAJOR; axis <= ABS_MAX; axis++) { > if (pEvdev->abs_axis_map[axis] >= 0) { > int val = pEvdev->mtdev ? 0 : libevdev_get_current_slot(pEvdev->dev); > /* XXX: read initial values from mtdev when it adds support > @@ -1669,7 +1669,7 @@ EvdevAddRelValuatorClass(DeviceIntPtr device, int num_scroll_axes) > if (!libevdev_has_event_type(pEvdev->dev, EV_REL)) > goto out; > > - for (i = 0; i < REL_MAX; i++) { > + for (i = 0; i <= REL_MAX; i++) { > if (i == REL_WHEEL || i == REL_HWHEEL || i == REL_DIAL) > continue; > > From hdegoede at redhat.com Fri Oct 21 09:10:09 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Fri, 21 Oct 2016 11:10:09 +0200 Subject: [PATCH xserver] xwayland: Activate and enable touch devices In-Reply-To: <20161021081145.29825-1-ofourdan@redhat.com> References: <20161021081145.29825-1-ofourdan@redhat.com> Message-ID: <935e1d0c-3d43-ed29-e0ae-1e5f666d5b25@redhat.com> HI, On 21-10-16 10:11, Olivier Fourdan wrote: > On some random condition, a touch event may trigger a crash in Xwayland > in GetTouchEvents(). > > The (simplified) backtrace goes as follow: > > (gdb) bt > #0 GetTouchEvents() at getevents.c:1892 > #1 QueueTouchEvents() at getevents.c:1866 > #2 xwl_touch_send_event() at xwayland-input.c:652 > #5 wl_closure_invoke() from libwayland-client.so.0 > #6 dispatch_event() from libwayland-client.so.0 > #7 wl_display_dispatch_queue_pending() from libwayland-client.so.0 > #8 xwl_read_events() at xwayland.c:483 > #9 ospoll_wait() at ospoll.c:412 > #10 WaitForSomething() at WaitFor.c:222 > #11 Dispatch() at dispatch.c:412 > #12 dix_main() at main.c:287 > #13 __libc_start_main() at libc-start.c:289 > #14 _start () > > The crash occurs when trying to access the sprite associated with the > touch device, which appears to be NULL. Reason being the device itself > is more a keyboard device than a touch device. > > Moreover, it appears the device is neither enabled nor activated > (inited=0, enabled=0) which doesn't seem right, but matches the code in > init_touch() from xwayland-input.c which would enable the device if it > was previously existing and otherwise would create the device but not > activate it. > > Make sure we do activate and enable touch devices just like we do for > other input devices such as keyboard and pointer. > > Signed-off-by: Olivier Fourdan Patch LGTM: Reviewed-by: Hans de Goede Regards, Hans > --- > hw/xwayland/xwayland-input.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c > index 4d447a5..9a7123a 100644 > --- a/hw/xwayland/xwayland-input.c > +++ b/hw/xwayland/xwayland-input.c > @@ -1056,12 +1056,13 @@ init_touch(struct xwl_seat *xwl_seat) > wl_touch_add_listener(xwl_seat->wl_touch, > &touch_listener, xwl_seat); > > - if (xwl_seat->touch) > - EnableDevice(xwl_seat->touch, TRUE); > - else { > + if (xwl_seat->touch == NULL) { > xwl_seat->touch = > add_device(xwl_seat, "xwayland-touch", xwl_touch_proc); > + ActivateDevice(xwl_seat->touch, TRUE); > } > + EnableDevice(xwl_seat->touch, TRUE); > + > } > > static void > From chris at chris-wilson.co.uk Fri Oct 21 11:23:42 2016 From: chris at chris-wilson.co.uk (Chris Wilson) Date: Fri, 21 Oct 2016 12:23:42 +0100 Subject: [PATCH xserver] xfree86: Choose the largest output as primary for xf86TargetFallback() Message-ID: <20161021112342.6847-1-chris@chris-wilson.co.uk> With all things equal (i.e. same output preferences), use the largest output as the primary. From the primary, we choose compatible modes for the others, and given that we are configuring an extended desktop, we have greater freedom in our selection and may as well base our choice on the largest mode available. Signed-off-by: Chris Wilson --- hw/xfree86/modes/xf86Crtc.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c index 966a168..048c3b2 100644 --- a/hw/xfree86/modes/xf86Crtc.c +++ b/hw/xfree86/modes/xf86Crtc.c @@ -2413,7 +2413,10 @@ xf86TargetFallback(ScrnInfoPtr scrn, xf86CrtcConfigPtr config, default_preferred = (((default_mode->type & M_T_PREFERRED) != 0) + ((default_mode->type & M_T_USERPREF) != 0)); - if (default_preferred > target_preferred || !target_mode) { + if (!target_mode || + default_preferred > target_preferred || + (default_preferred == target_preferred && + biggestMode(default_mode, target_mode))) { target_mode = default_mode; target_preferred = default_preferred; target_rotation = config->output[o]->initial_rotation; -- 2.9.3 From ofourdan at redhat.com Fri Oct 21 11:52:52 2016 From: ofourdan at redhat.com (Olivier Fourdan) Date: Fri, 21 Oct 2016 07:52:52 -0400 (EDT) Subject: Null pointer deref in FlushAllOutput with 1.19-rc1 ? In-Reply-To: References: Message-ID: <439027105.3863263.1477050772314.JavaMail.zimbra@redhat.com> Hi, > Multiple Fedora 25 users running 1.19-rc1 are reporting a backtrace > related to an InitFonts -> SendErrorToClient -> FlushAllOutput > call chain. > > Since there is no trivial reproducer this is somewhat hard to debug, > hence this mail. Anyone have a clue / hint ? See: > > https://bugzilla.redhat.com/show_bug.cgi?id=1382444 Actually, I think we cannot really trust the symbols from Xorg's own generated backtrace, however, looking at the addresses, the sequence makes some more sense: FlushAllOutput() in /usr/src/debug/xorg-server-20160929/os/io.c:612 Dispatch() in /usr/src/debug/xorg-server-20160929/dix/dispatch.c:3491 dix_main() in /usr/src/debug/xorg-server-20160929/dix/main.c:296 with /usr/src/debug/xorg-server-20160929/os/io.c:612 612 xorg_list_for_each_entry_safe(client, tmp, &output_pending_clients, output_pending) { 613 if (client->clientGone) 614 continue; 615 if (!client_is_ready(client)) { 616 oc = (OsCommPtr) client->osPrivate; 617 (void) FlushClient(client, oc, (char *) NULL, 0); 618 } else 619 NewOutputPending = TRUE; 620 } So it could be that output_pending_clients list got corrupted somehow. Not sure I can go much further than that with so little data, but if that rings a bell with someone else... Cheers, Olivier From eric at anholt.net Fri Oct 21 16:18:49 2016 From: eric at anholt.net (Eric Anholt) Date: Fri, 21 Oct 2016 09:18:49 -0700 Subject: [PATCH rendercheck] Report results on a per-test basis In-Reply-To: <20161006140535.32211-1-martin.peres@linux.intel.com> References: <20161006140535.32211-1-martin.peres@linux.intel.com> Message-ID: <87funpfzfa.fsf@eliezer.anholt.net> Martin Peres writes: > This allows a runner such as EzBench to track each test individually > and not limit the resolution to groups. > > This feature can be triggered by using the -r parameter. I don't really see the point of this -- you need an external runner to be choosing a specific test subset to run per rendercheck call, since the full matrix of composite tests is too long. Once you have an external runner calling rendercheck per test group, all you would be able to do using this patch would be save a few spawns of the process, which doesn't seem worth it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From emil.l.velikov at gmail.com Fri Oct 21 18:06:00 2016 From: emil.l.velikov at gmail.com (Emil Velikov) Date: Fri, 21 Oct 2016 19:06:00 +0100 Subject: [PATCH xserver] glamor: don't look for non-existing EGL_KHR_platform_base Message-ID: <20161021180600.6092-1-emil.l.velikov@gmail.com> From: Emil Velikov The extensions does not exist in the registry, thus needs to know they're using EGL 1.5 in order to determine the eglGetPlatformDisplay function pointer is valid. Thus brings us into some lovely circular dependency. Since mesa won't be able (in the foreseeable future) to export the KHR flavour of extensions (another way one could assume that EGL 1.5 is available) just drop all the heuristics and use the EGL_EXT_platform_base extension. In practise (checked with the Mali driver) any EGL 1.5 driver will advertise support for EGL_EXT_platform_base. Cc: Adam Jackson Signed-off-by: Emil Velikov --- glamor/glamor_egl.h | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/glamor/glamor_egl.h b/glamor/glamor_egl.h index 147aae6..6b05f57 100644 --- a/glamor/glamor_egl.h +++ b/glamor/glamor_egl.h @@ -49,23 +49,20 @@ * have yet. So you have to query for extensions no matter what. Fortunately * epoxy_has_egl_extension _does_ let you query for client extensions, so * we don't have to write our own extension string parsing. + * + * 4. There is no EGL_KHR_platform_base to complement the EXT one, thus one + * needs to know EGL 1.5 is supported in order to use the eglGetPlatformDisplay + * function pointer. + * We can workaround this (circular dependency) by probing for the EGL 1.5 + * platform extensions (EGL_KHR_platform_gbm and friends) yet it doesn't seem + * like mesa will be able to adverise these (even though it can do EGL 1.5). */ static inline EGLDisplay glamor_egl_get_display(EGLint type, void *native) { EGLDisplay dpy = NULL; - /* If we're EGL 1.5, the KHR extension will be there, try that */ - if (epoxy_has_egl_extension(NULL, "EGL_KHR_platform_base")) { - PFNEGLGETPLATFORMDISPLAYPROC getPlatformDisplay = - (void *) eglGetProcAddress("eglGetPlatformDisplay"); - if (getPlatformDisplay) - dpy = getPlatformDisplay(type, native, NULL); - if (dpy) - return dpy; - } - - /* Okay, maybe the EXT extension works */ + /* In practise any EGL 1.5 implementation would support the EXT extension */ if (epoxy_has_egl_extension(NULL, "EGL_EXT_platform_base")) { PFNEGLGETPLATFORMDISPLAYEXTPROC getPlatformDisplayEXT = (void *) eglGetProcAddress("eglGetPlatformDisplayEXT"); -- 2.9.3 From nmahale at nvidia.com Sat Oct 22 12:10:51 2016 From: nmahale at nvidia.com (Nikhil Mahale) Date: Sat, 22 Oct 2016 17:40:51 +0530 Subject: [PATCH xserver] modesetting: unifdef MODESETTING_OUTPUT_SLAVE_SUPPORT Message-ID: <1477138251-22145-1-git-send-email-nmahale@nvidia.com> Commit c7e8d4a6ee9542f56cd241cf7a960fb8223a6b22 had already unifdef MODESETTING_OUTPUT_SLAVE_SUPPORT but commit 9257b1252da9092ddc676fec9aabe2b33dfad272 didn't notice that. Signed-off-by: Nikhil Mahale --- hw/xfree86/drivers/modesetting/drmmode_display.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c b/hw/xfree86/drivers/modesetting/drmmode_display.c index 61a0e27..6e755e9 100644 --- a/hw/xfree86/drivers/modesetting/drmmode_display.c +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c @@ -1701,10 +1701,8 @@ drmmode_create_name(ScrnInfoPtr pScrn, drmModeConnectorPtr koutput, char *name, fallback: if (koutput->connector_type >= MS_ARRAY_SIZE(output_names)) snprintf(name, 32, "Unknown%d-%d", koutput->connector_type, koutput->connector_type_id); -#ifdef MODESETTING_OUTPUT_SLAVE_SUPPORT else if (pScrn->is_gpu) snprintf(name, 32, "%s-%d-%d", output_names[koutput->connector_type], pScrn->scrnIndex - GPU_SCREEN_OFFSET + 1, koutput->connector_type_id); -#endif else snprintf(name, 32, "%s-%d", output_names[koutput->connector_type], koutput->connector_type_id); } -- 2.6.6 From rhyskidd at gmail.com Sat Oct 22 21:40:40 2016 From: rhyskidd at gmail.com (Echelon9) Date: Sat, 22 Oct 2016 17:40:40 -0400 Subject: [PATCH xts] xts5: Fix clang warning - non-void function DoLayout should return a value Message-ID: <20161022214040.18330-1-rhyskidd@gmail.com> From: Rhys Kidd Box.c:245:7: error: non-void function 'DoLayout' should return a value [-Wreturn-type] return; ^ Box.c:285:6: error: non-void function 'DoLayout' should return a value [-Wreturn-type] return; ^ Signed-off-by: Rhys Kidd --- xts5/src/libXtTest/box.c | 2 +- xts5/src/libXtaw/Box.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/xts5/src/libXtTest/box.c b/xts5/src/libXtTest/box.c index 6383e59..d3674ce 100644 --- a/xts5/src/libXtTest/box.c +++ b/xts5/src/libXtTest/box.c @@ -182,7 +182,7 @@ WidgetClass boxWidgetClass = (WidgetClass)&boxClassRec; * */ -static DoLayout(bbw, width, height, reply_width, reply_height, position) +static void DoLayout(bbw, width, height, reply_width, reply_height, position) BoxWidget bbw; Dimension width, height; Dimension *reply_width, *reply_height; /* bounding box */ diff --git a/xts5/src/libXtaw/Box.c b/xts5/src/libXtaw/Box.c index feecbc3..d56e44d 100644 --- a/xts5/src/libXtaw/Box.c +++ b/xts5/src/libXtaw/Box.c @@ -196,7 +196,7 @@ WidgetClass boxWidgetClass = (WidgetClass)&boxClassRec; * */ -static DoLayout(bbw, width, height, reply_width, reply_height, position) +static void DoLayout(bbw, width, height, reply_width, reply_height, position) BoxWidget bbw; Dimension width, height; Dimension *reply_width, *reply_height; /* bounding box */ -- 2.9.3 From peter.hutterer at who-t.net Sun Oct 23 22:22:06 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Mon, 24 Oct 2016 08:22:06 +1000 Subject: [PATCH xserver 3/3] ddx: add new call to purge input devices that weren't added In-Reply-To: <5bcd1a47-7c3f-b069-3656-199c3f536ecb@redhat.com> References: <20161020215008.3103-1-peter.hutterer@who-t.net> <20161020215008.3103-3-peter.hutterer@who-t.net> <5bcd1a47-7c3f-b069-3656-199c3f536ecb@redhat.com> Message-ID: <20161023222206.GD1690@jelly.local> On Fri, Oct 21, 2016 at 11:08:04AM +0200, Hans de Goede wrote: > Hi, > > On 20-10-16 23:50, Peter Hutterer wrote: > > Special case for the systemd-logind case in xfree86: when we're vt-switched > > away and a device is plugged in, we get a paused fd from logind. Since we > > can't probe the device or do anything with it, we store that device in the > > xfree86 and handle it later when we vt-switch back. The device is not added to > > inputInfo.devices until that time. > > > > When the device is removed while still vt-switched away, the the config system > > never notifies the DDX. It only runs through inputInfo.devices and our device > > was never added to that. > > > > When a device is plugged in, removed, and plugged in again while vt-switched > > away, we have two entries in the xfree86-specific list that refer to the same > > device node, both pending for addition later. On VT switch back, the first one > > (the already removed one) will be added successfully, the second one (the > > still plugged-in one) fails. Since the fd is correct, the device works until > > it is removed again. The removed devices' config_info (i.e. the syspath) > > doesn't match the actual device we addded tough (the input number increases > > with each plug), it doesn't get removed, the fd remains open and we lose track > > of the fd count. Plugging the device in again leads to a dead device. > > > > Fix this by adding a call to notify the DDX to purge any remainders of devices > > with the given config_info, that's the only identifiable bit we have at this > > point. > > > > https://bugs.freedesktop.org/show_bug.cgi?id=97928 > > > > Signed-off-by: Peter Hutterer > > --- > > Xi/stubs.c | 14 ++++++++++++++ > > config/config.c | 2 ++ > > hw/dmx/dmxinput.c | 5 +++++ > > hw/kdrive/src/kinput.c | 5 +++++ > > hw/xfree86/common/xf86Xinput.c | 19 +++++++++++++++++++ > > hw/xquartz/darwinXinput.c | 15 +++++++++++++++ > > include/input.h | 1 + > > 7 files changed, 61 insertions(+) [...] > > --- a/hw/xfree86/common/xf86Xinput.c > > +++ b/hw/xfree86/common/xf86Xinput.c > > @@ -1119,6 +1119,25 @@ DeleteInputDeviceRequest(DeviceIntPtr pDev) > > input_unlock(); > > } > > > > +void > > +RemoveInputDeviceTraces(const char *config_info) > > +{ > > + PausedInputDevicePtr d, tmp; > > + > > + if (new_input_devices_list.next == NULL && > > + new_input_devices_list.prev == NULL) > > + xorg_list_init(&new_input_devices_list); > > This bit is unnecessary, as you already initialize > new_input_devices_list when you declare it at the top of the file. > > With these 3 lines dropped the entire series looks good to me and is: > > Reviewed-by: Hans de Goede ah, right. leftover from a previous version, sorry. thanks for the review. Cheers, Peter > > > > + > > + xorg_list_for_each_entry_safe(d, tmp, &new_input_devices_list, node) { > > + const char *ci = xf86findOptionValue(d->pInfo->options, "config_info"); > > + if (!ci || strcmp(ci, config_info) != 0) > > + continue; > > + > > + xorg_list_del(&d->node); > > + free(d); > > + } > > +} > > + > > /* > > * convenient functions to post events > > */ > > diff --git a/hw/xquartz/darwinXinput.c b/hw/xquartz/darwinXinput.c > > index 3efaa2c..fea7e92 100644 > > --- a/hw/xquartz/darwinXinput.c > > +++ b/hw/xquartz/darwinXinput.c > > @@ -147,3 +147,18 @@ DeleteInputDeviceRequest(DeviceIntPtr dev) > > { > > DEBUG_LOG("DeleteInputDeviceRequest(%p)\n", dev); > > } > > + > > +/**************************************************************************** > > + * > > + * Caller: configRemoveDevice (and others) > > + * > > + * Remove any traces of the input device specified in config_info. > > + * This is only necessary if the ddx keeps information around beyond > > + * the NewInputDeviceRequest/DeleteInputDeviceRequest > > + * > > + */ > > +void > > +RemoveInputDeviceTraces(const char *config_info) > > +{ > > + DEBUG_LOG("RemoveInputDeviceTraces(%s)\n", config_info); > > +} > > diff --git a/include/input.h b/include/input.h > > index c7b1e91..bb58b22 100644 > > --- a/include/input.h > > +++ b/include/input.h > > @@ -635,6 +635,7 @@ extern _X_EXPORT int NewInputDeviceRequest(InputOption *options, > > InputAttributes * attrs, > > DeviceIntPtr *dev); > > extern _X_EXPORT void DeleteInputDeviceRequest(DeviceIntPtr dev); > > +extern _X_EXPORT void RemoveInputDeviceTraces(const char *config_info); > > > > extern _X_EXPORT void DDXRingBell(int volume, int pitch, int duration); > > > > From hdegoede at redhat.com Mon Oct 24 07:59:35 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Mon, 24 Oct 2016 09:59:35 +0200 Subject: [PATCH xserver] modesetting: unifdef MODESETTING_OUTPUT_SLAVE_SUPPORT In-Reply-To: <1477138251-22145-1-git-send-email-nmahale@nvidia.com> References: <1477138251-22145-1-git-send-email-nmahale@nvidia.com> Message-ID: <11908292-53e0-011d-5782-e414d6d59a52@redhat.com> Hi, On 22-10-16 14:10, Nikhil Mahale wrote: > Commit c7e8d4a6ee9542f56cd241cf7a960fb8223a6b22 had already > unifdef MODESETTING_OUTPUT_SLAVE_SUPPORT but commit > 9257b1252da9092ddc676fec9aabe2b33dfad272 didn't > notice that. > > Signed-off-by: Nikhil Mahale Looks good to me: Reviewed-by: Hans de Goede Regards, Hans > --- > hw/xfree86/drivers/modesetting/drmmode_display.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c b/hw/xfree86/drivers/modesetting/drmmode_display.c > index 61a0e27..6e755e9 100644 > --- a/hw/xfree86/drivers/modesetting/drmmode_display.c > +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c > @@ -1701,10 +1701,8 @@ drmmode_create_name(ScrnInfoPtr pScrn, drmModeConnectorPtr koutput, char *name, > fallback: > if (koutput->connector_type >= MS_ARRAY_SIZE(output_names)) > snprintf(name, 32, "Unknown%d-%d", koutput->connector_type, koutput->connector_type_id); > -#ifdef MODESETTING_OUTPUT_SLAVE_SUPPORT > else if (pScrn->is_gpu) > snprintf(name, 32, "%s-%d-%d", output_names[koutput->connector_type], pScrn->scrnIndex - GPU_SCREEN_OFFSET + 1, koutput->connector_type_id); > -#endif > else > snprintf(name, 32, "%s-%d", output_names[koutput->connector_type], koutput->connector_type_id); > } > From emil.l.velikov at gmail.com Mon Oct 24 09:39:58 2016 From: emil.l.velikov at gmail.com (Emil Velikov) Date: Mon, 24 Oct 2016 10:39:58 +0100 Subject: [PATCH xserver] configure.ac: bump epoxy requirement to 1.2 Message-ID: <20161024093958.1877-1-emil.l.velikov@gmail.com> From: Emil Velikov As pointed out in the ABI tracker[1], epoxy has gone through a few non-backwards compatible ABI changes, yet preserved the DSO name. Most noticeable of which, from xserver POV, in epoxy_has_egl_extension() - s/EGLDisplay */EGLDisplay/. To avoid unwanted/unexpected 'fun' behaviour, just bump the requirement. Version 1.2 has been released more than 2 years ago, in May 2014. [1] https://abi-laboratory.pro/tracker/timeline/libepoxy/ Cc: Eric Anholt Cc: Dave Airlie Signed-off-by: Emil Velikov --- We might want this in the stable branch(es)? Eric, iirc Dave had some ideas about moving libepoxy to fd.o [+ making it the canonical/upstream source] and was looking for your blessing. How is that going ? The state of the github repo looks tragic. --- configure.ac | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 2e35abf..2aa8c85 100644 --- a/configure.ac +++ b/configure.ac @@ -828,6 +828,7 @@ LIBDMX="dmx >= 1.0.99.1" LIBDRI="dri >= 7.8.0" LIBDRM="libdrm >= 2.3.1" LIBEGL="egl" +LIBEPOXY="epoxy >= 1.2" LIBGBM="gbm >= 10.2.0" LIBGL="gl >= 7.1.0" LIBXEXT="xext >= 1.0.99.4" @@ -2150,7 +2151,7 @@ AM_CONDITIONAL([GLAMOR], [test "x$GLAMOR" = xyes]) if test "x$GLAMOR" = xyes; then AC_DEFINE(GLAMOR, 1, [Build glamor]) - PKG_CHECK_MODULES([GLAMOR], [epoxy]) + PKG_CHECK_MODULES([GLAMOR], [$LIBEPOXY]) PKG_CHECK_MODULES(GBM, "$LIBGBM", [GBM=yes], [GBM=no]) if test "x$GBM" = xyes; then @@ -2503,7 +2504,7 @@ AM_CONDITIONAL(XFAKESERVER, [test "x$KDRIVE" = xyes && test "x$XFAKE" = xyes]) dnl Xwayland DDX -XWAYLANDMODULES="wayland-client >= 1.3.0 $LIBDRM epoxy" +XWAYLANDMODULES="wayland-client >= 1.3.0 $LIBDRM $LIBEPOXY" if test "x$XF86VIDMODE" = xyes; then XWAYLANDMODULES="$XWAYLANDMODULES $VIDMODEPROTO" fi -- 2.10.0 From martin.peres at linux.intel.com Mon Oct 24 12:26:36 2016 From: martin.peres at linux.intel.com (Martin Peres) Date: Mon, 24 Oct 2016 15:26:36 +0300 Subject: [PATCH rendercheck] Report results on a per-test basis In-Reply-To: <87funpfzfa.fsf@eliezer.anholt.net> References: <20161006140535.32211-1-martin.peres@linux.intel.com> <87funpfzfa.fsf@eliezer.anholt.net> Message-ID: On 21/10/16 19:18, Eric Anholt wrote: > Martin Peres writes: > >> This allows a runner such as EzBench to track each test individually >> and not limit the resolution to groups. >> >> This feature can be triggered by using the -r parameter. > > I don't really see the point of this -- you need an external runner to > be choosing a specific test subset to run per rendercheck call, since > the full matrix of composite tests is too long. Once you have an > external runner calling rendercheck per test group, all you would be > able to do using this patch would be save a few spawns of the process, > which doesn't seem worth it. Just to be sure, are you suggesting I do something like this instead? for format in "a8r8g8b8 x8r8g8b8 ... more formats"; do ./rendercheck -f $format # parse the successful groups and store them, prefixed by $format so as I can identify regressions per format? done if so, then I agree that this will work for some groups of tests but not the ones trying the different combinations of formats, such as : ## ConjointXor linear gradient dst=a8r8g8b8, src=(1x1R a8r8g8b8, 1.00:1.00:1.00:1.00): pass ## ConjointXor linear gradient dst=a8r8g8b8, src=(1x1R x8r8g8b8, 1.00:1.00:1.00:1.00): pass or the ones that do multiple sub-tests, like: ## Src Triangles a8r8g8b8: pass ## Src TriStrip a8r8g8b8: pass ## Src TriFan a8r8g8b8: pass Indeed, I would like to know with the smallest granularity possible what are the results for all the sub-tests so as I can bisect as many changes possible instead of bisecting to the first change that broke the group of tests, having a double for-loop to go through all the combination of composite tests is orthogonal to this problem. This was useful for me to bisect a kernel change that broke rendering with glamor. It would have had had less chances of succeeding without this patch because multiple changes might have happened. Anyway, don't you think this is also nice from a developer perspective to know what test(s) actually broke in a group, instead of having to download rendercheck's source, patch it to add debug printfs, recompile and re-run? Given how piglit works and how devs love sub-tests, I think I am not the only one here. Martin From mattst88 at gmail.com Mon Oct 24 19:19:42 2016 From: mattst88 at gmail.com (Matt Turner) Date: Mon, 24 Oct 2016 12:19:42 -0700 Subject: [PATCH xserver] configure.ac: bump epoxy requirement to 1.2 In-Reply-To: <20161024093958.1877-1-emil.l.velikov@gmail.com> References: <20161024093958.1877-1-emil.l.velikov@gmail.com> Message-ID: On Mon, Oct 24, 2016 at 2:39 AM, Emil Velikov wrote: > From: Emil Velikov > > As pointed out in the ABI tracker[1], epoxy has gone through a few > non-backwards compatible ABI changes, yet preserved the DSO name. > > Most noticeable of which, from xserver POV, in epoxy_has_egl_extension() > - s/EGLDisplay */EGLDisplay/. > > To avoid unwanted/unexpected 'fun' behaviour, just bump the requirement. > Version 1.2 has been released more than 2 years ago, in May 2014. > > [1] https://abi-laboratory.pro/tracker/timeline/libepoxy/ > Cc: Eric Anholt > Cc: Dave Airlie > Signed-off-by: Emil Velikov > --- > We might want this in the stable branch(es)? > > Eric, iirc Dave had some ideas about moving libepoxy to fd.o [+ making > it the canonical/upstream source] and was looking for your blessing. > > How is that going ? The state of the github repo looks tragic. ajax and anholt were talking about epoxy's status at XDC. Cc'ing ajax. From agoins at nvidia.com Mon Oct 24 22:25:53 2016 From: agoins at nvidia.com (Alex Goins) Date: Mon, 24 Oct 2016 15:25:53 -0700 Subject: [PATCH] ramdac: Check sPriv != NULL in xf86CheckHWCursor() Message-ID: <1477347953-9687-1-git-send-email-agoins@nvidia.com> xf86CheckHWCursor() would dereference sPriv without NULL checking it. If Option "SWCursor" is specified, sPriv == NULL. In this case we should assume that HW cursors are not supported. Signed-off-by: Alex Goins Reviewed-by: Andy Ritger --- hw/xfree86/ramdac/xf86HWCurs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/hw/xfree86/ramdac/xf86HWCurs.c b/hw/xfree86/ramdac/xf86HWCurs.c index da2b181..5e99526 100644 --- a/hw/xfree86/ramdac/xf86HWCurs.c +++ b/hw/xfree86/ramdac/xf86HWCurs.c @@ -148,7 +148,8 @@ xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor, xf86CursorInfoPtr infoPtr continue; sPriv = dixLookupPrivate(&pSlave->devPrivates, xf86CursorScreenKey); - if (!xf86ScreenCheckHWCursor(pSlave, cursor, sPriv->CursorInfoPtr)) + if (!sPriv || + !xf86ScreenCheckHWCursor(pSlave, cursor, sPriv->CursorInfoPtr)) return FALSE; } return TRUE; -- 1.9.1 From wharms at bfs.de Tue Oct 25 08:10:15 2016 From: wharms at bfs.de (walter harms) Date: Tue, 25 Oct 2016 10:10:15 +0200 Subject: [PATCH] ramdac: Check sPriv != NULL in xf86CheckHWCursor() In-Reply-To: <1477347953-9687-1-git-send-email-agoins@nvidia.com> References: <1477347953-9687-1-git-send-email-agoins@nvidia.com> Message-ID: <580F1367.4030906@bfs.de> Am 25.10.2016 00:25, schrieb Alex Goins: > xf86CheckHWCursor() would dereference sPriv without NULL checking it. If Option > "SWCursor" is specified, sPriv == NULL. In this case we should assume that HW > cursors are not supported. > > Signed-off-by: Alex Goins > Reviewed-by: Andy Ritger > --- > hw/xfree86/ramdac/xf86HWCurs.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/hw/xfree86/ramdac/xf86HWCurs.c b/hw/xfree86/ramdac/xf86HWCurs.c > index da2b181..5e99526 100644 > --- a/hw/xfree86/ramdac/xf86HWCurs.c > +++ b/hw/xfree86/ramdac/xf86HWCurs.c > @@ -148,7 +148,8 @@ xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor, xf86CursorInfoPtr infoPtr > continue; > > sPriv = dixLookupPrivate(&pSlave->devPrivates, xf86CursorScreenKey); > - if (!xf86ScreenCheckHWCursor(pSlave, cursor, sPriv->CursorInfoPtr)) > + if (!sPriv || > + !xf86ScreenCheckHWCursor(pSlave, cursor, sPriv->CursorInfoPtr)) > return FALSE; > } > return TRUE; I would go for 2 lines that will make things more clear also adding a comment would help future debugging operations. 1. if (!sPriv) return FALSE; /* maybe option "SWCursor" */ 2. if (!xf86ScreenCheckHWCursor(pSlave, cursor, sPriv->CursorInfoPtr)) /* HWCursor not supported */ just my 2 cents, re, wh From hdegoede at redhat.com Tue Oct 25 08:11:16 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Tue, 25 Oct 2016 10:11:16 +0200 Subject: [PATCH] ramdac: Check sPriv != NULL in xf86CheckHWCursor() In-Reply-To: <1477347953-9687-1-git-send-email-agoins@nvidia.com> References: <1477347953-9687-1-git-send-email-agoins@nvidia.com> Message-ID: <3d482288-e4c9-0417-6778-2126defaedb5@redhat.com> Hi, On 25-10-16 00:25, Alex Goins wrote: > xf86CheckHWCursor() would dereference sPriv without NULL checking it. If Option > "SWCursor" is specified, sPriv == NULL. In this case we should assume that HW > cursors are not supported. > > Signed-off-by: Alex Goins > Reviewed-by: Andy Ritger Patch looks good to me: Reviewed-by: Hans de Goede Regards, Hans > --- > hw/xfree86/ramdac/xf86HWCurs.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/hw/xfree86/ramdac/xf86HWCurs.c b/hw/xfree86/ramdac/xf86HWCurs.c > index da2b181..5e99526 100644 > --- a/hw/xfree86/ramdac/xf86HWCurs.c > +++ b/hw/xfree86/ramdac/xf86HWCurs.c > @@ -148,7 +148,8 @@ xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor, xf86CursorInfoPtr infoPtr > continue; > > sPriv = dixLookupPrivate(&pSlave->devPrivates, xf86CursorScreenKey); > - if (!xf86ScreenCheckHWCursor(pSlave, cursor, sPriv->CursorInfoPtr)) > + if (!sPriv || > + !xf86ScreenCheckHWCursor(pSlave, cursor, sPriv->CursorInfoPtr)) > return FALSE; > } > return TRUE; > From ajax at redhat.com Tue Oct 25 14:59:51 2016 From: ajax at redhat.com (Adam Jackson) Date: Tue, 25 Oct 2016 10:59:51 -0400 Subject: [PATCH xserver] configure.ac: bump epoxy requirement to 1.2 In-Reply-To: References: <20161024093958.1877-1-emil.l.velikov@gmail.com> Message-ID: <1477407591.29084.14.camel@redhat.com> On Mon, 2016-10-24 at 12:19 -0700, Matt Turner wrote: > On Mon, Oct 24, 2016 at 2:39 AM, Emil Velikov wrote: > > > > From: Emil Velikov > > > > As pointed out in the ABI tracker[1], epoxy has gone through a few > > non-backwards compatible ABI changes, yet preserved the DSO name. I don't particularly object to bumping the required version, but... > > Most noticeable of which, from xserver POV, in epoxy_has_egl_extension() > > - s/EGLDisplay */EGLDisplay/. This happens not to matter. If you read the corresponding commit you'll see that the parameter was always treated as an opaque pointer anyway: https://github.com/anholt/libepoxy/commit/e20b3ce6c7895f355fd1bad81b45341d98b5ee76 > > Eric, iirc Dave had some ideas about moving libepoxy to fd.o [+ making > > it the canonical/upstream source] and was looking for your blessing. > > > > How is that going ? The state of the github repo looks tragic. > > ajax and anholt were talking about epoxy's status at XDC. Cc'ing ajax. I'm honestly on anholt's side here about leaving upstream on github. fdo is lovely and all but the contribution model for people not already in posession of an fdo account is terrible. Moving epoxy to fdo would be a step backwards, and we should continue to hold out on that front until fdo grows better collaborative hosting. The more serious issue to me is that epoxy needs a release, and that release should involve merging up the various forks on github. (This is an argument _in favor_ of github: not only was it easy for people to create their forks, but we can track them all down easily.) I'm sure epoxy isn't Eric's first priority (which is entirely reasonable) so it's kind of up to him how to proceed here. - ajax From eric at anholt.net Tue Oct 25 15:50:37 2016 From: eric at anholt.net (Eric Anholt) Date: Tue, 25 Oct 2016 08:50:37 -0700 Subject: [PATCH xserver] configure.ac: bump epoxy requirement to 1.2 In-Reply-To: <1477407591.29084.14.camel@redhat.com> References: <20161024093958.1877-1-emil.l.velikov@gmail.com> <1477407591.29084.14.camel@redhat.com> Message-ID: <87lgxc1l82.fsf@eliezer.anholt.net> Adam Jackson writes: > On Mon, 2016-10-24 at 12:19 -0700, Matt Turner wrote: >> On Mon, Oct 24, 2016 at 2:39 AM, Emil Velikov wrote: >> > > > From: Emil Velikov >> > >> > As pointed out in the ABI tracker[1], epoxy has gone through a few >> > non-backwards compatible ABI changes, yet preserved the DSO name. > > I don't particularly object to bumping the required version, but... > >> > Most noticeable of which, from xserver POV, in epoxy_has_egl_extension() >> > - s/EGLDisplay */EGLDisplay/. > > This happens not to matter. If you read the corresponding commit you'll > see that the parameter was always treated as an opaque pointer anyway: > > https://github.com/anholt/libepoxy/commit/e20b3ce6c7895f355fd1bad81b45341d98b5ee76 > >> > Eric, iirc Dave had some ideas about moving libepoxy to fd.o [+ making >> > it the canonical/upstream source] and was looking for your blessing. >> > >> > How is that going ? The state of the github repo looks tragic. >> >> ajax and anholt were talking about epoxy's status at XDC. Cc'ing ajax. > > I'm honestly on anholt's side here about leaving upstream on github. > fdo is lovely and all but the contribution model for people not already > in posession of an fdo account is terrible. Moving epoxy to fdo would > be a step backwards, and we should continue to hold out on that front > until fdo grows better collaborative hosting. > > The more serious issue to me is that epoxy needs a release, and that > release should involve merging up the various forks on github. (This is > an argument _in favor_ of github: not only was it easy for people to > create their forks, but we can track them all down easily.) I'm sure > epoxy isn't Eric's first priority (which is entirely reasonable) so > it's kind of up to him how to proceed here. I've said it before a couple of times, but it stands: The next step for epoxy is that someone needs to look into YaronCT's fork and decide if we should just bless it as the maintained upstream. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From ajax at redhat.com Tue Oct 25 16:36:45 2016 From: ajax at redhat.com (Adam Jackson) Date: Tue, 25 Oct 2016 12:36:45 -0400 Subject: [PATCH xserver] configure.ac: bump epoxy requirement to 1.2 In-Reply-To: <87lgxc1l82.fsf@eliezer.anholt.net> References: <20161024093958.1877-1-emil.l.velikov@gmail.com> <1477407591.29084.14.camel@redhat.com> <87lgxc1l82.fsf@eliezer.anholt.net> Message-ID: <1477413405.29084.18.camel@redhat.com> On Tue, 2016-10-25 at 08:50 -0700, Eric Anholt wrote: > I've said it before a couple of times, but it stands: The next step for > epoxy is that someone needs to look into YaronCT's fork and decide if we > should just bless it as the maintained upstream. Just read through the diff between your branch and Yaron's, it all looks good to me. Including a epoxy_egl_get_current_gl_context_api fix that I'd independently written long after the fact. I'll move my pull requests over. - ajax From tiagomatos at gmail.com Tue Oct 25 17:24:49 2016 From: tiagomatos at gmail.com (Rui Matos) Date: Tue, 25 Oct 2016 19:24:49 +0200 Subject: [PATCH xserver] xwayland: Transform pointer enter event coordinates Message-ID: <20161025172449.3892-1-tiagomatos@gmail.com> Pointer enter event coordinates are surface relative and we need them to be screen relative for pScreen->SetCursorPosition(). https://bugzilla.gnome.org/show_bug.cgi?id=758283 Signed-off-by: Rui Matos --- hw/xwayland/xwayland-input.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c index f2327dc..1352197 100644 --- a/hw/xwayland/xwayland-input.c +++ b/hw/xwayland/xwayland-input.c @@ -298,6 +298,7 @@ pointer_handle_enter(void *data, struct wl_pointer *pointer, int i; int sx = wl_fixed_to_int(sx_w); int sy = wl_fixed_to_int(sy_w); + int dx, dy; ScreenPtr pScreen = xwl_seat->xwl_screen->screen; ValuatorMask mask; @@ -314,9 +315,11 @@ pointer_handle_enter(void *data, struct wl_pointer *pointer, xwl_seat->pointer_enter_serial = serial; xwl_seat->focus_window = wl_surface_get_user_data(surface); + dx = xwl_seat->focus_window->window->drawable.x; + dy = xwl_seat->focus_window->window->drawable.y; master = GetMaster(dev, POINTER_OR_FLOAT); - (*pScreen->SetCursorPosition) (dev, pScreen, sx, sy, TRUE); + (*pScreen->SetCursorPosition) (dev, pScreen, dx + sx, dy + sy, TRUE); miPointerInvalidateSprite(master); -- 2.9.3 From eric.engestrom at imgtec.com Tue Oct 25 17:32:11 2016 From: eric.engestrom at imgtec.com (Eric Engestrom) Date: Tue, 25 Oct 2016 18:32:11 +0100 Subject: [PATCH xserver] xwayland: Transform pointer enter event coordinates In-Reply-To: <20161025172449.3892-1-tiagomatos@gmail.com> References: <20161025172449.3892-1-tiagomatos@gmail.com> Message-ID: <20161025173211.GH32235@imgtec.com> On Tuesday, 2016-10-25 19:24:49 +0200, Rui Matos wrote: > Pointer enter event coordinates are surface relative and we need them > to be screen relative for pScreen->SetCursorPosition(). > > https://bugzilla.gnome.org/show_bug.cgi?id=758283 > > Signed-off-by: Rui Matos LGTM :) Reviewed-by: Eric Engestrom > --- > hw/xwayland/xwayland-input.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c > index f2327dc..1352197 100644 > --- a/hw/xwayland/xwayland-input.c > +++ b/hw/xwayland/xwayland-input.c > @@ -298,6 +298,7 @@ pointer_handle_enter(void *data, struct wl_pointer *pointer, > int i; > int sx = wl_fixed_to_int(sx_w); > int sy = wl_fixed_to_int(sy_w); > + int dx, dy; > ScreenPtr pScreen = xwl_seat->xwl_screen->screen; > ValuatorMask mask; > > @@ -314,9 +315,11 @@ pointer_handle_enter(void *data, struct wl_pointer *pointer, > xwl_seat->pointer_enter_serial = serial; > > xwl_seat->focus_window = wl_surface_get_user_data(surface); > + dx = xwl_seat->focus_window->window->drawable.x; > + dy = xwl_seat->focus_window->window->drawable.y; > > master = GetMaster(dev, POINTER_OR_FLOAT); > - (*pScreen->SetCursorPosition) (dev, pScreen, sx, sy, TRUE); > + (*pScreen->SetCursorPosition) (dev, pScreen, dx + sx, dy + sy, TRUE); > > miPointerInvalidateSprite(master); > > -- > 2.9.3 > From pochu at debian.org Tue Oct 25 19:30:15 2016 From: pochu at debian.org (Emilio Pozuelo Monfort) Date: Tue, 25 Oct 2016 21:30:15 +0200 Subject: [PATCH libx11] Plug a memory leak Message-ID: <20161025193015.5026-1-pochu@debian.org> This was introduced in 8ea762f. Reported-by: Julien Cristau Signed-off-by: Emilio Pozuelo Monfort --- src/FontNames.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/FontNames.c b/src/FontNames.c index e55f338..3e23b5f 100644 --- a/src/FontNames.c +++ b/src/FontNames.c @@ -98,12 +98,14 @@ int *actualCount) /* RETURN */ *ch = '\0'; /* and replace with null-termination */ count++; } else { + Xfree(ch); Xfree(flist); flist = NULL; count = 0; break; } } else { + Xfree(ch); Xfree(flist); flist = NULL; count = 0; -- 2.9.3 From pochu at debian.org Tue Oct 25 19:31:18 2016 From: pochu at debian.org (Emilio Pozuelo Monfort) Date: Tue, 25 Oct 2016 21:31:18 +0200 Subject: [PATCH libxi 1/2] Plug a memory leak Message-ID: <20161025193119.5127-1-pochu@debian.org> Introduced in commit 19a9cd6. Reported-by: Julien Cristau Signed-off-by: Emilio Pozuelo Monfort --- src/XIQueryDevice.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/XIQueryDevice.c b/src/XIQueryDevice.c index a457cd6..e3b0c9f 100644 --- a/src/XIQueryDevice.c +++ b/src/XIQueryDevice.c @@ -135,6 +135,8 @@ error_loop: Xfree(info[i].name); Xfree(info[i].classes); } + Xfree(info); + Xfree(buf); error: UnlockDisplay(dpy); error_unlocked: -- 2.9.3 From pochu at debian.org Tue Oct 25 19:31:19 2016 From: pochu at debian.org (Emilio Pozuelo Monfort) Date: Tue, 25 Oct 2016 21:31:19 +0200 Subject: [PATCH libxi 2/2] Check that allocating a buffer succeeded In-Reply-To: <20161025193119.5127-1-pochu@debian.org> References: <20161025193119.5127-1-pochu@debian.org> Message-ID: <20161025193119.5127-2-pochu@debian.org> Since we are going to write into the buffer, we should make sure the allocation didn't fail. Reported-by: Julien Cristau Signed-off-by: Emilio Pozuelo Monfort --- src/XIQueryDevice.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/src/XIQueryDevice.c b/src/XIQueryDevice.c index e3b0c9f..a877d78 100644 --- a/src/XIQueryDevice.c +++ b/src/XIQueryDevice.c @@ -66,17 +66,18 @@ XIQueryDevice(Display *dpy, int deviceid, int *ndevices_return) { *ndevices_return = reply.num_devices; info = Xmalloc((reply.num_devices + 1) * sizeof(XIDeviceInfo)); + buf = Xmalloc(reply.length * 4); } else { *ndevices_return = 0; info = NULL; + buf = NULL; } - if (!info) + if (!info || !buf) goto error; - buf = Xmalloc(reply.length * 4); _XRead(dpy, buf, reply.length * 4); ptr = buf; end = buf + reply.length * 4; @@ -135,9 +136,9 @@ error_loop: Xfree(info[i].name); Xfree(info[i].classes); } +error: Xfree(info); Xfree(buf); -error: UnlockDisplay(dpy); error_unlocked: SyncHandle(); -- 2.9.3 From ajax at redhat.com Tue Oct 25 21:00:44 2016 From: ajax at redhat.com (Adam Jackson) Date: Tue, 25 Oct 2016 17:00:44 -0400 Subject: [PATCH xserver] glamor: don't look for non-existing EGL_KHR_platform_base In-Reply-To: <20161021180600.6092-1-emil.l.velikov@gmail.com> References: <20161021180600.6092-1-emil.l.velikov@gmail.com> Message-ID: <1477429244.29084.27.camel@redhat.com> On Fri, 2016-10-21 at 19:06 +0100, Emil Velikov wrote: > > From: Emil Velikov > > The extensions does not exist in the registry, thus needs to know > they're using EGL 1.5 in order to determine the eglGetPlatformDisplay > function pointer is valid. > > Thus brings us into some lovely circular dependency. Ugh. Right you are, I seem to have gotten a bit optimistic by seeing other EGL_KHR_platform_* extensions. > In practise (checked with the Mali driver) any EGL 1.5 driver will > advertise support for EGL_EXT_platform_base. Yeah, I think this pretty much has to be true. The whole point of the platform extensions is that you have to use them _before_ you have an EGL context, meaning you can't know if you're EGL 1.5 ahead of time. It's kinda lame that 1.5 doesn't have a mandatory extension string for this (since the KHR entrypoints really do have a different signature) but that's Khronos' bug not Xorg's. Merged, thanks: remote: I: patch #117260 updated using rev 7fc96fb02dade4a86f2fc038f3cf5f2d9c0cda00. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver 5dcb066..7fc96fb master -> master - ajax From peter.hutterer at who-t.net Tue Oct 25 21:58:32 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Wed, 26 Oct 2016 07:58:32 +1000 Subject: [PATCH libxi 2/2] Check that allocating a buffer succeeded In-Reply-To: <20161025193119.5127-2-pochu@debian.org> References: <20161025193119.5127-1-pochu@debian.org> <20161025193119.5127-2-pochu@debian.org> Message-ID: <20161025215832.GA8224@jelly.local> On Tue, Oct 25, 2016 at 09:31:19PM +0200, Emilio Pozuelo Monfort wrote: > Since we are going to write into the buffer, we should make sure the > allocation didn't fail. > > Reported-by: Julien Cristau > Signed-off-by: Emilio Pozuelo Monfort both applied, thanks. 1bdeb43..4c5c8d6 master -> master Cheers, Peter > --- > src/XIQueryDevice.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/src/XIQueryDevice.c b/src/XIQueryDevice.c > index e3b0c9f..a877d78 100644 > --- a/src/XIQueryDevice.c > +++ b/src/XIQueryDevice.c > @@ -66,17 +66,18 @@ XIQueryDevice(Display *dpy, int deviceid, int *ndevices_return) > { > *ndevices_return = reply.num_devices; > info = Xmalloc((reply.num_devices + 1) * sizeof(XIDeviceInfo)); > + buf = Xmalloc(reply.length * 4); > } > else > { > *ndevices_return = 0; > info = NULL; > + buf = NULL; > } > > - if (!info) > + if (!info || !buf) > goto error; > > - buf = Xmalloc(reply.length * 4); > _XRead(dpy, buf, reply.length * 4); > ptr = buf; > end = buf + reply.length * 4; > @@ -135,9 +136,9 @@ error_loop: > Xfree(info[i].name); > Xfree(info[i].classes); > } > +error: > Xfree(info); > Xfree(buf); > -error: > UnlockDisplay(dpy); > error_unlocked: > SyncHandle(); > -- > 2.9.3 > > _______________________________________________ > xorg-devel at lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel > From ian.ray at ge.com Tue Oct 25 12:56:56 2016 From: ian.ray at ge.com (Ian Ray) Date: Tue, 25 Oct 2016 15:56:56 +0300 Subject: EXT: Re: [xserver-xorg][PATCH V2 1/1] xwayland-shm: block signals during fallocate In-Reply-To: References: Message-ID: <20161025125655.GB7857@ubian> On Thu, May 26, 2016 at 04:43:44PM +0100, Daniel Stone wrote: > On 25 May 2016 at 08:41, Ian Ray wrote: > > posix_fallocate() does an explicit rollback if it gets EINTR, and > > this is a problem on slow systems because when the allocation size > > is sufficiently large posix_fallocate() will always be interrupted > > by the smart scheduler's SIGALRM. > > > > Changes since v1 - big comment in the code to explain what is going on > > > > Signed-off-by: Ian Ray > > Acked-by: Daniel Stone Any news on this? f48b0534f110397246809d279225afedb28aa233 does not resolve the EINTR on slow systems. From jadahl at gmail.com Wed Oct 26 04:09:08 2016 From: jadahl at gmail.com (Jonas =?iso-8859-1?Q?=C5dahl?=) Date: Wed, 26 Oct 2016 12:09:08 +0800 Subject: [PATCH xserver] xwayland: Transform pointer enter event coordinates In-Reply-To: <20161025172449.3892-1-tiagomatos@gmail.com> References: <20161025172449.3892-1-tiagomatos@gmail.com> Message-ID: <20161026040907.GA8979@gmail.com> On Tue, Oct 25, 2016 at 07:24:49PM +0200, Rui Matos wrote: > Pointer enter event coordinates are surface relative and we need them > to be screen relative for pScreen->SetCursorPosition(). > > https://bugzilla.gnome.org/show_bug.cgi?id=758283 > > Signed-off-by: Rui Matos Reviewed-by: Jonas Ådahl > --- > hw/xwayland/xwayland-input.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c > index f2327dc..1352197 100644 > --- a/hw/xwayland/xwayland-input.c > +++ b/hw/xwayland/xwayland-input.c > @@ -298,6 +298,7 @@ pointer_handle_enter(void *data, struct wl_pointer *pointer, > int i; > int sx = wl_fixed_to_int(sx_w); > int sy = wl_fixed_to_int(sy_w); > + int dx, dy; > ScreenPtr pScreen = xwl_seat->xwl_screen->screen; > ValuatorMask mask; > > @@ -314,9 +315,11 @@ pointer_handle_enter(void *data, struct wl_pointer *pointer, > xwl_seat->pointer_enter_serial = serial; > > xwl_seat->focus_window = wl_surface_get_user_data(surface); > + dx = xwl_seat->focus_window->window->drawable.x; > + dy = xwl_seat->focus_window->window->drawable.y; > > master = GetMaster(dev, POINTER_OR_FLOAT); > - (*pScreen->SetCursorPosition) (dev, pScreen, sx, sy, TRUE); > + (*pScreen->SetCursorPosition) (dev, pScreen, dx + sx, dy + sy, TRUE); > > miPointerInvalidateSprite(master); > > -- > 2.9.3 > > _______________________________________________ > xorg-devel at lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel From peter.hutterer at who-t.net Wed Oct 26 05:08:23 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Wed, 26 Oct 2016 15:08:23 +1000 Subject: [PATCH xf86-input-libinput] Don't init the AccelSpeed/LeftHanded properties on the base tablet device Message-ID: <20161026050823.GA18551@jelly.local> This device never sends events, no point in exposing these options Signed-off-by: Peter Hutterer --- src/xf86libinput.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/xf86libinput.c b/src/xf86libinput.c index 8ee6cbe..07b4d4e 100644 --- a/src/xf86libinput.c +++ b/src/xf86libinput.c @@ -4092,7 +4092,8 @@ LibinputInitAccelProperty(DeviceIntPtr dev, enum libinput_config_accel_profile profile; BOOL profiles[2] = {FALSE}; - if (!libinput_device_config_accel_is_available(device)) + if (!libinput_device_config_accel_is_available(device) || + driver_data->capabilities & CAP_TABLET) return; prop_accel = LibinputMakeProperty(dev, @@ -4260,7 +4261,8 @@ LibinputInitLeftHandedProperty(DeviceIntPtr dev, { BOOL left_handed = driver_data->options.left_handed; - if (!libinput_device_config_left_handed_is_available(device)) + if (!libinput_device_config_left_handed_is_available(device) || + driver_data->capabilities & CAP_TABLET) return; prop_left_handed = LibinputMakeProperty(dev, -- 2.9.3 From peter.hutterer at who-t.net Wed Oct 26 05:46:51 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Wed, 26 Oct 2016 15:46:51 +1000 Subject: [PATCH libx11] Plug a memory leak In-Reply-To: <20161025193015.5026-1-pochu@debian.org> References: <20161025193015.5026-1-pochu@debian.org> Message-ID: <20161026054651.GA20838@jelly.local> On Tue, Oct 25, 2016 at 09:30:15PM +0200, Emilio Pozuelo Monfort wrote: > This was introduced in 8ea762f. > > Reported-by: Julien Cristau > Signed-off-by: Emilio Pozuelo Monfort pushed, thanks. 8f349fe..20a3f99 master -> master Cheers, Peter > --- > src/FontNames.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/src/FontNames.c b/src/FontNames.c > index e55f338..3e23b5f 100644 > --- a/src/FontNames.c > +++ b/src/FontNames.c > @@ -98,12 +98,14 @@ int *actualCount) /* RETURN */ > *ch = '\0'; /* and replace with null-termination */ > count++; > } else { > + Xfree(ch); > Xfree(flist); > flist = NULL; > count = 0; > break; > } > } else { > + Xfree(ch); > Xfree(flist); > flist = NULL; > count = 0; > -- > 2.9.3 > > _______________________________________________ > xorg-devel at lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel > From eric.engestrom at imgtec.com Wed Oct 26 09:13:28 2016 From: eric.engestrom at imgtec.com (Eric Engestrom) Date: Wed, 26 Oct 2016 10:13:28 +0100 Subject: [PATCH xf86-input-libinput] Don't init the AccelSpeed/LeftHanded properties on the base tablet device In-Reply-To: <20161026050823.GA18551@jelly.local> References: <20161026050823.GA18551@jelly.local> Message-ID: <20161026091328.GI32235@imgtec.com> On Wednesday, 2016-10-26 15:08:23 +1000, Peter Hutterer wrote: > This device never sends events, no point in exposing these options > > Signed-off-by: Peter Hutterer Does what it says on the tin :) Reviewed-by: Eric Engestrom > --- > src/xf86libinput.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/src/xf86libinput.c b/src/xf86libinput.c > index 8ee6cbe..07b4d4e 100644 > --- a/src/xf86libinput.c > +++ b/src/xf86libinput.c > @@ -4092,7 +4092,8 @@ LibinputInitAccelProperty(DeviceIntPtr dev, > enum libinput_config_accel_profile profile; > BOOL profiles[2] = {FALSE}; > > - if (!libinput_device_config_accel_is_available(device)) > + if (!libinput_device_config_accel_is_available(device) || > + driver_data->capabilities & CAP_TABLET) > return; > > prop_accel = LibinputMakeProperty(dev, > @@ -4260,7 +4261,8 @@ LibinputInitLeftHandedProperty(DeviceIntPtr dev, > { > BOOL left_handed = driver_data->options.left_handed; > > - if (!libinput_device_config_left_handed_is_available(device)) > + if (!libinput_device_config_left_handed_is_available(device) || > + driver_data->capabilities & CAP_TABLET) > return; > > prop_left_handed = LibinputMakeProperty(dev, > -- > 2.9.3 > From hdegoede at redhat.com Wed Oct 26 10:21:16 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Wed, 26 Oct 2016 12:21:16 +0200 Subject: [PATCH xserver v2] inputthread: On Linux leave the main thread's name as-is Message-ID: <20161026102116.19035-1-hdegoede@redhat.com> From: Peter Hutterer On Linux, setting the main thread's name changes the program name (/proc/self/comm). Setting it to MainThread breaks scripts that rely on the command name, e.g. ps -C Xorg. Signed-off-by: Peter Hutterer Signed-off-by: Hans de Goede --- Changes in v2 (hdegoede): -Only leave the main thread as-is in Linux, naming it is not an issue on other platforms --- os/inputthread.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/os/inputthread.c b/os/inputthread.c index ddafa7f..8e7f2ed 100644 --- a/os/inputthread.c +++ b/os/inputthread.c @@ -431,11 +431,13 @@ InputThreadPreInit(void) } hotplugPipeWrite = hotplugPipe[1]; +#ifndef __linux__ /* Linux does not deal well with renaming the main thread */ #if defined(HAVE_PTHREAD_SETNAME_NP_WITH_TID) pthread_setname_np (pthread_self(), "MainThread"); #elif defined(HAVE_PTHREAD_SETNAME_NP_WITHOUT_TID) pthread_setname_np ("MainThread"); #endif +#endif } -- 2.9.3 From hdegoede at redhat.com Wed Oct 26 10:26:37 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Wed, 26 Oct 2016 12:26:37 +0200 Subject: [xserver PULL for 1.19 ] Various small fixes for 1.19 Message-ID: Hi Adam, Keith, Here is a pull-req with various small fixes (all with at least 1 Reviewed-by) which I've collected for merging into 1.19: The following changes since commit d13cb974426f7f1110b0bdb08c4ebb46ff8975f7: ddx: add new call to purge input devices that weren't added (2016-10-26 15:35:07 +1000) are available in the git repository at: git://people.freedesktop.org/~jwrdegoede/xserver for-server-1.19 for you to fetch changes up to 7b135f5e7d79622c0b922de8ee827a2556504d8f: xwayland: Transform pointer enter event coordinates (2016-10-26 11:51:38 +0200) ---------------------------------------------------------------- Hans de Goede (1): xfree86: Xorg.wrap: Do not require root rights for cards with 0 outputs Michel Dänzer (1): DRI2: Sync radeonsi_pci_ids.h from Mesa Mihail Konev (2): xwin: make glx optional again modesetting: fix glamor ifdef Nikhil Mahale (1): modesetting: unifdef MODESETTING_OUTPUT_SLAVE_SUPPORT Rui Matos (1): xwayland: Transform pointer enter event coordinates configure.ac | 4 ++-- hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h | 12 ++++++++++++ hw/xfree86/drivers/modesetting/driver.c | 2 ++ hw/xfree86/drivers/modesetting/drmmode_display.c | 2 -- hw/xfree86/xorg-wrapper.c | 2 +- hw/xwayland/xwayland-input.c | 5 ++++- 6 files changed, 21 insertions(+), 6 deletions(-) Regards, Hans From emil.l.velikov at gmail.com Wed Oct 26 10:29:00 2016 From: emil.l.velikov at gmail.com (Emil Velikov) Date: Wed, 26 Oct 2016 11:29:00 +0100 Subject: [PATCH xserver] configure.ac: bump epoxy requirement to 1.2 In-Reply-To: <1477407591.29084.14.camel@redhat.com> References: <20161024093958.1877-1-emil.l.velikov@gmail.com> <1477407591.29084.14.camel@redhat.com> Message-ID: On 25 October 2016 at 15:59, Adam Jackson wrote: > On Mon, 2016-10-24 at 12:19 -0700, Matt Turner wrote: >> On Mon, Oct 24, 2016 at 2:39 AM, Emil Velikov wrote: >> > > > From: Emil Velikov >> > >> > As pointed out in the ABI tracker[1], epoxy has gone through a few >> > non-backwards compatible ABI changes, yet preserved the DSO name. > > I don't particularly object to bumping the required version, but... > >> > Most noticeable of which, from xserver POV, in epoxy_has_egl_extension() >> > - s/EGLDisplay */EGLDisplay/. > > This happens not to matter. If you read the corresponding commit you'll > see that the parameter was always treated as an opaque pointer anyway: > > https://github.com/anholt/libepoxy/commit/e20b3ce6c7895f355fd1bad81b45341d98b5ee76 > Maybe coffee hasn't kicked in, but it does seem to matter. Think about: build against pre 1.2 [epoxy] then run against 1.2 or later and you'll get some lovely fireworks. >> > Eric, iirc Dave had some ideas about moving libepoxy to fd.o [+ making >> > it the canonical/upstream source] and was looking for your blessing. >> > >> > How is that going ? The state of the github repo looks tragic. >> >> ajax and anholt were talking about epoxy's status at XDC. Cc'ing ajax. > > I'm honestly on anholt's side here about leaving upstream on github. > fdo is lovely and all but the contribution model for people not already > in posession of an fdo account is terrible. Moving epoxy to fdo would > be a step backwards, and we should continue to hold out on that front > until fdo grows better collaborative hosting. > > The more serious issue to me is that epoxy needs a release, and that > release should involve merging up the various forks on github. (This is > an argument _in favor_ of github: not only was it easy for people to > create their forks, but we can track them all down easily.) I'm sure > epoxy isn't Eric's first priority (which is entirely reasonable) so > it's kind of up to him how to proceed here. > Seems like we've dived into [the] unintended direction. The goal is to see how things start rolling again - would that be fd.o github, whatever. Nitpicking pros/cons for each one is a very subjective and never ending battle that I'd rather not take part of :-) Thanks Emil From hdegoede at redhat.com Wed Oct 26 11:01:41 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Wed, 26 Oct 2016 13:01:41 +0200 Subject: [xserver PULL for 1.19 ] Various small fixes for 1.19 In-Reply-To: References: Message-ID: Hi, On 26-10-16 12:26, Hans de Goede wrote: > Hi Adam, Keith, > > Here is a pull-req with various small fixes > (all with at least 1 Reviewed-by) which I've collected > for merging into 1.19: I just realized I forgot to add this one: https://patchwork.freedesktop.org/patch/117894/ It would be good to merge that patch too IMO. Regards, Hans > > The following changes since commit d13cb974426f7f1110b0bdb08c4ebb46ff8975f7: > > ddx: add new call to purge input devices that weren't added (2016-10-26 15:35:07 +1000) > > are available in the git repository at: > > git://people.freedesktop.org/~jwrdegoede/xserver for-server-1.19 > > for you to fetch changes up to 7b135f5e7d79622c0b922de8ee827a2556504d8f: > > xwayland: Transform pointer enter event coordinates (2016-10-26 11:51:38 +0200) > > ---------------------------------------------------------------- > Hans de Goede (1): > xfree86: Xorg.wrap: Do not require root rights for cards with 0 outputs > > Michel Dänzer (1): > DRI2: Sync radeonsi_pci_ids.h from Mesa > > Mihail Konev (2): > xwin: make glx optional again > modesetting: fix glamor ifdef > > Nikhil Mahale (1): > modesetting: unifdef MODESETTING_OUTPUT_SLAVE_SUPPORT > > Rui Matos (1): > xwayland: Transform pointer enter event coordinates > > configure.ac | 4 ++-- > hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h | 12 ++++++++++++ > hw/xfree86/drivers/modesetting/driver.c | 2 ++ > hw/xfree86/drivers/modesetting/drmmode_display.c | 2 -- > hw/xfree86/xorg-wrapper.c | 2 +- > hw/xwayland/xwayland-input.c | 5 ++++- > 6 files changed, 21 insertions(+), 6 deletions(-) > > Regards, > > Hans From ofourdan at redhat.com Wed Oct 26 12:11:48 2016 From: ofourdan at redhat.com (Olivier Fourdan) Date: Wed, 26 Oct 2016 08:11:48 -0400 (EDT) Subject: [xserver PULL for 1.19 ] Various small fixes for 1.19 In-Reply-To: References: Message-ID: <1378199833.5614147.1477483908248.JavaMail.zimbra@redhat.com> Hi, ----- Original Message ----- > Hi Adam, Keith, > > Here is a pull-req with various small fixes > (all with at least 1 Reviewed-by) which I've collected > for merging into 1.19: > > The following changes since commit d13cb974426f7f1110b0bdb08c4ebb46ff8975f7: > > ddx: add new call to purge input devices that weren't added (2016-10-26 > 15:35:07 +1000) > > are available in the git repository at: > > git://people.freedesktop.org/~jwrdegoede/xserver for-server-1.19 > > for you to fetch changes up to 7b135f5e7d79622c0b922de8ee827a2556504d8f: > > xwayland: Transform pointer enter event coordinates (2016-10-26 11:51:38 > +0200) > > ---------------------------------------------------------------- > Hans de Goede (1): > xfree86: Xorg.wrap: Do not require root rights for cards with 0 > outputs > > Michel Dänzer (1): > DRI2: Sync radeonsi_pci_ids.h from Mesa > > Mihail Konev (2): > xwin: make glx optional again > modesetting: fix glamor ifdef > > Nikhil Mahale (1): > modesetting: unifdef MODESETTING_OUTPUT_SLAVE_SUPPORT > > Rui Matos (1): > xwayland: Transform pointer enter event coordinates > > configure.ac | 4 ++-- > hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h | 12 ++++++++++++ > hw/xfree86/drivers/modesetting/driver.c | 2 ++ > hw/xfree86/drivers/modesetting/drmmode_display.c | 2 -- > hw/xfree86/xorg-wrapper.c | 2 +- > hw/xwayland/xwayland-input.c | 5 ++++- > 6 files changed, 21 insertions(+), 6 deletions(-) Could we add https://patchwork.freedesktop.org/patch/117161/ to this as well? It (hopefully) fixes a random crash in Xwayland with touch devices. Or else I can prepare another pull request... Cheers, Olivier From ofourdan at redhat.com Wed Oct 26 12:23:51 2016 From: ofourdan at redhat.com (Olivier Fourdan) Date: Wed, 26 Oct 2016 08:23:51 -0400 (EDT) Subject: [xserver PULL for 1.19] One more patch on top of Hans' pull request In-Reply-To: <978329885.5615174.1477484503979.JavaMail.zimbra@redhat.com> Message-ID: <1259648839.5615425.1477484631692.JavaMail.zimbra@redhat.com> [...] > Could we add https://patchwork.freedesktop.org/patch/117161/ to this as well? > > It (hopefully) fixes a random crash in Xwayland with touch devices. > > Or else I can prepare another pull request... The following changes since commit d13cb974426f7f1110b0bdb08c4ebb46ff8975f7: ddx: add new call to purge input devices that weren't added (2016-10-26 15:35:07 +1000) are available in the git repository at: git://people.freedesktop.org/~ofourdan/xserver xwayland for you to fetch changes up to 8c460a77cac6e403299ec81f60745c3e8fb37c01: xwayland: Activate and enable touch devices (2016-10-26 14:16:42 +0200) ---------------------------------------------------------------- Olivier Fourdan (1): xwayland: Activate and enable touch devices hw/xwayland/xwayland-input.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) From ajax at redhat.com Wed Oct 26 16:13:15 2016 From: ajax at redhat.com (Adam Jackson) Date: Wed, 26 Oct 2016 12:13:15 -0400 Subject: [PATCH xserver] configure.ac: bump epoxy requirement to 1.2 In-Reply-To: References: <20161024093958.1877-1-emil.l.velikov@gmail.com> <1477407591.29084.14.camel@redhat.com> Message-ID: <1477498395.29084.33.camel@redhat.com> On Wed, 2016-10-26 at 11:29 +0100, Emil Velikov wrote: > Maybe coffee hasn't kicked in, but it does seem to matter. I did not misspeak, I promise. > Think about: build against pre 1.2 [epoxy] then run against 1.2 or > later and you'll get some lovely fireworks. glamor_egl_screen_private::display is an EGLDisplay, so if you build against pre-1.2 you will get build-time warnings about type mismatches where we call epoxy_has_egl_extension. But it will work just fine, because EGLDisplay is a pointer type anyway, and the pre-1.2 version of that function is: PUBLIC bool epoxy_has_egl_extension(EGLDisplay *dpy, const char *ext) { return epoxy_extension_in_string(eglQueryString(dpy, EGL_EXTENSIONS), ext); } Which is to say: epoxy _also_ had a type mismatch warning here. - ajax From ajax at redhat.com Wed Oct 26 17:01:07 2016 From: ajax at redhat.com (Adam Jackson) Date: Wed, 26 Oct 2016 13:01:07 -0400 Subject: [xserver PULL for 1.19 ] Various small fixes for 1.19 In-Reply-To: References: Message-ID: <1477501267.29084.34.camel@redhat.com> On Wed, 2016-10-26 at 12:26 +0200, Hans de Goede wrote: > Hi Adam, Keith, > > Here is a pull-req with various small fixes > (all with at least 1 Reviewed-by) which I've collected > for merging into 1.19: > > The following changes since commit d13cb974426f7f1110b0bdb08c4ebb46ff8975f7: > >    ddx: add new call to purge input devices that weren't added (2016-10-26 15:35:07 +1000) > > are available in the git repository at: > >    git://people.freedesktop.org/~jwrdegoede/xserver for-server-1.19 > > for you to fetch changes up to 7b135f5e7d79622c0b922de8ee827a2556504d8f: > >    xwayland: Transform pointer enter event coordinates (2016-10-26 11:51:38 +0200) Merged: remote: I: patch #115617 updated using rev 8fee6a917b6468e1b116d922f86484498874fb5c. remote: I: patch #114694 updated using rev f6ff2e974c5de3071c899eba828789f1d4d8645a. remote: I: patch #116072 updated using rev 7d91063aca4e4d326c294e246bc2dc36cb05318e. remote: I: patch #116414 updated using rev 4aaeeda4774397dd6d80aa240ca623ae795ec5dc. remote: I: patch #117406 updated using rev f5c6d751d08c6de77c2ca49ba2a48f8023758cef. remote: I: patch #118152 updated using rev f68ba7b81ffe765380664fccc92f3e689c6c48c2. remote: I: 6 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver d13cb97..f68ba7b master -> master - ajax From ajax at redhat.com Wed Oct 26 17:14:17 2016 From: ajax at redhat.com (Adam Jackson) Date: Wed, 26 Oct 2016 13:14:17 -0400 Subject: [xserver PULL for 1.19] One more patch on top of Hans' pull request In-Reply-To: <1259648839.5615425.1477484631692.JavaMail.zimbra@redhat.com> References: <1259648839.5615425.1477484631692.JavaMail.zimbra@redhat.com> Message-ID: <1477502057.29084.36.camel@redhat.com> On Wed, 2016-10-26 at 08:23 -0400, Olivier Fourdan wrote: >   xwayland: Activate and enable touch devices (2016-10-26 14:16:42 +0200) Merged: remote: I: patch #117161 updated using rev 007f8ee61a35ceda36b43e772a9a1074b8e27a06. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver f68ba7b..007f8ee master -> master - ajax From agoins at nvidia.com Wed Oct 26 18:03:49 2016 From: agoins at nvidia.com (Alex Goins) Date: Wed, 26 Oct 2016 11:03:49 -0700 Subject: [PATCH v2] ramdac: Check sPriv != NULL in xf86CheckHWCursor() Message-ID: <1477505029-27378-1-git-send-email-agoins@nvidia.com> xf86CheckHWCursor() would dereference sPriv without NULL checking it. If Option "SWCursor" is specified, sPriv == NULL. In this case we should assume that HW cursors are not supported. Signed-off-by: Alex Goins Reviewed-by: Andy Ritger --- hw/xfree86/ramdac/xf86HWCurs.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/hw/xfree86/ramdac/xf86HWCurs.c b/hw/xfree86/ramdac/xf86HWCurs.c index da2b181..4481320 100644 --- a/hw/xfree86/ramdac/xf86HWCurs.c +++ b/hw/xfree86/ramdac/xf86HWCurs.c @@ -148,6 +148,10 @@ xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor, xf86CursorInfoPtr infoPtr continue; sPriv = dixLookupPrivate(&pSlave->devPrivates, xf86CursorScreenKey); + if (!sPriv) /* NULL if Option "SWCursor", possibly other conditions */ + return FALSE; + + /* FALSE if HWCursor not supported by slave */ if (!xf86ScreenCheckHWCursor(pSlave, cursor, sPriv->CursorInfoPtr)) return FALSE; } -- 1.9.1 From ekurzinger at nvidia.com Wed Oct 26 21:16:11 2016 From: ekurzinger at nvidia.com (Erik Kurzinger) Date: Wed, 26 Oct 2016 14:16:11 -0700 Subject: [PATCH xserver] Fix race condition in ConfigureWindow Message-ID: Currently, the ConfigureWindow function will deliver a ConfigureNotify event to the application before calling into the window's appropriate function with the new size / position. Hence, the application may begin to process the event before some server-size data structures are updated with the new information leading to a potentially inconsistent state. The issue has been causing problems with our OpenGL driver, specifically when something like the following sequence of events happens after a window resize: 1. [xserver] send ConfigureNotify event to application 2. [application] call into client-side OpenGL code in response to resize 3. [driver] read shared memory variable (call it x) indicating whether current window has been resized, see that it has not, proceed without updating client side data structures 4. [xserver] call pScreen->ResizeWindow(...), eventually calling into server-side OpenGL code 5. [driver] update server side data structures, and write to x indicating that the window has changed (2 -> 3) and (4 -> 5) occur asynchronously. If they run in the order described above, it can leave the client side and server side driver components to disagree, causing problems later on. This change will ensure the new configuration is fully processed by the server before any event is sent to the application. Signed-off-by: Erik Kurzinger --- dix/window.c | 50 ++++++++++++++++++++++++++------------------------ 1 file changed, 26 insertions(+), 24 deletions(-) diff --git a/dix/window.c b/dix/window.c index ead4dc2..7177ae3 100644 --- a/dix/window.c +++ b/dix/window.c @@ -2368,6 +2368,32 @@ ConfigureWindow(WindowPtr pWin, Mask mask, XID *vlist, ClientPtr client) return Success; ActuallyDoSomething: + if (mask & CWBorderWidth) { + if (action == RESTACK_WIN) { + action = MOVE_WIN; + pWin->borderWidth = bw; + } + else if ((action == MOVE_WIN) && + (beforeX + wBorderWidth(pWin) == x + (int) bw) && + (beforeY + wBorderWidth(pWin) == y + (int) bw)) { + action = REBORDER_WIN; + (*pWin->drawable.pScreen->ChangeBorderWidth) (pWin, bw); + } + else + pWin->borderWidth = bw; + } + if (action == MOVE_WIN) + (*pWin->drawable.pScreen->MoveWindow) (pWin, x, y, pSib, + (mask & CWBorderWidth) ? VTOther + : VTMove); + else if (action == RESIZE_WIN) + (*pWin->drawable.pScreen->ResizeWindow) (pWin, x, y, w, h, pSib); + else if (mask & CWStackMode) + ReflectStackChange(pWin, pSib, VTOther); + + if (action != RESTACK_WIN) + CheckCursorConfinement(pWin); + if (pWin->drawable.pScreen->ConfigNotify) { int ret; @@ -2400,31 +2426,7 @@ ConfigureWindow(WindowPtr pWin, Mask mask, XID *vlist, ClientPtr client) #endif DeliverEvents(pWin, &event, 1, NullWindow); } - if (mask & CWBorderWidth) { - if (action == RESTACK_WIN) { - action = MOVE_WIN; - pWin->borderWidth = bw; - } - else if ((action == MOVE_WIN) && - (beforeX + wBorderWidth(pWin) == x + (int) bw) && - (beforeY + wBorderWidth(pWin) == y + (int) bw)) { - action = REBORDER_WIN; - (*pWin->drawable.pScreen->ChangeBorderWidth) (pWin, bw); - } - else - pWin->borderWidth = bw; - } - if (action == MOVE_WIN) - (*pWin->drawable.pScreen->MoveWindow) (pWin, x, y, pSib, - (mask & CWBorderWidth) ? VTOther - : VTMove); - else if (action == RESIZE_WIN) - (*pWin->drawable.pScreen->ResizeWindow) (pWin, x, y, w, h, pSib); - else if (mask & CWStackMode) - ReflectStackChange(pWin, pSib, VTOther); - if (action != RESTACK_WIN) - CheckCursorConfinement(pWin); return Success; #undef RESTACK_WIN #undef MOVE_WIN -- 2.7.4 From peter.hutterer at who-t.net Wed Oct 26 23:53:44 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Thu, 27 Oct 2016 09:53:44 +1000 Subject: [PATCH xserver v2] inputthread: On Linux leave the main thread's name as-is In-Reply-To: <20161026102116.19035-1-hdegoede@redhat.com> References: <20161026102116.19035-1-hdegoede@redhat.com> Message-ID: <20161026235344.GA6836@jelly> On Wed, Oct 26, 2016 at 12:21:16PM +0200, Hans de Goede wrote: > From: Peter Hutterer > > On Linux, setting the main thread's name changes the program name > (/proc/self/comm). Setting it to MainThread breaks scripts that rely on > the command name, e.g. ps -C Xorg. > > Signed-off-by: Peter Hutterer > Signed-off-by: Hans de Goede pushed, thanks. 007f8ee..5cb3283 master -> master Cheers, Peter > --- > Changes in v2 (hdegoede): > -Only leave the main thread as-is in Linux, naming it is not an issue on > other platforms > --- > os/inputthread.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/os/inputthread.c b/os/inputthread.c > index ddafa7f..8e7f2ed 100644 > --- a/os/inputthread.c > +++ b/os/inputthread.c > @@ -431,11 +431,13 @@ InputThreadPreInit(void) > } > hotplugPipeWrite = hotplugPipe[1]; > > +#ifndef __linux__ /* Linux does not deal well with renaming the main thread */ > #if defined(HAVE_PTHREAD_SETNAME_NP_WITH_TID) > pthread_setname_np (pthread_self(), "MainThread"); > #elif defined(HAVE_PTHREAD_SETNAME_NP_WITHOUT_TID) > pthread_setname_np ("MainThread"); > #endif > +#endif > > } > > -- > 2.9.3 > From ofourdan at redhat.com Thu Oct 27 07:09:37 2016 From: ofourdan at redhat.com (Olivier Fourdan) Date: Thu, 27 Oct 2016 03:09:37 -0400 (EDT) Subject: Null pointer deref in FlushAllOutput with 1.19-rc1 ? In-Reply-To: <439027105.3863263.1477050772314.JavaMail.zimbra@redhat.com> References: <439027105.3863263.1477050772314.JavaMail.zimbra@redhat.com> Message-ID: <260848793.5775453.1477552177797.JavaMail.zimbra@redhat.com> Hi > > Multiple Fedora 25 users running 1.19-rc1 are reporting a backtrace > > related to an InitFonts -> SendErrorToClient -> FlushAllOutput > > call chain. > > > > Since there is no trivial reproducer this is somewhat hard to debug, > > hence this mail. Anyone have a clue / hint ? See: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1382444 > > Actually, I think we cannot really trust the symbols from Xorg's own > generated backtrace, however, looking at the addresses, the sequence makes > some more sense: > > FlushAllOutput() in /usr/src/debug/xorg-server-20160929/os/io.c:612 > Dispatch() in /usr/src/debug/xorg-server-20160929/dix/dispatch.c:3491 > dix_main() in /usr/src/debug/xorg-server-20160929/dix/main.c:296 > > with /usr/src/debug/xorg-server-20160929/os/io.c:612 > > 612 xorg_list_for_each_entry_safe(client, tmp, &output_pending_clients, > output_pending) { > 613 if (client->clientGone) > 614 continue; > 615 if (!client_is_ready(client)) { > 616 oc = (OsCommPtr) client->osPrivate; > 617 (void) FlushClient(client, oc, (char *) NULL, 0); > 618 } else > 619 NewOutputPending = TRUE; > 620 } > > So it could be that output_pending_clients list got corrupted somehow. > > Not sure I can go much further than that with so little data, but if that > rings a bell with someone else... Some more reports all pointing to FlushAllOutput() with different backtraces, e.g.: #6 FlushClient at io.c:938 #7 WriteToClient at io.c:768 #8 WriteEventsToClient at events.c:6000 #9 present_send_complete_notify at present_event.c:172 #10 present_vblank_notify at present.c:213 #11 present_execute at present.c:771 #12 present_pixmap at present.c:963 #13 present_notify_msc at present.c:1014 #14 proc_present_notify_msc at present_request.c:174 #15 Dispatch at dispatch.c:469 or #6 FlushClient at io.c:938 #7 WriteToClient at io.c:768 #8 ProcGetScreenSaver at dispatch.c:3163 #9 Dispatch at dispatch.c:469 #10 dix_main at main.c:287 with 792 int 793 FlushClient(ClientPtr who, OsCommPtr oc, const void *__extraBuf, int extraCount) 794 { ... 936 937 if (oco->size > BUFWATERMARK) { 938 free(oco->buf); <== here 939 free(oco); 940 } 941 else { 942 oco->next = FreeOutputs; 943 FreeOutputs = oco; 944 } The most important change I see affecting this code is the "Switch server to poll" series, I am not sure how this can be related though. Also, I don't see any change between xorg-server-20160929 and current git master, so chances are this is still affecting current git code. Cheers, Olivier From wharms at bfs.de Thu Oct 27 09:02:54 2016 From: wharms at bfs.de (walter harms) Date: Thu, 27 Oct 2016 11:02:54 +0200 Subject: [PATCH libxi 2/2] Check that allocating a buffer succeeded In-Reply-To: <20161025193119.5127-2-pochu@debian.org> References: <20161025193119.5127-1-pochu@debian.org> <20161025193119.5127-2-pochu@debian.org> Message-ID: <5811C2BE.5040003@bfs.de> looks good to me. Signed-off-by: wharms at bfs.de Am 25.10.2016 21:31, schrieb Emilio Pozuelo Monfort: > Since we are going to write into the buffer, we should make sure the > allocation didn't fail. > > Reported-by: Julien Cristau > Signed-off-by: Emilio Pozuelo Monfort > --- > src/XIQueryDevice.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/src/XIQueryDevice.c b/src/XIQueryDevice.c > index e3b0c9f..a877d78 100644 > --- a/src/XIQueryDevice.c > +++ b/src/XIQueryDevice.c > @@ -66,17 +66,18 @@ XIQueryDevice(Display *dpy, int deviceid, int *ndevices_return) > { > *ndevices_return = reply.num_devices; > info = Xmalloc((reply.num_devices + 1) * sizeof(XIDeviceInfo)); > + buf = Xmalloc(reply.length * 4); > } > else > { > *ndevices_return = 0; > info = NULL; > + buf = NULL; > } > > - if (!info) > + if (!info || !buf) > goto error; > > - buf = Xmalloc(reply.length * 4); > _XRead(dpy, buf, reply.length * 4); > ptr = buf; > end = buf + reply.length * 4; > @@ -135,9 +136,9 @@ error_loop: > Xfree(info[i].name); > Xfree(info[i].classes); > } > +error: > Xfree(info); > Xfree(buf); > -error: > UnlockDisplay(dpy); > error_unlocked: > SyncHandle(); From emil.l.velikov at gmail.com Thu Oct 27 10:45:46 2016 From: emil.l.velikov at gmail.com (Emil Velikov) Date: Thu, 27 Oct 2016 11:45:46 +0100 Subject: [PATCH xserver] configure.ac: bump epoxy requirement to 1.2 In-Reply-To: <1477498395.29084.33.camel@redhat.com> References: <20161024093958.1877-1-emil.l.velikov@gmail.com> <1477407591.29084.14.camel@redhat.com> <1477498395.29084.33.camel@redhat.com> Message-ID: On 26 October 2016 at 17:13, Adam Jackson wrote: > On Wed, 2016-10-26 at 11:29 +0100, Emil Velikov wrote: > >> Maybe coffee hasn't kicked in, but it does seem to matter. > > I did not misspeak, I promise. > Eek, you're right. Me runs off to find a brown paper bag. Thanks Emil From jon.turney at dronecode.org.uk Thu Oct 27 13:29:16 2016 From: jon.turney at dronecode.org.uk (Jon Turney) Date: Thu, 27 Oct 2016 14:29:16 +0100 Subject: [PULL] Small fix for 1.19 Message-ID: <20161027132847.GA389552@tambora> The following changes since commit 5cb328338684d8e5b03913c47475bfcd7acffec4: inputthread: On Linux leave the main thread's name as-is (2016-10-27 09:53:01 +1000) are available in the git repository at: git://people.freedesktop.org/~jturney/xserver for you to fetch changes up to 03d99ef729178dd99268f185fb45320a29382091: glx/dri2: Don't build DRI loader if DRI2 isn't enabled (2016-10-27 14:25:42 +0100) ---------------------------------------------------------------- Jon Turney (1): glx/dri2: Don't build DRI loader if DRI2 isn't enabled glx/Makefile.am | 11 ++++++++--- hw/xfree86/dixmods/Makefile.am | 2 ++ 2 files changed, 10 insertions(+), 3 deletions(-) From eric at anholt.net Thu Oct 27 18:03:17 2016 From: eric at anholt.net (Eric Anholt) Date: Thu, 27 Oct 2016 11:03:17 -0700 Subject: [PATCH rendercheck] Report results on a per-test basis In-Reply-To: References: <20161006140535.32211-1-martin.peres@linux.intel.com> <87funpfzfa.fsf@eliezer.anholt.net> Message-ID: <87bmy5u0t6.fsf@eliezer.anholt.net> Martin Peres writes: > On 21/10/16 19:18, Eric Anholt wrote: >> Martin Peres writes: >> >>> This allows a runner such as EzBench to track each test individually >>> and not limit the resolution to groups. >>> >>> This feature can be triggered by using the -r parameter. >> >> I don't really see the point of this -- you need an external runner to >> be choosing a specific test subset to run per rendercheck call, since >> the full matrix of composite tests is too long. Once you have an >> external runner calling rendercheck per test group, all you would be >> able to do using this patch would be save a few spawns of the process, >> which doesn't seem worth it. > > Just to be sure, are you suggesting I do something like this instead? > > for format in "a8r8g8b8 x8r8g8b8 ... more formats"; do > ./rendercheck -f $format > # parse the successful groups and store them, prefixed by $format so as > I can identify regressions per format? > done You should probably look at piglit for subsetting of the tests. Actually, I'd say you should probably just use piglit. Given that piglit is what X developers are going to be using, if we're going to lock rendercheck into specific output formats I'd like to see the piglit patches included with it. From eric at anholt.net Thu Oct 27 21:02:40 2016 From: eric at anholt.net (Eric Anholt) Date: Thu, 27 Oct 2016 14:02:40 -0700 Subject: [PATCH xts] xts5: Fix clang warning - non-void function DoLayout should return a value In-Reply-To: <20161022214040.18330-1-rhyskidd@gmail.com> References: <20161022214040.18330-1-rhyskidd@gmail.com> Message-ID: <87k2ct4ia7.fsf@eliezer.anholt.net> Echelon9 writes: > From: Rhys Kidd > > Box.c:245:7: error: non-void function 'DoLayout' should return a value > [-Wreturn-type] > return; > ^ > Box.c:285:6: error: non-void function 'DoLayout' should return a value > [-Wreturn-type] > return; > ^ > > Signed-off-by: Rhys Kidd Applied. Thanks! From Joerg.Vehlow at Xcerra.com Thu Oct 27 10:51:43 2016 From: Joerg.Vehlow at Xcerra.com (Joerg.Vehlow at Xcerra.com) Date: Thu, 27 Oct 2016 12:51:43 +0200 Subject: [Xtrans] Interrupted function call for ioctl not handled Message-ID: Hi, I just stumbled upon a bug in Xtrans socket transport on QNX 6.5: At least on QNX 6.5 the syscall ioctl (FIONREAD) can be interrupted by a signal leading to a return value of -1 and errno set to EINTR. The QNX documentation doesn't mention the error, but it maps the ioctl to a devctl, where the behavior is documented. In the POSIX specification EINTR is also documented. I think this is a bug even in current implementations of Xtrans, because POSIX allows the EINTR and it for read and write it is handled, but not for the ioctl. Maybe someone should look into fixing it in the future. Regards Jörg -------------- next part -------------- An HTML attachment was scrubbed... URL: From keithp at keithp.com Fri Oct 28 15:04:43 2016 From: keithp at keithp.com (Keith Packard) Date: Fri, 28 Oct 2016 08:04:43 -0700 Subject: [PATCH xserver] os: Recompute whether any clients are ready after ProcessWorkQueue() (bug 98030) Message-ID: <20161028150443.4829-1-keithp@keithp.com> If a work proc wakes up a sleeping client and it is ready to execute, we need to re-compute the local 'are_ready' value before deciding what timeout value to use in WaitForSomething. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98030 Signed-off-by: Keith Packard --- os/WaitFor.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/os/WaitFor.c b/os/WaitFor.c index 7d5aa32..ff1c85e 100644 --- a/os/WaitFor.c +++ b/os/WaitFor.c @@ -204,8 +204,10 @@ WaitForSomething(Bool are_ready) crashed connections and the screen saver timeout */ while (1) { /* deal with any blocked jobs */ - if (workQueue) + if (workQueue) { ProcessWorkQueue(); + are_ready = clients_are_ready(); + } if (are_ready) timeout = 0; -- 2.10.1 From keithp at keithp.com Fri Oct 28 15:18:08 2016 From: keithp at keithp.com (Keith Packard) Date: Fri, 28 Oct 2016 08:18:08 -0700 Subject: [PATCH v2] ramdac: Check sPriv != NULL in xf86CheckHWCursor() In-Reply-To: <1477505029-27378-1-git-send-email-agoins@nvidia.com> References: <1477505029-27378-1-git-send-email-agoins@nvidia.com> Message-ID: <86mvhojydr.fsf@hiro.keithp.com> Alex Goins writes: > xf86CheckHWCursor() would dereference sPriv without NULL checking it. If Option > "SWCursor" is specified, sPriv == NULL. In this case we should assume that HW > cursors are not supported. > > Signed-off-by: Alex Goins > Reviewed-by: Andy Ritger Merged. 5cb3283..cba5a10 master -> master -- -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From hdegoede at redhat.com Fri Oct 28 15:38:49 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Fri, 28 Oct 2016 17:38:49 +0200 Subject: [PATCH xserver] os: Recompute whether any clients are ready after ProcessWorkQueue() (bug 98030) In-Reply-To: <20161028150443.4829-1-keithp@keithp.com> References: <20161028150443.4829-1-keithp@keithp.com> Message-ID: Hi, On 28-10-16 17:04, Keith Packard wrote: > If a work proc wakes up a sleeping client and it is ready to execute, > we need to re-compute the local 'are_ready' value before deciding > what timeout value to use in WaitForSomething. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98030 > Signed-off-by: Keith Packard Patch LGTM: Reviewed-by: Hans de Goede Regards, Hans > --- > os/WaitFor.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/os/WaitFor.c b/os/WaitFor.c > index 7d5aa32..ff1c85e 100644 > --- a/os/WaitFor.c > +++ b/os/WaitFor.c > @@ -204,8 +204,10 @@ WaitForSomething(Bool are_ready) > crashed connections and the screen saver timeout */ > while (1) { > /* deal with any blocked jobs */ > - if (workQueue) > + if (workQueue) { > ProcessWorkQueue(); > + are_ready = clients_are_ready(); > + } > > if (are_ready) > timeout = 0; > From keithp at keithp.com Fri Oct 28 15:42:20 2016 From: keithp at keithp.com (Keith Packard) Date: Fri, 28 Oct 2016 08:42:20 -0700 Subject: [PATCH xserver] ephyr: Leave window unmapped for -glamor-skip-present In-Reply-To: <87vax6u2ft.fsf@eliezer.anholt.net> References: <20161005164219.32641-1-keithp@keithp.com> <87vax6u2ft.fsf@eliezer.anholt.net> Message-ID: <86k2csjx9f.fsf@hiro.keithp.com> Eric Anholt writes: > Drop the extern ephyr_glamor_gles2 and it's: > > Reviewed-by: Eric Anholt Merged. cba5a10..2c91f32 master -> master -- -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From keithp at keithp.com Fri Oct 28 16:02:20 2016 From: keithp at keithp.com (Keith Packard) Date: Fri, 28 Oct 2016 09:02:20 -0700 Subject: [PATCH xserver] os: Recompute whether any clients are ready after ProcessWorkQueue() (bug 98030) In-Reply-To: References: <20161028150443.4829-1-keithp@keithp.com> Message-ID: <86h97wjwc3.fsf@hiro.keithp.com> Hans de Goede writes: > Patch LGTM: > > Reviewed-by: Hans de Goede Thanks. Merged. 2c91f32..9ed5b26 master -> master -- -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From keithp at keithp.com Fri Oct 28 16:06:35 2016 From: keithp at keithp.com (Keith Packard) Date: Fri, 28 Oct 2016 09:06:35 -0700 Subject: [PULL] Small fix for 1.19 In-Reply-To: <20161027132847.GA389552@tambora> References: <20161027132847.GA389552@tambora> Message-ID: <86bmy4jw50.fsf@hiro.keithp.com> Jon Turney writes: > Jon Turney (1): > glx/dri2: Don't build DRI loader if DRI2 isn't enabled Merged. 9ed5b26..356db23 master -> master -- -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From keithp at keithp.com Fri Oct 28 16:25:56 2016 From: keithp at keithp.com (Keith Packard) Date: Fri, 28 Oct 2016 09:25:56 -0700 Subject: [PATCH xserver] dix: Use 'output_pending_clear' instead of open-coding it in CloseDownClient Message-ID: <20161028162556.29291-1-keithp@keithp.com> Signed-off-by: Keith Packard --- dix/dispatch.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dix/dispatch.c b/dix/dispatch.c index e111377..f16a84e 100644 --- a/dix/dispatch.c +++ b/dix/dispatch.c @@ -3406,7 +3406,7 @@ CloseDownClient(ClientPtr client) UngrabServer(client); } mark_client_not_ready(client); - xorg_list_del(&client->output_pending); + output_pending_clear(client); BITCLEAR(grabWaiters, client->index); DeleteClientFromAnySelections(client); ReleaseActiveGrabs(client); -- 2.10.1 From keithp at keithp.com Fri Oct 28 16:30:27 2016 From: keithp at keithp.com (Keith Packard) Date: Fri, 28 Oct 2016 09:30:27 -0700 Subject: [PATCH xserver] dix: Bump MAXHASHSIZE for the resource db In-Reply-To: <86k2dmxxd9.fsf@hiro.keithp.com> References: <20160929151617.27347-1-ajax@redhat.com> <86k2dmxxd9.fsf@hiro.keithp.com> Message-ID: <86wpgsbfmk.fsf@hiro.keithp.com> Keith Packard writes: > v2: Replace with a shorter code sequence which computes the same > results for all but numBits == 7 > > Reviewed-by: Adam Jackson > Signed-off-by: Keith Packard Merged. 356db23..c85f818 master -> master -- -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From hdegoede at redhat.com Fri Oct 28 17:21:34 2016 From: hdegoede at redhat.com (Hans de Goede) Date: Fri, 28 Oct 2016 19:21:34 +0200 Subject: [PATCH xserver] dix: Use 'output_pending_clear' instead of open-coding it in CloseDownClient In-Reply-To: <20161028162556.29291-1-keithp@keithp.com> References: <20161028162556.29291-1-keithp@keithp.com> Message-ID: <1f796cb9-7c05-47c3-bf3a-e6dbbde48aed@redhat.com> Hi, On 28-10-16 18:25, Keith Packard wrote: > Signed-off-by: Keith Packard Patch LGTM: Reviewed-by: Hans de Goede Regards, Hans > --- > dix/dispatch.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/dix/dispatch.c b/dix/dispatch.c > index e111377..f16a84e 100644 > --- a/dix/dispatch.c > +++ b/dix/dispatch.c > @@ -3406,7 +3406,7 @@ CloseDownClient(ClientPtr client) > UngrabServer(client); > } > mark_client_not_ready(client); > - xorg_list_del(&client->output_pending); > + output_pending_clear(client); > BITCLEAR(grabWaiters, client->index); > DeleteClientFromAnySelections(client); > ReleaseActiveGrabs(client); > From emil.l.velikov at gmail.com Fri Oct 28 17:22:58 2016 From: emil.l.velikov at gmail.com (Emil Velikov) Date: Fri, 28 Oct 2016 18:22:58 +0100 Subject: [PATCH xbitmaps] Install pkgconfig file into arch-dependent location In-Reply-To: <6a27b17e-c57e-6508-3f18-3d840f35f0ac@exherbo.org> References: <20160922171213.20530-1-heirecka@exherbo.org> <20160923063142.4jv5avy4dqoqo6pf@betterave.cristau.org> <2ff50b72-9aa5-1f41-ad58-8e14b13c2f06@oracle.com> <6a27b17e-c57e-6508-3f18-3d840f35f0ac@exherbo.org> Message-ID: On 23 September 2016 at 11:42, Heiko Becker wrote: > On 09/23/16 12:34, Emil Velikov wrote: >> On 23 September 2016 at 08:07, Alan Coopersmith >> wrote: >>> On 09/23/16 12:05 AM, Emil Velikov wrote: >>>> >>>> On 23 September 2016 at 07:31, Julien Cristau wrote: >>>>> >>>>> On Thu, Sep 22, 2016 at 19:12:13 +0200, Heiko Becker wrote: >>>>> >>>>> That seems like it's going backwards, and your commit message doesn't >>>>> explain why. >>>>> >>>> That was my initial thought as well (going backwards). Then again, >>>> as-is the .pc file is located in a arch _in_ dependant location, which >>>> causes file conflicts as you have multilib - x86-86 & x86 installed >>>> for example. In such cases the files have different contents (path) >>>> which leads to link time issues. >>> >>> >>> How can you have link time issues when there's noting in xbitmaps to >>> link with? It's purely xbm files, sometimes abused as C headers. >>> >> Ack, you're absolutely correct. I didn't realise that the xbitmaps >> repo doesn't ship any libraries. > > It doesn't, but it provides includes and the includedir gets propagated > via pkg-config, leading to a build error on a multi-arch layout when > cross compiling xsetroot. > Yes, that's correct. From my [humble] experience - every 32bit build "clashes" with the 64bit one for everything but the libraries/executables. Since everything else (man pages, images, headers) should be identical, in theory at least, there isn't anything to be concerned about. Thus some distros do not bundle the 'duplicates' with the 32bit package. If things are not the identical, one ought to attempt to resolve that first. That's my take on it, but I could be very wrong on the topic. Emil From ekurzinger at nvidia.com Sat Oct 29 00:56:34 2016 From: ekurzinger at nvidia.com (Erik Kurzinger) Date: Fri, 28 Oct 2016 17:56:34 -0700 Subject: [PATCH xserver] Fix race condition in ConfigureWindow In-Reply-To: References: Message-ID: Resubmitting with proper formatting, and a small change to the patch. Signed-off-by: Erik Kurzinger --- dix/window.c | 42 ++++++++++++++++++++++-------------------- 1 file changed, 22 insertions(+), 20 deletions(-) diff --git a/dix/window.c b/dix/window.c index ead4dc2..677fe65 100644 --- a/dix/window.c +++ b/dix/window.c @@ -2380,26 +2380,6 @@ ConfigureWindow(WindowPtr pWin, Mask mask, XID *vlist, ClientPtr client) } } - if (SubStrSend(pWin, pParent)) { - xEvent event = { - .u.configureNotify.window = pWin->drawable.id, - .u.configureNotify.aboveSibling = pSib ? pSib->drawable.id : None, - .u.configureNotify.x = x, - .u.configureNotify.y = y, - .u.configureNotify.width = w, - .u.configureNotify.height = h, - .u.configureNotify.borderWidth = bw, - .u.configureNotify.override = pWin->overrideRedirect - }; - event.u.u.type = ConfigureNotify; -#ifdef PANORAMIX - if (!noPanoramiXExtension && (!pParent || !pParent->parent)) { - event.u.configureNotify.x += screenInfo.screens[0]->x; - event.u.configureNotify.y += screenInfo.screens[0]->y; - } -#endif - DeliverEvents(pWin, &event, 1, NullWindow); - } if (mask & CWBorderWidth) { if (action == RESTACK_WIN) { action = MOVE_WIN; @@ -2425,6 +2405,28 @@ ConfigureWindow(WindowPtr pWin, Mask mask, XID *vlist, ClientPtr client) if (action != RESTACK_WIN) CheckCursorConfinement(pWin); + + if (SubStrSend(pWin, pParent)) { + xEvent event = { + .u.configureNotify.window = pWin->drawable.id, + .u.configureNotify.aboveSibling = pSib ? pSib->drawable.id : None, + .u.configureNotify.x = x, + .u.configureNotify.y = y, + .u.configureNotify.width = w, + .u.configureNotify.height = h, + .u.configureNotify.borderWidth = bw, + .u.configureNotify.override = pWin->overrideRedirect + }; + event.u.u.type = ConfigureNotify; +#ifdef PANORAMIX + if (!noPanoramiXExtension && (!pParent || !pParent->parent)) { + event.u.configureNotify.x += screenInfo.screens[0]->x; + event.u.configureNotify.y += screenInfo.screens[0]->y; + } +#endif + DeliverEvents(pWin, &event, 1, NullWindow); + } + return Success; #undef RESTACK_WIN #undef MOVE_WIN -- 2.7.4 From keithp at keithp.com Sat Oct 29 02:20:28 2016 From: keithp at keithp.com (Keith Packard) Date: Fri, 28 Oct 2016 19:20:28 -0700 Subject: [PATCH xserver] Fix race condition in ConfigureWindow In-Reply-To: References: Message-ID: <86shrfgakz.fsf@hiro.keithp.com> Erik Kurzinger writes: > Resubmitting with proper formatting, and a small change to the patch. The protocol specifies that the ConfigureNotify event be delivered before any Expose events, so we can't just move the event generation until after the window has been configured and exposed. It sounds like your driver might want to use the ConfigNotify hook in the screen so that it can learn about configuration changes before the client does? -- -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From rhyskidd at gmail.com Sat Oct 29 02:44:30 2016 From: rhyskidd at gmail.com (Rhys Kidd) Date: Fri, 28 Oct 2016 22:44:30 -0400 Subject: [PATCH xserver] test: Fix stray Makefile reference to removed os test Message-ID: <20161029024430.4843-1-rhyskidd@gmail.com> Fixes the following warning: test/Makefile.am:69: warning: variable 'os_LDADD' is defined but no program or test/Makefile.am:69: library has 'os' as canonical name (possible typo) Introduced upon the removal of test/os in: commit 6a5a4e60373c1386b311b2a8bb666c32d68a9d99 Author: Keith Packard Date: Tue Dec 8 14:39:46 2015 -0800 Remove SIGIO support for input [v5] This removes all of the SIGIO handling support used for input throughout the X server, preparing the way for using threads for input handling instead. Places calling OsBlockSIGIO and OsReleaseSIGIO are marked with calls to stub functions input_lock/input_unlock so that we don't lose this information. xfree86 SIGIO support is reworked to use internal versions of OsBlockSIGIO and OsReleaseSIGIO. v2: Don't change locking order (Peter Hutterer) v3: Comment weird && FALSE in xf86Helper.c Leave errno save/restore in xf86ReadInput Squash with stub adding patch (Peter Hutterer) v4: Leave UseSIGIO config parameter so that existing config files don't break (Peter Hutterer) v5: Split a couple of independent patch bits out of kinput.c (Peter Hutterer) Signed-off-by: Keith Packard Reviewed-by: Peter Hutterer Signed-off-by: Rhys Kidd --- test/Makefile.am | 1 - 1 file changed, 1 deletion(-) diff --git a/test/Makefile.am b/test/Makefile.am index c89915c..b8a0f4d 100644 --- a/test/Makefile.am +++ b/test/Makefile.am @@ -66,7 +66,6 @@ xfree86_LDADD=$(TEST_LDADD) touch_LDADD=$(TEST_LDADD) signal_logging_LDADD=$(TEST_LDADD) hashtabletest_LDADD=$(TEST_LDADD) -os_LDADD=$(TEST_LDADD) libxservertest_la_LIBADD = $(XSERVER_LIBS) if XORG -- 2.9.3 From rhyskidd at gmail.com Sat Oct 29 03:04:43 2016 From: rhyskidd at gmail.com (Rhys Kidd) Date: Fri, 28 Oct 2016 23:04:43 -0400 Subject: [PATCH xts] xts5: Fix format specifier type warning in XtSetSelectionTimeout Message-ID: <20161029030443.5508-1-rhyskidd@gmail.com> XtSetSelectionTimeout.c: In function: XtSetSelectionTimeout.c:90:3: warning: format '%d' expects argument of type 'int', but argument 3 has type 'long unsigned int' [-Wformat=] sprintf(ebuf, "ERROR: Expected 5000 received %d", value_good); ^ XtSetSelectionTimeout.c:98:3: warning: format '%d' expects argument of type 'int', but argument 3 has type 'long unsigned int' [-Wformat=] sprintf(ebuf, "ERROR: Expected 10000 received %d", value_good); ^ Signed-off-by: Rhys Kidd --- xts5/XtC/XtSetSelectionTimeout.m | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xts5/XtC/XtSetSelectionTimeout.m b/xts5/XtC/XtSetSelectionTimeout.m index dbaf75c..4e97513 100644 --- a/xts5/XtC/XtSetSelectionTimeout.m +++ b/xts5/XtC/XtSetSelectionTimeout.m @@ -81,7 +81,7 @@ pid_t pid2; XtRealizeWidget(topLevel); tet_infoline("TEST: Verify the default"); if ((value_good = XtGetSelectionTimeout()) != (unsigned int)5000){ - sprintf(ebuf, "ERROR: Expected 5000 received %d", value_good); + sprintf(ebuf, "ERROR: Expected 5000 received %lu", value_good); tet_infoline(ebuf); tet_result(TET_FAIL); } @@ -89,7 +89,7 @@ pid_t pid2; XtSetSelectionTimeout((unsigned int )10000); tet_infoline("TEST: selectionTimeout is 10000 milliseconds"); if ((value_good = XtGetSelectionTimeout()) != (unsigned int)10000){ - sprintf(ebuf, "ERROR: Expected 10000 received %d", value_good); + sprintf(ebuf, "ERROR: Expected 10000 received %lu", value_good); tet_infoline(ebuf); tet_result(TET_FAIL); } -- 2.9.3 From keithp at keithp.com Sat Oct 29 03:27:18 2016 From: keithp at keithp.com (Keith Packard) Date: Fri, 28 Oct 2016 20:27:18 -0700 Subject: [PATCH xserver] test: Fix stray Makefile reference to removed os test In-Reply-To: <20161029024430.4843-1-rhyskidd@gmail.com> References: <20161029024430.4843-1-rhyskidd@gmail.com> Message-ID: <86eg2zx2ax.fsf@hiro.keithp.com> Rhys Kidd writes: > Fixes the following warning: > > test/Makefile.am:69: warning: variable 'os_LDADD' is defined but no program or > test/Makefile.am:69: library has 'os' as canonical name (possible typo) > > Introduced upon the removal of test/os in: > > commit 6a5a4e60373c1386b311b2a8bb666c32d68a9d99 > Author: Keith Packard > Date: Tue Dec 8 14:39:46 2015 -0800 > > Remove SIGIO support for input [v5] > > This removes all of the SIGIO handling support used for input > throughout the X server, preparing the way for using threads for input > handling instead. > > Places calling OsBlockSIGIO and OsReleaseSIGIO are marked with calls > to stub functions input_lock/input_unlock so that we don't lose this > information. > > xfree86 SIGIO support is reworked to use internal versions of > OsBlockSIGIO and OsReleaseSIGIO. > > v2: Don't change locking order (Peter Hutterer) > v3: Comment weird && FALSE in xf86Helper.c > Leave errno save/restore in xf86ReadInput > Squash with stub adding patch (Peter Hutterer) > v4: Leave UseSIGIO config parameter so that > existing config files don't break (Peter Hutterer) > v5: Split a couple of independent patch bits out > of kinput.c (Peter Hutterer) > > Signed-off-by: Keith Packard > Reviewed-by: Peter Hutterer > > Signed-off-by: Rhys Kidd Reviewed-by: Keith Packard (we'll wait until after 1.19 to merge this to master) -- -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From rhyskidd at gmail.com Sat Oct 29 03:37:57 2016 From: rhyskidd at gmail.com (Rhys Kidd) Date: Fri, 28 Oct 2016 23:37:57 -0400 Subject: [PATCH xts 1/3] xts5: Fix missing variable for format specifier Message-ID: <20161029033759.6386-1-rhyskidd@gmail.com> XtGetKeysymTable.c:258:5: warning: format '%ld' expects a matching 'long int' argument [-Wformat=] Signed-off-by: Rhys Kidd --- xts5/Xt12/XtGetKeysymTable.m | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xts5/Xt12/XtGetKeysymTable.m b/xts5/Xt12/XtGetKeysymTable.m index db22f1b..1d8ab91 100644 --- a/xts5/Xt12/XtGetKeysymTable.m +++ b/xts5/Xt12/XtGetKeysymTable.m @@ -209,7 +209,7 @@ Xlib returns to what Xt returns*/ for (i = min_keycode; i <= max_keycode; i++ ) { if (keysym_good[i] == NoSymbol) { if (keysym_return[i] != NoSymbol) { - sprintf(ebuf, "ERROR: min_keycode + %d should be NoSymbol, is %ld", (long)keysym_return[i]); + sprintf(ebuf, "ERROR: min_keycode + %d should be NoSymbol, is %ld", i, (long)keysym_return[i]); tet_infoline(ebuf); tet_result(TET_FAIL); } -- 2.9.3 From rhyskidd at gmail.com Sat Oct 29 03:37:58 2016 From: rhyskidd at gmail.com (Rhys Kidd) Date: Fri, 28 Oct 2016 23:37:58 -0400 Subject: [PATCH xts 2/3] xts5: Fix missing variable for format specifier In-Reply-To: <20161029033759.6386-1-rhyskidd@gmail.com> References: <20161029033759.6386-1-rhyskidd@gmail.com> Message-ID: <20161029033759.6386-2-rhyskidd@gmail.com> XtRemoveEventHandler.c:458:3: warning: format '%d' expects a matching 'int' argument [-Wformat=] sprintf(ebuf, "ERROR: Error message handler was invoked %d times"); ^ XtRemoveEventHandler.c:463:3: warning: format '%d' expects a matching 'int' argument [-Wformat=] sprintf(ebuf, "ERROR: Warning message handler was invoked %d times"); ^ XtRemoveEventHandler.c:540:3: warning: format '%d' expects a matching 'int' argument [-Wformat=] sprintf(ebuf, "ERROR: Error message handler was invoked %d times"); ^ XtRemoveEventHandler.c:545:3: warning: format '%d' expects a matching 'int' argument [-Wformat=] sprintf(ebuf, "ERROR: Warning message handler was invoked %d times"); ^ Signed-off-by: Rhys Kidd --- xts5/Xt9/XtRemoveEventHandler.m | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/xts5/Xt9/XtRemoveEventHandler.m b/xts5/Xt9/XtRemoveEventHandler.m index 1851ef9..6e6cbbe 100644 --- a/xts5/Xt9/XtRemoveEventHandler.m +++ b/xts5/Xt9/XtRemoveEventHandler.m @@ -425,13 +425,13 @@ int invoked = 0; XtAppMainLoop(app_ctext); LKROF(pid2, AVSXTTIMEOUT-2); tet_infoline("TEST: Error message was not emitted"); - if (avs_get_event(3) != 0) { - sprintf(ebuf, "ERROR: Error message handler was invoked %d times"); + if (invoked = avs_get_event(3) != 0) { + sprintf(ebuf, "ERROR: Error message handler was invoked %d times", invoked); tet_infoline(ebuf); tet_result(TET_FAIL); } - if (avs_get_event(2) != 0) { - sprintf(ebuf, "ERROR: Warning message handler was invoked %d times"); + if (invoked = avs_get_event(2) != 0) { + sprintf(ebuf, "ERROR: Warning message handler was invoked %d times", invoked); tet_infoline(ebuf); tet_result(TET_FAIL); } @@ -491,13 +491,13 @@ int invoked = 0; tet_result(TET_FAIL); } tet_infoline("TEST: Error message was not emitted"); - if (avs_get_event(3) != 0) { - sprintf(ebuf, "ERROR: Error message handler was invoked %d times"); + if (invoked = avs_get_event(3) != 0) { + sprintf(ebuf, "ERROR: Error message handler was invoked %d times", invoked); tet_infoline(ebuf); tet_result(TET_FAIL); } - if (avs_get_event(2) != 0) { - sprintf(ebuf, "ERROR: Warning message handler was invoked %d times"); + if (invoked = avs_get_event(2) != 0) { + sprintf(ebuf, "ERROR: Warning message handler was invoked %d times", invoked); tet_infoline(ebuf); tet_result(TET_FAIL); } -- 2.9.3 From rhyskidd at gmail.com Sat Oct 29 03:37:59 2016 From: rhyskidd at gmail.com (Rhys Kidd) Date: Fri, 28 Oct 2016 23:37:59 -0400 Subject: [PATCH xts 3/3] xts5: Fix missing variable for format specifier In-Reply-To: <20161029033759.6386-1-rhyskidd@gmail.com> References: <20161029033759.6386-1-rhyskidd@gmail.com> Message-ID: <20161029033759.6386-3-rhyskidd@gmail.com> XtRemoveRawEventHandler.c:396:3: warning: format '%d' expects a matching 'int' argument [-Wformat=] sprintf(ebuf, "ERROR: Error message handler was invoked %d times"); ^ XtRemoveRawEventHandler.c:401:3: warning: format '%d' expects a matching 'int' argument [-Wformat=] sprintf(ebuf, "ERROR: Warning message handler was invoked %d times"); ^ XtRemoveRawEventHandler.c:478:3: warning: format '%d' expects a matching 'int' argument [-Wformat=] sprintf(ebuf, "ERROR: Error message handler was invoked %d times"); ^ XtRemoveRawEventHandler.c:483:3: warning: format '%d' expects a matching 'int' argument [-Wformat=] sprintf(ebuf, "ERROR: Warning message handler was invoked %d times"); ^ Signed-off-by: Rhys Kidd --- xts5/Xt9/XtRemoveRawEventHandler.m | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/xts5/Xt9/XtRemoveRawEventHandler.m b/xts5/Xt9/XtRemoveRawEventHandler.m index 0a3f916..87dc286 100644 --- a/xts5/Xt9/XtRemoveRawEventHandler.m +++ b/xts5/Xt9/XtRemoveRawEventHandler.m @@ -374,13 +374,13 @@ int invoked = 0; XtAppMainLoop(app_ctext); LKROF(pid2, AVSXTTIMEOUT-2); tet_infoline("TEST: Error message was not emitted"); - if (avs_get_event(3) != 0) { - sprintf(ebuf, "ERROR: Error message handler was invoked %d times"); + if (invoked = avs_get_event(3) != 0) { + sprintf(ebuf, "ERROR: Error message handler was invoked %d times", invoked); tet_infoline(ebuf); tet_result(TET_FAIL); } - if (avs_get_event(2) != 0) { - sprintf(ebuf, "ERROR: Warning message handler was invoked %d times"); + if (invoked = avs_get_event(2) != 0) { + sprintf(ebuf, "ERROR: Warning message handler was invoked %d times", invoked); tet_infoline(ebuf); tet_result(TET_FAIL); } @@ -440,13 +440,13 @@ int invoked = 0; tet_result(TET_FAIL); } tet_infoline("TEST: Error message was not emitted"); - if (avs_get_event(3) != 0) { - sprintf(ebuf, "ERROR: Error message handler was invoked %d times"); + if (invoked = avs_get_event(3) != 0) { + sprintf(ebuf, "ERROR: Error message handler was invoked %d times", invoked); tet_infoline(ebuf); tet_result(TET_FAIL); } - if (avs_get_event(2) != 0) { - sprintf(ebuf, "ERROR: Warning message handler was invoked %d times"); + if (invoked = avs_get_event(2) != 0) { + sprintf(ebuf, "ERROR: Warning message handler was invoked %d times", invoked); tet_infoline(ebuf); tet_result(TET_FAIL); } -- 2.9.3 From rhyskidd at gmail.com Sat Oct 29 19:59:54 2016 From: rhyskidd at gmail.com (Rhys Kidd) Date: Sat, 29 Oct 2016 15:59:54 -0400 Subject: [PATCH xts] xts5: Fix clang warning - non-void function FillArea should return a value Message-ID: <20161029195954.9363-1-rhyskidd@gmail.com> Scrollbar.c:282:21: error: non-void function 'FillArea' should return a value [-Wreturn-type] if (bottom < 0) return; ^ Signed-off-by: Rhys Kidd --- xts5/src/libXtaw/Scrollbar.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xts5/src/libXtaw/Scrollbar.c b/xts5/src/libXtaw/Scrollbar.c index c5ed7f1..5c783d6 100644 --- a/xts5/src/libXtaw/Scrollbar.c +++ b/xts5/src/libXtaw/Scrollbar.c @@ -272,7 +272,7 @@ static float FractionLoc(w, x, y) } -static FillArea(w, top, bottom, thumb) +static void FillArea(w, top, bottom, thumb) ScrollbarWidget w; Position top, bottom; int thumb; -- 2.9.3 From wharms at bfs.de Sat Oct 29 20:45:00 2016 From: wharms at bfs.de (walter harms) Date: Sat, 29 Oct 2016 22:45:00 +0200 Subject: [PATCH xts 2/3] xts5: Fix missing variable for format specifier In-Reply-To: <20161029033759.6386-2-rhyskidd@gmail.com> References: <20161029033759.6386-1-rhyskidd@gmail.com> <20161029033759.6386-2-rhyskidd@gmail.com> Message-ID: <58150A4C.304@bfs.de> Am 29.10.2016 05:37, schrieb Rhys Kidd: > XtRemoveEventHandler.c:458:3: warning: format '%d' expects a matching 'int' argument [-Wformat=] > sprintf(ebuf, "ERROR: Error message handler was invoked %d times"); > ^ > XtRemoveEventHandler.c:463:3: warning: format '%d' expects a matching 'int' argument [-Wformat=] > sprintf(ebuf, "ERROR: Warning message handler was invoked %d times"); > ^ > XtRemoveEventHandler.c:540:3: warning: format '%d' expects a matching 'int' argument [-Wformat=] > sprintf(ebuf, "ERROR: Error message handler was invoked %d times"); > ^ > XtRemoveEventHandler.c:545:3: warning: format '%d' expects a matching 'int' argument [-Wformat=] > sprintf(ebuf, "ERROR: Warning message handler was invoked %d times"); > ^ > > Signed-off-by: Rhys Kidd > --- > xts5/Xt9/XtRemoveEventHandler.m | 16 ++++++++-------- > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/xts5/Xt9/XtRemoveEventHandler.m b/xts5/Xt9/XtRemoveEventHandler.m > index 1851ef9..6e6cbbe 100644 > --- a/xts5/Xt9/XtRemoveEventHandler.m > +++ b/xts5/Xt9/XtRemoveEventHandler.m > @@ -425,13 +425,13 @@ int invoked = 0; > XtAppMainLoop(app_ctext); > LKROF(pid2, AVSXTTIMEOUT-2); > tet_infoline("TEST: Error message was not emitted"); > - if (avs_get_event(3) != 0) { > - sprintf(ebuf, "ERROR: Error message handler was invoked %d times"); > + if (invoked = avs_get_event(3) != 0) { > + sprintf(ebuf, "ERROR: Error message handler was invoked %d times", invoked); > tet_infoline(ebuf); > tet_result(TET_FAIL); > } IMHO this is to complicated. what is wrong with: invoked = avs_get_event(3); if (invoked != 0) { sprintf(ebuf, "ERROR: Error message handler was invoked %d times", invoked); tet_infoline(ebuf); tet_result(TET_FAIL); } > - if (avs_get_event(2) != 0) { > - sprintf(ebuf, "ERROR: Warning message handler was invoked %d times"); > + if (invoked = avs_get_event(2) != 0) { > + sprintf(ebuf, "ERROR: Warning message handler was invoked %d times", invoked); > tet_infoline(ebuf); > tet_result(TET_FAIL); > } btw: this is the same msg als with avs_get_event(3). I have no clue what the differenz is but maybe it should be reflected in the errmsg. just my 2 cents, re, wh > @@ -491,13 +491,13 @@ int invoked = 0; > tet_result(TET_FAIL); > } > tet_infoline("TEST: Error message was not emitted"); > - if (avs_get_event(3) != 0) { > - sprintf(ebuf, "ERROR: Error message handler was invoked %d times"); > + if (invoked = avs_get_event(3) != 0) { > + sprintf(ebuf, "ERROR: Error message handler was invoked %d times", invoked); > tet_infoline(ebuf); > tet_result(TET_FAIL); > } > - if (avs_get_event(2) != 0) { > - sprintf(ebuf, "ERROR: Warning message handler was invoked %d times"); > + if (invoked = avs_get_event(2) != 0) { > + sprintf(ebuf, "ERROR: Warning message handler was invoked %d times", invoked); > tet_infoline(ebuf); > tet_result(TET_FAIL); > } From rhyskidd at gmail.com Sat Oct 29 22:05:10 2016 From: rhyskidd at gmail.com (Rhys Kidd) Date: Sat, 29 Oct 2016 18:05:10 -0400 Subject: [PATCH xts 2/3] xts5: Fix missing variable for format specifier In-Reply-To: <58150A4C.304@bfs.de> References: <20161029033759.6386-1-rhyskidd@gmail.com> <20161029033759.6386-2-rhyskidd@gmail.com> <58150A4C.304@bfs.de> Message-ID: On 29 October 2016 at 16:45, walter harms wrote: > > > Am 29.10.2016 05:37, schrieb Rhys Kidd: > > XtRemoveEventHandler.c:458:3: warning: format '%d' expects a matching > 'int' argument [-Wformat=] > > sprintf(ebuf, "ERROR: Error message handler was invoked %d times"); > > ^ > > XtRemoveEventHandler.c:463:3: warning: format '%d' expects a matching > 'int' argument [-Wformat=] > > sprintf(ebuf, "ERROR: Warning message handler was invoked %d times"); > > ^ > > XtRemoveEventHandler.c:540:3: warning: format '%d' expects a matching > 'int' argument [-Wformat=] > > sprintf(ebuf, "ERROR: Error message handler was invoked %d times"); > > ^ > > XtRemoveEventHandler.c:545:3: warning: format '%d' expects a matching > 'int' argument [-Wformat=] > > sprintf(ebuf, "ERROR: Warning message handler was invoked %d times"); > > ^ > > > > Signed-off-by: Rhys Kidd > > --- > > xts5/Xt9/XtRemoveEventHandler.m | 16 ++++++++-------- > > 1 file changed, 8 insertions(+), 8 deletions(-) > > > > diff --git a/xts5/Xt9/XtRemoveEventHandler.m b/xts5/Xt9/ > XtRemoveEventHandler.m > > index 1851ef9..6e6cbbe 100644 > > --- a/xts5/Xt9/XtRemoveEventHandler.m > > +++ b/xts5/Xt9/XtRemoveEventHandler.m > > @@ -425,13 +425,13 @@ int invoked = 0; > > XtAppMainLoop(app_ctext); > > LKROF(pid2, AVSXTTIMEOUT-2); > > tet_infoline("TEST: Error message was not emitted"); > > - if (avs_get_event(3) != 0) { > > - sprintf(ebuf, "ERROR: Error message handler was invoked %d > times"); > > + if (invoked = avs_get_event(3) != 0) { > > + sprintf(ebuf, "ERROR: Error message handler was invoked %d > times", invoked); > > tet_infoline(ebuf); > > tet_result(TET_FAIL); > > } > > IMHO this is to complicated. what is wrong with: > > invoked = avs_get_event(3); > if (invoked != 0) { > sprintf(ebuf, "ERROR: Error message handler was invoked %d > times", invoked); > tet_infoline(ebuf); > tet_result(TET_FAIL); > } > > > Hello Walter, thanks for your review. As an early patch from me, I preferred to keep consistent with the pattern adopted in this part of the code base -- rather than changing the pattern via refactoring at the same time as making the bug fix. e.g. you can see another example here: xts5/XtC/XtSetSelectionTimeout.m I'd prefer to keep this patch as is in this respect. There's nothing stopping a follow-up patch making your suggested changes. > > > - if (avs_get_event(2) != 0) { > > - sprintf(ebuf, "ERROR: Warning message handler was invoked > %d times"); > > + if (invoked = avs_get_event(2) != 0) { > > + sprintf(ebuf, "ERROR: Warning message handler was invoked > %d times", invoked); > > tet_infoline(ebuf); > > tet_result(TET_FAIL); > > } > > > btw: this is the same msg als with avs_get_event(3). I have no clue what > the differenz is > but maybe it should be reflected in the errmsg. > > There's a subtle difference. - The errmsg associated with avs_get_event(2) includes the text "*Warning* message handler...." - The errmsg associated with avs_get_event(3) includes the text "*Error* message handler..." If there is a problem with the existing approach, which is a pattern throughout this area of the code, then I'd prefer it is addressed in a subsequent patch. Accordingly, can I seek your Reviewed-by? Regards, Rhys > just my 2 cents, > > re, > wh > > > > @@ -491,13 +491,13 @@ int invoked = 0; > > tet_result(TET_FAIL); > > } > > tet_infoline("TEST: Error message was not emitted"); > > - if (avs_get_event(3) != 0) { > > - sprintf(ebuf, "ERROR: Error message handler was invoked %d > times"); > > + if (invoked = avs_get_event(3) != 0) { > > + sprintf(ebuf, "ERROR: Error message handler was invoked %d > times", invoked); > > tet_infoline(ebuf); > > tet_result(TET_FAIL); > > } > > - if (avs_get_event(2) != 0) { > > - sprintf(ebuf, "ERROR: Warning message handler was invoked > %d times"); > > + if (invoked = avs_get_event(2) != 0) { > > + sprintf(ebuf, "ERROR: Warning message handler was invoked > %d times", invoked); > > tet_infoline(ebuf); > > tet_result(TET_FAIL); > > } > _______________________________________________ > xorg-devel at lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.hutterer at who-t.net Mon Oct 31 05:26:31 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Mon, 31 Oct 2016 15:26:31 +1000 Subject: [PATCH xf86-input-libinput 0/2] Tablet tool pressurecurve support Message-ID: <20161031052633.22381-1-peter.hutterer@who-t.net> This set adds the pressurecurve implementation, in a similar manner to what the current xf86-input-wacom driver supports. It's slightly more on-demand, it's per tool (because everything in the driver is per-tool anyway) and the configuration is a tad more flexible with 4 configurable control points instead of just two. Cheers, Peter From peter.hutterer at who-t.net Mon Oct 31 05:26:32 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Mon, 31 Oct 2016 15:26:32 +1000 Subject: [PATCH xf86-input-libinput 1/2] Add a bezier curve implementation In-Reply-To: <20161031052633.22381-1-peter.hutterer@who-t.net> References: <20161031052633.22381-1-peter.hutterer@who-t.net> Message-ID: <20161031052633.22381-2-peter.hutterer@who-t.net> Needed for the wacom stylus pressure curve Signed-off-by: Peter Hutterer --- src/Makefile.am | 5 +- src/bezier.c | 170 +++++++++++++++++++++++++++++++++++++++++++++ src/bezier.h | 67 ++++++++++++++++++ test/Makefile.am | 5 +- test/test-bezier.c | 199 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 443 insertions(+), 3 deletions(-) create mode 100644 src/bezier.c create mode 100644 src/bezier.h create mode 100644 test/test-bezier.c diff --git a/src/Makefile.am b/src/Makefile.am index 60703e6..8634b69 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -30,10 +30,11 @@ AM_CPPFLAGS =-I$(top_srcdir)/include $(LIBINPUT_CFLAGS) @DRIVER_NAME at _drv_la_LTLIBRARIES = @DRIVER_NAME at _drv.la @DRIVER_NAME at _drv_la_LDFLAGS = -module -avoid-version - at DRIVER_NAME@_drv_la_LIBADD = $(LIBINPUT_LIBS) libdraglock.la + at DRIVER_NAME@_drv_la_LIBADD = $(LIBINPUT_LIBS) libdraglock.la -lm @DRIVER_NAME at _drv_ladir = @inputdir@ @DRIVER_NAME at _drv_la_SOURCES = xf86libinput.c -noinst_LTLIBRARIES = libdraglock.la +noinst_LTLIBRARIES = libdraglock.la libbezier.la libdraglock_la_SOURCES = draglock.c draglock.h +libbezier_la_SOURCES = bezier.c bezier.h diff --git a/src/bezier.c b/src/bezier.c new file mode 100644 index 0000000..e571a3c --- /dev/null +++ b/src/bezier.c @@ -0,0 +1,170 @@ +/* + * Copyright © 2016 Red Hat, Inc. + * + * Permission to use, copy, modify, distribute, and sell this software + * and its documentation for any purpose is hereby granted without + * fee, provided that the above copyright notice appear in all copies + * and that both that copyright notice and this permission notice + * appear in supporting documentation, and that the name of Red Hat + * not be used in advertising or publicity pertaining to distribution + * of the software without specific, written prior permission. Red + * Hat makes no representations about the suitability of this software + * for any purpose. It is provided "as is" without express or implied + * warranty. + * + * THE AUTHORS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN + * NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS + * OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, + * NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN + * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#include +#include +#include + +#include "bezier.h" + +struct point { + int x, y; +}; + +/** + * de Casteljau's algorithm. See this page here + * https://pomax.github.io/bezierinfo/#extended + * + * To play with bezier curve shapes, I used + * http://cubic-bezier.com/ + */ +static struct point +decasteljau(const struct point *controls, + size_t ncontrols, + double t) +{ + struct point new_controls[ncontrols]; + + if (ncontrols == 1) + return controls[0]; + + for (int i = 0; i < ncontrols - 1; i++) { + new_controls[i].x = (1.0 - t) * controls[i].x + t * controls[i + 1].x; + new_controls[i].y = (1.0 - t) * controls[i].y + t * controls[i + 1].y; + } + + return decasteljau(new_controls, ncontrols - 1, t); +} + +/** + * Given a Bézier curve defined by the control points, reduce the curve to + * one with ncurve_points. + */ +static void +flatten_curve(const struct point *controls, + size_t ncontrols, + struct point *curve, + size_t ncurve_points) +{ + ncurve_points--; /* make sure we end up with 100/100 as last point */ + + for (int i = 0; i <= ncurve_points; i++) { + double t = 1.0 * i/ncurve_points; + struct point p; + + p = decasteljau(controls, ncontrols, t); + curve[i] = p; + } +} + +/** + * Calculate line through a and b, set curve[x] for each x between + * [a.x, b.x]. + * + * Note: pcurve must be at least b.x size. + */ +static void +line_between(struct point a, struct point b, + struct point *curve, size_t curve_sz) +{ + double slope; + double offset; + + assert(b.x < curve_sz); + + if (a.x == b.x) { + curve[a.x].x = a.x; + curve[a.x].y = a.y; + return; + } + + slope = (double)(b.y - a.y)/(b.x - a.x); + offset = a.y - slope * a.x; + + for (int x = a.x; x <= b.x; x++) { + struct point p; + p.x = x; + p.y = slope * x + offset; + curve[x] = p; + } +} + +bool +cubic_bezier(const struct bezier_control_point controls[4], + int *bezier_out, + size_t bezier_sz) +{ + const int nsegments = 50; + const int range = bezier_sz - 1; + struct point curve[nsegments]; + struct point bezier[bezier_sz]; + struct point zero = { 0, 0 }, + max = { range, range}; + + /* Scale control points into the [0, bezier_sz) range */ + struct point ctrls[4]; + + for (int i = 0; i < 4; i++) { + if (controls[i].x < 0.0 || controls[i].x > 1.0 || + controls[i].y < 0.0 || controls[i].y > 1.0) + return false; + + ctrls[i].x = controls[i].x * range; + ctrls[i].y = controls[i].y * range; + } + + for (int i = 0; i < 3; i++) { + if (ctrls[i].x > ctrls[i+1].x) + return false; + } + + /* Reduce curve to nsegments, because this isn't a drawing program */ + flatten_curve(ctrls, 4, curve, nsegments); + + /* we now have nsegments points in curve that represent the bezier + curve (already in the [0, bezier_sz) range). Run through the + points and draw a straight line between each point and voila, we + have our curve. + + If the first control points (x0/y0) is not at x == 0 or the last + control point (x3/y3) is not at the max value, draw a line + between from 0/0 to x0/y0 and from x3/y3 to xmax/y3. + */ + + line_between(zero, curve[0], bezier, bezier_sz); + + for (int i = 0; i < nsegments - 1; i++) + line_between(curve[i], curve[i+1], bezier, bezier_sz); + + if (curve[nsegments - 1].x < max.x) + line_between(curve[nsegments - 1], max, bezier, bezier_sz); + + for (int i = 0; i < bezier_sz; i++) + bezier_out[i] = bezier[i].y; + + return true; +} diff --git a/src/bezier.h b/src/bezier.h new file mode 100644 index 0000000..c7f3b27 --- /dev/null +++ b/src/bezier.h @@ -0,0 +1,67 @@ +/* + * Copyright © 2016 Red Hat, Inc. + * + * Permission to use, copy, modify, distribute, and sell this software + * and its documentation for any purpose is hereby granted without + * fee, provided that the above copyright notice appear in all copies + * and that both that copyright notice and this permission notice + * appear in supporting documentation, and that the name of Red Hat + * not be used in advertising or publicity pertaining to distribution + * of the software without specific, written prior permission. Red + * Hat makes no representations about the suitability of this software + * for any purpose. It is provided "as is" without express or implied + * warranty. + * + * THE AUTHORS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN + * NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS + * OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, + * NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN + * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#ifndef BEZIER_H +#define BEZIER_H + +#include +#include + +struct bezier_control_point { + double x, y; +}; + +/** + * Given four control points in the range [(0.0/0.0), (1.0/1.0)] + * construct a Bézier curve. + * + * ^ + *1.0 | c2 ______ c3 + * | _/ + * | / + * |c1 / + * | / + * | / + * |/_________________> + * c0 1.0 + * + * This function requires that c[i].x <= c[i+1].x + * + * The curve is mapped into a canvas size [0, bezier_sz)². For each x + * coordiante in [0, bezier_sz), the matching y coordinate is thus + * bezier[x]. + * + * In other words, if you have a range [0,2048) input possible values, + * the output is a list of 2048 points in a [0, 2048) range. + * + * @return true on success, false otherwise + */ +bool +cubic_bezier(const struct bezier_control_point controls[4], + int *bezier, + size_t bezier_sz); +#endif diff --git a/test/Makefile.am b/test/Makefile.am index 6f94abe..4c9c5f6 100644 --- a/test/Makefile.am +++ b/test/Makefile.am @@ -3,11 +3,14 @@ AM_CPPFLAGS = $(XORG_CFLAGS) \ -I$(top_srcdir)/include \ -I$(top_srcdir)/src -tests = test-draglock +tests = test-draglock test-bezier noinst_PROGRAMS = $(tests) test_draglock_SOURCES = test-draglock.c test_draglock_LDADD = ../src/libdraglock.la +test_bezier_SOURCES = test-bezier.c +test_bezier_LDADD = ../src/libbezier.la -lm + TESTS = $(tests) diff --git a/test/test-bezier.c b/test/test-bezier.c new file mode 100644 index 0000000..1b290a4 --- /dev/null +++ b/test/test-bezier.c @@ -0,0 +1,199 @@ +/* + * Copyright © 2016 Red Hat, Inc. + * + * Permission to use, copy, modify, distribute, and sell this software + * and its documentation for any purpose is hereby granted without + * fee, provided that the above copyright notice appear in all copies + * and that both that copyright notice and this permission notice + * appear in supporting documentation, and that the name of Red Hat + * not be used in advertising or publicity pertaining to distribution + * of the software without specific, written prior permission. Red + * Hat makes no representations about the suitability of this software + * for any purpose. It is provided "as is" without express or implied + * warranty. + * + * THE AUTHORS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN + * NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS + * OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, + * NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN + * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#include "bezier.h" + +#include +#include +#include + +static inline void +print_curve(int *bezier, size_t size) +{ + /* look at it with gnuplot, "plot 'output-file.txt'" */ + for (int i = 0; i < size; i++) + printf("%d %d\n", i, bezier[i]); +} + +static void +test_linear(void) +{ + const int size = 2048; + int bezier[size]; + + struct bezier_control_point controls[] = { + { 0.0, 0.0 }, + { 0.0, 0.0 }, + { 1.0, 1.0 }, + { 1.0, 1.0 } + }; + + cubic_bezier(controls, bezier, size); + + assert(bezier[0] == 0); + assert(bezier[size - 1] == size - 1); + + for (int x = 1; x < size; x++) + assert(bezier[x] == x); +} + +/* Center point pulled down towards X axis */ +static void +test_flattened(void) +{ + const int size = 2048; + int bezier[size]; + + struct bezier_control_point controls[] = { + { 0.0, 0.0 }, + { 0.1, 0.0 }, + { 1.0, 0.9 }, + { 1.0, 1.0 } + }; + + cubic_bezier(controls, bezier, size); + + assert(bezier[0] == 0); + assert(bezier[size - 1] == size - 1); + + for (int x = 1; x < size - 1; x++) { + assert(bezier[x] < x); + } +} + +/* Center point pulled up from X axis */ +static void +test_raised(void) +{ + const int size = 2048; + int bezier[size]; + + struct bezier_control_point controls[] = { + { 0.0, 0.0 }, + { 0.1, 0.4 }, + { 0.4, 1.0 }, + { 1.0, 1.0 } + }; + + cubic_bezier(controls, bezier, size); + + assert(bezier[0] == 0); + assert(bezier[size - 1] == size - 1); + + for (int x = 1; x < size; x++) + assert(bezier[x] >= x); + + for (int x = 10; x < size - 10; x++) + assert(bezier[x] > x); +} + +static void +test_windy(void) +{ + const int size = 2048; + int bezier[size]; + + struct bezier_control_point controls[] = { + { 0.0, 0.0 }, + { 0.0, 0.3 }, + { 1.0, 0.7 }, + { 1.0, 1.0 } + }; + + cubic_bezier(controls, bezier, size); + + assert(bezier[0] == 0); + assert(bezier[size - 1] == size - 1); + + for (int x = 1; x < size/2 - 20; x++) + assert(bezier[x] > x); + + for (int x = size/2 + 20; x < size - 1; x++) + assert(bezier[x] < x); +} + +static void +test_nonzero_x_linear(void) +{ + const int size = 2048; + int bezier[size]; + int x; + + struct bezier_control_point controls[] = { + { 0.2, 0.0 }, + { 0.2, 0.0 }, + { 0.8, 1.0 }, + { 0.8, 1.0 } + }; + + cubic_bezier(controls, bezier, size); + + x = 0; + do { + assert(bezier[x] == 0); + } while (++x < size * 0.2 - 1); + + do { + assert(bezier[x] > bezier[x-1]); + } while (++x < size * 0.8 - 1); + + do { + assert(bezier[x] == size - 1); + } while (++x < size); +} + +static void +test_nonzero_y_linear(void) +{ + const int size = 2048; + int bezier[size]; + + struct bezier_control_point controls[] = { + { 0.0, 0.2 }, + { 0.0, 0.2 }, + { 1.0, 0.8 }, + { 1.0, 0.8 } + }; + + cubic_bezier(controls, bezier, size); + + assert(bezier[0] == (int)(size * 0.2)); + + for (int x = 1; x < size; x++) { + assert(bezier[x - 1] <= bezier[x]); + assert(bezier[x] >= (int)(size * 0.2)); + } +} + +int +main(int argc, char **argv) +{ + test_linear(); + test_flattened(); + test_raised(); + test_windy(); + test_nonzero_x_linear(); + test_nonzero_y_linear(); + + return 0; +} -- 2.9.3 From peter.hutterer at who-t.net Mon Oct 31 05:26:33 2016 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Mon, 31 Oct 2016 15:26:33 +1000 Subject: [PATCH xf86-input-libinput 2/2] Implement stylus pressure curve support In-Reply-To: <20161031052633.22381-1-peter.hutterer@who-t.net> References: <20161031052633.22381-1-peter.hutterer@who-t.net> Message-ID: <20161031052633.22381-3-peter.hutterer@who-t.net> Takes a 4-point cubic bezier curve as input and maps the pressure coordinates to the values outlined by this curve. This is an extension of the current implementation in the xf86-input-wacom driver which only allows the two center control points to be modified. Over the years a few users have noted that the wacom driver's pressure curve makes it impossible to cap the pressure at a given value. Given our bezier implementation here, it's effectively a freebie to add configurability of the first and last control points. We do require all control points' x coordinates to be in ascending order. Signed-off-by: Peter Hutterer --- include/libinput-properties.h | 7 ++ man/libinput.man | 31 +++++++ src/Makefile.am | 2 +- src/bezier.c | 7 ++ src/bezier.h | 2 + src/xf86libinput.c | 184 +++++++++++++++++++++++++++++++++++++++++- 6 files changed, 230 insertions(+), 3 deletions(-) diff --git a/include/libinput-properties.h b/include/libinput-properties.h index 8c6942d..f76500f 100644 --- a/include/libinput-properties.h +++ b/include/libinput-properties.h @@ -183,4 +183,11 @@ /* Device rotation: FLOAT, 1 value, 32 bit, read-only */ #define LIBINPUT_PROP_ROTATION_ANGLE_DEFAULT "libinput Rotation Angle Default" +/* Tablet tool pressure curve: float, 8 values, 32 bit + * Value range is [0.0, 1.0], the values specify the x/y of the four + * control points for a cubic bezier curve. + * Default value: 0.0 0.0 0.0 0.0 1.0 1.0 1.0 1.0 + */ +#define LIBINPUT_PROP_TABLET_TOOL_PRESSURECURVE "libinput Tablet Tool Pressurecurve" + #endif /* _LIBINPUT_PROPERTIES_H_ */ diff --git a/man/libinput.man b/man/libinput.man index 36775e6..c1655a7 100644 --- a/man/libinput.man +++ b/man/libinput.man @@ -155,6 +155,12 @@ default scroll option for this device is used. Sets the send events mode to disabled, enabled, or "disable when an external mouse is connected". .TP 7 +.BI "Option \*qTabletToolPressureCurve\*q \*q" "x0/y0 x1/y1 x2/y2 x3/y3" \*q +Set the pressure curve for a tablet stylus to the bezier formed by the four +points. The respective x/y coordinate must be in the [0.0, 1.0] range. For +more information see section +.B TABLET STYLUS PRESSURE CURVE. +.TP 7 .BI "Option \*qTapping\*q \*q" bool \*q Enables or disables tap-to-click behavior. .TP 7 @@ -252,6 +258,11 @@ on this device. "disabled-on-external-mouse". Indicates which send-event modes is currently enabled on this device. .TP 7 +.BI "libinput Tablet Tool Pressurecurve" +4 32-bit float values [0.0 to 1.0]. See section +.B TABLET TOOL PRESSURE CURVE +for more information. +.TP 7 .BI "libinput Tapping Enabled" 1 boolean value (8 bit, 0 or 1). 1 enables tapping .TP 7 @@ -313,6 +324,26 @@ and only the target button events are sent. .TP This feature is provided by this driver, not by libinput. +.SH TABLET TOOL PRESSURECURVE +The pressure curve affects how stylus pressure is reported. By default, the +hardware pressure is reported as-is and (usually). By setting a pressure curve, +the feel of the stylus can be adjusted to be more like e.g. a pencil or a +brush. +.PP +The pressure curve is a cubic Bezier curve, drawn within a normalized range +of 0.0 to 1.0 between the four points provided. This normalized range is +applied to the tablet's pressure input so that the highest pressure maps to +1.0. The points must have increasing x coordinates, if x0 is larger than 0.0 +all pressure values lower than x0 are equivalent to y0. If x3 is less than +1.0, all pressure values higher than x3 are equivalent to y3. + +The input for a linear curve (default) is "0.0/0.0 0.0/0.0 1.0/1.0 1.0/1.0"; +a slightly +depressed curve (firmer) might be "0.0/0.0 0.05/0.0 1.0/0.95 1.0/1.0"; a slightly raised +curve (softer) might be "0.0/0.0 0.0/0.05 0.95/1.0 1.0/1.0". +.TP +This feature is provided by this driver, not by libinput. + .SH AUTHORS Peter Hutterer .SH "SEE ALSO" diff --git a/src/Makefile.am b/src/Makefile.am index 8634b69..5dcb55e 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -30,7 +30,7 @@ AM_CPPFLAGS =-I$(top_srcdir)/include $(LIBINPUT_CFLAGS) @DRIVER_NAME at _drv_la_LTLIBRARIES = @DRIVER_NAME at _drv.la @DRIVER_NAME at _drv_la_LDFLAGS = -module -avoid-version - at DRIVER_NAME@_drv_la_LIBADD = $(LIBINPUT_LIBS) libdraglock.la -lm + at DRIVER_NAME@_drv_la_LIBADD = $(LIBINPUT_LIBS) libdraglock.la libbezier.la -lm @DRIVER_NAME at _drv_ladir = @inputdir@ @DRIVER_NAME at _drv_la_SOURCES = xf86libinput.c diff --git a/src/bezier.c b/src/bezier.c index e571a3c..95af16a 100644 --- a/src/bezier.c +++ b/src/bezier.c @@ -31,6 +31,13 @@ #include "bezier.h" +const struct bezier_control_point bezier_defaults[4] = { + { 0.0, 0.0 }, + { 0.0, 0.0 }, + { 1.0, 1.0 }, + { 1.0, 1.0 }, +}; + struct point { int x, y; }; diff --git a/src/bezier.h b/src/bezier.h index c7f3b27..7406565 100644 --- a/src/bezier.h +++ b/src/bezier.h @@ -35,6 +35,8 @@ struct bezier_control_point { double x, y; }; +extern const struct bezier_control_point bezier_defaults[4]; + /** * Given four control points in the range [(0.0/0.0), (1.0/1.0)] * construct a Bézier curve. diff --git a/src/xf86libinput.c b/src/xf86libinput.c index 07b4d4e..470b1ff 100644 --- a/src/xf86libinput.c +++ b/src/xf86libinput.c @@ -42,6 +42,7 @@ #include +#include "bezier.h" #include "draglock.h" #include "libinput-properties.h" @@ -162,6 +163,7 @@ struct xf86libinput { BOOL horiz_scrolling_enabled; float rotation_angle; + struct bezier_control_point pressurecurve[4]; } options; struct draglock draglock; @@ -172,6 +174,13 @@ struct xf86libinput { struct libinput_tablet_tool *tablet_tool; bool allow_mode_group_updates; + + /* Pre-calculated pressure curve. + In the 0...TABLET_AXIS_MAX range */ + struct { + int *values; + size_t sz; + } pressurecurve; }; enum event_handling { @@ -382,6 +391,30 @@ xf86libinput_shared_is_enabled(struct xf86libinput_device *shared_device) return shared_device->enabled_count > 0; } +static inline bool +xf86libinput_set_pressurecurve(struct xf86libinput *driver_data, + const struct bezier_control_point controls[4]) +{ + if (memcmp(controls, bezier_defaults, sizeof(bezier_defaults)) == 0) { + free(driver_data->pressurecurve.values); + driver_data->pressurecurve.values = NULL; + return true; + } + + if (!driver_data->pressurecurve.values) { + int *vals = calloc(TABLET_PRESSURE_AXIS_MAX + 1, sizeof(int)); + if (!vals) + return false; + + driver_data->pressurecurve.values = vals; + driver_data->pressurecurve.sz = TABLET_PRESSURE_AXIS_MAX + 1; + } + + return cubic_bezier(controls, + driver_data->pressurecurve.values, + driver_data->pressurecurve.sz); +} + static int LibinputSetProperty(DeviceIntPtr dev, Atom atom, XIPropertyValuePtr val, BOOL checkonly); @@ -1626,8 +1659,9 @@ xf86libinput_handle_tablet_axis(InputInfoPtr pInfo, tool = libinput_event_tablet_tool_get_tool(event); if (libinput_tablet_tool_has_pressure(tool)) { - value = libinput_event_tablet_tool_get_pressure(event); - value *= TABLET_PRESSURE_AXIS_MAX; + value = TABLET_PRESSURE_AXIS_MAX * libinput_event_tablet_tool_get_pressure(event); + if (driver_data->pressurecurve.values) + value = driver_data->pressurecurve.values[(int)value]; valuator_mask_set_double(mask, 2, value); } @@ -2606,6 +2640,69 @@ xf86libinput_parse_rotation_angle_option(InputInfoPtr pInfo, } static void +xf86libinput_parse_pressurecurve_option(InputInfoPtr pInfo, + struct xf86libinput *driver_data, + struct bezier_control_point pcurve[4]) +{ + struct bezier_control_point controls[4] = { + { 0.0, 0.0 }, + { 0.0, 0.0 }, + { 1.0, 1.0 }, + { 1.0, 1.0 }, + }; + float points[8]; + char *str; + int rc = 0; + int test_bezier[64]; + struct libinput_tablet_tool *tool = driver_data->tablet_tool; + + if ((driver_data->capabilities & CAP_TABLET_TOOL) == 0) + return; + + if (!tool || !libinput_tablet_tool_has_pressure(tool)) + return; + + str = xf86SetStrOption(pInfo->options, + "TabletToolPressureCurve", + NULL); + if (!str) + goto out; + + rc = sscanf(str, "%f/%f %f/%f %f/%f %f/%f", + &points[0], &points[1], &points[2], &points[3], + &points[4], &points[5], &points[6], &points[7]); + if (rc != 8) + goto out; + + for (int i = 0; i < 4; i++) { + if (points[i] < 0.0 || points[i] > 1.0) + goto out; + } + + controls[0].x = points[0]; + controls[0].y = points[1]; + controls[1].x = points[2]; + controls[1].y = points[3]; + controls[2].x = points[4]; + controls[2].y = points[5]; + controls[3].x = points[6]; + controls[3].y = points[7]; + + if (!cubic_bezier(controls, test_bezier, ARRAY_SIZE(test_bezier))) { + memcpy(controls, bezier_defaults, sizeof(controls)); + goto out; + } + + rc = 0; +out: + if (rc != 0) + xf86IDrvMsg(pInfo, X_ERROR, "Invalid pressure curve: %s\n", str); + free(str); + memcpy(pcurve, controls, sizeof(controls)); + xf86libinput_set_pressurecurve(driver_data, controls); +} + +static void xf86libinput_parse_options(InputInfoPtr pInfo, struct xf86libinput *driver_data, struct libinput_device *device) @@ -2638,6 +2735,10 @@ xf86libinput_parse_options(InputInfoPtr pInfo, xf86libinput_parse_draglock_option(pInfo, driver_data); options->horiz_scrolling_enabled = xf86libinput_parse_horiz_scroll_option(pInfo); } + + xf86libinput_parse_pressurecurve_option(pInfo, + driver_data, + options->pressurecurve); } static const char* @@ -3086,6 +3187,7 @@ static Atom prop_rotation_angle_default; /* driver properties */ static Atom prop_draglock; static Atom prop_horiz_scroll; +static Atom prop_pressurecurve; /* general properties */ static Atom prop_float; @@ -3815,6 +3917,52 @@ LibinputSetPropertyRotationAngle(DeviceIntPtr dev, return Success; } +static inline int +LibinputSetPropertyPressureCurve(DeviceIntPtr dev, + Atom atom, + XIPropertyValuePtr val, + BOOL checkonly) +{ + InputInfoPtr pInfo = dev->public.devicePrivate; + struct xf86libinput *driver_data = pInfo->private; + float *vals; + struct bezier_control_point controls[4]; + + if (val->format != 32 || val->size != 8 || val->type != prop_float) + return BadMatch; + + vals = val->data; + controls[0].x = vals[0]; + controls[0].y = vals[1]; + controls[1].x = vals[2]; + controls[1].y = vals[3]; + controls[2].x = vals[4]; + controls[2].y = vals[5]; + controls[3].x = vals[6]; + controls[3].y = vals[7]; + + if (checkonly) { + int test_bezier[64]; + + for (int i = 0; i < val->size; i++) { + if (vals[i] < 0.0 || vals[i] > 1.0) + return BadValue; + } + + if (!xf86libinput_check_device (dev, atom)) + return BadMatch; + + if (!cubic_bezier(controls, test_bezier, ARRAY_SIZE(test_bezier))) + return BadValue; + } else { + xf86libinput_set_pressurecurve(driver_data, controls); + memcpy(driver_data->options.pressurecurve, controls, + sizeof(controls)); + } + + return Success; +} + static int LibinputSetProperty(DeviceIntPtr dev, Atom atom, XIPropertyValuePtr val, BOOL checkonly) @@ -3867,6 +4015,8 @@ LibinputSetProperty(DeviceIntPtr dev, Atom atom, XIPropertyValuePtr val, } else if (atom == prop_rotation_angle) rc = LibinputSetPropertyRotationAngle(dev, atom, val, checkonly); + else if (atom == prop_pressurecurve) + rc = LibinputSetPropertyPressureCurve(dev, atom, val, checkonly); else if (atom == prop_device || atom == prop_product_id || atom == prop_tap_default || atom == prop_tap_drag_default || @@ -4691,6 +4841,35 @@ LibinputInitRotationAngleProperty(DeviceIntPtr dev, } static void +LibinputInitPressureCurveProperty(DeviceIntPtr dev, + struct xf86libinput *driver_data) +{ + const struct bezier_control_point *curve = driver_data->options.pressurecurve; + struct libinput_tablet_tool *tool = driver_data->tablet_tool; + float data[8]; + + if ((driver_data->capabilities & CAP_TABLET_TOOL) == 0) + return; + + if (!tool || !libinput_tablet_tool_has_pressure(tool)) + return; + + data[0] = curve[0].x; + data[1] = curve[0].y; + data[2] = curve[1].x; + data[3] = curve[1].y; + data[4] = curve[2].x; + data[5] = curve[2].y; + data[6] = curve[3].x; + data[7] = curve[3].y; + + prop_pressurecurve = LibinputMakeProperty(dev, + LIBINPUT_PROP_TABLET_TOOL_PRESSURECURVE, + prop_float, 32, + 8, data); +} + +static void LibinputInitProperty(DeviceIntPtr dev) { InputInfoPtr pInfo = dev->public.devicePrivate; @@ -4746,4 +4925,5 @@ LibinputInitProperty(DeviceIntPtr dev) LibinputInitDragLockProperty(dev, driver_data); LibinputInitHorizScrollProperty(dev, driver_data); + LibinputInitPressureCurveProperty(dev, driver_data); } -- 2.9.3 From martin.peres at linux.intel.com Mon Oct 31 06:40:05 2016 From: martin.peres at linux.intel.com (Martin Peres) Date: Mon, 31 Oct 2016 08:40:05 +0200 Subject: [PATCH rendercheck] Report results on a per-test basis In-Reply-To: <87bmy5u0t6.fsf@eliezer.anholt.net> References: <20161006140535.32211-1-martin.peres@linux.intel.com> <87funpfzfa.fsf@eliezer.anholt.net> <87bmy5u0t6.fsf@eliezer.anholt.net> Message-ID: <8a9f3e87-fe32-b1bb-0455-6d769e978540@linux.intel.com> On 27/10/16 21:03, Eric Anholt wrote: > Martin Peres writes: > >> On 21/10/16 19:18, Eric Anholt wrote: >>> Martin Peres writes: >>> >>>> This allows a runner such as EzBench to track each test individually >>>> and not limit the resolution to groups. >>>> >>>> This feature can be triggered by using the -r parameter. >>> >>> I don't really see the point of this -- you need an external runner to >>> be choosing a specific test subset to run per rendercheck call, since >>> the full matrix of composite tests is too long. Once you have an >>> external runner calling rendercheck per test group, all you would be >>> able to do using this patch would be save a few spawns of the process, >>> which doesn't seem worth it. >> >> Just to be sure, are you suggesting I do something like this instead? >> >> for format in "a8r8g8b8 x8r8g8b8 ... more formats"; do >> ./rendercheck -f $format >> # parse the successful groups and store them, prefixed by $format so as >> I can identify regressions per format? >> done > > You should probably look at piglit for subsetting of the tests. > Actually, I'd say you should probably just use piglit. Given that > piglit is what X developers are going to be using, if we're going to > lock rendercheck into specific output formats I'd like to see the piglit > patches included with it. That would be reasonable :) I will look into this. Martin