diff options
| -rw-r--r-- | README | 6 | ||||
| -rw-r--r-- | src/ct_Blitter.h | 4 | ||||
| -rw-r--r-- | src/ct_BltHiQV.h | 2 | ||||
| -rw-r--r-- | src/ct_accel.c | 2 | ||||
| -rw-r--r-- | src/ct_driver.c | 22 | ||||
| -rw-r--r-- | util/modClock.c | 2 |
6 files changed, 19 insertions, 19 deletions
@@ -436,13 +436,13 @@ the ct65555 and only when used with a DSTN LCD. Option The HiQV chipsets contain a multimedia engine - that allow a 16bpp window to be overlayed on the + that allow a 16bpp window to be overlaid on the screen. This driver uses this capability to include a 16bpp framebuffer on top of an 8bpp framebuffer. In this way PseudoColor and TrueColor visuals can be used on the same screen. XFree86 believes that the 8bpp framebuffer is - overlayed on the 16bpp framebuffer. Therefore to + overlaid on the 16bpp framebuffer. Therefore to use this option the server must be started in either 15 or 16bpp depth. Also the maximum size of the desktop with this option is 1024x1024, as @@ -992,7 +992,7 @@ the server attempts to read the panel size from the chip. If the user has used the "UseModeline" or "FixPanelSize" options the panel timings are derived from the mode, which can be different - than the panel size. Try deleting theses options from xorg.conf + than the panel size. Try deleting these options from xorg.conf or using an LCD/CRT switch. I can't get a 320x240 mode to occupy the whole 640x480 LCD diff --git a/src/ct_Blitter.h b/src/ct_Blitter.h index 6791ca9..3de88ed 100644 --- a/src/ct_Blitter.h +++ b/src/ct_Blitter.h @@ -11,9 +11,9 @@ /* 15-12 reserved (0) */ /* 27-16 destination offset, width of screen */ /* 31-28 reserved (0) */ -/* 87D0: 20-0 pattern (alinged 8 pixel x 8 line) pointer */ +/* 87D0: 20-0 pattern (aligned 8 pixel x 8 line) pointer */ /* 31-21 reserved (0) */ -/* 8BD0: 15-0 backgroud colour */ +/* 8BD0: 15-0 background colour */ /* 31-6 duplicate of 15-0 */ /* 8FD0: 15-0 foregroud/solid colour */ /* 31-6 duplicate of 15-0 */ diff --git a/src/ct_BltHiQV.h b/src/ct_BltHiQV.h index ada946e..2180db3 100644 --- a/src/ct_BltHiQV.h +++ b/src/ct_BltHiQV.h @@ -55,7 +55,7 @@ /* For some odd reason the blitter busy bit occasionly "locks up" when * it gets polled to fast. However I have observed this behavior only * when doing ScreenToScreenColorExpandFill on a 65550. This operation - * was broken anyway (the source offest register is not observed) therefore + * was broken anyway (the source offset register is not observed) therefore * no action was taken. * * This function uses indirect access to XR20 to test whether the blitter diff --git a/src/ct_accel.c b/src/ct_accel.c index 8ec3347..d891e26 100644 --- a/src/ct_accel.c +++ b/src/ct_accel.c @@ -29,7 +29,7 @@ * When monochrome tiles/stipples are cached on the HiQV chipsets the * pitch of the monochrome data is the displayWidth. The HiQV manuals * state that the source pitch is ignored with monochrome data, and so - * "offically" there the XAA cached monochrome data can't be used. But + * "officially" there the XAA cached monochrome data can't be used. But * it appears that by not setting the monochrome source alignment in * BR03, the monochrome source pitch is forced to the displayWidth!! * diff --git a/src/ct_driver.c b/src/ct_driver.c index b4b8422..8efcf77 100644 --- a/src/ct_driver.c +++ b/src/ct_driver.c @@ -842,7 +842,7 @@ CHIPSPciProbe(DriverPtr drv, int entity_num, struct pci_device * dev, cPtr->Chipset = match_data; /* * For cards that can do dual head per entity, mark the entity - * as sharable. + * as shareable. */ if (match_data == CHIPS_CT69030) { CHIPSEntPtr cPtrEnt = NULL; @@ -924,7 +924,7 @@ CHIPSProbe(DriverPtr drv, int flags) /* * For cards that can do dual head per entity, mark the entity - * as sharable. + * as shareable. */ pEnt = xf86GetEntityInfo(usedChips[i]); if (pEnt->chipset == CHIPS_CT69030) { @@ -2171,7 +2171,7 @@ chipsPreInitHiQV(ScrnInfoPtr pScrn, int flags) /* * Some chips seem to dislike some clocks in one of the PLL's. Give - * the user the oppurtunity to change it + * the user the opportunity to change it */ if (xf86GetOptValInteger(cPtr->Options, OPTION_CRT_CLK_INDX, &indx)) { xf86DrvMsg(pScrn->scrnIndex, X_CONFIG, "Force CRT Clock index to %d\n", @@ -5314,7 +5314,7 @@ chipsModeInit(ScrnInfoPtr pScrn, DisplayModePtr mode) * Normally the alternalte registers are set by the BIOS to optimized * values. * While the horizontal an vertical refresh rates are fixed independent - * of the visible display size to ensure optimal performace of both + * of the visible display size to ensure optimal performance of both * displays they can be adapted to the screen resolution and CRT * requirements in CRT mode by programming the standard timing registers * in the VGA fashion. @@ -5324,7 +5324,7 @@ chipsModeInit(ScrnInfoPtr pScrn, DisplayModePtr mode) * by the _alternate_ horizontal and vertical display size registers. * The size of the visible should always be equal or less than the * physical size. - * For the 69030 chipsets, the CRT and LCD display channels are seperate + * For the 69030 chipsets, the CRT and LCD display channels are separate * and so can be driven independently. */ static Bool @@ -5857,7 +5857,7 @@ chipsModeInitWingine(ScrnInfoPtr pScrn, DisplayModePtr mode) /* * This chipset seems to have problems if - * HBlankEnd is choosen equals HTotal + * HBlankEnd is chosen equals HTotal */ if (!mode->CrtcHAdjusted) mode->CrtcHBlankEnd = min(mode->CrtcHSyncEnd, mode->CrtcHTotal - 2); @@ -6093,7 +6093,7 @@ chipsModeInit655xx(ScrnInfoPtr pScrn, DisplayModePtr mode) /* * This chipset seems to have problems if - * HBlankEnd is choosen equals HTotal + * HBlankEnd is chosen equals HTotal */ if (!mode->CrtcHAdjusted) mode->CrtcHBlankEnd = min(mode->CrtcHSyncEnd, mode->CrtcHTotal - 2); @@ -6525,7 +6525,7 @@ chipsModeInit655xx(ScrnInfoPtr pScrn, DisplayModePtr mode) } } - /* This stuff was emprically derived several years ago. Not sure its + /* This stuff was empirically derived several years ago. Not sure its * still needed, and I'd love to get rid of it as its ugly */ switch (cPtr->Chipset) { @@ -6599,7 +6599,7 @@ chipsRestore(ScrnInfoPtr pScrn, vgaRegPtr VgaReg, CHIPSRegPtr ChipsReg, /* set extended regs */ chipsRestoreExtendedRegs(pScrn, ChipsReg); #if 0 - /* if people complain about lock ups or blank screens -- reenable */ + /* if people complain about lock ups or blank screens -- re-enable */ /* set CRTC registers - do it before sequencer restarts */ for (i=0; i<25; i++) hwp->writeCrtc(hwp, i, VgaReg->CRTC[i]); @@ -6625,7 +6625,7 @@ chipsRestore(ScrnInfoPtr pScrn, vgaRegPtr VgaReg, CHIPSRegPtr ChipsReg, chipsRestoreStretching(pScrn, (unsigned char)ChipsReg->FR[0x40], (unsigned char)ChipsReg->FR[0x48]); #if 0 - /* if people report about stretching not working -- reenable */ + /* if people report about stretching not working -- re-enable */ /* why twice ? : * sometimes the console is not well restored even if these registers * are good, re-write the registers works around it @@ -6640,7 +6640,7 @@ chipsRestore(ScrnInfoPtr pScrn, vgaRegPtr VgaReg, CHIPSRegPtr ChipsReg, /* perform a synchronous reset */ if (!cPtr->SyncResetIgn) { if (!IS_HiQV(cPtr)) { - /* enable syncronous reset on 655xx */ + /* enable synchronous reset on 655xx */ tmp = cPtr->readXR(cPtr, 0x0E); cPtr->writeXR(cPtr, 0x0E, tmp & 0x7F); } diff --git a/util/modClock.c b/util/modClock.c index 9f9ad9d..20edbbd 100644 --- a/util/modClock.c +++ b/util/modClock.c @@ -68,7 +68,7 @@ int compute_clock ( return 1; } - /* Other parameters available onthe 65548 but not the 65545, and + /* Other parameters available on the 65548 but not the 65545, and not documented in the Clock Synthesizer doc in rev 1.0 of the 65548 datasheet: |