Re: [PATCH] radv: fix depth transitions with layerCount = VK_REMAINING_ARRAY_LAYERS
Yep, sorry about that and thanks for the review... Please ignore the
other thread on mesa-dev now that this one is in the right place :(
On 01/06/2017 02:05 PM, Jason Ekstrand wrote:
Bah... cc mesa-dev
On Fri, Jan 6, 2017 at 2:04 PM, Jason Ekstrand <ja...@jlekstrand.net
<mailto:ja...@jlekstrand.net>> wrote:
Reviewed-by: Jason Ekstrand <ja...@jlekstrand.net
<mailto:ja...@jlekstrand.net>>
I'll let Dave or Bas push though. :-)
On Fri, Jan 6, 2017 at 12:57 PM, Pierre-Loup A. Griffais
<pgriff...@valvesoftware.com <mailto:pgriff...@valvesoftware.com>>
wrote:
Interpreting layerCount literally would try to create billions
of image
views in radv_process_depth_image_inplace().
Signed-off-by: Pierre-Loup A. Griffais
<pgriff...@valvesoftware.com <mailto:pgriff...@valvesoftware.com>>
---
src/amd/vulkan/radv_meta_decompress.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_meta_decompress.c
b/src/amd/vulkan/radv_meta_decompress.c
index 47ef64d..9f262e6 100644
--- a/src/amd/vulkan/radv_meta_decompress.c
+++ b/src/amd/vulkan/radv_meta_decompress.c
@@ -382,7 +382,7 @@ static void
radv_process_depth_image_inplace(struct radv_cmd_buffer *cmd_buffer,
radv_meta_save_graphics_reset_vport_scissor(_state,
cmd_buffer);
- for (uint32_t layer = 0; layer <
subresourceRange->layerCount; layer++) {
+ for (uint32_t layer = 0; layer <
radv_get_layerCount(image, subresourceRange); layer++) {
struct radv_image_view iview;
radv_image_view_init(, cmd_buffer->device,
--
2.9.3
___
xorg-devel@lists.x.org <mailto:xorg-devel@lists.x.org>: X.Org
development
Archives: http://lists.x.org/archives/xorg-devel
<http://lists.x.org/archives/xorg-devel>
Info: https://lists.x.org/mailman/listinfo/xorg-devel
<https://lists.x.org/mailman/listinfo/xorg-devel>
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] radv: fix depth transitions with layerCount = VK_REMAINING_ARRAY_LAYERS
Interpreting layerCount literally would try to create billions of image
views in radv_process_depth_image_inplace().
Signed-off-by: Pierre-Loup A. Griffais <pgriff...@valvesoftware.com>
---
src/amd/vulkan/radv_meta_decompress.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/amd/vulkan/radv_meta_decompress.c
b/src/amd/vulkan/radv_meta_decompress.c
index 47ef64d..9f262e6 100644
--- a/src/amd/vulkan/radv_meta_decompress.c
+++ b/src/amd/vulkan/radv_meta_decompress.c
@@ -382,7 +382,7 @@ static void radv_process_depth_image_inplace(struct
radv_cmd_buffer *cmd_buffer,
radv_meta_save_graphics_reset_vport_scissor(_state, cmd_buffer);
- for (uint32_t layer = 0; layer < subresourceRange->layerCount; layer++)
{
+ for (uint32_t layer = 0; layer < radv_get_layerCount(image,
subresourceRange); layer++) {
struct radv_image_view iview;
radv_image_view_init(, cmd_buffer->device,
--
2.9.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: How do we want to deal with 4k tiled displays?
I see lots of discussion has happened on that front already; sorry for being late to the party. I'm currently wrestling against a Dell UP3214Q, which seems to exhibit all of the problems you refer to. There are many existing binary games out there that most likely will never get touched again that are RandR clients and try to either maximize themselves to one of the displays or ask the window manager to do it for them, after discovering the monitor topology. Some of these games ship their own libXRandR, some of them statically link against it, some of them inline the protocol code to take bug fixes that weren't widespread in distros at the time they were packaged. It's pretty bad. Given that the only viable solution seems to lie completely on the X server side of things. It seems the X server should be responsible for both making sure the two halves are laid out properly (right now they're in reverse order) and hidden from clients. This database of quirks would ideally live in the server itself where it can be easily leveraged by everyone shipping DDXen. Thanks, - Pierre-Loup On 01/16/2014 11:11 AM, Aaron Plattner wrote: So, monitor manufacturers are starting to make high-resolution displays that consist of one LCD panel that appears to the PC as two. The one I've got is a Dell UP2414Q. It shows up to the PC as two DisplayPort 1.2 multistream devices that have the same GUID but different EDIDs. There's an extension block in the EDID that's supposed to indicate which side is the left tile and which is the right, though I haven't tried to decode it yet. The problem, obviously, is that applications (including some games) treat the two tiles as if they were completely separate monitors. Windows maximize to only half of the screen. My question is, how do we want to deal with these monitors? As far as I see it, we have four options: 1. Hide the presence of the second tile in the X server. Somehow combine the two tiles into a single logical output at the RandR protocol level. The X server would be responsible for setting up the right configuration to drive the logical output using the correct physical resources. 2. Hide the presence of the second tile in libXrandr. This would allow interested applications to query the real state of the hardware while also making it easier to do modesets on a per-monitor level rather than per-output. This could be exposed either as a new simple modeset API in libXrandr or similar, or by modifying the existing interface and having a new interface to punch through the façade and get at the real configuration, for clients that care. 3. Update every application that uses RandR 1.2. Applications can detect the presence of these monitors and deal with them themselves, but this might have poor adoption because programmers are a lazy bunch in general. 4. Do nothing and hope the problem goes away. Hopefully, the situation with current 4k monitors is temporary and we'll start seeing single-tile 4k displays soon, fixing the problem forever. Until we get 8k tiled displays. If the real output devices are still exposed through the protocol, it might make sense to add new properties describing their relative positions to make it easier for clients to lay them out in the right order. This might be useful for power-walls too. The problem with the first two options is that driving these monitors consumes two crtcs. If we present them as a single output to applications, they'll make the assumption that they can just assign a single crtc to that output and use the remaining crtcs for something else. I suspect that deleting crtcs or otherwise marking them as used as a side effect of setting a mode on a different crtc is going to explode a lot of existing applications. ~~ Regardless of what we do about the current crop of 4k monitors, one feature I would like to add is a standardized OutputGroup property. Multiple outputs with the same value of OutputGroup should be considered (both by clients and the server) as a single logical monitor. This would affect the Xinerama information presented by rrxinerama.c, and window managers that use RandR 1.2 directly would be encouraged to consider output groups in their UI behavior. The X server could configure OutputGroups automatically when setting up the initial configuration based on the presence of tiled displays, and clients could reconfigure the groups at runtime to get different behavior if desired. Does this sound like a reasonable extension to RandR? ___ 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 xrandr] xrandr: print primary output
Thanks! On 01/02/2013 01:25 PM, Aaron Plattner wrote: On 12/26/2012 11:49 PM, Pierre-Loup A. Griffais wrote: Ping; anyone feel like merging this? To ssh://git.freedesktop.org/git/xorg/app/xrandr b26fd53..094b40e master - master -- Aaron Thanks, - Pierre-Loup On 12/19/2012 12:35 PM, Pierre-Loup A. Griffais wrote: I could have sworn there was a change to do that in the wild already, but I couldn't find it. Thanks, - Pierre-Loup ___ 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 xrandr] xrandr: print primary output
Ping; anyone feel like merging this? Thanks, - Pierre-Loup On 12/19/2012 12:35 PM, Pierre-Loup A. Griffais wrote: I could have sworn there was a change to do that in the wild already, but I couldn't find it. Thanks, - Pierre-Loup ___ 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 xrandr] xrandr: print primary output
I could have sworn there was a change to do that in the wild already,
but I couldn't find it.
Thanks,
- Pierre-Loup
From 7d0720196cd89ac012fd7d0bf86cee0cffaea631 Mon Sep 17 00:00:00 2001
From: Pierre-Loup A. Griffais pgriff...@nvidia.com
Date: Wed, 19 Dec 2012 12:32:03 -0800
Subject: [PATCH] xrandr: print primary output
Sample output:
LVDS-0 connected primary 1920x1080+1920+120 [...]
Signed-off-by: Pierre-Loup A. Griffais pgriff...@nvidia.com
---
xrandr.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/xrandr.c b/xrandr.c
index 548015c..e8d24fb 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -3249,6 +3249,9 @@ main (int argc, char **argv)
Rotation rotations = output_rotations (output);
printf (%s %s, output_info-name, connection[output_info-connection]);
+ if (output-primary) {
+ printf( primary);
+ }
if (mode)
{
if (crtc_info) {
--
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
[PATCH] xwininfo: report the Visual class of the selected Window
Looks like fallout from the XCB port? Anyhow, appreciated if someone
could push this on my behalf.
Thanks!
- Pierre-Loup
From 12df33eb2424533fa0b9ae8b9ceecdd67fa84ffc Mon Sep 17 00:00:00 2001
From: Pierre-Loup A. Griffais pgriff...@nvidia.com
Date: Tue, 9 Oct 2012 20:33:10 -0700
Subject: [PATCH] xwininfo: report the Visual class of the selected Window
Not of the root window.
Signed-off-by: Pierre-Loup A. Griffais pgriff...@nvidia.com
---
xwininfo.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xwininfo.c b/xwininfo.c
index 70947ee..bb290b7 100644
--- a/xwininfo.c
+++ b/xwininfo.c
@@ -981,7 +981,7 @@ Display_Stats_Info (struct wininfo *w)
visual_iter = xcb_depth_visuals_iterator (depth_iter.data);
for (; visual_iter.rem; xcb_visualtype_next (visual_iter)) {
- if (screen-root_visual == visual_iter.data-visual_id) {
+ if (win_attributes-visual == visual_iter.data-visual_id) {
visual_type = visual_iter.data;
break;
}
--
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: Does Xorg'x XRender implementation support better-than-bilinear interpolation?
On 09/11/2012 10:43 AM, Søren Sandmann wrote: Pierre-Loup A. Griffaispgriff...@nvidia.com writes: 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. The convolution filter in Render only allows one phase of the filter to be used, so the quality of bicubic interpolation implemented that way would be terrible. As an aside, a bunch of code could be deleted if we removed the ability for drivers to provide their own filters. As far as I know, no driver has ever done this. I have an old branch here: One of the items of my (long) list of things to do is to expose anisotropic filtering to RENDER, so it'd be cool if that didn't get removed. Thanks, - Pierre-Loup http://cgit.freedesktop.org/~sandmann/xserver/log/?h=filters that could probably be resurrected. Soren ___ 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
Re: [PATCH] xrandr: move transform limit checking after scaling
Ping? On 03/20/2012 04:54 PM, Pierre-Loup A. Griffais wrote: Wasted a good chunk of time on that one. ___ 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] xrandr: move transform limit checking after scaling
Wasted a good chunk of time on that one.
From f1a65814f119cb83d16e15093e81946f3adcde61 Mon Sep 17 00:00:00 2001
From: Pierre-Loup A. Griffais pgriff...@nvidia.com
Date: Tue, 20 Mar 2012 16:46:22 -0700
Subject: [PATCH] xrandr: move transform limit checking after scaling
This would trigger for legit scaled matrices, resulting in the wrong
extents getting computed.
Signed-off-by: Pierre-Loup A. Griffais pgriff...@nvidia.com
---
xrandr.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/xrandr.c b/xrandr.c
index 35dff3e..622f6a9 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -432,14 +432,15 @@ transform_point (XTransform *transform, double *xp, double *yp)
v = 0;
for (i = 0; i 3; i++)
v += (XFixedToDouble (transform-matrix[j][i]) * vector[i]);
- if (v 32767 || v -32767)
- return False;
result[j] = v;
}
if (!result[2])
return False;
-for (j = 0; j 2; j++)
+for (j = 0; j 2; j++) {
vector[j] = result[j] / result[2];
+if (vector[j] 32767 || vector[j] -32767)
+return False;
+}
*xp = vector[0];
*yp = vector[1];
return True;
--
1.7.4.1
___
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] xfree86: Fix RandR rotation across server generations
From efced7bc4bba912e23a4c76f1057da7a1529dd92 Mon Sep 17 00:00:00 2001 From: Pierre-Loup A. Griffais pgriff...@nvidia.com Date: Fri, 4 Nov 2011 23:26:25 -0700 Subject: [PATCH] xfree86: Fix RandR rotation across server generations 245cb8e94fd1599 fixed xf86RotateDestroy() to actually run its teardown code, causing the Damage object to properly be re-allocated after a server regeneration. However the block that does that still thinks the Rotate layer BlockHandler is wrapped from the last generation, meaning the shadow pixmap is never re-allocated and the Damage object is never re-registered, causing a blank screen, and potentially a driver crash on the next teardown after the server asks it to free a 0x0 Pixmap. Signed-off-by: Pierre-Loup A. Griffais pgriff...@nvidia.com --- hw/xfree86/modes/xf86Crtc.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c index aac33d3..9532151 100644 --- a/hw/xfree86/modes/xf86Crtc.c +++ b/hw/xfree86/modes/xf86Crtc.c @@ -807,6 +807,9 @@ xf86CrtcScreenInit (ScreenPtr screen) config-CloseScreen = screen-CloseScreen; screen-CloseScreen = xf86CrtcCloseScreen; + +/* This might still be marked wrapped from a previous generation */ +config-BlockHandler = NULL; #ifdef XFreeXDGA _xf86_di_dga_init_internal(screen); -- 1.7.4.1 From efced7bc4bba912e23a4c76f1057da7a1529dd92 Mon Sep 17 00:00:00 2001 From: Pierre-Loup A. Griffais pgriff...@nvidia.com Date: Fri, 4 Nov 2011 23:26:25 -0700 Subject: [PATCH] xfree86: Fix RandR rotation across server generations 245cb8e94fd1599 fixed xf86RotateDestroy() to actually run its teardown code, causing the Damage object to properly be re-allocated after a server regeneration. However the block that does that still thinks the Rotate layer BlockHandler is wrapped from the last generation, meaning the shadow pixmap is never re-allocated and the Damage object is never re-registered, causing a blank screen, and potentially a driver crash on the next teardown after the server asks it to free a 0x0 Pixmap. Signed-off-by: Pierre-Loup A. Griffais pgriff...@nvidia.com --- hw/xfree86/modes/xf86Crtc.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c index aac33d3..9532151 100644 --- a/hw/xfree86/modes/xf86Crtc.c +++ b/hw/xfree86/modes/xf86Crtc.c @@ -807,6 +807,9 @@ xf86CrtcScreenInit (ScreenPtr screen) config-CloseScreen = screen-CloseScreen; screen-CloseScreen = xf86CrtcCloseScreen; + +/* This might still be marked wrapped from a previous generation */ +config-BlockHandler = NULL; #ifdef XFreeXDGA _xf86_di_dga_init_internal(screen); -- 1.7.4.1 ___ 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] xfree86: Fix RandR rotation across server generations
BTW, is it by design that RandR rotation sticks around across generations? I was under the impression you were supposed to get the server back in the exact state you originally started with. In any case, I think this is still worthwhile to have in the meantime to fix the corruption and crashes people are getting today, even if the behaviour ends up changing in the future. On 11/04/2011 11:42 PM, Pierre-Loup A. Griffais wrote: From efced7bc4bba912e23a4c76f1057da7a1529dd92 Mon Sep 17 00:00:00 2001 From: Pierre-Loup A. Griffaispgriff...@nvidia.com Date: Fri, 4 Nov 2011 23:26:25 -0700 Subject: [PATCH] xfree86: Fix RandR rotation across server generations 245cb8e94fd1599 fixed xf86RotateDestroy() to actually run its teardown code, causing the Damage object to properly be re-allocated after a server regeneration. However the block that does that still thinks the Rotate layer BlockHandler is wrapped from the last generation, meaning the shadow pixmap is never re-allocated and the Damage object is never re-registered, causing a blank screen, and potentially a driver crash on the next teardown after the server asks it to free a 0x0 Pixmap. Signed-off-by: Pierre-Loup A. Griffaispgriff...@nvidia.com --- hw/xfree86/modes/xf86Crtc.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c index aac33d3..9532151 100644 --- a/hw/xfree86/modes/xf86Crtc.c +++ b/hw/xfree86/modes/xf86Crtc.c @@ -807,6 +807,9 @@ xf86CrtcScreenInit (ScreenPtr screen) config-CloseScreen = screen-CloseScreen; screen-CloseScreen = xf86CrtcCloseScreen; + +/* This might still be marked wrapped from a previous generation */ +config-BlockHandler = NULL; #ifdef XFreeXDGA _xf86_di_dga_init_internal(screen); ___ 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] Revert composite: Don't backfill non-MapWindow allocations
On 07/29/2011 03:26 PM, Ville Syrjälä wrote:
On Thu, Jul 28, 2011 at 01:00:54PM -0700, Pierre-Loup A. Griffais wrote:
Oops, initially got an outdated address for Ville. Properly CCing now; the idea
is that 193ecc8b453b22b3e6 breaks backfilling on resize if db8840600e8e213562 is
also applied.
The problem only affects bg=None windows, right?
I haven't observed corruption for other windows, but I haven't looked for it
either.
Might be nice to get 6dd775f57d2f94f0ddaee324aeec33b9b66ed5bc back to
avoid the copy for bg!=None cases. But I suppose no-one has had the
time/incentive to look at the issue in more detail.
https://bugs.freedesktop.org/34427 seems to imply there was a genuine problem
with it. The logic looks sane to me too, but reverting it sounds like it fixed
issues for a lot of people. As you said I haven't personally experienced or
debugged this particular problem and it would probably need a closer look before
adding it back.
Thanks,
- Pierre-Loup
Thanks,
- Pierre-Loup
On 07/28/2011 12:58 PM, Pierre-Loup A. Griffais wrote:
This reverts commit db8840600e8e21356241eb87395031388d9b54d2.
Conflicts:
composite/compalloc.c
---
composite/compalloc.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/composite/compalloc.c b/composite/compalloc.c
index 5c27631..841b2dc 100644
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -557,7 +557,7 @@ compUnredirectOneSubwindow (WindowPtr pParent, WindowPtr
pWin)
}
static PixmapPtr
-compNewPixmap (WindowPtr pWin, int x, int y, int w, int h, Bool map)
+compNewPixmap (WindowPtr pWin, int x, int y, int w, int h)
{
ScreenPtrpScreen = pWin-drawable.pScreen;
WindowPtrpParent = pWin-parent;
@@ -572,10 +572,6 @@ compNewPixmap (WindowPtr pWin, int x, int y, int w, int h,
Bool map)
pPixmap-screen_x = x;
pPixmap-screen_y = y;
-/* resize allocations will update later in compCopyWindow, not here */
-if (!map)
- return pPixmap;
-
if (pParent-drawable.depth == pWin-drawable.depth)
{
GCPtr pGC = GetScratchGC (pWin-drawable.depth, pScreen);
@@ -641,7 +637,7 @@ compAllocPixmap (WindowPtr pWin)
int y = pWin-drawable.y - bw;
int w = pWin-drawable.width + (bw 1);
int h = pWin-drawable.height + (bw 1);
-PixmapPtr pPixmap = compNewPixmap (pWin, x, y, w, h, TRUE);
+PixmapPtr pPixmap = compNewPixmap (pWin, x, y, w, h);
CompWindowPtr cw = GetCompWindow (pWin);
if (!pPixmap)
@@ -713,7 +709,7 @@ compReallocPixmap (WindowPtr pWin, int draw_x, int draw_y,
pix_h = h + (bw 1);
if (pix_w != pOld-drawable.width || pix_h != pOld-drawable.height)
{
- pNew = compNewPixmap (pWin, pix_x, pix_y, pix_w, pix_h, FALSE);
+ pNew = compNewPixmap (pWin, pix_x, pix_y, pix_w, pix_h);
if (!pNew)
return FALSE;
cw-pOldPixmap = pOld;
___
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] Revert composite: Don't backfill non-MapWindow allocations
This reverts commit db8840600e8e21356241eb87395031388d9b54d2.
Conflicts:
composite/compalloc.c
---
composite/compalloc.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/composite/compalloc.c b/composite/compalloc.c
index 5c27631..841b2dc 100644
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -557,7 +557,7 @@ compUnredirectOneSubwindow (WindowPtr pParent, WindowPtr
pWin)
}
static PixmapPtr
-compNewPixmap (WindowPtr pWin, int x, int y, int w, int h, Bool map)
+compNewPixmap (WindowPtr pWin, int x, int y, int w, int h)
{
ScreenPtr pScreen = pWin-drawable.pScreen;
WindowPtr pParent = pWin-parent;
@@ -572,10 +572,6 @@ compNewPixmap (WindowPtr pWin, int x, int y, int w, int h,
Bool map)
pPixmap-screen_x = x;
pPixmap-screen_y = y;
-/* resize allocations will update later in compCopyWindow, not here */
-if (!map)
- return pPixmap;
-
if (pParent-drawable.depth == pWin-drawable.depth)
{
GCPtr pGC = GetScratchGC (pWin-drawable.depth, pScreen);
@@ -641,7 +637,7 @@ compAllocPixmap (WindowPtr pWin)
inty = pWin-drawable.y - bw;
intw = pWin-drawable.width + (bw 1);
inth = pWin-drawable.height + (bw 1);
-PixmapPtr pPixmap = compNewPixmap (pWin, x, y, w, h, TRUE);
+PixmapPtr pPixmap = compNewPixmap (pWin, x, y, w, h);
CompWindowPtr cw = GetCompWindow (pWin);
if (!pPixmap)
@@ -713,7 +709,7 @@ compReallocPixmap (WindowPtr pWin, int draw_x, int draw_y,
pix_h = h + (bw 1);
if (pix_w != pOld-drawable.width || pix_h != pOld-drawable.height)
{
- pNew = compNewPixmap (pWin, pix_x, pix_y, pix_w, pix_h, FALSE);
+ pNew = compNewPixmap (pWin, pix_x, pix_y, pix_w, pix_h);
if (!pNew)
return FALSE;
cw-pOldPixmap = pOld;
--
1.7.4.1
___
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] Revert composite: Don't backfill non-MapWindow allocations
Oops, initially got an outdated address for Ville. Properly CCing now; the idea
is that 193ecc8b453b22b3e6 breaks backfilling on resize if db8840600e8e213562 is
also applied.
Thanks,
- Pierre-Loup
On 07/28/2011 12:58 PM, Pierre-Loup A. Griffais wrote:
This reverts commit db8840600e8e21356241eb87395031388d9b54d2.
Conflicts:
composite/compalloc.c
---
composite/compalloc.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/composite/compalloc.c b/composite/compalloc.c
index 5c27631..841b2dc 100644
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -557,7 +557,7 @@ compUnredirectOneSubwindow (WindowPtr pParent, WindowPtr
pWin)
}
static PixmapPtr
-compNewPixmap (WindowPtr pWin, int x, int y, int w, int h, Bool map)
+compNewPixmap (WindowPtr pWin, int x, int y, int w, int h)
{
ScreenPtr pScreen = pWin-drawable.pScreen;
WindowPtr pParent = pWin-parent;
@@ -572,10 +572,6 @@ compNewPixmap (WindowPtr pWin, int x, int y, int w, int h,
Bool map)
pPixmap-screen_x = x;
pPixmap-screen_y = y;
-/* resize allocations will update later in compCopyWindow, not here */
-if (!map)
- return pPixmap;
-
if (pParent-drawable.depth == pWin-drawable.depth)
{
GCPtr pGC = GetScratchGC (pWin-drawable.depth, pScreen);
@@ -641,7 +637,7 @@ compAllocPixmap (WindowPtr pWin)
int y = pWin-drawable.y - bw;
int w = pWin-drawable.width + (bw 1);
int h = pWin-drawable.height + (bw 1);
-PixmapPtr pPixmap = compNewPixmap (pWin, x, y, w, h, TRUE);
+PixmapPtr pPixmap = compNewPixmap (pWin, x, y, w, h);
CompWindowPtr cw = GetCompWindow (pWin);
if (!pPixmap)
@@ -713,7 +709,7 @@ compReallocPixmap (WindowPtr pWin, int draw_x, int draw_y,
pix_h = h + (bw 1);
if (pix_w != pOld-drawable.width || pix_h != pOld-drawable.height)
{
- pNew = compNewPixmap (pWin, pix_x, pix_y, pix_w, pix_h, FALSE);
+ pNew = compNewPixmap (pWin, pix_x, pix_y, pix_w, pix_h);
if (!pNew)
return FALSE;
cw-pOldPixmap = pOld;
___
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] Revert composite: Don't backfill non-MapWindow allocations
Yeah, it was somewhat lacking; fixed and added reviewed tag by ajax.
Thanks!
- Pierre-Loup
On 07/28/2011 01:53 PM, Julien Cristau wrote:
On Thu, Jul 28, 2011 at 13:00:54 -0700, Pierre-Loup A. Griffais wrote:
now; the idea is that 193ecc8b453b22b3e6 breaks backfilling on
resize if db8840600e8e213562 is also applied.
I think the above should be in the commit message.
Cheers,
Julien
From da23841bc66cc54e604395ee2c63d7b9c8b22872 Mon Sep 17 00:00:00 2001
From: Pierre-Loup A. Griffais pgriff...@nvidia.com
Date: Thu, 28 Jul 2011 12:54:13 -0700
Subject: [PATCH] Revert composite: Don't backfill non-MapWindow allocations
This reverts commit db8840600e8e21356241eb87395031388d9b54d2.
It was an optimization for the resize case, but 193ecc8b453b22 made
it so that no backfilling takes place on resize if left in.
Signed-off-by: Pierre-Loup A. Griffais pgriff...@nvidia.com
Reviewed-by: Adam Jackson a...@redhat.com
Conflicts:
composite/compalloc.c
---
composite/compalloc.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/composite/compalloc.c b/composite/compalloc.c
index 5c27631..841b2dc 100644
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -557,7 +557,7 @@ compUnredirectOneSubwindow (WindowPtr pParent, WindowPtr pWin)
}
static PixmapPtr
-compNewPixmap (WindowPtr pWin, int x, int y, int w, int h, Bool map)
+compNewPixmap (WindowPtr pWin, int x, int y, int w, int h)
{
ScreenPtr pScreen = pWin-drawable.pScreen;
WindowPtr pParent = pWin-parent;
@@ -572,10 +572,6 @@ compNewPixmap (WindowPtr pWin, int x, int y, int w, int h, Bool map)
pPixmap-screen_x = x;
pPixmap-screen_y = y;
-/* resize allocations will update later in compCopyWindow, not here */
-if (!map)
- return pPixmap;
-
if (pParent-drawable.depth == pWin-drawable.depth)
{
GCPtr pGC = GetScratchGC (pWin-drawable.depth, pScreen);
@@ -641,7 +637,7 @@ compAllocPixmap (WindowPtr pWin)
int y = pWin-drawable.y - bw;
int w = pWin-drawable.width + (bw 1);
int h = pWin-drawable.height + (bw 1);
-PixmapPtr pPixmap = compNewPixmap (pWin, x, y, w, h, TRUE);
+PixmapPtr pPixmap = compNewPixmap (pWin, x, y, w, h);
CompWindowPtr cw = GetCompWindow (pWin);
if (!pPixmap)
@@ -713,7 +709,7 @@ compReallocPixmap (WindowPtr pWin, int draw_x, int draw_y,
pix_h = h + (bw 1);
if (pix_w != pOld-drawable.width || pix_h != pOld-drawable.height)
{
- pNew = compNewPixmap (pWin, pix_x, pix_y, pix_w, pix_h, FALSE);
+ pNew = compNewPixmap (pWin, pix_x, pix_y, pix_w, pix_h);
if (!pNew)
return FALSE;
cw-pOldPixmap = pOld;
--
1.7.4.1
___
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] rootless: Fix SetShape regression
On 06/04/2010 09:58 PM, Jeremy Huddleston wrote:
This fixes a regression in miext/rootless from
643cb6e87c10ab554c03ada81930001a8ebcc909
Whoops.
Reviewed-by: Pierre-Loup A. Griffais pgriff...@nvidia.com
Found-by: tinderbox
Signed-off-by: Jeremy Huddlestonjerem...@apple.com
---
miext/rootless/rootlessWindow.c |4 ++--
miext/rootless/rootlessWindow.h |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/miext/rootless/rootlessWindow.c b/miext/rootless/rootlessWindow.c
index ce088c7..4d541f4 100644
--- a/miext/rootless/rootlessWindow.c
+++ b/miext/rootless/rootlessWindow.c
@@ -288,12 +288,12 @@ static void RootlessReshapeFrame(WindowPtr pWin)
* shaped when the window is framed.
*/
void
-RootlessSetShape(WindowPtr pWin)
+RootlessSetShape(WindowPtr pWin, int kind)
{
ScreenPtr pScreen = pWin-drawable.pScreen;
SCREEN_UNWRAP(pScreen, SetShape);
-pScreen-SetShape(pWin);
+pScreen-SetShape(pWin, kind);
SCREEN_WRAP(pScreen, SetShape);
RootlessReshapeFrame(pWin);
diff --git a/miext/rootless/rootlessWindow.h b/miext/rootless/rootlessWindow.h
index ca104a4..2b018e0 100644
--- a/miext/rootless/rootlessWindow.h
+++ b/miext/rootless/rootlessWindow.h
@@ -39,7 +39,7 @@
Bool RootlessCreateWindow(WindowPtr pWin);
Bool RootlessDestroyWindow(WindowPtr pWin);
-void RootlessSetShape(WindowPtr pWin);
+void RootlessSetShape(WindowPtr pWin, int kind);
Bool RootlessChangeWindowAttributes(WindowPtr pWin, unsigned long vmask);
Bool RootlessPositionWindow(WindowPtr pWin, int x, int y);
___
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] Don't ValidateTree/expose when changing the input shape
On 05/27/2010 04:13 AM, Daniel Stone wrote:
* PGP Signed by an unknown key
On Wed, May 26, 2010 at 04:57:02PM -0700, Pierre-Loup A. Griffais wrote:
ValidateTree can be pretty expensive; gnome-shell floods the server with
input shape requests when animating windows, so that change makes it
perform a lot better.
Aaron suggested Keith and Adam as reviewers; are the SetWinSize,
SetBorderSize, ResizeChildrenWinSize also unneeded when changing the
input shape? The only thing that looks needed for sure is
CheckCursorConfinement(), but I have my doubts about the rest.
You don't need to call any of SetWinSize, SetBorderSize, or
ResizeChildrenWinSize, which are also moderately hostile. So if you
skipped those three for changes only to the input shape:
Reviewed-by: Daniel Stonedan...@fooishbar.org
Great, thanks a lot. New patch attached that explicitly conditionalizes most of
the function depending on the shape kind at Keith's suggestion. Indenting the
new block caused my editor to destroy all the tabs, so I had to touch up the
style of most of the function; sorry that makes the patch hard to read. Also
updated the commit message to reflect the more general approach of the change.
Thanks!
- Pierre-Loup
Cheers,
Daniel
* Unknown Key
* 0xB2808094
From 753dba594a3ee08ec924c89b5dfea294c6169e18 Mon Sep 17 00:00:00 2001
From: Pierre-Loup A. Griffais pgriff...@nvidia.com
Date: Wed, 26 May 2010 15:30:28 -0700
Subject: [PATCH] Only deal with input code when changing the input shape.
Propagate the shape kind all the way to SetShape to avoid performing non-input
operations such as revalidating the tree and generating exposures when only
changing a window's input shape.
Signed-off-by: Pierre-Loup A. Griffais pgriff...@nvidia.com
Acked-by: Aaron Plattneraplatt...@nvidia.com
---
Xext/shape.c |4 +-
hw/dmx/dmxwindow.c|4 +-
hw/dmx/dmxwindow.h|2 +-
hw/xnest/Window.c |4 +-
hw/xnest/XNWindow.h |2 +-
hw/xwin/win.h |4 +-
hw/xwin/winmultiwindowshape.c |6 +-
hw/xwin/winwindow.c |6 +-
include/scrnintstr.h |3 +-
mi/mi.h |3 +-
mi/mioverlay.c| 81 ++-
mi/miwindow.c | 94 +---
xfixes/region.c |2 +-
13 files changed, 112 insertions(+), 103 deletions(-)
diff --git a/Xext/shape.c b/Xext/shape.c
index 93e4703..86b0bc0 100644
--- a/Xext/shape.c
+++ b/Xext/shape.c
@@ -220,7 +220,7 @@ RegionOperate (
}
if (srcRgn)
REGION_DESTROY(pScreen, srcRgn);
-(*pScreen-SetShape) (pWin);
+(*pScreen-SetShape) (pWin, kind);
SendShapeNotify (pWin, kind);
return Success;
}
@@ -642,7 +642,7 @@ ProcShapeOffset (ClientPtr client)
if (srcRgn)
{
REGION_TRANSLATE(pScreen, srcRgn, stuff-xOff, stuff-yOff);
-(*pScreen-SetShape) (pWin);
+(*pScreen-SetShape) (pWin, stuff-destKind);
}
SendShapeNotify (pWin, (int)stuff-destKind);
return Success;
diff --git a/hw/dmx/dmxwindow.c b/hw/dmx/dmxwindow.c
index 39af510..5b0baff 100644
--- a/hw/dmx/dmxwindow.c
+++ b/hw/dmx/dmxwindow.c
@@ -991,7 +991,7 @@ static void dmxDoSetShape(WindowPtr pWindow)
}
/** Set shape of \a pWindow on the back-end server. */
-void dmxSetShape(WindowPtr pWindow)
+void dmxSetShape(WindowPtr pWindow, int kind)
{
ScreenPtr pScreen = pWindow-drawable.pScreen;
DMXScreenInfo *dmxScreen = dmxScreens[pScreen-myNum];
@@ -1000,7 +1000,7 @@ void dmxSetShape(WindowPtr pWindow)
DMX_UNWRAP(SetShape, dmxScreen, pScreen);
#if 1
if (pScreen-SetShape)
- pScreen-SetShape(pWindow);
+ pScreen-SetShape(pWindow, kind);
#endif
if (pWinPriv-window) {
diff --git a/hw/dmx/dmxwindow.h b/hw/dmx/dmxwindow.h
index 740a21f..8bd1f74 100644
--- a/hw/dmx/dmxwindow.h
+++ b/hw/dmx/dmxwindow.h
@@ -94,7 +94,7 @@ extern void dmxResizeRootWindow(WindowPtr pRoot,
extern Bool dmxBEDestroyWindow(WindowPtr pWindow);
/* Support for shape extension */
-extern void dmxSetShape(WindowPtr pWindow);
+extern void dmxSetShape(WindowPtr pWindow, int kind);
/** Private index. \see dmxwindow.c \see dmxscrinit.c */
extern DevPrivateKey dmxWinPrivateKey;
diff --git a/hw/xnest/Window.c b/hw/xnest/Window.c
index 48c870f..11d5369 100644
--- a/hw/xnest/Window.c
+++ b/hw/xnest/Window.c
@@ -423,10 +423,10 @@ xnestWindowExposures(WindowPtr pWin, RegionPtr pRgn, RegionPtr other_exposed)
}
void
-xnestSetShape(WindowPtr pWin)
+xnestSetShape(WindowPtr pWin, int kind)
{
xnestShapeWindow(pWin);
- miSetShape(pWin);
+ miSetShape(pWin, kind);
}
static Bool
diff --git a/hw/xnest/XNWindow.h b/hw/xnest/XNWindow.h
index b59d86a..92a1902 100644
--- a/hw/xnest/XNWindow.h
+++ b/hw/xnest/XNWindow.h
@@ -66,7 +66,7 @@ void xnestCopyWindow(WindowPtr pWin, xPoint oldOrigin, RegionPtr oldRegion);
void xnestClipNotify(WindowPtr pWin, int dx
[PATCH] Don't ValidateTree/expose when changing the input shape
ValidateTree can be pretty expensive; gnome-shell floods the server with input
shape requests when animating windows, so that change makes it perform a lot better.
Aaron suggested Keith and Adam as reviewers; are the SetWinSize, SetBorderSize,
ResizeChildrenWinSize also unneeded when changing the input shape? The only
thing that looks needed for sure is CheckCursorConfinement(), but I have my
doubts about the rest.
Thanks,
- Pierre-Loup
From d462db1f8bf99c428fcc59e1f167f563e789995e Mon Sep 17 00:00:00 2001
From: Pierre-Loup A. Griffais pgriff...@nvidia.com
Date: Wed, 26 May 2010 15:30:28 -0700
Subject: [PATCH] Don't ValidateTree/expose when changing the input shape.
Propagate the shape kind all the way to SetShape to avoid revalidating the tree
and generating exposures when only changing a window's input shape.
Signed-off-by: Pierre-Loup A. Griffais pgriff...@nvidia.com
Acked-by: Aaron Plattneraplatt...@nvidia.com
---
Xext/shape.c |4 ++--
hw/dmx/dmxwindow.c|4 ++--
hw/dmx/dmxwindow.h|2 +-
hw/xnest/Window.c |4 ++--
hw/xnest/XNWindow.h |2 +-
hw/xwin/win.h |4 ++--
hw/xwin/winmultiwindowshape.c |6 +++---
hw/xwin/winwindow.c |6 +++---
include/scrnintstr.h |3 ++-
mi/mi.h |3 ++-
mi/mioverlay.c|7 ---
mi/miwindow.c |5 +++--
xfixes/region.c |2 +-
13 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/Xext/shape.c b/Xext/shape.c
index 93e4703..86b0bc0 100644
--- a/Xext/shape.c
+++ b/Xext/shape.c
@@ -220,7 +220,7 @@ RegionOperate (
}
if (srcRgn)
REGION_DESTROY(pScreen, srcRgn);
-(*pScreen-SetShape) (pWin);
+(*pScreen-SetShape) (pWin, kind);
SendShapeNotify (pWin, kind);
return Success;
}
@@ -642,7 +642,7 @@ ProcShapeOffset (ClientPtr client)
if (srcRgn)
{
REGION_TRANSLATE(pScreen, srcRgn, stuff-xOff, stuff-yOff);
-(*pScreen-SetShape) (pWin);
+(*pScreen-SetShape) (pWin, stuff-destKind);
}
SendShapeNotify (pWin, (int)stuff-destKind);
return Success;
diff --git a/hw/dmx/dmxwindow.c b/hw/dmx/dmxwindow.c
index 39af510..5b0baff 100644
--- a/hw/dmx/dmxwindow.c
+++ b/hw/dmx/dmxwindow.c
@@ -991,7 +991,7 @@ static void dmxDoSetShape(WindowPtr pWindow)
}
/** Set shape of \a pWindow on the back-end server. */
-void dmxSetShape(WindowPtr pWindow)
+void dmxSetShape(WindowPtr pWindow, int kind)
{
ScreenPtr pScreen = pWindow-drawable.pScreen;
DMXScreenInfo *dmxScreen = dmxScreens[pScreen-myNum];
@@ -1000,7 +1000,7 @@ void dmxSetShape(WindowPtr pWindow)
DMX_UNWRAP(SetShape, dmxScreen, pScreen);
#if 1
if (pScreen-SetShape)
- pScreen-SetShape(pWindow);
+ pScreen-SetShape(pWindow, kind);
#endif
if (pWinPriv-window) {
diff --git a/hw/dmx/dmxwindow.h b/hw/dmx/dmxwindow.h
index 740a21f..8bd1f74 100644
--- a/hw/dmx/dmxwindow.h
+++ b/hw/dmx/dmxwindow.h
@@ -94,7 +94,7 @@ extern void dmxResizeRootWindow(WindowPtr pRoot,
extern Bool dmxBEDestroyWindow(WindowPtr pWindow);
/* Support for shape extension */
-extern void dmxSetShape(WindowPtr pWindow);
+extern void dmxSetShape(WindowPtr pWindow, int kind);
/** Private index. \see dmxwindow.c \see dmxscrinit.c */
extern DevPrivateKey dmxWinPrivateKey;
diff --git a/hw/xnest/Window.c b/hw/xnest/Window.c
index 48c870f..11d5369 100644
--- a/hw/xnest/Window.c
+++ b/hw/xnest/Window.c
@@ -423,10 +423,10 @@ xnestWindowExposures(WindowPtr pWin, RegionPtr pRgn, RegionPtr other_exposed)
}
void
-xnestSetShape(WindowPtr pWin)
+xnestSetShape(WindowPtr pWin, int kind)
{
xnestShapeWindow(pWin);
- miSetShape(pWin);
+ miSetShape(pWin, kind);
}
static Bool
diff --git a/hw/xnest/XNWindow.h b/hw/xnest/XNWindow.h
index b59d86a..92a1902 100644
--- a/hw/xnest/XNWindow.h
+++ b/hw/xnest/XNWindow.h
@@ -66,7 +66,7 @@ void xnestCopyWindow(WindowPtr pWin, xPoint oldOrigin, RegionPtr oldRegion);
void xnestClipNotify(WindowPtr pWin, int dx, int dy);
void xnestWindowExposures(WindowPtr pWin, RegionPtr pRgn,
RegionPtr other_exposed);
-void xnestSetShape(WindowPtr pWin);
+void xnestSetShape(WindowPtr pWin, int kind);
void xnestShapeWindow(WindowPtr pWin);
#endif /* XNESTWINDOW_H */
diff --git a/hw/xwin/win.h b/hw/xwin/win.h
index 26bb856..49b73d7 100644
--- a/hw/xwin/win.h
+++ b/hw/xwin/win.h
@@ -1204,7 +1204,7 @@ Bool
winMapWindowRootless (WindowPtr pWindow);
void
-winSetShapeRootless (WindowPtr pWindow);
+winSetShapeRootless (WindowPtr pWindow, int kind);
/*
@@ -1226,7 +1226,7 @@ void
winReshapeMultiWindow (WindowPtr pWin);
void
-winSetShapeMultiWindow (WindowPtr pWindow);
+winSetShapeMultiWindow (WindowPtr pWindow, int kind);
void
winUpdateRgnMultiWindow (WindowPtr pWindow);
diff --git a/hw/xwin/winmultiwindowshape.c b/hw/xwin/winmultiwindowshape.c
index 3532357..597eab6 100644
--- a/hw/xwin
Re: [PATCH] midispcur: Construct Picture objects lazily in case Render is disabled.
On 05/24/2010 07:05 PM, Jamey Sharp wrote: On Mon, May 24, 2010 at 4:49 PM, Pierre-Loup A. Griffais pgriff...@nvidia.com wrote: On 05/24/2010 09:34 AM, Jamey Sharp wrote: These Pictures are not freed in miDCDeviceCleanup. Before the don't thrash resources patch, there was a comment suggesting that pRootPicture was already freed for some reason, but it did free pTempPicture. See http://lists.x.org/archives/xorg-devel/2010-April/007699.html Ah, I get it. Thanks for the pointer; I've just sent a patch that includes a comment explaining what's going on there. The patch itself looks good to me. Would you provide a Reviewed-by tag, and CC Keith, then? Sure, sorry. Reviewed-by: Pierre-Loup A. Griffais pgriff...@nvidia.com Thanks! Jamey ___ 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: multi-card breakage
Tiago, On 05/19/2010 08:09 AM, Vignatti Tiago (Nokia-D/Helsinki) wrote: Hi Pierre, On Tue, May 04, 2010 at 10:21:55PM +0200, ext Pierre-Loup A. Griffais wrote: I just reproduced something that sounds like what you're describing with two R520 cards (one X screen per card) and the 'radeon' driver. However, it seems unrelated to my change; that's what the hang looks like: 575 VGAGet(); (gdb) bt #0 VGAarbiterCreateGC (pGC=0x83ebab0) at ../../../../hw/xfree86/common/xf86VGAarbiter.c:575 #1 0x080777ba in CreateGC (pDrawable=0x82d8d78, mask=value optimized out, pval=0xb534, pStatus=0xb53c, gcid=0, client=0x81ffca8) at ../../dix/gc.c:647 #2 0x0819e612 in miDCMakeGC (pWin=0x82b5530) at ../../mi/midispcur.c:422 #3 0x0819e7c4 in miDCDeviceInitialize (pDev=0x83ebdf0, pScreen=0x8263688) at ../../mi/midispcur.c:790 #4 0x081c48cf in miSpriteDeviceCursorInitialize (pDev=0x83ebdf0, pScreen=0x8263688) at ../../mi/misprite.c:949 #5 0x08186364 in xf86DeviceCursorInitialize (pDev=0x83ebdf0, pScreen=0x8263688) at ../../../../hw/xfree86/ramdac/xf86Cursor.c:453 #6 0x081672ba in VGAarbiterDeviceCursorInitialize (pDev=0x83ebdf0, pScreen=0x8263688) at ../../../../hw/xfree86/common/xf86VGAarbiter.c:1035 #7 0x080a1e0c in miPointerDeviceInitialize (pDev=0x83ebdf0, pScreen=0x8263688) at ../../mi/mipointer.c:283 #8 0x08087ed5 in ActivateDevice (dev=0x83ebdf0, sendevent=1 '\001') at ../../dix/devices.c:477 #9 0x08088f08 in InitCoreDevices () at ../../dix/devices.c:610 #10 0x08066d18 in main (argc=1, argv=0xb8a4, envp=0xb8ac) at ../../dix/main.c:255 The reason my change exposes this bug is that it creates a GC attached to the second screen upfront. If I roll it back, I still get the same hang after trying to move a SW cursor to the second screen of connecting an X client to the second screen. I'm still getting a very weird lock-up with your patch. I can get it even with hw cursor. Seems not related at all with the log bellow when radeon POST bios, so I guess your commit added a regression. Just reverting it solves the problem - and sorry, I don't know this code in depth to start dig the reason. Multiple cards work fine on my end. All this change does is create a few GCs and Pictures upfront on each X screen; I don't believe it sits at a level where we can consider it's directly the cause of a system hang. Can you provide more information regarding the issues you're having? What driver are you using? Try single-stepping through miDCDeviceInitialize() when the server starts and progressively break into more functions to determine where it hangs with more accuracy. Also, if X is hung in the kernel because of an interaction problem with the VGA-arbiter (as I still think that's the problem you're having), using an SMP-capable setup should allow you to keep interacting with the system after X hangs. Thanks, - Pierre-Loup BTW, Peter did you test this patch there with multiple cards? I'd revert this patch meanwhile (attached). Looking at the X log, I see: (II) RADEON(1): PCIE card detected (II) Loading sub module int10 (II) LoadModule: int10 (II) Reloading /usr/lib/xorg/modules/libint10.so (II) RADEON(1): initializing int10 (EE) RADEON(1): Cannot read V_BIOS (3) Input/output error (WW) RADEON(1): Failed to read PCI ROM! (II) RADEON(1): Attempting to read un-POSTed bios and in the kernel log: [ 1240.582149] pci :05:00.0: Invalid ROM contents That means the VGA arbiter tried to switch VGA access to an un-posted device, which is presumably the cause of the hang. It seems like the X screen should fail ScreenInit() and get discarded after initializing int10 fails. Whatever the reason behind that is, the driver ought to fail more gracefully. In any case, I'm guessing you have similar spew in your logs? no. My logs are normal, without any apparent errors. Thank you, Tiago ___ 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] Device init: Don't crash when CreateGC fails.
That looks good to me. Sorry I for introducing this!
- Pierre-Loup
On 05/14/2010 11:37 AM, Jamey Sharp wrote:
ActivateDevice was ignoring errors from DeviceCursorInitialize, so
cursor-related calls failed later. Jeremy Huddleston saw that crash in
miPointerConstrainCursor, while with Xvfb I saw it in
miSpriteRealizeCursor.
miDCDeviceCleanup frees any non-NULL GCs. miDCDeviceInitialize calls
Cleanup on any failure, but if it failed early then some of the pointers
in the miDCBufferPtr were garbage. Switch from malloc to calloc to
ensure everything's initialized safely first.
With these two fixes, if CreateGC fails then the server gracefully fails
in FatalError instead of segfaulting.
Signed-off-by: Jamey Sharpja...@minilop.net
Cc: Peter Huttererpeter.hutte...@who-t.net
---
dix/devices.c |3 ++-
mi/midispcur.c |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/dix/devices.c b/dix/devices.c
index de72c88..5bffcac 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -467,7 +467,8 @@ ActivateDevice(DeviceIntPtr dev, BOOL sendevent)
/* Initialize memory for sprites. */
if (IsMaster(dev) dev-spriteInfo-spriteOwner)
-pScreen-DeviceCursorInitialize(dev, pScreen);
+if (!pScreen-DeviceCursorInitialize(dev, pScreen))
+ return BadImplementation;
SendDevicePresenceEvent(dev-id, DeviceAdded);
if (sendevent)
diff --git a/mi/midispcur.c b/mi/midispcur.c
index 1acc469..4de37d7 100644
--- a/mi/midispcur.c
+++ b/mi/midispcur.c
@@ -780,7 +780,7 @@ miDCDeviceInitialize(DeviceIntPtr pDev, ScreenPtr pScreen)
{
pScreen = screenInfo.screens[i];
-pBuffer = malloc(sizeof(miDCBufferRec));
+pBuffer = calloc(1, sizeof(miDCBufferRec));
if (!pBuffer)
goto failure;
___
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: multi-card breakage
Tiago, This commit fixes the SW cursor with several screens, so the multi-card case is more or less the point of the change. Can you be more specific about the problems you're having and your testing environment? Do you have the SW cursor forced on? Removing the dependency on devPrivates from this layer is way outside the scope of this patch. Thanks, - Pierre-Loup On 05/04/2010 07:10 AM, Tiago Vignatti wrote: Pierre and Peter, commit 518f3b189b6c8aa28b62837d14309fd06163ccbb Author: Pierre-Loup A. Griffaispgriff...@nvidia.com Date: Wed Apr 21 16:46:17 2010 -0700 mi: don't thrash resources when displaying the software cursor across screens This commit break my system in a very bizarre way that I cannot kill the X server, neither use it anymore. I can reproduce it only when I set two video cards by the server. I haven't checked the logic behind the commit to see exactly what's going wrong. But I'd guess maybe your forgetting multi-card case? Also, we don't want privates mechanism in these common layers, so you could cook a commit without it. Cheers, Tiago ___ 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: multi-card breakage
Tiago, I just reproduced something that sounds like what you're describing with two R520 cards (one X screen per card) and the 'radeon' driver. However, it seems unrelated to my change; that's what the hang looks like: 575 VGAGet(); (gdb) bt #0 VGAarbiterCreateGC (pGC=0x83ebab0) at ../../../../hw/xfree86/common/xf86VGAarbiter.c:575 #1 0x080777ba in CreateGC (pDrawable=0x82d8d78, mask=value optimized out, pval=0xb534, pStatus=0xb53c, gcid=0, client=0x81ffca8) at ../../dix/gc.c:647 #2 0x0819e612 in miDCMakeGC (pWin=0x82b5530) at ../../mi/midispcur.c:422 #3 0x0819e7c4 in miDCDeviceInitialize (pDev=0x83ebdf0, pScreen=0x8263688) at ../../mi/midispcur.c:790 #4 0x081c48cf in miSpriteDeviceCursorInitialize (pDev=0x83ebdf0, pScreen=0x8263688) at ../../mi/misprite.c:949 #5 0x08186364 in xf86DeviceCursorInitialize (pDev=0x83ebdf0, pScreen=0x8263688) at ../../../../hw/xfree86/ramdac/xf86Cursor.c:453 #6 0x081672ba in VGAarbiterDeviceCursorInitialize (pDev=0x83ebdf0, pScreen=0x8263688) at ../../../../hw/xfree86/common/xf86VGAarbiter.c:1035 #7 0x080a1e0c in miPointerDeviceInitialize (pDev=0x83ebdf0, pScreen=0x8263688) at ../../mi/mipointer.c:283 #8 0x08087ed5 in ActivateDevice (dev=0x83ebdf0, sendevent=1 '\001') at ../../dix/devices.c:477 #9 0x08088f08 in InitCoreDevices () at ../../dix/devices.c:610 #10 0x08066d18 in main (argc=1, argv=0xb8a4, envp=0xb8ac) at ../../dix/main.c:255 The reason my change exposes this bug is that it creates a GC attached to the second screen upfront. If I roll it back, I still get the same hang after trying to move a SW cursor to the second screen of connecting an X client to the second screen. Looking at the X log, I see: (II) RADEON(1): PCIE card detected (II) Loading sub module int10 (II) LoadModule: int10 (II) Reloading /usr/lib/xorg/modules/libint10.so (II) RADEON(1): initializing int10 (EE) RADEON(1): Cannot read V_BIOS (3) Input/output error (WW) RADEON(1): Failed to read PCI ROM! (II) RADEON(1): Attempting to read un-POSTed bios and in the kernel log: [ 1240.582149] pci :05:00.0: Invalid ROM contents That means the VGA arbiter tried to switch VGA access to an un-posted device, which is presumably the cause of the hang. It seems like the X screen should fail ScreenInit() and get discarded after initializing int10 fails. Whatever the reason behind that is, the driver ought to fail more gracefully. In any case, I'm guessing you have similar spew in your logs? Thanks, - Pierre-Loup On 05/04/2010 10:28 AM, Pierre-Loup A. Griffais wrote: Tiago, This commit fixes the SW cursor with several screens, so the multi-card case is more or less the point of the change. Can you be more specific about the problems you're having and your testing environment? Do you have the SW cursor forced on? Removing the dependency on devPrivates from this layer is way outside the scope of this patch. Thanks, - Pierre-Loup On 05/04/2010 07:10 AM, Tiago Vignatti wrote: Pierre and Peter, commit 518f3b189b6c8aa28b62837d14309fd06163ccbb Author: Pierre-Loup A. Griffaispgriff...@nvidia.com Date: Wed Apr 21 16:46:17 2010 -0700 mi: don't thrash resources when displaying the software cursor across screens This commit break my system in a very bizarre way that I cannot kill the X server, neither use it anymore. I can reproduce it only when I set two video cards by the server. I haven't checked the logic behind the commit to see exactly what's going wrong. But I'd guess maybe your forgetting multi-card case? Also, we don't want privates mechanism in these common layers, so you could cook a commit without it. Cheers, Tiago ___ 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] Revert mi: don't thrash resources when displaying the software cursor across screens
= miDCMakeGC(pWin);
-if (!pBuffer-pMaskGC)
-goto failure;
-
-pBuffer-pSaveGC = miDCMakeGC(pWin);
-if (!pBuffer-pSaveGC)
-goto failure;
-
-pBuffer-pRestoreGC = miDCMakeGC(pWin);
-if (!pBuffer-pRestoreGC)
-goto failure;
-
-pBuffer-pMoveGC = CreateGC ((DrawablePtr)pWin,
-GCGraphicsExposures,gcval,status, (XID)0, serverClient);
-if (!pBuffer-pMoveGC)
-goto failure;
-
-pBuffer-pPixSourceGC = CreateGC ((DrawablePtr)pWin,
-GCGraphicsExposures,gcval,status, (XID)0, serverClient);
-if (!pBuffer-pPixSourceGC)
-goto failure;
-
-pBuffer-pPixMaskGC = CreateGC ((DrawablePtr)pWin,
-GCGraphicsExposures,gcval,status, (XID)0, serverClient);
-if (!pBuffer-pPixMaskGC)
-goto failure;
-
+miDCBufferPtr pBuffer;
+
+pBuffer = xalloc(sizeof(miDCBufferRec));
+dixSetPrivate(pDev-devPrivates, miDCSpriteKey, pBuffer);
+
+pBuffer-pSourceGC =
+pBuffer-pMaskGC =
+pBuffer-pSaveGC =
+pBuffer-pRestoreGC =
+pBuffer-pMoveGC =
+pBuffer-pPixSourceGC =
+pBuffer-pPixMaskGC = NULL;
#ifdef ARGB_CURSOR
-miDCMakePicture(pBuffer-pRootPicture,pWin-drawable, pWin);
-if (!pBuffer-pRootPicture)
-goto failure;
-
-pBuffer-pTempPicture = NULL;
+pBuffer-pRootPicture = NULL;
+pBuffer-pTempPicture = NULL;
#endif
-
-// these get (re)allocated lazily depending on the cursor size
-pBuffer-pSave = pBuffer-pTemp = NULL;
-}
+pBuffer-pSave = pBuffer-pTemp = NULL;
return TRUE;
-
-failure:
-
-miDCDeviceCleanup(pDev, pScreen);
-
-return FALSE;
}
static void
miDCDeviceCleanup(DeviceIntPtr pDev, ScreenPtr pScreen)
{
miDCBufferPtr pBuffer;
-int i;
if (DevHasCursor(pDev))
{
-for (i = 0; i screenInfo.numScreens; i++)
-{
-pScreen = screenInfo.screens[i];
-
-pBuffer = MIDCBUFFER(pDev, pScreen);
-
-if (pBuffer)
-{
-if (pBuffer-pSourceGC) FreeGC(pBuffer-pSourceGC, (GContext)
0);
-if (pBuffer-pMaskGC) FreeGC(pBuffer-pMaskGC, (GContext) 0);
-if (pBuffer-pSaveGC) FreeGC(pBuffer-pSaveGC, (GContext) 0);
-if (pBuffer-pRestoreGC) FreeGC(pBuffer-pRestoreGC,
(GContext) 0);
-if (pBuffer-pMoveGC) FreeGC(pBuffer-pMoveGC, (GContext) 0);
-if (pBuffer-pPixSourceGC) FreeGC(pBuffer-pPixSourceGC,
(GContext) 0);
-if (pBuffer-pPixMaskGC) FreeGC(pBuffer-pPixMaskGC,
(GContext) 0);
-
+pBuffer = MIDCBUFFER(pDev);
+tossGC (pBuffer-pSourceGC);
+tossGC (pBuffer-pMaskGC);
+tossGC (pBuffer-pSaveGC);
+tossGC (pBuffer-pRestoreGC);
+tossGC (pBuffer-pMoveGC);
+tossGC (pBuffer-pPixSourceGC);
+tossGC (pBuffer-pPixMaskGC);
+tossPix (pBuffer-pSave);
+tossPix (pBuffer-pTemp);
#ifdef ARGB_CURSOR
-if (pBuffer-pRootPicture) FreePicture(pBuffer-pRootPicture,
0);
-if (pBuffer-pTempPicture) FreePicture(pBuffer-pTempPicture,
0);
+#if 0 /* This has been free()d before */
+tossPict (pScreenPriv-pRootPicture);
+#endif
+tossPict (pBuffer-pTempPicture);
#endif
-
-if (pBuffer-pSave) (*pScreen-DestroyPixmap)(pBuffer-pSave);
-if (pBuffer-pTemp) (*pScreen-DestroyPixmap)(pBuffer-pTemp);
-
-xfree(pBuffer);
-dixSetPrivate(pDev-devPrivates, miDCSpriteKey +
pScreen-myNum, NULL);
-}
-}
+xfree(pBuffer);
+dixSetPrivate(pDev-devPrivates, miDCSpriteKey, NULL);
}
}
--
1.6.6.1
From 08e0cdea2142363ae36c1b916a4819ff4a861483 Mon Sep 17 00:00:00 2001
From: Pierre-Loup A. Griffais pgriff...@nvidia.com
Date: Wed, 21 Apr 2010 12:02:26 -0700
Subject: [PATCH] Don't double-free the software cursor pictures.
Signed-off-by: Pierre-Loup A. Griffais pgriff...@nvidia.com
---
mi/midispcur.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/mi/midispcur.c b/mi/midispcur.c
index 3a31b74..9041630 100644
--- a/mi/midispcur.c
+++ b/mi/midispcur.c
@@ -863,11 +863,6 @@ miDCDeviceCleanup(DeviceIntPtr pDev, ScreenPtr pScreen)
if (pBuffer-pPixSourceGC) FreeGC(pBuffer-pPixSourceGC, (GContext) 0);
if (pBuffer-pPixMaskGC) FreeGC(pBuffer-pPixMaskGC, (GContext) 0);
-#ifdef ARGB_CURSOR
-if (pBuffer-pRootPicture) FreePicture(pBuffer-pRootPicture, 0);
-if (pBuffer-pTempPicture) FreePicture(pBuffer-pTempPicture, 0);
-#endif
-
if (pBuffer-pSave) (*pScreen-DestroyPixmap)(pBuffer-pSave);
if (pBuffer-pTemp) (*pScreen-DestroyPixmap)(pBuffer-pTemp);
--
1.7.0.4
___
xorg-devel@lists.x.org
Re: [PATCH] Revert mi: don't thrash resources when displaying the software cursor across screens
(pWin);
-if (!pBuffer-pRestoreGC)
-goto failure;
-
-pBuffer-pMoveGC = CreateGC ((DrawablePtr)pWin,
-GCGraphicsExposures,gcval,status, (XID)0, serverClient);
-if (!pBuffer-pMoveGC)
-goto failure;
-
-pBuffer-pPixSourceGC = CreateGC ((DrawablePtr)pWin,
-GCGraphicsExposures,gcval,status, (XID)0, serverClient);
-if (!pBuffer-pPixSourceGC)
-goto failure;
-
-pBuffer-pPixMaskGC = CreateGC ((DrawablePtr)pWin,
-GCGraphicsExposures,gcval,status, (XID)0, serverClient);
-if (!pBuffer-pPixMaskGC)
-goto failure;
-
+miDCBufferPtr pBuffer;
+
+pBuffer = xalloc(sizeof(miDCBufferRec));
+dixSetPrivate(pDev-devPrivates, miDCSpriteKey, pBuffer);
+
+pBuffer-pSourceGC =
+pBuffer-pMaskGC =
+pBuffer-pSaveGC =
+pBuffer-pRestoreGC =
+pBuffer-pMoveGC =
+pBuffer-pPixSourceGC =
+pBuffer-pPixMaskGC = NULL;
#ifdef ARGB_CURSOR
-miDCMakePicture(pBuffer-pRootPicture,pWin-drawable, pWin);
-if (!pBuffer-pRootPicture)
-goto failure;
-
-pBuffer-pTempPicture = NULL;
+pBuffer-pRootPicture = NULL;
+pBuffer-pTempPicture = NULL;
#endif
-
-// these get (re)allocated lazily depending on the cursor size
-pBuffer-pSave = pBuffer-pTemp = NULL;
-}
+pBuffer-pSave = pBuffer-pTemp = NULL;
return TRUE;
-
-failure:
-
-miDCDeviceCleanup(pDev, pScreen);
-
-return FALSE;
}
static void
miDCDeviceCleanup(DeviceIntPtr pDev, ScreenPtr pScreen)
{
miDCBufferPtr pBuffer;
-int i;
if (DevHasCursor(pDev))
{
-for (i = 0; i screenInfo.numScreens; i++)
-{
-pScreen = screenInfo.screens[i];
-
-pBuffer = MIDCBUFFER(pDev, pScreen);
-
-if (pBuffer)
-{
-if (pBuffer-pSourceGC) FreeGC(pBuffer-pSourceGC, (GContext)
0);
-if (pBuffer-pMaskGC) FreeGC(pBuffer-pMaskGC, (GContext) 0);
-if (pBuffer-pSaveGC) FreeGC(pBuffer-pSaveGC, (GContext) 0);
-if (pBuffer-pRestoreGC) FreeGC(pBuffer-pRestoreGC,
(GContext) 0);
-if (pBuffer-pMoveGC) FreeGC(pBuffer-pMoveGC, (GContext) 0);
-if (pBuffer-pPixSourceGC) FreeGC(pBuffer-pPixSourceGC,
(GContext) 0);
-if (pBuffer-pPixMaskGC) FreeGC(pBuffer-pPixMaskGC,
(GContext) 0);
-
+pBuffer = MIDCBUFFER(pDev);
+tossGC (pBuffer-pSourceGC);
+tossGC (pBuffer-pMaskGC);
+tossGC (pBuffer-pSaveGC);
+tossGC (pBuffer-pRestoreGC);
+tossGC (pBuffer-pMoveGC);
+tossGC (pBuffer-pPixSourceGC);
+tossGC (pBuffer-pPixMaskGC);
+tossPix (pBuffer-pSave);
+tossPix (pBuffer-pTemp);
#ifdef ARGB_CURSOR
-if (pBuffer-pRootPicture) FreePicture(pBuffer-pRootPicture,
0);
-if (pBuffer-pTempPicture) FreePicture(pBuffer-pTempPicture,
0);
+#if 0 /* This has been free()d before */
+tossPict (pScreenPriv-pRootPicture);
+#endif
+tossPict (pBuffer-pTempPicture);
#endif
-
-if (pBuffer-pSave) (*pScreen-DestroyPixmap)(pBuffer-pSave);
-if (pBuffer-pTemp) (*pScreen-DestroyPixmap)(pBuffer-pTemp);
-
-xfree(pBuffer);
-dixSetPrivate(pDev-devPrivates, miDCSpriteKey +
pScreen-myNum, NULL);
-}
-}
+xfree(pBuffer);
+dixSetPrivate(pDev-devPrivates, miDCSpriteKey, NULL);
}
}
--
1.6.6.1
From 7ffae8aaa4ac445a727e663e1e1bf05a2510cd35 Mon Sep 17 00:00:00 2001
From: Pierre-Loup A. Griffais pgriff...@nvidia.com
Date: Wed, 21 Apr 2010 16:46:17 -0700
Subject: [PATCH] mi: don't thrash resources when displaying the software cursor across screens
This changes the DC layer to maintain a persistent set of GCs/pixmaps/pictures
for each pScreen instead of failing to thrash between them when changing
screens.
Signed-off-by: Pierre-Loup A. Griffais pgriff...@nvidia.com
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
mi/midispcur.c | 269 ++-
1 files changed, 108 insertions(+), 161 deletions(-)
diff --git a/mi/midispcur.c b/mi/midispcur.c
index 3fb7e02..9041630 100644
--- a/mi/midispcur.c
+++ b/mi/midispcur.c
@@ -59,9 +59,9 @@ static DevPrivateKey miDCScreenKey = miDCScreenKeyIndex;
static Bool miDCCloseScreen(int index, ScreenPtr pScreen);
-/* per device private data */
-static int miDCSpriteKeyIndex;
-static DevPrivateKey miDCSpriteKey = miDCSpriteKeyIndex;
+/* per device per-screen private data */
+static int miDCSpriteKeyIndex[MAXSCREENS];
+static DevPrivateKey miDCSpriteKey = miDCSpriteKeyIndex;
typedef struct {
GCPtr pSourceGC, pMaskGC;
@@ -75,10 +75,10 @@ typedef struct {
#endif
} miDCBufferRec, *miDCBufferPtr;
-#define
[PATCH] xf86: Don't crash when switching modes through RandR without owning the VT.
While VT-switched, FB access is disabled and should remain so. Trying to switch
modes in that state would re-enable it, potentially causing crashes if trying
to access it before the driver has recovered from the mode switch.
Thanks,
- Pierre-Loup
From 4d526e470faeaa658cd2cb362d3132384baa478b Mon Sep 17 00:00:00 2001
From: Pierre-Loup A. Griffais pgriff...@nvidia.com
Date: Wed, 21 Apr 2010 17:59:42 -0700
Subject: [PATCH] xf86: Don't crash when switching modes through RandR without owning the VT.
While VT-switched, FB access is disabled and should remain so. Trying to switch
modes in that state would re-enable it, potentially causing crashes if trying
to access it before the driver has recovered from the mode switch.
Signed-off-by: Pierre-Loup A. Griffais pgriff...@nvidia.com
---
hw/xfree86/common/xf86RandR.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/common/xf86RandR.c b/hw/xfree86/common/xf86RandR.c
index 02dcc34..d4beb2c 100644
--- a/hw/xfree86/common/xf86RandR.c
+++ b/hw/xfree86/common/xf86RandR.c
@@ -163,7 +163,7 @@ xf86RandRSetMode (ScreenPtr pScreen,
WindowPtr pRoot = WindowTable[pScreen-myNum];
Bool ret = TRUE;
-if (pRoot)
+if (pRoot scrp-vtSema)
(*scrp-EnableDisableFBAccess) (pScreen-myNum, FALSE);
if (useVirtual)
{
@@ -229,7 +229,7 @@ xf86RandRSetMode (ScreenPtr pScreen,
*/
xf86SetViewport (pScreen, pScreen-width, pScreen-height);
xf86SetViewport (pScreen, 0, 0);
-if (pRoot)
+if (pRoot scrp-vtSema)
(*scrp-EnableDisableFBAccess) (pScreen-myNum, TRUE);
return ret;
}
--
1.7.0.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] mi: fix software cursor with several X screens
Thanks for the review; responses inline and attached revised version of the
patch:
On 04/06/2010 06:52 PM, Peter Hutterer wrote:
On Tue, Apr 06, 2010 at 03:32:49PM -0700, Pierre-Loup A. Griffais wrote:
Now with a proper GC cleanup sequence instead of freeing the same GC in a loop.
Thanks,
- Pierre-Loup
On 04/06/2010 02:44 PM, Pierre-Loup A. Griffais wrote:
(disregard previous message sent too soon)
Attached is a tentative patch that cleans that particular code up and fixes the
issue.
It would seem cleaner to perform the screen looping in ActivateDevice(), but
that would also mean changing miPointerDeviceInitialize and
miSpriteDeviceCursorInitialize to only perform their own setup once in that
case. Opinions?
InitializeSprite is probably the better place since a device doesn't
necessarily get a sprite even when activated (attach SDs for example) and it
may get a sprite without being deactivated first (set floating).
Where do we hook the equivalent cleanup function in that case? Having these
resources being allocated upfront and persisting across enable/disable seems
more consistent in this context. It also means that toggling a device in a
resource exhausted scenario will ensure that the existing storage remains
optimal. Does that make sense?
Thanks,
- Pierre-Loup
On 04/06/2010 08:20 AM, Tiago Vignatti wrote:
On Tue, Apr 06, 2010 at 03:52:07AM +0200, ext Pierre-Loup A. Griffais wrote:
The DC code is broken for setups with several screens. Devs only have one pSave
pixmap and there's no code to thrash them like p[Save|Restore]GC.
That means if you have two X screens and force SW cursor on both, the server
will end up passing a bunch of CopyAreas with mismatching screens to the driver,
which can fail horribly if the driver does a good job abstracting screens away
from each other.
If helps you, I can confirm this happening here also.
Tiago
From e7c5552be9cc217866ea7362c44884baa2964d85 Mon Sep 17 00:00:00 2001
From: Pierre-Loup A. Griffaispgriff...@nvidia.com
Date: Tue, 6 Apr 2010 15:30:30 -0700
Subject: [PATCH] [PATCH] mi: don't thrash resources when displaying the
software cursor across screens
This changes the DC layer to maintain a persistent set of GCs/pixmaps/pictures
for each pScreen instead of failing to thrash between them when changing
screens.
Signed-off-by: Pierre-Loup A. Griffaispgriff...@nvidia.com
---
mi/midispcur.c | 263 +++-
1 files changed, 108 insertions(+), 155 deletions(-)
diff --git a/mi/midispcur.c b/mi/midispcur.c
index 3fb7e02..7d8f876 100644
--- a/mi/midispcur.c
+++ b/mi/midispcur.c
@@ -59,9 +59,9 @@ static DevPrivateKey miDCScreenKey =miDCScreenKeyIndex;
static Bool miDCCloseScreen(int index, ScreenPtr pScreen);
-/* per device private data */
-static int miDCSpriteKeyIndex;
-static DevPrivateKey miDCSpriteKey =miDCSpriteKeyIndex;
+/* per device per-screen private data */
+static int miDCSpriteKeyIndex[MAXSCREENS];
+static DevPrivateKey miDCSpriteKey = miDCSpriteKeyIndex;
typedef struct {
GCPtrpSourceGC, pMaskGC;
@@ -77,8 +77,8 @@ typedef struct {
#define MIDCBUFFER(dev) \
((DevHasCursor(dev)) ? \
- (miDCBufferPtr)dixLookupPrivate(dev-devPrivates, miDCSpriteKey) : \
- (miDCBufferPtr)dixLookupPrivate(dev-u.master-devPrivates, miDCSpriteKey))
+ (miDCBufferPtr)dixLookupPrivate(dev-devPrivates, miDCSpriteKey +
(pScreen)-myNum) : \
+ (miDCBufferPtr)dixLookupPrivate(dev-u.master-devPrivates, miDCSpriteKey +
(pScreen)-myNum))
I think it's better to change the macro to take (dev, pScreen) instead of
magically relying on pScreen to be there.
Good point, done.
/*
* The core pointer buffer will point to the index of the virtual core pointer
@@ -158,10 +158,6 @@ miDCInitialize (ScreenPtr pScreen, miPointerScreenFuncPtr
screenFuncs)
return TRUE;
}
-#define tossGC(gc) (gc ? FreeGC (gc, (GContext) 0) : 0)
-#define tossPix(pix) (pix ? (*pScreen-DestroyPixmap) (pix) : TRUE)
-#define tossPict(pict) (pict ? FreePicture (pict, 0) : 0)
-
static Bool
miDCCloseScreen (int index, ScreenPtr pScreen)
{
@@ -183,7 +179,6 @@ miDCRealizeCursor (ScreenPtr pScreen, CursorPtr pCursor)
}
#ifdef ARGB_CURSOR
-#define EnsurePicture(picture,draw,win) (picture ||
miDCMakePicture(picture,draw,win))
static VisualPtr
miDCGetWindowVisual (WindowPtr pWin)
@@ -415,12 +410,8 @@ miDCPutBits (
(*maskGC-ops-PushPixels) (maskGC, pPriv-maskBits, pDrawable, w, h, x,
y);
}
-#define EnsureGC(gc,win) (gc || miDCMakeGC(gc, win))
-
static GCPtr
-miDCMakeGC(
-GCPtr*ppGC,
-WindowPtrpWin)
+miDCMakeGC(ScreenPtr pScreen)
{
GCPtr pGC;
int status;
@@ -428,10 +419,9 @@ miDCMakeGC(
gcvals[0] = IncludeInferiors;
gcvals[1] = FALSE;
-pGC = CreateGC((DrawablePtr)pWin,
+pGC = CreateGC((DrawablePtr)WindowTable[pScreen-myNum],
GCSubwindowMode|GCGraphicsExposures
Re: Software cursor broken with several X screens
On 04/06/2010 08:20 AM, Tiago Vignatti wrote: On Tue, Apr 06, 2010 at 03:52:07AM +0200, ext Pierre-Loup A. Griffais wrote: The DC code is broken for setups with several screens. Devs only have one pSave pixmap and there's no code to thrash them like p[Save|Restore]GC. That means if you have two X screens and force SW cursor on both, the server will end up passing a bunch of CopyAreas with mismatching screens to the driver, which can fail horribly if the driver does a good job abstracting screens away from each other. If helps you, I can confirm this happening here also. Tiago ___ 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] mi: fix software cursor with several X screens (was Re: Software cursor broken with several X screens)
(disregard previous message sent too soon)
Attached is a tentative patch that cleans that particular code up and fixes the
issue.
It would seem cleaner to perform the screen looping in ActivateDevice(), but
that would also mean changing miPointerDeviceInitialize and
miSpriteDeviceCursorInitialize to only perform their own setup once in that
case. Opinions?
Thanks,
- Pierre-Loup
On 04/06/2010 08:20 AM, Tiago Vignatti wrote:
On Tue, Apr 06, 2010 at 03:52:07AM +0200, ext Pierre-Loup A. Griffais wrote:
The DC code is broken for setups with several screens. Devs only have one pSave
pixmap and there's no code to thrash them like p[Save|Restore]GC.
That means if you have two X screens and force SW cursor on both, the server
will end up passing a bunch of CopyAreas with mismatching screens to the driver,
which can fail horribly if the driver does a good job abstracting screens away
from each other.
If helps you, I can confirm this happening here also.
Tiago
From 2cee3907944d9a4c2624b5f4dbc609e408b8dd9b Mon Sep 17 00:00:00 2001
From: Pierre-Loup A. Griffais pgriff...@nvidia.com
Date: Tue, 6 Apr 2010 14:32:14 -0700
Subject: [PATCH] mi: don't thrash resources when displaying the software cursor across screens
This changes the DC layer to maintain a persistent set of GCs/pixmaps/pictures
for each pScreen instead of failing to thrash between them when changing
screens.
Signed-off-by: Pierre-Loup A. Griffais pgriff...@nvidia.com
---
mi/midispcur.c | 263 +++-
1 files changed, 108 insertions(+), 155 deletions(-)
diff --git a/mi/midispcur.c b/mi/midispcur.c
index 3fb7e02..2187437 100644
--- a/mi/midispcur.c
+++ b/mi/midispcur.c
@@ -59,9 +59,9 @@ static DevPrivateKey miDCScreenKey = miDCScreenKeyIndex;
static Bool miDCCloseScreen(int index, ScreenPtr pScreen);
-/* per device private data */
-static int miDCSpriteKeyIndex;
-static DevPrivateKey miDCSpriteKey = miDCSpriteKeyIndex;
+/* per device per-screen private data */
+static int miDCSpriteKeyIndex[MAXSCREENS];
+static DevPrivateKey miDCSpriteKey = miDCSpriteKeyIndex;
typedef struct {
GCPtr pSourceGC, pMaskGC;
@@ -77,8 +77,8 @@ typedef struct {
#define MIDCBUFFER(dev) \
((DevHasCursor(dev)) ? \
- (miDCBufferPtr)dixLookupPrivate(dev-devPrivates, miDCSpriteKey) : \
- (miDCBufferPtr)dixLookupPrivate(dev-u.master-devPrivates, miDCSpriteKey))
+ (miDCBufferPtr)dixLookupPrivate(dev-devPrivates, miDCSpriteKey + (pScreen)-myNum) : \
+ (miDCBufferPtr)dixLookupPrivate(dev-u.master-devPrivates, miDCSpriteKey + (pScreen)-myNum))
/*
* The core pointer buffer will point to the index of the virtual core pointer
@@ -158,10 +158,6 @@ miDCInitialize (ScreenPtr pScreen, miPointerScreenFuncPtr screenFuncs)
return TRUE;
}
-#define tossGC(gc) (gc ? FreeGC (gc, (GContext) 0) : 0)
-#define tossPix(pix) (pix ? (*pScreen-DestroyPixmap) (pix) : TRUE)
-#define tossPict(pict) (pict ? FreePicture (pict, 0) : 0)
-
static Bool
miDCCloseScreen (int index, ScreenPtr pScreen)
{
@@ -183,7 +179,6 @@ miDCRealizeCursor (ScreenPtr pScreen, CursorPtr pCursor)
}
#ifdef ARGB_CURSOR
-#define EnsurePicture(picture,draw,win) (picture || miDCMakePicture(picture,draw,win))
static VisualPtr
miDCGetWindowVisual (WindowPtr pWin)
@@ -415,12 +410,8 @@ miDCPutBits (
(*maskGC-ops-PushPixels) (maskGC, pPriv-maskBits, pDrawable, w, h, x, y);
}
-#define EnsureGC(gc,win) (gc || miDCMakeGC(gc, win))
-
static GCPtr
-miDCMakeGC(
-GCPtr *ppGC,
-WindowPtr pWin)
+miDCMakeGC(ScreenPtr pScreen)
{
GCPtr pGC;
int status;
@@ -428,10 +419,9 @@ miDCMakeGC(
gcvals[0] = IncludeInferiors;
gcvals[1] = FALSE;
-pGC = CreateGC((DrawablePtr)pWin,
+pGC = CreateGC((DrawablePtr)WindowTable[pScreen-myNum],
GCSubwindowMode|GCGraphicsExposures, gcvals, status,
(XID)0, serverClient);
-*ppGC = pGC;
return pGC;
}
@@ -461,17 +451,6 @@ miDCPutUpCursor (DeviceIntPtr pDev, ScreenPtr pScreen, CursorPtr pCursor,
#ifdef ARGB_CURSOR
if (pPriv-pPicture)
{
-/* see comment in miDCPutUpCursor */
-if (pBuffer-pRootPicture
-pBuffer-pRootPicture-pDrawable
-pBuffer-pRootPicture-pDrawable-pScreen != pScreen)
-{
-tossPict(pBuffer-pRootPicture);
-pBuffer-pRootPicture = NULL;
-}
-
- if (!EnsurePicture(pBuffer-pRootPicture, pWin-drawable, pWin))
- return FALSE;
CompositePicture (PictOpOver,
pPriv-pPicture,
NULL,
@@ -484,33 +463,6 @@ miDCPutUpCursor (DeviceIntPtr pDev, ScreenPtr pScreen, CursorPtr pCursor,
else
#endif
{
-/**
- * XXX: Before MPX, the sourceGC and maskGC were attached to the
- * screen, and would switch as the screen switches. With mpx we have
- * the GC's attached to the device now, so each time we switch screen
- * we need to make sure the GC's are allocated on the new
Re: [PATCH] mi: fix software cursor with several X screens
Now with a proper GC cleanup sequence instead of freeing the same GC in a loop.
Thanks,
- Pierre-Loup
On 04/06/2010 02:44 PM, Pierre-Loup A. Griffais wrote:
(disregard previous message sent too soon)
Attached is a tentative patch that cleans that particular code up and fixes the
issue.
It would seem cleaner to perform the screen looping in ActivateDevice(), but
that would also mean changing miPointerDeviceInitialize and
miSpriteDeviceCursorInitialize to only perform their own setup once in that
case. Opinions?
Thanks,
- Pierre-Loup
On 04/06/2010 08:20 AM, Tiago Vignatti wrote:
On Tue, Apr 06, 2010 at 03:52:07AM +0200, ext Pierre-Loup A. Griffais wrote:
The DC code is broken for setups with several screens. Devs only have one pSave
pixmap and there's no code to thrash them like p[Save|Restore]GC.
That means if you have two X screens and force SW cursor on both, the server
will end up passing a bunch of CopyAreas with mismatching screens to the driver,
which can fail horribly if the driver does a good job abstracting screens away
from each other.
If helps you, I can confirm this happening here also.
Tiago
From e7c5552be9cc217866ea7362c44884baa2964d85 Mon Sep 17 00:00:00 2001
From: Pierre-Loup A. Griffais pgriff...@nvidia.com
Date: Tue, 6 Apr 2010 15:30:30 -0700
Subject: [PATCH] [PATCH] mi: don't thrash resources when displaying the software cursor across screens
This changes the DC layer to maintain a persistent set of GCs/pixmaps/pictures
for each pScreen instead of failing to thrash between them when changing
screens.
Signed-off-by: Pierre-Loup A. Griffais pgriff...@nvidia.com
---
mi/midispcur.c | 263 +++-
1 files changed, 108 insertions(+), 155 deletions(-)
diff --git a/mi/midispcur.c b/mi/midispcur.c
index 3fb7e02..7d8f876 100644
--- a/mi/midispcur.c
+++ b/mi/midispcur.c
@@ -59,9 +59,9 @@ static DevPrivateKey miDCScreenKey = miDCScreenKeyIndex;
static Bool miDCCloseScreen(int index, ScreenPtr pScreen);
-/* per device private data */
-static int miDCSpriteKeyIndex;
-static DevPrivateKey miDCSpriteKey = miDCSpriteKeyIndex;
+/* per device per-screen private data */
+static int miDCSpriteKeyIndex[MAXSCREENS];
+static DevPrivateKey miDCSpriteKey = miDCSpriteKeyIndex;
typedef struct {
GCPtr pSourceGC, pMaskGC;
@@ -77,8 +77,8 @@ typedef struct {
#define MIDCBUFFER(dev) \
((DevHasCursor(dev)) ? \
- (miDCBufferPtr)dixLookupPrivate(dev-devPrivates, miDCSpriteKey) : \
- (miDCBufferPtr)dixLookupPrivate(dev-u.master-devPrivates, miDCSpriteKey))
+ (miDCBufferPtr)dixLookupPrivate(dev-devPrivates, miDCSpriteKey + (pScreen)-myNum) : \
+ (miDCBufferPtr)dixLookupPrivate(dev-u.master-devPrivates, miDCSpriteKey + (pScreen)-myNum))
/*
* The core pointer buffer will point to the index of the virtual core pointer
@@ -158,10 +158,6 @@ miDCInitialize (ScreenPtr pScreen, miPointerScreenFuncPtr screenFuncs)
return TRUE;
}
-#define tossGC(gc) (gc ? FreeGC (gc, (GContext) 0) : 0)
-#define tossPix(pix) (pix ? (*pScreen-DestroyPixmap) (pix) : TRUE)
-#define tossPict(pict) (pict ? FreePicture (pict, 0) : 0)
-
static Bool
miDCCloseScreen (int index, ScreenPtr pScreen)
{
@@ -183,7 +179,6 @@ miDCRealizeCursor (ScreenPtr pScreen, CursorPtr pCursor)
}
#ifdef ARGB_CURSOR
-#define EnsurePicture(picture,draw,win) (picture || miDCMakePicture(picture,draw,win))
static VisualPtr
miDCGetWindowVisual (WindowPtr pWin)
@@ -415,12 +410,8 @@ miDCPutBits (
(*maskGC-ops-PushPixels) (maskGC, pPriv-maskBits, pDrawable, w, h, x, y);
}
-#define EnsureGC(gc,win) (gc || miDCMakeGC(gc, win))
-
static GCPtr
-miDCMakeGC(
-GCPtr *ppGC,
-WindowPtr pWin)
+miDCMakeGC(ScreenPtr pScreen)
{
GCPtr pGC;
int status;
@@ -428,10 +419,9 @@ miDCMakeGC(
gcvals[0] = IncludeInferiors;
gcvals[1] = FALSE;
-pGC = CreateGC((DrawablePtr)pWin,
+pGC = CreateGC((DrawablePtr)WindowTable[pScreen-myNum],
GCSubwindowMode|GCGraphicsExposures, gcvals, status,
(XID)0, serverClient);
-*ppGC = pGC;
return pGC;
}
@@ -461,17 +451,6 @@ miDCPutUpCursor (DeviceIntPtr pDev, ScreenPtr pScreen, CursorPtr pCursor,
#ifdef ARGB_CURSOR
if (pPriv-pPicture)
{
-/* see comment in miDCPutUpCursor */
-if (pBuffer-pRootPicture
-pBuffer-pRootPicture-pDrawable
-pBuffer-pRootPicture-pDrawable-pScreen != pScreen)
-{
-tossPict(pBuffer-pRootPicture);
-pBuffer-pRootPicture = NULL;
-}
-
- if (!EnsurePicture(pBuffer-pRootPicture, pWin-drawable, pWin))
- return FALSE;
CompositePicture (PictOpOver,
pPriv-pPicture,
NULL,
@@ -484,33 +463,6 @@ miDCPutUpCursor (DeviceIntPtr pDev, ScreenPtr pScreen, CursorPtr pCursor,
else
#endif
{
-/**
- * XXX: Before MPX, the sourceGC and maskGC were attached to the
- * screen, and would switch as the screen
Software cursor broken with several X screens
The DC code is broken for setups with several screens. Devs only have one pSave pixmap and there's no code to thrash them like p[Save|Restore]GC. That means if you have two X screens and force SW cursor on both, the server will end up passing a bunch of CopyAreas with mismatching screens to the driver, which can fail horribly if the driver does a good job abstracting screens away from each other. The GC thrashing code looks a bit clunky in the first place. Can we just have an array with numScreens elements for the per-device GCs and pixmaps? Thanks, - Pierre-Loup ___ 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 xfree86] Don't keep a pointer to a possibly freed cursor when changing screens, preventing a crash in xf86CursorEnableDisableFBAccess() trying to restore it.
Signed-off-by: Pierre-Loup A. Griffais pgriff...@nvidia.com --- hw/xfree86/ramdac/xf86Cursor.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/xfree86/ramdac/xf86Cursor.c b/hw/xfree86/ramdac/xf86Cursor.c index 7f23d9e..f5f0873 100644 --- a/hw/xfree86/ramdac/xf86Cursor.c +++ b/hw/xfree86/ramdac/xf86Cursor.c @@ -312,6 +312,7 @@ xf86CursorSetCursor(DeviceIntPtr pDev, ScreenPtr pScreen, CursorPtr pCurs, xf86SetCursor(pScreen, NullCursor, x, y); ScreenPriv-isUp = FALSE; } +ScreenPriv-CurrentCursor = NullCursor; return; } -- 1.7.0 --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ 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] Fix source pictures getting random transforms after 2d6a8f668342a5190cdf43b5.
Signed-off-by: Pierre-Loup A. Griffais pgriff...@nvidia.com Reviewed-by: Aaron Plattner aplatt...@nvidia.com --- fb/fbpict.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/fb/fbpict.c b/fb/fbpict.c index f9f4343..c046bae 100644 --- a/fb/fbpict.c +++ b/fb/fbpict.c @@ -453,6 +453,7 @@ image_from_pict_18 (PicturePtr pict, Bool has_clip, int *xoff, int *yoff) else if (sp-type == SourcePictTypeConical) image = create_conical_gradient_image (gradient); } + *xoff = *yoff = 0; } if (image) -- 1.6.3.3 ___ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Let the server expose 10bpc picture formats
PICT_a2b10g10r10, PICT_x2b10g10r10, and their newly-added RGB
equivalents aren't currently available for clients to use. Does that
patch seem reasonable?
---
render/picture.c | 11 +++
render/picture.h |5 +
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/render/picture.c b/render/picture.c
index 5f86c7c..71230a2 100644
--- a/render/picture.c
+++ b/render/picture.c
@@ -311,6 +311,17 @@ PictureCreateDefaultFormats (ScreenPtr pScreen, int
*nformatp)
nformats = addFormat (formats, nformats,
PICT_x8b8g8r8, pDepth-depth);
}
+ if (pDepth-depth = 30)
+ {
+ nformats = addFormat (formats, nformats,
+ PICT_a2r10g10b10, pDepth-depth);
+ nformats = addFormat (formats, nformats,
+ PICT_x2r10g10b10, pDepth-depth);
+ nformats = addFormat (formats, nformats,
+ PICT_a2b10g10r10, pDepth-depth);
+ nformats = addFormat (formats, nformats,
+ PICT_x2b10g10r10, pDepth-depth);
+ }
break;
}
}
diff --git a/render/picture.h b/render/picture.h
index 1f90f43..f3fec0b 100644
--- a/render/picture.h
+++ b/render/picture.h
@@ -67,6 +67,11 @@ typedef struct _Picture *PicturePtr;
/* 32bpp formats */
typedef enum _PictFormatShort {
+PICT_a2r10g10b10 = PIXMAN_a2r10g10b10,
+PICT_x2r10g10b10 = PIXMAN_x2r10g10b10,
+PICT_a2b10g10r10 = PIXMAN_a2b10g10r10,
+PICT_x2b10g10r10 = PIXMAN_x2b10g10r10,
+
PICT_a8r8g8b8 =PIXMAN_a8r8g8b8,
PICT_x8r8g8b8 =PIXMAN_x8r8g8b8,
PICT_a8b8g8r8 =PIXMAN_a8b8g8r8,
--
1.6.0.4
---
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
---
From 7495d36d1e9fd0ddfaa868c7628486591cac3f50 Mon Sep 17 00:00:00 2001
From: Pierre-Loup A. Griffais pgriff...@nvidia.com
Date: Mon, 27 Jul 2009 20:58:44 +0200
Subject: [PATCH] Add 4 missing 10bpc picture formats to the server format list.
---
render/picture.c | 11 +++
render/picture.h |5 +
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/render/picture.c b/render/picture.c
index 5f86c7c..71230a2 100644
--- a/render/picture.c
+++ b/render/picture.c
@@ -311,6 +311,17 @@ PictureCreateDefaultFormats (ScreenPtr pScreen, int *nformatp)
nformats = addFormat (formats, nformats,
PICT_x8b8g8r8, pDepth-depth);
}
+ if (pDepth-depth = 30)
+ {
+ nformats = addFormat (formats, nformats,
+ PICT_a2r10g10b10, pDepth-depth);
+ nformats = addFormat (formats, nformats,
+ PICT_x2r10g10b10, pDepth-depth);
+ nformats = addFormat (formats, nformats,
+ PICT_a2b10g10r10, pDepth-depth);
+ nformats = addFormat (formats, nformats,
+ PICT_x2b10g10r10, pDepth-depth);
+ }
break;
}
}
diff --git a/render/picture.h b/render/picture.h
index 1f90f43..f3fec0b 100644
--- a/render/picture.h
+++ b/render/picture.h
@@ -67,6 +67,11 @@ typedef struct _Picture *PicturePtr;
/* 32bpp formats */
typedef enum _PictFormatShort {
+PICT_a2r10g10b10 = PIXMAN_a2r10g10b10,
+PICT_x2r10g10b10 = PIXMAN_x2r10g10b10,
+PICT_a2b10g10r10 = PIXMAN_a2b10g10r10,
+PICT_x2b10g10r10 = PIXMAN_x2b10g10r10,
+
PICT_a8r8g8b8 = PIXMAN_a8r8g8b8,
PICT_x8r8g8b8 = PIXMAN_x8r8g8b8,
PICT_a8b8g8r8 = PIXMAN_a8b8g8r8,
--
1.6.0.4
___
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
