Re: 8k resolution video causes X Error
On Sun, Dec 4, 2011 at 6:11 PM, Donald McLachlan donald.mclach...@crc.ca wrote: Hi, I don't know where to start to resolve this problem and guessed maybe this is a good place to start. If not, please point me in the right direction. Our ultimate goal is to stream 8k resolution video using sage (see www.sagecommons.org). - We first used ffmpeg to convert a 4k resolution video file to yuv format, and we were able to view it with ffplay, mplayer, and crcview (an in house program). - We then used ffmpeg to convert/resample the same 4k resolution video file to yuv/8k resolution; the conversion completed without error. - When trying to view the resulting yuv/8k resolution file all three viewer programs failed with the same X Error. For example, here is the output from ffplay: ffplay -i Lupe.8k.yuv -s 8192x4320 -pix_fmt yuv420p -x 1920 -y 1080 ffplay version 0.8, Copyright (c) 2003-2011 the FFmpeg developers built on Nov 30 2011 13:01:22 with gcc 4.5.1 20101208 [gcc-4_5-branch revision 167585] configuration: libavutil 51. 9. 1 / 51. 9. 1 libavcodec 53. 7. 0 / 53. 7. 0 libavformat 53. 4. 0 / 53. 4. 0 libavdevice 53. 1. 1 / 53. 1. 1 libavfilter 2. 23. 0 / 2. 23. 0 libswscale 2. 0. 0 / 2. 0. 0 [rawvideo @ 0x129d740] Estimating duration from bitrate, this may be inaccurate Input #0, rawvideo, from 'Lupe.8k.yuv': Duration: N/A, start: 0.00, bitrate: N/A Stream #0.0: Video: rawvideo, yuv420p, 8192x4320, 25 tbr, 25 tbn, 25 tbc X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 132 (XVideo) Minor opcode of failed request: 18 () Serial number of failed request: 23 Current serial number in output stream: 24 In case it matters, we are using openSuse 11.4 64 bit linux, on an ASUS P6T7 WS Supercomputer motherboard, with 12 G RAM, and a ASUS GTX590 video card. My guess is the 8k resolution video format is exceeding a buffer size limit somewhere, either in software, or maybe on the video card. Is there a way to find out what buffers are affected and is there a way to overcome these limits? Thanks for any assistance you can provide, Don ___ 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 If this is using the nouveau driver (check lsmod or xorg log), i see that for some reason that it's limited to 4096x4096 for xvideo. See this line: http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/src/nouveau_xv.c#n2031 And then check the contents of DummyEncodingTex and you'll find it refers to the maximum sizes. The command xvinfo confirms this. NV50 and higher (everything starting geforce 8) are able to do 8192x8192, it should just be a matter of making a NV50 specific DummyEncodingTex structure. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ xorg@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 performance problem
On Mon, Nov 28, 2011 at 4:49 PM, Christoph Bartoschek bartosc...@or.uni-bonn.de wrote: Am 28.11.2011 10:35, schrieb Christoph Bartoschek: Now one has to look at (*pGC-ops-PolyRectangle)(pDrawable, pGC, nRects, pRects); Here is what I see so far: - damagePolyRectangle is called for 2044 rectangles. - the damage region is computed it consists of about 1000 rectangles each time. - miPolyRectangle is called. - the function iterates over all rectangles and calls exaPolylines for each of them because most have only a width and height of 0 - exaPolylines calls ExaCheckPolylines. We see that for each rectanlge ExaCheckPolylines is called. I have added timers to this function to see what costs time: void ExaCheckPolylines (DrawablePtr pDrawable, GCPtr pGC, int mode, int npt, DDXPointPtr ppt) { EXA_PRE_FALLBACK_GC(pGC); EXA_FALLBACK((to %p (%c), width %d, mode %d, count %d\n, pDrawable, exaDrawableLocation(pDrawable), pGC-lineWidth, mode, npt)); exaPrepareAccess (pDrawable, EXA_PREPARE_DEST); // Step1: 55 s exaPrepareAccessGC (pGC); // Step2: 2.4 s pGC-ops-Polylines (pDrawable, pGC, mode, npt, ppt); // Step3: 2.4 s exaFinishAccessGC (pGC); // Step4: 2.2 s exaFinishAccess (pDrawable, EXA_PREPARE_DEST); // Step5: 2.2 s EXA_POST_FALLBACK_GC(pGC); } We see that exaPrepareAccess needs most of the time. Is that expected? Inside we see that there are some region operations on the damage region in exaCopyDirty. As said before the damage region contains about 1000 rectangles. So we have 2000 times several operations on 1000 rectangeles. I think this explains the runtime. Isn't it somehow possible to batch the rectangle drawing such that the region operations are not neccessary for each rectangle? Isn't is possible to expand the damage region such that it contains less rectangles? Is this still the correct list, or should I ask the EXA questions elsewhere? Christoph ___ 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 EXA doesn't have a seperate list, but now that you ask, you should probably move to the xorg-devel mailinglist :-) I don't have any answers right now, but i'll think about it. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ xorg@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 performance problem
On Sun, Nov 27, 2011 at 3:55 PM, Christoph Bartoschek bartosc...@or.uni-bonn.de wrote: Hi, I still have a huge performance problem with Xorg. One application that painted 2 Mio rectangles on the screen within a second or so with XFree86 needs about a minute with Xorg. Most of the time is spent in libpixman. I've added some debug statements and see that pixman_raster_op is called about 7.2 mio times during my testcase. I do not think that pixman itself is the problem. It is just used too often by EXA. Is there anything I can do about this? Is there a better list where I can ask? Or do you know a person that might be interested in solving such a problem? Christoph ___ 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 As far as i know it basically boils down to this, rendering rectangles is done in a software library as you observed. If your pixmap happens to be outside normal ram then a lot of reads will kill performance. These days the aim should be to use as little core rendering as possible. A modern toolkit or a rendering library like cairo should handle this far better. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ xorg@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 performance problem
On Sun, Nov 27, 2011 at 9:40 PM, Christoph Bartoschek bartosc...@or.uni-bonn.de wrote: Am 27.11.2011 16:13, schrieb Maarten Maathuis: On Sun, Nov 27, 2011 at 3:55 PM, Christoph Bartoschek bartosc...@or.uni-bonn.de wrote: Hi, I still have a huge performance problem with Xorg. One application that painted 2 Mio rectangles on the screen within a second or so with XFree86 needs about a minute with Xorg. Most of the time is spent in libpixman. I've added some debug statements and see that pixman_raster_op is called about 7.2 mio times during my testcase. I do not think that pixman itself is the problem. It is just used too often by EXA. Is there anything I can do about this? Is there a better list where I can ask? Or do you know a person that might be interested in solving such a problem? Christoph ___ 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 As far as i know it basically boils down to this, rendering rectangles is done in a software library as you observed. If your pixmap happens to be outside normal ram then a lot of reads will kill performance. These days the aim should be to use as little core rendering as possible. A modern toolkit or a rendering library like cairo should handle this far better. How can I check whether the pixmap is outside the normal ram? For me it does not look as if pixman is used for rendering the image. It looks as if EXA is managing the region that needs updates with pixman routines. But I could be wrong here. Christoph Only the driver knows that. If you know what driver it is, you can also figure out if the driver handles pixmap allocation themselves. Then you can see if they (are likely) to use dedicated video ram, which is the only uncached memory (=slow read) i can think of right now. I don't know off the top of my head how to determine if a pixmap is offscreen (for a driver that allocates pixmaps this means that the pixmap is under driver control, the alternative is that it's a malloc private to exa). -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ xorg@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 performance problem
On Mon, Nov 28, 2011 at 2:41 AM, Christoph Bartoschek bartosc...@or.uni-bonn.de wrote: I have new information. I am no longer sure whether it is a problem with EXA. I have a testcase that currently takes 90 seconds to draw all rectangles. I see that in damage.c two functions are mainly used: damagePolyRectangle damagePolyFillRectangle The first function calls for each given rectangle up to four times damageDamageBox (pDrawable, box, pGC-subWindowMode); which adds the box to a region. The function then calls damageRegionAppend. This part takes in sum 30 seconds of my testcase. I think the code has quadratic behaviour here becuase it adds rectangle by rectangle instead of first adding them to a region and then calling damageRegionAppend. I think removing the quadratic behaviour can reduce the runtime significantly. About 60 seconds are spent in the calls (*pGC-ops-PolyRectangle)(pDrawable, pGC, nRects, pRects); (*pGC-ops-PolyFillRect)(pDrawable, pGC, nRects, pRects); However I do not yet know why they are so slow. Is damage.c part of EXA? Christoph ___ 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 No, damage is an extention, it is called by EXA, it's probably adding all you rectangles to a damage region used to determine how much data is actually valid (needed for ram--vram migrations for example). One thing that just comes to mind, if you are rendering a million rectangles, how many of those do you actually see on your screen? Anyway, you can try optimizing damaga, exa and either fb or mi (for PolyRectangle PolyFillRect software ops). I don't know how efficient the region code is at reducing the number of rectangles if they overlap, a region is built up out of rectangles as well. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ xorg@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 performance problem
On Mon, Nov 28, 2011 at 7:43 AM, Maarten Maathuis madman2...@gmail.com wrote: On Mon, Nov 28, 2011 at 2:41 AM, Christoph Bartoschek bartosc...@or.uni-bonn.de wrote: I have new information. I am no longer sure whether it is a problem with EXA. I have a testcase that currently takes 90 seconds to draw all rectangles. I see that in damage.c two functions are mainly used: damagePolyRectangle damagePolyFillRectangle The first function calls for each given rectangle up to four times damageDamageBox (pDrawable, box, pGC-subWindowMode); which adds the box to a region. The function then calls damageRegionAppend. This part takes in sum 30 seconds of my testcase. I think the code has quadratic behaviour here becuase it adds rectangle by rectangle instead of first adding them to a region and then calling damageRegionAppend. I think removing the quadratic behaviour can reduce the runtime significantly. About 60 seconds are spent in the calls (*pGC-ops-PolyRectangle)(pDrawable, pGC, nRects, pRects); (*pGC-ops-PolyFillRect)(pDrawable, pGC, nRects, pRects); However I do not yet know why they are so slow. Is damage.c part of EXA? Christoph ___ 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 No, damage is an extention, it is called by EXA, it's probably adding all you rectangles to a damage region used to determine how much data is actually valid (needed for ram--vram migrations for example). One thing that just comes to mind, if you are rendering a million rectangles, how many of those do you actually see on your screen? Anyway, you can try optimizing damaga, exa and either fb or mi (for PolyRectangle PolyFillRect software ops). I don't know how efficient the region code is at reducing the number of rectangles if they overlap, a region is built up out of rectangles as well. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. s/damaga/damage and s/extention/extension and s/you rectangles/your rectangles It was too early in the morning :-) -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ xorg@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: intel and 8 bit pseudo colour mode
On Tue, Oct 11, 2011 at 10:31 PM, Christopher Harvey ch...@basementcode.com wrote: I'm having problems with an Intel card (82915G/GV/910GL) running in 8 bit colour mode. I could post a screenshot if required, but basically the screen is gray scale and some (but not all) of the pixels seem to have inverted brightness. I'm not sure what other information to provide except for xf86-video-intel is at version 2.14.0 and xorg-server is 1.10.2 the only setup I did to run 8 bit mode was adding DefaultDepth 8 to xorg.conf Am I missing something to get it running? Does Intel not support 8 bit mode? Is there an open source driver that does? (I'm trying to figure out how 8 bit mode should be implemented in drivers with recent versions of X) thanks, Chris ___ 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 I think this is at least related to a known problem with the xserver. See here: http://www.mail-archive.com/xorg-devel@lists.x.org/msg17941.html -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ xorg@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: Respository vandalism by r...@...fd.o
On Wed, Nov 24, 2010 at 11:03 AM, Tim Beaulen tbsc...@gmail.com wrote: Luc, I completely agree with you. ___ 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 If Adam indeed did this, and did not undo it afterwards, then he is having at least some (mental) issues. He did the right thing by disabling his admin account, because he obviously has some things to sort out. While the action itself is minor, the causes for doing it probably are not. Just encourage Adam to work out his problems. Trust can be rebuilt, it just takes (a lot of) time and an effort on his side to sort out his life. Maarten. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ xorg@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: Respository vandalism by r...@...fd.o
On Tue, Nov 23, 2010 at 4:27 PM, Luc Verhaegen l...@skynet.be wrote: On Tue, Nov 23, 2010 at 10:25:33AM -0500, Gaetan Nadon wrote: On Tue, 2010-11-23 at 13:57 +0100, Luc Verhaegen wrote: It is clear that this is not a normal security breach, as this commit is fully in line with the naming scheme used by fd.o. Plus, given the history of radeonhd, combined with who i think have root access, makes it seem quite likely that this was simply one of the people with regular root access. I had noticed this appalling commit, looked around and came to the same conclusion. I had also received an e-mail alerting me about this commit. This is not a good use of our time. The commit should actually be removed from the repository, or at least reverted, to save other people from wasting time on this. Their wiki states that radeonhd is deprecated, which is fine, but that does not mean it should be crippled. That would be the honorable thing to do for the author of this commit. I make mistakes, people tell me nicely, I fix them and life goes on. Gaetan Still, would you really want to trust your code to freedesktop.org after this, knowing that there's someone with root access pulling stunts like this? Luc Verhaegen. ___ xorg-de...@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel It's obvious the person must be found, and regardless of whether the person is found, change the root password and only tell those who are known to be trustworthy still. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ xorg@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: mixed OpenGL vendor drivers
On Wed, Nov 17, 2010 at 10:34 AM, Kai-Uwe Behrmann k...@gmx.de wrote: Am 16.11.10, 19:21 -0500 schrieb Matt Turner: On Tue, Nov 16, 2010 at 3:38 AM, Kai-Uwe Behrmann k...@gmx.de wrote: ATI and Nvidia ship separate version of libGL.so, for Linux and probably for other operating systems. Now I want to make a Live media with out of the box fantastic OpenGL support for a wide range of graphic cards. Is the replacement by vendors of libGL something dictated by the architecture of Xorg or the OpenGL spec? What are good solutions to switch the library on the fly? (That written, I admire the efforts to bring open sourced GL drivers on the table. But artists need for work horse graphics really fast drivers. Otherwise coe in danger to simply switch the platform.) Can you legally redistribute ATI/Nvidia's binary drivers? Back in the Xgl days, someone made a LiveCD to show off the spinning cube, and in order to make this work distributed the drivers on the CD. I think they realized (or were told?) that they weren't really supposed to do that and stopped making the CD. It's pretty pedantic, but. http://de.download.nvidia.com/XFree86/Linux-x86_64/260.19.21/README/faq.html says under 7.1 NVIDIA-INSTALLER Why does NVIDIA not provide RPMs? ... These repackaged NVIDIA drivers are likely to inter-operate best with the Linux distribution's package management technology. For this reason, NVIDIA encourages users to use their distribution's repackaged NVIDIA driver, where available. AMD Software End User License Agreement (d) In addition to the license terms above, with respect to portions of the Software in source code or binary form designed exclusively for use with the Linux operating system (AMD Linux Code), you may use, display, modify, copy, distribute, allow others to re-distribute, package and repackage such AMD Linux Code for commercial and non-commercial purposes, provided that: So I read this as, redistribution is fine with at least Nvidia and AMD. The constraints lie in linux' GPL license. This all hearsay, but there is supposed to be a segment that forbids shipping a closed source module with the kernel, without also providing the sourcecode. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ 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 -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ xorg@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: Guarantees of order of X events vs requests
On Wed, Oct 20, 2010 at 11:34 AM, Eirik Byrkjeflot Anonsen ei...@opera.com wrote: What guarantees does X give when it comes to the order of events generated in relation to processing of the requests sent by the client? (Also, of course: To which degree does various implementations of X actually fulfill these guarantees?) Some specific questions: X events have a serial value. I expect that any event delivered by X will reflect the state after the request number serial (and all preceding requests) have been processed. Is this correct? Can I also assume that the X event will reflect the state before any requests with a later serial number is processed? (And I assume that serial is monotonically increasing, except on wrap-arounds...) I think the ordering is kept for obvious reasons, but you don't know when you'll see the result. Context: Given an application that frequently performs a sequence of XCopyArea() calls on the contents of a window. When this application receives Expose events or GraphicsExpose events, it is necessary for the application to know exactly which XCopyArea calls have taken effect to be able to correctly calculate which area of the window has become invalid. I think you are supposed to draw the entire area that is exposed. If that is too costly, maybe render to a backbuffer and copy to the window. Just my two cents. eirik ___ 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 -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ xorg@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: Guarantees of order of X events vs requests
On Wed, Oct 20, 2010 at 2:57 PM, Eirik Byrkjeflot Anonsen ei...@opera.com wrote: Maarten Maathuis madman2...@gmail.com writes: On Wed, Oct 20, 2010 at 11:34 AM, Eirik Byrkjeflot Anonsen ei...@opera.com wrote: What guarantees does X give when it comes to the order of events generated in relation to processing of the requests sent by the client? (Also, of course: To which degree does various implementations of X actually fulfill these guarantees?) Some specific questions: X events have a serial value. I expect that any event delivered by X will reflect the state after the request number serial (and all preceding requests) have been processed. Is this correct? Can I also assume that the X event will reflect the state before any requests with a later serial number is processed? (And I assume that serial is monotonically increasing, except on wrap-arounds...) I think the ordering is kept for obvious reasons, but you don't know when you'll see the result. X is required to produce the same result as if all requests were handled strictly in-order, but the server can reorder requests as long as the client doesn't notice the difference. I'm not so sure the serial member of events are included in the set of observable effects, and I'm even less sure that implementations have kept that in mind. So can I be sure that an event will reflect the state resulting from exactly the requests with request number serial and earlier having been executed? Context: Given an application that frequently performs a sequence of XCopyArea() calls on the contents of a window. When this application receives Expose events or GraphicsExpose events, it is necessary for the application to know exactly which XCopyArea calls have taken effect to be able to correctly calculate which area of the window has become invalid. I think you are supposed to draw the entire area that is exposed. If that is too costly, maybe render to a backbuffer and copy to the window. Just my two cents. I certainly intend to draw the entire area that is exposed (typically from a back buffer, yes...). The problem is, I don't know where in the window that area is now. The event only tells me which area of the window was exposed at the time when the event was generated. If one of the XCopyArea requests are executed after that, then the invalid area will move too. You do know that regardless of how many operations are still scheduled, your new one will end up at the end? So after all your previous XCopyArea requests. eirik ___ 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 -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ xorg@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: internal monitor name in xrandr
On Fri, Jul 2, 2010 at 12:19 PM, CSJ changsi...@gmail.com wrote: Hi, I am writing a script to output to external monitor automatically when it is connected. But now I have no idea about what name will be used for internal monitor in xrandr. some are LVDS and some are DP1 In recent versions of xrandr/xorg/etc there exists the concept of a primary output, maybe that is what you seek. I want to parsing the xrandr output and remove the internal one. (xrandr | grep -v connected | grep -v $INTERNAL_NAME) then others will be external monitor. So, does any methods to does which name will be used for internal monitor. in many kinds of notebooks? One more question, I've tried meego live USB, it can auto output when I plug a external monitor, How does it achieve this function? Does any event will be issued when I plug a external monitor? Thanks ___ 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
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: 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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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: 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: [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: 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: 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 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: 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: 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: 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: [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: [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: 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 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: [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: 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 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
[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
[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 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
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
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: 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
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: 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
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
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
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
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
[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
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
[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
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
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
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: [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
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: 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