RE: Who can explain the diff between Xserver-1.6.4 version and 1.7 version about the ExaGetPixmapAddress?
Hi, Maarten, After I debug the GeodeAllocOffscreen() operation (it is an internal function), I found it have been replaced exaOffscreenAlloc() with GeodeAllocOffscreen(). About the change, you can see: http://cgit.freedesktop.org/xorg/driver/xf86-video-geode/commit/?id=d681a844e448712a9a419d2a4dca81930d39a80a A wholesale update to Randr 1.2 for LX accompanied by massive cleanup since 08/07/2008, include exaOffscreenAlloc(), because no longer to maintain the gx_video. So you can find the exaOffscreenAlloc on Geode-gx. And now, only need to maintain Geode-LX, I believe the GeodeAllocOffscreen() have been update to a strong effort. It have been allocated the Geode-LX memory, include Compression buffer, TryHWCursor, exaBfSz, EXA offscreen space, a shadow buffer, a video overlay. (you can see in lx_memory.c - LXInitOffscreen). My issue is RandR-unable to rotate. (I have been described the phenomenon in: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-geode/+bug/377929/comments/12 ). I have been debug the memory allocation method in LXInitOffscreen. After allocate the EXA offscreen space (http://cgit.freedesktop.org/xorg/driver/xf86-video-geode/tree/src/lx_memory.c#n261 ) The crtc shadow frame buffer (Rotate_memory) allocate: size -= pScrni-virtualX * (pScrni-virtualY * (pScrni-bitsPerPixel 3)); about 2MB size The video overlay size is 2MB size. Then the memorySize = offscreenBase + EXA offscreen Space size Steps: 1). In exaOffscreenInit (Xserver: exa_offscreen.c: 677), the offscreenAreas struct will be allocated. When do rotate action. 2). The client program will call the xf86CrtcRotate (In xf86Rotate.c), then it will allocate the Rotate_memory in shadow frame buffer (less than 2MB). 3). Xf86RotatePrepare - lx_crtc_shadow_create - GetScratchPixmapHeader - exaModifyPixmapHeader_classic, the rotate_memory_base will be loaded into pPixData, the value is equal to memorySize+memoryBase, So pPixData - pExaScr-info-memoryBase = pExaScr-info-memorySize, but now in Xserver, it only have . The judge is not come into existence. The fb_ptr address value is 0x0. I think the GeodeAllocOffscreen() memory allocate action is right. Please take a look, I have not find another reason. So I suggest to add =. Looking forward to your reply. Thanks, Hunk Cui -Original Message- From: Maarten Maathuis [mailto:madman2...@gmail.com] Sent: Thursday, June 10, 2010 12:42 AM To: Cui, Hunk Cc: xorg-devel@lists.x.org; Huang, FrankR; Writer, Tim; Torres, Rigo Subject: Re: Who can explain the diff between Xserver-1.6.4 version and 1.7 version about the ExaGetPixmapAddress? On Wed, Jun 9, 2010 at 1:00 PM, Cui, Hunk hunk@amd.com wrote: Hi, Maarten, Thank you very much for your help, I am looking forward to your reply. :) GeodeAllocOffscreen() is an internal function, exa doesn't know this memory. The idea is to remove this from src/lx_memory.c:253 /* Deduct the probable size of a shadow buffer */ size -= pScrni-virtualX * (pScrni-virtualY * (pScrni-bitsPerPixel 3)); This will then be added to the exa pool, you can use exaOffscreenAlloc. See http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/tree/src/radeon_legacy_memory.c#n50 for appropriate arguments and usage. The offset is relative to memory base. The same is true for the video overlay, gx_video seems to be using exaOffscreenAlloc already. Thanks, Hunk Cui -Original Message- From: Maarten Maathuis [mailto:madman2...@gmail.com] Sent: Wednesday, June 09, 2010 6:57 PM To: Cui, Hunk Cc: xorg-devel@lists.x.org; Huang, FrankR; Writer, Tim; Torres, Rigo Subject: Re: Who can explain the diff between Xserver-1.6.4 version and 1.7 version about the ExaGetPixmapAddress? On Wed, Jun 9, 2010 at 12:37 PM, Cui, Hunk hunk@amd.com wrote: Hi, Maarten, About the crtc-rotatedData (AMD Geode LX driver) in http://cgit.freedesktop.org/xorg/driver/xf86-video-geode/tree/src/lx_display.c#n386 then the rotate_mem offset and shadow_allocate address will be return to xf86CrtcSetModeTransform, after run to xf86RotatePrepare, it will call lx_crtc_shadow_create - GetScratchPixmapHeader - exaModifyPixmapHeader_classic to write the pPixData. The pPixData will be allocated to the sys_ptr and fb_ptr(if the judge come into existence). I am looking at your driver, and it's all a bit confusing. This will have to wait until (at least) this evening. Thanks Hunk Cui -Original Message- From: Maarten Maathuis [mailto:madman2...@gmail.com] Sent: Wednesday, June 09, 2010 6:16 PM To: Cui, Hunk Cc: xorg-devel@lists.x.org; Huang, FrankR; Writer, Tim; Torres, Rigo Subject: Re: Who can explain the diff between Xserver-1.6.4 version and 1.7 version about the ExaGetPixmapAddress? On Wed, Jun 9, 2010 at 11:59 AM, Cui,
RE: Rendering in geode
Morton, Seems that I have found the root cause of that. According to my debug, there are two places in error of geode driver. I have one question to ask you for one bug: You know when the driver does the composite, it is called in exaTryDriverComposite() function. You guess what? It give a driver a composite call that the source's width is less than srcX. That is impossible from my point. Make is more simple: A XRenderComposite() call below: XRenderComposite(dpy, PictOpOver, picture_10x10[0].pict, 0, win-pict, 11, 0, 0, 0, 50, 50, 40, 40) The source is a 10x10 pixmap, but the srcX is 11. The rendering result is none! I think the driver should refuse that parameter to do the rendering. It will bring chaos operation. That is my thought. Thanks, Frank -Original Message- From: Huang, FrankR Sent: 2010?6?12? 17:51 To: 'jonathan.mor...@movial.com' Cc: 'xorg-devel@lists.x.org'; 'xorg-driver-ge...@lists.x.org' Subject: Rendering in geode Resend it. Forget the subject. -Original Message- From: Huang, FrankR Sent: 2010?6?12? 17:43 To: 'jonathan.mor...@movial.com' Cc: 'xorg-devel@lists.x.org'; xorg-driver-ge...@lists.x.org Subject: Morton, After I fix the PictOpOver operation, the geode still has another rendering issue. That is also serious. I attached a picture, please take a look. I have not find the root cause. I use this simple gtk program to reproduce. When I move the mouse on the button, some green add-on region is appearing. You can see the green part on scissor button. I trace the code and found that when I move the mouse on the button, the driver will do two rendering operation(lx_do_composite). The format of these two operations are: 1)pSrc : PICT_a8r8g8b8 pMsk: 0 pDst: PICT_r5g6b5 2)pSrc : PICT_a8r8g8b8 pMsk: PICT_a8pDst: PICT_r5g6b5 When I note the 1) condition handle in geode driver code, everything is ok. No add-on region is appeared again. But I am sure our driver can handle the 1) condition correctly, I use rendercheck to test that case. At the same time, when I move the mouse on the button, other rendering is done by Xserver because our driver can not handle all the rendering condition. That is due to our limited rendering function. I am not sure if it is caused by this mixed rendering result( our driver and pixman rendering together). Thanks, Frank ___ 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: Who can explain the diff between Xserver-1.6.4 version and 1.7 version about the ExaGetPixmapAddress?
2010/6/13 Cui, Hunk hunk@amd.com: Hi, Maarten, In our xf86-video-geode driver, all of memories are allocated by GeodeAllocOffscreen, the exa offscreen memory is part of the memorySize. And the rotation data is not in memorySize, it is allocated after memorySize. This is exactly the reason why exa doesn't recognize it. Rotateddata has to be allocated between memoryBase and memorySize. Only exaAllocOffscreen can do that. About the GeodeAllocOffscreen, it is Data structure tables, why you said allocate exa offscreen memory out of a private pool? What the diff between GeodeAllocOffscreen and exaOffscreen? In exaOffscreenInit, the EXA offscreen base and size are loaded into server, so the exa should recognize it as offscreen memory, furthermore, the ratate_memory(2MB) is not included in EXA offscreen space. That pPixData - pExaScr-info-memoryBase = pExaScr-info-memorySize should right. Just because it's right for your driver doesn't mean it's right everywhere (the memory after memorySize could belong to another device for example). Classic exa is made on the assumption that all memory usable for gpu acceleration is a linear range between memoryBase and memorySize. If you don't want this limitation then you should move to another type of exa where the driver has more control. I just don't see why you cannot use exaAllocOffscreen for rotatedData, that's what every driver has done and it works last i tried. What you have proposed so far is just a hack that will never be added. If you confuse in this explain, I can provide a chart about the memory allocate. Thanks, Hunk Cui -Original Message- From: Maarten Maathuis [mailto:madman2...@gmail.com] Sent: Sunday, June 13, 2010 6:08 PM To: Cui, Hunk Cc: xorg-devel@lists.x.org; xorg-driver-ge...@lists.x.org; Michel Dänzer Subject: Re: Who can explain the diff between Xserver-1.6.4 version and 1.7 version about the ExaGetPixmapAddress? On Sun, Jun 13, 2010 at 10:18 AM, Cui, Hunk hunk@amd.com wrote: Hi, Maarten, After I debug the GeodeAllocOffscreen() operation (it is an internal function), I found it have been replaced exaOffscreenAlloc() with GeodeAllocOffscreen(). About the change, you can see: http://cgit.freedesktop.org/xorg/driver/xf86-video-geode/commit/?id=d681a844e448712a9a419d2a4dca81930d39a80a A wholesale update to Randr 1.2 for LX accompanied by massive cleanup since 08/07/2008, include exaOffscreenAlloc(), because no longer to maintain the gx_video. So you can find the exaOffscreenAlloc on Geode-gx. And now, only need to maintain Geode-LX, I believe the GeodeAllocOffscreen() have been update to a strong effort. It have been allocated the Geode-LX memory, include Compression buffer, TryHWCursor, exaBfSz, EXA offscreen space, a shadow buffer, a video overlay. (you can see in lx_memory.c - LXInitOffscreen). My issue is RandR-unable to rotate. (I have been described the phenomenon in: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-geode/+bug/377929/comments/12 ). I have been debug the memory allocation method in LXInitOffscreen. After allocate the EXA offscreen space (http://cgit.freedesktop.org/xorg/driver/xf86-video-geode/tree/src/lx_memory.c#n261 ) The crtc shadow frame buffer (Rotate_memory) allocate: size -= pScrni-virtualX * (pScrni-virtualY * (pScrni-bitsPerPixel 3)); about 2MB size The video overlay size is 2MB size. Then the memorySize = offscreenBase + EXA offscreen Space size Steps: 1). In exaOffscreenInit (Xserver: exa_offscreen.c: 677), the offscreenAreas struct will be allocated. When do rotate action. 2). The client program will call the xf86CrtcRotate (In xf86Rotate.c), then it will allocate the Rotate_memory in shadow frame buffer (less than 2MB). 3). Xf86RotatePrepare - lx_crtc_shadow_create - GetScratchPixmapHeader - exaModifyPixmapHeader_classic, the rotate_memory_base will be loaded into pPixData, the value is equal to memorySize+memoryBase, So pPixData - pExaScr-info-memoryBase = pExaScr-info-memorySize, but now in Xserver, it only have . The judge is not come into existence. The fb_ptr address value is 0x0. You allocate exa offscreen memory out of a private pool with GeodeAllocOffscreen, only that memory is considered usable for acceleration by exa. Your proposed change to = is taping over the real issue. GeodeAllocOffscreen seems to give you memory directly after exa's offscreen memory, but that doesn't mean exa should recognize it as offscreen memory. Your change would hack exa to accept one extra byte as valid, but shouldn't your whole 2 MB region be inside? If the whole 2 MB was inside or = wouldn't even matter. I've cc'ed someone else who also knows a lot about exa, but i still stand by my judgement that you need to use exaOffscreenAlloc for the rotation data,
[PATCH 1/5] Implement option -b to set default root fill color.
A color name must be included to specify the background fill color to
use if no root window background pixmap property is set. For
example, -b black sets the fill color to black.
The previous hard-coded fill color (a gray) is used if this option is
not specified.
Signed-off-by: Forest Bond for...@alittletooquiet.net
---
xcompmgr.c | 39 +--
1 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/xcompmgr.c b/xcompmgr.c
index 3a01cce..dc5b225 100644
--- a/xcompmgr.c
+++ b/xcompmgr.c
@@ -120,6 +120,7 @@ static Bool clipChanged;
#if HAS_NAME_WINDOW_PIXMAP
static BoolhasNamePixmap;
#endif
+static XRenderColorfill_color;
static int root_height, root_width;
static ignore *ignore_head, **ignore_tail = ignore_head;
static int xfixes_event, xfixes_error;
@@ -801,11 +802,7 @@ root_tile (Display *dpy)
CPRepeat, pa);
if (fill)
{
- XRenderColorc;
-
- c.red = c.green = c.blue = 0x8080;
- c.alpha = 0x;
- XRenderFillRectangle (dpy, PictOpSrc, picture, c,
+ XRenderFillRectangle (dpy, PictOpSrc, picture, fill_color,
0, 0, 1, 1);
}
return picture;
@@ -1863,6 +1860,7 @@ usage (char *program)
fprintf (stderr,-o opacity\n Specifies the translucency for
client-side shadows. (default .75)\n);
fprintf (stderr,-l left-offset\n Specifies the left offset for
client-side shadows. (default -15)\n);
fprintf (stderr,-t top-offset\n Specifies the top offset for
clinet-side shadows. (default -15)\n);
+fprintf (stderr,-b color\n Specifies the background color to use
if no root pixmap is set. (default is a gray)\n);
fprintf (stderr,-I fade-in-step\n Specifies the opacity change
between steps while fading in. (default 0.028)\n);
fprintf (stderr,-O fade-out-step\n Specifies the opacity change
between steps while fading out. (default 0.03)\n);
fprintf (stderr,-D fade-delta-time\n Specifies the time between
steps in a fade in milliseconds. (default 10)\n);
@@ -1945,8 +1943,9 @@ main (int argc, char **argv)
intcomposite_major, composite_minor;
char *display = NULL;
into;
+char *fill_color_name = NULL;
-while ((o = getopt (argc, argv, D:I:O:d:r:o:l:t:scnfFCaS)) != -1)
+while ((o = getopt (argc, argv, D:I:O:d:r:o:l:t:b:scnfFCaS)) != -1)
{
switch (o) {
case 'd':
@@ -2003,6 +2002,9 @@ main (int argc, char **argv)
case 't':
shadowOffsetY = atoi (optarg);
break;
+ case 'b':
+ fill_color_name = optarg;
+ break;
default:
usage (argv[0]);
break;
@@ -2074,6 +2076,31 @@ main (int argc, char **argv)
presum_gaussian (gaussianMap);
}
+if (fill_color_name)
+{
+ XColor c;
+ if (! XParseColor (dpy, DefaultColormap (dpy, scr),
+ fill_color_name, c))
+ {
+ fprintf (stderr, Could not parse fill color.\n);
+ exit (1);
+ }
+ if (! XAllocColor (dpy, DefaultColormap (dpy, scr), c))
+ {
+ fprintf (stderr, Could not allocate color.\n);
+ exit (1);
+ }
+
+ fill_color.red = c.red;
+ fill_color.green = c.green;
+ fill_color.blue = c.blue;
+}
+else
+{
+ fill_color.red = fill_color.green = fill_color.blue = 0x8080;
+}
+fill_color.alpha = 0x;
+
root_width = DisplayWidth (dpy, scr);
root_height = DisplayHeight (dpy, scr);
--
1.7.0.4
signature.asc
Description: Digital signature
___
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 2/5] DEBUG_PAINT: log windows that will not be repainted.
With DEBUG_PAINT, windows that were being painted were logged, but
nothing was logged for skipped windows. With this patch, the reason
a window is skipped is logged (not damaged, invisible) with the
window id.
Signed-off-by: Forest Bond for...@alittletooquiet.net
---
xcompmgr.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/xcompmgr.c b/xcompmgr.c
index dc5b225..1f6b450 100644
--- a/xcompmgr.c
+++ b/xcompmgr.c
@@ -945,11 +945,21 @@ paint_all (Display *dpy, XserverRegion region)
#endif
/* never painted, ignore it */
if (!w-damaged)
+ {
+#if DEBUG_REPAINT
+ printf ( [not damaged: 0x%x], w-id);
+#endif
continue;
+ }
/* if invisible, ignore it */
if (w-a.x + w-a.width 1 || w-a.y + w-a.height 1
|| w-a.x = root_width || w-a.y = root_height)
+ {
+#if DEBUG_REPAINT
+ printf ( [invisible: 0x%x], w-id);
+#endif
continue;
+ }
if (!w-picture)
{
XRenderPictureAttributespa;
@@ -970,7 +980,7 @@ paint_all (Display *dpy, XserverRegion region)
pa);
}
#if DEBUG_REPAINT
- printf ( 0x%x, w-id);
+ printf ( [painting 0x%x], w-id);
#endif
if (clipChanged)
{
--
1.7.0.4
signature.asc
Description: Digital signature
___
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 3/5] Add logging of window ops enabled via DEBUG_WINDOWS.
Some extra debug logging is implemented, enabled by defining
DEBUG_WINDOWS. Existing window logging (dump_wins) is uncommented and
instead also made conditional on DEBUG_WINDOWS.
Signed-off-by: Forest Bond for...@alittletooquiet.net
---
xcompmgr.c | 39 ---
1 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/xcompmgr.c b/xcompmgr.c
index 1f6b450..bd731f0 100644
--- a/xcompmgr.c
+++ b/xcompmgr.c
@@ -156,6 +156,7 @@ static conv *gaussianMap;
#define TRANS_OPACITY 0.75
+#define DEBUG_WINDOWS 0
#define DEBUG_REPAINT 0
#define DEBUG_EVENTS 0
#define MONITOR_REPAINT 0
@@ -1182,6 +1183,10 @@ map_win (Display *dpy, Window id, unsigned long
sequence, Bool fade)
{
win*w = find_win (dpy, id);
+#if DEBUG_WINDOWS
+printf (map_win: 0x%x\n, w-id);
+#endif
+
if (!w)
return;
@@ -1207,6 +1212,9 @@ map_win (Display *dpy, Window id, unsigned long sequence,
Bool fade)
static void
finish_unmap_win (Display *dpy, win *w)
{
+#if DEBUG_WINDOWS
+printf (finish_unmap_win: 0x%x\n, w-id);
+#endif
w-damaged = 0;
#if CAN_DO_USABLE
w-usable = False;
@@ -1268,6 +1276,11 @@ static void
unmap_win (Display *dpy, Window id, Bool fade)
{
win *w = find_win (dpy, id);
+
+#if DEBUG_WINDOWS
+printf (unmap_win: 0x%x\n, w-id);
+#endif
+
if (!w)
return;
w-a.map_state = IsUnmapped;
@@ -1432,6 +1445,10 @@ add_win (Display *dpy, Window id, Window prev)
win*new = malloc (sizeof (win));
win**p;
+#if DEBUG_WINDOWS
+printf (add_win: 0x%x\n, id);
+#endif
+
if (!new)
return;
if (prev)
@@ -1447,6 +1464,9 @@ add_win (Display *dpy, Window id, Window prev)
if (!XGetWindowAttributes (dpy, id, new-a))
{
free (new);
+#if DEBUG_WINDOWS
+ printf (not adding 0x%x: failed to get attributes\n, new-id);
+#endif
return;
}
new-damaged = 0;
@@ -1494,6 +1514,10 @@ restack_win (Display *dpy, win *w, Window new_above)
{
Window old_above;
+#if DEBUG_WINDOWS
+printf(restack_win: 0x%x\n, w-id);
+#endif
+
if (w-next)
old_above = w-next-id;
else
@@ -1606,6 +1630,10 @@ finish_destroy_win (Display *dpy, Window id, Bool gone)
{
win**prev, *w;
+#if DEBUG_WINDOWS
+printf (finish_destroy_win: 0x%x\n, id);
+#endif
+
for (prev = list; (w = *prev); prev = w-next)
if (w-id == id)
{
@@ -1657,6 +1685,9 @@ static void
destroy_win (Display *dpy, Window id, Bool gone, Bool fade)
{
win *w = find_win (dpy, id);
+#if DEBUG_WINDOWS
+printf (destroy_win: 0x%x\n, w-id);
+#endif
#if HAS_NAME_WINDOW_PIXMAP
if (w w-pixmap fade fadeWindows)
set_fade (dpy, w, w-opacity*1.0/OPAQUE, 0.0, fade_out_step,
destroy_callback, gone, False, True);
@@ -1667,7 +1698,7 @@ destroy_win (Display *dpy, Window id, Bool gone, Bool
fade)
}
}
-/*
+#if DEBUG_WINDOWS
static void
dump_win (win *w)
{
@@ -1685,7 +1716,7 @@ dump_wins (void)
for (w = list; w; w = w-next)
dump_win (w);
}
-*/
+#endif
static void
damage_win (Display *dpy, XDamageNotifyEvent *de)
@@ -2147,7 +2178,9 @@ main (int argc, char **argv)
paint_all (dpy, None);
for (;;)
{
- /* dump_wins (); */
+#if DEBUG_WINDOWS
+ dump_wins ();
+#endif
do {
if (autoRedirect)
XFlush (dpy);
--
1.7.0.4
signature.asc
Description: Digital signature
___
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 4/5] Prevent flicker on root background pixmap change.
Changes to the root background pixmap would previously cause the new
image to flicker into visibility briefy before windows were redrawn
over it. This was apparently caused by calling XClearWindow when the
_XROOTPMAP_ID property on the root window changed.
This patch fixes this by dropping the XClearWindow call and providing
a new function (damage_screen) to force a redraw of the entire screen.
Most programs that change the root window pixmap will call XClearWindow,
anyway, so xcompmgr doing the same is redundant. However, dropping
the call makes it possible to use the _XROOTPMAP_ID property of the root
window to pass new pixmaps to xcompmgr from another process. The other
process can then neglect to call XClearWindow, resulting in a
flicker-free change to the new background image.
Signed-off-by: Forest Bond for...@alittletooquiet.net
---
xcompmgr.c | 27 +++
1 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/xcompmgr.c b/xcompmgr.c
index bd731f0..a345bbe 100644
--- a/xcompmgr.c
+++ b/xcompmgr.c
@@ -129,6 +129,7 @@ static int composite_event, composite_error;
static int render_event, render_error;
static Boolsynchronize;
static int composite_opcode;
+static Boolscreen_damaged = False;
/* find these once and be done with it */
static AtomopacityAtom;
@@ -945,7 +946,7 @@ paint_all (Display *dpy, XserverRegion region)
continue;
#endif
/* never painted, ignore it */
- if (!w-damaged)
+ if ((!screen_damaged) (!w-damaged))
{
#if DEBUG_REPAINT
printf ( [not damaged: 0x%x], w-id);
@@ -1128,6 +1129,7 @@ paint_all (Display *dpy, XserverRegion region)
XRenderComposite (dpy, PictOpSrc, rootBuffer, None, rootPicture,
0, 0, 0, 0, 0, 0, root_width, root_height);
}
+screen_damaged = False;
}
static void
@@ -1776,6 +1778,22 @@ damage_win (Display *dpy, XDamageNotifyEvent *de)
repair_win (dpy, w);
}
+static void
+damage_screen (Display *dpy)
+{
+ XserverRegion region;
+ XRectangle r;
+
+ r.x = 0;
+ r.y = 0;
+ r.width = root_width;
+ r.height = root_height;
+
+ region = XFixesCreateRegion (dpy, r, 1);
+ add_damage (dpy, region);
+ screen_damaged = True;
+}
+
static int
error (Display *dpy, XErrorEvent *ev)
{
@@ -2263,9 +2281,9 @@ main (int argc, char **argv)
{
if (rootTile)
{
- XClearArea (dpy, root, 0, 0, 0, 0, True);
XRenderFreePicture (dpy, rootTile);
rootTile = None;
+ damage_screen (dpy);
break;
}
}
@@ -2302,12 +2320,13 @@ main (int argc, char **argv)
} while (QLength (dpy));
if (allDamage !autoRedirect)
{
- static int paint;
paint_all (dpy, allDamage);
- paint++;
XSync (dpy, False);
allDamage = None;
clipChanged = False;
}
}
+
+XClearArea (dpy, root, 0, 0, 0, 0, True);
+XSync (dpy, False);
}
--
1.7.0.4
signature.asc
Description: Digital signature
___
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 5/5] Fix window mapping with re-used window ids.
The X server can re-use window ids once a window has been destroyed.
However, window ids persist in xcompmgr until the window has finished
fading out. As a result, xcompmgr can have multiple win structures
with the same window id.
If a window is destroyed and a new window with the same id is added
and subsequently mapped before the first window fades out, xcompmgr
finds the wrong win structure and tries to map the destroyed window,
failing due to X errors. The new window is never mapped and never
appears.
This patch fixes this problem by adding a destroyed field to the win
structure and only considering non-destroyed windows when matching wins
on window id.
Signed-off-by: Forest Bond for...@alittletooquiet.net
---
xcompmgr.c | 99
1 files changed, 53 insertions(+), 46 deletions(-)
diff --git a/xcompmgr.c b/xcompmgr.c
index a345bbe..c5a7dea 100644
--- a/xcompmgr.c
+++ b/xcompmgr.c
@@ -67,6 +67,7 @@ typedef struct _win {
Bool usable; /* mapped and all damaged at one
point */
XRectangle damage_bounds; /* bounds of damage */
#endif
+intdestroyed;
intmode;
intdamaged;
Damage damage;
@@ -753,7 +754,7 @@ find_win (Display *dpy, Window id)
win*w;
for (w = list; w; w = w-next)
- if (w-id == id)
+ if ((!w-destroyed) (w-id == id))
return w;
return NULL;
}
@@ -1456,7 +1457,7 @@ add_win (Display *dpy, Window id, Window prev)
if (prev)
{
for (p = list; *p; p = (*p)-next)
- if ((*p)-id == prev)
+ if ((!(*p)-destroyed) ((*p)-id == prev))
break;
}
else
@@ -1471,6 +1472,7 @@ add_win (Display *dpy, Window id, Window prev)
#endif
return;
}
+new-destroyed = 0;
new-damaged = 0;
#if CAN_DO_USABLE
new-usable = False;
@@ -1537,7 +1539,7 @@ restack_win (Display *dpy, win *w, Window new_above)
/* rehook */
for (prev = list; *prev; prev = (*prev)-next)
{
- if ((*prev)-id == new_above)
+ if ((!(*prev)-destroyed) ((*prev)-id == new_above))
break;
}
w-next = *prev;
@@ -1628,58 +1630,61 @@ circulate_win (Display *dpy, XCirculateEvent *ce)
}
static void
-finish_destroy_win (Display *dpy, Window id, Bool gone)
+finish_destroy_win (Display *dpy, win *w, Bool gone)
{
-win**prev, *w;
+win *prev;
#if DEBUG_WINDOWS
-printf (finish_destroy_win: 0x%x\n, id);
+printf (finish_destroy_win: 0x%x\n, w-id);
#endif
-for (prev = list; (w = *prev); prev = w-next)
- if (w-id == id)
- {
- if (gone)
- finish_unmap_win (dpy, w);
- *prev = w-next;
- if (w-picture)
- {
- set_ignore (dpy, NextRequest (dpy));
- XRenderFreePicture (dpy, w-picture);
- w-picture = None;
- }
- if (w-alphaPict)
- {
- XRenderFreePicture (dpy, w-alphaPict);
- w-alphaPict = None;
- }
- if (w-shadowPict)
- {
- XRenderFreePicture (dpy, w-shadowPict);
- w-shadowPict = None;
- }
- if (w-shadow)
- {
- XRenderFreePicture (dpy, w-shadow);
- w-shadow = None;
- }
- if (w-damage != None)
- {
- set_ignore (dpy, NextRequest (dpy));
- XDamageDestroy (dpy, w-damage);
- w-damage = None;
- }
- cleanup_fade (dpy, w);
- free (w);
+for (prev = list; prev; prev = prev-next)
+ if (prev-next == w)
break;
- }
+
+if (! prev)
+ /* Couldn't find the window? */
+ return;
+
+if (gone)
+ finish_unmap_win (dpy, w);
+prev-next = w-next;
+if (w-picture)
+{
+ set_ignore (dpy, NextRequest (dpy));
+ XRenderFreePicture (dpy, w-picture);
+ w-picture = None;
+}
+if (w-alphaPict)
+{
+ XRenderFreePicture (dpy, w-alphaPict);
+ w-alphaPict = None;
+}
+if (w-shadowPict)
+{
+ XRenderFreePicture (dpy, w-shadowPict);
+ w-shadowPict = None;
+}
+if (w-shadow)
+{
+ XRenderFreePicture (dpy, w-shadow);
+ w-shadow = None;
+}
+if (w-damage != None)
+{
+ set_ignore (dpy, NextRequest (dpy));
+ XDamageDestroy (dpy, w-damage);
+ w-damage = None;
+}
+cleanup_fade (dpy, w);
+free (w);
}
#if HAS_NAME_WINDOW_PIXMAP
static void
destroy_callback (Display *dpy, win *w, Bool gone)
{
-finish_destroy_win (dpy, w-id, gone);
+finish_destroy_win (dpy, w, gone);
}
#endif
@@ -1690,13 +1695,14 @@ destroy_win (Display *dpy, Window id, Bool gone, Bool
fade)
#if DEBUG_WINDOWS
printf
[PATCH] DRI2/xserver: Don't hang in glXSwapBuffers if drawable moves between crtc's
Hi This patch fixes a hang in glXSwapBuffers if a user moves a drawable from a fast running crtc, e.g., 60 Hz to a slower running crtc, e.g., 50 Hz, when using the new DRI2 sync swap bits. It should fix Bugzilla bug #28383. https://bugs.freedesktop.org/show_bug.cgi?id=28383 I've tested this on a R600 against master. I assume the poster of that bug report will test it as well. He has tested a previous version of the patch. Jesse could you review it? Would be good if this could make it into master and 1.8.2 as well. thanks, -mario ___ 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] DRI2/xserver: Don't hang in glXSwapBuffers if drawable moves between crtc's
Detect if a drawable has been moved from an original crtc to a new crtc
with a lower current vblank count than the original crtc inbetween
glXSwapBuffers() calls. Reinitialize drawable's last_swap_target
before scheduling next swap if such a move has taken place.
last_swap_target defines the baseline for scheduling the next swap.
If a movement between crtc's is not taken into account, the swap may
schedule for a vblank count on the new crtc far in the future, resulting
in a apparent hang of the drawable for a long time.
Fixes Bugzilla bug #28383.
Signed-off-by: Mario Kleiner mario.klei...@tuebingen.mpg.de
---
hw/xfree86/dri2/dri2.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index d33b0d1..1f80022 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -756,6 +756,7 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr pDraw, CARD64
target_msc,
DRI2DrawablePtr pPriv;
DRI2BufferPtr pDestBuffer = NULL, pSrcBuffer = NULL;
int ret, i;
+CARD64 ust, current_msc;
pPriv = DRI2GetDrawable(pDraw);
if (pPriv == NULL) {
@@ -800,12 +801,26 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr pDraw,
CARD64 target_msc,
* need to schedule a swap for the last swap target + the swap interval.
*/
if (target_msc == 0 divisor == 0 remainder == 0) {
+ /* If the current vblank count of the drawable's crtc is lower
+* than the count stored in last_swap_target from a previous swap
+* then reinitialize last_swap_target to the current crtc's msc,
+* otherwise the swap will hang. This will happen if the drawable
+* is moved to a crtc with a lower refresh rate, or a crtc that just
+* got enabled.
+*/
+ if (!(*ds-GetMSC)(pDraw, ust, current_msc))
+ pPriv-last_swap_target = 0;
+
+ if (current_msc pPriv-last_swap_target)
+ pPriv-last_swap_target = current_msc;
+
/*
* Swap target for this swap is last swap target + swap interval since
* we have to account for the current swap count, interval, and the
* number of pending swaps.
*/
*swap_target = pPriv-last_swap_target + pPriv-swap_interval;
+
} else {
/* glXSwapBuffersMscOML could have a 0 target_msc, honor it */
*swap_target = target_msc;
--
1.6.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
[PATCH xserver] config: declare xserver private dependencies in xorg-server.pc
Any module (drivers) depending on xserver also depends on some of the
server private dependencies. Any driver including xf86.h depends on
xext, kbproto, inputproto and randr.
These dependencies are in separate packages, so anything can happen,
removal, wrong version, etc... and the driver fails during compilation.
Having the private dependencies declared will ensure all packages the
server depends on are present and at the correct version.
Currently each module attempts to check for server dependencies with
various degrees of accuracy. With this patch, the driver will only need
to check for its own explicit dependencies.
Signed-off-by: Gaetan Nadon mems...@videotron.ca
---
configure.ac |9 -
xorg-server.pc.in |1 +
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/configure.ac b/configure.ac
index 4ada8f5..cb33637 100644
--- a/configure.ac
+++ b/configure.ac
@@ -793,9 +793,13 @@ WINDOWSWMPROTO=windowswmproto
APPLEWMPROTO=applewmproto = 1.4
dnl Core modules for most extensions, et al.
-REQUIRED_MODULES=[randrproto = 1.2.99.3] [renderproto = 0.11] [fixesproto
= 4.1] [damageproto = 1.1] [xcmiscproto = 1.2.0] [xextproto = 7.0.99.3]
[xproto = 7.0.17] [xtrans = 1.2.2] [bigreqsproto = 1.1.0] fontsproto
[inputproto = 1.9.99.902] [kbproto = 1.0.3]
+SDK_REQUIRED_MODULES=[randrproto = 1.2.99.3] [renderproto = 0.11]
[xextproto = 7.0.99.3] [inputproto = 1.9.99.902] [kbproto = 1.0.3]
+REQUIRED_MODULES=[fixesproto = 4.1] [damageproto = 1.1] [xcmiscproto =
1.2.0] [xproto = 7.0.17] [xtrans = 1.2.2] [bigreqsproto = 1.1.0] fontsproto
$SDK_REQUIRED_MODULES
REQUIRED_LIBS=xfont xau
+# Make SDK_REQUIRED_MODULES available for inclusion in xorg-server.pc
+AC_SUBST(SDK_REQUIRED_MODULES)
+
dnl List of libraries that require a specific version
LIBAPPLEWM=applewm = 1.4
LIBDMX=dmx = 1.0.99.1
@@ -947,6 +951,7 @@ if test x$XV = xyes; then
AC_DEFINE(XV, 1, [Support Xv extension])
AC_DEFINE(XvExtension, 1, [Build Xv extension])
REQUIRED_MODULES=$REQUIRED_MODULES $VIDEOPROTO
+ SDK_REQUIRED_MODULES=$SDK_REQUIRED_MODULES $VIDEOPROTO
else
XVMC=no
fi
@@ -1036,6 +1041,7 @@ case $DRI2,$HAVE_DRI2PROTO in
yes,yes | auto,yes)
AC_DEFINE(DRI2, 1, [Build DRI2 extension])
DRI2=yes
+ SDK_REQUIRED_MODULES=$SDK_REQUIRED_MODULES $DRI2PROTO
;;
esac
AM_CONDITIONAL(DRI2, test x$DRI2 = xyes)
@@ -1074,6 +1080,7 @@ if test x$XINERAMA = xyes; then
AC_DEFINE(XINERAMA, 1, [Support Xinerama extension])
AC_DEFINE(PANORAMIX, 1, [Internal define for Xinerama])
REQUIRED_MODULES=$REQUIRED_MODULES $XINERAMAPROTO
+ SDK_REQUIRED_MODULES=$SDK_REQUIRED_MODULES $XINERAMAPROTO
fi
AM_CONDITIONAL(XACE, [test x$XACE = xyes])
diff --git a/xorg-server.pc.in b/xorg-server.pc.in
index 44f886a..1fa4fb5 100644
--- a/xorg-server.pc.in
+++ b/xorg-server.pc.in
@@ -16,5 +16,6 @@ Name: xorg-server
Description: Modular X.Org X Server
Version: @PACKAGE_VERSION@
Requires: pixman-1 pciaccess xproto = 7.0.17
+Requires.private: @SDK_REQUIRED_MODULES@
Cflags: -I${sdkdir} @symbol_visibility@
Libs: -L${libdir}
--
1.6.0.4
Version 2 which needed to be rebased.
Requires.private:
randrproto = 1.2.99.3
renderproto = 0.11
xextproto = 7.0.99.3
inputproto = 1.9.99.902
kbproto = 1.0.3
videoproto optional
dri2proto = 2.3optional
xineramaproto optional
___
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
libX11 or xproto seem to disable some macros defined by mips toolchain
Hello, I have a issue when I build libX11 with a mips toolchain. The macro __WORDSIZE seems to be disabled by libX11 or xproto. Here is the build ouput: make[3]: Entering directory `/home/walsimou/embtoolkit.git/build/packages_build-mipsel-linux-mips32/libX11-1.3.4/src' cd util make make[4]: Entering directory `/home/walsimou/embtoolkit.git/build/packages_build-mipsel-linux-mips32/libX11-1.3.4/src/util' CC makekeys-makekeys.o In file included from /home/walsimou/embtoolkit.git/sysroot-mipsel-linux-mips32/usr/include/sys/types.h:31, from /home/walsimou/embtoolkit.git/sysroot-mipsel-linux-mips32/usr/include/X11/Xos.h:42, from makekeys.c:32: /home/walsimou/embtoolkit.git/sysroot-mipsel-linux-mips32/usr/include/bits/types.h:133:3: error: #error In file included from /home/walsimou/embtoolkit.git/sysroot-mipsel-linux-mips32/usr/include/sys/types.h:31, from /home/walsimou/embtoolkit.git/sysroot-mipsel-linux-mips32/usr/include/X11/Xos.h:42, from makekeys.c:32: And Here is part of usr/include/sys/types.h (see attachment for complete file): #if __WORDSIZE == 32 # define __SQUAD_TYPE__quad_t # define __UQUAD_TYPE__u_quad_t # define __SWORD_TYPEint # define __UWORD_TYPEunsigned int # define __SLONG32_TYPElong int # define __ULONG32_TYPEunsigned long int # define __S64_TYPE__quad_t # define __U64_TYPE__u_quad_t /* We want __extension__ before typedef's that use nonstandard base types such as `long long' in C89 mode. */ # define __STD_TYPE__extension__ typedef #elif __WORDSIZE == 64 # define __SQUAD_TYPElong int # define __UQUAD_TYPEunsigned long int # define __SWORD_TYPElong int # define __UWORD_TYPEunsigned long int # define __SLONG32_TYPEint # define __ULONG32_TYPEunsigned int # define __S64_TYPElong int # define __U64_TYPEunsigned long int /* No need to mark the typedef with __extension__. */ # define __STD_TYPEtypedef #else # error = __WORDSIZE is not defined #endif I think this shows that somewhere in xproto or libX11 __WORDSIZE is disabled. A simple test code, which prints __WORDSIZE shows that it is defined by the mips toolchain. Thanks for any help/comment about this issue, AWG /* Copyright (C) 1991,1992,1994,1995,1996,1997,1998,1999,2000,2001,2002 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. The GNU C Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with the GNU C Library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. */ /* * POSIX Standard: 2.6 Primitive System Data Types sys/types.h */ #ifndef _SYS_TYPES_H #define _SYS_TYPES_H 1 #include features.h __BEGIN_DECLS #include bits/types.h #ifdef __USE_BSD # ifndef __u_char_defined typedef __u_char u_char; typedef __u_short u_short; typedef __u_int u_int; typedef __u_long u_long; typedef __quad_t quad_t; typedef __u_quad_t u_quad_t; typedef __fsid_t fsid_t; # define __u_char_defined # endif #endif typedef __loff_t loff_t; #ifndef __ino_t_defined # ifndef __USE_FILE_OFFSET64 typedef __ino_t ino_t; # else typedef __ino64_t ino_t; # endif # define __ino_t_defined #endif #if defined __USE_LARGEFILE64 !defined __ino64_t_defined typedef __ino64_t ino64_t; # define __ino64_t_defined #endif #ifndef __dev_t_defined typedef __dev_t dev_t; # define __dev_t_defined #endif #ifndef __gid_t_defined typedef __gid_t gid_t; # define __gid_t_defined #endif #ifndef __mode_t_defined typedef __mode_t mode_t; # define __mode_t_defined #endif #ifndef __nlink_t_defined typedef __nlink_t nlink_t; # define __nlink_t_defined #endif #ifndef __uid_t_defined typedef __uid_t uid_t; # define __uid_t_defined #endif #ifndef __off_t_defined # ifndef __USE_FILE_OFFSET64 typedef __off_t off_t; # else typedef __off64_t off_t; # endif # define __off_t_defined #endif #if defined __USE_LARGEFILE64 !defined __off64_t_defined typedef __off64_t off64_t; # define __off64_t_defined #endif #ifndef __pid_t_defined typedef __pid_t pid_t; # define __pid_t_defined #endif #if (defined __USE_SVID || defined __USE_XOPEN) !defined __id_t_defined typedef __id_t id_t; # define __id_t_defined #endif #ifndef __ssize_t_defined typedef __ssize_t ssize_t; # define __ssize_t_defined #endif #ifdef __USE_BSD #
Re: libX11 or xproto seem to disable some macros defined by mips toolchain
On 06/13/2010 10:55 PM, Abdoulaye Walsimou GAYE wrote: Hello, I have a issue when I build libX11 with a mips toolchain. The macro __WORDSIZE seems to be disabled by libX11 or xproto. [...] I think this shows that somewhere in xproto or libX11 __WORDSIZE is disabled. A simple test code, which prints __WORDSIZE shows that it is defined by the mips toolchain. Thanks for any help/comment about this issue, AWG Ohhh i used xproto-7.0.17 and libX11-1.3.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: [Xorg-driver-geode] [PATCH 1/7] Prevent the pixmap migration if the geode GP can not do the acceleration.
On P, 2010-06-13 at 18:47 +0800, Huang, FrankR wrote:
From: Frank Huang frankr.hu...@amd.com
Bring all the return FALSE condition forward from lx_prepare_composite
to lx_check_composite. The Xserver will handle this condition. See more
on Freedesktop Bugzilla #27243
Signed-off-by: Frank Huang frankr.hu...@amd.com
---
src/lx_exa.c | 52 +---
1 files changed, 29 insertions(+), 23 deletions(-)
diff --git a/src/lx_exa.c b/src/lx_exa.c
index b267cc0..ab33124 100644
--- a/src/lx_exa.c
+++ b/src/lx_exa.c
@@ -536,12 +536,15 @@ static Bool
lx_check_composite(int op, PicturePtr pSrc, PicturePtr pMsk, PicturePtr pDst)
{
GeodeRec *pGeode = GEODEPTR_FROM_PICTURE(pDst);
+const struct exa_format_t *srcFmt, *dstFmt;
/* Check that the operation is supported */
if (op PictOpAdd)
return FALSE;
+/* We need the off-screen buffer to do the multipass work */
+
Extra whitespace here. Extra line too that I don't agree, but
consistency is good enough argument for now, so we can kill the empty
line later on along with all the others. There's just a lone space in
here as well besides the linebreak.
@@ -583,21 +586,23 @@ lx_check_composite(int op, PicturePtr pSrc, PicturePtr
pMsk, PicturePtr pDst)
return FALSE;
if (pMsk op != PictOpClear) {
+ struct blend_ops_t *opPtr = lx_alpha_ops[op * 2];
+ int direction = (opPtr-channel == CIMGP_CHANNEL_A_SOURCE) ? 0 : 1;
+
+ /* Direction 0 indicates src-dst, 1 indiates dst-src */
+ if (((direction == 0) (pSrc-pDrawable-bitsPerPixel 16)) ||
+ ((direction == 1) (pDst-pDrawable-bitsPerPixel 16))) {
+ ErrorF(Can't do mask blending with less then 16bpp\n);
+ return FALSE;
+ }
snip
- /* Direction 0 indicates src-dst, 1 indiates dst-src */
-
- if (((direction == 0) (pxSrc-drawable.bitsPerPixel 16)) ||
- ((direction == 1) (pxDst-drawable.bitsPerPixel 16))) {
- ErrorF(Can't do mask blending with less then 16bpp\n);
- return FALSE;
- }
-
Are you sure this can be moved so easily? Is there any guarantee that if
the src/dst Picture drawable is 16bpp, that then the src/dst pixmap
drawable will be too? I'm not sure we know that absolutely surely, do
we?
So for now just pointing out that the move isn't trivial here, as the
checks are done on different data structures with this patch. Can you
explain how this is fine, or if not, perhaps it's better to just leave
this part in lx_prepare_composite for now and get the rest moved in a
new smaller patch?
I'm CCing xorg-devel for some EXA expert say on this. Full patch visible
at http://lists.x.org/archives/xorg-driver-geode/2010-June/000678.html
Cheers,
Mart Raudsepp
___
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] Revert Adding experimental pseudocolor overlay stuff to NeoMagic driver.
ajax removed the key parts of that patch two years ago in commit
dc2a372ad7edf34417d7d7042562b601e4f0041c. This patch reverts the rest of
commit 57cea11892e956f4e6f07005e05d121fa48c3059, aside from whitespace
changes.
---
This is the only user of xaaWrapper. Can we just kill it?
src/neo.h|2 --
src/neo_2070.c |2 +-
src/neo_2097.c |2 +-
src/neo_2200.c |2 +-
src/neo_driver.c | 18 +++---
5 files changed, 6 insertions(+), 20 deletions(-)
diff --git a/src/neo.h b/src/neo.h
index 718b8a5..f3f2b4c 100644
--- a/src/neo.h
+++ b/src/neo.h
@@ -48,7 +48,6 @@ CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
#include xaa.h
#include xaalocal.h /* XAA internals as we replace some of XAA */
-#include xaaWrapper.h
#include xf86Cursor.h
#include shadowfb.h
@@ -268,7 +267,6 @@ typedef struct neoRec
int overlay_offset;
int videoKey;
int interlace;
-SyncFunc accelSync;
} NEORec, *NEOPtr;
typedef struct {
diff --git a/src/neo_2070.c b/src/neo_2070.c
index 007a304..b3811d6 100644
--- a/src/neo_2070.c
+++ b/src/neo_2070.c
@@ -159,7 +159,7 @@ Neo2070AccelInit(ScreenPtr pScreen)
return FALSE;
}
-return (xaaSetupWrapper(pScreen, infoPtr, pScrn-depth, nPtr-accelSync));
+return(XAAInit(pScreen, infoPtr));
}
diff --git a/src/neo_2097.c b/src/neo_2097.c
index ed9014c..7d720df 100644
--- a/src/neo_2097.c
+++ b/src/neo_2097.c
@@ -248,7 +248,7 @@ Neo2097AccelInit(ScreenPtr pScreen)
return FALSE;
}
-return (xaaSetupWrapper(pScreen, infoPtr, pScrn-depth, nPtr-accelSync));
+return(XAAInit(pScreen, infoPtr));
}
static void
diff --git a/src/neo_2200.c b/src/neo_2200.c
index 78b3367..4b354e7 100644
--- a/src/neo_2200.c
+++ b/src/neo_2200.c
@@ -253,7 +253,7 @@ Neo2200AccelInit(ScreenPtr pScreen)
return FALSE;
}
-return (xaaSetupWrapper(pScreen, infoPtr, pScrn-depth, nPtr-accelSync));
+return(XAAInit(pScreen, infoPtr));
}
static void
diff --git a/src/neo_driver.c b/src/neo_driver.c
index 9b40943..b12c125 100644
--- a/src/neo_driver.c
+++ b/src/neo_driver.c
@@ -1454,22 +1454,11 @@ NEOScreenInit(int scrnIndex, ScreenPtr pScreen, int
argc, char **argv)
miClearVisualTypes();
/* Setup the visuals we support. */
-#if 0
-if (!miSetVisualTypes(pScrn-depth,
- miGetDefaultVisualMask(pScrn-depth),
- pScrn-rgbBits, pScrn-defaultVisual))
- return FALSE;
-#else
if (!miSetVisualTypes(pScrn-depth,
miGetDefaultVisualMask(pScrn-depth),
pScrn-rgbBits, pScrn-defaultVisual))
return FALSE;
-if (pScrn-depth 8) {
- if (!miSetVisualTypes(8, miGetDefaultVisualMask(8), 6,
- pScrn-defaultVisual))
- return FALSE;
-}
-#endif
+
if (!miSetPixmapDepths ()) return FALSE;
/*
@@ -1505,8 +1494,7 @@ NEOScreenInit(int scrnIndex, ScreenPtr pScreen, int argc,
char **argv)
/* Fixup RGB ordering */
visual = pScreen-visuals + pScreen-numVisuals;
while (--visual = pScreen-visuals) {
- if ((visual-class | DynamicClass) == DirectColor
-visual-nplanes 8) {
+ if ((visual-class | DynamicClass) == DirectColor) {
visual-offsetRed = pScrn-offset.red;
visual-offsetGreen = pScrn-offset.green;
visual-offsetBlue = pScrn-offset.blue;
@@ -2605,7 +2593,7 @@ neoModeInit(ScrnInfoPtr pScrn, DisplayModePtr mode)
*/
NeoStd-Attribute[16] = 0x01;
-switch (pScrn-depth) { /*...@!@*/
+switch (pScrn-depth) {
case 8 :
NeoStd-CRTC[0x13] = pScrn-displayWidth 3;
NeoNew-ExtCRTOffset = pScrn-displayWidth 11;
--
1.7.0
___
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: [Xorg-driver-geode] [PATCH 1/7] Prevent the pixmap migrationif the geode GP can not do the acceleration.
-Original Message-
From: Mart Raudsepp [mailto:l...@gentoo.org]
Sent: 2010?6?14? 6:50
To: Huang, FrankR
Cc: xorg-driver-ge...@lists.x.org; xorg-devel@lists.x.org
Subject: Re: [Xorg-driver-geode] [PATCH 1/7] Prevent the pixmap migrationif the
geode GP can not do the acceleration.
On P, 2010-06-13 at 18:47 +0800, Huang, FrankR wrote:
From: Frank Huang frankr.hu...@amd.com
Bring all the return FALSE condition forward from lx_prepare_composite
to lx_check_composite. The Xserver will handle this condition. See more
on Freedesktop Bugzilla #27243
Signed-off-by: Frank Huang frankr.hu...@amd.com
---
src/lx_exa.c | 52 +---
1 files changed, 29 insertions(+), 23 deletions(-)
diff --git a/src/lx_exa.c b/src/lx_exa.c
index b267cc0..ab33124 100644
--- a/src/lx_exa.c
+++ b/src/lx_exa.c
@@ -536,12 +536,15 @@ static Bool
lx_check_composite(int op, PicturePtr pSrc, PicturePtr pMsk, PicturePtr pDst)
{
GeodeRec *pGeode = GEODEPTR_FROM_PICTURE(pDst);
+const struct exa_format_t *srcFmt, *dstFmt;
/* Check that the operation is supported */
if (op PictOpAdd)
return FALSE;
+/* We need the off-screen buffer to do the multipass work */
+
Extra whitespace here. Extra line too that I don't agree, but
consistency is good enough argument for now, so we can kill the empty
line later on along with all the others. There's just a lone space in
here as well besides the linebreak.
[Frank] whitespace here, yes. delete it and resend?
@@ -583,21 +586,23 @@ lx_check_composite(int op, PicturePtr pSrc, PicturePtr
pMsk, PicturePtr pDst)
return FALSE;
if (pMsk op != PictOpClear) {
+ struct blend_ops_t *opPtr = lx_alpha_ops[op * 2];
+ int direction = (opPtr-channel == CIMGP_CHANNEL_A_SOURCE) ? 0 : 1;
+
+ /* Direction 0 indicates src-dst, 1 indiates dst-src */
+ if (((direction == 0) (pSrc-pDrawable-bitsPerPixel 16)) ||
+ ((direction == 1) (pDst-pDrawable-bitsPerPixel 16))) {
+ ErrorF(Can't do mask blending with less then 16bpp\n);
+ return FALSE;
+ }
snip
- /* Direction 0 indicates src-dst, 1 indiates dst-src */
-
- if (((direction == 0) (pxSrc-drawable.bitsPerPixel 16)) ||
- ((direction == 1) (pxDst-drawable.bitsPerPixel 16))) {
- ErrorF(Can't do mask blending with less then 16bpp\n);
- return FALSE;
- }
-
Are you sure this can be moved so easily? Is there any guarantee that if
the src/dst Picture drawable is 16bpp, that then the src/dst pixmap
drawable will be too? I'm not sure we know that absolutely surely, do
we?
[Frank]Good point. In my opinion, they are the same value.
So for now just pointing out that the move isn't trivial here, as the
checks are done on different data structures with this patch. Can you
explain how this is fine, or if not, perhaps it's better to just leave
this part in lx_prepare_composite for now and get the rest moved in a
new smaller patch?
I'm CCing xorg-devel for some EXA expert say on this. Full patch visible
at http://lists.x.org/archives/xorg-driver-geode/2010-June/000678.html
[Frank]I agree with you by putting this question cc to xorg-devel to let EXA
experts make sure of this. I do think they have the same value. The reason why
I put this judge advanced is that the pixmap migration will be happened again
if keep putting the return FALSE in lx_prepare_composite. So I try to put all
the judge advanced. We can see how the EXA experts give the answer.
Cheers,
Mart Raudsepp
___
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
How to help on multitouch?
Hi all, I've recently become interested in multitouch on linux, and I'd like to get involved. I've read some of the back threads, and I agree with Peter's Direct Input Devices approach. I came to a nearly identical concept when I was thinking about how the iPhone handled multitouch (I've done some iPhone development in the past). So first, where does the DIDs work stand? I would be happy to lend a hand with any coding. I've not done any X work before, the kernel has been my mainstay, but I can get my elbows dirty :). Second, I was thinking about the DIDs approach, but I have some concerns about situations where legacy apps don't listen for them. My thought is that if a legacy app has not registered to listen for DIDs, the X server should do some work on its behalf. The server could create one master pointer for each legacy app and warp it to the location of the first touch in the app. Multiple touches beyond the first inside such an app do nothing. This would allow multitouch DIDs to control legacy apps while avoiding some of the master pointer dynamic allocation issues that required multitouchd to have a pool of pre-allocated pointers for. Lastly, I have concerns about keyboard focus with multitouch. I can't think of a way to have the server manage focus with the help of DIDs due to the fact that multiple apps may be used at the same time. However, even when an app is used it may not need to become focused. For example, if you are just making some motion to scroll a window that is partially behind the focused window, you might not want to focus it. So, I think the best way to handle focus would be to have the application receiving DID events ask for focus if it feels it should gain it. I'd love to hear others' thoughts on these ideas. I'm really new to X development, so I may have some concepts wrong in my head, so please let me know if I've got anything wrong :). Thanks, -- Chase ___ 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
