Re: make World failure? on distclean in tinyx dirs
On Fri, Oct 06, 2006 at 07:22:33AM +0100, Andrew C Aitchison wrote: I've been forgetting to report this for a while. It started happening around the 2nd September. I run make WORLDOPTS=-k World and all (I think) the tinyx directories report problems with make target distclean. This is RedHat Linux. I'm not expliciting building TinyX. I've just committed a fix for this. Thanks for the report. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 4.6.99.2 Problem
On Tue, Jun 27, 2006 at 03:37:29AM +0900, Takaaki Nomura wrote:
I've tested 4.6.99.2 static/loader servers on Linux and FreeBSD.
The servers didn't work. The problem didn't occur with 4.6.99.1.
I've attached the servers' logs and gdb stack trace of the static
server.
I committed the following patch that fixes this.
Thanks for the report.
David
Index: xf86Init.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/common/xf86Init.c,v
retrieving revision 3.242
retrieving revision 3.243
diff -u -r3.242 -r3.243
--- xf86Init.c 19 Jun 2006 13:43:26 - 3.242
+++ xf86Init.c 25 Jun 2006 04:12:54 - 3.243
@@ -211,7 +211,14 @@
#endif
};
-static int numFormats = sizeof(formats) / sizeof(formats[0]);
+#ifdef RENDER
+#define NUMDEFFORMATS 7
+#else
+#define NUMDEFFORMATS 6
+#endif
+
+static int numFormats = NUMDEFFORMATS;
+
static Bool formatsDone = FALSE;
InputDriverRec xf86KEYBOARD = {
Announce: XFree86 4.6.0 released
I am very pleased to announce the release of XFree86 4.6.0. This release comes about a year after the 4.5.0 release, and is the product of the work of dedicated volunteers. I would like to thank all who have contributed to this release, through code, testing, and other feedback, and all who continue to support XFree86 and the work of its volunteer developers. Source, patches, and binaries for a range of platforms are available now for download from our ftp site: ftp://ftp.xfree86.org/pub/XFree86/4.6.0/ http://ftp.xfree86.org/pub/XFree86/4.6.0/ We currently have binaries available for 23 platforms. If you are not sure which binary set you need, first download the Xinstall.sh script, and run: sh Xinstall.sh -check Also, before downloading, check the 4.6.0 online documentation at: http://www.xfree86.org/4.6.0/ Read especially the README, Release Notes and Install documents. Also check the ERRATA for 4.6.0 for any last minute issues: http://www.xfree86.org/4.6.0/ERRATA.html and the UPDATES page to see when new binaries or other updates are available: http://www.xfree86.org/4.6.0/UPDATES.html The CVS tag for this release is xf-4_6_0. Information about accessing our anonymous CVS service is at http://www.xfree86.org/cvs/. User-related problems should be reported to our xfree86@xfree86.org list. Development issues and specific bugs should be reported to our devel@xfree86.org list and/or logged at http://bugs.xfree86.org/. The next release, 4.7.0, is planned for the first half of 2007. If you find XFree86 useful and would like to help support our work, please visit our donations page: http://www.xfree86.org/donations/ Enjoy. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 4.5.99.902 Problem with i810 EDID not honoured for [EMAIL PROTECTED]
On Mon, May 08, 2006 at 12:07:49PM +0100, Barry Scott wrote: David Dawes wrote: On Wed, May 03, 2006 at 10:17:11AM +0100, Barry Scott wrote: David, Can you tell me if this is supposed to work? If not why not? It is supposed to work. The i810 driver (for = i830) handles modes differently than most drivers, and I don't know if the problem lies there or not. What are the results of running: XFree86 -autoconfig -screen 'Builtin Default vesa Screen 0' David xrandr says its running at [EMAIL PROTECTED] but the screen claims its running at 1024x768. Which is progress as X appears to be doing the right thing. I don't trust the Hitachi panel to be working at 1360x768 as the Windows Nvidia drivers get the same result as the X i810, e.g. choose 1360x768 and panel says 1024x768. Does it visually look like 1360x768? What does the log file look like? Anyway, if the vesa does the right thing, that points to the i810 driver. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 4.5.99.902 Problem with i810 EDID not honoured for [EMAIL PROTECTED]
On Wed, May 03, 2006 at 10:17:11AM +0100, Barry Scott wrote: David, Can you tell me if this is supposed to work? If not why not? It is supposed to work. The i810 driver (for = i830) handles modes differently than most drivers, and I don't know if the problem lies there or not. What are the results of running: XFree86 -autoconfig -screen 'Builtin Default vesa Screen 0' David The edit the config option is not reasonable as I want to install against a large number of monitors and have X11 use the preferred mode with admin intervention. Barry Barry Scott wrote: Alan suggested: Try adding the 1360x768 modeline explicitly to the config file. Isn't the point of the EDID data that I do not have to do custom config for every monitor? Why doesn't the i810 + XFree86 code set up the mode correctly? Barry p.s. Sorry for the delay replying, I'm very busy at the moment. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Fourth XFree86 4.6.0 release candidate
On Sun, Apr 23, 2006 at 02:30:28PM -0400, David Dawes wrote: The fourth release candidate for XFree86 4.6.0 is now available. The source tarball can be found at: ftp://ftp.xfree86.org/pub/XFree86/develsnaps/XFree86-4.5.99.904.tar.bz2 Preview documentation for the 4.6.0 release is at: http://www.xfree86.org/~dawes/pre-4.6/ Binaries for some platforms may be available in the next few days. I'll post a note when they are available. Some binaries are available at: ftp://ftp.xfree86.org/pub/XFree86/snapshots/4.5.99.904/ David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: [EMAIL PROTECTED]: Problem with 4.5.99.903 on NetBSD]
On Mon, Apr 24, 2006 at 07:11:09PM +0200, Bernd Ernesti wrote: Forwared because my original mail was stopper by the subscriber check. - Forwarded message from Bernd Ernesti [EMAIL PROTECTED] - Date: Sun, 23 Apr 2006 12:06:52 +0200 From: Bernd Ernesti [EMAIL PROTECTED] Subject: Problem with 4.5.99.903 on NetBSD To: devel@XFree86.Org Hi, I send David Dawes a mail last month that there was a problem with his change #231. Not all problems were fixed since then. I don't recall it -- it probably got lost amongst the spam. The remaining problem is that you can't use #define InstallManPageSource NO in host.def. This would result in an error during the cleaning stage of a make World: cleaning in programs/Xserver/hw/xfree86... make: /xc/programs/Xserver/hw/xfree86/Makefile line 1120: Missing dependency operator make: Fatal errors encountered -- cannot continue These are the lines around 1120, where 1120 is the InstallManPageLongBase one: cleandir:: $(RM) XF86Config.$(MANNEWSUFFIX) InstallManPageLongBase(XF86Config,$(FILEMANDIR),XF86Config,$(FILEMANSUFFIX)) install:: Looking further into the NetBSD.cf changes made be belive that the change in 3.130 contains some problems: +#define InstallGenManPageLong(file,destdir,dest,suffix) @@\ +BuildInstallHtmlManPage(file,dest,suffix) @@\ + @@\ +CppManTarget(file, $(EXTRAMANDEFS))@@\ + @@\ +InstallManPageLongBase(file,destdir,dest,suffix) and -InstallManPageAliasesBase(file,destdir,aliases) +InstallManPageAliasesBase(file,destdir,suffix,aliases) IMHO there is an 'Os' prefix missing for InstallManPageLongBase and InstallManPageAliasesBase. I agree. I'll fix these. Attached is an NetBSD.cf to sync it with the one used in our cvs repository: - Added some brackets to make it easier to read and changed some logic for the NetBSD version check - Adding support for HasArc4Random and a fix for the InstallManPageSource problem which seems to work for me. I just did a complete new build, while using InstallManPageSource set to NO. And the unformated manpages where not installed. Given where we are in the release cycle, I'm inclined to leave the other changes, until after 4.6.0. Thanks for the feedback and patch. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Fourth XFree86 4.6.0 release candidate
The fourth release candidate for XFree86 4.6.0 is now available. The source tarball can be found at: ftp://ftp.xfree86.org/pub/XFree86/develsnaps/XFree86-4.5.99.904.tar.bz2 Preview documentation for the 4.6.0 release is at: http://www.xfree86.org/~dawes/pre-4.6/ Binaries for some platforms may be available in the next few days. I'll post a note when they are available. This should be the final release candidate before the 4.6.0 release. Only documentation updates and important bug fixes will be accepted between now and the release. Please report problems/success, etc here, and send me any documentation updates that you may have. The latest version of xtest (4.0.14) can be found at: ftp://ftp.xfree86.org/pub/XFree86/xtest/XFree86-xtest-4.0.14.tar.bz2 David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 4.5.99.903 problem on Linux
On Wed, Apr 19, 2006 at 08:52:52PM +0900, Takaaki Nomura wrote: On Tue, 18 Apr 2006 19:27:36 -0400, David Dawes wrote: On Fri, Apr 14, 2006 at 08:39:47PM +0900, Takaaki Nomura wrote: On Thu, 13 Apr 2006 20:27:29 -0400, David Dawes wrote: On Wed, Apr 12, 2006 at 08:22:39PM +0900, Takaaki Nomura wrote: I've tested 4.5.99.903 on FreeBSD and Linux. When I terminated the server on Linux, I couldn't return to the console and the root window remained. The problem didn't occur on FreeBSD. I've attached the server log below. Are there any latest changes on the CVS version? Not that would affect this. Is the problem repeatable? If so, can you get some debugging information with gdb? If you start the server with no clients, then exit, does the problem still occur? If the stack trace in the log is accurate, it shows a crash in main(). A trace with gdb from a server built with debugging info should help. Caught signal 11. Stack trace: 0: 0x808db5d: 0x808db40 xf86ShowStackTrace + 0x1d Module /usr/X11R6.6/bin/XFree86 1: 0x808dc23: 0x808dbc0 xf86SigHandler + 0x63 Module /usr/X11R6.6/bin/XFree86 2: 0xe420: 0xe420 __kernel_sigreturn + 0x0 Module 3: 0x80d2946: 0x80d24c0 main + 0x486 Module /usr/X11R6.6/bin/XFree86 Fatal server error: Server aborting David It is repeatable on both of my two test PCs running Fedora Core 5. I've attached the static server logs below. One is with glint-based PC and the other is with i810-base PC. It's strange that gdb indicates the static symbol(variable)s of Enc61 and i810_pitch_flags. Fedora Core 5 uses gcc 4.1.0. I can't test until next week. I've gotten access to a machine running FC5 and have reproduced this problem. It seems to be an array overrun. The attached patch fixes it for me. Let me know how it goes for you. David I've tested the 4.5.99.903 static/loader servers with your patch on both of my two test PCs running FC5. The problem didn't occur. It seemed to be fixed. Thanks a lot. Thanks for the report and feedback. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 4.5.99.903 problem on Linux
On Fri, Apr 14, 2006 at 08:39:47PM +0900, Takaaki Nomura wrote:
On Thu, 13 Apr 2006 20:27:29 -0400, David Dawes wrote:
On Wed, Apr 12, 2006 at 08:22:39PM +0900, Takaaki Nomura wrote:
I've tested 4.5.99.903 on FreeBSD and Linux.
When I terminated the server on Linux, I couldn't return to
the console and the root window remained.
The problem didn't occur on FreeBSD.
I've attached the server log below.
Are there any latest changes on the CVS version?
Not that would affect this.
Is the problem repeatable? If so, can you get some debugging information
with gdb? If you start the server with no clients, then exit, does the
problem still occur? If the stack trace in the log is accurate, it shows
a crash in main(). A trace with gdb from a server built with debugging
info should help.
Caught signal 11.
Stack trace:
0: 0x808db5d: 0x808db40 xf86ShowStackTrace + 0x1d
Module /usr/X11R6.6/bin/XFree86
1: 0x808dc23: 0x808dbc0 xf86SigHandler + 0x63
Module /usr/X11R6.6/bin/XFree86
2: 0xe420: 0xe420 __kernel_sigreturn + 0x0
Module
3: 0x80d2946: 0x80d24c0 main + 0x486
Module /usr/X11R6.6/bin/XFree86
Fatal server error:
Server aborting
David
It is repeatable on both of my two test PCs running Fedora Core 5.
I've attached the static server logs below. One is with glint-based
PC and the other is with i810-base PC.
It's strange that gdb indicates the static symbol(variable)s of Enc61
and i810_pitch_flags.
Fedora Core 5 uses gcc 4.1.0.
I can't test until next week.
I've gotten access to a machine running FC5 and have reproduced this
problem. It seems to be an array overrun. The attached patch fixes it
for me. Let me know how it goes for you.
David
Index: common/xf86KbdLnx.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/common/xf86KbdLnx.c,v
retrieving revision 3.21
diff -u -r3.21 xf86KbdLnx.c
--- common/xf86KbdLnx.c 20 Feb 2006 00:14:37 - 3.21
+++ common/xf86KbdLnx.c 18 Apr 2006 23:23:22 -
@@ -364,7 +364,7 @@
}
else {
k = map+GLYPHS_PER_KEY;
-maxkey = NUM_AT2LNX;
+maxkey = NUM_AT2LNX - 1;
}
for (i = 0; i maxkey; ++i)
Index: os-support/linux/lnx_KbdMap.c
===
RCS file:
/home/x-cvs/xc/programs/Xserver/hw/xfree86/os-support/linux/lnx_KbdMap.c,v
retrieving revision 1.4
diff -u -r1.4 lnx_KbdMap.c
--- os-support/linux/lnx_KbdMap.c 20 Feb 2006 00:14:37 - 1.4
+++ os-support/linux/lnx_KbdMap.c 18 Apr 2006 23:23:18 -
@@ -287,7 +287,7 @@
}
else {
k = map+GLYPHS_PER_KEY;
-maxkey = NUM_AT2LNX;
+maxkey = NUM_AT2LNX - 1;
}
for (i = 0; i maxkey; ++i)
4.6.0 preview documentation for review
I've put a copy of the preview documentation for the upcoming 4.6.0 release at: http://www.xfree86.org/~dawes/pre-4.6/ If you have any additions or corrections, please let me know. In particular send release notes updates, and updates to the credits sections. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 4.5.99.903 problem on Linux
On Wed, Apr 12, 2006 at 08:22:39PM +0900, Takaaki Nomura wrote: I've tested 4.5.99.903 on FreeBSD and Linux. When I terminated the server on Linux, I couldn't return to the console and the root window remained. The problem didn't occur on FreeBSD. I've attached the server log below. Are there any latest changes on the CVS version? Not that would affect this. Is the problem repeatable? If so, can you get some debugging information with gdb? If you start the server with no clients, then exit, does the problem still occur? If the stack trace in the log is accurate, it shows a crash in main(). A trace with gdb from a server built with debugging info should help. Caught signal 11. Stack trace: 0: 0x808db5d: 0x808db40 xf86ShowStackTrace + 0x1d Module /usr/X11R6.6/bin/XFree86 1: 0x808dc23: 0x808dbc0 xf86SigHandler + 0x63 Module /usr/X11R6.6/bin/XFree86 2: 0xe420: 0xe420 __kernel_sigreturn + 0x0 Module 3: 0x80d2946: 0x80d24c0 main + 0x486 Module /usr/X11R6.6/bin/XFree86 Fatal server error: Server aborting David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: patch - word/byte PCI config support for ix86
On Mon, Apr 10, 2006 at 09:55:11AM -0400, David Dawes wrote: On Sun, Apr 09, 2006 at 03:07:45PM -0500, Sergey Babkin wrote: Hi, I'm not sure if it's a good idea to cc: to both X.org and XF86 mailing lists, but the subject is kind of useful for both. I've attached the patch that adds word- and byte-sized PCI configuration reads and writes for the ix86 platform. The particular reason was to fix the support of sincgle-chip Matrox G200 with the VESA driver on UnixWare. This hardware is somewhat brain-damaged and really expects word- and byte-sized bus cycles, it does not work with the wraping in Long. I fixed this in the int10 module before 4.6.0 RC2. It addressed the problems of this type that I saw. Try 4.6.0 RC3 and let me know if you still see the problem. Just a quick followup... I originally saw the problem when using the vesa driver with a G400. I have now verified 4.6.0 RC3 with the vesa driver and a G200. I don't have a working UnixWare system (I was never able to get it to play well in a multi-boot environment), but this is using XFree86's ix86 CFG1 PCI functions, not any of the OS-specific interfaces. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: patch - word/byte PCI config support for ix86
On Sun, Apr 09, 2006 at 03:07:45PM -0500, Sergey Babkin wrote: Hi, I'm not sure if it's a good idea to cc: to both X.org and XF86 mailing lists, but the subject is kind of useful for both. I've attached the patch that adds word- and byte-sized PCI configuration reads and writes for the ix86 platform. The particular reason was to fix the support of sincgle-chip Matrox G200 with the VESA driver on UnixWare. This hardware is somewhat brain-damaged and really expects word- and byte-sized bus cycles, it does not work with the wraping in Long. I fixed this in the int10 module before 4.6.0 RC2. It addressed the problems of this type that I saw. Try 4.6.0 RC3 and let me know if you still see the problem. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Third 4.6.0 release candidate
The third release candidate for XFree86 4.6.0 is now available. The source tarball can be found at: ftp://ftp.xfree86.org/pub/XFree86/develsnaps/XFree86-4.5.99.903.tar.bz2 Please report problems/success, etc here. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 4.5.99.902 Problem with i810
On Wed, Mar 29, 2006 at 11:58:40PM +0900, Takaaki Nomura wrote: On Tue, 28 Mar 2006 19:57:58 -0500, David Dawes wrote: On Tue, Mar 28, 2006 at 11:13:46PM +0900, Takaaki Nomura wrote: I've tested 4.5.99.902 with i810 based built-in card on Linux.. Server worked, but console blacked out after I terminated it. I've attached the server log and the console log. The latter contains some gnome's messages and japanese characters. Can you try the current CVS version? I fixed a couple of problems since 4.5.99.902 that might be contributing to what you are seeing. If that doesn't make any difference, the problem might be related to recent 830/845/865/etc driver changes. I'dont have a CVS environment. But after I got the lastest files under the following directories of the CVS repository and rebuilt the server, the problem seemed to be fixed. Thanks for the feedback. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 4.5.99.902 Problem with i810
On Tue, Mar 28, 2006 at 11:13:46PM +0900, Takaaki Nomura wrote: I've tested 4.5.99.902 with i810 based built-in card on Linux.. Server worked, but console blacked out after I terminated it. I've attached the server log and the console log. The latter contains some gnome's messages and japanese characters. Can you try the current CVS version? I fixed a couple of problems since 4.5.99.902 that might be contributing to what you are seeing. If that doesn't make any difference, the problem might be related to recent 830/845/865/etc driver changes. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Second 4.6.0 release candidate
On Tue, Mar 28, 2006 at 09:02:31AM +0100, Andrew C Aitchison wrote: On Mon, 27 Mar 2006, David Dawes wrote: On Mon, Mar 27, 2006 at 07:22:51AM +0100, Andrew C Aitchison wrote: On Sun, 26 Mar 2006, David Dawes wrote: While looking into this, I did find a bug in fontconfig where memory could get freed twice. I don't see the same symptoms, but this problem does happen in code paths that get used when slanting a font. I'm committing the patch now. Let me know if it makes a difference for you. It shoud be there by now, but if it isn't, I've attached the patch (forgot to do that last night). Thanks. The patch is in CVS now, and solves my mozilla/firefox problem. Thanks for the feedback. This particular problem was likely exposed by the fontconfig matching bug I fixed in RC2. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Second 4.6.0 release candidate
On Mon, Mar 27, 2006 at 07:22:51AM +0100, Andrew C Aitchison wrote: On Sun, 26 Mar 2006, David Dawes wrote: While looking into this, I did find a bug in fontconfig where memory could get freed twice. I don't see the same symptoms, but this problem does happen in code paths that get used when slanting a font. I'm committing the patch now. Let me know if it makes a difference for you. Thanks. When should I expect this to make it into anoncvs.xfree86.org or http://cvsweb.xfree86.org/cvsweb/xc/ (I see that it has made it to http://www.xfree86.org/cvs/changes.html) ? It shoud be there by now, but if it isn't, I've attached the patch (forgot to do that last night). David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com Index: extras/fontconfig//src/fccfg.c === RCS file: /home/x-cvs/xc/extras/fontconfig/src/fccfg.c,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- extras/fontconfig//src/fccfg.c 3 May 2005 20:43:27 - 1.3 +++ extras/fontconfig//src/fccfg.c 27 Mar 2006 01:32:46 - 1.4 @@ -675,6 +675,7 @@ r = FcPatternGet (p, e-u.field, 0, v); if (r != FcResultMatch) v.type = FcTypeVoid; + v = FcValueSave (v); break; case FcOpConst: if (FcNameConstant (e-u.constant, v.u.i))
Re: Second 4.6.0 release candidate
On Wed, Mar 22, 2006 at 11:38:10AM +, Andrew C Aitchison wrote: On Mon, 20 Mar 2006, David Dawes wrote: The second release candidate for XFree86 4.6.0 is now available. The source tarball can be found at: ftp://ftp.xfree86.org/pub/XFree86/develsnaps/XFree86-4.5.99.902.tar.bz2 This version marks the beginning of the intensive testing phase for this release. Please report problems/success, etc here. Is there a broken (italic) font ? mozilla and firefox keep getting wedged in tight loops. firefox file:/ is fine, but if I view source (ctrl-U) the process spins (cpu 99%+, strace and ltrace show nothing, process does respond to signals). I started seeing this when I upgraded to XFree86-4.5.99.902 (from CVS head). Previous version was probably six weeks ago. While looking into this, I did find a bug in fontconfig where memory could get freed twice. I don't see the same symptoms, but this problem does happen in code paths that get used when slanting a font. I'm committing the patch now. Let me know if it makes a difference for you. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: CVS GLX oddity
On Fri, Mar 24, 2006 at 10:13:25AM -0800, Mark Vojkovich wrote:
Is that the final fix or is there something else I should test?
That one works for me.
That is the final fix. I'll commit it soon.
David
Mark.
On Thu, 23 Mar 2006, Mark Vojkovich wrote:
Yes, that works.
Mark.
On Thu, 23 Mar 2006, David Dawes wrote:
On Wed, Mar 22, 2006 at 08:52:00PM -0800, Mark Vojkovich wrote:
initdata is still NULL even after your call to LoaderSymbol() in
that patch.
The module name needs to be prepended. Something like:
if (!initdata) {
char *md;
xasprintf(md, %s MODULE_DATA_NAME, name);
if (md) {
initdata = LoaderSymbol(md);
xfree(md);
}
}
David
Mark.
On Wed, 22 Mar 2006, David Dawes wrote:
On Wed, Mar 22, 2006 at 06:57:17PM -0800, Mark Vojkovich wrote:
I can't get CVS to load NVIDIA's GLX module. It complains:
(II) Loading /usr/X11R6/lib/modules/extensions/libglx.so
(EE) LoadModule: Module glx does not have a glxModuleData data object.
(II) UnloadModule: glx
Did something change with regards to this? It was working before
I updated.
dlopen modules have always had different semantics than XFree86 modules.
These differences will only get greater as additional features are added
to the XFree86 loader and as the newly added features are used more
widely.
The following (untested) patch may solve this particular problem. Let
me know
how it goes.
David
--
David Dawes X-Oz Technologies
www.XFree86.org/~dawes www.x-oz.com
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
--
David Dawes X-Oz Technologies
www.XFree86.org/~dawes www.x-oz.com
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: CVS GLX oddity
On Wed, Mar 22, 2006 at 08:52:00PM -0800, Mark Vojkovich wrote:
initdata is still NULL even after your call to LoaderSymbol() in
that patch.
The module name needs to be prepended. Something like:
if (!initdata) {
char *md;
xasprintf(md, %s MODULE_DATA_NAME, name);
if (md) {
initdata = LoaderSymbol(md);
xfree(md);
}
}
David
Mark.
On Wed, 22 Mar 2006, David Dawes wrote:
On Wed, Mar 22, 2006 at 06:57:17PM -0800, Mark Vojkovich wrote:
I can't get CVS to load NVIDIA's GLX module. It complains:
(II) Loading /usr/X11R6/lib/modules/extensions/libglx.so
(EE) LoadModule: Module glx does not have a glxModuleData data object.
(II) UnloadModule: glx
Did something change with regards to this? It was working before
I updated.
dlopen modules have always had different semantics than XFree86 modules.
These differences will only get greater as additional features are added
to the XFree86 loader and as the newly added features are used more
widely.
The following (untested) patch may solve this particular problem. Let me
know
how it goes.
David
--
David Dawes X-Oz Technologies
www.XFree86.org/~dawes www.x-oz.com
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: CVS GLX oddity
On Wed, Mar 22, 2006 at 06:57:17PM -0800, Mark Vojkovich wrote:
I can't get CVS to load NVIDIA's GLX module. It complains:
(II) Loading /usr/X11R6/lib/modules/extensions/libglx.so
(EE) LoadModule: Module glx does not have a glxModuleData data object.
(II) UnloadModule: glx
Did something change with regards to this? It was working before
I updated.
dlopen modules have always had different semantics than XFree86 modules.
These differences will only get greater as additional features are added
to the XFree86 loader and as the newly added features are used more
widely.
The following (untested) patch may solve this particular problem. Let me know
how it goes.
David
--
David Dawes X-Oz Technologies
www.XFree86.org/~dawes www.x-oz.com
Index: loadmod.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/loader/loadmod.c,v
retrieving revision 1.78
diff -u -r1.78 loadmod.c
--- loadmod.c 16 Mar 2006 16:50:34 - 1.78
+++ loadmod.c 23 Mar 2006 03:29:57 -
@@ -1084,6 +1084,10 @@
ret-filename = xstrdup(found);
+/* This is needed for dlopen modules. */
+if (!initdata)
+ initdata = LoaderSymbol(MODULE_DATA_NAME);
+
if (initdata) {
ModuleSetupProc setup;
ModuleTearDownProc teardown;
Second 4.6.0 release candidate
The second release candidate for XFree86 4.6.0 is now available. The source tarball can be found at: ftp://ftp.xfree86.org/pub/XFree86/develsnaps/XFree86-4.5.99.902.tar.bz2 This version marks the beginning of the intensive testing phase for this release. Please report problems/success, etc here. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] Question about XFree86 4.5.99.901 snapshot
On Thu, Mar 09, 2006 at 07:53:41AM -0800, Tom Williams wrote: David Dawes wrote: On Wed, Mar 08, 2006 at 05:54:02PM -0500, David Dawes wrote: On Wed, Mar 08, 2006 at 08:23:17AM -0800, Tom Williams wrote: Hi! I just installed the XFree86 4.5.99.901 snapshot (which fixed my xterm installation problem, thanks guys! :)) and it runs fine. I wanted to try the -autoconfig option to see what it would do and it generated these messages: Autoconfigure works by loading a bunch of drivers, using the one that proves to be the best choice, and unloading the others. The problem is that fbdev registers that it needs fbdevhw. When it is unloaded it doesn't notify the loader that fbdevhw is no longer needed. Since the nv driver refers to fbdevhw (even though it isn't using it), these references are being reported as fatal unresolved symbols. The new loader now invalidates symbol references to modules that have been unloaded. To fix this problem, the fbdev module (and all modules, really) needs to be modified to register its fbdevhw requirements as being specific to itself so that those requirements get removed when it is unloaded. I'll take a look at doing this, and post a patch. Tom, thanks for reporting the problem! The attached patch should fix this problem. David Yep, that patch worked. *Both* -autoconfig and -configure work just fine. :) I've just committed some changes that improve the handling of module requirements, and have modified all modules to make use of this. Along the way I found several bugs that showed up as a result of this and of the fact that modules can now be unloaded and reloaded cleanly. I have also removed some workarounds for the old loader (mis)behaviour, and plan to remove some more after further testing. I expect that there will be more problems showing up that either were masked in the past, or come from code that relied on the old loader behaviour. Please report problems and/or new warnings/errors in the log file here and I'll follow them up. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
xterm warning regressions (was Re: CVS Update: xc (branch: trunk))
On Sun, Mar 12, 2006 at 05:28:02PM -0800, Thomas Dickey wrote: CVSROOT: /home/x-cvs Module name: xc Changes by:[EMAIL PROTECTED] 06/03/12 17:28:02 Log message: 241. Xterm patch #210 (Thomas Dickey). This reinstates the following warnings on Solaris 9: xterm.h:243: warning: redundant redeclaration of `errno' in same scope /usr/include/errno.h:41: warning: previous declaration of `errno' main.c:452: warning: redundant redeclaration of `ptsname' in same scope /usr/include/stdlib.h:170: warning: previous declaration of `ptsname' main.c:2818: warning: unsigned int format, long unsigned int arg (arg 5) and adds this one: main.c:2586: warning: `pty_search' defined but not used David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xterm warning regressions (was Re: CVS Update: xc (branch: trunk))
On Tue, Mar 14, 2006 at 06:49:49PM -0500, Thomas Dickey wrote: On Tue, 14 Mar 2006, David Dawes wrote: On Sun, Mar 12, 2006 at 05:28:02PM -0800, Thomas Dickey wrote: CVSROOT: /home/x-cvs Module name: xc Changes by: [EMAIL PROTECTED] 06/03/12 17:28:02 Log message: 241. Xterm patch #210 (Thomas Dickey). This reinstates the following warnings on Solaris 9: xterm.h:243: warning: redundant redeclaration of `errno' in same scope /usr/include/errno.h:41: warning: previous declaration of `errno' I test-built on Solaris 8, 9 and 10 without seeing any warnings other than those addressed by the fix for lastlog(). That was using the configure script of course. Perhaps having the particular -D's set by imake would help focus the discussion. gcc -c -O2 -fno-strength-reduce -fno-strict-aliasing -DNO_ASM -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I. -I. -I../../exports/include -I../../exports/include -I../../exports/include/freetype2 -I../../exports/include -Dsun -DSVR4 -D__EXTENSIONS__ -Di386 -D__i386 -D__i386__-DSCROLLBAR_RIGHT -DOPT_WIDE_CHARS -DOPT_LUIT_PROG -DXRENDERFONT -DXFREE86_FT2 -DPROJECTROOT=/usr/X11R6 -DUTMP -DUSE_TTY_GROUP -DOSMAJORVERSION=5 -DOSMINORVERSION=9 main.c main.c:452: warning: redundant redeclaration of `ptsname' in same scope /usr/include/stdlib.h:170: warning: previous declaration of `ptsname' main.c:2818: warning: unsigned int format, long unsigned int arg (arg 5) and adds this one: main.c:2586: warning: `pty_search' defined but not used yes, that's an annoyance (but the proposed fix reversed the general process of removing special definitions from main.c). David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: First 4.6.0 release candidate
On Tue, Mar 07, 2006 at 05:31:00AM -0500, Thomas Dickey wrote: On Mon, 6 Mar 2006, David Dawes wrote: The first release candidate for XFree86 4.6.0 is now available. The source tarball can be found at: ftp://ftp.xfree86.org/pub/XFree86/develsnaps/XFree86-4.5.99.901.tar.bz2 that's nice. I'm not using the changes which have been recently applied to xterm in your tree. The latest change I made to xterm prevents a SEGV that was happening when XftFontMatch() returned NULL. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 4.5.99.22 problem
On Tue, Mar 07, 2006 at 12:35:20AM +0900, Takaaki Nomura wrote: On Thu, 2 Mar 2006 18:56:38 -0500, David Dawes [EMAIL PROTECTED] wrote: On Fri, Mar 03, 2006 at 08:39:25AM +0900, Takaaki Nomura wrote: I've tested static/loader servers on FreeBSD and Linux. The servers didn't start with the following error. Can you send your config file? The config file search path has changed with 4.5.99.22 and the file under my home directory was used. I'm usually using /etc/ XF86Config. After I renamed the file under my home directory, the servers worked. This change in search path is not intended, and I'm committing a fix now. Thanks for reporting the problem. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
First 4.6.0 release candidate
The first release candidate for XFree86 4.6.0 is now available. The source tarball can be found at: ftp://ftp.xfree86.org/pub/XFree86/develsnaps/XFree86-4.5.99.901.tar.bz2 David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: incomplete docs ?
On Thu, Mar 02, 2006 at 11:06:16AM -0800, bruno schwander wrote: Hi all, I noticed some manpages and documentation is missing from the release information available at http://xfree86.org/current/RELNOTES4.html . Can you give some examples of what is missing? Are these web pages automagically generated from the xfree86 sources ? They are generated for each release at release time, from the XFree86 source tree. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 4.5.99.22 problem
On Fri, Mar 03, 2006 at 08:39:25AM +0900, Takaaki Nomura wrote: I've tested static/loader servers on FreeBSD and Linux. The servers didn't start with the following error. Can you send your config file? David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: EDID Prefered mode problems
On Thu, Jan 26, 2006 at 02:31:23PM +, Barry Scott wrote: I'm running 4.5.99.18 and having problems with supporting HDReady panels. The HDReady panels support [EMAIL PROTECTED] typically. Using the i810 driver on a i945G with the i915resolution hack I can get the driver to set 1360x768 but not at 60Hz. Talking to alanh it seems that the problem may be in XFree86 not matching modes correctly. We try changing to LOOK_CLOSEST_CLOCK but that does not work. At the moment I've forced 60 into the calls to prevent any higher frequency being used. I assume that its not just the i810 driver that will have this problem, I know the CLE266 does not work as well and I'll pick up Luc's newer driver code soon to test again. Is this problem with EDID prefered mode known about? Have we missed a way to makes things work? Send the full log file, including one with 'XFree86 -autoconfig' if that's not your default. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: CVS Update: xc (branch: trunk)
On Wed, Jan 25, 2006 at 04:41:10PM +0100, Matthieu Herrb wrote: CVSROOT: /home/x-cvs Module name: xc Changes by: [EMAIL PROTECTED] 06/01/24 20:32:10 Log message: 187. Add two new functions that can be used to scroll the content of an Xaw viewport from outside the viewportWidgetClass (Bugzilla #1648, Alexander Pohoyda). 186. Fix i18n for Xaw's tip widget (Bugzilla #1647, Alexander Pohoyda). 185. Fix a performance issue with Xaw's Tree widget caused by useless relayouts (Bugzilla #1645, Alexander Pohoyda). 184. Add some XChar2b string manipulation functions to Xt (Bugzilla #1646, Alexander Pohoyda). Modified files: xc/lib/Xaw/: Label.c Label.h LabelP.h Simple.c Simple.h SimpleP.h Tip.c Tree.c TreeP.h Viewport.c Viewport.h xc/lib/Xt/: Functions.c Intrinsic.h Xt-def.cpp jump_funcs xc/programs/Xserver/hw/xfree86/: CHANGELOG libXaw and libXt minor revision numbers should be incremented when adding functions. http://bugs.xfree86.org/show_bug.cgi?id=1646#c2 David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
XFree86 4.6.0 plans
We are planning to release XFree86 version 4.6.0 in the next two-three months. The details of the release schedule have not been finalised yet, but I'll post them here when they are. If you have new work or updates that you would like to see included in the upcoming 4.6.0 release, they should be submitted/discussed here and/or at bugs.xfree86.org. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Updated GDB patches for XFree86 modules
I have some updated patches for adding support to gdb for debugging XFree86 modules. The patches are for gdb versions 5.3, 6.0, and 6.4, and I've tested them on NetBSD, FreeBSD and Solaris/x86 in addition to Linux. The patches are based on the original work that Paul Flinders did for earlier versions of gdb. The patches are at http://www.xfree86.org/~dawes/gdb-XFree86.html. I'm planning to update these further as the XFree86 loader is enhanced. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: uClibc floating point xfree
On Mon, Jan 09, 2006 at 10:17:02AM +0100, Marco Longhin wrote: Hi, I'm trying to compile xfree 4.5.0 with uClibc 0.9.27 (mipsel). My question: Is possible to compile xfree without floating point? uClibc don't have all functions of libm, and xfree need floating point. Portions of XFree86 do require floating point. In which specific areas of XFree86 are you running into the most problems? David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: [PATCH] trident_video.c
On Fri, Dec 09, 2005 at 09:14:40AM -0800, Tim Roberts wrote:
Jeff Chua wrote:
The following patch is needed in order to compile trident_video.c with
gcc-2.95.3 ...
---
xfree86/xc/programs/Xserver/hw/xfree86/drivers/trident/trident_video.c.org
2005-12-09 12:05:15 +0800
+++
xfree86/xc/programs/Xserver/hw/xfree86/drivers/trident/trident_video.c
2005-12-09 12:05:43 +0800
@@ -666,10 +666,11 @@
OUTW(vgaIOBase + 4, ((width1) 0xff00) | 0x91);
OUTW(vgaIOBase + 4, ((offset) 0xff) 8 | 0x92);
OUTW(vgaIOBase + 4, ((offset) 0xff00)| 0x93);
-if (pTrident-Chipset = CYBER9397)
+if (pTrident-Chipset = CYBER9397) {
OUTW(vgaIOBase + 4, ((offset) 0x0f) 8 | 0x94);
-else
+} else {
OUTW(vgaIOBase + 4, ((offset) 0x07) 8 | 0x94);
+}
Why? If the OUTW macro is generating multiple statements, then the OUTW
macro should be fixed. Otherwise, this is just a nasty bug waiting to
happen.
Yes, it needs to be fixed. It is currently a { ... } block. The
do { ... } while (0) trick would fix it.
David
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: Offscreenmemory copy
On Fri, Dec 02, 2005 at 09:21:34AM -0800, Tim Roberts wrote: Anybody know why there were a set of messages from two weeks ago (including this one) that are just showing up today? It is a side-effect of the member-only posting restriction that helps keep this list spam-free. It can be avoided when unsubscribed posters subscribe and re-post. For those posting from an address that they don't wish to receive list mail at, subscribe the address, and enable the no mail setting for that subscription. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Future of Unichrome (CLE266, CN400 etc) unichrome drivers
On Fri, Oct 14, 2005 at 12:35:19PM +0100, Barry Scott wrote: David Dawes wrote: On Thu, Oct 13, 2005 at 09:56:16AM +0100, Barry Scott wrote: I'm using the Unichrome driver with XFree86 4.5.0 and I'm hitting problems trying to use their latest code. I sent the previous message to fast and did not reply to you question correctly. The problem in the current CVS unichrome driver is a Opss when the via_drv.o deallocates a piece of DRM memory twice. Elsewhere in the Xserver DRM context 1 is removed. (This occurs when the Xserver resets its self when the lat client disconnects and the a new client connects and uses XVIDEO). It would appear that the via_drv.o code needs to be called back to tell it to shutdown. Is there such a call back to a driver? If so the via_drv.o code needs to arrnage for it to be called and clean up. The via driver (X server) is supposed to take care of closing down and cleaning up everything it has used when its CloseScreen function is called. I don't know if you're seeing a bug in the X driver or the kernel driver. Server reset is often a poorly tested case, but it is usually straightforward to fix the problems that arise there. I'm about to ship a product with a work around to the bug in the Unichrome drivers. I'm not going to be able to doing any testing until a few weeks time. What I really need to know is do you have people that are supporting UNichrome for XFree86. I can work with them on getting the bugs fixed. However if unichrome does not have support then I going to be forced to Xorg that does have support, and I'm not happy with the stability of Xorg. I'm not aware of anyone specifically working on the via driver for XFree86. Why not take it on yourself? David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Future of Unichrome (CLE266, CN400 etc) unichrome drivers
On Thu, Oct 13, 2005 at 09:56:16AM +0100, Barry Scott wrote: I'm using the Unichrome driver with XFree86 4.5.0 and I'm hitting problems trying to use their latest code. What problems are you hitting? David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: tdfx and DDC2
On Thu, Aug 25, 2005 at 01:21:55PM -0400, Michael wrote: Hello, the attached patch adds DDC2/I2C support to the tdfx driver which has the distinct advantage to work anywhere since it doesn't depend on the vbe module. It will try DDC2 first and if that fails fall back to the old vbe stuff when possible. Moved mode validation and related stuff /after/ monitor detection. That looks reasonable. Does the vbe/int10 portion still need to be disabled for PowerPC? David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: tdfx and DDC2
On Tue, Aug 30, 2005 at 06:01:42PM -0400, Michael wrote: Hello, I don't see why they should be enabled - they're PC-specific and even with x86 emulation they would be pretty much useless since you're not too likely to encounter a graphics board with PC firmware in a Mac ( or other PowerPC boxes ) Wrong. No hardware manufacturer in their right mind would build a Mac-only PCI graphics board, with the possible exception of Apple. What the hell are you talking about? VESA BIOS is x86 only. Int10 is PC only. They're going to build a generic graphics board that works in a PC and by the way also works in a Mac. Such a board will have a video BIOS. Wrong. A Mac graphics board will have an OpenFirmware driver and possibly a MacOS driver in ROM, not a VESA BIOS. Is the implication here that plugging a PC PCI graphics card into a powerpc machine will never work (as a secondary display), even if the software driving it knows how to initialise it in the absence of OpenFirmware? David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: tdfx and DDC2
On Tue, Aug 30, 2005 at 07:06:22PM -0400, Michael wrote: Hello, Is the implication here that plugging a PC PCI graphics card into a powerpc machine will never work (as a secondary display), even if the software driving it knows how to initialise it in the absence of OpenFirmware? Of course not. All I said is that you're rather unlikely to find a VESA BIOS on a graphics card in a non-PC-box. And in the case at hand - tdfx - we don't need firmware help to set up the hardware anyway. The tdfx driver will attempt to use the int10 module to soft-boot a secondary card. Except on powerpc because right now that is #ifdef'd out. Many drivers will not work correctly on secondary cards without this, including the tdfx driver on some tdfx cards I've used in the past. My original question about whether these things still need to be #ifdef'd out on powerpc platforms (yet they are not on other non-x86 platforms) is independent of whether it is typically needed on those platforms. XFree86 strives to run on more than just the most common hardware configurations. Marc appears to have fixed various issues for int10/vbe on non-x86 platforms as part of his sparc work. Perhaps some of those same issues prevented this stuff from working on powerpc in the past and so these #ifdef's can be removed now. int10/vbe should fail-safe on hardware that does not have an x86 BIOS, and if they don't it is a bug. After all, one of the reasons for having an x86 emulator is so that PC video cards can be soft-booted on non-x86 platforms. It would also be nice to be able to soft-boot OpenFirmware cards on platforms that don't support that natively. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: tdfx and DDC2
On Tue, Aug 30, 2005 at 09:30:26PM -0400, Michael wrote: Hello, Marc appears to have fixed various issues for int10/vbe on non-x86 platforms as part of his sparc work. Perhaps some of those same issues prevented this stuff from working on powerpc in the past and so these #ifdef's can be removed now. int10/vbe should fail-safe on hardware that does not have an x86 BIOS, and if they don't it is a bug. I'll just remove them and tell you what happens? Sounds good. If anyone has a powerpc with a PC card as a secondary to test with, that'd be good too. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Inter-module compatibility
On Wed, Aug 10, 2005 at 10:49:49AM -0600, Marc Aurele La France wrote: On Tue, 9 Aug 2005, David Dawes wrote: On Tue, Aug 09, 2005 at 10:45:15AM -0600, Marc Aurele La France wrote: Our loader scheme has been, and is, reasonably good at dealing with incompatibilities between modules and the core binary. But it is not so good with ensuring modules are compatible with each other. As a case in point, I am now faced with strong motivation to rework the three Vbe.*InfoBlock structures currently exported by vbe.h. Now, it's not my purpose here to get into these motivations, but reworking these structures would have consequences, one of which I am unsure how to deal with. At minimum, what I need to do is ... a) prevent drivers compiled with the current vbe.h from using a vbe module created with the new vbe.h; and b) prevent drivers compiled with the new vbe.h from using a vbe module created with the current vbe.h. The hammer approach would suggest bumping the video driver ABI version number all the way up to 1.0. (It currently sits at 0.8). This is overkill as doing so would prevent the loading of _any_ version 0.* module, vendor-provided or not, making this politically unwise. Bumping this version number to 0.9 (or leaving it alone) is insufficient as it prevents neither a) nor b), so changes would be required. I've prototyped a way of dealing with a). Basically, I'd have the vbe module's Setup() function call the common layer to associate a (potentially extended) XF86ModReqInfo occurrence with the vbe module, which the loader would then use to check parent modules against. Dealing with b) is trickier. All I can think of right now would require changes to the way video drivers load the vbe module, something I'd like to stay away from, especially in the presence of vendor-provided source and/or binaries. b) could be handled by changing the drivers to specify a vbe module version requirement when loading the vbe module. I don't think that is unreasonable given that child module version checking is already a part of the loadModule interface. Yes. One issue with this is that it doesn't do anything for vendor-provided drivers. Vendors would need to handle the b) case in their drivers. On the other hand, in this case, this would only need to be done to that subset of drivers that actually peek/poke inside the structures to be reworked, rather than passing structure occurrences around. This requirement would need to be clearly documented. Also, vbe.h could provide a macro to load the vbe module, the idea being to make the module control its own loading. If we were to start adding module interface version checking for other shared module interfaces, that would head off similar issues in the future. Yes, and how a module is loaded could be controlled by its main header, or something like xxxModule.h. Yes. Another option for handling both cases is to change the the name of a required entry point in the vbe module (such as VBEInit and VBEExtendedInit). There are cases where this will not result in a clean failure (one of the flaws of the current loader's handling of unresolved symbols), but it will fail before attempting to operate with incompatible data structures. It would fail, yes, but not with an appropriate message. The a) case can be made to fail cleanly by having the old names being functions that print out an informative message and exit. The b) case could be handled like this: #define VBEExtendedInit(a,b,c) \ (xf86LoaderCheckSymbol(newVBEExtendedInit) : \ newVBEExtendedInit(a,b,c) ? (FatalError(INFORMATIVE_MESSAGE), NULL)) However, I think it's better to control module loading from the module public headers, thus incorporating interface version checking with the interface definition and avoiding the need to resort to tricks like this. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Inter-module compatibility
On Tue, Aug 09, 2005 at 10:45:15AM -0600, Marc Aurele La France wrote: Hi. I've something here I'd like to discuss. Our loader scheme has been, and is, reasonably good at dealing with incompatibilities between modules and the core binary. But it is not so good with ensuring modules are compatible with each other. As a case in point, I am now faced with strong motivation to rework the three Vbe.*InfoBlock structures currently exported by vbe.h. Now, it's not my purpose here to get into these motivations, but reworking these structures would have consequences, one of which I am unsure how to deal with. At minimum, what I need to do is ... a) prevent drivers compiled with the current vbe.h from using a vbe module created with the new vbe.h; and b) prevent drivers compiled with the new vbe.h from using a vbe module created with the current vbe.h. The hammer approach would suggest bumping the video driver ABI version number all the way up to 1.0. (It currently sits at 0.8). This is overkill as doing so would prevent the loading of _any_ version 0.* module, vendor-provided or not, making this politically unwise. Bumping this version number to 0.9 (or leaving it alone) is insufficient as it prevents neither a) nor b), so changes would be required. I've prototyped a way of dealing with a). Basically, I'd have the vbe module's Setup() function call the common layer to associate a (potentially extended) XF86ModReqInfo occurrence with the vbe module, which the loader would then use to check parent modules against. Dealing with b) is trickier. All I can think of right now would require changes to the way video drivers load the vbe module, something I'd like to stay away from, especially in the presence of vendor-provided source and/or binaries. b) could be handled by changing the drivers to specify a vbe module version requirement when loading the vbe module. I don't think that is unreasonable given that child module version checking is already a part of the loadModule interface. If we were to start adding module interface version checking for other shared module interfaces, that would head off similar issues in the future. Another option for handling both cases is to change the the name of a required entry point in the vbe module (such as VBEInit and VBEExtendedInit). There are cases where this will not result in a clean failure (one of the flaws of the current loader's handling of unresolved symbols), but it will fail before attempting to operate with incompatible data structures. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xrandr not working in Dual Monitor
On Sat, Jun 25, 2005 at 02:16:50PM +0100, Andrew C Aitchison wrote: On Sat, 25 Jun 2005, Karthik Ramamoorthy wrote: Hi, xrandr is not working in my Dual Mnitor setup. In my /etc/X11XF86Config file. it i disable Xinerama then xrandr is working properly. But my Dual Configuration is not working properly. And if i enable Xinerama then xrandr is not working giving error as follow Xlib: extension RANDR missing on display :0.0 Can anybody tell me why this is happening. It isn't very clear how the two extensions should work together and the combination isn't implemented (there may be exceptions for some cards - I don't know). It should be clear how they would work together, but the blurring between physical resolutions and root window sizes coupled with an incomplete implementation results in the current situation. I suppose there are two underlying problems for RANDR: 1 X says that the clients can assume that the screen resolution and depth will not change; and 2 XINERAMA aims to hide the fact that there are multiple heads from the clients. I'd like to see it possible to change all of the currently static connection block information at run-time. The dynamic configuration infrastructure that I'm working on, combined with a minor revision bump of the X11 protocol will address all of these issues and more. If the original poster needs randr+xinerama now, he'll likely have some work to do. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: autoconf trouble - mice
On Tue, Jun 28, 2005 at 11:50:37AM +, Thorsten Glaser wrote: Hi, running X without configuration file works, except that the mouse defaults to a PS/2 mouse, whereas, under MirOS, it's always a wsmouse. Does anyone have a quick hint where I can patch this, before I go looking myself? (Yes, I admit I'm too lazy due to the summer heat.) Look in os-support/bsd/bsd_mouse.c, specifically the mouseDevs list and the FindDevice() function. If you have a /dev/mouse link, check what it points too. Other than that, make sure that this file is compiled with the appropriate defines. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: A correction for xf86cfg Cards database
On Sun, Jun 26, 2005 at 01:45:37AM +0200, Dejan Lesjak wrote: On Saturday 25 of June 2005 23:14, David Dawes wrote: On Sat, Jun 25, 2005 at 01:39:57PM +0200, Dejan Lesjak wrote: There's a tweak for xf86cfg Cards database at http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/32121 I wonder if such change still makes sense to be submitted to Bugzilla or is xf86cfg rather deprecated wrt newer autoconfigure methods. Anything that over-specifies static configuration data (as the out-of-date Cards database does) should be avoided. Such things should be limited to exceptions/workarounds and user/system preferences. Yeah, I thought so but I rather asked first. While the utilties that use the Cards database continue to be used, it may be useful to eliminate the unnecessary data in the Cards database. A patch that does this would be welcome. What do you mean by unnecessary data. Does this include such entries like this one that is wrong? Unnecessary data is any configuration information that isn't required in in order for XFree86 to run on a particular card. In almost all cases, the only thing required is the driver name. The chipset information, which was wrong in this entry, is not necessary here. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Imake changes in 4.5 break a couple of imake-using software packages
On Sat, Jun 25, 2005 at 01:33:24PM +0200, Dejan Lesjak wrote: A change was made to Imake.rules rev. 3.132 that removes dependencies from install targets. The rationale for this was to have everything created in the build tree during the build phase, allowing an install from a read-only build tree. Some of the install target dependencies have since been added back in though. A couple of projects that use imake for configuring Makefiles depended on imake adding dependencies to install:: target so those files were built at install time. This includes at least xgammon [1], xcheckers [2], xfm [3]. For example in xgammon: previously imake would add XGammon.ad as dependency for install target, now it fails at install like this: xgammon-0.98a# make install /usr/bin/install -c -s xgammon /usr/X11R6/bin/xgammon /usr/bin/install -c -m 0444 XGammon.ad /usr/X11R6/lib/X11/app-defaults/XGammon install: XGammon.ad: No such file or directory *** Error code 71 This is handled by InstallAppDefaults macro which in turn uses InstallNamedTarget from Imake.rules. One solution would be to instead add such dependencies to all:: target so they are still not built at install stage, which would seem to be in accordance to made Imake.rules change. I would modify the Imakefiles to add an AllTarget() for such files. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: can't get color map: invalid argument
On Mon, Jun 20, 2005 at 07:34:25PM +0800, Kai.Niu wrote: Hi ALL: Now, I am sucked on a new problem. As the topic, My TinyX can't get color map. I simply copied the rgb.txt generated from the source tree to the default directory. Unfortunately, TinyX server still can't get color map, and abend immediately. Dose anyone have clues on this? It will be very appreciated that someone could provide me some documentation about TinyX package..thank you all guys! It should find it if it is copied to the correct location (it does for me). The default location is /usr/X11R6/lib/X11/rgb.txt. This default location can be changed by defining DefaultRGBDatabase (leave off the .txt suffix), or you can override it at run-time by using -co command line option. Alternatively can have it built-in to the TinyX server instead so that an external file is no longer needed if you add a line like the following to Xserver/os/tiny/Imakefile: #define DDXOsColor YES David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: several fixes for XKB
On Thu, Jun 02, 2005 at 05:30:31PM +0200, Michal Maru?ka wrote: hello fellow _xfree86_ hackers! In order to provide to my friends, and maybe one day customers, a way to type differently, as described at http://maruska.dyndns.org/wiki/forkExtension.html ... i would like to donate a necessary infrastructure to xfree86 project, to be distributed under the xfree86 version 1.1 licence. I also provide patches exclusively under this license. Thanks. I'm going to commit these patches now. I'm working on the documentation (and final patches), which i will send here as several emails, you can see a pre-version at: http://maruska.dyndns.org/wiki/x-plugin In this email, I provide some patches(against CVS)/fixes for XKB: * memory allocation in file lib/X11/XKBMAlloc.c ** off-by-one errors. bzero-ing wrong regions. This is only triggered by a keyboard driver, which (at start) registers 256 keycodes. It is also impossible to change the interval of *core* valid keycodes. I have hacked a (probably unacceptable) workaround, by updating ConnectionInfo (from DIX). A part of my work is a new keyboard driver ( http://maruska.dyndns.org/wiki/medved ), and if this workaround is not accepted (nor easily corrected), i'll just force registering of all 256 keycodes. I'd like to see it possible to change most, if not all, connection block information at run time. This is something that would be good material for a minor revision of the X11 protocol. However, in the meantime, the impact of this on clients that do not expect such changes needs some investigation. Regarding your changes to ConnectionInfo in xkbUtils.c, it would be better to do as your comments says, and recompute it in the dix/ code. ** growing tables w/o never shrinking. table of XKB actions and keysyms. (i provide comments in the patch) * client requests for info lib/X11/XKBGetMap.c various vmodmap vs. modmap incomplete cut-n-paste bugs * client request to change XKB configuration failing (ProcXkbSetMap) programs/Xserver/xkb/xkb.c if the client request does not specify (XKB) types, the request fails. * notify event processing in lib/X11/XKBUse.c If number of XKB types changes (by calling apropriate functions), the XKB-unaware applications (eg. xterm) don't notice it! In other words (client side) synthesized core X events were not sufficiently informative. Next patches (some against the same files) will not contain these modifications (i hope). David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: (linux-only) keyboard driver Medved
On Thu, Jun 02, 2005 at 09:06:35PM +0200, Michal Maru?ka wrote: hello fellow _xfree86_ hackers! This is a second email in a series aimed at getting code into the X server needed to use a more sophisticated way of typing --- exploiting the time information: key semantics changes according to the duration of the key press. I am providing the code to be distributed under the xfree86 version 1.1 licence. Linux provides an alternative way to read keyboard input: /dev/input/eventXXX device, provided by the evdev driver/module. This source provides 2 new features: 1/ every event has a timestamp, which is more precise that calling (inside X server) GetTimeInMillis Playing with the time of key events is the core point of my rewriting plugin, so i had to make several changes to all parts of X server which handle key events. 2/ distinct hardware devices (keyboard) are reported in distinct devices/files /dev/input/event0 /dev/input/event1 ... The driver, called Medved, wraps/represents the set of evdev devices (keyboards) as 1 X keyboard. I.e. X clients see 1 _core_ keyboard --- no need to play with XInput: The driver is quite unusual, b/c it handles more file descriptors, and therefore it cannot use a higher level xf86AddInputDriver and xf86Wakeup but i have to use lower level RegisterBlockAndWakeupHandlers. and look directly at the select mask to see which of managed files/devices has input ready. While coding this driver, i realized the cause of several bugs in other drivers. I had previously communicated in http://www.mail-archive.com/devel%40xfree86.org/msg06818.html the conflict between current state of the 2 halves of key handling code, separated by xf86EventQueue. In that message, i talked about down bit-array, now i add, that keyc-state is impossible to use in the lower half. This (incorrect use of upper half's state in the lower half, which runs ahead in time) explain 2 bugs: 1/ XF86Config options: Option AllowDeactivateGrabs yes # C-M kp-/ steal the grab Option AllowClosedownGrabs yes # C-M kp-* kill the grabbing client simply didn't work (in situations i needed them) situation: an application stopped accepting key events (i.e. holds a synchro grab doesn't call XAllowEvent) - therefore keys accumulate in syncEvents (dix/events.c) w/o effecting the XKB state XKB state is not meta control modifiers now, you want to steal the grab, so you press 3 keys Contol Meta kp-/ - the first 2 events enter the queue, and the keyboard driver when processing the 3rd (kp-/) will look at the XKB state which is not meta control modifiers, hence it will not trigger any special function. Same applies to C-M-Fn to switch VTs (during such frozen situation). 2/ C-M-Fn occasionally leaked the Fn key into applications. When the Fn was processed before the the upper part picked C M from xf86EventQueue and changed the XKB state. This is possible when X server reads all 3 key events at once. Solution is not very flexible, though. I just look if the fixed keys (say Alt_L, Ctrl_L) are down. (Since i play a lot with the time,) medved does not use HW autorepeat. This will be explained in the next email. More hw keyboards are used in the OR mode: a key is down, if and only if it is down on any of the hw keyboards. Hotplug is handled by polling, sorry. I had to pull some functionality from the linux specific part of the kbd driver (lnx_kbd.c) into a shared part. If these functions are needed, I'd suggest naming them with an xf86 prefix and providing dummy versions for other platforms, or, if more appropriate, adding them as new fields to KbdDevRec (xf86OSKbd.h). I enclose these preparative changes as a patch. The driver itself is at http://maruska.dyndns.org/comp/packages/medved.tar.gz If you build xfree86 server with this patch driver, you should notice that: - auto-repeat does not work - X mixes its monotonic time (GetTimeInMillis) with the timestamp coming from evdev devices (gettimeofday) ... with various consequences (keyboard grabbing stops working, iirc) I don't bother providing fix for this, because in the next messages i will provide - patch for linux kernel GetTimeInMillis: preversion http://maruska.dyndns.org/wiki/kernel.html - and an alternative method of generating auto-repeat events: at last a reasonable auto-repeat, which i found lacking 2 years ago, when i started fixing (hacking around) the key-event processing in X server. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Live Touchscreen Calibration [WAS: magictouch touch screen driver]
On Thu, Jun 09, 2005 at 04:00:54PM -0700, bruno schwander wrote: BTW, I submitted the source for the magictouch driver on this mailling list, is there any chance it will appear in the XFree86 tree someday ? If a comitter needs changes, fixes to it or has questions, I'll be happy to help as I can. I'm committing it now. Thanks for the submission. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Live Touchscreen Calibration [WAS: magictouch touch screen driver]
On Fri, Jun 10, 2005 at 10:53:47AM -0400, Fred Gleason wrote: On Friday 10 June 2005 03:17, Veikko Werner wrote: actually a great thing to have, but not that easy. The main problem is, that the driver itself has to be disabled. Why so? AFAICT, we basically need two things: 1) The ability to get 'raw' --i.e. unscaled -- data from the device during the calibration run. 2) Some way to set the calibration parameters of the driver based on the results of 1). Both of these could be accomplished by means of adding appropriate new methods to each driver. While I suppose this does involve effectively 'disabling' the driver for the duration of the calibration run, this fact can be completely hidden from the server. The server merely doesn't receive pointer updates while calibration is in progress. Or am I missing something here? Sounds reasonable to me. The XInput extension could be enhanced to provide calibration requests which would be the mechanism for a calibration utility to communicate with the driver. The problem with most of the solutions I've seen for this so far is that they attempt to open a communication path directly between the driver and a calibration utility, often creating security problems. The X server already provides an authenticated mechanism for doing such things. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: magictouch touch screen driver
On Tue, May 24, 2005 at 08:05:43AM -0700, bruno schwander wrote: I have my driver for the serial MagicTouch touchscreen working. There is just one thing that I am not sure of: if the resolution is changed dynamically (by some program running fullscreen for example), the scaling is off. How do I find if the resolution has changed ? Right now, I check the screen size when the device inits, and store that away. Should I instead use the actual screen size everytime through screenInfo ? Is that safe ? Also, how can I twiddle the DTR, RTS lines, I do not find some abstraction for that... Maybe xf86SetSerialModemState() will let you twiddle the DTR, RTS lines. I haven't looked at that stuff in a while. Perhaps someone else can give you some answers to your other questions. then, how do I submit the driver ? send it to this list ? You can either send it here, or submit it at bugs.xfree86.org. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Keyboard handling on non-x86
On Mon, May 23, 2005 at 11:43:48PM -0400, Michael wrote: Hello, That's good. Even better, especially for the modular driver, would be to handle this automatically in the driver at run-time. The mouse driver does this and should handle auto-detection of wscons support on NetBSD for mouse input without the need for any mouse configuration data in the config file. I'll have a look how the mouse driver does that and see if I can do something similar for kbd - I'm not sure that's really necessary though, the only NetBSD port that could run XFree86 without wscons was i386 - it switched to wscons ages ago. My point is only that you shouldn't have to tell the XFree86 server to use wscons for the keyboard driver. It should know without being told, especially on platforms where it is the only viable option. Also, as you noted in your first message on this subject, it should try a default wskbd device if none is specified explicitly in the config file. The wscons support is used for OpenBSD too. I don't remember the details now, but some of the i386 Open/NetBSD test platforms I was using when automating the mouse device/protocol selection either didn't have wscons or it wasn't activated in the default install. See the OpenBSD/NetBSD versions of the FindDevice(), GuessProtocol() and haveWSCons() functions in bsd_mouse.c for how it is handled by the mouse driver. The Sun map had a minor mistake (or feature?)- Props/L3 and ScrollLock were swapped. Sounds like a bug. I wasn't sure, I have only Type 5 keyboards here ( well, one 5 and one 5c, both US ). Anyway, I tested the whole thing on NetBSD/macppc too - works as expected. Sounds good. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Keyboard handling on non-x86
On Thu, May 19, 2005 at 08:11:25PM -0400, Michael wrote: Hello, right now I'm struggling to get XFree86 properly supported on NetBSD/sparc and sparc64 and one problematic point is the keyboard handling. With Option Protocol wscons Option Device /dev/wskbd0 things work reasonably well but the Xserver doesn't pot these options into XF86Config when configuring itself, so I tried to get the Ideally it should automatically determine when wscons mode is needed. This would be easier to do via the modular XFree86 keyboard driver than with the built-in kbd driver. See more below. read-input-from-console mode to work. This is where the mess started. XFree tries to switch the console fd into raw mode and if that fails it complains and recommends to add the above lines to XF86Config. This was ok since we didn't support raw mode on Sun keyboards. Now we do. In this mode of operation XFree obviously expects to read AT-style scancodes from the console fd and feed them into its event queue via xf86PostKbdEvent(). With a Sun Type 5 this can't work since it uses a completely different set of scancodes ( but at least it uses but 7 the same way to signal key up / down ). What confused me for a while is some code in xf86PostKbdEvent() that seemed to handle Sun scancodes but as it is now it can't possibly work. And it doesn't properly translate Sun scancodes into whatever X uses internally, so I conditionally replaced xf86Info.kbdEvents with a function that reads from the console fd, translates Sun scancodes unto AT scancodes the way xf86PostWSKbdEvent() does and feeds them to xf86PostKbdEvent(). This works mostly, but I found that the PageDown key didn't deliver a scancode. Some debugging revealed something ugly - its translated keycode collides with the prefix code used by AT keyboards for cursor keys and the number block and the prefix handling in xf86PostKbdEvent() is skipped when xf86Info.kbdEvents points to the wscons version. Still easy to get around this, ugly as it is. Finally I found that atKeynames.h defines names for Sun-typical keys found nowhere else, but what it assigns them starts at 0x84 so it collides with the AT keyup/down bit - to deliver it to xf86PostKbdEvent() I'd have to prefix them which I can't since prefixing is disabled. So - what would you suggest - I think I should replace xf86PostKbdEvent() with something usable by wscons which doesn't need all this AT-inherited nonsense, I don't really see why I should emulate this broken excuse for a protocol to get keyboard events into the Xserver. There are two sets of functions which seem to deal with keyboard input on BSD - one in bsd_io.c and another in bsd_kbd.c - the latter seems unused. What's the purpose of this? And lastly - why does the wscons protocol option require a device name? Defaulting it to /dev/wskbd should do the trick. Would it be better to write an input driver module for wskbd that uses wscons' hardware-independent scancodes instead? Seeing the mess that the current code is I'd almost think so. I would suggest following this up via the modular keyboard driver. Like the mouse driver, it consists of two components: a platform-independent input driver module in xfree86/input/keyboard/, and an OS-specific portion in xfree86/os-support/platform/. The interface between the two should make it possible to avoid forcing all keyboard models into the AT-style mould. Also, as with the mouse driver, it should be able to automatically determine which is the best device/protocol mode to use at run-time. One thing to keep in mind is that the mapping between physical keys and their X keycodes should remain the same on all platforms. This mapping is specified in the file xc/programs/xkbcomp/keycodes/xfree86. If you find any issues with the keyboard driver or the interface between the platform-specific and platform-independent components of it, this is the place to discuss and resolve them. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Keyboard handling on non-x86
On Fri, May 20, 2005 at 02:37:59PM -0400, Michael wrote: Hello, Ideally it should automatically determine when wscons mode is needed. Ok, on NetBSD that would be always, none of the pre-wscons ports runs XFree as far as I can tell. So - some ( like x86 ) might not exactly /need/ it but they /should/ use it. If older versions of NetBSD (x86 at least) don't have wscons, there should at least be a check that it is available. This would be easier to do via the modular XFree86 keyboard driver than with the built-in kbd driver. See more below. Yeah, I finally found it - looks MUCH more sane than what I've been ranting about yesterday. In fact I got it to work pretty well now and I have a few questions. I would suggest following this up via the modular keyboard driver. Like the mouse driver, it consists of two components: a platform-independent input driver module in xfree86/input/keyboard/, and an OS-specific portion in xfree86/os-support/platform/. The interface between the two should make it possible to avoid forcing all keyboard models into the AT-style mould. That's what I'm doing now. When I find a Sun keyboard I simply change the default xkb settings to rules=sun and model=type4 or type5. Works pretty well when I disable scancode remapping ( it's still in the driver... ) - then even the Sun-specific keys work and it can still be overridden via XF86Config. Also, as with the mouse driver, it should be able to automatically determine which is the best device/protocol mode to use at run-time. Agreed. If you find any issues with the keyboard driver or the interface between the platform-specific and platform-independent components of it, this is the place to discuss and resolve them. What I'm doing right now is to make the keyboard driver use xkb for scancode-keysym translation, at least for Sun keyboards. This allows all keys to work and avoids all these AT-scancode quirks. To do that I leave both the remap function and the scancode translation table at NULL and set the XKB keymap according to what wskbd tells me about the keyboard ( sun type4 or sun type 5 ). The wscons support code there has numerous issues: - it didn't know about WSKBD_TYPE_SUN5 so initially it tried to use AT-style scancode translation. - the mapping between XLEDs and wscons ioctls is wrong. The reason seems to be the sun keymap which says: indicator 4 = Caps Lock; indicator 3 = Compose; indicator 2 = Scroll Lock; indicator 1 = Num Lock; ... while XFree's map says: indicator 1 = Caps Lock; indicator 2 = Num Lock; indicator 3 = Scroll Lock; the latter seems to be hard-coded into the driver. The driver still attempts to translate everything into AT scancodes which is a Bad Thing in my opinion, I think the main reason is to catch special keystrokes like ctrl-alt-backspace before xkb does. Is this really necessary? Shouldn't xkb handle them correctly? These are still handled in the driver for cases when XKB isn't used, and as fallbacks when XKB initialisation fails for some reason. It is probably a good idea to keep these fallbacks within the keyboard driver, especially the ctrl-alt-backspace escape method. Wouldn't it be better to select a sane xkb map instead of attempting to make everything fit a PC keymap? I suggested using the xfree86 XKB rules/keycodes for consistency of features across platforms and because they are the best-supported ones within XFree86. In the past, diverging from this has resulted in unnecessary feature and functionality differences between platforms. Also, the set of XKB key tokens (the objects mapped to raw keycodes by the keycodes files) would ideally be platform-independent to avoid the unnecessary need to have multiple copies of the XKB symbol mappings. The symbols mappings in xkbcomp/symbols/pc are the most full-featured that we have, and they're not really PC-specific. In fact, it is probably a good time to promote them out of their pc/ subdirectory. That would just leave the issue of whether the raw keyboard codes are mapped to a consistent set of X keycodes within the driver, or whether that is handled by using different XKB keycodes files. I don't see a great advantage to doing this mapping at the XKB level. I'd like to see a lot of the unnecessary platform differences amongst the XKB data files eliminated. I suspect that with some work most of the platforms specific copies of the XKB symbols files could be removed. (It may also be time to remove the obsoleted xkbcomp/keymap files.) Ivan Pascal is most familiar with this area and may have other ideas/comments/plans. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xon.sh
On Wed, May 04, 2005 at 11:09:16AM -0700, Mike Urban wrote: I do not know the proper 'channel' for this sort of feedback, but we have for some time been using the following enhancement for 'xon' that others might find useful. We do not run remsh/rcmd/rsh servers on our systems. So we add a new flag so we can say xon target -remote ssh command to go through SSH instead. Note that because of the way xon is used, no SSH session is left behind, and the DISPLAY is the X server rather than being tunneled through SSH. Whether this is a bug or a feature is a matter of taste. XFree86 already has this patch integrated from when you originally submitted about two years ago :-) If there are good uses for this non-tunneled operation, I'd suggest modifying the remote shell selection logic to use ssh as the first choice, falling back to rsh and the others only when it isn't available. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: GL problems
On Tue, Apr 26, 2005 at 02:19:33PM +, Thorsten Glaser wrote: David Dawes dixit: Another useful data point might be a delay loop in place of the usleep(). I was going to try that today, replacing the call usleep in the .s file with a simple delay loop, but checked first if it still failed without, and it worked without the usleep workaround. What did I change? I lowered the default cflags from -march=pentium to -march=i486 (to fix another miscompile in ppp(8)) and rebuilt the whole system (just playing with cflags in X had not helped earlier). I'm surprised, but thankfully it looks like a gcc optimisation bug. Thanks for the help, though. That's interesting. Sad: now 108.000 fps instead of 115.200 fps :( By the way, you wanted to provisionally commit my decompress.c, I hope you didn't forget? I didn't forget. I'll commit it soon. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: GL problems
On Fri, Apr 22, 2005 at 08:30:55PM +, Thorsten Glaser wrote: David Dawes dixit: Does replacing the fprintf with sleep(1) make a difference? Even with usleep(1), glxgears still works. I've committed that as a temporary workaround now, till we discover the real problem. This points to an underlying problem elsewhere. I keep mentioning libpthread because that appears to be the only difference between clients that have the problem and those that don't. An XFree86 build with the threading options disabled should confirm this one way or the other (a look at the 'Multi-thread safe libs' portion of OpenBSD.cf should show what to change for the build). Another useful data point might be a delay loop in place of the usleep(). Use volatile variables or build with optimisation disabled to avoid the loop being optimised out of existence by the compiler. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: [RESEND] free xc/lib/font/fontfile/decompress.c replacement
On Fri, Apr 15, 2005 at 12:42:20PM +, Thorsten Glaser wrote: since I'm a BSD developer, the natural place to look for me regarding the xc/lib/font/fontfile/decompress.c sources (Keith Packard said it was derived from some ancient BSD sources) is our own source tree. Voilà, there it is - src/usr.bin/compress/zopen.c, that's why the decompress.c source looked so familiar to me. Yes, historically I believe that this zopen.c is derived from from the older decompress.c. I've taken a whole afternoon hacking this together, and tested it on a foo.bdf.Z file (about 400 KiB compressed), derived from xc/fonts/bdf/misc/12x13ja.bdf, with one character modified so I can distinguish it. Works For Me(tm), but I'd be happy if someone would review and endorse this replacement before it gets committed, since I have absolutely no experience hacking X11 code, I must admit. I don't have the time right now to give it a thorough review, but I wouldn't object to committing it provisionally to XFree86 to give it wider exposure. I've tested mkfontdir on the file, which is dynamically linked against libXfont.so.1.5 (thus I guess it's safe), but had not yet the chance to do a full XFree86 rebuild due to day-job constraints. The new file comes with only a standard 3-clause UCB-style licence, some more credits, and a much easier licence covering my work. I do believe it's OSD and DFSG compliant and GNU GPL compatible; supporting compress'd font files gives us an advantage over x.org, which is something I'd like to see ;-) Also it's important in case there is still an ancient Unix® around. :-) David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: GL problems
On Sat, Apr 16, 2005 at 10:46:46PM +, Thorsten Glaser wrote: This one goes deep into i386 interna... I still wonder if there is an issue related to libpthread. Dixi: Looks like a compiler bug to me. Okay, it doesn't. I have generated two assembly files, x1 and x2, to be the output of the normal compiler command for xc/lib/X11/x11trans.c with the -S option added. The difference is that, before compiling x2, I have patched xc/lib/xtrans/Xtrans.c with this: --- Xtrans.c19 Mar 2005 17:19:31 - 1.2 +++ Xtrans.c16 Apr 2005 22:41:59 - @@ -424,6 +424,7 @@ XtransConnInfo ciptr = NULL; Xtransport *thistrans; +fprintf(stderr, %s, address); PRMSG (2,Open(%d,%s)\n, type, address, 0); #if defined(WIN32) (defined(TCPCONN) || defined(DNETCONN)) Does replacing the fprintf with sleep(1) make a difference? David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
mailing list updates
The XFree86 mailing lists have been modified on an experimental basis to require subscription for posting. Perhaps this will be enough to eliminate the 0.1% of spam that our existing filtering does not already catch. The existing filtering (spam assassin plus a home-grown filter) will remain in place. If this does not prove effective, or if the list admin burden increases signficantly (i.e., posters do not subscribe), then the behaviour may be reverted. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Darwin extern/static fix
On Wed, Apr 13, 2005 at 11:52:47AM -0700, Torrey Lyons wrote: Bugzilla #1576 and the fix committed for it is only partially right. The patch applewmExt.h is right, but patching the imported Mesa code in extras/Mesa/include/GL/internal/dri_interface.h is the wrong thing to do and likely has unintended side effects on other platforms. The correct fix is just to rename __driConfigOptions in lib/GL/apple/dri_glx.c. Thanks for pointing out the issue. I didn't find anything that requires the external declaration of __driConfigOptions, which is why I applied the patch as submitted. Perhaps something should in the BUILT_IN_DRI_DRIVER case. There are also likely other issues with the BUILT_IN_DRI_DRIVER case. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: GL problems (was Re: Commenced update to XFree86(tm) 4.5.0 on MirOS BSD)
On Wed, Mar 30, 2005 at 05:35:17PM +, Thorsten Glaser wrote: David Dawes dixit: Can you try running glxgears with ktrace or truss (or something like that), and see how that compares with apps that work OK? Sure. Here's the ktrace and systrace -A output for glxgears (does not work natively, works in the emulation) and xlock (works for both). One difference I see is that glxgears is linked against libpthread, while xlock is not. In the xlock case, the socket() system call is followed soon after by a connect(). In the glxgears case, the socket() call appears successful (same positive return value as in the xlock case), but the behaviour thereafter is quite different. Try editing xc/lib/Xtrans/Xtransint.h and changing the definition of XTRANSDEBUG to 5, rebuilding libX11, and running glxgears against that. This will enable more of the xtrans messages and may help narrow down the failure point. BTW, the ktrace for the glxgears in emulation shows it failing because of not finding libpthread.so.6.0. BTW, what is this emulation? David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Commenced update to XFree86(tm) 4.5.0 on MirOS BSD
On Tue, Mar 22, 2005 at 07:46:17AM +, Thorsten Glaser wrote: David Dawes dixit: First of all, thanks for the continued support! Sure thing, XFree86 has provided us with a stable X implementation long enough, no reason to fix what ain't broke. What is the policy there for bumping shared library majors? ABI changes. When they introduced ProPolice, all libraries needed some new functions from a newer libc major, so they bumped everything. Oh, OK. The majors for OpenBSD builds of XFree86 are already different than for most other platforms, and I think that was done for the a.out-elf transition. I don't think they have changed any shared library version when i386 went ELF. Shared library versions are machine-independent on OpenBSD (and so on MirOS, but we've still not yet sparc and macppc running again due to lack of ressources, but it will come). In OpenBSDLib.tmpl the versions are bumped for releases = 3.1. Was that the ProPolice bump or something else? It might be a good idea to see what of the ws* stuff needs to be folded in. And some of the other MirOS support code as well, maybe? Yes, definitely. I'm sure I haven't done everything according to XFree86 coding standards, but I've tried so far. Especially the MirBSD.cf could need some cleaning, because I've had issues when I started. (All MirOS BSD versions define __OpenBSD__ *and* __MirBSD__) I've also linked freetype against the system libz and exported the functions, as well as the ProPolice functions, using the xf86 loader, so the modules need not be built with -fno-stack-protector any more. OK. The complete diff can be retrieved using $ CVS_RSH=ssh cvs -z9 -d [EMAIL PROTECTED]:/cvs \ rdiff -urxf-4_5_0 X11/xc (password anoncvs) (attention, there are three new programmes in xc/programs/, namely ssh-askpass, xlock and xsystrace, thus the diff is a bit large) On request, I can try to sort out these diffs, but most of it is legacy from the OpenBSD version of XF86 4.3 and 4.4RC2 before they went to x.org, and Matthieu Herrb can probably tell you better which purpose a specific patch has for these. I haven't seen this on any of the platforms I've tested on, including fairly recent OpenBSD versions. Do other clients start up OK? You may I will try xlock, I think it's got some GLX modes too. I'm curious because it seems to fail before getting into the GLX-specific code. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Tue, Mar 22, 2005 at 07:52:28AM +, Thorsten Glaser wrote: Alex Deucher dixit: and two for bsd 1. bsd monolithic 2. bsd-coremodular as above why not just let the kernel provide the drm? Most if not all recent linux and bsd kernels (last few years) have drm support. The dri and ddx will adapt depending on what's available in the kernel. For the record, BSD seems to mean FreeBSD exclusively here (and maybe DragonFly, which relates to FreeBSD like MirOS relates to OpenBSD, namely being a fork). I've tried to build DRI/DRM on OpenBSD and MirOS for XF86 4.4; I eventually got DRI working but it just blanked the screen instead of using Mesa when it didn't find a DRM, which is a K.O. criterium, thus I haven't looked deeper into it. The DRM use FreeBSD-ish bsd.kmod.mk whereas OpenBSD and derivates have bsd.lkm.mk, and from a short glimpse on the code I've got the impression it's non-trivial to support OpenBSD too. I'm not too experienced in kernel programming though. That's pretty much the same conclusion I came to. I think we _can_ load kernel modules though, I've played with a VMware 3 module some time (but VMware didn't want to play with me, so I left). If that screen blank, no Mesa issue is fixed, you could probably enable DRI builds on OpenBSD and MirOS, too. I haven't looked into it on 4.5 yet. It only makes sense if working DRM modules are available though. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Commenced update to XFree86(tm) 4.5.0 on MirOS BSD
First of all, thanks for the continued support! On Sun, Mar 20, 2005 at 09:53:22PM +, Thorsten Glaser wrote: Hi all, I've built it through, and most of the stuff works for me. Before updating, you will have to remove /usr/X11R6 in its entirety, as I've reverted from cloning OpenBSD behaviour (in this case, bumping the shared library majors because of ProPolice) to principle of least diffs against the vendor. What is the policy there for bumping shared library majors? The majors for OpenBSD builds of XFree86 are already different than for most other platforms, and I think that was done for the a.out-elf transition. There's still some 300-400 KiB worth of unified diff, however some of that is only a pleasure diff (e.g. linking freetype2 against the system libz, and exporting the system libz's symbols in the XF86 loader to the module), and most other stuff is taken from OpenBSD (wsfb, wscons, wsmouse, wskbd stuff) where I don't know if it's still needed. It might be a good idea to see what of the ws* stuff needs to be folded in. Anyway, that's a works for me and the next development snapshot will be published with XFree86(tm) 4.5.0, and of course all required advertising clauses are reproduced in the documentation *wink* That makes us second to only Fink in adopting, as far as I know, by the way. I've got some minor problems still: [EMAIL PROTECTED]:/home/tg $ glxgears _X11TransSocketOpenCOTSClient: Unable to open socket for local _X11TransOpen: transport open failed for local/odem.66h.42h.de:0 Error: couldn't open display (null) [EMAIL PROTECTED]:/home/tg $ print $DISPLAY :0.0 and of course the old apps such as mplayer don't work since they were linked against the old libs with higher shlib versions I just deleted, but the M*zilla(tee emm) Firef*x(tee emm) runs just fine in the OpenBSD binary emulation. To the XFree86 list: * feel free to list MirOS as a supporting project, as it was last release Thanks. * do you have any idea regarding the above error? IPv6, maybe? consider MirOS a clone of OpenBSD for most aspects. I haven't seen this on any of the platforms I've tested on, including fairly recent OpenBSD versions. Do other clients start up OK? You may need to trace through what's happening in the xtrans code. glxgears calls XOpenDisplay in a fairly standard way. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 4.4.99.903: s3: missing some of the screen
On Tue, Mar 15, 2005 at 12:37:28PM +0100, N?meth M?rton wrote:
David Dawes wrote:
On Mon, Mar 14, 2005 at 08:45:07PM +0100, N?meth M?rton wrote:
Marc Aurele La France ?rta:
On Fri, 11 Mar 2005, [ISO-8859-2] N?meth M?rton wrote:
Starting XFree86 4.4.99.903 using the s3 driver at mode 1024x768 8bpp
I see the following screen:
0 303 1023
| | |
0 -----+
|
|
GOOD AREA |
|
|
767----+
where B means that black pixels are displayed always.
I don't know what is the problem exactly but the attached patch
removes this bug. (May cause new ones, too...)
chip:
-
S3 Trio64V+
P1E3BF
86C765
9650 MB851
TAIWAN
VGA BIOS:
-
Phoenix S3 TRIO64V+ Enhanced VGA BIOS. Version 1.02-02
Copyright 1987-1992 Phoenix Technologies Ltd.
Copyright 1992-1995 S3 Incorporated.
All Rights Reserved
lspci -v:
-
:00:09.0 VGA compatible controller: S3 Inc. 86c764/765
[Trio32/64/64V+] (rev 54) (prog-if 00 [VGA])
Flags: medium devsel, IRQ 10
Memory at e000 (32-bit, non-prefetchable) [size=64M]
Could you try the attached instead? This one also fixes a few other
problems I noticed.
The problem is solved if I use the patch.
Running the xtest 4.0.11 the following tests are failed using
4.4.99.903+patched s3 driver, using 1024x768 8bpp:
XListPixmapFormats
XDrawArc
XDrawArcs
XSetFontPath
XAllocNamedColor
XLookupColor
XStringToKeysym
XDrawArc and XDrawArcs are expected.
Are these tests bad?
There is an accepted long-standing mis-match between the spec and
the implementations. My recollection is that an implementation that
matches the spec exactly would require higher precision arithmetic
than is typically available.
XSetFontPath might be configuration related.
After installing
ftp://ftp.xfree86.org/pub/XFree86/snapshots/4.4.99.903/binaries/Linux-ix86-glibc23/Xf100.tgz
optional package and setting the path in /etc/X11/XF86Config the test
passed. I cannot find in the xtest 4.0.11 documentation that the 100dpi
fonts must installed to pass these tests.
I'll add that to the xtest docs.
XStringToKeysym should go away if you run with XKB disabled.
I run the X server as
XFree86 -ac -s 0 -kb -dpms
so the -kb disables the XKB. The error message is:
Test 7: FAIL
XStringToKeysym() returned NoSymbol for string Greek_IOTAdiaeresis.
What are the reported problems for the other three (XListPixmapFormats,
XAllocNamedColor, XLookupColor)?
Tests for XListPixmapFormats
Test 1: FAIL
XListPixmapFormats() returned 7 structures
Expected 6 structures
I believe that this was fixed for the 4.4.99.22 snapshot. The problem here
was in libX11. Are you running xtest against a recent libX11?
Summary of Results for XListPixmapFormats
-
PASS 0
FAIL 1
UNTESTED 1
Tests for XAllocNamedColor
Test 2: FAIL
--- Running test with visual class PseudoColor, depth 8
--- Testing with supported visual class PseudoColor
--- Running test with visual class GrayScale, depth 8
--- Testing with supported visual class GrayScale
Colour names gray and sky blue yield the same supported rgb values.
Colour names dim gray and magenta yield the same supported rgb
It looks to me like these tests are not taking into account the
rounding that happens with coarse GrayScale and and TrueColor
visuals. The tests themselves probably need to be reworked.
David
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: 4.4.99.903: s3: missing some of the screen
On Mon, Mar 14, 2005 at 08:45:07PM +0100, N?meth M?rton wrote:
Marc Aurele La France ?rta:
On Fri, 11 Mar 2005, [ISO-8859-2] N?meth M?rton wrote:
Starting XFree86 4.4.99.903 using the s3 driver at mode 1024x768 8bpp
I see the following screen:
0 303 1023
| | |
0 -----+
|
|
GOOD AREA |
|
|
767----+
where B means that black pixels are displayed always.
I don't know what is the problem exactly but the attached patch
removes this bug. (May cause new ones, too...)
chip:
-
S3 Trio64V+
P1E3BF
86C765
9650 MB851
TAIWAN
VGA BIOS:
-
Phoenix S3 TRIO64V+ Enhanced VGA BIOS. Version 1.02-02
Copyright 1987-1992 Phoenix Technologies Ltd.
Copyright 1992-1995 S3 Incorporated.
All Rights Reserved
lspci -v:
-
:00:09.0 VGA compatible controller: S3 Inc. 86c764/765
[Trio32/64/64V+] (rev 54) (prog-if 00 [VGA])
Flags: medium devsel, IRQ 10
Memory at e000 (32-bit, non-prefetchable) [size=64M]
Could you try the attached instead? This one also fixes a few other
problems I noticed.
The problem is solved if I use the patch.
Running the xtest 4.0.11 the following tests are failed using
4.4.99.903+patched s3 driver, using 1024x768 8bpp:
XListPixmapFormats
XDrawArc
XDrawArcs
XSetFontPath
XAllocNamedColor
XLookupColor
XStringToKeysym
XDrawArc and XDrawArcs are expected. XSetFontPath might be configuration
related. XStringToKeysym should go away if you run with XKB disabled.
What are the reported problems for the other three (XListPixmapFormats,
XAllocNamedColor, XLookupColor)?
David
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: xtest version in test/xsuite/NOTES.xf86
On Mon, Mar 14, 2005 at 09:24:24PM +0100, N?meth M?rton wrote: Hi! The version number of the xtest is not updated in the file test/xsuite/NOTES.xf86 Thanks for pointing that out -- I'll fix it. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Yet another Xpm vulnerability
On Fri, Mar 11, 2005 at 12:54:47PM +, Matthias Scheler wrote: On Thu, Mar 10, 2005 at 06:37:06PM -0500, David Dawes wrote: How about the attached patch? I just pulled OpenBSD-current's Xpm source into NetBSD. It has fixes for this vulnerability and various other bug fixes from X.org. I looked at one of the patches out there for this, and it only seemed to solve one end of the problem: trapping a negative XImage.bitmap_unit value, which, when converted to a signed value allowed the heap to be overflowed. It didn't address the same problem arising from a large positive XImage.bitmap_unit value, or a similar problem with the XImage.bits_per_pixel field, but the patch I sent does. There are also other XImage fields that are not validated, but from a cursory look they don't appear to be used by Xpm in a way that can cause write-to-stack or heap overflows. What is the mechanism for getting the bad data into the privileged program to start with? Maybe a web browser? Well, the bad XImage data has to come from somewhere. The two places that libXpm gets XImage data that it (or libX11) doesn't have direct control of is via XGetImage() and XCreateImage(), both of which use data provided by the X server without any validation. This is why I suggested that perhaps libX11 should validate such data before passing it back to the application. If an application is using user-supplied data to generate an XImage in another way and not validating it, then that is arguably a bug in the application. Either way the patch should trap that within libXpm. I'm curious about the mechanism because it might hint at other issues that need attention. Anyway, this is from a quick look at the reported problem based on the description in the CAN. If you or anyone else see something that I'm missing, let me know. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xc/Install
On Mon, Mar 07, 2005 at 04:32:00PM +0100, Frank Gie?ler wrote: Unfortunately, the new file xc/Install breaks the install target on filesystems that are case insensitive. Can this be fixed? The easiest solution is probably to append .txt to the top level doc files. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
XFree86 4.5.0 RC3 (4.4.99.903)
The third XFree86 4.5.0 release candidate is available. Source and some binaries can be found at: ftp://ftp.xfree86.org/pub/XFree86/snapshots/4.4.99.903/ Documentation is at: http://www.xfree86.org/4.4.99.903/ Preview documentation for 4.5.0 is at: http://www.xfree86.org/~dawes/pre-4.5/ This release candidate resolves problems discovered during testing of the first two release candidates. The DRM source has been rolled back to a version based on what we shipped with the 4.4.0 release, and has been verified to build and run on a range of Linux 2.4.x and 2.6.x kernels, and on recent versions of FreeBSD. Thanks to all who have tested and reported their results and/or submitted fixes! This is expected to be the final 4.5.0 release candidate, and marks the start of the code freeze phase. Only serious bug fixes and documentation updates will be accepted between now and the 4.5.0 release. All potential commits other than documentation updates must be reviewed and approved by either Marc La France or myself during this code freeze period. The focus now is on platform and stability testing, and on updating the documentation. If you run into any problems with this release candidate, please report details here. The remaining issue for the 4.5.0 release is: - Documentation updates, especially the releae notes. If you have updates for the documentation, send them here. Enjoy! David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: lib/GL
On Fri, Mar 04, 2005 at 02:18:38PM -0700, Marc Aurele La France wrote: On Tue, 1 Mar 2005, David Dawes wrote: On Tue, Mar 01, 2005 at 06:51:54PM -0700, Marc Aurele La France wrote: I've been auditing various builds and noticed that xc/lib/GL/mesa/drivers/x11 is never built, let alone referenced. Is this an oversight, or can this directory be deleted? It is supposed to be built and referenced when GlxBuiltInXMesa is set to YES. Although the necessary reference to it is in lib/GL/GL/Imakefile, there doesn't appear to be anything in lib/GL/Imakefile that would actually cause that directory to be built. That could be fixed. Hummm. This looks like another post-4.5 thing. More importantly though, there is a reference to the Imakefile.inc file in that directory from Xserver/GL/mesa/GLcore/Imakefile, and that is used. Not so. Removing that reference doesn't change anything. It doesn't change anything because the objects are referenced as: XOBJS = ../X/?*.o rather than by using the make variables defined in that Imakefile.inc. However, it is also referenced from Xserver/GL/mesa/X/Imakefile, and removing that reference will be noticed. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problems with xf86Globals.c
On Sat, Mar 05, 2005 at 08:32:30AM +, Dr Andrew C Aitchison wrote: I'm not sure why this change from January to xc/programs/Xserver/hw/xfree86/common/xf86Globals.c is only biting now but: It's a more recent change to xf86Privstr.h. I see that Marc has committed a fix for this (removing the initialiser for the removed 'log' field). David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 4.4.99.902: s3 fails some of xtests
On Fri, Mar 04, 2005 at 08:40:55AM +0100, N?meth M?rton wrote: Mark Vojkovich ?rta: On Wed, 2 Mar 2005, Tim Roberts wrote: N?meth M?rton wrote: Hi! I've tested 4.5.0RC2 with xtest 4.0.10, see http://bugs.xfree86.org/show_bug.cgi?id=1557 for details. I've attached a test C program which always produces bad rendering using acceleration, and never if XaaNoScreenToScreenCopy is set (=without acceleration). The results are also attached. Have anyone see souch behaviour? Have anyone programers manual about 86c764/765 [Trio32/64/64V+] chip? Is it really only GXclear, GXinvert, and GXset that fail? If so, the diagnosis is pretty easy. For those three ROPs, it's not really a screen-to-screen blit at all: the source surface is not used. Most S3 chips (Savage included) fail if you attempt to use a two-operand bitblt command when the source is not involved. That's why there is an XAA flag specifically for this case. The solution is to add pXAA-ScreenToScreenCopyFlags = ROP_NEEDS_SOURCE; to the S3AccelInitXxx function at the bottom of the file. I don't believe the Trio32/64/64V+ had that problem. That was specific to the ViRGE. I'm more inclined to believe that this problem is because it's not setting: pXAA-ScreenToScreenCopyFlags = NO_TRANSPARENCY; I don't recall the the S3 driver I wrote a long time ago having that feature, and you definitely don't want to be using it if you support transparency during color expansions. The transparent blit feature is really only for chips that don't have a color expansion engine for stippling. If you want to see correct acceleration code for the old S3 chips you should dig up the old s3 code in the XFree86 3.3.x XF86_SVGA server. I wrote that years ago. I've tested the two settings using xtest 4.0.10 at color depth 16. Here are my results: pXAA-ScreenToScreenCopyFlags = ROP_NEEDS_SOURCE; = the XCopyArea tests passed pXAA-ScreenToScreenCopyFlags = NO_TRANSPARENCY; = the XCopyArea tests fails the following tests: - GXclear (6) - GXinvert (16) - GXset (21) Is there any need to set the ROP_NEEDS_SOURCE on S3 Trio64V+ and not on the other S3 chips or the ROP_NEEDS_SOURCE will work on all S3 cards? s3virge have an other driver, and uses NO_TRANSPARENCY already. (What does ROP mean, anyway?) NMarci I'll commit the patch. Thanks for following it up. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: lib/GL
On Tue, Mar 01, 2005 at 06:51:54PM -0700, Marc Aurele La France wrote: Hi. I've been auditing various builds and noticed that xc/lib/GL/mesa/drivers/x11 is never built, let alone referenced. Is this an oversight, or can this directory be deleted? It is supposed to be built and referenced when GlxBuiltInXMesa is set to YES. Although the necessary reference to it is in lib/GL/GL/Imakefile, there doesn't appear to be anything in lib/GL/Imakefile that would actually cause that directory to be built. That could be fixed. More importantly though, there is a reference to the Imakefile.inc file in that directory from Xserver/GL/mesa/GLcore/Imakefile, and that is used. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: TinyX startup
On Thu, Feb 24, 2005 at 05:24:19PM +0800, Liu Lijuan wrote: hello: Lately I am working on Xserver(TinyX). In the process, I found that tinyX startup is not very fast in embedded system. I read its startup codes and found the font initialization speeds lots of time. Do you have other suggestion to accelerate the tinyX startup? Or have some resources? A few things to look at: 1. identify exactly which parts of the font init are slow 2. minimise the set of fonts and font paths 3. rewrite (and enable) the built-in font support so that it builds in pre-processed fonts. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Wed, Feb 16, 2005 at 06:03:41PM -0500, David Dawes wrote: On Wed, Feb 09, 2005 at 11:55:58AM -0500, David Dawes wrote: On Wed, Feb 09, 2005 at 10:05:38AM +, Alan Hourihane wrote: But isn't it better to move forward than backwards ? If the result is no better, then we need to fix the problems found. Going back to an older version, and just because it builds, doesn't guarantee it's going to work any better either. I've got more faith in the current DRM CVS as people are actively working on it, rather than using an older snapshot that people could be unwilling to go back and fix if a problem was found. I'd like to see a version that is proven to build, work, and fit in with our requirements before making any final decision on this. The snapshot we currently have imported is clearly not a good one. Otherwise, going back to the version of the kernel modules that we shipped with 4.4.0 won't be too difficult, especially if the user-mode side has the level of backward compatibility that people have claimed. Is there any update on this? Since the DRM people are not able to come up with a working version, I'm rolling back to the version that we shipped with 4.4.0 as a base for 4.5.0, and I'll work from there. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 4.4.99.901: s3 fails some of xtests
On Sun, Feb 20, 2005 at 01:34:40AM +0100, Németh Márton wrote: Hi! I've downloaded XFree86 4.4.99.901 from ftp://ftp.xfree86.org/pub/XFree86/snapshots/4.4.99.901/binaries/Linux-ix86-glibc23/ and run xtest 4.0.8 against it. There was some tests which failed: XCopyArea XDrawArc XDrawArcs XSetFontPath I don't know how to see exactly what went wrong and what would be the expected result. The XDrawArc and XDrawArcs failures are expected, and are considered acceptable. The XSetFontPath problems may be configuration-related. I don't see them, and those code paths are certainly not driver-specific. Where to start debugging these failures? The XCopyArea failure looks like a real driver problem. I'd suggest starting by running just the specific tests that are failing (there's information about how to do that in the NOTES.xf86 file), and add some debugging messages to the relevant S3 accel function to trace what is happening. Thanks for doing the testing and reporting your results. The platforms I've tested on so far have shown only a few minor issues, some of which were issues with the test suite itself. The test suite issues have been addressed in xtest version 4.0.10, available at: ftp://ftp.xfree86.org/pub/XFree86/xtest/XFree86-xtest-4.0.10.tar.bz2 David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Modeline behavior changed (broken)?
On Thu, Feb 17, 2005 at 10:52:33AM -0800, Mark Vojkovich wrote:
On Wed, 16 Feb 2005, David Dawes wrote:
On Wed, Feb 16, 2005 at 06:07:43PM -0800, Mark Vojkovich wrote:
It used to be that if you specified a modeline, say 1600x1200 in
the XF86Config file, that modeline would take preference over any
internal modelines of the same name. This no longer appears to be
the case. If I have a 1600x1200 modeline in the XF86Config file,
it no longer gets used, but another mode instead (I presume the
internal mode). I have to name my mode to something else in order
to use it.
It seems like the server was changed to ignore modes placed
in the monitor section if they conflict with internal modes. Was
this change intentional?
It works correctly for me. If explicitly provided modes are not
overriding the default modes then it is a bug. Can you send your
log file?
It appears that what's happening is modes from the monitor's
edid take precedence over Section Monitor overrides. I specified
mode 1600x1200 in my SubSection Display Modes. I provided a custom
modeline in the Section Monitor:
# 1600x1200 @ 79.1 Hz, 98.9 kHz
Modeline 1600x1200 213.6 1600 1664 1856 2160 1200 1201 1204 1250
but the monitor is reporting 86 Hz, 106 kHz.
(**) NV(0): *Preferred EDID mode 1600x1200: 230.0 MHz, 106.5 kHz, 85.2 Hz
Adding the EDID modes to the set is part of the recent autoconfig enhancements.
...
(**) NV(0): Mode 1600x1200: 213.6 MHz, 98.9 kHz, 79.1 Hz
(II) NV(0): Modeline 1600x1200 213.60 1600 1664 1856 2160 1200 1201 1204
1250
I think the priority should be: Section Monitor, EDID, builtin.
But it appears that it's EDID, Section Monitor, builtin.
Yes, I agree that the modes specified explicitly in the Monitor section
should have first priority. The attached patch prevents EDID modes matching
Monitor section modes from being added to the pool, much the same way as
happens already for the built-in default/VESA modes.
Let me know how it goes.
David
Index: xf86Mode.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/hw/xfree86/common/xf86Mode.c,v
retrieving revision 1.75
diff -u -r1.75 xf86Mode.c
--- xf86Mode.c 17 Feb 2005 03:46:48 - 1.75
+++ xf86Mode.c 17 Feb 2005 21:47:19 -
@@ -1241,10 +1241,6 @@
return MODE_OK;
}
-#ifndef MODENAMESIZE
-#define MODENAMESIZE (4 + 1 + 4 + 1)
-#endif
-
/*
* xf86ValidateModes
*
@@ -1494,29 +1490,45 @@
hmax = h;
if (!haveEDIDModes) {
- new = xnfcalloc(1, sizeof(DisplayModeRec));
- new-type = M_T_DEFAULT | M_T_EDID;
- new-Clock = dt-clock / 1000;
- new-HDisplay = dt-h_active;
- new-HSyncStart = new-HDisplay + dt-h_sync_off;
- new-HSyncEnd = new-HSyncStart + dt-h_sync_width;
- new-HTotal = new-HDisplay + dt-h_blanking;
- new-VDisplay = dt-v_active;
- new-VSyncStart = new-VDisplay + dt-v_sync_off;
- new-VSyncEnd = new-VSyncStart + dt-v_sync_width;
- new-VTotal = new-VDisplay + dt-v_blanking;
- new-name = xnfalloc(MODENAMESIZE);
- snprintf(new-name, MODENAMESIZE, %dx%d,
-new-HDisplay, new-VDisplay);
- if (firstPreferred firstDetailed) {
- new-type |= M_T_PREFER;
- preferredName = new-name;
+ char *newName = NULL;
+
+ xasprintf(newName, %dx%d,
+ dt-h_active, dt-v_active);
+ if (newName !xf86ModeIsPresent(newName,
+ monitor-Modes,
+ 0, M_T_DEFAULT)) {
+ new = xcalloc(1, sizeof(DisplayModeRec));
+ if (new) {
+ new-type = M_T_DEFAULT | M_T_EDID;
+ new-Clock = dt-clock / 1000;
+ new-HDisplay = dt-h_active;
+ new-HSyncStart = new-HDisplay +
+ dt-h_sync_off;
+ new-HSyncEnd = new-HSyncStart +
+ dt-h_sync_width;
+ new-HTotal = new-HDisplay + dt-h_blanking;
+ new-VDisplay = dt-v_active;
+ new-VSyncStart = new-VDisplay +
+ dt-v_sync_off;
+ new-VSyncEnd = new-VSyncStart +
+ dt-v_sync_width
Re: DRM kernel source broken/incomplete
On Wed, Feb 09, 2005 at 11:55:58AM -0500, David Dawes wrote: On Wed, Feb 09, 2005 at 10:05:38AM +, Alan Hourihane wrote: But isn't it better to move forward than backwards ? If the result is no better, then we need to fix the problems found. Going back to an older version, and just because it builds, doesn't guarantee it's going to work any better either. I've got more faith in the current DRM CVS as people are actively working on it, rather than using an older snapshot that people could be unwilling to go back and fix if a problem was found. I'd like to see a version that is proven to build, work, and fit in with our requirements before making any final decision on this. The snapshot we currently have imported is clearly not a good one. Otherwise, going back to the version of the kernel modules that we shipped with 4.4.0 won't be too difficult, especially if the user-mode side has the level of backward compatibility that people have claimed. Is there any update on this? David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Modeline behavior changed (broken)?
On Wed, Feb 16, 2005 at 06:07:43PM -0800, Mark Vojkovich wrote: It used to be that if you specified a modeline, say 1600x1200 in the XF86Config file, that modeline would take preference over any internal modelines of the same name. This no longer appears to be the case. If I have a 1600x1200 modeline in the XF86Config file, it no longer gets used, but another mode instead (I presume the internal mode). I have to name my mode to something else in order to use it. It seems like the server was changed to ignore modes placed in the monitor section if they conflict with internal modes. Was this change intentional? It works correctly for me. If explicitly provided modes are not overriding the default modes then it is a bug. Can you send your log file? David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problem restoring console?
On Tue, Feb 15, 2005 at 10:34:16AM -0800, Mark Vojkovich wrote: On Mon, 14 Feb 2005, David Dawes wrote: On Mon, Feb 14, 2005 at 07:40:40PM -0800, Mark Vojkovich wrote: On Mon, 14 Feb 2005, Mark Vojkovich wrote: On Mon, 14 Feb 2005, David Dawes wrote: On Mon, Feb 14, 2005 at 04:00:18PM -0800, Mark Vojkovich wrote: I just updated on my dual-card system and with the update I see a problem restoring the console that I did not see previously. If I startx on the primary card and then quit, the primary card is restored correctly. However, if I startx on both cards and quit, the primary card is not restored correctly. I have a hard time imagining how it could be a driver issue since the nv driver knows nothing about the other cards in the layout (nor should it) and does not change its behavior when there is more than one card in the layout. The core server code, on the other hand, does. Have there been changes to vgahw, RAC, PCI config code, console code, etc... that may have caused this regression? Do you know approximately when this problem started? I haven't updated in a long time on that machine. I'll try to figure out when, but I'm not sure how to do that reliably. I can't tell when I last updated on this machine. Can you go back to 4.4 as a first step, or do you know it was post-4.4? It worked fine with 4.4. I built sometime after 4.4 but I'm not sure when. I tried 4.5.0 RC1 with a multi-head config using a Mach64 and i810, and didn't see any problem like this. I can try some other multi-head configs later this week. What OS are you on? It could be something specific to Linux console/vt. That quick test was on Linux. Without further information, I'd suggest trying a snapshot from the last month or so, then work backwards or forwards from there. What do the console restoration problems look like? David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problem restoring console?
On Tue, Feb 15, 2005 at 02:50:23PM -0800, Mark Vojkovich wrote:
On Tue, 15 Feb 2005, David Dawes wrote:
On Tue, Feb 15, 2005 at 10:34:16AM -0800, Mark Vojkovich wrote:
On Mon, 14 Feb 2005, David Dawes wrote:
On Mon, Feb 14, 2005 at 07:40:40PM -0800, Mark Vojkovich wrote:
On Mon, 14 Feb 2005, Mark Vojkovich wrote:
On Mon, 14 Feb 2005, David Dawes wrote:
On Mon, Feb 14, 2005 at 04:00:18PM -0800, Mark Vojkovich wrote:
I just updated on my dual-card system and with the update I see
a problem restoring the console that I did not see previously. If
I startx on the primary card and then quit, the primary card is
restored
correctly. However, if I startx on both cards and quit, the
primary card is not restored correctly. I have a hard time
imagining
how it could be a driver issue since the nv driver knows nothing
about
the other cards in the layout (nor should it) and does not change
its behavior when there is more than one card in the layout. The
core server code, on the other hand, does.
Have there been changes to vgahw, RAC, PCI config code, console
code, etc... that may have caused this regression?
Do you know approximately when this problem started?
I haven't updated in a long time on that machine. I'll try to
figure out when, but I'm not sure how to do that reliably.
I can't tell when I last updated on this machine.
Can you go back to 4.4 as a first step, or do you know it was post-4.4?
It worked fine with 4.4. I built sometime after 4.4 but I'm
not sure when.
I tried 4.5.0 RC1 with a multi-head config using a Mach64 and i810,
and didn't see any problem like this. I can try some other multi-head
configs later this week.
What OS are you on? It could be something specific to Linux
console/vt.
That quick test was on Linux. Without further information, I'd
suggest trying a snapshot from the last month or so, then work
backwards or forwards from there. What do the console restoration
problems look like?
I'm left with just a blinking cursor.
I've reproduced this with another multi-head combination. It turns out
that the i810 isn't a good test of font save/restore because it doesn't
overwrite that data during normal operation.
The problem is that the font data isn't getting saved/restored correctly,
as can be seen from the fact that running 'setfont' fixes things up. A
4.4.99.901 server with 4.4.0 modules worked fine, and I tracked the
problem down to a change to the rac module:
if (!flag) {
ENABLE;
return TRUE;
}
The problem with this optimisation is that flag is only set for
operating state requirements, not for setup state. RAC assumes that
setup state operations always need to be wrapped in multi-card
configurations. To eliminate even this wrapping, additional flag bits
would be needed to describe setup state requirements, such as access to
VGA resources for font save/restore, etc.
David
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: Problem restoring console?
On Mon, Feb 14, 2005 at 04:00:18PM -0800, Mark Vojkovich wrote: I just updated on my dual-card system and with the update I see a problem restoring the console that I did not see previously. If I startx on the primary card and then quit, the primary card is restored correctly. However, if I startx on both cards and quit, the primary card is not restored correctly. I have a hard time imagining how it could be a driver issue since the nv driver knows nothing about the other cards in the layout (nor should it) and does not change its behavior when there is more than one card in the layout. The core server code, on the other hand, does. Have there been changes to vgahw, RAC, PCI config code, console code, etc... that may have caused this regression? Do you know approximately when this problem started? David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problem restoring console?
On Mon, Feb 14, 2005 at 07:40:40PM -0800, Mark Vojkovich wrote: On Mon, 14 Feb 2005, Mark Vojkovich wrote: On Mon, 14 Feb 2005, David Dawes wrote: On Mon, Feb 14, 2005 at 04:00:18PM -0800, Mark Vojkovich wrote: I just updated on my dual-card system and with the update I see a problem restoring the console that I did not see previously. If I startx on the primary card and then quit, the primary card is restored correctly. However, if I startx on both cards and quit, the primary card is not restored correctly. I have a hard time imagining how it could be a driver issue since the nv driver knows nothing about the other cards in the layout (nor should it) and does not change its behavior when there is more than one card in the layout. The core server code, on the other hand, does. Have there been changes to vgahw, RAC, PCI config code, console code, etc... that may have caused this regression? Do you know approximately when this problem started? I haven't updated in a long time on that machine. I'll try to figure out when, but I'm not sure how to do that reliably. I can't tell when I last updated on this machine. Can you go back to 4.4 as a first step, or do you know it was post-4.4? I tried 4.5.0 RC1 with a multi-head config using a Mach64 and i810, and didn't see any problem like this. I can try some other multi-head configs later this week. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: x86 emulator bug
On Fri, Feb 11, 2005 at 08:55:16AM -, Charles Dobson wrote: Yes, thanks for pointing that out. I missed that in my haste to post. It seems that the Silicon Motion video BIOS relies on a undocumented feature of the CPU. This leaves me in a dilemma, should I post my changes to Bugzilla or not! No dilemma. I committed your changes yesterday. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: x86 emulator bug
On Thu, Feb 10, 2005 at 10:08:20AM -, Charles Dobson wrote: I am not sure if I should post this here or on bugzilla. Definitely here so that more people will see it and have a chance to comment. While trying to get a Silicon Motion SM722 video controller working with Solaris, I have discovered a problem with the emulation of the SHLD and SHRD (double precision shift) instructions of the x86 emulator. According to the Intel Pentium User Guide Vol 3, these instructions can shift upto 31 bits with both 16 and 32 bit operands. The emulator code will only work with shifts of upto 15 bits for 16 bit operands. As Tim pointed out, that behaviour is documented as undefined. However, if emulating it this way helps for that controller, then that's probably how we should do it. The file is xc/extras/x86emu/src/x86emu/prim_ops.c I have modified the two functions as below. I am not positive the flags are set correctly so would appreciated someone else to check these. Since the flags are also undefined for that case, setting them this way looks OK to me. If there are no further comments, I'll commit your changes. Thanks. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Tue, Feb 08, 2005 at 08:14:59PM -0500, David Dawes wrote: Some have said here today that the drivers can adapt to older DRM versions. That's how it should be, but I don't know if it is true or not. I've seen some things in my initial testing that may cast some doubt on it, but there were too many other variables to be certain without followup. Following up on this, if I start XFree86 with DRI enabled with an i810, on Red Hat 9 with its stock kernel and DRM module, the server gets killed by the kernel. The reason is that it tries to open up to 255 minor device nodes (vs 16 before), but some versions of the DRM have a hard limit of 16 and unfortunately don't validate the minor number before using it to index an array. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Wed, Feb 09, 2005 at 10:05:38AM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 08:14:59PM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 11:52:27PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 06:40:07PM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 11:24:43PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 06:17:50PM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 05:12:29PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:59:15AM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 04:40:42PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:32:56AM -0500, David Dawes wrote: It looks like the DRM kernel source in xc/extras/drm is broken and incomplete, especially for BSD platforms. The Linux version only appears to build for a narrow range of kernels, and this either needs to be fixed, or the minimum kernel requirements enforced in the Makefile. Perhaps we'll have to roll back to an older version that does build? I suspect pulling in a newer snapshot would be better, although it's a little more complicated now because the drm has split out support for linux 2.4 and 2.6 kernels is separate subdirectories. Does the build automatically figure out which to use based on the kernel version, and what range of kernels has it been verified on? No. Any imports/updates need to address our requirements in this regard. If we import the current DRM trunk code, there are three linux directories. 1. linux for 2.4 kernels (monolithic) 2. linux-2.6 for 2.6 kernels (monolithic) 3. linux-corefor 2.6 kernels with modular drm.ko and driver.ko and two for bsd 1. bsd monolithic 2. bsd-core modular as above The -core are the new ones going forward and which I believe has been merged in linux 2.6.11. So, for now the linux-2.6, linux and bsd directories are the ones to stick with for stability. But things are changing. There'll be necessary build tweaks to select which directories are needed. At this point in our release cycle, the priorities are: 1st: It builds/runs and is reasonably stable on a good range of platforms. 2nd: It supports as many DRI features as possible consistent with the first priority. I don't think that even changing from the existing single Linux directory to two different kernel-specific directories is appropriate at this point in our release cycle. The time for such a change was before the feature freeze. If what we have now is too broken to be fixed without major structural changes, then it will need to be rolled back. The fear is, if you roll back the DRM, then the drivers may need to be rolled back as well to support lesser features. Some have said here today that the drivers can adapt to older DRM versions. That's how it should be, but I don't know if it is true or not. I've seen some things in my initial testing that may cast some doubt on it, but there were too many other variables to be certain without followup. It would clearly be preferable to have a recent version that works. Is there a known recent stable/working version? From my point of view the fear is, updating to the latest version, adapting to its structural changes, and finding that the result is no better. But isn't it better to move forward than backwards ? If the result is no better, then we need to fix the problems found. Going back to an older version, and just because it builds, doesn't guarantee it's going to work any better either. I've got more faith in the current DRM CVS as people are actively working on it, rather than using an older snapshot that people could be unwilling to go back and fix if a problem was found. I'd like to see a version that is proven to build, work, and fit in with our requirements before making any final decision on this. The snapshot we currently have imported is clearly not a good one. Otherwise, going back to the version of the kernel modules that we shipped with 4.4.0 won't be too difficult, especially if the user-mode side has the level of backward compatibility that people have claimed. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
DRM kernel source broken/incomplete
It looks like the DRM kernel source in xc/extras/drm is broken and incomplete, especially for BSD platforms. The Linux version only appears to build for a narrow range of kernels, and this either needs to be fixed, or the minimum kernel requirements enforced in the Makefile. Perhaps we'll have to roll back to an older version that does build? David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Tue, Feb 08, 2005 at 04:40:42PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:32:56AM -0500, David Dawes wrote: It looks like the DRM kernel source in xc/extras/drm is broken and incomplete, especially for BSD platforms. The Linux version only appears to build for a narrow range of kernels, and this either needs to be fixed, or the minimum kernel requirements enforced in the Makefile. Perhaps we'll have to roll back to an older version that does build? I suspect pulling in a newer snapshot would be better, although it's a little more complicated now because the drm has split out support for linux 2.4 and 2.6 kernels is separate subdirectories. Does the build automatically figure out which to use based on the kernel version, and what range of kernels has it been verified on? What about the FreeBSD code? The current version we have is very broken, failing to build even the simplest of drivers (tdfx) on 4.10 or 5.2. Also, does the i915 driver build on BSD? It is referenced in the Makefile, but the required files are not present. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Tue, Feb 08, 2005 at 05:12:29PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:59:15AM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 04:40:42PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:32:56AM -0500, David Dawes wrote: It looks like the DRM kernel source in xc/extras/drm is broken and incomplete, especially for BSD platforms. The Linux version only appears to build for a narrow range of kernels, and this either needs to be fixed, or the minimum kernel requirements enforced in the Makefile. Perhaps we'll have to roll back to an older version that does build? I suspect pulling in a newer snapshot would be better, although it's a little more complicated now because the drm has split out support for linux 2.4 and 2.6 kernels is separate subdirectories. Does the build automatically figure out which to use based on the kernel version, and what range of kernels has it been verified on? No. Any imports/updates need to address our requirements in this regard. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Tue, Feb 08, 2005 at 11:24:43PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 06:17:50PM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 05:12:29PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:59:15AM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 04:40:42PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:32:56AM -0500, David Dawes wrote: It looks like the DRM kernel source in xc/extras/drm is broken and incomplete, especially for BSD platforms. The Linux version only appears to build for a narrow range of kernels, and this either needs to be fixed, or the minimum kernel requirements enforced in the Makefile. Perhaps we'll have to roll back to an older version that does build? I suspect pulling in a newer snapshot would be better, although it's a little more complicated now because the drm has split out support for linux 2.4 and 2.6 kernels is separate subdirectories. Does the build automatically figure out which to use based on the kernel version, and what range of kernels has it been verified on? No. Any imports/updates need to address our requirements in this regard. If we import the current DRM trunk code, there are three linux directories. 1. linux for 2.4 kernels (monolithic) 2. linux-2.6 for 2.6 kernels (monolithic) 3. linux-core for 2.6 kernels with modular drm.ko and driver.ko and two for bsd 1. bsd monolithic 2. bsd-coremodular as above The -core are the new ones going forward and which I believe has been merged in linux 2.6.11. So, for now the linux-2.6, linux and bsd directories are the ones to stick with for stability. But things are changing. There'll be necessary build tweaks to select which directories are needed. At this point in our release cycle, the priorities are: 1st: It builds/runs and is reasonably stable on a good range of platforms. 2nd: It supports as many DRI features as possible consistent with the first priority. I don't think that even changing from the existing single Linux directory to two different kernel-specific directories is appropriate at this point in our release cycle. The time for such a change was before the feature freeze. If what we have now is too broken to be fixed without major structural changes, then it will need to be rolled back. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
XFree86 4.5.0 RC1 (4.4.99.901)
The first XFree86 4.5.0 release candidate is available. Source and some binaries can be found at: ftp://ftp.xfree86.org/pub/XFree86/snapshots/4.4.99.901/ Documentation is at: http://www.xfree86.org/4.4.99.901/ Preview documentation for 4.5.0 is at: http://www.xfree86.org/~dawes/pre-4.5/ This release candidate marks the start of the intense testing phase for the 4.5.0 release. Most platform build/packaging issues should be resolved at this point, but if you run into any, let us know. The focus now is on run-time and correctness testing. Run-time testing is basically running the release candidate in your usual environment and reporting problems you find. Correctness testing consists of running the xtest suite. If you are interested in running the xtest suite, you can find the source with this release candidate. Information about how to build and run the xtest suite can be found in the test/xsuite/NOTES.xf86 file that is part of the xtest source. If you find any run-time or correctness problems, or run into any problems building or running the xtest suite, please report details here. If you haven't already done so, this release candidate would be a good time to test the XFree86 automatic configuration feature. It was first available with the 4.4.0 release, and has been improved since then. It currently works on most Linux, FreeBSD, NetBSD, OpenBSD and Solaris/ix86 platforms. You can try it out easily without affecting your existing configuration. The quickest way to do this is to run: XFree86 -autoconfig which will start up the XFree86 server without any applications. You should see the familiar X stipple background and be able to move the X cursor. You can exit this with CtrlAltBackspace. If that looks OK, try running your usual X session with: startx -- -autoconfig If you find any problems with this, please send details. The goal of the automatic configuration feature is for the XFree86 server to run in a usable form without any user intervention on a majority of platforms. It works by maximising the amount of configuration that can automatically be detected within the XFree86 server, by using an external rule-based mechanism to make the best choices of video driver and video driver options, and by providing fallbacks to ensure that the XFree86 server will run in some form in nearly all situations. The TODO list for the 4.5.0 release is: 1. Testing, testing, and more testing. 2. Update the documentation, especially the release notes. If you have updates for the documentation, send them here. 3. Resolve issues with the DRM source. 4. Did I mention testing? :-) Enjoy! David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
