XLibre/xf86-video-chips
1
0
Fork 0
mirror of https://github.com/X11Libre/xf86-video-chips.git synced 2026-03-24 01:24:44 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix spelling/wording issues

Browse Source 
Found by using:
    codespell --builtin clear,rare,usage,informal,code,names

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
This commit is contained in:
Alan Coopersmith
2022-01-22 09:42:47 -08:00
parent dd4337729a
commit 7f216da92e
6 changed files with 19 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
README
View File

@@ -436,13 +436,13 @@
the ct65555 and only when used with a DSTN LCD. the ct65555 and only when used with a DSTN LCD.
Option The HiQV chipsets contain a multimedia engine 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 screen. This driver uses this capability to
include a 16bpp framebuffer on top of an 8bpp include a 16bpp framebuffer on top of an 8bpp
framebuffer. In this way PseudoColor and framebuffer. In this way PseudoColor and
TrueColor visuals can be used on the same screen. TrueColor visuals can be used on the same screen.
XFree86 believes that the 8bpp framebuffer is 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 use this option the server must be started in
either 15 or 16bpp depth. Also the maximum size either 15 or 16bpp depth. Also the maximum size
of the desktop with this option is 1024x1024, as 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 the server attempts to read the panel size from the chip. If the
user has used the "UseModeline" or "FixPanelSize" options the user has used the "UseModeline" or "FixPanelSize" options the
panel timings are derived from the mode, which can be different 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. or using an LCD/CRT switch.
I can't get a 320x240 mode to occupy the whole 640x480 LCD I can't get a 320x240 mode to occupy the whole 640x480 LCD

4
src/ct_Blitter.h
View File

@@ -11,9 +11,9 @@
/* 15-12 reserved (0) */ /* 15-12 reserved (0) */
/* 27-16 destination offset, width of screen */ /* 27-16 destination offset, width of screen */
/* 31-28 reserved (0) */ /* 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) */ /* 31-21 reserved (0) */
/* 8BD0: 15-0 backgroud colour */ /* 8BD0: 15-0 background colour */
/* 31-6 duplicate of 15-0 */ /* 31-6 duplicate of 15-0 */
/* 8FD0: 15-0 foregroud/solid colour */ /* 8FD0: 15-0 foregroud/solid colour */
/* 31-6 duplicate of 15-0 */ /* 31-6 duplicate of 15-0 */

2
src/ct_BltHiQV.h
View File

