Re: [PATCH 11/13] glamor: use miZeroPolyArc for 0-width arcs

2014-05-06 Thread Keith Packard
walter harms writes: > IMHO that should be done within miPolyArc(). Agreed. I'll also create an miPolylines to handle that case. Replicating this silly logic all over the server is not useful -- keith.pack...@intel.com pgpWyXsIJcrfh.pgp Description: PGP signature

Re: [PATCH 10/13] glamor: Provide render fallbacks for debugging

2014-05-06 Thread Keith Packard
walter harms writes: > and this is needed why ? I used it a bunch when trying to figure out if glamor's render code was broken, or if there were bugs elsewhere. It was useful to me, so I sent it along to see if other people also might find it useful to them. -- keith.pack...@intel.com pgpVK4

Re: [PATCH 00/13] Updated set of glamor patches

2014-05-06 Thread Eric Anholt
Keith Packard writes: > Here's the current set of glamor patches to be added post 1.16. > > -keith Patches 1, 7, 8, 9 are also: Reviewed-by: Eric Anholt pgp12e2Y8F8hJ.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Arch

Re: [PATCH 12/13] mi: Fill all spans for PolyFillArc at once

2014-05-06 Thread Eric Anholt
Keith Packard writes: > This allocates span data for all of the provided arcs and draws the > whole set in one call, rather than doing them one at a time. For > modern hardware, this is a significant performance improvement. > > Signed-off-by: Keith Packard > --- > mi/mifillarc.c | 98 > ++

Re: [PATCH 06/13] glamor: Add accelerated stipple support

2014-05-06 Thread Eric Anholt
Keith Packard writes: > This copies the stipple to a 8bpp pixmap and uses that to paint the > texture from. > > v2: Create deep stipple pixmap without GLAMOR_CREATE_FBO_NO_FBO > > v3: Fix stipple origin sign (matches tiles now). Track changes > to original stipple with damage. This isn't requ

[PATCH] glamor: Review changes for glamor_dash.c

2014-05-06 Thread Eric Anholt
3 major changes: - Drops power-of-two alignment of our line vertex data, simplifying the code. - Stops reading from the VBO. While on keithp's and my machines the VBO is mapped cached, on many implementations it will be mapped WC, making those reads extremely expensive. - Style fixes (lin

Re: [PATCH 04/13] glamor: Use glamor_program and GL_LINES for 0-width lines

2014-05-06 Thread Eric Anholt
Keith Packard writes: > GL lines are nearly X compliant; you just need to fill in the last > pixel when the client hasn't requested CapNotLast. > > v2: switch to glamor_make_current > > Signed-off-by: Keith Packard > diff --git a/glamor/glamor_lines.c b/glamor/glamor_lines.c > new file mode 100

Re: [PATCH 12/13] mi: Fill all spans for PolyFillArc at once

2014-05-06 Thread walter harms
Am 06.05.2014 18:43, schrieb Eric Anholt: > walter harms writes: > >> Am 06.05.2014 00:02, schrieb Keith Packard: >>> This allocates span data for all of the provided arcs and draws the >>> whole set in one call, rather than doing them one at a time. For >>> modern hardware, this is a significa

Re: [PATCH 5/8] glamor: Split the XV code into XF86-dependent parts and generic.

2014-05-06 Thread walter harms
Am 06.05.2014 18:41, schrieb Eric Anholt: > walter harms writes: > >> Am 05.05.2014 22:09, schrieb Eric Anholt: >>> I want to expose this from Xephyr as well, both to be able to test XV >>> changes rapidly, and beause the XV passthrough to the host's overlay >>> really doesn't work out well whe

Re: [PATCH 03/13] glamor: Use glamor_program for glamor_push_pixels

2014-05-06 Thread Eric Anholt
Keith Packard writes: > This uses the same shaders as glamor_poly_glyph_blt. > > Signed-off-by: Keith Packard > --- > glamor/glamor_glyphblt.c | 131 > ++- > 1 file changed, 49 insertions(+), 82 deletions(-) > > diff --git a/glamor/glamor_glyphblt.c

Re: [PATCH 02/13] glamor: Add glamor_program based copy acceleration

2014-05-06 Thread Eric Anholt
Looks like my reply last night didn't go through... Keith Packard writes: > Paints with textures, using a temporary buffer for overlapping copies > > Performs CPU to GPU transfers for pixmaps in memory. Accelerates copy > plane when both objects are in the GPU. Includes copy_window > acceleration

Re: [PATCH 12/13] mi: Fill all spans for PolyFillArc at once

2014-05-06 Thread Eric Anholt
walter harms writes: > Am 06.05.2014 00:02, schrieb Keith Packard: >> This allocates span data for all of the provided arcs and draws the >> whole set in one call, rather than doing them one at a time. For >> modern hardware, this is a significant performance improvement. >> >> Signed-off-by: Ke

Re: [PATCH 5/8] glamor: Split the XV code into XF86-dependent parts and generic.

2014-05-06 Thread Eric Anholt
walter harms writes: > Am 05.05.2014 22:09, schrieb Eric Anholt: >> I want to expose this from Xephyr as well, both to be able to test XV >> changes rapidly, and beause the XV passthrough to the host's overlay >> really doesn't work out well when we glXSwapBuffers() over the >> colorkey. >> >> S

