[PATCH] dix: fix scale_to_desktop for edge ABS events
Scale_to_desktop() converts ABS events from device coordinates
to screen coordinates:
[dev_X_min, dev_X_max] - [screen_X_min, screen_X_max]
[dev_Y_min, dev_Y_max] - [screen_Y_min, screen_Y_max]
An edge ABS event with X = dev_X_max (e.g., generated from the
edge of a touchscreen) will be converted to have screen X value
= screen_X_max, which, however, will be filterd out when xserver
tries to find proper Window to receive the event, because the
range check for a Window to receive events is
window_X_min = event_screen_X window_X_max
Events with event_screen_X = screen_X_max will fail the test get
and rejected by the Window.
To fix this, we change the device to screen coordinates mapping to
[dev_X_min, dev_X_max] - [screen_X_min, screen_X_max-1]
[dev_Y_min, dev_Y_max] - [screen_Y_min, screen_Y_max-1]
Reviewed-by: Chase Douglas chase.doug...@canonical.com
Reviewed-by: Jeremy Huddleston Sequoia jerem...@apple.com
Signed-off-by: Yufeng Shen mile...@chromium.org
---
dix/getevents.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/dix/getevents.c b/dix/getevents.c
index fade40c..f46b018 100644
--- a/dix/getevents.c
+++ b/dix/getevents.c
@@ -346,14 +346,14 @@ updateSlaveDeviceCoords(DeviceIntPtr master, DeviceIntPtr
pDev)
NULL,
pDev-valuator-axes + 0,
screenInfo.x,
- screenInfo.width);
+ screenInfo.x +
screenInfo.width);
}
if (pDev-valuator-numAxes 1) {
pDev-last.valuators[1] = rescaleValuatorAxis(pDev-last.valuators[1],
NULL,
pDev-valuator-axes + 1,
screenInfo.y,
- screenInfo.height);
+ screenInfo.y +
screenInfo.height);
}
/* calculate the other axis as well based on info from the old
@@ -890,9 +890,11 @@ scale_to_desktop(DeviceIntPtr dev, ValuatorMask *mask,
/* scale xy to desktop coordinates */
*screenx = rescaleValuatorAxis(x, dev-valuator-axes + 0, NULL,
- screenInfo.x, screenInfo.width);
+ screenInfo.x,
+ screenInfo.x + screenInfo.width - 1);
*screeny = rescaleValuatorAxis(y, dev-valuator-axes + 1, NULL,
- screenInfo.y, screenInfo.height);
+ screenInfo.y,
+ screenInfo.y + screenInfo.height - 1);
*devx = x;
*devy = y;
@@ -946,11 +948,13 @@ positionSprite(DeviceIntPtr dev, int mode, ValuatorMask
*mask,
*/
if (tmpx != *screenx)
*devx = rescaleValuatorAxis(*screenx, NULL, dev-valuator-axes + 0,
-screenInfo.x, screenInfo.width);
+screenInfo.x,
+screenInfo.x + screenInfo.width);
if (tmpy != *screeny)
*devy = rescaleValuatorAxis(*screeny, NULL, dev-valuator-axes + 1,
-screenInfo.y, screenInfo.height);
+screenInfo.y,
+screenInfo.y + screenInfo.height);
/* Recalculate the per-screen device coordinates */
if (valuator_mask_isset(mask, 0)) {
--
1.7.7.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH vmmouse] Log in VMMouseReadInput() in a signal-safe manner
This fixes the following message from Xorg.0.log: (EE) BUG: triggered 'if (inSignalContext)' (EE) BUG: ../../os/log.c:484 in LogVMessageVerb() (EE) Warning: attempting to log data in a signal unsafe manner while in signal context. Please update to check inSignalContext and/or use LogMessageVerbSigSafe() or ErrorFSigSafe(). The offending log format message is: VMWARE(0): vmmouse enable absolute mode I haven't seen that complaint about other log messages, but it's possible other calls to xf86Msg in this code should also be changed. Signed-off-by: Geoffrey Thomas geo...@ldpreload.com --- src/vmmouse.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/vmmouse.c b/src/vmmouse.c index 590144f..569776f 100644 --- a/src/vmmouse.c +++ b/src/vmmouse.c @@ -1063,7 +1063,7 @@ VMMouseReadInput(InputInfoPtr pInfo) */ VMMouseClient_RequestAbsolute(); mPriv-absoluteRequested = TRUE; - xf86Msg(X_INFO, VMWARE(0): vmmouse enable absolute mode\n); + LogMessageVerbSigSafe(X_INFO, 1, VMWARE(0): vmmouse enable absolute mode\n); } /* -- 1.7.10.4 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xf86: return NULL for compat output if no outputs.
On Mon, 10 Sep 2012 11:30:01 +1000, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com With outputless GPUs showing up we crash here if there are not outputs try and recover with a bit of grace. With this fixed, are we then in a position where all modes can be added later upon hotplug detection? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH vmmouse] Log in VMMouseReadInput() in a signal-safe manner
On 09/08/2012 04:31 PM, Geoffrey Thomas wrote: This fixes the following message from Xorg.0.log: (EE) BUG: triggered 'if (inSignalContext)' (EE) BUG: ../../os/log.c:484 in LogVMessageVerb() (EE) Warning: attempting to log data in a signal unsafe manner while in signal context. Please update to check inSignalContext and/or use LogMessageVerbSigSafe() or ErrorFSigSafe(). The offending log format message is: VMWARE(0): vmmouse enable absolute mode I haven't seen that complaint about other log messages, but it's possible other calls to xf86Msg in this code should also be changed. Signed-off-by: Geoffrey Thomas geo...@ldpreload.com --- src/vmmouse.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/vmmouse.c b/src/vmmouse.c index 590144f..569776f 100644 --- a/src/vmmouse.c +++ b/src/vmmouse.c @@ -1063,7 +1063,7 @@ VMMouseReadInput(InputInfoPtr pInfo) */ VMMouseClient_RequestAbsolute(); mPriv-absoluteRequested = TRUE; - xf86Msg(X_INFO, VMWARE(0): vmmouse enable absolute mode\n); + LogMessageVerbSigSafe(X_INFO, 1, VMWARE(0): vmmouse enable absolute mode\n); } /* Looks right :). Reviewed-by: Chase Douglas chase.doug...@ubuntu.com ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2 4/4] dix: Delete mibstore.h
Fine with us, since our driver won't call miInitializeBackingStore on ABIs 8, but I think other drivers need to be fixed before this goes in: mesa/mesa/src/gallium/state_trackers/xorg/xorg_driver.c:855: miInitializeBackingStore(pScreen); driver/xf86-video-tdfx/src/tdfx_driver.c:2376: miInitializeBackingStore(pScreen); driver/xf86-video-sis/src/sis_driver.c:8886: miInitializeBackingStore(pScreen); driver/xf86-video-cirrus/src/lg_driver.c:1376: miInitializeBackingStore(pScreen); driver/xf86-video-cirrus/src/alp_driver.c:1620: miInitializeBackingStore(pScreen); driver/xf86-video-xgixp/src/xgi_driver.c:2045: miInitializeBackingStore(pScreen); driver/xf86-video-fbdev/src/fbdev.c:848: miInitializeBackingStore(pScreen); driver/xf86-video-s3/src/s3_driver.c:825: miInitializeBackingStore(pScreen); driver/xf86-video-apm/src/apm_driver.c:1787: miInitializeBackingStore(pScreen); driver/xf86-video-ati/src/radeon_kms.c:1221: miInitializeBackingStore(pScreen); driver/xf86-video-voodoo/src/voodoo_driver.c:683: miInitializeBackingStore(pScreen); driver/xf86-video-ark/src/ark_driver.c:541: miInitializeBackingStore(pScreen); driver/xf86-video-mach64/src/atiscreen.c:545: miInitializeBackingStore(pScreen); driver/xf86-video-glint/src/glint_driver.c:2907: miInitializeBackingStore(pScreen); driver/xf86-video-chips/src/ct_driver.c:4148: miInitializeBackingStore(pScreen); driver/xf86-video-chips/src/ct_driver.c:4299: miInitializeBackingStore(pScreen); driver/xf86-video-tga/src/tga_driver.c:1454: miInitializeBackingStore(pScreen); driver/xf86-video-dummy/src/dummy_driver.c:620: miInitializeBackingStore(pScreen); driver/xf86-video-i128/src/i128_driver.c:1559: miInitializeBackingStore(pScreen); driver/xf86-video-sisusb/src/sisusb_driver.c:1910: miInitializeBackingStore(pScreen); driver/xf86-video-siliconmotion/src/smi_driver.c:1753: miInitializeBackingStore(pScreen); driver/xf86-video-savage/src/savage_driver.c:3411: miInitializeBackingStore(pScreen); driver/xf86-video-r128/src/r128_driver.c:2699: miInitializeBackingStore(pScreen); driver/xf86-video-vesa/src/vesa.c:1084:miInitializeBackingStore(pScreen); driver/xf86-video-nv/src/g80_driver.c:836:miInitializeBackingStore(pScreen); driver/xf86-video-nv/src/nv_driver.c:2553:miInitializeBackingStore(pScreen); driver/xf86-video-nv/src/riva_driver.c:1171: miInitializeBackingStore(pScreen); driver/xf86-video-s3virge/src/s3v_driver.c:2423: miInitializeBackingStore(pScreen); driver/xf86-video-vmware/src/vmware.c:1486: miInitializeBackingStore(pScreen); driver/xf86-video-vmware/vmwgfx/vmwgfx_driver.c:1039: miInitializeBackingStore(pScreen); driver/xf86-video-ast/src/ast_driver.c:891: miInitializeBackingStore(pScreen); driver/xf86-video-mga/src/mga_driver.c:3411: miInitializeBackingStore(pScreen); driver/xf86-video-newport/src/newport_driver.c:540: miInitializeBackingStore(pScreen); driver/xf86-video-i740/src/i740_driver.c:1561: miInitializeBackingStore(pScreen); driver/xf86-video-sunffb/src/ffb_driver.c:765: miInitializeBackingStore(pScreen); driver/xf86-video-neomagic/src/neo_driver.c:1624: miInitializeBackingStore(pScreen); driver/xf86-video-tseng/src/tseng_driver.c:1456: miInitializeBackingStore(pScreen); driver/xf86-video-rendition/src/rendition.c:1176: miInitializeBackingStore(pScreen); driver/xf86-video-trident/src/trident_driver.c:3040: miInitializeBackingStore(pScreen); driver/xf86-video-intel/src/legacy/i810/i810_driver.c:1678: miInitializeBackingStore(screen); driver/xf86-video-intel/src/sna/sna_driver.c:887: miInitializeBackingStore(screen); driver/xf86-video-intel/src/intel_driver.c:962: miInitializeBackingStore(screen); Some of these are important, so Nacked-by: Aaron Plattner aplatt...@nvidia.com -- Aaron On 09/05/2012 03:38 PM, Daniel Martin wrote: Since Nov 2010 (commit c4c4676) the only purpose of mibstore.h was to define an empty function (miInitializeBackingStore()) for backward compatibility. Time to say goodbye. --- mi/Makefile.am | 3 +-- mi/mibstore.h | 23 --- 2 files changed, 1 insertion(+), 25 deletions(-) delete mode 100644 mi/mibstore.h diff --git a/mi/Makefile.am b/mi/Makefile.am index 96ceeaa..0cef779 100644 --- a/mi/Makefile.am +++ b/mi/Makefile.am @@ -1,7 +1,7 @@ noinst_LTLIBRARIES = libmi.la if XORG -sdk_HEADERS = micmap.h miline.h mipointer.h mi.h mibstore.h \ +sdk_HEADERS = micmap.h miline.h mipointer.h mi.h \ migc.h mipointrst.h mizerarc.h micoord.h mifillarc.h \ mispans.h miwideline.h mistruct.h mifpoly.h mioverlay.h endif @@ -12,7 +12,6 @@ libmi_la_SOURCES = \ mi.h\ miarc.c \ mibitblt.c \ - mibstore.h \ micmap.c\ micmap.h\ micoord.h \ diff --git a/mi/mibstore.h b/mi/mibstore.h deleted file mode 100644
Re: [PATCH v2 0/4] dix: Remove more backing store leftovers
On 09/05/2012 03:38 PM, Daniel Martin wrote: These patches remove some more backing store leftovers. Basicly dead snippets since Nov 2010 (commit: c4c4676). v2: remove mibstore.h instead of adding #warning pragma Daniel Martin (4): dix: Delete mibstore.c dix: Remove #includes of mibstore.h dix: Remove refs to mi backing store from docs Patches 1 through 3, Reviewed-by: Aaron Plattner aplatt...@nvidia.com -- Aaron dix: Delete mibstore.h exa/exa_priv.h | 1 - fb/fb.h | 1 - hw/dmx/doc/dmx.xml | 12 ++-- hw/kdrive/src/kdrive.h | 1 - hw/vfb/InitInput.c | 1 - hw/vfb/InitOutput.c | 1 - hw/xfree86/doc/ddxDesign.xml | 20 hw/xfree86/sdksyms.sh| 1 - hw/xnest/Screen.c| 1 - hw/xnest/Visual.c| 1 - hw/xquartz/darwin.c | 1 - hw/xwin/win.h| 1 - mi/Makefile.am | 3 +-- mi/mibstore.c| 43 --- mi/mibstore.h| 23 --- 15 files changed, 3 insertions(+), 108 deletions(-) delete mode 100644 mi/mibstore.c delete mode 100644 mi/mibstore.h ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH neomagic] Don't call NEO_Sync with no XAA
The commit that makes XAA optional left a use of NEO_Sync while putting
the body inside an #ifdef HAVE_XAA_H block, which caused undefined
symbol errors when loading the driver. NEO_Sync doesn't do anything
without XAA, so don't bother calling it without XAA.
Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=434468
---
src/neo_dga.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/neo_dga.c b/src/neo_dga.c
index b6346c5..8ea31a9 100644
--- a/src/neo_dga.c
+++ b/src/neo_dga.c
@@ -38,10 +38,10 @@
static Bool NEO_OpenFramebuffer(ScrnInfoPtr, char **, unsigned char **,
int *, int *, int *);
static Bool NEO_SetMode(ScrnInfoPtr, DGAModePtr);
-static void NEO_Sync(ScrnInfoPtr);
static int NEO_GetViewport(ScrnInfoPtr);
static void NEO_SetViewport(ScrnInfoPtr, int, int, int);
#ifdef HAVE_XAA_H
+static void NEO_Sync(ScrnInfoPtr);
static void NEO_FillRect(ScrnInfoPtr, int, int, int, int, unsigned long);
static void NEO_BlitRect(ScrnInfoPtr, int, int, int, int, int, int);
#if 0
@@ -57,8 +57,8 @@ DGAFunctionRec NEODGAFuncs = {
NEO_SetMode,
NEO_SetViewport,
NEO_GetViewport,
- NEO_Sync,
#ifdef HAVE_XAA_H
+ NEO_Sync,
NEO_FillRect,
NEO_BlitRect,
#if 0
@@ -219,17 +219,14 @@ NEO_FillRect (
}
}
-
static void
NEO_Sync(
ScrnInfoPtr pScrn
){
NEOPtr pNEO = NEOPTR(pScrn);
-#ifdef HAVE_XAA_H
if(pNEO-AccelInfoRec) {
(*pNEO-AccelInfoRec-Sync)(pScrn);
}
-#endif
}
static void
--
1.7.8.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH neomagic] Don't call NEO_Sync with no XAA
On Mon, Sep 10, 2012 at 12:50 PM, Matt Turner matts...@gmail.com wrote:
The commit that makes XAA optional left a use of NEO_Sync while putting
the body inside an #ifdef HAVE_XAA_H block, which caused undefined
symbol errors when loading the driver. NEO_Sync doesn't do anything
without XAA, so don't bother calling it without XAA.
Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=434468
Reviewed-by: Alex Deucher alexdeuc...@gmail.com
---
src/neo_dga.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/neo_dga.c b/src/neo_dga.c
index b6346c5..8ea31a9 100644
--- a/src/neo_dga.c
+++ b/src/neo_dga.c
@@ -38,10 +38,10 @@
static Bool NEO_OpenFramebuffer(ScrnInfoPtr, char **, unsigned char **,
int *, int *, int *);
static Bool NEO_SetMode(ScrnInfoPtr, DGAModePtr);
-static void NEO_Sync(ScrnInfoPtr);
static int NEO_GetViewport(ScrnInfoPtr);
static void NEO_SetViewport(ScrnInfoPtr, int, int, int);
#ifdef HAVE_XAA_H
+static void NEO_Sync(ScrnInfoPtr);
static void NEO_FillRect(ScrnInfoPtr, int, int, int, int, unsigned long);
static void NEO_BlitRect(ScrnInfoPtr, int, int, int, int, int, int);
#if 0
@@ -57,8 +57,8 @@ DGAFunctionRec NEODGAFuncs = {
NEO_SetMode,
NEO_SetViewport,
NEO_GetViewport,
- NEO_Sync,
#ifdef HAVE_XAA_H
+ NEO_Sync,
NEO_FillRect,
NEO_BlitRect,
#if 0
@@ -219,17 +219,14 @@ NEO_FillRect (
}
}
-
static void
NEO_Sync(
ScrnInfoPtr pScrn
){
NEOPtr pNEO = NEOPTR(pScrn);
-#ifdef HAVE_XAA_H
if(pNEO-AccelInfoRec) {
(*pNEO-AccelInfoRec-Sync)(pScrn);
}
-#endif
}
static void
--
1.7.8.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2 4/4] dix: Delete mibstore.h
On Mon, Sep 10, 2012 at 09:26:18AM -0700, Aaron Plattner wrote: Fine with us, since our driver won't call miInitializeBackingStore on ABIs 8, but I think other drivers need to be fixed before this goes in: ... I'll do so and I would send patches to the respective mailling list of: mesa xf86-video-ati xf86-video-intel and every driver I'll find a distinct list for. For everything else: xf86-video-apm xf86-video-ark xf86-video-ast xf86-video-chips xf86-video-cirrus xf86-video-cyrix xf86-video-dummy xf86-video-fbdev xf86-video-geode xf86-video-glide xf86-video-glint xf86-video-i128 xf86-video-i740 xf86-video-impact xf86-video-imstt xf86-video-mach64 xf86-video-mga xf86-video-modesetting xf86-video-neomagic xf86-video-nested xf86-video-newport xf86-video-nsc xf86-video-nv xf86-video-omap xf86-video-qxl xf86-video-r128 xf86-video-radeonhd xf86-video-rendition xf86-video-s3 xf86-video-s3virge xf86-video-savage xf86-video-siliconmotion xf86-video-sis xf86-video-sisusb xf86-video-sunbw2 xf86-video-suncg14 xf86-video-suncg3 xf86-video-suncg6 xf86-video-sunffb xf86-video-sunleo xf86-video-suntcx xf86-video-tdfx xf86-video-tga xf86-video-trident xf86-video-tseng xf86-video-vermilion xf86-video-vesa xf86-video-vga xf86-video-via xf86-video-vmware xf86-video-voodoo xf86-video-wsfb xf86-video-xgi xf86-video-xgixp I would create some kind of a patch set and send it to this list. Anyone having concerns with this procedure? An advice how to do it better? Cheers, Daniel Martin ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Does Xorg'x XRender implementation support better-than-bilinear interpolation?
Hi,
I just realized that at least on my machine (fedora 17 + intel 20.2),
the only interpolation modes offered by Xrender are: {nearest ,
bilinear , convolution, fast , good, best}
I always thought best translates into something better than bilinear,
but it seems to be just equal to it.
Is there any way to archive bicubic interpolation or any other
higher-than-bilinear interpolation using xrender?
As Java2D offers bicubic interpolation, it would mean a fallback to
software-rendering every time a program requests high-quality
interpolation.
Thank you in advance, Clemens
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Does Xorg'x XRender implementation support better-than-bilinear interpolation?
On Mon, Sep 10, 2012 at 11:05 PM, Clemens Eisserer linuxhi...@gmail.com wrote:
Hi,
I just realized that at least on my machine (fedora 17 + intel 20.2),
the only interpolation modes offered by Xrender are: {nearest ,
bilinear , convolution, fast , good, best}
I always thought best translates into something better than bilinear,
but it seems to be just equal to it.
Is there any way to archive bicubic interpolation or any other
higher-than-bilinear interpolation using xrender?
As Java2D offers bicubic interpolation, it would mean a fallback to
software-rendering every time a program requests high-quality
interpolation.
Thank you in advance, Clemens
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
I don't see it in the renderproto, so it's probably not possible
without a spec extension.
http://cgit.freedesktop.org/xorg/proto/renderproto/tree/render.h
--
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Does Xorg'x XRender implementation support better-than-bilinear interpolation?
On 09/10/2012 06:08 PM, Daniel Stone wrote:
Hi,
On 10 September 2012 23:33, Maarten Maathuismadman2...@gmail.com wrote:
On Mon, Sep 10, 2012 at 11:05 PM, Clemens Eissererlinuxhi...@gmail.com wrote:
I just realized that at least on my machine (fedora 17 + intel 20.2),
the only interpolation modes offered by Xrender are: {nearest ,
bilinear , convolution, fast , good, best}
I always thought best translates into something better than bilinear,
but it seems to be just equal to it.
Is there any way to archive bicubic interpolation or any other
higher-than-bilinear interpolation using xrender?
As Java2D offers bicubic interpolation, it would mean a fallback to
software-rendering every time a program requests high-quality
interpolation.
'Best' might be bicubic. It might be nearest. It might be anything,
it's just whatever the driver thinks will offer the best quality.
Bicubic is not required to be offered, but it may be.
I'm not very familiar with bicubic interpolation, but couldn't it be achieved
using the 'convolution' filter with the adequate kernel? (possibly in several
passes at different scales). AFAIK 'convolution' is always provided and often
accelerated.
Thanks,
- Pierre-Loup
I don't see it in the renderproto, so it's probably not possible
without a spec extension.
http://cgit.freedesktop.org/xorg/proto/renderproto/tree/render.h
The filters are a list of strings; a protocol extension is not
required for a driver to offer (and a client use) more filters than
the predefined ones.
Cheers,
Daniel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
