Re: A couple of composite fixes from Owen Taylor
On Thu, Sep 18, 2008 at 9:22 PM, Keith Packard [EMAIL PROTECTED] wrote: Owen Taylor has been poking at Composite for a while now and has helped uncover a couple of interesting corner cases. Here are two patches, the first is a correctness patch which fixes parent clip recomputation when windows move from automatic to manual redirection. The second is an optimization to eliminate descendent exposures on parent resize. -- [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg Is there a reason why you didn't commit these patches? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: A couple of composite fixes from Owen Taylor
On Fri, Sep 19, 2008 at 7:44 PM, Owen Taylor [EMAIL PROTECTED] wrote: On Fri, 2008-09-19 at 09:06 -0700, Keith Packard wrote: On Fri, 2008-09-19 at 17:11 +0200, Maarten Maathuis wrote: Is there a reason why you didn't commit these patches? Owen hasn't tested the second patch yet. Also, it's nice to see if anyone has comments on the patch before they hit master. I've tested both patches and they work well as far as I can tell. (Of course, proving that they don't cause obscure problems elsewhere is a lot harder than proving that they fix the problems they were designed to fix.) Also, they make sense to me as patches. I guess I might quibble with the comment in the second one which makes it sounds like this has to do with exotic guffaw scrolling manipulations or something. /* No matter what happened to the parent window bits because of window * and bit gravity, the bits of redirected children are not affected * so no exposures are needed */ ? - Owen If keithp wrote that comment, than perhaps he could improve the comment, because it's not very obvious to me what window gravity does. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [EXA PATCH] prefer intermediate surface for triangle/trapezoid/addtraps when destination is offscreen
On Sat, Sep 20, 2008 at 11:25 AM, Michel Dänzer [EMAIL PROTECTED] wrote: On Fri, 2008-09-19 at 22:47 +0200, Maarten Maathuis wrote: On Fri, Sep 19, 2008 at 10:41 PM, Maarten Maathuis [EMAIL PROTECTED] wrote: In my experience UploadToScreen is faster than DownloadFromScreen, so it seems prudent to give this software rendered operation a reasonable chance should someone use an existing (offscreen) mask. Let me know what you think. Maarten. After posting i noticed a rather big mistake (one of the offsets to fbAddTraps was wrong). So here is a new version. Do you have any before/after numbers for this? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [EXA PATCH] prefer intermediate surface for triangle/trapezoid/addtraps when destination is offscreen
On Sat, Sep 20, 2008 at 11:28 AM, Maarten Maathuis [EMAIL PROTECTED] wrote: On Sat, Sep 20, 2008 at 11:25 AM, Michel Dänzer [EMAIL PROTECTED] wrote: On Fri, 2008-09-19 at 22:47 +0200, Maarten Maathuis wrote: On Fri, Sep 19, 2008 at 10:41 PM, Maarten Maathuis [EMAIL PROTECTED] wrote: In my experience UploadToScreen is faster than DownloadFromScreen, so it seems prudent to give this software rendered operation a reasonable chance should someone use an existing (offscreen) mask. Let me know what you think. Maarten. After posting i noticed a rather big mistake (one of the offsets to fbAddTraps was wrong). So here is a new version. Do you have any before/after numbers for this? -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer That empty message was unintentional. This patch was made when i was under the impression that someone was hitting this problem. Now i realize it is something else that is causing serious issues. I still stand by the patch, because i do believe an additional composite operation is far cheaper than falling back. That said, i'll try putting together a testcase in the forseeable future. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Optimization idea: soft XvPutImage
On Sun, Sep 21, 2008 at 11:10 AM, Adam Richter [EMAIL PROTECTED] wrote: On Fri, 9/19/08, Soeren Sandmann [EMAIL PROTECTED] wrote: Adam Richter [EMAIL PROTECTED] writes: I want to suggest a way we could eliminate a substantial amount of data copying [...] [...] Pixman, the software implementation of XRender already has support for YUV formats, so all that is really required is to just export YUV picture formats through the XRender protocol. [...] Thank you for pointing out that pixman has some limited YUV reading support already. The biggest problem that I see with using the X Render is that it lacks stretch and shrink, at least if I understand correctly from looking at the protocol specification here: http://gitweb.freedesktop.org/?p=xorg/proto/renderproto.git;a=blob_plain;f=renderproto.txt See lines 758-766: Composite op: PICTOP src:PICTURE mask: PICTURE or None dst:PICTURE src-x, src-y: INT16 mask-x, mask-y: INT16 dst-x, dst-y: INT16 width, height: CARD16 The last two parameters (width and height) presumably apply to both source and destination rather than having separate parameters for the source and destination rectangles. This also appears to be the case when I look in the header for the pixman library (pixman-0.12/pixman/pixman.h) at the declaration of pixman_blt. It also only has a width and height, which presumably apply to both source and destination. Even if you do not want to do stretch, I believe that the X Render extension would require first copying the YUV data to a drawable and then doing a drawable-drawable block transfer operation to do the YUV transformation. In comparison, XvPutImage is a single call takes an XImage, which can be in shared memory, and would normally be in YUV, and specifies the YUV-RGB conversion and stretch in a single operation. Thanks for your input, especially the tip about some YUV support already existing in libpixman. Adam Richter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg Src and Mask pictures have a transform, which can translate and rotate coordinates as you please. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xorg-server-1.5.1 still sluggish
On Fri, Oct 3, 2008 at 4:30 PM, Markus Strobl [EMAIL PROTECTED] wrote: A few weeks ago there were some messages about 1.5.0 being sluggish (1-2 second pauses when switching tabs in firefox, delays in menus appearing etc). It looked like the cause was identified and tracked to a patch. I just tried 1.5.1 and the problem is still there so was just wondering what happened to the fix. Will it be part of 1.5.2 or should I file a bug report? Thanks, Markus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg If you're referring to the shm pixmap issue in combination with exa, then that made it in for 1.5.1. http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.5-branchid=ce6424853c2df2486ad99c0369974afc91a92993 Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xorg-server-1.5.1 still sluggish
On Sat, Oct 4, 2008 at 2:12 AM, Markus Strobl [EMAIL PROTECTED] wrote: Maarten Maathuis wrote: On Fri, Oct 3, 2008 at 5:50 PM, Markus Strobl [EMAIL PROTECTED] wrote: If you're referring to the shm pixmap issue in combination with exa, then that made it in for 1.5.1. http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.5-branchid=ce6424853c2df2486ad99c0369974afc91a92993 Maarten. Yep, that's the one. But the problem is still there. The pauses/freezes are so annoying I had to switch back to 1.4.2. Even just moving a window will freeze every second for a 1 second. Markus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg Is this just with firefox (or other mozilla apps)? Thunderbird is even worse. It took about 5 seconds to paint the reply window I'm typing this in, getting painted in section. Empty rectangle, then borders, then buttons, then text panes, etc. /Markus I meant, do non-mozilla applications also show this problem? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] [pixmap] rename/convert devKind and devPrivate fields
On Tue, Oct 7, 2008 at 10:09 PM, Aaron Plattner [EMAIL PROTECTED] wrote: On Tue, Oct 07, 2008 at 08:04:52PM +0200, Maarten Maathuis wrote: These names are supposedly historical, but everyone seems to use them for the same purpose. I am aware this may require a few minor changes to (for example) exa drivers with driver based memory allocations. I personally believe in having clear names rather than some obscure remnant of the past. I removed the devPrivate considering the void pointer is the only useful part anyway. It would be nice to know if all !xfree86 has the equivilant of VIDEODRV_ABI_VERSION. Anyway, share your thoughts, comments and such. It seems unfortunate to break the API just to rename a few fields. While I can understand wanting to make the naming clearer, if we're going to change the API can we please strive to make it better, rather than just different? -- Aaron Anything particular you have in mind? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] [pixmap] rename/convert devKind and devPrivate fields
On Tue, Oct 7, 2008 at 8:04 PM, Maarten Maathuis [EMAIL PROTECTED] wrote: These names are supposedly historical, but everyone seems to use them for the same purpose. I am aware this may require a few minor changes to (for example) exa drivers with driver based memory allocations. I personally believe in having clear names rather than some obscure remnant of the past. I removed the devPrivate considering the void pointer is the only useful part anyway. It would be nice to know if all !xfree86 has the equivilant of VIDEODRV_ABI_VERSION. Anyway, share your thoughts, comments and such. Maarten. PS. i can commit these myself, this is just for review, considering it's a non-trivial change. Any thoughts about other stuff needing change in the pixmap (or maybe the closely related drawable)? I'm openminded to change, so it seems sensible to check if there are any other problems out there. Without any further complaints i'll probably go ahead with this in a few days. Maarten ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: ProcPutImage calls exaDoMoveOutPixmap, 4x slowdown
On Tue, Oct 14, 2008 at 7:35 PM, Clemens Eisserer [EMAIL PROTECTED] wrote: Hi, There is ofcource a fallback system, which is pretty much a memcpy. Ah, I guess that was that memcpy I always saw in moveIn / moveOut ;) intel has never had an UploadToScreen hook. Ah interesting, because I saw 4x better performance with intel-2.1.1 / xserver-1.3. With this configuration the putted data was just memcpy'd to vram, but now it seems to be a readback-put-upload cycle :-/ I'll try to find a small test-case and report a bug. I'm just mentioning uxa, because they did realize exa wasn't perfect for them (in it's current form), they just haven't fixed exa yet to be a little more smart for non-vram cards. Yes, I also really hope they merge it back soon. Thanks again, Clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg 2.1.1 probably used XAA as default, which didn't try to accelerate much. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: ProcPutImage calls exaDoMoveOutPixmap, 4x slowdown
On Wed, Oct 15, 2008 at 9:43 PM, Eric Anholt [EMAIL PROTECTED] wrote:
On Tue, 2008-10-14 at 16:49 +0200, Maarten Maathuis wrote:
On Tue, Oct 14, 2008 at 4:02 PM, Clemens Eisserer [EMAIL PROTECTED] wrote:
Hello,
I've a use-case where the client uploads 32x32 A8 images to an
256x256x8 pixmap which is later used as mask in a composition
operation.
The test-case is able to render with 40fps on xserver-1.3/intel-2.1.1
however with the latest GIT of both I only get ~10-15fps.
Unfourtunatly I've not been able to create a stand-alone testcase
which triggers this problem :-/
Using sysprof I can see a lot of time is spent moving data arround,
very strange is that PutImage seems to cause a readback:
ProcPutImage-ExaCheckPutImage-exaPrepareAccessReg-exaDoMigration-exaDoMoveOutPixmap-exaCopyDirty-exaWaitSync-I830EXASync
In Composite I see the re-uploading again.
Any idea why ProcPutImage could to fallback (there's plenty of free vram)?
Are there tools / settings which could help me to identify the problem?
Thank you in advance, Clemens
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
I think this is because intel does not provide an UploadToScreen hook
(because it has no vram). It hasn't made (visible) effort to
reintegrate UXA in EXA, because you can obviously be bit smarter than
what is currently being done. I've got an idea or two on how to
improve this, but intel should be more than capable in dealing with
this.
Migrating out for a write-only operation is just broken, and is the
thing that should be fixed there.
--
Eric Anholt
[EMAIL PROTECTED] [EMAIL PROTECTED]
I'd like to add that if anything changes in this beheaviour, then this
shouldn't be done quietly. Because some may depend on this (offscreen
memory tiled and needing migration to have something linear available
for example). The current {Prepare,Finish}Access isn't completely
suited for this conversion (exaPixmapIsOffscreen() isn't exported).
Just my 3 cent.
Maarten.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: ProcPutImage calls exaDoMoveOutPixmap, 4x slowdown
On Thu, Oct 16, 2008 at 5:02 PM, Michel Dänzer
[EMAIL PROTECTED] wrote:
On Wed, 2008-10-15 at 21:59 +0200, Maarten Maathuis wrote:
On Wed, Oct 15, 2008 at 9:43 PM, Eric Anholt [EMAIL PROTECTED] wrote:
Migrating out for a write-only operation is just broken, and is the
thing that should be fixed there.
There is no actual migration here, just superfluous syncing fixed by my
patch.
What makes you so sure, the standard thing to do on a fallback is migrate out.
I'd like to add that if anything changes in this beheaviour, then this
shouldn't be done quietly. Because some may depend on this (offscreen
memory tiled and needing migration to have something linear available
for example).
Sounds like something that could be handled in UploadToScreen.
I'm assuming a case where UTS and DFS do the conversion, but direct
cpu access is a bad idea. Fortunately exa *never* does this currently,
prepare access always triggers a migration out.
The current {Prepare,Finish}Access isn't completely
suited for this conversion (exaPixmapIsOffscreen() isn't exported).
FWIW, exporting exaPixmapIsOffscreen() might make sense anyway though.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is interpolation of image-border specified by Render?
On Sat, Oct 18, 2008 at 11:39 AM, Clemens Eisserer [EMAIL PROTECTED] wrote: Hi Maarten, Bilinear and nearest are standard texture unit properties, this should pose no difficulty for drivers. Good to know, thanks. I was a bit concerned when mixing both with src and mask. As far as the mask goes, nearest should guarantee a sharp border. I'd expect things to go ok with the size if you keep in mind it's fixed point transformation, but i'm not a 100% sure. Well, it seems to work perfectly with pixman, I don't see any problems over a very large scale range. However, when using the intel-driver I soon seem to hit precision limits, it works only in a very limited scale range. I also thought that I maybe could use the fact that clip-rects are transformed when set on source (to not having to fillRect the mask all then time), but this doesn't work with any driver I tried (nouveau, intel, nvidia binary). Seems I have to go the fillRect route and tile of the mask is too small :-/ Thanks again, Clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg Do you have a test program or at least share the transformation matrix you're using, because i'm curious why it fails so badly. Have you tried using a 1x1 mask pixel and scaling that an integer amount? Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is interpolation of image-border specified by Render?
On Sat, Oct 18, 2008 at 12:35 PM, Clemens Eisserer [EMAIL PROTECTED] wrote: Hi Maarten, Do you have a test program or at least share the transformation matrix you're using, because i'm curious why it fails so badly. Yes I created one, http://pastebin.com/f729a71aa The testcase works perfectly with pixman (even with much higher scale), but on intel seems the mask has too small x/y values. Would be really interesting how other hardware/drivers behave ;) Have you tried using a 1x1 mask pixel and scaling that an integer amount? I used a 16x16 mask ... just without any further thinking, thought it would give me more headroom till I hit precision limits. I've now tried it with a 1x1 mask (as in the attached testcase), its the same. It seems only to work when mask is 0.75-1.5 of the size of the source, otherwise the pixel-borders differ :-/ Thanks, Clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg Where do these transformation matrices come from? Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is interpolation of image-border specified by Render?
On Sat, Oct 18, 2008 at 12:52 PM, Clemens Eisserer [EMAIL PROTECTED] wrote: Where do these transformation matrices come from? They were created by the Java AffineTransform class. I just dumped it and copied it into the C file. I basically get an AffineTransformation instance (set by the user), inverse it and set it on the source. For the mask I do exactly the same, except I scale it up, by the needed amount. - Clemens ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg What are the precise artifacts you see? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] candidate patches for server-1.5-branch inclusion
On Fri, Oct 24, 2008 at 5:57 PM, Rémi Cardona [EMAIL PROTECTED] wrote: Hi all, Here's a branch with all the patches that we currently plan on shipping in Gentoo. http://www.lri.fr/~cardona/git/xserver.git (server-1.5-branch) The first 37 patches are backports from git master, basically all the patches that touched exa/ since the branching for 1.5. Only a few got thrown out : - those that only touched shmPutImage() and friends - the patch that modifies the devPrivates With this branch, git diff --stat server-1.5-branch..master exa/ reports only 4 insertions and 2 deletions. It also includes a backport of a build fix, and another patch that fixes a build issue with KDrive's Xvesa with newer kernels. If accepted, this one should be applied to master as well. This branch builds and runs successfully (so far at least) and our test users can confirm all the improvements brought by the glyphs cache. Thanks for considering it. Cheers -- Rémi Cardona LRI, INRIA [EMAIL PROTECTED] [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg I'd like to point the glyph cache isn't entirely bug free yet. https://bugs.freedesktop.org/show_bug.cgi?id=18065 Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] RandR 1.3 properties
On Tue, Oct 28, 2008 at 10:37 PM, Keith Packard [EMAIL PROTECTED] wrote: On Tue, 2008-10-28 at 19:51 +0100, Matthias Hopf wrote: - Apparently there are only 8, 16, and 32bit integers available as property types. Having ATOMs and FLOATs would add semantics, which could help in some cases. But if this implies some changes throughout the system, I don't think this is helpful. If it's basically xrandr, it would be easy. ATOMs are obviously supported, but FLOATs seem harder as they aren't described in the core protocol anywhere. - Is RANDR_BANDWIDTH helpful? Or should we have a dedicated property for indicating dual link capability on DVI? What other meta information (also on other connections) would be useful? I think it would be better to just indicate that this is a dual-link connector. - Should RANDR_CONNECTOR_TYPE be made mandatory? If a driver *really* doesn't want to implement anything here, it could always set this to '0' and be done. Yes, we should make several of these required. I'm wondering how well we can do in automatically setting these from BIOS properties in the Intel driver though. For the TV signalling type, I think we'll need more options; PAL has a lot of variants that we'll want to expose. I'm also thinking we want to expose a separate TV signalling property and leave the general property as 'TV' or some such. - Panning - Keith indicated pretty strongly that this should be part of the protocol level, and not a property. Haven't dealt with that yet, it's still in the diff. Yeah, we'll need stacks of code to manage this property, so it's not just informational like most of the other properties. - So far we didn't have standard properties, and no RANDR_ prefix. EDID_DATA had been around since 1.2, should that be renamed to RANDR_EDID_DATA (as indidcated in the draft), be left alone (and the whole RANDR_ prefix idea burried), or cloned? I'd say that we should feel free to take over the unprefixed name space, but that we should explicitly call out property names starting with '_' as non-standard properties. -- [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg Is there any chance to get rid of strings in the protocol/server altogether and stick to standardised names and properties (in the form of enums) as much as possible? It would improve consistency for the standard stuff a lot. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
gtkperf freeze, a backtrace, and not sure what to file the bug against.
Based on the backtrace there are several things that could cause this. xcb, xrender and cairo are amongst the first that come to mind. This happens on the GtkDrawingArea - Text test only. Any idea who i should poke? Maarten. #0 0x7fc6f74826e3 in __select_nocancel () from /lib/libc.so.6 #1 0x7fc6f491d9c4 in _xcb_conn_wait () from /usr/lib/libxcb.so.1 #2 0x7fc6f491f327 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1 #3 0x7fc6f6f008c8 in _XReply () from /usr/lib/libX11.so.6 #4 0x7fc6f6efb38f in _XSeqSyncFunction () from /usr/lib/libX11.so.6 #5 0x7fc6f5351989 in XRenderFillRectangles () from /usr/lib/libXrender.so.1 #6 0x7fc6f6981275 in _cairo_xlib_surface_fill_rectangles () from /usr/lib/libcairo.so.2 #7 0x7fc6f696ce3b in _cairo_surface_fill_rectangles () from /usr/lib/libcairo.so.2 #8 0x7fc6f696cfad in _cairo_surface_fill_region () from /usr/lib/libcairo.so.2 #9 0x7fc6f696ed06 in _clip_and_composite_trapezoids () from /usr/lib/libcairo.so.2 #10 0x7fc6f696f3e8 in _cairo_surface_fallback_paint () from /usr/lib/libcairo.so.2 #11 0x7fc6f696cd82 in _cairo_surface_paint () from /usr/lib/libcairo.so.2 #12 0x7fc6f696db28 in _cairo_surface_create_similar_solid () from /usr/lib/libcairo.so.2 #13 0x7fc6f6965608 in _cairo_pattern_acquire_surface_for_solid () from /usr/lib/libcairo.so.2 #14 0x7fc6f696609e in _cairo_pattern_acquire_surface () from /usr/lib/libcairo.so.2 #15 0x7fc6f697f5ee in _cairo_xlib_surface_show_glyphs () from /usr/lib/libcairo.so.2 #16 0x7fc6f696c19d in _cairo_surface_show_text_glyphs () from /usr/lib/libcairo.so.2 #17 0x7fc6f695a6b1 in _cairo_gstate_show_text_glyphs () from /usr/lib/libcairo.so.2 #18 0x7fc6f6956091 in cairo_show_glyphs () from /usr/lib/libcairo.so.2 #19 0x7fc6f71b4c73 in pango_cairo_renderer_show_text_glyphs () from /usr/lib/libpangocairo-1.0.so.0 #20 0x7fc6f71b4ed3 in pango_cairo_renderer_draw_glyphs () from /usr/lib/libpangocairo-1.0.so.0 #21 0x7fc6f7c31eec in pango_renderer_draw_glyphs () from /usr/lib/libpango-1.0.so.0 #22 0x7fc6f71b3cb2 in _pango_cairo_do_glyph_string () from /usr/lib/libpangocairo-1.0.so.0 #23 0x7fc6f7c31eec in pango_renderer_draw_glyphs () from /usr/lib/libpango-1.0.so.0 #24 0x7fc6f7c31e71 in pango_renderer_draw_glyph_item () from /usr/lib/libpango-1.0.so.0 #25 0x7fc6f7c323bb in pango_renderer_draw_layout_line () from /usr/lib/libpango-1.0.so.0 #26 0x7fc6f7c32800 in pango_renderer_draw_layout () from /usr/lib/libpango-1.0.so.0 #27 0x7fc6f80952d7 in gdk_draw_layout_with_colors () from /usr/lib/libgdk-x11-2.0.so.0 #28 0x7fc6f809547f in gdk_draw_layout () from /usr/lib/libgdk-x11-2.0.so.0 #29 0x00407ccc in on_idle_gtkdrawingarea_text_test () #30 0x7fc6f773f5f4 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #31 0x7fc6f77415e0 in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0 #32 0x7fc6f7742410 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #33 0x7fc6f8652d27 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #34 0x0040459c in main () ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: gtkperf freeze, a backtrace, and not sure what to file the bug against.
On Sun, Nov 2, 2008 at 3:50 AM, Maarten Maathuis [EMAIL PROTECTED] wrote: Based on the backtrace there are several things that could cause this. xcb, xrender and cairo are amongst the first that come to mind. This happens on the GtkDrawingArea - Text test only. Any idea who i should poke? Maarten. #0 0x7fc6f74826e3 in __select_nocancel () from /lib/libc.so.6 #1 0x7fc6f491d9c4 in _xcb_conn_wait () from /usr/lib/libxcb.so.1 #2 0x7fc6f491f327 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1 #3 0x7fc6f6f008c8 in _XReply () from /usr/lib/libX11.so.6 #4 0x7fc6f6efb38f in _XSeqSyncFunction () from /usr/lib/libX11.so.6 #5 0x7fc6f5351989 in XRenderFillRectangles () from /usr/lib/libXrender.so.1 #6 0x7fc6f6981275 in _cairo_xlib_surface_fill_rectangles () from /usr/lib/libcairo.so.2 #7 0x7fc6f696ce3b in _cairo_surface_fill_rectangles () from /usr/lib/libcairo.so.2 #8 0x7fc6f696cfad in _cairo_surface_fill_region () from /usr/lib/libcairo.so.2 #9 0x7fc6f696ed06 in _clip_and_composite_trapezoids () from /usr/lib/libcairo.so.2 #10 0x7fc6f696f3e8 in _cairo_surface_fallback_paint () from /usr/lib/libcairo.so.2 #11 0x7fc6f696cd82 in _cairo_surface_paint () from /usr/lib/libcairo.so.2 #12 0x7fc6f696db28 in _cairo_surface_create_similar_solid () from /usr/lib/libcairo.so.2 #13 0x7fc6f6965608 in _cairo_pattern_acquire_surface_for_solid () from /usr/lib/libcairo.so.2 #14 0x7fc6f696609e in _cairo_pattern_acquire_surface () from /usr/lib/libcairo.so.2 #15 0x7fc6f697f5ee in _cairo_xlib_surface_show_glyphs () from /usr/lib/libcairo.so.2 #16 0x7fc6f696c19d in _cairo_surface_show_text_glyphs () from /usr/lib/libcairo.so.2 #17 0x7fc6f695a6b1 in _cairo_gstate_show_text_glyphs () from /usr/lib/libcairo.so.2 #18 0x7fc6f6956091 in cairo_show_glyphs () from /usr/lib/libcairo.so.2 #19 0x7fc6f71b4c73 in pango_cairo_renderer_show_text_glyphs () from /usr/lib/libpangocairo-1.0.so.0 #20 0x7fc6f71b4ed3 in pango_cairo_renderer_draw_glyphs () from /usr/lib/libpangocairo-1.0.so.0 #21 0x7fc6f7c31eec in pango_renderer_draw_glyphs () from /usr/lib/libpango-1.0.so.0 #22 0x7fc6f71b3cb2 in _pango_cairo_do_glyph_string () from /usr/lib/libpangocairo-1.0.so.0 #23 0x7fc6f7c31eec in pango_renderer_draw_glyphs () from /usr/lib/libpango-1.0.so.0 #24 0x7fc6f7c31e71 in pango_renderer_draw_glyph_item () from /usr/lib/libpango-1.0.so.0 #25 0x7fc6f7c323bb in pango_renderer_draw_layout_line () from /usr/lib/libpango-1.0.so.0 #26 0x7fc6f7c32800 in pango_renderer_draw_layout () from /usr/lib/libpango-1.0.so.0 #27 0x7fc6f80952d7 in gdk_draw_layout_with_colors () from /usr/lib/libgdk-x11-2.0.so.0 #28 0x7fc6f809547f in gdk_draw_layout () from /usr/lib/libgdk-x11-2.0.so.0 #29 0x00407ccc in on_idle_gtkdrawingarea_text_test () #30 0x7fc6f773f5f4 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #31 0x7fc6f77415e0 in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0 #32 0x7fc6f7742410 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #33 0x7fc6f8652d27 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #34 0x0040459c in main () I've determined it is related to xcb in combination with the so called handoff patches that were applied to it. I shall be taking this elsewhere. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] RandR 1.3 properties
On Fri, Nov 7, 2008 at 5:18 PM, Matthias Hopf [EMAIL PROTECTED] wrote: On Oct 28, 08 14:37:30 -0700, Keith Packard wrote: On Tue, 2008-10-28 at 19:51 +0100, Matthias Hopf wrote: - Apparently there are only 8, 16, and 32bit integers available as property types. Having ATOMs and FLOATs would add semantics, which could help in some cases. But if this implies some changes throughout the system, I don't think this is helpful. If it's basically xrandr, it would be easy. ATOMs are obviously supported, but FLOATs seem harder as they aren't described in the core protocol anywhere. Thinking about that, adding floats was probably a bull idea. However, having semantics about ATOMs might be helpful (e.g. for xrandr or any general purpose property setting tool). For the TV signalling type, I think we'll need more options; PAL has a lot of variants that we'll want to expose. I'm also thinking we want to expose a separate TV signalling property and leave the general property as 'TV' or some such. Reasonable. Thinking about that. Types of PAL are typically PAL-B, -G, -H, -I, -M, -D, -N, -Nc Similar for NTSC and SECAM. Any additional features? Actually, single link/dual link, number of DisplayPort links, etc. could be set in the same property. I'd make that a generic transition frequency and an the total number of links, unless there are connections that don't scale linearly in number of links. Adding this as SignalProperties. - Panning - Keith indicated pretty strongly that this should be part of the protocol level, and not a property. Haven't dealt with that yet, it's still in the diff. Yeah, we'll need stacks of code to manage this property, so it's not just informational like most of the other properties. Agreed. Thinking about that. Find a protocol suggestion in the next diff. Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] RandR 1.3 properties
On Fri, Nov 7, 2008 at 5:19 PM, Matthias Hopf [EMAIL PROTECTED] wrote: On Oct 28, 08 22:44:35 +0100, Maarten Maathuis wrote: Is there any chance to get rid of strings in the protocol/server altogether and stick to standardised names and properties (in the form of enums) as much as possible? Sounds reasonable to me. We should still stick to ATOMs to make this extensible, but for the standardized values we should have standardized ATOMs. Just to be clear, i was also referring to output names, which have a habit to be slightly different pretty much everywhere. Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] RandR 1.3 properties
On Fri, Nov 7, 2008 at 7:38 PM, Matthias Hopf [EMAIL PROTECTED] wrote: On Nov 07, 08 18:48:18 +0100, Maarten Maathuis wrote: On Fri, Nov 7, 2008 at 5:19 PM, Matthias Hopf [EMAIL PROTECTED] wrote: On Oct 28, 08 22:44:35 +0100, Maarten Maathuis wrote: Is there any chance to get rid of strings in the protocol/server altogether and stick to standardised names and properties (in the form of enums) as much as possible? Sounds reasonable to me. We should still stick to ATOMs to make this extensible, but for the standardized values we should have standardized ATOMs. Just to be clear, i was also referring to output names, which have a habit to be slightly different pretty much everywhere. I don't see that coming ATM. There are at least two different interpretations of what RandR outputs actually are, both with different pros and cons. We had a discussion on the radeonhd mailinglist whether to move to the interpretation used e.g. by radeon, but that would kill a few special cases, and consensus (well, that might be too strong a word, say 50%) was that we should stick with the current interpretation, with slightly less complicated names. Perhaps now would be the time to standardise on a beheaviour, my personal opinion is that, the user should see something that represents the connectors on the back of their computer. Anything else should become a property of that connector (since it's automatic in 99% of the cases). Was there any good reason in that discussion to do otherwise? Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] RandR 1.3 properties
On Fri, Nov 7, 2008 at 7:58 PM, Matthias Hopf [EMAIL PROTECTED] wrote: On Nov 07, 08 19:44:07 +0100, Maarten Maathuis wrote: Perhaps now would be the time to standardise on a beheaviour, my personal opinion is that, the user should see something that represents the connectors on the back of their computer. Anything else should become a property of that connector (since it's automatic in 99% of the cases). Was there any good reason in that discussion to do otherwise? The discussion was rather length and technical, but there are use cases where you want to drive the analog pins of e.g. and DVI-I connector differently from the digital pins. That's not possible if outputs and connectors are mapped 1:1. Overriding the encoder/output/whatever behind the connector is what i would put under a property. Unless you're referring to actually using both the analog and digital pins at the same time, which seems like a very strange situation (and what percentage of hardware would actually allow this?). Considering you've only got one set of ddc pins. But why do you insist on standardized names? As long as the names resemble something user can understand, the exact names shouldn't matter. Selecting outputs by properties (connector or signal type) might be something interesting for generalized scripts. Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] candidate patches for server-1.5-branch inclusion
On Fri, Oct 24, 2008 at 6:27 PM, Maarten Maathuis [EMAIL PROTECTED] wrote: On Fri, Oct 24, 2008 at 5:57 PM, Rémi Cardona [EMAIL PROTECTED] wrote: Hi all, Here's a branch with all the patches that we currently plan on shipping in Gentoo. http://www.lri.fr/~cardona/git/xserver.git (server-1.5-branch) The first 37 patches are backports from git master, basically all the patches that touched exa/ since the branching for 1.5. Only a few got thrown out : - those that only touched shmPutImage() and friends - the patch that modifies the devPrivates With this branch, git diff --stat server-1.5-branch..master exa/ reports only 4 insertions and 2 deletions. It also includes a backport of a build fix, and another patch that fixes a build issue with KDrive's Xvesa with newer kernels. If accepted, this one should be applied to master as well. This branch builds and runs successfully (so far at least) and our test users can confirm all the improvements brought by the glyphs cache. Thanks for considering it. Cheers -- Rémi Cardona LRI, INRIA [EMAIL PROTECTED] [EMAIL PROTECTED] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg I'd like to point the glyph cache isn't entirely bug free yet. https://bugs.freedesktop.org/show_bug.cgi?id=18065 Maarten. This commit fixed that issue: http://cgit.freedesktop.org/xorg/xserver/commit/?id=21c116219cd5c6845a0955f2d88fdb5fab5c17cf Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[IDEA] shrink xrender featureset
Currently there exist several operations in xrender that are better off client side or through some other graphic api (imo). Think of trapezoid rasterisation, gradient rendering, etc. Doing this stuff client side avoids unforseen migration issues and doesn't create any false impressions with the api users. My suggestion would be to deprecate everything, except solid, composite, cursor stuff and glyphs. The idea is to stop doing seemingly arbitrary graphics operations that end up causing slowness most of the time (if not worked around properly). At this stage noone accelerates these operations, so there can be no complaints about that. xrender is here to stay, but there are limits to it, so let's accept this and move on (for other needs). How do others feel about this? Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xserver git fails to build with xf86config enabled
The usefulness of it is debatable, i personally don't need it, just wanted to give a heads up. Maarten. libtool: link: ( cd .libs rm -f libxorg.la ln -s ../libxorg.la libxorg.la ) ../../doltlibtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include-I../../include -I../../include -I../../Xext -I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage -I../../render -I../../randr -I../../fb -fvisibility=hidden -DHAVE_XORG_CONFIG_H -fvisibility=hidden -DXF86PM -march=k8 -Os -pipe -msse3 -fno-omit-frame-pointer -rdynamic -Wl,-O1 -Wl,--as-needed -Wl,-z,lazy -o Xorg xorg.o libxorg.la -lpciaccess -ldl -ldl -lpthread -lXfont -lXau -lfontenc -lpixman-1 -lhal -ldbus-1 -lXdmcp -lssl -lcrypto -ldl-lm -lrt -lm -lrt libtool: link: x86_64-pc-linux-gnu-gcc -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I../../include -I../../include -I../../Xext -I../../composite -I../../damageext -I../../xfixes -I../../Xi -I../../mi -I../../miext/shadow -I../../miext/damage -I../../render -I../../randr -I../../fb -fvisibility=hidden -DHAVE_XORG_CONFIG_H -fvisibility=hidden -DXF86PM -march=k8 -Os -pipe -msse3 -fno-omit-frame-pointer -rdynamic -Wl,-O1 -Wl,--as-needed -Wl,-z -Wl,lazy -o .libs/Xorg xorg.o ./.libs/libxorg.a /var/tmp/portage/x11-base/xorg-server-/work/xorg-server-/hw/xfree86/parser/.libs/libxf86config.so /usr/lib64/libpciaccess.so -lpthread /usr/lib64/libXfont.so /usr/lib64/libfreetype.so /usr/lib64/libXau.so /usr/lib64/libfontenc.so -lz /usr/lib64/libpixman-1.so /usr/lib64/libhal.so /usr/lib64/libdbus-1.so /usr/lib64/libXdmcp.so -lssl -lcrypto -ldl -lm -lrt ./.libs/libxorg.a(xf86Config.o): In function `xf86ModulelistFromConfig': xf86Config.c:(.text+0x3596): undefined reference to `xf86addNewLoadDirective' xf86Config.c:(.text+0x36a3): undefined reference to `xf86addNewLoadDirective' ./.libs/libxorg.a(xf86Configure.o): In function `DoConfigure': xf86Configure.c:(.text+0xd34): undefined reference to `xf86freeMonitorList' xf86Configure.c:(.text+0xd4c): undefined reference to `xf86freeScreenList' collect2: ld returned 1 exit status make[4]: *** [Xorg] Error 1 make[4]: Leaving directory `/var/tmp/portage/x11-base/xorg-server-/work/xorg-server-/hw/xfree86' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/var/tmp/portage/x11-base/xorg-server-/work/xorg-server-/hw/xfree86' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/portage/x11-base/xorg-server-/work/xorg-server-/hw/xfree86' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/x11-base/xorg-server-/work/xorg-server-/hw' make: *** [all-recursive] Error 1 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCHES] improve gamma support for randr-1.2 drivers
These two patches should accomplish the following:
- Usage of Gamma in xorg.conf will be associated with an output and set
on the initial crtc.
(This should work as good as possible for clone modes, eg a non-1.0
gamma will not be overwritten with a standard value)
- Gamma is stored from preinit and between server generations.
- The old colourmap system will be disabled if gamma hook is available.
- xrandr can now set gamma.
My main question is, are there any xserver ABI's to bump due to the
changes to the xf86CrtcRec struct?
Maarten.
diff --git a/hw/xfree86/common/Makefile.am b/hw/xfree86/common/Makefile.am
index 01b9cf3..b562e66 100644
--- a/hw/xfree86/common/Makefile.am
+++ b/hw/xfree86/common/Makefile.am
@@ -42,7 +42,7 @@ INCLUDES = $(XORG_INCS) -I$(srcdir)/../ddc -I$(srcdir)/../i2c
\
-I$(srcdir)/../loader -I$(srcdir)/../rac -I$(srcdir)/../parser \
-I$(srcdir)/../vbe -I$(srcdir)/../int10 \
-I$(srcdir)/../vgahw -I$(srcdir)/../dixmods/extmod \
- -I$(srcdir)/../modes
+ -I$(srcdir)/../modes -I$(srcdir)/../ramdac
sdk_HEADERS = compiler.h fourcc.h xf86.h xf86Module.h xf86Opt.h \
xf86PciInfo.h xf86Priv.h xf86Privstr.h xf86Resources.h \
diff --git a/hw/xfree86/common/xf86Helper.c b/hw/xfree86/common/xf86Helper.c
index 0a66f80..78df060 100644
--- a/hw/xfree86/common/xf86Helper.c
+++ b/hw/xfree86/common/xf86Helper.c
@@ -60,6 +60,7 @@
#include mivalidate.h
#include xf86RAC.h
#include xf86Bus.h
+#include xf86Crtc.h
/* For xf86GetClocks */
#if defined(CSRG_BASED) || defined(__GNU__)
@@ -918,6 +919,11 @@ Bool
xf86SetGamma(ScrnInfoPtr scrp, Gamma gamma)
{
MessageType from = X_DEFAULT;
+/* Pretend we succeeded if we support better a gamma system.
+ * This avoids a confusing message.
+ */
+if (xf86_crtc_supports_gamma(scrp))
+ return TRUE;
#if 0
xf86MonPtr DDC = (xf86MonPtr)(scrp-monitor-DDC);
#endif
diff --git a/hw/xfree86/common/xf86cmap.c b/hw/xfree86/common/xf86cmap.c
index bb1aff1..be50a5c 100644
--- a/hw/xfree86/common/xf86cmap.c
+++ b/hw/xfree86/common/xf86cmap.c
@@ -49,6 +49,7 @@
#include xf86_OSproc.h
#include xf86str.h
#include micmap.h
+#include xf86Crtc.h
#ifdef XFreeXDGA
#define _XF86DGA_SERVER_
@@ -141,6 +142,10 @@ Bool xf86HandleColormaps(
int *indices;
int elements;
+/* If we support a better colormap system, then pretend we succeeded. */
+if (xf86_crtc_supports_gamma(pScrn))
+ return TRUE;
+
if(!maxColors || !sigRGBbits || !loadPalette)
return FALSE;
diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index ef2ecb7..7a3bb89 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -117,6 +117,12 @@ xf86CrtcCreate (ScrnInfoPtrscrn,
crtc-desiredTransformPresent = FALSE;
memset (crtc-bounds, '\0', sizeof (crtc-bounds));
+/* Preallocate gamma at a sensible size. */
+crtc-gamma_size = 256;
+crtc-gamma_red = malloc(3 * crtc-gamma_size * sizeof (CARD16));
+crtc-gamma_green = crtc-gamma_red + crtc-gamma_size;
+crtc-gamma_blue = crtc-gamma_green + crtc-gamma_size;
+
if (xf86_config-crtc)
crtcs = xrealloc (xf86_config-crtc,
(xf86_config-num_crtc + 1) * sizeof (xf86CrtcPtr));
@@ -150,6 +156,7 @@ xf86CrtcDestroy (xf86CrtcPtr crtc)
}
if (crtc-params)
xfree (crtc-params);
+free(crtc-gamma_red);
xfree (crtc);
}
@@ -2207,6 +2214,97 @@ xf86TargetUserpref(ScrnInfoPtr scrn, xf86CrtcConfigPtr
config,
return FALSE;
}
+static Bool
+xf86CrtcSetInitialGamma(xf86CrtcPtr crtc, float gamma_red, float gamma_green,
+float gamma_blue)
+{
+int i, size = 256;
+CARD16 *red, *green, *blue;
+
+red = malloc(3 * size * sizeof(CARD16));
+green = red + size;
+blue = green + size;
+
+ /* Only cause warning if user wanted gamma to be set. */
+if (!crtc-funcs-gamma_set (gamma_red != 1.0 || gamma_green != 1.0 ||
gamma_blue != 1.0))
+return FALSE;
+else if (!crtc-funcs-gamma_set)
+return TRUE;
+
+/* At this early stage none of the randr-interface stuff is up.
+ * So take the default gamma size for lack of something better.
+ */
+for (i = 0; i size; i++) {
+/* Code partially borrowed from ComputeGamma(). */
+if (gamma_red == 1.0)
+red[i] = i 8;
+else
+red[i] = (CARD16)((pow((double)i/(double)size,
+gamma_red) * (double)size + 0.5)*256);
+
+if (gamma_green == 1.0)
+green[i] = i 8;
+else
+green[i] = (CARD16)((pow((double)i/(double)size,
+gamma_green) * (double)size + 0.5)*256);
+
+if (gamma_blue == 1.0)
+blue[i] = i 8;
+else
+blue[i] = (CARD16)((pow((double)i/(double)size,
+gamma_blue) * (double)size + 0.5)*256);
+}
+
+/* Default
Re: xf86SetGamma crashes the server [Re: xserver: Branch 'master']
I should swap the reply button for reply to all :-)
On 12/17/2008 10:50 PM, Maarten Maathuis wrote:
On 12/17/2008 09:33 PM, Aaron Plattner wrote:
On Wed, Dec 17, 2008 at 08:05:24AM -0800, Maarten Maathuis wrote:
hw/xfree86/common/Makefile.am |2
hw/xfree86/common/xf86Helper.c |6 +
hw/xfree86/common/xf86cmap.c |5 +
hw/xfree86/modes/xf86Crtc.c| 128
-
hw/xfree86/modes/xf86Crtc.h| 16 +
hw/xfree86/modes/xf86RandR12.c | 52
randr/randrstr.h | 12 +++
randr/rrcrtc.c | 35 ++-
8 files changed, 249 insertions(+), 7 deletions(-)
New commits:
commit 91f73b79b7ae64e5b846d1efeb470bb61a913720
Author: Maarten Maathuismadman2...@gmail.com
Date: Wed Dec 17 16:56:26 2008 +0100
randr: Improve per-crtc gamma support.
- The Gamma values from the monitor section are now used during
initial config.
- The old colormap system is disabled when gamma set hook is
available.
- Gamma values are now persistent for the lifetime of the xserver.
- This requires no driver changes and should be driver ABI
compatible.
I've got some changes pending, i'll add a check for non-NULL'ness of
xf86_config as well.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f1c582006f0 (LWP 15464)]
0x0047126b in xf86_crtc_supports_gamma (pScrn=0x899ac0) at
/home/aaron/X/modular/xserver/hw/xfree86/modes/xf86Crtc.c:3146
3146for (c = 0; c xf86_config-num_crtc; c++) {
(gdb) bt
#0 0x0047126b in xf86_crtc_supports_gamma (pScrn=0x899ac0)
at /home/aaron/X/modular/xserver/hw/xfree86/modes/xf86Crtc.c:3146
#1 0x0045966b in xf86SetGamma (scrp=0x899ac0, gamma={red =
0, green = 0, blue = 0})
at /home/aaron/X/modular/xserver/hw/xfree86/common/xf86Helper.c:925
#2 0x7f1c54264788 in VESAPreInit (pScrn=0x899ac0, flags=value
optimized out)
at /home/aaron/X/modular/driver/xf86-video-vesa/src/vesa.c:640
#3 0x00453ab8 in InitOutput (pScreenInfo=0x8702a0, argc=4,
argv=0x7fff60336308)
at /home/aaron/X/modular/xserver/hw/xfree86/common/xf86Init.c:1007
#4 0x00428315 in main (argc=4, argv=0x7fff60336308,
envp=0x7fff60336330) at /home/aaron/X/modular/xserver/dix/main.c:308
(gdb) p xf86_config
$1 = (xf86CrtcConfigPtr) 0x21
(gdb) p xf86CrtcConfigPrivateIndex
$2 = -1
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
randr: panning doesn't change screen size
At least the xinerama sizes are not updated to reflect the size of the panned area. Meaning that your window manager won't consider the entire panned area as useable space. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xrandr: needs changes for dualhead + panning
The placement logic is output driven, and doesn't take panning into account. So you end up with strange overlap. If dual head + panning was a goal you might consider fixing this. It doesn't seem trivial to do from a quick look. On the plus side it's just a xrandr change. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xrandr: needs changes for dualhead + panning
On 12/19/2008 08:42 PM, Carl Karsten wrote: Maarten Maathuis wrote: The placement logic is output driven, and doesn't take panning into account. So you end up with strange overlap. If dual head + panning was a goal you might consider fixing this. It doesn't seem trivial to do from a quick look. On the plus side it's just a xrandr change. dual head + panning could mean a the whole space pans when you get to the side of the virtual space, b pan each physical display separately, c a combination of a/b. zoiks Carl K (a) would need changes on the protocol side (imo) I was thinking of (b). Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: X Server 1.6.99.1 NV Driver - Server crashes
On 12/22/2008 12:13 AM, Chris Ball wrote: Hi, 4: /home/fl0/mpx_neu/bin/Xorg(xf86SetGamma+0x37) See the thread at http://lists.freedesktop.org/archives/xorg/2008-December/041634.html. Maarten, any idea when you'll push a fix for this? Thanks, - Chris. Sorry, I thought I had fixed this. Should be ok now. http://cgit.freedesktop.org/xorg/xserver/commit/?id=82fba7697fbbb6f66cc22424ba99755b99ff482e Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Multihead Displays
On 12/31/2008 11:42 PM, Timothy S. Nelson wrote: On Wed, 31 Dec 2008, Jason Gauthier wrote: So, I?m left wondering how to accomplish this task. Any insight is helpful! I'm under the impression that this problem can be solved at both the X level and the Window Manager level. If no solutions are forthcoming at the X level, you may want to investigate a Window Manager that will co-ordinate these for you. I'm no expert on any of this, though, so YMMV. HTH some. - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+++ PGP-+++ R(+) !tv b++ DI D G+ e++ h! y- -END GEEK CODE BLOCK- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg I'm fairly sure that without serious changes the best you will get is two separate protocol screens. So the answer to your question is not. The why part (in case you ask) is that no-one has written a screen multiplexer yet that is compatible with randr-1.2 drivers. The intel driver happens to be such a driver. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
EXA, driver allocated pixmaps and fallbacks
Imagine having tiled pixmaps, that get copied on every map/unmap. EXA has certain optimisations to avoid migration ping-pong, ofcource that only applies to drivers using exa's built in memory manager. My impression is that an optional component, much like the migration logic in exa, should be added. With one major difference, no continuous offscreen memory. This should reduce the penalty on sw rendering, and bring performance back to previous levels. In case i get bored at some point and start coding, i would like to know if there are mistakes that should be avoided this time. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: general question: xorg Nvdriver
On Wed, Jan 28, 2009 at 11:21 PM, Stephane Marchesin marche...@icps.u-strasbg.fr wrote: 2009/1/28 Florian Lier f...@icram.de: Okay, new problem: I tried to insmod the nvdriver...this is the result: insmod: error inserting 'drm/linux-core/nv.ko': -1 Unknown symbol in module Any suggestions? There is no nv.ko module. There is a nouveau.ko module, an nvidia.ko proprietary module, but no nv module. There is an nv.ko, but it is a useless placeholder that exists for unknown reasons. Stephane ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: LibX11/xcb fails to initialize something
On Sat, Jan 31, 2009 at 7:37 PM, Brian Rogers br...@xyzw.org wrote: On Ubuntu Jaunty, Ekiga hangs during startup before it can open any windows. I traced the issue back to an uninitialized condition variable in libX11 xcb code. So to anyone with mysterious freezes, this may be the fix you need. Especially if your backtrace looks like the following one: #0 0x7fb79f38ca94 in __lll_lock_wait () from /lib/libpthread.so.0 #1 0x7fb79f38a830 in pthread_cond_broadcast@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x7fb7a1f266b7 in wait_or_poll_for_event (dpy=0x10a6290, wait=value optimized out) at ../../src/xcb_io.c:141 #3 0x7fb7a1f26a2d in process_responses (dpy=0x10a6e00, wait_for_first_event=1, current_error=0x0, current_request=0) at ../../src/xcb_io.c:166 #4 0x7fb7a1f272e9 in _XReadEvents (dpy=0x10a6290) at ../../src/xcb_io.c:272 #5 0x7fb7a1f05bd4 in XIfEvent (dpy=0x10a6290, event=0x7fffaa400690, predicate=0x7fb79dd02a70 timestamp_predicate, arg=0x284 Address 0x284 #6 0x7fb79dd02a39 in IA__gdk_x11_get_server_time (window=0x135a3f0) at /build/buildd/gtk+2.0-2.15.0/gdk/x11/gdkevents-x11.c:2598 #7 0x7fb79e4782f8 in gtk_tray_icon_send_manager_message (icon=0x10d1340, message=0, window=value optimized out, data1=41943044, data2=0, data3=0) #8 0x7fb79e4785cf in gtk_tray_icon_realize (widget=0x10d1340) at /build/buildd/gtk+2.0-2.15.0/gtk/gtktrayicon-x11.c:629 #9 0x7fb79d3f12cd in IA__g_closure_invoke (closure=0x108aa30, return_value=0x0, n_param_values=1, param_values=0x11d2280, invocation_hint=0x7fffaa4009e0) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg Was there supposed to be a patch or some other hint attached to this message? Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCHES] remove direct access to fb module from exa
On Mon, Feb 2, 2009 at 5:27 PM, Michel Dänzer mic...@daenzer.net wrote: On Mon, 2009-02-02 at 16:08 +0100, Maarten Maathuis wrote: The problem about mangling with fb symbols is that you need to do it at runtime, that would turn out to be very awkward, not to mention incorrect. For fallbacks we need to obey the wrap chain at all times. I will check if core font rendering is somehow slow, but i wouldn't know any correct fix. The case of patch 8 is something i cannot avoid, since fallbacks have to go through a wrapped function, that means i need a boolean return value, instead of void. Making brand new code seemed more error prone. What I mean is to build e.g. fbcopy.c into libexa.so, mangling the symbol names to something like exaFbCopyRegion if necessary. It would require modifying fbcopy.c, partially because i need return values on some of the functions. I would also have to split the file up, because half of that file is not machine independent. I could perhaps strip out a part of fbcopy.c and move it to mi. As long as it doesn't require fixing code i don't know. And yes, with this you can load and run wfb without crashing, my first attempts haven't resulted in correct rendering, but i'm probably misunderstanding the memory layout for my particular hardware. Still, may want to wait until you can rule out a problem with these patches? Normal X gives no regressions and just using wfb with linear accessors (1:1 usage of memory address) is fine too. I see no reason to hold up these patches for those reasons. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Recent input changes
On Mon, Feb 2, 2009 at 1:52 AM, Ben Gamari bgam...@gmail.com wrote: On Sun, Jan 25, 2009 at 2:48 PM, Ben Gamari bgam...@gmail.com wrote: Strangely enough, before I login (in gdm) things seem to behave as they should. Directly after I login though (even before my own minimal ~/.Xmodmap has been loaded), the behavior I described earlier begins. - Ben It's well-known what is said about assumptions and today I just learned why. As it turns out, loading ~/.Xmodmap is one of the first things that is done in the gnome session start-up. As it turns out, moving my simple ~/.Xmodmap out of the way fixes the problem with my modifiers (Ctrl functioning as Caps Lock, Alt not working at all, etc.) It's a relief to know that the problem isn't difficult to work around, however this does present the question of why my modmap is ruining the modifier map. My ~/.Xmodmap simply remaps the Caps_Lock key as Escape for use in vim, $ cat ~/.Xmodmap remove Lock = Caps_Lock keysym Caps_Lock = Escape Is there any reason why this wouldn't work with the reworked input subsystem? Is this simply a regression? Thanks, - Ben ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg I think i noticed something similar too. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 6/9] exa: wrap the remainder of exa_unaccel.c
---
exa/exa_unaccel.c | 30 +++---
1 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/exa/exa_unaccel.c b/exa/exa_unaccel.c
index d56f589..a521497 100644
--- a/exa/exa_unaccel.c
+++ b/exa/exa_unaccel.c
@@ -290,9 +290,14 @@ ExaCheckGetSpans (DrawablePtr pDrawable,
int nspans,
char *pdstStart)
{
+ScreenPtr pScreen = pDrawable-pScreen;
+ExaScreenPriv(pScreen);
+
EXA_FALLBACK((from %p (%c)\n, pDrawable,
exaDrawableLocation(pDrawable)));
exaPrepareAccess (pDrawable, EXA_PREPARE_SRC);
-fbGetSpans (pDrawable, wMax, ppt, pwidth, nspans, pdstStart);
+swap(pExaScr, pScreen, GetSpans);
+pScreen-GetSpans (pDrawable, wMax, ppt, pwidth, nspans, pdstStart);
+swap(pExaScr, pScreen, GetSpans);
exaFinishAccess (pDrawable, EXA_PREPARE_SRC);
}
@@ -310,6 +315,11 @@ ExaCheckComposite (CARD8 op,
CARD16 width,
CARD16 height)
{
+ScreenPtr pScreen = pDst-pDrawable-pScreen;
+#ifdef RENDER
+PictureScreenPtr ps = GetPictureScreen(pScreen);
+#endif /* RENDER */
+ExaScreenPriv(pScreen);
RegionRec region;
int xoff, yoff;
@@ -338,7 +348,9 @@ ExaCheckComposite (CARD8 op,
exaPrepareAccess (pSrc-pDrawable, EXA_PREPARE_SRC);
if (pMask pMask-pDrawable != NULL)
exaPrepareAccess (pMask-pDrawable, EXA_PREPARE_MASK);
-fbComposite (op,
+#ifdef RENDER
+swap(pExaScr, ps, Composite);
+ps-Composite (op,
pSrc,
pMask,
pDst,
@@ -350,6 +362,8 @@ ExaCheckComposite (CARD8 op,
yDst,
width,
height);
+swap(pExaScr, ps, Composite);
+#endif /* RENDER */
if (pMask pMask-pDrawable != NULL)
exaFinishAccess (pMask-pDrawable, EXA_PREPARE_MASK);
if (pSrc-pDrawable != NULL)
@@ -366,10 +380,20 @@ ExaCheckAddTraps (PicturePtr pPicture,
int ntrap,
xTrap *traps)
{
+ScreenPtr pScreen = pPicture-pDrawable-pScreen;
+#ifdef RENDER
+PictureScreenPtr ps = GetPictureScreen(pScreen);
+#endif /* RENDER */
+ExaScreenPriv(pScreen);
+
EXA_FALLBACK((to pict %p (%c)\n,
exaDrawableLocation(pPicture-pDrawable)));
exaPrepareAccess(pPicture-pDrawable, EXA_PREPARE_DEST);
-fbAddTraps (pPicture, x_off, y_off, ntrap, traps);
+#ifdef RENDER
+swap(pExaScr, ps, AddTraps);
+ps-AddTraps (pPicture, x_off, y_off, ntrap, traps);
+swap(pExaScr, ps, AddTraps);
+#endif /* RENDER */
exaFinishAccess(pPicture-pDrawable, EXA_PREPARE_DEST);
}
--
1.6.1.1
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 9/9] exa: fix exaCopyArea and friends.
---
exa/Makefile.am |3 ++-
exa/exa_accel.c | 44 ++--
exa/exa_priv.h |6 +-
exa/exa_render.c| 14 --
exa/exa_unaccel.c | 15 +++
fb/fbcopy_helpers.h |5 +
6 files changed, 69 insertions(+), 18 deletions(-)
diff --git a/exa/Makefile.am b/exa/Makefile.am
index 2b3f1e4..f344a05 100644
--- a/exa/Makefile.am
+++ b/exa/Makefile.am
@@ -12,11 +12,12 @@ INCLUDES = \
$(XORG_INCS) \
-I$(srcdir)/../miext/cw
-AM_CFLAGS = $(XORG_CFLAGS) $(DIX_CFLAGS)
+AM_CFLAGS = $(XORG_CFLAGS) $(DIX_CFLAGS) -DEXA_WRAPPER
libexa_la_SOURCES = \
exa.c \
exa.h \
+ ../fb/fbcopy_helpers.c \
exa_accel.c \
exa_glyphs.c \
exa_migration.c \
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index 02858f1..db79cee 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -359,7 +359,7 @@ exaCopyNtoNTwoDir (DrawablePtr pSrcDrawable, DrawablePtr
pDstDrawable,
return TRUE;
}
-void
+Bool
exaCopyNtoN (DrawablePtrpSrcDrawable,
DrawablePtrpDstDrawable,
GCPtr pGC,
@@ -383,7 +383,7 @@ exaCopyNtoN (DrawablePtrpSrcDrawable,
/* avoid doing copy operations if no boxes */
if (nbox == 0)
- return;
+ return TRUE;
pSrcPixmap = exaGetDrawablePixmap (pSrcDrawable);
pDstPixmap = exaGetDrawablePixmap (pDstDrawable);
@@ -492,15 +492,15 @@ exaCopyNtoN (DrawablePtrpSrcDrawable,
goto out;
fallback:
-EXA_FALLBACK((from %p to %p (%c,%c)\n, pSrcDrawable, pDstDrawable,
- exaDrawableLocation(pSrcDrawable),
- exaDrawableLocation(pDstDrawable)));
-exaPrepareAccessReg (pDstDrawable, EXA_PREPARE_DEST, dstregion);
-exaPrepareAccessReg (pSrcDrawable, EXA_PREPARE_SRC, srcregion);
-fbCopyNtoN (pSrcDrawable, pDstDrawable, pGC, pbox, nbox, dx, dy, reverse,
- upsidedown, bitplane, closure);
-exaFinishAccess (pSrcDrawable, EXA_PREPARE_SRC);
-exaFinishAccess (pDstDrawable, EXA_PREPARE_DEST);
+if (dstregion) {
+ REGION_UNINIT(pScreen, dstregion);
+ REGION_DESTROY(pScreen, dstregion);
+}
+if (srcregion) {
+ REGION_UNINIT(pScreen, srcregion);
+ REGION_DESTROY(pScreen, srcregion);
+}
+return FALSE;
out:
if (dstregion) {
@@ -511,6 +511,8 @@ out:
REGION_UNINIT(pScreen, srcregion);
REGION_DESTROY(pScreen, srcregion);
}
+
+return TRUE;
}
RegionPtr
@@ -518,15 +520,25 @@ exaCopyArea(DrawablePtr pSrcDrawable, DrawablePtr
pDstDrawable, GCPtr pGC,
int srcx, int srcy, int width, int height, int dstx, int dsty)
{
ExaScreenPriv (pDstDrawable-pScreen);
+RegionPtr ret;
+Bool success;
if (pExaScr-swappedOut) {
return ExaCheckCopyArea(pSrcDrawable, pDstDrawable, pGC,
srcx, srcy, width, height, dstx, dsty);
}
-return fbDoCopy (pSrcDrawable, pDstDrawable, pGC,
+ret = exaDoCopy (pSrcDrawable, pDstDrawable, pGC,
srcx, srcy, width, height,
- dstx, dsty, exaCopyNtoN, 0, NULL);
+ dstx, dsty, exaCopyNtoN, 0, NULL, success);
+
+if (!success) {
+ xfree(ret);
+ return ExaCheckCopyArea(pSrcDrawable, pDstDrawable, pGC,
+ srcx, srcy, width, height, dstx, dsty);
+}
+
+return ret;
}
static void
@@ -865,6 +877,7 @@ exaCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg,
RegionPtr prgnSrc)
RegionRec rgnDst;
intdx, dy;
PixmapPtr pPixmap = (*pWin-drawable.pScreen-GetWindowPixmap) (pWin);
+Bool ret;
dx = ptOldOrg.x - pWin-drawable.x;
dy = ptOldOrg.y - pWin-drawable.y;
@@ -879,11 +892,14 @@ exaCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg,
RegionPtr prgnSrc)
-pPixmap-screen_x, -pPixmap-screen_y);
#endif
-fbCopyRegion (pPixmap-drawable, pPixmap-drawable,
+ret = exaCopyRegion (pPixmap-drawable, pPixmap-drawable,
NULL,
rgnDst, dx, dy, exaCopyNtoN, 0, NULL);
REGION_UNINIT(pWin-drawable.pScreen, rgnDst);
+
+if (!ret)
+ ExaCheckCopyWindow(pWin, ptOldOrg, prgnSrc);
}
static Bool
diff --git a/exa/exa_priv.h b/exa/exa_priv.h
index 6d7c1dd..c555f85 100644
--- a/exa/exa_priv.h
+++ b/exa/exa_priv.h
@@ -55,6 +55,7 @@
#include glyphstr.h
#endif
#include damage.h
+#include fbcopy_helpers.h
#define DEBUG_TRACE_FALL 0
#define DEBUG_MIGRATE 0
@@ -379,6 +380,9 @@ ExaCheckAddTraps (PicturePtrpPicture,
int ntrap,
xTrap *traps);
+void
+ExaCheckCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg, RegionPtr prgnSrc);
+
/* exa_accel.c */
static _X_INLINE Bool
@@ -465,7 +469,7 @@ RegionPtr
exaCopyArea(DrawablePtr pSrcDrawable, DrawablePtr pDstDrawable, GCPtr pGC,
int srcx, int srcy,
[PATCH 1/9] exa: Remove one of the many calls directly into the fb layer.
---
exa/exa_accel.c | 32 ++--
1 files changed, 6 insertions(+), 26 deletions(-)
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index f72a08a..b70222a 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -149,6 +149,7 @@ exaDoPutImage (DrawablePtr pDrawable, GCPtr pGC, int depth,
int x, int y,
int xoff, yoff;
int bpp = pDrawable-bitsPerPixel;
Bool access_prepared = FALSE;
+Bool ret = TRUE;
if (pExaPixmap-accel_blocked)
return FALSE;
@@ -210,33 +211,12 @@ exaDoPutImage (DrawablePtr pDrawable, GCPtr pGC, int
depth, int x, int y,
src = bits + (y1 - y) * src_stride + (x1 - x) * (bpp / 8);
ok = pExaScr-info-UploadToScreen(pPix, x1 + xoff, y1 + yoff,
x2 - x1, y2 - y1, src, src_stride);
- /* If we fail to accelerate the upload, fall back to using unaccelerated
-* fb calls.
+ /* We have to fall back completely, and ignore what has already been
completed.
+* Messing with the fb layer directly like we used to is completely
unacceptable.
*/
if (!ok) {
- FbStip *dst;
- FbStride dst_stride;
- int dstBpp;
- int dstXoff, dstYoff;
-
- if (!access_prepared) {
- ExaDoPrepareAccess(pDrawable, EXA_PREPARE_DEST);
-
- access_prepared = TRUE;
- }
-
- fbGetStipDrawable(pDrawable, dst, dst_stride, dstBpp,
- dstXoff, dstYoff);
-
- fbBltStip((FbStip *)bits + (y1 - y) * (src_stride / sizeof(FbStip)),
- src_stride / sizeof(FbStip),
- (x1 - x) * dstBpp,
- dst + (y1 + dstYoff) * dst_stride,
- dst_stride,
- (x1 + dstXoff) * dstBpp,
- (x2 - x1) * dstBpp,
- y2 - y1,
- GXcopy, FB_ALLONES, dstBpp);
+ ret = FALSE;
+ break;
}
}
@@ -245,7 +225,7 @@ exaDoPutImage (DrawablePtr pDrawable, GCPtr pGC, int depth,
int x, int y,
else
exaMarkSync(pDrawable-pScreen);
-return TRUE;
+return ret;
}
static void
--
1.6.1.1
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 5/9] exa: use proper wrapping in exa.c
---
exa/exa.c | 141 ++---
1 files changed, 70 insertions(+), 71 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 42b664f..5faeee0 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -188,6 +188,7 @@ exaDestroyPixmap (PixmapPtr pPixmap)
{
ScreenPtr pScreen = pPixmap-drawable.pScreen;
ExaScreenPriv(pScreen);
+Bool ret;
if (pPixmap-refcnt == 1)
{
@@ -213,7 +214,12 @@ exaDestroyPixmap (PixmapPtr pPixmap)
REGION_UNINIT(pPixmap-drawable.pScreen, pExaPixmap-validSys);
REGION_UNINIT(pPixmap-drawable.pScreen, pExaPixmap-validFB);
}
-return fbDestroyPixmap (pPixmap);
+
+swap(pExaScr, pScreen, DestroyPixmap);
+ret = pScreen-DestroyPixmap (pPixmap);
+swap(pExaScr, pScreen, DestroyPixmap);
+
+return ret;
}
static int
@@ -286,12 +292,14 @@ exaCreatePixmap(ScreenPtr pScreen, int w, int h, int
depth,
if (w 32767 || h 32767)
return NullPixmap;
+swap(pExaScr, pScreen, CreatePixmap);
if (!pExaScr-info-CreatePixmap) {
-pPixmap = fbCreatePixmap (pScreen, w, h, depth, usage_hint);
+pPixmap = pScreen-CreatePixmap (pScreen, w, h, depth, usage_hint);
} else {
driver_alloc = 1;
-pPixmap = fbCreatePixmap(pScreen, 0, 0, depth, usage_hint);
+pPixmap = pScreen-CreatePixmap(pScreen, 0, 0, depth, usage_hint);
}
+swap(pExaScr, pScreen, CreatePixmap);
if (!pPixmap)
return NULL;
@@ -322,8 +330,10 @@ exaCreatePixmap(ScreenPtr pScreen, int w, int h, int depth,
pExaPixmap-driverPriv = pExaScr-info-CreatePixmap(pScreen,
datasize, 0);
if (!pExaPixmap-driverPriv) {
- fbDestroyPixmap(pPixmap);
- return NULL;
+ swap(pExaScr, pScreen, DestroyPixmap);
+ pScreen-DestroyPixmap (pPixmap);
+ swap(pExaScr, pScreen, DestroyPixmap);
+ return NULL;
}
(*pScreen-ModifyPixmapHeader)(pPixmap, w, h, 0, 0,
@@ -354,8 +364,10 @@ exaCreatePixmap(ScreenPtr pScreen, int w, int h, int depth,
pExaPixmap-fb_size = pExaPixmap-fb_pitch * h;
if (pExaPixmap-fb_pitch 131071) {
-fbDestroyPixmap(pPixmap);
-return NULL;
+ swap(pExaScr, pScreen, DestroyPixmap);
+ pScreen-DestroyPixmap (pPixmap);
+ swap(pExaScr, pScreen, DestroyPixmap);
+ return NULL;
}
/* Set up damage tracking */
@@ -364,7 +376,9 @@ exaCreatePixmap(ScreenPtr pScreen, int w, int h, int depth,
pScreen, pPixmap);
if (pExaPixmap-pDamage == NULL) {
- fbDestroyPixmap (pPixmap);
+ swap(pExaScr, pScreen, DestroyPixmap);
+ pScreen-DestroyPixmap (pPixmap);
+ swap(pExaScr, pScreen, DestroyPixmap);
return NULL;
}
@@ -760,6 +774,8 @@ static Bool
exaChangeWindowAttributes(WindowPtr pWin, unsigned long mask)
{
Bool ret;
+ScreenPtr pScreen = pWin-drawable.pScreen;
+ExaScreenPriv(pScreen);
if ((mask CWBackPixmap) pWin-backgroundState == BackgroundPixmap)
exaPrepareAccess(pWin-background.pixmap-drawable, EXA_PREPARE_SRC);
@@ -767,7 +783,9 @@ exaChangeWindowAttributes(WindowPtr pWin, unsigned long
mask)
if ((mask CWBorderPixmap) pWin-borderIsPixel == FALSE)
exaPrepareAccess(pWin-border.pixmap-drawable, EXA_PREPARE_MASK);
-ret = fbChangeWindowAttributes(pWin, mask);
+swap(pExaScr, pScreen, ChangeWindowAttributes);
+ret = pScreen-ChangeWindowAttributes(pWin, mask);
+swap(pExaScr, pScreen, ChangeWindowAttributes);
if ((mask CWBorderPixmap) pWin-borderIsPixel == FALSE)
exaFinishAccess(pWin-border.pixmap-drawable, EXA_PREPARE_MASK);
@@ -782,9 +800,15 @@ static RegionPtr
exaBitmapToRegion(PixmapPtr pPix)
{
RegionPtr ret;
+ScreenPtr pScreen = pPix-drawable.pScreen;
+ExaScreenPriv(pScreen);
+
exaPrepareAccess(pPix-drawable, EXA_PREPARE_SRC);
-ret = fbPixmapToRegion(pPix);
+swap(pExaScr, pScreen, BitmapToRegion);
+ret = pScreen-BitmapToRegion(pPix);
+swap(pExaScr, pScreen, BitmapToRegion);
exaFinishAccess(pPix-drawable, EXA_PREPARE_SRC);
+
return ret;
}
@@ -795,9 +819,9 @@ exaCreateScreenResources(ScreenPtr pScreen)
PixmapPtr pScreenPixmap;
Bool b;
-pScreen-CreateScreenResources = pExaScr-SavedCreateScreenResources;
+swap(pExaScr, pScreen, CreateScreenResources);
b = pScreen-CreateScreenResources(pScreen);
-pScreen-CreateScreenResources = exaCreateScreenResources;
+swap(pExaScr, pScreen, CreateScreenResources);
if (!b)
return FALSE;
@@ -831,23 +855,26 @@ exaCloseScreen(int i, ScreenPtr pScreen)
if (ps-Glyphs == exaGlyphs)
exaGlyphsFini(pScreen);
-pScreen-CreateGC = pExaScr-SavedCreateGC;
-pScreen-CloseScreen = pExaScr-SavedCloseScreen;
-pScreen-GetImage = pExaScr-SavedGetImage;
-
[PATCH 8/9] fb: split off a few functions into a seperate file and enhance them slightly.
- Compatibility wrappers, if deemed neccesary will come later. --- fb/Makefile.am |3 +- fb/fb.h | 37 +- fb/fb24_32.c|4 +- fb/fbcopy.c | 342 ++- fb/fbcopy_helpers.c | 367 +++ fb/fbcopy_helpers.h | 52 +++ fb/fboverlay.c |1 + fb/fbwindow.c |5 +- 8 files changed, 448 insertions(+), 363 deletions(-) create mode 100644 fb/fbcopy_helpers.c create mode 100644 fb/fbcopy_helpers.h diff --git a/fb/Makefile.am b/fb/Makefile.am index 64e49f3..cfd9364 100644 --- a/fb/Makefile.am +++ b/fb/Makefile.am @@ -7,7 +7,7 @@ INCLUDES = \ AM_CFLAGS = $(DIX_CFLAGS) if XORG -sdk_HEADERS = fb.h fbrop.h fboverlay.h wfbrename.h fbpict.h +sdk_HEADERS = fb.h fbrop.h fboverlay.h wfbrename.h fbpict.h fbcopy_helpers.h endif libfb_la_CFLAGS = $(AM_CFLAGS) @@ -24,6 +24,7 @@ libfb_la_SOURCES =\ fbbits.h\ fbblt.c \ fbbltone.c \ + fbcopy_helpers.c\ fbcopy.c\ fbfill.c\ fbfillrect.c\ diff --git a/fb/fb.h b/fb/fb.h index 8384315..b0898b0 100644 --- a/fb/fb.h +++ b/fb/fb.h @@ -788,7 +788,7 @@ fb24_32GetImage (DrawablePtr pDrawable, unsigned long planeMask, char*d); -extern _X_EXPORT void +extern _X_EXPORT Bool fb24_32CopyMtoN (DrawablePtr pSrcDrawable, DrawablePtr pDstDrawable, GCPtr pGC, @@ -1306,7 +1306,7 @@ fbInitVisuals (VisualPtr*visualp, * fbcopy.c */ -typedef void (*fbCopyProc) (DrawablePtr pSrcDrawable, +typedef Bool (*fbCopyProc) (DrawablePtr pSrcDrawable, DrawablePtr pDstDrawable, GCPtrpGC, BoxPtr pDstBox, @@ -1318,7 +1318,7 @@ typedef void (*fbCopyProc) (DrawablePtr pSrcDrawable, Pixelbitplane, void *closure); -extern _X_EXPORT void +extern _X_EXPORT Bool fbCopyNtoN (DrawablePtrpSrcDrawable, DrawablePtr pDstDrawable, GCPtr pGC, @@ -1331,7 +1331,7 @@ fbCopyNtoN (DrawablePtr pSrcDrawable, Pixel bitplane, void*closure); -extern _X_EXPORT void +extern _X_EXPORT Bool fbCopy1toN (DrawablePtrpSrcDrawable, DrawablePtr pDstDrawable, GCPtr pGC, @@ -1344,7 +1344,7 @@ fbCopy1toN (DrawablePtr pSrcDrawable, Pixel bitplane, void*closure); -extern _X_EXPORT void +extern _X_EXPORT Bool fbCopyNto1 (DrawablePtrpSrcDrawable, DrawablePtr pDstDrawable, GCPtr pGC, @@ -1357,31 +1357,6 @@ fbCopyNto1 (DrawablePtr pSrcDrawable, Pixel bitplane, void*closure); -extern _X_EXPORT void -fbCopyRegion (DrawablePtr pSrcDrawable, - DrawablePtr pDstDrawable, - GCPtr pGC, - RegionPtr pDstRegion, - int dx, - int dy, - fbCopyProccopyProc, - Pixel bitPlane, - void *closure); - -extern _X_EXPORT RegionPtr -fbDoCopy (DrawablePtr pSrcDrawable, - DrawablePtr pDstDrawable, - GCPtr pGC, - int xIn, - int yIn, - int widthSrc, - int heightSrc, - int xOut, - int yOut, - fbCopyProccopyProc, - Pixel bitplane, - void *closure); - extern _X_EXPORT RegionPtr fbCopyArea (DrawablePtrpSrcDrawable, DrawablePtr pDstDrawable, @@ -2036,7 +2011,7 @@ fbPositionWindow(WindowPtr pWin, int x, int y); extern _X_EXPORT Bool fbUnmapWindow(WindowPtr pWindow); -extern _X_EXPORT void +extern _X_EXPORT Bool fbCopyWindowProc (DrawablePtr pSrcDrawable, DrawablePtr pDstDrawable, GCPtr pGC, diff --git a/fb/fb24_32.c b/fb/fb24_32.c index 1ebd598..952b9ff 100644 --- a/fb/fb24_32.c +++ b/fb/fb24_32.c @@ -472,7 +472,7 @@ fb24_32GetImage (DrawablePtr pDrawable, fbFinishAccess (pDrawable); } -void +Bool fb24_32CopyMtoN (DrawablePtr pSrcDrawable, DrawablePtr pDstDrawable, GCPtr pGC, @@ -529,6 +529,8 @@ fb24_32CopyMtoN (DrawablePtr pSrcDrawable, fbFinishAccess (pSrcDrawable); fbFinishAccess (pDstDrawable); + +return TRUE; } PixmapPtr diff --git a/fb/fbcopy.c b/fb/fbcopy.c index b8b0b6a..2f430b7 100644 --- a/fb/fbcopy.c +++ b/fb/fbcopy.c @@ -27,8 +27,9 @@ #include stdlib.h #include fb.h +#include fbcopy_helpers.h -void +Bool fbCopyNtoN (DrawablePtrpSrcDrawable, DrawablePtr pDstDrawable,
Comments about exa patches i just sent
Per request by anholt and others, i have sent the patches as plain text. The only change from the last set is that i splitted out a few fb functions into a seperate file, enhanced them slightly and added a few defines to allow exa to use them. My attempts to split it out into mi, gave me very strange issues, so if you think you can do better, be my guest. In hindsight this approach isn't bad either, and is MrCooper suggested. One of the questions is (as it says in patch 8), do you deem compatibility wrappers necessary? Comments are appreciated as usual. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 4/9] exa: properly wrap GC functions
---
exa/exa.c | 219
exa/exa_priv.h| 33 -
exa/exa_unaccel.c | 98 +---
3 files changed, 234 insertions(+), 116 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 496b898..42b664f 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -575,86 +575,164 @@ exaFinishAccess(DrawablePtr pDrawable, int index)
}
/**
- * exaValidateGC() sets the ops to EXA's implementations, which may be
- * accelerated or may sync the card and fall back to fb.
+ * Here begins EXA's GC code.
+ * Do not ever access the fb/mi layer directly.
*/
+
+static void
+exaValidateGC(GCPtr pGC,
+ unsigned long changes,
+ DrawablePtr pDrawable);
+
+static void
+exaDestroyGC(GCPtr pGC);
+
+static void
+exaChangeGC (GCPtr pGC,
+ unsigned long mask);
+
+static void
+exaCopyGC (GCPtr pGCSrc,
+ unsigned long mask,
+ GCPtr pGCDst);
+
+static void
+exaChangeClip (GCPtr pGC,
+ int type,
+ pointer pvalue,
+ int nrects);
+
+static void
+exaCopyClip(GCPtr pGCDst, GCPtr pGCSrc);
+
+static void
+exaCopyClip(GCPtr pGCDst, GCPtr pGCSrc);
+
static void
-exaValidateGC (GCPtr pGC, unsigned long changes, DrawablePtr pDrawable)
+exaDestroyClip(GCPtr pGC);
+
+const GCFuncs exaGCFuncs = {
+exaValidateGC,
+exaChangeGC,
+exaCopyGC,
+exaDestroyGC,
+exaChangeClip,
+exaDestroyClip,
+exaCopyClip
+};
+
+/*
+ * This wrapper exists to allow fbValidateGC to work.
+ */
+static PixmapPtr
+exaCreatePixmapWithPrepare(ScreenPtr pScreen, int w, int h, int depth,
+ unsigned usage_hint)
+{
+PixmapPtr pPixmap = exaCreatePixmap(pScreen, w, h, depth, usage_hint);
+
+if (!pPixmap)
+ return NULL;
+
+/* We use MASK, because SRC is already taken. */
+exaPrepareAccess(pPixmap-drawable, EXA_PREPARE_MASK);
+
+return pPixmap;
+}
+
+static void
+exaValidateGC(GCPtr pGC,
+ unsigned long changes,
+ DrawablePtr pDrawable)
{
/* fbValidateGC will do direct access to pixmaps if the tiling has changed.
- * Preempt fbValidateGC by doing its work and masking the change out, so
- * that we can do the Prepare/FinishAccess.
+ * Do a few smart things so fbValidateGC can do it's work.
*/
-#ifdef FB_24_32BIT
-if ((changes GCTile) fbGetRotatedPixmap(pGC)) {
- (*pGC-pScreen-DestroyPixmap) (fbGetRotatedPixmap(pGC));
- fbGetRotatedPixmap(pGC) = 0;
-}
-
-if (pGC-fillStyle == FillTiled) {
- PixmapPtr pOldTile, pNewTile;
- pOldTile = pGC-tile.pixmap;
- if (pOldTile-drawable.bitsPerPixel != pDrawable-bitsPerPixel)
- {
- pNewTile = fbGetRotatedPixmap(pGC);
- if (!pNewTile ||
- pNewTile -drawable.bitsPerPixel != pDrawable-bitsPerPixel)
- {
- if (pNewTile)
- (*pGC-pScreen-DestroyPixmap) (pNewTile);
- /* fb24_32ReformatTile will do direct access of a newly-
-* allocated pixmap. This isn't a problem yet, since we don't
-* put pixmaps in FB until at least one accelerated EXA op.
-*/
- exaPrepareAccess(pOldTile-drawable, EXA_PREPARE_SRC);
- pNewTile = fb24_32ReformatTile (pOldTile,
- pDrawable-bitsPerPixel);
- exaPixmapDirty(pNewTile, 0, 0, pNewTile-drawable.width,
pNewTile-drawable.height);
- exaFinishAccess(pOldTile-drawable, EXA_PREPARE_SRC);
- }
- if (pNewTile)
- {
- fbGetRotatedPixmap(pGC) = pOldTile;
- pGC-tile.pixmap = pNewTile;
- changes |= GCTile;
- }
- }
+ScreenPtr pScreen = pDrawable-pScreen;
+CreatePixmapProcPtr old_ptr = NULL;
+PixmapPtr pTile = NULL;
+EXA_GC_PROLOGUE(pGC);
+if (changes GCTile) {
+ old_ptr = pScreen-CreatePixmap;
+ pScreen-CreatePixmap = exaCreatePixmapWithPrepare;
+ if (pGC-fillStyle == FillTiled)
+ pTile = pGC-tile.pixmap;
+ if (pTile)
+ exaPrepareAccess(pTile-drawable, EXA_PREPARE_SRC);
}
-#endif
+exaPrepareAccessGC(pGC);
+(*pGC-funcs-ValidateGC)(pGC, changes, pDrawable);
+exaFinishAccessGC(pGC);
if (changes GCTile) {
- if (!pGC-tileIsPixel FbEvenTile (pGC-tile.pixmap-drawable.width *
-pDrawable-bitsPerPixel))
- {
- exaPrepareAccess(pGC-tile.pixmap-drawable, EXA_PREPARE_SRC);
- fbPadPixmap (pGC-tile.pixmap);
- exaFinishAccess(pGC-tile.pixmap-drawable, EXA_PREPARE_SRC);
+ pScreen-CreatePixmap = old_ptr;
+ if (pTile)
+ exaFinishAccess(pTile-drawable, EXA_PREPARE_SRC);
+
+ /* A new tile pixmap was created. */
+ if (pGC-tile.pixmap != pTile pGC-fillStyle == FillTiled) {
+
[PATCH 3/9] exa: add GC private
---
exa/exa.c | 11 +++
exa/exa_priv.h | 12 +++-
2 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index ba063bb..496b898 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -41,6 +41,8 @@ static int exaScreenPrivateKeyIndex;
DevPrivateKey exaScreenPrivateKey = exaScreenPrivateKeyIndex;
static int exaPixmapPrivateKeyIndex;
DevPrivateKey exaPixmapPrivateKey = exaPixmapPrivateKeyIndex;
+static int exaGCPrivateKeyIndex;
+DevPrivateKey exaGCPrivateKey = exaGCPrivateKeyIndex;
#ifdef MITSHM
static ShmFuncs exaShmFuncs = { NULL, NULL };
@@ -661,6 +663,8 @@ static GCFuncs exaGCFuncs = {
static int
exaCreateGC (GCPtr pGC)
{
+ExaGCPriv(pGC);
+
if (!fbCreateGC (pGC))
return FALSE;
@@ -890,6 +894,13 @@ exaDriverInit (ScreenPtr pScreen,
exaDDXDriverInit(pScreen);
+if (!dixRequestPrivate(exaGCPrivateKey, sizeof(ExaGCPrivRec))) {
+ LogMessage(X_WARNING,
+ EXA(%d): Failed to allocate GC private\n,
+ pScreen-myNum);
+ return FALSE;
+}
+
/*
* Replace various fb screen functions
*/
diff --git a/exa/exa_priv.h b/exa/exa_priv.h
index cc789c6..3b58948 100644
--- a/exa/exa_priv.h
+++ b/exa/exa_priv.h
@@ -173,9 +173,13 @@ typedef struct {
extern DevPrivateKey exaScreenPrivateKey;
extern DevPrivateKey exaPixmapPrivateKey;
+extern DevPrivateKey exaGCPrivateKey;
#define ExaGetScreenPriv(s)
((ExaScreenPrivPtr)dixLookupPrivate((s)-devPrivates, exaScreenPrivateKey))
#define ExaScreenPriv(s) ExaScreenPrivPtrpExaScr =
ExaGetScreenPriv(s)
+#define ExaGetGCPriv(gc) ((ExaGCPrivPtr)dixLookupPrivate((gc)-devPrivates,
exaGCPrivateKey))
+#define ExaGCPriv(gc) ExaGCPrivPtr pExaGC = ExaGetGCPriv(gc)
+
/** Align an offset to an arbitrary alignment */
#define EXA_ALIGN(offset, align) (((offset) + (align) - 1) - \
(((offset) + (align) - 1) % (align)))
@@ -236,7 +240,13 @@ typedef struct {
*/
void *driverPriv;
} ExaPixmapPrivRec, *ExaPixmapPrivPtr;
-
+
+typedef struct {
+/* GC values from the layer below. */
+GCOps *ops;
+GCFuncs *funcs;
+} ExaGCPrivRec, *ExaGCPrivPtr;
+
typedef struct _ExaMigrationRec {
Bool as_dst;
Bool as_src;
--
1.6.1.1
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
about the exa patches
Found a potential bug in exaValidateGC, which should be fixed now. I hope the changes are coming to an end. I still need to know if there are any external users of fbDoCopy that would care for a wrapper. I'm assuming that functions that changed their return value from void to Bool pose no issue, but you're welcome to explain if it's not. @MrCooper: the approach of patch 8 and 9 is ok by you? Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 7/9] exa: create ExaCheckGetImage
---
exa/exa_accel.c |7 +--
exa/exa_priv.h|4
exa/exa_unaccel.c | 30 ++
3 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index 10e7914..02858f1 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -1201,12 +1201,7 @@ exaGetImage (DrawablePtr pDrawable, int x, int y, int w,
int h,
}
fallback:
-EXA_FALLBACK((from %p (%c)\n, pDrawable,
- exaDrawableLocation(pDrawable)));
-
-exaPrepareAccessReg (pDrawable, EXA_PREPARE_SRC, Reg);
-fbGetImage (pDrawable, x, y, w, h, format, planeMask, d);
-exaFinishAccess (pDrawable, EXA_PREPARE_SRC);
+ExaCheckGetImage(pDrawable, x, y, w, h, format, planeMask, d);
out:
REGION_UNINIT(pScreen, Reg);
diff --git a/exa/exa_priv.h b/exa/exa_priv.h
index a41e5fe..6d7c1dd 100644
--- a/exa/exa_priv.h
+++ b/exa/exa_priv.h
@@ -361,6 +361,10 @@ ExaCheckPushPixels (GCPtr pGC, PixmapPtr pBitmap,
int w, int h, int x, int y);
void
+ExaCheckGetImage(DrawablePtr pDrawable, int x, int y, int w, int h,
+ unsigned int format, unsigned long planeMask, char *d);
+
+void
ExaCheckGetSpans (DrawablePtr pDrawable,
int wMax,
DDXPointPtr ppt,
diff --git a/exa/exa_unaccel.c b/exa/exa_unaccel.c
index a521497..e0f2ae9 100644
--- a/exa/exa_unaccel.c
+++ b/exa/exa_unaccel.c
@@ -283,6 +283,36 @@ ExaCheckPushPixels (GCPtr pGC, PixmapPtr pBitmap,
}
void
+ExaCheckGetImage(DrawablePtr pDrawable, int x, int y, int w, int h,
+ unsigned int format, unsigned long planeMask, char *d)
+{
+BoxRec Box;
+RegionRec Reg;
+int xoff, yoff;
+ScreenPtr pScreen = pDrawable-pScreen;
+PixmapPtr pPix = exaGetDrawablePixmap (pDrawable);
+ExaScreenPriv(pScreen);
+
+EXA_FALLBACK((from %p (%c)\n, pDrawable,
+ exaDrawableLocation(pDrawable)));
+
+exaGetDrawableDeltas(pDrawable, pPix, xoff, yoff);
+
+Box.x1 = pDrawable-y + x + xoff;
+Box.y1 = pDrawable-y + y + yoff;
+Box.x2 = Box.x1 + w;
+Box.y2 = Box.y1 + h;
+
+REGION_INIT(pScreen, Reg, Box, 1);
+
+exaPrepareAccessReg (pDrawable, EXA_PREPARE_SRC, Reg);
+swap(pExaScr, pScreen, GetImage);
+pScreen-GetImage (pDrawable, x, y, w, h, format, planeMask, d);
+swap(pExaScr, pScreen, GetImage);
+exaFinishAccess (pDrawable, EXA_PREPARE_SRC);
+}
+
+void
ExaCheckGetSpans (DrawablePtr pDrawable,
int wMax,
DDXPointPtr ppt,
--
1.6.1.1
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 4/9] exa: properly wrap GC functions
---
exa/exa.c | 233 +
exa/exa_priv.h| 33 +++-
exa/exa_unaccel.c | 98 ---
3 files changed, 248 insertions(+), 116 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 496b898..58d1a7d 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -575,86 +575,178 @@ exaFinishAccess(DrawablePtr pDrawable, int index)
}
/**
- * exaValidateGC() sets the ops to EXA's implementations, which may be
- * accelerated or may sync the card and fall back to fb.
+ * Here begins EXA's GC code.
+ * Do not ever access the fb/mi layer directly.
*/
+
+static void
+exaValidateGC(GCPtr pGC,
+ unsigned long changes,
+ DrawablePtr pDrawable);
+
+static void
+exaDestroyGC(GCPtr pGC);
+
+static void
+exaChangeGC (GCPtr pGC,
+ unsigned long mask);
+
+static void
+exaCopyGC (GCPtr pGCSrc,
+ unsigned long mask,
+ GCPtr pGCDst);
+
+static void
+exaChangeClip (GCPtr pGC,
+ int type,
+ pointer pvalue,
+ int nrects);
+
static void
-exaValidateGC (GCPtr pGC, unsigned long changes, DrawablePtr pDrawable)
+exaCopyClip(GCPtr pGCDst, GCPtr pGCSrc);
+
+static void
+exaCopyClip(GCPtr pGCDst, GCPtr pGCSrc);
+
+static void
+exaDestroyClip(GCPtr pGC);
+
+const GCFuncs exaGCFuncs = {
+exaValidateGC,
+exaChangeGC,
+exaCopyGC,
+exaDestroyGC,
+exaChangeClip,
+exaDestroyClip,
+exaCopyClip
+};
+
+/*
+ * This wrapper exists to allow fbValidateGC to work.
+ */
+static PixmapPtr
+exaCreatePixmapWithPrepare(ScreenPtr pScreen, int w, int h, int depth,
+ unsigned usage_hint)
+{
+PixmapPtr pPixmap;
+ExaScreenPriv(pScreen);
+
+/* This swaps between this function and the real upper layer function.
+ * Normally this would swap to the fb layer pointer, this is a very
special case.
+ */
+swap(pExaScr, pScreen, CreatePixmap);
+pPixmap = pScreen-CreatePixmap(pScreen, w, h, depth, usage_hint);
+swap(pExaScr, pScreen, CreatePixmap);
+
+if (!pPixmap)
+ return NULL;
+
+/* We use MASK, because SRC is already taken. */
+exaPrepareAccess(pPixmap-drawable, EXA_PREPARE_MASK);
+
+return pPixmap;
+}
+
+static void
+exaValidateGC(GCPtr pGC,
+ unsigned long changes,
+ DrawablePtr pDrawable)
{
/* fbValidateGC will do direct access to pixmaps if the tiling has changed.
- * Preempt fbValidateGC by doing its work and masking the change out, so
- * that we can do the Prepare/FinishAccess.
+ * Do a few smart things so fbValidateGC can do it's work.
*/
-#ifdef FB_24_32BIT
-if ((changes GCTile) fbGetRotatedPixmap(pGC)) {
- (*pGC-pScreen-DestroyPixmap) (fbGetRotatedPixmap(pGC));
- fbGetRotatedPixmap(pGC) = 0;
-}
-
-if (pGC-fillStyle == FillTiled) {
- PixmapPtr pOldTile, pNewTile;
- pOldTile = pGC-tile.pixmap;
- if (pOldTile-drawable.bitsPerPixel != pDrawable-bitsPerPixel)
- {
- pNewTile = fbGetRotatedPixmap(pGC);
- if (!pNewTile ||
- pNewTile -drawable.bitsPerPixel != pDrawable-bitsPerPixel)
- {
- if (pNewTile)
- (*pGC-pScreen-DestroyPixmap) (pNewTile);
- /* fb24_32ReformatTile will do direct access of a newly-
-* allocated pixmap. This isn't a problem yet, since we don't
-* put pixmaps in FB until at least one accelerated EXA op.
-*/
- exaPrepareAccess(pOldTile-drawable, EXA_PREPARE_SRC);
- pNewTile = fb24_32ReformatTile (pOldTile,
- pDrawable-bitsPerPixel);
- exaPixmapDirty(pNewTile, 0, 0, pNewTile-drawable.width,
pNewTile-drawable.height);
- exaFinishAccess(pOldTile-drawable, EXA_PREPARE_SRC);
- }
- if (pNewTile)
- {
- fbGetRotatedPixmap(pGC) = pOldTile;
- pGC-tile.pixmap = pNewTile;
- changes |= GCTile;
- }
- }
+ScreenPtr pScreen = pDrawable-pScreen;
+ExaScreenPriv(pScreen);
+CreatePixmapProcPtr old_ptr = NULL;
+PixmapPtr pTile = NULL;
+EXA_GC_PROLOGUE(pGC);
+if (changes GCTile) {
+ /* save the fb pointer. */
+ old_ptr = pExaScr-SavedCreatePixmap;
+ /* create a new upper layer pointer. */
+ wrap(pExaScr, pScreen, CreatePixmap, exaCreatePixmapWithPrepare);
+ if (pGC-fillStyle == FillTiled)
+ pTile = pGC-tile.pixmap;
+ if (pTile)
+ exaPrepareAccess(pTile-drawable, EXA_PREPARE_SRC);
}
-#endif
+exaPrepareAccessGC(pGC);
+(*pGC-funcs-ValidateGC)(pGC, changes, pDrawable);
+exaFinishAccessGC(pGC);
if (changes GCTile) {
- if (!pGC-tileIsPixel FbEvenTile (pGC-tile.pixmap-drawable.width *
-
[PATCH 5/9] exa: use proper wrapping in exa.c
---
exa/exa.c | 141 ++---
1 files changed, 70 insertions(+), 71 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index 58d1a7d..033b353 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -188,6 +188,7 @@ exaDestroyPixmap (PixmapPtr pPixmap)
{
ScreenPtr pScreen = pPixmap-drawable.pScreen;
ExaScreenPriv(pScreen);
+Bool ret;
if (pPixmap-refcnt == 1)
{
@@ -213,7 +214,12 @@ exaDestroyPixmap (PixmapPtr pPixmap)
REGION_UNINIT(pPixmap-drawable.pScreen, pExaPixmap-validSys);
REGION_UNINIT(pPixmap-drawable.pScreen, pExaPixmap-validFB);
}
-return fbDestroyPixmap (pPixmap);
+
+swap(pExaScr, pScreen, DestroyPixmap);
+ret = pScreen-DestroyPixmap (pPixmap);
+swap(pExaScr, pScreen, DestroyPixmap);
+
+return ret;
}
static int
@@ -286,12 +292,14 @@ exaCreatePixmap(ScreenPtr pScreen, int w, int h, int
depth,
if (w 32767 || h 32767)
return NullPixmap;
+swap(pExaScr, pScreen, CreatePixmap);
if (!pExaScr-info-CreatePixmap) {
-pPixmap = fbCreatePixmap (pScreen, w, h, depth, usage_hint);
+pPixmap = pScreen-CreatePixmap (pScreen, w, h, depth, usage_hint);
} else {
driver_alloc = 1;
-pPixmap = fbCreatePixmap(pScreen, 0, 0, depth, usage_hint);
+pPixmap = pScreen-CreatePixmap(pScreen, 0, 0, depth, usage_hint);
}
+swap(pExaScr, pScreen, CreatePixmap);
if (!pPixmap)
return NULL;
@@ -322,8 +330,10 @@ exaCreatePixmap(ScreenPtr pScreen, int w, int h, int depth,
pExaPixmap-driverPriv = pExaScr-info-CreatePixmap(pScreen,
datasize, 0);
if (!pExaPixmap-driverPriv) {
- fbDestroyPixmap(pPixmap);
- return NULL;
+ swap(pExaScr, pScreen, DestroyPixmap);
+ pScreen-DestroyPixmap (pPixmap);
+ swap(pExaScr, pScreen, DestroyPixmap);
+ return NULL;
}
(*pScreen-ModifyPixmapHeader)(pPixmap, w, h, 0, 0,
@@ -354,8 +364,10 @@ exaCreatePixmap(ScreenPtr pScreen, int w, int h, int depth,
pExaPixmap-fb_size = pExaPixmap-fb_pitch * h;
if (pExaPixmap-fb_pitch 131071) {
-fbDestroyPixmap(pPixmap);
-return NULL;
+ swap(pExaScr, pScreen, DestroyPixmap);
+ pScreen-DestroyPixmap (pPixmap);
+ swap(pExaScr, pScreen, DestroyPixmap);
+ return NULL;
}
/* Set up damage tracking */
@@ -364,7 +376,9 @@ exaCreatePixmap(ScreenPtr pScreen, int w, int h, int depth,
pScreen, pPixmap);
if (pExaPixmap-pDamage == NULL) {
- fbDestroyPixmap (pPixmap);
+ swap(pExaScr, pScreen, DestroyPixmap);
+ pScreen-DestroyPixmap (pPixmap);
+ swap(pExaScr, pScreen, DestroyPixmap);
return NULL;
}
@@ -774,6 +788,8 @@ static Bool
exaChangeWindowAttributes(WindowPtr pWin, unsigned long mask)
{
Bool ret;
+ScreenPtr pScreen = pWin-drawable.pScreen;
+ExaScreenPriv(pScreen);
if ((mask CWBackPixmap) pWin-backgroundState == BackgroundPixmap)
exaPrepareAccess(pWin-background.pixmap-drawable, EXA_PREPARE_SRC);
@@ -781,7 +797,9 @@ exaChangeWindowAttributes(WindowPtr pWin, unsigned long
mask)
if ((mask CWBorderPixmap) pWin-borderIsPixel == FALSE)
exaPrepareAccess(pWin-border.pixmap-drawable, EXA_PREPARE_MASK);
-ret = fbChangeWindowAttributes(pWin, mask);
+swap(pExaScr, pScreen, ChangeWindowAttributes);
+ret = pScreen-ChangeWindowAttributes(pWin, mask);
+swap(pExaScr, pScreen, ChangeWindowAttributes);
if ((mask CWBorderPixmap) pWin-borderIsPixel == FALSE)
exaFinishAccess(pWin-border.pixmap-drawable, EXA_PREPARE_MASK);
@@ -796,9 +814,15 @@ static RegionPtr
exaBitmapToRegion(PixmapPtr pPix)
{
RegionPtr ret;
+ScreenPtr pScreen = pPix-drawable.pScreen;
+ExaScreenPriv(pScreen);
+
exaPrepareAccess(pPix-drawable, EXA_PREPARE_SRC);
-ret = fbPixmapToRegion(pPix);
+swap(pExaScr, pScreen, BitmapToRegion);
+ret = pScreen-BitmapToRegion(pPix);
+swap(pExaScr, pScreen, BitmapToRegion);
exaFinishAccess(pPix-drawable, EXA_PREPARE_SRC);
+
return ret;
}
@@ -809,9 +833,9 @@ exaCreateScreenResources(ScreenPtr pScreen)
PixmapPtr pScreenPixmap;
Bool b;
-pScreen-CreateScreenResources = pExaScr-SavedCreateScreenResources;
+swap(pExaScr, pScreen, CreateScreenResources);
b = pScreen-CreateScreenResources(pScreen);
-pScreen-CreateScreenResources = exaCreateScreenResources;
+swap(pExaScr, pScreen, CreateScreenResources);
if (!b)
return FALSE;
@@ -845,23 +869,26 @@ exaCloseScreen(int i, ScreenPtr pScreen)
if (ps-Glyphs == exaGlyphs)
exaGlyphsFini(pScreen);
-pScreen-CreateGC = pExaScr-SavedCreateGC;
-pScreen-CloseScreen = pExaScr-SavedCloseScreen;
-pScreen-GetImage = pExaScr-SavedGetImage;
-
[PATCH 1/9] exa: Remove one of the many calls directly into the fb layer.
---
exa/exa_accel.c | 32 ++--
1 files changed, 6 insertions(+), 26 deletions(-)
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index f72a08a..b70222a 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -149,6 +149,7 @@ exaDoPutImage (DrawablePtr pDrawable, GCPtr pGC, int depth,
int x, int y,
int xoff, yoff;
int bpp = pDrawable-bitsPerPixel;
Bool access_prepared = FALSE;
+Bool ret = TRUE;
if (pExaPixmap-accel_blocked)
return FALSE;
@@ -210,33 +211,12 @@ exaDoPutImage (DrawablePtr pDrawable, GCPtr pGC, int
depth, int x, int y,
src = bits + (y1 - y) * src_stride + (x1 - x) * (bpp / 8);
ok = pExaScr-info-UploadToScreen(pPix, x1 + xoff, y1 + yoff,
x2 - x1, y2 - y1, src, src_stride);
- /* If we fail to accelerate the upload, fall back to using unaccelerated
-* fb calls.
+ /* We have to fall back completely, and ignore what has already been
completed.
+* Messing with the fb layer directly like we used to is completely
unacceptable.
*/
if (!ok) {
- FbStip *dst;
- FbStride dst_stride;
- int dstBpp;
- int dstXoff, dstYoff;
-
- if (!access_prepared) {
- ExaDoPrepareAccess(pDrawable, EXA_PREPARE_DEST);
-
- access_prepared = TRUE;
- }
-
- fbGetStipDrawable(pDrawable, dst, dst_stride, dstBpp,
- dstXoff, dstYoff);
-
- fbBltStip((FbStip *)bits + (y1 - y) * (src_stride / sizeof(FbStip)),
- src_stride / sizeof(FbStip),
- (x1 - x) * dstBpp,
- dst + (y1 + dstYoff) * dst_stride,
- dst_stride,
- (x1 + dstXoff) * dstBpp,
- (x2 - x1) * dstBpp,
- y2 - y1,
- GXcopy, FB_ALLONES, dstBpp);
+ ret = FALSE;
+ break;
}
}
@@ -245,7 +225,7 @@ exaDoPutImage (DrawablePtr pDrawable, GCPtr pGC, int depth,
int x, int y,
else
exaMarkSync(pDrawable-pScreen);
-return TRUE;
+return ret;
}
static void
--
1.6.1.1
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 2/9] exa: kill of exaImageGlyphBlt
- It serves no obvious purpose, yet it directly accesses many fb
symbols.
---
exa/exa_accel.c | 135 +--
1 files changed, 1 insertions(+), 134 deletions(-)
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index b70222a..10e7914 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -836,139 +836,6 @@ out:
REGION_DESTROY(pScreen, pReg);
}
-static void
-exaImageGlyphBlt (DrawablePtr pDrawable,
- GCPtr pGC,
- int x,
- int y,
- unsigned int nglyph,
- CharInfoPtr *ppciInit,
- pointer pglyphBase)
-{
-FbGCPrivPtrpPriv = fbGetGCPrivate(pGC);
-CharInfoPtr*ppci;
-CharInfoPtrpci;
-unsigned char *pglyph; /* pointer bits in glyph */
-intgWidth, gHeight;/* width and height of glyph */
-FbStride gStride;/* stride of glyph */
-Bool opaque;
-intgx, gy;
-void (*glyph) (FbBits *,
- FbStride,
- int,
- FbStip *,
- FbBits,
- int,
- int);
-FbBits *dst;
-FbStride dstStride;
-intdstBpp;
-intdstXoff, dstYoff;
-FbBits depthMask;
-PixmapPtr pPixmap = exaGetDrawablePixmap(pDrawable);
-ExaPixmapPriv(pPixmap);
-RegionPtr pending_damage = NULL;
-BoxRec extents;
-intxoff, yoff;
-
-if (pExaPixmap-pDamage)
- pending_damage = DamagePendingRegion(pExaPixmap-pDamage);
-
-if (pending_damage) {
- extents = *REGION_EXTENTS(pScreen, pending_damage);
-
- if (extents.x1 = extents.x2 || extents.y1 = extents.y2)
- return;
-
- depthMask = FbFullMask(pDrawable-depth);
-}
-
-if (!pending_damage || (pGC-planemask depthMask) != depthMask)
-{
- ExaCheckImageGlyphBlt(pDrawable, pGC, x, y, nglyph, ppciInit,
pglyphBase);
- return;
-}
-
-glyph = NULL;
-switch (pDrawable-bitsPerPixel) {
-case 8:glyph = fbGlyph8; break;
-case 16:glyph = fbGlyph16; break;
-case 24:glyph = fbGlyph24; break;
-case 32:glyph = fbGlyph32; break;
-}
-
-x += pDrawable-x;
-y += pDrawable-y;
-
-exaGetDrawableDeltas(pDrawable, pPixmap, xoff, yoff);
-extents.x1 -= xoff;
-extents.x2 -= xoff;
-extents.y1 -= yoff;
-extents.y2 -= yoff;
-
-exaPrepareAccessReg (pDrawable, EXA_PREPARE_DEST, pending_damage);
-
-if (TERMINALFONT (pGC-font) !glyph)
-{
- opaque = TRUE;
-}
-else
-{
- FbBits fg = fbReplicatePixel (pGC-bgPixel, pDrawable-bitsPerPixel);
-
- fbSolidBoxClipped (pDrawable,
- fbGetCompositeClip(pGC),
- extents.x1,
- extents.y1,
- extents.x2,
- extents.y2,
- fbAnd (GXcopy, fg, pGC-planemask),
- fbXor (GXcopy, fg, pGC-planemask));
-
- opaque = FALSE;
-}
-
-EXA_FALLBACK((to %p (%c)\n, pDrawable, exaDrawableLocation(pDrawable)));
-
-exaPrepareAccessGC (pGC);
-
-fbGetDrawable (pDrawable, dst, dstStride, dstBpp, dstXoff, dstYoff);
-
-for (ppci = ppciInit; nglyph; nglyph--, x += pci-metrics.characterWidth)
-{
- pci = *ppci++;
- gWidth = GLYPHWIDTHPIXELS(pci);
- gHeight = GLYPHHEIGHTPIXELS(pci);
- gx = x + pci-metrics.leftSideBearing;
- gy = y - pci-metrics.ascent;
-
- if (!gWidth || !gHeight || (gx + gWidth) = extents.x1 ||
- (gy + gHeight) = extents.y1 || gx = extents.x2 ||
- gy = extents.y2)
- continue;
-
- pglyph = FONTGLYPHBITS(pglyphBase, pci);
-
- if (glyph gWidth = sizeof (FbStip) * 8
- fbGlyphIn (fbGetCompositeClip(pGC), gx, gy, gWidth, gHeight))
- {
- (*glyph) (dst + (gy + dstYoff) * dstStride, dstStride, dstBpp,
- (FbStip *) pglyph, pPriv-fg, gx + dstXoff, gHeight);
- }
- else
- {
- RegionPtr pClip = fbGetCompositeClip(pGC);
-
- gStride = GLYPHWIDTHBYTESPADDED(pci) / sizeof (FbStip);
- fbPutXYImage (pDrawable, pClip, pPriv-fg, pPriv-bg, pPriv-pm,
- GXcopy, opaque, gx, gy, gWidth, gHeight,
- (FbStip *) pglyph, gStride, 0);
- }
-}
-exaFinishAccessGC (pGC);
-exaFinishAccess (pDrawable, EXA_PREPARE_DEST);
-}
-
const GCOps exaOps = {
exaFillSpans,
ExaCheckSetSpans,
@@ -987,7 +854,7 @@ const GCOps exaOps = {
miPolyText16,
miImageText8,
miImageText16,
-exaImageGlyphBlt,
+
[PATCH 7/9] exa: create ExaCheckGetImage
---
exa/exa_accel.c |7 +--
exa/exa_priv.h|4
exa/exa_unaccel.c | 30 ++
3 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index 10e7914..02858f1 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -1201,12 +1201,7 @@ exaGetImage (DrawablePtr pDrawable, int x, int y, int w,
int h,
}
fallback:
-EXA_FALLBACK((from %p (%c)\n, pDrawable,
- exaDrawableLocation(pDrawable)));
-
-exaPrepareAccessReg (pDrawable, EXA_PREPARE_SRC, Reg);
-fbGetImage (pDrawable, x, y, w, h, format, planeMask, d);
-exaFinishAccess (pDrawable, EXA_PREPARE_SRC);
+ExaCheckGetImage(pDrawable, x, y, w, h, format, planeMask, d);
out:
REGION_UNINIT(pScreen, Reg);
diff --git a/exa/exa_priv.h b/exa/exa_priv.h
index a41e5fe..6d7c1dd 100644
--- a/exa/exa_priv.h
+++ b/exa/exa_priv.h
@@ -361,6 +361,10 @@ ExaCheckPushPixels (GCPtr pGC, PixmapPtr pBitmap,
int w, int h, int x, int y);
void
+ExaCheckGetImage(DrawablePtr pDrawable, int x, int y, int w, int h,
+ unsigned int format, unsigned long planeMask, char *d);
+
+void
ExaCheckGetSpans (DrawablePtr pDrawable,
int wMax,
DDXPointPtr ppt,
diff --git a/exa/exa_unaccel.c b/exa/exa_unaccel.c
index a521497..e0f2ae9 100644
--- a/exa/exa_unaccel.c
+++ b/exa/exa_unaccel.c
@@ -283,6 +283,36 @@ ExaCheckPushPixels (GCPtr pGC, PixmapPtr pBitmap,
}
void
+ExaCheckGetImage(DrawablePtr pDrawable, int x, int y, int w, int h,
+ unsigned int format, unsigned long planeMask, char *d)
+{
+BoxRec Box;
+RegionRec Reg;
+int xoff, yoff;
+ScreenPtr pScreen = pDrawable-pScreen;
+PixmapPtr pPix = exaGetDrawablePixmap (pDrawable);
+ExaScreenPriv(pScreen);
+
+EXA_FALLBACK((from %p (%c)\n, pDrawable,
+ exaDrawableLocation(pDrawable)));
+
+exaGetDrawableDeltas(pDrawable, pPix, xoff, yoff);
+
+Box.x1 = pDrawable-y + x + xoff;
+Box.y1 = pDrawable-y + y + yoff;
+Box.x2 = Box.x1 + w;
+Box.y2 = Box.y1 + h;
+
+REGION_INIT(pScreen, Reg, Box, 1);
+
+exaPrepareAccessReg (pDrawable, EXA_PREPARE_SRC, Reg);
+swap(pExaScr, pScreen, GetImage);
+pScreen-GetImage (pDrawable, x, y, w, h, format, planeMask, d);
+swap(pExaScr, pScreen, GetImage);
+exaFinishAccess (pDrawable, EXA_PREPARE_SRC);
+}
+
+void
ExaCheckGetSpans (DrawablePtr pDrawable,
int wMax,
DDXPointPtr ppt,
--
1.6.1.1
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 9/9] exa: fix exaCopyArea and friends.
---
exa/Makefile.am |3 ++-
exa/exa_accel.c | 44 ++--
exa/exa_priv.h |6 +-
exa/exa_render.c| 14 --
exa/exa_unaccel.c | 15 +++
fb/fbcopy_helpers.h |5 +
6 files changed, 69 insertions(+), 18 deletions(-)
diff --git a/exa/Makefile.am b/exa/Makefile.am
index 2b3f1e4..f344a05 100644
--- a/exa/Makefile.am
+++ b/exa/Makefile.am
@@ -12,11 +12,12 @@ INCLUDES = \
$(XORG_INCS) \
-I$(srcdir)/../miext/cw
-AM_CFLAGS = $(XORG_CFLAGS) $(DIX_CFLAGS)
+AM_CFLAGS = $(XORG_CFLAGS) $(DIX_CFLAGS) -DEXA_WRAPPER
libexa_la_SOURCES = \
exa.c \
exa.h \
+ ../fb/fbcopy_helpers.c \
exa_accel.c \
exa_glyphs.c \
exa_migration.c \
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index 02858f1..db79cee 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -359,7 +359,7 @@ exaCopyNtoNTwoDir (DrawablePtr pSrcDrawable, DrawablePtr
pDstDrawable,
return TRUE;
}
-void
+Bool
exaCopyNtoN (DrawablePtrpSrcDrawable,
DrawablePtrpDstDrawable,
GCPtr pGC,
@@ -383,7 +383,7 @@ exaCopyNtoN (DrawablePtrpSrcDrawable,
/* avoid doing copy operations if no boxes */
if (nbox == 0)
- return;
+ return TRUE;
pSrcPixmap = exaGetDrawablePixmap (pSrcDrawable);
pDstPixmap = exaGetDrawablePixmap (pDstDrawable);
@@ -492,15 +492,15 @@ exaCopyNtoN (DrawablePtrpSrcDrawable,
goto out;
fallback:
-EXA_FALLBACK((from %p to %p (%c,%c)\n, pSrcDrawable, pDstDrawable,
- exaDrawableLocation(pSrcDrawable),
- exaDrawableLocation(pDstDrawable)));
-exaPrepareAccessReg (pDstDrawable, EXA_PREPARE_DEST, dstregion);
-exaPrepareAccessReg (pSrcDrawable, EXA_PREPARE_SRC, srcregion);
-fbCopyNtoN (pSrcDrawable, pDstDrawable, pGC, pbox, nbox, dx, dy, reverse,
- upsidedown, bitplane, closure);
-exaFinishAccess (pSrcDrawable, EXA_PREPARE_SRC);
-exaFinishAccess (pDstDrawable, EXA_PREPARE_DEST);
+if (dstregion) {
+ REGION_UNINIT(pScreen, dstregion);
+ REGION_DESTROY(pScreen, dstregion);
+}
+if (srcregion) {
+ REGION_UNINIT(pScreen, srcregion);
+ REGION_DESTROY(pScreen, srcregion);
+}
+return FALSE;
out:
if (dstregion) {
@@ -511,6 +511,8 @@ out:
REGION_UNINIT(pScreen, srcregion);
REGION_DESTROY(pScreen, srcregion);
}
+
+return TRUE;
}
RegionPtr
@@ -518,15 +520,25 @@ exaCopyArea(DrawablePtr pSrcDrawable, DrawablePtr
pDstDrawable, GCPtr pGC,
int srcx, int srcy, int width, int height, int dstx, int dsty)
{
ExaScreenPriv (pDstDrawable-pScreen);
+RegionPtr ret;
+Bool success;
if (pExaScr-swappedOut) {
return ExaCheckCopyArea(pSrcDrawable, pDstDrawable, pGC,
srcx, srcy, width, height, dstx, dsty);
}
-return fbDoCopy (pSrcDrawable, pDstDrawable, pGC,
+ret = exaDoCopy (pSrcDrawable, pDstDrawable, pGC,
srcx, srcy, width, height,
- dstx, dsty, exaCopyNtoN, 0, NULL);
+ dstx, dsty, exaCopyNtoN, 0, NULL, success);
+
+if (!success) {
+ xfree(ret);
+ return ExaCheckCopyArea(pSrcDrawable, pDstDrawable, pGC,
+ srcx, srcy, width, height, dstx, dsty);
+}
+
+return ret;
}
static void
@@ -865,6 +877,7 @@ exaCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg,
RegionPtr prgnSrc)
RegionRec rgnDst;
intdx, dy;
PixmapPtr pPixmap = (*pWin-drawable.pScreen-GetWindowPixmap) (pWin);
+Bool ret;
dx = ptOldOrg.x - pWin-drawable.x;
dy = ptOldOrg.y - pWin-drawable.y;
@@ -879,11 +892,14 @@ exaCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg,
RegionPtr prgnSrc)
-pPixmap-screen_x, -pPixmap-screen_y);
#endif
-fbCopyRegion (pPixmap-drawable, pPixmap-drawable,
+ret = exaCopyRegion (pPixmap-drawable, pPixmap-drawable,
NULL,
rgnDst, dx, dy, exaCopyNtoN, 0, NULL);
REGION_UNINIT(pWin-drawable.pScreen, rgnDst);
+
+if (!ret)
+ ExaCheckCopyWindow(pWin, ptOldOrg, prgnSrc);
}
static Bool
diff --git a/exa/exa_priv.h b/exa/exa_priv.h
index 6d7c1dd..c555f85 100644
--- a/exa/exa_priv.h
+++ b/exa/exa_priv.h
@@ -55,6 +55,7 @@
#include glyphstr.h
#endif
#include damage.h
+#include fbcopy_helpers.h
#define DEBUG_TRACE_FALL 0
#define DEBUG_MIGRATE 0
@@ -379,6 +380,9 @@ ExaCheckAddTraps (PicturePtrpPicture,
int ntrap,
xTrap *traps);
+void
+ExaCheckCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg, RegionPtr prgnSrc);
+
/* exa_accel.c */
static _X_INLINE Bool
@@ -465,7 +469,7 @@ RegionPtr
exaCopyArea(DrawablePtr pSrcDrawable, DrawablePtr pDstDrawable, GCPtr pGC,
int srcx, int srcy,
[PATCH 2/9] exa: kill of exaImageGlyphBlt
- It serves no obvious purpose, yet it directly accesses many fb
symbols.
---
exa/exa_accel.c | 135 +--
1 files changed, 1 insertions(+), 134 deletions(-)
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index b70222a..10e7914 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -836,139 +836,6 @@ out:
REGION_DESTROY(pScreen, pReg);
}
-static void
-exaImageGlyphBlt (DrawablePtr pDrawable,
- GCPtr pGC,
- int x,
- int y,
- unsigned int nglyph,
- CharInfoPtr *ppciInit,
- pointer pglyphBase)
-{
-FbGCPrivPtrpPriv = fbGetGCPrivate(pGC);
-CharInfoPtr*ppci;
-CharInfoPtrpci;
-unsigned char *pglyph; /* pointer bits in glyph */
-intgWidth, gHeight;/* width and height of glyph */
-FbStride gStride;/* stride of glyph */
-Bool opaque;
-intgx, gy;
-void (*glyph) (FbBits *,
- FbStride,
- int,
- FbStip *,
- FbBits,
- int,
- int);
-FbBits *dst;
-FbStride dstStride;
-intdstBpp;
-intdstXoff, dstYoff;
-FbBits depthMask;
-PixmapPtr pPixmap = exaGetDrawablePixmap(pDrawable);
-ExaPixmapPriv(pPixmap);
-RegionPtr pending_damage = NULL;
-BoxRec extents;
-intxoff, yoff;
-
-if (pExaPixmap-pDamage)
- pending_damage = DamagePendingRegion(pExaPixmap-pDamage);
-
-if (pending_damage) {
- extents = *REGION_EXTENTS(pScreen, pending_damage);
-
- if (extents.x1 = extents.x2 || extents.y1 = extents.y2)
- return;
-
- depthMask = FbFullMask(pDrawable-depth);
-}
-
-if (!pending_damage || (pGC-planemask depthMask) != depthMask)
-{
- ExaCheckImageGlyphBlt(pDrawable, pGC, x, y, nglyph, ppciInit,
pglyphBase);
- return;
-}
-
-glyph = NULL;
-switch (pDrawable-bitsPerPixel) {
-case 8:glyph = fbGlyph8; break;
-case 16:glyph = fbGlyph16; break;
-case 24:glyph = fbGlyph24; break;
-case 32:glyph = fbGlyph32; break;
-}
-
-x += pDrawable-x;
-y += pDrawable-y;
-
-exaGetDrawableDeltas(pDrawable, pPixmap, xoff, yoff);
-extents.x1 -= xoff;
-extents.x2 -= xoff;
-extents.y1 -= yoff;
-extents.y2 -= yoff;
-
-exaPrepareAccessReg (pDrawable, EXA_PREPARE_DEST, pending_damage);
-
-if (TERMINALFONT (pGC-font) !glyph)
-{
- opaque = TRUE;
-}
-else
-{
- FbBits fg = fbReplicatePixel (pGC-bgPixel, pDrawable-bitsPerPixel);
-
- fbSolidBoxClipped (pDrawable,
- fbGetCompositeClip(pGC),
- extents.x1,
- extents.y1,
- extents.x2,
- extents.y2,
- fbAnd (GXcopy, fg, pGC-planemask),
- fbXor (GXcopy, fg, pGC-planemask));
-
- opaque = FALSE;
-}
-
-EXA_FALLBACK((to %p (%c)\n, pDrawable, exaDrawableLocation(pDrawable)));
-
-exaPrepareAccessGC (pGC);
-
-fbGetDrawable (pDrawable, dst, dstStride, dstBpp, dstXoff, dstYoff);
-
-for (ppci = ppciInit; nglyph; nglyph--, x += pci-metrics.characterWidth)
-{
- pci = *ppci++;
- gWidth = GLYPHWIDTHPIXELS(pci);
- gHeight = GLYPHHEIGHTPIXELS(pci);
- gx = x + pci-metrics.leftSideBearing;
- gy = y - pci-metrics.ascent;
-
- if (!gWidth || !gHeight || (gx + gWidth) = extents.x1 ||
- (gy + gHeight) = extents.y1 || gx = extents.x2 ||
- gy = extents.y2)
- continue;
-
- pglyph = FONTGLYPHBITS(pglyphBase, pci);
-
- if (glyph gWidth = sizeof (FbStip) * 8
- fbGlyphIn (fbGetCompositeClip(pGC), gx, gy, gWidth, gHeight))
- {
- (*glyph) (dst + (gy + dstYoff) * dstStride, dstStride, dstBpp,
- (FbStip *) pglyph, pPriv-fg, gx + dstXoff, gHeight);
- }
- else
- {
- RegionPtr pClip = fbGetCompositeClip(pGC);
-
- gStride = GLYPHWIDTHBYTESPADDED(pci) / sizeof (FbStip);
- fbPutXYImage (pDrawable, pClip, pPriv-fg, pPriv-bg, pPriv-pm,
- GXcopy, opaque, gx, gy, gWidth, gHeight,
- (FbStip *) pglyph, gStride, 0);
- }
-}
-exaFinishAccessGC (pGC);
-exaFinishAccess (pDrawable, EXA_PREPARE_DEST);
-}
-
const GCOps exaOps = {
exaFillSpans,
ExaCheckSetSpans,
@@ -987,7 +854,7 @@ const GCOps exaOps = {
miPolyText16,
miImageText8,
miImageText16,
-exaImageGlyphBlt,
+
[PATCH 8/9] fb: split off a few functions into a seperate file and enhance them slightly.
- Compatibility wrappers, if deemed neccesary will come later. --- fb/Makefile.am |3 +- fb/fb.h | 37 +- fb/fb24_32.c|4 +- fb/fbcopy.c | 342 ++- fb/fbcopy_helpers.c | 367 +++ fb/fbcopy_helpers.h | 52 +++ fb/fboverlay.c |1 + fb/fbwindow.c |5 +- 8 files changed, 448 insertions(+), 363 deletions(-) create mode 100644 fb/fbcopy_helpers.c create mode 100644 fb/fbcopy_helpers.h diff --git a/fb/Makefile.am b/fb/Makefile.am index 64e49f3..cfd9364 100644 --- a/fb/Makefile.am +++ b/fb/Makefile.am @@ -7,7 +7,7 @@ INCLUDES = \ AM_CFLAGS = $(DIX_CFLAGS) if XORG -sdk_HEADERS = fb.h fbrop.h fboverlay.h wfbrename.h fbpict.h +sdk_HEADERS = fb.h fbrop.h fboverlay.h wfbrename.h fbpict.h fbcopy_helpers.h endif libfb_la_CFLAGS = $(AM_CFLAGS) @@ -24,6 +24,7 @@ libfb_la_SOURCES =\ fbbits.h\ fbblt.c \ fbbltone.c \ + fbcopy_helpers.c\ fbcopy.c\ fbfill.c\ fbfillrect.c\ diff --git a/fb/fb.h b/fb/fb.h index 8384315..b0898b0 100644 --- a/fb/fb.h +++ b/fb/fb.h @@ -788,7 +788,7 @@ fb24_32GetImage (DrawablePtr pDrawable, unsigned long planeMask, char*d); -extern _X_EXPORT void +extern _X_EXPORT Bool fb24_32CopyMtoN (DrawablePtr pSrcDrawable, DrawablePtr pDstDrawable, GCPtr pGC, @@ -1306,7 +1306,7 @@ fbInitVisuals (VisualPtr*visualp, * fbcopy.c */ -typedef void (*fbCopyProc) (DrawablePtr pSrcDrawable, +typedef Bool (*fbCopyProc) (DrawablePtr pSrcDrawable, DrawablePtr pDstDrawable, GCPtrpGC, BoxPtr pDstBox, @@ -1318,7 +1318,7 @@ typedef void (*fbCopyProc) (DrawablePtr pSrcDrawable, Pixelbitplane, void *closure); -extern _X_EXPORT void +extern _X_EXPORT Bool fbCopyNtoN (DrawablePtrpSrcDrawable, DrawablePtr pDstDrawable, GCPtr pGC, @@ -1331,7 +1331,7 @@ fbCopyNtoN (DrawablePtr pSrcDrawable, Pixel bitplane, void*closure); -extern _X_EXPORT void +extern _X_EXPORT Bool fbCopy1toN (DrawablePtrpSrcDrawable, DrawablePtr pDstDrawable, GCPtr pGC, @@ -1344,7 +1344,7 @@ fbCopy1toN (DrawablePtr pSrcDrawable, Pixel bitplane, void*closure); -extern _X_EXPORT void +extern _X_EXPORT Bool fbCopyNto1 (DrawablePtrpSrcDrawable, DrawablePtr pDstDrawable, GCPtr pGC, @@ -1357,31 +1357,6 @@ fbCopyNto1 (DrawablePtr pSrcDrawable, Pixel bitplane, void*closure); -extern _X_EXPORT void -fbCopyRegion (DrawablePtr pSrcDrawable, - DrawablePtr pDstDrawable, - GCPtr pGC, - RegionPtr pDstRegion, - int dx, - int dy, - fbCopyProccopyProc, - Pixel bitPlane, - void *closure); - -extern _X_EXPORT RegionPtr -fbDoCopy (DrawablePtr pSrcDrawable, - DrawablePtr pDstDrawable, - GCPtr pGC, - int xIn, - int yIn, - int widthSrc, - int heightSrc, - int xOut, - int yOut, - fbCopyProccopyProc, - Pixel bitplane, - void *closure); - extern _X_EXPORT RegionPtr fbCopyArea (DrawablePtrpSrcDrawable, DrawablePtr pDstDrawable, @@ -2036,7 +2011,7 @@ fbPositionWindow(WindowPtr pWin, int x, int y); extern _X_EXPORT Bool fbUnmapWindow(WindowPtr pWindow); -extern _X_EXPORT void +extern _X_EXPORT Bool fbCopyWindowProc (DrawablePtr pSrcDrawable, DrawablePtr pDstDrawable, GCPtr pGC, diff --git a/fb/fb24_32.c b/fb/fb24_32.c index 1ebd598..952b9ff 100644 --- a/fb/fb24_32.c +++ b/fb/fb24_32.c @@ -472,7 +472,7 @@ fb24_32GetImage (DrawablePtr pDrawable, fbFinishAccess (pDrawable); } -void +Bool fb24_32CopyMtoN (DrawablePtr pSrcDrawable, DrawablePtr pDstDrawable, GCPtr pGC, @@ -529,6 +529,8 @@ fb24_32CopyMtoN (DrawablePtr pSrcDrawable, fbFinishAccess (pSrcDrawable); fbFinishAccess (pDstDrawable); + +return TRUE; } PixmapPtr diff --git a/fb/fbcopy.c b/fb/fbcopy.c index b8b0b6a..2f430b7 100644 --- a/fb/fbcopy.c +++ b/fb/fbcopy.c @@ -27,8 +27,9 @@ #include stdlib.h #include fb.h +#include fbcopy_helpers.h -void +Bool fbCopyNtoN (DrawablePtrpSrcDrawable, DrawablePtr pDstDrawable,
[PATCH 6/9] exa: wrap the remainder of exa_unaccel.c
---
exa/exa_unaccel.c | 30 +++---
1 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/exa/exa_unaccel.c b/exa/exa_unaccel.c
index d56f589..a521497 100644
--- a/exa/exa_unaccel.c
+++ b/exa/exa_unaccel.c
@@ -290,9 +290,14 @@ ExaCheckGetSpans (DrawablePtr pDrawable,
int nspans,
char *pdstStart)
{
+ScreenPtr pScreen = pDrawable-pScreen;
+ExaScreenPriv(pScreen);
+
EXA_FALLBACK((from %p (%c)\n, pDrawable,
exaDrawableLocation(pDrawable)));
exaPrepareAccess (pDrawable, EXA_PREPARE_SRC);
-fbGetSpans (pDrawable, wMax, ppt, pwidth, nspans, pdstStart);
+swap(pExaScr, pScreen, GetSpans);
+pScreen-GetSpans (pDrawable, wMax, ppt, pwidth, nspans, pdstStart);
+swap(pExaScr, pScreen, GetSpans);
exaFinishAccess (pDrawable, EXA_PREPARE_SRC);
}
@@ -310,6 +315,11 @@ ExaCheckComposite (CARD8 op,
CARD16 width,
CARD16 height)
{
+ScreenPtr pScreen = pDst-pDrawable-pScreen;
+#ifdef RENDER
+PictureScreenPtr ps = GetPictureScreen(pScreen);
+#endif /* RENDER */
+ExaScreenPriv(pScreen);
RegionRec region;
int xoff, yoff;
@@ -338,7 +348,9 @@ ExaCheckComposite (CARD8 op,
exaPrepareAccess (pSrc-pDrawable, EXA_PREPARE_SRC);
if (pMask pMask-pDrawable != NULL)
exaPrepareAccess (pMask-pDrawable, EXA_PREPARE_MASK);
-fbComposite (op,
+#ifdef RENDER
+swap(pExaScr, ps, Composite);
+ps-Composite (op,
pSrc,
pMask,
pDst,
@@ -350,6 +362,8 @@ ExaCheckComposite (CARD8 op,
yDst,
width,
height);
+swap(pExaScr, ps, Composite);
+#endif /* RENDER */
if (pMask pMask-pDrawable != NULL)
exaFinishAccess (pMask-pDrawable, EXA_PREPARE_MASK);
if (pSrc-pDrawable != NULL)
@@ -366,10 +380,20 @@ ExaCheckAddTraps (PicturePtr pPicture,
int ntrap,
xTrap *traps)
{
+ScreenPtr pScreen = pPicture-pDrawable-pScreen;
+#ifdef RENDER
+PictureScreenPtr ps = GetPictureScreen(pScreen);
+#endif /* RENDER */
+ExaScreenPriv(pScreen);
+
EXA_FALLBACK((to pict %p (%c)\n,
exaDrawableLocation(pPicture-pDrawable)));
exaPrepareAccess(pPicture-pDrawable, EXA_PREPARE_DEST);
-fbAddTraps (pPicture, x_off, y_off, ntrap, traps);
+#ifdef RENDER
+swap(pExaScr, ps, AddTraps);
+ps-AddTraps (pPicture, x_off, y_off, ntrap, traps);
+swap(pExaScr, ps, AddTraps);
+#endif /* RENDER */
exaFinishAccess(pPicture-pDrawable, EXA_PREPARE_DEST);
}
--
1.6.1.1
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 9/9] exa: fix exaCopyArea and friends.
---
exa/Makefile.am |3 ++-
exa/exa_accel.c | 44 ++--
exa/exa_priv.h |6 +-
exa/exa_render.c| 14 --
exa/exa_unaccel.c | 15 +++
fb/fbcopy_helpers.c |6 +++---
fb/fbcopy_helpers.h | 12 ++--
7 files changed, 77 insertions(+), 23 deletions(-)
diff --git a/exa/Makefile.am b/exa/Makefile.am
index 2b3f1e4..409dd09 100644
--- a/exa/Makefile.am
+++ b/exa/Makefile.am
@@ -12,11 +12,12 @@ INCLUDES = \
$(XORG_INCS) \
-I$(srcdir)/../miext/cw
-AM_CFLAGS = $(XORG_CFLAGS) $(DIX_CFLAGS)
+AM_CFLAGS = $(XORG_CFLAGS) $(DIX_CFLAGS) -DFB_WRAP_PREFIX=exa
libexa_la_SOURCES = \
exa.c \
exa.h \
+ ../fb/fbcopy_helpers.c \
exa_accel.c \
exa_glyphs.c \
exa_migration.c \
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index 02858f1..db79cee 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -359,7 +359,7 @@ exaCopyNtoNTwoDir (DrawablePtr pSrcDrawable, DrawablePtr
pDstDrawable,
return TRUE;
}
-void
+Bool
exaCopyNtoN (DrawablePtrpSrcDrawable,
DrawablePtrpDstDrawable,
GCPtr pGC,
@@ -383,7 +383,7 @@ exaCopyNtoN (DrawablePtrpSrcDrawable,
/* avoid doing copy operations if no boxes */
if (nbox == 0)
- return;
+ return TRUE;
pSrcPixmap = exaGetDrawablePixmap (pSrcDrawable);
pDstPixmap = exaGetDrawablePixmap (pDstDrawable);
@@ -492,15 +492,15 @@ exaCopyNtoN (DrawablePtrpSrcDrawable,
goto out;
fallback:
-EXA_FALLBACK((from %p to %p (%c,%c)\n, pSrcDrawable, pDstDrawable,
- exaDrawableLocation(pSrcDrawable),
- exaDrawableLocation(pDstDrawable)));
-exaPrepareAccessReg (pDstDrawable, EXA_PREPARE_DEST, dstregion);
-exaPrepareAccessReg (pSrcDrawable, EXA_PREPARE_SRC, srcregion);
-fbCopyNtoN (pSrcDrawable, pDstDrawable, pGC, pbox, nbox, dx, dy, reverse,
- upsidedown, bitplane, closure);
-exaFinishAccess (pSrcDrawable, EXA_PREPARE_SRC);
-exaFinishAccess (pDstDrawable, EXA_PREPARE_DEST);
+if (dstregion) {
+ REGION_UNINIT(pScreen, dstregion);
+ REGION_DESTROY(pScreen, dstregion);
+}
+if (srcregion) {
+ REGION_UNINIT(pScreen, srcregion);
+ REGION_DESTROY(pScreen, srcregion);
+}
+return FALSE;
out:
if (dstregion) {
@@ -511,6 +511,8 @@ out:
REGION_UNINIT(pScreen, srcregion);
REGION_DESTROY(pScreen, srcregion);
}
+
+return TRUE;
}
RegionPtr
@@ -518,15 +520,25 @@ exaCopyArea(DrawablePtr pSrcDrawable, DrawablePtr
pDstDrawable, GCPtr pGC,
int srcx, int srcy, int width, int height, int dstx, int dsty)
{
ExaScreenPriv (pDstDrawable-pScreen);
+RegionPtr ret;
+Bool success;
if (pExaScr-swappedOut) {
return ExaCheckCopyArea(pSrcDrawable, pDstDrawable, pGC,
srcx, srcy, width, height, dstx, dsty);
}
-return fbDoCopy (pSrcDrawable, pDstDrawable, pGC,
+ret = exaDoCopy (pSrcDrawable, pDstDrawable, pGC,
srcx, srcy, width, height,
- dstx, dsty, exaCopyNtoN, 0, NULL);
+ dstx, dsty, exaCopyNtoN, 0, NULL, success);
+
+if (!success) {
+ xfree(ret);
+ return ExaCheckCopyArea(pSrcDrawable, pDstDrawable, pGC,
+ srcx, srcy, width, height, dstx, dsty);
+}
+
+return ret;
}
static void
@@ -865,6 +877,7 @@ exaCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg,
RegionPtr prgnSrc)
RegionRec rgnDst;
intdx, dy;
PixmapPtr pPixmap = (*pWin-drawable.pScreen-GetWindowPixmap) (pWin);
+Bool ret;
dx = ptOldOrg.x - pWin-drawable.x;
dy = ptOldOrg.y - pWin-drawable.y;
@@ -879,11 +892,14 @@ exaCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg,
RegionPtr prgnSrc)
-pPixmap-screen_x, -pPixmap-screen_y);
#endif
-fbCopyRegion (pPixmap-drawable, pPixmap-drawable,
+ret = exaCopyRegion (pPixmap-drawable, pPixmap-drawable,
NULL,
rgnDst, dx, dy, exaCopyNtoN, 0, NULL);
REGION_UNINIT(pWin-drawable.pScreen, rgnDst);
+
+if (!ret)
+ ExaCheckCopyWindow(pWin, ptOldOrg, prgnSrc);
}
static Bool
diff --git a/exa/exa_priv.h b/exa/exa_priv.h
index 6d7c1dd..c555f85 100644
--- a/exa/exa_priv.h
+++ b/exa/exa_priv.h
@@ -55,6 +55,7 @@
#include glyphstr.h
#endif
#include damage.h
+#include fbcopy_helpers.h
#define DEBUG_TRACE_FALL 0
#define DEBUG_MIGRATE 0
@@ -379,6 +380,9 @@ ExaCheckAddTraps (PicturePtrpPicture,
int ntrap,
xTrap *traps);
+void
+ExaCheckCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg, RegionPtr prgnSrc);
+
/* exa_accel.c */
static _X_INLINE Bool
@@ -465,7 +469,7 @@ RegionPtr
exaCopyArea(DrawablePtr pSrcDrawable, DrawablePtr
Re: about the exa patches
On Wed, Feb 4, 2009 at 8:32 AM, Michel Dänzer mic...@daenzer.net wrote: On Wed, 2009-02-04 at 00:29 +0100, Maarten Maathuis wrote: I hope the changes are coming to an end. I still need to know if there are any external users of fbDoCopy that would care for a wrapper. I'm assuming that functions that changed their return value from void to Bool pose no issue, but you're welcome to explain if it's not. @MrCooper: the approach of patch 8 and 9 is ok by you? I definitely like the reuse of fbCopyRegion and fbDoCopy; the only minor niggle I have there would be to replace EXA_WRAPPER with something more generic like FB_WRAP_PREFIX, and then #ifdef FB_WRAP_PREFIX #define fbCopyRegion FB_WRAP_PREFIX##CopyRegion #define fbDoCopy FB_WRAP_PREFIX##DoCopy #endif I'd like the fb changes to be reviewed by an fb hacker. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer I sent a new version of patch 9 to the list, the macro turned out to be slightly more complex, i also made it a little more clear that the function names are variable. I don't know if there are any fb hackers, but i agree someone should judge the changes. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 9/9] exa: don't use fbCopyNtoN
---
exa/exa_accel.c | 43 ---
exa/exa_priv.h| 16
exa/exa_render.c | 17 +
exa/exa_unaccel.c | 27 +++
4 files changed, 84 insertions(+), 19 deletions(-)
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index cc5dd18..b66b1da 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -359,8 +359,8 @@ exaCopyNtoNTwoDir (DrawablePtr pSrcDrawable, DrawablePtr
pDstDrawable,
return TRUE;
}
-void
-exaCopyNtoN (DrawablePtrpSrcDrawable,
+Bool
+exaHWCopyNtoN (DrawablePtrpSrcDrawable,
DrawablePtrpDstDrawable,
GCPtr pGC,
BoxPtr pbox,
@@ -368,9 +368,7 @@ exaCopyNtoN (DrawablePtrpSrcDrawable,
intdx,
intdy,
Bool reverse,
-Bool upsidedown,
-Pixel bitplane,
-void *closure)
+Bool upsidedown)
{
ExaScreenPriv (pDstDrawable-pScreen);
PixmapPtr pSrcPixmap, pDstPixmap;
@@ -380,10 +378,11 @@ exaCopyNtoN (DrawablePtrpSrcDrawable,
ExaMigrationRec pixmaps[2];
RegionPtr srcregion = NULL, dstregion = NULL;
xRectangle *rects;
+Bool ret = TRUE;
/* avoid doing copy operations if no boxes */
if (nbox == 0)
- return;
+ return TRUE;
pSrcPixmap = exaGetDrawablePixmap (pSrcDrawable);
pDstPixmap = exaGetDrawablePixmap (pDstDrawable);
@@ -492,15 +491,7 @@ exaCopyNtoN (DrawablePtrpSrcDrawable,
goto out;
fallback:
-EXA_FALLBACK((from %p to %p (%c,%c)\n, pSrcDrawable, pDstDrawable,
- exaDrawableLocation(pSrcDrawable),
- exaDrawableLocation(pDstDrawable)));
-exaPrepareAccessReg (pDstDrawable, EXA_PREPARE_DEST, dstregion);
-exaPrepareAccessReg (pSrcDrawable, EXA_PREPARE_SRC, srcregion);
-fbCopyNtoN (pSrcDrawable, pDstDrawable, pGC, pbox, nbox, dx, dy, reverse,
- upsidedown, bitplane, closure);
-exaFinishAccess (pSrcDrawable, EXA_PREPARE_SRC);
-exaFinishAccess (pDstDrawable, EXA_PREPARE_DEST);
+ret = FALSE;
out:
if (dstregion) {
@@ -511,6 +502,28 @@ out:
REGION_UNINIT(pScreen, srcregion);
REGION_DESTROY(pScreen, srcregion);
}
+
+return ret;
+}
+
+void
+exaCopyNtoN (DrawablePtrpSrcDrawable,
+DrawablePtrpDstDrawable,
+GCPtr pGC,
+BoxPtr pbox,
+intnbox,
+intdx,
+intdy,
+Bool reverse,
+Bool upsidedown,
+Pixel bitplane,
+void *closure)
+{
+if (exaHWCopyNtoN(pSrcDrawable, pDstDrawable, pGC, pbox, nbox, dx, dy,
reverse, upsidedown))
+ return;
+
+/* fallback */
+ExaCheckCopyNtoN(pSrcDrawable, pDstDrawable, pGC, pbox, nbox, dx, dy,
reverse, upsidedown, bitplane, closure);
}
RegionPtr
diff --git a/exa/exa_priv.h b/exa/exa_priv.h
index 6d7c1dd..13de499 100644
--- a/exa/exa_priv.h
+++ b/exa/exa_priv.h
@@ -316,6 +316,11 @@ ExaCheckPutImage (DrawablePtr pDrawable, GCPtr pGC, int
depth,
int x, int y, int w, int h, int leftPad, int format,
char *bits);
+void
+ExaCheckCopyNtoN (DrawablePtr pSrc, DrawablePtr pDst, GCPtr pGC,
+BoxPtr pbox, int nbox, int dx, int dy, Boolreverse,
+Bool upsidedown, Pixel bitplane, void *closure);
+
RegionPtr
ExaCheckCopyArea (DrawablePtr pSrc, DrawablePtr pDst, GCPtr pGC,
int srcx, int srcy, int w, int h, int dstx, int dsty);
@@ -465,6 +470,17 @@ RegionPtr
exaCopyArea(DrawablePtr pSrcDrawable, DrawablePtr pDstDrawable, GCPtr pGC,
int srcx, int srcy, int width, int height, int dstx, int dsty);
+Bool
+exaHWCopyNtoN (DrawablePtrpSrcDrawable,
+DrawablePtrpDstDrawable,
+GCPtr pGC,
+BoxPtr pbox,
+intnbox,
+intdx,
+intdy,
+Bool reverse,
+Bool upsidedown);
+
void
exaCopyNtoN (DrawablePtrpSrcDrawable,
DrawablePtrpDstDrawable,
diff --git a/exa/exa_render.c b/exa/exa_render.c
index 63ea5c1..1788531 100644
--- a/exa/exa_render.c
+++ b/exa/exa_render.c
@@ -851,6 +851,7 @@ exaComposite(CARD8 op,
!pSrc-repeat
!pSrc-transform)
{
+ Bool ret;
xDst += pDst-pDrawable-x;
yDst += pDst-pDrawable-y;
xSrc += pSrc-pDrawable-x;
@@ -861,12 +862,20 @@ exaComposite(CARD8op,
yDst, width, height))
goto done;
-
- exaCopyNtoN (pSrc-pDrawable, pDst-pDrawable, NULL,
+ ret =
[PATCH 8/9] fb: move some code to mi
---
exa/exa_accel.c |4 +-
fb/fb.h | 37 --
fb/fbcopy.c | 331 +--
fb/fboverlay.c |2 +-
fb/fboverlay.h |2 +-
fb/fbwindow.c |2 +-
mi/Makefile.am |1 +
mi/mi.h | 42 +++
mi/micopy.c | 354 +++
9 files changed, 406 insertions(+), 369 deletions(-)
create mode 100644 mi/micopy.c
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index 02858f1..cc5dd18 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -524,7 +524,7 @@ exaCopyArea(DrawablePtr pSrcDrawable, DrawablePtr
pDstDrawable, GCPtr pGC,
srcx, srcy, width, height, dstx, dsty);
}
-return fbDoCopy (pSrcDrawable, pDstDrawable, pGC,
+return miDoCopy (pSrcDrawable, pDstDrawable, pGC,
srcx, srcy, width, height,
dstx, dsty, exaCopyNtoN, 0, NULL);
}
@@ -879,7 +879,7 @@ exaCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg,
RegionPtr prgnSrc)
-pPixmap-screen_x, -pPixmap-screen_y);
#endif
-fbCopyRegion (pPixmap-drawable, pPixmap-drawable,
+miCopyRegion (pPixmap-drawable, pPixmap-drawable,
NULL,
rgnDst, dx, dy, exaCopyNtoN, 0, NULL);
diff --git a/fb/fb.h b/fb/fb.h
index 8384315..cadb9a0 100644
--- a/fb/fb.h
+++ b/fb/fb.h
@@ -1306,18 +1306,6 @@ fbInitVisuals (VisualPtr*visualp,
* fbcopy.c
*/
-typedef void (*fbCopyProc) (DrawablePtr pSrcDrawable,
- DrawablePtr pDstDrawable,
- GCPtrpGC,
- BoxPtr pDstBox,
- int nbox,
- int dx,
- int dy,
- Bool reverse,
- Bool upsidedown,
- Pixelbitplane,
- void *closure);
-
extern _X_EXPORT void
fbCopyNtoN (DrawablePtrpSrcDrawable,
DrawablePtr pDstDrawable,
@@ -1357,31 +1345,6 @@ fbCopyNto1 (DrawablePtr pSrcDrawable,
Pixel bitplane,
void*closure);
-extern _X_EXPORT void
-fbCopyRegion (DrawablePtr pSrcDrawable,
- DrawablePtr pDstDrawable,
- GCPtr pGC,
- RegionPtr pDstRegion,
- int dx,
- int dy,
- fbCopyProccopyProc,
- Pixel bitPlane,
- void *closure);
-
-extern _X_EXPORT RegionPtr
-fbDoCopy (DrawablePtr pSrcDrawable,
- DrawablePtr pDstDrawable,
- GCPtr pGC,
- int xIn,
- int yIn,
- int widthSrc,
- int heightSrc,
- int xOut,
- int yOut,
- fbCopyProccopyProc,
- Pixel bitplane,
- void *closure);
-
extern _X_EXPORT RegionPtr
fbCopyArea (DrawablePtrpSrcDrawable,
DrawablePtr pDstDrawable,
diff --git a/fb/fbcopy.c b/fb/fbcopy.c
index b8b0b6a..fed87a5 100644
--- a/fb/fbcopy.c
+++ b/fb/fbcopy.c
@@ -289,329 +289,6 @@ fbCopyNto1 (DrawablePtr pSrcDrawable,
}
}
-void
-fbCopyRegion (DrawablePtr pSrcDrawable,
- DrawablePtr pDstDrawable,
- GCPtr pGC,
- RegionPtr pDstRegion,
- int dx,
- int dy,
- fbCopyProccopyProc,
- Pixel bitPlane,
- void *closure)
-{
-intcareful;
-Bool reverse;
-Bool upsidedown;
-BoxPtr pbox;
-intnbox;
-BoxPtr pboxNew1, pboxNew2, pboxBase, pboxNext, pboxTmp;
-
-pbox = REGION_RECTS(pDstRegion);
-nbox = REGION_NUM_RECTS(pDstRegion);
-
-/* XXX we have to err on the side of safety when both are windows,
- * because we don't know if IncludeInferiors is being used.
- */
-careful = ((pSrcDrawable == pDstDrawable) ||
- ((pSrcDrawable-type == DRAWABLE_WINDOW)
- (pDstDrawable-type == DRAWABLE_WINDOW)));
-
-pboxNew1 = NULL;
-pboxNew2 = NULL;
-if (careful dy 0)
-{
- upsidedown = TRUE;
-
- if (nbox 1)
- {
- /* keep ordering in each band, reverse order of bands */
- pboxNew1 = (BoxPtr)xalloc(sizeof(BoxRec) * nbox);
- if(!pboxNew1)
- return;
- pboxBase = pboxNext = pbox+nbox-1;
- while (pboxBase = pbox)
- {
- while ((pboxNext = pbox)
- (pboxBase-y1 == pboxNext-y1))
- pboxNext--;
- pboxTmp = pboxNext+1;
- while (pboxTmp = pboxBase)
-
Re: XCopyArea clip bug
On Wed, Feb 4, 2009 at 10:56 PM, Alexander Larsson al...@redhat.com wrote: On Wed, 2009-02-04 at 14:46 +0100, Alexander Larsson wrote: On Wed, 2009-02-04 at 13:38 +0100, Alexander Larsson wrote: I found what I think is a bug in XCopyArea. If you copy a pixmap to a window and some of the copied area is outside the pixmap then that area in the destination window is cleared to the background color (and possibly graphics exposes are sent). If the GC has a clip region set so that the destination area that would contain data from outside the pixmap is clipped out, then I would expect it to not be cleared. However, that is not the case right now, even the clipped out area has the destination cleared to the window background. I'm attaching an xlib example. Oh, the same thing happens if the source is another window and not a pixmap. I saw this reply in the archives: http://lists.freedesktop.org/archives/xorg/2009-February/043340.html But i don't see in in my inbox, dunno what happened to it. Anyway, the screenshot in that mail is correct. (The red part is the background set when copying from an obscured source, and its correctly clipped so its only visible in the left half of the window. When I run it I see red in the right half, while the green part is correctly clipped.) This is the (xserver) patch i used to achieve this, someone needs to ack the change obviously. miComputeCompositeClip also uses clientClip as a region when != CT_NONE, but there are more types. /* clientClipType field in GC */ #define CT_NONE 0 #define CT_PIXMAP 1 #define CT_REGION 2 #define CT_UNSORTED 6 #define CT_YSORTED 10 #define CT_YXSORTED 14 #define CT_YXBANDED 18 So either miCompositeClip is wrong, or i'm misunderstanding the situation. Especially CT_PIXMAP is certainly not a region. Maarten. clip.patch Description: Binary data ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: about the exa patches
On Thu, Feb 5, 2009 at 7:13 PM, Michel Dänzer mic...@daenzer.net wrote: On Thu, 2009-02-05 at 17:17 +0100, Maarten Maathuis wrote: core glyphs before and after are within an error margin of 1%. Cool, thanks for verifying it. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer The new patches are ok? Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 9/9] exa: don't use fbCopyNtoN
---
exa/exa_accel.c | 77 ++--
exa/exa_priv.h| 25 +
exa/exa_render.c | 17 +---
exa/exa_unaccel.c | 51 +++
4 files changed, 151 insertions(+), 19 deletions(-)
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index cc5dd18..afdeaac 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -359,8 +359,8 @@ exaCopyNtoNTwoDir (DrawablePtr pSrcDrawable, DrawablePtr
pDstDrawable,
return TRUE;
}
-void
-exaCopyNtoN (DrawablePtrpSrcDrawable,
+Bool
+exaHWCopyNtoN (DrawablePtrpSrcDrawable,
DrawablePtrpDstDrawable,
GCPtr pGC,
BoxPtr pbox,
@@ -368,9 +368,7 @@ exaCopyNtoN (DrawablePtrpSrcDrawable,
intdx,
intdy,
Bool reverse,
-Bool upsidedown,
-Pixel bitplane,
-void *closure)
+Bool upsidedown)
{
ExaScreenPriv (pDstDrawable-pScreen);
PixmapPtr pSrcPixmap, pDstPixmap;
@@ -380,10 +378,11 @@ exaCopyNtoN (DrawablePtrpSrcDrawable,
ExaMigrationRec pixmaps[2];
RegionPtr srcregion = NULL, dstregion = NULL;
xRectangle *rects;
+Bool ret = TRUE;
/* avoid doing copy operations if no boxes */
if (nbox == 0)
- return;
+ return TRUE;
pSrcPixmap = exaGetDrawablePixmap (pSrcDrawable);
pDstPixmap = exaGetDrawablePixmap (pDstDrawable);
@@ -492,15 +491,7 @@ exaCopyNtoN (DrawablePtrpSrcDrawable,
goto out;
fallback:
-EXA_FALLBACK((from %p to %p (%c,%c)\n, pSrcDrawable, pDstDrawable,
- exaDrawableLocation(pSrcDrawable),
- exaDrawableLocation(pDstDrawable)));
-exaPrepareAccessReg (pDstDrawable, EXA_PREPARE_DEST, dstregion);
-exaPrepareAccessReg (pSrcDrawable, EXA_PREPARE_SRC, srcregion);
-fbCopyNtoN (pSrcDrawable, pDstDrawable, pGC, pbox, nbox, dx, dy, reverse,
- upsidedown, bitplane, closure);
-exaFinishAccess (pSrcDrawable, EXA_PREPARE_SRC);
-exaFinishAccess (pDstDrawable, EXA_PREPARE_DEST);
+ret = FALSE;
out:
if (dstregion) {
@@ -511,6 +502,53 @@ out:
REGION_UNINIT(pScreen, srcregion);
REGION_DESTROY(pScreen, srcregion);
}
+
+return ret;
+}
+
+void
+exaCopyNtoN (DrawablePtrpSrcDrawable,
+DrawablePtrpDstDrawable,
+GCPtr pGC,
+BoxPtr pbox,
+intnbox,
+intdx,
+intdy,
+Bool reverse,
+Bool upsidedown,
+Pixel bitplane,
+void *closure)
+{
+PixmapPtr pPixmap = exaGetDrawablePixmap(pDstDrawable);
+ExaPixmapPriv(pPixmap);
+
+if (pExaPixmap-fallback_flags EXA_FALLBACK_COPYWINDOW)
+ return;
+
+if (exaHWCopyNtoN(pSrcDrawable, pDstDrawable, pGC, pbox, nbox, dx, dy,
reverse, upsidedown))
+ return;
+
+/* This is a CopyWindow, it's cleaner to fallback at the original call. */
+if (pExaPixmap-fallback_flags EXA_ACCEL_COPYWINDOW) {
+ pExaPixmap-fallback_flags |= EXA_FALLBACK_COPYWINDOW;
+ return;
+}
+
+/* We need a pGC to call our fallback. */
+if (!pGC) {
+ pExaPixmap-fallback_flags |= EXA_FALLBACK_NOGC;
+ pGC = CreateScratchGC(pDstDrawable-pScreen, pDstDrawable-depth);
+ if (!pGC)
+ return;
+}
+
+/* fallback */
+ExaCheckCopyNtoN(pSrcDrawable, pDstDrawable, pGC, pbox, nbox, dx, dy,
reverse, upsidedown, bitplane, closure);
+
+if (pExaPixmap-fallback_flags EXA_FALLBACK_NOGC) {
+ pExaPixmap-fallback_flags = ~EXA_FALLBACK_NOGC;
+ FreeScratchGC(pGC);
+}
}
RegionPtr
@@ -865,6 +903,7 @@ exaCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg,
RegionPtr prgnSrc)
RegionRec rgnDst;
intdx, dy;
PixmapPtr pPixmap = (*pWin-drawable.pScreen-GetWindowPixmap) (pWin);
+ExaPixmapPriv(pPixmap);
dx = ptOldOrg.x - pWin-drawable.x;
dy = ptOldOrg.y - pWin-drawable.y;
@@ -879,11 +918,19 @@ exaCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg,
RegionPtr prgnSrc)
-pPixmap-screen_x, -pPixmap-screen_y);
#endif
+pExaPixmap-fallback_flags |= EXA_ACCEL_COPYWINDOW;
miCopyRegion (pPixmap-drawable, pPixmap-drawable,
NULL,
rgnDst, dx, dy, exaCopyNtoN, 0, NULL);
+pExaPixmap-fallback_flags = ~EXA_ACCEL_COPYWINDOW;
REGION_UNINIT(pWin-drawable.pScreen, rgnDst);
+
+if (pExaPixmap-fallback_flags EXA_FALLBACK_COPYWINDOW) {
+ pExaPixmap-fallback_flags = ~EXA_FALLBACK_COPYWINDOW;
+ REGION_TRANSLATE(pWin-drawable.pScreen, prgnSrc, dx, dy);
+ ExaCheckCopyWindow(pWin, ptOldOrg, prgnSrc);
+}
}
static Bool
diff --git a/exa/exa_priv.h b/exa/exa_priv.h
index 6d7c1dd..bcb9c66
Re: about the exa patches
On Thu, Feb 5, 2009 at 7:28 PM, Michel Dänzer mic...@daenzer.net wrote: On Thu, 2009-02-05 at 19:16 +0100, Maarten Maathuis wrote: On Thu, Feb 5, 2009 at 7:13 PM, Michel Dänzer mic...@daenzer.net wrote: On Thu, 2009-02-05 at 17:17 +0100, Maarten Maathuis wrote: core glyphs before and after are within an error margin of 1%. Cool, thanks for verifying it. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer (BTW, please trim irrelevant parts of what you're quoting) The new patches are ok? I can't say, Adam? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer I just sent the hopefully final version of the last exa (number 9) patch, i used your suggestion to use exa's pixmap priv to store data with regards to fallback. I've run this version with my driver forcing fallbacks everywhere. If you (Michel) are ok with the style, i'll push the whole patch series. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Patch noise [Was: GIT Noise]
On Fri, Feb 6, 2009 at 1:21 PM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote: 2009/2/6 Maarten Maathuis: If you were really seeing a duplicate of a git commit list, then you would see a whole different picture. For you patches may just be noise, but that's not the case for everyone. So ok then, what is the purpose of posting thousands of patches to xorg list? Cheers, Igor It gives people time to check, review and/or complain about patches. Now that the xorg-devel list was made, it will obviously move there. I certainly check patches that catch my eye (a small fraction of the total, i admit). Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Patch noise [Was: GIT Noise]
On Fri, Feb 6, 2009 at 4:21 PM, Igor Mozolevsky i...@hybrid-lab.co.uk wrote: 2009/2/6 Maarten Maathuis: It gives people time to check, review and/or complain about patches. Now that the xorg-devel list was made, it will obviously move there. I certainly check patches that catch my eye (a small fraction of the total, i admit). Does one not submit patches to the maintainer for the sub-project anymore?.. Igor :-) Not all subprojects have a clear maintainer, the xserver is one of those (imo). It's more of a someone who happens to have written that piece of code for it situation. In my case i'd like to get large changes right the first time, i obviously don't send patches for every little thing. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH 9/9] exa: don't use fbCopyNtoN
---
exa/exa_accel.c | 76 ++--
exa/exa_priv.h| 25 +
exa/exa_render.c | 17 +---
exa/exa_unaccel.c | 50 ++
4 files changed, 149 insertions(+), 19 deletions(-)
diff --git a/exa/exa_accel.c b/exa/exa_accel.c
index cc5dd18..326720f 100644
--- a/exa/exa_accel.c
+++ b/exa/exa_accel.c
@@ -359,8 +359,8 @@ exaCopyNtoNTwoDir (DrawablePtr pSrcDrawable, DrawablePtr
pDstDrawable,
return TRUE;
}
-void
-exaCopyNtoN (DrawablePtrpSrcDrawable,
+Bool
+exaHWCopyNtoN (DrawablePtrpSrcDrawable,
DrawablePtrpDstDrawable,
GCPtr pGC,
BoxPtr pbox,
@@ -368,9 +368,7 @@ exaCopyNtoN (DrawablePtrpSrcDrawable,
intdx,
intdy,
Bool reverse,
-Bool upsidedown,
-Pixel bitplane,
-void *closure)
+Bool upsidedown)
{
ExaScreenPriv (pDstDrawable-pScreen);
PixmapPtr pSrcPixmap, pDstPixmap;
@@ -380,10 +378,11 @@ exaCopyNtoN (DrawablePtrpSrcDrawable,
ExaMigrationRec pixmaps[2];
RegionPtr srcregion = NULL, dstregion = NULL;
xRectangle *rects;
+Bool ret = TRUE;
/* avoid doing copy operations if no boxes */
if (nbox == 0)
- return;
+ return TRUE;
pSrcPixmap = exaGetDrawablePixmap (pSrcDrawable);
pDstPixmap = exaGetDrawablePixmap (pDstDrawable);
@@ -492,15 +491,7 @@ exaCopyNtoN (DrawablePtrpSrcDrawable,
goto out;
fallback:
-EXA_FALLBACK((from %p to %p (%c,%c)\n, pSrcDrawable, pDstDrawable,
- exaDrawableLocation(pSrcDrawable),
- exaDrawableLocation(pDstDrawable)));
-exaPrepareAccessReg (pDstDrawable, EXA_PREPARE_DEST, dstregion);
-exaPrepareAccessReg (pSrcDrawable, EXA_PREPARE_SRC, srcregion);
-fbCopyNtoN (pSrcDrawable, pDstDrawable, pGC, pbox, nbox, dx, dy, reverse,
- upsidedown, bitplane, closure);
-exaFinishAccess (pSrcDrawable, EXA_PREPARE_SRC);
-exaFinishAccess (pDstDrawable, EXA_PREPARE_DEST);
+ret = FALSE;
out:
if (dstregion) {
@@ -511,6 +502,52 @@ out:
REGION_UNINIT(pScreen, srcregion);
REGION_DESTROY(pScreen, srcregion);
}
+
+return ret;
+}
+
+void
+exaCopyNtoN (DrawablePtrpSrcDrawable,
+DrawablePtrpDstDrawable,
+GCPtr pGC,
+BoxPtr pbox,
+intnbox,
+intdx,
+intdy,
+Bool reverse,
+Bool upsidedown,
+Pixel bitplane,
+void *closure)
+{
+ExaScreenPriv(pDstDrawable-pScreen);
+
+if (pExaScr-fallback_flags EXA_FALLBACK_COPYWINDOW)
+ return;
+
+if (exaHWCopyNtoN(pSrcDrawable, pDstDrawable, pGC, pbox, nbox, dx, dy,
reverse, upsidedown))
+ return;
+
+/* This is a CopyWindow, it's cleaner to fallback at the original call. */
+if (pExaScr-fallback_flags EXA_ACCEL_COPYWINDOW) {
+ pExaScr-fallback_flags |= EXA_FALLBACK_COPYWINDOW;
+ return;
+}
+
+/* We need a pGC to call our fallback. */
+if (!pGC) {
+ pExaScr-fallback_flags |= EXA_FALLBACK_NOGC;
+ pGC = CreateScratchGC(pDstDrawable-pScreen, pDstDrawable-depth);
+ if (!pGC)
+ return;
+}
+
+/* fallback */
+ExaCheckCopyNtoN(pSrcDrawable, pDstDrawable, pGC, pbox, nbox, dx, dy,
reverse, upsidedown, bitplane, closure);
+
+if (pExaScr-fallback_flags EXA_FALLBACK_NOGC) {
+ pExaScr-fallback_flags = ~EXA_FALLBACK_NOGC;
+ FreeScratchGC(pGC);
+}
}
RegionPtr
@@ -865,6 +902,7 @@ exaCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg,
RegionPtr prgnSrc)
RegionRec rgnDst;
intdx, dy;
PixmapPtr pPixmap = (*pWin-drawable.pScreen-GetWindowPixmap) (pWin);
+ExaScreenPriv(pWin-drawable.pScreen);
dx = ptOldOrg.x - pWin-drawable.x;
dy = ptOldOrg.y - pWin-drawable.y;
@@ -879,11 +917,19 @@ exaCopyWindow(WindowPtr pWin, DDXPointRec ptOldOrg,
RegionPtr prgnSrc)
-pPixmap-screen_x, -pPixmap-screen_y);
#endif
+pExaScr-fallback_flags |= EXA_ACCEL_COPYWINDOW;
miCopyRegion (pPixmap-drawable, pPixmap-drawable,
NULL,
rgnDst, dx, dy, exaCopyNtoN, 0, NULL);
+pExaScr-fallback_flags = ~EXA_ACCEL_COPYWINDOW;
REGION_UNINIT(pWin-drawable.pScreen, rgnDst);
+
+if (pExaScr-fallback_flags EXA_FALLBACK_COPYWINDOW) {
+ pExaScr-fallback_flags = ~EXA_FALLBACK_COPYWINDOW;
+ REGION_TRANSLATE(pWin-drawable.pScreen, prgnSrc, dx, dy);
+ ExaCheckCopyWindow(pWin, ptOldOrg, prgnSrc);
+}
}
static Bool
diff --git a/exa/exa_priv.h b/exa/exa_priv.h
index 6d7c1dd..588fdec 100644
--- a/exa/exa_priv.h
+++ b/exa/exa_priv.h
@@ -127,6
Re: XCopyArea clip bug
I comitted a slightly different patch. I found out that all clipping possibilities are converted to regions in the end, so this should be enough. http://cgit.freedesktop.org/xorg/xserver/commit/?id=00226d0b589595cdd45c75e7e28237334a8883b1 You can put the patch on the wiki (http://wiki.x.org/wiki/Server16Branch) for xserver 1.6 inclusion if you are seriously bothered by the issue. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 8/9] fb: move some code to mi
I'll wait a bit to see what the preferred solution is, but i see three options atm. - A wrapper function in fbcopy.c - A define in fb.h, silently converting fbFoo into miFoo - User side fixes Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 8/9] fb: move some code to mi
commit 734b23e5982e171031077a2d5d6b5dc2a12e1a70 should fix the problem. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: openSUSE 11.1 and Intel graphics chip
Maybe try the http://lists.freedesktop.org/mailman/listinfo/intel-gfx list? Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] 64-bit issues in libx11
While we're on this subject, i have a question as well (same file, line 175). if(event) widen(event_sequence, event-full_sequence); What purpose does that serve? Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] 64-bit issues in libx11
Committed as
http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=da6bbca07c796c69172a649405474f03bee66754
Please provide git patches in the future (it's easier for both sides).
Maarten.
On Fri, Feb 20, 2009 at 3:10 AM, Emilio Jesús Gallego Arias
egall...@babel.ls.fi.upm.es wrote:
It seems xcb/x11 have some bugs related to sizeof(long), in concrete
using 32 bit variables for dpy-request et al in AMD64.
This patch fixes some crashes for me.
diff -ur libx11-1.1.99.2/src/xcb_io.c libx11-1.1.99.2-a/src/xcb_io.c
--- libx11-1.1.99.2/src/xcb_io.c2008-11-04 20:52:54.0 +0100
+++ libx11-1.1.99.2-a/src/xcb_io.c 2009-02-20 02:58:02.0 +0100
@@ -214,7 +214,7 @@
}
else if(req xcb_poll_for_reply(dpy-xcb-connection,
req-sequence, reply, error))
{
- unsigned int sequence = req-sequence;
+ uint64_t sequence = req-sequence;
if(!reply)
{
dpy-xcb-pending_requests = req-next;
@@ -300,7 +300,7 @@
* we need to remember to check later. */
if(dpy-xcb-event_owner != XlibOwnsEventQueue || dpy-async_handlers)
{
- unsigned int sequence;
+ uint64_t sequence;
for(sequence = dpy-xcb-last_flushed; sequence
dpy-request; ++sequence)
{
PendingRequest *req = malloc(sizeof(PendingRequest));
I've used uint64_t instead unsigned long as it seems preferred through the
codebase.
Note that both req-sequence and dpy-request are defined as unsigned long.
Regards,
Emilio
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to shift color bits in fbdev?
You could hack wrapped fb support into the fbdev driver, but that will only work for software rendering in X. And you'll loose some performance because every pixel access goes through a wrapper The vermillion driver has a simple wfb implementation http://cgit.freedesktop.org/xorg/driver/xf86-video-vermilion/tree/src/vermilion.c Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to shift color bits in fbdev?
Several things i see. 1: you are throwing away bits in the colors 2: you should undo the mangling in the read function (the system doesn't understand your strange layout) 3: the alpha channel is in the upper 8 bits on little endian systems (typically) for A8R8G8B 4: read/write are used by more pixmaps than just the ones going to your videocard, you need to check if devPrivate.ptr lies in your fontbuffer range or you need to make a list (6 entries will be more than enough) in wrap and check in read/write to be sure (this is because pixman (sw rendering library) is shared between the xserver and cairo) 5: you only support A/XRGB pixmaps (no 8 or 16 bits formats)? Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
You can argue against the config system, xml is not ideal for manual editing. But, having hinted, aliased fonts isn't impossible. It's pretty simple actually. Providing you have a suitable freetype version. So please put your ranting into perspective. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xserver doesn't support XvPutImage to Pixmap?
I think Xv is meant to also work for overlays, which obviously won't
work on a pixmap. Maybe it's a safety so application developers don't
do anything stupid.
Maarten.
On Fri, Apr 10, 2009 at 11:30 AM, Yuan Austin shengquan.y...@gmail.com wrote:
On Thu, Apr 2, 2009 at 3:59 PM, Shengquan Yuan shengquan.y...@gmail.com
wrote:
Hi,
I tried to use XvPutImage to draw into a pixmap, but it always returns
error. After tracing into Xserver, I found function
hw/xfree86/common/xf86xv.c:xf86XVPutImage checks whether the drawable
is WINDOW, if not, it returns BadAlloc directly, see bellow code:
static int
xf86XVPutImage(
ClientPtr client,
DrawablePtr pDraw,
XvPortPtr pPort,
GCPtr pGC,
INT16 src_x, INT16 src_y,
CARD16 src_w, CARD16 src_h,
INT16 drw_x, INT16 drw_y,
CARD16 drw_w, CARD16 drw_h,
XvImagePtr format,
unsigned char* data,
Bool sync,
CARD16 width, CARD16 height
){
XvPortRecPrivatePtr portPriv = (XvPortRecPrivatePtr)(pPort-devPriv.ptr);
ScreenPtr pScreen;
RegionRec WinRegion;
RegionRec ClipRegion;
BoxRec WinBox;
int ret = Success;
Bool clippedAway = FALSE;
if (pDraw-type != DRAWABLE_WINDOW)
= return BadAlloc;
I tried to comment above two lines, then XvPutImage can draw into a
pixmap. I am not sure if it has side effect.
I also tried intel driver on a 945G platform, since intel driver is
using UXA architecture, and bellow exaMoveInPixmap won't be called,
this hacking doesn't work.
I also looked at Xvideo implementation in Xserver video driver, and it
looks like texture video supports rendering into a pixmap:
if (pDraw-type == DRAWABLE_WINDOW)
pPriv-pPixmap = (*pScreen-GetWindowPixmap)((WindowPtr)pDraw);
else
pPriv-pPixmap = (PixmapPtr)pDraw;
#ifdef USE_EXA
if (info-useEXA) {
/* Force the pixmap into framebuffer so we can draw to it. */
exaMoveInPixmap(pPriv-pPixmap);
}
#endif
I am wondering what's the reason that Xserver returns failure directly
when XvPutImage drawing into a pixmap?
Thanks
Austin
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: disabling MIT-SHM on older Xorg-X11 servers
Section Extensions Option MIT-SHM Disable EndSection Should work, providing you don't have an extension section already. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver patch - Fix xf86CrtcSetModeTransform() to not skip transform processing with KMS
set_mode_major is not exclusive to kernel modesetting. Is the driver api breakage neccesary? If so you definately need to bump something somewhere. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xf86-video-intel 2.7.1
There is probably also a textured Xv adapter, have you double checked which one you are using? Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
I personally wouldn't mind a kill all grabs button/key/whatever. Even if you can debug a grab issue, you don't always have the time or the right machine (debugging symbols and friends) to do it. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
From a performance pov an accelerated shadow framebuffer arrangement is probably much faster. Assuming it has some dma capability. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: help configuring a 30 apple cinema display
You can only addmode after newmode. I would expect a monitor to have it's native resolution in edid. Maybe you only have a single link dvi (which lacks the bandwith for your native resolution)? Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: help configuring a 30 apple cinema display
xf86-video-nv which i guess you're using doesn't unconditionally support dual link dvi. Some bios'es don't init it appearantly. There is an option to force it, but you could end up with a blank screen. Option AllowDualLinkModes Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
2009/6/4 Michel Dänzer mic...@daenzer.net: On Thu, 2009-05-28 at 15:07 +0400, Evgeny M. Zubok wrote: Ville Syrjälä syrj...@sci.fi writes: Just set the alignment to your fixed pitch value and it should work, shouldn't it? Great! Good idea! I have tried to set up pitch align pEXA-pixmapPitchAlign = pScrn-displayWidth * pS3-s3Bpp; and got almost normal working screen (with artefacts though) but not so ugly as before. I think that it may be bug somewhere in EXA or driver bacause server's log is full of error messages. ... EXA bug: Calling FinishAccess on pixmap 0x9278d68 with index 1 while it should have been (nil). This may indeed be a bug, Maarten? Might be interesting to see gdb backtraces for when these trigger. I'm curious as to what triggers this. Can't think of anything from the top of my head. However the main problem with this method is that memory manager doesn't effectively use the offscreen in this case. Indeed, I'm afraid EXA just doesn't offer any advantages over XAA for such limited hardware. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to run the X xserver in a chroot environment
They can never be replaced by evdev, because evdev is linux-only. But yes, evdev is often used on linux platforms, but it does need a working hal. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Has anyone seen this?
My guess is that this some early version of dri2 (which was never actually used), there is probably a --disable-dri2 or something like that. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XFixesFetchRegion() crashes app
Common sense (and the fact that the error says BadRegion here) suggest that reg = XFixesCreateRegion( display, rec, 1); This region number is no longer valid after you close the display. Doing this a 2nd time after setting nRect = 0 will fix it. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XFixesFetchRegion() crashes app
Please don't think i know what you are actually trying to do, i solved this like you would a puzzle. First guess happened to work. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XFixesFetchRegion() crashes app
And this region is some property of the root window? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Artifacts on Radeon 4850
A screenshot or something might help. But this is probably not related to mesa, unless you are running compiz or something like that. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: EXA bug: Calling FinishAccess on pixmap 0xaf06d008 with index 1 while it should have been (nil).
That would suggest creating a GC that completely bypasses exa. The proper solution seems like adding more indices or at least detecting that the indices are being used. I'll write a patch as soon as my system is in order again. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: exa/nouveau segfault
On Mon, Sep 14, 2009 at 12:27 PM, Sebastian Glita gls...@yahoo.com wrote: Hello, I use xorg-server/xf86-video-nouveau/nouveau-drm/mesa/libdrm et.al. from git.freedesktop.org. [A 2-3 days update solved the trouble with console switching, always restarting Xorg/gdm. Great relief.] Since 1-2 weeks ago I keep getting this segfault whenever launching windows except x11vnc/xterm/mplayer. Also using gtk+/glib from git.gnome.org. Backtrace: 0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x46b5a8] 1: /usr/bin/Xorg (0x40+0x76e65) [0x476e65] 2: /lib/libpthread.so.0 (0x7fc0aeb23000+0xed40) [0x7fc0aeb31d40] 3: /usr/lib/xorg/modules/drivers/nouveau_drv.so (0x7fc0abbde000+0x4552b) [0x7fc0abc2352b] 4: /usr/lib/xorg/modules/libexa.so (0x7fc0aa155000+0xf02c) [0x7fc0aa16402c] 5: /usr/lib/xorg/modules/libexa.so (0x7fc0aa155000+0xfe4d) [0x7fc0aa164e4d] 6: /usr/bin/Xorg (0x40+0xdec9d) [0x4dec9d] 7: /usr/bin/Xorg (0x40+0xd178e) [0x4d178e] 8: /usr/bin/Xorg (0x40+0x37954) [0x437954] 9: /usr/bin/Xorg (0x40+0x24f5a) [0x424f5a] 10: /lib/libc.so.6 (__libc_start_main+0xe6) [0x7fc0ad753a26] 11: /usr/bin/Xorg (0x40+0x24b19) [0x424b19] Segmentation fault at address 0xc Fatal server error: Caught signal 11 (Segmentation fault). Server aborting --- Thanks for any help, S. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg A proper backtrace made with gdb would help, some debug symbols would be useful too, at least for nouveau. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: exa/nouveau segfault
running xserver git by any chance? Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: exa/nouveau segfault
On Fri, Sep 25, 2009 at 8:35 PM, Sebastian Glita gls...@yahoo.com wrote: Yes, patch URIs accepted. tx. S. - Original Message From: Maarten Maathuis madman2...@gmail.com To: Sebastian Glita gls...@yahoo.com Cc: xorg@lists.freedesktop.org Sent: Friday, September 25, 2009 8:12:55 PM Subject: Re: exa/nouveau segfault running xserver git by any chance? Maarten. Could you retry latest xf86-video-nouveau git? Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is it normal that X consumes 800 MB RAM?
On Thu, Dec 17, 2009 at 10:40 PM, Nikos Chantziaras rea...@arcor.de wrote: On 12/17/2009 10:54 PM, dolphinling wrote: On 12/14/2009 04:44 PM, Nikos Chantziaras wrote: The longer the system runs, the more RAM X eats. After about 5 hours of uptime, I get this: http://i49.tinypic.com/wqu61j.png That's about 800MB memory usage. It gets worse as time passes. Is this normal? This looks like some memory leak to me. Does the graphics driver play a role here? I'm using AMD's binary blob for ATI cards (the radeon driver doesn't support my card.) Anything else that might be going on? This is on a Gentoo AMD64 system with X server 1.6.5, AMD Catalyst 9.11 drivers and kernel 2.6.31.6. DE is KDE 4.3.4 (in case it matters.) Typically high memory usage of X is caused by other programs asking X to store things for them. You can use the xrestop program to see how much is being used for each program. This problem may be because some other program is never telling X that it's done with resources. xrestop should be able to tell you which program it is. Of course theoretically it's possible there's a leak in one of the X components (especially the binary graphics driver), but this is far more common. This seemed to be the result of using a KDE 4.3 built against Qt 4.6 (this is not officially supported by KDE). I've since downgraded to Qt 4.5 and rebuilt KDE. This seems to have fixed the issue (mostly). X still uses more and more memory as uptime goes up, but not as dramatic as reaching 800MB after 5 hours. At boot-up, X starts with about 60MB of memory usage. Right now, after about 3 hours, it's at 170MB and slightly increasing with time. xrestop doesn't show anything interesting: adding up all the Total values reported only amounts to about 20MB or memory. Where the missing 90MB are spent, I've no idea. But in any case, we're now talking about 90MB unaccounted for instead of 700MB previously. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg Have you considered running valgrind for a little while, because it is possible there is a real memory leak somewhere. One hint, xorg is a suid binary (runs as root), so you probably want to make a copy of it and let valgrind run on that. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Board voting ends today, but...
I am not a member, which says something already. But in short everything surrounding the board has never tempted to sign up or vote. Apart from hosting a few servers i never knew what they were doing. This situation has somewhat improved but it's still vague. At the moment i still do not feel the need to sign and vote, because the process is still untransparent and unappealing. If it were me, i would suspend the elections temporarily and let the current board get their things in order. A year report is what i expect at the very least, and i've not seen this come by. The financial state of affairs is unusual to say the very least. If this is to be an election of interest, i want written material stating their long term intentions, much like any political election would have (although it could be less eleborate ofcource). Maarten. On Thu, Feb 18, 2010 at 2:44 PM, Luc Verhaegen l...@skynet.be wrote: Since voting is officially ending today I have cast my votes just now... but i did not at all feel comfortable doing so. While we did start to get some insights in the Boards doings of the past year, these insights are very limited indeed. There are no transcripts nor minutes of meetings. Irc meetings are supposed to be free and open now, but the first one to become free was the one from this tuesday. There is little to no information about the X.org Foundation Boards financial handlings. Several years ago, several companies (at least one, Sun) deposited a lot of money into the foundation. It seems that the foundation had 222k usd at the start of 2007; and we have 125k usd today. We are not getting many details on how these funds were used, and we only get some very general statements about how these funds were used in the last year. And it seems that nobody on the actual board of directors has anything but some hazy ideas of what is going on. All of this makes me extremely uneasy, especially since we have to vote on a partial replacement of this board, right now. Is there anyone else who, that with the information that has now become available, would like to alter their vote? Is there anyone here who thinks that he has not enough information available today to be able to vote at all? Thanks, Luc Verhaegen. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: super_bisq...@yahoo.com None
Everyone got a mail containing their email in the title, the fact that you can still post here means you're not the one ;-) Maarten. On Fri, May 28, 2010 at 10:10 AM, Super Biscuit super_bisq...@yahoo.comwrote: Let me put it this way. If I am spamming the list, then anyone who uses ATT or Comcast is spamming the list. You might as well cut off half the Eastern Seaboard. --- On *Thu, 5/27/10, Tollef Fog Heen tfh...@freedesktop.org* wrote: From: Tollef Fog Heen tfh...@freedesktop.org Subject: super_bisq...@yahoo.com None To: xorg@lists.freedesktop.org Cc: tfh...@err.no Date: Thursday, May 27, 2010, 4:30 PM ]] Tollef Fog Heen | somebody on this list appears to forward their mail to a ticketing | system which spams everybody who mails the list. Earlier attempts at | working out who the responsible part is has failed, so I have modified | mailman a little bit to prepend the recipient to the subject field. | Hopefully this should allow us to work out who the responsible part is | and unsubscribe that address. Ok, I did a silly error in that patch to mailman, hopefully the second try should work. Again, sorry for the noise. Regards, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are ___ xorg@lists.freedesktop.orghttp://mc/compose?to=x...@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: super_bisq...@yahoo.comhttp://mc/compose?to=super_bisq...@yahoo.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: madman2...@gmail.com -- Life spent, a precious moment, in the wink of an eye we live and we die. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: EXA classic problem with Xv
On Thu, Jun 10, 2010 at 8:56 PM, Corbin Simpson mostawesomed...@gmail.com wrote: 2010/6/10 Yves De Muyter y...@alfavisio.be: Is there any documentation available about the differences between exa_mixed and exa_driver ? Is exa_driver like complete handover of pixmap migration to the driver ? The three flavors: ~ Classic. EXA handles offscreen pixmaps itself. Simple, except when it breaks. ~ Driver. EXA lets the driver control pixmap allocation and placement. Great if you have a memory manager. ~ Mixed. Like driver, but certain things have been tweaked to optimize certain kinds of acceleration in a way that was never really explained to me. mixed has parts from classic that avoid touching driver pixmaps directly for fallbacks (vram is slow to access from the cpu). Xorg's unique access patterns are not well suited to modern gpu's IMO. That's why mixed was made. Mixed would be useless if our world was 100% gpu accelerated, but unfortunately it's not. For mixed you can also fail prepare access on the frontbuffer, which allows you to make a driver that doesn't allow mapping of vram, provided you have a UTS and DFS hook that always works. For igp'ish hardware without dedicated memory and a decent memory manager, exa driver is preferred because it's the simplest driver mode and avoids overhead that is unneeded for such hardware. To go from driver to mixed is pretty simple; here's an example commit: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=577ff3ce922e457cc32f80d4365cb1da81552e72 ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: madman2...@gmail.com -- Life spent, a precious moment, in the wink of an eye we live and we die. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
