[PATCH xserver 3/3] glamor: Switch XY bitmap putimage function for small images

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

[PATCH xserver 2/3] glamor: Accelerate up XY pixmap putimage a little

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

[PATCH xserver 1/3] glamor: Accelerate PutImage for XYBitmap format

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

[PATCH xserver 0/3] glamor: Accelerate XY format images

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,

Re: [PATCH xserver] glamor: Accelerate XYBitmap PutImage

Adam Jackson writes: > This could probably be made faster if GL exposed an R1 texture format. The existing core text code emulates R1 textures; it seems like you could use those programs for this. We could also use that for PushPixels at some point. -- -keith signature.asc

[PATCH xserver 3/3] modesetting: allow switching from software to hardware cursors (v5).

Currently if modesetting ever fails to set a hardware cursor it will switch to using a software cursor and never go back. Change this to only permanently switch to a software cursor if -ENXIO is returned (which means hardware cursors not supported), and to otherwise still try a hardware cursor

[PATCH xserver 2/3] modesetting: Immediately handle failure to set HW cursor, v5

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).

[PATCH xserver 1/3] xfree86: Immediately handle failure to set HW cursor, v5

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).

Re: [PATCH xserver] modesetting: always set a hardware cursor when requested to load one.

Hello Hans, On 29.09.2016 09:56, Hans de Goede wrote: Hi, On 28-09-16 16:54, Michael Thayer wrote: Hello Hans, On 28.09.2016 15:37, Hans de Goede wrote: Hi Michael, On 28-09-16 14:47, Michael Thayer wrote: [...] On 09/16/2016 06:52 PM, Michael Thayer wrote: When the X server asks us to

Re: [PATCH] glamor: spans: fixup wrong count on glDrawArrays

Mark Yao writes: > since commit (9e9fcf5 glamor: Add a helper function for the common > GL_QUADS fallback pattern.), the glDrawArrays count change to nbox, > That is wrong, I think it maybe cause by fat finger. > > Signed-off-by: Mark Yao

[PATCH xserver] glamor: Accelerate XYBitmap PutImage

XYBitmap to a drawable of depth != 1 is special. Where bits are 1, we draw the foreground color; where they are 0, we draw the background color. To handle this without falling back, allocate a temporary pixmap, do the color expansion in software, and then upload that image to the destination.

[PATCH xserver] os/xdmcp: Honour -once when session is dead

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 @@

[PATCH 2/2] xfree86: Try harder to find atleast 1 non GPU Screen

If we did not find any non GPU Screens, try again ignoring the notion of any video devices being the primary device. This fixes Xorg exiting with a "no screens found" error when using virtio-vga in a virtual-machine and when using a device driven by simpledrm. This is a somewhat ugly solution,

[PATCH 1/2] xfree86: Make adding unclaimed devices as GPU devices a separate step

This is primarily a preparation patch for fixing the xserver exiting with a "no screens found" error even though there are supported video cards, due to the server not recognizing any card as the primary card. This also fixes the (mostly theoretical) case of a platformBus capable driver adding a

[PATCH] xfree86: Remove redundant ServerIsNotSeat0 check from xf86CallDriverProbe

If foundScreen is TRUE, then all the code below the removed if will not execute until we reach the return foundScreen; at the end, so this entire if block is redundant. Signed-off-by: Hans de Goede --- hw/xfree86/common/xf86Bus.c | 2 -- 1 file changed, 2 deletions(-) diff