[PATCH xf86-video-cirrus] Save and restore RIF Control and RAC Control registers
While the standby resume from ACPI S3 State still fails (i.e., hard
system freeze), saving and restoring Rambus RIF (Rambus Interface)
Control and RAC (Rambus ASIC Cell) Control registers prevents weird
artifacts from being displayed after standby resume (i.e., merely a
blank screen after standby resume).
Signed-off-by: Kevin Brace
---
src/lg.h| 1 +
src/lg_driver.c | 9 +
2 files changed, 10 insertions(+)
diff --git a/src/lg.h b/src/lg.h
index 3f5dcdf..42add0c 100644
--- a/src/lg.h
+++ b/src/lg.h
@@ -44,6 +44,7 @@ typedef struct {
/* Laguna regs */
CARD8 TILE, BCLK;
CARD16 FORMAT, DTTC, TileCtrl, CONTROL;
+ CARD16 RIFCtrl, RACCtrl;
CARD32 VSC;
} LgRegRec, *LgRegPtr;
diff --git a/src/lg_driver.c b/src/lg_driver.c
index 3af8432..f6d721a 100644
--- a/src/lg_driver.c
+++ b/src/lg_driver.c
@@ -1081,6 +1081,12 @@ LgSave(ScrnInfoPtr pScrn)
pCir->chip.lg->ModeReg.CONTROL =
pCir->chip.lg->SavedReg.CONTROL = memrw(0x402);
+
+pCir->chip.lg->ModeReg.RIFCtrl =
+pCir->chip.lg->SavedReg.RIFCtrl = memrw(0x200);
+
+pCir->chip.lg->ModeReg.RACCtrl =
+pCir->chip.lg->SavedReg.RACCtrl = memrw(0x202);
}
/*
@@ -1549,6 +1555,9 @@ LgRestoreLgRegs(ScrnInfoPtr pScrn, LgRegPtr lgReg)
memwb(0x8C, lgReg->BCLK);
memww(0x402, lgReg->CONTROL);
+
+memww(0x200, lgReg->RIFCtrl);
+memww(0x202, lgReg->RACCtrl);
}
/*
--
2.17.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xf86-video-cirrus] Stop accessing SR12 and SR13
The access to these extended VGA sequencer registers appears to come
from the code for Cirrus Logic Alpine family. Laguna family does not
use these registers according to Laguna VisualMedia Accelerators Family
CL-GD546X Software Technical Reference Manual, Second Edition.
Signed-off-by: Kevin Brace
---
src/lg.h| 2 --
src/lg_driver.c | 6 --
2 files changed, 8 deletions(-)
diff --git a/src/lg.h b/src/lg.h
index fa716d6..3f5dcdf 100644
--- a/src/lg.h
+++ b/src/lg.h
@@ -31,8 +31,6 @@ enum {
/* SR regs */
SR07,
SR0E,
- SR12,
- SR13,
SR1E,
/* Must be last! */
LG_LAST_REG
diff --git a/src/lg_driver.c b/src/lg_driver.c
index 95886b0..3af8432 100644
--- a/src/lg_driver.c
+++ b/src/lg_driver.c
@@ -1052,10 +1052,6 @@ LgSave(ScrnInfoPtr pScrn)
pCir->chip.lg->SavedReg.ExtVga[SR07] = hwp->readSeq(hwp, 0x07);
pCir->chip.lg->ModeReg.ExtVga[SR0E] =
pCir->chip.lg->SavedReg.ExtVga[SR0E] = hwp->readSeq(hwp, 0x0E);
-pCir->chip.lg->ModeReg.ExtVga[SR12] =
-pCir->chip.lg->SavedReg.ExtVga[SR12] = hwp->readSeq(hwp, 0x12);
-pCir->chip.lg->ModeReg.ExtVga[SR13] =
-pCir->chip.lg->SavedReg.ExtVga[SR13] = hwp->readSeq(hwp, 0x13);
pCir->chip.lg->ModeReg.ExtVga[SR1E] =
pCir->chip.lg->SavedReg.ExtVga[SR1E] = hwp->readSeq(hwp, 0x1E);
@@ -1530,8 +1526,6 @@ LgRestoreLgRegs(ScrnInfoPtr pScrn, LgRegPtr lgReg)
hwp->writeSeq(hwp, 0x07, lgReg->ExtVga[SR07]);
hwp->writeSeq(hwp, 0x0E, lgReg->ExtVga[SR0E]);
-hwp->writeSeq(hwp, 0x12, lgReg->ExtVga[SR12]);
-hwp->writeSeq(hwp, 0x13, lgReg->ExtVga[SR13]);
hwp->writeSeq(hwp, 0x1E, lgReg->ExtVga[SR1E]);
memww(0xC0, lgReg->FORMAT);
--
2.17.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Fonts: Pango Drops Bitmap Support.
On 7/30/19 10:32 AM, Adam Jackson wrote: > On Mon, 2019-07-29 at 14:36 +0100, Ralph Corderoy wrote: > >> Is there any chance X.org can ship their super collection of fonts as >> OpenType bitmaps as well? I understand it's a mechanical conversion. >> That would allow distro packagers to make them readily available to >> users alongside the existing BDFs, etc., so they can continue to use >> their decade-old favourites. > > Do you have a link to a recipe for such mechanical conversion? I think > we would still preserve the BDF as the "source" format but I'd > certainly be happy to install them as something other than PCF. (For > that matter I might like to ship my OS without PCF support in the > renderer at all.) Isn't that what we wrote fnttosfnt for years ago and then never finished the plan to actually use it? https://keithp.com/blogs/fonttosfnt/ https://gitlab.freedesktop.org/xorg/app/fonttosfnt -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: Fonts: Pango Drops Bitmap Support.
On Mon, 2019-07-29 at 14:36 +0100, Ralph Corderoy wrote: > Is there any chance X.org can ship their super collection of fonts as > OpenType bitmaps as well? I understand it's a mechanical conversion. > That would allow distro packagers to make them readily available to > users alongside the existing BDFs, etc., so they can continue to use > their decade-old favourites. Do you have a link to a recipe for such mechanical conversion? I think we would still preserve the BDF as the "source" format but I'd certainly be happy to install them as something other than PCF. (For that matter I might like to ship my OS without PCF support in the renderer at all.) - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Fonts: Pango Drops Bitmap Support.
Hi, Pango has just dropped its support for bitmap fonts. As it uses Harfbuzz, it can still use Harfbuzz's support for OpenType's bitmap format. https://fontforge.github.io/bitmaponlysfnt.html#X11 This Pango change has caused some grief, e.g. terminal emulators displaying boxes instead of the user's font, gimp unable to paint bitmap fonts, etc. https://gitlab.gnome.org/GNOME/pango/issues/386 Is there any chance X.org can ship their super collection of fonts as OpenType bitmaps as well? I understand it's a mechanical conversion. That would allow distro packagers to make them readily available to users alongside the existing BDFs, etc., so they can continue to use their decade-old favourites. Fonts aren't my speciality, nor Pango, so apologies if I've grasped the stick wrong. Pango 1.44 is when this change will hit most users. As I run Arch Linux, I've already met it! -- Cheers, Ralph. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
