Fix a few typos

Reviewed-by: Francisco Jerez <[email protected]>

17 files changed, 26 insertions, 26 deletions

diff --git a/src/mesa/drivers/dri/i915/i830_state.c b/src/mesa/drivers/dri/i915/i830_state.c
index 13adf560835..ea54e2b25b1 100644
--- a/src/mesa/drivers/dri/i915/i830_state.c
+++ b/src/mesa/drivers/dri/i915/i830_state.c
@@ -219,9 +219,9 @@ i830AlphaFunc(struct gl_context * ctx, GLenum func, GLfloat ref)
 }
 
 /**
- * Makes sure that the proper enables are set for LogicOp, Independant Alpha
+ * Makes sure that the proper enables are set for LogicOp, Independent Alpha
  * Blend, and Blending.  It needs to be called from numerous places where we
- * could change the LogicOp or Independant Alpha Blend without subsequent
+ * could change the LogicOp or Independent Alpha Blend without subsequent
  * calls to glEnable.
  * 
  * \todo
@@ -369,7 +369,7 @@ i830_set_blend_state(struct gl_context * ctx)
    }
 
    /* This will catch a logicop blend equation.  It will also ensure
-    * independant alpha blend is really in the correct state (either enabled
+    * independent alpha blend is really in the correct state (either enabled
     * or disabled) if blending is already enabled.
     */
 
diff --git a/src/mesa/drivers/dri/i915/i915_state.c b/src/mesa/drivers/dri/i915/i915_state.c
index f12bf8af991..5f10b840b1a 100644
--- a/src/mesa/drivers/dri/i915/i915_state.c
+++ b/src/mesa/drivers/dri/i915/i915_state.c
@@ -197,9 +197,9 @@ i915AlphaFunc(struct gl_context * ctx, GLenum func, GLfloat ref)
 }
 
 /* This function makes sure that the proper enables are
- * set for LogicOp, Independant Alpha Blend, and Blending.
+ * set for LogicOp, Independent Alpha Blend, and Blending.
  * It needs to be called from numerous places where we
- * could change the LogicOp or Independant Alpha Blend without subsequent
+ * could change the LogicOp or Independent Alpha Blend without subsequent
  * calls to glEnable.
  */
 static void
diff --git a/src/mesa/drivers/dri/i915/intel_context.h b/src/mesa/drivers/dri/i915/intel_context.h
index 1bbd58fbfd4..350d35d9033 100644
--- a/src/mesa/drivers/dri/i915/intel_context.h
+++ b/src/mesa/drivers/dri/i915/intel_context.h
@@ -248,7 +248,7 @@ struct intel_context
    intel_tri_func draw_tri;
 
    /**
-    * Set if rendering has occured to the drawable's front buffer.
+    * Set if rendering has occurred to the drawable's front buffer.
     *
     * This is used in the DRI2 case to detect that glFlush should also copy
     * the contents of the fake front buffer to the real front buffer.
diff --git a/src/mesa/drivers/dri/i915/intel_tex_layout.c b/src/mesa/drivers/dri/i915/intel_tex_layout.c
index 647a2f8b31f..01ea165c756 100644
--- a/src/mesa/drivers/dri/i915/intel_tex_layout.c
+++ b/src/mesa/drivers/dri/i915/intel_tex_layout.c
@@ -136,7 +136,7 @@ void i945_miptree_layout_2d(struct intel_mipmap_tree *mt)
        mt->total_width = ALIGN(mt->physical_width0, mt->align_w);
    }
 
-   /* May need to adjust width to accomodate the placement of
+   /* May need to adjust width to accommodate the placement of
     * the 2nd mipmap.  This occurs when the alignment
     * constraints of mipmap placement push the right edge of the
     * 2nd mipmap out past the width of its parent.
diff --git a/src/mesa/drivers/dri/i965/brw_clip_unfilled.c b/src/mesa/drivers/dri/i965/brw_clip_unfilled.c
index 8fe1c0afa03..6baf620a1a7 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_unfilled.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_unfilled.c
@@ -135,9 +135,9 @@ static void copy_bfc( struct brw_clip_compile *c )
          brw_clip_have_varying(c, VARYING_SLOT_BFC1)))
       return;
 
-   /* In some wierd degnerate cases we can end up testing the
+   /* In some weird degenerate cases we can end up testing the
     * direction twice, once for culling and once for bfc copying.  Oh
-    * well, that's what you get for setting wierd GL state.
+    * well, that's what you get for setting weird GL state.
     */
    if (c->key.copy_bfc_ccw)
       conditional = BRW_CONDITIONAL_GE;
