nx-libs/nx-X11/programs/Xserver/xkb, branch pr/extend_manpage

xkb/xkbUtils.c: add link to bugreport

2020-05-07T10:55:04+00:00

The problem we are fixing (or better "working around") here has also been seen in XQuartz, but no-one has found the reason yet. Point to bugreport so that anyone stumbling over this in future can check if there's a better fix and possibly implement that one.

_XkbFilterDeviceBtn: move variable declarations to match usage scope

2020-01-09T23:25:46+00:00

Fix this warning: xkbActions.c: In function ‘_XkbFilterDeviceBtn’: xkbActions.c:1084:6: warning: declaration of ‘button’ shadows a previous local [-Wshadow=compatible-local] int button; ^~~~~~ xkbActions.c:1044:6: note: shadowed declaration is here int button; ^~~~~~ Backport of this xorg-xserver upstream commit: commit 41dd7cf673e47ab74c5065b8dbf268b2e5facb64 Author: Alan Coopersmith Date: Mon Dec 12 16:49:34 2011 -0800 _XkbFilterDeviceBtn: move variable declarations to match usage scope The main body of this function is an if { } else if { } pair of blocks. Previously there was int button at the top level scope which is used only in the first block, and a redeclaration of int button inside the second block. Since there's no overlap in the code paths for the two uses of button, move the one from the outer block into the first block to help the programmer more quickly determine they are unrelated usages, and to silence the gcc warning of: xkbActions.c: In function '_XkbFilterDeviceBtn': xkbActions.c:999:6: warning: declaration of 'button' shadows a previous local xkbActions.c:955:6: warning: shadowed declaration is here For consistency, move DeviceIntPtr dev declarations as well that are used in the same way. Signed-off-by: Alan Coopersmith Reviewed-by: Jamey Sharp Reviewed-by: Peter Hutterer

XkbFindSrvLedInfo: remove extraneous name-clashing sli variable

2020-01-09T23:25:46+00:00

Fix shadow warning: xkbLEDs.c: In function ‘XkbFindSrvLedInfo’: xkbLEDs.c:633:19: warning: declaration of ‘sli’ shadows a previous local [-Wshadow=compatible-local] XkbSrvLedInfoPtr sli; ^~~ xkbLEDs.c:629:18: note: shadowed declaration is here XkbSrvLedInfoPtr sli; ^~~ Backport of this xorg-xserver commit: commit d8eb9b5faa2d2c9350bdaffef8749a9cac3c87b8 Author: Alan Coopersmith Date: Mon Dec 12 16:49:34 2011 -0800 XkbFindSrvLedInfo: remove extraneous name-clashing sli variable Variable is already defined outside the outer if statement, and there's no need to redefine inside the if statement. No point in setting sli before if (dev->kbdfeed->xkb_sli==NULL) check - if check is true, we immediately set it, if check is false, we immediately return without further reference or use of it. The one thing we do with it inside the inner if statement is store an allocation in it for a brief moment before writing to the final destination, which is immediately returned to the caller. In short, there's no benefit to the variable at all in this block, it just gives the optimizer more code to figure out how to omit. Fixes gcc warning: xkbLEDs.c: In function 'XkbFindSrvLedInfo': xkbLEDs.c:683:19: warning: declaration of 'sli' shadows a previous local xkbLEDs.c:679:18: warning: shadowed declaration is here Signed-off-by: Alan Coopersmith Reviewed-by: Jamey Sharp Reviewed-by: Peter Hutterer

xkb: fix shadow warnings

2020-01-09T23:25:46+00:00

xkb.c: In function ‘ProcXkbSetCompatMap’: xkb.c:2601:20: warning: declaration of ‘i’ shadows a previous local [-Wshadow=compatible-local] register unsigned i,bit; ^ xkb.c:2529:23: note: shadowed declaration is here register unsigned i,bit; ^ xkb.c:2601:22: warning: declaration of ‘bit’ shadows a previous local [-Wshadow=compatible-local] register unsigned i,bit; ^~~ xkb.c:2529:25: note: shadowed declaration is here register unsigned i,bit; ^~~ Backport of this xorg upstream commit: commit 344eea237fc07dedfd733d14f95ed0ad26bb5f81 Author: Yaakov Selkowitz Date: Tue Oct 16 02:04:34 2012 -0500 xkb: fix shadow warnings Signed-off-by: Yaakov Selkowitz Reviewed-by: Peter Hutterer

xkbActions.c: fix formatting

2020-01-05T23:18:44+00:00

xkb: replace NX_TRANS_SOCKET by NXAGENT_SERVER

2019-09-29T15:10:05+00:00

This has nothing to do with the transport.

rework xkb device private handling

2019-06-22T14:05:48+00:00

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).

xkb: fix what looks to be a copy-paste error with first vs firstMM

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

commit 758393951233d1b2520cf4cefd33ec4288a3880a Author: Dave Airlie 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

xkmread.c: fix compiler warning

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

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 warnings

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

commit 83913de25d35709b3ab7b0ab124b73924145d2dd Author: Adam Jackson 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 Acked-by: Keith Packard