Re: [PATCH] dri2: Sync i965_pci_ids.h from Mesa.

Kenneth Graunke writes: > Copied from Mesa with no modifications. Gives us Geminilake PCI IDs. > > Signed-off-by: Kenneth Graunke Acked-by: Eric Anholt signature.asc Description: PGP signature

Re: [PATCH xserver v3] autobind GPUs to the screen

Hans de Goede writes: > From: Dave Airlie > > This is a modified version of a patch we've been carry-ing in Fedora and "carrying" > RHEL for years now. This patch automatically adds secondary GPUs to the > master as output sink / offload source making

[PATCH] dri2: Sync i965_pci_ids.h from Mesa.

Copied from Mesa with no modifications. Gives us Geminilake PCI IDs. Signed-off-by: Kenneth Graunke --- hw/xfree86/dri2/pci_ids/i965_pci_ids.h | 40 ++ 1 file changed, 21 insertions(+), 19 deletions(-) diff --git

Re: [PATCH xserver] glamor: avoid a crash if texture allocation failed

Olivier Fourdan writes: > Texture creation in _glamor_create_tex() can fail if a GL_OUT_OF_MEMORY > is raised, in which case the texture returned is zero. > > But the texture value is not checked in glamor_create_fbo() and glamor > will abort in glamor_pixmap_ensure_fb()

Re: [PATCH xserver 0/3] Death to 24bpp, v3

On Fri, 2017-03-17 at 13:47 -0400, Adam Jackson wrote: > New in this round: > > 1/ fixes a bizzare bit of Xephyr glamor that would zero bitsPerPixel for > the screen. That, combined with the if (Ones(bpp) != 1) in fbScreenInit, > meant glamor would crash on init. > > 3/ also removes the now-dead

[PATCH xserver 3/3] fb: Remove 24bpp support (v3)

v2: - Require power-of-two bpp in ScreenInit - Eliminate fbCreatePixmapBpp v3 - Squash in the exa and glamor changes so we can remove pRotatedPixmap in the same stroke. Signed-off-by: Adam Jackson --- exa/exa.c| 25 +-- fb/Makefile.am | 2 - fb/fb.h

[PATCH xserver] configure.ac: fix checking for libdrm version after 9232835bd

Fix commit 9232835bd16b6948442f7a4588fb9376782cb814 glamor: use drmGetDeviceNameFromFD2 when available No matter what libdrm version was installed, it always set the GLAMOR_HAS_DRM_NAME_FROM_FD_2 conditional to 1. This obviously leads to compilation problems. Signed-off-by: Mariusz Bialonczyk

[PATCH xserver 2/3] xfree86: Remove 24bpp pixmap format support (v2)

There's really no reason to pretend to support this, apps hate it, all we're doing is giving people a way to injure themselves. It doesn't work anyway with any Radeon, any NVIDIA chip, or any Intel chip since i810. Rip out all the logic for handling 24bpp pixmaps and framebuffers, and silently

[PATCH xserver 1/3] ephyr: Don't clobber bitsPerPixel when using glamor

This ends up passing 0 as the bpp argument to fb screen setup, which is not really the best plan. Signed-off-by: Adam Jackson --- hw/kdrive/ephyr/hostx.c | 1 - 1 file changed, 1 deletion(-) diff --git a/hw/kdrive/ephyr/hostx.c b/hw/kdrive/ephyr/hostx.c index a9ea372..d5578de

[PATCH xserver 0/3] Death to 24bpp, v3

New in this round: 1/ fixes a bizzare bit of Xephyr glamor that would zero bitsPerPixel for the screen. That, combined with the if (Ones(bpp) != 1) in fbScreenInit, meant glamor would crash on init. 3/ also removes the now-dead pRotatedPixmap from the GC, and squashes in the glamor/exa changes

[PATCH xserver] glamor: avoid a crash if texture allocation failed

Texture creation in _glamor_create_tex() can fail if a GL_OUT_OF_MEMORY is raised, in which case the texture returned is zero. But the texture value is not checked in glamor_create_fbo() and glamor will abort in glamor_pixmap_ensure_fb() because the fbo->tex is 0: Truncated backtrace: Thread

Re: [PATCH xserver] configure.ac: fix checking for libdrm version after 9232835bd

Hi Mariusz, Thanks. Your patch works for both libdrm >= 2.4.74 and < 2.4.74. But my PKG_CHECK_MODULES always define the macro. I still don't know the reason, but your patch is: Review-and-tested-by: Qiang Yu Regards, Qiang From: Mariusz

Re: [PATCH xim] modules/im/ximcp: Send display and screen number to XIM server

ping On 03/14/17 13:39, Takao Fujiwara-san wrote: Hi, Would you integrate the patch? Fujiwara On 02/18/17 12:22, Takao Fujiwara-san wrote: Enables that client application sends its screen number to XIM server. In ZaphodHeads environment, XIM server needs to know the screen number to launch