aboutsummaryrefslogtreecommitdiff
path: root/nx-X11/programs
Commit message (Collapse)AuthorAgeFilesLines
* release 3.5.99.213.5.99.21Mike Gabriel2019-08-051-1/+1
|
* drop onscreen keyboard supportUlrich Sibiller2019-06-272-75/+1
| | | | | | | | | With the removal of the Ipaq code there's no path anymore to open the onscreen keyboard. Also nxkbd is not available and we do not have tested that feature with any onscreen keyboard yet. So there's no point in integrating that code. Fixes ArcticaProject/nx-libs#405
* Drop Ipaq supportUlrich Sibiller2019-06-276-61/+5
| | | | Did we ever provide a binary?
* Screen.c: use XlibWindow so silence the compilerUlrich Sibiller2019-06-271-2/+2
| | | | | | | | | | | | | | This is a bit weird, I'd expect far more places where the compiler could complain about Window vs Window64... But it does not. Screen.c:306:32: warning: passing argument 3 of ‘XQueryTree’ from incompatible pointer type [-Wincompatible-pointer-types] if (XQueryTree(d, candidate, &root, &parent, &children, &num_children)) ^~~~~ In file included from Screen.c:60: Agent.h:85:25: note: expected ‘Window64 *’ {aka ‘long unsigned int *’} but argument is of type ‘Window *’ {aka ‘unsigned int *’} #define Window Window64 ../../../../exports/include/nx-X11/Xlib.h:3041:5: note: in expansion of macro ‘Window’ Window* /* root_return */,
* Consistently use None instead of 0 for nxagentIconWindow everywhereUlrich Sibiller2019-06-272-2/+2
|
* Screen.c: simplify nxagentMinimizeFromFullscreenUlrich Sibiller2019-06-271-6/+9
|
* nxagentMaximizeToFullScreen: only reparent if necessaryUlrich Sibiller2019-06-271-21/+56
| | | | | | | | This fixes problems with kwin and compiz when using the switch-all-screens keystroke. The fullscreen would appear shortly and then vanish again. Fixes ArcticaProject/nx-libs#458
* Screen.c: add nxagentIsParentOf helperUlrich Sibiller2019-06-271-0/+22
|
* Window.c: rearrange code regarding window decorations sizesUlrich Sibiller2019-06-271-2/+9
|
* Window.c: add some comments about fullscreen handlingUlrich Sibiller2019-06-271-0/+12
|
* rework xkb device private handlingUlrich Sibiller2019-06-224-16/+23
| | | | | | | We can only free the xkbDevicePrivate because we do not know the details of any other (possible) extension. So let's limit to that one private for now and call the new xkbFreePrivates from dix (where such a function is completely missing).
* record/set.c: silence cpp findingUlrich Sibiller2019-06-221-1/+2
| | | | | | | | [nx-X11/programs/Xserver/record/set.c:361]: (warning) Possible null pointer dereference: stackIntervals stackIntervals is only NULL if nIntervals is 0, too. In that case memcpy will do nothing and so it is ok to pass NULL as source. But it is ugly nevertheless...
* Keyboard.c: use existing define instead of hardcoced valueUlrich Sibiller2019-06-221-1/+1
|
* Keyboard.c: fix another cppcheck findingUlrich Sibiller2019-06-221-1/+2
| | | | [Keyboard.c:559]: (error) Shifting signed 32-bit value by 31 bits is undefined behaviour
* xkb: fix what looks to be a copy-paste error with first vs firstMMUlrich Sibiller2019-06-221-1/+1
| | | | | | | | | | | | commit 758393951233d1b2520cf4cefd33ec4288a3880a Author: Dave Airlie <airlied@redhat.com> Date: Wed Sep 12 11:09:40 2018 +1000 xkb: fix what looks to be a copy-paste error with first vs firstMM Pointed out by coverity. Signed-off-by: Dave Airlie <airlied@redhat.com>
* xkmread.c: fix compiler warningUlrich Sibiller2019-06-221-0/+4
| | | | | | xkmread.c: In function ‘XkmReadFileSectionName’: xkmread.c:1181:25: warning: ‘tmpTOC.type’ may be used uninitialized in this function [-Wmaybe-uninitialized] XkbConfigText(tmpTOC.type,XkbMessage),0);
* xkb: Silence some compiler warningsUlrich Sibiller2019-06-221-5/+6
| | | | | | | | | | | | | | | | | | | | | | commit 83913de25d35709b3ab7b0ab124b73924145d2dd Author: Adam Jackson <ajax@redhat.com> Date: Thu Apr 5 12:59:11 2018 -0400 xkb: Silence some compiler warnings Of the form: ../xkb/XKBGAlloc.c: In function ‘SrvXkbAddGeomKeyAlias’: ../xkb/XKBGAlloc.c:591:13: warning: ‘strncpy’ specified bound 4 equals destination size [-Wstringop-truncation] strncpy(alias->real, realStr, XkbKeyNameLength); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is intentional; the code that reads from these fields never reads more than 4 bytes anyway. Rephrase things in terms of memcpy so that's clear. Obviously this is awful but in XKB awful is par. Signed-off-by: Adam Jackson <ajax@redhat.com> Acked-by: Keith Packard <keithp@keithp.com>
* xkb: Use snprintf to measure string lengths instead of manual strlen mathUlrich Sibiller2019-06-222-12/+12
| | | | | | | | | | | | commit a4a2e814d5d0e6152307a301eda1d6fc1c555aaa Author: Alan Coopersmith <alan.coopersmith@oracle.com> Date: Sun Feb 13 21:36:02 2011 -0800 xkb: Use snprintf to measure string lengths instead of manual strlen math Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Daniel Stone <daniel@fooishbar.org>
* xkbEvents.c: Fix "warning: unused variable `s'".Ulrich Sibiller2019-06-221-5/+4
| | | | | | | | commit 2391c409a2840d61fed93832650c0d6c82ebebdf Author: Eamon Walsh <ewalsh@tycho.nsa.gov> Date: Fri Jun 13 22:48:17 2008 -0400 Fix "warning: unused variable `s'".
* XKB: Remove a bunch of mad ifdefsUlrich Sibiller2019-06-2215-243/+67
| | | | | | | | | | | commit 534fc5140b039a8c98ab715d0a6740d513b41209 Author: Daniel Stone <daniel@fooishbar.org> Date: Sun Feb 3 23:30:22 2008 +1100 XKB: Remove a bunch of mad ifdefs We have SEEK_SET and size_t, seriously. Also use DebugF instead of ifdef DEBUG, and ditch a couple of random bits that were never used.
* xkb: remove oldState from XkbHandleActions.Ulrich Sibiller2019-06-221-4/+2
| | | | | | | | | | | | | | | | | | | | Fixes this cppcheck finding: [nx-X11/programs/Xserver/xkb/xkbActions.c:1306]: (error) Uninitialized variable: oldState commit 35a4b8e7f4526a92d44cb16a783f21030cd1f6df Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Tue May 5 16:51:59 2009 +1000 xkb: remove oldState from XkbHandleActions. I really don't know what the purpose of this variable is or was, aside from potentially clobbering up our key state since there's a path where it may be used uninitialised. Also, this means that xkbi->prev_state is now accessible from the DIX with meaningful data. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
* mi/miexpose.c: add missing free()Ulrich Sibiller2019-06-221-0/+3
|
* compext/Png.c: Nullify after freeUlrich Sibiller2019-06-221-2/+2
|
* compext/Png.c: simplify srcBuf allocationUlrich Sibiller2019-06-221-30/+13
|
* compext/Png.c: late image_index allocationUlrich Sibiller2019-06-221-17/+18
| | | | | | | | Move allocation of image_index close before first_use. This way we do not need to free it if previous step fail. And we cannot forget that free() call. While at it replace malloc+memset by calloc.
* NXdixfonts.c: fix index out of boundsUlrich Sibiller2019-06-221-2/+2
|
* Keyboard.c: rearrange code to make cppcheck happyUlrich Sibiller2019-06-221-1/+4
| | | | Otherwise it will (falsely) report "Memory pointed to by 'sessionpath' is freed twice."
* os/access.c: add missing }Ulrich Sibiller2019-06-221-0/+1
|
* NXpicture.c: code simplificationUlrich Sibiller2019-06-221-6/+2
|
* Screen.c: fix two more memleaks of visualsUlrich Sibiller2019-06-221-0/+2
|
* Screen.c: fix two memleaksUlrich Sibiller2019-06-221-19/+18
| | | | While at it create and use the freeDepths() helper function.
* NXrender: fix another memleakUlrich Sibiller2019-06-221-1/+5
|
* render: Propagate allocation failure from createSourcePicture()Ulrich Sibiller2019-06-222-0/+4
| | | | | | | | | | | | | | | | | commit 211d4c2d353b5e379716484055a3f58235ea65f4 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Dec 14 15:55:22 2011 +0000 render: Propagate allocation failure from createSourcePicture() All the callers were already checking for failure, except that createSourcePicture() itself was failing to check whether it successfully allocated the Picture. [ajax: Rebase, fix line wrap of preceding line] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
* fb: fix memory leak in fbOverlayFinishScreenInitUlrich Sibiller2019-06-221-2/+6
| | | | | | | | | | | | commit 2aa935bc5cc1e2d5365a97b8c5bb3d33eb5fc758 Author: Tiago Vignatti <tiago.vignatti@nokia.com> Date: Fri Mar 25 22:10:55 2011 +0200 fb: fix memory leak in fbOverlayFinishScreenInit Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com> Reviewed-by: Nicolas Peninguy <nico@lostgeeks.org> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
* dix/dispatch: fix a small memory leakUlrich Sibiller2019-06-221-0/+3
|
* Keyboard.c: fix three memory leaksUlrich Sibiller2019-06-221-0/+4
| | | | | | | | | | | | | | | | | | | | | ==12976==ERROR: LeakSanitizer: detected memory leaks Direct leak of 6 byte(s) in 1 object(s) allocated from: #0 0x7f510b3ac810 in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3a810) #1 0x559ca29c5035 in nxagentKeyboardProc /home/uli/work/nx/ArcticaProject/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Keyboard.c:866 #2 0x7a29bff07 (<unknown module>) Direct leak of 1 byte(s) in 1 object(s) allocated from: #0 0x7f510b3ac810 in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3a810) #1 0x559ca29c509a in nxagentKeyboardProc /home/uli/work/nx/ArcticaProject/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Keyboard.c:870 #2 0x7a29bff07 (<unknown module>) Direct leak of 1 byte(s) in 1 object(s) allocated from: #0 0x7f510b3ac810 in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3a810) #1 0x559ca29c507f in nxagentKeyboardProc /home/uli/work/nx/ArcticaProject/nx-libs/nx-X11/programs/Xserver/hw/nxagent/Keyboard.c:869 #2 0x7a29bff07 (<unknown module>) SUMMARY: AddressSanitizer: 8 byte(s) leaked in 3 allocation(s).
* glyph.c: fix a read beyond end of heap bufferUlrich Sibiller2019-06-222-0/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | If compiled with -fsanitize=address this showed up when running startlxde: ==11551==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60d000018fbc at pc 0x7f270a9ed57b bp 0x7fff30ef3050 sp 0x7fff30ef2800 READ of size 204 at 0x60d000018fbc thread T0 #0 0x7f270a9ed57a (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a) #1 0x559dafcd5c93 in FindGlyphRef ../../render/glyph.c:179 #2 0x559dafcd705d in AddGlyph /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXglyph.c:71 #3 0x559dafccc0ff in ProcRenderAddGlyphs ../../mi/../render/render.c:1186 #4 0x559dafcbd5a5 in ProcRenderDispatch /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXrender.c:1689 #5 0x559dafcbc4ea in Dispatch /work/nx-libs/nx-X11/programs/Xserver/hw/nxagent/NXdispatch.c:476 #6 0x559dafc4e9b0 in main /work/nx-libs/nx-X11/programs/Xserver/dix/main.c:353 #7 0x7f2708e1d09a in __libc_start_main ../csu/libc-start.c:308 #8 0x559dafc4f5d9 in _start (/work/nx-libs/nx-X11/programs/Xserver/nxagent+0x6e5d9) 0x60d000018fbc is located 0 bytes to the right of 140-byte region [0x60d000018f30,0x60d000018fbc) allocated by thread T0 here: #0 0x7f270aa1e330 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe9330) #1 0x559dafcd646c in AllocateGlyph ../../render/glyph.c:348 This happens when two glyphs are compared via memcmp and the smaller one happens to be identical to the beginning of the bigger one. Newer render implementations use a sha1 hash instead of memcmp so this patch will (hopefully) be obsolete once render gets updated.
* Font.c: code simplificationsUlrich Sibiller2019-06-191-20/+9
|
* various scope improvementsUlrich Sibiller2019-06-198-107/+50
|
* glxext.c: fix another memory leakUlrich Sibiller2019-06-191-3/+1
| | | | | | | | | | | | | | | | ==10226== 3,337 bytes in 1 blocks are definitely lost in loss record 295 of 307 ==10226== at 0x483577F: malloc (vg_replace_malloc.c:299) ==10226== by 0x6281DB9: strdup (strdup.c:42) ==10226== by 0x2ABA9E: __glXClientInfo (glxcmds.c:2170) ==10226== by 0x17CA3E: __glXDispatch (NXglxext.c:128) ==10226== by 0x16EE77: Dispatch (NXdispatch.c:476) ==10226== by 0x14DCE0: main (main.c:353) There's no point in trying to free cl->* after memset(0). This one is a bug that is found identically in xorg upstream and has only been fixed during rework of the whole client resource freeing stuff. So we fix it in glxext.c.
* Screen.c: more debug outputUlrich Sibiller2019-06-191-1/+4
|
* Extension.c: code simplificationsUlrich Sibiller2019-06-191-8/+3
|
* Events.c: use designated initializer in nxagentDeactivatePointerGrabUlrich Sibiller2019-06-191-15/+17
|
* mi/miinitext.c: fix memleaks: remove (double) glx initializationUlrich Sibiller2019-06-191-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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?).
* Screen.c: fix another memory leakUlrich Sibiller2019-06-191-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ==12280== 0 bytes in 5 blocks are definitely lost in loss record 1 of 304 ==12280== at 0x483577F: malloc (vg_replace_malloc.c:299) ==12280== by 0x2EFC29: init_visuals (xf86glx.c:489) ==12280== by 0x2EFC29: __MESA_initVisuals (xf86glx.c:540) ==12280== by 0x17C902: GlxInitVisuals (glxext.c:317) ==12280== by 0x218C03: fbInitVisuals (fbcmap.c:668) ==12280== by 0x20BC41: fbFinishScreenInit (fbscreen.c:229) ==12280== by 0x20C005: fbScreenInit (fbscreen.c:273) ==12280== by 0x1E024C: nxagentOpenScreen (Screen.c:1356) ==12280== by 0x16D828: AddScreen (dispatch.c:4171) ==12280== by 0x1DB7DF: InitOutput (Init.c:396) ==12280== by 0x14DB12: main (main.c:279) ==12280== ==12280== 64 bytes in 2 blocks are definitely lost in loss record 223 of 304 ==12280== at 0x483577F: malloc (vg_replace_malloc.c:299) ==12280== by 0x2EFA05: init_visuals (xf86glx.c:489) ==12280== by 0x2EFA05: __MESA_initVisuals (xf86glx.c:540) ==12280== by 0x17C902: GlxInitVisuals (glxext.c:317) ==12280== by 0x218C03: fbInitVisuals (fbcmap.c:668) ==12280== by 0x20BC41: fbFinishScreenInit (fbscreen.c:229) ==12280== by 0x20C005: fbScreenInit (fbscreen.c:273) ==12280== by 0x1E024C: nxagentOpenScreen (Screen.c:1356) ==12280== by 0x16D828: AddScreen (dispatch.c:4171) ==12280== by 0x1DB7DF: InitOutput (Init.c:396) ==12280== by 0x14DB12: main (main.c:279)
* Fix memleaks: Free devPrivates of devices on shutdownUlrich Sibiller2019-06-192-3/+17
| | | | | | | | | | | | | | | | | | | | | | Fixes these two memory leaks identified by valgrind: ==28336== 32 (8 direct, 24 indirect) bytes in 1 blocks are definitely lost in loss record 180 of 308 ==28336== at 0x48356AF: malloc (vg_replace_malloc.c:298) ==28336== by 0x4837DE7: realloc (vg_replace_malloc.c:826) ==28336== by 0x1AE322: AllocateDevicePrivate (privates.c:439) ==28336== by 0x27527B: XkbSetExtension (xkbActions.c:72) ==28336== by 0x198E9B: _RegisterPointerDevice (devices.c:361) ==28336== by 0x1DBA35: InitInput (Init.c:440) ==28336== by 0x14DBD6: main (main.c:303) ==28336== ==28336== 32 (8 direct, 24 indirect) bytes in 1 blocks are definitely lost in loss record 181 of 308 ==28336== at 0x48356AF: malloc (vg_replace_malloc.c:298) ==28336== by 0x4837DE7: realloc (vg_replace_malloc.c:826) ==28336== by 0x1AE322: AllocateDevicePrivate (privates.c:439) ==28336== by 0x27527B: XkbSetExtension (xkbActions.c:72) ==28336== by 0x198F1B: _RegisterKeyboardDevice (devices.c:384) ==28336== by 0x1DBA3D: InitInput (Init.c:441) ==28336== by 0x14DBD6: main (main.c:303)
* CloseDevice: call XkbRemoveResourceClient before freeing key class structUlrich Sibiller2019-06-191-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | This patch is not necessary at the current code level. But when xkb code introduced the dev->key check Xorg upstream missed that. So we backport it now to skip that trap when updating xkb code. Author: Alan Coopersmith <alan.coopersmith@sun.com> Date: Mon Jan 4 18:21:54 2010 -0800 CloseDevice: call XkbRemoveResourceClient before freeing key class struct XkbRemoveResourceClient() returns immediately if dev->key is NULL. CloseDevice calls XkbRemoveResourceClient until it removes all resources. If we free dev->key and NULL it before XkbRemoveResourceClient, then infinite loop ensues, and the server appears to hang on exit or crash. Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Daniel Stone <daniel@fooishbar.org> Signed-off-by: Keith Packard <keithp@keithp.com> Backported-to-NX-by: Ulrich Sibiller <uli42@gmx.de>
* Keyboard.c: nullify freed pointersUlrich Sibiller2019-06-191-7/+11
| | | | | | | While trying to properly free memory allocated by XKB I accidently called nxagentFreeKeyboardDeviceData twice and noticed it would cause a segfault here. As the other pointers are also nullified after being freed let's just do it here, too.
* Screen.c: Fix: make sure RRCloseScreen is being calledUlrich Sibiller2019-06-191-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes ArcticaProject/nx-libs#598 In nxagentOpenScreen we first initialized the RRExtension for the screen and then replaced pScreen->CloseScreen by nxagentCloseScreen. This resulted in RandR's RRCloseScreen (and any other CloseScreen procedure installed by extensions) being no longer called. Moving RandR init after configuring pScreen->CloseScreen ensures the correct calling cascade: RRCloseScreen -> nxagentCloseScreen ->fbCloseScreen (called explicitly by nxagentCloseScreen). Which in turn will fix this memory leak: ==9688== 328 (312 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 271 of 319 ==9688== at 0x4837B65: calloc (vg_replace_malloc.c:752) ==9688== by 0x4ED2C6: RRScreenInit (randr.c:329) ==9688== by 0x1F2B18: nxagentInitRandRExtension (Extensions.c:122) ==9688== by 0x1DEAFF: nxagentOpenScreen (Screen.c:1409) ==9688== by 0x16D7F8: AddScreen (dispatch.c:4257) ==9688== by 0x1DA0CF: InitOutput (Init.c:397) ==9688== by 0x14DCC2: main (main.c:280)
* Screen.c: correctly free stuff in nxagentCloseScreenUlrich Sibiller2019-06-191-3/+15
| | | | | | | | | | | | | | fixes a memory leak: ==19074== 2 bytes in 1 blocks are definitely lost in loss record 8 of 313 ==19074== at 0x483577F: malloc (vg_replace_malloc.c:299) ==19074== by 0x1FD83D: fbAllocatePrivates (fballpriv.c:79) ==19074== by 0x20A666: fbSetupScreen (fbscreen.c:110) ==19074== by 0x20A666: fbScreenInit (fbscreen.c:300) ==19074== by 0x1DEA4C: nxagentOpenScreen (Screen.c:1356) ==19074== by 0x16D7F8: AddScreen (dispatch.c:4257) ==19074== by 0x1DA0CF: InitOutput (Init.c:397) ==19074== by 0x14DCC2: main (main.c:280)
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-17 09:22:05 +0000