Re: Spinning in _XReply
On 02/23/2011 04:35 PM, Michal Suchanek wrote: X server seems to preserve the extension codes until the server is regenerated and therefore all connections should use the same codes. Is that guaranteed by some protocol or does it just happen to work as the requests in error handler did? This is a good point and I can't find a definite answer for it. Documentation of C.2.1 XInitExtension from Xlib manual says that the Xlib specific extension number in XExtCodes is connection specific, which makes sense, because the number is managed internally in Xlib and not asked from server. Then C.5.11 Deriving the Correct Extension Opcode says that a separate XExtCodes should be maintained for each connection. So I think that one shouldn't assume that opcodes stay the same, even though it seems to be so in practice. -- Rami ___ 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: [PULL xserver] Composite ClipNotify fix and expose event elimination
On Thu, Feb 24, 2011 at 07:17:28PM -0800, ext Keith Packard wrote: On Thu, 24 Feb 2011 17:38:53 +0200, Ville Syrjälä ville.syrj...@nokia.com wrote: Ville Syrjälä (4): composite: Call ValidateGC after ChangeGC composite: Initialize borderClip with current values I'm good with merging these two obvious fixes. composite: Get rid of the internal UnmapWindow+MapWindow cycle composite: Copy the window contents back from the pixmap These look too late for 1.10. Yeah, I figured you might say that. I suppose I should've sent the pull req earlier, but since the review discussions seemed to just peter out, I went on to do other things. The patches aren't going to disappear though, so waiting after 1.10 isn't a problem for me. -- Ville Syrjälä ___ 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] Server build fixes
The following changes since commit 780a77acce1dd369549ece802b3e2c4006058dfe:
Version bumped to 1.9.99.903 (1.10 RC3) (2011-02-24 20:45:46 -0800)
are available in the git repository at:
git://people.freedesktop.org/~dbn/xserver build-fixes
Dan Nicholson (2):
xfree86: Allow sdksyms.dep to be included portably
dmx: Construct paths in doxygen.conf to fix VPATH builds
configure.ac |3 +++
hw/dmx/doc/.gitignore|1 +
hw/dmx/doc/Makefile.am |2 +-
hw/dmx/doc/{doxygen.conf = doxygen.conf.in} | 18 +-
hw/xfree86/loader/Makefile.am|3 ++-
5 files changed, 16 insertions(+), 11 deletions(-)
rename hw/dmx/doc/{doxygen.conf = doxygen.conf.in} (98%)
___
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: Spinning in _XReply
On Fri, Feb 25, 2011 at 03:18:37PM +0200, Rami Ylimäki wrote: On 02/25/2011 02:48 PM, Daniel Stone wrote: On Fri, Feb 25, 2011 at 02:08:38PM +0200, Rami Ylimäki wrote: Documentation of C.2.1 XInitExtension from Xlib manual says that the Xlib specific extension number in XExtCodes is connection specific, which makes sense, because the number is managed internally in Xlib and not asked from server. Then C.5.11 Deriving the Correct Extension Opcode says that a separate XExtCodes should be maintained for each connection. So I think that one shouldn't assume that opcodes stay the same, even though it seems to be so in practice. Er, really? How would sending requests then work without an event from the server telling you to round-trip and get the extension list again? Looks like I removed a little bit too much context when answering. The original question was about whether one can trust that extension opcodes are the same between connections. The answer seems to be that there is no guarantee of that, because XExtCodes structure is connection specific. Of course the opcodes should stay the same over the lifetime of a connection but nobody guarantees, that XInitExtension returns the same opcodes for different connections, even though in practice it's so. Oh, right. Yeah, not guaranteed at all. Cheers, Daniel signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Spinning in _XReply
On 02/25/2011 02:48 PM, Daniel Stone wrote: On Fri, Feb 25, 2011 at 02:08:38PM +0200, Rami Ylimäki wrote: On 02/23/2011 04:35 PM, Michal Suchanek wrote: X server seems to preserve the extension codes until the server is regenerated and therefore all connections should use the same codes. Is that guaranteed by some protocol or does it just happen to work as the requests in error handler did? This is a good point and I can't find a definite answer for it. Documentation of C.2.1 XInitExtension from Xlib manual says that the Xlib specific extension number in XExtCodes is connection specific, which makes sense, because the number is managed internally in Xlib and not asked from server. Then C.5.11 Deriving the Correct Extension Opcode says that a separate XExtCodes should be maintained for each connection. So I think that one shouldn't assume that opcodes stay the same, even though it seems to be so in practice. Er, really? How would sending requests then work without an event from the server telling you to round-trip and get the extension list again? Looks like I removed a little bit too much context when answering. The original question was about whether one can trust that extension opcodes are the same between connections. The answer seems to be that there is no guarantee of that, because XExtCodes structure is connection specific. Of course the opcodes should stay the same over the lifetime of a connection but nobody guarantees, that XInitExtension returns the same opcodes for different connections, even though in practice it's so. -- Rami ___ 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: Spinning in _XReply
On 25 February 2011 14:39, Daniel Stone dan...@fooishbar.org wrote: On Fri, Feb 25, 2011 at 03:18:37PM +0200, Rami Ylimäki wrote: On 02/25/2011 02:48 PM, Daniel Stone wrote: On Fri, Feb 25, 2011 at 02:08:38PM +0200, Rami Ylimäki wrote: Documentation of C.2.1 XInitExtension from Xlib manual says that the Xlib specific extension number in XExtCodes is connection specific, which makes sense, because the number is managed internally in Xlib and not asked from server. Then C.5.11 Deriving the Correct Extension Opcode says that a separate XExtCodes should be maintained for each connection. So I think that one shouldn't assume that opcodes stay the same, even though it seems to be so in practice. Er, really? How would sending requests then work without an event from the server telling you to round-trip and get the extension list again? Looks like I removed a little bit too much context when answering. The original question was about whether one can trust that extension opcodes are the same between connections. The answer seems to be that there is no guarantee of that, because XExtCodes structure is connection specific. Of course the opcodes should stay the same over the lifetime of a connection but nobody guarantees, that XInitExtension returns the same opcodes for different connections, even though in practice it's so. Oh, right. Yeah, not guaranteed at all. Meaning there is no way to get the error name for an error code that's guaranteed to work? Thanks Michal ___ 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: [PULL] Server build fixes
On Fri, 25 Feb 2011 06:43:58 -0800, Dan Nicholson dbn.li...@gmail.com wrote: dmx: Construct paths in doxygen.conf to fix VPATH builds The paths in doxygen.conf assumed that srcdir=builddir and broke otherwise. Use autoconf to fill in the paths to the srcdir so that the files can be found when users have a separate build directory (as with distcheck). So, I'm a bit confused here -- I do 'make distcheck' to build releases, and it works for me. I'd like to know how I can test this patch to make sure it does what you expect. -- keith.pack...@intel.com pgp2YXjlZAeU2.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: [PULL] Server build fixes
Keith Packard kei...@keithp.com (25/02/2011): So, I'm a bit confused here -- I do 'make distcheck' to build releases, and it works for me. I'd like to know how I can test this patch to make sure it does what you expect. Do you end up building with devel docs, so with doxygen support when you're running make distcheck? KiBi. signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PULL] Server build fixes
On Fri, 25 Feb 2011 18:04:56 +0100, Cyril Brulebois k...@debian.org wrote: Keith Packard kei...@keithp.com (25/02/2011): So, I'm a bit confused here -- I do 'make distcheck' to build releases, and it works for me. I'd like to know how I can test this patch to make sure it does what you expect. Do you end up building with devel docs, so with doxygen support when you're running make distcheck? Yeah, I try to build as much as I can: (from config.log) $ ./configure --enable-maintainer-mode --prefix=/local/xorg --enable-docs --enable-devel-docs --enable-kdrive --enable-dmx I even took the resulting tarball and did a separate o-o-t build with --enable-devel-docs and that seemed to work just fine. Here's one of the xmlto commands that it ran: /usr/bin/xmlto --searchpath /home/keithp/tmp/test-build/xorg-server-1.9.99.903/build/doc/xml -m /usr/share/sgml/X11/xorg.xsl --stringparam html.stylesheet=/usr/share/sgml/X11/xorg.css xhtml-nochunks ../../../../hw/dmx/doc/dmx.xml -- keith.pack...@intel.com pgpLYNqhUEeaf.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: [PULL] Server build fixes
On Fri, Feb 25, 2011 at 09:53:00AM -0800, Keith Packard wrote: On Fri, 25 Feb 2011 18:04:56 +0100, Cyril Brulebois k...@debian.org wrote: Keith Packard kei...@keithp.com (25/02/2011): So, I'm a bit confused here -- I do 'make distcheck' to build releases, and it works for me. I'd like to know how I can test this patch to make sure it does what you expect. Do you end up building with devel docs, so with doxygen support when you're running make distcheck? Yeah, I try to build as much as I can: (from config.log) $ ./configure --enable-maintainer-mode --prefix=/local/xorg --enable-docs --enable-devel-docs --enable-kdrive --enable-dmx I even took the resulting tarball and did a separate o-o-t build with --enable-devel-docs and that seemed to work just fine. Here's one of the xmlto commands that it ran: /usr/bin/xmlto --searchpath /home/keithp/tmp/test-build/xorg-server-1.9.99.903/build/doc/xml -m /usr/share/sgml/X11/xorg.xsl --stringparam html.stylesheet=/usr/share/sgml/X11/xorg.css xhtml-nochunks ../../../../hw/dmx/doc/dmx.xml Try doing the initial ./configure from out-of-tree: it should fail then. Cheers, Daniel signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] vbe: Fix malloc size bug
v2: Slightly more obvious sizing math. ==14882== Invalid write of size 2 ==14882==at 0x6750267: VBEGetVBEInfo (vbe.c:400) ==14882==by 0x6142064: ??? (in /usr/lib64/xorg/modules/drivers/vesa_drv.so) ==14882==by 0x471895: InitOutput (xf86Init.c:519) ==14882==by 0x422778: main (main.c:205) ==14882== Address 0x4f32fa8 is 72 bytes inside a block of size 73 alloc'd ==14882==at 0x4A0640D: malloc (vg_replace_malloc.c:236) ==14882==by 0x675024B: VBEGetVBEInfo (vbe.c:398) ==14882==by 0x6142064: ??? (in /usr/lib64/xorg/modules/drivers/vesa_drv.so) ==14882==by 0x471895: InitOutput (xf86Init.c:519) ==14882==by 0x422778: main (main.c:205) Signed-off-by: Adam Jackson a...@redhat.com --- hw/xfree86/vbe/vbe.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/xfree86/vbe/vbe.c b/hw/xfree86/vbe/vbe.c index bcda5ec..04132d9 100644 --- a/hw/xfree86/vbe/vbe.c +++ b/hw/xfree86/vbe/vbe.c @@ -395,7 +395,7 @@ VBEGetVBEInfo(vbeInfoPtr pVbe) i = 0; while (modes[i] != 0x) i++; -block-VideoModePtr = malloc(sizeof(CARD16) * i + 1); +block-VideoModePtr = malloc(sizeof(CARD16) * (i + 1)); memcpy(block-VideoModePtr, modes, sizeof(CARD16) * i); block-VideoModePtr[i] = 0x; -- 1.7.3.5 ___ 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] vbe: Fix malloc size bug
On Fri, Feb 25, 2011 at 13:08:59 -0500, Adam Jackson wrote: v2: Slightly more obvious sizing math. ==14882== Invalid write of size 2 ==14882==at 0x6750267: VBEGetVBEInfo (vbe.c:400) ==14882==by 0x6142064: ??? (in /usr/lib64/xorg/modules/drivers/vesa_drv.so) ==14882==by 0x471895: InitOutput (xf86Init.c:519) ==14882==by 0x422778: main (main.c:205) ==14882== Address 0x4f32fa8 is 72 bytes inside a block of size 73 alloc'd ==14882==at 0x4A0640D: malloc (vg_replace_malloc.c:236) ==14882==by 0x675024B: VBEGetVBEInfo (vbe.c:398) ==14882==by 0x6142064: ??? (in /usr/lib64/xorg/modules/drivers/vesa_drv.so) ==14882==by 0x471895: InitOutput (xf86Init.c:519) ==14882==by 0x422778: main (main.c:205) Signed-off-by: Adam Jackson a...@redhat.com --- hw/xfree86/vbe/vbe.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/xfree86/vbe/vbe.c b/hw/xfree86/vbe/vbe.c index bcda5ec..04132d9 100644 --- a/hw/xfree86/vbe/vbe.c +++ b/hw/xfree86/vbe/vbe.c @@ -395,7 +395,7 @@ VBEGetVBEInfo(vbeInfoPtr pVbe) i = 0; while (modes[i] != 0x) i++; -block-VideoModePtr = malloc(sizeof(CARD16) * i + 1); +block-VideoModePtr = malloc(sizeof(CARD16) * (i + 1)); memcpy(block-VideoModePtr, modes, sizeof(CARD16) * i); block-VideoModePtr[i] = 0x; Reviewed-by: Julien Cristau jcris...@debian.org 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
Re: [PATCH:mkfontscale 1/2] Leave room for null terminator in file font name arrays
On Thu, Feb 24, 2011 at 23:38:44 -0800, Alan Coopersmith wrote: fscanf %s arguments don't include the trailing \0 byte in their counts. Error: Buffer overrun Buffer overflow (CWE 120): Use of fscanf(%1024[), with buffer 'font' Array size is 1024 bytes at line 707 of mkfontscale.c in function 'readFontScale'. Buffer overflow (CWE 120): Use of fscanf(%1024s), with buffer 'file' Array size is 1024 bytes at line 707 of mkfontscale.c in function 'readFontScale'. [ This bug was found by the Parfait 0.3.6 bug checking tool. For more information see http://labs.oracle.com/projects/parfait/ ] Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com --- mkfontscale.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mkfontscale.c b/mkfontscale.c index ef3f490..ba2f841 100644 --- a/mkfontscale.c +++ b/mkfontscale.c @@ -679,7 +679,7 @@ readFontScale(HashTablePtr entries, char *dirname) char *filename; FILE *in; int rc, count, i; -char file[MAXFONTFILENAMELEN], font[MAXFONTNAMELEN]; +char file[MAXFONTFILENAMELEN+1], font[MAXFONTNAMELEN+1]; if(dirname[n - 1] == '/') filename = dsprintf(%sfonts.scale, dirname); Reviewed-by: Julien Cristau jcris...@debian.org 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
Re: [PATCH:mkfontscale 2/2] makeList: free partially allocated list on failure
On Thu, Feb 24, 2011 at 23:38:45 -0800, Alan Coopersmith wrote:
Error: Memory leak (CWE 401)
Memory leak of pointer 'first' allocated with malloc(8)
at line 192 of list.c in function 'makeList'.
'first' allocated at line 181 with malloc(8).
first leaks when next == 0 at line 191.
[ This bug was found by the Parfait 0.3.6 bug checking tool.
For more information see http://labs.oracle.com/projects/parfait/ ]
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
---
list.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/list.c b/list.c
index fdf81d3..a10b5ed 100644
--- a/list.c
+++ b/list.c
@@ -188,8 +188,10 @@ makeList(char **a, int n, ListPtr old, int begin)
current = first;
for(i = 1; i n; i++) {
next = malloc(sizeof(ListRec));
-if(!next)
+if(!next) {
+destroyList(first);
return NULL;
+}
next-value = a[i];
next-next = NULL;
Reviewed-by: Julien Cristau jcris...@debian.org
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
Re: [PATCH] vbe: Fix malloc size bug
From: Adam Jackson a...@redhat.com Date: Fri, 25 Feb 2011 13:08:59 -0500 v2: Slightly more obvious sizing math. ==14882== Invalid write of size 2 ==14882==at 0x6750267: VBEGetVBEInfo (vbe.c:400) ==14882==by 0x6142064: ??? (in /usr/lib64/xorg/modules/drivers/vesa_drv.so) ==14882==by 0x471895: InitOutput (xf86Init.c:519) ==14882==by 0x422778: main (main.c:205) ==14882== Address 0x4f32fa8 is 72 bytes inside a block of size 73 alloc'd ==14882==at 0x4A0640D: malloc (vg_replace_malloc.c:236) ==14882==by 0x675024B: VBEGetVBEInfo (vbe.c:398) ==14882==by 0x6142064: ??? (in /usr/lib64/xorg/modules/drivers/vesa_drv.so) ==14882==by 0x471895: InitOutput (xf86Init.c:519) ==14882==by 0x422778: main (main.c:205) Signed-off-by: Adam Jackson a...@redhat.com --- hw/xfree86/vbe/vbe.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/xfree86/vbe/vbe.c b/hw/xfree86/vbe/vbe.c index bcda5ec..04132d9 100644 --- a/hw/xfree86/vbe/vbe.c +++ b/hw/xfree86/vbe/vbe.c @@ -395,7 +395,7 @@ VBEGetVBEInfo(vbeInfoPtr pVbe) i = 0; while (modes[i] != 0x) i++; -block-VideoModePtr = malloc(sizeof(CARD16) * i + 1); +block-VideoModePtr = malloc(sizeof(CARD16) * (i + 1)); memcpy(block-VideoModePtr, modes, sizeof(CARD16) * i); block-VideoModePtr[i] = 0x; I agree that this looks better. Reviewed-by: Mark Kettenis kette...@openbsd.org ___ 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] hw/xwin: Look for gl spec files in $(srcdir) or .
Tarballs include the downloaded gl spec files, which will end up in $(srcdir). But, git-based builds will not have them at all and will need to download them from opengl.org. They'll land in in the build directory instead of $(srcdir), and so we need to allow them to be in either place. This change checks for the files in $(srcdir), linking them to . if present. Otherwise, it downloads them from opengl.org. A suggested better solution is to have Mesa install these files somewhere. Signed-off-by: Keith Packard kei...@keithp.com --- hw/xwin/glx/Makefile.am | 28 ++-- 1 files changed, 22 insertions(+), 6 deletions(-) diff --git a/hw/xwin/glx/Makefile.am b/hw/xwin/glx/Makefile.am index e9fea50..5b9d2da 100644 --- a/hw/xwin/glx/Makefile.am +++ b/hw/xwin/glx/Makefile.am @@ -33,22 +33,38 @@ indirect.c: wgl_ext_api.h SPEC_FILES = gl.spec gl.tm wglext.spec wgl.tm gl.spec: - wget http://www.opengl.org/registry/api/gl.spec + if test -f $(srcdir)/$@; then \ + $(LN) $(srcdir)/$@ .; \ + else \ + wget http://www.opengl.org/registry/api/$@; \ + fi gl.tm: - wget http://www.opengl.org/registry/api/gl.tm + if test -f $(srcdir)/$@; then \ + $(LN) $(srcdir)/$@ .; \ + else \ + wget http://www.opengl.org/registry/api/$@; \ + fi wglext.spec: - wget http://www.opengl.org/registry/api/wglext.spec + if test -f $(srcdir)/$@; then \ + $(LN) $(srcdir)/$@ .; \ + else \ + wget http://www.opengl.org/registry/api/$@; \ + fi wgl.tm: - wget http://www.opengl.org/registry/api/wgl.tm + if test -f $(srcdir)/$@; then \ + $(LN) $(srcdir)/$@ .; \ + else \ + wget http://www.opengl.org/registry/api/$@; \ + fi generated_gl_wrappers.c: gen_gl_wrappers.py gl.spec gl.tm - $(srcdir)/gen_gl_wrappers.py --spec=$(srcdir)/gl.spec --typemap=$(srcdir)/gl.tm --dispatch-header=$(top_srcdir)/glx/dispatch.h --staticwrappers generated_gl_wrappers.c + $(srcdir)/gen_gl_wrappers.py --spec=gl.spec --typemap=gl.tm --dispatch-header=$(top_srcdir)/glx/dispatch.h --staticwrappers generated_gl_wrappers.c generated_wgl_wrappers.c: gen_gl_wrappers.py wglext.spec wgl.tm - $(srcdir)/gen_gl_wrappers.py --spec=$(srcdir)/wglext.spec --typemap=$(srcdir)/wgl.tm --prefix=wgl --preresolve generated_wgl_wrappers.c + $(srcdir)/gen_gl_wrappers.py --spec=wglext.spec --typemap=wgl.tm --prefix=wgl --preresolve generated_wgl_wrappers.c wglext.h: wget http://www.opengl.org/registry/api/wglext.h -- 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
Re: [PULL] Server build fixes
On Fri, 25 Feb 2011 18:03:44 +, Daniel Stone dan...@fooishbar.org wrote: Try doing the initial ./configure from out-of-tree: it should fail then. Right, this fails only when building out-of-tree directly from git, not From a tarball. The fix isn't perfect -- there's a missing dependency issue which can be seen by building with -j5. Seems to work fine -j1. -- keith.pack...@intel.com pgpv5HhMzEKLZ.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: [PULL] Server build fixes
On Fri, 2011-02-25 at 11:02 -0800, Keith Packard wrote: Right, this fails only when building out-of-tree directly from git, not From a tarball. The doxygen generated html files are stuffed in the tarball. Doxygen is not invoked when building from a tarball. 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
[PATCH setxkbmap] Few messages added for easier troubleshooting.
If setxkbmap fails to load rules file, it is not possible to find
out where setxkbmap looks for it. Increasing verbosity level does
not help:
$ ./setxkbmap -v 10
Setting verbose level to 10
locale is C
Couldn't find rules file (evdev)
The problem fixed by adding two messages: before loading file and
after successful loading. Messages are displayed if verbosity level
is 8 or higher:
$ ./setxkbmap -v 10
Setting verbose level to 10
locale is C
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/local/share/X11/xkb/rules/evdev...
Couldn't find rules file (evdev)
Signed-off-by: Van de Bugger van.de.bug...@gmail.com
---
setxkbmap.c | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/setxkbmap.c b/setxkbmap.c
index 7aa56f7..fc0362e 100644
--- a/setxkbmap.c
+++ b/setxkbmap.c
@@ -186,6 +186,7 @@ FILE *findFileInPath(char *name);
Bool addStringToOptions(char *opt_str, list_t *opts);
char *stringFromOptions(char *orig, list_t *newOpts);
Bool applyConfig(char *name);
+XkbRF_RulesPtr tryLoadRules(char *name, char *locale, Bool wantDesc, Bool
wantRules);
Bool applyRules(void);
Bool applyComponentNames(void);
void printKeymap(void);
@@ -804,6 +805,19 @@ applyConfig(char *name)
return True;
}
+XkbRF_RulesPtr
+tryLoadRules(char *name, char *locale, Bool wantDesc, Bool wantRules)
+{
+XkbRF_RulesPtr rules = NULL;
+VMSG1(7, Trying to load rules file %s...\n, name);
+rules = XkbRF_Load(name, locale, wantDesc, wantRules);
+if (rules)
+{
+VMSG(7, Success.\n);
+};
+return rules;
+}
+
/**
* If any of model, layout, variant or options is specified, then compile the
* options into the
@@ -839,7 +853,7 @@ applyRules(void)
if (rfName[0] == '/')
{
-rules = XkbRF_Load(rfName, settings.locale.value, True, True);
+rules = tryLoadRules(rfName, settings.locale.value, True, True);
}
else
{
@@ -854,7 +868,7 @@ applyRules(void)
inclPath.item[i], rfName);
continue;
}
-rules = XkbRF_Load(buf, settings.locale.value, True, True);
+rules = tryLoadRules(buf, settings.locale.value, True, True);
}
}
if (!rules)
--
1.7.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] UMS: Fix build against xserver 1.10-rc3
This issue was introduced due to last minute backout of RandR-1.4
in xserver 1.10-rc3.
Switch to #ifdef RANDR_14_INTERFACE as suggested by Keith Packard.
See also http://lists.x.org/archives/xorg-devel/2011-February/019643.html.
Note:
The ddx needs a rebuild as the X video driver ABI changed to version 10.0.
Reported-by: Alex Deucher alexdeuc...@gmail.com
CC: Keith Packard kei...@keithp.com
Signed-off-by: Sedat Dilek sedat.di...@gmail.com
---
src/radeon_output.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/radeon_output.c b/src/radeon_output.c
index 15cef06..ccde346 100644
--- a/src/radeon_output.c
+++ b/src/radeon_output.c
@@ -1622,7 +1622,7 @@ radeon_set_mode_for_property(xf86OutputPtr output)
xf86CrtcPtr crtc = output-crtc;
if (crtc-enabled) {
-#if XORG_VERSION_CURRENT = XORG_VERSION_NUMERIC(1,9,99,901,0)
+#ifdef RANDR_14_INTERFACE
xf86CrtcSetRec crtc_set_rec;
crtc_set_rec.flags = (XF86CrtcSetMode |
--
1.7.4.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH setxkbmap] Minor style changes in help message.
1. `args' renamed to `options'. (xkbcomp and gcc name these entities
`options').
2. `Where legal args are:' replaced with `Options:'. (Short and
correct. As I remember, GNU does not recommend to use word
`legal' unless it related to law and lawyers).
3. Option descriptions shifted right by 2 space. (Like gcc.)
Signed-off-by: Van de Bugger van.de.bug...@gmail.com
---
setxkbmap.c | 46 +++---
1 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/setxkbmap.c b/setxkbmap.c
index fc0362e..5d97ad8 100644
--- a/setxkbmap.c
+++ b/setxkbmap.c
@@ -238,29 +238,29 @@ void
usage(int argc, char **argv)
{
MSG1(
-Usage: %s [args] [layout [variant [option ... ]]]\n
-Where legal args are:\n
--?, -help Print this message\n
--compat name Specifies compatibility map component name\n
--config file Specifies configuration file to use\n
--device deviceid Specifies the device ID to use\n
--display dpy Specifies display to use\n
--geometry nameSpecifies geometry component name\n
--Idir Add dir to list of directories to be used\n
--keycodes nameSpecifies keycodes component name\n
--keymap name Specifies name of keymap to load\n
--layout name Specifies layout used to choose component names\n
--model name Specifies model used to choose component names\n
--option name Adds an option used to choose component names\n
--print Print a complete xkb_keymap description and
exit\n
--query Print the current layout settings and exit\n
--rules name Name of rules file to use\n
--symbols name Specifies symbols component name\n
--synch Synchronize request w/X server\n
--types name Specifies types component name\n
--v[erbose] [lvl] Sets verbosity (1..10). Higher values yield\n
-more messages\n
--variant name Specifies layout variant used to choose component
names\n,
+Usage: %s [options] [layout [variant [option ... ]]]\n
+Options:\n
+ -?, -help Print this message\n
+ -compat name Specifies compatibility map component name\n
+ -config file Specifies configuration file to use\n
+ -device deviceid Specifies the device ID to use\n
+ -display dpy Specifies display to use\n
+ -geometry nameSpecifies geometry component name\n
+ -Idir Add dir to list of directories to be used\n
+ -keycodes nameSpecifies keycodes component name\n
+ -keymap name Specifies name of keymap to load\n
+ -layout name Specifies layout used to choose component
names\n
+ -model name Specifies model used to choose component
names\n
+ -option name Adds an option used to choose component names\n
+ -print Print a complete xkb_keymap description and
exit\n
+ -query Print the current layout settings and exit\n
+ -rules name Name of rules file to use\n
+ -symbols name Specifies symbols component name\n
+ -synch Synchronize request with X server\n
+ -types name Specifies types component name\n
+ -v[erbose] [lvl] Sets verbosity (1..10). Higher values yield\n
+ more messages\n
+ -variant name Specifies layout variant used to choose
component names\n,
argv[0]
);
}
--
1.7.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] vbe: Fix malloc size bug
On 02/25/11 10:08 AM, Adam Jackson wrote: v2: Slightly more obvious sizing math. ==14882== Invalid write of size 2 ==14882==at 0x6750267: VBEGetVBEInfo (vbe.c:400) ==14882==by 0x6142064: ??? (in /usr/lib64/xorg/modules/drivers/vesa_drv.so) ==14882==by 0x471895: InitOutput (xf86Init.c:519) ==14882==by 0x422778: main (main.c:205) ==14882== Address 0x4f32fa8 is 72 bytes inside a block of size 73 alloc'd ==14882==at 0x4A0640D: malloc (vg_replace_malloc.c:236) ==14882==by 0x675024B: VBEGetVBEInfo (vbe.c:398) ==14882==by 0x6142064: ??? (in /usr/lib64/xorg/modules/drivers/vesa_drv.so) ==14882==by 0x471895: InitOutput (xf86Init.c:519) ==14882==by 0x422778: main (main.c:205) Signed-off-by: Adam Jackson a...@redhat.com --- hw/xfree86/vbe/vbe.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/hw/xfree86/vbe/vbe.c b/hw/xfree86/vbe/vbe.c index bcda5ec..04132d9 100644 --- a/hw/xfree86/vbe/vbe.c +++ b/hw/xfree86/vbe/vbe.c @@ -395,7 +395,7 @@ VBEGetVBEInfo(vbeInfoPtr pVbe) i = 0; while (modes[i] != 0x) i++; -block-VideoModePtr = malloc(sizeof(CARD16) * i + 1); +block-VideoModePtr = malloc(sizeof(CARD16) * (i + 1)); memcpy(block-VideoModePtr, modes, sizeof(CARD16) * i); block-VideoModePtr[i] = 0x; Thanks Reviewed-by: Alan Coopersmith alan.coopersm...@oracle.com -- -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
Re: [PATCH setxkbmap; 2nd try] Consistent handling of memory allocation errors.
On 02/25/11 11:43 AM, Van de Bugger wrote:
Macro `OOM' (Out of memory) introduced for checking and reporting
memory allocation errors. The same macro is used in all the cases.
One check was missed in original source; fixed.
Signed-off-by: Van de Bugger van.de.bug...@gmail.com
---
setxkbmap.c | 27 +--
1 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/setxkbmap.c b/setxkbmap.c
index f7dbade..7aa56f7 100644
--- a/setxkbmap.c
+++ b/setxkbmap.c
@@ -170,6 +170,8 @@ static int deviceSpec = XkbUseCoreKbd;
#define ERR2(s,a,b) fprintf(stderr,s,a,b)
#define ERR3(s,a,b,c) fprintf(stderr,s,a,b,c)
+#define OOM(ptr){ if ((ptr) == NULL) { ERR(Out of memory.\n);
abort(); }; }
There's an extra ; between the last two }'s there. Also, you probably want to
stick with the original exit(-1), not force a core dump with abort();
The idiom normally used in the X code (and much C code in fact) for a
compound statement in a macro like this you want to make look like a
function call is:
#define OOM(ptr) \
do { if ((ptr) == NULL) { ERR(Out of memory.\n); abort(); } } while (0)
The do { ... } while(0) allows OOM(); to end with a ; without any compiler
warnings about empty statements or without causing any issues in breaking
other blocks, like if/else pairs, that you may wind up adjacent to.
For more complete explanations, see:
http://kernelnewbies.org/FAQ/DoWhile0
http://www.rtems.com/ml/rtems-users/2001/august/msg00086.html
http://stackoverflow.com/questions/923822/whats-the-use-of-do-while0-when-we-define-a-macro
--
-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
[PATCH] input: properly align doubles in InitValuatorClassDeviceStruct
Some architectures (hi, sparc!) are unhappy with unaligned memory
accesses. So make sure the axisVal member of ValuatorClassRec has
sizeof(double) alignment to avoid crashes and test failures.
X.Org bug#34742 https://bugs.freedesktop.org/show_bug.cgi?id=34742
Signed-off-by: Julien Cristau jcris...@debian.org
---
dix/devices.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/dix/devices.c b/dix/devices.c
index 6c0dc42..959817e 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -1225,6 +1225,7 @@ InitValuatorClassDeviceStruct(DeviceIntPtr dev, int
numAxes, Atom *labels,
{
int i;
ValuatorClassPtr valc;
+int len;
if (!dev)
return FALSE;
@@ -1237,9 +1238,10 @@ InitValuatorClassDeviceStruct(DeviceIntPtr dev, int
numAxes, Atom *labels,
numAxes = MAX_VALUATORS;
}
-valc = (ValuatorClassPtr)calloc(1, sizeof(ValuatorClassRec) +
- numAxes * sizeof(AxisInfo) +
- numAxes * sizeof(double));
+len = sizeof(ValuatorClassRec) + numAxes * sizeof(AxisInfo);
+/* round up so that valc-axisVal is properly aligned */
+len = (len + sizeof(double) - 1) ~(sizeof(double) - 1);
+valc = (ValuatorClassPtr)calloc(1, len + numAxes * sizeof(double));
if (!valc)
return FALSE;
@@ -1252,7 +1254,7 @@ InitValuatorClassDeviceStruct(DeviceIntPtr dev, int
numAxes, Atom *labels,
valc-motionHintWindow = NullWindow;
valc-numAxes = numAxes;
valc-axes = (AxisInfoPtr)(valc + 1);
-valc-axisVal = (double *)(valc-axes + numAxes);
+valc-axisVal = (double *)((char *)valc + len);
if (mode OutOfProximity)
InitProximityClassDeviceStruct(dev);
--
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
Re: [PATCH setxkbmap] Few messages added for easier troubleshooting.
On 02/25/11 12:38 PM, Van de Bugger wrote:
If setxkbmap fails to load rules file, it is not possible to find
out where setxkbmap looks for it. Increasing verbosity level does
not help:
$ ./setxkbmap -v 10
Setting verbose level to 10
locale is C
Couldn't find rules file (evdev)
The problem fixed by adding two messages: before loading file and
after successful loading. Messages are displayed if verbosity level
is 8 or higher:
$ ./setxkbmap -v 10
Setting verbose level to 10
locale is C
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/local/share/X11/xkb/rules/evdev...
Couldn't find rules file (evdev)
That certainly seems useful for troubleshooting.
+XkbRF_RulesPtr
+tryLoadRules(char *name, char *locale, Bool wantDesc, Bool wantRules)
+{
+XkbRF_RulesPtr rules = NULL;
+VMSG1(7, Trying to load rules file %s...\n, name);
+rules = XkbRF_Load(name, locale, wantDesc, wantRules);
+if (rules)
+{
+VMSG(7, Success.\n);
+};
Extra ; after }
--
-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
Re: [PATCH setxkbmap; 2nd try] Consistent handling of memory allocation errors.
Got it. See the next version.
On Fri, 2011-02-25 at 14:50 -0800, Alan Coopersmith wrote:
On 02/25/11 11:43 AM, Van de Bugger wrote:
Macro `OOM' (Out of memory) introduced for checking and reporting
memory allocation errors. The same macro is used in all the cases.
One check was missed in original source; fixed.
Signed-off-by: Van de Bugger van.de.bug...@gmail.com
---
setxkbmap.c | 27 +--
1 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/setxkbmap.c b/setxkbmap.c
index f7dbade..7aa56f7 100644
--- a/setxkbmap.c
+++ b/setxkbmap.c
@@ -170,6 +170,8 @@ static int deviceSpec = XkbUseCoreKbd;
#define ERR2(s,a,b) fprintf(stderr,s,a,b)
#define ERR3(s,a,b,c) fprintf(stderr,s,a,b,c)
+#define OOM(ptr){ if ((ptr) == NULL) { ERR(Out of memory.\n);
abort(); }; }
There's an extra ; between the last two }'s there. Also, you probably want
to
stick with the original exit(-1), not force a core dump with abort();
The idiom normally used in the X code (and much C code in fact) for a
compound statement in a macro like this you want to make look like a
function call is:
#define OOM(ptr) \
do { if ((ptr) == NULL) { ERR(Out of memory.\n); abort(); } } while (0)
The do { ... } while(0) allows OOM(); to end with a ; without any compiler
warnings about empty statements or without causing any issues in breaking
other blocks, like if/else pairs, that you may wind up adjacent to.
For more complete explanations, see:
http://kernelnewbies.org/FAQ/DoWhile0
http://www.rtems.com/ml/rtems-users/2001/august/msg00086.html
http://stackoverflow.com/questions/923822/whats-the-use-of-do-while0-when-we-define-a-macro
___
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 setxkbmap; 3rd try] Consistent handling of memory allocation errors.
Macro `OOM' (Out of memory) introduced for checking and reporting
memory allocation errors. The same macro is used in all the cases.
One check was missed in original source; fixed.
Changes after patch review:
1. `OOM' macro uses `do ... while (0)'.
2. `exit(-1)', not `abort()'.
Signed-off-by: Van de Bugger van.de.bug...@gmail.com
---
setxkbmap.c | 27 +--
1 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/setxkbmap.c b/setxkbmap.c
index f7dbade..04c3fdf 100644
--- a/setxkbmap.c
+++ b/setxkbmap.c
@@ -170,6 +170,8 @@ static int deviceSpec = XkbUseCoreKbd;
#define ERR2(s,a,b) fprintf(stderr,s,a,b)
#define ERR3(s,a,b,c) fprintf(stderr,s,a,b,c)
+#define OOM(ptr)do { if ((ptr) == NULL) { ERR(Out of memory.\n);
exit(-1); } } while (0)
+
/******/
Bool addToList(list_t *list, char *newVal);
@@ -215,19 +217,16 @@ addToList(list_t *list, char *newVal)
list-num = 0;
list-sz = 4;
list-item = (char **) calloc(list-sz, sizeof(char *));
+OOM(list-item);
}
else if (list-num = list-sz)
{
list-sz *= 2;
list-item = (char **) realloc(list-item, (list-sz) * sizeof(char
*));
-}
-if (!list-item)
-{
-ERR(Internal Error! Allocation failure in add to list!\n);
-ERR(Exiting.\n);
-exit(-1);
+OOM(list-item);
}
list-item[list-num] = strdup(newVal);
+OOM(list-item[list-num]);
list-num += 1;
return True;
}
@@ -663,8 +662,8 @@ addStringToOptions(char *opt_str, list_t *opts)
char *tmp, *str, *next;
Bool ok = True;
-if ((str = strdup(opt_str)) == NULL)
-return False;
+str = strdup(opt_str);
+OOM(str);
for (tmp = str; (tmp *tmp != '\0') ok; tmp = next)
{
next = strchr(str, ',');
@@ -700,21 +699,13 @@ stringFromOptions(char *orig, list_t *newOpts)
if (orig)
{
orig = (char *) realloc(orig, len);
-if (!orig)
-{
-ERR(OOM in stringFromOptions\n);
-return NULL;
-}
+OOM(orig);
nOut = 1;
}
else
{
orig = (char *) calloc(len, 1);
-if (!orig)
-{
-ERR(OOM in stringFromOptions\n);
-return NULL;
-}
+OOM(orig);
nOut = 0;
}
for (i = 0; i newOpts-num; i++)
--
1.7.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] hw/xwin: Look for gl spec files in $(srcdir) or .
On 25/02/2011 18:58, Keith Packard wrote: Tarballs include the downloaded gl spec files, which will end up in $(srcdir). But, git-based builds will not have them at all and will need to download them from opengl.org. They'll land in in the build directory instead of $(srcdir), and so we need to allow them to be in either place. This change checks for the files in $(srcdir), linking them to . if present. Otherwise, it downloads them from opengl.org. A suggested better solution is to have Mesa install these files somewhere. If I recall and understood correctly, mesa doesn't contain the Khronos group .spec/.tm files, but the equivalent data in some XML format. I hope I didn't imagine that, as not only would this solve the problem at hand, but I think would also be a better solution as (i) my comedy python code which parses those files could be replaced by using an XML parser, and (ii) the spec would come from a versioned source. Anyhow, I fully accept this is less than ideal as it stands, and I'll try to come up with something better for the future, as time permits. Signed-off-by: Keith Packard keithp-an4hjg94kolqt0dzr+a...@public.gmane.org Reviewed-by: Jon TURNEY jon.tur...@dronecode.org.uk ___ 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 xserver] EXA/mixed: ModifyPixmapHeader pitch fixes. (bug #33929)
Merged: 0e253a9..7b3b7ef server-1.9-branch - server-1.9-branch On Feb 24, 2011, at 19:52, Cyril Brulebois wrote: Keith Packard kei...@keithp.com (24/02/2011): On Thu, 24 Feb 2011 12:17:57 +0100, Michel Dänzer mic...@daenzer.net wrote: On the other hand, the system memory copy doesn't need the pitch to be aligned beyond the PixmapBytePad of the width. Merged. Hi Jeremy, please consider 31704510f448706524b7b7085cc4ff0ada7bfe7e for 1.9.x, it fixes nasty things for radeon at least. (Debian unstable) users have been happy with it on top of 1.9.4, it's probably a good idea to cherry-pick it in server-1.9-branch. KiBi. ___ 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] hw/xwin: Look for gl spec files in $(srcdir) or .
On Sat, 26 Feb 2011 00:19:45 +, Jon TURNEY jon.tur...@dronecode.org.uk wrote: Anyhow, I fully accept this is less than ideal as it stands, and I'll try to come up with something better for the future, as time permits. Argh. My first patch didn't work in the o-o-t build from tarball case (sigh). I've actually got a simpler patch that appears to work in all cases now. It simply has the commands check for a local file, and when that fails, to use $(srcdir). I wish gnumake provided syntax within the command for files which should follow the vpath stuff. diff --git a/hw/xwin/glx/Makefile.am b/hw/xwin/glx/Makefile.am index e9fea50..303ff53 100644 --- a/hw/xwin/glx/Makefile.am +++ b/hw/xwin/glx/Makefile.am @@ -45,10 +45,10 @@ wgl.tm: wget http://www.opengl.org/registry/api/wgl.tm generated_gl_wrappers.c: gen_gl_wrappers.py gl.spec gl.tm - $(srcdir)/gen_gl_wrappers.py --spec=$(srcdir)/gl.spec --typemap=$(srcdir)/gl.tm --dispatch-header=$(top_srcdir)/glx/dispatch.h --staticwrappers generated_gl_wrappers.c + $(srcdir)/gen_gl_wrappers.py --spec=`test -e gl.spec || echo $(srcdir)/`gl.spec --typemap=`test -e gl.tm || echo $(srcdir)/`gl.tm --dispatch-header=$(top_srcdir)/glx/dispatch.h --staticwrappers generated_gl_wrappers.c generated_wgl_wrappers.c: gen_gl_wrappers.py wglext.spec wgl.tm - $(srcdir)/gen_gl_wrappers.py --spec=$(srcdir)/wglext.spec --typemap=$(srcdir)/wgl.tm --prefix=wgl --preresolve generated_wgl_wrappers.c + $(srcdir)/gen_gl_wrappers.py --spec=`test -e wglext.spec || echo $(srcdir)/`wglext.spec --typemap=`test -e wgl.tm || echo $(srcdir)/`wgl.tm --prefix=wgl --preresolve generated_wgl_wrappers.c wglext.h: wget http://www.opengl.org/registry/api/wglext.h -- keith.pack...@intel.com pgpzxOyw7sskB.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: [PULL] Server build fixes
On Fri, 25 Feb 2011 06:43:58 -0800, Dan Nicholson dbn.li...@gmail.com wrote: Dan Nicholson (2): xfree86: Allow sdksyms.dep to be included portably dmx: Construct paths in doxygen.conf to fix VPATH builds Merged. 780a77a..6b951de master - master -- keith.pack...@intel.com pgpOEr02XLbPd.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
New Linux VT Keyboard Mode Off
Currently the linux-next branch of the linux kernel contains a patch to add a new vt keyboard mode off. In this new mode all special kernel keys are ignored, like how they are ignored in raw mode, but no key events are buffered to the vt input buffer. The patch adding the new mode has been included because it has the potential to clean up and fix a corner case of the xserver vt input handling in hw/xfree86/os-support/linux/lnx_init.c. In the interest of full disclosure, I authored the patch. A complete saga is at http://art.ified.ca/?p=278 This also fixes the corner case of if AllowEmptyInput is false but input-kbd isn't loaded the VT input buffer can overflow. Also, calling flush per-keystroke seems to be more of a band-aid than a real fix. Expect a sample patch using the new mode soon. Cheers -Art -- Arthur Taylor a...@ified.ca theycallhim...@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: [PATCH] input: properly align doubles in InitValuatorClassDeviceStruct
On Sat, 26 Feb 2011 00:00:39 +0100, Julien Cristau jcris...@debian.org wrote:
Some architectures (hi, sparc!) are unhappy with unaligned memory
accesses. So make sure the axisVal member of ValuatorClassRec has
sizeof(double) alignment to avoid crashes and test failures.
The 'standard' way to do this is to use a union to ensure correct
alignment. Seems like simply moving the doubles to after the
ValuatorClassRec and using a union between a double and the
ValuatorClassRec would fix this without a lot of ugly pointer computations.
This is completely untested, but I imagine something the following would work:
diff --git a/dix/devices.c b/dix/devices.c
index 6c0dc42..89294aa 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -1225,6 +1225,7 @@ InitValuatorClassDeviceStruct(DeviceIntPtr dev, int
numAxes, Atom *labels,
{
int i;
ValuatorClassPtr valc;
+union align_u { ValuatorClassRec valc; double d; } *align;
if (!dev)
return FALSE;
@@ -1237,12 +1238,13 @@ InitValuatorClassDeviceStruct(DeviceIntPtr dev, int
numAxes, Atom *labels,
numAxes = MAX_VALUATORS;
}
-valc = (ValuatorClassPtr)calloc(1, sizeof(ValuatorClassRec) +
- numAxes * sizeof(AxisInfo) +
- numAxes * sizeof(double));
-if (!valc)
+align = (union align_u *) calloc(1, sizeof(union align_u) +
+numAxes * sizeof(double) +
+numAxes * sizeof(AxisInfo));
+if (!align)
return FALSE;
+valc = align-valc;
valc-sourceid = dev-id;
valc-motion = NULL;
valc-first_motion = 0;
@@ -1251,8 +1253,8 @@ InitValuatorClassDeviceStruct(DeviceIntPtr dev, int
numAxes, Atom *labels,
valc-numMotionEvents = numMotionEvents;
valc-motionHintWindow = NullWindow;
valc-numAxes = numAxes;
-valc-axes = (AxisInfoPtr)(valc + 1);
-valc-axisVal = (double *)(valc-axes + numAxes);
+valc-axisVal = (double *)(align + 1);
+valc-axes = (AxisInfoPtr)(valc-axisVal + numAxes);
if (mode OutOfProximity)
InitProximityClassDeviceStruct(dev);
--
keith.pack...@intel.com
pgpMA9CvjvTp3.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
[PATCH:xscope] Greatly reduce xscope's bss pages
xscope had several static arrays of StaticMaxFD structures, which ended up
in .bss sections. StaticMaxFD was initialized to FD_SETSIZE.
On 32-bit Solaris, the default value FD_SETSIZE is 1024.
On 64-bit Solaris, the FD_SETSIZE is 64k, due to the SPARCv9 ABI.
One of the structures allocated included the 32k data buffer for each FD.
This resulted in the highly excessive mapping of 2gb of .bss when building
64-bit binaries on Solaris, and 32mb for 32-bit binaries.
After this patch, only 52k of .bss is mapped.
(Actual RSS pages for xscope were barely changed.)
To reduce this, the static tables were replaced with callocs of MaxFD
tables, where MaxFD is now the smaller of StaticMaxFD or the current
fd limit. StaticMaxFD is reduced by default to 256, since xscope is
rarely used with large numbers of clients (it can be recompiled with a
larger StaticMaxFD when needed).
Additionally, the 32k buffers are allocated only when FD's are opened to
use them, instead of for the maximum possible number of FD's.
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
---
common.c | 16
decode11.c | 11 +++
fd.c | 11 +++
fd.h | 14 +-
proto.h|1 +
scope.c| 16
scope.h|4 ++--
server.c |2 +-
table11.c |1 +
x11.h |2 +-
10 files changed, 49 insertions(+), 29 deletions(-)
diff --git a/common.c b/common.c
index 1d48530..7ac342c 100644
--- a/common.c
+++ b/common.c
@@ -93,6 +93,22 @@ Malloc (longn)
return(p);
}
+void *
+CallocPerFD (longn)
+{
+ void *p;
+ p = calloc(MaxFD, n);
+ debug(64,(stderr, %lx = calloc(%d, %ld)\n, (unsigned long) p, MaxFD, n));
+ if (p == NULL)
+{
+ fprintf(stderr, failed to allocate %d bytes for %d files\n,
+ MaxFD * n, MaxFD);
+ panic(cannot continue);
+}
+ return(p);
+}
+
+
void
Free(void *p)
{
diff --git a/decode11.c b/decode11.c
index a9360ff..fb5cb73 100644
--- a/decode11.c
+++ b/decode11.c
@@ -133,19 +133,14 @@ struct QueueHeader
struct QueueEntry *Tail;
};
-static struct QueueHeader ReplyQ[StaticMaxFD];
+static struct QueueHeader *ReplyQ;
/* */
void
InitReplyQ (void)
{
- short i;
- for (i = 0; i StaticMaxFD; i++)
-{
- ReplyQ[i].Head = NULL;
- ReplyQ[i].Tail = NULL;
-}
+ ReplyQ = CallocPerFD(sizeof(struct QueueHeader));
}
void
@@ -209,7 +204,7 @@ SequencedReplyExpected (
/* find the server associated with this client */
fd = FDPair(fd);
- if (fd 0 || fd = StaticMaxFD) return;
+ if (fd 0 || fd = MaxFD) return;
/* attach the new queue entry to the end of the queue for the Server */
if (ReplyQ[fd].Tail != NULL)
diff --git a/fd.c b/fd.c
index 5096e70..623e45f 100644
--- a/fd.c
+++ b/fd.c
@@ -84,7 +84,7 @@
void
InitializeFD(void)
{
- register short i;
+ int i;
enterprocedure(InitializeFD);
/* get the number of file descriptors the system will let us use */
@@ -100,17 +100,12 @@ InitializeFD(void)
}
if (MaxFD StaticMaxFD)
{
- fprintf(stderr, Recompile with larger StaticMaxFD value %d\n, MaxFD);
MaxFD = StaticMaxFD;
}
/* allocate space for a File Descriptor (FD) Table */
- FDD = (struct FDDescriptor *)
-Malloc ((long)(MaxFD * sizeof (struct FDDescriptor)));
- if (FDD == NULL) {
- panic(Can't allocate memory!);
- }
- bzero(FDD, (MaxFD * sizeof (struct FDDescriptor)));
+ FDD = CallocPerFD(sizeof (struct FDDescriptor));
+ FDinfo = CallocPerFD(sizeof (struct fdinfo));
/* be sure all fd's are closed and marked not busy */
for (i = 0; i MaxFD; i++)
diff --git a/fd.h b/fd.h
index 76a3e6e..a711359 100644
--- a/fd.h
+++ b/fd.h
@@ -78,17 +78,21 @@ struct FDDescriptor
};
extern struct FDDescriptor *FDD /* array of FD descriptors */ ;
-extern short MaxFD /* maximum number of FD's possible */ ;
+extern int MaxFD /* maximum number of FD's possible */ ;
-extern short nFDsInUse /* number of FD's actually in use */ ;
+extern int nFDsInUse /* number of FD's actually in use */ ;
extern fd_set ReadDescriptors /* bit map of FD's in use -- for select */ ;
extern fd_set WriteDescriptors /* bit map of write blocked FD's -- for select
*/;
extern fd_set BlockedReadDescriptors /* bit map of FD's blocked from reading
*/;
-extern short HighestFD /* highest FD in use -- for select */ ;
+extern int HighestFD /* highest FD in use -- for select */ ;
-/* need to change the MaxFD to allow larger number of fd's */
-#define StaticMaxFD FD_SETSIZE
+/* cap the number of file descriptors to a reasonable size as long as
+ we're preallocating structs for every one
+ */
+#ifndef StaticMaxFD
+# define StaticMaxFD 256
+#endif
extern void InitializeFD(void);
extern void UsingFD(FD fd, void (*Handler)(int), void (*FlushHandler)(int),
diff --git a/proto.h b/proto.h
index d7dfaec..268e212 100644
--- a/proto.h
+++
