Bug#522747: xserver-xorg-video-s3: X failed after upgrading stable to testing
Julien Cristau writes: > Does the package at http://people.debian.org/~jcristau/522747/ work > better? > > Its sha1sum is 95b0beda410bb0508d3079fcb161776f5ca67c0c. This works. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obeeuo0q@tochka.ru
Bug#522747: xserver-xorg-video-s3: X failed after upgrading stable to testing
I've upraded to Wheezy. The bug is reproducible. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sj3quo1e@tochka.ru
Bug#522747: xserver-xorg-video-s3: X failed after upgrading stable to testing
I will try to reproduce this issue. I just need to upgrade to Wheezy. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87boaewd6b@tochka.ru
Bug#620813: xserver-xorg-video-s3: laptop display distorted after resume from sleep
Cyril Brulebois writes: > why are you submitting this bug against the s3 driver? You seem to be > running the radeon driver Perhaps the original poster meant ACPI S3 mode and decided to put bug here. Need to reassign either to radeon or to kernel. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lizpqeok@tochka.ru
Bug#568524: xserver-xorg-video-s3: on S3 86c764/765 [Trio32/64/64V+] screen stays blank in power saving mode
John Talbut writes: > Package: xserver-xorg-video-s3 > Version: 1:0.6.0-1 > Severity: important > > As soon as X is started the screen switches to power saving mode, the > same when running gdm or xorg. If I use the vesa driver this does not > happen (but it is slow). > This happened after installing Lenney, it worked all right with etch. > I wonder if this is a regression since a similar bug was apparantly > solved in Ubuntu: > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-s3/+bug/33504 > . There seems to be a similar bug outstanding upstream: > https://bugs.freedesktop.org/show_bug.cgi?id=16859 This is not a regression. By default your X server tries depth 24. This is from your log: > (--) Depth 24 pixmap format is 32 bpp I've added the 24-bit colour depth support to s3 driver starting version 0.6.1. For 0.6.0 version you need to set the DefaultDepth to 16 (man xorg.conf) in "Screen" section of xorg.conf. Please, try this and report the results. As an option, you can backport the driver from testing. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#374059: xserver-xorg-video-s3: missing man page: /usr/share/man/man4/s3.4.gz
I've written and committed to the upstream the manual page for S3. Should I rework it for Lenny and prepare patch? Is the man page the subject for proposed updates? I'm asking because the changes can be slightly complicated for proposed updates as it's needed to change configure.ac and /debian files, add /man/Makefile.am and the manual. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#470408: xserver-xorg-video-s3: Screen corrupted for Virtual PC 2007, in 24bit mode
Franklin Piat writes: > The screen looks too wide and corrupted, when ran in 24 bits mode. I close this bug in upstream. The problem was partially solved in 0.6.1 version (available in Debian) and finally solved in upstream by fixing interlaced mode which is needed to set up 1024x768 resolution in 32 bpp framebuffer / 24-bit colour mode. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522747: xserver-xorg-video-s3: Caught signal 11. Server aborting
Shaddy Baddah writes: > (II) Bus 1: bridge is at (0:1:1), (0,1,1), BCTRL: 0x0023 (VGA_EN is cleared) > (--) PCI:*(1:2:0) ATI Technologies Inc 3D Rage Pro 215GP rev 92, Mem @ > 0xe100/24, 0xe200/12, BIOS @ 0xe102/0 > (--) PCI: (2:1:0) S3 Inc. 86c764/765 [Trio32/64/64V+] rev 84, Mem @ > 0x0400/26, BIOS @ 0x0800/16 > (--) PCI: (2:3:0) Matrox Graphics, Inc. MGA 2064W [Millennium] rev 1, > Mem @ 0x0801/14, 0x0880/23, BIOS @ 0x0900/16 Please, try S3 without inserted ATI and Matrox to eliminate any potentially possible hardware conflict. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#476876: [PATCH] S3 Trio64 on Alpha
Brice Goglin <[EMAIL PROTECTED]> writes: > Evgeni, From what I see, you've been involved with upstream s3 > recently. So, does this patch matter for s3 0.6 as well ? do you plan > to apply it upstream? This patch is intended only for 0.4.0 version and can not be applied to 0.6.0 as there was some rearrangings in this place after 0.4.0. I will apply this patch along with other changes into upstream in near future. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476876: [PATCH] S3 Trio64 on Alpha
> I can put the S3 back in and get the lspci output for you, but it will
> be a few days before I can do so. The card itself and the bus it goes
> into is working, as OpenVMS on the same system does correctly
> initialize and use the display with the S3 card in place.
I've searched in Google the similar bug reports and found that there was
the problems with Trio64 on Alphas. More frequent advice to reporters
was to enable "no_pci_disconnect" driver's option (you can type
"no_pci_disconnect" in Google and read these bug reports). But this
option was removed long time ago.
There is register in S3 Trio64 which disables PCI Disconnect. Also there
is register which disables or enables PCI Read Burst. I've wrote the
patch for s3 driver from Etch (0.4.1-5) which adds two new options:
Option "pci_burst" and Option "no_pci_disconnect". You can try all the
four combinations of these options. By default "(if ommited) pci_burst"
is "on" (PCI Read Burst is enabled) and "no_pci_disconnect" is "off"
(PCI Disconnect is enabled). In original driver from Etch PCI Read Burst
is disabled and PCI Disconnect is enabled.
If you are still interested and will have some time in future, you will
be able to patch source from Debian (apt-get source
xserver-xorg-video-s3) and recompile driver.
Notes:
1. Sometimes Trio64 can hangs your system when switching between
graphical mode and console (even on start). This is due to enabling
graphic mode without waiting vertical sync. This bug was corrected only
in upstream but not in Etch. So if you get this problem, you need to try
again.
2. Don't make the missprints in option names. (no_pci_disconnect,
pci_burst). An example:
Option "pci_burst" "off"
Option "no_pci_disconnect"
Patch is attached. I've verified patch by dumping S3 registers after
initialization -- the new options are working correctly.
diff -u xserver-xorg-video-s3-0.4.1/src/s3_driver.c xserver-xorg-video-s3/src/s3_driver.c
--- xserver-xorg-video-s3-0.4.1/src/s3_driver.c 2006-04-04 16:06:58.0 +0400
+++ xserver-xorg-video-s3/src/s3_driver.c 2008-08-07 22:02:21.0 +0400
@@ -157,7 +157,9 @@
OPTION_SLOW_DRAM_REFRESH,
OPTION_SLOW_DRAM,
OPTION_SLOW_EDODRAM,
- OPTION_SLOW_VRAM
+ OPTION_SLOW_VRAM,
+ OPTION_PCI_BURST,
+ OPTION_NO_PCI_DISC
} S3Opts;
static OptionInfoRec S3Options[] = {
@@ -167,6 +169,8 @@
{ OPTION_SLOW_DRAM, "slow_dram", OPTV_BOOLEAN, {0}, FALSE },
{ OPTION_SLOW_EDODRAM, "slow_edodram", OPTV_BOOLEAN, {0}, FALSE },
{ OPTION_SLOW_VRAM, "slow_vram", OPTV_BOOLEAN, {0}, FALSE },
+ { OPTION_PCI_BURST, "pci_burst", OPTV_BOOLEAN, {0}, FALSE },
+ { OPTION_NO_PCI_DISC, "no_pci_disconnect", OPTV_BOOLEAN, {0}, FALSE },
{ -1, NULL, OPTV_NONE, {0}, FALSE }
};
@@ -459,6 +463,8 @@
} else
pS3->SlowVRAM = FALSE;
+ pS3->PCIBurst = xf86ReturnOptValBool(S3Options, OPTION_PCI_BURST, TRUE);
+ pS3->NoPCIDisc = xf86ReturnOptValBool(S3Options, OPTION_NO_PCI_DISC, FALSE);
if (pScrn->numEntities > 1) {
S3FreeRec(pScrn);
return FALSE;
@@ -1198,13 +1204,6 @@
outb(vgaCRIndex, 0x34);
outb(vgaCRReg, new->cr34);
- if (pS3->SlowDRAMRefresh)
- new->cr3a = 0xb7;
- else
- new->cr3a = 0xb5;
- outb(vgaCRIndex, 0x3a);
- outb(vgaCRReg, new->cr3a);
-
if (pS3->Chipset != PCI_CHIP_AURORA64VP) {
new->cr3b = (pVga->CRTC[0] + pVga->CRTC[4] + 1) / 2;
outb(vgaCRIndex, 0x3b);
@@ -1462,13 +1461,57 @@
outb(vgaCRReg, bdelay);
}
+
+ /*
+ * Overriding refresh cycles count.
+ *
+ * 1-0: Number of refresh cycles per scanline
+ * 2: Enable alternate refresh count control (1 = enable bits 0-1)
+ * 4: Colour enhanced mode (1 = enable)
+ */
+ outb(vgaCRIndex, 0x3a);
+ new->cr3a = inb(vgaCRReg) & 0xfc;
+ if (pS3->SlowDRAMRefresh)
+ new->cr3a |= 0x17;
+ else
+ new->cr3a |= 0x15;
+ outb(vgaCRReg, new->cr3a);
+
+ /*
+ * Disable or enable PCI Read Bursts
+ * cr3a_7: PCIRB DISA: 0 - enabled, 1 - disabled
+ *
+ * cr66_7 must be set to 1 before cr3a_7 is set to 1
+ * (from documentation)
+ */
+ if (!pS3->PCIBurst) {
+ outb(vgaCRIndex, 0x66);
+ outb(vgaCRReg, inb(vgaCRReg) | 0x80);
+
+ outb(vgaCRIndex, 0x3a);
+ outb(vgaCRReg, inb(vgaCRReg) | 0x80);
+ } else {
+ outb(vgaCRIndex, 0x3a);
+ outb(vgaCRReg, inb(vgaCRReg) & 0x7f);
+ }
+
+ /*
+ * Setting PCI Disconnect.
+ * cr66_7: PCI DE: 0 - disabled, 1 - enabled
+ */
outb(vgaCRIndex, 0x66);
new->cr66 = inb(vgaCRReg);
- if (pS3->S3NewMMIO)
- new->cr66 |= 0x88;
- else
- new->cr66 |= 0x80;
- outb(vgaCRReg, new->cr66);
+
+ if (pS3->NoPCIDisc) {
+ if (pS3->S3NewMMIO)
+ new->cr66 &= 0xf7;
+ outb(vgaCRReg, new->cr66 & 0x7f);
+ } else {
+ if (pS3->S3NewMMIO)
+ new->cr66 |= 0x08;
+ outb(vgaCRReg, new->cr66 | 0x80);
+ }
+
if (pS3->SlowVRAM) {
/*
diff -u xserver-xorg-video-s3-0.4.1/src/s3.h xserver-xorg-video-s3/src/s3.h
--- xserver-xorg-video-s3-0.4.1/src/s3.h 2006-04-08 05:38:57.0 +0400
+++ xserver-xorg-video-s3/src/s3.h 2008-08-07 21:28:51.0 +0400
@
Bug#476876: Log is ended up unexpectadly
You logs are incomplete. They are broken before the ScreenInit section. I think that the hanging occurs before that moment. After the place where your logs are ended up there must be something like this: (==) s3(0): Write-combining range (0xf400,0x20) (==) s3(0): Backing store disabled (II) s3(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 color pattern filled rectangles Solid Lines (II) s3(0): Acceleration enabled (II) s3(0): Using PIO (II) s3(0): Using SW cursor (**) Option "dpms" "off" (**) s3(0): DPMS enabled (==) RandR enabled (II) Setting vga for screen 0. (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFIXES (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Initializing built-in extension RANDR (II) Initializing built-in extension COMPOSITE (II) Initializing built-in extension DAMAGE (II) Initializing built-in extension XEVIE (EE) AIGLX: DRI module not loaded (II) Loading local sub module "GLcore" (II) LoadModule: "GLcore" (II) Loading /usr/lib/xorg/modules/extensions/libGLcore.so (II) Module GLcore: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.0.0 ABI class: X.Org Server Extension, version 0.3 (II) GLX: Initialized MESA-PROXY GL provider for screen 0 (**) Option "CoreKeyboard" (**) Keyboard0: Core Keyboard (**) Option "Protocol" "standard" (**) Keyboard0: Protocol: standard (**) Option "AutoRepeat" "500 30" (**) Option "XkbRules" "xorg" (**) Keyboard0: XkbRules: "xorg" (**) Option "XkbModel" "pc105" (**) Keyboard0: XkbModel: "pc105" (**) Option "XkbLayout" "us,ru" (**) Keyboard0: XkbLayout: "us,ru" (**) Option "XkbVariant" ",winkeys" (**) Keyboard0: XkbVariant: ",winkeys" (**) Option "XkbOptions" "grp:ctrl_shift_toggle,grp_led:scroll" (**) Keyboard0: XkbOptions: "grp:ctrl_shift_toggle,grp_led:scroll" (**) Option "CustomKeycodes" "off" (**) Keyboard0: CustomKeycodes disabled (**) Option "Protocol" "IMPS/2" (**) Mouse0: Device: "/dev/input/mouse0" (**) Mouse0: Protocol: "IMPS/2" (**) Option "CorePointer" (**) Mouse0: Core Pointer (**) Option "Device" "/dev/input/mouse0" (==) Mouse0: Emulate3Buttons, Emulate3Timeout: 50 (**) Option "ZAxisMapping" "4 5" (**) Mouse0: ZAxisMapping: buttons 4 and 5 (**) Mouse0: Buttons: 9 (II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE) (II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD) (**) Option "Device" "/dev/input/mouse0" The first line from this log is reffered to MTRR: (==) s3(0): Write-combining range (0xf400,0x20) Is there something like MTRR in Digital Alpha? If not, try to disable MTRR with option "NoMTRR" as first step and verify your log, whether it goes further. Section "Device" Identifier "Trio64" Driver "s3" BusID "PCI:1:9:0" Option "noaccel" Option "NoMtrr" VideoRAM2048 EndSection -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476876: Need more details about lspci output
"Evgeny M. Zubok" <[EMAIL PROTECTED]> writes: > What is your full lspci -v output? If you had got such strange picture > when X was started then probably S3 displayed some other place in > memory. Your log shows that framebuffer's start address is 0x0900 > - 0x097f. So X server will put the image there. Sorry, I have found the message about memory address in your logs? so my previous question can be ignored. >From your log: (--) PCI:*(1:9:0) S3 Inc. 86c764/765 [Trio32/64/64V+] rev 0, Mem @0x0900/23, BIOS @ 0x8080/16 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#476876: Need more details about lspci output
What is your full lspci -v output? If you had got such strange picture when X was started then probably S3 displayed some other place in memory. Your log shows that framebuffer's start address is 0x0900 - 0x097f. So X server will put the image there. (II) resource ranges after preInit: [0] 0 0 0x0900 - 0x097f (0x80) MS[B] I have, for example, the following output: 00:0b.0 VGA compatible controller: S3 Inc. 86c775/86c785 [Trio 64V2/DX or /GX] (rev 14) (prog-if 00 [VGA]) Subsystem: S3 Inc. 86C775 Trio64V2/DX, 86C785 Trio64V2/GX Flags: medium devsel, IRQ 12 Memory at e000 (32-bit, non-prefetchable) [size=64M] [virtual] Expansion ROM at 2000 [disabled] [size=64K] and (II) resource ranges after preInit: [0] 0 0 0xe000 - 0xe3ff (0x400) MS[B] VESA doesn't use framebuffer for putting image into videomemory. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#377386: (no subject)
Sorry for my previous dirty hack for Makefile.am. My previous message should be ignored. Now I present new correct version of patch. It also possibly closes bug #377386 which was merged with this bug. Infomation for maintainer. This patch replaces(!!!) my previous patch 01_enable_new_mmio.diff. It should be applied against /src/Makefile.am. And then './autogen.sh'. The old patch should be removed from /debian dir (also remove line AC_DEFINE(S3_NEWMMIO, 1, [Enable support for the new MMIO] from configure.ac which the 01_enable_new_mmio.diff inserts). Patchfile against /src/Makefile.am --- orig/src/Makefile.am 2006-11-24 22:49:28.0 + +++ new/src/Makefile.am 2006-11-24 22:51:19.0 + @@ -30,7 +30,6 @@ s3_drv_la_SOURCES = \ newmmio.h \ - s3_accel.c \ s3_bios.c \ s3_cursor.c \ s3_dga.c \ @@ -41,3 +40,12 @@ s3_Ti.c \ s3_Trio64DAC.c \ s3_video.c + +noinst_LTLIBRARIES = libs3_accel_newmmio.la libs3_accel_pio.la +s3_drv_la_LIBADD = libs3_accel_newmmio.la libs3_accel_pio.la + +libs3_accel_newmmio_la_SOURCES = s3_accel.c +libs3_accel_newmmio_la_CFLAGS = $(AM_CFLAGS) -DS3_NEWMMIO=1 + +libs3_accel_pio_la_SOURCES = s3_accel.c +libs3_accel_pio_la_CFLAGS = $(AM_CFLAGS)
Bug#377386: A new patch for s3 driver.
I resolved (i hope) the incosistences with the old S3 chipsets. Thanks to Eugene Konev for his report. Now s3_accel.c compiled twice: with and without S3_NEWMMIO and then object files s3_accel_newmmio.o and s3_accel_pio.o are linked together. Infomation for maintainer. This patch replaces(!!!) my previous patch 01_enable_new_mmio.diff. It should be applied against /src/Makefile.am. And then 'autoreconf --install --force'. The old patch should be removed from /debian dir. I'm waiting for any feedback! --- xserver-xorg-video-s3.orig/src/Makefile.am 2005-07-26 18:46:49.0 + +++ xserver-xorg-video-s3/src/Makefile.am 2006-10-29 13:29:55.0 + @@ -30,7 +30,6 @@ s3_drv_la_SOURCES = \ newmmio.h \ - s3_accel.c \ s3_bios.c \ s3_cursor.c \ s3_dga.c \ @@ -41,3 +40,15 @@ s3_Ti.c \ s3_Trio64DAC.c \ s3_video.c + +EXTRA_s3_drv_la_SOURCES = s3_accel.c +s3_drv_la_LIBADD = s3_accel_newmmio.lo s3_accel_pio.lo + +s3_accel_newmmio.lo: s3_accel.c + if $(LTCOMPILE) -DS3_NEWMMIO=1 -MT $@ -MD -MP -MF "$(DEPDIR)/$*.Tpo" -c -o $@ $<; \ + then mv -f "$(DEPDIR)/$*.Tpo" "$(DEPDIR)/$*.Plo"; else rm -f "$(DEPDIR)/$*.Tpo"; exit 1; fi + +s3_accel_pio.lo: s3_accel.c + if $(LTCOMPILE) -MT $@ -MD -MP -MF "$(DEPDIR)/$*.Tpo" -c -o $@ $<; \ + then mv -f "$(DEPDIR)/$*.Tpo" "$(DEPDIR)/$*.Plo"; else rm -f "$(DEPDIR)/$*.Tpo"; exit 1; fi +
Bug#377386: Addition to the last post
Sorry, I see what you are talking about. When Xorg was moved from imake building system the old building rules was not incorporated into Xorg 7.0/7.1 source tree. I'll try to change this issue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#377386: What S3 chip you use?
What chip you are talking about? In the s3 driver source code there are
only following supported chips:
Without New MMIO:
PCI_CHIP_964_0
PCI_CHIP_964_1
PCI_CHIP_TRIO
PCI_CHIP_AURORA64VP,
With New MMIO:
PCI_CHIP_968
PCI_CHIP_TRIO64UVP
PCI_CHIP_TRIO64V2_DXGX
As I remember there is always one common driver s3_drv.so in Xorg
binaries for legacy S3 chips and one for S3 Virge.
'grep -r "S3_GENERIC" *' gives nothing. Where you found it?
If your chip doesn't support acceleration, try Option "noaccel"
in Device section or vesa driver.
There is also S3NewMMIO boolean flag (not the S3_NEWMMIO preprocessor
variable!) in sources which excludes NewMMIO specific code if chip
hasn't support for the New MMIO. But this flag works only for detected
chips which supported by driver:
switch (pS3->Chipset) {
case PCI_CHIP_964_0:
case PCI_CHIP_964_1:
case PCI_CHIP_TRIO:
case PCI_CHIP_AURORA64VP: /* ??? */
pS3->S3NewMMIO = FALSE;
break;
case PCI_CHIP_TRIO64V2_DXGX:
case PCI_CHIP_TRIO64UVP:
case PCI_CHIP_968:
pS3->S3NewMMIO = TRUE;
break;
}
I'm waiting for your comments.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#377386: [SOLVED]
--- orig/configure.ac 2006-02-13 03:48:46.0 + +++ new/configure.ac2006-10-08 02:31:54.0 + @@ -62,6 +62,8 @@ # Checks for header files. AC_HEADER_STDC +AC_DEFINE(S3_NEWMMIO, 1, [Enable support for the new MMIO]) + AC_SUBST([XORG_CFLAGS]) AC_SUBST([moduledir]) A patch that solves the problem attached. A C preprocessor macro #define S3_NEWMMIO was lost while transition to Xorg 7.1. This patch should be applied against configure.ac. After that it need to reconfigure a package: autoreconf -v --install to generate new scripts and headers. Now the S3 driver works as before.
Bug#377386: Workaround
I have the same issue. See #370382 and https://bugs.freedesktop.org/show_bug.cgi?id=7112 I discovered that the problem is in acceleration. Workaround is to disable acceleration :( Section "Device" Identifier "s3_trio64v2" Driver "s3" Option "noaccel" ^^ ^ Option "DPMS" EndSection -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390766: xserver-xorg: X server always looks up the compiled-in font pathes.
Package: xserver-xorg Version: 1:7.0.22 Severity: normal First of all I take some configurations and logs |= X font Server = /etc/X11/fs/config contains: [skip] catalogue = /usr/share/fonts/X11/misc/, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1/ [skip] |= Xorg server /etc/X11/xorg.conf contains: Section "Files" FontPath"unix/:7100" EndSection |== /var/log/Xorg.0.log takes: (**) FontPath set to "unix/:7100,/usr/share/fonts/X11/misc/,/usr/share/fonts/X11/TTF/, /usr/share/fonts/X11/OTF,/usr/share/fonts/X11/Type1/,/usr/share/fonts/X11/CID/, /usr/share/fonts/X11/100dpi/,/usr/share/fonts/X11/75dpi/" |== Output of 'xlsfonts' is something like this: [skip] -adobe-helvetica-bold-o-normal--11-80-100-100-p-60-iso10646-1 -adobe-helvetica-bold-o-normal--11-80-100-100-p-60-iso10646-1 -adobe-helvetica-bold-o-normal--11-80-100-100-p-60-iso8859-1 -adobe-helvetica-bold-o-normal--11-80-100-100-p-60-iso8859-1 -adobe-helvetica-bold-o-normal--12-120-75-75-p-69-iso10646-1 -adobe-helvetica-bold-o-normal--12-120-75-75-p-69-iso10646-1 -adobe-helvetica-bold-o-normal--12-120-75-75-p-69-iso8859-1 -adobe-helvetica-bold-o-normal--12-120-75-75-p-69-iso8859-1 [skip] -xos4-terminus-medium-r-normal--32-320-72-72-c-160-iso10646-1 -xos4-terminus-medium-r-normal--32-320-72-72-c-160-iso10646-1 -xos4-terminus-medium-r-normal--32-320-72-72-c-160-iso10646-1 -xos4-terminus-medium-r-normal--32-320-72-72-c-160-iso8859-1 -xos4-terminus-medium-r-normal--32-320-72-72-c-160-iso8859-1 -xos4-terminus-medium-r-normal--32-320-72-72-c-160-iso8859-1 [skip] -misc-fixed-bold-r-semicondensed--13-120-75-75-c-60-iso8859-1 -misc-fixed-bold-r-semicondensed--13-120-75-75-c-60-iso8859-1 -misc-fixed-bold-r-semicondensed--13-120-75-75-c-60-iso8859-1 -misc-fixed-bold-r-semicondensed--13-120-75-75-c-60-iso8859-1 [skip] As we see, Xorg server dublicates font patterns because it processes compiled-in pathes (see log above). Hm, this is something strange because the FILE SECTION, subsection "FontPath" from 'man xorg.conf' says: - "When this entry is not specified in the config file, the server falls back to the compiled-in default font path, which contains the following font path elements: /usr/lib/X11/fonts/misc/ /usr/lib/X11/fonts/TTF/ /usr/lib/X11/fonts/Type1/ /usr/lib/X11/fonts/CID/ /usr/lib/X11/fonts/75dpi/ /usr/lib/X11/fonts/100dpi/" - So the rule is 'if I write one or more FontPath entries, then compiled-in font path must be skiped'. We see the opposite behaviour: compiled-in pathes were selected and the dublication of fontpathes wasn't eliminated. I discovered that the number of duplicates in 'xlsfonts' output equals = font patternt from xfs (one entry) + font pattern from compiled-in pathes (one entry) + number of aliases to this font which was found in fonts.alias (zero or great entries). So for, say, -misc-fixed-bold-r-semicondensed--13-120-75-75-c-60-iso8859-1 we have four entries in the 'xlsfonts' output! With the command xset -fp /usr/share/fonts/X11/75dpi/,/usr/share/fonts/X11/100dpi/, /usr/share/fonts/X11/misc/,/usr/share/fonts/X11/Type1/ the dublications of font patterns are disappeared. (wow!) The 'xfontsel' program also processes all these pattern entries. Before xset command 'xfontsel' found 6000+ pattens and after 2400+. I have the same issue if I rewrite xorg.conf. Section "Files" # FontPath"unix/:7100" FontPath"/usr/share/fonts/X11/misc" FontPath"/usr/share/fonts/X11/100dpi/:unscaled" FontPath"/usr/share/fonts/X11/75dpi/:unscaled" FontPath"/usr/share/fonts/X11/Type1" EndSection Then /var/log/Xorg.0.log: (WW) The directory "/usr/share/fonts/X11/TTF/" does not exist. Entry deleted from font path. (WW) The directory "/usr/share/fonts/X11/OTF" does not exist. Entry deleted from font path. (WW) The directory "/usr/share/fonts/X11/CID/" does not exist. Entry deleted from font path. (==) FontPath set to "/usr/share/fonts/X11/misc/,/usr/share/fonts/X11/Type1/, /usr/share/fonts/X11/100dpi/,/usr/share/fonts/X11/75dpi/" Xorg server try to search compiled-in pathes again. Why? -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i586) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-486 Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8) Versions of packages xserver-xorg depends on: ii debconf 1.5.4 Debian configuration managem
Bug#370382: xserver-xorg-video-all: Xorg 7.0.20: S3 driver doesn't work
Package: xserver-xorg-video-all Version: 1:7.0.20 Severity: important Subj. I have old S3 Trio64v2 videocard. I placed the same bug into freedesktop.org bugtracking system with xorg.conf and Xorg.0.log. Here: https://bugs.freedesktop.org/show_bug.cgi?id=7112 -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i586) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-486 Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
