Re: [PATCH] Remove leftover fbSaveAreas fbRestoreAreas defines from wfbrename.h
Checked grep to be sure... Reviewed-by: Jeremy Huddleston jerem...@apple.com Tested-by: Jeremy Huddleston jerem...@apple.com On Oct 5, 2010, at 18:05, Alan Coopersmith wrote: The fb functions they try to rename were deleted in 2007 by commit ae7f71a8b3d6756161e55d998d6eec37d2695c98 Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com --- fb/wfbrename.h |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/fb/wfbrename.h b/fb/wfbrename.h index 433f286..c8e98c8 100644 --- a/fb/wfbrename.h +++ b/fb/wfbrename.h @@ -155,8 +155,6 @@ #define fbReduceRasterOp wfbReduceRasterOp #define fbReplicatePixel wfbReplicatePixel #define fbResolveColor wfbResolveColor -#define fbRestoreAreas wfbRestoreAreas -#define fbSaveAreas wfbSaveAreas #define fbScreenPrivateKeyRec wfbScreenPrivateKeyRec #define fbSegment wfbSegment #define fbSelectBres wfbSelectBres -- 1.5.6.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 ___ 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:libXt-1.0.8 fix possible NULL access
Alan Coopersmith schrieb: walter harms wrote: You appear to have attached a different version of the patch than in the body of your e-mail - neither git nor patch can apply either one to the current git tree. After a bit of manual editing I finally got one to work, so I fixed the indenting and committed it. I am confused, I used the current 1.0.8 as base. Are the problems related to the tabs or more ? The patch in your attachment claimed to delete a /* FIXME: can be NULL */ comment that wasn't in the original source, and left a trailing space at the end of the line that git rejects. The one in the message body did not show the FIXME comment. ok, i see, i forgot the attach the new patchset after i saw that i left my FIXME comment my bad. BTW: Intrinsic.c: static char *ExtractLocaleName() the comment says: Should match the code in Xlib _XlcMapOSLocaleName but the code in _XlcMapOSLocaleName() look very different. can you take a look please ? re, wh ___ 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 libXi] Fix typo when converting raw events from the wire.
From: Carlos Garnacho carl...@gnome.org The raw values were being miscalculated, containing only the integral part of the FP3232, meanwhile normal valuators were mistakenly added the fractional part of its corresponding raw value. Signed-off-by: Carlos Garnacho carl...@gnome.org --- src/XExtInt.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/XExtInt.c b/src/XExtInt.c index 4909ab6..05b4ff2 100644 --- a/src/XExtInt.c +++ b/src/XExtInt.c @@ -1804,7 +1804,7 @@ wireToRawEvent(xXIRawEvent *in, XGenericEventCookie *cookie) out-valuators.values[i] = values-integral; out-valuators.values[i] += ((double)values-frac / (1 16) / (1 16)); out-raw_values[i] = (values + bits)-integral; -out-valuators.values[i] += ((double)(values + bits)-frac / (1 16) / (1 16)); +out-raw_values[i] += ((double)(values + bits)-frac / (1 16) / (1 16)); values++; } -- 1.7.0.4 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] DRI2: Add ReuseBufferNotify hook
ReuseBufferNotify hook is called whenever old buffer is reused in DRI2
code.
Driver can use this hook to rewrite the buffer name if hardware requires
shared buffers. Shared buffer might be some hardware limited resources like
framebuffer that is preallocated in boot.
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
hw/xfree86/dri2/dri2.c |9 +
hw/xfree86/dri2/dri2.h | 16 +++-
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index c96eb35..228c0e0 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -101,6 +101,7 @@ typedef struct _DRI2Screen {
DRI2GetMSCProcPtr GetMSC;
DRI2ScheduleWaitMSCProcPtr ScheduleWaitMSC;
DRI2AuthMagicProcPtrAuthMagic;
+DRI2ReuseBufferNotifyProcPtr ReuseBufferNotify;
HandleExposuresProcPtr HandleExposures;
@@ -369,6 +370,10 @@ allocate_or_reuse_buffer(DrawablePtr pDraw, DRI2ScreenPtr
ds,
} else {
*buffer = pPriv-buffers[old_buf];
+
+ if (ds-ReuseBufferNotify)
+ (*ds-ReuseBufferNotify)(pDraw, *buffer);
+
pPriv-buffers[old_buf] = NULL;
return FALSE;
}
@@ -1123,6 +1128,10 @@ DRI2ScreenInit(ScreenPtr pScreen, DRI2InfoPtr info)
ds-AuthMagic = info-AuthMagic;
}
+if (info-version = 6) {
+ ds-ReuseBufferNotify = info-ReuseBufferNotify;
+}
+
/*
* if the driver doesn't provide an AuthMagic function or the info struct
* version is too low, it relies on the old method (using libdrm) or fail
diff --git a/hw/xfree86/dri2/dri2.h b/hw/xfree86/dri2/dri2.h
index 0e0bea4..3d01c55 100644
--- a/hw/xfree86/dri2/dri2.h
+++ b/hw/xfree86/dri2/dri2.h
@@ -110,6 +110,16 @@ typedef DRI2BufferPtr
(*DRI2CreateBufferProcPtr)(DrawablePtr pDraw,
typedef void (*DRI2DestroyBufferProcPtr)(DrawablePtr pDraw,
DRI2BufferPtr buffer);
/**
+ * Notifies driver when DRI2GetBuffers reuses a dri2 buffer.
+ *
+ * Driver may rename the dri2 buffer in this notify if it is required.
+ *
+ * \param pDraw drawable whose count we want
+ * \param buffer buffer that will be returned to client
+ */
+typedef void (*DRI2ReuseBufferNotifyProcPtr)(DrawablePtr pDraw,
+ DRI2BufferPtr buffer);
+/**
* Get current media stamp counter values
*
* This callback is used to support the SGI_video_sync and OML_sync_control
@@ -161,7 +171,7 @@ typedef void
(*DRI2InvalidateProcPtr)(DrawablePtr pDraw,
/**
* Version of the DRI2InfoRec structure defined in this header
*/
-#define DRI2INFOREC_VERSION 5
+#define DRI2INFOREC_VERSION 6
typedef struct {
unsigned int version; /** Version of this struct */
@@ -189,6 +199,10 @@ typedef struct {
/* added in version 5 */
DRI2AuthMagicProcPtr AuthMagic;
+
+/* added in version 6 */
+
+DRI2ReuseBufferNotifyProcPtr ReuseBufferNotify;
} DRI2InfoRec, *DRI2InfoPtr;
extern _X_EXPORT int DRI2EventBase;
--
1.7.0.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] DRI2: Expose API to set drawable swap limit.
This allows ddx to set swap_limit if there is more than one back
buffer for drawable. Setting swap_limit has to also check if change
affects a client that is blocked.
This can be used to implement N-buffering in driver with minimal
logic in allocation and selecting next back.
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
hw/xfree86/dri2/dri2.c | 23 +++
hw/xfree86/dri2/dri2.h |1 +
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 34f735f..c96eb35 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -190,6 +190,29 @@ DRI2AllocateDrawable(DrawablePtr pDraw)
return pPriv;
}
+Bool
+DRI2SwapLimit(DrawablePtr pDraw, int swap_limit)
+{
+DRI2DrawablePtr pPriv = DRI2GetDrawable(pDraw);
+if (!pPriv)
+ return FALSE;
+
+pPriv-swap_limit = swap_limit;
+
+/* Check throttling */
+if (pPriv-swapsPending = pPriv-swap_limit)
+ return TRUE;
+
+if (pPriv-target_sbc == -1 !pPriv-blockedOnMsc) {
+ if (pPriv-blockedClient) {
+ AttendClient(pPriv-blockedClient);
+ pPriv-blockedClient = NULL;
+ }
+}
+
+return TRUE;
+}
+
typedef struct DRI2DrawableRefRec {
XID id;
XID dri2_id;
diff --git a/hw/xfree86/dri2/dri2.h b/hw/xfree86/dri2/dri2.h
index fe0bf6c..0e0bea4 100644
--- a/hw/xfree86/dri2/dri2.h
+++ b/hw/xfree86/dri2/dri2.h
@@ -251,6 +251,7 @@ extern _X_EXPORT DRI2BufferPtr
*DRI2GetBuffersWithFormat(DrawablePtr pDraw,
int *out_count);
extern _X_EXPORT void DRI2SwapInterval(DrawablePtr pDrawable, int interval);
+extern _X_EXPORT Bool DRI2SwapLimit(DrawablePtr pDraw, int swap_limit);
extern _X_EXPORT int DRI2SwapBuffers(ClientPtr client, DrawablePtr pDrawable,
CARD64 target_msc, CARD64 divisor,
CARD64 remainder, CARD64 *swap_target,
--
1.7.0.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 1/2] DRI2: Avoid call to NULL pointer
DDX driver may implement schedule swap without GetMSC. In that case we
can't call GetMSC in DRI2SwapBuffers.
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
hw/xfree86/dri2/dri2.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 228c0e0..d9b9d57 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -856,11 +856,14 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr pDraw,
CARD64 target_msc,
* is moved to a crtc with a lower refresh rate, or a crtc that just
* got enabled.
*/
- if (!(*ds-GetMSC)(pDraw, ust, current_msc))
- pPriv-last_swap_target = 0;
+ if (ds-GetMSC) {
+ if (!(*ds-GetMSC)(pDraw, ust, current_msc))
+ pPriv-last_swap_target = 0;
- if (current_msc pPriv-last_swap_target)
- pPriv-last_swap_target = current_msc;
+ if (current_msc pPriv-last_swap_target)
+ pPriv-last_swap_target = current_msc;
+
+ }
/*
* Swap target for this swap is last swap target + swap interval since
--
1.7.0.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 2/2] DRI2: Add error message when working around driver bug
There isn't API that allows application atomically query for msc changes
and schedule swaps. If msc changes dramatically between query and
scheduling application would schedule swap to happen at wrong time.
Because of API limitations driver has to make msc increment for each
vblank affecting the drawable.
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
hw/xfree86/dri2/dri2.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index d9b9d57..d70c115 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -860,9 +860,12 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr pDraw,
CARD64 target_msc,
if (!(*ds-GetMSC)(pDraw, ust, current_msc))
pPriv-last_swap_target = 0;
- if (current_msc pPriv-last_swap_target)
+ if (current_msc pPriv-last_swap_target) {
pPriv-last_swap_target = current_msc;
-
+ xf86DrvMsg(pScreen-myNum, X_ERROR,
+ [DRI2] %s: GetMSC returned swap count that is in
+ past. Working around driver bug.\n, __func__);
+ }
}
/*
--
1.7.0.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] render: repack PictureRec
Eliminate the unused dither field, move filter and stateChanges into the
bitfield, and reorder elements to pack holes on LP64.
sizeof(PictureRec) ILP32 LP64
before:84152
after: 72120
Signed-off-by: Adam Jackson a...@redhat.com
---
hw/dmx/dmxpict.c|2 --
render/picture.c|6 ++
render/picturestr.h | 15 +++
3 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/hw/dmx/dmxpict.c b/hw/dmx/dmxpict.c
index 915e767..ab26593 100644
--- a/hw/dmx/dmxpict.c
+++ b/hw/dmx/dmxpict.c
@@ -1011,8 +1011,6 @@ void dmxValidatePicture(PicturePtr pPicture, Mask mask)
attribs.poly_edge = pPicture-polyEdge;
if (mask CPPolyMode)
attribs.poly_mode = pPicture-polyMode;
- if (mask CPDither)
- attribs.dither = pPicture-dither;
if (mask CPComponentAlpha)
attribs.component_alpha = pPicture-componentAlpha;
diff --git a/render/picture.c b/render/picture.c
index 7fda6b9..8f4e631 100644
--- a/render/picture.c
+++ b/render/picture.c
@@ -735,13 +735,12 @@ SetPictureToDefaults (PicturePtrpPicture)
pPicture-transform = 0;
-pPicture-dither = None;
pPicture-filter = PictureGetFilterId (FilterNearest, -1, TRUE);
pPicture-filter_params = 0;
pPicture-filter_nparams = 0;
pPicture-serialNumber = GC_CHANGE_SERIAL_BIT;
-pPicture-stateChanges = (1 (CPLastBit+1)) - 1;
+pPicture-stateChanges = -1;
pPicture-pSourcePict = 0;
}
@@ -1261,7 +1260,7 @@ ChangePicture (PicturePtr pPicture,
}
break;
case CPDither:
- pPicture-dither = NEXT_VAL(Atom);
+ (void) NEXT_VAL(Atom); /* unimplemented */
break;
case CPComponentAlpha:
{
@@ -1483,7 +1482,6 @@ CopyPicture (PicturePtr pSrc,
pDst-polyMode = pSrc-polyMode;
break;
case CPDither:
- pDst-dither = pSrc-dither;
break;
case CPComponentAlpha:
pDst-componentAlpha = pSrc-componentAlpha;
diff --git a/render/picturestr.h b/render/picturestr.h
index 5c6c41e..ae69eef 100644
--- a/render/picturestr.h
+++ b/render/picturestr.h
@@ -151,8 +151,6 @@ typedef struct _Picture {
PictFormatShort format;/* PICT_FORMAT */
intrefcnt;
CARD32 id;
-PicturePtr pNext; /* chain on same drawable */
-
unsigned intrepeat : 1;
unsigned intgraphicsExposures : 1;
unsigned intsubWindowMode : 1;
@@ -162,7 +160,11 @@ typedef struct _Picture {
unsigned intclientClipType : 2;
unsigned intcomponentAlpha : 1;
unsigned intrepeatType : 2;
-unsigned intunused : 21;
+unsigned intfilter : 3;
+unsigned intstateChanges : CPLastBit;
+unsigned intunused : 18 - CPLastBit;
+
+PicturePtr pNext; /* chain on same drawable */
PicturePtr alphaMap;
DDXPointRecalphaOrigin;
@@ -170,9 +172,6 @@ typedef struct _Picture {
DDXPointRecclipOrigin;
pointerclientClip;
-Atom dither;
-
-unsigned long stateChanges;
unsigned long serialNumber;
RegionPtr pCompositeClip;
@@ -181,10 +180,9 @@ typedef struct _Picture {
PictTransform *transform;
-intfilter;
+SourcePictPtr pSourcePict;
xFixed *filter_params;
intfilter_nparams;
-SourcePictPtr pSourcePict;
} PictureRec;
typedef Bool (*PictFilterValidateParamsProcPtr) (ScreenPtr pScreen, int id,
@@ -205,6 +203,7 @@ typedef struct {
#define PictFilterBest 4
#define PictFilterConvolution 5
+/* if you add an 8th filter, expand the filter bitfield above */
typedef struct {
char *alias;
--
1.7.2.2
___
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: Disabling monitors with bad EDIDs?!?!
On 24 September 2010 07:07, Kai-Uwe Behrmann k...@gmx.de wrote: Manufacturers have typical good colour measurement equipement and appear to put some reasonable colorimetric data inside the EDID. The colorimetric precission is of course rough, given that the gamma curves are represented by just one float value. Can't we use the xy co-ordinates provided in the colour point data? Am I missing something obvious? Thanks. Richard. ___ 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: Disabling monitors with bad EDIDs?!?!
Am 06.10.10, 16:54 +0100 schrieb Richard Hughes: On 24 September 2010 07:07, Kai-Uwe Behrmann k...@gmx.de wrote: Manufacturers have typical good colour measurement equipement and appear to put some reasonable colorimetric data inside the EDID. The colorimetric precission is of course rough, given that the gamma curves are represented by just one float value. Can't we use the xy co-ordinates provided in the colour point data? Am I missing something obvious? Oyranos generates ICC profiles on the fly from EDID. The EDID parsing code will be contained in the next libXcm release. kind regards Kai-Uwe Behrmann -- developing for colour management www.behrmann.name + www.oyranos.org ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH libXi] Fix typo when converting raw events from the wire.
Reviewed-by: Jeremy Huddleston jerem...@apple.com On Oct 6, 2010, at 02:04, Carlos Garnacho wrote: From: Carlos Garnacho carl...@gnome.org The raw values were being miscalculated, containing only the integral part of the FP3232, meanwhile normal valuators were mistakenly added the fractional part of its corresponding raw value. Signed-off-by: Carlos Garnacho carl...@gnome.org --- src/XExtInt.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/XExtInt.c b/src/XExtInt.c index 4909ab6..05b4ff2 100644 --- a/src/XExtInt.c +++ b/src/XExtInt.c @@ -1804,7 +1804,7 @@ wireToRawEvent(xXIRawEvent *in, XGenericEventCookie *cookie) out-valuators.values[i] = values-integral; out-valuators.values[i] += ((double)values-frac / (1 16) / (1 16)); out-raw_values[i] = (values + bits)-integral; -out-valuators.values[i] += ((double)(values + bits)-frac / (1 16) / (1 16)); +out-raw_values[i] += ((double)(values + bits)-frac / (1 16) / (1 16)); values++; } -- 1.7.0.4 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ 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] Xorg restarted each session after some activity (20-30 minutes).
From: Sebastian Glita gs...@cs.upt.ro
A simple fixup in dixutils.c:_CallCallbacks:
- by moving recursion count check *before* list iteration and actual callbacks'
invocation;
- can say for sure, though, whether counters (member `int inCallback' from
include/dixstruct.h:171:CallbackListRec structure) were supposed to grow
greater than 1 before iteration,
- so cannot ascertain whether the new behavior is required.
The mutual recursive functions' chain:
1. dix/dixutils.c:CallCallbacks:877
2. dix/dixutils.c:_CallCallbacks:743
3. record/record.c:RecordFlushAllContexts:867
4. record/record.c:RecordFlushReplyBuffer:251
5. os/io.c:WriteToClient:824
Signed-off-by: Sebastian Glita gs...@cs.upt.ro
---
dix/dixutils.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/dix/dixutils.c b/dix/dixutils.c
index 470bb5d..e3c9c22 100644
--- a/dix/dixutils.c
+++ b/dix/dixutils.c
@@ -737,6 +737,8 @@ _CallCallbacks(
CallbackListPtr cbl = *pcbl;
CallbackPtr cbr, pcbr;
+if (cbl-inCallback) return;
+
++(cbl-inCallback);
for (cbr = cbl-list; cbr != NULL; cbr = cbr-next)
{
@@ -744,8 +746,6 @@ _CallCallbacks(
}
--(cbl-inCallback);
-if (cbl-inCallback) return;
-
/* Was the entire list marked for deletion? */
if (cbl-deleted)
--
1.7.3.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 modular] Process a user-supplied list of module/components.
On Tue, 2010-10-05 at 17:35 -0400, Trevor Woerner wrote: From: Trevor Woerner twoer...@gmail.com New feature. Using the new --modlist file option, the user can specify a file which contains a list of the module/component items to process. The file can contain blank lines and comment lines which start with a hash mark (#). The list can be in any arbitrary order, the script will process them in the correct dependency order. The script can't figure out what the dependencies are, it expects the list to contain the necessary module/component items. The script attempts to process any unknown items at the end of the known list. Any reasons why this is better for the user? I think 99 out of a 100 users will expect the module to be build in the order specified in the provided list. If it is not doable, we should have a way for users to quickly find out it's the way it works so he does not waste time debugging. Suggested usage: 1. run script go generate the list of known items, redirecting to a file || type? to prehaps $ util/modular/build.sh -L modulefile 2. edit file, commenting or deleting out unnecessary items 3. run the build off the list: $ util/modular/build.sh $PREFIX --modfile modulefile ... This is great stuff. 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 modular] Process a user-supplied list of module/components.
On Wed, Oct 6, 2010 at 3:59 PM, Gaetan Nadon mems...@videotron.ca wrote: On Tue, 2010-10-05 at 17:35 -0400, Trevor Woerner wrote: The script attempts to process any unknown items at the end of the known list. Any reasons why this is better for the user? I think 99 out of a 100 users will expect the module to be build in the order specified in the provided list. I agree... but to be honest I think the more pertinent question is: why would a user be trying to build unknown sub-projects? Shouldn't all the projects be known to the build.sh script? Should the script even support unknown projects? If a new project is being added to the X.Org family, shouldn't it be patched into the build script the way the others are already? If it is not doable, we should have a way for users to quickly find out it's the way it works so he does not waste time debugging. I'll think about ways to build unknown projects in whatever order they're specified, but I really think projects that aren't known to the script shouldn't be supported at all. Let's say you're working on a new project to be added: xf86-video-gaetan. I would hope that as part of your development you would determine where in the sub-project list it should be built, add it to the build.sh script, then submit it when you send in the patches for the rest of your work. In other words, if you're working on something locally that isn't yet available publicly, just patch your build.sh to support your new project, then send it in when the rest of your work gets accepted. I was under the impression one of the most important things the build.sh script provides for the user is the ability to build all the sub-projects of X.Org in the correct order. So in that case no matter how the user supplies the list of projects they want built, the script should build them in the order it knows will work correctly. I think that's important to retain; more important than supporting sub-projects which aren't known to the script. Suggested usage: 1. run script go generate the list of known items, redirecting to a file || type? to prehaps Yes, typo. Sorry. ___ 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 modular] Process a user-supplied list of module/components.
On Wed, Oct 6, 2010 at 4:16 PM, Trevor Woerner twoer...@gmail.com wrote: Shouldn't all the projects be known to the build.sh script? Whoops, one more thought I forgot to add: how would the script differentiate between an unlisted sub-project the user wants the script to build and a known sub-project which the user has simply misspelled? It's obvious xf86-video-gaetan is something new and probably local you want built, but what about xf86-video-silicomnotion or xf86-video-silliconmotion? ___ 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 modular] Process a user-supplied list of module/components.
On Wed, 2010-10-06 at 16:16 -0400, Trevor Woerner wrote: I agree... but to be honest I think the more pertinent question is: why would a user be trying to build unknown sub-projects? Shouldn't all the projects be known to the build.sh script? Should the script even support unknown projects? If a new project is being added to the X.Org family, shouldn't it be patched into the build script the way the others are already? If it is not doable, we should have a way for users to quickly find out it's the way it works so he does not waste time debugging. I'll think about ways to build unknown projects in whatever order they're specified, but I really think projects that aren't known to the script shouldn't be supported at all. Let's say you're working on a new project to be added: xf86-video-gaetan. I would hope that as part of your development you would determine where in the sub-project list it should be built, add it to the build.sh script, then submit it when you send in the patches for the rest of your work. In other words, if you're working on something locally that isn't yet available publicly, just patch your build.sh to support your new project, then send it in when the rest of your work gets accepted. I was under the impression one of the most important things the build.sh script provides for the user is the ability to build all the sub-projects of X.Org in the correct order. So in that case no matter how the user supplies the list of projects they want built, the script should build them in the order it knows will work correctly. I think that's important to retain; more important than supporting sub-projects which aren't known to the script. Exactly how I used to see things. But Xorg does not have finite boundaries. The list of modules you see in build.sh has been crafted over several years, adding and removing some around the time of a release. It is based on usage and if there is a maintainer. Some modules gets dropped-off the list because there is no maintainer and the module ceases to function or build. Some modules make a come back after a few years. Here is a concrete example of a module which is included in my distro, has been and will be in use for quite some time: xf86-input-wacom a driver for Wacom tablets. This is the module description, which summarizes it all: Note that it is not a part of the X.Org distribution since X11R6: this driver is from the linuxwacom project. See http://linuxwacom.sf.net for details. The radeonhd driver is in build.sh but has not yet been include in an Xorg release. The mesa, xcb, pixman and xkeyboard-config are dependencies of xorg, but are separate projects. They are included in build.sh to make it easy to have a complete build. The build.sh script does not reflect the scope of the X.Org Project and does not reflect the content of the current release either. Even the term release is too strict, we use katamari. Back to the feature in question. Assuming what I said makes sense and there is a reasonable use for a custom list, it makes sense that I would add a driver alongside the other drivers and expect it to be build where it is placed in the list. This is not a critical feature, should the implementation effort be unreasonable, I can certainly live with the way it is today. To answer your question in the next post, a user supplied module name that is unknown to build.sh is dealt with on a best effort basis. If there is a typo, it fails to build (or clone). It will be easier to find out if it is processed in list order. The hard-coded module list in build.sh is probably why it is not as popular as it could be. Nobody works on 240 modules at a time. Many don't ever build the apps, for example. About half of them are deprecated and not included in a release. Many are only interested in the server (and it's dependencies), while otehrs may be interested in a full release as customized on their distros. I could be wrong, but I thought that having a custom list would go a long way in making build.sh more useful. That's why I still don't think that sorting a list of modules to build them in order in terribly useful. If this gets in the way of processing modules in the order supplied by the user, I would drop this sorting feature. 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
[PATCH modular] build.sh usage text: remove annoying backslashes
This is text intended for the user to read, not the shell interpreter. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- build.sh | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/build.sh b/build.sh index 1e31c2a..f9b581d 100755 --- a/build.sh +++ b/build.sh @@ -10,8 +10,8 @@ global environment variables you may set: global environment variables you may set to replace default functionality: ACLOCAL: alternate invocation for 'aclocal' (default: aclocal) MAKE: program to use instead of 'make' (default: make) - FONTPATH: font path to use (defaults under: \$PREFIX/\$LIBDIR...) - LIBDIR: path under \$PREFIX for libraries (e.g., lib64) (default: lib) + FONTPATH: font path to use (defaults under: $PREFIX/$LIBDIR...) + LIBDIR: path under $PREFIX for libraries (e.g., lib64) (default: lib) GITROOT: path to freedesktop.org git root, only needed for --clone (default: git://anongit.freedesktop.org/git) @@ -20,12 +20,12 @@ global environment variables you may set to augment functionality: CONFCFLAGS: additional compile flags to pass to all configure scripts MAKEFLAGS: additional flags to pass to all make invocations PKG_CONFIG_PATH: include paths in addition to: - \$DESTDIR/\$PREFIX/share/pkgconfig - \$DESTDIR/\$PREFIX/\$LIBDIR/pkgconfig + $DESTDIR/$PREFIX/share/pkgconfig + $DESTDIR/$PREFIX/$LIBDIR/pkgconfig LD_LIBRARY_PATH: include paths in addition to: - \$DESTDIR/\$PREFIX/\$LIBDIR + $DESTDIR/$PREFIX/$LIBDIR PATH:include paths in addition to: - \$DESTDIR/\$PREFIX/bin + $DESTDIR/$PREFIX/bin EOF } -- 1.6.0.4 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular] Process a user-supplied list of module/components.
On Wed, Oct 6, 2010 at 5:21 PM, Gaetan Nadon mems...@videotron.ca wrote: I could be wrong, but I thought that having a custom list would go a long way in making build.sh more useful. That's why I still don't think that sorting a list of modules to build them in order in terribly useful. The fact is you have a lot more experience with this stuff than I do. So if you say building them in the user-specified order is more important than sorting them, I can easily create a new patch which implements this behaviour. Besides, what's there already sort-of allows the user to build an arbitrary set of sub-projects in sorted order. ___ 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 modular] build.sh usage text: remove annoying backslashes
On Wed, Oct 6, 2010 at 5:30 PM, Gaetan Nadon mems...@videotron.ca wrote: This is text intended for the user to read, not the shell interpreter. Yes, that's why there are backslashes, so the interpreter doesn't replace them when displaying the help text. For example the user is told they can set an environment variable called LIBDIR to specify where to install libraries. FONTPATH uses the defined LIBDIR so to specify the FONTPATH the usage is currently described as: FONTPATH: font path to use (defaults under: $PREFIX/$LIBDIR...) If you remove the backslashes the user will be informed that: FONTPATH: font path to use (defaults under: /...) if neither $PREFIX nor $LIBDIR are set. In this case it's not clear to the user that the FONTPATH is being built using the predefined PREFIX and LIBDIR variables. ___ 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 modular] Process a user-supplied list of module/components.
On Wed, 2010-10-06 at 17:37 -0400, Trevor Woerner wrote: The fact is you have a lot more experience with this stuff than I do. So if you say building them in the user-specified order is more important than sorting them, I can easily create a new patch which implements this behaviour. And many others have a lot more than I do. Hopefully, we will get more feedback. Users like to customize, we can never anticipate all the possible uses. 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 2/2] DRI2: Add error message when working around driver bug
On Oct 6, 2010, at 1:05 PM, Pauli Nieminen wrote:
There isn't API that allows application atomically query for msc
changes
and schedule swaps. If msc changes dramatically between query and
scheduling application would schedule swap to happen at wrong time.
Because of API limitations driver has to make msc increment for each
vblank affecting the drawable.
Hi Paul,
this is not a driver bug which should be reported as an error, but
simply handling of what happens if a drawable is moved by the user
from one display head to a different display head, which likely has a
different msc count because it runs at a different refresh rate or
was enabled later than the first crtc.
Therefore i don't think this error printout should be added. It is
arguably not perfect, but probably good enough for the most common
cases. The correct solution would be to virtualize the msc counter
for each drawable and keep track of crtc changes and compensate for
those at each change. I have some ideas on how to do this properly,
just didn't have the time to test them.
best,
-mario
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
hw/xfree86/dri2/dri2.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index d9b9d57..d70c115 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -860,9 +860,12 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr
pDraw, CARD64 target_msc,
if (!(*ds-GetMSC)(pDraw, ust, current_msc))
pPriv-last_swap_target = 0;
- if (current_msc pPriv-last_swap_target)
+ if (current_msc pPriv-last_swap_target) {
pPriv-last_swap_target = current_msc;
-
+ xf86DrvMsg(pScreen-myNum, X_ERROR,
+ [DRI2] %s: GetMSC returned swap count that is in
+ past. Working around driver bug.\n, __func__);
+ }
}
/*
--
1.7.0.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
*
Mario Kleiner
Max Planck Institute for Biological Cybernetics
Spemannstr. 38
72076 Tuebingen
Germany
e-mail: mario.klei...@tuebingen.mpg.de
office: +49 (0)7071/601-1623
fax:+49 (0)7071/601-616
www:http://www.kyb.tuebingen.mpg.de/~kleinerm
*
For a successful technology, reality must take precedence
over public relations, for Nature cannot be fooled.
(Richard Feynman)
___
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 modular] build.sh usage text: remove annoying backslashes
On Wed, 2010-10-06 at 17:46 -0400, Trevor Woerner wrote: On Wed, Oct 6, 2010 at 5:30 PM, Gaetan Nadon mems...@videotron.ca wrote: This is text intended for the user to read, not the shell interpreter. Yes, that's why there are backslashes, so the interpreter doesn't replace them when displaying the help text. For example the user is told they can set an environment variable called LIBDIR to specify where to install libraries. FONTPATH uses the defined LIBDIR so to specify the FONTPATH the usage is currently described as: FONTPATH: font path to use (defaults under: $PREFIX/$LIBDIR...) If you remove the backslashes the user will be informed that: FONTPATH: font path to use (defaults under: /...) if neither $PREFIX nor $LIBDIR are set. In this case it's not clear to the user that the FONTPATH is being built using the predefined PREFIX and LIBDIR variables. Thanks I should have seen this. 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 1/2] DRI2: Avoid call to NULL pointer
On Oct 6, 2010, at 1:05 PM, Pauli Nieminen wrote:
DDX driver may implement schedule swap without GetMSC. In that case we
can't call GetMSC in DRI2SwapBuffers.
I don't think this check is neccessary. Afaik if the ds-GetMSC entry
point isn't defined then ds-ScheduleSwap isn't defined either, so
the !ds-ScheduleSwap check at the beginning of the routine triggers
and the fallback path is taken, no?
-mario
Signed-off-by: Pauli Nieminen ext-pauli.niemi...@nokia.com
---
hw/xfree86/dri2/dri2.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/hw/xfree86/dri2/dri2.c b/hw/xfree86/dri2/dri2.c
index 228c0e0..d9b9d57 100644
--- a/hw/xfree86/dri2/dri2.c
+++ b/hw/xfree86/dri2/dri2.c
@@ -856,11 +856,14 @@ DRI2SwapBuffers(ClientPtr client, DrawablePtr
pDraw, CARD64 target_msc,
* is moved to a crtc with a lower refresh rate, or a crtc that just
* got enabled.
*/
- if (!(*ds-GetMSC)(pDraw, ust, current_msc))
- pPriv-last_swap_target = 0;
+ if (ds-GetMSC) {
+ if (!(*ds-GetMSC)(pDraw, ust, current_msc))
+ pPriv-last_swap_target = 0;
- if (current_msc pPriv-last_swap_target)
- pPriv-last_swap_target = current_msc;
+ if (current_msc pPriv-last_swap_target)
+ pPriv-last_swap_target = current_msc;
+
+ }
/*
* Swap target for this swap is last swap target + swap interval
since
--
1.7.0.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
*
Mario Kleiner
Max Planck Institute for Biological Cybernetics
Spemannstr. 38
72076 Tuebingen
Germany
e-mail: mario.klei...@tuebingen.mpg.de
office: +49 (0)7071/601-1623
fax:+49 (0)7071/601-616
www:http://www.kyb.tuebingen.mpg.de/~kleinerm
*
For a successful technology, reality must take precedence
over public relations, for Nature cannot be fooled.
(Richard Feynman)
___
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 libXi] Fix typo when converting raw events from the wire.
On Wed, Oct 06, 2010 at 12:27:15PM -0700, Jeremy Huddleston wrote: Reviewed-by: Jeremy Huddleston jerem...@apple.com On Oct 6, 2010, at 02:04, Carlos Garnacho wrote: From: Carlos Garnacho carl...@gnome.org The raw values were being miscalculated, containing only the integral part of the FP3232, meanwhile normal valuators were mistakenly added the fractional part of its corresponding raw value. Signed-off-by: Carlos Garnacho carl...@gnome.org --- src/XExtInt.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/XExtInt.c b/src/XExtInt.c index 4909ab6..05b4ff2 100644 --- a/src/XExtInt.c +++ b/src/XExtInt.c @@ -1804,7 +1804,7 @@ wireToRawEvent(xXIRawEvent *in, XGenericEventCookie *cookie) out-valuators.values[i] = values-integral; out-valuators.values[i] += ((double)values-frac / (1 16) / (1 16)); out-raw_values[i] = (values + bits)-integral; -out-valuators.values[i] += ((double)(values + bits)-frac / (1 16) / (1 16)); +out-raw_values[i] += ((double)(values + bits)-frac / (1 16) / (1 16)); values++; } -- 1.7.0.4 pushed, thanks. 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
[PATCH font-util] fontutil.m4: Add XORG_FONT_FC_CONFDIR to find fontconfig's confdir
Signed-off-by: Jeremy Huddleston jerem...@apple.com
---
fontutil.m4.in | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/fontutil.m4.in b/fontutil.m4.in
index c867ea6..b9ad59c 100644
--- a/fontutil.m4.in
+++ b/fontutil.m4.in
@@ -256,6 +256,40 @@ AC_DEFUN([XORG_FONT_UCS2ANY],[
+# XORG_FONT_FC_CONFDIR()
+#
+# Minimum version: 1.2.0
+#
+# Sets FC_CONFDIR to the fontconfig config directory
+# (which should be --with-confdir=... when building fontconfig)
+# found from:
+# --with-fc-confdir=...
+# pkg-config --variable=confdir fontconfig
+# ${sysconfdir}/fonts
+
+AC_DEFUN([XORG_FONT_FC_CONFDIR],[
+ dnl Ensure $PKG_CONFIG is set first
+ AC_REQUIRE([PKG_PROG_PKG_CONFIG])
+
+ AC_MSG_CHECKING([for fontconfig's configuration directory])
+ AC_ARG_WITH(fc-confdir,
+ AS_HELP_STRING([--with-fc-confdir=DIR],
+ [Path to fontconfig's configuration directory]),
+ [FC_CONFDIR=$withval])
+ # if --with-fc-confdir was not specified
+ if test x${FC_CONFDIR} = x; then
+ FC_CONFDIR=`$PKG_CONFIG --variable=confdir fontconfig`
+ fi
+ # ...and if pkg-config didn't find confdir in fontconfig.pc...
+ if test x${FC_CONFDIR} = x; then
+ FC_CONFDIR=${sysconfdir}/fonts
+ fi
+ AC_SUBST(FC_CONFDIR)
+ AC_MSG_RESULT([${FC_CONFDIR}])
+])
+
+
+
# XORG_FONTROOTDIR()
#
# Minimum version: 1.1.0
--
1.7.3.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH bh-ttf] Use XORG_FONT_FC_CONFDIR from font-util 1.2 to find fontconfig's confdir
Signed-off-by: Jeremy Huddleston jerem...@apple.com --- Makefile.am |2 +- configure.ac |7 --- 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/Makefile.am b/Makefile.am index 34d9819..f1fc0cc 100644 --- a/Makefile.am +++ b/Makefile.am @@ -36,7 +36,7 @@ FONT_FILES = \ fontdir = @FONTDIR@ font_DATA = $(FONT_FILES) -fontconfigdir = $(sysconfdir)/fonts +fontconfigdir = @FC_CONFDIR@ actualconfigdir = $(fontconfigdir)/conf.d availconfigdir = $(fontconfigdir)/conf.avail dist_availconfig_DATA = 42-luxi-mono.conf diff --git a/configure.ac b/configure.ac index eb883cc..5a69880 100644 --- a/configure.ac +++ b/configure.ac @@ -36,12 +36,13 @@ XORG_DEFAULT_OPTIONS AC_PROG_INSTALL -# Require X.Org's font util macros 1.1 or later +# Require X.Org's font util macros 1.2 or later m4_ifndef([XORG_FONT_MACROS_VERSION], - [m4_fatal([must install X.Org font-util 1.1 or later before running autoconf/autogen])]) -XORG_FONT_MACROS_VERSION(1.1) + [m4_fatal([must install X.Org font-util 1.2 or later before running autoconf/autogen])]) +XORG_FONT_MACROS_VERSION(1.2) XORG_FONTDIR([TTF]) XORG_FONT_SCALED_UTILS +XORG_FONT_FC_CONFDIR AC_OUTPUT([Makefile]) -- 1.7.3.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
