Bug reported on the Debian BTS by Dietrich Clauss several months ago. The problem appeared with Xorg 7.1, it still occurs with driver 1.1.0 and Xserver 1.3. Driver 1.1.1 does not seem to change anything for ET4000 so I guess the problem is still there too. The driver reports the following lines. See the Debian bug for details, including the log with Xorg 7.0 which worked fine. (II) Loading /usr/lib/xorg/modules/drivers/tseng_drv.so (II) Module tseng: vendor="X.Org Foundation" compiled for 7.1.1, module version = 1.1.0 Module class: X.Org Video Driver ABI class: X.Org Video Driver, version 1.0 [...] (II) TSENG: driver for TsengLabs ET4000W32p, ET6000 and ET6100 chips. (II) Primary Device is: PCI 00:0b:0 (--) Assigning device section with no busID to primary device (--) Chipset ET4000W32p found (II) resource ranges after xf86ClaimFixedResources() call: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xc5000000 - 0xc50000ff (0x100) MX[B] [5] -1 0 0xc5800000 - 0xc5800fff (0x1000) MX[B] [6] -1 0 0xc7800000 - 0xc7800fff (0x1000) MX[B] [7] -1 0 0xc8000000 - 0xc7ffffff (0x0) MX[B]O [8] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [9] -1 0 0xc6000000 - 0xc6ffffff (0x1000000) MX[B](B) [10] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [11] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [12] -1 0 0x0000b800 - 0x0000b80f (0x10) IX[B] [13] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B] [14] -1 0 0x0000d400 - 0x0000d4ff (0x100) IX[B] [15] -1 0 0x0000d800 - 0x0000d83f (0x40) IX[B] [16] -1 0 0x0000e800 - 0x0000e800 (0x1) IX[B] [17] -1 0 0x0000ec00 - 0x0000ec00 (0x1) IX[B] (II) resource ranges after probing: [0] -1 0 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [1] -1 0 0x000f0000 - 0x000fffff (0x10000) MX[B] [2] -1 0 0x000c0000 - 0x000effff (0x30000) MX[B] [3] -1 0 0x00000000 - 0x0009ffff (0xa0000) MX[B] [4] -1 0 0xc5000000 - 0xc50000ff (0x100) MX[B] [5] -1 0 0xc5800000 - 0xc5800fff (0x1000) MX[B] [6] -1 0 0xc7800000 - 0xc7800fff (0x1000) MX[B] [7] -1 0 0xc8000000 - 0xc7ffffff (0x0) MX[B]O [8] -1 0 0xd0000000 - 0xdfffffff (0x10000000) MX[B](B) [9] -1 0 0xc6000000 - 0xc6ffffff (0x1000000) MX[B](B) [10] 0 0 0x000a0000 - 0x000affff (0x10000) MS[B] [11] 0 0 0x000b0000 - 0x000b7fff (0x8000) MS[B] [12] 0 0 0x000b8000 - 0x000bffff (0x8000) MS[B] [13] -1 0 0x0000ffff - 0x0000ffff (0x1) IX[B] [14] -1 0 0x00000000 - 0x000000ff (0x100) IX[B] [15] -1 0 0x0000b800 - 0x0000b80f (0x10) IX[B] [16] -1 0 0x0000d000 - 0x0000d0ff (0x100) IX[B] [17] -1 0 0x0000d400 - 0x0000d4ff (0x100) IX[B] [18] -1 0 0x0000d800 - 0x0000d83f (0x40) IX[B] [19] -1 0 0x0000e800 - 0x0000e800 (0x1) IX[B] [20] -1 0 0x0000ec00 - 0x0000ec00 (0x1) IX[B] [21] 0 0 0x000003b0 - 0x000003bb (0xc) IS[B] [22] 0 0 0x000003c0 - 0x000003df (0x20) IS[B] (II) Setting vga for screen 0. (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Reloading /usr/lib/xorg/modules/libint10.so (II) TSENG(0): initializing int10 (II) TSENG(0): Primary V_BIOS segment is: 0xc000 (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/lib/xorg/modules/libvgahw.so (II) Module vgahw: vendor="X.Org Foundation" compiled for 7.1.1, module version = 0.1.0 ABI class: X.Org Video Driver, version 1.0 (II) TSENG(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 (--) TSENG(0): Chipset: "ET4000/W32P (rev D)" (EE) TSENG(0): Unable to probe RAMDAC (II) UnloadModule: "tseng" (II) UnloadModule: "vgahw" (II) Unloading /usr/lib/xorg/modules/libvgahw.so (II) UnloadModule: "int10" (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found
Which ramdac is this? It's the third big chip on the card. The one that isn't the tseng and the one that isn't the DIP ROM, it's also just by itself, unlike the RAM chips. The driver currently only supports the CH8398 and the STG1703, as these are the only devices i could get my hands on when i rewrote this part of the tseng support.
Right, ICS GenDAC, support was removed as no hardware (and thus no testing) was available with it. Will be added again.
What's the status of this? It looks like a fix is available based on the previous comment.
HW has since become available, and is part of my collection now, one of the two cards even booted at one point or another. Back then, i got into tseng as it was the only driver using multiple clock ranges infrastructure. I rewrote the driver to no longer use this. This decade, i am probably the only guy left who has used tseng hw: i have dcc support sitting around somewhere, as i noticed a tseng with a blue vga connector, and i traced the board, and spent 10 minutes disassembling the bios. If i am bored enough, one day, who knows... But WONTFIX, i doubt the reporter still cares much.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.