Re: xfree86 emulation of VGA BIOS cards on powerpc platforms
On Thu, 2006-08-10 at 18:23 +0200, jf simon wrote: Hi, For non x86 architecture, I understand that xfree86 is able to initialize (soft boot) PCI graphic cards, by emulating the VGA BIOS extension located on the graphic card. Does x86 VGA BIOS emulation for powerPC works in xfree86? We use a IBM Maple platform (CPU is a ppc64 970FX) and would like to know if we could do it. Thanks a lot, It does work on some platforms. I'm afraid it's a case of try it and see. Alan. ___ 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 Tue, 2006-03-28 at 18:37 +0100, Barry Scott wrote: I'm testing the i945G driving a Hitachi panel that has a preferred mode of [EMAIL PROTECTED] RC2 sets the refresh to 75Hz that is not allowed by the EDID. Attached is the config created by X -configure and the X log at logverbose 8. I use 915resolution to set a slot tp 1360x768: 915resolution 58 1360 768 xrandr reports: SZ:Pixels Physical Refresh *0 1360 x 768( 720mm x 406mm ) *75 1 1024 x 768( 720mm x 406mm ) 75 2800 x 600( 720mm x 406mm ) 75 3640 x 480( 720mm x 406mm ) 75 Current rotation - normal Current reflection - none Rotations possible - normal Reflections possible - none The panel reports 1024x768 75Hz Why isn't 60Hz being used? Is the any of the timing info from the EDID being used? Quite possibly. What does the log say ? Alan. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: EDID Prefered mode problems
On Thu, 2006-01-26 at 14:31 +, 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? Barry, I think you'll find that XFree86 already adds the EDID modes. Additionally, it's more likely the driver that's ignoring CLOSEST_CLOCK rather than XFree86 too. I didn't say it was XFree86 to blame here. There's some work to fix all this up correctly and the i810 driver just makes it worse when it has complete reliance on the Video BIOS. Alan. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Does Intel 865G graphics card support gamma correction
I thought I'd replied to this, but maybe not. The current CVS for the intel driver does support gamma correction on the i865. Alan. On Thu, Jun 23, 2005 at 10:35:16AM -0700, Mark Vojkovich wrote: While i865G hardware might support gamma correction, the XFree86 drivers for it do not. I believe this is because nobody with the time or ability to add gamma correction support the driver have sufficient documentation for the i865. Mark. On Wed, 22 Jun 2005, Karthik Ramamoorthy wrote: Hi all, In my system ie Intel PC with i865G integrated graphics card, i am not able to do gamma correction. My Linux is SuSE 9.2. Is it that Intel cards does have XFree86 driver support to change gamma values. How can i do gamma correction in my system. Is it possible in Intel systems or not? Regards Karthik R ___ 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
Re: Symbol i830PrintModes unresolved (fwd)
Fixed. Alan. On Tue, May 24, 2005 at 07:44:58 +0800, Jeff Chua wrote: Latest CVS build has this problem during 'startx' ... Symbol i830PrintModes from module /usr/X11R6/lib/modules/drivers/i810_drv.o is unresolved! Changes prior to May 23 is ok. Thanks, Jeff ___ 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: 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 could be deleted. It's essentially a direct rendering X11 interface, instead of doing it over GLX. It's a useful test tool sometimes though. Alan. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: lib/GL
On Wed, Mar 02, 2005 at 08:27:46AM +, Alan Hourihane wrote: 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 could be deleted. It's essentially a direct rendering X11 interface, instead of doing it over GLX. It's a useful test tool sometimes though. Whoops, ignore that. I read xc/lib/GL/mesa/drivers/dri/x11 which is exactly what I said, but inserted a 'dri' directory in there. Alan. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: External CRT works on 1024x768 but LCD not. Please Help!!!
On Fri, Feb 18, 2005 at 03:39:28PM -0800, Bukie Mabayoje wrote: Alan Hourihane wrote: I became aware of this problem few years back (since 2003). The first time I experienced it was with a DELL laptop, and I didn't have free time then to debug it when I actually had the laptop. I going to see if I can figure the problem out (why the LCD is not working) just by reading the code. I've already done work in this area. And I've got a driver up at http://www.fairlite.demon.co.uk/intel.html if anyone wants to test it. What does this driver fix? Switching between CRT, LCD and CRT+LCD type combinations through the Fn-F7/F8 switching. Plus a few other minor fixes. Alan. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: External CRT works on 1024x768 but LCD not. Please Help!!!
Can you provide a log with that driver ? Alan. On Sat, Feb 19, 2005 at 12:57:38AM -0300, Nqnsome wrote: Hi, I tryed your driver, but could not get 1024x768 on the LCD. XFree does not see the Built-in 1024x768 mode. Thanks, S?rgio Alan Hourihane wrote: I've already done work in this area. And I've got a driver up at http://www.fairlite.demon.co.uk/intel.html if anyone wants to test it. Alan. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.8 - Release Date: 2/14/2005 ___ 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: External CRT works on 1024x768 but LCD not. Please Help!!!
Actually, From the look of your log file, the 1024x768 mode isn't supported at all on your LCD. And although your LCD is reported at 1024x768 it looks like your BIOS is broken. ModeAttributes should show 0x9b, whereas it's showing 0x9a. That first bit is dictating whether XFree86 allows the mode or not, as it's VBE's method of saying if the mode is supported in the current configuration. Have you double checked for an updated BIOS ? Alan. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: External CRT works on 1024x768 but LCD not. Please Help!!!
On Sat, Feb 19, 2005 at 08:17:07PM -0300, Nqnsome wrote: Hi Christian, Thanks for answering. Christian Zietz wrote: I still suppose that your BIOS only recognizes the LCD as a 800x600 one, while the CRT is recognized correctly as being able to display 1024x768. The Windows XP driver doesn't care about the BIOS but bypasses it. X on the other hand needs the BIOS to set the resolution because the information on how to do that without the BIOS is not publicly available. CU Christian Sorry, but what do you mean with how to do that? What kind of information is (not!) in the BIOS that tells X how to change the resolution? A function? A memory address? Something else? No. Christian is saying that the programming information is not publicly available so that the driver can bypass using the BIOS. Which is what the Windows drivers do. I am asking this because, if I have more information about what is possibly broken/missing in the BIOS, I can try to contact the manufacturer and ask for a fix. Without specific information it is difficult to get a useful answer from the manufacturer (COMPAL). Just tell COMPAL that the ModeAttributes field for bit 0 which is called 'Mode supported by hardware configuration' is not being set when asking the Video BIOS for available supported resolutions with the LFP (Local Flat Panel). The Video BIOS call is 0x4F01 with the mode set to 0x34 for 1024x768 at 8bpp, 0x45 for 1024x768 at 16bpp and 0x54 for 1024x768 at 32bpp. Alan. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: To submit graphics driver supporting for XGI Volari V5, V8, and Z7
Hi Jong, You can submit it via [EMAIL PROTECTED] or via bugzilla database at http://bugs.xfree86.org and create an attachment with the patch. Use the 'diff -u' command to create a unified diff makes it easier to see the changes you made. Thanks for your future submission, Alan. On Fri, Feb 18, 2005 at 10:26:25AM +0800, Jong Lin wrote: Hi there, Per marketing's strong demand, we plan to release source code of 2D, Video modules of Volari V5, V8, and Z7 for XFree86 4.4.0 in the near feature. According to description of XFree86.Org, we just need to submit the source code to [EMAIL PROTECTED] Is it right? I was wondering if we need to do precedent preparation before submitting to [EMAIL PROTECTED] By the way, is there any example or format to prepare source code for submitting to [EMAIL PROTECTED] ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: External CRT works on 1024x768 but LCD not. Please Help!!!
On Fri, Feb 18, 2005 at 06:15:16PM -0300, Nqnsome wrote: Thanks a lot for the explanations, but I would like to return to the question why the CRT works under 1024x768 and the LCD not. Can this be related to the VESA VBE DCC that does not work on the LCD? If you boot up on the LCD and have the 1024x768 mode as your only listed mode, also check that VertRefresh is set to 60. Does that work ? If not, post the log file. Alan. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: External CRT works on 1024x768 but LCD not. Please Help!!!
On Fri, Feb 18, 2005 at 02:11:48PM -0800, Bukie Mabayoje wrote: Nqnsome wrote: Hi, Thanks again. Alex Deucher wrote: Alex is correct. Let focus on the primary display controller on PCI:0:2:0 with Display Pipe A and Display Pipe B. In your case you can only have PipeA=CRT and PipeB=LCD (LFP). That is why you have the following information (II) I810(0): Display Info: CRT: attached: TRUE, present: TRUE, size: (800,600) (II) I810(0): Display Info: LFP (local flat panel): attached: TRUE, present: TRUE, size: (1024,768) The problem is why XFree is saying there is no active display on Pipe B (II) I810(0): No active displays on Pipe B you can use the monitorlayout option to force on the pipes. see the i810 man page. Alex Now I understand the Pipes, but is still a mistery for me why lspci sees the 0:2:1, if it is a Windows placeholder (propably because I do not understand what a placeholder is...). Regarding the No active displays on Pipe B, this probably happens because, before starting X, I disable the LCD with the keyboard sequence FN+F5. If I do not do this, the screen becomes unreadble I became aware of this problem few years back (since 2003). The first time I experienced it was with a DELL laptop, and I didn't have free time then to debug it when I actually had the laptop. I going to see if I can figure the problem out (why the LCD is not working) just by reading the code. I've already done work in this area. And I've got a driver up at http://www.fairlite.demon.co.uk/intel.html if anyone wants to test it. Alan. ___ 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: 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-core for 2.6 kernels with modular drm.ko and driver.ko and two for bsd 1. bsdmonolithic 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. Alan. ___ 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: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. Alan. ___ 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: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. 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. I've not built the BSD code for quite some time. Alan. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
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. linuxfor 2.4 kernels (monolithic) 2. linux-2.6for 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-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. Alan. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
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. Alan. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRI on i810
On Mon, Jan 31, 2005 at 07:27:51PM -0500, David Dawes wrote:
On Mon, Jan 31, 2005 at 09:20:06AM +, Alan Hourihane wrote:
On Sun, Jan 30, 2005 at 08:11:38PM -0500, David Dawes wrote:
Has anyone tried DRI on an i810 with the current tree? I get a
ring buffer lockup almost immediately after running glxgears. This
is with the current i810 DRM module built and loaded against an
otherwise stock 2.4.24 kernel.
I've not tried it for a while, but I might be able to give it a go.
I'm also getting lockups with the i810 in 2D with DRI not enabled on at
least one system. I haven't narrowed this down yet.
I think this is down to the change I made moving LpRing to an allocated
structure.
The patch below should correct things.
Alan.
Index: i810_driver.c
===
RCS file:
/home/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/i810/i810_driver.c,v
retrieving revision 1.109
diff -u -r1.109 i810_driver.c
--- i810_driver.c 9 Jan 2005 20:47:19 - 1.109
+++ i810_driver.c 1 Feb 2005 20:11:01 -
@@ -2069,6 +2069,13 @@
pI810 = I810PTR(pScrn);
hwp = VGAHWPTR(pScrn);
+ pI810-LpRing = xcalloc(sizeof(I810RingBuffer),1);
+ if (!pI810-LpRing) {
+ xf86DrvMsg(pScrn-scrnIndex, X_ERROR,
+ Could not allocate lpring data structure.\n);
+ return FALSE;
+ }
+
miClearVisualTypes();
/* Re-implemented Direct Color support, -jens */
@@ -2487,6 +2494,9 @@
*/
xf86GARTCloseScreen(scrnIndex);
+ xfree(pI810-LpRing);
+ pI810-LpRing = NULL;
+
pScrn-vtSema = FALSE;
pScreen-CloseScreen = pI810-CloseScreen;
return (*pScreen-CloseScreen) (scrnIndex, pScreen);
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: DRI on i810
On Sun, Jan 30, 2005 at 08:11:38PM -0500, David Dawes wrote: Has anyone tried DRI on an i810 with the current tree? I get a ring buffer lockup almost immediately after running glxgears. This is with the current i810 DRM module built and loaded against an otherwise stock 2.4.24 kernel. I've not tried it for a while, but I might be able to give it a go. Separately, the ARGB cursor allocation fails, but presumably that requires an updated agpgart module since the stock one fails for AGP_PHYS_MEMORY requests larger than one page? Indeed it does need a later version of agpgart that's available in later 2.4 and 2.6 kernels. Alan. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 4.5.0 release schedule
On Mon, Jan 10, 2005 at 11:00:22PM -0500, David Dawes wrote: On Mon, Jan 10, 2005 at 08:43:18AM +, Matthias Scheler wrote: On Sat, Jan 08, 2005 at 07:37:29PM -0500, David Dawes wrote: The schedule for the next XFree86 release -- 4.5.0 is as follows: 26 January 2005feature freeze late February 2005 code freeze early-mid March 2005 release Is a list of changes for this release already available somewhere? Most changes are listed in the changelog file in the source tree. There are some exceptions: for example, the latest Mesa/DRI updates, which should probably be added to the changelog. Sorry, I thought I'd done that. I'll fix it now. Alan. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Rootless documentation
On Wed, Jun 30, 2004 at 10:28:06AM -0700, Torrey Lyons wrote: I've written up some documentation on the generic rootless layer in Xserver/miext/rootless. What is the appropriate place and format for this kind of documentation in the tree? For now, I'd probably stick it into the same directory as the code. The other option is to use doxygen and document the source code itself. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: cvs compile failed
On Tue, Jun 29, 2004 at 02:18:10AM +0200, Thomas Winischhofer wrote: David Dawes wrote: On Mon, Jun 28, 2004 at 05:44:14PM +0100, Dr Andrew C Aitchison wrote: On Mon, 28 Jun 2004, Andrew C Aitchison wrote: CVS compile works for me since this change revision 3.479 date: 2004/06/23 16:58:39; author: dawes; state: Exp; lines: +2 -2 Turn XItsyServer off by default (it doesn't build). in xc/config/cf/xfree86.cf You probably need to do a make World (or at least make Makefiles) in the top level to get this change to take effect. ... However make install fails with install -c -m 0444 SecurityPolicy /usr/X11R6/lib/X11/xserver/SecurityPolicy install: cannot stat `SecurityPolicy': No such file or directory make[5]: *** [install] Error 1 make[5]: Leaving directory `/home/XFree86/4.4/std/xc/programs/Xserver/Xext/tiny' Work-around appears to be make -k install Speaking of build failures with the current CVS, some recent changes to the sis driver result in a build failure for the static server: ../../programs/Xserver/hw/xfree86/drivers/libdriver.a(sis_drv.o): In function `SISDRIScreenInit': sis_drv.o(.text+0x4ecae): undefined reference to `DRICreatePCIBusID' Yeah, I know. Fix in the queue. Isn't Alan to update the DRI stuff to current anytime soon? We're lagging a little behind the DRI CVS, but if there's build problems Thomas, please go ahead and don't wait for me and pull what you need in. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Voyager CF for Xfbdev
On Tue, Jun 22, 2004 at 10:53:59AM +0530, Suresh wrote: Hi, I am using Voyager CF card for exporting display to the VGA monitor my handheld runs Xfbdev. Can any one tell me how to configure. The Voyager CF isn't supported by Xipaq. As for Xfbdev, it would require a kernel driver for the Voyager CF, and I don't believe one exists for that either. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i830 screen black after resume on 4.4
Have you tried adding Option VBERestore false Alan. On Mon, Apr 12, 2004 at 10:37:34AM +0800, Jeff Chua wrote: I've checked the CVS, and found that the i810 driver up to 4_3_99_9 works after resume, but anything after 4_3_99_9 has the same problem of displaying black screen after apm resume. Is there anyone else having this problem? I'm running on IBM X30 ThinkPad. Thanks, Jeff On Sat, 10 Apr 2004, Jeff Chua wrote: still doesn't work. But why _old_ version works better than new one? Usually newer version should works better, but in this case, it looks like going one step back ... Thanks, Jeff [ [EMAIL PROTECTED] ] On Fri, 9 Apr 2004, Alex Deucher wrote: --- Jeff Chua [EMAIL PROTECTED] wrote: I'm getting black screen after power resume on version 4.4.99.2. I can see the mouse, all window frames, but black contents. No such problem with 4.3.0. Tested on linux 2.4.26-rc2 and 2.6.5 I'm using apm to resume, and with 4.3.0, it works fine. You might try changing the VT prior to suspending if you are not already. Alex Thanks, Jeff [ [EMAIL PROTECTED] ] __ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: S3 driver bug
On Fri, Apr 09, 2004 at 05:44:31PM +0200, root wrote: I think there's a bug in the acceleration code of the s3 driver. When scrolling (with acceleration enabled), only parts of the screen that become newly visible really get visible, the screen doesn't scroll up. XaaNoScreenToScreenCopy option solves it. What version of XFree86 are you using ? Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Intel 82852 Xv
On Wed, Apr 07, 2004 at 09:28:39AM -0600, Mark Cuss wrote: Hi All I have a laptop with an Intel 82852/855GM Integrated graphics chipset. The machine is running RedHat 9 with the new 4.4.0 X Server. I'd like to use the XVideo extension on the machine, but xvinfo reports that no adaptors are present. The X server log file says: I810: Disabling Xv because the overlay register buffer allocation failed So, this looks like it may be the problem, but I'm no X server expert when it comes time to solve it... Is it possible to make Xv work on this chipset? If anyone has any ideas I'd appreciate them... Mark, It'd be good to get your log file from /var/log/XFree86.0.log to see why the allocation failed. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Intel 82852 Xv
Mark, Basically, it looks like you are out of video memory because you have set VideoRAM to 16384 in your config file. Bump that up to 32768, and try again. Alan. On Wed, Apr 07, 2004 at 09:37:40AM -0600, Mark Cuss wrote: Hi Alan The log file is attached. Mark - Original Message - From: Alan Hourihane [EMAIL PROTECTED] To: Mark Cuss [EMAIL PROTECTED] Cc: X Developers List [EMAIL PROTECTED] Sent: Wednesday, April 07, 2004 9:33 AM Subject: Re: Intel 82852 Xv On Wed, Apr 07, 2004 at 09:28:39AM -0600, Mark Cuss wrote: Hi All I have a laptop with an Intel 82852/855GM Integrated graphics chipset. The machine is running RedHat 9 with the new 4.4.0 X Server. I'd like to use the XVideo extension on the machine, but xvinfo reports that no adaptors are present. The X server log file says: I810: Disabling Xv because the overlay register buffer allocation failed So, this looks like it may be the problem, but I'm no X server expert when it comes time to solve it... Is it possible to make Xv work on this chipset? If anyone has any ideas I'd appreciate them... Mark, It'd be good to get your log file from /var/log/XFree86.0.log to see why the allocation failed. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Intel 82852 Xv
On Wed, Apr 07, 2004 at 01:06:55PM -0600, Mark Cuss wrote: Hello again I have an application running on this machine that decodes MPEG-2 into a window and then draws overlays on top of the video using a colorkey. This works on other hardware combinations (ie - an Intel 810, anything nVidia, etc), but on this machine the XvPutImage that performed by the MPEG-2 encoder and the draw commands for the overlays fight with each other, causing a blinking effect... I've seen this before on the SMI chip, and one of my co-workers modified the X server to fix it for me - it had something to do with the X server and the driver not negotiating the YUV format correctly - something about the YUV data not being drawn into the overlay buffer - sorry - I just can't remember the nitty gritty details. Does anybody know if and how this problem could be addressed? Jump into the driver Mark, and take a look. Without nitty gritty details and sample applications and videos there may not be a lot others can do. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
Mark, What's the current status of the new xaa ?? Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Xinerama xtest
I remember that a couple of extra tests failed with Xinerama enabled. The ones I'm seeing are XCopyArea and XCopyPlane. Are these the ones that are expected to fail - Mark V. ? Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Multiple Monitors
I'm looking to enhance the parser in XFree86 so that a lot of redundant code in the current drivers that implement the 'mergedfb' mode can be eliminated such that they don't have to do all the monitor munging in the driver. So here's two variants of the modifications to the XF86Config I'm thinking of, and both would remove the current 'Monitor' keyword from the Screen Section, in favour of the SubSection keyword being the actual monitor it's referencing. I've already started poking around the parser to implement this, but I thought I'd ask for comments first before taking it too far, and to ask for possible enhancements that others can think of too. Option 1 Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 SubSection Monitor0 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection SubSection Monitor1 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection EndSection Or, Option 2. Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 SubSection Monitor0 Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Monitor0 Depth 24 Modes1024x768 800x600 640x480 EndSubSection SubSection Monitor1 Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSection Comments ? Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Mon, Mar 01, 2004 at 10:10:40PM +, Alan Hourihane wrote: I'm looking to enhance the parser in XFree86 so that a lot of redundant code in the current drivers that implement the 'mergedfb' mode can be eliminated such that they don't have to do all the monitor munging in the driver. So here's two variants of the modifications to the XF86Config I'm thinking of, and both would remove the current 'Monitor' keyword from the Screen Section, in favour of the SubSection keyword being the actual monitor it's referencing. To add to this, we'd probably need to add a keyword 'Monitor' into the Device Section, and be able to do something like this Section Device Identifier Videocard0 VendorName Vendor BoardName RADEON 8500 Monitor Monitor0,Monitor1 Driver radeon EndSection Then the driver can see that Monitor0 is primary and Monitor1 is secondary and so on. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Mon, Mar 01, 2004 at 02:57:50PM -0800, Alex Deucher wrote: --- Alan Hourihane [EMAIL PROTECTED] wrote: I'm looking to enhance the parser in XFree86 so that a lot of redundant code in the current drivers that implement the 'mergedfb' mode can be eliminated such that they don't have to do all the monitor munging in the driver. So here's two variants of the modifications to the XF86Config I'm thinking of, and both would remove the current 'Monitor' keyword from the Screen Section, in favour of the SubSection keyword being the actual monitor it's referencing. I've already started poking around the parser to implement this, but I thought I'd ask for comments first before taking it too far, and to ask for possible enhancements that others can think of too. I like Option 1. but either is ok with me. Also, FWIW, a lot of the other mergedfb code could/should be moved into a general mergedfb lib. Stuff like pseudo-xinerama could be folded into the real xinerama extension. some of this work may already be done for the OSX port. Indeed. So I'd let to get this first step of modifying the config file out of the way so all the other pieces can drop into place. Also how would clone modes and head orientation be handled in this model? Perhaps a clone mode of each supportable res on each monitor would be automatically added? I'm not sure what the best way to handle that is. Actually, you bring up a good point with orientation, and it's making me rethink a little. Maybe we need to be a little more radical with the changes and change the ServerLayout to accept Monitor configurations instead of Screen sections as essentially that's how it's really tied down. I'm gonna ponder on this some more, but I'd love to hear any furthur comments. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Monitors
On Mon, Mar 01, 2004 at 04:11:02PM -0800, Mark Vojkovich wrote: And please don't break binary compatibility with drivers who parse the current Monitor info in the ScrnInfoRec. Absolutely, that is a main priority, as is allowing the new XFree86 server to still parse older XF86Config files. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
On Mon, Mar 01, 2004 at 04:19:21PM -0800, Mark Vojkovich wrote: The current XAA has functions starting with XAA and header files starting with xaa. To avoid namespace pollution, the second implementation of XAA will need a different namespace. It seems good to avoid calling it anything with a '2' in the name. I'm leaning towards Xaa for the functions and header files. Any concerns? That'll be bad for those case-insensitive systems. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XAA2 namespace?
On Mon, Mar 01, 2004 at 04:19:21PM -0800, Mark Vojkovich wrote: The current XAA has functions starting with XAA and header files starting with xaa. To avoid namespace pollution, the second implementation of XAA will need a different namespace. It seems good to avoid calling it anything with a '2' in the name. I'm leaning towards Xaa for the functions and header files. Any concerns? So, based on the case problem... I'd go with Xaa_Line.c instead of the current xaaLine.c and you can still use Xaa() for the functions. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver
On Tue, Feb 24, 2004 at 01:37:27PM +0100, Egbert Eich wrote: Christian, thank you for the investigation. It proves that we are not to blame. It remains to see what should be done about it. Disabling the offending function by default for all future doesn't seem to be a good idea as the information retreived thru this function may be helpful when people send in their logs with their bug reports. I'd therefore suggest to enable it and provide information on the web and in the man page how the hang can be avoided if somebody encounters it. Egbert, We could leave the option in, but enable it by default, so that this information is displayed, and allow people to turn it off if it hangs. That might be better. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver
On Mon, Feb 23, 2004 at 07:29:32PM +0100, Christian Zietz wrote: Hi, Alan Hourihane schrieb: Is there a string 'DELL' or similar in the BIOS that we can use the function xf86ReadBIOS() to detect this buggy BIOS and skip using this function call in this case ? No, there is no reference to Dell in the BIOS. I'm not even sure if they configure the BIOS. I just know that there is the possibility to do so and that the faulty table is in an area where some values can be configured by the OEM. So it doesn't need to be a bug introduced by Dell, it's just one possible explanation. No, but currently we've only had reports of people with a Dell BIOS complain of problems. But I suppose that all computers made by Dell affected by this bug use BIOS build 3066. So you could scan for 3066Intel(r), although I don't think this would be a good idea. Dell could release a BIOS update or other computers from other companies with a different build number could be affected, too. Right, so a combination of the build number and something else would nail it down furthur. So, why not continue to use a configuration option? I don't see any problems caused by not calling this particular function. I don't mind leaving the option in, but it's nice to be able to print out the detected monitor information for those BIOS' that actually work. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver - solved
On Fri, Feb 20, 2004 at 12:33:41PM +0100, Alain Poirier wrote: Le vendredi 20 Février 2004 01:33, Alan Hourihane a écrit : Alain, Can you try the int10 emulator ? To do this, (re)move this file out of the way. /usr/X11R6/lib/modules/linux/libint10.a Then XFree86 will use /usr/X11R6/lib/modules/libint10.a Which is the emulator. Does it still lockup with that BIOS call ? I tried and got the exact same lockup. O.k. Thanks. I committed a patch which turns this BIOS call off by default and it can be turned back on again with the option DisplayInfo. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver - solved
On Thu, Feb 19, 2004 at 11:17:03PM +0100, Alain POIRIER wrote:
Hi,
Christian Zietz writes:
Hi,
as developer of 855patch I get a lot of feedback from people using
XFree86 on computers with i855GM graphics.
It seems like new notebooks by Dell feature a new video BIOS from Intel
(iirc Build 3066) which finally implements the int 0x10 0x5f11 function
to set the amount of video RAM and thus making 855patch obsolete.
But the i810-driver refuses to work on systems with that BIOS version. I
had several independent reports of users who just get a completely green
screen when starting XFree86. I had a look on a log file and found
nothing unusual. The XFree86 VESA driver however works but just in low
resolutions/color depths as there is no way to allocate more video RAM
there.
As I've been absent of this list: Is this already a known issue?
I haven't heared anyting about this issue yet.
The first question that comes to my mind is:
What happens if a low resolution mode that works with VESA
is set on the i8xx driver?
Egbert.
I've got this problem with the new Dell 510m model : with the normal i810
driver, we've got only a total green screen.
The problem comes from the call to INT 10h, 0x5f64 in the
GetDisplayInfo() function. It never returns.
As this function is only informative, I commented out its call in
I830DetectDisplayDevice() (XFree86 4.3.0.1) :
...
static Bool
I830DetectDisplayDevice(ScrnInfoPtr pScrn)
{
I830Ptr pI830 = I830PTR(pScrn);
int pipe, n;
DisplayType i;
#if 0
for (i = 0; i NumKnownDisplayTypes; i++) {
if (GetDisplayInfo(pScrn, 1 i, pI830-displayAttached[i],
pI830-displayPresent[i],
pI830-displaySize[i].x2,
pI830-displaySize[i].y2)) {
xf86DrvMsg(pScrn-scrnIndex, X_INFO,
Display Info: %s: attached: %s, present: %s, size:
(%d,%d)\n, displayDevices[i],
BOOLTOSTRING(pI830-displayAttached[i]),
BOOLTOSTRING(pI830-displayPresent[i]),
pI830-displaySize[i].x2, pI830-displaySize[i].y2);
}
}
#endif
pI830-configuredDevices = GetDisplayDevices(pScrn);
if (pI830-configuredDevices == -1) {
xf86DrvMsg(pScrn-scrnIndex, X_INFO,
Failed to detect active display devices\n);
return FALSE;
}
Alain,
That's good to know. This call to GetDisplayInfo isn't strictly needed,
but it's useful information to find out about the attached displays.
It's probably wise if we make this an option in the driver and turn
it off by default.
Alan.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: i855GM: New BIOS breaks i810-driver - solved
Alain, Can you try the int10 emulator ? To do this, (re)move this file out of the way. /usr/X11R6/lib/modules/linux/libint10.a Then XFree86 will use /usr/X11R6/lib/modules/libint10.a Which is the emulator. Does it still lockup with that BIOS call ? Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: A error when compiling XFree864.2 on SELS 8.2 on AMD64 system
On Fri, Feb 13, 2004 at 10:58:38AM +0800, Yukun Chen wrote: Hi All For some reasons, I have to compile XFree864.2 on SELS 8.2(64bit) with AMD64bit CPU. But when I run make WorldWorld.log on the specific dir, I just get the error message in my World.log file as follows: gcc: cannot specify -o with -c or -S and multiple compilations make[2]: ** [imake.o] Error 1 make[2]: Leaving directory '/xfree86420_release/config/imake make[1]: *** [imake.bootstrap] Error 2 make[1]: Leaving directory '/xfree86420_release' make: *** [World] Error 2 The XFree864.2 source packages are gotten from xfree86.org and can be built successfully on other OS such as Redhat. Also, I have ever tried the latest code of XFree864.2 but failed to achieve. Meanwhile, I searched for it in google but the way taught in such articles dosenot work. Finally , the version of gcc is 3.3 Can anybody be kind to give some ideas for it? Even if you fix the build problem above, your going to run into trouble, as the 4.2 code doesn't have support for the x86_64 architecture of the AMD64. I guess it may work in it's 32bit mode though, but not having an AMD64 platform - I really don't know. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Latest fixes from DRI Project
On Tue, Feb 10, 2004 at 06:20:25PM -0800, Torrey Lyons wrote: At 10:11 AM -0800 1/28/04, Alan Hourihane wrote: Log message: 778. Fix Multitexture problems with vertex arrays and indirect rendering (Bugzilla #1092, DRI Project). 777. Fix SecondaryColor FogColor when indirect rendering (Bugzilla #1091, DRI Project). These fixes have the side effect of breaking GLX on Mac OS X. The problem is the addition of new server side dependencies on glPointParameteri, glPointParameteriv, glSampleMaskSGIS, glSamplePatternSGIS. Mac OS X instead uses glPointParameteriNV and glPointParameterivNV and GL_SGIS_multisample is not supported. I can fix these by substituting the glPointParameter*NV calls and removing the calls to the glSample*SGIS functions as shown in the patch below. Note the server still says it supports the glx extension GLX_SGIS_multisample. Should I add an #ifdef to glxscreens.c as well to remove claiming this extension? Any other comments? Your changes seem reasonable Torrey, go ahead. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: GL_VERSION string fix
On Tue, Feb 10, 2004 at 10:33:24PM -0500, David Dawes wrote: Just using atof() should work. Or better, add __glXAtof() to glx_ansic.h. Your right David. I should allow time for testing next time :-) committed. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: GL_VERSION string fix
On Tue, Feb 10, 2004 at 02:34:54PM -0800, Torrey Lyons wrote:
At 3:46 PM -0800 2/9/04, Alan Hourihane wrote:
CVSROOT: /home/x-cvs
Module name: xc
Changes by: [EMAIL PROTECTED] 04/02/09 15:46:31
Log message:
797. Fix GL_VERSION string for indirect rendering (Bugzilla
#1147, DRI Project)
Modified files:
xc/programs/Xserver/hw/xfree86/:
CHANGELOG
xc/lib/GL/glx/:
glxclient.h glxcmds.c single2.c
xc/programs/Xserver/GL/glx/:
glxext.h glxscreens.c single2.c single2swap.c
This fix breaks the build when the module loader is not used because
it introduced dependence on xf86atof() in single2.c:
--- single2.c 6 Jun 2001 19:00:15 - 1.6
+++ single2.c 9 Feb 2004 23:46:31 - 1.7
@@ -331,18 +340,43 @@
}
string = buf;
}
+else if ( name == GL_VERSION ) {
+ if ( xf86atof( string ) xf86atof( GLServerVersion ) ) {
+ buf = __glXMalloc( __glXStrlen( string )
...
Should this be #ifdef'ed for IN_MODULE, or is there a more elegant
way to handle this.
Yes, I think that's the way to do it, as most of mesa does this too.
Here's the patch I committed.
Alan.
Index: single2.c
===
RCS file: /home/x-cvs/xc/programs/Xserver/GL/glx/single2.c,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- single2.c 9 Feb 2004 23:46:31 - 1.7
+++ single2.c 10 Feb 2004 22:54:15 - 1.8
@@ -341,7 +341,11 @@
string = buf;
}
else if ( name == GL_VERSION ) {
+#if defined(XFree86LOADER) defined(IN_MODULE)
if ( xf86atof( string ) xf86atof( GLServerVersion ) ) {
+#else
+ if ( atof( string ) atof( GLServerVersion ) ) {
+#endif
buf = __glXMalloc( __glXStrlen( string )
+ __glXStrlen( GLServerVersion )
+ 3 );
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: g_render.c needs a paren
On Thu, Feb 05, 2004 at 11:21:32AM -0700, Terry R. Friedrichsen wrote:
Building on FreeBSD/Alpha version 5.2 with gcc 3.3.3:
In building the world from a Wednesday morning CVS update, g_render.c
in xc/programs/Xserver/GL/glx failed to compile. The root problem
was a missing right paren, fixed by the patch included below.
This was fixed a few days ago.
But, thanks anyway Terry,
Alan.
cut here-
*** g_render.c.dist Wed Jan 28 11:11:50 2004
--- g_render.cWed Feb 4 09:50:41 2004
***
*** 83,89
*/
# define GLX_DO_ALIGN_MAGIC(count, type) \
do { if ( (sizeof(type) == 8) ((unsigned long)(pc) 7)) { \
! __GLX_MEM_COPY(pc-4, pc, (count * sizeof( type ) ); \
pc -= 4; \
} } while( 0 )
#else
--- 83,89
*/
# define GLX_DO_ALIGN_MAGIC(count, type) \
do { if ( (sizeof(type) == 8) ((unsigned long)(pc) 7)) { \
! __GLX_MEM_COPY(pc-4, pc, (count * sizeof( type ) )); \
pc -= 4; \
} } while( 0 )
#else
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: i830 crash
On Thu, Feb 05, 2004 at 08:57:47PM +0100, David Gómez wrote: Hi all ;), I got an X crash with X 4.3.0, here is the error log. By the way, are there many bugfixes in the i830 driver for the upcoming 4.4.0 release? Maybe i'm asking for a problem already fixed in CVS... You should try it as there have been some reports that this has been fixed for them. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: help new Developer
On Mon, Feb 02, 2004 at 06:34:40PM +1300, dave wrote: Hi I have just go my computers up and running and am ready to Start my X11 driver I have downloaded the latest dev-4.3.99.902 The drivers directory name will be nvxf So can some one give a quick start help about how to enter my driver In the tree and get it started ? What hardware does nvxf support Dave ? Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: help new Developer
On Mon, Feb 02, 2004 at 11:35:23PM +1300, dave wrote: - Original Message - From: Alan Hourihane [EMAIL PROTECTED] To: dave [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, February 02, 2004 10:50 PM Subject: Re: help new Developer On Mon, Feb 02, 2004 at 06:34:40PM +1300, dave wrote: Hi I have just go my computers up and running and am ready to Start my X11 driver I have downloaded the latest dev-4.3.99.902 The drivers directory name will be nvxf So can some one give a quick start help about how to enter my driver In the tree and get it started ? What hardware does nvxf support Dave ? Alan. its a DMA based driver for NVIDIA cards NV04 - NVxx and also has a kernel module (resource manager) Does it provide any benefit over the current 'nv' driver ? Speed ? Linux-only ? Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: help new Developer
On Tue, Feb 03, 2004 at 12:38:16AM +1300, dave wrote: - Original Message - From: Alan Hourihane [EMAIL PROTECTED] To: dave [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, February 02, 2004 11:39 PM Subject: Re: help new Developer On Mon, Feb 02, 2004 at 11:35:23PM +1300, dave wrote: - Original Message - From: Alan Hourihane [EMAIL PROTECTED] To: dave [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, February 02, 2004 10:50 PM Subject: Re: help new Developer On Mon, Feb 02, 2004 at 06:34:40PM +1300, dave wrote: Hi I have just go my computers up and running and am ready to Start my X11 driver I have downloaded the latest dev-4.3.99.902 The drivers directory name will be nvxf So can some one give a quick start help about how to enter my driver In the tree and get it started ? What hardware does nvxf support Dave ? Alan. its a DMA based driver for NVIDIA cards NV04 - NVxx and also has a kernel module (resource manager) Does it provide any benefit over the current 'nv' driver ? Speed ? Linux-only ? yes Using DMA for GR commands and all data transfers will be a lot faster and more efficient The driver fully utilizes the NV architecture I will be doing the 3D OpenGl part and VIDEO in Also it works in a completely deferent way The client (NVXF) sends commands to the NV chip thou channel's DMA or PIO these Channel are allocated by the kernel module amd are protected by the NV chip its self So a local error will not bring down the whole system Also functions like sleep process until commands is are finished using NOTIFY can be used Grate for compatibility, as the client only needs to concern its self with NV commands and not the chip IO so NVXF for NV04 will work on a NV15 And it is something I really won't to do :) Is it something that could be integrated with the current 'nv' driver as this would be the third driver to support NVIDIA cards. i.e. NVIDIA's own binary driver, the 'nv' driver and now this. If your going to support the DRI (for 3D) then it'd be great to integrate that code into the existing 'nv' driver. If that's the case, then getting your driver modifications into the DRI project would be wise. I suggest subscribing to the dri-devel lists at sourceforge. Also, utilizing the DRM kernel module layer would also be good for the kernel module. And if you are doing something more in your kernel module, it might be possible to fold your changes into other driver modules to benefit. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] radeon bugs
On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote: There are quite a few Radeon-related bugs still outstanding in bugs.xfree86.org, including several related to DRI lockups. Has anyone followed them up? David, I suspect not with XFree86's DRI drivers still being based on Mesa 4.0.4, and the DRI developers aren't tracking Mesa 4.0.x anymore. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] radeon bugs
On Tue, Jan 27, 2004 at 02:21:42PM -0500, David Dawes wrote: On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote: On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote: There are quite a few Radeon-related bugs still outstanding in bugs.xfree86.org, including several related to DRI lockups. Has anyone followed them up? David, I suspect not with XFree86's DRI drivers still being based on Mesa 4.0.4, and the DRI developers aren't tracking Mesa 4.0.x anymore. We are at Mesa 5.0.2. Doesn't the DRI project maintain a Mesa 5.0.x-based stable branch of some sort? Whoops, sorry I meant to say 5.0.2. It's moved to Mesa 6.0 now, but I don't believe there's anyone maintaining a stable 5.0.2 branch. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: How can we XGI share our Linux 2D driver with the open source community? Thanx
On Mon, Jan 12, 2004 at 03:39:22PM +0800, Yukun Chen wrote: Hi All I am a developer from XGI Technology which is a new company stem from graphic dpt. of Trident and graphic dpt. of Sis. Now we want to share our linux 2D driver with open source community. Then what should we do? Pls give some advice or suggestions. Please send all submissions through our bugzilla interface at http://bugs.xfree86.org and use the attachment features to attach your patch/driver. Additionally mark the submission as an enhancement. The CVS committers will pick that up and make any suggestions related to it and later commit the code. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Proper attribution of patches
On Tue, Dec 23, 2003 at 02:02:20PM -0500, Thomas Dickey wrote: On Tue, 23 Dec 2003, Harold L Hunt II wrote: The following CVS commit, made by Thomas Dickey, has no indication that Thomas was either a) not involved at all in the patch or b) that Thomas found Ralf Habacker's patch and committed a modified version of that patch. The CVS log message says: fixes for _XtInherit on cygwin. The hw/xfree86/CHANGELOG files says: XFree86 4.3.99.903 (xx December 2003) + 699. Fixes to build/run on cygwin (Thomas Dickey). I know that this patch was based at least in part (if not entirely) on Ralf Habacker's patch for the same, since it includes a more than twenty line comment from Ralf along with his name at the bottom: http://cvsweb.xfree86.org/cvsweb/xc/lib/Xt/Initialize.c.diff?r1=3.21r2=3.22f=h I'm aware of that. Your commit didn't mention this either. Do you have point? Thomas, If you did get this code directly from Cygwin/X's tree then I'd of expected at least the credit to be apportioned to Harold at the very least, rather than putting your name against it. Ralf's name could have been corrected later, with a follow email from Harold. It's a simple change to put that right in the CHANGELOG. So I'll do that. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Guaranteed Server crash with 4.4.0 (RC1)
On Wed, Dec 17, 2003 at 03:08:03PM -0800, Mark Vojkovich wrote: I don't think it's as bad as you think. It looks to me like this comes about due to a difference in the Shm protocol. Going against convention, xShmPutImageReq has an unsigned value for the src X and Y location. All other primitive have signed values. I think the correct behavior is probably to clamp the source X and Y in ProcShmPutImage function to the unsigned 15 bit coordinate system. Can somebody try that to see if it fixes the problem? Actually, it doesn't fix it. And I've backed out that patch. Stephen uploaded another test app which shows that even with srcX/Y as 0 and a negative dstX/Y parameter can still crash the server. It looks like a bug in the way fb uses deltas whereas I've tested the original cfb code and it works fine. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Guaranteed Server crash with 4.4.0 (RC1)
Looking at ProcShmGetImage() there's a bunch of checking for out-of-bounds
coordinates, but ProcShmPutImage() lacks this checking.
Is this patch reasonable or too much (it does fix the problem) but I'm
wondering if the bounds are too strict for PutImage ?
Alan.
Index: shm.c
===
RCS file: /X11R6/x-cvs/xc/programs/Xserver/Xext/shm.c,v
retrieving revision 3.40
diff -u -r3.40 shm.c
--- shm.c 17 Nov 2003 22:20:27 - 3.40
+++ shm.c 18 Dec 2003 14:17:07 -
@@ -815,6 +815,34 @@
REQUEST_SIZE_MATCH(xShmPutImageReq);
VALIDATE_DRAWABLE_AND_GC(stuff-drawable, pDraw, pGC, client);
VERIFY_SHMPTR(stuff-shmseg, stuff-offset, FALSE, shmdesc, client);
+if (pDraw-type == DRAWABLE_WINDOW)
+{
+ if( /* check for being viewable */
+!((WindowPtr) pDraw)-realized ||
+ /* check for being on screen */
+ pDraw-x + stuff-dstX 0 ||
+pDraw-x + stuff-dstX + (int)stuff-srcWidth pDraw-pScreen-width ||
+ pDraw-y + stuff-dstY 0 ||
+ pDraw-y + stuff-dstY + (int)stuff-srcHeight pDraw-pScreen-height ||
+ /* check for being inside of border */
+ stuff-dstX - wBorderWidth((WindowPtr)pDraw) ||
+ stuff-dstX + (int)stuff-srcWidth
+ wBorderWidth((WindowPtr)pDraw) + (int)pDraw-width ||
+ stuff-dstY -wBorderWidth((WindowPtr)pDraw) ||
+ stuff-dstY + (int)stuff-srcHeight
+ wBorderWidth((WindowPtr)pDraw) + (int)pDraw-height
+)
+ return(BadMatch);
+}
+else
+{
+ if (stuff-dstX 0 ||
+ stuff-dstX+(int)stuff-srcWidth pDraw-width ||
+ stuff-dstY 0 ||
+ stuff-dstY+(int)stuff-srcHeight pDraw-height
+ )
+ return(BadMatch);
+}
if ((stuff-sendEvent != xTrue) (stuff-sendEvent != xFalse))
return BadValue;
if (stuff-format == XYBitmap)
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: 4.4 release status
On Wed, Dec 17, 2003 at 11:59:00PM -0500, David Dawes wrote: I've been catching up on the 4.4 RC1 test/bug reports after being out of action for the last few days. Judging from the reports coming in both here and in bugzilla, there's a good amount of testing happening, which is great. Some serious bugs and regressions are being found and fixed. I have what look like some xtest regressions that I haven't had the time to follow up yet too. These xtest regressions are in XDrawString*() ?? I think I know what this is. The patch I committed to fbgc.c, which I'm looking at now. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.4 release status
On Thu, Dec 18, 2003 at 10:19:47AM -0500, David Dawes wrote: I did get lots of spurious results with the early versions of the new xtest scripts I added to make testing easier. The latest version (4.0.1) seems to be pretty stable now though. I needed this to get the run.sh script to work properly. Alan. Index: run.sh === RCS file: /X11R6/x-cvs/test/xsuite/run.sh,v retrieving revision 1.3 diff -u -r1.3 run.sh --- run.sh 6 Dec 2003 18:45:17 - 1.3 +++ run.sh 18 Dec 2003 17:44:10 - @@ -61,13 +61,15 @@ Echo Press enter to continue: read resp +newsettings=y + if [ -f xtest/tetexec.cfg ]; then echo There is an existing xtest configuration file Echo Do you want to use it? (y/n) [y] read resp case $resp in - [nN]*) - newsettings=y + [yY]*) + newsettings=n ;; *) ;; ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Guaranteed Server crash with 4.4.0 (RC1)
Having looked at Bugzilla #978 it shows that it's very easy to crash the Xserver when using out-of-bounds coordinates that get mixed up when passing in int's that get converted to short's during the client-server conversation. Seeing as PutImage gets pushed through the CopyArea path, I'm sure the same problem can happen with the core protocol request for XCopyArea() too (and possibly others). There's obvious ways to fix this, but I'm keen to hear others views... Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Guaranteed Server crash with 4.4.0 (RC1)
Ah yes. I skimmed over shmstr.h too quickly and assumed INT16 instead of CARD16 for the source coords. I'll try this now. Alan. On Wed, Dec 17, 2003 at 03:08:03PM -0800, Mark Vojkovich wrote: I don't think it's as bad as you think. It looks to me like this comes about due to a difference in the Shm protocol. Going against convention, xShmPutImageReq has an unsigned value for the src X and Y location. All other primitive have signed values. I think the correct behavior is probably to clamp the source X and Y in ProcShmPutImage function to the unsigned 15 bit coordinate system. Can somebody try that to see if it fixes the problem? Mark. On Wed, 17 Dec 2003, Alan Hourihane wrote: Having looked at Bugzilla #978 it shows that it's very easy to crash the Xserver when using out-of-bounds coordinates that get mixed up when passing in int's that get converted to short's during the client-server conversation. Seeing as PutImage gets pushed through the CopyArea path, I'm sure the same problem can happen with the core protocol request for XCopyArea() too (and possibly others). There's obvious ways to fix this, but I'm keen to hear others views... Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Guaranteed Server crash with 4.4.0 (RC1)
On Wed, Dec 17, 2003 at 03:08:03PM -0800, Mark Vojkovich wrote: I don't think it's as bad as you think. It looks to me like this comes about due to a difference in the Shm protocol. Going against convention, xShmPutImageReq has an unsigned value for the src X and Y location. All other primitive have signed values. I think the correct behavior is probably to clamp the source X and Y in ProcShmPutImage function to the unsigned 15 bit coordinate system. Can somebody try that to see if it fixes the problem? Yup. This fixes it. Just committed. Alan. Index: shm.c === RCS file: /X11R6/x-cvs/xc/programs/Xserver/Xext/shm.c,v retrieving revision 3.40 diff -u -r3.40 shm.c --- shm.c 17 Nov 2003 22:20:27 - 3.40 +++ shm.c 17 Dec 2003 23:20:06 - @@ -815,6 +815,8 @@ REQUEST_SIZE_MATCH(xShmPutImageReq); VALIDATE_DRAWABLE_AND_GC(stuff-drawable, pDraw, pGC, client); VERIFY_SHMPTR(stuff-shmseg, stuff-offset, FALSE, shmdesc, client); +if (stuff-srcX 32767 || stuff-srcY 32767) + return BadValue; if ((stuff-sendEvent != xTrue) (stuff-sendEvent != xFalse)) return BadValue; if (stuff-format == XYBitmap) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 4.4.0 RC1
Yes, it was committed by Egbert on 8th October. Alan. On Mon, Dec 08, 2003 at 08:49:40AM -0800, Alex Deucher wrote: I looked through the cvs commit archives and I never saw that the fix for 661 was committed. I don't have the hardware so I can't test. Alex --- David Dawes [EMAIL PROTECTED] wrote: On Mon, Dec 08, 2003 at 08:11:24AM +, Andrew C Aitchison wrote: On Mon, 8 Dec 2003, David Dawes wrote: On Thu, Dec 04, 2003 at 08:19:59PM -0500, David Dawes wrote: If you have any open bugs in our bugzilla, you need to verify whether or not they are still valid against this release candidate. Send a note here for bugs that are confirmed to still be a problem, and close ones that you confirm are fixed. Bugs that are not confirmed against a release candidate will be closed as a matter of course when 4.4 is released. I haven't seen much reponse here yet regarding new bugs or existing open bugs in bugzilla. Does that mean that most of them are no longer relevant and can be closed? I don't think that we can behave like that. The only bug with my name on it is 85, and I've never been able to reproduce it, so I can't say whether it has been fixed. I would be very uncomfortable marking it as closed. My point is that for the bug reports to be useful, they need to be refreshed. That means that the reporter (or someone else with an interest in it) needs to, at a minimum, retest against new versions. It helps, especially at this stage of a release, to bring stuff up here. I don't know how to figure out which of the 150 or so currently open reports are even still valid, let alone when they get an update that needs attention. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Could the VESA BIOS be of assistance? (ID 20311056 ignore this filter)
On Mon, Nov 24, 2003 at 09:19:01PM +, Raymond Jennings wrote: I was wondering if we could make some use of the VESA VGA extension, to set video modes at least. That would eliminate all of the video mode problems, such as bad offsets, out of sync, and scanline problems. The VESA standard covers everything the XVidMode extension does, but does it more safely. I have yet to see the video bios mess up the video card. The XVidMode extension could ignore everything but the screen dimensions and be backward compatible. Xvidtune would be made obsolete. I've done plenty of VESA hacking, and it seems a promising interface. And don't tell me it's slow, because the video card takes a while when changing video modes anyway, and any latency involved in calling the VESA BIOS would be masked by the monitor resyncing. Tell me what you guys think about this. I'm aware of a prejudice against the BIOS, but this is a special case. I know for a fact that messing around with sync frequencies is dangerous, and the BIOS can be trusted. You could make use of the vm86 system call, or write a kernel module to go to v86 mode on behalf of the X server. I'm certain there's always a way to get to the VESA extension. Let me know what you guys think. Is this practical? is it ingenious? Is it dangerous? Is it stupid? The driver for using the VESA BIOS already exists and has done for several XFree86 versions. The driver is called 'vesa'. Some drivers already use BIOS calls to set modes too, some of the Intel chipsets exclusively use it. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Could the VESA BIOS be of assistance? (ID 20311056 ignore this filter)
The 'vesa' driver is just like any other driver. If you use the 'vesa' driver then it will change video modes using the VESA BIOS. Note that you won't get any acceleration from this driver. One problem with using the BIOS is that your set in the fixed modes provided by the BIOS. Some people like the ability to set obscure modes. It's also been noted that some laptops don't have appropriate modes in the BIOS for some 1400x1050 panels and the Windows driver programs the mode directly anyway, so XFree86's users lose out when using the VESA BIOS exclusively. I'm sure it affects more users too. You don't have to get the latest version though either, although it's that's best. Alan. On Mon, Nov 24, 2003 at 09:33:04PM +, Raymond Jennings wrote: So if I got the latest version, and decided to change video modes, would it use VESA? From: Alan Hourihane [EMAIL PROTECTED] To: Raymond Jennings [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: Could the VESA BIOS be of assistance? (ID 20311056 ignore this filter) Date: Mon, 24 Nov 2003 21:26:50 + On Mon, Nov 24, 2003 at 09:19:01PM +, Raymond Jennings wrote: I was wondering if we could make some use of the VESA VGA extension, to set video modes at least. That would eliminate all of the video mode problems, such as bad offsets, out of sync, and scanline problems. The VESA standard covers everything the XVidMode extension does, but does it more safely. I have yet to see the video bios mess up the video card. The XVidMode extension could ignore everything but the screen dimensions and be backward compatible. Xvidtune would be made obsolete. I've done plenty of VESA hacking, and it seems a promising interface. And don't tell me it's slow, because the video card takes a while when changing video modes anyway, and any latency involved in calling the VESA BIOS would be masked by the monitor resyncing. Tell me what you guys think about this. I'm aware of a prejudice against the BIOS, but this is a special case. I know for a fact that messing around with sync frequencies is dangerous, and the BIOS can be trusted. You could make use of the vm86 system call, or write a kernel module to go to v86 mode on behalf of the X server. I'm certain there's always a way to get to the VESA extension. Let me know what you guys think. Is this practical? is it ingenious? Is it dangerous? Is it stupid? The driver for using the VESA BIOS already exists and has done for several XFree86 versions. The driver is called 'vesa'. Some drivers already use BIOS calls to set modes too, some of the Intel chipsets exclusively use it. Alan. _ Has one of the new viruses infected your computer? Find out with a FREE online computer virus scan from McAfee. Take the FreeScan now! http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
On Thu, Oct 30, 2003 at 08:09:05AM +, Andrew C Aitchison wrote:
On Wed, 29 Oct 2003, Alan Hourihane wrote:
On Wed, Oct 29, 2003 at 12:26:45PM -0800, Alex Deucher wrote:
As I recall we had problems with allocating additional memory for Xv on
neomagic chips (hence the overly_mem option). As I recall there was an
issue with allocating memory beyond the limits of the blitter, similar
to the problems with Xv on via (bug 525). Could this issue be resolved
with Alan H's new linear allocator?
From looking at the driver. Yes it can. But I don't have a neomagic
chipset to test.
I have a chipset, if someone can can give me pointers to what to look at.
I wont be able to look for a week or two, since the hard disk on the
laptop has died, and needs to be replaced.
Well, if someone else has a chip, or wants to update and test other
drivers (but be careful with DRI enabled drivers as it needs more work
in the driver). Here's a patch to the neomagic that should work, and
could be used as a template for the other drivers.
That's all. Most Xv (if not all) use linear allocation already and will
take advantage of it straight away without any furthur modifications.
Alan.
Index: neo_driver.c
===
RCS file: /X11R6/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/neomagic/neo_driver.c,v
retrieving revision 1.71
diff -u -r1.71 neo_driver.c
--- neo_driver.c24 Sep 2003 03:16:55 - 1.71
+++ neo_driver.c30 Oct 2003 10:05:04 -
@@ -1685,11 +1685,20 @@
AvailFBArea.y1 = 0;
AvailFBArea.x2 = pScrn-displayWidth;
AvailFBArea.y2 = lines;
- xf86InitFBManager(pScreen, AvailFBArea);
-
- xf86DrvMsg(pScrn-scrnIndex, X_INFO,
- Using %i scanlines of offscreen memory \n,
+ if (xf86InitFBManager(pScreen, AvailFBArea)) {
+ int cpp = pScrn-bitsPerPixel / 8;
+ int area = lines * pScrn-displayWidth;
+ int areaoffset = area * cpp;
+
+ xf86DrvMsg(pScrn-scrnIndex, X_INFO,
+ Using %i scanlines of offscreen memory for area's \n,
lines - pScrn-virtualY);
+
+ if ( xf86InitFBManagerLinear(pScreen, area, (nPtr-NeoFbMapSize -
area))) {
+ xf86DrvMsg(scrnIndex, X_INFO,
+ Using the rest of offscreen memory for linear
(offset=0x%x,size=%3.1fMB)\n, areaoffset, (float)(nPtr-NeoFbMapSize -
(areaoffset/(1024*1024;
+ }
+ }
}
/* Setup the acceleration primitives */
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
On Thu, Oct 30, 2003 at 10:07:13AM +, Alan Hourihane wrote:
On Thu, Oct 30, 2003 at 08:09:05AM +, Andrew C Aitchison wrote:
On Wed, 29 Oct 2003, Alan Hourihane wrote:
On Wed, Oct 29, 2003 at 12:26:45PM -0800, Alex Deucher wrote:
As I recall we had problems with allocating additional memory for Xv on
neomagic chips (hence the overly_mem option). As I recall there was an
issue with allocating memory beyond the limits of the blitter, similar
to the problems with Xv on via (bug 525). Could this issue be resolved
with Alan H's new linear allocator?
From looking at the driver. Yes it can. But I don't have a neomagic
chipset to test.
I have a chipset, if someone can can give me pointers to what to look at.
I wont be able to look for a week or two, since the hard disk on the
laptop has died, and needs to be replaced.
Well, if someone else has a chip, or wants to update and test other
drivers (but be careful with DRI enabled drivers as it needs more work
in the driver). Here's a patch to the neomagic that should work, and
could be used as a template for the other drivers.
That's all. Most Xv (if not all) use linear allocation already and will
take advantage of it straight away without any furthur modifications.
Actually,
Due to the neomagic driver having different use of NeoFbMapSize, here's
a new followup.
Alan.
Index: neo_driver.c
===
RCS file: /X11R6/x-cvs/xc/programs/Xserver/hw/xfree86/drivers/neomagic/neo_driver.c,v
retrieving revision 1.71
diff -u -r1.71 neo_driver.c
--- neo_driver.c24 Sep 2003 03:16:55 - 1.71
+++ neo_driver.c30 Oct 2003 11:05:23 -
@@ -1685,11 +1685,21 @@
AvailFBArea.y1 = 0;
AvailFBArea.x2 = pScrn-displayWidth;
AvailFBArea.y2 = lines;
- xf86InitFBManager(pScreen, AvailFBArea);
-
- xf86DrvMsg(pScrn-scrnIndex, X_INFO,
- Using %i scanlines of offscreen memory \n,
+ if (xf86InitFBManager(pScreen, AvailFBArea)) {
+ int cpp = pScrn-bitsPerPixel / 8;
+ int area = lines * pScrn-displayWidth;
+ int areaoffset = area * cpp;
+ int totalmapsize = (pScrn-videoRam * 1024);
+
+ xf86DrvMsg(pScrn-scrnIndex, X_INFO,
+ Using %i scanlines of offscreen memory for area's \n,
lines - pScrn-virtualY);
+
+ if ( xf86InitFBManagerLinear(pScreen, area, (totalmapsize - area))) {
+ xf86DrvMsg(scrnIndex, X_INFO,
+ Using the rest of offscreen memory for linear
(offset=0x%x,size=%3.1fMB)\n, areaoffset, (float)(totalmapsize -
(areaoffset/(1024*1024;
+ }
+ }
}
/* Setup the acceleration primitives */
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
On Thu, Oct 30, 2003 at 11:06:45AM +, Alan Hourihane wrote: On Thu, Oct 30, 2003 at 10:07:13AM +, Alan Hourihane wrote: On Thu, Oct 30, 2003 at 08:09:05AM +, Andrew C Aitchison wrote: On Wed, 29 Oct 2003, Alan Hourihane wrote: On Wed, Oct 29, 2003 at 12:26:45PM -0800, Alex Deucher wrote: As I recall we had problems with allocating additional memory for Xv on neomagic chips (hence the overly_mem option). As I recall there was an issue with allocating memory beyond the limits of the blitter, similar to the problems with Xv on via (bug 525). Could this issue be resolved with Alan H's new linear allocator? From looking at the driver. Yes it can. But I don't have a neomagic chipset to test. I have a chipset, if someone can can give me pointers to what to look at. I wont be able to look for a week or two, since the hard disk on the laptop has died, and needs to be replaced. Well, if someone else has a chip, or wants to update and test other drivers (but be careful with DRI enabled drivers as it needs more work in the driver). Here's a patch to the neomagic that should work, and could be used as a template for the other drivers. That's all. Most Xv (if not all) use linear allocation already and will take advantage of it straight away without any furthur modifications. Actually, Due to the neomagic driver having different use of NeoFbMapSize, here's a new followup. Sorry, another followup for Andrew really. The hardware cursor code should be made to use the linear allocator too, and the overlay_mem code could be removed. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
Andrew, I've just committed a patch to the trident driver to enable it. Best use that as the basis for the neomagic work. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
On Thu, Oct 30, 2003 at 07:47:06AM -0600, Billy Biggs wrote: Alan Hourihane ([EMAIL PROTECTED]): Well, if someone else has a chip, or wants to update and test other drivers (but be careful with DRI enabled drivers as it needs more work in the driver). Here's a patch to the neomagic that should work, and could be used as a template for the other drivers. That's all. Most Xv (if not all) use linear allocation already and will take advantage of it straight away without any furthur modifications. Alan, do you know if it would help with the Radeon driver, re bug 830? http://bugs.xfree86.org/show_bug.cgi?id=830 Potentially - yes. But the DRI parts need a little more work to play nicely with the Linear allocator. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
I've actually already done it, but I'll probably leave it till after XFree86 4.4.0. Once 4.4.0 is out, I'll merge that into the DRI CVS and create a branch for this work I've been doing on the radeon with regard to dynamic allocation the DRI. Alan. On Thu, Oct 30, 2003 at 07:36:42AM -0800, Alex Deucher wrote: I'll take a look at fixing this in the radeon driver. What needs to be done to play nice with the DRI? Alex --- Alan Hourihane [EMAIL PROTECTED] wrote: On Thu, Oct 30, 2003 at 07:47:06AM -0600, Billy Biggs wrote: Alan Hourihane ([EMAIL PROTECTED]): Well, if someone else has a chip, or wants to update and test other drivers (but be careful with DRI enabled drivers as it needs more work in the driver). Here's a patch to the neomagic that should work, and could be used as a template for the other drivers. That's all. Most Xv (if not all) use linear allocation already and will take advantage of it straight away without any furthur modifications. Alan, do you know if it would help with the Radeon driver, re bug 830? http://bugs.xfree86.org/show_bug.cgi?id=830 Potentially - yes. But the DRI parts need a little more work to play nicely with the Linear allocator. Alan. __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Linear Allocator (Was Re: Alan H's new linear allocator and Neomagic Xv)
On Thu, Oct 30, 2003 at 10:59:41AM -0600, Billy Biggs wrote: Alan Hourihane ([EMAIL PROTECTED]): I've actually already done it, but I'll probably leave it till after XFree86 4.4.0. Regarding bug 830, does this mean my users can expect to sometimes hit these situations where XVIDEO apps can't run until they shut down a large application like their web browser? Don't take this the wrong way, I don't mind, I just want to understand the situation so I can design appropriate error messages. Low memory situations should only happen when a 3D application is also running. I'm not sure why you'd be hitting it when it's not. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Alan H's new linear allocator and Neomagic Xv
On Wed, Oct 29, 2003 at 12:26:45PM -0800, Alex Deucher wrote: As I recall we had problems with allocating additional memory for Xv on neomagic chips (hence the overly_mem option). As I recall there was an issue with allocating memory beyond the limits of the blitter, similar to the problems with Xv on via (bug 525). Could this issue be resolved with Alan H's new linear allocator? From looking at the driver. Yes it can. But I don't have a neomagic chipset to test. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Cygwin/XFree86 - No longer associated with XFree86.org
On Mon, Oct 27, 2003 at 11:35:20AM -0500, Harold L Hunt II wrote: 6) Alternatives are being evaluated for hosting Cygwin/XFree86 code in CVS. Hosts that can provide CVS commit access for at least five Cygwin/XFree86 developers will be given priority. Harold, I thought you already had the CVS for Cygwin/XFree86 sorted out, by using what you'd already setup in http://sf.net/projects/xoncygwin ? You and Alexander Gottwald (and myself) have already been using this for quite some time now. Couldn't you give Kensuke et al commit access there rather than seeking out yet another repository ? Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: VIA's Savage Drivers
On Wed, Oct 15, 2003 at 09:50:40AM -0700, Tim Roberts wrote: Some months ago, VIA released an XFree86 Savage driver in source form that included, among other things, a DRI driver and XvMC support. Has that code been integrated into the XFree86 source tree? Will it make XFree86 4.4? Or is it still waiting in limbo for someone to do the integration? I created the savage-1-0-0-branch in the DRI tree and merged the 2D these pieces together. Unfortunately the 3D driver is based on Mesa 3.4.x from the XFree86 4.2.0 days, and needs some work to bring it up-to-date. I suggest you check out that branch from the DRI. It certainly won't make 4.4. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Audio in X11
On Wed, Sep 10, 2003 at 05:41:23PM +0200, Michel Dänzer wrote: On Wed, 2003-09-10 at 17:09, Jim Gettys wrote: While the X server has had the XSync extension for a long time, the operating system hooks to allow X to synchronize with external events (e.g. vertical sync, sample clock of audio streams, etc) have been absent in open source systems. XSync was developed in the days of engineering workstations 10 years ago, and was debugged with such kernel support. FWIW, the DRM has provided synchronization to the vertical refresh for a while. Indeed. But it's presented through the OpenGL interface, whereas using XSync would allow non-OpenGL apps to use this extension and get that facility. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Audio in X11
On Wed, Sep 10, 2003 at 06:05:42PM +0200, Michel Dänzer wrote: On Wed, 2003-09-10 at 17:55, Alan Hourihane wrote: On Wed, Sep 10, 2003 at 05:41:23PM +0200, Michel Dänzer wrote: On Wed, 2003-09-10 at 17:09, Jim Gettys wrote: While the X server has had the XSync extension for a long time, the operating system hooks to allow X to synchronize with external events (e.g. vertical sync, sample clock of audio streams, etc) have been absent in open source systems. XSync was developed in the days of engineering workstations 10 years ago, and was debugged with such kernel support. FWIW, the DRM has provided synchronization to the vertical refresh for a while. Indeed. But it's presented through the OpenGL interface, whereas using XSync would allow non-OpenGL apps to use this extension and get that facility. No need for OpenGL, it's simply an ioctl for the DRM device. It wonly works when the DRI is enabled obviously. O.k. But then that's not very portable - in this instance we'd have to get the user space app to talk directly to the DRM. Ugh! In the current form, a user app uses OpenGL's extension to do it in a portable form. XSync is the same portable form for X only apps. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Audio in X11
On Wed, Sep 10, 2003 at 06:24:13PM +0200, Michel Dänzer wrote: On Wed, 2003-09-10 at 18:11, Alan Hourihane wrote: On Wed, Sep 10, 2003 at 06:05:42PM +0200, Michel Dänzer wrote: On Wed, 2003-09-10 at 17:55, Alan Hourihane wrote: On Wed, Sep 10, 2003 at 05:41:23PM +0200, Michel Dänzer wrote: On Wed, 2003-09-10 at 17:09, Jim Gettys wrote: While the X server has had the XSync extension for a long time, the operating system hooks to allow X to synchronize with external events (e.g. vertical sync, sample clock of audio streams, etc) have been absent in open source systems. XSync was developed in the days of engineering workstations 10 years ago, and was debugged with such kernel support. FWIW, the DRM has provided synchronization to the vertical refresh for a while. Indeed. But it's presented through the OpenGL interface, whereas using XSync would allow non-OpenGL apps to use this extension and get that facility. No need for OpenGL, it's simply an ioctl for the DRM device. It wonly works when the DRI is enabled obviously. O.k. But then that's not very portable - in this instance we'd have to get the user space app to talk directly to the DRM. Ugh! Really? I'd think only the server would use the device, if the clients did, it would be the same problem regardless of the underlying mechanism, wouldn't it? (I'm talking about using it for XSync, in case that wasn't clear; an abstraction library for the various methods of vertical refresh synchronization might also be useful though) It wasn't clear. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xrender transforms...
On Sun, Aug 10, 2003 at 02:27:13PM +1000, Carsten Haitzler wrote: Would I be correct in the assumption that the only accelerated path for xrender is the identity transform (1:1 scale)? all other transforms are done in software? (my initial tests here with xfree86 4.3.0 nvidia's latest drivers (as of about a month ago) seem to indicate as much...) (and yes... my drivers are using acceleration... GL definitely is). ? No. About 99% of the drivers don't have any xrender acceleration. I think only the mga driver does. Although looking furthur the sis has some, but it seems disabled, and the vmware driver has it too. But that's it. I guess nvidia do some acceleration in their binary drivers though, as you've probably found. But it's bad to assume other drivers have xrender acceleration. I think the thing that's holding other drivers up in getting furthur xrender acceleration is that there's no test suite to check that the driver is doing the right thing. I think Keith Packard mentioned he had intern's working on a test suite a while ago, but nothing has materialized as far as I know. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: cvsup problems
Sounds like your using an old cvsup binary with glibc-2.3. This is exactly
what I got.
You need to recompile cvsup for glibc-2.3.
I suspect as you work for RedHat, you've probably upgraded to RH9.
Alan.
On Fri, Aug 08, 2003 at 12:09:30PM -0400, John Dennis wrote:
I had been using cvsup successfully to sync with the XFree86 CVS tree,
but after returning from vacation it has started to fail with what
appears to be an internal error in the client.
***
*** runtime error:
***Segmentation violation - possible attempt to dereference NIL0
***
use option @M3stackdump to get a stack trace
Aborted
I will include the stackdump below and my config file, I didn't see
anything in the stackdump that meant anything to me. I did update my
cvsup client to the latest and I checked the cvsup web site looking for
possible causes/solutions. The only thing I found was if you DNS could
not reverse map your ip address you could get a similar failure, but my
DNS server can do the reverse mapping fine. So I'm a bit perplexed,
anybody have a suggestion as to what may be the problem. Like I said,
this has all been working fine previously. The only thing I can think of
is that my host machine did have some libraries updated but cvsup is
statically linked so I don't think that could explain the sudden
failure.
$ cvsup @M3stackdump cvsup.xfree86
***
*** runtime error:
***Segmentation violation - possible attempt to dereference NIL0
***
- STACK DUMP ---
PC SP
0x80c9c18 0xbfffe130 Crash + 0x58 in
/usr/local/src/m3/pm3-1.1.15/libs/m3core/src/runtime/common/RTProcess.m3
0x80c8d6f 0xbfffe144 EndError + 0x3f in
/usr/local/src/m3/pm3-1.1.15/libs/m3core/src/runtime/common/RTMisc.m3
0x80c8b74 0xbfffe168 FatalErrorI + 0x34 in
/usr/local/src/m3/pm3-1.1.15/libs/m3core/src/runtime/common/RTMisc.m3
0x80cd46a 0xbfffe17c SegV + 0x2a in
/usr/local/src/m3/pm3-1.1.15/libs/m3core/src/runtime/LINUXLIBC6/RTSignal.m3
0x80eafb8 0xbfffe4f0
0x8106e0c 0xbfffe538
0x810694b 0xbfffe5fc
0x8106f36 0xbfffe628
0x8101ef9 0xbfffe634
0x810694b 0xbfffe6f8
0x8101772 0xbfffe758
0x8101dff 0xbfffe774
0x811b2d7 0xbfffe78c
0x8102c9d 0xbfffe7e4
0x810285c 0xbfffe83c
0x80a7e8e 0xbfffea0c CanGet + 0x16e in
/usr/local/src/m3/pm3-1.1.15/libs/libm3/src/uid/POSIX/MachineIDPosix.m3
0x80a7238 0xbfffea28 Init + 0x58 in
/usr/local/src/m3/pm3-1.1.15/libs/libm3/src/uid/Common/TimeStamp.m3
0x80a73b1 0xbfffea94 New + 0x81 in
/usr/local/src/m3/pm3-1.1.15/libs/libm3/src/uid/Common/TimeStamp.m3
0x80a69a1 0xbfffead0 RandomSeed + 0x41 in
/usr/local/src/m3/pm3-1.1.15/libs/libm3/src/random/Common/Random.m3
0x80a6876 0xbfffeae4 Init + 0x46 in
/usr/local/src/m3/pm3-1.1.15/libs/libm3/src/random/Common/Random.m3
0x8066467 0xbfffeb1c New + 0x87 in
/usr/local/src/cvsup/cvsup-snap-16.1d/client/src/BackoffTimer.m3
0x806895b 0xb0bc
0x80c869f 0xb0d4 RunMainBodies + 0x6f in
/usr/local/src/m3/pm3-1.1.15/libs/m3core/src/runtime/common/RTLinker.m3
-- EXCEPTION HANDLER STACK -
0xbfffe85c RAISES {}
0xbfffea20 RAISES {}
0xbfffea60 LOCK mutex = 0x81842ec
0xbfffea6c RAISES {}
0xbfffeac8 RAISES {}
0xbfffec34 TRY-FINALLY proc = 0x8068d73 frame = 0xb0bc
0xbfffecfc TRY-EXCEPT {Main.Error}
0xbfffee68 TRY-EXCEPT {Thread.Alerted}
Aborted
Here is my cvsup config file:
*default release=cvs host=anoncvs.xfree86.org
base=/home/boston/jdennis/.cvsup
*default prefix=/home/boston/jdennis/src/xfree86 delete use-rel-suffix
*default compress
*default tag=.
xc-all
doctools-all
contrib-all
xtest-all
utils-all
--
John Dennis [EMAIL PROTECTED]
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Savage Driver Replacement?
On Fri, Jul 11, 2003 at 05:20:16PM -0700, Tim Roberts wrote: I've recently been made aware of the XFree86 Savage driver that VIA released and is now available on Alan Hourihane's web site. This driver is so much superior to the one I've been maintaining that I should be embarrassed. My question is: has anyone actually taken an action item to incorporate this into the 4.3.99 tree? The drivers on my web page at XFree86 is what comes from the CVS. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] PLE133 driver source
On Thu, Jul 10, 2003 at 08:40:27AM -0700, Alex Deucher wrote: I just saw this on VIA's website. It looks like they just took Alan's code and added some tv features (or perhaps just re-released his code?). I don't know if there are already in CVS or not, but for what it's worth here's the link: http://www.viaarena.com/?PageID=296 http://downloads.viaarena.com/LinuxApplicationNotes/RedHat/VIA_RH8.0_KPLE_v12a_03192003.zip In fact, they've updated some code slightly, so I'll add this in. Thanks for the heads up Alex. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Performance regression between 4.3.0 and snapshot version.
On Tue, Jul 08, 2003 at 10:25:40AM +0200, Egbert Eich wrote: Bugzilla #434 shows a x11perf regression test between 4.3.0 and a rather current CVS versions. The performance of some tests has gone down by 20% for a specific test, some other tests have suffered a performance penalty of 3%. There may be a simple explanation for this however I can't find it right now. Any idea? Egbert, I believe this guy had 4.3.0 running with a savage with UseBIOS off because the BIOS failed for some reason so the UseBIOS option was turned off. In the later 4.3.99.x series the BIOS now works for him, but unfortunately the BIOS makes some more conservative settings for the accelerator engine in the savage. If he add Option UseBIOS off back in, I believe that will solve his problem. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: fontstosfnt doesn't build
On Fri, Jul 04, 2003 at 10:54:22PM +0200, Matthieu Herrb wrote: Alan Hourihane wrote (in a message from Friday 4) With the latest CVS 'fontstosfnt' doesn't build on FreeBSD on presumably other OS's too, due to the lack of byteswap.h. A heads up for those maintaining it, and can you produce a fix ? I've commited a fix to write.c for that portability problem on June 29. I guess you don't have the latest revision of write.c (1.3). Ah, thanks Matthieu. For some reason that directory didn't get updated. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Repeating Keystrokes in X
On Mon, Jun 02, 2003 at 04:30:11PM -0600, Mark Cuss wrote: Hello I'm not sure if this is an X problem or not - if not, please let me know... I have a Toshiba Satellite 2450 notebook on which I've recently installed RedHat 8. Everything works OK, except that sometimes in X when I type (in a terminal or anywhere else), my keystrokes are doubled up (ie - pressing s once results in 2 of them in the terminal). This can happen every 10th keystroke or so... This doesn't seem to happen when X isn't running, so I think it may be an X thing. I've attached my config file - I couldn't find anything out of the ordinary in here... If anyone has any suggestions I'd appreciate them... Try disabling xkb when starting X. So do this startx -- -kb Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 1200dpi bitmap fonts in the tree
On Sun, Jun 01, 2003 at 07:20:57PM +0200, Juliusz Chroboczek wrote: Is it me, or are we really shipping 1200dpi bitmap fonts as part of XFree86? xc/programs/Xserver/XpConfig/C/print/models/SPSPARC2/fonts/Courier.pmf These have always been there. It's part of the Xprint server. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Trident cyberblade Ai1/Xp
I'm gonna have a play later this week with some Trident problems. I'll report back then. Alan. On Sat, Mar 29, 2003 at 10:24:45PM +0100, Olivier Fourdan wrote: I wonder if it shows on an external monitor. If you have one, you may try and see if the problem occurs. Maybe it's a problem with the refresh rate, dunno... Or maybe I'm just all wrong. I cannot test with an external monitor since I have none. Alan..., any idea ? Cheers, Olivier. On Fri, 2003-03-28 at 03:19, Trent R. Gemmill wrote: Thamks for the reply! I do wonder if it's something specific to Toshiba or to the cyberblade. But at least I know their aren't any fixes yet. Trent On Thu, Mar 27, 2003 at 09:26:19PM +0100, Olivier Fourdan wrote: I have the exact same problems with another Toshiba laptop with the same video card. I did try to fix the problem by hacking the driver w/out success... Too bad. Cheers, Olivier. On Thu, 2003-03-27 at 14:53, Trent R. Gemmill wrote: I have a Toshiba Satellite 1805-S274 which uses the Trident cyberblade Ai1/Xp chip. I am running RH 8.0 (Linux version 2.4.18-14, X11R6 V 4.2). ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel -- Olivier Fourdan [EMAIL PROTECTED] http://www.xfce.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 host.def file questions
On Thu, Mar 27, 2003 at 04:01:56PM -0800, Kendall Bennett wrote: Hi Again, I think that http://www.xfree86.org/current/BUILD.html is a reasonable introduction to building XFree86, but suggestions for improving that document are most welcome. Going through the current BUILD.html file again I see that things are a lot clearer now. However one thing that needs to be explained is the section that says 'When the build is finished, you should check the World.log file to see if there were any problems'. Fair enough. Well the first time a user attemps to do exactly that, they will bring it up in their favorite editor and immediately say to themselves 'How the hell do I know if there is an error!'. The next obvious idea is to grep for 'error', but that also is not good because there are lots of files with 'error' in the filename! As I have now found out, there are a few simple grep commands that can be used to grep the World.log file and determine if any errors occurred. It would be really nice if the BUILD file had a description of a good grep command and how it can be used to check for errors. That would have saved me a lot of time also tracking down the weird '@Aliases' build problem I was having ;-) Kendall, Your obviously making good progress on getting things going, but the problems your hitting are kind of hidden to the die hard developers. Your making observations on how some of the documentation is deficient. What I would recommend you doing is changing the documentation and submitting a patch to improve it rather than relying on others to update it. That would be a great bonus! Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Generic rootless code home
On Thu, Mar 20, 2003 at 04:32:23PM -0800, Torrey Lyons wrote: XDarwin's generic rootless code is generally useful for anyone implementing an X server on top of another windowing system. It was written to abstract the implementation details of dealing with the underlying window system. It is used by XDarwin to provide a rootless X server on Mac OS X and by XDirectFB to do the same over DirectFB. The code is sufficiently mature and generally useful that we would like to move it out into a more accessible place instead of being buried in Xserver/hw/darwin/quartz. Are there any suggestions for a suitable home? Likely candidates are Xserver/rootless or Xserver/miext/rootless. Xserver/miext/rootless sounds like a plan. I'm sure the cygwin folks could use it too over the top of Windows. I'd certainly be interested in it. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: nasty little bug in radeon driver
On Fri, Mar 07, 2003 at 09:47:42AM +0100, Enrik Berkhan wrote: Hi, after having some problems with an R300 based ATI card (dotclocks seemed to be too slowed by a factor of about 1.17, text mode restoral didn't work), I've found the following: Index: radeon_reg.h === RCS file: /cvs/xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_reg.h,v retrieving revision 1.25 diff -u -r1.25 radeon_reg.h --- radeon_reg.h 2003/02/07 18:08:59 1.25 +++ radeon_reg.h 2003/03/07 08:34:09 @@ -879,7 +879,7 @@ # define RADEON_P2PLL_REF_DIV_MASK0x03ff # define RADEON_P2PLL_ATOMIC_UPDATE_R (1 15) /* same as _W */ # define RADEON_P2PLL_ATOMIC_UPDATE_W (1 15) /* same as _R */ -# define R300_PPLL_REF_DIV_ACC_MASK (0x3ff 18) +# define R300_PPLL_REF_DIV_ACC_MASK (0x3ff 18) # define R300_PPLL_REF_DIV_ACC_SHIFT 18 #define RADEON_PALETTE_DATA 0x00b4 #define RADEON_PALETTE_30_DATA 0x00b8 Now it works for me. Thanks, I've committed your fix to the CVS. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xf86cfg: ERROR SIGSEGV caught!
On Fri, Feb 28, 2003 at 05:46:24AM -0500, Mike A. Harris wrote: On Thu, 27 Feb 2003, Stefan Dirsch wrote: No. Will be some work to extract the CVS diff for me. So you can't reproduce this problem with 4.3.0? I'll have a try with 4.3.0 now before looking deeper into this issue. I've just tried xf86cfg under 4.3 and didn't have any difficulties. One thing I did have to do was clean out ancient drivers from the modules directory -- I had several seg faults until I made sure I didn't have anything older than 4.3 installed. Strange. It only happens if libfreetype.so render module exists. I compile this against system libfreetype to get rid of some bugs in freetype2 which comes with XFree86 (some fonts can't be displayed any more which worked with freetype1 based freetype module). After loading this module every module gets a ERROR SIGSEGV caught! after loading. [...] Loading /usr/X11R6/lib/modules/fonts/libfreetype.so Module freetype: vendor=The XFree86 Project compiled for 4.3.0, module version = 2.0.2 Unloading /usr/X11R6/lib/modules/fonts/libfreetype.so Loading /usr/X11R6/lib/modules/fonts/libtype1.a Module type1: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.2 ERROR SIGSEGV caught! Loading /usr/X11R6/lib/modules/fonts/libbitmap.a Module bitmap: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.0 ERROR SIGSEGV caught! Maybe xf86cfg can't handle these modules. XFree86 loader can. Hmm. Perhaps this is related to the setjmp() et al. changes lately? Just a thought... Mmm, Mike - did you actually read this thread before making this comment ? Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xf86cfg: ERROR SIGSEGV caught!
On Fri, Feb 28, 2003 at 11:06:49 -0500, Mike A. Harris wrote: On Fri, 28 Feb 2003, Alan Hourihane wrote: From: Alan Hourihane [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: xf86cfg: ERROR SIGSEGV caught! Loading /usr/X11R6/lib/modules/fonts/libfreetype.so Module freetype: vendor=The XFree86 Project compiled for 4.3.0, module version = 2.0.2 Unloading /usr/X11R6/lib/modules/fonts/libfreetype.so Loading /usr/X11R6/lib/modules/fonts/libtype1.a Module type1: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.2 ERROR SIGSEGV caught! Loading /usr/X11R6/lib/modules/fonts/libbitmap.a Module bitmap: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.0 ERROR SIGSEGV caught! Maybe xf86cfg can't handle these modules. XFree86 loader can. Hmm. Perhaps this is related to the setjmp() et al. changes lately? Just a thought... Mmm, Mike - did you actually read this thread before making this comment ? No I did not. I read the message I responded to, which is the only message aside from the one before it in my mail folder. I responded based on that. After your response and reading list archives, it seems that my comment was right on the money too. Referring to Stefan's original email you'd have seen he already made the comment about setjmp(). Was there a particular reason to be rude about my attempt to help, or am I missing something? You were just re-stating something that the original poster had already mentioned, and David's followup even asked for Stefan to try reversing the patch anyway to see if the problem resolved itself. Nothing rude about it. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: date.def
On Thu, Feb 27, 2003 at 12:55:21 +, Dr Andrew C Aitchison wrote: xc/config/cf/Imakefile now refers to date.def, and xfree86.cf includes it, but I can't find it in the latest CVS, nor can I find a rule which builds it on the fly. Without this file make World does very little. The Imakefile change appears to be before the 4.2 tag, so we may need to add the file to both branches ? The rule to build it is in xc/Makefile. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RELNOTES for 4.3.0
On Tue, Feb 25, 2003 at 12:05:17AM -0500, David Dawes wrote: On Tue, Feb 25, 2003 at 01:49:52AM +0100, Rob van Nieuwkerk wrote: David Dawes wrote: On Wed, Feb 19, 2003 at 11:14:55AM +, Alan Hourihane wrote: Here's a list of items for the RELNOTES for 4.3.0, if anyone has anything to add to this, please send it in. Thanks to all who sent in items for the release notes. I've put updated versions of the docs for 4.3.0 at http://www.xfree86.org/~dawes/4.3.0/. Further updates for the release notes and other docs are welcome. The final section of the release notes needs to be reviewed too. Hi David, In: http://www.xfree86.org/~dawes/4.3.0/RELNOTES2.html#3 (2.1. Video Driver Enhancements) I read: National Semiconductor SC1x00, GX1, and GX2 chipset support added with the nsc driver. Maybe there should be a nsc section added to: http://www.xfree86.org/~dawes/4.3.0/Status.html (Driver Status for XFree86[tm] 4.3.0) ? Yes, I'll add a National Semiconductor section. Btw: I'm wondering if this new nsc obsoletes the Cyrix driver for the Cyrix MediaGX ? I'm not sure. Alan, can you clarify this? The nsc driver certainly obsoletes the cyrix driver for the 5530. But I've heard rumours that it doesn't cope with the older style VSA1 5530 chips very well in which the cyrix driver may still be needed. But, additionally, the cyrix driver deals with 5510 and 5520 chips, whereas the nsc driver doesn't. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RELNOTES for 4.3.0
On Wed, Feb 19, 2003 at 12:37:45 +0100, Frank Giessler wrote: In [EMAIL PROTECTED], on 02/19/03 at 11:14 AM, Alan Hourihane [EMAIL PROTECTED] said: Here's a list of items for the RELNOTES for 4.3.0, if anyone has anything to add to this, please send it in. * Major OS/2 support updates. ??? Where do they come from? Holger Veit. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: RELNOTES for 4.3.0
On Wed, Feb 19, 2003 at 01:28:12PM +0100, Holger Veit wrote: On Wed, Feb 19, 2003 at 11:49:07AM +, Alan Hourihane wrote: On Wed, Feb 19, 2003 at 12:37:45 +0100, Frank Giessler wrote: In [EMAIL PROTECTED], on 02/19/03 at 11:14 AM, Alan Hourihane [EMAIL PROTECTED] said: Here's a list of items for the RELNOTES for 4.3.0, if anyone has anything to add to this, please send it in. * Major OS/2 support updates. ??? Where do they come from? Holger Veit. To be precise, considerable work has been done for this release by Frank Giessler. Honour to those who really deserve it. I'm puzzled why it was Frank who asked the question then... Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: server crash on linux-mips
On Tue, Feb 18, 2003 at 10:49:58 -0800, Nolan Leake wrote: On Sun, 2003-02-16 at 16:36, Mark Vojkovich wrote: I don't really know what the point of fbIsVirtual was. Apps that use ShadowFBInit need to repaint when entering the VT. We didn't have the EnableDisableFBAccess stuff when I wrote shadowfb and the refresh at EnterVT was to catch the copy from the old root window backing pixmap. With EnableDisableFBAccess handling exposures, it shouldn't be needed anymore but we definitely don't want to block EnableDisableFBAccess like the code is doing. It seems like having ShadowFBInit call ShadowFBInit2 with FALSE is the correct behavior. Experimentation shows this to remove the corruption. The previous shadowfb code blocked EnableDisableFBAccess and updated on VT switching. Since the code looked stale (I couldn't find where the screen got stored in the backing pixmap anywhere), I disabled it for the vmware driver, but since I didn't have a way to test the other clients of shadowfb, I preserved the old behavior for them. If having ShadowFBInit call ShadowFBInit2 with FALSE works for all clients, then the fbIsVirtual flag can be removed entirely; the only caller of ShadowFBInit2 is vmware.c, and it passes in FALSE. O.k. Thanks Nolan. I've just removed that code from the CVS. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: server crash on linux-mips
On Mon, Feb 17, 2003 at 10:23:03PM +0100, Guido Guenther wrote: On Mon, Feb 17, 2003 at 12:10:16AM +, Alan Hourihane wrote: If you call the ShadowFBInit2 in newport_driver.c (just tag FALSE on the end of the arguments). Does that work for you ? Yes, this works. Thanks! But it's significantly slower. After switching back from the console there's nothing happenning for about 5 seconds (but I see an half updated screen), then inistantly everything is back to normal. The expose events sent, should be fairly immediate, I don't know why it would take 5 seconds. My question is now: is ShadowFBInit going to be removed in favor of ShadowFBInit2 or will it be revived? Should I look into fixing it or send a patch that uses ShadowFBInit2 (which would hopefully slip into 4.3.0)? Yes send a patch in. shadowfb.h says about ShadowfbInit2: * It also allows you to specify that you * actually do have a real framebuffer (as opposed to just some malloc'd space * in memory) by passing FALSE to fbIsVirtual. But when I pass TRUE (since I only have a virtual fb and can't access the newports fb directly) it doesn't work. I have to pass FALSE. Am I missing something here? Not that I can see. I was hoping that Nolan Leake from VMware can shed some light on this. Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: glint driver broken in current CVS.
Thanks, I've just committed your fixes for these. Alan. On Mon, Feb 17, 2003 at 12:51:05 +0100, Björn Augustsson wrote: revision 1.153 date: 2003/02/10 13:20:11; author: alanh; state: Exp; lines: +10 -1 abort when finding a depth 30 visual and no IBM640 dac fix up depth 555 visual for DRI The code if ( (pGlint-RamDac-RamDacType != (IBM640_RAMDAC)) (pScrn-depth == 30) ) Is the problem, since, at least on this box, pGlint-RamDac is NULL at this point. The box is an ev6 alpha, card is an 8MB Elsa Gloria ti_pm2. Also, something I found while researching something else: From xc/config/cf/linux.cf: # define LdCmd CcCmd -nostdlib -Wl'-m m68klinux Looks strange, should likely be: # define LdCmd CcCmd -nostdlib -Wl,-m m68klinux /August. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
