Adding a return value to set_cursor_position() to allow it to report failure
Since I did not get feedback about whether or not this patch would be of interest I just went ahead and wrote it. Sadly I have missed the merge window for 1.16 (so I had to bump the ABI version again in the patch). I am also thinking that my previous patch to add a return value to load_cursor_argb() makes the UseHWCursor*() call-backs irrelevant and that I should perhaps submit a patch to remove them. And on similar lines, is xf86ForceHWCursor() still useful? The only user seems to be the R128 DRI1 code. Regards, Michael -- ORACLE Deutschland B.V. Co. KG Michael Thayer Werkstrasse 24 VirtualBox engineering 71384 Weinstadt, Germany mailto:michael.tha...@oracle.com Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Geschäftsführer: Jürgen Kunz Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher ___ 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] Add a return value to set_cursor_position() to allow it to report failure
set_cursor_position() may need to be able to fail and have the server fall
back to a software cursor in at least the situation in which we are running
on virtual hardware and using the host cursor as a hardware cursor for the
guest but cannot change its position.
Signed-off-by: Michael Thayer michael.tha...@oracle.com
---
hw/xfree86/common/xf86Module.h | 2 +-
hw/xfree86/modes/xf86Crtc.h| 2 +-
hw/xfree86/modes/xf86Cursors.c | 14 ++
hw/xfree86/ramdac/IBM.c| 6 --
hw/xfree86/ramdac/TI.c | 3 ++-
hw/xfree86/ramdac/xf86Cursor.c | 28
hw/xfree86/ramdac/xf86Cursor.h | 2 +-
hw/xfree86/ramdac/xf86CursorPriv.h | 4 +++-
hw/xfree86/ramdac/xf86HWCurs.c | 4 ++--
9 files changed, 48 insertions(+), 17 deletions(-)
diff --git a/hw/xfree86/common/xf86Module.h b/hw/xfree86/common/xf86Module.h
index 62ac95d..b848f53 100644
--- a/hw/xfree86/common/xf86Module.h
+++ b/hw/xfree86/common/xf86Module.h
@@ -80,7 +80,7 @@ typedef enum {
* mask is 0x.
*/
#define ABI_ANSIC_VERSION SET_ABI_VERSION(0, 4)
-#define ABI_VIDEODRV_VERSION SET_ABI_VERSION(17, 0)
+#define ABI_VIDEODRV_VERSION SET_ABI_VERSION(18, 0)
#define ABI_XINPUT_VERSION SET_ABI_VERSION(21, 0)
#define ABI_EXTENSION_VERSION SET_ABI_VERSION(8, 0)
#define ABI_FONT_VERSION SET_ABI_VERSION(0, 6)
diff --git a/hw/xfree86/modes/xf86Crtc.h b/hw/xfree86/modes/xf86Crtc.h
index 5407deb..6fe0b1b 100644
--- a/hw/xfree86/modes/xf86Crtc.h
+++ b/hw/xfree86/modes/xf86Crtc.h
@@ -168,7 +168,7 @@ typedef struct _xf86CrtcFuncs {
/**
* Set cursor position
*/
-void
+Bool
(*set_cursor_position) (xf86CrtcPtr crtc, int x, int y);
/**
diff --git a/hw/xfree86/modes/xf86Cursors.c b/hw/xfree86/modes/xf86Cursors.c
index 10ef6f6..f8fb941 100644
--- a/hw/xfree86/modes/xf86Cursors.c
+++ b/hw/xfree86/modes/xf86Cursors.c
@@ -355,7 +355,7 @@ xf86CrtcTransformCursorPos(xf86CrtcPtr crtc, int *x, int *y)
*y -= dy;
}
-static void
+static Bool
xf86_crtc_set_cursor_position(xf86CrtcPtr crtc, int x, int y)
{
ScrnInfoPtr scrn = crtc-scrn;
@@ -363,6 +363,7 @@ xf86_crtc_set_cursor_position(xf86CrtcPtr crtc, int x, int
y)
xf86CursorInfoPtr cursor_info = xf86_config-cursor_info;
DisplayModePtr mode = crtc-mode;
Bool in_range;
+Bool ret = FALSE;
/*
* Transform position of cursor on screen
@@ -388,18 +389,21 @@ xf86_crtc_set_cursor_position(xf86CrtcPtr crtc, int x,
int y)
crtc-cursor_in_range = in_range;
if (in_range) {
-crtc-funcs-set_cursor_position(crtc, x, y);
+if (crtc-funcs-set_cursor_position(crtc, x, y))
+ret = TRUE;
xf86_crtc_show_cursor(crtc);
}
else
xf86_crtc_hide_cursor(crtc);
+return ret;
}
-static void
+static Bool
xf86_set_cursor_position(ScrnInfoPtr scrn, int x, int y)
{
xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
int c;
+Bool ret = FALSE;
/* undo what xf86HWCurs did to the coordinates */
x += scrn-frameX0;
@@ -408,8 +412,10 @@ xf86_set_cursor_position(ScrnInfoPtr scrn, int x, int y)
xf86CrtcPtr crtc = xf86_config-crtc[c];
if (crtc-enabled)
-xf86_crtc_set_cursor_position(crtc, x, y);
+if (xf86_crtc_set_cursor_position(crtc, x, y))
+ret = TRUE;
}
+return ret;
}
/*
diff --git a/hw/xfree86/ramdac/IBM.c b/hw/xfree86/ramdac/IBM.c
index 872d3d4..73b3d20 100644
--- a/hw/xfree86/ramdac/IBM.c
+++ b/hw/xfree86/ramdac/IBM.c
@@ -505,7 +505,7 @@ IBMramdac640HideCursor(ScrnInfoPtr pScrn)
(*ramdacPtr-WriteDAC) (pScrn, RGB640_CURSOR_CONTROL, 0x00, 0x08);
}
-static void
+static Bool
IBMramdac526SetCursorPosition(ScrnInfoPtr pScrn, int x, int y)
{
RamDacRecPtr ramdacPtr = RAMDACSCRPTR(pScrn);
@@ -519,9 +519,10 @@ IBMramdac526SetCursorPosition(ScrnInfoPtr pScrn, int x,
int y)
(*ramdacPtr-WriteDAC) (pScrn, IBMRGB_curs_xh, 0x00, (x 8) 0xf);
(*ramdacPtr-WriteDAC) (pScrn, IBMRGB_curs_yl, 0x00, y 0xff);
(*ramdacPtr-WriteDAC) (pScrn, IBMRGB_curs_yh, 0x00, (y 8) 0xf);
+return TRUE;
}
-static void
+static Bool
IBMramdac640SetCursorPosition(ScrnInfoPtr pScrn, int x, int y)
{
RamDacRecPtr ramdacPtr = RAMDACSCRPTR(pScrn);
@@ -535,6 +536,7 @@ IBMramdac640SetCursorPosition(ScrnInfoPtr pScrn, int x, int
y)
(*ramdacPtr-WriteDAC) (pScrn, RGB640_CURS_X_HIGH, 0x00, (x 8) 0xf);
(*ramdacPtr-WriteDAC) (pScrn, RGB640_CURS_Y_LOW, 0x00, y 0xff);
(*ramdacPtr-WriteDAC) (pScrn, RGB640_CURS_Y_HIGH, 0x00, (y 8) 0xf);
+return TRUE;
}
static void
diff --git a/hw/xfree86/ramdac/TI.c b/hw/xfree86/ramdac/TI.c
index 7d4e0d7..05914b7 100644
--- a/hw/xfree86/ramdac/TI.c
+++ b/hw/xfree86/ramdac/TI.c
@@ -606,7 +606,7 @@ TIramdacHideCursor(ScrnInfoPtr pScrn)
(*ramdacPtr-WriteDAC) (pScrn, TIDAC_ind_curs_ctrl, 0, 0x00);
}
-static void
+static Bool
Re: [PATCH xf86-input-mouse] Do not drop the result of protocol detection
No response on this yet. Who would be the right person for looking at
patches to xf86-input-mouse? I do realise that it is no longer as
widely used as it once was...
Regards,
Michael
On 31/03/14 11:21, Michael Thayer wrote:
In MousePickProtocol() with protocol PROT_AUTO we probe for the protocol to
use but drop the result in most cases. This was causing DEVICE_INIT and
DEVICE_ON to fail to be called with the VUID protocol. Git history suggests
that this code was originally meant to cover both PS/2 auto-detection and OS-
specific detection, but that only the first case was implemented at the time.
Now that only the second is needed dropping the result to keep the protocol
as PROT_AUTO is presumably no longer useful and seems to actively breaking
things.
Signed-off-by: Michael Thayer michael.tha...@oracle.com
---
src/mouse.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/src/mouse.c b/src/mouse.c
index 2da2b4d..ff8d799 100644
--- a/src/mouse.c
+++ b/src/mouse.c
@@ -843,11 +843,8 @@ MousePickProtocol(InputInfoPtr pInfo, const char* device,
{
const char *osProt;
if (osInfo-SetupAuto (osProt = osInfo-SetupAuto(pInfo,NULL))) {
-MouseProtocolID id = ProtocolNameToID(osProt);
-if (id == PROT_UNKNOWN || id == PROT_UNSUP) {
-protocolID = id;
-protocol = osProt;
-}
+protocolID = ProtocolNameToID(osProt);
+protocol = osProt;
}
}
--
ORACLE Deutschland B.V. Co. KG Michael Thayer
Werkstrasse 24 VirtualBox engineering
71384 Weinstadt, Germany mailto:michael.tha...@oracle.com
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Geschäftsführer: Jürgen Kunz
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
___
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] linux: Propagate failure up to xf86MapVidMem (#18304)
As opposed to calling FatalError.
Signed-off-by: Adam Jackson a...@redhat.com
---
hw/xfree86/os-support/linux/lnx_video.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/os-support/linux/lnx_video.c
b/hw/xfree86/os-support/linux/lnx_video.c
index 47f5abc..6a7c85f 100644
--- a/hw/xfree86/os-support/linux/lnx_video.c
+++ b/hw/xfree86/os-support/linux/lnx_video.c
@@ -437,8 +437,9 @@ mapVidMem(int ScreenNum, unsigned long Base, unsigned long
Size, int flags)
fd = open(DEV_MEM, (flags VIDMEM_READONLY) ? O_RDONLY : O_RDWR);
#endif
if (fd 0) {
-FatalError(xf86MapVidMem: failed to open DEV_MEM (%s)\n,
+xf86ErrorF(xf86MapVidMem: failed to open DEV_MEM (%s)\n,
strerror(errno));
+return MAP_FAILED;
}
if (flags VIDMEM_READONLY)
@@ -451,8 +452,9 @@ mapVidMem(int ScreenNum, unsigned long Base, unsigned long
Size, int flags)
(off_t) realBase + BUS_BASE);
close(fd);
if (base == MAP_FAILED) {
-FatalError(xf86MapVidMem: Could not mmap framebuffer
+xf86ErrorF(xf86MapVidMem: Could not mmap framebuffer
(0x%08lx,0x%lx) (%s)\n, Base, Size, strerror(errno));
+return MAP_FAILED;
}
DebugF(base: %lx aligned base: %lx\n, base, (char *) base + alignOff);
return (char *) base + alignOff;
--
1.8.5.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
Re: [PATCH] linux: Propagate failure up to xf86MapVidMem (#18304)
why is it bad to exit here ? can the caller fix that issue ?
Am 10.04.2014 16:52, schrieb Adam Jackson:
As opposed to calling FatalError.
Signed-off-by: Adam Jackson a...@redhat.com
---
hw/xfree86/os-support/linux/lnx_video.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/os-support/linux/lnx_video.c
b/hw/xfree86/os-support/linux/lnx_video.c
index 47f5abc..6a7c85f 100644
--- a/hw/xfree86/os-support/linux/lnx_video.c
+++ b/hw/xfree86/os-support/linux/lnx_video.c
@@ -437,8 +437,9 @@ mapVidMem(int ScreenNum, unsigned long Base, unsigned
long Size, int flags)
fd = open(DEV_MEM, (flags VIDMEM_READONLY) ? O_RDONLY : O_RDWR);
#endif
this looks strange, what fd is checked in case open(DEV_MEM,... is never called
?
if (fd 0) {
-FatalError(xf86MapVidMem: failed to open DEV_MEM (%s)\n,
+xf86ErrorF(xf86MapVidMem: failed to open DEV_MEM (%s)\n,
strerror(errno));
+return MAP_FAILED;
}
if (flags VIDMEM_READONLY)
@@ -451,8 +452,9 @@ mapVidMem(int ScreenNum, unsigned long Base, unsigned
long Size, int flags)
(off_t) realBase + BUS_BASE);
close(fd);
if (base == MAP_FAILED) {
-FatalError(xf86MapVidMem: Could not mmap framebuffer
+xf86ErrorF(xf86MapVidMem: Could not mmap framebuffer
(0x%08lx,0x%lx) (%s)\n, Base, Size, strerror(errno));
+return MAP_FAILED;
}
giving users a better error message is always a good idea.
just my 2 cents
re,
wh
DebugF(base: %lx aligned base: %lx\n, base, (char *) base + alignOff);
return (char *) base + alignOff;
___
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
ETEST, EINTR, and interrupted read() system call
Hi, I posted this on one of the other mailing lists but haven't seen any response so maybe this is a better list for it. I am troubleshooting a problem with a Java X client getting disconnected from the X-server (explicit kill or server shutdown message). I've tracked it down in the X-server to the StandardReadRequestFromClient() routine in os/io.c and the call to _XSERVTransRead() (which ultimately calls read()). This routine normally works fine but very occasionally it returns -1 with errno set to EINTR. This causes the server to close down the connection. I normally would expect this condition to call for a retry on the read() since it was interrupted. But, the code does not pay any attention to EINTR. There is a macro, ETEST() which only takes into account EAGAIN and EWOULDBLOCK. For all other cases, if -1 is returned from the read(), it is considered a fatal error and the X-server proceeds to close down the connection. So, my main question has to do with whether or not EINTR is supposed to be taken into account in another fashion? The Xorg server I am using is very old, xorg-6.8.2 from RHEL4. But, I've looked at current sources and they are essentially the same. So, can someone shed any light on why this may be happening? What signal might be interrupting the read()? Why is EINTR not retried? How can I get around this issue? Thanks for your help. Regards, Jason ___ 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] xfixes: Forbid manipulating clip for source-only pictures (#28968)
Just throw BadPicture instead of crashing. It's not currently a
meaningful thing to do anyway, RenderSetPictureRectangles would error if
you tried (which this patch changes to BadPicture as well for
consistency). The problem with trying to do it is if the clip is
specified as a pixmap then we try to convert it to a region, and
-BitmapToRegion requires a ScreenPtr, and source-only pictures don't
have one.
I can imagine a use for client clip on source-only pictures, so if we
really wanted to allow this, probably the way forward is to always store
the clip as a region internally, and when setting the clip _from_ a
pixmap, look up BitmapToRegion relative to the pixmap not the picture.
But since clearly nobody can be relying on it working...
Signed-off-by: Adam Jackson a...@redhat.com
---
render/render.c | 2 +-
xfixes/region.c | 6 ++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/render/render.c b/render/render.c
index 3b7151a..9ac4a98 100644
--- a/render/render.c
+++ b/render/render.c
@@ -638,7 +638,7 @@ ProcRenderSetPictureClipRectangles(ClientPtr client)
REQUEST_AT_LEAST_SIZE(xRenderSetPictureClipRectanglesReq);
VERIFY_PICTURE(pPicture, stuff-picture, client, DixSetAttrAccess);
if (!pPicture-pDrawable)
-return BadDrawable;
+return RenderErrBase + BadPicture;
nr = (client-req_len 2) - sizeof(xRenderSetPictureClipRectanglesReq);
if (nr 4)
diff --git a/xfixes/region.c b/xfixes/region.c
index cc8f1a5..f9de525 100644
--- a/xfixes/region.c
+++ b/xfixes/region.c
@@ -269,6 +269,9 @@ ProcXFixesCreateRegionFromPicture(ClientPtr client)
VERIFY_PICTURE(pPicture, stuff-picture, client, DixGetAttrAccess);
+if (!pPicture-pDrawable)
+return RenderErrBase + BadPicture;
+
switch (pPicture-clientClipType) {
case CT_PIXMAP:
pRegion = BitmapToRegion(pPicture-pDrawable-pScreen,
@@ -750,6 +753,9 @@ ProcXFixesSetPictureClipRegion(ClientPtr client)
VERIFY_PICTURE(pPicture, stuff-picture, client, DixSetAttrAccess);
VERIFY_REGION_OR_NONE(pRegion, stuff-region, client, DixReadAccess);
+if (!pPicture-pDrawable)
+return RenderErrBase + BadPicture;
+
return SetPictureClipRegion(pPicture, stuff-xOrigin, stuff-yOrigin,
pRegion);
}
--
1.8.5.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] xres: Fix size estimation for 8bpp pixmaps (#69057)
Just use floats, it's not like this is a performance path.
Signed-off-by: Adam Jackson a...@redhat.com
---
Xext/xres.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Xext/xres.c b/Xext/xres.c
index b26cbb5..546b942 100644
--- a/Xext/xres.c
+++ b/Xext/xres.c
@@ -353,9 +353,9 @@ static unsigned long
ResGetApproxPixmapBytes(PixmapPtr pix)
{
unsigned long nPixels;
-int bytesPerPixel;
+float bytesPerPixel;
-bytesPerPixel = pix-drawable.bitsPerPixel 3;
+bytesPerPixel = (float)pix-drawable.bitsPerPixel / 8.0;
nPixels = pix-drawable.width * pix-drawable.height;
/* Divide by refcnt as pixmap could be shared between clients,
--
1.8.5.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] shadowfb: Port to miext/damage (#31303, #65547)
Somewhat shocking how much simpler this is, isn't it? We no longer need
to wrap the screen or GC or Picture, because damage does it for us,
which is doubly great since the old shadowfb code didn't wrap _enough_
things (border updates and Render glyphs, at least). The only real
difference now between this and shadow is a) shadow will let you track
arbitrary pixmaps, and b) shadow's update hook runs off the BlockHandler
whereas shadowfb is immediate.
Tested on nouveau.
Signed-off-by: Adam Jackson a...@redhat.com
---
hw/xfree86/shadowfb/shadow.c | 1587 ++
1 file changed, 58 insertions(+), 1529 deletions(-)
diff --git a/hw/xfree86/shadowfb/shadow.c b/hw/xfree86/shadowfb/shadow.c
index 4352939..7412213 100644
--- a/hw/xfree86/shadowfb/shadow.c
+++ b/hw/xfree86/shadowfb/shadow.c
@@ -1,8 +1,8 @@
/*
Copyright (C) 1999. The XFree86 Project Inc.
+ Copyright 2014 Red Hat, Inc.
Written by Mark Vojkovich (mvojk...@ucsd.edu)
-
Pre-fb-write callbacks and RENDER support - Nolan Leake (no...@vmware.com)
*/
@@ -29,107 +29,22 @@
#include picturestr.h
static Bool ShadowCloseScreen(ScreenPtr pScreen);
-static void ShadowCopyWindow(WindowPtr pWin,
- DDXPointRec ptOldOrg, RegionPtr prgn);
-static Bool ShadowCreateGC(GCPtr pGC);
-
-static Bool ShadowEnterVT(ScrnInfoPtr pScrn);
-static void ShadowLeaveVT(ScrnInfoPtr pScrn);
-
-static void ShadowComposite(CARD8 op,
-PicturePtr pSrc,
-PicturePtr pMask,
-PicturePtr pDst,
-INT16 xSrc,
-INT16 ySrc,
-INT16 xMask,
-INT16 yMask,
-INT16 xDst,
-INT16 yDst, CARD16 width, CARD16 height);
+static Bool ShadowCreateScreenResources(ScreenPtr pScreen);
typedef struct {
ScrnInfoPtr pScrn;
RefreshAreaFuncPtr preRefresh;
RefreshAreaFuncPtr postRefresh;
CloseScreenProcPtr CloseScreen;
-CopyWindowProcPtr CopyWindow;
-CreateGCProcPtr CreateGC;
-ModifyPixmapHeaderProcPtr ModifyPixmapHeader;
-CompositeProcPtr Composite;
-Bool (*EnterVT) (ScrnInfoPtr);
-void (*LeaveVT) (ScrnInfoPtr);
-Bool vtSema;
} ShadowScreenRec, *ShadowScreenPtr;
-typedef struct {
-const GCOps *ops;
-const GCFuncs *funcs;
-} ShadowGCRec, *ShadowGCPtr;
-
static DevPrivateKeyRec ShadowScreenKeyRec;
-#define ShadowScreenKey (ShadowScreenKeyRec)
-
-static DevPrivateKeyRec ShadowGCKeyRec;
-
-#define ShadowGCKey (ShadowGCKeyRec)
-
-#define GET_SCREEN_PRIVATE(pScreen) \
-(ShadowScreenPtr)dixLookupPrivate((pScreen)-devPrivates, ShadowScreenKey)
-#define GET_GC_PRIVATE(pGC) \
-(ShadowGCPtr)dixLookupPrivate((pGC)-devPrivates, ShadowGCKey)
-
-#define SHADOW_GC_FUNC_PROLOGUE(pGC)\
-ShadowGCPtr pGCPriv = GET_GC_PRIVATE(pGC);\
-(pGC)-funcs = pGCPriv-funcs;\
-if(pGCPriv-ops)\
-(pGC)-ops = pGCPriv-ops
-
-#define SHADOW_GC_FUNC_EPILOGUE(pGC)\
-pGCPriv-funcs = (pGC)-funcs;\
-(pGC)-funcs = ShadowGCFuncs;\
-if(pGCPriv-ops) {\
-pGCPriv-ops = (pGC)-ops;\
-(pGC)-ops = ShadowGCOps;\
-}
-
-#define SHADOW_GC_OP_PROLOGUE(pGC)\
-ShadowScreenPtr pPriv = GET_SCREEN_PRIVATE(pGC-pScreen); \
-ShadowGCPtr pGCPriv = GET_GC_PRIVATE(pGC);\
-const GCFuncs *oldFuncs = pGC-funcs;\
-pGC-funcs = pGCPriv-funcs;\
-pGC-ops = pGCPriv-ops
-
-#define SHADOW_GC_OP_EPILOGUE(pGC)\
-pGCPriv-ops = pGC-ops;\
-pGC-funcs = oldFuncs;\
-pGC-ops = ShadowGCOps
-
-#define IS_VISIBLE(pWin) (pPriv-vtSema \
-(((WindowPtr)pWin)-visibility != VisibilityFullyObscured))
-
-#define TRIM_BOX(box, pGC) { \
-BoxPtr extents = pGC-pCompositeClip-extents;\
-if(box.x1 extents-x1) box.x1 = extents-x1; \
-if(box.x2 extents-x2) box.x2 = extents-x2; \
-if(box.y1 extents-y1) box.y1 = extents-y1; \
-if(box.y2 extents-y2) box.y2 = extents-y2; \
-}
-
-#define TRANSLATE_BOX(box, pDraw) { \
-box.x1 += pDraw-x; \
-box.x2 += pDraw-x; \
-box.y1 += pDraw-y; \
-box.y2 += pDraw-y; \
-}
-
-#define TRIM_AND_TRANSLATE_BOX(box, pDraw, pGC) { \
-TRANSLATE_BOX(box, pDraw); \
-TRIM_BOX(box, pGC); \
-}
-
-#define BOX_NOT_EMPTY(box) \
-(((box.x2 - box.x1) 0) ((box.y2 - box.y1) 0))
+static ShadowScreenPtr
+shadowfbGetScreenPrivate(ScreenPtr pScreen)
+{
+return dixLookupPrivate((pScreen)-devPrivates, ShadowScreenKeyRec)
+}
Bool
ShadowFBInit2(ScreenPtr pScreen,
@@ -146,14 +61,10 @@ ShadowFBInit2(ScreenPtr pScreen,
if (!dixRegisterPrivateKey(ShadowScreenKeyRec, PRIVATE_SCREEN, 0))
return FALSE;
-if (!dixRegisterPrivateKey
-(ShadowGCKeyRec, PRIVATE_GC, sizeof(ShadowGCRec)))
-return FALSE;
-
if (!(pPriv = (ShadowScreenPtr) malloc(sizeof(ShadowScreenRec
return FALSE;
-dixSetPrivate(pScreen-devPrivates,
Re: [PATCH] xres: Fix size estimation for 8bpp pixmaps (#69057)
On Thu, Apr 10, 2014 at 11:45:37 -0400, Adam Jackson wrote: Just use floats, it's not like this is a performance path. Signed-off-by: Adam Jackson a...@redhat.com --- Xext/xres.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Julien Cristau jcris...@debian.org Cheers, Julien ___ 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 xf86-input-mouse] Make absolute input reporting in Solaris aware of resolution changes
Currently on Solaris absolute input reporting only takes resolution changes
into account when the video driver is using the pre-RandR 1.2 APIs, and
there it uses the physical resolution, not the virtual. This patch fixes
those two things.
Signed-off-by: Michael Thayer michael.tha...@oracle.com
---
src/sun_mouse.c | 42 +-
1 file changed, 33 insertions(+), 9 deletions(-)
diff --git a/src/sun_mouse.c b/src/sun_mouse.c
index ad38ba4..9ffd590 100644
--- a/src/sun_mouse.c
+++ b/src/sun_mouse.c
@@ -57,6 +57,7 @@
#include mouse.h
#include xisb.h
#include mipointer.h
+#include xf86Crtc.h
#include sys/stropts.h
#include sys/vuid_event.h
#include sys/msio.h
@@ -401,14 +402,11 @@ static void vuidMouseSendScreenSize(ScreenPtr pScreen,
VuidMsePtr pVuidMse)
ScrnInfoPtr pScr = XF86SCRNINFO(pScreen);
int result;
-if (!pScr-currentMode)
- return;
-
-if ((pVuidMse-absres.width != pScr-currentMode-HDisplay) ||
- (pVuidMse-absres.height != pScr-currentMode-VDisplay))
+if ((pVuidMse-absres.width != pScr-virtualX) ||
+ (pVuidMse-absres.height != pScr-virtualY))
{
- pVuidMse-absres.width = pScr-currentMode-HDisplay;
- pVuidMse-absres.height = pScr-currentMode-VDisplay;
+ pVuidMse-absres.width = pScr-virtualX;
+ pVuidMse-absres.height = pScr-virtualY;
do {
result = ioctl(pInfo-fd, MSIOSRESOLUTION, (pVuidMse-absres));
@@ -452,6 +450,24 @@ static void vuidMouseAdjustFrame(int index, int x, int y,
int flags)
}
}
}
+
+static void vuidMouseCrtcNotify(ScreenPtr pScreen)
+{
+ xf86_crtc_notify_proc_ptr wrappedCrtcNotify
+ = (xf86_crtc_notify_proc_ptr) vuidMouseGetScreenPrivate(pScreen);
+ VuidMsePtr m;
+ ScreenPtrptrCurScreen;
+
+ if(wrappedCrtcNotify)
+wrappedCrtcNotify(pScreen);
+
+ for (m = vuidMouseList; m != NULL ; m = m-next) {
+ ptrCurScreen = miPointerGetScreen(m-pInfo-dev);
+ if (ptrCurScreen == pScreen) {
+ vuidMouseSendScreenSize(pScreen, m);
+ }
+ }
+}
#endif /* HAVE_ABSOLUTE_MOUSE_SCALING */
@@ -487,8 +503,16 @@ vuidMouseProc(DeviceIntPtr pPointer, int what)
for (i = 0; i screenInfo.numScreens; i++) {
ScreenPtr pScreen = screenInfo.screens[i];
ScrnInfoPtr pScrn = XF86SCRNINFO(pScreen);
- vuidMouseSetScreenPrivate(pScreen, pScrn-AdjustFrame);
- pScrn-AdjustFrame = vuidMouseAdjustFrame;
+ if (xf86CrtcConfigPrivateIndex != -1) {
+ xf86_crtc_notify_proc_ptr pCrtcNotify
+ = xf86_wrap_crtc_notify(pScreen,
+ vuidMouseCrtcNotify);
+ vuidMouseSetScreenPrivate(pScreen, pCrtcNotify);
+ } else {
+ vuidMouseSetScreenPrivate(pScreen,
+ pScrn-AdjustFrame);
+ pScrn-AdjustFrame = vuidMouseAdjustFrame;
+ }
}
vuidMouseGeneration = serverGeneration;
}
--
ORACLE Deutschland B.V. Co. KG Michael Thayer
Werkstrasse 24 VirtualBox engineering
71384 Weinstadt, Germany mailto:michael.tha...@oracle.com
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Geschäftsführer: Jürgen Kunz
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
___
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-input-mouse] Do not drop the result of protocol detection
On 04/10/14 07:20 AM, Michael Thayer wrote: No response on this yet. Who would be the right person for looking at patches to xf86-input-mouse? I do realise that it is no longer as widely used as it once was... Occasionally the BSD folks will pipe in, but mostly it's been Peter Hutterer and myself, and we've both been rather busy lately. I'll try to catch up soon if Peter doesn't beat me to it. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ 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