@@ -55,7 +55,7 @@
/* For some odd reason the blitter busy bit occasionly "locks up" when /* For some odd reason the blitter busy bit occasionly "locks up" when
* it gets polled to fast. However I have observed this behavior only * it gets polled to fast. However I have observed this behavior only
* when doing ScreenToScreenColorExpandFill on a 65550. This operation * 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. * no action was taken.
* *
* This function uses indirect access to XR20 to test whether the blitter * This function uses indirect access to XR20 to test whether the blitter

2
src/ct_accel.c
View File

@@ -29,7 +29,7 @@
* When monochrome tiles/stipples are cached on the HiQV chipsets the * When monochrome tiles/stipples are cached on the HiQV chipsets the
* pitch of the monochrome data is the displayWidth. The HiQV manuals * pitch of the monochrome data is the displayWidth. The HiQV manuals
* state that the source pitch is ignored with monochrome data, and so * 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 * it appears that by not setting the monochrome source alignment in
* BR03, the monochrome source pitch is forced to the displayWidth!! * BR03, the monochrome source pitch is forced to the displayWidth!!
* *

22
src/ct_driver.c
View File

@@ -842,7 +842,7 @@ CHIPSPciProbe(DriverPtr drv, int entity_num, struct pci_device * dev,
cPtr->Chipset = match_data; cPtr->Chipset = match_data;
/* /*
* For cards that can do dual head per entity, mark the entity * For cards that can do dual head per entity, mark the entity
* as sharable. * as shareable.
*/ */
if (match_data == CHIPS_CT69030) { if (match_data == CHIPS_CT69030) {
CHIPSEntPtr cPtrEnt = NULL; CHIPSEntPtr cPtrEnt = NULL;
@@ -924,7 +924,7 @@ CHIPSProbe(DriverPtr drv, int flags)
/* /*
* For cards that can do dual head per entity, mark the entity * For cards that can do dual head per entity, mark the entity
* as sharable. * as shareable.
*/ */
pEnt = xf86GetEntityInfo(usedChips[i]); pEnt = xf86GetEntityInfo(usedChips[i]);
if (pEnt->chipset == CHIPS_CT69030) { 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 * 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)) { if (xf86GetOptValInteger(cPtr->Options, OPTION_CRT_CLK_INDX, &indx)) {
xf86DrvMsg(pScrn->scrnIndex, X_CONFIG, "Force CRT Clock index to %d\n", 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 * Normally the alternalte registers are set by the BIOS to optimized
* values. * values.
* While the horizontal an vertical refresh rates are fixed independent * 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 * displays they can be adapted to the screen resolution and CRT
* requirements in CRT mode by programming the standard timing registers * requirements in CRT mode by programming the standard timing registers
* in the VGA fashion. * in the VGA fashion.
@@ -5324,7 +5324,7 @@ chipsModeInit(ScrnInfoPtr pScrn, DisplayModePtr mode)
* by the _alternate_ horizontal and vertical display size registers. * by the _alternate_ horizontal and vertical display size registers.
* The size of the visible should always be equal or less than the * The size of the visible should always be equal or less than the
* physical size. * 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. * and so can be driven independently.
*/ */
static Bool static Bool
@@ -5857,7 +5857,7 @@ chipsModeInitWingine(ScrnInfoPtr pScrn, DisplayModePtr mode)
/* /*
* This chipset seems to have problems if * This chipset seems to have problems if
* HBlankEnd is choosen equals HTotal * HBlankEnd is chosen equals HTotal
*/ */
if (!mode->CrtcHAdjusted) if (!mode->CrtcHAdjusted)
mode->CrtcHBlankEnd = min(mode->CrtcHSyncEnd, mode->CrtcHTotal - 2); mode->CrtcHBlankEnd = min(mode->CrtcHSyncEnd, mode->CrtcHTotal - 2);
@@ -6093,7 +6093,7 @@ chipsModeInit655xx(ScrnInfoPtr pScrn, DisplayModePtr mode)
/* /*
* This chipset seems to have problems if * This chipset seems to have problems if
* HBlankEnd is choosen equals HTotal * HBlankEnd is chosen equals HTotal
*/ */
if (!mode->CrtcHAdjusted) if (!mode->CrtcHAdjusted)
mode->CrtcHBlankEnd = min(mode->CrtcHSyncEnd, mode->CrtcHTotal - 2); 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 * still needed, and I'd love to get rid of it as its ugly
*/ */
switch (cPtr->Chipset) { switch (cPtr->Chipset) {
@@ -6599,7 +6599,7 @@ chipsRestore(ScrnInfoPtr pScrn, vgaRegPtr VgaReg, CHIPSRegPtr ChipsReg,
/* set extended regs */ /* set extended regs */
chipsRestoreExtendedRegs(pScrn, ChipsReg); chipsRestoreExtendedRegs(pScrn, ChipsReg);
#if 0 #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 */ /* set CRTC registers - do it before sequencer restarts */
for (i=0; i<25; i++) for (i=0; i<25; i++)
hwp->writeCrtc(hwp, i, VgaReg->CRTC[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], chipsRestoreStretching(pScrn, (unsigned char)ChipsReg->FR[0x40],
(unsigned char)ChipsReg->FR[0x48]); (unsigned char)ChipsReg->FR[0x48]);
#if 0 #if 0
/* if people report about stretching not working -- reenable */ /* if people report about stretching not working -- re-enable */
/* why twice ? : /* why twice ? :
* sometimes the console is not well restored even if these registers * sometimes the console is not well restored even if these registers
* are good, re-write the registers works around it * are good, re-write the registers works around it
@@ -6640,7 +6640,7 @@ chipsRestore(ScrnInfoPtr pScrn, vgaRegPtr VgaReg, CHIPSRegPtr ChipsReg,
/* perform a synchronous reset */ /* perform a synchronous reset */
if (!cPtr->SyncResetIgn) { if (!cPtr->SyncResetIgn) {
if (!IS_HiQV(cPtr)) { if (!IS_HiQV(cPtr)) {
/* enable syncronous reset on 655xx */ /* enable synchronous reset on 655xx */
tmp = cPtr->readXR(cPtr, 0x0E); tmp = cPtr->readXR(cPtr, 0x0E);
cPtr->writeXR(cPtr, 0x0E, tmp & 0x7F); cPtr->writeXR(cPtr, 0x0E, tmp & 0x7F);
} }

2
util/modClock.c
View File

@@ -68,7 +68,7 @@ int compute_clock (
return 1; 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 not documented in the Clock Synthesizer doc in rev 1.0 of the
65548 datasheet: 65548 datasheet: