Re: X.Org modular build problem with xcb
On Mon, Jul 26, 2010 at 9:41 PM, Gaetan Nadon mems...@videotron.ca wrote: On Mon, 2010-07-26 at 17:38 -0400, Trevor Woerner wrote: File /usr/lib/python2.6/site-packages/xcbgen/state.py, line 94, in resolve item.resolve(self) You need the package xcb-proto-1.2 or later which has an xcbgen sub directory which gets installed in /usr/lib/python2.6/site-packages. Excellent, thank you! openSUSE 11.3 doesn't have a package called xcb-proto-1.2, but it does have a package called xorg-x11-proto-devel which includes a whole bunch of files in /usr/lib/python2.6/site-packages/xcbgen. That package was already installed on my system; it seems as though having it installed was the problem. Trying to uninstall it, however, would also want to uninstall just about every xorg-*-devel package from my system, which I assume some parts of which I need to build the latest. So simply renaming python's xcbgen directory to xcbgen.BAK allowed the build to continue successfully. Thanks for pointing me in the right direction. Best regards, Trevor ___ 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 00/15] xkb: Fixes for static analyzer reported bugs
Hi, Here is punch of small fixes for bugs reported by static analyzer. Some of bugs aren't possible in runtime but it is still nice to have correct code even for currently unused code paths. Pauli ___ 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 02/15] xkb: Fix memory leak if opening file fails
If fopen fails pointer in buf would be overwriten with a new pointer.
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
xkb/ddxList.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/xkb/ddxList.c b/xkb/ddxList.c
index 2256424..39bd739 100644
--- a/xkb/ddxList.c
+++ b/xkb/ddxList.c
@@ -161,6 +161,7 @@ chartmpname[PATH_MAX];
}
if (!in) {
haveDir= FALSE;
+ free(buf);
buf = Xprintf(
'%s/xkbcomp' '-R%s/%s' -w %ld -l -vlfhpR '%s' W32_tmparg,
XkbBinDirectory,XkbBaseDirectory,componentDirs[what],(long)
@@ -176,6 +177,7 @@ chartmpname[PATH_MAX];
}
if (!in) {
haveDir= FALSE;
+ free(buf);
buf = Xprintf(
xkbcomp -R%s -w %ld -l -vlfhpR '%s' W32_tmparg,
componentDirs[what],(long)
--
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
[PATCH 05/15] xkb: Check for unsuported comibnation of action for XkbSetMap
This prevents validation code from using unitialized values.
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
xkb/xkb.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/xkb/xkb.c b/xkb/xkb.c
index 935f5ea..9a5d5b3 100644
--- a/xkb/xkb.c
+++ b/xkb/xkb.c
@@ -2366,6 +2366,14 @@ _XkbSetMapChecks(ClientPtr client, DeviceIntPtr dev,
xkbSetMapReq *req, char* va
}
}
+if ((!(req-present XkbKeySymsMask)
+ (req-present XkbKeyActionsMask)) ||
+ (!(req-present XkbKeyTypesMask)
+ (req-present XkbKeySymsMask))) {
+ client-errorValue = req-present;
+ return BadMatch;
+}
+
if ((req-present XkbKeyTypesMask)
(!CheckKeyTypes(client,xkb,req,(xkbKeyTypeWireDesc **)values,
nTypes,mapWidths))) {
--
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
[PATCH 06/15] xkb: Remove redurant intialization code
calloc already initializes allocated memory to zero. Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com --- xkb/xkbEvents.c |9 - 1 files changed, 0 insertions(+), 9 deletions(-) diff --git a/xkb/xkbEvents.c b/xkb/xkbEvents.c index 8028502..c020e5e 100644 --- a/xkb/xkbEvents.c +++ b/xkb/xkbEvents.c @@ -1045,15 +1045,6 @@ XkbInterestPtr interest; interest-dev = dev; interest-client = client; interest-resource = id; - interest-stateNotifyMask= 0; - interest-ctrlsNotifyMask= 0; - interest-namesNotifyMask= 0; - interest-compatNotifyMask= 0; - interest-bellNotifyMask= FALSE; - interest-accessXNotifyMask= 0; - interest-iStateNotifyMask= 0; - interest-iMapNotifyMask= 0; - interest-altSymsNotifyMask= 0; interest-next = dev-xkb_interest; dev-xkb_interest= interest; return interest; -- 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
[PATCH 07/15] xkb: Fix memory leak in error path
map is allocated but not freed if reply length and data don't match.
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
xkb/xkb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/xkb/xkb.c b/xkb/xkb.c
index 9a5d5b3..452bf2c 100644
--- a/xkb/xkb.c
+++ b/xkb/xkb.c
@@ -3027,6 +3027,7 @@ register unsigned bit;
to = (CARD8 *)wire;
if ((to-map)!=length) {
client-errorValue = _XkbErrCode2(0xff,length);
+ free(map);
return BadLength;
}
}
--
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
[PATCH 09/15] xkb: Don't check for NULL when pointer can't be NULL
Caller quarantines that pAction pointer is valid.
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
xkb/xkbActions.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/xkb/xkbActions.c b/xkb/xkbActions.c
index eea3d4a..ddab882 100644
--- a/xkb/xkbActions.c
+++ b/xkb/xkbActions.c
@@ -340,7 +340,7 @@ _XkbFilterLockState(XkbSrvInfoPtr xkbi,
unsignedkeycode,
XkbAction * pAction)
{
-if (pAction(pAction-type==XkbSA_LockGroup)) {
+if (pAction-type==XkbSA_LockGroup) {
if (pAction-group.flagsXkbSA_GroupAbsolute)
xkbi-state.locked_group= XkbSAGroup(pAction-group);
else xkbi-state.locked_group+= XkbSAGroup(pAction-group);
--
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
[PATCH 11/15] xkb: Fix possible NULL pointer dereference
sli is null beofre allocation assigment so deference t osli has to be
protected.
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
xkb/xkbLEDs.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/xkb/xkbLEDs.c b/xkb/xkbLEDs.c
index 1682671..515e9b7 100644
--- a/xkb/xkbLEDs.c
+++ b/xkb/xkbLEDs.c
@@ -556,6 +556,7 @@ BoolcheckNames;
else if ((kf!=NULL)((kf-xkb_sli-flagsXkbSLI_IsDefault)!=0)) {
XkbDescPtr xkb;
xkb= dev-key-xkbInfo-desc;
+ sli= kf-xkb_sli;
sli-physIndicators=xkb-indicators-phys_indicators;
if (xkb-names-indicators!=sli-names) {
checkNames= TRUE;
@@ -584,6 +585,8 @@ BoolcheckNames;
sli-maps= NULL;
sli-names= NULL;
}
+else
+ return NULL;
if ((sli-names==NULL)(needed_partsXkbXI_IndicatorNamesMask))
sli-names= calloc(XkbNumIndicators, sizeof(Atom));
if ((sli-maps==NULL)(needed_partsXkbXI_IndicatorMapsMask))
--
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
[PATCH 01/15] xkb: Use memcpy for copy that has known length
Fixes warning that strncpy is not able to append NULL to the end of destination. Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com --- xkb/xkmread.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/xkb/xkmread.c b/xkb/xkmread.c index 814bb1d..9eb8601 100644 --- a/xkb/xkmread.c +++ b/xkb/xkmread.c @@ -534,8 +534,7 @@ XkbAction *act; case XkbSA_XFree86Private: /* copy the kind of action */ -strncpy((char*)act-any.data, (char*)wire.actionData, -XkbAnyActionDataSize); +memcpy(act-any.data, wire.actionData, XkbAnyActionDataSize); break ; case XkbSA_Terminate: -- 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
[PATCH 03/15] xkb: Don't check for NULL before calling free
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
xkb/ddxList.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/xkb/ddxList.c b/xkb/ddxList.c
index 39bd739..c1ada5c 100644
--- a/xkb/ddxList.c
+++ b/xkb/ddxList.c
@@ -202,8 +202,7 @@ chartmpname[PATH_MAX];
}
if (!in)
{
-if (buf != NULL)
- free(buf);
+ free(buf);
#ifdef WIN32
unlink(tmpname);
#endif
@@ -266,8 +265,7 @@ chartmpname[PATH_MAX];
fclose(in);
unlink(tmpname);
#endif
-if (buf != NULL)
-free(buf);
+free(buf);
return status;
}
--
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
[PATCH 08/15] xkb: Don't check for NULL when pointer can't be NULL
Caller quarantines that changes pointer is valid.
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
xkb/xkbUtils.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/xkb/xkbUtils.c b/xkb/xkbUtils.c
index 14dc784..31aff93 100644
--- a/xkb/xkbUtils.c
+++ b/xkb/xkbUtils.c
@@ -223,7 +223,6 @@ XkbDescPtr xkb;
unsigned key,nG,explicit;
inttypes[XkbNumKbdGroups];
KeySym tsyms[XkbMaxSymsPerKey],*syms;
-XkbMapChangesPtr mc;
xkb= pXDev-key-xkbInfo-desc;
if (first+num-1xkb-max_key_code) {
@@ -231,8 +230,6 @@ XkbMapChangesPtrmc;
num= xkb-max_key_code-first+1;
}
-mc= (changes?(changes-map):NULL);
-
syms= pCore-map[(first - pCore-minKeyCode) * pCore-mapWidth];
for (key=first; key(first+num); key++,syms+= pCore-mapWidth) {
explicit= xkb-server-explicit[key]XkbExplicitKeyTypesMask;
@@ -242,7 +239,7 @@ XkbMapChangesPtrmc;
types[XkbGroup4Index]= XkbKeyKeyTypeIndex(xkb,key,XkbGroup4Index);
nG= XkbKeyTypesForCoreSymbols(xkb,pCore-mapWidth,syms,explicit,types,
tsyms);
- XkbChangeTypesOfKey(xkb,key,nG,XkbAllGroupsMask,types,mc);
+ XkbChangeTypesOfKey(xkb,key,nG,XkbAllGroupsMask,types,changes-map);
memcpy((char *)XkbKeySymsPtr(xkb,key),(char *)tsyms,
XkbKeyNumSyms(xkb,key)*sizeof(KeySym));
}
--
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
[PATCH 12/15] xkb: Fix allocation check to compare correct variable
prop-name is allocated in code but check is for parameter name that can't be NULL. Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com --- xkb/XKBGAlloc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/xkb/XKBGAlloc.c b/xkb/XKBGAlloc.c index d1adea3..7143e7a 100644 --- a/xkb/XKBGAlloc.c +++ b/xkb/XKBGAlloc.c @@ -669,7 +669,7 @@ register XkbPropertyPtr prop; } prop= geom-properties[geom-num_properties]; prop-name= malloc(strlen(name)+1); -if (!name) +if (!prop-name) return NULL; strcpy(prop-name,name); prop-value= malloc(strlen(value)+1); -- 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
[PATCH 13/15] xkb: Check if AddResource failed
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
xkb/xkb.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/xkb/xkb.c b/xkb/xkb.c
index 452bf2c..618d0bc 100644
--- a/xkb/xkb.c
+++ b/xkb/xkb.c
@@ -224,7 +224,8 @@ ProcXkbSelectEvents(ClientPtr client)
masks = XkbFindClientResource((DevicePtr)dev,client);
if (!masks){
XID id = FakeClientID(client-index);
- AddResource(id,RT_XKBCLIENT,dev);
+ if (!AddResource(id,RT_XKBCLIENT,dev))
+ return BadAlloc;
masks= XkbAddClientResource((DevicePtr)dev,client,id);
}
if (masks) {
@@ -5386,7 +5387,8 @@ ProcXkbPerClientFlags(ClientPtr client)
}
else if (want (!interest)) {
XID id = FakeClientID(client-index);
- AddResource(id,RT_XKBCLIENT,dev);
+ if (!AddResource(id,RT_XKBCLIENT,dev))
+ return BadAlloc;
interest= XkbAddClientResource((DevicePtr)dev,client,id);
if (!interest)
return BadAlloc;
--
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
[PATCH 10/15] xkb: Fix possible NULL pointer dereference
If search for device failed sli is NULL. In that case we have to protect
dereference to prevent server crash.
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
xkb/ddxLoad.c |6 +-
xkb/xkbLEDs.c | 10 ++
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/xkb/ddxLoad.c b/xkb/ddxLoad.c
index 5e6ab87..2fdf71e 100644
--- a/xkb/ddxLoad.c
+++ b/xkb/ddxLoad.c
@@ -342,7 +342,11 @@ char fileName[PATH_MAX];
unsigned missing;
*xkbRtrn = NULL;
-if ((keybd==NULL)||(keybd-key==NULL)||(keybd-key-xkbInfo==NULL))
+if (!keybd) {
+LogMessage(X_ERROR, XKB: %s no device given as parameter.\n,
__func__);
+return 0;
+}
+if ((keybd-key==NULL)||(keybd-key-xkbInfo==NULL))
xkb= NULL;
else xkb= keybd-key-xkbInfo-desc;
if ((names-keycodes==NULL)(names-types==NULL)
diff --git a/xkb/xkbLEDs.c b/xkb/xkbLEDs.c
index f617537..1682671 100644
--- a/xkb/xkbLEDs.c
+++ b/xkb/xkbLEDs.c
@@ -714,10 +714,12 @@ XkbSrvLedInfoPtr sli;
}
}
}
-if ((sli-names==NULL)(needed_partsXkbXI_IndicatorNamesMask))
- sli-names= calloc(XkbNumIndicators, sizeof(Atom));
-if ((sli-maps==NULL)(needed_partsXkbXI_IndicatorMapsMask))
- sli-maps= calloc(XkbNumIndicators, sizeof(XkbIndicatorMapRec));
+if (sli) {
+ if ((sli-names==NULL)(needed_partsXkbXI_IndicatorNamesMask))
+ sli-names= calloc(XkbNumIndicators, sizeof(Atom));
+ if ((sli-maps==NULL)(needed_partsXkbXI_IndicatorMapsMask))
+ sli-maps= calloc(XkbNumIndicators, sizeof(XkbIndicatorMapRec));
+}
return sli;
}
--
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
[PATCH 14/15] xkb: Use memcpy for copy
Source and destination have well defined size so use memcpy instead of strncpy. strncpy tryes to add NULL to end of destination but it is not possible if source doesn't have NULL. Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com --- xkb/XKBGAlloc.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/xkb/XKBGAlloc.c b/xkb/XKBGAlloc.c index 7143e7a..9a768ca 100644 --- a/xkb/XKBGAlloc.c +++ b/xkb/XKBGAlloc.c @@ -922,8 +922,8 @@ Boolfound; if ((row-num_keys=row-sz_keys)(_XkbAllocOverlayKeys(row,1)!=Success)) return NULL; key= row-keys[row-num_keys]; -strncpy(key-under.name,under,XkbKeyNameLength); -strncpy(key-over.name,over,XkbKeyNameLength); +memcpy(key-under.name,under,XkbKeyNameLength); +memcpy(key-over.name,over,XkbKeyNameLength); row-num_keys++; return key; } -- 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: xf86-video-intel: configure.ac
On Mon, Jul 26, 2010 at 16:44:47 -0700, Jesse Barnes wrote: configure.ac |2 ++ 1 file changed, 2 insertions(+) New commits: commit d580fa82a1cf339d2d1fd1055d137c0b23cd04f3 Author: Jesse Barnes jbar...@virtuousgeek.org Date: Mon Jul 26 16:44:19 2010 -0700 configure.ac: add xi and gl requirements Could probably be earlier versions, but having these here makes packaging easier. diff --git a/configure.ac b/configure.ac index d5989a6..4edd07b 100644 --- a/configure.ac +++ b/configure.ac @@ -81,6 +81,8 @@ XORG_DRIVER_CHECK_EXT(DPMSExtension, xextproto) PKG_CHECK_MODULES(XORG, [xorg-server = 1.6 xproto fontsproto $REQUIRED_MODULES]) PKG_CHECK_MODULES(DRM, [libdrm = 2.4.21]) PKG_CHECK_MODULES(PCIACCESS, [pciaccess = 0.10]) +PKG_CHECK_MODULES(XI, [xi = 1.3]) +PKG_CHECK_MODULES(GL, [gl = 7.7.0]) sdkdir=`$PKG_CONFIG --variable=sdkdir xorg-server` May I ask why? None of these seem necessary… Cheers, Julien 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: xf86-video-intel: configure.ac
On Tue, 2010-07-27 at 15:41 +0200, Julien Cristau wrote: +PKG_CHECK_MODULES(XI, [xi = 1.3]) +PKG_CHECK_MODULES(GL, [gl = 7.7.0]) sdkdir=`$PKG_CONFIG --variable=sdkdir xorg-server` May I ask why? None of these seem necessary… Jesse, Will the --disable-dri option still work now that the module cannot be configured without the gl package? Will xi version 1.3 version be too recent when built against a 1.6 server? The 1.6 server does not depend on libXi. It's great to have accurate dependencies checking. Just by looking at the configuration of this driver, it has an explicit requirement to support server 1.6 and later, and to work without dri. Gaetan 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: xf86-video-intel: configure.ac
On Tue, 27 Jul 2010 15:41:35 +0200 Julien Cristau jcris...@debian.org wrote: On Mon, Jul 26, 2010 at 16:44:47 -0700, Jesse Barnes wrote: configure.ac |2 ++ 1 file changed, 2 insertions(+) New commits: commit d580fa82a1cf339d2d1fd1055d137c0b23cd04f3 Author: Jesse Barnes jbar...@virtuousgeek.org Date: Mon Jul 26 16:44:19 2010 -0700 configure.ac: add xi and gl requirements Could probably be earlier versions, but having these here makes packaging easier. diff --git a/configure.ac b/configure.ac index d5989a6..4edd07b 100644 --- a/configure.ac +++ b/configure.ac @@ -81,6 +81,8 @@ XORG_DRIVER_CHECK_EXT(DPMSExtension, xextproto) PKG_CHECK_MODULES(XORG, [xorg-server = 1.6 xproto fontsproto $REQUIRED_MODULES]) PKG_CHECK_MODULES(DRM, [libdrm = 2.4.21]) PKG_CHECK_MODULES(PCIACCESS, [pciaccess = 0.10]) +PKG_CHECK_MODULES(XI, [xi = 1.3]) +PKG_CHECK_MODULES(GL, [gl = 7.7.0]) sdkdir=`$PKG_CONFIG --variable=sdkdir xorg-server` May I ask why? None of these seem necessary… Apparently MeeGo does automatic packaging based on configure.ac, so Arjan requested that these be added to make that easier. -- Jesse Barnes, Intel Open Source Technology Center ___ 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-intel: configure.ac
On Tue, 27 Jul 2010 10:50:24 -0400 Gaetan Nadon mems...@videotron.ca wrote: On Tue, 2010-07-27 at 15:41 +0200, Julien Cristau wrote: +PKG_CHECK_MODULES(XI, [xi = 1.3]) +PKG_CHECK_MODULES(GL, [gl = 7.7.0]) sdkdir=`$PKG_CONFIG --variable=sdkdir xorg-server` May I ask why? None of these seem necessary… Jesse, Will the --disable-dri option still work now that the module cannot be configured without the gl package? Will xi version 1.3 version be too recent when built against a 1.6 server? The 1.6 server does not depend on libXi. It's great to have accurate dependencies checking. Just by looking at the configuration of this driver, it has an explicit requirement to support server 1.6 and later, and to work without dri. I didn't test with the --disable-dri option, we could put the pkg requirement under a DRI check if needed. I also haven't tried building against a 1.6 server for a long time, if we need changes to support that I can make them as well. -- Jesse Barnes, Intel Open Source Technology Center ___ 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: [Intel-gfx] xf86-video-intel: configure.ac
On Tue, Jul 27, 2010 at 08:25:13 -0700, Jesse Barnes wrote: Apparently MeeGo does automatic packaging based on configure.ac, so Arjan requested that these be added to make that easier. So we're adding fictional dependencies based on meego brokenness? Do you have more details on the issues they were having? 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: [Intel-gfx] xf86-video-intel: configure.ac
Hi, On Tue, Jul 27, 2010 at 05:44:39PM +0200, Julien Cristau wrote: On Tue, Jul 27, 2010 at 08:25:13 -0700, Jesse Barnes wrote: Apparently MeeGo does automatic packaging based on configure.ac, so Arjan requested that these be added to make that easier. So we're adding fictional dependencies based on meego brokenness? Do you have more details on the issues they were having? That's pretty awesome. In either case, xi is almost certainly the wrong module. If the requirement is to have X11/extensions/XI.h and friends for server headers, then not only should that dep be in the server rather than a driver which blatantly has nothing to do with input, but you want inputproto rather than xi, which is libXi. 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: [Intel-gfx] xf86-video-intel: configure.ac
On Tue, 27 Jul 2010 17:00:28 +0100 Daniel Stone dan...@fooishbar.org wrote: Hi, On Tue, Jul 27, 2010 at 05:44:39PM +0200, Julien Cristau wrote: On Tue, Jul 27, 2010 at 08:25:13 -0700, Jesse Barnes wrote: Apparently MeeGo does automatic packaging based on configure.ac, so Arjan requested that these be added to make that easier. So we're adding fictional dependencies based on meego brokenness? Do you have more details on the issues they were having? That's pretty awesome. In either case, xi is almost certainly the wrong module. If the requirement is to have X11/extensions/XI.h and friends for server headers, then not only should that dep be in the server rather than a driver which blatantly has nothing to do with input, but you want inputproto rather than xi, which is libXi. Yep, sorry, my fault. I should have checked these out more; Arjan showed me the logs and it looks like the server is missing a dep on xi: arjan In file included from /usr/include/xorg/scrnintstr.h:58:0, arjan from /usr/include/xorg/xf86str.h:39, arjan from /usr/include/xorg/xf86.h:46, arjan from uxa-priv.h:37, arjan from uxa.c:37: arjan /usr/include/xorg/dix.h:57:31: fatal error: X11/extensions/XI.h: No such file or directory and glproto is missing a dep on GL: arjan In file included from i810.h:60:0, arjan from i810_accel.c:41: arjan /usr/include/GL/glxint.h:36:19: fatal error: GL/gl.h: No such file or directory So we'll have to fix those instead. -- Jesse Barnes, Intel Open Source Technology Center ___ 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: [Intel-gfx] xf86-video-intel: configure.ac
On Tue, Jul 27, 2010 at 09:34:01AM -0700, Jesse Barnes wrote: On Tue, 27 Jul 2010 17:00:28 +0100 Daniel Stone dan...@fooishbar.org wrote: On Tue, Jul 27, 2010 at 05:44:39PM +0200, Julien Cristau wrote: On Tue, Jul 27, 2010 at 08:25:13 -0700, Jesse Barnes wrote: Apparently MeeGo does automatic packaging based on configure.ac, so Arjan requested that these be added to make that easier. So we're adding fictional dependencies based on meego brokenness? Do you have more details on the issues they were having? That's pretty awesome. In either case, xi is almost certainly the wrong module. If the requirement is to have X11/extensions/XI.h and friends for server headers, then not only should that dep be in the server rather than a driver which blatantly has nothing to do with input, but you want inputproto rather than xi, which is libXi. Yep, sorry, my fault. I should have checked these out more; Arjan showed me the logs and it looks like the server is missing a dep on xi: arjan In file included from /usr/include/xorg/scrnintstr.h:58:0, arjan from /usr/include/xorg/xf86str.h:39, arjan from /usr/include/xorg/xf86.h:46, arjan from uxa-priv.h:37, arjan from uxa.c:37: arjan /usr/include/xorg/dix.h:57:31: fatal error: X11/extensions/XI.h: No such file or directory That would be a dep on inputproto. :) xi only gives you XInput.h and XInput2.h, both client-only headers. 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: [Intel-gfx] xf86-video-intel: configure.ac
On Tue, Jul 27, 2010 at 17:39:11 +0100, Daniel Stone wrote: arjan In file included from /usr/include/xorg/scrnintstr.h:58:0, arjan from /usr/include/xorg/xf86str.h:39, arjan from /usr/include/xorg/xf86.h:46, arjan from uxa-priv.h:37, arjan from uxa.c:37: arjan /usr/include/xorg/dix.h:57:31: fatal error: X11/extensions/XI.h: No such file or directory That would be a dep on inputproto. :) xi only gives you XInput.h and XInput2.h, both client-only headers. And it's already fixed. http://cgit.freedesktop.org/xorg/xserver/commit/?id=32c706c4ffd7433dbfc79dba8785b1510d2f053f The GL one is more annoying. 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: [Intel-gfx] xf86-video-intel: configure.ac
On Tue, 27 Jul 2010 17:39:11 +0100 Daniel Stone dan...@fooishbar.org wrote: On Tue, Jul 27, 2010 at 09:34:01AM -0700, Jesse Barnes wrote: On Tue, 27 Jul 2010 17:00:28 +0100 Daniel Stone dan...@fooishbar.org wrote: On Tue, Jul 27, 2010 at 05:44:39PM +0200, Julien Cristau wrote: On Tue, Jul 27, 2010 at 08:25:13 -0700, Jesse Barnes wrote: Apparently MeeGo does automatic packaging based on configure.ac, so Arjan requested that these be added to make that easier. So we're adding fictional dependencies based on meego brokenness? Do you have more details on the issues they were having? That's pretty awesome. In either case, xi is almost certainly the wrong module. If the requirement is to have X11/extensions/XI.h and friends for server headers, then not only should that dep be in the server rather than a driver which blatantly has nothing to do with input, but you want inputproto rather than xi, which is libXi. Yep, sorry, my fault. I should have checked these out more; Arjan showed me the logs and it looks like the server is missing a dep on xi: arjan In file included from /usr/include/xorg/scrnintstr.h:58:0, arjan from /usr/include/xorg/xf86str.h:39, arjan from /usr/include/xorg/xf86.h:46, arjan from uxa-priv.h:37, arjan from uxa.c:37: arjan /usr/include/xorg/dix.h:57:31: fatal error: X11/extensions/XI.h: No such file or directory That would be a dep on inputproto. :) xi only gives you XInput.h and XInput2.h, both client-only headers. Right, and the server already has this, so either Arjan has an old server or his autopackager is broken. -- Jesse Barnes, Intel Open Source Technology Center ___ 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] Freeing EDID_block attached to nowhere
EDID_block is allocated dynamically and attached to xf86MonPtr object in
the function where the object is initialized.
When the initilization fails, EDID_block should be freed.
Signed-off-by: Masatake YAMATO yam...@redhat.com
---
hw/xfree86/ddc/ddc.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/ddc/ddc.c b/hw/xfree86/ddc/ddc.c
index 7379e95..873c674 100644
--- a/hw/xfree86/ddc/ddc.c
+++ b/hw/xfree86/ddc/ddc.c
@@ -262,6 +262,8 @@ xf86DoEDID_DDC1(
if (EDID_block){
tmp = xf86InterpretEDID(scrnIndex,EDID_block);
+ if (!tmp)
+ free(EDID_block);
}
#ifdef DEBUG
else ErrorF(No EDID block returned\n);
@@ -423,6 +425,8 @@ xf86DoEEDID(int scrnIndex, I2CBusPtr pBus, Bool complete)
}
tmp = xf86InterpretEEDID(scrnIndex, EDID_block);
+ if (!tmp)
+ free(EDID_block);
}
if (tmp complete)
--
1.6.2.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: [Intel-gfx] xf86-video-intel: configure.ac
On Tue, 2010-07-27 at 18:47 +0200, Julien Cristau wrote: The GL one is more annoying. glproto includes gl.h which is in the mesa source. The mesa package depends on glproto. This will become a circular dependency if glproto is fixed to depend on gl. I was surprised to see a protocol including a header file from it's package implementation. The patch is not responsible for this situation, but it shows that the packager cannot rely on configuration dependencies alone to function properly. Not to mention there are most likely missing dependencies. Build tool chain dependencies are one thing, but running dependencies are another. 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] int10: Remove the vm86 and stub backends
Date: Tue, 27 Jul 2010 17:57:01 +0100 From: Matthew Garrett m...@redhat.com On Wed, Jul 14, 2010 at 04:15:56PM +0300, Tiago Vignatti wrote: On Tue, Jul 13, 2010 at 11:32:54PM +0200, ext Adam Jackson wrote: vm86 has been defaulted off since 1.6, and is still a terrible idea to actually use. Time to say goodbye. My empirical evidences say that we can't do this. The vm86 code is guaranteed to fail in certain circumstances. The most obvious is anything where the BIOS tries to access address space above 3GB. We're better off killing it and figuring out where the bugs in x86emu are. How about fixing those bugs before killing it? ___ 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] int10: Remove the vm86 and stub backends
From: Adam Jackson a...@redhat.com Date: Tue, 27 Jul 2010 15:46:59 -0400 On Tue, 2010-07-27 at 20:23 +0200, Mark Kettenis wrote: Date: Tue, 27 Jul 2010 17:57:01 +0100 From: Matthew Garrett m...@redhat.com On Wed, Jul 14, 2010 at 04:15:56PM +0300, Tiago Vignatti wrote: On Tue, Jul 13, 2010 at 11:32:54PM +0200, ext Adam Jackson wrote: vm86 has been defaulted off since 1.6, and is still a terrible idea= to actually use. Time to say goodbye. =20 My empirical evidences say that we can't do this.=20 =20 The vm86 code is guaranteed to fail in certain circumstances. The most=20 obvious is anything where the BIOS tries to access address space above=20 3GB. We're better off killing it and figuring out where the bugs in=20 x86emu are. =20 How about fixing those bugs before killing it? Some of them are... nontrivial. Which makes me seriously doubt that these bugs can be found and fixed fast enough such that users won't be affected. ___ 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] int10: Remove the vm86 and stub backends
On Tue, 2010-07-27 at 22:47 +0200, Mark Kettenis wrote: From: Adam Jackson a...@redhat.com Some of them are... nontrivial. Which makes me seriously doubt that these bugs can be found and fixed fast enough such that users won't be affected. Perhaps they can consider running an older X server. - 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
[PATCH] edid: Fix the HDTV sync pulse adjustment
Simple typo, should have been adjusting the horizontal timings
consistently since we're not trying to mangle vertical at all.
Signed-off-by: Adam Jackson a...@redhat.com
---
hw/xfree86/modes/xf86EdidModes.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/modes/xf86EdidModes.c b/hw/xfree86/modes/xf86EdidModes.c
index 8f4d04f..a94379f 100644
--- a/hw/xfree86/modes/xf86EdidModes.c
+++ b/hw/xfree86/modes/xf86EdidModes.c
@@ -484,8 +484,8 @@ DDCModesFromStandardTiming(struct std_timings *timing,
ddc_quirk_t quirks,
(hsize == 1368 vsize == 769))) {
Mode = xf86CVTMode(1366, 768, 60, FALSE, FALSE);
Mode-HDisplay = 1366;
- Mode-VSyncStart--;
- Mode-VSyncEnd--;
+ Mode-HSyncStart--;
+ Mode-HSyncEnd--;
} else if (hsize vsize refresh) {
Mode = FindDMTMode(hsize, vsize, refresh, rb);
--
1.7.1.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
Re: [PATCH 08/15] xkb: Don't check for NULL when pointer can't be NULL
On Tue, Jul 27, 2010 at 03:09:49PM +0300, Pauli Nieminen wrote:
Caller quarantines that changes pointer is valid.
^^ guarantees?
this is a bad description IMO. for better or worse,
XkbUpdateKeyTypesFromCore is _X_EXPORT and could thus be called from a
module, not just from the single place in the tree. if changes was NULL
however, the server would segfault a few lines below anyway since we
unconditionally dereference changes. This should be in the commit message.
Cheers,
Peter
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
xkb/xkbUtils.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/xkb/xkbUtils.c b/xkb/xkbUtils.c
index 14dc784..31aff93 100644
--- a/xkb/xkbUtils.c
+++ b/xkb/xkbUtils.c
@@ -223,7 +223,6 @@ XkbDescPtrxkb;
unsigned key,nG,explicit;
int types[XkbNumKbdGroups];
KeySym tsyms[XkbMaxSymsPerKey],*syms;
-XkbMapChangesPtr mc;
xkb= pXDev-key-xkbInfo-desc;
if (first+num-1xkb-max_key_code) {
@@ -231,8 +230,6 @@ XkbMapChangesPtr mc;
num= xkb-max_key_code-first+1;
}
-mc= (changes?(changes-map):NULL);
-
syms= pCore-map[(first - pCore-minKeyCode) * pCore-mapWidth];
for (key=first; key(first+num); key++,syms+= pCore-mapWidth) {
explicit= xkb-server-explicit[key]XkbExplicitKeyTypesMask;
@@ -242,7 +239,7 @@ XkbMapChangesPtr mc;
types[XkbGroup4Index]= XkbKeyKeyTypeIndex(xkb,key,XkbGroup4Index);
nG=
XkbKeyTypesForCoreSymbols(xkb,pCore-mapWidth,syms,explicit,types,
tsyms);
- XkbChangeTypesOfKey(xkb,key,nG,XkbAllGroupsMask,types,mc);
+ XkbChangeTypesOfKey(xkb,key,nG,XkbAllGroupsMask,types,changes-map);
memcpy((char *)XkbKeySymsPtr(xkb,key),(char *)tsyms,
XkbKeyNumSyms(xkb,key)*sizeof(KeySym));
}
--
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: [PATCH 09/15] xkb: Don't check for NULL when pointer can't be NULL
On Tue, Jul 27, 2010 at 03:09:50PM +0300, Pauli Nieminen wrote:
Caller quarantines that pAction pointer is valid.
^^ guarantees?
same applies here as well as for the other patch, it's not the caller
guaranteeing that pAction is non-NULL, it's that we dereferernce it later
unconditionally anyway, so a NULL argument is already invalid.
Cheers,
Peter
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
xkb/xkbActions.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/xkb/xkbActions.c b/xkb/xkbActions.c
index eea3d4a..ddab882 100644
--- a/xkb/xkbActions.c
+++ b/xkb/xkbActions.c
@@ -340,7 +340,7 @@ _XkbFilterLockState( XkbSrvInfoPtr xkbi,
unsignedkeycode,
XkbAction * pAction)
{
-if (pAction(pAction-type==XkbSA_LockGroup)) {
+if (pAction-type==XkbSA_LockGroup) {
if (pAction-group.flagsXkbSA_GroupAbsolute)
xkbi-state.locked_group= XkbSAGroup(pAction-group);
else xkbi-state.locked_group+= XkbSAGroup(pAction-group);
--
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: [PATCH 10/15] xkb: Fix possible NULL pointer dereference
On Tue, Jul 27, 2010 at 03:09:51PM +0300, Pauli Nieminen wrote:
If search for device failed sli is NULL. In that case we have to protect
dereference to prevent server crash.
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
xkb/ddxLoad.c |6 +-
xkb/xkbLEDs.c | 10 ++
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/xkb/ddxLoad.c b/xkb/ddxLoad.c
index 5e6ab87..2fdf71e 100644
--- a/xkb/ddxLoad.c
+++ b/xkb/ddxLoad.c
@@ -342,7 +342,11 @@ char fileName[PATH_MAX];
unsigned missing;
*xkbRtrn = NULL;
-if ((keybd==NULL)||(keybd-key==NULL)||(keybd-key-xkbInfo==NULL))
+if (!keybd) {
+LogMessage(X_ERROR, XKB: %s no device given as parameter.\n,
__func__);
+return 0;
+}
+if ((keybd-key==NULL)||(keybd-key-xkbInfo==NULL))
xkb= NULL;
else xkb= keybd-key-xkbInfo-desc;
if ((names-keycodes==NULL)(names-types==NULL)
what was the error message that prompted this hunk? Cursory inspection of
the code seems like a keybd of NULL is valid.
diff --git a/xkb/xkbLEDs.c b/xkb/xkbLEDs.c
index f617537..1682671 100644
--- a/xkb/xkbLEDs.c
+++ b/xkb/xkbLEDs.c
@@ -714,10 +714,12 @@ XkbSrvLedInfoPtrsli;
}
}
}
-if ((sli-names==NULL)(needed_partsXkbXI_IndicatorNamesMask))
- sli-names= calloc(XkbNumIndicators, sizeof(Atom));
-if ((sli-maps==NULL)(needed_partsXkbXI_IndicatorMapsMask))
- sli-maps= calloc(XkbNumIndicators, sizeof(XkbIndicatorMapRec));
+if (sli) {
+ if ((sli-names==NULL)(needed_partsXkbXI_IndicatorNamesMask))
+ sli-names= calloc(XkbNumIndicators, sizeof(Atom));
+ if ((sli-maps==NULL)(needed_partsXkbXI_IndicatorMapsMask))
+ sli-maps= calloc(XkbNumIndicators, sizeof(XkbIndicatorMapRec));
+}
return sli;
}
--
1.6.3.3
these seem to be two unrelated hunks, should be two separate patches.
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net for the second hunk
though with the commit message above.
Cheers,
Peter
___
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 15/15] xkb: Use memcpy for copy
On Tue, Jul 27, 2010 at 03:09:56PM +0300, Pauli Nieminen wrote:
Source and destination have well defined size so use memcpy instead of
strncpy. strncpy tryes to add NULL to end of destination but it is not
possible if source doesn't have NULL.
same argument as for the other patch.
memcpy will initialize whole array/structure so memset is redurant and
^ better use copy, not initialize to avoid confusion.
can be removed.
Cheers,
Peter
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
xkb/XKBGAlloc.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/xkb/XKBGAlloc.c b/xkb/XKBGAlloc.c
index 9a768ca..2f7dc84 100644
--- a/xkb/XKBGAlloc.c
+++ b/xkb/XKBGAlloc.c
@@ -693,8 +693,7 @@ register XkbKeyAliasPtr alias;
return NULL;
for (i=0,alias=geom-key_aliases;igeom-num_key_aliases;i++,alias++) {
if (strncmp(alias-alias,aliasStr,XkbKeyNameLength)==0) {
- memset(alias-real, 0, XkbKeyNameLength);
- strncpy(alias-real,realStr,XkbKeyNameLength);
+ memcpy(alias-real,realStr,XkbKeyNameLength);
return alias;
}
}
@@ -703,9 +702,8 @@ register XkbKeyAliasPtr alias;
return NULL;
}
alias= geom-key_aliases[geom-num_key_aliases];
-memset(alias, 0, sizeof(XkbKeyAliasRec));
-strncpy(alias-alias,aliasStr,XkbKeyNameLength);
-strncpy(alias-real,realStr,XkbKeyNameLength);
+memcpy(alias-alias,aliasStr,XkbKeyNameLength);
+memcpy(alias-real,realStr,XkbKeyNameLength);
geom-num_key_aliases++;
return alias;
}
--
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: [PATCH 00/15] xkb: Fixes for static analyzer reported bugs
On Tue, Jul 27, 2010 at 03:09:41PM +0300, Pauli Nieminen wrote: Here is punch of small fixes for bugs reported by static analyzer. Some of bugs aren't possible in runtime but it is still nice to have correct code even for currently unused code paths. Reviewed-by: Peter Hutterer peter.hutte...@who-t.net for the patches I didn't respond to separately. Please provide those in a tree to pull from and I get them into my -next branch for when the merge window opens again. The others I'd like to see on the list again first. For next time, I'd appreciate it if you could add the message from the analyser to the commit message, it's much easier to know what to look for then. Cheers, Peter ___ 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] edid: Fix the HDTV sync pulse adjustment
Reviewed-by: Patrick E. Kane pekan...@gmail.com
The lines of context appear to show that both hsize and vsize are being
changed, could include a comment to explain why only HSync* needs to
be adjusted?
In any event, thanks for the patch.
Pat
---
On Tue, Jul 27, 2010 at 4:34 PM, Adam Jackson a...@redhat.com wrote:
Simple typo, should have been adjusting the horizontal timings
consistently since we're not trying to mangle vertical at all.
Signed-off-by: Adam Jackson a...@redhat.com
---
hw/xfree86/modes/xf86EdidModes.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/modes/xf86EdidModes.c
b/hw/xfree86/modes/xf86EdidModes.c
index 8f4d04f..a94379f 100644
--- a/hw/xfree86/modes/xf86EdidModes.c
+++ b/hw/xfree86/modes/xf86EdidModes.c
@@ -484,8 +484,8 @@ DDCModesFromStandardTiming(struct std_timings *timing,
ddc_quirk_t quirks,
(hsize == 1368 vsize == 769))) {
Mode = xf86CVTMode(1366, 768, 60, FALSE, FALSE);
Mode-HDisplay = 1366;
- Mode-VSyncStart--;
- Mode-VSyncEnd--;
+ Mode-HSyncStart--;
+ Mode-HSyncEnd--;
} else if (hsize vsize refresh) {
Mode = FindDMTMode(hsize, vsize, refresh, rb);
--
1.7.1.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
How to add the screen resoution support in driver?
Have a question to ask: We want to support some wide-screen resolutions in our platform under linux. And we hope that can be recognized in the applet Preferences-Display-Resolution. Can you tell me what the mechanism in that? That is to say, how the application under desktop can recognize the resolutions we add? Thanks, Frank ___ 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] Freeing EDID_block attached to nowhere
On Tue, Jul 27, 2010 at 3:56 AM, Masatake YAMATO yam...@redhat.com wrote:
EDID_block is allocated dynamically and attached to xf86MonPtr object in
the function where the object is initialized.
When the initilization fails, EDID_block should be freed.
Signed-off-by: Masatake YAMATO yam...@redhat.com
---
hw/xfree86/ddc/ddc.c | 4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/ddc/ddc.c b/hw/xfree86/ddc/ddc.c
index 7379e95..873c674 100644
--- a/hw/xfree86/ddc/ddc.c
+++ b/hw/xfree86/ddc/ddc.c
@@ -262,6 +262,8 @@ xf86DoEDID_DDC1(
if (EDID_block){
tmp = xf86InterpretEDID(scrnIndex,EDID_block);
+ if (!tmp)
+ free(EDID_block);
}
#ifdef DEBUG
else ErrorF(No EDID block returned\n);
@@ -423,6 +425,8 @@ xf86DoEEDID(int scrnIndex, I2CBusPtr pBus, Bool complete)
}
tmp = xf86InterpretEEDID(scrnIndex, EDID_block);
+ if (!tmp)
+ free(EDID_block);
}
if (tmp complete)
--
1.6.2.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
Looks good.
Reviewed-by: Matt Turner matts...@gmail.com
I think after reviewing your patch, I found another leak. Patch in progress.
___
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] ddc: Fix memory leak in GetEDID_DDC1
Mark argument to DDC_checksum as const too.
Signed-off-by: Matt Turner matts...@gmail.com
---
hw/xfree86/ddc/ddc.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/ddc/ddc.c b/hw/xfree86/ddc/ddc.c
index 7379e95..2d9d4dc 100644
--- a/hw/xfree86/ddc/ddc.c
+++ b/hw/xfree86/ddc/ddc.c
@@ -102,7 +102,7 @@ resort(unsigned char *s_block)
}
static int
-DDC_checksum(unsigned char *block, int len)
+DDC_checksum(const unsigned char *block, int len)
{
int i, result = 0;
int not_null = 0;
@@ -149,7 +149,10 @@ GetEDID_DDC1(unsigned int *s_ptr)
d_pos++;
}
free(s_ptr);
-if (d_block DDC_checksum(d_block,EDID1_LEN)) return NULL;
+if (d_block DDC_checksum(d_block,EDID1_LEN)) {
+ free(d_block);
+ return NULL;
+}
return (resort(d_block));
}
--
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
Re: [PATCH 2/2] Add support for per-axis valuator modes (Relative/Absolute)
On Fri, Jul 16, 2010 at 09:21:19AM -0400, Chase Douglas wrote:
The XI2 protocol supports per-axis modes, but the server so far does
not. This change adds support in the server.
A complication is the fact that XI1 does not support per-axis modes.
The solution provided here is to set a per-device mode that defines the
mode of at least the first two valuators (X and Y). The per-axis
valuator mode defaults to Relative, so any absolute axes must be
explicitly set. Note that initializing the first two axes to a different
mode than the device mode will fail.
For XI1 events, any axes following the first two that have the same mode
will be sent to clients, up to the first axis that has a different mode.
Thus, if a device has relative, then absolute, then relative mode axes,
only the first block of relative axes will be sent over XI1.
Since the XI2 protocol supports per-axis modes, all axes are sent to the
client.
Signed-off-by: Chase Douglas chase.doug...@canonical.com
---
Xi/exevents.c|1 +
Xi/xiquerydevice.c |2 +-
dix/devices.c|3 +--
dix/eventconvert.c | 14 +-
dix/getevents.c | 23 ---
hw/dmx/input/dmxmotion.c |7 +++
include/inputstr.h |1 +
7 files changed, 36 insertions(+), 15 deletions(-)
diff --git a/Xi/exevents.c b/Xi/exevents.c
index e990aeb..26084f5 100644
--- a/Xi/exevents.c
+++ b/Xi/exevents.c
@@ -1145,6 +1145,7 @@ InitValuatorAxisStruct(DeviceIntPtr dev, int axnum,
Atom label, int minval, int
ax-min_resolution = min_res;
ax-max_resolution = max_res;
ax-label = label;
+ax-mode = dev-valuator-mode;
shouldn't this be another parameter then?
}
static void
diff --git a/Xi/xiquerydevice.c b/Xi/xiquerydevice.c
index 303c8b2..c8b3d7e 100644
--- a/Xi/xiquerydevice.c
+++ b/Xi/xiquerydevice.c
@@ -349,7 +349,7 @@ ListValuatorInfo(DeviceIntPtr dev, xXIValuatorInfo* info,
int axisnumber,
info-value.frac = (int)(v-axisVal[axisnumber] * (1 16) * (1 16));
info-resolution = v-axes[axisnumber].resolution;
info-number = axisnumber;
-info-mode = v-mode; /* Server doesn't have per-axis mode yet */
+info-mode = v-axes[axisnumber].mode;
info-sourceid = v-sourceid;
if (!reportState)
diff --git a/dix/devices.c b/dix/devices.c
index ac5806a..e4048e4 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -2366,8 +2366,7 @@ RecalculateMasterButtons(DeviceIntPtr slave)
event.valuators[i].min = master-valuator-axes[i].min_value;
event.valuators[i].max = master-valuator-axes[i].max_value;
event.valuators[i].resolution =
master-valuator-axes[i].resolution;
-/* This should, eventually, be a per-axis mode */
-event.valuators[i].mode = master-valuator-mode;
+event.valuators[i].mode = master-valuator-axes[i].mode;
event.valuators[i].name = master-valuator-axes[i].label;
}
}
diff --git a/dix/eventconvert.c b/dix/eventconvert.c
index 4e3de0b..991298e 100644
--- a/dix/eventconvert.c
+++ b/dix/eventconvert.c
@@ -252,6 +252,12 @@ eventToKeyButtonPointer(DeviceEvent *ev, xEvent **xi,
int *count)
}
num_events = (countValuators(ev, first) + 5)/6; /* valuator ev */
+if (num_events = 0)
+{
+*count = 0;
+return BadMatch;
+}
+
num_events++; /* the actual event event */
*xi = calloc(num_events, sizeof(xEvent));
@@ -309,6 +315,12 @@ countValuators(DeviceEvent *ev, int *first)
for (i = 0; i sizeof(ev-valuators.mask) * 8; i++)
{
+/* Assume mode of 0th valuator matches XI1 device mode. Stop when the
+ * event mode changes since XI1 can't handle mixed mode devices.
+ */
why is this assumption necessary? valuator-mode still stores what the XI1
device mode is.
+if (ev-valuators.mode[i] != ev-valuators.mode[0])
+break;
+
if (BitIsOn(ev-valuators.mask, i))
{
if (first_valuator == -1)
@@ -431,7 +443,7 @@ appendValuatorInfo(DeviceChangedEvent *dce,
xXIValuatorInfo *info, int axisnumbe
info-value.frac = 0;
info-resolution = dce-valuators[axisnumber].resolution;
info-number = axisnumber;
-info-mode = dce-valuators[axisnumber].mode; /* Server doesn't have
per-axis mode yet */
+info-mode = dce-valuators[axisnumber].mode;
info-sourceid = dce-sourceid;
return info-length * 4;
diff --git a/dix/getevents.c b/dix/getevents.c
index 20cc79b..72daa16 100644
--- a/dix/getevents.c
+++ b/dix/getevents.c
@@ -208,7 +208,7 @@ set_valuators(DeviceIntPtr dev, DeviceEvent* event,
uint8_t *mask,
if (BitIsOn(mask, i))
{
SetBit(event-valuators.mask, i);
-if (dev-valuator-mode == Absolute)
+if (dev-valuator-axes[i].mode
[PATCH] Xi: reset the unused classes pointer after copying
After copying the unused_classes into the device, reset the original
pointer. Otherwise we have two pointers pointing to the same field and both
get freed on device removal.
Some classes already have this behaviour since 51c8fd69.
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
Xi/exevents.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Xi/exevents.c b/Xi/exevents.c
index e990aeb..e19e207 100644
--- a/Xi/exevents.c
+++ b/Xi/exevents.c
@@ -223,6 +223,7 @@ DeepCopyFeedbackClasses(DeviceIntPtr from, DeviceIntPtr to)
{
classes = to-unused_classes;
to-intfeed = classes-intfeed;
+classes-intfeed = NULL;
}
i = to-intfeed;
@@ -258,6 +259,7 @@ DeepCopyFeedbackClasses(DeviceIntPtr from, DeviceIntPtr to)
{
classes = to-unused_classes;
to-stringfeed = classes-stringfeed;
+classes-stringfeed = NULL;
}
s = to-stringfeed;
@@ -293,6 +295,7 @@ DeepCopyFeedbackClasses(DeviceIntPtr from, DeviceIntPtr to)
{
classes = to-unused_classes;
to-bell = classes-bell;
+classes-bell = NULL;
}
b = to-bell;
@@ -329,6 +332,7 @@ DeepCopyFeedbackClasses(DeviceIntPtr from, DeviceIntPtr to)
{
classes = to-unused_classes;
to-leds = classes-leds;
+classes-leds = NULL;
}
l = to-leds;
@@ -379,6 +383,7 @@ DeepCopyKeyboardClasses(DeviceIntPtr from, DeviceIntPtr to)
to-kbdfeed = classes-kbdfeed;
if (!to-kbdfeed)
InitKeyboardDeviceStruct(to, NULL, NULL, NULL);
+classes-kbdfeed = NULL;
}
k = to-kbdfeed;
@@ -506,6 +511,7 @@ DeepCopyPointerClasses(DeviceIntPtr from, DeviceIntPtr to)
{
classes = to-unused_classes;
to-ptrfeed = classes-ptrfeed;
+classes-ptrfeed = NULL;
}
p = to-ptrfeed;
--
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
[RFC] Refactoring of dix/dixutils.c
My humble attempt to put some order in dix. For lack of inspiration (or knowledge, if you prefer) I didn't touch the original copyright notices, and simply copied them verbatim to the new files; exactly like I did to headers. Ugly, I presume. But just a first try. Do people see any value in things like these? -- dix/Makefile.am|7 +- dix/blockhandler.c | 243 dix/callback.c | 333 +++ dix/dixutils.c | 634 dix/lookup.c | 190 dix/sleepqueue.c | 184 +++ dix/workqueue.c| 176 +++ 7 files changed, 1132 insertions(+), 635 deletions(-) ___ 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 1/5] dix: Extract blockhandler.c from within dixutils.c
The file dixutils.c has grown into an incohesive and bloated beast. The time has come to refactor some of its routines to their own files. This patch gives a new home for all of those which deal with block and wake up handlers. --- dix/Makefile.am|1 + dix/blockhandler.c | 243 dix/dixutils.c | 144 --- 3 files changed, 244 insertions(+), 144 deletions(-) create mode 100644 dix/blockhandler.c diff --git a/dix/Makefile.am b/dix/Makefile.am index 5e2dad7..8164a34 100644 --- a/dix/Makefile.am +++ b/dix/Makefile.am @@ -7,6 +7,7 @@ libmain_la_SOURCES =\ libdix_la_SOURCES =\ atom.c \ + blockhandler.c \ colormap.c \ cursor.c\ deprecated.c\ diff --git a/dix/blockhandler.c b/dix/blockhandler.c new file mode 100644 index 000..3a55600 --- /dev/null +++ b/dix/blockhandler.c @@ -0,0 +1,243 @@ +/*** + +Copyright 1987, 1998 The Open Group + +Permission to use, copy, modify, distribute, and sell this software and its +documentation for any purpose is hereby granted without fee, provided that +the above copyright notice appear in all copies and that both that +copyright notice and this permission notice appear in supporting +documentation. + +The above copyright notice and this permission notice shall be included in +all copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN +AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN +CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. + +Except as contained in this notice, the name of The Open Group shall not be +used in advertising or otherwise to promote the sale, use or other dealings +in this Software without prior written authorization from The Open Group. + + +Copyright 1987 by Digital Equipment Corporation, Maynard, Massachusetts. + +All Rights Reserved + +Permission to use, copy, modify, and distribute this software and its +documentation for any purpose and without fee is hereby granted, +provided that the above copyright notice appear in all copies and that +both that copyright notice and this permission notice appear in +supporting documentation, and that the name of Digital not be +used in advertising or publicity pertaining to distribution of the +software without specific, written prior permission. + +DIGITAL DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING +ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL +DIGITAL BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR +ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, +WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS +SOFTWARE. + +**/ + +/* + +(c)Copyright 1988,1991 Adobe Systems Incorporated. All rights reserved. + +Permission to use, copy, modify, distribute, and sublicense this software and its +documentation for any purpose and without fee is hereby granted, provided that +the above copyright notices appear in all copies and that both those copyright +notices and this permission notice appear in supporting documentation and that +the name of Adobe Systems Incorporated not be used in advertising or publicity +pertaining to distribution of the software without specific, written prior +permission. No trademark license to use the Adobe trademarks is hereby +granted. If the Adobe trademark Display PostScript(tm) is used to describe +this software, its functionality or for any other purpose, such use shall be +limited to a statement that this software works in conjunction with the Display +PostScript system. Proper trademark attribution to reflect Adobe's ownership +of the trademark shall be given whenever any such reference to the Display +PostScript system is made. + +ADOBE MAKES NO REPRESENTATIONS ABOUT THE SUITABILITY OF THE SOFTWARE FOR ANY +PURPOSE. IT IS PROVIDED AS IS WITHOUT EXPRESS OR IMPLIED WARRANTY. ADOBE +DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED +WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON- +INFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL ADOBE BE LIABLE TO YOU +OR ANY OTHER PARTY FOR ANY SPECIAL, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY +DAMAGES WHATSOEVER WHETHER IN AN ACTION OF CONTRACT,NEGLIGENCE, STRICT +LIABILITY OR ANY OTHER ACTION ARISING OUT OF OR IN CONNECTION WITH THE USE OR +PERFORMANCE OF THIS SOFTWARE.
[PATCH 2/5] dix: Extract callback.c from within dixutils.c
The file dixutils.c has grown into an incohesive and bloated beast. The time has come to refactor some of its routines to their own files. This patch gives a new home for all of those which deal with callback management. --- dix/Makefile.am |1 + dix/callback.c | 333 +++ dix/dixutils.c | 234 -- 3 files changed, 334 insertions(+), 234 deletions(-) create mode 100644 dix/callback.c diff --git a/dix/Makefile.am b/dix/Makefile.am index 8164a34..2716ea5 100644 --- a/dix/Makefile.am +++ b/dix/Makefile.am @@ -8,6 +8,7 @@ libmain_la_SOURCES =\ libdix_la_SOURCES =\ atom.c \ blockhandler.c \ + callback.c \ colormap.c \ cursor.c\ deprecated.c\ diff --git a/dix/callback.c b/dix/callback.c new file mode 100644 index 000..8404039 --- /dev/null +++ b/dix/callback.c @@ -0,0 +1,333 @@ +/*** + +Copyright 1987, 1998 The Open Group + +Permission to use, copy, modify, distribute, and sell this software and its +documentation for any purpose is hereby granted without fee, provided that +the above copyright notice appear in all copies and that both that +copyright notice and this permission notice appear in supporting +documentation. + +The above copyright notice and this permission notice shall be included in +all copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN +AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN +CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. + +Except as contained in this notice, the name of The Open Group shall not be +used in advertising or otherwise to promote the sale, use or other dealings +in this Software without prior written authorization from The Open Group. + + +Copyright 1987 by Digital Equipment Corporation, Maynard, Massachusetts. + +All Rights Reserved + +Permission to use, copy, modify, and distribute this software and its +documentation for any purpose and without fee is hereby granted, +provided that the above copyright notice appear in all copies and that +both that copyright notice and this permission notice appear in +supporting documentation, and that the name of Digital not be +used in advertising or publicity pertaining to distribution of the +software without specific, written prior permission. + +DIGITAL DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING +ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL +DIGITAL BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR +ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, +WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS +SOFTWARE. + +**/ + +/* + +(c)Copyright 1988,1991 Adobe Systems Incorporated. All rights reserved. + +Permission to use, copy, modify, distribute, and sublicense this software and its +documentation for any purpose and without fee is hereby granted, provided that +the above copyright notices appear in all copies and that both those copyright +notices and this permission notice appear in supporting documentation and that +the name of Adobe Systems Incorporated not be used in advertising or publicity +pertaining to distribution of the software without specific, written prior +permission. No trademark license to use the Adobe trademarks is hereby +granted. If the Adobe trademark Display PostScript(tm) is used to describe +this software, its functionality or for any other purpose, such use shall be +limited to a statement that this software works in conjunction with the Display +PostScript system. Proper trademark attribution to reflect Adobe's ownership +of the trademark shall be given whenever any such reference to the Display +PostScript system is made. + +ADOBE MAKES NO REPRESENTATIONS ABOUT THE SUITABILITY OF THE SOFTWARE FOR ANY +PURPOSE. IT IS PROVIDED AS IS WITHOUT EXPRESS OR IMPLIED WARRANTY. ADOBE +DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED +WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON- +INFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL ADOBE BE LIABLE TO YOU +OR ANY OTHER PARTY FOR ANY SPECIAL, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY +DAMAGES WHATSOEVER WHETHER IN AN ACTION OF CONTRACT,NEGLIGENCE, STRICT +LIABILITY OR ANY OTHER ACTION ARISING OUT OF OR IN CONNECTION WITH THE USE OR +PERFORMANCE OF THIS SOFTWARE.
[PATCH 3/5] dix: Extract lookup.c from within dixutils.c
The file dixutils.c has grown into an incohesive and bloated beast. The time has
come to refactor some of its routines to their own files. This patch gives a new
home for all of those which deal with resource lookup.
---
dix/Makefile.am |1 +
dix/dixutils.c | 92 ---
dix/lookup.c| 190 +++
3 files changed, 191 insertions(+), 92 deletions(-)
create mode 100644 dix/lookup.c
diff --git a/dix/Makefile.am b/dix/Makefile.am
index 2716ea5..c40a797 100644
--- a/dix/Makefile.am
+++ b/dix/Makefile.am
@@ -30,6 +30,7 @@ libdix_la_SOURCES = \
grabs.c \
initatoms.c \
inpututils.c\
+ lookup.c\
pixmap.c\
privates.c \
property.c \
diff --git a/dix/dixutils.c b/dix/dixutils.c
index c9075ec..ef2df44 100644
--- a/dix/dixutils.c
+++ b/dix/dixutils.c
@@ -185,98 +185,6 @@ CompareISOLatin1Lowered(unsigned char *s1, int s1len,
return (int) c1 - (int) c2;
}
-/*
- * dixLookupWindow and dixLookupDrawable:
- * Look up the window/drawable taking into account the client doing the
- * lookup, the type of drawable desired, and the type of access desired.
- * Return Success with *pDraw set if the window/drawable exists and the client
- * is allowed access, else return an error code with *pDraw set to NULL. The
- * access mask values are defined in resource.h. The type mask values are
- * defined in pixmap.h, with zero equivalent to M_DRAWABLE.
- */
-int
-dixLookupDrawable(DrawablePtr *pDraw, XID id, ClientPtr client,
- Mask type, Mask access)
-{
-DrawablePtr pTmp;
-int rc;
-
-*pDraw = NULL;
-client-errorValue = id;
-
-if (id == INVALID)
- return BadDrawable;
-
-rc = dixLookupResourceByClass((pointer *)pTmp, id, RC_DRAWABLE, client,
access);
-
-if (rc == BadValue)
- return BadDrawable;
-if (rc != Success)
- return rc;
-if (!((1 pTmp-type) (type ? type : M_DRAWABLE)))
- return BadMatch;
-
-*pDraw = pTmp;
-return Success;
-}
-
-int
-dixLookupWindow(WindowPtr *pWin, XID id, ClientPtr client, Mask access)
-{
-int rc;
-rc = dixLookupDrawable((DrawablePtr*)pWin, id, client, M_WINDOW, access);
-return (rc == BadDrawable) ? BadWindow : rc;
-}
-
-int
-dixLookupGC(GCPtr *pGC, XID id, ClientPtr client, Mask access)
-{
-return dixLookupResourceByType((pointer *)pGC, id, RT_GC, client, access);
-}
-
-int
-dixLookupFontable(FontPtr *pFont, XID id, ClientPtr client, Mask access)
-{
-int rc;
-GC *pGC;
-client-errorValue = id; /* EITHER font or gc */
-rc = dixLookupResourceByType((pointer *) pFont, id, RT_FONT, client,
access);
-if (rc != BadFont)
- return rc;
-rc = dixLookupResourceByType((pointer *) pGC, id, RT_GC, client, access);
-if (rc == BadGC)
- return BadFont;
-if (rc == Success)
- *pFont = pGC-font;
-return rc;
-}
-
-int
-dixLookupClient(ClientPtr *pClient, XID rid, ClientPtr client, Mask access)
-{
-pointer pRes;
-int rc = BadValue, clientIndex = CLIENT_ID(rid);
-
-if (!clientIndex || !clients[clientIndex] || (rid SERVER_BIT))
- goto bad;
-
-rc = dixLookupResourceByClass(pRes, rid, RC_ANY, client,
DixGetAttrAccess);
-if (rc != Success)
- goto bad;
-
-rc = XaceHook(XACE_CLIENT_ACCESS, client, clients[clientIndex], access);
-if (rc != Success)
- goto bad;
-
-*pClient = clients[clientIndex];
-return Success;
-bad:
-if(client)
-client-errorValue = rid;
-*pClient = NULL;
-return rc;
-}
-
int
AlterSaveSetForClient(ClientPtr client, WindowPtr pWin, unsigned mode,
Bool toRoot, Bool map)
diff --git a/dix/lookup.c b/dix/lookup.c
new file mode 100644
index 000..223be69
--- /dev/null
+++ b/dix/lookup.c
@@ -0,0 +1,190 @@
+/***
+
+Copyright 1987, 1998 The Open Group
+
+Permission to use, copy, modify, distribute, and sell this software and its
+documentation for any purpose is hereby granted without fee, provided that
+the above copyright notice appear in all copies and that both that
+copyright notice and this permission notice appear in supporting
+documentation.
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+Except as contained in this notice, the name of The Open Group shall not be
+used in advertising or
[PATCH 4/5] dix: Extract sleepqueue.c from within dixutils.c
The file dixutils.c has grown into an incohesive and bloated beast. The time has
come to refactor some of its routines to their own files. This patch gives a new
home for all of those which deal with sleeping clients.
---
dix/Makefile.am |1 +
dix/dixutils.c | 84 -
dix/sleepqueue.c | 184 ++
3 files changed, 185 insertions(+), 84 deletions(-)
create mode 100644 dix/sleepqueue.c
diff --git a/dix/Makefile.am b/dix/Makefile.am
index c40a797..c03b412 100644
--- a/dix/Makefile.am
+++ b/dix/Makefile.am
@@ -39,6 +39,7 @@ libdix_la_SOURCES = \
registry.c \
resource.c \
selection.c \
+ sleepqueue.c\
swaprep.c \
swapreq.c \
tables.c\
diff --git a/dix/dixutils.c b/dix/dixutils.c
index ef2df44..cc1ef6f 100644
--- a/dix/dixutils.c
+++ b/dix/dixutils.c
@@ -344,87 +344,3 @@ QueueWorkProc (
return TRUE;
}
-/*
- * Manage a queue of sleeping clients, awakening them
- * when requested, by using the OS functions IgnoreClient
- * and AttendClient. Note that this *ignores* the troubles
- * with request data interleaving itself with events, but
- * we'll leave that until a later time.
- */
-
-typedef struct _SleepQueue {
-struct _SleepQueue *next;
-ClientPtr client;
-ClientSleepProcPtr function;
-pointerclosure;
-} SleepQueueRec, *SleepQueuePtr;
-
-static SleepQueuePtr sleepQueue = NULL;
-
-Bool
-ClientSleep (ClientPtr client, ClientSleepProcPtr function, pointer closure)
-{
-SleepQueuePtr q;
-
-q = malloc(sizeof *q);
-if (!q)
- return FALSE;
-
-IgnoreClient (client);
-q-next = sleepQueue;
-q-client = client;
-q-function = function;
-q-closure = closure;
-sleepQueue = q;
-return TRUE;
-}
-
-Bool
-ClientSignal (ClientPtr client)
-{
-SleepQueuePtr q;
-
-for (q = sleepQueue; q; q = q-next)
- if (q-client == client)
- {
- return QueueWorkProc (q-function, q-client, q-closure);
- }
-return FALSE;
-}
-
-void
-ClientWakeup (ClientPtr client)
-{
-SleepQueuePtr q, *prev;
-
-prev = sleepQueue;
-while ( (q = *prev) )
-{
- if (q-client == client)
- {
- *prev = q-next;
- free(q);
- if (client-clientGone)
- /* Oops -- new zombie cleanup code ensures this only
-* happens from inside CloseDownClient; don't want to
-* recurse here...
-*/
- /* CloseDownClient(client) */;
- else
- AttendClient (client);
- break;
- }
- prev = q-next;
-}
-}
-
-Bool
-ClientIsAsleep (ClientPtr client)
-{
-SleepQueuePtr q;
-
-for (q = sleepQueue; q; q = q-next)
- if (q-client == client)
- return TRUE;
-return FALSE;
-}
diff --git a/dix/sleepqueue.c b/dix/sleepqueue.c
new file mode 100644
index 000..bdea641
--- /dev/null
+++ b/dix/sleepqueue.c
@@ -0,0 +1,184 @@
+/***
+
+Copyright 1987, 1998 The Open Group
+
+Permission to use, copy, modify, distribute, and sell this software and its
+documentation for any purpose is hereby granted without fee, provided that
+the above copyright notice appear in all copies and that both that
+copyright notice and this permission notice appear in supporting
+documentation.
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+Except as contained in this notice, the name of The Open Group shall not be
+used in advertising or otherwise to promote the sale, use or other dealings
+in this Software without prior written authorization from The Open Group.
+
+
+Copyright 1987 by Digital Equipment Corporation, Maynard, Massachusetts.
+
+All Rights Reserved
+
+Permission to use, copy, modify, and distribute this software and its
+documentation for any purpose and without fee is hereby granted,
+provided that the above copyright notice appear in all copies and that
+both that copyright notice and this permission notice appear in
+supporting documentation, and that the name of Digital not be
+used in advertising or publicity pertaining to distribution of the
+software without specific, written prior permission.
+
+DIGITAL DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING
+ALL IMPLIED WARRANTIES OF
[PATCH 5/5] dix: Extract blockhandler.c from within dixutils.c
The file dixutils.c has grown into an incohesive and bloated beast. The time has
come to refactor some of its routines to their own files. This patch gives a new
home for all of those which deal with work queues.
---
dix/Makefile.am |3 +-
dix/dixutils.c | 80 -
dix/workqueue.c | 176 +++
3 files changed, 178 insertions(+), 81 deletions(-)
create mode 100644 dix/workqueue.c
diff --git a/dix/Makefile.am b/dix/Makefile.am
index c03b412..58316a1 100644
--- a/dix/Makefile.am
+++ b/dix/Makefile.am
@@ -43,7 +43,8 @@ libdix_la_SOURCES = \
swaprep.c \
swapreq.c \
tables.c\
- window.c
+ window.c\
+ workqueue.c
EXTRA_DIST = buildatoms BuiltInAtoms Xserver.d Xserver-dtrace.h.in
diff --git a/dix/dixutils.c b/dix/dixutils.c
index cc1ef6f..898dbe5 100644
--- a/dix/dixutils.c
+++ b/dix/dixutils.c
@@ -264,83 +264,3 @@ void
NoopDDA(void)
{
}
-
-
-/*
- * A general work queue. Perform some task before the server
- * sleeps for input.
- */
-
-WorkQueuePtr workQueue;
-static WorkQueuePtr*workQueueLast = workQueue;
-
-void
-ProcessWorkQueue(void)
-{
-WorkQueuePtrq, *p;
-
-p = workQueue;
-/*
- * Scan the work queue once, calling each function. Those
- * which return TRUE are removed from the queue, otherwise
- * they will be called again. This must be reentrant with
- * QueueWorkProc.
- */
-while ((q = *p))
-{
- if ((*q-function) (q-client, q-closure))
- {
- /* remove q from the list */
- *p = q-next;/* don't fetch until after func called */
- free(q);
- }
- else
- {
- p = q-next;/* don't fetch until after func called */
- }
-}
-workQueueLast = p;
-}
-
-void
-ProcessWorkQueueZombies(void)
-{
-WorkQueuePtrq, *p;
-
-p = workQueue;
-while ((q = *p))
-{
- if (q-client q-client-clientGone)
- {
- (void) (*q-function) (q-client, q-closure);
- /* remove q from the list */
- *p = q-next;/* don't fetch until after func called */
- free(q);
- }
- else
- {
- p = q-next;/* don't fetch until after func called */
- }
-}
-workQueueLast = p;
-}
-
-Bool
-QueueWorkProc (
-Bool (*function)(ClientPtr /* pClient */, pointer /* closure */),
-ClientPtr client, pointer closure)
-{
-WorkQueuePtrq;
-
-q = malloc(sizeof *q);
-if (!q)
- return FALSE;
-q-function = function;
-q-client = client;
-q-closure = closure;
-q-next = NULL;
-*workQueueLast = q;
-workQueueLast = q-next;
-return TRUE;
-}
-
diff --git a/dix/workqueue.c b/dix/workqueue.c
new file mode 100644
index 000..6348b3e
--- /dev/null
+++ b/dix/workqueue.c
@@ -0,0 +1,176 @@
+/***
+
+Copyright 1987, 1998 The Open Group
+
+Permission to use, copy, modify, distribute, and sell this software and its
+documentation for any purpose is hereby granted without fee, provided that
+the above copyright notice appear in all copies and that both that
+copyright notice and this permission notice appear in supporting
+documentation.
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+
+Except as contained in this notice, the name of The Open Group shall not be
+used in advertising or otherwise to promote the sale, use or other dealings
+in this Software without prior written authorization from The Open Group.
+
+
+Copyright 1987 by Digital Equipment Corporation, Maynard, Massachusetts.
+
+All Rights Reserved
+
+Permission to use, copy, modify, and distribute this software and its
+documentation for any purpose and without fee is hereby granted,
+provided that the above copyright notice appear in all copies and that
+both that copyright notice and this permission notice appear in
+supporting documentation, and that the name of Digital not be
+used in advertising or publicity pertaining to distribution of the
+software without specific, written prior permission.
+
+DIGITAL DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING
+ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL
+DIGITAL BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR
+ANY DAMAGES WHATSOEVER RESULTING
Re: [PATCH 5/5] dix: Extract blockhandler.c from within dixutils.c
Fernando Carrijo fcarr...@yahoo.com.br wrote: The file dixutils.c has grown into an incohesive and bloated beast. The time has come to refactor some of its routines to their own files. This patch gives a new home for all of those which deal with work queues. --- dix/Makefile.am |3 +- dix/dixutils.c | 80 - dix/workqueue.c | 176 +++ 3 files changed, 178 insertions(+), 81 deletions(-) create mode 100644 dix/workqueue.c Argh! Sorry for the wrong subject. ___ 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
