java OutOfMemory building documentation
This change seems to be causing documentation to fail building on yuffie due to java running out of memory… http://tinderbox.x.org/builds/2010-09-22-0004/logs/libX11/#build I seem to recall other OutOfMemory errors being reported wrt documentation earlier, but I don't recall any resolution. Looking at fop, it looks like we can setup a FOP_OPTS environment variable with an appropriate -Xmx argument to be passed along to java. I just tested this on yuffie by adding the following to my tinderbox script, and it resolved my build failure: export FOP_OPTS=-Xmx2048m Obviously setting the max VM size as 2G universally isn't the best solution. I also don't expect everyone to know about FOPS_OPTS either, so what is the best way to resolve this across modules? On Sep 21, 2010, at 18:25, Alan Coopersmith wrote: COPYING |2 configure.ac | 62 -- cpprules.in |2 nls/.gitignore |2 nls/C/Makefile.am|3 nls/Makefile.am | 61 +- nls/am_ET.UTF-8/Makefile.am |3 nls/armscii-8/Makefile.am|3 nls/compose-chart.pl | 389 +++ nls/compose-check.pl |7 nls/el_GR.UTF-8/Makefile.am |3 nls/en_US.UTF-8/Makefile.am |3 nls/fi_FI.UTF-8/Makefile.am |3 nls/georgian-academy/Makefile.am |3 nls/georgian-ps/Makefile.am |3 nls/ibm-cp1133/Makefile.am |3 nls/iscii-dev/Makefile.am|3 nls/isiri-3342/Makefile.am |3 nls/iso8859-1/Makefile.am|3 nls/iso8859-10/Makefile.am |3 nls/iso8859-11/Makefile.am |3 nls/iso8859-13/Makefile.am |3 nls/iso8859-14/Makefile.am |3 nls/iso8859-15/Makefile.am |3 nls/iso8859-2/Makefile.am|3 nls/iso8859-3/Makefile.am|3 nls/iso8859-4/Makefile.am|3 nls/iso8859-5/Makefile.am|3 nls/iso8859-6/Makefile.am|3 nls/iso8859-7/Makefile.am|3 nls/iso8859-8/Makefile.am|3 nls/iso8859-9/Makefile.am|3 nls/iso8859-9e/Makefile.am |3 nls/ja.JIS/Makefile.am |3 nls/ja.S90/Makefile.am |3 nls/ja.SJIS/Makefile.am |3 nls/ja.U90/Makefile.am |3 nls/ja/Makefile.am |3 nls/ja_JP.UTF-8/Makefile.am |3 nls/ko/Makefile.am |3 nls/ko_KR.UTF-8/Makefile.am |3 nls/koi8-c/Makefile.am |3 nls/koi8-r/Makefile.am |3 nls/koi8-u/Makefile.am |3 nls/localerules.in | 13 - nls/microsoft-cp1251/Makefile.am |3 nls/microsoft-cp1255/Makefile.am |3 nls/microsoft-cp1256/Makefile.am |3 nls/mulelao-1/Makefile.am|3 nls/nokhchi-1/Makefile.am|3 nls/pt_BR.UTF-8/Makefile.am |3 nls/ru_RU.UTF-8/Makefile.am |3 nls/tatar-cyr/Makefile.am|3 nls/th_TH.UTF-8/Makefile.am |3 nls/th_TH/Makefile.am|3 nls/tscii-0/Makefile.am |3 nls/vi_VN.tcvn/Makefile.am |3 nls/vi_VN.viscii/Makefile.am |3 nls/zh_CN.UTF-8/Makefile.am |3 nls/zh_CN.gb18030/Makefile.am|3 nls/zh_CN.gbk/Makefile.am|3 nls/zh_CN/Makefile.am|3 nls/zh_HK.UTF-8/Makefile.am |3 nls/zh_HK.big5/Makefile.am |3 nls/zh_HK.big5hkscs/Makefile.am |3 nls/zh_TW.UTF-8/Makefile.am |3 nls/zh_TW.big5/Makefile.am |3 nls/zh_TW/Makefile.am|3 specs/xmlrules.in| 10 - 69 files changed, 464 insertions(+), 264 deletions(-) New commits: commit 986bb6d1d54368fe91e3ea24f518d43ce6179782 Author: Alan Coopersmith alan.coopersm...@oracle.com Date: Tue Sep 14 00:10:31 2010 -0700 Bug 19379 - Provide docs with overview of all compose key combinations Adds compose-chart.pl to generate DocBook/XML documents listing compose keys, and Makefile rules to generate HTML PDF output from them if xmlto is present. https://bugs.freedesktop.org/show_bug.cgi?id=19379 Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com Reviewed-by: Mikhail Gusarov dotted...@dottedmag.net Reviewed-by: James Cloos cl...@jhcloos.com Tested-by: Gaetan Nadon mems...@videotron.ca commit 3eb064071695ebf0f371163ed818a428dfeba8e6 Author: Alan Coopersmith alan.coopersm...@oracle.com Date: Sat Sep 11 00:49:21 2010 -0700 Make locale data build non-recursive / parallelizable On a 4 core CPU with gmake -j 16 the nls subdir builds in half the time, plus this simplifies the next set of changes. Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com Reviewed-by: Mikhail Gusarov dotted...@dottedmag.net Reviewed-by: James
Re: [PATCH] Cygwin/X: Fix compilation after delete pervasively use of DISPATCH_PROC
On Tue, Sep 28, 2010 at 07:29:27PM +0200, ext Jon TURNEY wrote: commit cbd4d5dbb70db62ba1cb79c7b904e6fa11f62d7e removes the static declarations of ProcWindowsWMDispatch and SProcWindowsWMDispatch which precede their first use in winWindowsWMExtensionInit() Move winWindowsWMExtensionInit() to after the definition of those two functions to fix compilation. Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk Reviewed-by: Tiago Vignatti tiago.vigna...@nokia.com please send it to Keith, Jon. Thank you! Tiago ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH xorg-docs] XACE spec: move from sgml/security to specs/Xserver directory
On Tue, 2010-09-28 at 21:35 -0700, Alan Coopersmith wrote: Long term, it should probably end up in the X server repo, since it's really documentation of a set of hooks inside the X server, so that it's in sync with the version of the hooks inside the server, but until then moving it to the Xserver directory is fine. Exactly what I had in mind. Probably the 3 other docs in /Xserver should go in xserver module as well. Thanks signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libX11] Add an X11_ string to header guards to avoid possible collision
On Sun, Sep 26, 2010 at 9:25 PM, Jeremy Huddleston jerem...@freedesktop.org wrote: This addresses a build failure which can result from X11/Xlocale.h and xlocale.h being included in the same code since they both used the same _XLOCALE_H_ protection. Signed-off-by: Jeremy Huddleston jerem...@apple.com Looks reasonable to me. Reviewed-by: Dan Nicholson dbn.li...@gmail.com ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: xf86-video-geode: Changes to 'master'
On Wed, Sep 29, 2010 at 06:36:52 -0700, Martin-Éric Racine wrote: src/lx_output.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) New commits: commit 89c60efe899f0cda4a52e0574f030c021c4b1ece Author: Frank Huang frankr.hu...@amd.com Date: Wed Sep 29 16:35:46 2010 +0300 Mode Validation support on modeline in xorg.conf *mode validation(lx_output_mode_valid) in this driver should return MODE_OK for all modes filtered out by previous process in this function. Otherwise, new modelines(conf_modes) will be pruned by Xserver function Xf86PruneInvalidModes. The result is that the user can not set arbitrary resolutions. We comply with the code of ATIIntel mode_valid function to do this. *For modes that cannot be supported by the geode driver, it is better to give the specific MODE_XXX(such as MODE_CLOCK_RANGE) instead of MODE_BAD. Signed-off-by: Frank Huang frankr.hu...@amd.com This looks broken. lx_output_mode_valid() now returns MODE_OK for every possible mode, but takes great pains to get there. The commit message doesn't help, I have no idea what it's trying to say. Cheers, Julien ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
TargetRefresh option gone, can't select initial refresh rate
Hello All, [Please keep me on CC as I'm not an xorg-devel subscriber.] I was pointed to this list via this bug: https://bugs.freedesktop.org/show_bug.cgi?id=30315 I would like to draw people's attention to this bug which I experience as a regression from previous X releases. Please let me know if this really was intentional, if there are plans to fix it, or if I have overlooked a new method to archive initial selection of a certain refresh rate if there are multiple ones to choose. In the initial bug report I have detailed which procedures I don't consider viable work-arounds (and why). Thanks in advance Marius ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Build error in new xf86-video-ati (from Git)
drmmode_display.c: In function 'drmmode_xf86crtc_resize': drmmode_display.c:1148: error: 'struct _ScrnInfoRec' has no member named 'pixmapPrivate' As per usual, I rebuild the entire tree using jhbuild. The dependencies were all updated, to my knowledge. Tried doing a clean build for xf86-video-ati, but no luck. -- - Joel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Build error in new xf86-video-ati (from Git)
On Wed, Sep 29, 2010 at 11:11:06 -0400, Joel Feiner wrote: drmmode_display.c: In function 'drmmode_xf86crtc_resize': drmmode_display.c:1148: error: 'struct _ScrnInfoRec' has no member named 'pixmapPrivate' There's a patch on https://bugs.freedesktop.org/show_bug.cgi?id=30451 Cheers, Julien ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH libXtst] Allow more than 6 axes to be sent.
From: Tobias Koch tobias.k...@nokia.com
From: Tobias Koch tobias.k...@nokia.com
If the number of axes exceeds 6, X server will return BadValue for
XTestFakeInput because the number of axes in a single DeviceValuator
event is incorrectly set to the total number of axes.
Signed-off-by: Tobias Koch tobias.k...@nokia.com
Reviewed-by: Rami Ylimäki rami.ylim...@vincit.fi
---
src/XTest.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/XTest.c b/src/XTest.c
index c04cc09..24ae8b9 100644
--- a/src/XTest.c
+++ b/src/XTest.c
@@ -267,12 +267,10 @@ send_axes(
req-length += ((n_axes + 5) / 6) * (SIZEOF(xEvent) 2);
ev.type = XI_DeviceValuator + (long)info-data;
ev.deviceid = dev-device_id;
-ev.num_valuators = n_axes;
ev.first_valuator = first_axis;
while (n_axes 0) {
- n = n_axes;
- if (n 6)
- n = 6;
+ n = n_axes 6 ? 6 : n_axes;
+ ev.num_valuators = n;
switch (n) {
case 6:
ev.valuator5 = *(axes+5);
--
1.6.3.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Build error in new xf86-video-ati (from Git)
On Wed, Sep 29, 2010 at 11:11 AM, Joel Feiner jafei...@gmail.com wrote: drmmode_display.c: In function 'drmmode_xf86crtc_resize': drmmode_display.c:1148: error: 'struct _ScrnInfoRec' has no member named 'pixmapPrivate' As per usual, I rebuild the entire tree using jhbuild. The dependencies were all updated, to my knowledge. Tried doing a clean build for xf86-video-ati, but no luck. The driver hasn't been updated to the latest changes in xserver git. https://bugs.freedesktop.org/show_bug.cgi?id=30451 Alex -- - Joel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X input event generation thread (v2)
On Tue, 2010-09-28 at 23:00 +0200, Mark Kettenis wrote: If the input thread is going to run the same code as the SIGIO handlers do now, I fear this isn't going to fly. That code simply isn't thread-safe. The biggest issue the code that draws pointers. On multi-card setups, that will cause the input thread to switch the VGA arbiter to the device on which the pointer is visible. If that happens while the main server thread is drawing on a different device bad things will happen (typically things just lock up). As we said at XDS, this is merely a bug. The sprite code is written to expect this case and get it right (by deferring sprite updates if they would trigger a screen crossing), so if it's broken that's something we introduced and need to fix. Of course the same problem exists with SIGIO. After realizing how much code was run from the SIGIO signal handler, and the VGA arbiter issues related to that we decided to disable SIGIO on OpenBSD (encouraged by Alan C.'s statement that Solaris does the same). As far as I can tell, the only effect of this is that it disables the silken mouse. Quite a few OpenBSD users tested that change, and all of them indicated that they noticed no difference whatsoever. Your users are clearly not sensitive to input latency. Mine are. But, numbers. The current perceptual behaviour of the SIGIO code is that, in the common non-screen-crossing case, the cursor is perfectly stuck to the screen; updates happen on the very next vertical retrace. If you wanted to preserve that behaviour, you have options. For example: After every request, select() for input again and process it if there is any. That's certainly something you can do. Here's how that looks to your request throughput numbers: 1: Xvfb-normal.perf 2: Xvfb-select-happy.perf 1 2 Operation - - 542000.0 535000.0 ( 0.99) 100x100 rectangle 268000.0 258000.0 ( 0.96) ShmPutImage 100x100 square 1470.0 774.0 ( 0.53) X protocol NoOperation 19400.016500.0 ( 0.85) QueryPointer 574000.0 554000.0 ( 0.97) Create and map subwindows (4 kids) 4990.0 4010.0 ( 0.80) Dot So, anything that's round-trip-limited gets 15% slower, anything that's request-rate-limited gets 20% to 50% slower, but anything that's actually bounded by server execution time is pretty much unaffected. Not the end of the world, but not something I'd ship. But, of course, you don't really need to do that. You can do something like what the smart scheduler does, possibly even still _using_ SIGIO to do it: if input comes in, raise a flag (isItTimeToYield, in fact) to bomb back out from request processing to the select loop. That's cheap enough, but you're still bounded by the time required to actually complete a request, and it's pretty trivial to get that to spike well north of 100ms. Even discounting pathological clients, it's pretty easy for something like firefox to submit enough work to keep you away from dispatch for multiple frame intervals. You're not necessarily doing anything besides moving the pointer during that, but that's not a reason to let the pointer skip. Again, if your users don't think that's a problem, good for them, that must be nice. I find it's like MPEG artifacts on TV: once you see it, you can't stop seeing it. So I'm wondering whether we shouldn't simply remove the SIGIO code and let the main event loop handle input events. You are free to continue to use the main loop for input in your own products. - ajax signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: java OutOfMemory building documentation
On Wed, Sep 29, 2010 at 2:25 AM, Jeremy Huddleston jerem...@apple.com wrote: This change seems to be causing documentation to fail building on yuffie due to java running out of memory… http://tinderbox.x.org/builds/2010-09-22-0004/logs/libX11/#build I seem to recall other OutOfMemory errors being reported wrt documentation earlier, but I don't recall any resolution. Looking at fop, it looks like we can setup a FOP_OPTS environment variable with an appropriate -Xmx argument to be passed along to java. I just tested this on yuffie by adding the following to my tinderbox script, and it resolved my build failure: export FOP_OPTS=-Xmx2048m Obviously setting the max VM size as 2G universally isn't the best solution. I also don't expect everyone to know about FOPS_OPTS either, so what is the best way to resolve this across modules? It's not a terrible solution, it's not like you'll actually be using 2G on any halfway sane jvm except when you need it, it's just an upper bound. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Cygwin/X: Fix compilation after delete pervasively use of DISPATCH_PROC
commit cbd4d5dbb70db62ba1cb79c7b904e6fa11f62d7e
removes the static declarations of ProcWindowsWMDispatch and
SProcWindowsWMDispatch which precede their first use in
winWindowsWMExtensionInit()
Move winWindowsWMExtensionInit() to after the definition of those
two functions to fix compilation.
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
Reviewed-by: Tiago Vignatti tiago.vigna...@nokia.com
---
hw/xwin/winwindowswm.c | 52 +++
1 files changed, 25 insertions(+), 27 deletions(-)
diff --git a/hw/xwin/winwindowswm.c b/hw/xwin/winwindowswm.c
index ca3dbc3..4027539 100755
--- a/hw/xwin/winwindowswm.c
+++ b/hw/xwin/winwindowswm.c
@@ -44,8 +44,6 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#include protocol-versions.h
static int WMErrorBase;
-
-
static unsigned char WMReqCode = 0;
static int WMEventBase = 0;
@@ -78,31 +76,6 @@ make_box (int x, int y, int w, int h)
return r;
}
-void
-winWindowsWMExtensionInit (void)
-{
- ExtensionEntry* extEntry;
-
- ClientType = CreateNewResourceType(WMFreeClient, WMClient);
- eventResourceType = CreateNewResourceType(WMFreeEvents, WMEvent);
- eventResource = FakeClientID(0);
-
- if (ClientType eventResourceType
- (extEntry = AddExtension(WINDOWSWMNAME,
- WindowsWMNumberEvents,
- WindowsWMNumberErrors,
- ProcWindowsWMDispatch,
- SProcWindowsWMDispatch,
- NULL,
- StandardMinorOpcode)))
-{
- WMReqCode = (unsigned char)extEntry-base;
- WMErrorBase = extEntry-errorBase;
- WMEventBase = extEntry-eventBase;
- EventSwapVector[WMEventBase] = (EventSwapPtr) SNotifyEvent;
-}
-}
-
static int
ProcWindowsWMQueryVersion(register ClientPtr client)
{
@@ -639,3 +612,28 @@ SProcWindowsWMDispatch (register ClientPtr client)
return BadRequest;
}
}
+
+void
+winWindowsWMExtensionInit (void)
+{
+ ExtensionEntry* extEntry;
+
+ ClientType = CreateNewResourceType(WMFreeClient, WMClient);
+ eventResourceType = CreateNewResourceType(WMFreeEvents, WMEvent);
+ eventResource = FakeClientID(0);
+
+ if (ClientType eventResourceType
+ (extEntry = AddExtension(WINDOWSWMNAME,
+ WindowsWMNumberEvents,
+ WindowsWMNumberErrors,
+ ProcWindowsWMDispatch,
+ SProcWindowsWMDispatch,
+ NULL,
+ StandardMinorOpcode)))
+{
+ WMReqCode = (unsigned char)extEntry-base;
+ WMErrorBase = extEntry-errorBase;
+ WMEventBase = extEntry-eventBase;
+ EventSwapVector[WMEventBase] = (EventSwapPtr) SNotifyEvent;
+}
+}
--
1.7.2.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[DOC] Re: java OutOfMemory building documentation
On Wed, Sep 29, 2010 at 9:41 AM, Younes Manton youne...@gmail.com wrote: On Wed, Sep 29, 2010 at 2:25 AM, Jeremy Huddleston jerem...@apple.com wrote: This change seems to be causing documentation to fail building on yuffie due to java running out of memory… http://tinderbox.x.org/builds/2010-09-22-0004/logs/libX11/#build I seem to recall other OutOfMemory errors being reported wrt documentation earlier, but I don't recall any resolution. Looking at fop, it looks like we can setup a FOP_OPTS environment variable with an appropriate -Xmx argument to be passed along to java. I just tested this on yuffie by adding the following to my tinderbox script, and it resolved my build failure: export FOP_OPTS=-Xmx2048m Obviously setting the max VM size as 2G universally isn't the best solution. I also don't expect everyone to know about FOPS_OPTS either, so what is the best way to resolve this across modules? It's not a terrible solution, it's not like you'll actually be using 2G on any halfway sane jvm except when you need it, it's just an upper bound. FWIW, libX11 is the largest document and I found that using export FOP_OPTS=-Xmx512m was sufficient. Matt ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [DOC] Re: java OutOfMemory building documentation
Matt Dew wrote: On Wed, Sep 29, 2010 at 9:41 AM, Younes Manton youne...@gmail.com wrote: On Wed, Sep 29, 2010 at 2:25 AM, Jeremy Huddleston jerem...@apple.com wrote: This change seems to be causing documentation to fail building on yuffie due to java running out of memory… http://tinderbox.x.org/builds/2010-09-22-0004/logs/libX11/#build I seem to recall other OutOfMemory errors being reported wrt documentation earlier, but I don't recall any resolution. Looking at fop, it looks like we can setup a FOP_OPTS environment variable with an appropriate -Xmx argument to be passed along to java. I just tested this on yuffie by adding the following to my tinderbox script, and it resolved my build failure: export FOP_OPTS=-Xmx2048m Obviously setting the max VM size as 2G universally isn't the best solution. I also don't expect everyone to know about FOPS_OPTS either, so what is the best way to resolve this across modules? It's not a terrible solution, it's not like you'll actually be using 2G on any halfway sane jvm except when you need it, it's just an upper bound. FWIW, libX11 is the largest document and I found that using export FOP_OPTS=-Xmx512m was sufficient. The new documents I autogenerate from the Compose data files have some very large tables in, most especially the en_US.UTF-8 compose key list - I'd set them to split into new tables after 750 lines since that solved the java out-of-memory issues in my environment, but it appears not to solve it for everyone - the script can be adjusted to split at a different threshold if that's easier than trying to find a way to set FOP_OPTS in the Makefile.am's. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PULL 1.9] xfree86 fixes
Jeremy, please pull this from this branch. Fixes a warning and a minor memory leak, and adds 18bpp and nds32 arch support. --- The following changes since commit 6a0b4051972a4fa6f1a3b22ec1ae54bd1849bc9f: XQuartz: RandR: Refactor legacy mode-switching to be better integrated with RandR (2010-09-28 18:54:40 -0700) are available in the git repository at: ssh://people.freedesktop.org/~ajax/xserver.git server-1.9-xfree86 Adam Jackson (1): xfree86: Add 18bpp support Jesse Adkins (1): xfree86: Fix leaks in OpenConfigFile and OpenConfigDir Macpaul Lin (3): xfree86: nds32: add nds32 definition for vgaHW support. xfree86: nds32: add nds32 support for compiler specific codes xfree86: nds32: add nds32 support for compiler related mmio codes Peter Hutterer (1): xfree86: fix compiler warning about implicied decl of DuplicateModule. hw/xfree86/common/compiler.h | 416 +++- hw/xfree86/common/xf86Helper.c |3 + hw/xfree86/common/xf86Xinput.c |1 + hw/xfree86/parser/scan.c |2 + hw/xfree86/vgahw/vgaHW.h |2 +- 5 files changed, 420 insertions(+), 4 deletions(-) - ajax signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Build error: pixmapPrivate
On Wed, Sep 29, 2010 at 12:25 PM, Trevor Woerner twoer...@gmail.com wrote: driver/xf86-video-geode/src/gx_randr.c ... and: driver/xf86-video-mach64/src/aticonsole.c mesa/mesa/src/gallium/state_trackers/xorg/xorg_driver.c ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xfree86: Kill pixmapPrivate with a vengeance (v2)
On Tue, Sep 28, 2010 at 11:08 AM, Keith Packard kei...@keithp.com wrote: On Mon, 27 Sep 2010 19:39:23 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: v2: Kill ShadowModifyPixmapHeader() as well. I've merged this patch. This patch caused the following modules to fail to compile: driver/xf86-video-ati driver/xf86-video-geode driver/xf86-video-mach64 mesa/mesa ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Build error: pixmapPrivate
Date: Wed, 29 Sep 2010 14:23:40 -0400 From: Trevor Woerner twoer...@gmail.com On Wed, Sep 29, 2010 at 12:25 PM, Trevor Woerner twoer...@gmail.com wrote: driver/xf86-video-geode/src/gx_randr.c ... and: driver/xf86-video-mach64/src/aticonsole.c mesa/mesa/src/gallium/state_trackers/xorg/xorg_driver.c I think whoever made that pixmapprivates change needs to back it out and fix the open source drivers first. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Cygwin/X: Fix compilation after delete pervasively use of DISPATCH_PROC
On Wed, 29 Sep 2010 17:05:12 +0100, Jon TURNEY jon.tur...@dronecode.org.uk wrote: Move winWindowsWMExtensionInit() to after the definition of those two functions to fix compilation. Applied. 1a9022d..72a9c68 master - master -- keith.pack...@intel.com pgp15U6QlIIw3.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] randr: set error numbers of resource types in RRExtenstionInit() #30367
On Tue, 28 Sep 2010 18:44:53 +0200, Tobias Droste tdro...@gmx.de wrote: Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=30367 Currently the ddx calls RROutputInit() before RRExtensionInit() is called. This causes RRErrorBase being 0 while setting resource type error (resource types RROutput, RRMode and RRCrtc). The fix moves the setting of error numbers to RRExtensionInit() to get the right RRErrorBase. This is generating a few new warnings: rrmode.c:283: warning: function declaration isn’t a prototype rrmode.c: In function ‘RRModeInitErrorValue’: rrmode.c:282: warning: old-style function definition CC rroutput.lo randr.c: In function ‘RRExtensionInit’: randr.c:358: warning: implicit declaration of function ‘RRModeInitErrorValue’ randr.c:358: warning: nested extern declaration of ‘RRModeInitErrorValue’ randr.c:359: warning: implicit declaration of function ‘RRCrtcInitErrorValue’ randr.c:359: warning: nested extern declaration of ‘RRCrtcInitErrorValue’ randr.c:360: warning: implicit declaration of function ‘RROutputInitErrorValue’ randr.c:360: warning: nested extern declaration of ‘RROutputInitErrorValue’ rroutput.c:430: warning: function declaration isn’t a prototype rroutput.c: In function ‘RROutputInitErrorValue’: rroutput.c:429: warning: old-style function definition rrcrtc.c:643: warning: function declaration isn’t a prototype rrcrtc.c: In function ‘RRCrtcInitErrorValue’: rrcrtc.c:642: warning: old-style function definition -- keith.pack...@intel.com pgp7HDVsQj3kV.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Build error: pixmapPrivate
On Wed, Sep 29, 2010 at 08:48:13PM +0200, Mark Kettenis wrote: Date: Wed, 29 Sep 2010 14:23:40 -0400 From: Trevor Woerner twoer...@gmail.com On Wed, Sep 29, 2010 at 12:25 PM, Trevor Woerner twoer...@gmail.com wrote: ? ?driver/xf86-video-geode/src/gx_randr.c ... and: driver/xf86-video-mach64/src/aticonsole.c mesa/mesa/src/gallium/state_trackers/xorg/xorg_driver.c I think whoever made that pixmapprivates change needs to back it out and fix the open source drivers first. As we learned on XDS, this sort of, what others would call, basic diligence, like testing some graphics drivers first, would only be reserved for drivers which would've been merged back into the server tree. Question: Why can this not be a general rule? Whenever a change at this side of the server happens: test the build of some drivers, and runtest at least _one_ driver, and take full responsibility when the error reports from other drivers come rolling in. Why would this be different whether whether drivers are in a unified build system or out of tree? Question: Would either the dummy or the vesa driver have caught this one at build time at all? Luc Verhaegen. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Build error: pixmapPrivate
On Wed, Sep 29, 2010 at 10:48:58PM +0200, Luc Verhaegen wrote: ... Question: Would either the dummy or the vesa driver have caught this one at build time at all? No. Luc Verhaegen. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Build error: pixmapPrivate
On Wed, Sep 29, 2010 at 4:48 PM, Luc Verhaegen l...@skynet.be wrote: Question: Would either the dummy or the vesa driver have caught this one at build time at all? I don't think so. I grep'ed through the source tree and only found those 4 locations where the pixmapPrivate member was being used. None of those 4 were in dummy or vesa. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Build error: pixmapPrivate
On Wed, Sep 29, 2010 at 11:55:00PM +0300, Adrian Bunk wrote: On Wed, Sep 29, 2010 at 10:48:58PM +0200, Luc Verhaegen wrote: ... Question: Would either the dummy or the vesa driver have caught this one at build time at all? No. Yet exactly supposedly being able to catch issues like this, seems to be the only reason to merge those two drivers back. What are dummy and vesa using that is moving _that_ often for them to catch anything? Luc Verhaegen. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] randr: set error numbers of resource types in RRExtenstionInit() (V2)
On Wed, 29 Sep 2010 22:51:48 +0200, Tobias Droste tdro...@gmx.de wrote: V2: With header file Applied. 72a9c68..c7e4222 master - master -- keith.pack...@intel.com pgp2DZ55qMDXH.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] randr: set error numbers of resource types in RRExtenstionInit() #30367
Since I think I introduced this bug in the 1.9 cycle, I'd guess this
patch should be cherry-picked to the 1.9 stable branch too.
Jamey
On Tue, Sep 28, 2010 at 9:44 AM, Tobias Droste tdro...@gmx.de wrote:
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=30367
Currently the ddx calls RROutputInit() before RRExtensionInit() is
called. This causes RRErrorBase being 0 while setting resource type
error (resource types RROutput, RRMode and RRCrtc).
The fix moves the setting of error numbers to RRExtensionInit() to get
the right RRErrorBase.
Signed-off-by: Tobias Droste tdro...@gmx.de
---
randr/randr.c | 5 +
randr/rrcrtc.c | 11 ++-
randr/rrmode.c | 14 +-
randr/rroutput.c | 11 ++-
4 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/randr/randr.c b/randr/randr.c
index f52a46a..6077705 100644
--- a/randr/randr.c
+++ b/randr/randr.c
@@ -354,6 +354,11 @@ RRExtensionInit (void)
SRRScreenChangeNotifyEvent;
EventSwapVector[RREventBase + RRNotify] = (EventSwapPtr)
SRRNotifyEvent;
+
+ RRModeInitErrorValue();
+ RRCrtcInitErrorValue();
+ RROutputInitErrorValue();
+
#ifdef PANORAMIX
RRXineramaExtensionInit();
#endif
diff --git a/randr/rrcrtc.c b/randr/rrcrtc.c
index 14f6e45..839f3cd 100644
--- a/randr/rrcrtc.c
+++ b/randr/rrcrtc.c
@@ -631,10 +631,19 @@ RRCrtcInit (void)
RRCrtcType = CreateNewResourceType (RRCrtcDestroyResource, CRTC);
if (!RRCrtcType)
return FALSE;
- SetResourceTypeErrorValue(RRCrtcType, RRErrorBase + BadRRCrtc);
+
return TRUE;
}
+/*
+ * Initialize crtc type error value
+ */
+void
+RRCrtcInitErrorValue()
+{
+ SetResourceTypeErrorValue(RRCrtcType, RRErrorBase + BadRRCrtc);
+}
+
int
ProcRRGetCrtcInfo (ClientPtr client)
{
diff --git a/randr/rrmode.c b/randr/rrmode.c
index deddd3c..361d17d 100644
--- a/randr/rrmode.c
+++ b/randr/rrmode.c
@@ -260,6 +260,9 @@ RRModeDestroyResource (pointer value, XID pid)
return 1;
}
+/*
+ * Initialize mode type
+ */
Bool
RRModeInit (void)
{
@@ -268,10 +271,19 @@ RRModeInit (void)
RRModeType = CreateNewResourceType (RRModeDestroyResource, MODE);
if (!RRModeType)
return FALSE;
- SetResourceTypeErrorValue(RRModeType, RRErrorBase + BadRRMode);
+
return TRUE;
}
+/*
+ * Initialize mode type error value
+ */
+void
+RRModeInitErrorValue()
+{
+ SetResourceTypeErrorValue(RRModeType, RRErrorBase + BadRRMode);
+}
+
int
ProcRRCreateMode (ClientPtr client)
{
diff --git a/randr/rroutput.c b/randr/rroutput.c
index 937b14d..1d65c11 100644
--- a/randr/rroutput.c
+++ b/randr/rroutput.c
@@ -418,10 +418,19 @@ RROutputInit (void)
RROutputType = CreateNewResourceType (RROutputDestroyResource, OUTPUT);
if (!RROutputType)
return FALSE;
- SetResourceTypeErrorValue(RROutputType, RRErrorBase + BadRROutput);
+
return TRUE;
}
+/*
+ * Initialize output type error value
+ */
+void
+RROutputInitErrorValue()
+{
+ SetResourceTypeErrorValue(RROutputType, RRErrorBase + BadRROutput);
+}
+
#define OutputInfoExtra (SIZEOF(xRRGetOutputInfoReply) - 32)
int
--
1.7.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
RE: xf86-video-geode: Changes to 'master'
See below: This looks broken. lx_output_mode_valid() now returns MODE_OK for every possible mode, but takes great pains to get there. The commit message doesn't help, I have no idea what it's trying to say. I have not received your mail until Martin forwarded it to me just now. If you don't understand what I means in commit message, I think you should see the code in ATIIntel driver. It can prove what I have committed. So I don't know why you give the broken conclusion. I totally disagree with your point. The mode valid function should return MODE_OK at the last stage of this function. If the driver give MODE_BAD at last, most modes will be filtered out including the modelines in xorg.conf. If you disagree with me, please give your reason and solved method. I definitely know MODE_OK will be returned in this function now for every condition. But you should know my patch is based on the patch Otavio committed on 5/29/2010. If there is some condition we need give MODE_XXX, we can add code. But the last return value of this function must be MODE_OK. That is my point. Cheers, Julien -- - maahanmuuttoasian ja ulkomaankaupan asiantuntija - Suomen tutkimusverkoston jäsen, European Migration Network, MIGRI - neuvottelukunnan jäsen 2009-2011, Otaniemi International Network, NEO- OTANIEMI - käyttäjäraadin jäsen 2009-2013, Infopankki - vierasblogaaja, Magma ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