Re: [PATCH v2 1/2] ephyr: allow starting window at other than 0, 0 location (via kdrive -origin option)

2014-05-06 Thread Laércio de Sousa
Keith, I've just submitted an updated series following your feedback. Please take a look: http://lists.x.org/archives/xorg-devel/2014-May/042329.html CANTATE DOMINO CANTICUM NOVUM QUIA MIRABILIA FECIT Laércio 2014-05-03 15:19 GMT-03:00 Laércio de Sousa : > > Em 03/05/2014 14:02, "Keith Packa

[PATCH v3 2/3] ephyr: enable screen window placement following kdrive -screen option extended syntax

2014-05-06 Thread Laércio de Sousa
With this patch, one can launch Xephyr with option "-screen WxH+X+Y" to place its window origin at (X,Y). This patch relies on a previous one that extends kdrive -screen option syntax to parse +X+Y substring as expected. If +X+Y is not passed in -screen argument string, let the WM place the window

[PATCH v3 0/3] new approach for Xephyr window placement (for multiseat purposes) (v3)

2014-05-06 Thread Laércio de Sousa
This is the v3 of patch series for providing window placement support for Xephyr. Following Keith Packard's feedback, we are dropping use of -origin option to set window placement, and restoring extended -screen option parsing for geometry strings like WxH+X+Y. Moreover, we only force window plac

[PATCH v3 1/3] kdrive: add support to +X+Y syntax in -screen option parsing

2014-05-06 Thread Laércio de Sousa
This patch enhances current -screen option parsing for kdrive-based applications. It can parse strings like x++, storing X and Y offsets in KdScreenInfo instances. For negative values, this patch supports +-X+-Y (not -X-Y) syntax. It will allow e.g. proper Xephyr window placement for multiseat pu

[PATCH v3 3/3] ephyr: set screen size & origin from host X server output's CRTC geometry

2014-05-06 Thread Laércio de Sousa
If a given output is passed via new -output option, Xephyr will query host X server for its info. If the following conditions are met: a. RandR extension is enabled in host X server; b. supported RandR version in host X server is 1.2 or newer; c. the given output name is valid; d. the given ou

Re: [PATCH 13/13] mi: Draw all points/spans for miZeroPolyArc at once if possible

2014-05-06 Thread walter harms
Am 06.05.2014 00:02, schrieb Keith Packard: > Drawing all of the spans in one driver call is a considerable > performance improvement, which we can do unless the arcs are > double-dashed, in which case overlapping dashes should draw the latter > arc contents. > > Signed-off-by: Keith Packard >

Re: [PATCH 12/13] mi: Fill all spans for PolyFillArc at once

2014-05-06 Thread walter harms
Am 06.05.2014 00:02, schrieb Keith Packard: > This allocates span data for all of the provided arcs and draws the > whole set in one call, rather than doing them one at a time. For > modern hardware, this is a significant performance improvement. > > Signed-off-by: Keith Packard > --- > mi/mif

Re: [PATCH 10/13] glamor: Provide render fallbacks for debugging

2014-05-06 Thread walter harms
Am 06.05.2014 00:02, schrieb Keith Packard: > These provide a complete set of fallbacks to isolate the glamor render > code from the rest of the implementation. > > Signed-off-by: Keith Packard > --- > glamor/Makefile.am | 4 +- > glamor/glamor.c | 4 ++ > glam

Re: [PATCH 11/13] glamor: use miZeroPolyArc for 0-width arcs

2014-05-06 Thread walter harms
Am 06.05.2014 00:02, schrieb Keith Packard: > miPolyArc is a whole lot slower than miZeroPolyArc. > > Signed-off-by: Keith Packard > --- > glamor/glamor_core.c | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/glamor/glamor_core.c b/glamor/glamor_core.c > in

Re: [PATCH 5/8] glamor: Split the XV code into XF86-dependent parts and generic.

2014-05-06 Thread walter harms
Am 05.05.2014 22:09, schrieb Eric Anholt: > I want to expose this from Xephyr as well, both to be able to test XV > changes rapidly, and beause the XV passthrough to the host's overlay > really doesn't work out well when we glXSwapBuffers() over the > colorkey. > > Signed-off-by: Eric Anholt >

Re: [PATCH 1/5] xorg: Fix a bunch of format string size warnings in debug code.

2014-05-06 Thread walter harms
Am 05.05.2014 20:10, schrieb Eric Anholt: > Signed-off-by: Eric Anholt > --- > hw/xfree86/common/xf86Events.c | 2 +- > hw/xfree86/common/xf86Helper.c | 4 ++-- > hw/xfree86/dri/dri.c | 2 +- > hw/xfree86/os-support/linux/lnx_video.c | 2 +- > hw/xfr

Re: [PATCH evdev] Use the server's device list for duplicate detection (#78309)

2014-05-06 Thread Hans de Goede
Hi, On 05/06/2014 02:43 AM, Peter Hutterer wrote: > EvdevAddDevice/EvdevRemoveDevice keep a reference to the device to detect > duplicate devices based on the dev_t. > > EvdevAddDevices was called during PreInit, EvdevRemoveDevice was called during > DEVICE_CLOSE. That makes it imbalanced if the