Bug#182704: Debconf configuration sets use_fbdev without asking, making X unstartable
On Fri, Feb 28, 2003 at 08:27:02PM -0500, Branden Robinson wrote: On Fri, Feb 28, 2003 at 10:04:53PM +0100, Michel D?nzer wrote: Uh, so it sounds like you're telling me that /proc/fb is essentially useless for autoconfiguring the X server. 1) /proc/fb reporting something doesn't mean you can just switch on UseFBDev, because that won't work with generic [kernel] drivers I do think parsing /proc/fb to determine this is feasible, we just need to gather enough data. Well, why don't you get me started with some, and we can add more as time goes by? I think not all X drivers support (or even need) the UseFBDev flag. For example, the glint driver doesn't know anything about UseFBDev, and will work just fine without it, even if you were using pm3fb for example. That said it doesn't use the fbdev for mode configuration or anything. Now, the glint driver for pm2fb on amiga/apus hardware, will autodetect that we are on amiga/apus, and start using the fbdev in this case. More or less, michel wrote that code, so he knows more than me on this issue. Anyway, i guess the best solution would be to check each X driver, and see if it supports the UseFBDev option. Then you can either parse the /proc/fb for appropriate drivers, with a mapping like Michel suggest, or use the pci ids the driver supports. Still you would need to check if the specific fbdev was loaded before setting the UseFBDev or something such. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#182924: xserver-xfree86: Xserver freezes on resume from suspend to disk with radeon chips and DRI enabled
On Fri, Feb 28, 2003 at 08:34:59PM -0500, Branden Robinson wrote: LY. It will completly lock the machine. This is a known problem. Charl Botha has written a patch for this. Since it is still not included in the XF86 cvs and is also missing in XFree86 4.3 according to http://www.mail-archive.com/[EMAIL PROTECTED]/msg00207.html and my own experience with 4.3, I would like to have the patches applied for the Debian package xserver-xfree86. More information about this problem can be found at http://cpbotha.net/dri_resume.html, patches can be found at http://cpbotha.net/files/dri_resume/. The patch is pretty extensive; this means it may not apply cleanly given all the other patches I've made to the driver for Debian's packages. I may not have the patience do a lot of hand-merging, however, I will give this patch a shot. If it's too much trouble I'll let you know; in that event perhaps you can mail debian-x or some other mailing list and find someone with this hardware and willing to prepare a version of the patch for our packages. Another problem is that my patch makes crucial modifications to the DRM, without which the Radeon XFree86 driver patches will have little or no effect. The DRM is the only place where things like Radeon microcode can be reloaded after resume. I've thought about this, but wouldn't know how to package this for Debian, as Debian ships an unpatched kernel AFAICR. Are there other packages which ship kernel modules? I did submit the work to [EMAIL PROTECTED], but apparently too late for the 4.3 release. I've been promised that it would be integrated AFTER the 4.3 release, so eventually the DRM part will propagate into the 2.5 (and probably 2.4) kernel trees. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#182986: Savage driver doesn't work (ThinkPad T23)
Package: xserver-xfree86 Version: 4.2.1-6 Severity: important Tags: sid Using version 4.2.1-5 (IIRC), X worked just fine here. After upgrading to 4.2.1-6, the screen just shows a black background (instead of the normal X background). The mouse cursor is still visible though, and can be moved normally. Furthermore, I believe that X applications (such as KDM) are started correctly, except that I can't see anything... This is a ThinkPad T23 with a SuperSavage card. -- Package-specific info: 01:00.0 VGA compatible controller: S3 Inc. SuperSavage IX/C SDR (rev 05) 01:00.0 Class 0300: 5333:8c2e (rev 05) # XF86Config-4 (XFree86 server configuration file) 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.) # # If you want your changes to this file preserved by dexconf, only make changes # before the ### BEGIN DEBCONF SECTION line above, and/or after the # ### END DEBCONF SECTION line below. # # To change things within the debconf section, run the command: # dpkg-reconfigure xserver-xfree86 # as root. Also see How do I add custom sections to a dexconf-generated # XF86Config or XF86Config-4 file? in /usr/share/doc/xfree86-common/FAQ.gz. Section Files # 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/75dpi/:unscaled FontPath/usr/lib/X11/fonts/100dpi/:unscaled FontPath/usr/lib/X11/fonts/Type1 FontPath/usr/lib/X11/fonts/Speedo FontPath/usr/lib/X11/fonts/75dpi FontPath/usr/lib/X11/fonts/100dpi FontPath/var/lib/defoma/x-ttcidfont-conf.d/dirs/CID FontPath/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType EndSection Section Module LoadGLcore Loadbitmap Loaddbe Loadddc Loaddri Loadextmod Loadfreetype Loadglx Loadint10 Loadrecord Loadspeedo Loadtype1 Loadvbe 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/psaux Option Protocol PS/2 EndSection Section InputDevice Identifier Generic Mouse Driver mouse Option SendCoreEventstrue Option Device/dev/input/mice Option Protocol ImPS/2 Option Buttons 5 Option ZAxisMapping 4 5 EndSection Section Device Identifier Generic Video Card Driver savage Option UseFBDev true EndSection Section Monitor Identifier Generic Monitor HorizSync 28-49 VertRefresh 43-72 Option DPMS EndSection Section Screen Identifier Default Screen Device Generic Video Card Monitor Generic Monitor DefaultDepth24 SubSection Display Depth 1 Modes 1024x768 EndSubSection SubSection Display Depth 4 Modes 1024x768 EndSubSection SubSection Display Depth 8 Modes 1024x768 EndSubSection SubSection Display Depth 15 Modes 1024x768 EndSubSection SubSection Display Depth 16 Modes 1024x768 EndSubSection SubSection Display Depth 24 Modes 1024x768 EndSubSection EndSection Section ServerLayout Identifier Default Layout Screen Default Screen InputDevice Generic Keyboard InputDevice Configured Mouse InputDevice Generic Mouse EndSection Section DRI Mode0666 EndSection This is version 4.2.1-6: This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository
Bug#182924: xserver-xfree86: Xserver freezes on resume from suspend to disk with radeon chips and DRI enabled
On Sam, 2003-03-01 at 14:17, Charl P. Botha wrote: On Fri, Feb 28, 2003 at 08:34:59PM -0500, Branden Robinson wrote: LY. It will completly lock the machine. This is a known problem. Charl Botha has written a patch for this. Since it is still not included in the XF86 cvs and is also missing in XFree86 4.3 according to http://www.mail-archive.com/[EMAIL PROTECTED]/msg00207.html and my own experience with 4.3, I would like to have the patches applied for the Debian package xserver-xfree86. More information about this problem can be found at http://cpbotha.net/dri_resume.html, patches can be found at http://cpbotha.net/files/dri_resume/. The patch is pretty extensive; this means it may not apply cleanly given all the other patches I've made to the driver for Debian's packages. I may not have the patience do a lot of hand-merging, however, I will give this patch a shot. If it's too much trouble I'll let you know; in that event perhaps you can mail debian-x or some other mailing list and find someone with this hardware and willing to prepare a version of the patch for our packages. Another problem is that my patch makes crucial modifications to the DRM, without which the Radeon XFree86 driver patches will have little or no effect. As long as it doesn't have a bad effect... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#182976: xserver-xfree86: more information in debconf about possible problems with framebuffer
On Sam, 2003-03-01 at 13:10, Marco Herrn wrote: Sometimes using the framebuffer device can lead to problems (for example when using nvidia drivers). How so? I thought they simply didn't support it, in which case they should ignore it. The error message from the X server is not very verbose: EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found Nobody can know that this can be the result of using framebuffer. Indeed, because it's a very generic error message which can be caused by a lot of things. If Option UseFBDev is a problem, the usual symptom is the driver aborting right after loading the fbdevhw module. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Unidentified subject!
Hi, this is my big problem... SID, XP1.700+, MSI KT-333, 512DDR, Inno GEF4 4200/64AGP4X Everithing was fine, until the last dselect/update/install... Thnx, Attila Kovari This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] 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.2.1.1 (Debian 4.2.1-6 20030225230350 [EMAIL PROTECTED]) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 18 October 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.20-586tsc i686 [ELF] Module Loader present 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: Sat Mar 1 14:03:35 2003 (==) Using config file: /etc/X11/XF86Config-4 (==) ServerLayout XFree86 Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Card0 (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (==) Keyboard: CustomKeycode disabled (**) FontPath set to unix/:7110,unix/:7100,/usr/X11R6/lib/X11/fonts/misc/ (**) 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.1 XFree86 Video Driver: 0.5 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (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.2.1.1, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (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.2.1.1, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x80a8, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1106,3099 card 1106, rev 00 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1106,b099 card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:06:0: chip 109e,0350 card , rev 12 class 04,00,00 hdr 00 (II) PCI: 00:07:0: chip 1274,5880 card 1274,2000 rev 02 class 04,01,00 hdr 00 (II) PCI: 00:08:0: chip 8086,1229 card 8086,0009 rev 05 class 02,00,00 hdr 00 (II) PCI: 00:10:0: chip 1106,3038 card 1106,3038 rev 80 class 0c,03,00 hdr 80 (II) PCI: 00:10:1: chip 1106,3038 card 1106,3038 rev 80 class 0c,03,00 hdr 80 (II) PCI: 00:10:2: chip 1106,3038 card 1106,3038 rev 80 class 0c,03,00 hdr 80 (II) PCI: 00:10:3: chip 1106,3104 card 1106,3104 rev 82 class 0c,03,20 hdr 00 (II) PCI: 00:11:0: chip 1106,3177 card 1106, rev 00 class 06,01,00 hdr 80 (II) PCI: 00:11:1: chip 1106,0571 card 1106,0571 rev 06 class 01,01,8a hdr 00 (II) PCI: 01:00:0: chip 10de,0253 card , rev a3 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) LoadModule: scanpci (II) Loading /usr/X11R6/lib/modules/libscanpci.a (II) Module scanpci: vendor=The XFree86 Project compiled for 4.2.1.1, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) UnloadModule: scanpci (II) Unloading /usr/X11R6/lib/modules/libscanpci.a (II) Host-to-PCI bridge: (II) PCI-to-ISA bridge: (II) PCI-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (-1,0,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 00x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 00x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 00x - 0x (0x0) MX[B] (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x0c (VGA_EN is set) (II) Bus 1 I/O range: (II) Bus 1 non-prefetchable memory range: [0] -1 00xdda0 - 0xdfaf (0x210) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 00xd570 - 0xdd8f (0x820) MX[B] (II) Bus -1: bridge is at (0:17:0), (0,-1,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus -1 I/O range: (II) Bus -1 non-prefetchable memory range: (II) Bus -1 prefetchable memory range: (--) PCI: (0:6:0) BrookTree 848 rev 18, Mem @ 0xdd9ff000/12 (--) PCI:*(1:0:0) NVidia GeForce4 Ti 4200 rev 163, Mem @ 0xde00/24, 0xd800/26,
Bug#182986: Same Problem on a T20 with a Savage/MX chipset
I had the exact same problem on my T20 with the Savage/MX chipset. I tried changing resolutions, color depths. I threw out my X config and started over. I tried through an external monitor, or the panel directly. None of them worked. I had to spend two hours downgrading almost everything, and reinstalling against testing just to get my X back up. -- Ryan Eatmon [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#182704: Debconf configuration sets use_fbdev without asking, making X unstartable
On Sam, 2003-03-01 at 02:27, Branden Robinson wrote:
On Fri, Feb 28, 2003 at 10:04:53PM +0100, Michel D?nzer wrote:
Uh, so it sounds like you're telling me that /proc/fb is essentially
useless for autoconfiguring the X server.
1) /proc/fb reporting something doesn't mean you can just switch on
UseFBDev, because that won't work with generic [kernel] drivers
I do think parsing /proc/fb to determine this is feasible, we just need
to gather enough data.
Well, why don't you get me started with some, and we can add more as
time goes by?
Here's some OFfb output:
0 OFfb /[EMAIL PROTECTED]/ATY,[EMAIL PROTECTED]/AT
And vesafb:
0 VESA VGA
These look easy. :) I think these are the most common generic
framebuffer devices, then there's also vga{16,256}fb but I doubt they
are widely used.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#183029: PATCH: put X, XIM, Xfs unix sockets in /var/run/X11
Package: xfree86
Version: unavailable; reported 2003-03-01
Severity: wishlist
Tags: patch
As requested I'm re-transmitting this as a wishlist bug.
I edited the change to debian/xfree86-common.README.Debian so that it
now says 4.3.0-1 instead of 4.2.1-6. 4.2.1-6 is already out the
door, and I'm guessing you'd rather look at this in the 4.3.x timeframe
anyway.
This patch moves the UNIX domain sockets created by the X server, the
font server, and XIM input methods from various .subdirs of /tmp to
/var/run/X11, which directory is created at boot time by the existing
xfree86-common init script.
This change naturally has backward compatibility implications. There
are several cases to consider:
* New client, old server (for any of the above): logic exists in the
Xtrans client code to try an old location if the socket is not found
in the new one, so this is not a problem.
* New X server, old libX11: The boot script creates a symbolic link
from /tmp/.X11-unix to /var/run/X11, which should prevent any
trouble in this case. (Users who know they don't need this can
disable it.)
* New font server or input method, old X server: This is unlikely to
come up, but the boot script can be edited to create more symlinks
if necessary. README.Debian documents this.
I did not move the socket directory for libICE, because those sockets
get created by arbitrary users. The major point of moving sockets to
/var/run/X11 is that that directory can be mode 755. I can think of a
couple ways to get around that but they're all messy enough not to be
worth it.
I also did not move /tmp/.X%d-lock as that would break cohabitation of
old and new X servers on the same host.
zw
--- xc/config/cf/linux.cf~ 2003-02-06 23:42:21.0 -0800
+++ xc/config/cf/linux.cf 2003-02-14 14:17:55.0 -0800
@@ -125,7 +125,8 @@
# define SharedLibGlu YES
# define NormalLibGlu YES
# define FSUseSyslog YES
+# define UnixSocketsInVarRun YES
/*
*
--- xc/config/cf/X11.tmpl~ 2003-02-06 20:56:37.0 -0800
+++ xc/config/cf/X11.tmpl 2003-02-14 14:21:07.0 -0800
@@ -562,6 +562,10 @@
#define InstallMiscManPagesNO
#endif
+#ifndef UnixSocketsInVarRun
+#define UnixSocketsInVarRunNO
+#endif
+
#ifndef FSUseSyslog
#define FSUseSyslogNO
#endif
@@ -704,8 +708,11 @@
#if HasFchown
FCHOWN_DEFINES = -DHAS_FCHOWN
#endif
+#if UnixSocketsInVarRun
+USLOC_DEFINES = -DSOCKETS_IN_VAR_RUN
+#endif
#ifndef ExtraConnectionDefs
-#define ExtraConnectionDefs $(STICKY_DEFINES) $(FCHOWN_DEFINES)
+#define ExtraConnectionDefs $(STICKY_DEFINES) $(FCHOWN_DEFINES) $(USLOC_DEFINES)
#endif
#ifndef ProjectThreadsDefines
#define ProjectThreadsDefines -DXTHREADS
--- xc/lib/xtrans/Xtranssock.c~ 2001-12-14 11:57:06.0 -0800
+++ xc/lib/xtrans/Xtranssock.c 2003-02-14 14:46:14.0 -0800
@@ -228,7 +228,40 @@
#define UNIX_DIR /usr/spool/sockets/X11
#endif
-#else /* !hpux */
+#elif defined(SOCKETS_IN_VAR_RUN)
+
+#if defined(X11_t)
+#define UNIX_PATH /var/run/X11/X
+#define UNIX_DIR /var/run/X11
+#define OLD_UNIX_PATH /tmp/.X11-unix/X
+#endif /* X11_t */
+#if defined(XIM_t)
+#define UNIX_PATH /var/run/X11/XIM
+#define UNIX_DIR /var/run/X11
+#define OLD_UNIX_PATH /tmp/.XIM-unix/XIM
+#endif /* XIM_t */
+#if defined(FS_t) || defined(FONT_t)
+#define UNIX_PATH /var/run/X11/fs
+#define UNIX_DIR /var/run/X11
+#define OLD_UNIX_PATH /tmp/.font-unix/fs
+#endif /* FS_t || FONT_t */
+#if defined(ICE_t)
+/* ICE sockets stay in /tmp since those are created by clients. */
+#define UNIX_PATH /tmp/.ICE-unix/
+#define UNIX_DIR /tmp/.ICE-unix
+#endif /* ICE_t */
+#if defined(TEST_t)
+/* ??? Does not appear to be used for anything. */
+#define UNIX_PATH /tmp/.Test-unix/test
+#define UNIX_DIR /tmp/.Test-unix
+#endif
+#if defined(LBXPROXY_t)
+#define UNIX_PATH /var/run/X11/X
+#define UNIX_DIR /var/run/X11
+#define OLD_UNIX_PATH /tmp/.X11-unix/X
+#endif
+
+#else /* not hpux and not /var/run/X11 */
#if defined(X11_t)
#define UNIX_PATH /tmp/.X11-unix/X
@@ -1552,7 +1585,7 @@
struct sockaddr_un sockname;
intnamelen;
-#if defined(hpux) defined(X11_t)
+#ifdef OLD_UNIX_PATH
struct sockaddr_un old_sockname;
intold_namelen;
#endif
@@ -1607,9 +1640,9 @@
#endif
-#if defined(hpux) defined(X11_t)
+#ifdef OLD_UNIX_PATH
/*
- * This is gross, but it was in Xlib
+ * Support an older location for the socket.
*/
old_sockname.sun_family = AF_UNIX;
if (set_sun_path(port, OLD_UNIX_PATH, old_sockname.sun_path) != 0) {
@@ -1620,7 +1653,6 @@
sizeof (old_sockname.sun_family);
#endif
-
/*
* Do the connect()
*/
@@ -1630,7 +1662,7 @@
int olderrno = errno;
int connected = 0;
-#if defined(hpux) defined(X11_t)
+#ifdef OLD_UNIX_PATH
if (olderrno == ENOENT)
{
if (connect (ciptr-fd,
--- debian/xfree86-common.init~
Bug#182704: Debconf configuration sets use_fbdev without asking, making X unstartable
On Sam, 2003-03-01 at 11:32, Sven Luther wrote: On Fri, Feb 28, 2003 at 08:27:02PM -0500, Branden Robinson wrote: On Fri, Feb 28, 2003 at 10:04:53PM +0100, Michel D?nzer wrote: Uh, so it sounds like you're telling me that /proc/fb is essentially useless for autoconfiguring the X server. 1) /proc/fb reporting something doesn't mean you can just switch on UseFBDev, because that won't work with generic [kernel] drivers I do think parsing /proc/fb to determine this is feasible, we just need to gather enough data. Well, why don't you get me started with some, and we can add more as time goes by? I think not all X drivers support (or even need) the UseFBDev flag. In general, those that don't support it ignore it. For example, the glint driver doesn't know anything about UseFBDev, and will work just fine without it, even if you were using pm3fb for example. That said it doesn't use the fbdev for mode configuration or anything. Now, the glint driver for pm2fb on amiga/apus hardware, will autodetect that we are on amiga/apus, and start using the fbdev in this case. More or less, michel wrote that code, so he knows more than me on this issue. AFAICS the glint driver is a special case which can be covered by adding pm3fb to the list of framebuffer devices Option UseFBDev doesn't work with. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Merging duplicate bugs
Processing commands for [EMAIL PROTECTED]: reassign 179263 xlibmesa3-gl Bug#179263: xserver-xfree86: GL graphics stopped working on my system after the last sid update of xserver-xfree86 Bug reassigned from package `xserver-xfree86' to `xlibmesa3-gl'. reassign 179789 xlibmesa3-gl Bug#179789: Problem with X 4.2.1-5 and Radeons Bug reassigned from package `xserver-xfree86' to `xlibmesa3-gl'. severity 179263 important Bug#179263: xserver-xfree86: GL graphics stopped working on my system after the last sid update of xserver-xfree86 Severity set to `important'. severity 179789 important Bug#179789: Problem with X 4.2.1-5 and Radeons Severity set to `important'. tags 179263 sid Bug#179263: xserver-xfree86: GL graphics stopped working on my system after the last sid update of xserver-xfree86 There were no tags set. Tags added: sid tags 179789 sid Bug#179789: Problem with X 4.2.1-5 and Radeons Tags were: sid Tags added: sid merge 179263 179789 178242 Bug#178242: xlibmesa3: [radeon_dri] hardware acceleration non-functional on Radeon 7500 QW Bug#179263: xserver-xfree86: GL graphics stopped working on my system after the last sid update of xserver-xfree86 Bug#179789: Problem with X 4.2.1-5 and Radeons Bug#180502: xlibmesa3-gl: [radeon_dri] hardware acceleration non-functional Bug#182524: xlibmesa3-gl: glx displays only blankness Merged 178242 179263 179789 180502 182524. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#179263: Merging duplicate bugs
reassign 179263 xlibmesa3-gl reassign 179789 xlibmesa3-gl severity 179263 important severity 179789 important tags 179263 sid tags 179789 sid merge 179263 179789 178242 thanks [This is a form letter.] Hello, You recently filed a duplicate bug report against Debian's XFree86 packages; that is, the problem had already been reported. While there is often nothing inherently wrong with doing so, the filing of duplicate reports can cause Debian package maintainers to spend time performing triage and maintenance operations on bug reports (e.g., instructing the Debian Bug Tracking System to merge the duplicates) that could otherwise be spent resolving problems and doing other work on the package. One very good way to file bugs with the Debian Bug Tracking System is to use the reportbug package and command of the same name. A very nice feature of reportbug is that, if the machine where you run it has network access to the World Wide Web, it can query the Debian Bug Tracking System and show you existing reports. This reduces the chance that you'll file a duplicate report, and offers you the option of adding follow-up information to an existing bug report. This is especially valuable if you have unique information to add to an existing report, because this way information relevant to the problem is gathered together in one place as opposed to being scattered among multiple, duplicate bug reports where some facts may be overlooked by the package maintainers. The reportbug program also does a lot of automatic information-gathering that helps package maintainers to understand your system configuration, and also ensures that your message to the Debian Bug Tracking System is well-formed so that it is processed correctly by the automated tools that manage the reports. (If you've ever gotten a bounce message from the Debian Bug Tracking System that tells you your message couldn't be processed, you might appreciate this latter feature.) Therefore, I strongly urge you to give reportbug a try as your primary bug reporting tool for the Debian System. One way to install reportbug is with apt-get; for example: $ apt-get install reportbug The reportbug command has a few different modes that cater to different levels of user expertise. If this message has contained a lot of jargon that is unfamiliar to you, you likely want to use reportbug's novice mode; here's one way to do that. $ reportbug --mode=novice Please enter the name of the package in which you have found a problem, or type 'other' to report a more general problem. If you're more sophisticated, or if you are not using the released version of Debian (stable), but instead Debian testing or unstable, you should use reportbug's standard mode. $ reportbug Please enter the name of the package in which you have found a problem, or type 'other' to report a more general problem. The reportbug command is extensively documented in its usage message and manual page. Commands to view these pieces of documentation are: $ reportbug --help | more $ man reportbug (The output of the above commands has been omitted from this message.) Thanks for using the Debian system! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: retitle 182976 to xserver-xfree86: [core server] hack server to tell people 'no screens found' can be due to 'UseFBDev' option
Processing commands for [EMAIL PROTECTED]: retitle 182976 xserver-xfree86: [core server] hack server to tell people 'no screens found' can be due to 'UseFBDev' option Bug#182976: xserver-xfree86: more information in debconf about possible problems with framebuffer Changed Bug title. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#182986: Savage driver doesn't work (ThinkPad T23)
Processing commands for [EMAIL PROTECTED]: severity 182986 normal Bug#182986: Savage driver doesn't work (ThinkPad T23) Severity set to `normal'. retitle 182986 xserver-xfree86: [savage] patch to 'stop softbooting twice' keeps driver from working on some /MX and /IX chips Bug#182986: Savage driver doesn't work (ThinkPad T23) Changed Bug title. merge 182788 182986 Bug#182788: xserver-xfree86: [savage] patch to 'stop softbooting twice' keeps driver from working on some /MX and /IX chips Bug#182986: xserver-xfree86: [savage] patch to 'stop softbooting twice' keeps driver from working on some /MX and /IX chips Bug#182831: xserver-xfree86: [savage] failed to fetch bios modes on SuperSavage IX/C SDR (rev 05) Merged 182788 182831 182986. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#182924: xserver-xfree86: Xserver freezes on resume from suspend to disk with radeon chips and DRI enabled
On Sat, Mar 01, 2003 at 02:17:59PM +0100, Charl P. Botha wrote: I've thought about this, but wouldn't know how to package this for Debian, as Debian ships an unpatched kernel AFAICR. Are there other packages which ship kernel modules? Oh, a couple: % apt-cache search kernel-patch | grep '^kernel-patch' | head kernel-patch-2.2.17-vm-global - Andrea Archangeli's 2.2.17pre11 vm-global patch, modified for 2.2.17. kernel-patch-2.2.18-openwall - patch to add extra security-related features to the linux kernel. kernel-patch-2.2.18-vm-global - Andrea Archangeli's 2.2.18pre25 vm-global patch. kernel-patch-2.2.19-arm - Diffs to the Linux kernel source 2.2.19 for ARM kernel-patch-2.2.20-arm - Diffs to the Linux kernel source 2.2.20 for ARM kernel-patch-2.2.20-ide - Andre Hedrick's IDE patch. kernel-patch-2.2.20-m68k - Diffs to the kernel source for m68k kernel-patch-2.2.20-p3 - Doug Ledford's 2.2.12 p3 patch, modified for 2.2.20. kernel-patch-2.2.20-powerpc - Diffs to the kernel source for PowerPC kernel-patch-2.2.20-raid - Ingo Molnar's patch of raid2 functionality to 2.2.x (There are many more.) -- G. Branden Robinson| Mob rule isn't any prettier just Debian GNU/Linux | because you call your mob a [EMAIL PROTECTED] | government. http://people.debian.org/~branden/ | pgp0.pgp Description: PGP signature
Bug#182704: Debconf configuration sets use_fbdev without asking, making X unstartable
On Sat, Mar 01, 2003 at 08:49:47PM +0100, Michel D?nzer wrote: For example, the glint driver doesn't know anything about UseFBDev, and will work just fine without it, even if you were using pm3fb for example. That said it doesn't use the fbdev for mode configuration or anything. Now, the glint driver for pm2fb on amiga/apus hardware, will autodetect that we are on amiga/apus, and start using the fbdev in this case. More or less, michel wrote that code, so he knows more than me on this issue. AFAICS the glint driver is a special case which can be covered by adding pm3fb to the list of framebuffer devices Option UseFBDev doesn't work with. pm3fb or pm2fb? I don't see a justification in the above paragraphs for marking either of them as incompatible with UseFBDev. Will work fine without it doesn't mean we should forbid usage of UseFBDev with that framebuffer type. We should only forbid where we know it will always cause problems. -- G. Branden Robinson| To be is to do -- Plato Debian GNU/Linux | To do is to be -- Aristotle [EMAIL PROTECTED] | Do be do be do -- Sinatra http://people.debian.org/~branden/ | pgp0.pgp Description: PGP signature
Bug#182704: Debconf configuration sets use_fbdev without asking, making X unstartable
On Sat, Mar 01, 2003 at 03:30:02PM +0100, Michel D?nzer wrote:
Here's some OFfb output:
0 OFfb /[EMAIL PROTECTED]/ATY,[EMAIL PROTECTED]/AT
And vesafb:
0 VESA VGA
These look easy. :) I think these are the most common generic
framebuffer devices, then there's also vga{16,256}fb but I doubt they
are widely used.
Okay, here's the new code based on this:
# use fbcon kernel functions?
USE_FBDEV=
if [ -e /proc/fb ]; then
FB_TYPE=$(awk '{print $2}' /proc/fb)
# did we actually get back anything?
if [ -n $FB_TYPE ]; then
case $FB_TYPE in
OFfb|VESA)
# generic framebuffer that doesn't support UseFBDev
;;
*)
# other framebuffers do support UseFBDEV
USE_FBDEV=yes
;;
esac
fi
fi
if [ -n $USE_FBDEV ]; then
auto_answer db_input high xserver-xfree86/config/device/use_fbdev true
else
db_get xserver-xfree86/config/device/use_fbdev || debug_report_status db_get
xserver-xfree86/config/device/use_fbdev $?
if [ $RET = true ]; then
debug_echo xserver-xfree86/config/device/use_fbdev is \true\ but /proc/fb does
not exist, is empty, or reports a framebuffer type with which UseFBDev cannot be used;
setting template to \false\
db_set xserver-xfree86/config/device/use_fbdev false
fi
fi
Comments?
--
G. Branden Robinson|I have a truly elegant proof of the
Debian GNU/Linux |above, but it is too long to fit
[EMAIL PROTECTED] |into this .signature file.
http://people.debian.org/~branden/ |
pgp0.pgp
Description: PGP signature
Bug#182986: Savage driver doesn't work (ThinkPad T23)
severity 182986 normal retitle 182986 xserver-xfree86: [savage] patch to 'stop softbooting twice' keeps driver from working on some /MX and /IX chips merge 182788 182986 thanks [This is a form letter.] Hello, You recently filed a duplicate bug report against Debian's XFree86 packages; that is, the problem had already been reported. While there is often nothing inherently wrong with doing so, the filing of duplicate reports can cause Debian package maintainers to spend time performing triage and maintenance operations on bug reports (e.g., instructing the Debian Bug Tracking System to merge the duplicates) that could otherwise be spent resolving problems and doing other work on the package. One very good way to file bugs with the Debian Bug Tracking System is to use the reportbug package and command of the same name. A very nice feature of reportbug is that, if the machine where you run it has network access to the World Wide Web, it can query the Debian Bug Tracking System and show you existing reports. This reduces the chance that you'll file a duplicate report, and offers you the option of adding follow-up information to an existing bug report. This is especially valuable if you have unique information to add to an existing report, because this way information relevant to the problem is gathered together in one place as opposed to being scattered among multiple, duplicate bug reports where some facts may be overlooked by the package maintainers. The reportbug program also does a lot of automatic information-gathering that helps package maintainers to understand your system configuration, and also ensures that your message to the Debian Bug Tracking System is well-formed so that it is processed correctly by the automated tools that manage the reports. (If you've ever gotten a bounce message from the Debian Bug Tracking System that tells you your message couldn't be processed, you might appreciate this latter feature.) Therefore, I strongly urge you to give reportbug a try as your primary bug reporting tool for the Debian System. One way to install reportbug is with apt-get; for example: $ apt-get install reportbug The reportbug command has a few different modes that cater to different levels of user expertise. If this message has contained a lot of jargon that is unfamiliar to you, you likely want to use reportbug's novice mode; here's one way to do that. $ reportbug --mode=novice Please enter the name of the package in which you have found a problem, or type 'other' to report a more general problem. If you're more sophisticated, or if you are not using the released version of Debian (stable), but instead Debian testing or unstable, you should use reportbug's standard mode. $ reportbug Please enter the name of the package in which you have found a problem, or type 'other' to report a more general problem. The reportbug command is extensively documented in its usage message and manual page. Commands to view these pieces of documentation are: $ reportbug --help | more $ man reportbug (The output of the above commands has been omitted from this message.) Thanks for using the Debian system! -- G. Branden Robinson| Q: How does a Unix guru have sex? Debian GNU/Linux | A: unzip;strip;touch;finger;mount; [EMAIL PROTECTED] |fsck;more;yes;fsck;fsck;fsck; http://people.debian.org/~branden/ |umount;sleep pgp0.pgp Description: PGP signature
Bug#182924: xserver-xfree86: Xserver freezes on resume from suspend to disk with radeon chips and DRI enabled
On Sat, Mar 01, 2003 at 04:04:16PM -0500, Branden Robinson wrote: On Sat, Mar 01, 2003 at 02:17:59PM +0100, Charl P. Botha wrote: I've thought about this, but wouldn't know how to package this for Debian, as Debian ships an unpatched kernel AFAICR. Are there other packages which ship kernel modules? I may not be able to do very much with this bug. Charl Botha is using a mail server that has my address blacklisted. As a matter of policy, I do not do business or correspond with people who slanderously accuse my emails of being spam. Someone may want to pass this along to Charl. [EMAIL PROTECTED]: host mailhst2.its.tudelft.nl[130.161.34.250] said: 553 5.3.0 E-mail refused - see http://www.dto.tudelft.nl/blacklist.htm (in reply to MAIL FROM command) -- G. Branden Robinson|Somewhere, there is a .sig so funny Debian GNU/Linux |that reading it will cause an [EMAIL PROTECTED] |aneurysm. This is not that .sig. http://people.debian.org/~branden/ | pgp0.pgp Description: PGP signature
Bug#182704: Debconf configuration sets use_fbdev without asking, making X unstartable
On Sam, 2003-03-01 at 22:20, Branden Robinson wrote:
On Sat, Mar 01, 2003 at 03:30:02PM +0100, Michel D?nzer wrote:
Here's some OFfb output:
0 OFfb /[EMAIL PROTECTED]/ATY,[EMAIL PROTECTED]/AT
And vesafb:
0 VESA VGA
These look easy. :) I think these are the most common generic
framebuffer devices, then there's also vga{16,256}fb but I doubt they
are widely used.
Okay, here's the new code based on this:
# use fbcon kernel functions?
USE_FBDEV=
if [ -e /proc/fb ]; then
FB_TYPE=$(awk '{print $2}' /proc/fb)
# did we actually get back anything?
if [ -n $FB_TYPE ]; then
case $FB_TYPE in
OFfb|VESA)
# generic framebuffer that doesn't support UseFBDev
;;
*)
# other framebuffers do support UseFBDEV
USE_FBDEV=yes
;;
esac
fi
fi
if [ -n $USE_FBDEV ]; then
auto_answer db_input high xserver-xfree86/config/device/use_fbdev true
else
db_get xserver-xfree86/config/device/use_fbdev || debug_report_status db_get
xserver-xfree86/config/device/use_fbdev $?
if [ $RET = true ]; then
debug_echo xserver-xfree86/config/device/use_fbdev is \true\ but /proc/fb
does not exist, is empty, or reports a framebuffer type with which UseFBDev cannot
be used; setting template to \false\
db_set xserver-xfree86/config/device/use_fbdev false
fi
fi
Comments?
I think this doesn't handle multiple framebuffer devices, it would set
USE_FBDEV to yes no matter what they are. I'm not sure how to handle
that though, maybe
FB_TYPE=$(egrep '^0' /proc/fb | awk '{print $2}')
?
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#182924: xserver-xfree86: Xserver freezes on resume from suspend to disk with radeon chips and DRI enabled
On Sat, Mar 01, 2003 at 02:17:59PM +0100, Charl P. Botha scrawled: Another problem is that my patch makes crucial modifications to the DRM, without which the Radeon XFree86 driver patches will have little or no effect. The DRM is the only place where things like Radeon microcode can be reloaded after resume. I've thought about this, but wouldn't know how to package this for Debian, as Debian ships an unpatched kernel AFAICR. Are there other packages which ship kernel modules? I did submit the work to [EMAIL PROTECTED], but apparently too late for the 4.3 release. I've been promised that it would be integrated AFTER the 4.3 release, so eventually the DRM part will propagate into the 2.5 (and probably 2.4) kernel trees. Hi Charl! I've integrated your patch into 4.3.0-1, which means that both xserver-xfree86 and xlibmesa4-drm-src will work properly with Radeons resuming. Thanks for all your work! :) d -- Daniel Stone [EMAIL PROTECTED] Developer, Trinity College, University of Melbourne pgp0.pgp Description: PGP signature
Bug#182924: xserver-xfree86: Xserver freezes on resume from suspend to disk with radeon chips and DRI enabled
Hello there Daniel, On Sun, Mar 02, 2003 at 11:58:05AM +1100, Daniel Stone wrote: On Sat, Mar 01, 2003 at 02:17:59PM +0100, Charl P. Botha scrawled: I did submit the work to [EMAIL PROTECTED], but apparently too late for the 4.3 release. I've been promised that it would be integrated AFTER the 4.3 release, so eventually the DRM part will propagate into the 2.5 (and probably 2.4) kernel trees. Hi Charl! I've integrated your patch into 4.3.0-1, which means that both xserver-xfree86 and xlibmesa4-drm-src will work properly with Radeons resuming. Thanks for all your work! Ali GRESPEC! Fank you./Ali G Seriously, that's impressively fast. :) Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 182773
Processing commands for [EMAIL PROTECTED]: tag 182773 + moreinfo Bug#182773: xserver-xfree86: [mga] hardware 3D accel + VT switching causes screen corruption and lockup on MGA G400 AGP rev 4 There were no tags set. Tags added: moreinfo End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: output from X -configure
On Fri, Feb 28, 2003 at 11:03:49AM -0800, michael wrote: I sent the original message to this list because the output from X suggested that this was the correct place for such info. If it is not, then should I open a bug against xserver-xfree86 suggesting that the output message be corrected to point to a more appropriate forum? also, this seems to be in line with the part in the charter about those with various graphics hardware who seek to reproduce and/or fix bugs in the X server. but if you say it's off-charter, then I'll take your word for it. but if so, then what about filing that bug I mentioned? Yes, actually the error message reported by the server was caused by a bug. It should have said [EMAIL PROTECTED] (This will be fixed in the next package release.) Please go ahead and file bug, after checking to make sure your problem hasn't already been reported. -- G. Branden Robinson| To be is to do -- Plato Debian GNU/Linux | To do is to be -- Aristotle [EMAIL PROTECTED] | Do be do be do -- Sinatra http://people.debian.org/~branden/ | pgp0.pgp Description: PGP signature
Re: X and SDL
On Fri, Feb 28, 2003 at 11:11:25PM +0100, J?r?me Marant wrote: Hi, I'd like to package sdl-ttf 2 and I wonder if I need to port the changes Branden made last year to sdl-ttf1.2. I browsed the libsdl1.2debian changelog and noticed that upstream must have fixed the problem: libsdl1.2 (1.2.3+cvs20020303-1) unstable; urgency=low ... - The SDL and X Extension Library mess has been provided with a better fix upstream. (Closes: #128827, #122754) [ This has since been confirmed to _not_ need package recompiles! ] ... This would mean I don't need to port changes. Could someone please confirm? Well, I heard that SDL was actually including the source code to the XFree86 static extension libraries in its own source tree, but changing the symbol names. If they did that, then yes, that's a fix. Though Keith Packard would say it's not a better one. :) -- G. Branden Robinson|Men use thought only to justify Debian GNU/Linux |their wrong doings, and speech only [EMAIL PROTECTED] |to conceal their thoughts. http://people.debian.org/~branden/ |-- Voltaire pgp0.pgp Description: PGP signature
Re: ati.2 drivers on 4.2.1-6 2003022523035
Please see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=182687 -- G. Branden Robinson| That's the saving grace of humor: Debian GNU/Linux | if you fail, no one is laughing at [EMAIL PROTECTED] | you. http://people.debian.org/~branden/ | -- A. Whitney Brown pgp0.pgp Description: PGP signature
Bug#182861: xkb errors on server startup [breaks meta key]
On Sat, Mar 01, 2003 at 09:17:05PM -0500, Branden Robinson scrawled: On Sat, Mar 01, 2003 at 01:25:31AM +0100, Mikael Hedin wrote: If so, I think I may know what caused this problem. :) I have to retract that. I'm not sure how this broke, and it would take a lot of time to track down. I will probably let this problem be fixed by 4.3.0-1 instead of 4.2.1-7. Yes, because the xkb in 4.3.0 is the best-quality xkb we've ever seen. :) -- Daniel Stone [EMAIL PROTECTED] Developer, Trinity College, University of Melbourne pgp0.pgp Description: PGP signature
Bug#182976: xserver-xfree86: more information in debconf about possible problems with framebuffer
Package: xserver-xfree86 Version: 4.2.1-3 Severity: minor Sometimes using the framebuffer device can lead to problems (for example when using nvidia drivers). The error message from the X server is not very verbose: EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found Nobody can know that this can be the result of using framebuffer. It would be good, if debconf displays an extra warning to the question of whether using the framebuffer device, like: If you get the error message no screens found and /var/log/XFree86.0.log contains the line EE) Screen(s) found, but none have a usable configuration., then this is possibly the result of using the framebuffer device. Try turning this option off, by running dpkg-reconfigure xserver-xfree86 and see if the error goes away. I would say this is more a bug of the actual X server, but this message could help newbies a lot by showing them a frequent cause of problems. Maybe this problem is the one of bug #157924: xserver-xfree86: [nv] no screens found on GeForce2 MX DDR rev 178 (I do not send the content of my /var/log/XFree86.0.log, because it wouldn't help here.) -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux lurkabove.darkstar 2.4.19 #1 Sam Sep 7 18:28:31 CEST 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] Versions of packages xserver-xfree86 depends on: ii debconf 1.2.21 Debian configuration management sy ii libc6 2.2.5-14.3 GNU C Library: Shared libraries an ii xserver-common4.2.1-3files and utilities common to all ii zlib1g1:1.1.4-6 compression library - runtime -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#182704: Debconf configuration sets use_fbdev without asking, making X unstartable
On Fri, Feb 28, 2003 at 08:27:02PM -0500, Branden Robinson wrote: On Fri, Feb 28, 2003 at 10:04:53PM +0100, Michel D?nzer wrote: Uh, so it sounds like you're telling me that /proc/fb is essentially useless for autoconfiguring the X server. 1) /proc/fb reporting something doesn't mean you can just switch on UseFBDev, because that won't work with generic [kernel] drivers I do think parsing /proc/fb to determine this is feasible, we just need to gather enough data. Well, why don't you get me started with some, and we can add more as time goes by? I think not all X drivers support (or even need) the UseFBDev flag. For example, the glint driver doesn't know anything about UseFBDev, and will work just fine without it, even if you were using pm3fb for example. That said it doesn't use the fbdev for mode configuration or anything. Now, the glint driver for pm2fb on amiga/apus hardware, will autodetect that we are on amiga/apus, and start using the fbdev in this case. More or less, michel wrote that code, so he knows more than me on this issue. Anyway, i guess the best solution would be to check each X driver, and see if it supports the UseFBDev option. Then you can either parse the /proc/fb for appropriate drivers, with a mapping like Michel suggest, or use the pci ids the driver supports. Still you would need to check if the specific fbdev was loaded before setting the UseFBDev or something such. Friendly, Sven Luther
Bug#182976: xserver-xfree86: more information in debconf about possible problems with framebuffer
Package: xserver-xfree86 Version: 4.2.1-3 Severity: minor Sometimes using the framebuffer device can lead to problems (for example when using nvidia drivers). The error message from the X server is not very verbose: EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found Nobody can know that this can be the result of using framebuffer. It would be good, if debconf displays an extra warning to the question of whether using the framebuffer device, like: If you get the error message no screens found and /var/log/XFree86.0.log contains the line EE) Screen(s) found, but none have a usable configuration., then this is possibly the result of using the framebuffer device. Try turning this option off, by running dpkg-reconfigure xserver-xfree86 and see if the error goes away. I would say this is more a bug of the actual X server, but this message could help newbies a lot by showing them a frequent cause of problems. Maybe this problem is the one of bug #157924: xserver-xfree86: [nv] no screens found on GeForce2 MX DDR rev 178 (I do not send the content of my /var/log/XFree86.0.log, because it wouldn't help here.) -- System Information Debian Release: testing/unstable Architecture: i386 Kernel: Linux lurkabove.darkstar 2.4.19 #1 Sam Sep 7 18:28:31 CEST 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] Versions of packages xserver-xfree86 depends on: ii debconf 1.2.21 Debian configuration management sy ii libc6 2.2.5-14.3 GNU C Library: Shared libraries an ii xserver-common4.2.1-3files and utilities common to all ii zlib1g1:1.1.4-6 compression library - runtime
Bug#182924: xserver-xfree86: Xserver freezes on resume from suspend to disk with radeon chips and DRI enabled
On Fri, Feb 28, 2003 at 08:34:59PM -0500, Branden Robinson wrote: LY. It will completly lock the machine. This is a known problem. Charl Botha has written a patch for this. Since it is still not included in the XF86 cvs and is also missing in XFree86 4.3 according to http://www.mail-archive.com/devel@xfree86.org/msg00207.html and my own experience with 4.3, I would like to have the patches applied for the Debian package xserver-xfree86. More information about this problem can be found at http://cpbotha.net/dri_resume.html, patches can be found at http://cpbotha.net/files/dri_resume/. The patch is pretty extensive; this means it may not apply cleanly given all the other patches I've made to the driver for Debian's packages. I may not have the patience do a lot of hand-merging, however, I will give this patch a shot. If it's too much trouble I'll let you know; in that event perhaps you can mail debian-x or some other mailing list and find someone with this hardware and willing to prepare a version of the patch for our packages. Another problem is that my patch makes crucial modifications to the DRM, without which the Radeon XFree86 driver patches will have little or no effect. The DRM is the only place where things like Radeon microcode can be reloaded after resume. I've thought about this, but wouldn't know how to package this for Debian, as Debian ships an unpatched kernel AFAICR. Are there other packages which ship kernel modules? I did submit the work to [EMAIL PROTECTED], but apparently too late for the 4.3 release. I've been promised that it would be integrated AFTER the 4.3 release, so eventually the DRM part will propagate into the 2.5 (and probably 2.4) kernel trees. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/
Bug#182986: Savage driver doesn't work (ThinkPad T23)
Package: xserver-xfree86 Version: 4.2.1-6 Severity: important Tags: sid Using version 4.2.1-5 (IIRC), X worked just fine here. After upgrading to 4.2.1-6, the screen just shows a black background (instead of the normal X background). The mouse cursor is still visible though, and can be moved normally. Furthermore, I believe that X applications (such as KDM) are started correctly, except that I can't see anything... This is a ThinkPad T23 with a SuperSavage card. -- Package-specific info: 01:00.0 VGA compatible controller: S3 Inc. SuperSavage IX/C SDR (rev 05) 01:00.0 Class 0300: 5333:8c2e (rev 05) # XF86Config-4 (XFree86 server configuration file) 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.) # # If you want your changes to this file preserved by dexconf, only make changes # before the ### BEGIN DEBCONF SECTION line above, and/or after the # ### END DEBCONF SECTION line below. # # To change things within the debconf section, run the command: # dpkg-reconfigure xserver-xfree86 # as root. Also see How do I add custom sections to a dexconf-generated # XF86Config or XF86Config-4 file? in /usr/share/doc/xfree86-common/FAQ.gz. Section Files # 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/75dpi/:unscaled FontPath/usr/lib/X11/fonts/100dpi/:unscaled FontPath/usr/lib/X11/fonts/Type1 FontPath/usr/lib/X11/fonts/Speedo FontPath/usr/lib/X11/fonts/75dpi FontPath/usr/lib/X11/fonts/100dpi FontPath/var/lib/defoma/x-ttcidfont-conf.d/dirs/CID FontPath/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType EndSection Section Module LoadGLcore Loadbitmap Loaddbe Loadddc Loaddri Loadextmod Loadfreetype Loadglx Loadint10 Loadrecord Loadspeedo Loadtype1 Loadvbe 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/psaux Option Protocol PS/2 EndSection Section InputDevice Identifier Generic Mouse Driver mouse Option SendCoreEventstrue Option Device/dev/input/mice Option Protocol ImPS/2 Option Buttons 5 Option ZAxisMapping 4 5 EndSection Section Device Identifier Generic Video Card Driver savage Option UseFBDev true EndSection Section Monitor Identifier Generic Monitor HorizSync 28-49 VertRefresh 43-72 Option DPMS EndSection Section Screen Identifier Default Screen Device Generic Video Card Monitor Generic Monitor DefaultDepth24 SubSection Display Depth 1 Modes 1024x768 EndSubSection SubSection Display Depth 4 Modes 1024x768 EndSubSection SubSection Display Depth 8 Modes 1024x768 EndSubSection SubSection Display Depth 15 Modes 1024x768 EndSubSection SubSection Display Depth 16 Modes 1024x768 EndSubSection SubSection Display Depth 24 Modes 1024x768 EndSubSection EndSection Section ServerLayout Identifier Default Layout Screen Default Screen InputDevice Generic Keyboard InputDevice Configured Mouse InputDevice Generic Mouse EndSection Section DRI Mode0666 EndSection This is version 4.2.1-6: 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
Bug#182924: xserver-xfree86: Xserver freezes on resume from suspend to disk with radeon chips and DRI enabled
On Sam, 2003-03-01 at 14:17, Charl P. Botha wrote: On Fri, Feb 28, 2003 at 08:34:59PM -0500, Branden Robinson wrote: LY. It will completly lock the machine. This is a known problem. Charl Botha has written a patch for this. Since it is still not included in the XF86 cvs and is also missing in XFree86 4.3 according to http://www.mail-archive.com/devel@xfree86.org/msg00207.html and my own experience with 4.3, I would like to have the patches applied for the Debian package xserver-xfree86. More information about this problem can be found at http://cpbotha.net/dri_resume.html, patches can be found at http://cpbotha.net/files/dri_resume/. The patch is pretty extensive; this means it may not apply cleanly given all the other patches I've made to the driver for Debian's packages. I may not have the patience do a lot of hand-merging, however, I will give this patch a shot. If it's too much trouble I'll let you know; in that event perhaps you can mail debian-x or some other mailing list and find someone with this hardware and willing to prepare a version of the patch for our packages. Another problem is that my patch makes crucial modifications to the DRM, without which the Radeon XFree86 driver patches will have little or no effect. As long as it doesn't have a bad effect... -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast
Bug#182976: xserver-xfree86: more information in debconf about possible problems with framebuffer
On Sam, 2003-03-01 at 13:10, Marco Herrn wrote: Sometimes using the framebuffer device can lead to problems (for example when using nvidia drivers). How so? I thought they simply didn't support it, in which case they should ignore it. The error message from the X server is not very verbose: EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found Nobody can know that this can be the result of using framebuffer. Indeed, because it's a very generic error message which can be caused by a lot of things. If Option UseFBDev is a problem, the usual symptom is the driver aborting right after loading the fbdevhw module. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast
Unidentified subject!
Hi, this is my big problem... SID, XP1.700+, MSI KT-333, 512DDR, Inno GEF4 4200/64AGP4X Everithing was fine, until the last dselect/update/install... Thnx, Attila Kovari 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.2.1.1 (Debian 4.2.1-6 20030225230350 [EMAIL PROTECTED]) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 18 October 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.20-586tsc i686 [ELF] Module Loader present 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: Sat Mar 1 14:03:35 2003 (==) Using config file: /etc/X11/XF86Config-4 (==) ServerLayout XFree86 Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Card0 (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (==) Keyboard: CustomKeycode disabled (**) FontPath set to unix/:7110,unix/:7100,/usr/X11R6/lib/X11/fonts/misc/ (**) 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.1 XFree86 Video Driver: 0.5 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (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.2.1.1, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (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.2.1.1, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x80a8, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1106,3099 card 1106, rev 00 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1106,b099 card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:06:0: chip 109e,0350 card , rev 12 class 04,00,00 hdr 00 (II) PCI: 00:07:0: chip 1274,5880 card 1274,2000 rev 02 class 04,01,00 hdr 00 (II) PCI: 00:08:0: chip 8086,1229 card 8086,0009 rev 05 class 02,00,00 hdr 00 (II) PCI: 00:10:0: chip 1106,3038 card 1106,3038 rev 80 class 0c,03,00 hdr 80 (II) PCI: 00:10:1: chip 1106,3038 card 1106,3038 rev 80 class 0c,03,00 hdr 80 (II) PCI: 00:10:2: chip 1106,3038 card 1106,3038 rev 80 class 0c,03,00 hdr 80 (II) PCI: 00:10:3: chip 1106,3104 card 1106,3104 rev 82 class 0c,03,20 hdr 00 (II) PCI: 00:11:0: chip 1106,3177 card 1106, rev 00 class 06,01,00 hdr 80 (II) PCI: 00:11:1: chip 1106,0571 card 1106,0571 rev 06 class 01,01,8a hdr 00 (II) PCI: 01:00:0: chip 10de,0253 card , rev a3 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) LoadModule: scanpci (II) Loading /usr/X11R6/lib/modules/libscanpci.a (II) Module scanpci: vendor=The XFree86 Project compiled for 4.2.1.1, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) UnloadModule: scanpci (II) Unloading /usr/X11R6/lib/modules/libscanpci.a (II) Host-to-PCI bridge: (II) PCI-to-ISA bridge: (II) PCI-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (-1,0,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 00x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 00x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 00x - 0x (0x0) MX[B] (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x0c (VGA_EN is set) (II) Bus 1 I/O range: (II) Bus 1 non-prefetchable memory range: [0] -1 00xdda0 - 0xdfaf (0x210) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 00xd570 - 0xdd8f (0x820) MX[B] (II) Bus -1: bridge is at (0:17:0), (0,-1,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus -1 I/O range: (II) Bus -1 non-prefetchable memory range: (II) Bus -1 prefetchable memory range: (--) PCI: (0:6:0) BrookTree 848 rev 18, Mem @ 0xdd9ff000/12 (--) PCI:*(1:0:0) NVidia GeForce4 Ti 4200 rev 163, Mem @ 0xde00/24, 0xd800/26,
Bug#182986: Same Problem on a T20 with a Savage/MX chipset
I had the exact same problem on my T20 with the Savage/MX chipset. I tried changing resolutions, color depths. I threw out my X config and started over. I tried through an external monitor, or the panel directly. None of them worked. I had to spend two hours downgrading almost everything, and reinstalling against testing just to get my X back up. -- Ryan Eatmon [EMAIL PROTECTED]
Bug#182704: Debconf configuration sets use_fbdev without asking, making X unstartable
On Sam, 2003-03-01 at 02:27, Branden Robinson wrote:
On Fri, Feb 28, 2003 at 10:04:53PM +0100, Michel D?nzer wrote:
Uh, so it sounds like you're telling me that /proc/fb is essentially
useless for autoconfiguring the X server.
1) /proc/fb reporting something doesn't mean you can just switch on
UseFBDev, because that won't work with generic [kernel] drivers
I do think parsing /proc/fb to determine this is feasible, we just need
to gather enough data.
Well, why don't you get me started with some, and we can add more as
time goes by?
Here's some OFfb output:
0 OFfb /[EMAIL PROTECTED]/ATY,[EMAIL PROTECTED]/AT
And vesafb:
0 VESA VGA
These look easy. :) I think these are the most common generic
framebuffer devices, then there's also vga{16,256}fb but I doubt they
are widely used.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
Bug#183029: PATCH: put X, XIM, Xfs unix sockets in /var/run/X11
Package: xfree86
Version: unavailable; reported 2003-03-01
Severity: wishlist
Tags: patch
As requested I'm re-transmitting this as a wishlist bug.
I edited the change to debian/xfree86-common.README.Debian so that it
now says 4.3.0-1 instead of 4.2.1-6. 4.2.1-6 is already out the
door, and I'm guessing you'd rather look at this in the 4.3.x timeframe
anyway.
This patch moves the UNIX domain sockets created by the X server, the
font server, and XIM input methods from various .subdirs of /tmp to
/var/run/X11, which directory is created at boot time by the existing
xfree86-common init script.
This change naturally has backward compatibility implications. There
are several cases to consider:
* New client, old server (for any of the above): logic exists in the
Xtrans client code to try an old location if the socket is not found
in the new one, so this is not a problem.
* New X server, old libX11: The boot script creates a symbolic link
from /tmp/.X11-unix to /var/run/X11, which should prevent any
trouble in this case. (Users who know they don't need this can
disable it.)
* New font server or input method, old X server: This is unlikely to
come up, but the boot script can be edited to create more symlinks
if necessary. README.Debian documents this.
I did not move the socket directory for libICE, because those sockets
get created by arbitrary users. The major point of moving sockets to
/var/run/X11 is that that directory can be mode 755. I can think of a
couple ways to get around that but they're all messy enough not to be
worth it.
I also did not move /tmp/.X%d-lock as that would break cohabitation of
old and new X servers on the same host.
zw
--- xc/config/cf/linux.cf~ 2003-02-06 23:42:21.0 -0800
+++ xc/config/cf/linux.cf 2003-02-14 14:17:55.0 -0800
@@ -125,7 +125,8 @@
# define SharedLibGlu YES
# define NormalLibGlu YES
# define FSUseSyslog YES
+# define UnixSocketsInVarRun YES
/*
*
--- xc/config/cf/X11.tmpl~ 2003-02-06 20:56:37.0 -0800
+++ xc/config/cf/X11.tmpl 2003-02-14 14:21:07.0 -0800
@@ -562,6 +562,10 @@
#define InstallMiscManPagesNO
#endif
+#ifndef UnixSocketsInVarRun
+#define UnixSocketsInVarRunNO
+#endif
+
#ifndef FSUseSyslog
#define FSUseSyslogNO
#endif
@@ -704,8 +708,11 @@
#if HasFchown
FCHOWN_DEFINES = -DHAS_FCHOWN
#endif
+#if UnixSocketsInVarRun
+USLOC_DEFINES = -DSOCKETS_IN_VAR_RUN
+#endif
#ifndef ExtraConnectionDefs
-#define ExtraConnectionDefs $(STICKY_DEFINES) $(FCHOWN_DEFINES)
+#define ExtraConnectionDefs $(STICKY_DEFINES) $(FCHOWN_DEFINES)
$(USLOC_DEFINES)
#endif
#ifndef ProjectThreadsDefines
#define ProjectThreadsDefines -DXTHREADS
--- xc/lib/xtrans/Xtranssock.c~ 2001-12-14 11:57:06.0 -0800
+++ xc/lib/xtrans/Xtranssock.c 2003-02-14 14:46:14.0 -0800
@@ -228,7 +228,40 @@
#define UNIX_DIR /usr/spool/sockets/X11
#endif
-#else /* !hpux */
+#elif defined(SOCKETS_IN_VAR_RUN)
+
+#if defined(X11_t)
+#define UNIX_PATH /var/run/X11/X
+#define UNIX_DIR /var/run/X11
+#define OLD_UNIX_PATH /tmp/.X11-unix/X
+#endif /* X11_t */
+#if defined(XIM_t)
+#define UNIX_PATH /var/run/X11/XIM
+#define UNIX_DIR /var/run/X11
+#define OLD_UNIX_PATH /tmp/.XIM-unix/XIM
+#endif /* XIM_t */
+#if defined(FS_t) || defined(FONT_t)
+#define UNIX_PATH /var/run/X11/fs
+#define UNIX_DIR /var/run/X11
+#define OLD_UNIX_PATH /tmp/.font-unix/fs
+#endif /* FS_t || FONT_t */
+#if defined(ICE_t)
+/* ICE sockets stay in /tmp since those are created by clients. */
+#define UNIX_PATH /tmp/.ICE-unix/
+#define UNIX_DIR /tmp/.ICE-unix
+#endif /* ICE_t */
+#if defined(TEST_t)
+/* ??? Does not appear to be used for anything. */
+#define UNIX_PATH /tmp/.Test-unix/test
+#define UNIX_DIR /tmp/.Test-unix
+#endif
+#if defined(LBXPROXY_t)
+#define UNIX_PATH /var/run/X11/X
+#define UNIX_DIR /var/run/X11
+#define OLD_UNIX_PATH /tmp/.X11-unix/X
+#endif
+
+#else /* not hpux and not /var/run/X11 */
#if defined(X11_t)
#define UNIX_PATH /tmp/.X11-unix/X
@@ -1552,7 +1585,7 @@
struct sockaddr_un sockname;
intnamelen;
-#if defined(hpux) defined(X11_t)
+#ifdef OLD_UNIX_PATH
struct sockaddr_un old_sockname;
intold_namelen;
#endif
@@ -1607,9 +1640,9 @@
#endif
-#if defined(hpux) defined(X11_t)
+#ifdef OLD_UNIX_PATH
/*
- * This is gross, but it was in Xlib
+ * Support an older location for the socket.
*/
old_sockname.sun_family = AF_UNIX;
if (set_sun_path(port, OLD_UNIX_PATH, old_sockname.sun_path) != 0) {
@@ -1620,7 +1653,6 @@
sizeof (old_sockname.sun_family);
#endif
-
/*
* Do the connect()
*/
@@ -1630,7 +1662,7 @@
int olderrno = errno;
int connected = 0;
-#if defined(hpux) defined(X11_t)
+#ifdef OLD_UNIX_PATH
if (olderrno == ENOENT)
{
if (connect (ciptr-fd,
--- debian/xfree86-common.init~
Bug#182704: Debconf configuration sets use_fbdev without asking, making X unstartable
On Sam, 2003-03-01 at 11:32, Sven Luther wrote: On Fri, Feb 28, 2003 at 08:27:02PM -0500, Branden Robinson wrote: On Fri, Feb 28, 2003 at 10:04:53PM +0100, Michel D?nzer wrote: Uh, so it sounds like you're telling me that /proc/fb is essentially useless for autoconfiguring the X server. 1) /proc/fb reporting something doesn't mean you can just switch on UseFBDev, because that won't work with generic [kernel] drivers I do think parsing /proc/fb to determine this is feasible, we just need to gather enough data. Well, why don't you get me started with some, and we can add more as time goes by? I think not all X drivers support (or even need) the UseFBDev flag. In general, those that don't support it ignore it. For example, the glint driver doesn't know anything about UseFBDev, and will work just fine without it, even if you were using pm3fb for example. That said it doesn't use the fbdev for mode configuration or anything. Now, the glint driver for pm2fb on amiga/apus hardware, will autodetect that we are on amiga/apus, and start using the fbdev in this case. More or less, michel wrote that code, so he knows more than me on this issue. AFAICS the glint driver is a special case which can be covered by adding pm3fb to the list of framebuffer devices Option UseFBDev doesn't work with. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast
Processed: Merging duplicate bugs
Processing commands for [EMAIL PROTECTED]: reassign 179263 xlibmesa3-gl Bug#179263: xserver-xfree86: GL graphics stopped working on my system after the last sid update of xserver-xfree86 Bug reassigned from package `xserver-xfree86' to `xlibmesa3-gl'. reassign 179789 xlibmesa3-gl Bug#179789: Problem with X 4.2.1-5 and Radeons Bug reassigned from package `xserver-xfree86' to `xlibmesa3-gl'. severity 179263 important Bug#179263: xserver-xfree86: GL graphics stopped working on my system after the last sid update of xserver-xfree86 Severity set to `important'. severity 179789 important Bug#179789: Problem with X 4.2.1-5 and Radeons Severity set to `important'. tags 179263 sid Bug#179263: xserver-xfree86: GL graphics stopped working on my system after the last sid update of xserver-xfree86 There were no tags set. Tags added: sid tags 179789 sid Bug#179789: Problem with X 4.2.1-5 and Radeons Tags were: sid Tags added: sid merge 179263 179789 178242 Bug#178242: xlibmesa3: [radeon_dri] hardware acceleration non-functional on Radeon 7500 QW Bug#179263: xserver-xfree86: GL graphics stopped working on my system after the last sid update of xserver-xfree86 Bug#179789: Problem with X 4.2.1-5 and Radeons Bug#180502: xlibmesa3-gl: [radeon_dri] hardware acceleration non-functional Bug#182524: xlibmesa3-gl: glx displays only blankness Merged 178242 179263 179789 180502 182524. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#179263: Merging duplicate bugs
reassign 179263 xlibmesa3-gl reassign 179789 xlibmesa3-gl severity 179263 important severity 179789 important tags 179263 sid tags 179789 sid merge 179263 179789 178242 thanks [This is a form letter.] Hello, You recently filed a duplicate bug report against Debian's XFree86 packages; that is, the problem had already been reported. While there is often nothing inherently wrong with doing so, the filing of duplicate reports can cause Debian package maintainers to spend time performing triage and maintenance operations on bug reports (e.g., instructing the Debian Bug Tracking System to merge the duplicates) that could otherwise be spent resolving problems and doing other work on the package. One very good way to file bugs with the Debian Bug Tracking System is to use the reportbug package and command of the same name. A very nice feature of reportbug is that, if the machine where you run it has network access to the World Wide Web, it can query the Debian Bug Tracking System and show you existing reports. This reduces the chance that you'll file a duplicate report, and offers you the option of adding follow-up information to an existing bug report. This is especially valuable if you have unique information to add to an existing report, because this way information relevant to the problem is gathered together in one place as opposed to being scattered among multiple, duplicate bug reports where some facts may be overlooked by the package maintainers. The reportbug program also does a lot of automatic information-gathering that helps package maintainers to understand your system configuration, and also ensures that your message to the Debian Bug Tracking System is well-formed so that it is processed correctly by the automated tools that manage the reports. (If you've ever gotten a bounce message from the Debian Bug Tracking System that tells you your message couldn't be processed, you might appreciate this latter feature.) Therefore, I strongly urge you to give reportbug a try as your primary bug reporting tool for the Debian System. One way to install reportbug is with apt-get; for example: $ apt-get install reportbug The reportbug command has a few different modes that cater to different levels of user expertise. If this message has contained a lot of jargon that is unfamiliar to you, you likely want to use reportbug's novice mode; here's one way to do that. $ reportbug --mode=novice Please enter the name of the package in which you have found a problem, or type 'other' to report a more general problem. If you're more sophisticated, or if you are not using the released version of Debian (stable), but instead Debian testing or unstable, you should use reportbug's standard mode. $ reportbug Please enter the name of the package in which you have found a problem, or type 'other' to report a more general problem. The reportbug command is extensively documented in its usage message and manual page. Commands to view these pieces of documentation are: $ reportbug --help | more $ man reportbug (The output of the above commands has been omitted from this message.) Thanks for using the Debian system!
Processed: retitle 182976 to xserver-xfree86: [core server] hack server to tell people 'no screens found' can be due to 'UseFBDev' option
Processing commands for [EMAIL PROTECTED]: retitle 182976 xserver-xfree86: [core server] hack server to tell people 'no screens found' can be due to 'UseFBDev' option Bug#182976: xserver-xfree86: more information in debconf about possible problems with framebuffer Changed Bug title. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Processed: Re: Bug#182986: Savage driver doesn't work (ThinkPad T23)
Processing commands for [EMAIL PROTECTED]: severity 182986 normal Bug#182986: Savage driver doesn't work (ThinkPad T23) Severity set to `normal'. retitle 182986 xserver-xfree86: [savage] patch to 'stop softbooting twice' keeps driver from working on some /MX and /IX chips Bug#182986: Savage driver doesn't work (ThinkPad T23) Changed Bug title. merge 182788 182986 Bug#182788: xserver-xfree86: [savage] patch to 'stop softbooting twice' keeps driver from working on some /MX and /IX chips Bug#182986: xserver-xfree86: [savage] patch to 'stop softbooting twice' keeps driver from working on some /MX and /IX chips Bug#182831: xserver-xfree86: [savage] failed to fetch bios modes on SuperSavage IX/C SDR (rev 05) Merged 182788 182831 182986. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Bug#182924: xserver-xfree86: Xserver freezes on resume from suspend to disk with radeon chips and DRI enabled
On Sat, Mar 01, 2003 at 02:17:59PM +0100, Charl P. Botha wrote: I've thought about this, but wouldn't know how to package this for Debian, as Debian ships an unpatched kernel AFAICR. Are there other packages which ship kernel modules? Oh, a couple: % apt-cache search kernel-patch | grep '^kernel-patch' | head kernel-patch-2.2.17-vm-global - Andrea Archangeli's 2.2.17pre11 vm-global patch, modified for 2.2.17. kernel-patch-2.2.18-openwall - patch to add extra security-related features to the linux kernel. kernel-patch-2.2.18-vm-global - Andrea Archangeli's 2.2.18pre25 vm-global patch. kernel-patch-2.2.19-arm - Diffs to the Linux kernel source 2.2.19 for ARM kernel-patch-2.2.20-arm - Diffs to the Linux kernel source 2.2.20 for ARM kernel-patch-2.2.20-ide - Andre Hedrick's IDE patch. kernel-patch-2.2.20-m68k - Diffs to the kernel source for m68k kernel-patch-2.2.20-p3 - Doug Ledford's 2.2.12 p3 patch, modified for 2.2.20. kernel-patch-2.2.20-powerpc - Diffs to the kernel source for PowerPC kernel-patch-2.2.20-raid - Ingo Molnar's patch of raid2 functionality to 2.2.x (There are many more.) -- G. Branden Robinson| Mob rule isn't any prettier just Debian GNU/Linux | because you call your mob a [EMAIL PROTECTED] | government. http://people.debian.org/~branden/ | pgpI9j80mtMpH.pgp Description: PGP signature
Bug#182704: Debconf configuration sets use_fbdev without asking, making X unstartable
On Sat, Mar 01, 2003 at 08:49:47PM +0100, Michel D?nzer wrote: For example, the glint driver doesn't know anything about UseFBDev, and will work just fine without it, even if you were using pm3fb for example. That said it doesn't use the fbdev for mode configuration or anything. Now, the glint driver for pm2fb on amiga/apus hardware, will autodetect that we are on amiga/apus, and start using the fbdev in this case. More or less, michel wrote that code, so he knows more than me on this issue. AFAICS the glint driver is a special case which can be covered by adding pm3fb to the list of framebuffer devices Option UseFBDev doesn't work with. pm3fb or pm2fb? I don't see a justification in the above paragraphs for marking either of them as incompatible with UseFBDev. Will work fine without it doesn't mean we should forbid usage of UseFBDev with that framebuffer type. We should only forbid where we know it will always cause problems. -- G. Branden Robinson| To be is to do -- Plato Debian GNU/Linux | To do is to be -- Aristotle [EMAIL PROTECTED] | Do be do be do -- Sinatra http://people.debian.org/~branden/ | pgpWw6OlnBJTB.pgp Description: PGP signature
Bug#182704: Debconf configuration sets use_fbdev without asking, making X unstartable
On Sat, Mar 01, 2003 at 03:30:02PM +0100, Michel D?nzer wrote:
Here's some OFfb output:
0 OFfb /[EMAIL PROTECTED]/ATY,[EMAIL PROTECTED]/AT
And vesafb:
0 VESA VGA
These look easy. :) I think these are the most common generic
framebuffer devices, then there's also vga{16,256}fb but I doubt they
are widely used.
Okay, here's the new code based on this:
# use fbcon kernel functions?
USE_FBDEV=
if [ -e /proc/fb ]; then
FB_TYPE=$(awk '{print $2}' /proc/fb)
# did we actually get back anything?
if [ -n $FB_TYPE ]; then
case $FB_TYPE in
OFfb|VESA)
# generic framebuffer that doesn't support UseFBDev
;;
*)
# other framebuffers do support UseFBDEV
USE_FBDEV=yes
;;
esac
fi
fi
if [ -n $USE_FBDEV ]; then
auto_answer db_input high xserver-xfree86/config/device/use_fbdev true
else
db_get xserver-xfree86/config/device/use_fbdev || debug_report_status db_get
xserver-xfree86/config/device/use_fbdev $?
if [ $RET = true ]; then
debug_echo xserver-xfree86/config/device/use_fbdev is \true\ but
/proc/fb does not exist, is empty, or reports a framebuffer type with which
UseFBDev cannot be used; setting template to \false\
db_set xserver-xfree86/config/device/use_fbdev false
fi
fi
Comments?
--
G. Branden Robinson|I have a truly elegant proof of the
Debian GNU/Linux |above, but it is too long to fit
[EMAIL PROTECTED] |into this .signature file.
http://people.debian.org/~branden/ |
pgp43x6k1GMA9.pgp
Description: PGP signature
Bug#182986: Savage driver doesn't work (ThinkPad T23)
severity 182986 normal retitle 182986 xserver-xfree86: [savage] patch to 'stop softbooting twice' keeps driver from working on some /MX and /IX chips merge 182788 182986 thanks [This is a form letter.] Hello, You recently filed a duplicate bug report against Debian's XFree86 packages; that is, the problem had already been reported. While there is often nothing inherently wrong with doing so, the filing of duplicate reports can cause Debian package maintainers to spend time performing triage and maintenance operations on bug reports (e.g., instructing the Debian Bug Tracking System to merge the duplicates) that could otherwise be spent resolving problems and doing other work on the package. One very good way to file bugs with the Debian Bug Tracking System is to use the reportbug package and command of the same name. A very nice feature of reportbug is that, if the machine where you run it has network access to the World Wide Web, it can query the Debian Bug Tracking System and show you existing reports. This reduces the chance that you'll file a duplicate report, and offers you the option of adding follow-up information to an existing bug report. This is especially valuable if you have unique information to add to an existing report, because this way information relevant to the problem is gathered together in one place as opposed to being scattered among multiple, duplicate bug reports where some facts may be overlooked by the package maintainers. The reportbug program also does a lot of automatic information-gathering that helps package maintainers to understand your system configuration, and also ensures that your message to the Debian Bug Tracking System is well-formed so that it is processed correctly by the automated tools that manage the reports. (If you've ever gotten a bounce message from the Debian Bug Tracking System that tells you your message couldn't be processed, you might appreciate this latter feature.) Therefore, I strongly urge you to give reportbug a try as your primary bug reporting tool for the Debian System. One way to install reportbug is with apt-get; for example: $ apt-get install reportbug The reportbug command has a few different modes that cater to different levels of user expertise. If this message has contained a lot of jargon that is unfamiliar to you, you likely want to use reportbug's novice mode; here's one way to do that. $ reportbug --mode=novice Please enter the name of the package in which you have found a problem, or type 'other' to report a more general problem. If you're more sophisticated, or if you are not using the released version of Debian (stable), but instead Debian testing or unstable, you should use reportbug's standard mode. $ reportbug Please enter the name of the package in which you have found a problem, or type 'other' to report a more general problem. The reportbug command is extensively documented in its usage message and manual page. Commands to view these pieces of documentation are: $ reportbug --help | more $ man reportbug (The output of the above commands has been omitted from this message.) Thanks for using the Debian system! -- G. Branden Robinson| Q: How does a Unix guru have sex? Debian GNU/Linux | A: unzip;strip;touch;finger;mount; [EMAIL PROTECTED] |fsck;more;yes;fsck;fsck;fsck; http://people.debian.org/~branden/ |umount;sleep pgpTjFoJ7T1J2.pgp Description: PGP signature
Bug#182704: Debconf configuration sets use_fbdev without asking, making X unstartable
On Sam, 2003-03-01 at 22:20, Branden Robinson wrote:
On Sat, Mar 01, 2003 at 03:30:02PM +0100, Michel D?nzer wrote:
Here's some OFfb output:
0 OFfb /[EMAIL PROTECTED]/ATY,[EMAIL PROTECTED]/AT
And vesafb:
0 VESA VGA
These look easy. :) I think these are the most common generic
framebuffer devices, then there's also vga{16,256}fb but I doubt they
are widely used.
Okay, here's the new code based on this:
# use fbcon kernel functions?
USE_FBDEV=
if [ -e /proc/fb ]; then
FB_TYPE=$(awk '{print $2}' /proc/fb)
# did we actually get back anything?
if [ -n $FB_TYPE ]; then
case $FB_TYPE in
OFfb|VESA)
# generic framebuffer that doesn't support UseFBDev
;;
*)
# other framebuffers do support UseFBDEV
USE_FBDEV=yes
;;
esac
fi
fi
if [ -n $USE_FBDEV ]; then
auto_answer db_input high xserver-xfree86/config/device/use_fbdev true
else
db_get xserver-xfree86/config/device/use_fbdev || debug_report_status
db_get xserver-xfree86/config/device/use_fbdev $?
if [ $RET = true ]; then
debug_echo xserver-xfree86/config/device/use_fbdev is \true\ but
/proc/fb does not exist, is empty, or reports a framebuffer type with which
UseFBDev cannot be used; setting template to \false\
db_set xserver-xfree86/config/device/use_fbdev false
fi
fi
Comments?
I think this doesn't handle multiple framebuffer devices, it would set
USE_FBDEV to yes no matter what they are. I'm not sure how to handle
that though, maybe
FB_TYPE=$(egrep '^0' /proc/fb | awk '{print $2}')
?
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
Bug#182924: xserver-xfree86: Xserver freezes on resume from suspend to disk with radeon chips and DRI enabled
On Sat, Mar 01, 2003 at 02:17:59PM +0100, Charl P. Botha scrawled: Another problem is that my patch makes crucial modifications to the DRM, without which the Radeon XFree86 driver patches will have little or no effect. The DRM is the only place where things like Radeon microcode can be reloaded after resume. I've thought about this, but wouldn't know how to package this for Debian, as Debian ships an unpatched kernel AFAICR. Are there other packages which ship kernel modules? I did submit the work to [EMAIL PROTECTED], but apparently too late for the 4.3 release. I've been promised that it would be integrated AFTER the 4.3 release, so eventually the DRM part will propagate into the 2.5 (and probably 2.4) kernel trees. Hi Charl! I've integrated your patch into 4.3.0-1, which means that both xserver-xfree86 and xlibmesa4-drm-src will work properly with Radeons resuming. Thanks for all your work! :) d -- Daniel Stone [EMAIL PROTECTED] Developer, Trinity College, University of Melbourne pgp8FptBC1Oxf.pgp Description: PGP signature
Bug#182924: xserver-xfree86: Xserver freezes on resume from suspend to disk with radeon chips and DRI enabled
Hello there Daniel, On Sun, Mar 02, 2003 at 11:58:05AM +1100, Daniel Stone wrote: On Sat, Mar 01, 2003 at 02:17:59PM +0100, Charl P. Botha scrawled: I did submit the work to [EMAIL PROTECTED], but apparently too late for the 4.3 release. I've been promised that it would be integrated AFTER the 4.3 release, so eventually the DRM part will propagate into the 2.5 (and probably 2.4) kernel trees. Hi Charl! I've integrated your patch into 4.3.0-1, which means that both xserver-xfree86 and xlibmesa4-drm-src will work properly with Radeons resuming. Thanks for all your work! Ali GRESPEC! Fank you./Ali G Seriously, that's impressively fast. :) Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/
Processed: tagging 182773
Processing commands for [EMAIL PROTECTED]: tag 182773 + moreinfo Bug#182773: xserver-xfree86: [mga] hardware 3D accel + VT switching causes screen corruption and lockup on MGA G400 AGP rev 4 There were no tags set. Tags added: moreinfo End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database)
Re: output from X -configure
On Fri, Feb 28, 2003 at 11:03:49AM -0800, michael wrote: I sent the original message to this list because the output from X suggested that this was the correct place for such info. If it is not, then should I open a bug against xserver-xfree86 suggesting that the output message be corrected to point to a more appropriate forum? also, this seems to be in line with the part in the charter about those with various graphics hardware who seek to reproduce and/or fix bugs in the X server. but if you say it's off-charter, then I'll take your word for it. but if so, then what about filing that bug I mentioned? Yes, actually the error message reported by the server was caused by a bug. It should have said [EMAIL PROTECTED] (This will be fixed in the next package release.) Please go ahead and file bug, after checking to make sure your problem hasn't already been reported. -- G. Branden Robinson| To be is to do -- Plato Debian GNU/Linux | To do is to be -- Aristotle [EMAIL PROTECTED] | Do be do be do -- Sinatra http://people.debian.org/~branden/ | pgp4XNOMsEZ0o.pgp Description: PGP signature
Re: X and SDL
On Fri, Feb 28, 2003 at 11:11:25PM +0100, J?r?me Marant wrote: Hi, I'd like to package sdl-ttf 2 and I wonder if I need to port the changes Branden made last year to sdl-ttf1.2. I browsed the libsdl1.2debian changelog and noticed that upstream must have fixed the problem: libsdl1.2 (1.2.3+cvs20020303-1) unstable; urgency=low ... - The SDL and X Extension Library mess has been provided with a better fix upstream. (Closes: #128827, #122754) [ This has since been confirmed to _not_ need package recompiles! ] ... This would mean I don't need to port changes. Could someone please confirm? Well, I heard that SDL was actually including the source code to the XFree86 static extension libraries in its own source tree, but changing the symbol names. If they did that, then yes, that's a fix. Though Keith Packard would say it's not a better one. :) -- G. Branden Robinson|Men use thought only to justify Debian GNU/Linux |their wrong doings, and speech only [EMAIL PROTECTED] |to conceal their thoughts. http://people.debian.org/~branden/ |-- Voltaire pgpEFA42ObeTT.pgp Description: PGP signature
Re: ati.2 drivers on 4.2.1-6 2003022523035
Please see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=182687 -- G. Branden Robinson| That's the saving grace of humor: Debian GNU/Linux | if you fail, no one is laughing at [EMAIL PROTECTED] | you. http://people.debian.org/~branden/ | -- A. Whitney Brown pgpjtVWL8gcyz.pgp Description: PGP signature
Re: Unidentified subject!
Please see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=182687 -- G. Branden Robinson| It's not a matter of alienating Debian GNU/Linux | authors. They have every right to [EMAIL PROTECTED] | license their software however we http://people.debian.org/~branden/ | like. -- Craig Sanders pgpwrIAgIKjWf.pgp Description: PGP signature
Bug#182861: xkb errors on server startup [breaks meta key]
On Sat, Mar 01, 2003 at 01:25:31AM +0100, Mikael Hedin wrote: If so, I think I may know what caused this problem. :) I have to retract that. I'm not sure how this broke, and it would take a lot of time to track down. I will probably let this problem be fixed by 4.3.0-1 instead of 4.2.1-7. -- G. Branden Robinson| Debian GNU/Linux | Music is the brandy of the damned. [EMAIL PROTECTED] | -- George Bernard Shaw http://people.debian.org/~branden/ | pgpRooKCj352d.pgp Description: PGP signature
Bug#182861: xkb errors on server startup [breaks meta key]
On Sat, Mar 01, 2003 at 09:17:05PM -0500, Branden Robinson scrawled: On Sat, Mar 01, 2003 at 01:25:31AM +0100, Mikael Hedin wrote: If so, I think I may know what caused this problem. :) I have to retract that. I'm not sure how this broke, and it would take a lot of time to track down. I will probably let this problem be fixed by 4.3.0-1 instead of 4.2.1-7. Yes, because the xkb in 4.3.0 is the best-quality xkb we've ever seen. :) -- Daniel Stone [EMAIL PROTECTED] Developer, Trinity College, University of Melbourne pgpYtqp2AYddu.pgp Description: PGP signature
Bug#182773: xserver-xfree86: [mga] Any opengl app on 4.2.1-5 and 4.2.1-6 crashes the hardware hard.
On Thu, Feb 27, 2003 at 08:04:55PM +, Phil Armstrong wrote: Package: xserver-xfree86 Version: 4.2.1-6 Severity: normal Just running glxinfo on 4.2.1-5 or 4.2.1-6 is enough to put my G400 in an unusable state, with screen corruption all over the place. Switching to another console is possible, but the corruption remains; switching back to the X console hangs the system completely. 4.2.1-4 appears to be entirely stable. I think I missed this bug on 4.2.1-5 due to running the experimental dri packages at the time. Let me know if there's any diagnostics I can run. Phil, I have a G400 and 3d is working perfectly for me at this point. All the GL screensavers and armagetron work great and fast. I seem to have all the 4.2.1.5 sid xfree packages including xlibmesa-gl and xlibmesa-glu. I did knock my screen resolution down to 1600x1200 and my color depth to 16 based on a recent post pointing out that bad things happen when you exhaust the memory on your G400. Oh, yeah, I'm using the stock mga_drv.o, not the one from Matrox.