@@ -278,7 +278,7 @@ static void emit_lines(struct brw_clip_compile *c,
    struct brw_indirect v0ptr = brw_indirect(2, 0);
    struct brw_indirect v1ptr = brw_indirect(3, 0);
 
-   /* Need a seperate loop for offset:
+   /* Need a separate loop for offset:
     */
    if (do_offset) {
       brw_MOV(p, c->reg.loopcount, c->reg.nr_verts);
diff --git a/src/mesa/drivers/dri/i965/brw_clip_util.c b/src/mesa/drivers/dri/i965/brw_clip_util.c
index b7c48014594..40ad14402a7 100644
--- a/src/mesa/drivers/dri/i965/brw_clip_util.c
+++ b/src/mesa/drivers/dri/i965/brw_clip_util.c
@@ -336,10 +336,10 @@ void brw_clip_emit_vue(struct brw_clip_compile *c,
    brw_MOV(p, get_element_ud(c->reg.R0, 2), brw_imm_ud(header));
 
 
-   /* Send each vertex as a seperate write to the urb.  This
+   /* Send each vertex as a separate write to the urb.  This
     * is different to the concept in brw_sf_emit.c, where
     * subsequent writes are used to build up a single urb
-    * entry.  Each of these writes instantiates a seperate
+    * entry.  Each of these writes instantiates a separate
     * urb entry - (I think... what about 'allocate'?)
     */
    brw_urb_WRITE(p,
diff --git a/src/mesa/drivers/dri/i965/brw_context.c b/src/mesa/drivers/dri/i965/brw_context.c
index 9d903609a8b..0f2f9ad7d34 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -599,7 +599,7 @@ brw_initialize_context_constants(struct brw_context *brw)
       ctx->Const.MaxViewports = GEN7_NUM_VIEWPORTS;
       ctx->Const.ViewportSubpixelBits = 0;
 
-      /* Cast to float before negating becuase MaxViewportWidth is unsigned.
+      /* Cast to float before negating because MaxViewportWidth is unsigned.
        */
       ctx->Const.ViewportBounds.Min = -(float)ctx->Const.MaxViewportWidth;
       ctx->Const.ViewportBounds.Max = ctx->Const.MaxViewportWidth;
@@ -974,7 +974,7 @@ intelUnbindContext(__DRIcontext * driContextPriv)
  * sRGB encode if the renderbuffer can handle it.  You can ask specifically
  * for a visual where you're guaranteed to be capable, but it turns out that
  * everyone just makes all their ARGB8888 visuals capable and doesn't offer
- * incapable ones, becuase there's no difference between the two in resources
+ * incapable ones, because there's no difference between the two in resources
  * used.  Applications thus get built that accidentally rely on the default
  * visual choice being sRGB, so we make ours sRGB capable.  Everything sounds
  * great...
diff --git a/src/mesa/drivers/dri/i965/brw_context.h b/src/mesa/drivers/dri/i965/brw_context.h
index d4b7b556de0..8db1028d9fb 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1028,7 +1028,7 @@ struct brw_context
     * Number of resets observed in the system at context creation.
     *
     * This is tracked in the context so that we can determine that another
-    * reset has occured.
+    * reset has occurred.
     */
    uint32_t reset_count;
 
@@ -1041,7 +1041,7 @@ struct brw_context
    } upload;
 
    /**
-    * Set if rendering has occured to the drawable's front buffer.
+    * Set if rendering has occurred to the drawable's front buffer.
     *
     * This is used in the DRI2 case to detect that glFlush should also copy
     * the contents of the fake front buffer to the real front buffer.
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index 26b433bddbd..1ffd332f57e 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -1287,7 +1287,7 @@ get_inner_do_insn(struct brw_codegen *p)
  *
  * When the matching 'else' instruction is reached (presumably by
  * countdown of the instruction count patched in by our ELSE/ENDIF
- * functions), the relevent flags are inverted.
+ * functions), the relevant flags are inverted.
  *
  * When the matching 'endif' instruction is reached, the flags are
  * popped off.  If the stack is now empty, normal execution resumes.
@@ -1559,7 +1559,7 @@ brw_ENDIF(struct brw_codegen *p)
       emit_endif = false;
 
    /*
-    * A single next_insn() may change the base adress of instruction store
+    * A single next_insn() may change the base address of instruction store
     * memory(p->store), so call it first before referencing the instruction
     * store pointer from an index
     */
diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c b/src/mesa/drivers/dri/i965/brw_tex_layout.c
index d1ac3ed53b1..274040b1c3e 100644
--- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
+++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
@@ -205,7 +205,7 @@ brw_miptree_layout_2d(struct intel_mipmap_tree *mt)
        mt->total_width = ALIGN(mt->physical_width0, mt->align_w);
    }
 
-   /* May need to adjust width to accomodate the placement of
+   /* May need to adjust width to accommodate the placement of
     * the 2nd mipmap.  This occurs when the alignment
     * constraints of mipmap placement push the right edge of the
     * 2nd mipmap out past the width of its parent.
diff --git a/src/mesa/drivers/dri/i965/brw_wm_state.c b/src/mesa/drivers/dri/i965/brw_wm_state.c
index 28a4aa43d83..0cd439046b3 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_state.c
@@ -210,7 +210,7 @@ brw_upload_wm_unit(struct brw_context *brw)
    /* _NEW_POLYGON */
    if (ctx->Polygon.OffsetFill) {
       wm->wm5.depth_offset = 1;
-      /* Something wierd going on with legacy_global_depth_bias,
+      /* Something weird going on with legacy_global_depth_bias,
        * offset_constant, scaling and MRD.  This value passes glean
        * but gives some odd results elsewere (eg. the
        * quad-offset-units test).
diff --git a/src/mesa/drivers/dri/i965/gen7_sol_state.c b/src/mesa/drivers/dri/i965/gen7_sol_state.c
index 3f99df9dd91..aec4f44bb73 100644
--- a/src/mesa/drivers/dri/i965/gen7_sol_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_sol_state.c
@@ -164,7 +164,7 @@ gen7_upload_3dstate_so_decl_list(struct brw_context *brw,
        * for fake "hole" components, rather than simply taking the offset
        * for each real varying.  Each hole can have size 1, 2, 3, or 4; we
        * program as many size = 4 holes as we can, then a final hole to
-       * accomodate the final 1, 2, or 3 remaining.
+       * accommodate the final 1, 2, or 3 remaining.
        */
       int skip_components =
          linked_xfb_info->Outputs[i].DstOffset - next_offset[buffer];
diff --git a/src/mesa/drivers/dri/r200/r200_ioctl.h b/src/mesa/drivers/dri/r200/r200_ioctl.h
index 4c1f1ac698e..25a9dd37682 100644
--- a/src/mesa/drivers/dri/r200/r200_ioctl.h
+++ b/src/mesa/drivers/dri/r200/r200_ioctl.h
@@ -78,7 +78,7 @@ do {						\
       rmesa->radeon.dma.flush( &rmesa->radeon.glCtx );	\
 } while (0)
 
-/* Can accomodate several state changes and primitive changes without
+/* Can accommodate several state changes and primitive changes without
  * actually firing the buffer.
  */
 #define R200_STATECHANGE( rmesa, ATOM )			\
diff --git a/src/mesa/drivers/dri/r200/r200_texstate.c b/src/mesa/drivers/dri/r200/r200_texstate.c
index cc13ccb4d65..ab84d1752ba 100644
--- a/src/mesa/drivers/dri/r200/r200_texstate.c
+++ b/src/mesa/drivers/dri/r200/r200_texstate.c
@@ -1453,7 +1453,7 @@ static void setup_hardware_state(r200ContextPtr rmesa, radeonTexObj *t)
        */
       t->pp_txformat_x |= R200_TEXCOORD_PROJ;
    }
-   /* FIXME: NPOT sizes, Is it correct realy? */
+   /* FIXME: NPOT sizes, is it correct really? */
    t->pp_txsize = (((firstImage->Width - 1) << R200_PP_TX_WIDTHMASK_SHIFT)
 		   | ((firstImage->Height - 1) << R200_PP_TX_HEIGHTMASK_SHIFT));
 
diff --git a/src/mesa/drivers/dri/radeon/radeon_common_context.h b/src/mesa/drivers/dri/radeon/radeon_common_context.h
index 8a1c61ad80b..dc72592b90c 100644
--- a/src/mesa/drivers/dri/radeon/radeon_common_context.h
+++ b/src/mesa/drivers/dri/radeon/radeon_common_context.h
@@ -433,7 +433,7 @@ struct radeon_context {
   GLboolean front_cliprects;
 
    /**
-    * Set if rendering has occured to the drawable's front buffer.
+    * Set if rendering has occurred to the drawable's front buffer.
     *
     * This is used in the DRI2 case to detect that glFlush should also copy
     * the contents of the fake front buffer to the real front buffer.
diff --git a/src/mesa/drivers/dri/radeon/radeon_ioctl.h b/src/mesa/drivers/dri/radeon/radeon_ioctl.h
index 4d24e5f6a26..2fe0e5756a5 100644
--- a/src/mesa/drivers/dri/radeon/radeon_ioctl.h
+++ b/src/mesa/drivers/dri/radeon/radeon_ioctl.h
@@ -95,7 +95,7 @@ do {						\
       rmesa->radeon.dma.flush( &rmesa->radeon.glCtx );	\
 } while (0)
 
-/* Can accomodate several state changes and primitive changes without
+/* Can accommodate several state changes and primitive changes without
  * actually firing the buffer.
  */
 
diff --git a/src/mesa/drivers/x11/xm_api.c b/src/mesa/drivers/x11/xm_api.c
index 681b81ac762..65e7ca89d32 100644
--- a/src/mesa/drivers/x11/xm_api.c
+++ b/src/mesa/drivers/x11/xm_api.c
@@ -196,7 +196,7 @@ bits_per_pixel( XMesaVisual xmv )
  * Do this by calling XGetWindowAttributes() for the window and
  * checking if we catch an X error.
  * Input:  dpy - the display
- *         win - the window to check for existance
+ *         win - the window to check for existence
  * Return:  GL_TRUE - window exists
  *          GL_FALSE - window doesn't exist
  */