nx-libs/nx-X11/programs/Xserver/mi, branch 3.5.99.21

mi/miexpose.c: add missing free()

2019-06-22T09:30:54+00:00

mi/miinitext.c: fix memleaks: remove (double) glx initialization

2019-06-18T22:49:57+00:00

Fix these memory leaks: ==30021== 128 bytes in 1 blocks are definitely lost in loss record 230 of 302 ==30021== at 0x483577F: malloc (vg_replace_malloc.c:299) ==30021== by 0x2EF89C: init_visuals (xf86glx.c:390) ==30021== by 0x2EF89C: __MESA_initVisuals (xf86glx.c:541) ==30021== by 0x17C922: GlxInitVisuals (glxext.c:317) ==30021== by 0x218E73: fbInitVisuals (fbcmap.c:668) ==30021== by 0x20BEB1: fbFinishScreenInit (fbscreen.c:229) ==30021== by 0x20C275: fbScreenInit (fbscreen.c:273) ==30021== by 0x1E0317: nxagentOpenScreen (Screen.c:1357) ==30021== by 0x16D848: AddScreen (dispatch.c:4171) ==30021== by 0x1DB7FF: InitOutput (Init.c:396) ==30021== by 0x14DB12: main (main.c:279) ==30021== ==30021== 3,072 (192 direct, 2,880 indirect) bytes in 1 blocks are definitely lost in loss record 290 of 302 ==30021== at 0x483577F: malloc (vg_replace_malloc.c:299) ==30021== by 0x2CCCC7: _gl_context_modes_create (glcontextmodes.c:364) ==30021== by 0x2EF87C: init_visuals (xf86glx.c:381) ==30021== by 0x2EF87C: __MESA_initVisuals (xf86glx.c:541) ==30021== by 0x17C922: GlxInitVisuals (glxext.c:317) ==30021== by 0x218E73: fbInitVisuals (fbcmap.c:668) ==30021== by 0x20BEB1: fbFinishScreenInit (fbscreen.c:229) ==30021== by 0x20C275: fbScreenInit (fbscreen.c:273) ==30021== by 0x1E0317: nxagentOpenScreen (Screen.c:1357) ==30021== by 0x16D848: AddScreen (dispatch.c:4171) ==30021== by 0x1DB7FF: InitOutput (Init.c:396) ==30021== by 0x14DB12: main (main.c:279) The problem here is that GlxInitVisuals is called twice. First via fbScreenInit and then again via nxagentInitGlxExtension. We remove the first one to ensure the code in nxagenOpenScreen works as initially intended. There's an xorg upstream patch that does the same (7d74690536b64f7b8e8036507ab7790807349c50), but it also cleans up other stuff we do not even have in out source (yet?).

miwindow.c: add hint to Red Hat Bugzilla + fix

2019-06-12T16:45:02+00:00

mi: Hush an almost certainly bogus warning

2019-06-12T16:45:02+00:00

commit 57e872301f5e836be2efb8f952f9c9711650b447 Author: Adam Jackson Date: Thu Apr 5 13:07:09 2018 -0400 mi: Hush an almost certainly bogus warning In file included from ../mi/miexpose.c:83: ../mi/miexpose.c: In function ‘miHandleExposures’: ../include/regionstr.h:174:22: warning: ‘expBox.y2’ may be used uninitialized in this function [-Wmaybe-uninitialized] (_pReg)->extents = *(_pBox); ~~~~~~~~~~~~~~~~~^~~~~~~~~~ ../mi/miexpose.c:139:12: note: ‘expBox.y2’ was declared here BoxRec expBox; ^~~~~~ etc. It's initialized if (extents), and then only read if (extents), but gcc doesn't seem to figure that out. Whatever, bzero it to be explicit. Signed-off-by: Adam Jackson Acked-by: Keith Packard

Remove the Must_have_memory hack.

2019-06-12T16:35:01+00:00

We are not using any alloc function that respects that variable, so lets drop it. Backport of this commit: commit 0ce61e21d6d7dcca0090e319bbcdb678570f2c3f Author: Adam Jackson Date: Fri Oct 3 16:05:19 2008 -0400 Remove the Must_have_memory hack. Also remove an astonishing amount of misunderstanding of how casts work.

NXmiexpose.c: drop file altogether

2019-06-11T10:09:27+00:00

The only left function is identical to the one in mi/miexpose.c.

NXmiexpose.c: use upstream version of miPaintWindows()

2019-06-11T10:09:27+00:00

miPaintWindow() was identical to the version in miexpose.c except for some unitialized variable fixes. As these also should be in upstream code we add them there (Note: Xorg never fixed this but totally rewrote the miPaintWindow() later on.) This allows us to totally drop our special version of miPaintWindow().

NXmiexpose.c: use upstream miHandleExposures()

2019-06-11T10:09:27+00:00

It is (functionally) identical to our code, so why have duplicate code?

Die XTESTEXT1, die!

2019-05-10T17:02:51+00:00

commit a73e0f8cdfec1c9199ffe696146ba7d677c4c10d Author: Daniel Stone Date: Thu Jun 1 18:47:47 2006 +0000 Die XTESTEXT1, die! Citing an email from the xorg-modular mailing list: On Tuesday 21 February 2006 23:04, Enrico Weigelt wrote: > Hi folks, > > I'm wondering what's the difference between XTEST and XTESTEXT1 > (the second one can be configured w/ my current patch ...) > Are they both the same ( -> XTest extension ) ? > Can I put both symbols together ? They're not the same extension. XTest is the one you want, if you want either. The other hasn't been built by default in ages and I should probably go ahead and nuke it from the tree. - ajax

misc: fix more regressions and whitespace weirdness introduced in 913fcf1a74426725f14380dd5b34286a21c37ab7.

2018-07-07T06:05:24+00:00