Bug#233001:
Contents of /var/lib/xfree86/X.roster: xserver-xfree86 X server symlink status: lrwxrwxrwx1 root root 20 2004-04-30 13:19 /etc/X11/X -> /usr/bin/X11/XFree86 -rwxr-xr-x1 root root 1742316 2004-03-18 16:42 /usr/bin/X11/XFree86 /var/lib/xfree86/X.md5sum does not exist. Contents of /var/lib/xfree86/XF86Config-4.roster: xserver-xfree86 VGA-compatible devices on PCI bus: :00:08.0 VGA compatible controller: Tseng Labs Inc ET4000/W32p rev C :00:08.0 Class 0300: 100c:3206 XFree86 X server configuration file status: -rw-r--r--1 root root 3210 2004-04-30 14:10 /etc/X11/XF86Config-4 Contents of /etc/X11/XF86Config-4: # XF86Config-4 (XFree86 X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type "man XF86Config-4" at the shell prompt.) # # This file is automatically updated on xserver-xfree86 package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xfree86 # package. # # If you have edited this file but would like it to be automatically updated # again, run the following commands as root: # # cp /etc/X11/XF86Config-4 /etc/X11/XF86Config-4.custom # md5sum /etc/X11/XF86Config-4 > /var/lib/xfree86/XF86Config-4.md5sum # dpkg-reconfigure xserver-xfree86 Section "Files" FontPath"unix/:7100"# local font server # if the local font server has problems, we can fall back on these FontPath"/usr/lib/X11/fonts/misc" FontPath"/usr/lib/X11/fonts/cyrillic" FontPath"/usr/lib/X11/fonts/100dpi/:unscaled" FontPath"/usr/lib/X11/fonts/75dpi/:unscaled" FontPath"/usr/lib/X11/fonts/Type1" FontPath"/usr/lib/X11/fonts/CID" FontPath"/usr/lib/X11/fonts/Speedo" FontPath"/usr/lib/X11/fonts/100dpi" FontPath"/usr/lib/X11/fonts/75dpi" EndSection Section "Module" Load"GLcore" Load"bitmap" Load"dbe" Load"ddc" Load"dri" Load"extmod" Load"freetype" Load"glx" Load"int10" Load"record" Load"speedo" Load"type1" Load"vbe" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xfree86" Option "XkbModel" "pc104" Option "XkbLayout" "us" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/tts/0" Option "Protocol" "Microsoft" Option "Emulate3Buttons" "true" Option "ZAxisMapping" "4 5" EndSection Section "InputDevice" Identifier "Generic Mouse" Driver "mouse" Option "SendCoreEvents""true" Option "Device""/dev/input/mice" Option "Protocol" "ImPS/2" Option "Emulate3Buttons" "true" Option "ZAxisMapping" "4 5" EndSection Section "Device" Identifier "ViewTop_BP-ET4" Driver "tseng" EndSection Section "Monitor" Identifier "Generic Monitor" HorizSync 30-72 VertRefresh 50-120 Option "DPMS" EndSection Section "Screen" Identifier "Default Screen" Device "ViewTop_BP-ET4" Monitor "Generic Monitor" DefaultDepth8 SubSection "Display" Depth 1 Modes "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 4 Modes "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 8 Modes "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 15 Modes "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 16 Modes "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 24 Modes "1024x768" "800x600" "640x480" EndSubSection EndSection Section "ServerLayout" Identifier "Default Layout" Screen "Default Screen" InputDevice "Generic Keyboard" Inp
Bug#233001: xserver-xfree86: [tseng] ET4000/W32p only works with vesa or vga
On Tue, Apr 20, 2004 at 08:20:39PM -0500, Branden Robinson wrote: > tag 233001 + moreinfo > thanks > > On Mon, Feb 16, 2004 at 08:32:25PM +1100, Ian Maclaine-cross wrote: > > Package: xserver-xfree86 > > Version: 4.2.1-12.1 > > Severity: important > > > > Xfree86 3.3.6 worked with my Tseng ET4000/W32p graphics card but > > 4.2 does not except with a low resolution vesa or vga mode. > > Did you *try* the "tseng" driver instead? Yes indeed and it did nothing. > Please do so, explain exactly how it appears to fail, and please mail > this bug number the corresponding XFree86 X server config file and log > file from when it does not work. > E.g., > > $ /usr/share/bug/xserver-xfree86 > /tmp/output 3>&1 > $ mailx -s "Re: Bug#233001" [EMAIL PROTECTED] < /tmp/output Done. Please let me know if /tmp/output arrives. I checked it and it appears correct (ie wrong). Sorry to be so slow in responding. Thanks for your good work in tracking down bugs. > -- > G. Branden Robinson| Never attribute to malice that > Debian GNU/Linux | which can be adequately explained > [EMAIL PROTECTED] | by stupidity. > http://people.debian.org/~branden/ | -- Hanlon's Razor -- Regards, Ian Maclaine-cross <[EMAIL PROTECTED]> GnuPG key fingerprint = 5F7A 7539 EA0D F4B4 95D3 0D22 A8BB B366 1D1D FB53 This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender and are not necessarily the views of UNSW.
Re: x configuration process
On Thu, Apr 29, 2004 at 08:30:17PM -0700, Nick Urban wrote: > Why does X not attempt to configure itself automatically before asking > the user questions? Depends on whether discover and friends are installed or not. > The debconf configurator asks lots of questions that many users don't > understand or care about. If the user does care, they can always just > run `XFree86 -configure' and do some manual editing. Oh, and doing it that way subjects clueless users to LESS intimidating questions. Not. Branden's configuration method is pretty moron-friendly. > Does X it normally autoconfigure when working correctly, or is this a > bigger problem. If it is, can we just steal knoppix autoconfigure system? Please, no... can we have something that works, instead? -- Marc Wilson | Money is the root of all wealth. [EMAIL PROTECTED] |
Bug#241014: marked as done (xlibs: AltGr key doesn't work after upgrade to XFree86 4.3.0 when using xfree86/pc105/se/nodeadkeys)
Your message dated Thu, 29 Apr 2004 23:54:52 -0500 with message-id <[EMAIL PROTECTED]> and subject line Bug#241014: XKB problems after upgrade to 4.3.0 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 30 Mar 2004 10:34:06 + >From [EMAIL PROTECTED] Tue Mar 30 02:34:06 2004 Return-path: <[EMAIL PROTECTED]> Received: from av3-1-sn4.m-sp.skanova.net [81.228.10.114] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1B8GZK-00029n-00; Tue, 30 Mar 2004 02:34:06 -0800 Received: by av3-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 0CEA437EB2; Tue, 30 Mar 2004 12:33:35 +0200 (CEST) Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av3-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id F1BBB37E5E for <[EMAIL PROTECTED]>; Tue, 30 Mar 2004 12:33:34 +0200 (CEST) Received: from em2.my.own.domain (h245n2fls301o1037.telia.com [81.227.209.245]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 9511337E67 for <[EMAIL PROTECTED]>; Tue, 30 Mar 2004 12:33:34 +0200 (CEST) Received: from srs by em2.my.own.domain with local (Exim 3.36 #1 (Debian)) id 1B8GYr-00053r-00 for <[EMAIL PROTECTED]>; Tue, 30 Mar 2004 12:33:37 +0200 Subject: XKB problems after upgrade to 4.3.0 From: Svante Signell <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <[EMAIL PROTECTED]> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 30 Mar 2004 12:33:37 +0200 Sender: Svante Signell <[EMAIL PROTECTED]> Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_30,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2004_03_25 X-Spam-Level: Package: xserver-xfree86 Version: 4.3.0-7 Severity: important I get the errors shown below when starting the X server. One result is that the key does not work, making keys like |\~ not to work, very annoying. For 4.2.x versions the same XF86config-4 file worked fine. Error screen in Gnome: == Error activating XKB configuration. Probably internal X server problem. X server version data: The XFree86 Project, Inc 4031 You are using XFree 4.3.0. There are known problems with complex XKB configurations. Try using simpler configuration or taking more fresh version of XFree software. If you report this situation as a bug, please include: - The result of xprop -root | grep XKB - The result of gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb Parts of /var/log/XFree86.0.log === (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "se" (**) XKB: layout: "se" (**) Option "XkbVariant" "nodeadkeys" (==) Keyboard: CustomKeycode disabled Couldn't load XKB keymap, falling back to pre-XKB keymap (II) Server_Terminate keybinding not found xprop -root | grep XKB _XKB_RULES_NAMES_BACKUP(STRING) = "xfree86", "pc105", "se", "nodeadkeys", "" _XKB_RULES_NAMES(STRING) = "xfree86", "pc105", "se", "nodeadkeys", "" gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb layouts = [se nodeadkeys] model = pc105 overrideSettings = false options = [] --- Received: (at 241014-done) by bugs.debian.org; 30 Apr 2004 04:54:53 + >From [EMAIL PROTECTED] Thu Apr 29 21:54:53 2004 Return-path: <[EMAIL PROTECTED]> Received: from dhcp065-026-182-085.indy.rr.com (redwald.deadbeast.net) [65.26.182.85] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1BJQ33-Mf-00; Thu, 29 Apr 2004 21:54:53 -0700 Received: by redwald.deadbeast.net (Postfix, from userid 1000) id 424EF6419A; Thu, 29 Apr 2004 23:54:52 -0500 (EST) Date: Thu, 29 Apr 2004 23:54:52 -0500 From: Branden Robinson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: Bug#241014: XKB problems after upgrade to 4.3.0 Message-ID: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; proto
X Strike Force XFree86 SVN commit: r1340 - trunk/debian
Author: branden
Date: 2004-04-30 00:56:30 -0500 (Fri, 30 Apr 2004)
New Revision: 1340
Modified:
trunk/debian/TODO
Log:
Add item.
Update SiS driver item.
Modified: trunk/debian/TODO
===
--- trunk/debian/TODO 2004-04-29 02:15:52 UTC (rev 1339)
+++ trunk/debian/TODO 2004-04-30 05:56:30 UTC (rev 1340)
@@ -55,7 +55,8 @@
generic ones by fixing upstream Imakeage to not turn extra stuff off when
the XFree86 X server is not being built (like xmodmap.std). It ships
libXxf86vm.a but not the corresponding manpages.
-* Grab SiS driver from HEAD per Thomas Winischhofer.
+* Grab SiS driver from Thomas Winischhofer's website, per his information.
+ Should fix #245249 and #246087.
* hurd-i386 MANIFEST, and probably some debhelper files, are out of date.
* Should xc/include/{Xw32defs.h,Xwinsock.h} be installed (and shipped) for
the benefit of cross-compilers? Check upstream Imakeage.
@@ -90,6 +91,8 @@
* #243288: xfree86-common: DebianRed should be in rgb.txt [STALLED awaiting
more info]
* #245044: xdm: cannot resolve hostnames from Xaccess Indirect lines
+* #245065: xbase-clients: add an option to let setxkbmap ignore current server
+ settings
Do opportunistically, only in conjuction with other fixes
-
Re: X and 2.6.5 kernel: update of 2.6.5 kernel locks my laptop
On Thu, Apr 29, 2004 at 09:14:58AM +, slaven peles wrote: > Apr 29 08:25:01 ivor kernel: atkbd.c: Unknown key released (translated set 2, > code 0x7a on isa0060/serio0). > Apr 29 08:25:01 ivor kernel: atkbd.c: This is an XFree86 bug. It shouldn't > access hardware directly. > Apr 29 08:25:01 ivor kernel: atkbd.c: Unknown key released (translated set 2, > code 0x7a on isa0060/serio0). > Apr 29 08:25:01 ivor kernel: atkbd.c: This is an XFree86 bug. It shouldn't > access hardware directly. On Thu, Apr 29, 2004 at 10:54:24AM -0500, Diego Enrique Rodriguez wrote: > I have same problem look my log in > http://uvirtual.ean.edu.co/~derodriguez/kernelprob/XFree86.0.log On Thu, Apr 29, 2004 at 03:52:18PM -0400, Josh Metzler wrote: > This happens to me, too - Radeon 7000, same kernel. I filed bug #246587 > against kernel-image-2.6.5-1-686. Hi guys, This should be fixed in the version of XFree86 that entered sid on 29 April. xfree86 (4.3.0.dfsg.1-1) unstable; urgency=low [...] * Fix AT keyboard rate I/O controls by operating on the actual console file descriptor, not on file descriptor zero (thanks, Keith Packard). Suppresses warning messages from Linux 2.6. (Closes: #224909) [...] -- Fabio M. Di Nitto <[EMAIL PROTECTED]> Wed, 28 Apr 2004 18:55:17 +0200 -- G. Branden Robinson|I must despise the world which does Debian GNU/Linux |not know that music is a higher [EMAIL PROTECTED] |revelation than all wisdom and http://people.debian.org/~branden/ |philosophy. -- Ludwig van Beethoven signature.asc Description: Digital signature
Re: problem with left-handed mouse on X - is GPM to blame or is it X?
[Zeph Hull dropped from Cc.] On Thu, Apr 29, 2004 at 12:29:35PM +0300, Martin-Éric Racine wrote: > Greetings, > > Given how everyone in this family is left-handed, I recently got around > inverting the order of the mouse buttons in GPM; works great in console. > > Since GPM is setup as a repeater for X, I thought that X would also end up > defaulting to inverted button order, but it doesn't. > > I haven't found any option in X to configure the button order and Googling > didn't tell me anything relevant about perhaps selecting a different protocol > in > GPM to get everything working in X the same way it does on console. > > Would anybody happen to have a cure for this? There is information in the Debian X FAQ about this. /usr/share/doc/xfree86-common/FAQ.gz http://necrotic.deadbeast.net/xsf/XFree86/trunk/debian/local/FAQ Please let us know if it is insufficient. -- G. Branden Robinson|Religion consists in a set of Debian GNU/Linux |things which the average man thinks [EMAIL PROTECTED] |he believes and wishes he was http://people.debian.org/~branden/ |certain of. -- Mark Twain signature.asc Description: Digital signature
Bug#245246: xserver-xfree86: xserver starts but suddenly dies before and windowmanager or similar starts
On Thu, Apr 29, 2004 at 02:02:42PM -0400, Ben Collins wrote: > On Thu, Apr 29, 2004 at 11:57:42AM -0500, Branden Robinson wrote: > > tag 245246 - moreinfo > > tag 245246 + help > > thanks > > > > On Thu, Apr 29, 2004 at 03:24:31PM +0200, Joerg Friedrich wrote: > > > Branden Robinson schrieb am Mittwoch, 28. April 2004 um 02:49:07 -0500: > > > > > > > > Does the X server stay up if you give it no clients to run? > > > > > > > > One way to test this is simply to run "X" as root. > > > > > > definitly X, I tried to run 'X' as root, the result is the same. > > > > Okay, it looks like the sunffb driver is definitely busted in testing > > and unstable. > > Is this minus the patches that I sent you? It's minus the one that wouldn't compile. The other one is part of the package version the submitter is using: * Apply patch by David S. Miller to implement support for RGB->BGR colorspace conversion in the X server's fb layer. - debian/patches/072_Xserver_fb_convert_RGB_to_BGR.diff A few weeks ago, I asked for an updated version of the other patch: * Apply patch by David S. Miller to implement XAA and Render support in the sunffb driver. - debian/patches/073_sunffb_xaa_render_fb_support.diff If you could get a version to me that will build I'd be happy to apply it. However, the missing symbols that are being complained have to do with DRI and drm, not XAA or Render. -- G. Branden Robinson| Yesterday upon the stair, Debian GNU/Linux | I met a man who wasn't there. [EMAIL PROTECTED] | He wasn't there again today, http://people.debian.org/~branden/ | I think he's from the CIA. signature.asc Description: Digital signature
Bug#243081: xserver-xfree86: dpms blanking behaves erracticaly
On Thu, Apr 29, 2004 at 04:44:08PM -0700, Tyler Riddle wrote: > I switched monitors and the behavior changed a little. > Instead of oscilating between off and on states it now > displays about 5 seconds of strange lines, I believe > the sync rates to be pretty wild. Then the new monitor > will turn off. I also tried switching cards after > changing monitors, both cards had the same behavior. > > The current card is a brand new nVidia Geforce 3d card > using the nVidia drivers. Finaly, the same behavior > was observed under freebsd previously on this > computer, with the Rage video card and the original > monitor. Thanks for following up. Do these monitors claim to support DPMS? As I understand it, DPMS signaling is done very crudely, by turning off the horizontal and vertical sync signals in various combinations to indicate "standby", "sleep", and "off". -- G. Branden Robinson| You could wire up a dead rat to a Debian GNU/Linux | DIMM socket and the PC BIOS memory [EMAIL PROTECTED] | test would pass it just fine. http://people.debian.org/~branden/ | -- Ethan Benson signature.asc Description: Digital signature
Re: Start preparing xfree86 4.3.0.dfsg.1-2
On Thu, Apr 29, 2004 at 07:56:06AM +0200, Fabio Massimo Di Nitto wrote:
> Hi all,
> a few hours ago 4.3.0.dfsg.1-1 has been uploaded and it will hit
> the mirrors within tomorrow.
Hats off, Fabio! You have my deepest thanks for handling this
responsibility, and handling it well.
> So far Branden has already commited to trunk a fix for #242485 and it is
> perfectly fine with me.
Okay.
> >From the TODO list, I think we should proceed in the following order of
> priorities:
>
> - ---> subliminal message: fix whatever I broke with 4.3.0.dfsg.1-1 <---
There are some reports trickling in that the damn kernel 2.6 "This is a
bug in XFree86. This is a bug in XFree86. This is a bug in XFree86.
This is a bug in XFree86." problem isn't truly resolved.
We'll have to wait and see how that develops. Not your fault in any
case.
> * #240889: add AMD64 support
> patch seems ok.
Yeah, the Great Biarch Debate is no reason for us to delay AMD64 support
any further.
[snip items I agree with and which do not require comment]
> * Grab SiS driver from HEAD per Thomas Winischhofer.
As noted on this list, we'll pull from Thomas's website instead. I've
updated the TODO already.
> * steal {U,}XTerm* app-defaults updates from HEAD and resync patches
I think I will pull from Thomas (Dickey's) releases instead. With
XFree86 (implicitly) slapping their new license on all the Imakefiles, I
don't feel like messing with upstream CVS.
[snip items I agree with and which do not require comment]
> * 006_dont_ref_rman.man.diff: different fix exists upstream; steal it
> from HEAD
>
> * 013_xkb_symbols_euro_support.diff: different fix exists upstream;
> steal it from HEAD
We should grab fixes from XFree86 CVS only if:
1) They predate the relicensing on 2004-02-13; and
2) They predate the addition of X-Oz copyrighted code on affected files.
That means that for some files, the clock stops on 2003-10-07. Those
files are:
xc/programs/Xserver/hw/xfree86/CHANGELOG
xc/programs/Xserver/hw/xfree86/Imakefile
xc/programs/Xserver/hw/xfree86/XF86Config.man
xc/programs/Xserver/hw/xfree86/common/Imakefile
xc/programs/Xserver/hw/xfree86/common/xf86AutoConfig.c
xc/programs/Xserver/hw/xfree86/common/xf86Config.c
xc/programs/Xserver/hw/xfree86/common/xf86Config.h
xc/programs/Xserver/hw/xfree86/common/xf86Configure.c
xc/programs/Xserver/hw/xfree86/common/xf86Helper.c
xc/programs/Xserver/hw/xfree86/common/xf86Init.c
xc/programs/Xserver/hw/xfree86/common/xf86Mode.c
xc/programs/Xserver/hw/xfree86/drivers/vesa/vesa.c
xc/programs/Xserver/hw/xfree86/getconfig/Imakefile
xc/programs/Xserver/hw/xfree86/getconfig/cfg.sample
xc/programs/Xserver/hw/xfree86/getconfig/getconfig.pl
xc/programs/Xserver/hw/xfree86/getconfig/getconfig.sh
xc/programs/Xserver/hw/xfree86/getconfig/xfree86.cfg
xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c
xc/programs/Xserver/hw/xfree86/os-support/bsd/bsd_mouse.c
xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_mouse.c
xc/programs/Xserver/hw/xfree86/os-support/xf86OSmouse.h
xc/programs/Xserver/hw/xfree86/parser/scan.c
xc/programs/Xserver/hw/xfree86/parser/xf86Parser.h
> * Fix upstream install rule that prevents Xcursor themes from being
> installed on s390. As I understand it, this is client-side stuff and
> there's not really any reason it shouldn't be made available on the s390
> architecture.
>
> * Fix other gratuitous differences between s390 debehlper files and the
> generic ones by fixing upstream Imakeage to not turn extra stuff off when
> the XFree86 X server is not being built (like xmodmap.std). It ships
> libXxf86vm.a but not the corresponding manpages.
Be warned; I know my way around Imake fairly well by now (though I'm hardly an
expert), but the above could be time consuming. I think we should be
prepared to defer these in favor either of other fixes or just getting
the release out the door.
> * more cosmetic/lintian cleanup if there will be time for it.
Yeah, I should add this to the "ongoing work" items in the TODO.
> For this release, other than the 4 bug fixes, we will work mainly on
> resync and cleanup. If -1 and -2 will not show big problems we might want
> to consider slightly bigger changes for -3, like the rewrite
> xserver-xfree86 debconfage. Time will tell.
Yeah, I'm not quite ready for a commit of the stuff I've got in my
working copy.
> Again as -1 this release will have only one major/risky change applying
> the via patch from Adam Conrad.
Right.
> Without repeating Branden and myself on each entry, be sure that licences
> are ok when pulling stuff from cvs HEAD.
See above. As I feared, David Dawes has not replied to my request for a
clarification on what the heck is going on with this "implicit relicense
even if neither the file nor the commit message say so" business, so I
think that everything failing the criteria I outlined above needs to be
regarded as poisonous.
If anyone feels differently -- about the license business or anything
else -- please spea
Bug#246642: new Xfree86 in unstable crashes with ATI Radeon on IBM Thinkpad
Package: xserver-xfree86 Version: 4.3.0.dfsg.1-1 Severity: critical Description of problem: When X starts up, it goes into an infinite loop, spewing out the following error message in the log file endlessly, until / is filled up: (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 (EE) RADEON(0): GetBuffer timed out, resetting engine... The full log file is attached (I delete the endless reptitions so file will be of reasonable size). Also attached please find the XFree86 configuration file. Since my system is configured to start gdm upon boot-up, and since this causes an infinite loop of error messages, essentially the system is inoperable. I need to ssh in and kill the X server, but then I no longer have access to the console window on the notebook. Software/Hardware configuration: The system is running kernel 2.6.5-3-686 and is running on an IBM Thinkpad r32 and uses Debian unstable. I have been running X fine until I upgraded to the newest version of the X files that include the "dfsg" extension. I attach a file of Debian packages installed on the system which are probably relevant in some way. Thanks for your attention to this bug. This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to XFree86@XFree86.Org and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs). XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-1 20040428170728 [EMAIL PROTECTED]) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.23 i686 [ELF] Build Date: 28 April 2004 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present OS Kernel: Linux version 2.6.5-1-686 ([EMAIL PROTECTED]) (gcc version 3.3.3 (Debian 20040401)) #1 Tue Apr 27 23:39:55 EST 2004 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Fri Apr 30 01:20:28 2004 (==) Using config file: "/etc/X11/XF86Config-4" (==) ServerLayout "Default Layout" (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "IBM LCD" (**) | |-->Device "ATI Radeon Mobility" (**) |-->Input Device "Generic Keyboard" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc104" (**) XKB: model: "pc104" (**) Option "XkbLayout" "us" (**) XKB: layout: "us" (==) Keyboard: CustomKeycode disabled (**) |-->Input Device "Configured Mouse" (**) |-->Input Device "Generic Mouse" (WW) The directory "/usr/lib/X11/fonts/TrueType" does not exist. Entry deleted from font path. (WW) `fonts.dir' not found (or not valid) in "/usr/share/fonts/truetype". Entry deleted from font path. (Run 'mkfontdir' on "/usr/share/fonts/truetype"). (**) FontPath set to "unix/:7100,/usr/lib/X11/fonts/Type1,/usr/share/fonts/type1/psfonts,/usr/lib/X11/fonts/Speedo,/usr/lib/X11/fonts/misc,/usr/lib/X11/fonts/cyrillic,/usr/lib/X11/fonts/100dpi,/usr/lib/X11/fonts/75dpi" (==) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (++) using VT number 7 (WW) Open APM failed (/dev/apm_bios) (No such device) (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="The XFree86 Project" compiled for 4.3.0.1, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: "pcidata" (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor="The XFree86 Project" compiled for 4.3.0.1, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x8002483c, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,1a30 card 1014,0521 rev 04 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,1a31 card , rev 04 class 06,04,00 hdr 01 (II) PCI: 00:1d:0: chip 8086,2482 card 1014,0521 rev 02 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,2484 card 1014,0521 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,2487 card 1014,0521 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1e:0: chip 8086,2448 card , rev 42 class 06,04,00 hdr 01 (II) PCI: 00:1f:0:
Re: Bug#246627: Radeon card firmware problem
reassign 246627 kernel-source-2.6.5 stop Hi all, On Fri, 30 Apr 2004, David Meggy wrote: > On startup it quickly kills my console and I never get an X-window > server. Logging in remotely and running dmesg, I get the following at > the end. [SNIP] > [drm] Initialized radeon 1.9.0 20020828 on minor 0 > agpgart: Found an AGP 2.0 compliant device at :00:00.0. > agpgart: Putting AGP V2 device at :00:00.0 into 1x mode > agpgart: Putting AGP V2 device at :01:00.0 into 1x mode > [drm:radeon_cp_load_microcode] *ERROR* Firmware file "r200_cp_microcode" not > available. [SNIP] > Other useful information: > I'm running Debian Sid, using the 2.6-k7 kernel > package, and this problem started after my daily > update this evening which would be the early hours of > April 30 GMT With the last X update, some non-free code has been revomed, and source patched accordingly. X itself does not handle the load of the microcode to the board, the kernel does (therefor i am reassigning the bug). For completness I did a check on the radeon code inside X and there is no reference to radeon_cp_load_microcode or similar calls. On the other side that can be spotted inside the kernel at: kernel-source-2.6.5-2.6.5/drivers/char/drm/radeon_cp.c:675 /* Load the microcode for the CP */ static void radeon_cp_load_microcode( drm_radeon_private_t *dev_priv ) [SNIP] that is called twice in the same file. Specifically at lines 1258 for radeon_do_init_cp and 1339 for radeon_do_resume_cp. X uses these two functions via ioctl but cannot disable the radeon_cp_load_microcode itself. Herbert, would you be so kind to take a look at this patch? --- radeon_cp.c.orig2004-04-30 06:50:24.0 + +++ radeon_cp.c 2004-04-30 06:51:02.0 + @@ -1255,7 +1255,7 @@ radeon_set_pcigart( dev_priv, 1 ); } - radeon_cp_load_microcode( dev_priv ); + /* radeon_cp_load_microcode( dev_priv ); */ radeon_cp_init_ring_buffer( dev, dev_priv ); dev_priv->last_buf = 0; @@ -1336,7 +1336,7 @@ radeon_set_pcigart( dev_priv, 1 ); } - radeon_cp_load_microcode( dev_priv ); + /* radeon_cp_load_microcode( dev_priv ); */ radeon_cp_init_ring_buffer( dev, dev_priv ); radeon_do_engine_reset( dev ); It should be able to fix the problem but i cannot test it myself since I lack that kind of hardware. Thanks a lot Fabio -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.
Bug#246643: _XPollfdCacheDel: select(s) forever when used with fglrx.
Package: libx11-6 Version: 4.3.0-7 Severity: normal (gdb) bt #0 0x403e3398 in select () from /lib/tls/libc.so.6 #1 0x4018de32 in _XPollfdCacheDel () from /usr/X11R6/lib/libX11.so.6 #2 0x4018eda1 in _XRead () from /usr/X11R6/lib/libX11.so.6 #3 0x4093c2d9 in s5943 () from /usr/X11R6/lib/modules/dri/fglrx_dri.so #4 0x40950593 in s3197 () from /usr/X11R6/lib/modules/dri/fglrx_dri.so #5 0x4094d984 in s3176 () from /usr/X11R6/lib/modules/dri/fglrx_dri.so #6 0x4094ccff in s5118 () from /usr/X11R6/lib/modules/dri/fglrx_dri.so #7 0x4094d02a in __driCreateScreen () from /usr/X11R6/lib/modules/dri/fglrx_dri.so #8 0x40123fda in AllocAndFetchScreenConfigs () from /usr/X11R6/lib/libGL.so.1 I also got this bt with DRI installed, but they do not replace libX11.so. (gdb) bt #0 0x4027d398 in select () from /lib/tls/libc.so.6 #1 0x40103e32 in _XPollfdCacheDel () from /usr/X11R6/lib/libX11.so.6 #2 0x40104da1 in _XRead () from /usr/X11R6/lib/libX11.so.6 #3 0x407dc2d9 in s5943 () from /usr/X11R6/lib/modules/dri/fglrx_dri.so #4 0x407f0593 in s3197 () from /usr/X11R6/lib/modules/dri/fglrx_dri.so #5 0x407ed984 in s3176 () from /usr/X11R6/lib/modules/dri/fglrx_dri.so #6 0x407eccff in s5118 () from /usr/X11R6/lib/modules/dri/fglrx_dri.so #7 0x407ed02a in __driCreateScreen () from /usr/X11R6/lib/libGL.so.1 -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (980, 'unstable'), (900, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.5-1-k7 Locale: LANG=C, LC_CTYPE=C Versions of packages libx11-6 depends on: ii libc6 2.3.2.ds1-12 GNU C Library: Shared libraries an ii xfree86-common 4.3.0-7 X Window System (XFree86) infrastr ii xlibs-data 4.3.0-7 X Window System client data -- no debconf information
Re: Bug#246627: Radeon card firmware problem
On Fri, Apr 30, 2004 at 08:53:41AM +0200, Fabio Massimo Di Nitto wrote: > It should be able to fix the problem but i cannot test it myself since I > lack that kind of hardware. I can test any of these patches, but I doubt stuff like 3D will work if this microcode is actually needed! This would be really, really, really bad if we can do neither 3D nor acceleration. If this is the case, and the GR goes ahead, IMO radeon_cp must be stuffed back in. Next time we need a more thorough analysis, not just 'I don't think this file gets used much anywhere'. That includes testing on the relevant hardware: I have a Radeon 9000 which can be used for testing Radeon stuff, but I just assumed it had been tested when it was asserted that it was thoroughly unnecessary. -- Daniel Stone<[EMAIL PROTECTED]> Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
Re: Bug#246627: Radeon card firmware problem
On Fri, 30 Apr 2004, Daniel Stone wrote: > On Fri, Apr 30, 2004 at 08:53:41AM +0200, Fabio Massimo Di Nitto wrote: > > It should be able to fix the problem but i cannot test it myself since I > > lack that kind of hardware. > > I can test any of these patches, Please do so! > but I doubt stuff like 3D will work if this microcode is actually > needed! This would be really, really, really bad if we can do neither 3D > nor acceleration. Yes these was mentioned on debian-x. Sorry i don't have the message reference handy. > Next time we need a more thorough analysis, not just 'I don't think this > file gets used much anywhere'. That includes testing on the relevant > hardware: I have a Radeon 9000 which can be used for testing Radeon > stuff, but I just assumed it had been tested when it was asserted that > it was thoroughly unnecessary. http://lists.debian.org/debian-x/2004/debian-x-200404/msg00955.html I did call for testers after we changed/removed the code from X but there have no replies to it. I assumed that noone had problems with it. Fabio -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.
Bug#246642: new Xfree86 in unstable crashes with ATI Radeon on IBM Thinkpad
On Fri, Apr 30, 2004 at 02:15:54AM -0400, Aron Trauring wrote: > When X starts up, it goes into an infinite loop, spewing out the > following error message in the log file endlessly, until / is filled up: > > (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 > (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 > (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 > (EE) RADEON(0): GetBuffer timed out, resetting engine... Oh my. I'm willing to bet this is another CP microcode issue; some cards are known to ship with bad firmware (IIRC), or exist in such a state that they're useless with microcode. This is all a mixture of IIRC and AIUI, and I'll try to test .dfsg when I get home (dialup sucks), but yeah. It looks like we've crippled radeon_drv. :( -- Daniel Stone<[EMAIL PROTECTED]> Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
Adding a keyboard to Xfree
Hi! Warning: This might be a packaging issue only. I developed my own keyboard mapping for XKB (based on my keyboard, however I did add a lot of fancy chars that I needed so type spanish, italian and other european languages on a regular basis via AltGr+key, I could fit in most of latin-9 charset). To have it work fully, I had to manually edit /etc/X11/xkb/symbols.dir. However, this means each upgrade is slightly annoying (asking me wether I want to replace .../symbols.dir with the provided version). I would also like to package my keyboard, to deploy it on a large number of computers. The modification of symbols.dir would therefore be unpractical and against the Debian packaging rules (no conffile should be modified by two packages). How could I solve this? Any idea? -- JCD
Processed: Re: Bug#246627: Radeon card firmware problem
Processing commands for [EMAIL PROTECTED]: > reassign 246627 kernel-source-2.6.5 Bug#246627: Radeon card firmware problem Bug reassigned from package `xserver-xfree86' to `kernel-source-2.6.5'. > stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: problem with left-handed mouse on X - is GPM to blame or is it X?
On Fri, 30 Apr 2004, Branden Robinson wrote: > [Zeph Hull dropped from Cc.] > > On Thu, Apr 29, 2004 at 12:29:35PM +0300, Martin-Éric Racine wrote: > > Greetings, > > > > Given how everyone in this family is left-handed, I recently got around > > inverting the order of the mouse buttons in GPM; works great in console. > > > > Since GPM is setup as a repeater for X, I thought that X would also end up > > defaulting to inverted button order, but it doesn't. > > > > I haven't found any option in X to configure the button order and Googling > > didn't tell me anything relevant about perhaps selecting a different > > protocol in > > GPM to get everything working in X the same way it does on console. > > > > Would anybody happen to have a cure for this? > > There is information in the Debian X FAQ about this. > > /usr/share/doc/xfree86-common/FAQ.gz > > http://necrotic.deadbeast.net/xsf/XFree86/trunk/debian/local/FAQ > > Please let us know if it is insufficient. 1) The information about using GPM's -B option is incorrect. As you can see from the enclosed configs, I already use -B 321, but this is ignored by X. 2) xmodmap has been broken since XFree 4.3.0. Any xmodmap receipe I had left from 4.2.1 either results in broken keyboard maps or in is simply ignored. Honnestly, the correct action would be for X to follow the button order configured for GPM. I really wonder why that fails. -- Martin-Éric Racine, ICT Consultant http://www.pp.fishpool.fi/~q-funk/
Re: x configuration process
[EMAIL PROTECTED] wrote: On Thu, Apr 29, 2004 at 08:30:17PM -0700, Nick Urban wrote: Why does X not attempt to configure itself automatically before asking the user questions? Depends on whether discover and friends are installed or not. Okay, well I'm pretty sure discover and friends are installed by default, and I was still prompted with questions during my sarge install. For some things I was given the option of auto-detection, but with the values it came up with for my monitor config, I seemed to be limited more than I should have been. The debconf configurator asks lots of questions that many users don't understand or care about. If the user does care, they can always just run `XFree86 -configure' and do some manual editing. Oh, and doing it that way subjects clueless users to LESS intimidating questions. Not. Branden's configuration method is pretty moron-friendly. The point I was trying to make is that there are basically two classes of users, those who know how to set up X and those who don't. The former don't need the debconf interface, and the latter don't understand it. I'm not suggesting that those who don't understand debconf would understand XF86Config. In any case, the system should at least try to autodetect everything and only prompt the user if it fails... is this currently what it does? Does X it normally autoconfigure when working correctly, or is this a bigger problem. If it is, can we just steal knoppix autoconfigure system? Please, no... can we have something that works, instead? All I know is that in my testing, it always worked with no hassles. In what way does knoppix autodetection not work? I'm not writing just to complain. There seem to be autodetection schemes out there that work, and I'd like to help Debian make use of them if possible. Nick
Bug#246663: xserver-xfree86: new version in sid won't start
Package: xserver-xfree86 Version: 4.3.0.dfsg.1-1 Severity: important Tags: sid Since my apt-get upgrade yesterday, X refuses to start with the message: *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. Fatal server error: Caught signal 11. Server aborting There were some message about symbols that couldn't be found. These had to do with GLCore and speedo. I reinstalled xserver-common and xserver-xfree86 and now these messages are gone, but X still refuses to start. Marco -- Package-specific info: Contents of /var/lib/xfree86/X.roster: xserver-xfree86 /var/lib/xfree86/X.md5sum does not exist. X server symlink status: lrwxrwxrwx1 root root 20 2002-02-12 16:50 /etc/X11/X -> /usr/bin/X11/XFree86 -rwxr-xr-x1 root root 1743788 2004-04-28 20:23 /usr/bin/X11/XFree86 Contents of /var/lib/xfree86/XF86Config-4.roster: xserver-xfree86 VGA-compatible devices on PCI bus: :01:05.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04) :01:05.0 Class 0300: 102b:0525 (rev 04) /var/lib/xfree86/XF86Config-4.md5sum does not exist. XFree86 X server configuration file status: -rw-r--r--1 root root 3123 2004-04-30 10:46 /etc/X11/XF86Config-4 Contents of /etc/X11/XF86Config-4: Section "ServerLayout" Identifier "Matrox PowerDesk configured." Screen "Display 1" 0 0 InputDevice"Generic Keyboard" InputDevice"Configured Mouse" EndSection Section "Files" FontPath "unix/:7100" FontPath "/usr/lib/X11/fonts/misc" FontPath "/usr/lib/X11/fonts/cyrillic" FontPath "/usr/lib/X11/fonts/100dpi/:unscaled" FontPath "/usr/lib/X11/fonts/75dpi/:unscaled" FontPath "/usr/lib/X11/fonts/Type1" FontPath "/usr/lib/X11/fonts/CID" # FontPath "/usr/lib/X11/fonts/Speedo" FontPath "/usr/lib/X11/fonts/100dpi" FontPath "/usr/lib/X11/fonts/75dpi" EndSection Section "Module" Load "bitmap" Load "dbe" Load "ddc" # Load "dri" Load "extmod" Load "freetype" # Load "glx" Load "int10" Load "record" # Load "speedo" Load "type1" Load "vbe" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xfree86" Option "XkbModel" "pc105" Option "XkbLayout" "de" Option "XkbVariant" "nodeadkeys" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device" "/dev/gpmdata" Option "Protocol" "IntelliMouse" Option "ZAxisMapping" "4 5" EndSection Section "Monitor" Identifier "Display 1" HorizSync30.0 - 96.0 VertRefresh 50.0 - 160.0 ModeLine "[EMAIL PROTECTED]:0" 147.6 1280 1368 1528 1728 960 970 973 1005 +hsync +vsync ModeLine "[EMAIL PROTECTED]:0" 94.5 1024 1088 1184 1376 768 769 772 808 +hsync +vsync ModeLine "[EMAIL PROTECTED]:0" 157.5 1280 1368 1528 1728 1024 1025 1028 1072 +hsync +vsync ModeLine "[EMAIL PROTECTED]:0(1)" 157.5 1280 1368 1528 1728 1024 1025 1028 1072 +hsync +vsync ModeLine "[EMAIL PROTECTED]:0(2)" 157.5 1280 1368 1528 1728 1024 1025 1028 1072 +hsync +vsync ModeLine "[EMAIL PROTECTED]:0(1)" 94.5 1024 1080 1176 1376 768 769 772 808 +hsync +vsync ModeLine "[EMAIL PROTECTED]:0" 56.3 800 840 904 1048 600 601 604 631 +hsync +vsync Option "DPMS" EndSection Section "Device" Identifier "MATROX CARD 1" Driver "mga" BusID "PCI:1:5:0" EndSection Section "Screen" Identifier "Display 1" Device "MATROX CARD 1" Monitor"Display 1" DefaultDepth 16 SubSection "Display" Depth 1 Modes"1280x960" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 4 Modes"1280x960" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 8 Modes"[EMAIL PROTECTED]:0" "1152x864" "[EMAIL PROTECTED]:0" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 15 Modes"1280x960" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 16 Modes"[EMAIL PROTECTED]:0" "1152x864" "[EMAIL PROTECTED]:0" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 24 Modes"[EMAIL PROT
Bug#246671: xserver-xfree86: Never gives up on CP GetBuffer.
Package: xserver-xfree86 Version: 4.3.0-7 Severity: normal I use :3 for my "GL Layout", I also cut back the logfile as it was 183MB. Fglrx workes fine with your Xserver. It's only when I try to run withought it that I think I need DRI's. I also use MergedFB, the DRI project is building out of Mesa CVS now so we may soon see the end of there 'X' binary and 2d drivers. It's important that we get all these intercompatibilitys sorted out, if only for the sake of consitancy. -- Package-specific info: Contents of /var/lib/xfree86/X.roster: xserver-xfree86 X server symlink status: lrwxrwxrwx1 root root 20 Oct 28 2003 /etc/X11/X -> /usr/bin/X11/XFree86 -rwxr-xr-x1 root root 1742316 Mar 17 23:42 /usr/bin/X11/XFree86 /etc/X11/X target unchanged from checksum in /var/lib/xfree86/X.md5sum. Contents of /var/lib/xfree86/XF86Config-4.roster: xserver-xfree86 VGA-compatible devices on PCI bus: :01:05.0 VGA compatible controller: ATI Technologies Inc Radeon R200 QL [Radeon 8500 LE] :01:05.0 Class 0300: 1002:514c XFree86 X server configuration file status: -rw-r--r--1 root root16758 Apr 30 03:27 /etc/X11/XF86Config-4 Contents of /etc/X11/XF86Config-4: Section "Files" RgbPath "/usr/X11R6/lib/X11/rgb" ModulePath "/usr/X11R6/lib/modules" FontPath "/usr/X11R6/lib/X11/fonts/misc" FontPath "/usr/X11R6/lib/X11/fonts/Type1" FontPath "/usr/X11R6/lib/X11/fonts/75dpi:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/100dpi:unscaled" FontPath "/usr/X11R6/lib/X11/fonts/75dpi" FontPath "/usr/X11R6/lib/X11/fonts/100dpi" EndSection Section "Module" Load "dbe" SubSection "extmod" Option"omit xfree86-dga" # don't initialise the DGA extension EndSubSection # Load "record" # Load "xtrap" Load "type1" Load "freetype" Load "glx" Load "dri" EndSection Section "DRI" Mode0660 Group "video" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xfree86" Option "XkbModel" "pc104" Option "XkbLayout" "us" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" Option "Device""/dev/input/mouse0" Option "Protocol" "ImPS/2" Option "ZAxisMapping" "4 5" EndSection Section "Monitor" # EDID version 1 revision 2 # Block type: 2:0 3:ff # Block type: 2:0 3:fd # Block type: 2:0 3:fc Identifier "PF775" VendorName "VSC" ModelName "PF775" # Block type: 2:0 3:ff # Block type: 2:0 3:fd HorizSync 25-97 VertRefresh 50-180 # Max dot clock (video bandwidth) 200 MHz # Added by Cheako DisplaySize 330 240 # Block type: 2:0 3:fc # DPMS capabilities: Active off:yes Suspend:yes Standby:yes Mode"1024x768" # vfreq 84.997Hz, hfreq 68.677kHz DotClock94.50 HTimings1024 1072 1168 1376 VTimings768 769 772 808 Flags "+HSync" "+VSync" EndMode # Block type: 2:0 3:ff # Block type: 2:0 3:fd # Block type: 2:0 3:fc # Added for NES and other emulators. Mode"[EMAIL PROTECTED]" # vfreq 60Hz, hfreq 30.68kHz DotClock21.96 HTimings256 276 316 352 VTimings240 244 249 257 Flags "doublescan" EndMode Mode"[EMAIL PROTECTED]" # vfreq 120Hz, hfreq 61.01kHz DotClock10.31 HTimings256 280 296 336 VTimings240 241 244 253 Flags "doublescan" EndMode EndSection Section "Monitor" # EDID version 1 revision 1 # Block type: 2:0 3:ff # Block type: 2:0 3:fc Identifier "CPD-200ES" VendorName "SNY" ModelName "CPD-200ES" # Block type: 2:0 3:ff # Block type: 2:0 3:fc # Block type: 2:0 3:fd DisplaySize 330 240 HorizSync 30-70 VertRefresh 50-120 # Max dot clock not given # DPMS capabilities: Active off:yes Suspend:yes Standby:yes Mode"640x480" # vfreq 59.952Hz, hfreq 31.475kHz DotClock25.18 HTimings640 656 752 800 VTimings480 490 492 525 Flags "-HSync" "-VSync" EndMode # Block type: 2:0 3:ff # Block type: 2:0 3:fc # Block type: 2:0
If X refuses to start with Radeon chip...
Then please upgrade your kernel to 2.6.5-4 or above.
The 2.6.5-3 release contained code which attempted to load firmware
for Radeon/R128 from userspace that fails miserably when the firmware
files aren't available.
This has been reverted for now.
I apologise for any inconvenience caused.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: problem with left-handed mouse on X - is GPM to blame or is it X?
On Thu, Apr 29, 2004 at 12:29:35PM +0300, Martin-?ric Racine wrote: > Greetings, > > Given how everyone in this family is left-handed, I recently got around > inverting the order of the mouse buttons in GPM; works great in console. > > Since GPM is setup as a repeater for X, I thought that X would also end up > defaulting to inverted button order, but it doesn't. > > repeat_type=raw > type=imps2 > Section "InputDevice" > Option "Device""/dev/gpmdata" > Option "Protocol" "ImPS/2" > EndSection This is user error. The raw repeat type is something that I am beginning to think is more of a bug then a feature, it does a byte for byte repeat, making no changes to the byte stream. Further more, it seems to be most commonly used with the PS/2 protocols, which, is another rant about two-way communications on a FIFO. Kill the repeat type, have X read from /dev/input/mice as well, and use xmodmap in your ~/.xsession. -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. So, you are thinking am Communist ? Deal, Comerade ! -- Chris on ASR. signature.asc Description: Digital signature
Re: X and 2.6.5 kernel: update of 2.6.5 kernel locks my laptop
On April 30, 2004 06:00 am, Branden Robinson wrote: > On Thu, Apr 29, 2004 at 09:14:58AM +, slaven peles wrote: > > Apr 29 08:25:01 ivor kernel: atkbd.c: Unknown key released (translated > > set 2, code 0x7a on isa0060/serio0). > > Apr 29 08:25:01 ivor kernel: atkbd.c: This is an XFree86 bug. It > > shouldn't access hardware directly. > > Apr 29 08:25:01 ivor kernel: atkbd.c: Unknown key released (translated > > set 2, code 0x7a on isa0060/serio0). > > Apr 29 08:25:01 ivor kernel: atkbd.c: This is an XFree86 bug. It > > shouldn't access hardware directly. > > On Thu, Apr 29, 2004 at 10:54:24AM -0500, Diego Enrique Rodriguez wrote: > > I have same problem look my log in > > http://uvirtual.ean.edu.co/~derodriguez/kernelprob/XFree86.0.log > > On Thu, Apr 29, 2004 at 03:52:18PM -0400, Josh Metzler wrote: > > This happens to me, too - Radeon 7000, same kernel. I filed bug #246587 > > against kernel-image-2.6.5-1-686. > > Hi guys, > > This should be fixed in the version of XFree86 that entered sid on 29 > April. > > xfree86 (4.3.0.dfsg.1-1) unstable; urgency=low > [...] > * Fix AT keyboard rate I/O controls by operating on the actual console > file descriptor, not on file descriptor zero (thanks, Keith Packard). > Suppresses warning messages from Linux 2.6. (Closes: #224909) [...] > -- Fabio M. Di Nitto <[EMAIL PROTECTED]> Wed, 28 Apr 2004 18:55:17 > +0200 I checked my older logs and this error message showed up before. So this bug appears to be benign. It seems that the problem here is that Radeon firmware was removed from kernel. In README.Debian.1st file that comes with kernel-image package I found this: Non-free bits removed: (...) * R128 firmware: . drivers/char/drm/r128_cce.c * Radeon firmware: . drivers/char/drm/radeon_cp.c No workaround was suggested, and there was no warning about possible consequences. Perhaps using kernel modules from Michael Daenzer's repository would be a good transitional solution? Alternatively, one can always turn off dri. Cheers, Slaven
Re: Re: Bug#246627: Radeon card firmware problem
On Fri, 30 Apr 2004, Fabio Massimo Di Nitto wrote: On Fri, 30 Apr 2004, Daniel Stone wrote: On Fri, Apr 30, 2004 at 08:53:41AM +0200, Fabio Massimo Di Nitto wrote: > It should be able to fix the problem but i cannot test it myself since I > lack that kind of hardware. I can test any of these patches, Please do so! but I doubt stuff like 3D will work if this microcode is actually needed! This would be really, really, really bad if we can do neither 3D nor acceleration. Yes these was mentioned on debian-x. Sorry i don't have the message reference handy. Next time we need a more thorough analysis, not just 'I don't think this file gets used much anywhere'. That includes testing on the relevant hardware: I have a Radeon 9000 which can be used for testing Radeon stuff, but I just assumed it had been tested when it was asserted that it was thoroughly unnecessary. http://lists.debian.org/debian-x/2004/debian-x-200404/msg00955.html I did call for testers after we changed/removed the code from X but there have no replies to it. I assumed that noone had problems with it. Fabio This is not a problem with the new XFree86. It works fine with Debian kernel version 2.6.5-2. Non-free firmware was also pulled from the Debian kernel starting in version 2.6.5-3, and that is what causes this problem. See bug #246587 against kernel-image-2.6.5-1-686. It would be nice, though, if X didn't lockup using 100% cpu in this situation. Josh
Bug#240581: Did you forget about this patch?
Hi!
I thought this patch would be applied on the new upload, but it seems it
wasn't, I have reworked it again so that it applies well against the new
packages and I'm sending it again to see if we have better luck next time
;-)
Regards...
--
Manty/BestiaTester -> http://manty.net
diff -r -u xc.orig/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c
xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c
--- xc.orig/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c
2004-04-30 14:04:58.0 +0200
+++ xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c 2004-04-30
13:59:44.0 +0200
@@ -149,7 +149,8 @@
OPTION_CLONE_HSYNC,
OPTION_CLONE_VREFRESH,
OPTION_FBDEV,
-OPTION_VIDEO_KEY
+OPTION_VIDEO_KEY,
+OPTION_MIN_DOTCLOCK
} RADEONOpts;
const OptionInfoRec RADEONOptions[] = {
@@ -180,6 +181,7 @@
{ OPTION_CLONE_VREFRESH, "CloneVRefresh",OPTV_ANYSTR, {0}, FALSE },
{ OPTION_FBDEV, "UseFBDev", OPTV_BOOLEAN, {0}, FALSE },
{ OPTION_VIDEO_KEY, "VideoKey", OPTV_INTEGER, {0}, FALSE },
+{ OPTION_MIN_DOTCLOCK, "ForceMinDotClock", OPTV_FREQ,{0}, FALSE },
{ -1,NULL, OPTV_NONE,{0}, FALSE }
};
@@ -1728,6 +1730,7 @@
RADEONPLLPtr pll = &info->pll;
CARD16 bios_header;
CARD16 pll_info_block;
+double min_dotclock;
if (!info->VBIOS) {
@@ -1782,6 +1785,26 @@
pll->xclk = RADEON_BIOS16(pll_info_block + 0x08);
}
+/* (Some?) Radeon BIOSes seem too lie about their minimum dot
+ * clocks. Allow users to override the detected minimum dot clock
+ * value (e.g., and allow it to be suitable for TV sets).
+ */
+if (xf86GetOptValFreq(info->Options, OPTION_MIN_DOTCLOCK,
+ OPTUNITS_MHZ, &min_dotclock)) {
+ if (min_dotclock < 12 || min_dotclock*100 >= pll->max_pll_freq) {
+ xf86DrvMsg(pScrn->scrnIndex, X_INFO,
+ "Illegal minimum dotclock specified %.2f MHz "
+ "(option ignored)\n",
+ min_dotclock);
+ } else {
+ xf86DrvMsg(pScrn->scrnIndex, X_INFO,
+ "Forced minimum dotclock to %.2f MHz "
+ "(instead of detected %.2f MHz)\n",
+ min_dotclock, ((double)pll->min_pll_freq/1000));
+ pll->min_pll_freq = min_dotclock * 1000;
+ }
+}
+
xf86DrvMsg(pScrn->scrnIndex, X_INFO,
"PLL parameters: rf=%d rd=%d min=%d max=%d; xclk=%d\n",
pll->reference_freq,
diff -r -u xc.orig/programs/Xserver/hw/xfree86/drivers/ati/radeon.man
xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.man
--- xc.orig/programs/Xserver/hw/xfree86/drivers/ati/radeon.man 2004-04-30
14:04:58.0 +0200
+++ xc/programs/Xserver/hw/xfree86/drivers/ati/radeon.man 2004-04-30
13:59:44.0 +0200
@@ -235,6 +235,17 @@
but not work correctly in some rare cases, hence the default is
.B off.
+.TP
+.BI "Option \*qForceMinDotClock\*q \*q" frequency \*q
+Override minimum dot clock. Some Radeon BIOSes report a minimum dot
+clock unsuitable (too high) for use with television sets even when they
+actually can produce lower dot clocks. If this is the case you can
+override the value here.
+.B Note that using this option may damage your hardware.
+You have been warned. The
+.B frequency
+parameter may be specified as a float value with standard suffixes like
+"k", "kHz", "M", "MHz".
.SH SEE ALSO
XFree86(1), XF86Config(__filemansuffix__), xf86config(1), Xserver(1),
X(__miscmansuffix__)
Re: Re: X and 2.6.5 kernel: update of 2.6.5 kernel locks my laptop
On Fri, 30 Apr 2004, Branden Robinson wrote: On Thu, Apr 29, 2004 at 09:14:58AM +, slaven peles wrote: Apr 29 08:25:01 ivor kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0). Apr 29 08:25:01 ivor kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly. Apr 29 08:25:01 ivor kernel: atkbd.c: Unknown key released (translated set 2, code 0x7a on isa0060/serio0). Apr 29 08:25:01 ivor kernel: atkbd.c: This is an XFree86 bug. It shouldn't access hardware directly. On Thu, Apr 29, 2004 at 10:54:24AM -0500, Diego Enrique Rodriguez wrote: I have same problem look my log in http://uvirtual.ean.edu.co/~derodriguez/kernelprob/XFree86.0.log On Thu, Apr 29, 2004 at 03:52:18PM -0400, Josh Metzler wrote: This happens to me, too - Radeon 7000, same kernel. I filed bug #246587 against kernel-image-2.6.5-1-686. Hi guys, This should be fixed in the version of XFree86 that entered sid on 29 April. xfree86 (4.3.0.dfsg.1-1) unstable; urgency=low [...] * Fix AT keyboard rate I/O controls by operating on the actual console file descriptor, not on file descriptor zero (thanks, Keith Packard). Suppresses warning messages from Linux 2.6. (Closes: #224909) [...] -- Fabio M. Di Nitto <[EMAIL PROTECTED]> Wed, 28 Apr 2004 18:55:17 +0200 Thanks, but slaven misdiagnosed the cause of the problem. These atkbd.c errors are unrelated to it (though may be the errors Diego was talking about). The removal of the non-free radeon firmware from the kernel causes the X server to lock up using 100% cpu (and to fill up XFree86.0.log with error messages). I was able to ssh into my box and reboot it, so using the power button is not necessary if you can connect remotely. See bug #246587 against kernel-image-2.6.5-1-686 for more details. Josh
Bug#11147: buldge? 6/6/00
ESMTP id DADAF63099 for <[EMAIL PROTECTED]>; Fri, 23 Apr 2004 22:15:42 -0400 (EDT) Received: from mail.yahoo.com ([170.196.247.4]) by localhost (targa.yahoo.com [82.222.22.208]) (amavisd-new, port 10003) with ESMTP id 26931-08 for <[EMAIL PROTECTED]>; Fri, 23 Apr 2004 22:15:42 -0400 (EDT) Received: from spm (Ottawa-ppp-199508.yahoo.com [244.108.50.206])by mail.yahoo.com (Postfix) with ESMTP id D8CCD44203for <[EMAIL PROTECTED]>; Fri, 23 Apr 2004 22:04:45 -0400 (EDT) X-Message-Info: JGTYoYF28jHYfowwei7Kx0KRaH09kJr0 Message-Id: <[EMAIL PROTECTED]> X-Virus-Scanned: by amavisd-new at yahoo.com Return-Path: [EMAIL PROTECTED] X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-OriginalArrivalTime: 30 Apr 2004 08:68:42.0870 (UTC) FILETIME=[D9F1CAA0:00C428DA] Hello, You application has been approved for extended auto war ranty coverage. Your 24 hour service will with no limits begins very soon. Please finish the 15 second post app lication. You will never have to worry about vehicle problems again with us by your side. Thank you. Travis T. Jenkins Auto Warr anty Associate http://superiorautowarranty.com/auto/?partid=dmps If you feel that you are rece iving this ema il in err or or would like to modify your fut ure pre ferences, please visit: http://superiorautowarranty.com/st.html converge delusive axial disgruntle speedup djakarta vivacity barb incinerate atrocity corrigendum allege fob brown allyl circulatory withdrew coleman exposition walcott b's euripides flown ethology macabre marlin cardiac alphameric music filmstrip facto am
Re: X and 2.6.5 kernel: update of 2.6.5 kernel locks my laptop
On April 30, 2004 06:00 am, Branden Robinson wrote: > On Thu, Apr 29, 2004 at 09:14:58AM +, slaven peles wrote: > > Apr 29 08:25:01 ivor kernel: atkbd.c: Unknown key released (translated > > set 2, code 0x7a on isa0060/serio0). > > Apr 29 08:25:01 ivor kernel: atkbd.c: This is an XFree86 bug. It > > shouldn't access hardware directly. > > Apr 29 08:25:01 ivor kernel: atkbd.c: Unknown key released (translated > > set 2, code 0x7a on isa0060/serio0). > > Apr 29 08:25:01 ivor kernel: atkbd.c: This is an XFree86 bug. It > > shouldn't access hardware directly. > > On Thu, Apr 29, 2004 at 10:54:24AM -0500, Diego Enrique Rodriguez wrote: > > I have same problem look my log in > > http://uvirtual.ean.edu.co/~derodriguez/kernelprob/XFree86.0.log > > On Thu, Apr 29, 2004 at 03:52:18PM -0400, Josh Metzler wrote: > > This happens to me, too - Radeon 7000, same kernel. I filed bug #246587 > > against kernel-image-2.6.5-1-686. > > Hi guys, > > This should be fixed in the version of XFree86 that entered sid on 29 > April. > > xfree86 (4.3.0.dfsg.1-1) unstable; urgency=low > [...] > * Fix AT keyboard rate I/O controls by operating on the actual console > file descriptor, not on file descriptor zero (thanks, Keith Packard). > Suppresses warning messages from Linux 2.6. (Closes: #224909) [...] > -- Fabio M. Di Nitto <[EMAIL PROTECTED]> Wed, 28 Apr 2004 18:55:17 > +0200 I checked this again and it's definitely a firmware issue. Thanks to Michael Daenzer there is an easy fix for this. Download and install drm-trunk-module-src package from http://people.debian.org/~daenzer/dri-trunk-sid/ as well as appropriate kernel-headers-2.6.5 package. Then follow standard procedure (as a root): cd /usr/src tar xvfz drm-trunk.tar.gz export KVERS=2.6.5-XXX export KSRC=/usr/src/kernel-headers-2.6.5-XXX cd modules/drm-trunk debian/rules kdist_image This creates drm-trunk-module...deb package in /usr/src directory, which can be easily installed with dpkg -i (no --force-overwrite necessary). At least, this worked for me ;-). Cheers, Slaven
Re: Bug#246627: Radeon card firmware problem
On Fri, 2004-04-30 at 09:09, Daniel Stone wrote: > On Fri, Apr 30, 2004 at 08:53:41AM +0200, Fabio Massimo Di Nitto wrote: > > It should be able to fix the problem but i cannot test it myself since I > > lack that kind of hardware. > > I can test any of these patches, but I doubt stuff like 3D will work if > this microcode is actually needed! It is, so the patch is completely bogus. > This would be really, really, really bad if we can do neither 3D nor > acceleration. If this is the case, and the GR goes ahead, IMO radeon_cp > must be stuffed back in. It still wouldn't be used at all in the xfree86 build... The r128 and radeon 2D drivers don't deal gracefully with the DRM failing to load the firmware. That's a bug which has been fixed at least in the radeon driver in DRI CVS. I suggest those who insisted on inconveniencing users by crippling the kernel-image packages dig up the fix and provide it to the XSF. Alternatively, they could provide the microcode in a convenient way. Of course, people can also use non-Debian kernels or drm-trunk-module-src, which still have the microcode built in. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Bug#246642: new Xfree86 in unstable crashes with ATI Radeon on IBM Thinkpad
On Fri, 2004-04-30 at 09:10, Daniel Stone wrote: > On Fri, Apr 30, 2004 at 02:15:54AM -0400, Aron Trauring wrote: > > When X starts up, it goes into an infinite loop, spewing out the > > following error message in the log file endlessly, until / is filled up: > > > > (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 > > (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 > > (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 > > (EE) RADEON(0): GetBuffer timed out, resetting engine... > > Oh my. I'm willing to bet this is another CP microcode issue; some cards > are known to ship with bad firmware (IIRC), or exist in such a state > that they're useless with microcode. The cards don't ship any microcode, and the DRM doesn't work without it. > This is all a mixture of IIRC and AIUI, and I'll try to test .dfsg when > I get home (dialup sucks), but yeah. It looks like we've crippled > radeon_drv. :( No, Herbert has crippled the kernel packages. Of course, the DDX drivers could deal better with this, at least the radeon driver does in DRI CVS. I could dig up a patch, but I'd prefer if those who insisted on crippling things did... -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Bug#246642: Workaround
I don't think this is necessarily a bug in the new xserver-xfree86. I had this same problem, and tried downgrading xfree86. After successfully downgrading I still got the same problem. A little poking around showed that kernel-image-2.6.5-1-k7_2.6.5-3_i386.deb came in on the same day as the xfree upgrade. Dropping back to an older kernel fixed the problem (even after upgrading to the latest xfree86, the problem stayed fixed on the older kernel). I suspect this is actually a bug in kernel 2.6.5-3. Ed
Re: Bug#240581: Did you forget about this patch?
On Fri, 30 Apr 2004, Santiago Garcia Mantinan wrote: > Hi! > > I thought this patch would be applied on the new upload, but it seems it > wasn't, I have reworked it again so that it applies well against the new > packages and I'm sending it again to see if we have better luck next time > ;-) Hi, no it is scheduled for the next upload [1]. Thanks for rediffing it again. Fabio [1] http://lists.debian.org/debian-x/2004/debian-x-200404/msg01214.html -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.
Re: If X refuses to start with Radeon chip...
Hi Herbert, On Fri, 30 Apr 2004, Herbert Xu wrote: > Then please upgrade your kernel to 2.6.5-4 or above. > > The 2.6.5-3 release contained code which attempted to load firmware > for Radeon/R128 from userspace that fails miserably when the firmware > files aren't available. > > This has been reverted for now. > > I apologise for any inconvenience caused. Thanks a lot for your incredibly fast response to this issue. Fabio -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.
Re: Start preparing xfree86 4.3.0.dfsg.1-2
On Fri, 30 Apr 2004, Branden Robinson wrote:
> On Thu, Apr 29, 2004 at 07:56:06AM +0200, Fabio Massimo Di Nitto wrote:
> > Hi all,
> > a few hours ago 4.3.0.dfsg.1-1 has been uploaded and it will hit
> > the mirrors within tomorrow.
>
> Hats off, Fabio! You have my deepest thanks for handling this
> responsibility, and handling it well.
Well thanks also to all your work in cleaning up my logs and errors here
and there ;)
> > >From the TODO list, I think we should proceed in the following order of
> > priorities:
> >
> > - ---> subliminal message: fix whatever I broke with 4.3.0.dfsg.1-1 <---
The ATI/radeon problem has been fixed by Herbert already in the new kernel
upload -4. We need to investigate the mga driver to verify who needs to
work on it.
> There are some reports trickling in that the damn kernel 2.6 "This is a
> bug in XFree86. This is a bug in XFree86. This is a bug in XFree86.
> This is a bug in XFree86." problem isn't truly resolved.
>
> We'll have to wait and see how that develops. Not your fault in any
> case.
The one i saw was still to 4.3.0-7, but i went trough it very very fast.
> > * steal {U,}XTerm* app-defaults updates from HEAD and resync patches
>
> I think I will pull from Thomas (Dickey's) releases instead. With
> XFree86 (implicitly) slapping their new license on all the Imakefiles, I
> don't feel like messing with upstream CVS.
[SNIP]
agreed. more we stay away from the licence mess better is.
> > * Fix upstream install rule that prevents Xcursor themes from being
> > installed on s390. As I understand it, this is client-side stuff and
> > there's not really any reason it shouldn't be made available on the s390
> > architecture.
> >
> > * Fix other gratuitous differences between s390 debehlper files and the
> > generic ones by fixing upstream Imakeage to not turn extra stuff off when
> > the XFree86 X server is not being built (like xmodmap.std). It ships
> > libXxf86vm.a but not the corresponding manpages.
>
> Be warned; I know my way around Imake fairly well by now (though I'm hardly an
> expert), but the above could be time consuming. I think we should be
> prepared to defer these in favor either of other fixes or just getting
> the release out the door.
Sure. Mine is just a list. We will do as much as we can. Also removing or
postponing items if required.
More generally, I would like that people read my messages as a direction
to go, but not a strict rule to follow.
> > For this release, other than the 4 bug fixes, we will work mainly on
> > resync and cleanup. If -1 and -2 will not show big problems we might want
> > to consider slightly bigger changes for -3, like the rewrite
> > xserver-xfree86 debconfage. Time will tell.
>
> Yeah, I'm not quite ready for a commit of the stuff I've got in my
> working copy.
Do you have a branch for it? or only a local copy?
> See above. As I feared, David Dawes has not replied to my request for a
> clarification on what the heck is going on with this "implicit relicense
> even if neither the file nor the commit message say so" business, so I
> think that everything failing the criteria I outlined above needs to be
> regarded as poisonous.
agreed.. as above ;)
Thanks
Fabio
--
fajita: step one
Whatever the problem, step one is always to look in the error log.
fajita: step two
When in danger or in doubt, step two is to scream and shout.
Re: Start preparing xfree86 4.3.0.dfsg.1-2
On Fri, 2004-04-30 at 17:16, Fabio Massimo Di Nitto wrote: > > The ATI/radeon problem has been fixed by Herbert already in the new kernel > upload -4. Let me point out again that there is actually a bug in the xserver-xfree86 r128 and radeon drivers: they don't deal gracefully with the DRI initialisation failing late in the game. However, IMHO it's the responsibility of the people who want to remove the firmware from the kernel packages to fix this, as this bug is very unlikely to trigger otherwise (basically takes a buggy DRM). -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: Start preparing xfree86 4.3.0.dfsg.1-2
On Fri, 30 Apr 2004, Michel D�nzer wrote: > On Fri, 2004-04-30 at 17:16, Fabio Massimo Di Nitto wrote: > > > > The ATI/radeon problem has been fixed by Herbert already in the new kernel > > upload -4. > > Let me point out again that there is actually a bug in the > xserver-xfree86 r128 and radeon drivers: they don't deal gracefully with > the DRI initialisation failing late in the game. However, IMHO it's the > responsibility of the people who want to remove the firmware from the > kernel packages to fix this, as this bug is very unlikely to trigger > otherwise (basically takes a buggy DRM). Yes I understand that. Would that bug shows up again in other situations other than this one? I read in another message that you can dig out a patch for this problem. Would you mind to post it here? Thanks Fabio -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.
Re: Bug#246642: new Xfree86 in unstable crashes with ATI Radeon on IBM Thinkpad
Hi, as pointed already by Michel and Herbert, you need to upgrade your kernel to -4. I am closing this bug since it is fixed already. Fabio -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.
Bug#246642: new Xfree86 in unstable crashes with ATI Radeon on IBM Thinkpad
I also tried downgrading to a 2.6.4 version of the kernel, and it is now working fine, so it is definitely a 2.6.5-3 kernel bug, since I upgraded to that simultaneously. In fact, now that I think of it, I restarted X once after upgrade and it work. The problem only started when I rebooted, so got new kernel. Should I report bug to the kernel package, or will it get passed along internally? -- Aron Trauring Zoteca http://www.zoteca.com/
Re: Bug#246642: new Xfree86 in unstable crashes with ATI Radeon on IBM Thinkpad
On Fri, 30 Apr 2004, Aron Trauring wrote: > I also tried downgrading to a 2.6.4 version of the kernel, and it is now > working fine, so it is definitely a 2.6.5-3 kernel bug, since I upgraded > to that simultaneously. In fact, now that I think of it, I restarted X > once after upgrade and it work. The problem only started when I > rebooted, so got new kernel. Should I report bug to the kernel package, > or will it get passed along internally? The kernel package maintainer already uploaded 2.6.5-4 with proper fixes. Fabio -- fajita: step one Whatever the problem, step one is always to look in the error log. fajita: step two When in danger or in doubt, step two is to scream and shout.
Bug#246642: marked as done (new Xfree86 in unstable crashes with ATI Radeon on IBM Thinkpad)
Your message dated Fri, 30 Apr 2004 18:53:26 +0200 (CEST) with message-id <[EMAIL PROTECTED]> and subject line Bug#246642: new Xfree86 in unstable crashes with ATI Radeon on IBM Thinkpad has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 30 Apr 2004 06:15:59 + >From [EMAIL PROTECTED] Thu Apr 29 23:15:59 2004 Return-path: <[EMAIL PROTECTED]> Received: from maximam.com [198.49.126.86] by spohr.debian.org with smtp (Exim 3.35 1 (Debian)) id 1BJRJW-jr-00; Thu, 29 Apr 2004 23:15:59 -0700 Received: (qmail 29177 invoked from network); 30 Apr 2004 06:15:54 - Received: from unknown (HELO zoteca.com) (66.108.215.85) by maximam.com with SMTP; 30 Apr 2004 06:15:54 - Message-ID: <[EMAIL PROTECTED]> Date: Fri, 30 Apr 2004 02:15:54 -0400 From: Aron Trauring <[EMAIL PROTECTED]> User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: [EMAIL PROTECTED] Subject: new Xfree86 in unstable crashes with ATI Radeon on IBM Thinkpad Content-Type: multipart/mixed; boundary="040004020804070503040204" Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,DATING,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2004_03_25 X-Spam-Level: X-CrossAssassin-Score: 1 This is a multi-part message in MIME format. --040004020804070503040204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Package: xserver-xfree86 Version: 4.3.0.dfsg.1-1 Severity: critical Description of problem: When X starts up, it goes into an infinite loop, spewing out the following error message in the log file endlessly, until / is filled up: (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 (EE) RADEON(0): GetBuffer timed out, resetting engine... The full log file is attached (I delete the endless reptitions so file will be of reasonable size). Also attached please find the XFree86 configuration file. Since my system is configured to start gdm upon boot-up, and since this causes an infinite loop of error messages, essentially the system is inoperable. I need to ssh in and kill the X server, but then I no longer have access to the console window on the notebook. Software/Hardware configuration: The system is running kernel 2.6.5-3-686 and is running on an IBM Thinkpad r32 and uses Debian unstable. I have been running X fine until I upgraded to the newest version of the X files that include the "dfsg" extension. I attach a file of Debian packages installed on the system which are probably relevant in some way. Thanks for your attention to this bug. --040004020804070503040204 Content-Type: text/plain; name="XFree86.0.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="XFree86.0.log" This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to XFree86@XFree86.Org and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs). XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-1 20040428170728 [EMAIL PROTECTED]) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.23 i686 [ELF] Build Date: 28 April 2004 Before reporting problems, check http://www.XFree86.Org/ to make sure that you have the latest version. Module Loader present OS Kernel: Linux version 2.6.5-1-686 ([EMAIL PROTECTED]) (gcc version 3.3.3 (Debian 20040401)) #1 Tue Apr 27 23:39:55 EST 2004 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Fri Apr 30 01:20:28 2004 (==) Using config file: "/etc/X11/XF86Config-4" (==) ServerLayout "Default Layout" (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "IBM LCD" (**) | |-->Device "ATI Radeon Mobility" (**) |-->Input Device "Generic Keyboard" (**) Option "XkbRules" "xfree86" (**) XKB: rules: "xfree86" (**) Option "XkbModel" "pc10
Processed: Radeon firmware issue is not an XFree86 bug
Processing commands for [EMAIL PROTECTED]: > reassign 246642 kernel-source-2.6.5 Bug#246642: new Xfree86 in unstable crashes with ATI Radeon on IBM Thinkpad Bug reassigned from package `xserver-xfree86' to `kernel-source-2.6.5'. > reassign 246671 kernel-source-2.6.5 Bug#246671: xserver-xfree86: Never gives up on CP GetBuffer. Bug reassigned from package `xserver-xfree86' to `kernel-source-2.6.5'. > severity 246627 normal Bug#246627: Radeon card firmware problem Severity set to `normal'. > severity 246642 normal Bug#246642: new Xfree86 in unstable crashes with ATI Radeon on IBM Thinkpad Severity set to `normal'. > severity 246671 normal Bug#246671: xserver-xfree86: Never gives up on CP GetBuffer. Severity set to `normal'. > merge 246627 246642 246671 Bug#246627: Radeon card firmware problem Bug#246642: new Xfree86 in unstable crashes with ATI Radeon on IBM Thinkpad Bug#246671: xserver-xfree86: Never gives up on CP GetBuffer. Mismatch - only Bugs in same state can be merged: Values for `done mark' don't match: #246627 has `done'; #246671 has `open' > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
X Strike Force XFree86 SVN commit: r1341 - people/branden
Author: branden Date: 2004-04-30 13:37:08 -0500 (Fri, 30 Apr 2004) New Revision: 1341 Removed: people/branden/lintian-overrides/ Log: Remove unused personal branch.
X Strike Force XFree86 SVN commit: r1342 - people/branden
Author: branden Date: 2004-04-30 13:40:55 -0500 (Fri, 30 Apr 2004) New Revision: 1342 Removed: people/branden/xlibs-and-xbase-clients-split/ Log: Remove no-longer-needed private branch. The xlibs split was completed and merged onto the trunk long ago, and the xbase-clients split has not been started, and its future is uncertain.
Re: Start preparing xfree86 4.3.0.dfsg.1-2
On Fri, 2004-04-30 at 18:48, Fabio Massimo Di Nitto wrote: > On Fri, 30 Apr 2004, Michel Dnzer wrote: > > > On Fri, 2004-04-30 at 17:16, Fabio Massimo Di Nitto wrote: > > > > > > The ATI/radeon problem has been fixed by Herbert already in the new kernel > > > upload -4. > > > > Let me point out again that there is actually a bug in the > > xserver-xfree86 r128 and radeon drivers: they don't deal gracefully with > > the DRI initialisation failing late in the game. However, IMHO it's the > > responsibility of the people who want to remove the firmware from the > > kernel packages to fix this, as this bug is very unlikely to trigger > > otherwise (basically takes a buggy DRM). > > Yes I understand that. Would that bug shows up again in other situations > other than this one? I read in another message that you can dig out a > patch for this problem. Would you mind to post it here? http://penguinppc.org/~daenzer/DRI/applied/radeon-accelinit.diff is the radeon fix. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
X Strike Force XFree86 SVN commit: r1343 - branches
Author: branden Date: 2004-04-30 13:44:06 -0500 (Fri, 30 Apr 2004) New Revision: 1343 Added: branches/lintian-cleanup/ Log: Create branch for collaborative work on cleaning up the xfree86 packages' lintian warnings and errors (both overrides and fixes are acceptable). Copied: branches/lintian-cleanup (from rev 1342, trunk)
Debian, programs for you.
Top of the morning to you! :)Love is a chain of love as nature is a chain of life. Searching for not expensive high-quality software? Our site might be just what you need.http://seminecessary.dbsoft.biz We offer Software to download or it can be shipped to you on CD. And more!We can ship worldwide.What a fool does in the end, the wise do in the beginning.Life without industry is guilt. Industry without Art is Brutality.
X Strike Force XFree86 SVN commit: r1344 - trunk/debian
Author: fabbione Date: 2004-04-30 14:05:47 -0500 (Fri, 30 Apr 2004) New Revision: 1344 Modified: trunk/debian/changelog Log: Make possible to upgrade from SVN to the next release and fix a FTBFS in binary: target. dpkg-deb wants at least one digit in Debian revision. Modified: trunk/debian/changelog === --- trunk/debian/changelog 2004-04-30 18:44:06 UTC (rev 1343) +++ trunk/debian/changelog 2004-04-30 19:05:47 UTC (rev 1344) @@ -1,4 +1,4 @@ -xfree86 (4.3.0.dfsg.1-SVN) unstable; urgency=low +xfree86 (4.3.0.dfsg.1-1+SVN) unstable; urgency=low * Fix 30xfree86-common_xresources Xsession script to check for existence of xrdb command before attempting to execute it, and warn if it is not found
Create a new income with eBay
Title: Turnkey surreal yeats cinematic pornographer assuage citrate conscious rubric nazism zippy carlyle adulthood coherent bony odyssey deborah mallard lesotho showroom daydream anastigmatic baltic brace cowgirl captivate classmate conferred peridotite reconcile proclaim dreyfuss was brainchild lose knifelike detail bindery eulerian cable hilum dioxide checkpoint castigate episodic rug miles thirsty cruise infield permissive octennial dorchester quadrivium gangling euclidean crayfish concoct custodian aviv celsius chance furbish portray burr sequin monongahela clinging difficulty ssw secession promiscuous cruddy grass topple inhospitable elate dubitable cutworm dilogarithm infrastructure portugal cajole ballard metamorphism bereave revertive boyish clothesline filmdom andromeda shank kettering teller saturday counterargument laurentian tatty disseminate warehouse brocade screech numismatist insect separate allocate incentive cease nutritious plagiarism kind adopt tort leery cadaverous roister forgo clammy ecumenic household carbine couple irresponsible aforementioned fingertip homebuilder test leigh pummel siberia bulky pooch marshmallow mannerism brazier comprehension pay abdomen interject deal mesenteric payne freshmen rodney who cougar eagle plenum gall animate somal awake conakry dortmund avis peppy trample discriminatory nuisance abutted indiscriminate rap reputation illogic cage atlantica disparate newborn shill coverlet detroit headstand item beseech hypothesis sherwin connivance haplology chaparral chatty committed methodology leighton situs sacrosanct deplete rampant nashua schist convict Learn to Make A For'tune With E'bay! Com'plete Tur'nkey Sy'stem So'ftware - Vi'deos - Tut'orials Visit Here For Information removemeplease
Bug#22506: Message subject
Pendleton,* Need affordable but reliable web hosting for only $5/month? -800 MB Disk Space -Unlimited email accounts -FREE Shopping Cart... and much more! Please contact us to take advantage of this new offer at http://viewhostdeals.com dubhe
X Strike Force XFree86 SVN commit: r1345 - branches/lintian-cleanup/debian
Author: branden Date: 2004-04-30 14:58:39 -0500 (Fri, 30 Apr 2004) New Revision: 1345 Added: branches/lintian-cleanup/debian/xfree86.lintian branches/lintian-cleanup/debian/xserver-common.lintian branches/lintian-cleanup/debian/xserver-xfree86.lintian branches/lintian-cleanup/debian/xterm.lintian branches/lintian-cleanup/debian/xutils.lintian Log: Add some lintian overrides files. Note that a change to debian/rules to install these in the proper location will be necessary. Note also that these were created some time ago, and some of the overrides may be obsolete. The contents of these files should be reviewed. Added: branches/lintian-cleanup/debian/xfree86.lintian === --- branches/lintian-cleanup/debian/xfree86.lintian 2004-04-30 19:05:47 UTC (rev 1344) +++ branches/lintian-cleanup/debian/xfree86.lintian 2004-04-30 19:58:39 UTC (rev 1345) @@ -0,0 +1,4 @@ +# $Id$ + +# Lintian bug: #194257 +xfree86 source: newer-standards-version 3.6.1 Property changes on: branches/lintian-cleanup/debian/xfree86.lintian ___ Name: svn:keywords + Id Added: branches/lintian-cleanup/debian/xserver-common.lintian === --- branches/lintian-cleanup/debian/xserver-common.lintian 2004-04-30 19:05:47 UTC (rev 1344) +++ branches/lintian-cleanup/debian/xserver-common.lintian 2004-04-30 19:58:39 UTC (rev 1345) @@ -0,0 +1,8 @@ +# $Id$ + +# The X server needs to be setuid/setgid root because it performs +# privileged hardware access. +xserver-common: setuid-gid-binary usr/X11R6/bin/X 6755 root/root + +# The dexconf script does not use debconf as a registry. +xserver-common: debconf-is-not-a-registry ./usr/bin/dexconf Property changes on: branches/lintian-cleanup/debian/xserver-common.lintian ___ Name: svn:keywords + Id Added: branches/lintian-cleanup/debian/xserver-xfree86.lintian === --- branches/lintian-cleanup/debian/xserver-xfree86.lintian 2004-04-30 19:05:47 UTC (rev 1344) +++ branches/lintian-cleanup/debian/xserver-xfree86.lintian 2004-04-30 19:58:39 UTC (rev 1345) @@ -0,0 +1,33 @@ +# $Id$ + +# The Choices field for this question does not need to be translated, since +# it is a package name. +xserver-xfree86: partially-translated-question shared/default-x-server + +# The Choices field for this question does not need to be translated, since +# it is a device driver name. +xserver-xfree86: partially-translated-question xserver-xfree86/config/device/driver + +# The Choices field for this question does not need to be translated, since +# it is a device file specification. +xserver-xfree86: partially-translated-question xserver-xfree86/config/inputdevice/mouse/port + +# The Choices field for this question does not need to be translated, since +# it is a mouse protocol name. +xserver-xfree86: partially-translated-question xserver-xfree86/config/inputdevice/mouse/protocol + +# The Choices field for this question does not need to be translated, since +# it is populated at run time. +xserver-xfree86: partially-translated-question xserver-xfree86/config/monitor/selection-method + +# The Choices field for this question does not need to be translated, since +# it is a list of video modes. +xserver-xfree86: partially-translated-question xserver-xfree86/config/monitor/mode-list + +# The Choices field for this question does not need to be translated, since +# it is a list of video modes. +xserver-xfree86: partially-translated-question xserver-xfree86/config/display/modes + +# The Choices field for this question does not need to be translated, since +# it is a list of integers (color depths). +xserver-xfree86: partially-translated-question xserver-xfree86/config/display/default_depth Property changes on: branches/lintian-cleanup/debian/xserver-xfree86.lintian ___ Name: svn:keywords + Id Added: branches/lintian-cleanup/debian/xterm.lintian === --- branches/lintian-cleanup/debian/xterm.lintian 2004-04-30 19:05:47 UTC (rev 1344) +++ branches/lintian-cleanup/debian/xterm.lintian 2004-04-30 19:58:39 UTC (rev 1345) @@ -0,0 +1,4 @@ +# $Id$ + +# xterm needs to be setgid utmp per Debian Policy section 11.3 +xterm: setgid-binary usr/X11R6/bin/xterm 2755 root/utmp Property changes on: branches/lintian-cleanup/debian/xterm.lintian ___ Name: svn:keywords + Id Added: branches/lintian-cleanup/debian/xutils.lintian === --- branches/lintian-cleanup/debian/xutils.lintian 2004-04-30 19:05:47 UTC (rev 1
Re: Adding a keyboard to Xfree
On Fri, Apr 30, 2004 at 08:52:57AM +0200, Jean-Christophe Dubacq wrote: > Hi! > > Warning: This might be a packaging issue only. > > I developed my own keyboard mapping for XKB (based on my keyboard, > however I did add a lot of fancy chars that I needed so type spanish, > italian and other european languages on a regular basis via AltGr+key, > I could fit in most of latin-9 charset). > > To have it work fully, I had to manually edit /etc/X11/xkb/symbols.dir. > However, this means each upgrade is slightly annoying (asking me wether > I want to replace .../symbols.dir with the provided version). > > I would also like to package my keyboard, to deploy it on a large > number of computers. The modification of symbols.dir would therefore > be unpractical and against the Debian packaging rules (no conffile > should be modified by two packages). > > How could I solve this? Any idea? If this keyboard layout is only used by you, you could run setxkbmap from $HOME/.xsession, see for instance (in French) http://lists.debian.org/debian-user-french-0402/msg01539.html Denis
Bug#246760: xserver-xfree86: cannot upgrade from 4.1.0-2 - complaint about unknown 'escription-pt_br'
Package: xserver-xfree86 Version: 4.1.0-2 Severity: normal Tags: sid When I try to upgrade from xserver-xfree86 4.1.0-2, I get the following complaint from dpkg: Preparing to replace xserver-xfree86 4.1.0-2 (using .../xserver-xfree86_4.3.0.dfsg.1-1_i386.deb) ... ln: /etc/X11/X.dpkg-old': File exists dpkg: error processing /var/cache/apt/archives/xserver-xfree86_4.3.0.dfsg.1-1_i386.deb (--unpack): subprocess pre-installation script returned error exit status 1 debconf: Unknown template field 'escription-pt_br', in stanza #28 of /var/lib/dpkg/info/xserver-xfree86.templates Errors were encountered while processing: /var/cache/apt/archives/xserver-xfree86_4.3.0.dfsg.1-1_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) (I'm pretty sure that the 'X.dpkg-old' part isn't the problem, but I've included it for completeness.) I've looked through the file it references, and I can't find a field by that description. The bug might be with dpkg, I guess, but this is the first and only time I've ever seen it (dpkg upgraded lots of other packages fine at the same time). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (600, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.24 Locale: LANG=C, LC_CTYPE=C Versions of packages xserver-xfree86 depends on: ii debconf 1.4.24 Debian configuration management sy ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries an ii xserver-common 4.3.0-7 files and utilities common to all ii zlib1g 1:1.2.1-3compression library - runtime -- debconf information excluded
Bug#243081: xserver-xfree86: dpms blanking behaves erracticaly
Yes they do, in fact both monitors work flawlessly (with identical hardware) under Windows 2000. There seems to be something up with XFree86 4, as when the last time I used unix on these monitors was duing the 3.x days and there were also no problems there. Thanks for your assistance, Tyler Riddle --- Branden Robinson <[EMAIL PROTECTED]> wrote: > On Thu, Apr 29, 2004 at 04:44:08PM -0700, Tyler > Riddle wrote: > > I switched monitors and the behavior changed a > little. > > Instead of oscilating between off and on states it > now > > displays about 5 seconds of strange lines, I > believe > > the sync rates to be pretty wild. Then the new > monitor > > will turn off. I also tried switching cards after > > changing monitors, both cards had the same > behavior. > > > > The current card is a brand new nVidia Geforce 3d > card > > using the nVidia drivers. Finaly, the same > behavior > > was observed under freebsd previously on this > > computer, with the Rage video card and the > original > > monitor. > > Thanks for following up. > > Do these monitors claim to support DPMS? As I > understand it, DPMS > signaling is done very crudely, by turning off the > horizontal and > vertical sync signals in various combinations to > indicate "standby", > "sleep", and "off". > > -- > G. Branden Robinson| You could > wire up a dead rat to a > Debian GNU/Linux | DIMM socket > and the PC BIOS memory > [EMAIL PROTECTED] | test would > pass it just fine. > http://people.debian.org/~branden/ | -- Ethan > Benson > > ATTACHMENT part 2 application/pgp-signature name=signature.asc = "There are only 10 types of people in this world: Those who understand binary and those who don't." aim: TheMastaSpice __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover
Bug#246760: xserver-xfree86: cannot upgrade from 4.1.0-2 - complaint about unknown 'escription-pt_br'
On Fri, Apr 30, 2004 at 10:54:08PM +0100, Paul Walker wrote: > Package: xserver-xfree86 > Version: 4.1.0-2 > Severity: normal > Tags: sid > > When I try to upgrade from xserver-xfree86 4.1.0-2, I get the following > complaint from dpkg: > > Preparing to replace xserver-xfree86 4.1.0-2 (using > .../xserver-xfree86_4.3.0.dfsg.1-1_i386.deb) ... > ln: /etc/X11/X.dpkg-old': File exists > dpkg: error processing > /var/cache/apt/archives/xserver-xfree86_4.3.0.dfsg.1-1_i386.deb (--unpack): > subprocess pre-installation script returned error exit status 1 > debconf: Unknown template field 'escription-pt_br', in stanza #28 of > /var/lib/dpkg/info/xserver-xfree86.templates Can you please send your /var/lib/dpkg/info/xserver-xfree86.templates? Denis
Bug#246760: xserver-xfree86: cannot upgrade from 4.1.0-2 - complaint about unknown 'escription-pt_br'
On Fri, Apr 30, 2004 at 11:57:41PM +0100, Paul Walker wrote: > On Sat, May 01, 2004 at 12:42:01AM +0200, Denis Barbier wrote: > > > Can you please send your /var/lib/dpkg/info/xserver-xfree86.templates? > > Attached; sorry, I forgot to send it earlier. I think I've found the problem > (grepped with -i this time) - right at the end, there's an entry: > > Escription-pt_BR: Selecione os modos de vídeo que o X deve usar. > > If you correct that to "Description" then I don't get that problem any more. > (Just a different one instead. But at least it's a change.) > > Sorry, I should have thought of that particular grep combination before. :/ > No idea whether the corruption came from 4.1.0 or 4.3.0, I'm afraid. Very strange, this file is not the one found on Debian servers. Where does it come from? Denis
Bug#246760: xserver-xfree86: cannot upgrade from 4.1.0-2 - complaint about unknown 'escription-pt_br'
On Sat, May 01, 2004 at 01:28:05AM +0200, Denis Barbier wrote: > > No idea whether the corruption came from 4.1.0 or 4.3.0, I'm afraid. > Very strange, this file is not the one found on Debian servers. > Where does it come from? Er .. if it's not from either of those packages, then I've no idea! This is the first time I've touched any of the files in the dpkg directories. If it's definitely not present in 4.3.0.dfsg.1-1, then the bug might as well be closed, I guess. -- Paul
Bug#246760: xserver-xfree86: cannot upgrade from 4.1.0-2 - complaint about unknown 'escription-pt_br'
On Sat, May 01, 2004 at 12:42:01AM +0200, Denis Barbier wrote: > Can you please send your /var/lib/dpkg/info/xserver-xfree86.templates? Attached; sorry, I forgot to send it earlier. I think I've found the problem (grepped with -i this time) - right at the end, there's an entry: Escription-pt_BR: Selecione os modos de v?deo que o X deve usar. If you correct that to "Description" then I don't get that problem any more. (Just a different one instead. But at least it's a change.) Sorry, I should have thought of that particular grep combination before. :/ No idea whether the corruption came from 4.1.0 or 4.3.0, I'm afraid. -- Paul Over the centuries, mankind has tried many ways of combating the forces of evil...prayer, fasting, good works and so on. Up until Doom, no one seemed to have thought about the double-barrel shotgun. Eat leaden death, demon... -- Terry Pratchett xserver-xfree86.templates.bz2 Description: Binary data
