ANNOUNCE: XFree86 4.8.0 is now available
We are very pleased to announce the release of XFree86 4.8.0. This release comes about a year and a half after the 4.7.0 release, and is the product of the work of dedicated volunteers. We would like to thank all who have contributed to this release, through code, testing, and other feedback, and all who continue to support XFree86 and the work of its volunteer developers. Source, patches and binaries for a range of platforms are now available for download from our ftp site: ftp://ftp.xfree86.org/pub/XFree86/4.8.0/ http://ftp.xfree86.org/pub/XFree86/4.8.0/ We currently have binaries available for a number of platforms. More will become available over time. If you are not sure which binary set you need, first download the Xinstall.sh script, and run: sh Xinstall.sh -check Also, before downloading, check the 4.8.0 online documentation at: http://ftp.xfree86.org/pub/XFree86/4.8.0/doc/html/ Read especially the README, RELNOTES and Install documents. Also, check the ERRATA for 4.8.0 for any last minute issues: http://ftp.xfree86.org/pub/XFree86/4.8.0/ERRATA The CVS tag for this release is xf-4_8_0. Information about accessing our anonymous CVS service is at http://www.xfree86.org/cvs/. User-related problems should be reported to our xfre...@xfree86.org list. Development issues and specific bugs should be reported to our devel@xfree86.org list and/or logged at http://bugs.xfree86.org/. The next release, 4.9.0, is planned for late 2009 or early 2010. If you find XFree86 useful and would like to help support our work, please visit our donations page: http://www.xfree86.org/donations/ Enjoy. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: t...@ualberta.ca | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: problem with patch 4.7.99.14-4.7.99.15.diff.bz2 in PCI detection
On Wed, 21 May 2008, [EMAIL PROTECTED] wrote: I suspect this is happening because these systems are capable of PCI Express. Please try the attached patch when you get the system back. It would be sufficient to check if the slowdown still occurs with the resulting scanpci binary. Okay, I've got the machine back and I've tested your patch with scanpci. = The problem is corrected, XFree86 doesn't block anymore on this 111d:8018 chip. I suppose it will be included in the next official patch ? Yes it will, given I've already committed it. Thanks for trying it out. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: problem with patch 4.7.99.14-4.7.99.15.diff.bz2 in PCI detection
On Tue, 13 May 2008, [EMAIL PROTECTED] wrote: I'am testing some Fujitsu-Siemens workstations which have the same video chip : 102b:0522 Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines (SEP1) FSC TX150-S6 FSC TX200-S4 FSC RX100-S5 The 3 computers have the same /etc/X11/XF86Config-4 file. I've noticed a problem with the TX150-S6 when XFree86 starts : the process gets stuck in the PCI detection sequence on the first of 3 identical PCI chips (111d:8018). After several minutes (between 5 and 10 minutes, I've not measured exactly), XFree finished the start sequence and works well after that. Well, the code no longer assumes multifunction devices have a zero function, which means the PCI scan now looks at all combinations of device and function numbers. So I would expect it to take slightly longer. But not by _that_ much. These chips (111d:8018) are found only on the TX150-S6. On the 2 other computers, XFree86 starts without problem. Here is the lspci output for the TX150-S6. The chip which blocks the XFree86 startup is prefixed by an asterisk. Attached is a detailled output of lspci (-vv). [elided] During the freeze, I noticed that lspci seems unhappy with what he detects, since all device classes are detected as (and chip revisions as ff). For example, the video chip which normally is : 07:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines (SEP1) (rev 02) becomes : 07:00.0 Class : Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines (SEP1) (rev ff) So the XFree86 PCI detection code seems to have a side effect on the system. It is not a good idea to run two PCI scans simultaneously. And I can think of no way to prevent them. Please note that XFree86 and the Linux kernel show no warning or error messages at all, the only problem is the very long start time for XFree. I tested a previous build of XFree86, including patches up to 4.7.99.5-4.7.99.6.diff.bz2. This version doesn't show the problem. So I digged a little bit in the patches released after this one and I found that some modifications were done at the PCI level. I finally found that the problem is located in 4.7.99.14-4.7.99.15.diff.bz2, more precisely in the xc/programs/Xserver/hw/xfree86/os-support/bus/Pci.c file (which includes the PCI detection loop). I suppressed the modifications on Pci.c from the 4.7.99.14-4.7.99.15.diff.bz2 patch, rebuilded XFree86 and the problem doesn't occur now. So it is related to the recent modifications on the PCI code. But I don't know where the problem exactly occurs in this file. I don't have the time to track line by line and I had to give the computer to someone else for a couple of weeks. I suspect this is happening because these systems are capable of PCI Express. Please try the attached patch when you get the system back. It would be sufficient to check if the slowdown still occurs with the resulting scanpci binary. Thanks. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. Mahe.diff.gz Description: Binary data
Re: Re Re: missing ATI chips in radeon_probe.c ?
On Wed, 30 Apr 2008, [EMAIL PROTECTED] wrote: Please note that I didn't test if these boards worked actually ! I'm only making suggestions and these reasonings may be wrong ! Yes. I understood that. 1) I've reworked my list. I'd still like to know where your original list came from. 2) Now, looking at radeon_probe.c, we can note that some boards in your list have chips which are not in the list of the radeon(4x) man page. So either the man page should be updated or this is a mistake ? Dunno. Not surprising though, given this was a merge from X.Org. RC410 : - 0x1002 0x5a61 ATI|RC410 [Radeon Xpress 200] - 0x1002 0x5a62 ATI|RC410 [Radeon Xpress 200M] ES1000 : - 0x1002 0x515e ATI|ES1000 - 0x1002 0x5969 ATI|ES1000 According to http://ati.amd.com/products/server/es1000/index.html, ES1000 was designed for servers and has no 3D acceleration (so Option nodri). I agree the driver should know that. RS480 : - 0x1002 0x5954 ATI|RS480 [Radeon Xpress 200G Series] - 0x1002 0x5955 ATI|Radeon XPRESS 200M 5955 (PCIE) RS482 : - 0x1002 0x5974 ATI|RS482 [Radeon Xpress 200] - 0x1002 0x5975 ATI|RS485 [Radeon Xpress 1100 IGP] Note : RS485 is a typo in pci.ids - I told that to the guys on sourceforge. I don't think such lists can ever be 100% reliable. 3) Continuing on that way, these chipsets are of the same type as those in 2) and could perhaps be added too : *0x1002 0x5854 ATI Radeon Xpress Series (RS480) *0x1002 0x5874 ATI Radeon Xpress Series (RS482) *0x1002 0x5a63 ATI Radeon Xpress Series (RC410) Moreover, the following two boards are also ES1000, but are aren't in the supported list, they could perhaps be added if the ES1000 chip is kept in the list : - 0x1002 0x515f ATI|ES1000 - 0x103c 0x31fb HP|DL365 ATI ES1000 VGA controller Note : these chips are not in pci.ids now. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xaa vs. WriteImage()
On Wed, 5 Mar 2008, Michael Lorenz wrote: Otherwise, teaching the framebuffer layer to cope with a tiled framebuffer might be necessary in the long run, any pointers where to start? By design, this is a driver issue, as it is responsible for providing VRAM access to the rest of the server. Really. Now /that/ was helpful. Guess I'm on my own here. Not really. This sounds like the kind of thing that is right up the mibank screen wrapper's alley, assuming the tiles are all the same size. mibank can interoperate with any other screen wrapper (including XAA), except shadowfb, because the later is not a true screen wrapper. An example of the use of mibank can be found in ATIPreInit() and ATIScreenInit(). Mine, that is; not X.Org's lobotomised imitations of same. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xaa vs. WriteImage()
On Mon, 3 Mar 2008, Michael Lorenz wrote:
I noticed the following - XAACopyArea() only attempts to use accelerated
WriteImage() when writing to a DRAWABLE_WINDOW but not on off-screen pixmaps.
I used the following changes to make it work:
diff -u -w -r1.1.1.3 xaaCpyArea.c
- --- xaaCpyArea.c 9 Jun 2001 15:09:02 - 1.1.1.3
+++ xaaCpyArea.c3 Mar 2008 20:51:05 -
@@ -64,9 +64,16 @@
return (XAABitBlt( pSrcDrawable, pDstDrawable,
pGC, srcx, srcy, width, height, dstx, dsty,
XAADoBitBlt, 0L));
+ } else {
+ if(infoRec-ScreenToScreenBitBlt
+CHECK_ROP(pGC,infoRec-ScreenToScreenBitBltFlags)
+CHECK_ROPSRC(pGC,infoRec-ScreenToScreenBitBltFlags)
+CHECK_PLANEMASK(pGC,infoRec-ScreenToScreenBitBltFlags))
+return (XAABitBlt( pSrcDrawable, pDstDrawable,
+ pGC, srcx, srcy, width, height, dstx, dsty,
+ XAADoImageWrite, 0L));
}
}
This does not look correct. Shouldn't this be more in line with the case
where the destination drawable is a window? (i.e. test bitsPerPixel's and
WritePixmap files instead of ScreenToScreenBitBlt).
have fun
Always.
Marc.
+--+--+
| Marc Aurele La France | work: 1-780-492-9310 |
| Academic Information and| fax:1-780-492-1729 |
|Communications Technologies | email: [EMAIL PROTECTED] |
| 352 General Services Building +--+
| University of Alberta | |
| Edmonton, Alberta |Standard disclaimers apply|
| T6G 2H1 | |
| CANADA | |
+--+--+
XFree86 developer and VP. ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: TWM: truetype support
(dpy, font-name)) == NULL)
{
char *deffontname = Scr-DefaultFont.name;
if (deffontname == NULL)
deffontname = fixed;
if ((font-font = XLoadQueryFont(dpy, deffontname)) == NULL)
{
fprintf (stderr, %s: unable to open fonts \%s\ or \%s\\n,
ProgramName, font-name, deffontname);
exit(1);
}
}
font-height = font-font-ascent + font-font-descent;
font-y = font-font-ascent;
font-ascent = font-font-ascent;
font-descent = font-font-descent;
}
This means that, to use Xft, the user would need to specify a font name
that is recognized by XftFontOpenName().
In looking over your latest patch sets, I notice a fair amount of activity
in the Fixes and Appearance ones. Do you now consider them as finalised?
What about SloppyFocus?
I'm attaching a diff, against XFree86 CVS source, of those of your changes
that I have so far integrated.
Lastly, do you intend to update twm's man page?
Thanks.
Marc.
+--+--+
| Marc Aurele La France | work: 1-780-492-9310 |
| Academic Information and| fax:1-780-492-1729 |
|Communications Technologies | email: [EMAIL PROTECTED] |
| 352 General Services Building +--+
| University of Alberta | |
| Edmonton, Alberta |Standard disclaimers apply|
| T6G 2H1 | |
| CANADA | |
+--+--+
XFree86 developer and VP. ATI driver and X server internals.
twm.diff.gz
Description: GNU Zip compressed data
Re: X driver: Using offscreen memory manager for Xv
On Mon, 26 Nov 2007, Bankim Bhavsar wrote: I'm implementing Xv extension of linux X driver. I need to use offscreen memory to allocate space for incoming video-frames. Currently, I am using xf86InitFBManager() part of xf86fbman.h to initialize offscreen memory by specifying a BoxPtr. The offscreen memory is initialized such that it starts just after the on-screen memory (using Frame Buffer Size). When there is a ModeSwitch the Frame Buffer Size changes and the offscreen memory previously allocated becomes a part of the on-screen memory and causes X to crash. I was thinking of re-initalizing the Offscreen memory manager on ModeSwitch and modify the previously allocated pointers accordingly but I don't see a way to re-initialize the offscreen memory. One possible solution would be to leave some space before starting the offscreen memory. That would work for common case but still doesn't guarantee the framebuffer extending into the previously initialized offscreen memory. I also looked into EXA but doesn't seem to serve the purpose either. Am I missing out on something? Any other possible solution? Can someone point me to a driver that uses EXA and handles the offscreen memory on ModeSwitch? No, mode switches are irrelevent. xf86InitFBManager() factors out the _virtual_ resolution, not the physical one. If you are seeing crashes, it's because your driver incorrectly uses a virtual resolution that does not include all physical modes the user can switch to. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: another i810 crash when switching bewteen X and text console
On Mon, 29 Oct 2007, [EMAIL PROTECTED] wrote: Correct me if I'm wrong, but these are not the correct logs. None of them show a segfault, let alone an initially BIOS-reported VideoRAM value of 0. Indeed. Here are now : 4) the logfile displaying the crash when you switch to the text console and back (865patch not started - no VideoRam parameter) 5) the logfile when restarting X after the crash ; here you will find the initially BIOS-reported VideoRAM value of 0 (II) I810(0): VESA VBE Total Mem: 0 kB When you use 865patch, would you happen to be specifying its 'nocheck' parameter? Thanks. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: another i810 crash when switching bewteen X and text console
On Wed, 24 Oct 2007, [EMAIL PROTECTED] wrote: Sorry to be late, but I had to switch to another activity. I made some tests with the lastest build (4.7.99.3). The PC (Dell GX270) is cold-started between each test, since it seems that a simple reboot doesn't reset the BIOS. (Christian) A question to the person who started this thread: Does setting the VideoRam option in the Device section of the XFree86 configuration file to 32000 and not running 865patch help? Test with VideoRam set to 32000 in the config file and 865patch not started. Here are the significant log lines (I can send the whole file upon demand) : (II) I810(0): VESA VBE Total Mem: 8064 kB (WW) I810(0): Detected stolen memory (8000 kB) doesn't match what the BIOS reports (8064 kB) (II) I810(0): Will attempt to tell the BIOS that there is 12288 kB VideoRAM (WW) I810(0): Extended BIOS function 0x5f11 not supported. (II) I810(0): BIOS view of memory size can't be changed (this is not an error) (**) I810(0): VideoRAM: 32000 kByte (--) I810(0): Maximum frambuffer space: 31832 kByte (--) I810(0): Maximum space available for video modes: 8064 kByte (II) I810(0): VESA VBE Total Mem: 0 kB (II) I810(0): BIOS call 0x5f05 not supported, setting refresh with VBE 3 method. What is strange here is the second VESA VBE Total Mem: line, which indicates 0 kB !!! Yes, that's what your prior logs reported. Then, if I switch to the text console and back, the crash is still here : (WW) I810(0): PGTBL_ER is 0x0029 This is new. *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. Caught signal 11. Stack trace: 0: 0x808e796: 0x808e780 xf86ShowStackTrace + 0x16 Module /usr/X11R6/bin/XFree86 1: 0x808e8a8: 0x808e820 xf86SigHandler + 0x88 Module /usr/X11R6/bin/XFree86 2: 0x400828b8: cannot guess 3: 0x40561734: 0x405615c0 I830BIOSEnterVT + 0x174 Module /usr/X11R6/lib/modules/drivers/i810_drv.o Section .text 4: 0x406eb307: 0x406eb2e0 XAAEnterVT + 0x27 Module /usr/X11R6/lib/modules/libxaa.a:xaaInit.o Section .text 5: 0x4073c41a: 0x4073c3f0 xf86CursorEnterVT + 0x2a Module /usr/X11R6/lib/modules/libramdac.a:xf86Cursor.o Section .text 6: 0x810ca6e: 0x810ca40 CMapEnterVT + 0x2e Module /usr/X11R6/bin/XFree86 7: 0x810a7ec: 0x810a7c0 xf86XVEnterVT + 0x2c Module /usr/X11R6/bin/XFree86 8: 0x808eb9f: 0x808e8c0 xf86VTSwitch + 0x2df Module /usr/X11R6/bin/XFree86 9: 0x808e6ae: 0x808e4f0 xf86Wakeup + 0x1be Module /usr/X11R6/bin/XFree86 10: 0x80c645c: 0x80c6420 WakeupHandler + 0x3c Module /usr/X11R6/bin/XFree86 11: 0x80e196a: 0x80e15b0 WaitForSomething + 0x3ba Module /usr/X11R6/bin/XFree86 12: 0x80c00b4: 0x80c0040 Dispatch + 0x74 Module /usr/X11R6/bin/XFree86 13: 0x80d10cb: 0x80d0b30 main + 0x59b Module /usr/X11R6/bin/XFree86 Fatal server error: Server aborting After the crash (without reboot), X starts again (since it's respawned by init) and here are again the significant log lines : (WW) I810(0): Bad V_BIOS checksum (II) I810(0): VESA VBE Total Mem: 0 kB (WW) I810(0): Detected stolen memory (8000 kB) doesn't match what the BIOS reports (0 kB) (II) UnloadSubModule: int10 (II) Loading sub module int10 (II) I810(0): VESA VBE Total Mem: 12288 kB (II) I810(0): Tweak BIOS image to 12288 kB VideoRAM (==) I810(0): VideoRAM: 65536 kByte (--) I810(0): Maximum frambuffer space: 65368 kByte (--) I810(0): Maximum space available for video modes: 12288 kByte (WW) I810(0): Extended BIOS function 0x5f05 failed. So I think the 865patch is still need for the 865G on the Dell GX270. This is not a problem for me, as I previoulsy stated, since at installation time (RedHat's anaconda), the Video Memory isn't always correctly detected (and it's perhaps to confusing for the end-user). So I prefer not to use this configuration option and use the 865patch. (Marc) Indeed. The problem is that zero isn't recognised as a valid TweakMemorySize() return. The attached, which I've already committed, should fix this. I'm not sure, since every time I don't use the 865patch, with or without the VideoRam parameter, I get these messages on the second int10 launch (before drmOpenDevice). (WW) I810(0): Bad V_BIOS checksum (II) I810(0): VESA VBE Total Mem: 0 kB And the crash still occurs after switch to text console and back. Please post the _complete_ log. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1
Re: TWM: truetype support
On Wed, 10 Oct 2007, Eeri Kask wrote: Eeri Kask wrote: (6) twm-1.0.3-diff6.Fixes.tgz Here are bugs I encountered in twm as improving icon manager functionality; some are serious. Such as? Please be more descriptive. (1) In iconmgr.c.diff6 at the end is corrected a bug which leads to *multicolumn* iconmanager window width gradual collapse under certain circumstances while computing 'wwidth'. I observed this while resizing and/or moving the icon manager window and then terminating some client, say xcalc. In that moment the icon manager window gets squeezed unexpectedly showing this bug. I am sure my correction to this problem is not correct, as it only undoes something what gets screwed somewhere else (namely, ip-width seems to have incorrect value on enrty into PackIconManager()). I'll have to study the problem more closely and then suggest a bugfix. OK. I've #if 0'ed it out for now. Let me know when you're ready. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
RE: [Bug 1685] 4.6.0 - sig 11 crash in or under __MESA_destroyBuffer
On Thu, 18 Oct 2007, Marc Aurele La France wrote: On Mon, 15 Oct 2007, John Lumby wrote: On Sun, 14 Oct 2007, John Lumby wrote: Thanks Marc - but it prompted me for pwd. And this id can happily ssh to another system of mine without pwd prompt. date;scp -qp /mnt/super9root/root/core.2856.X11crash.20071003122131 [EMAIL PROTECTED]:.;date;scp -qp /mnt/super9root/usr/X11R6/bin/XFree86.statload [EMAIL PROTECTED]:.;date; Sun Oct 14 22:10:48 EDT 2007 [EMAIL PROTECTED]'s password: Sun Oct 14 22:10:57 EDT 2007 [EMAIL PROTECTED]'s password: Sun Oct 14 22:11:00 EDT 2007 /home/lumby:0 ssh -l lumby date Sun Oct 14 22:19:51 EDT 2007 The problem turned out to be that jlumby wasn't listed in AllowUsers. Please try again. It worked this time; They should be there now (I hope) Thanks. These were (and still are) _most_ informative. I've uncovered a real bug here, one that affects not only GLX Friends, but potentially other extensions also. The bug only occurs on server shutdown or reset. It is a definite candidate for causing this problem, but I can't be sure at this point, given the memory corruption this core file attests to. Fixing it will take some time (on my part). The bug has existed for quite some time, and from what I can tell, still exists not only in our repository, but X.Org's as well. Given that, I request that you update to the LG sources, which you can get by following the instructions at http://xfree86.org/cvs. I hope to have a patch against that source ready for you to try in the next few days. Attached is a preliminary fix. As it turns out, this should also apply to 4.6.0, perhaps even 4.5.0. I say preliminary because this only deals with GLX/Mesa. I consider this instance of the problem to only be the tip of the iceberg of a more general design glitch. To fix that glitch, I'd have to change the order some things are done during server termination or reset. Doing so is likely to break several things which will take some time to go through. This fix does the following: - Fix initialisation of __GLXscreenInfo structures (not directly related to the problem at hand); - Fix Mesa to complain (on stderr), rather than segfault, when an attempt is made to free an unknown buffer; - Do not free all Mesa buffers upon GLX extension closedown. Instead these will be freed later, at FreeAllResources() time, when the drawable privates that reference these buffers are also freed. Please let me know if this fixes the segfault. Please `scp` to your id on my machine a capture of the server's stderr, the resulting /var/log/XFree86.0.log, and, should the server still segfault, another copy of the server binary and core file. Thanks. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. cvs-devel.diff.gz Description: Binary data
RE: [Bug 1685] 4.6.0 - sig 11 crash in or under __MESA_destroyBuffer
On Mon, 15 Oct 2007, John Lumby wrote: On Sun, 14 Oct 2007, John Lumby wrote: Thanks Marc - but it prompted me for pwd. And this id can happily ssh to another system of mine without pwd prompt. date;scp -qp /mnt/super9root/root/core.2856.X11crash.20071003122131 [EMAIL PROTECTED]:.;date;scp -qp /mnt/super9root/usr/X11R6/bin/XFree86.statload [EMAIL PROTECTED]:.;date; Sun Oct 14 22:10:48 EDT 2007 [EMAIL PROTECTED]'s password: Sun Oct 14 22:10:57 EDT 2007 [EMAIL PROTECTED]'s password: Sun Oct 14 22:11:00 EDT 2007 /home/lumby:0 ssh -l lumby date Sun Oct 14 22:19:51 EDT 2007 The problem turned out to be that jlumby wasn't listed in AllowUsers. Please try again. It worked this time; They should be there now (I hope) Thanks. These were (and still are) _most_ informative. I've uncovered a real bug here, one that affects not only GLX Friends, but potentially other extensions also. The bug only occurs on server shutdown or reset. It is a definite candidate for causing this problem, but I can't be sure at this point, given the memory corruption this core file attests to. Fixing it will take some time (on my part). The bug has existed for quite some time, and from what I can tell, still exists not only in our repository, but X.Org's as well. Given that, I request that you update to the LG sources, which you can get by following the instructions at http://xfree86.org/cvs. I hope to have a patch against that source ready for you to try in the next few days. Thanks for your patience. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: TWM: truetype support
function. That sounds reasonable. P.S. The f.hideiconmgr case above is badly implemented as well, I'll correct this next time: we don't have to move the mouse if we are already in the correct client window. Right. One more thing, before I forget (again). The man page should be updated accordingly. Thanks. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. cvs-devel.diff.gz Description: Binary data
Re: TWM: truetype support
On Wed, 10 Oct 2007, Eeri Kask wrote: Eeri Kask wrote: (6) twm-1.0.3-diff6.Fixes.tgz Here are bugs I encountered in twm as improving icon manager functionality; some are serious. Such as? Please be more descriptive. (1) In iconmgr.c.diff6 at the end is corrected a bug which leads to *multicolumn* iconmanager window width gradual collapse under certain circumstances while computing 'wwidth'. I observed this while resizing and/or moving the icon manager window and then terminating some client, say xcalc. In that moment the icon manager window gets squeezed unexpectedly showing this bug. I am sure my correction to this problem is not correct, as it only undoes something what gets screwed somewhere else (namely, ip-width seems to have incorrect value on enrty into PackIconManager()). I'll have to study the problem more closely and then suggest a bugfix. OK. Thanks for letting me know. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: TWM: truetype support
On Wed, 10 Oct 2007, Marc Aurele La France wrote: I'm attaching a context diff of what I've done on this so far. It is against our main CVS repository as it stands now. Note that, as of this writting, our publicly accessible repository mirror has yet to be sync'ed (but it should be sometime today). This includes (among other odds ends): - your first change (MyFont_ChangeGC); - my rework of your second change (TWM_USE_XFT); - two non-spacing changes I found in your third batch (Spacing); - the XSetClassHint() and DefaultFont changes from your fifth batch (Appearance); - your seventh change (Improvements). This is not yet ready to commit. Oops. Use this one instead. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. cvs-devel.diff.gz Description: Binary data
Re: TWM: truetype support
On Mon, 1 Oct 2007, Eeri Kask wrote: Here are patchsets (against Xorg twm release 1.0.3) completing and polishing Xft support for twm (and improving the icon manager): (1) twm-1.0.3-diff1.MyFont_ChangeGC.tgz to my knowing has not changed from last time: cleans up bitmap font drawing. OK. (2) twm-1.0.3-diff2.TWM_USE_XFT.tgz introduces Xft support (replaces bitmap text rendering functions with xft-font rendering). [Compile with -DTWM_USE_XFT to activate.] This leaks memory in the form of XftDraw structures that never get released. I've reworked this to fix that problem, and also to re-instate core font support even if TWM_USE_XFT is #define'd. If a font cannot be found through libXft, it will be looked for through the older standard mechanism. (3) twm-1.0.3-diff3.Spacing.tgz (Vertical) spacing corrections; having scalable fonts one should use scalable spacing as well, otherwise one day having 600x600 dpi screen vertical spacing of, e.g. 4 pixels, results in text line distance of zero. Now baseline skip is computed like 1.2 times font height or something. I would prefer that this be done only for Xft fonts, or, better, be made configurable. Maybe here some spacing corrections need to be done as some ttf-fonts may include bad metrics. I have mostly tested with bitstream vera fonts. (E.g. Apple's Lucida Grande looks vertically definitely too tight.) I don't believe fonts with bad metrics should be dealt with in twm. (4) twm-1.0.3-diff4.TWM_USE_OPACITY.tgz If you value transparency in twm menus and icon manger/icons, apply this. This patchset introduces MenuOpacity and IconOpacity keywords having integer values in range 0...255. [Enable with -DTWM_USE_OPACITY] As stated previously, this will not be integrated as it relies on X.Org-specific functionality. (5) twm-1.0.3-diff5.Appearance.tgz Here lies probably the most radical change I have made to twm: the iconmanager painting DrawIconManagerBorder() is now DrawIconManagerEntry() and draws the iconmanager entry in full. This work is not completed yet. I'm inclined to delay this one until it is complete. This patchset introduces DefaultFont keyword. The default font was up to now like some orphan parameter not configurable by the user and in the same time used prominently in rendering InfoWindow/SizeWindow text. (Letting it be fixed as in bitmap rendering would cause twm become non-usable in whole as XftFontOpenXlfd() (at least the installed library I have to use) is not able to load that font, so something needed to be done anyway. Lacking any better idea now by default DefaultFont is set to mono-10 if XFT is compiled in.) My rework of your second change fixes this. (6) twm-1.0.3-diff6.Fixes.tgz Here are bugs I encountered in twm as improving icon manager functionality; some are serious. Such as? Please be more descriptive. (7) twm-1.0.3-diff7.Improvements.tgz Here are some improvements to the icon manager. The old behaviour is kept as long as WarpCursor is not defined: actually the meaning of this variable is broadened in the sense that everywhere where warping mouse makes sense, this is done: (*) if some client window has focus and this client opens a transient window, then mouse is transfered there; like in password prompt and file-open dialogs (this is a valuable idea from vtwm); (*) if iconifying some client window and the icon manager is currently mapped, the mouse is transfered into the corresponding icon manager entry; (*) if executing f.hideiconmgr transfer mouse into the corresponding client if some iconmanager entry was active. (*) iconmanager navigation functions raise the corresponding client windows as stepping around entries. OK, except that, as you currently have it coded, that last one does not depend on WarpCursor. Is that intentional? P.P.S. How to put TWM_USE_XFT, TWM_USE_OPACITY into autoconfig or Imake if you are interested please kindly help as not coming from software development it is a little complicated. (Few weeks ago I only learned how to use 'diff'.) :-) The automangle suite isn't a concern here, and my integration of these changes, as it currently stands, already takes care of imake. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals
Re: another i810 crash when switching bewteen X and text console
On Tue, 2 Oct 2007, Marc Aurele La France wrote: On Mon, 1 Oct 2007 [EMAIL PROTECTED] wrote: Complete logfiles are attached (I recall this is a Dell Optiplex GX270). Thanks for the logs. So it seems that the builtin patch doesn't work here. Indeed. The problem is that zero isn't recognised as a valid TweakMemorySize() return. The attached, which I've already committed, should fix this. The rest of the driver might not like saveBIOSMemSize being set to one, so here's a slight correction. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. cvs-devel.diff.gz Description: Binary data
Re: another i810 crash when switching bewteen X and text console
On Mon, 1 Oct 2007 [EMAIL PROTECTED] wrote: Complete logfiles are attached (I recall this is a Dell Optiplex GX270). Thanks for the logs. So it seems that the builtin patch doesn't work here. Indeed. The problem is that zero isn't recognised as a valid TweakMemorySize() return. The attached, which I've already committed, should fix this. Thanks. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. cvs-devel.diff.gz Description: Binary data
Re: TWM: truetype support
On Mon, 1 Oct 2007, Eeri Kask wrote: Marc Aurele La France: The point of using XListFonts() is that it'll resolve fixed variable to their respective XLFDs which can then be passed to XftFontOpenXlfd(). I have installed Xorg 7.2.0 release and here XListFonts() returns fixed if called with fixed, which XftFontOpenXlfd() unfortunately cannot load. Maybe this is a bug in XftFontOpenXlfd() or in XListFonts(), it actually doesn't matter; but as long as it is so coding fixed as a default (at least for 7.2.0) is very inconvenient for the end user (as there is as is no DefaultFont keyword to change the default font), in fact resulting in twm being unusable. Some possible solutions: (1) agree on a different than fixed font which XftFontOpenXlfd() in all X11-implementations can definitely load; (2) let mono-10 or some other ttf-font be the default if XFT is compiled in. (1) makes not that much sense in the case one has to drop fixed anyway. There is a third option: change TWM_USE_XFT to TWM_ALLOW_XFT and make the use of libXft configurable (default to no), instead of forcing it. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: TWM: truetype support
On Fri, 28 Sep 2007, Eeri Kask wrote:
As quick answer, I'd take two good ideas from you suggestion instantly:
(1) Use XListFonts() instead of XLoadQueryFont() to test if a font is
available;
No. It is to test if it is a core font.
(2) Use DefaultFont as a first fallback if requested font could not be
loaded. (I don't know if it makes sense to give a stderr warning that
the requested font could not be found and a replacement was needed?)
The !defined(TWM_USE_XFT) case doesn't. Both cases should be consistent.
Regarding the issue of fixed/variable -- mono-10/sans-10 I'd
suggest to find out how XftFontOpenXlfd() is per definition _supposed_
to work if called with fixed or variable. Now my installed Xft
library crashes twm in whole; but irrespective to that, if
XftFontOpenXlfd() is supposed or is free to choose a random replacement
(as not being able to load fixed for example), then initialising to
mono-10 instead of fixed makes sense as the outcome to the user is
kind of more deterministic. This is a matter of opinion/taste, and in
the end a minor issue.
The point of using XListFonts() is that it'll resolve fixed variable
to their respective XLFDs which can then be passed to XftFontOpenXlfd().
void
GetFont(font)
MyFont *font;
{
#ifdef TWM_USE_XFT
char **fontlist;
int listcount;
if (font-font != NULL)
XftFontClose(dpy, font-font);
GetFont() is only called on screen initialisation in CreateFonts() and
the font-font variable is priorly initialised to NULL; this is
guaranteed. So the 'if' test here --- if passing --- would hide some
programming error somewhere else, if I am correct... :-)
Again, look at the !defined(TWM_USE_XFT) code.
Marc.
+--+--+
| Marc Aurele La France | work: 1-780-492-9310 |
| Academic Information and| fax:1-780-492-1729 |
|Communications Technologies | email: [EMAIL PROTECTED] |
| 352 General Services Building +--+
| University of Alberta | |
| Edmonton, Alberta |Standard disclaimers apply|
| T6G 2H1 | |
| CANADA | |
+--+--+
XFree86 developer and VP. ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: TWM: truetype support
On Wed, 26 Sep 2007, Eeri Kask wrote: Eeri Kask wrote: Wait, please, don't commit yet! :-) Here are my current twm improvement patches, organised thematically: [...] (3) Introduces twm menu and iconmanager (and icon) transparency, introducing two keywords: MenuOpacity, IconOpacity (in range 0 = transparent ... 255 = opaque). Effectively it will be compiled in only if set '#define TWM_USE_OPACITY'. It adds no complexity to twm as it only sets the window opacity property and as long you don't run something like xcompmgr -c -o 0.5 -r 6 -t -6 -l -9 in the background, this has no effect on anything. I found two keywords the only solution as menus and icons have too different transparency values in order to configure them with one keyword. I have MenuOpacity 245 and IconOpacity 200 in .twmrc. This one is X.Org-specific as it relies on an extension not provided by XFree86. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: TWM: truetype support
On Wed, 26 Sep 2007, Eeri Kask wrote: Marc Aurele La France wrote: On Tue, 18 Sep 2007, Eeri Kask wrote: [] So compile with -DTWM_USE_XFT -I/usr/include/freetype2 -lXft Then insert TitleFontsans-9 MenuFontsans-9 IconFontsans-9:bold IconManagerFontsans-9 ResizeFontsans-10:bold If you are a twm user, please test it; what do you think? :-) I have refit this to our current source. However, I don't think the default fonts `twm` uses should be changed as doing so will surprise many users. It appears that restoring the previous defaults would only require additional changes to InitVariables() in twm.c and GetFont() in util.c. Comments? Marc. Wait, please, don't commit yet! :-) In the meanwile I have done some minor cosmetic improvements to the Xft inclusion and now I am in two days ready to release these (I renamed two macros, as being no english native speaker these looked stupid in the first iteration). That is, I am in fact right now ready to release these improvements, but additionally I have done some one-liner corrections to text spacing everywhere in rendering as well, so that all menu items, icon captions, iconmanager window label texts and so on look considerably better spaced. In the sense, that vertical spacing now goes proportionally to the font height and not by a fixed amount like font height plus 4 pixels etc. (but 1.2 times font height, and the like). It really goes hand in hand with using scalable fonts: one also has to have scalable spacing as well! :-) These improvements are indeed finished too. Two days I want to spend on completeing a small focus tweak: if and only if some client window has focus and this client opens a transient window (like thunderbird password prompt, or some file-open dialogue), then the mouse should be warped into that window. I am thinking how to do this best using as much existing twm code and functionality as possible; and it also remains to decide if it makes sense to invent a new keyword like WarpToTransients as in vtwm to that purpose, to retain old behaviour if the user so wishes. Then I also found a serious bug and fixed a multicolumn iconmanager geometry problem (in Xorg 1.0.3 twm release): if mapped and one moves that iconmanager window then its width gets corrupted during next packing. It was a small thinking error in PackIconManager() in iconmgr.c while computing wwidth, it should/could be something like wwidth = (ip-first ? (ip-first-width 0 ? ip-first-width : ip-width/ip-columns) : 150); These above improvements are unrelated to xft-support in twm though. So actually I didn't quite understand you what do you mean by preserving default fonts twm uses? Currently twm uses fixed and variable in twm.c as default fonts if no fonts are specified in .twmrc. Next, if some font failed to load, then fixed is (unrelated to InitVariables() in twm.c) tried in util.c as a fallback. So by the way, the DefaultFont as initialised in twm.c is actually never used as a fallback, this font is used only to render infowindow text! (It should be called InfoFont instead, but let it be DefaultFont as it is; we have DefaultForeground and DefaultBackground as colours as well and nobody actually knows for what purpose: to draw size- and infowindows.) Much more important is that one can specify DefaultFont in .twmrc which needs to be fixed (and already is :-). I am afraid we need to change fixed and variable in twm.c if Xft is included because xft-subsystem crashes (at least mine) if one uses these in XftFontOpenXlfd(), probably because these names are not XLFD-compliant. (xft should not crash because of that, but it is xft's problem, not ours.) So as long as default font names (or user-specified font names in .twmrc) are xlfd-conform one can use these as usual, in that regard nothing has changed. If I am correct the choice of fixed as a default font is always justified by the fact that this font is guaranteed present in every X11 installation and so it is a very reasonable decision. Concerning xft I believe having read Keith Packard sans, serif and mono should be expected included in every xft installation, so I chose sans-10 and mono-10 as a replacement for variable and fixed in twm.c. This is the story to that decision. :-) Greetings, Eeri Kask +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA
Re: another i810 crash when switching bewteen X and text console
On Wed, 12 Sep 2007, [EMAIL PROTECTED] wrote: I've noticed this with the Intel 865G chipset (i810 driver) on XFree86 4.7.0 (Linux, 2.4.35 kernel). I've got two different machines with this chipset. In both cases, the BIOS is set-up for using 8MB of VRAM (this memory is taken from the RAM). 1) industrial PC : 8085:2572 with subvendor/device 8086:4246 (Intel 865 GBF motherboard) Here there is no crash. 2) Dell GX270 : 8086:2572 with subvendor/device 1028:0151 (Dell motherboard) Here X crashes when switching to text console and back to X. It seems that the Dell BIOS mismanages something ... The solution I found to avoid this crash is to use 865patch (available at http://www.chzsoft.com.ar/855patch.html) and set the VRAM to 32000 (for example) before starting X. I think this could be mentionned in the release-notes and/or i810 man page. IMHO the same information could be given for the Intel 845G (eg apply 845patch). The driver already does this for some chips. Can you produce a patch to the driver that extends this to other chip revisions? I have little experience with this driver and no hardware that I could use to test such a change. Thanks. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: possible case-sensitive problems during building
On Sat, 4 Aug 2007, Marc Aurele La France wrote: On Sat, 4 Aug 2007, SciFi wrote: I'm trying to build the current cvs on a case-sensitive HFS+ volume (darwin/osx). In my particular case, the build volume BigUn3 is case-sensitive, while the system/boot/root/install volume itself is not. (Apple preinstalls OSX onto a non-case-sensitive format, so this _is_ a very common case.) Building xf86 stumbles in certain places -- one is shown here: # pwd /Volumes/BigUn3/Projects/xf86_cvs/build/programs/Xserver/Xprint # make make: Entering directory `/Volumes/BigUn3/Projects/xf86_cvs/build/programs/Xserver/Xprint' rm -f Util.o /usr/bin/cc -c -Os -g -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -no-cpp-precomp -UNEED_SCREEN_REGIONS -I. -I../../../programs/Xserver/mfb -I../../../programs/Xserver/mi -I../../../programs/Xserver/cfb -I../../../programs/Xserver/Xext -I../../../programs/Xserver/include -I../../../lib/X11 -I../../../exports/include-D__i386__ -D__DARWIN__ -DNO_ALLOCA -DCSRG_BASED -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DXSYNC -DXF86BIGFONT-DBIGREQS -DPANORAMIX -DRENDER -DRANDR -DRES -DPIXPRIV -DNDEBUG -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFree86Server-DSMART_SCHEDULE -DBUILDDEBUG -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DDDXOSINIT -DSERVER_LOCK -DDDXOSFATALERROR -DDDXOSVERRORF -DMITSHM -DMITMISC -DXTEST -DXTRAP -DXCMISC -DXRECORD -DTOGCUP -DDBE -DEVI -DSCREENSAVER -DXV -DXVMC -DGLXEXT -DGLX_DIRECT_RENDERING -DGLX_USE_APPLEGL -fno-common -DFONTCACHE -UXINPUT -UXKB -UDPMSExtension -UPANORAMIX -UGLXEXT -UXF86DRI -UXF86VIDMODE-UXF86MISC -UXFreeXDGA -UXTESTEXT1 -USCREENSAVER -UXV -UXVMC -UXFree86LOADER -D_XP_PRINT_SERVER_ -DXPRINTDIR=\/usr/X11R6/lib/X11/xserver\ -DXPRASTERDDX -DXPPCLDDX -DXPPSDDX util.c i686-apple-darwin8-gcc-4.0.1: util.c: No such file or directory i686-apple-darwin8-gcc-4.0.1: no input files make: *** [Util.o] Error 1 make: Leaving directory `/Volumes/BigUn3/Projects/xf86_cvs/build/programs/Xserver/Xprint' # ls -al total 348 drwxr-xr-x 36 root scifi 1224 2007-07-28 17:48 . drwxr-xr-x 47 root scifi 1598 2007-07-28 17:33 .. lrwxr-xr-x 1 root scifi50 2007-07-28 17:21 AttrValid.c - ../../../../xc/programs/Xserver/Xprint/AttrValid.c lrwxr-xr-x 1 root scifi50 2007-07-28 17:21 AttrValid.h - ../../../../xc/programs/Xserver/Xprint/AttrValid.h lrwxr-xr-x 1 root scifi48 2007-07-28 17:21 DiPrint.h - ../../../../xc/programs/Xserver/Xprint/DiPrint.h lrwxr-xr-x 1 root scifi48 2007-07-28 17:21 Imakefile - ../../../../xc/programs/Xserver/Xprint/Imakefile lrwxr-xr-x 1 root scifi45 2007-07-28 17:21 Init.c - ../../../../xc/programs/Xserver/Xprint/Init.c -rw-r--r-- 1 root scifi 72476 2007-07-28 17:48 Init.o -rw-r--r-- 1 root scifi 70830 2007-07-28 17:36 Makefile -rw-r--r-- 1 root scifi 33270 2007-07-28 17:33 Makefile.bak lrwxr-xr-x 1 root scifi44 2007-07-28 17:21 Oid.c - ../../../../xc/programs/Xserver/Xprint/Oid.c lrwxr-xr-x 1 root scifi44 2007-07-28 17:21 Oid.h - ../../../../xc/programs/Xserver/Xprint/Oid.h lrwxr-xr-x 1 root scifi48 2007-07-28 17:21 OidDefs.h - ../../../../xc/programs/Xserver/Xprint/OidDefs.h lrwxr-xr-x 1 root scifi48 2007-07-28 17:21 OidStrs.h - ../../../../xc/programs/Xserver/Xprint/OidStrs.h lrwxr-xr-x 1 root scifi25 2007-07-28 17:34 Quarks.c - ../../../lib/X11/Quarks.c -rw-r--r-- 1 root scifi 7036 2007-07-28 17:48 Quarks.o lrwxr-xr-x 1 root scifi45 2007-07-28 17:21 Util.c - ../../../../xc/programs/Xserver/Xprint/Util.c lrwxr-xr-x 1 root scifi48 2007-07-28 17:21 ValTree.c - ../../../../xc/programs/Xserver/Xprint/ValTree.c drwxr-xr-x 10 root scifi 340 2007-07-28 17:36 XTrap drwxr-xr-x 44 root scifi 1496 2007-07-28 17:36 Xext lrwxr-xr-x 1 root scifi51 2007-07-28 17:21 attributes.c - ../../../../xc/programs/Xserver/Xprint/attributes.c lrwxr-xr-x 1 root scifi51 2007-07-28 17:21 attributes.h - ../../../../xc/programs/Xserver/Xprint/attributes.h -rw-r--r-- 1 root scifi 91724 2007-07-28 17:48 attributes.o drwxr-xr-x 8 root scifi 272 2007-07-28 17:36 dbe lrwxr-xr-x 1 root scifi48 2007-07-28 17:21 ddxInit.c - ../../../../xc/programs/Xserver/Xprint/ddxInit.c drwxr-xr-x 29 root scifi 986 2007-07-28 17:36 dix lrwxr-xr-x 1 root scifi51 2007-07-28 17:21 mediaSizes.c - ../../../../xc/programs/Xserver/Xprint/mediaSizes.c lrwxr-xr-x 1 root scifi40 2007-07-28 17:34 miinitext.c - ../../../programs/Xserver/mi/miinitext.c drwxr-xr-x 27 root scifi 918 2007-07-28 17:36 os drwxr-xr-x 28 root scifi 952 2007-07-28 17:36 pcl drwxr-xr-x 3 root scifi 102 2007-07-28 17:21 pcl-mono drwxr-xr-x 27 root scifi 918 2007-07-28 17:36 ps drwxr-xr-x 7 root scifi 238 2007-07-28 17:36 randr drwxr-xr-x 8
Re: ANNOUNCE: XFree86 4.7.0 is now available
On Mon, 20 Aug 2007, Yves de Champlain wrote: I'm trying to install hardcopy docs I set #define InstallHardcopyDocs YES in host.def but it won't do it. What am I missing ? You also need to #define HardcopyDocDirs. There is no default. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: ANNOUNCE: XFree86 4.7.0 is now available
On Sun, 19 Aug 2007, Yves de Champlain wrote: Le 07-08-19 à 19:41, Yves de Champlain a écrit : Congrats for the new release ! Thanks. I am geting this problem MacOS X 10.4.10 PPC with gcc 4.0.1 /usr/bin/cc -c -Wall -Wpointer-arith -no-cpp-precomp -fno-common -I. -I../../../extras/Mesa/include-I../../../lib/GL/glx -I../../../extras/Mesa/src/mesa/main -I../../../extras/Mesa/src/mesa/glapi -I../../../extras/Mesa/src/mesa/drivers/x11 -I../../../extras/Mesa/src/mesa/ -I../../../programs/Xserver/hw/xfree86/os-support/shared/drm/kernel -I../../../programs/Xserver/GL/dri -I../../../programs/Xserver/hw/xfree86/os-support -I../../../exports/include -I/Users/Shared/MacPorts/build/_Users_Shared_MacPorts_dports_x11_XFree86/work/include -D__powerpc__ -D__DARWIN__ -DNO_ALLOCA -DCSRG_BASED-DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -DXNO_MTSAFE_UNISTDAPI-DGLXEXT -DGLX_DIRECT_RENDERING -DGLX_USE_APPLEGL -fno-common -DDEFAULT_DRIVER_DIR=\/usr/X11R6/lib/modules/dri\ -DGLX_ALIAS_UNSUPPORTED -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -DXNO_MTSAFE_UNISTDAPI -Os -fno-strict-aliasing glxcmds.c -o unshared/glxcmds.o glxcmds.c:50:38: error: X11/extensions/xf86vmode.h: No such file or directory This comes from this part of xc/lib/GL/glx/glxcmds.c #ifdef GLX_DIRECT_RENDERING #include indirect_init.h #include X11/extensions/xf86vmode.h #endif Cute. In my test builds, the header was found in /usr/include/X11 :-( I've dug a little deeper and xf86vmode.h is not exported. This should happen here in xc/include/extensions/Imakefile : #if BuildXF86VidModeExt || BuildXF86VidModeLibrary XF86VIDMODEHEADERS = xf86vmode.h xf86vmstr.h #endif The first is disabled in darwin.cf : /* no XFree86-VidMode extension */ #define BuildXF86VidModeExt NO The second should be defined in xfree86.cf : #ifndef BuildXF86VidModeLibrary #define BuildXF86VidModeLibrary YES #endif This looks contradictory to me, so I don't know what is the best solution No. That xfree86.cf snippet is protected by ... #if BuildXFree86ConfigTools BuildLibrariesForConfigTools ... which is false on Darwin. Anyway, the attached seems to fix this. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. GLX_VIDMODE.diff.gz Description: Binary data
ANNOUNCE: XFree86 4.7.0 is now available
We are very pleased to announce the release of XFree86 4.7.0. This release comes about a year after the 4.6.0 release, and is the product of the work of dedicated volunteers. We would like to thank all who have contributed to this release, through code, testing, and other feedback, and all who continue to support XFree86 and the work of its volunteer developers. Source, patches, and binaries for a range of platforms are now available for download from our ftp site: ftp://ftp.xfree86.org/pub/XFree86/4.7.0/ http://ftp.xfree86.org/pub/XFree86/4.7.0/ We currently have binaries available for a number of platforms. More will become available over time. If you are not sure which binary set you need, first download the Xinstall.sh script, and run: sh Xinstall.sh -check Also, before downloading, check the 4.7.0 online documentation at: http://www.xfree86.org/4.7.0/ Read especially the README, Release Notes and Install documents. Also check the ERRATA for 4.7.0 for any last minute issues: http://www.xfree86.org/4.7.0/ERRATA.html and the UPDATES page to see when new binaries or other updates are available: http://www.xfree86.org/4.7.0/UPDATES.html The CVS tag for this release is xf-4_7_0. Information about accessing our anonymous CVS service is at http://www.xfree86.org/cvs/. User-related problems should be reported to our [EMAIL PROTECTED] list. Development issues and specific bugs should be reported to our devel@xfree86.org list and/or logged at http://bugs.xfree86.org/. The next release, 4.8.0, is planned for the second half of 2008. If you find XFree86 useful and would like to help support our work, please visit our donations page: http://www.xfree86.org/donations/ Enjoy. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: possible case-sensitive problems during building
drwxr-xr-x 3 root scifi 102 2007-07-28 17:21 pcl-mono drwxr-xr-x 27 root scifi 918 2007-07-28 17:36 ps drwxr-xr-x 7 root scifi 238 2007-07-28 17:36 randr drwxr-xr-x 8 root scifi 272 2007-07-28 17:36 raster drwxr-xr-x 8 root scifi 272 2007-07-28 17:36 record drwxr-xr-x 16 root scifi 544 2007-07-28 17:36 render The lower-case 'util.c' string is not in this subdir's Imakefile or Makefile; So, how could `make` have spawned a command line with 'util.c', not respecting the Makefile's reference to 'Util.c'? This is also wildly inconsistent. No complaints about Init.[co] and Quarks.[co], for example. Ditto for your problem under lbxproxy/di. in fact I can't grep for it without finding a few hundred other hits i.e. which one's this one. ;) I think you might have to wade through those anyway. Even if it is our problem, it'll have to wait until 4.7.0 is released. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Passing calibrated values to XFree86 input driver
On Fri, 13 Jul 2007, Pankaj S wrote: Can anyone tell me how to read XF86Config file from an XFree86 driver? This is for the purpose of reading calibrated values from a touchscreen driver. There are several input drivers that process options in their Init() entry. Perhaps you can use these as an example. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Re Re: patch 4.6.99.26-4.6.99.27.diff.bz2 fails
On Mon, 9 Jul 2007, Marc Aurele La France wrote: On Mon, 9 Jul 2007, [EMAIL PROTECTED] wrote: I don't understand what you're getting at, as the patch contains no changes to any Makefile. Sorry, it wasn't very clear. Yes indeed, but it does make changes to the corresponding Imakefiles and this seems sufficient to break things. I still use the same config file and I simply added this patch to the list in the .spec file. The error does not occur when applying the patch, but during the compilation. Hummm. Please send me that .spec file (privately). That .spec file applies additional changes, some of which are no longer needed. In this case, it's patch 40002 that fails, not the 4.6.99.[26-27] diff. In any case, XFree86 cannot be expected to support any additional changes made to its sources. So, you're on your own on this one. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Re Re: patch 4.6.99.26-4.6.99.27.diff.bz2 fails
On Mon, 9 Jul 2007, [EMAIL PROTECTED] wrote: I don't understand what you're getting at, as the patch contains no changes to any Makefile. Sorry, it wasn't very clear. Yes indeed, but it does make changes to the corresponding Imakefiles and this seems sufficient to break things. I still use the same config file and I simply added this patch to the list in the .spec file. The error does not occur when applying the patch, but during the compilation. Hummm. Please send me that .spec file (privately). Thanks. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Re patch 4.6.99.17-4.6.99.18.diff.bz2 breaks i810 driver on Dell machines
On Tue, 3 Jul 2007, [EMAIL PROTECTED] wrote: Thanks for the output. I'm almost certain I know what the problem is, but I'd like to confirm my hunch. Please send me a copy of this system's /proc/bus/pci/devices file. Here it is (I replaced tab by spaces). Thanks. This confirms my hunch. I've just committed a change to fix this. It'll show up tomorrow (CVSWeb, cvsup, etc.) and in 4.6.99.27. Thanks. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Re Re: problems with several patches
On Tue, 3 Jul 2007, [EMAIL PROTECTED] wrote: Hummm. Please send me a copy of the host.def you're using. Here is is attached. Thanks. This helps. This host.def is created during the RPM %setup phase (after applying patches). I'm using RedHat's XFree86 4.3.0 specfile with some minor local modifications. Maybe I should watch this file closely as XFree86 evolves ? No, that host.def file is fine as it is. I've just committed changes to fix the xterm and install.sdk issues you brought up. That leaves us with with the freetype2 problem. Please send me the following files from your build: xc/lib/font/FreeType/Makefile xc/lib/font/FreeType/module/Makefile As these are fairly large, please send them to me privately, not to the list. Thanks. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Re patch 4.6.99.17-4.6.99.18.diff.bz2 breaks i810 driver on Dell machines
On Mon, 2 Jul 2007, [EMAIL PROTECTED] wrote: Without the output from `scanpci -v -v` that I asked you for, there is nothing I can rework it to. This is strange, my second message, submitted on 22/06, was sent by the list only on 30/06, along with you first answer. This is the reason I didn't saw the question about the scanpci. Yes, there appears to have been a glitch in our mailing lists, which seems to have been resolved now. Anyway, here it is (on the Dell GX270). This is the scanpci shipped with the faulty XFree86, which displays the INVALID IO ALLOCATION error. Thanks for the output. I'm almost certain I know what the problem is, but I'd like to confirm my hunch. Please send me a copy of this system's /proc/bus/pci/devices file. Thanks. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: problems with several patches
On Mon, 2 Jul 2007, [EMAIL PROTECTED] wrote: This seems to imply that your host.def is such that both InstallXtermSet[GU]ID end up set to NO. Is this so? With the patch 4.6.99.3-4.6.99.4.diff.bz2 modified to remove the changes on xc/programs/xterm/Imakefile, in order to have xterm builded, I find neither InstallXtermSetGID or InstallXtermSetUID. I reverted to the original 4.6.99.3-4.6.99.4.diff.bz2 patch and host.def is still the same. What compiler version does Red Hat 7.2 install? I forget. gcc 2.96 Hummm. Please send me a copy of the host.def you're using. Thanks. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: problems with several patches
On Mon, 11 Jun 2007, [EMAIL PROTECTED] wrote: I'm building XFree86 4.6+patches on a RedHat 7.2 basis (yes, I know this is OLD). The following patches are causing errors : 1) 4.6.99.3-4.6.99.4.diff.bz2 : the xterm binary is not created There is no install:: line for xterm in the Makefile. This seems to imply that your host.def is such that both InstallXtermSet[GU}ID end up set to NO. Is this so? 2) 4.6.99.23-4.6.99.24.diff.bz2 : compilation error for ftfuncs.c (freetype) : ftfuncs.c:45:10: #include expects FILENAME or FILENAME ftfuncs.c:46:10: #include expects FILENAME or FILENAME ftfuncs.c:47:10: #include expects FILENAME or FILENAME ftfuncs.c:48:10: #include expects FILENAME or FILENAME ftfuncs.c:49:10: #include expects FILENAME or FILENAME ftfuncs.c:50:10: #include expects FILENAME or FILENAME ftfuncs.c:51:10: #include expects FILENAME or FILENAME ftfuncs.c:52:10: #include expects FILENAME or FILENAME The error seems to come from several include lines ; here is the first one : #include FT_FREETYPE_H FT_FREETYPE_H (and the other macros) should be expanded to a filename, but doesn't ... What compiler version does Red Hat 7.2 install? I forget. 3) 4.6.99.23-4.6.99.24.diff.bz2 : missing layer.h file installing driver SDK in programs/Xserver/miext/layer/module... make[5]: Entering `/home/rpm/BUILD/XFree86-4.6.0/xc/programs/Xserver/miext/layer/module' install -c liblayer.a /home/rpm/tmp/XFree86-4.6.0-root/usr/X11R6/lib/Server/modules/. install -c -m 0444 layer.h /home/rpm/tmp/XFree86-4.6.0-root/usr/X11R6/lib/Server/include install: cannot stat `layer.h': No such file or directory In fact, both miext/layer/Makefile and miext/layer/module/Makefile try to install layer.h But the file in only in the first directory. This is an oversight, which I'll fix shortly. Thanks. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Re patch 4.6.99.17-4.6.99.18.diff.bz2 breaks i810 driver on Dell machines
On Fri, 22 Jun 2007, [EMAIL PROTECTED] wrote: Okay, more investigation on this error. I noticed the same message (INVALID IO ALLOCATION) in the logfile for another chipset (ATI Technologies Inc RS480 [Radeon Xpress 200G Series]) on a Nec VL350 computer. I noticed a beep when starting XFree86, which this time doesn't fail. This beep probably comes from the BIOS. I tested again on the Dell GX270 and Dell GX280 and, indeed, they emit the beep too (but, as said, XFree86 fails on the computers). The beep is part of the message... I looked deeper into the patch 4.6.99.17-4.6.99.18.diff.bz2 and found that this file modified by the patch is the culprit : xc/programs/Xserver/hw/xfree86/os-support/bus/linuxPci.c (1.14) bugfixes : 111. Various PCI-related changes (Marc La France): [...] So it has to be reworked, I think. Without the output from `scanpci -v -v` that I asked you for, there is nothing I can rework it to. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: XDarwin.app is installed with symlinks inside MainMenu.nib bundles, app won't launch.
On Tue, 22 May 2007, SciFi wrote: On Tue, 22 May 2007 08:50:00 -0600, Marc Aurele La France wrote: Now, is there anything else that you think needs fixing here? I can only remember another patch I put on locally here, as I want to set this in the custom build/config/cf/host.def: cut-here --- xc/config/cf/darwin.cf_orig 2007-04-25 09:42:47 -0500 +++ xc/config/cf/darwin.cf 2007-04-25 10:18:58 -0500 @@ -315,7 +315,9 @@ #define BuildLibPathVar DYLD_LIBRARY_PATH +#ifndef DefaultUserPath #define DefaultUserPath /bin:/sbin:/usr/bin:/usr/sbin:$(BINDIR) +#endif #define DefaultSystemPath DefaultUserPath /* include rules to build shared libraries */ cut-here In my host.def I specify: #define DefaultUserPath $(PATH):$(BINDIR) to pick up the normal user environment (it's really long). Of course this mod will affect all platforms. But let me try to explain why I do this. This is to be sure we run the new(er) code in /usr/local/bin and other places rather than the vendor's old cruft in /usr/bin during _all_ phases. There are other tricks e.g. to set [DY]LD_ for similar reasons. Specifically for darwin/osx, we mainly do this in the user's ~/.MacOSX/environment.plist as well as root's, so the boot-system, early GUI-related apps, Finder, and all spawned apps including XDarwin.app will get the same long paths and hopefully run with newer bins libs etc. even during early single-user mode (yes I have modified /etc/rc* scripts as well). I know $(PATH) in host.def will be resolved at build time, but at least this will pick up the same long string, without our having to manually modify any /etc/X11 stuff or in users' hidden $HOME parmfiles. I hope at least. ;) (Since I can't afford $ADC$ account to test Leopard officially, this is the next-best effort to get up on latest code and to override what Apple provides at all levels, hoping to spot any problems before they include it into Leopard. I'm mainly interested in free / open apps, not caring much for any new proprietary gizmos that they are of course adding to Leopard, per se. I'll try to take any problem to the project itself, not to Apple, as I'm doing here. My philosophy is that the project ought to build function properly straight out of the tarball and without any pkg-mgr help even officially from the vendor. ;) ) Such a long-winded justification for a simple change ;-) Committed. As a final _final_ test, regardless -- When the public cvs server gets that latest XDarwin.app symlink patch pushed to it, let's do a complete new checkout and build it. Are we getting close to an official 4.7 release? :) We're looking at a June code freeze, release in July. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: XDarwin.app is installed with symlinks inside MainMenu.nib bundles, app won't launch.
On Sun, 20 May 2007, SciFi wrote: On Fri, 18 May 2007 12:44:22 -0600, Marc Aurele La France wrote: On Thu, 17 May 2007, SciFi wrote: I'm totally out of ideas on this... I'm not. At least, not yet. Please try the attached patch. Patch went on okay. Still have symlinks in the installed .app bundle. :( I tee'd the stdout + stderr output to files for both make [all, not World] and make install to prove your new lines to the Imakefiles _did_ get executed, as well the xcodeprojs did get rerun etc. If you need this evidence, we probably should convert this into a bugzilla report for proper tracking attachments etc. `make all` won't do it. `make Everything` minimum. Then `make install`. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: XDarwin.app is installed with symlinks inside MainMenu.nib bundles, app won't launch.
On Wed, 16 May 2007, SciFi wrote: On Sun, 22 Apr 2007 10:29:12 -0600, Marc Aurele La France wrote: On Tue, 17 Apr 2007, Marc Aurele La France wrote: On Sun, 15 Apr 2007, Yves de Champlain wrote: There already is a bug opened that XDarwin won't build in shadow tree. http://bugs.xfree86.org/show_bug.cgi?id=1182 As mentionned there, once the right files are copied to replace symlinks, everything go on smoothly. I think the right files (TM) were xc/programs/Xserver/hw/darwin/bundle OK. Thanks for the info. The attached patch should fix this. The change I attached has now been committed. Thanks for reporting the problem. Took a while to get back here to report. I built the current cvs as of the date of this msg (gee why can't cvs just give us a simple revision number as svn can...). The XDarwin.app that got installed into /Applications *again* has the symlinks inside the MainMenu nibs for all languages. Just to be sure, I moved the previous build out of the way for a clean copy to be put there. I did this build to apply the test patches from bug #1683; I've updated that record with good results. A cvs up will show 'M' as expected for those files that were modified from those patches of course. I don't think those patches had anything to do with this problem with XDarwin.app. The nibs built under e.g. build2/programs/Xserver/hw/darwin/bundle/English.lproj/ have symlinks. Shouldn't use them for bundling into the final .app. The nibs built under e.g. build2/programs/Xserver/hw/darwin/quartz/build/Development/XDarwin.app/Contents/Resources/English.lproj/ are OKAY. The latter are the .lproj trees I used to fix the XDarwin.app installed into /Applications manually via Finder dragdrop directly into the .app bundle. Wish I could help diagnose this more, this is perplexing. I'll try testing anything if someone comes up with something. You might need to might need to manually remove what was previously installed before running `make install` again. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Link problems with xedit, may be Darwin-only(?)
On Sun, 22 Apr 2007, SciFi wrote: On Sat, 14 Apr 2007, Marc Aurele La France wrote: On Wed, 11 Apr 2007, SciFi wrote: 4. Link problems with xedit, may be Darwin-only(?) Possibly. Build Log snip: [...] -L../../../exports/lib lsp.o -L. -llisp -Lmp -lmp -Lre -lre -lm -L/usr/X11R6/lib /usr/bin/ld: Undefined symbols: [...] collect2: ld returned 1 exit status [...] I'd like to see the _complete_ command line that fails, not just the tail end of it. Anything more on this? Is this related to your GNU make upgrade? oh I just saw this ... having weather connection problems etc. here... No ... as I mentioned I've seen this kind of problem with other projects albeit rarely. I'd blame the Apple linker on such occasions for losing the symbols, whatever is causing it we have no idea. The symbols _are_ there in the .a files. (IIRC the libdvdread project does this, too, and there are others, all usually fixed by including the .a files...) One possibility here is that it is finding a libmp.dylib in a LD_LIBRARY_PATH path, /lib, /usr/lib, or /usr/local/lib. If so, then the fix would be to #define ExtraLoadOptions to -Wl,-search_paths_first. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Link problems with xedit, may be Darwin-only(?)
On Tue, 24 Apr 2007, SciFi wrote: On Tue, 24 Apr 2007 08:08:24 -0600, Marc Aurele La France wrote: On Sun, 22 Apr 2007, SciFi wrote: On Sat, 14 Apr 2007, Marc Aurele La France wrote: On Wed, 11 Apr 2007, SciFi wrote: 4. Link problems with xedit, may be Darwin-only(?) Possibly. Build Log snip: [...] -L../../../exports/lib lsp.o -L. -llisp -Lmp -lmp -Lre -lre -lm -L/usr/X11R6/lib /usr/bin/ld: Undefined symbols: [...] collect2: ld returned 1 exit status [...] I'd like to see the _complete_ command line that fails, not just the tail end of it. Anything more on this? Is this related to your GNU make upgrade? oh I just saw this ... having weather connection problems etc. here... No ... as I mentioned I've seen this kind of problem with other projects albeit rarely. I'd blame the Apple linker on such occasions for losing the symbols, whatever is causing it we have no idea. The symbols _are_ there in the .a files. (IIRC the libdvdread project does this, too, and there are others, all usually fixed by including the .a files...) One possibility here is that it is finding a libmp.dylib in a LD_LIBRARY_PATH path, /lib, /usr/lib, or /usr/local/lib. If so, then the fix would be to #define ExtraLoadOptions to -Wl,-search_paths_first. Holy guacamole this is getting too strange. Please bear with me, I really need to explain some things that are related to your reply. For background: Even though Apple's current docs say they would honour LD_LIBRARY_PATH (probably due to their promise to be more Linux-friendly), in actuality we've never seen it work. Instead we must set DYLD_LIBRARY_PATH for Darwin/OSX systems. Now to the meat of this issue: In my /usr/local/lib are the GNU MP 4.1.2 libraries named -- you guessed it -- libmp.a libmp.dylib (plus symlinks to the versioned names). AFAICT this is their latest version. I need it for some other projects I think related to the FFT libs which again are needed for some other projects. Talk about a naming clash. I could try putting /usr/X11R6/lib ahead of /usr/local/lib for the DYLD_ env just for starting X11 and tasks it spawns, but we then have a crazy problem if we include /usr/X11R6/lib AT ALL in that path string -- anywhere: late, early, first, middle, last -- it makes no difference. The biggest crazy problem is that this will disable the Macromedia Flash plugin for any all web-browsers: 2007-04-02 05:36:26.495 firefox-bin[6726] CFLog (21): Error loading /Library/Internet Plug-Ins/Flash Player.plugin/Contents/MacOS/Flash Player: error code 4, error number 0 (Symbol not found: _gluTessCallbackCFM Referenced from: /System/Library/Frameworks/AGL.framework/Versions/A/AGL Expected in: /usr/X11R6/lib/libGLU.dylib ) Another crazy problem is that we see the console printing this message for _any-and-all_ tasks using that DYLD_ setting: dyld: warning DYLD_ setting caused circular dependency in /usr/X11R6/lib/libGL.dylib Some weeks ago I opened problem #5104136 at http://bug-report.apple.com/ to log these interrelated issues with DYLD_LIBRARY_PATH and /usr/X11R6/lib. (By the nature of the 'free' ADC account, the bug-reports aren't made public, searchable, or otherwise sharable. If you want I could cp the discussion going on there.) What's even more strange is that I cannot find any file whatsoever *anywhere* with the string 'gluTessCallbackCFM' -- even in the calling libs (AGL Frameworks Flash plugin files)!!! (hmm I am assuming the symbol tables are not encoded with 16-bit ASCII/UTF like with some M$ stuff...) That happens with libGL[U].dylib coming from Apple's X11 on the Tiger install DVD with their updates from a few months ago. It also happens with the _new_ libGL[U].dylib being built from current XFree86-cvs!!! The only way to fix this for real is to remove /usr/X11R6/lib from the DYLD_ path entirely. But I want my test env to be sure to use my newer builds of libs in /usr/local/lib no matter what. (There are settings in each user's ~/.MacOSX/environment.plist that control these paths for the Finder and GUI stuff itself. To get the system itself to find stuff there first, we set+export DYLD_ in the /etc/rc.common script which ought to propagate to all other boot tasks. For the system GUI stuff, we edit root's ~/.MacOSX/environment.plist as well. This way we get the whole ball of wax to use e.g. the latest iconv+intl libs and many many many others.) So my test env isn't going to be able to scan /usr/X11R6/lib at all until/unless Apple fix this bug. But maybe that isn't the real problem with this particular xf86 build problem. Do you think I should add '.' as the very first path to DYLD_ -- I don't think it is implicit? (Right now I actually do have '.' as the very last path here.) Didn't mean to get so long with this post, but you brought up something related I needed to get out into the public for others to see anyway. ;) I'll definitely try your patch
Re: Link problems with Xdmx, may be Darwin-only(?)
On Sat, 14 Apr 2007, Marc Aurele La France wrote:
On Wed, 11 Apr 2007, SciFi wrote:
5. Link problems with Xdmx, may be Darwin-only(?)
Build Log snip:
[...] -Wall -UNEED_SCREEN_REGIONS -L../../exports/lib
hw/dmx/dix/main.o hw/dmx/miinitext.o
GL/mesa/main/dispatch.o hw/dmx/dix/libdix.a hw/dmx/os/libos.a
hw/dmx/libdmxlib.a hw/dmx/config/libdmxconfig.a
hw/dmx/glxProxy/libglxProxy.a
miext/shadow/libshadow.a fb/libfb.a mi/libmi.a hw/dmx/Xext/libext.a
record/librecord.a XTrap/libxtrap.a xkb/libxkb.a Xi/libxinput.a
lbx/liblbx.a ../../lib/lbxutil/liblbxutil.a
render/librender.a hw/dmx/input/libdmxinput.a -L/usr/X11R6/lib
-L../../exports/lib -lXfont -L/usr/local/lib -lfreetype
../../lib/font/stubs/libfntstubs.a -L../../exports/lib -lXi -lXmu -lXt
-lSM -lICE -lXext -lX11 -lXrender -lXext -lX11 -lz
-lXdmcp
/usr/bin/ld: Undefined symbols:
_DarwinGlxExtensionInit
_DarwinGlxWrapInitVisuals
__glapi_Dispatch
[...]
To recreate:
Enable the Xdmx options in your [build/]config/cf/host.def file,
e.g.
#define XdmxServer YES
You also have XFree86Devel set to YES.
Build with latest XCode (Apple-provided gcc, ld, etc.).
Possibly related env-vars:
export MACOSX_DEPLOYMENT_TARGET=10.4
export SDKROOT=/Developer/SDKs/MacOSX10.4u.sdk
export SDK=${SDKROOT}
...and maybe others...
$ gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build
5367)
[...]
$ uname -a
Darwin hostname 8.9.0 Darwin Kernel Version 8.9.0: Thu Feb 22 20:54:07
PST 2007; root:xnu-792.17.14~1/RELEASE_PPC Power Macintosh powerpc
PowerMac7,3 Darwin
(OSX 10.4.9 running on a Dual G5 2.7GHz with 3.5GB of matched-pair
SDRAM and more...)
Discussion:
Some libs aren't being included at all during the link phase for
Xdmx.
I _think_ this is how it might be fixed:
-cut-
--- xc/programs/Xserver/Imakefile_orig 2007-04-10 20:58:18 -0500
+++ xc/programs/Xserver/Imakefile 2007-04-11 01:57:39 -0500
@@ -1454,7 +1454,7 @@
$(XDMXDIRS), \
$(XDMXOBJS) $(XDMXDEFFILE), \
$(XDMXLIBS), \
- $(XDMXSYSLIBS))
+ $(XDMXSYSLIBS) $(IOKITLIB) GL/mesa/GLcore/libGLcore.a -Wl,-m)
#endif /* XdmxServer */
-cut-
No. Xdmx has its own GLX implementation.
The patch below should fix this:
*** cvs/xc/programs/Xserver/Imakefile Mon Apr 9 09:19:10 2007
--- devel/xc/programs/Xserver/Imakefile Sat Apr 14 23:00:06 2007
*** XCOMM
*** 1427,1436
$(DMXEXTDIRS) $(SHADOWDIR) $(DEPDIRS)
#if BuildGlxInDmx
GLXPROXYLIB = $(XDMXDDXDIR)/glxProxy/LibraryTargetName(glxProxy)
- XDMXGLOBJS = $(GLOBJS)
#endif
! XDMXOBJS = $(XDMXDDXDIR)/dix/main.o $(XDMXDDXDIR)/miinitext.o \
! $(XDMXGLOBJS)
XDMXINPUT = $(XDMXDDXDIR)/input/LibraryTargetName(dmxinput)
XDMXCONFIG = $(XDMXDDXDIR)/config/LibraryTargetName(dmxconfig)
XDMX = $(XDMXDDXDIR)/LibraryTargetName(dmxlib) $(XDMXCONFIG)
\
--- 1427,1434
$(DMXEXTDIRS) $(SHADOWDIR) $(DEPDIRS)
#if BuildGlxInDmx
GLXPROXYLIB = $(XDMXDDXDIR)/glxProxy/LibraryTargetName(glxProxy)
#endif
! XDMXOBJS = $(XDMXDDXDIR)/dix/main.o $(XDMXDDXDIR)/miinitext.o
XDMXINPUT = $(XDMXDDXDIR)/input/LibraryTargetName(dmxinput)
XDMXCONFIG = $(XDMXDDXDIR)/config/LibraryTargetName(dmxconfig)
XDMX = $(XDMXDDXDIR)/LibraryTargetName(dmxlib) $(XDMXCONFIG)
\
*** cvs/xc/programs/Xserver/hw/dmx/glxProxy/glxext.c Fri Jan 19 08:37:02
2007
--- devel/xc/programs/Xserver/hw/dmx/glxProxy/glxext.c Sat Apr 14 22:48:48
2007
*** void __glXNoSuchRenderOpcode(GLbyte *pc)
*** 518,520
--- 518,534
return;
}
+ #ifdef __DARWIN__
+ void
+ DarwinGlxExtensionInit(INITARGS)
+ {
+ GlxExtensionInit();
+ }
+
+ void
+ DarwinGlxWrapInitVisuals(
+ void *procPtr)
+ {
+ GlxWrapInitVisuals(procPtr);
+ }
+ #endif
This has now been committed. Thanks for reporting the problem.
Marc.
+--+--+
| Marc Aurele La France | work: 1-780-492-9310 |
| Academic Information and| fax:1-780-492-1729 |
|Communications Technologies | email: [EMAIL PROTECTED] |
| 352 General Services Building +--+
| University of Alberta | |
| Edmonton, Alberta |Standard disclaimers apply|
| T6G 2H1 | |
| CANADA | |
+--+--+
XFree86 developer and VP. ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: Link problems with xedit, may be Darwin-only(?)
On Sat, 14 Apr 2007, Marc Aurele La France wrote: On Wed, 11 Apr 2007, SciFi wrote: 4. Link problems with xedit, may be Darwin-only(?) Possibly. Build Log snip: [...] -L../../../exports/lib lsp.o -L. -llisp -Lmp -lmp -Lre -lre -lm -L/usr/X11R6/lib /usr/bin/ld: Undefined symbols: [...] collect2: ld returned 1 exit status [...] I'd like to see the _complete_ command line that fails, not just the tail end of it. Anything more on this? Is this related to your GNU make upgrade? Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Building against fontconfig-2.4.2 (latest release) causes two missing symbols when linking libXft.
On Sat, 14 Apr 2007, Marc Aurele La France wrote:
On Wed, 11 Apr 2007, SciFi wrote:
1. Building against fontconfig-2.4.2 (latest release) causes two
missing symbols when linking libXft.
Build Log snip:
[...]
ld: Undefined symbols:
_FcPatternFindElt
_FcPatternInsertElt
/usr/bin/libtool: internal link edit command failed
To recreate:
a) build and install fontconfig-2.4.2
b) specify these in your [build/]config/cf/host.def file:
#define HasFontconfig YES
#define FontconfigDir /usr/local (or wherever you installed fontconfig)
Discussion:
There are two API functions that have been renamed in recent
versions of fontconfig, while their ABI (parms passed, header
layouts, etc.) remain the same.
Chiefly what we need to do in xf86's source:
s/FcPatternFindElt/FcPatternObjectFindElt/
s/FcPatternInsertElt/FcPatternObjectInsertElt/
I don't know enough how to insert #ifdefs that will test the
installed fontconfig's version criteria, so that we could make
xf86 compilable on old-and-new versions. I did find the commit
that made this change:
http://lists.freedesktop.org/archives/fontconfig/2006-August/002381.html
...but still not sure what was the switchover point for this
commit, i.e. the version-rel-mod-patch level to use for #ifdefs to
decide after which point to use the new function names. I hope
you know what I mean. ;)
For now, a quick patch to fix this:
-cut-
--- xc/lib/Xft1/xftint.h_orig 2002-06-30 23:28:17 -0500
+++ xc/lib/Xft1/xftint.h2007-04-06 08:17:55 -0500
@@ -92,10 +92,10 @@
* Yes, these are stolen from fcint.h
*/
FcPatternElt *
-FcPatternFindElt (const FcPattern *p, const char *object);
+FcPatternObjectFindElt (const FcPattern *p, const char *object);
FcPatternElt *
-FcPatternInsertElt (FcPattern *p, const char *object);
+FcPatternObjectInsertElt (FcPattern *p, const char *object);
typedef FcPatternElt XftPatternElt;
--- xc/lib/Xft1/xftpat.c_orig 2002-06-07 18:44:23 -0500
+++ xc/lib/Xft1/xftpat.c2007-04-06 08:18:45 -0500
@@ -210,9 +210,9 @@
XftPatternFind (XftPattern *p, const char *object, FcBool insert)
{
if (insert)
- return FcPatternInsertElt (p, object);
+ return FcPatternObjectInsertElt (p, object);
else
- return FcPatternFindElt (p, object);
+ return FcPatternObjectFindElt (p, object);
}
-cut-
Here's a quicker one...
*** cvs/xc/lib/Xft1/xftint.hSun Jun 30 22:28:17 2002
--- devel/xc/lib/Xft1/xftint.h Sat Apr 14 21:40:45 2007
*** typedef struct _FcPatternElt FcPatternEl
*** 91,96
--- 91,107
/*
* Yes, these are stolen from fcint.h
*/
+ /*
+ * Unfortunately, fontconfig's version number was not updated when these
were
+ * renamed (in 2.3.95).
+ */
+ #if FC_VERSION == 20395
+ # error fontconfig 2.3.95 not supported
+ #endif
+ #if FC_VERSION 20395
+ # define FcPatternFindElt FcPatternObjectFindElt
+ # define FcPatternInsertElt FcPatternObjectInsertElt
+ #endif
FcPatternElt *
FcPatternFindElt (const FcPattern *p, const char *object);
This has now been committed. Thanks for reporting the problem.
Marc.
+--+--+
| Marc Aurele La France | work: 1-780-492-9310 |
| Academic Information and| fax:1-780-492-1729 |
|Communications Technologies | email: [EMAIL PROTECTED] |
| 352 General Services Building +--+
| University of Alberta | |
| Edmonton, Alberta |Standard disclaimers apply|
| T6G 2H1 | |
| CANADA | |
+--+--+
XFree86 developer and VP. ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: XDarwin.app is installed with symlinks inside MainMenu.nib bundles, app won't launch.
On Tue, 17 Apr 2007, Marc Aurele La France wrote: On Sun, 15 Apr 2007, Yves de Champlain wrote: Le 07-04-15 à 14:55, Marc Aurele La France a écrit : On Wed, 11 Apr 2007, SciFi wrote: 6. XDarwin.app is installed with symlinks inside MainMenu.nib bundles, app won't launch. Discussion: The make-install process is creating/copying symlinks for the innards of the MainMenu.nib bundles instead of copying the actual files. This is for each language inside the installed XDarwin.app bundle itself. As installed, we'll see errors in console.log concerning the language couldn't be loaded, and the app will fail to launch. This is what we _should_ see in the installed app-bundle after repaired by hand: $ cd /Applications/XDarwin.app/Contents/Resources/English.lproj/ MainMenu.nib $ ls -alL total 28 drwxr-xr-x 5 scifi wheel 170 2007-04-04 11:05 . dr-xr-xr-x 7 root wheel 238 2007-04-11 02:26 .. -rw-r--r-- 1 scifi wheel 2369 2003-10-16 18:50 classes.nib -rw-r--r-- 1 scifi wheel 20640 2003-10-16 18:50 objects.nib The xf86 installer is creating those two .nib files as symlinks to somewhere in the build/ tree, which further are symlinks elsewhere. OSX don't like it that way. ;) Each/every MainMenu.nib in all *.lproj (language) subdirs are affected this way. I don't know how to fix this in Makefiles etc. I ended up using Finder to drag-copy these from the real xc/ tree (not the build/ tree) directly into the installed /Application/XDarwin.app bundle itself. I don't see anywhere in `make install` that would create symlinks for these. So, I suspect this is artifact is due to a combination of the way XCode normally operates and your use of shadow trees for builds (a practice I highly recommend BTW). There might be a way to coerce XCode into following symlinks either through a command line flag, the project file, so some other mechanism. Please investigate. There already is a bug opened that XDarwin won't build in shadow tree. http://bugs.xfree86.org/show_bug.cgi?id=1182 As mentionned there, once the right files are copied to replace symlinks, everything go on smoothly. I think the right files (TM) were xc/programs/Xserver/hw/darwin/bundle OK. Thanks for the info. The attached patch should fix this. The change I attached has now been committed. Thanks for reporting the problem. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals.
Re: Several Darwin quartz objects not being built when using GNU make-3.81+.
On Fri, 20 Apr 2007, SciFi wrote: I've come across a bug filed a year ago with the GNU make project here: https://savannah.gnu.org/bugs/index.php?16389 We're trying to convince the GNU-make team to accept Apple's patches so the .m rules etc. will be implicit. If the GNU-make team decide not to accept the patch there, then we must revamp all affected projects' build systems _again_ to re-insert these explicit rules. After logging this particular xfree86 problem, I've applied that patch to my local make-3.81.90cvs so I could continue building other projects (that patch indeed does help a _lot_ ;) ). I've yet to rebuild xfree86-cvs to see if that patch will help this situation, but I have a strong feeling it will. In order to test your patch fairly, I'll need to back-out the patch to make. Not really. You can build with gnumake instead of make. If I could ask anyone in the audience here interested to go to that bug report for GNU make and add your comments (either 'for' or 'against'), I'd appreciate it, as the GNU team really needs to make a final decision. As I mention there-in, if they decline, then I can pursue the issue with affected projects with a stronger argument ... if they leave the make bug open / undecided, I don't have much muscle. So I'm asking people to help out either way, just so we'll have a final decision. Of course several of us are very much wanting the GNU team to accept the patch just so the issues can be resolved relatively easily than the inevitable alternative... and please keep in mind I'm more worried about buildbots that don't run on darwin/osx but must build _for_ darwin/osx... While I understand your take on this, I don't entirely agree with it. It seems to me that the root cause of this is that Apple distributes a system including changes to free/open software that they did not bother to, or succeed in, pushing upstream. In the first case, accepting the change referenced in the bug report now would mean GNU sanctions such behaviour. On a more technical level, Objective C projects need to define .m.o suffix rules in any case, if they are to be portable to other make implementations. I doubt very much all such projects are Darwin-specific. In any case, XFree86's dependence on this specific Apple change to GNU make has now been removed. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Link problems with xedit, may be Darwin-only(?)
On Wed, 11 Apr 2007, SciFi wrote: 4. Link problems with xedit, may be Darwin-only(?) Possibly. Build Log snip: [...] -L../../../exports/lib lsp.o -L. -llisp -Lmp -lmp -Lre -lre -lm -L/usr/X11R6/lib /usr/bin/ld: Undefined symbols: [...] collect2: ld returned 1 exit status [...] I'd like to see the _complete_ command line that fails, not just the tail end of it. Thanks. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: patches for Darwin /MacOSX
On Fri, 6 Apr 2007, SciFi wrote: If I did things right, three patches were no longer needed, cvs seems to have similar fixes. The others needed some matching done to the compare lines. One of the others had a hunk that was done better with the cvs changes. It might be better if I update your bugzilla reports, to keep track of the updated patches better? I've done more tweaks to my own host.def file, then will build it with your patches altered to match cvs. I want xf86 to use my own built freetype2-cvs, fontconfig-2.4.2, png-1.2.17beta, and expat-2.0.0 libs etc. instead of the old stuff in the xf86 tarball/cvs. ;) For one thing, the next freetype2-2.3.3 release will have some important ttf tweaks fixes, things should look much better. I turned on and/or up'd some freetype2 config parms, too, plus I want to try their new LCD pixel support (I have a 23 Cinema HD thing here ;) ). Crossing fingers... ah-oh, it already stopped while linking libXft: can't find a couple Fc symbols but the correct -L/-l parms are right there. ...grrr... Ain't xf86 keeping up with the latest APIs stuff being done to projects it depends on? ... :( ... maybe I'll switch to x.org ... Well, you can do that. But, AFAICT there has been little to no activity on its Darwin port for the past two years either. A few more comments here ... XFree86 is strictly a volunteer organisation, not the 9-to-5 outfit you seem to imply it is. As such, it cannot be expected to follow your schedule. There are imake controls that allow building against external packages instead of the ones in the tree. The repository mirror you (and CVSWeb) have read access to is updated once a day. When exactly I never remember, but in any case, I have no access to affect it. Yves's changes are still under review (almost done), which means that they have yet to be integrated. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: patches for Darwin /MacOSX
On Wed, 4 Apr 2007, Yves de Champlain wrote: I just posted many patches in bugzilla for Darwin/MacOSX. http://bugs.xfree86.org/show_bug.cgi?id=1680 http://bugs.xfree86.org/show_bug.cgi?id=1681 Some of the issues you address have already been resolved since 4.6.99.20, but I'll be going through these in the next little while. Thanks for the patches! Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: miinitext.c - recordproc.h and dbeproc.h: No such file or directory
On Mon, 26 Mar 2007, [EMAIL PROTECTED] wrote: This time as a member: Welcome! Trying to compile the latest snapshot of XFree86 from March 21, 07, I get the following error in the World.log file: [elided] What does that mean? I have searched the bug database and the internet, but this time I was not able to find any hints for a solution. As it so happens, this problem has already been reported and a patch to fix it is in the last stages of being finalised before being committed. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: siliconmotion CSync output ?
On Thu, 8 Mar 2007, Tim Roberts wrote: bruno schwander wrote: ah never mind. since this is interlaced, the pixel clock needs to be half that to get the right frame refresh rate (60Hz) with a pixel clock of 12.22MHz, it passes. Now, I am not sure if the pixel clock is effectively set to that, and my lcd still does not sync, so either the pixel clock is not set right or the SMI712 is not outputting composite sync (despite my hack to enable it) You have an LCD that expects 640x480 interlaced? Really? Expects it? No. But, certainly I've run into panels that can handle it. Not a pretty picture though. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xc/programs/mkcfm/cidchar.c doesn't compile
On Mon, 18 Dec 2006, Dr Andrew C Aitchison wrote: xc/programs/mkcfm/cidchar.c doesn't compile Oddly this is a link to xc/lib/font/Type1/cidchar.c which *does* compile gcc -m32 -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -I. -I../../lib/font/Type1 -I../../lib/font/include -I../../programs/Xserver/include -I../../exports/include-Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DBUILDCID -DCID_ALL_CHARS-c -o cidchar.o cidchar.c cidchar.c: In function `CIDGetGlyphInfo': cidchar.c:122: structure has no member named `CIDsize' cidchar.c:191: structure has no member named `CIDsize' cidchar.c:268: structure has no member named `CIDsize' cidchar.c:306: structure has no member named `CIDsize' cidchar.c:348: structure has no member named `CIDsize' cidchar.c:360: structure has no member named `CIDsize' make: *** [cidchar.o] Error 1 I have justnow committed a fix for this. Thanks for reporting the problem. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Security bug: querying the nameserver for your own ip address
On Mon, 13 Nov 2006, Mikulas Patocka wrote:
I am running xfree86 on configuration with only tcp/ip (no unix domain
sockets) and I discovered a really weird behaviour:
When standard :0.0 display is passed to an application, Xlib calls
gethostname() to determine my own host name, then queries the nameserver for
that name and connects to that IP address --- it opens pretty bad security
hole: anyone on LAN can spoof nameserver responses and mess with applications
that are supposed to run locally. Why doesn't it use 127.0.0.1 that is
designed for this purpose?
So far, I fixed it with this patch (it needs to have IPv6 support added if
you want to commit it).
Mikulas
diff -u -r ../../X/XC/LIB/XTRANS/XTRANSSOCK.C ./XTRANS/XTRANSSOCK.C
--- ../../X/XC/LIB/XTRANS/XTRANSSOCK.C 2006-03-01 23:01:55.0 +0200
+++ ./XTRANS/XTRANSSOCK.C 2006-11-13 06:52:44.0 +0200
@@ -1408,12 +1408,13 @@
PRMSG (2,SocketINETConnect(%d,%s,%s)\n, ciptr-fd, host, port);
+hostnamebuf[0] = '\0';
+(void) TRANS(GetHostname) (hostnamebuf, sizeof hostnamebuf);
if (!host)
{
- hostnamebuf[0] = '\0';
- (void) TRANS(GetHostname) (hostnamebuf, sizeof hostnamebuf);
host = hostnamebuf;
}
+if (!strcasecmp(host, hostnamebuf)) host = 127.0.0.1;
#ifdef X11_t
/*
I don't particularly agree with this change. If a system cannot trust its
own hostname, spoofing an X connection would be the least of your worries.
Besides, you can accomplish the same thing by including the hostname in
/etc/hosts and configuring your name resolutions to look at files first.
Also, this change doesn't really fix the problem, even if name resolution is
compromised.
Marc.
+--+--+
| Marc Aurele La France | work: 1-780-492-9310 |
| Academic Information and| fax:1-780-492-1729 |
|Communications Technologies | email: [EMAIL PROTECTED] |
| 352 General Services Building +--+
| University of Alberta | |
| Edmonton, Alberta |Standard disclaimers apply|
| T6G 2H1 | |
| CANADA | |
+--+--+
XFree86 developer and VP. ATI driver and X server internals.
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
RE: WD90C24 Anyone?
On Tue, 7 Nov 2006, Chris Schumann wrote: [mailto:[EMAIL PROTECTED] On Behalf Of Tim Roberts [EMAIL PROTECTED] wrote: I have an old ThinkPad 750P. It uses the WD90C24 chip, which was in the old svga driver. What would it take to port that to the new XFree86 code? I'm not above writing assembly code or digging in here, I just don't know where to start or how much effort it might take... swatting a fly or eating an elephant? Holy moly! You have a whopping 1 megabyte of video RAM there. Will it work with the VESA fb driver? If not, then you might as well give up. I have the source code for their old Windows 3.1 driver, and it is more than 76,000 lines of 16-bit x86 assembler. The blitter provided virtually no acceleration, so you won't really be giving anything up to use the fb driver. This machine didn't quite get the VESA in firmware. It was provided by a DOS TSR, which was required for the Win3.1 and Win95 drivers. I thought it was for use with VESA, but now I'm not sure. Anyway, I don't think it's a good idea to require a DOS TSR for video in Linux. There is source for this chip somewhere in the annals of X code. I think XFree86 supported it as late as 3.1. 3.3.6, actually. The only mode I've seen with modern distributions is 320x200x1. It's not pleasant. I'd also like to get the pen interface to work on it, but one step at a time! :) So what's that next step? You can start with reading the DESIGN document included in the distribution, using the 3.3.6 pvga1 driver as a guide in filling in the blanks. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: x86emu emulation problem
On Fri, 6 Oct 2006, jf simon wrote: 2- The same code as seen from ndisasm: 68DA A00080mov al,[0x8000] 68DD 04F5 add al,0xf5 68DF 0002 add [bp+si],al 68E1 C8008015 enter 0x8000,0x15 68E5 0Epush cs 68E6 0106C800 add [0xc8],ax 68EA 80100Eadc byte [bx+si],0xe 68ED 0105 add [di],ax 68EF C800800B enter 0x8000,0xb 68F3 0Epush cs 68F4 0104 add [si],ax 68F6 C8008006 enter 0x8000,0x6 68FA 0Epush cs 68FB 0102 add [bp+si],ax 68FD E80080call 0xe900 !!!HERE AGAIN This is probably data -- either font data or VGA register tables. Can you trace backwards any more and figure out how you got to 68DA? You are right. I have found that the problem was on a JMP SHORT which was incorrectly landing in that part of the VGA BIOS. The relative displacement was negative (was 0xBA), but the JMP was considering it to be a jump to [PC]+0xBA rather than applying the signed arithmetic. Setting GCC -fsigned-char switch made the signed displacemnt correctly appliedand solved the problem. I didn't know that the char type was unsigned by default. I've just committed a change to insulate x86emu against this. Lastly, I have found that the VGA bios i use is doing CF8/CFC PCI configuration style accesses. Which doesn't work on my PowerPC plaftorm. (I think it is only to be seen in the x86 world, but not sure). So they need to be translated to whatever the platform is going to use as PCI configuration access. I just mention this for the record in case others are not aware of this. The generic int10 modules already intercepts such accesses and emulates them using PCI accesses appropriate for the platform. Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: error about compiling Xorg7.1
On Wed, 23 Aug 2006, cckuo wrote: Dear X friends: I download the Xserver7.1 from the http://ftp.x.org/pub/X11R7.1/src/xserver/ After producing Makefile by typing configure, I found the error message says extension.c:234: error: UntrustedProcVector undeclared (first use in this function) extension.c:234: error: (Each undeclared identifier is reported only once extension.c:234: error: for each function it appears in.) extension.c:235: error: SwappedUntrustedProcVectorundeclared (first use in this function) make[1]: *** [extension.lo] Error 1 make[1]: Leaving directory `/mnt/hdc/cckuo/Xorg/7.1/xserver/dix' make: *** [all-recursive] Error 1 I grep both the UntrustedProcVector and SwappedUntrustedProcVector, and I found it was defined in Xext/Security.c. Should I add some compiling options or download additional files to compile? Sincerely Yours, cckuo Please refrain from spamming XFree86 mailing lists about X.Org problems. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 2 bugs in the X server
On Wed, 26 Jul 2006, Michal [utf-8] Maru?ka wrote: Hello, I know about 2 bugs in X server which are quite reproducible with my programs. I use CVS from a month ago, but I noticed the first bug months ago already. I use mga driver. 1/ There is a way to see a screen full of pixmaps (instead of what should be on the screen). I can reproduce this bug with sawfish WM. It has a mode to flip between viewspaces, while moving a window by mouse movement (and bumping into the border of the screen). When I do such movement w/ keyboard using mouse emulation, I can trigger this funny bug. Suddenly, after Sawfish does a series of requests to move windows, and warp pointer, I see pictures which are used in my (running) firefox browser, and I explain this that I see off-screen pixmaps. To recover from the wrong display I can either switch to another console, or cycle resolution with C-M-KP+/-. I can't really help you with this problem, as I have no MGA hardware. 2/ DBE (double-buffer extension) operations can make the server segfault. My guess is, that it is caused by the double-buffered window being too large: the DBE request are made by my quick dirty experimental code for Sawfish, to draw window's title-bar, and the bug happens, when I construct a too large window (building gtk view-text widget with a long line inside, w/o scrolling enabled). Here's the Caught signal 11. Stack trace: 0: 0x808da2c: 0x808da10 xf86ShowStackTrace + 0x1c Module XFree86 1: 0x808db13: 0x808dab0 xf86SigHandler + 0x63 Module XFree86 2: 0xe420: 0xe420 __kernel_sigreturn + 0x0 Module 3: 0x813ca09: 0x813c8d0 miSpriteCopyArea + 0x139 Module /usr/xfree86-4.6/bin/XFree86 4: 0xb7f95420: 0xb7f95360 miDbeSwapBuffers + 0xc0 Module /usr/xfree86-4.6/lib/modules/extensions/libdbe.a:midbe.o Section .text 5: 0xb7f967b4: 0xb7f96690 ProcDbeSwapBuffers + 0x124 Module /usr/xfree86-4.6/lib/modules/extensions/libdbe.a:dbe.o Section .text 6: 0x80c5fba: 0x80c5e60 Dispatch + 0x15a Module XFree86 7: 0x80d2327: 0x80d1f30 main + 0x3f7 Module XFree86 Fatal server error: Server aborting That displacement in miSpriteCopyArea doesn't match anything I have here, likely because I have different compiler versions. Please do ... gdb /usr/xfree86-4.6/bin/XFree86 disass miSpriteCopyArea quit ... and send the resulting output. And I would like to ask, if there's a hope to get support for RV370[Radeon X300SE] in xfree86. Well, such support would have to be contributed, as the author/maintainer of Radeon support has moved on to the X.Org Foundation. Thanks! ... and thank you! Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Copyright grant for Adobe Times fonts?
On Tue, 11 Jul 2006, Robinson Tryon wrote: I've been working on a program that includes the Adobe Times font from the debian package x11/xfonts-75dpi. That package is assembled from xfree86 sources. Several other fonts that come from xfree86 have explict copyright permissions -- for example the Bitstream Charter fonts, but I have been unable to find any record of Adobe giving a license for their 'Times' fonts. I asked debian-legal, but no one could provide me with solid information about the upstream licensing. The font files themselves have all-rights-reserved copyright notices for Adobe and Digital: Copyright (c) 1984, 1987 Adobe Systems Incorporated. All Rights Reserved. Copyright (c) 1988, 1991 Digital Equipment Corporation. All Rights Reserved. Times is a trademark of Linotype-Hell AG and/or its subsidiaries. The upstream license' section of the COPYRIGHT file for the xfonts-75dpi package does not appear to contain any pertinent information, other than mentioning Adobe's name in a long list of contributors. Does anyone know where I could find the explicit license from Adobe/Digital for these fonts to be included in Xfree86? You are confusing copyright and license. The license says how the work can be redistributed. The copyright says who has the authority to grant such a license. Rest assured that XFree86 does not include any font that cannot be freely redistributed. And by freely redistributed, I mean without any incumberances whatsoever. flamebaitThis excludes anything under GPL/flamebait Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Copyright grant for Adobe Times fonts?
On Tue, 11 Jul 2006, Robinson Tryon wrote: On 7/11/06, Marc Aurele La France [EMAIL PROTECTED] wrote: On Tue, 11 Jul 2006, Robinson Tryon wrote: I've been working on a program that includes the Adobe Times font from the debian package x11/xfonts-75dpi. That package is assembled from xfree86 sources. Several other fonts that come from xfree86 have explict copyright permissions -- for example the Bitstream Charter fonts, but I have been unable to find any record of Adobe giving a license for their 'Times' fonts. I asked debian-legal, but no one could provide me with solid information about the upstream licensing. The font files themselves have all-rights-reserved copyright notices for Adobe and Digital: Copyright (c) 1984, 1987 Adobe Systems Incorporated. All Rights Reserved. Copyright (c) 1988, 1991 Digital Equipment Corporation. All Rights Reserved. Times is a trademark of Linotype-Hell AG and/or its subsidiaries. The upstream license' section of the COPYRIGHT file for the xfonts-75dpi package does not appear to contain any pertinent information, other than mentioning Adobe's name in a long list of contributors. Does anyone know where I could find the explicit license from Adobe/Digital for these fonts to be included in Xfree86? You are confusing copyright and license. You're right -- I should have written that more clearly. The license says how the work can be redistributed. The copyright says who has the authority to grant such a license. Agreed. Rest assured that XFree86 does not include any font that cannot be freely redistributed. And by freely redistributed, I mean without any incumberances whatsoever. But the font files say (to paraphrase) copyright Adobe/Digital, all rights reserved. No one has been able to produce a license from Adobe that indicates that the Adobe Times fonts can be freely distributed. Other fonts included in XFree86 include a license from the copyright owner of the font. For example, here is the one for Bitstream Charter: The Bitstream Type 1 fonts are under the following license: (c) Copyright 1989-1992, Bitstream Inc., Cambridge, MA. You are hereby granted permission under all Bitstream propriety rights to use, copy, modify, sublicense, sell, and redistribute the 4 Bitstream Charter (r) Type 1 outline fonts and the 4 Courier Type 1 outline fonts for any purpose and without restriction; provided, that this notice is left intact on all copies of such fonts and that Bitstream's trademark is acknowledged as shown below on all unmodified copies of the 4 Charter Type 1 fonts. BITSTREAM CHARTER is a registered trademark of Bitstream Inc. If I don't have a license for the Adobe Times font, then I can't (legally) distribute those files. Right? Oh, but you _do_ have a license, as Alan points out. And the term All Rights Reserved simply means only the copyright holder has the right to change the license's terms. You, as a licensee, cannot legally do so on a whim or otherwise. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: PATCH: Added amd64 support for aperture driver (plus cosmetics to make aperture building on sun4v)
On Mon, 26 Jun 2006, Martin Bochnig wrote: ### ### ## ## I have uploaded two files to ## http://fiesta.cs.tu-berlin.de/~mbeinsx/aperture_amd64_sun4v/ ## ### ### ... it was summer solstice on June 20/21 (UTC Date). And therefore also half-time between two Happy Holidays seasons, Tempus Fugit! So Cristmas is six short long months away - in whatever direction we look. This will, however, not hinder me from releasing my _few_ added bits to the public, which make XFree86's / Xorg's aperture driver work on amd64 64 bit (Open)Solaris kernels, where the un-open /dev/xsvc driver can not be distributed legally, and where the lack of a working amd64-aperture module has been kind of a show-stopper for over a year. So I'm indeed publishing those changes, before I actually have out marTux for x86/x64 (which I publically announce hereby) and because of that give Belenix, Nextenda and Schillix the chance to be out with a release featuring X11 in amd64 mode, before myself's marTux is. So go, hurry! :-) You may notice, that interestingly both XFree86 and Xorg still have 100% exactly the same apSolaris.shar inside their current CVS, last modified in 2002 (though the webcvs entries and even revisions look different at first): http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/etc/apSolaris.shar http://webcvs.freedesktop.org/xorg/xserver/xorg/hw/xfree86/os-support/solaris/apSolaris.shar?view=log --- -rw-r--r-- 1 bochnig bochnig16546 Jun 26 00:30 XF86_apSolaris.shar -rw-r--r-- 1 bochnig bochnig16546 Jun 26 00:29 Xorg_apSolaris.shar bash-3.1$ diff -cu XF86_apSolaris.shar Xorg_apSolaris.shar No differences encountered Both projects can (or could?) therefore use the same attached diff, if they decide to incorporate something. I also chose a new detection mechanism for ISA-dependent selection of Makefiles: I use isainfo -k instead of uname -m. The reasons for this are: #0.) You cannot determine with uname (on Solaris), whether or not we are running on a plain x86, or on amd64. Especially can't we determine, wich kernel we're running. uname -m would always and only give i86pc on amd64. #1.) sun4u is by no means the only implementation of sparcv9 anymore: Take into account SUNW's throughput computing (sun4v) or - not to forget - the vendor FJSV, that may become much more wide- spread in the future, when SUNW/FJSV's APL will be out. The ISA is important to us, rather then the machine platform. To summarize this: Integrated support for generic sparcv9 - and therefore also sun4v aka Niagara servers, later APL, Rock, Rock2 etc. in the mid term future. All that by means of a rather cosmetical change. This has now been committed to our repository, modulo a small number of cosmetic changes. Thanks for the patch! Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: you may remove my name from ucs2any.c
On Sat, 11 Feb 2006, Ben Collver wrote: I had converted ucs2any.pl to ucs2any.c, and it was committed on my behalf. It was put under the old 4-clause BSD license with my name and a now-defunct email address. I noticed this at section 6.6 of http://www.xfree86.org/current/LICENSE6.html, which I assume is generated from xc/LICENSE.txt. It is now under the 3-clause BSD license. You can verify that here: http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/xsrc/xfree/xc/fonts/util/ucs2any.c?rev=1.9content-type=text/plain Please feel free to remove my name and email address from LICENSE.txt and LICENSE6.html. This has (finally) been reflected in our repository. The HTML page will get updated next release. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: How do I convert 4.5.0 driver to 4.6.0?
On Mon, 22 May 2006, Barry Scott wrote: Marc Aurele La France wrote: Looking at the diffs of the xfree86 via driver between 4.5.0 and 4.6.0 I seem to see that all that changed, apart from new features, is loader stuff: -LoaderRefSymLists(vgaHWSymbols, +LoaderModRefSymLists(module, + vgaHWSymbols, Do I need to make these loader changes to get correct operation or does your fallback code work correctly in all cases? Can I ignore this code change, I assume I can given that the driver works without changes. You should be able to. But, in my opinion, it would be better to determine why the 4.5 driver works better for you than the 4.6 one, aside from the Xv thing. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Where did the XvExtension define get removed?
On Fri, 19 May 2006, Barry Scott wrote: In 4.5.0 I see -DXvExtension passed to my driver compile but its missing under 4.6.0. Should I be always including XV code now and not making it conditional? Yes, that's correct. The intent is to have module objects be as independent of the way the core server is built as possible. Eventually, even DRI support will follow suit. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: How do I convert 4.5.0 driver to 4.6.0?
On Fri, 19 May 2006, Barry Scott wrote: I have a via driver (Unichrome from last November plus patches) that works very well on 4.5.0. It supports XVIDEO that the standard XFree86 driver does not support. I can build and use this same driver code is a trivia patch under 4.6.0 but xvinfo reports that there is an XVIDEO adapters. Looking at the diffs of the xfree86 via driver between 4.5.0 and 4.6.0 I seem to see that all that changed, apart from new features, is loader stuff: -LoaderRefSymLists(vgaHWSymbols, +LoaderModRefSymLists(module, + vgaHWSymbols, Do I need to make these loader changes to get correct operation or does your fallback code work correctly in all cases? Where should I look to debug why XVIDEO is not showing up under 4.6.0? This would be answered by your subsequent query about the XvExtension symbol's disappearance. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: lspci
On Wed, 10 May 2006, MANJUNATHA P wrote: whether lspci command supports all the graphics cards (AGP,PCI,PCIe),I am facing a problem with PCIe(pci express cards ). if anybody know please let me know. lspci is not distributed with XFree86. Rather, it is a Linux-based utility for listing PCI configuration space. What problem with PCIe(pci express cards ) would you be facing? Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 4.5.99.902 Problem with i810 EDID not honoured for [EMAIL PROTECTED]
On Mon, 8 May 2006, David Dawes wrote: On Mon, May 08, 2006 at 12:07:49PM +0100, Barry Scott wrote: David Dawes wrote: On Wed, May 03, 2006 at 10:17:11AM +0100, Barry Scott wrote: Can you tell me if this is supposed to work? If not why not? It is supposed to work. The i810 driver (for = i830) handles modes differently than most drivers, and I don't know if the problem lies there or not. What are the results of running: XFree86 -autoconfig -screen 'Builtin Default vesa Screen 0' xrandr says its running at [EMAIL PROTECTED] but the screen claims its running at 1024x768. Which is progress as X appears to be doing the right thing. I don't trust the Hitachi panel to be working at 1360x768 as the Windows Nvidia drivers get the same result as the X i810, e.g. choose 1360x768 and panel says 1024x768. Does it visually look like 1360x768? For purposes such as these, I set my background using ... xsetroot -mod 15 15 -bg black -fg rgb:00/9F/9F ... and start counting. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
RE: [XFree86] Clipping graphic primitives to visible area of Window
On Tue, 11 Apr 2006, Mark Vojkovich wrote: This is probably either a r128 driver bug or a bug in the acceleration architecture (XAA). If you had access to a non-ATI video card that would be an interesting test. What might fix the problem without resorting to NoAccel is to prevent XAA from putting pixmaps in videoram. You can do that with: Option XaaNoOffscreenPixmaps If this was a r128 driver bug related to rendering to offscreen videoram or if this was an XAA problem related to rendering to backing store's backing pixmap, that would probably fix the problem. If it were a problem with XAA breaking backing store's wrappers, it probably wouldn't. But there may be other causes - perhaps that driver disables something else when disabling acceleration. From looking through driver code, it does appear that NoAccel also disables some things related to 3D. I think it likely this is an issue with the driver's handling of scissors. See if the problem disappears when you set both ... Option XaaNoScanlineCPUToScreenColorExpandFill ... and ... Option XaaNoScanlineImageWriteRect If this works, the driver's other XAA primitives will need to be changed to reset the scissors to their default values. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xterm's ongoing setgid saga
On Tue, 4 Apr 2006, Thomas Dickey wrote: On Tue, 4 Apr 2006, Marc Aurele La France wrote: This still isn't right, for `make install`. Indeed, not all glibc-based then fix it in config/cf/*, where it belongs. Not really. xterm is the only one that needs utmp. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: make install fails
On Sun, 26 Mar 2006, Thomas Dickey wrote: On Sun, 26 Mar 2006, Andrew C Aitchison wrote: make[3]: Entering directory `/home/XFree86/4.2/std/xc/programs/xterm' install -c `if [ \`grep ^utmp: /etc/group\` ]; then echo ' -m 2755 -g utmp'; else echo ' -m 4711'; fi` xterm /usr/X11R6-v4/bin/xterm install: installing multiple files, but last argument, `/usr/X11R6-v4/bin/xterm' is not a directory Try `install --help' for more information. I think that the double quotes are turning the -m flags into a filename beginning with a space. The enclosed patch seems to work. I saw the commit message, but the proposed solution still doesn't solve the problem: it is possible to have a utmp group defined but not use it for the file-permissions on /var/whatever. There's no 100% standard pathname for that file, so the configure script does some work to decide if it looks reasonable. The configure script is irrelevant. If you come up with a means to make this work properly with imake Xinstall, then by all means do so. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: make install fails
On Sun, 26 Mar 2006, Andrew C Aitchison wrote: make[3]: Entering directory `/home/XFree86/4.2/std/xc/programs/xterm' install -c `if [ \`grep ^utmp: /etc/group\` ]; then echo ' -m 2755 -g utmp'; else echo ' -m 4711'; fi` xterm /usr/X11R6-v4/bin/xterm install: installing multiple files, but last argument, `/usr/X11R6-v4/bin/xterm' is not a directory Try `install --help' for more information. I think that the double quotes are turning the -m flags into a filename beginning with a space. The enclosed patch seems to work. This has been committed. Thanks. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xterm warning regressions (was Re: CVS Update: xc (branch: trunk))
On Tue, 14 Mar 2006, Thomas Dickey wrote: On Tue, 14 Mar 2006, David Dawes wrote: and adds this one: main.c:2586: warning: `pty_search' defined but not used yes, that's an annoyance (but the proposed fix reversed the general process of removing special definitions from main.c). Please expand on this statement. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xterm warning regressions (was Re: CVS Update: xc (branch: trunk))
On Thu, 16 Mar 2006, Thomas Dickey wrote: On Thu, 16 Mar 2006, Marc Aurele La France wrote: On Tue, 14 Mar 2006, Thomas Dickey wrote: On Tue, 14 Mar 2006, David Dawes wrote: and adds this one: main.c:2586: warning: `pty_search' defined but not used yes, that's an annoyance (but the proposed fix reversed the general process of removing special definitions from main.c). Please expand on this statement. It overrode a definition in ptyx.h, moving the definition inline into main.c, rather than refining it in xterm.h as a fallback for a configure script test. That's irrelevent. My fix holds whether xterm is built through imake or through autowhatchamecallsit. (main.c has too many special cases) Indeed... Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: xterm warning regressions (was Re: CVS Update: xc (branch: trunk))
On Thu, 16 Mar 2006, Thomas Dickey wrote: On Thu, 16 Mar 2006, Marc Aurele La France wrote: main.c, rather than refining it in xterm.h as a fallback for a configure script test. That's irrelevent. My fix holds whether xterm is built through imake or no, it is relevant. I considered a change like that some time ago, decided that it was too ugly to bother with, and that it would be better to do it properly sometime, leaving the warning as a reminder than cover it up. I agree my fix is a coverup, but, as I see it, this has gone on for waaayyy too long. xterm's tty handling needs a major rewrite, perhaps along the lines of OpenSSH's, and I just don't see that happening any time soon. So perhaps, a post-it on your refrigerator would be more productive than reminding everybody else. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: cross-compile XFree86 on arm error , help :)
On Thu, 9 Feb 2006, [gb2312] С´º wrote:
make install, the error below :
thanks :(
+ rm -f /usr/X11R6_ARM/lib/libfontconfig.so.1
+ ln -s libfontconfig.so.1.0 /usr/X11R6_ARM/lib/libfontconfig.so.1
+ rm -f /usr/X11R6_ARM/lib/libfontconfig.so
+ ln -s libfontconfig.so.1.0 /usr/X11R6_ARM/lib/libfontconfig.so
install in lib/fontconfig/src done
make[4]: Leaving directory `/home/zqy/X_4.3/build/lib/fontconfig/src'
installing in lib/fontconfig/fc-cache...
make[4]: Entering directory `/home/zqy/X_4.3/build/lib/fontconfig/fc-cache'
install -c fc-cache /usr/X11R6_ARM/bin/fc-cache
if [ x${DESTDIR} = x ]; thenset -x;
LD_LIBRARY_PATH=../../../exports/lib FONTCONFIG_PATH=../../../lib/fontconfig
../../../exports/bin/fc-cache -v -f; fi
+ LD_LIBRARY_PATH=../../../exports/lib
+ FONTCONFIG_PATH=../../../lib/fontconfig
+ ../../../exports/bin/fc-cache -v -f
/bin/sh: ../../../exports/bin/fc-cache: cannot execute binary file
make[4]: *** [install] Error 126
make[4]: Leaving directory `/home/zqy/X_4.3/build/lib/fontconfig/fc-cache'
make[3]: *** [install] Error 2
First, this is not a snippet from an XFree86 install. This is a separate
install of the fontconfig library. Secondly (and because of the first), this
build picked up the build host's host.def which doesn't set CrossCompiling to
YES.
Marc.
+--+---+
| Marc Aurele La France | work: 1-780-492-9310 |
| Academic Information and| fax:1-780-492-1729 |
|Communications Technologies | email: [EMAIL PROTECTED] |
| 352 General Services Building +---+
| University of Alberta | |
| Edmonton, Alberta | Standard disclaimers apply|
| T6G 2H1 | |
| CANADA | |
+--+---+
XFree86 developer and VP. ATI driver and X server internals.
Re: [PATCH] to comply using Linux-2.6.16-rc2
On Mon, 6 Feb 2006, Jeff Chua wrote: I make this patch in order to compile latest CVS source with Linux-2.6.16-rc2 XFree86 Version 4.5.99.20 Release Date: 23 January 2006 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.16-rc2 i686 [ELF] I know it would be nice to do that change in input.h, but afraid it'll get shot down in lkml. Someone want to try? Please comment. Problems like this show up every so often. They are caused by directly using kernel headers to rebuild glibc. You are instead supposed to use laundered headers, such as the ones available at ... http://ep09.pld-linux.org/~mmazur/linux-libc-headers/ ... among others. And, yes. If you bring this up on LKML, you will indeed be flamed. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: How to debug xfree86 successfully
On Fri, 4 Nov 2005, cckuo wrote: I want to trace the behaviors of my video driver under Xfree86 and have done the following steps which were collected from this mailing list. 1. prepare two machines; one is called host, and another is called target. 2. type makeg World under xc folder 3. telnet the target from host and run gdb /usr/X11R6/bin/XFree86 4. under the gdb command mode type run :0 Here my question comes from. I type list under gdb command mode. I saw the source code of XFree86, main.c, but if I set the breakpoint about the driver functions such as Probe, ScreenInit and EnterVT, which are assigned to pScrn. The gdb told me that he cannot find the symbol file. Are there some steps between 1-4 I made wrong or in fact I didn't build the symbol file correctly? The most straight-forward way of debugging an X server is to build it with ... #define DoLoadableServer NO ... in your xc/config/cf/host.def. After a `make World`, this'll build everything into one binary. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problems with mach64 on NetBSD/sparc64
On Thu, 6 Oct 2005, Martin Husemann wrote: On Thu, Oct 06, 2005 at 01:39:10PM -0600, Marc Aurele La France wrote: No. My preference is definitely to keep the OS out of the way, as much as possible Ok, but in this case that is not realy possible. You need a OS driver that understands your mmap() call anyway to get the IOMMU mappings correct consistent. We do not allow generic mmap'ing of PCI memory ranges, because that would mean we had to try very hard to keep all OS drivers out of the way or somehow synchronize the userland mapping with them. On i386 with plain pass-through PCI access thinks are certainly different. You're assuming the X server would indiscriminately trample all over such mappings. That's not the case on SPARC any more than it is on x86. I also don't see why this is not really possible with NetBSD, when it works very well through Linux and SunOS (... and I _do_ mean through). The idea here is to support PCI, not PCI/x86, PCI/SPARC, ad nauseam. This means creating a generic model of PCI and filtering out host differences before presenting that model to our video drivers. The less lobotomies of PCI the underlying OS implements, the better. The only restriction on PCI this architecture actually implements is its default handling of master aborts. And even that assertion is debatable. _All_ other restrictions are necessarily OS inventions. No matter how you look at it, some NetBSD kernel work will be required for multihead to work on both uni-domain (Sabre Hummingbird) and multi-domain (Psycho, Schizo Tomatillo) systems. The first thing to look at is PCI I/O. I see from the logs posted on this thread that the kernel clobbers OBP's assignment of PCI I/O BARs. This clobbering needs to be removed. There also needs to be an ability to map in one chunk the entirety of a host bridge's PCI I/O range. Doing this mapping per device isn't practical because PCI limits assignments to 256 bytes (which is less than the host page size) and per-device mappings don't allow for unregistered assignments such as those for VGA, 8514/A, etc. It doesn't really matter whether PCI memory mappings are done per-device, per-domain, or through some more liberal /dev/mem clone. The caveat here is that should you require that such mappings be done per-device, you had better ensure even PCI ROM pointers are assigned, valid and mappable. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problems with mach64 on NetBSD/sparc64
On Thu, 6 Oct 2005, Michael wrote: The only work-around is to remove the XL. It won't work anyway, at least not under NetBSD/sparc64 as things currently stand. There's no way for the ati driver to simply ignore adaptors it cannot mmap? How can it, when the port FatalError's mmap() failures? Ouch. Hmm, many ports seem to do that. On the other hand drivers seem to check wether xf86MapVidMem() returns NULL ( well, the ati driver does ) so - is there a good reason to FatalError() in whatever_MapVidMem() ? If not I'd just let it return NULL on sparc64 and see what happens. FatalError'ing mmap() failures here normally indicate a problem with the server's OS interface, rather than one with the server itself. Think of these as reminders to developers that more work needs to be done. So, yes, you should see what happens when mmap() failures return NULL. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: _X11TransSocketUNIXConnect: Can't connect: errno = 111
On Fri, 21 Oct 2005, Stefan Strobl wrote: Thanks for the help. Indeed it's compiling without errors now. Trying to run XF86Setup doesn't work though. When trying to swith to graphics mode I get the following error: _X11TransSocketUNIXConnect: Can't connect: errno = 111 and after some attempts it gives up saying: Unable to communicate with X server! Any ide what's going wrong now? It looks to me your kernel doesn't support unix sockets. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: undefined reference to 'yylex'
On Thu, 20 Oct 2005, Stefan Strobl wrote: I'm trying to compile XFree86 3.3.6 on a SuSE 8.1 (kernel 2.4.19) but get the following compile errors: [...] In file included from connection.c:79: /usr/include/stdlib.h:699: parse error before int make[4]: *** [connection.o] Error 1 make[4]: Leaving directory /usr/XFree86/3.3.6/source/xc/programs/xfs/os` make[3]: *** [os] Error 2 [...] Hard to imagine there's something wrong with the stdlib.h, so what else could it be? I didn't tamper with the sources... Move stdlib.h to be the first #include in connection.c. [...] /usr/lib/gcc-lib/i486-suse-linux/3.2/../../../../i486-suse-linux/bin/ld: cannot find -ltk collect2: ld returned 1 exit status make[5]: *** [XF86Setup] Error 1 [...] I'm using tk/tcl-8.4-48 while xf86site.def suggests to be using tk-4.0 and Tcl-7.4. Might that be a problem? Looks like TkLibDir isn't specified correctly in your host.def. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Sun Creator and XRender
On Tue, 18 Oct 2005, Michael wrote: The problem is definitely in the Xserver: - sparc64 client with X in ARGB running on a powerpc box - text colours are right - sparc64 client and X with FFB/ABGR - wrong text colours - sparc64 client and X with mach64 or mga in ARGB - text colours are right - client on powerpc, X on sparc64 with FFB/ABGR - text colours are wrong - sparc64 without Xrender support - text colours are right ... so it should be somewhere in Xrender. There's a bug ( or at least an inconsistency ) in xf86Helper / xf86SetWeight(): scrp-offset.red = ffs(mask.red); scrp-offset.green = ffs(mask.green); scrp-offset.blue = ffs(mask.blue); this sets 1-based offsets while the rest of the code ( or at least Xrender's PictureCreateDefaultFormats() ) expects 0-based ones. That's already been fixed in our repository. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Sun Creator and XRender
On Sat, 15 Oct 2005, Michael wrote: since the sunffb driver doesn't support the XRender extension but the graphics processor supports alpha blending and a few other nice tricks I've been poking around a bit to add this sort of functionality. The problem seems to be that sunffb doesn't use xaa or the standard framebuffer manager. so I couldn't get the included render code to work. So my questions are: - is there a text somewhere describing how to add xrender functionality to a driver without using fbPictureInit() ? - is there some more comprehensive ffb documentation available somewhere? I think I know how alpha blending and so on is supposed to work ( from reading the mesa driver source ) but there are still a few more questions. This has already been done in X.Org's repository and it is on my to-do-soon list to merge in. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: missed reference to xfree86/os-support/linux/agpgart.h
On Sat, 15 Oct 2005, Andrew C Aitchison wrote: On the off-chance that this hasn't already been spotted, here is a patch to make xc/programs/Xserver/hw/tinyx/linux/agp.c compile after xfree86/os-support/linux/agpgart.h was retired in favour of the system version. As a stopgap, I've already undone our agpgart.h's deletion. I agree it's best to use the system's copy (if available). I'll review this after I've fixed all the other build problems I have caused. Please bear with me. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problems with mach64 on NetBSD/sparc64
On Tue, 4 Oct 2005, Michael wrote: Second - the driver seems to either ignore the BusID parameter. Log excerpt: (--) PCI: (1:2:0) ATI Technologies Inc 3D Rage Pro 215GP rev 92, Mem @ 0xe10 0/24, 0xe200/12, I/O @ 0xff00/8, BIOS @ 0xe102/17 (--) PCI: (2:1:0) ATI Technologies Inc Rage XL rev 39, Mem @0x1100/24, 0x12 00/12, I/O @ 0xff00/8, BIOS @ 0x1202/17 That's the onboard Rage Pro and a Sun PGX64 in a Sun Ultra 5 The Device section in XF86Config: Section Device ### Available Driver options are:- ### Values: i: integer, f: float, bool: True/False, ### string: String, freq: f Hz/kHz/MHz ### [arg]: arg optional #Option accel # [bool] #Option crt_display # [bool] #Option composite_sync# [bool] #Option hw_cursor # [bool] #Option mmio_cache# [bool] #Option test_mmio_cache # [bool] #Option panel_display # [bool] #Option probe_clocks # [bool] #Option reference_clock # freq #Option shadow_fb # [bool] #Option sw_cursor # [bool] Identifier Card0 Driver ati VendorName ATI BoardName 3D Rage Pro 215GP ChipSet ati ChipId 0x4750 ChipRev 0x5c BusID PCI:1:2:0 EndSection but XFree fails with this: (II) ATI: Candidate Device section Card0. (II) ATI: Unshared PCI/AGP Mach64 in slot 1:2:0 detected. Fatal server error: xf86MapVidMem: could not mmap screen [s=2000,a=1200] (Invalid argument) So it tries to map PCI resources belonging to the Rage XL while the Device section clearly says it should use the onboard Rage Pro. Even if it's only probing it shouldn't fail here since the device it's supposed to use is definitely usable - with the Rage XL removed it works as expected. I'd need to see a log of this. The log and config are attached. ATIProbe() tries to mmap() every adapter of interest in the system so that it can probe them. This happens before the driver even looks at XF86Config information (which might not exist). But that's not the real issue here. The problem is that wscons on NetBSD/sparc64 does not consider secondary adapters as part of the console. This means that multi-head cannot work as this port is currently coded. I would venture to guess that a different file descriptor is needed for every adapter in the system. Another possibility is to convert the NetBSD/sparc64 to use the common layer's domain scheme, essentially translating every mmap() request into one of /dev/mem. Either way, there's work to be done in this port's os-support layer. The only work-around is to remove the XL. It won't work anyway, at least not under NetBSD/sparc64 as things currently stand. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problems with mach64 on NetBSD/sparc64
On Thu, 6 Oct 2005, Michael wrote: The only work-around is to remove the XL. It won't work anyway, at least not under NetBSD/sparc64 as things currently stand. There's no way for the ati driver to simply ignore adaptors it cannot mmap? How can it, when the port FatalError's mmap() failures? Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problems with mach64 on NetBSD/sparc64
On Thu, 6 Oct 2005, Martin Husemann wrote: On Thu, Oct 06, 2005 at 09:51:38AM -0600, Marc Aurele La France wrote: I would venture to guess that a different file descriptor is needed for every adapter in the system. Yeah, I would prefer to use /dev/fb* for the PCI devices too (this is what is used for SBUS and UPA devices already) - and avoid all the PCI bus scanning that way too. No. My preference is definitely to keep the OS out of the way, as much as possible, because it's more portable to do so (from our perspective). This OS-as-God idea is out-to-lunch, IMNSHO. Look at Linux as an example of why. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Problems with mach64 on NetBSD/sparc64
On Wed, 28 Sep 2005, Michael wrote: we ran into two problems with the ati driver. First - it seems to screw up when switching resolution on Sun PGX64 cards ( these use a Rage XL with 8MB VRAM). The result is a monitor reporting frequencies out of range, even when forced to use something very conservative that works with the same monitor and a different graphics controller. It works just fine with a Rage Pro. If the XL has no ix86 BIOS, the ReferenceClock option (documented in README.ati) likely needs to be specified. Accurately detecting this value is not possible. Second - the driver seems to either ignore the BusID parameter. Log excerpt: (--) PCI: (1:2:0) ATI Technologies Inc 3D Rage Pro 215GP rev 92, Mem @ 0xe10 0/24, 0xe200/12, I/O @ 0xff00/8, BIOS @ 0xe102/17 (--) PCI: (2:1:0) ATI Technologies Inc Rage XL rev 39, Mem @0x1100/24, 0x12 00/12, I/O @ 0xff00/8, BIOS @ 0x1202/17 That's the onboard Rage Pro and a Sun PGX64 in a Sun Ultra 5 The Device section in XF86Config: Section Device ### Available Driver options are:- ### Values: i: integer, f: float, bool: True/False, ### string: String, freq: f Hz/kHz/MHz ### [arg]: arg optional #Option accel # [bool] #Option crt_display # [bool] #Option composite_sync# [bool] #Option hw_cursor # [bool] #Option mmio_cache# [bool] #Option test_mmio_cache # [bool] #Option panel_display # [bool] #Option probe_clocks # [bool] #Option reference_clock # freq #Option shadow_fb # [bool] #Option sw_cursor # [bool] Identifier Card0 Driver ati VendorName ATI BoardName 3D Rage Pro 215GP ChipSet ati ChipId 0x4750 ChipRev 0x5c BusID PCI:1:2:0 EndSection but XFree fails with this: (II) ATI: Candidate Device section Card0. (II) ATI: Unshared PCI/AGP Mach64 in slot 1:2:0 detected. Fatal server error: xf86MapVidMem: could not mmap screen [s=2000,a=1200] (Invalid argument) So it tries to map PCI resources belonging to the Rage XL while the Device section clearly says it should use the onboard Rage Pro. Even if it's only probing it shouldn't fail here since the device it's supposed to use is definitely usable - with the Rage XL removed it works as expected. The Xserver in question is: XFree86 Version 4.5.0 Release Date: 16 March 2005 X Protocol Version 11, Revision 0 Build Operating System:NetBSD/sparc64 3.99.8 - The NetBSD Foundation, Inc. Current Operating System: NetBSD censored 3.99.9 NetBSD 3.99.9 (INISHOWEN) #594: Fri Sep 23 06:57:25 EDT 2005 [EMAIL PROTECTED]:/data/src/sys/arch/sparc64/compile/INISHOWEN sparc64 I'd need to see a log of this. any ideas? Anything we should import from XFree -current? I think doing so for this problem is a little premature. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: miext/shadow/shrotate.c speedup and question
On Tue, 21 Sep 2005, Staffan Ulfberg wrote: I have a Sharp Zaurus C3100, where X normally runs rotated 90 degrees, using a shadow framebuffer. I've been hacking a bit on getting the code that blits a rotated shadow onto the display a bit faster and came up with the included patch. Blitting in rotated mode is about 4x the previous speed. Non-rotated copies are about the same speed; maybe up to 10% slower for small rectangles (on the Zaurus). The idea is to copy the area in blocks of 32x32 pixels, to reduce the number of cache misses, which are unavoidable when walking either the source or the destination bitmap across the scanlines. 16x16, 24x24, andd 32x32 yields about the same result, so I chose 32x32 since it seems best for the non-rotated modes. Any comments on this patch? This looks good to me. I have committed it. I have a question myself about the original code: This is the function call to get the address in the destination frame buffer to write to: win = (FbBits *) (*pBuf-window) (pScreen, scr_y, scr_x 2, SHADOW_WINDOW_WRITE, winSize, pBuf-closure); The scr_x 2 part seems, to me, to assume that sizeof(FbBits) == 4. Am I missing something, or is this really correct? Anyway, my patch does not make this problem either better or worse, but this is a chance to fix it if it is a bug... As we compile this, FbBits will always be a CARD32. Thanks for the patch. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 4.5.99.11 problems with i810
On Fri, 16 Sep 2005, Takaaki Nomura wrote: On Thu, 15 Sep 2005 10:38:38 -0600 (MDT), Marc Aurele La France wrote: On Thu, 15 Sep 2005, Takaaki Nomura wrote: I'm using i810 based built-in video card. 4.5.99.11 loader server doesn't work. 4.5.99.11 static server works. I've attached both of the logs below. I'm using Japanese 106 keyboard and some problems with inputs. I don't know exactly which version made the problems. A backtrace of the problem would be most useful. How can I take a backtrace? I'm sorry, but I can't use the test machine for about a week. I've been able to duplicate this problem and the attached (which I've already committed) fixes it. Thanks for reporting the problem. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. loader.diff.gz Description: Binary data
Re: xf86InterpretEDID xf86DoEDID_Option symbols unresolved
On Fri, 16 Sep 2005, Jeff Chua wrote: The lastest CVS source can't start X11 after I do a fresh make World. Here's the error ... Symbol xf86InterpretEDID from module /usr/X11R6/lib/modules/libvbe.a is unresolved! Symbol xf86DoEDID_Option from module /usr/X11R6/lib/modules/libvbe.a is unresolved! ... followed by a segfault. When I roll back to CVS from August, it works without any problem. This problem surfaces only after I do a make World from a clean CVS sources. I was doing daily CVS update followed by make and could get X11 to start without any problem. This one works ... XFree86 Version 4.5.99.10 Release Date: 23 August 2005 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.13-mh1 i686 [ELF] Something changes in the CVS after that ... I've been able to duplicate this and the attached (already committed) fixes it. Thanks for reporting the problem. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: 4.5.99.11 problems with i810
On Thu, 15 Sep 2005, Takaaki Nomura wrote: I'm using i810 based built-in video card. 4.5.99.11 loader server doesn't work. 4.5.99.11 static server works. I've attached both of the logs below. I'm using Japanese 106 keyboard and some problems with inputs. I don't know exactly which version made the problems. A backtrace of the problem would be most useful. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: libXaw/Viewport widget initialization
On Wed, 14 Sep 2005, Alexander Pohoyda wrote: I do have one request though. If you are to contune with more Xaw work, please ensure you do not adversely affect Xaw6. What do you mean? How do I ensure this? I mean that, even with your changes to xc/lib/Xaw, you should ensure xc/lib/Xaw6 is still buildable. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Moving XtWidth, XtHeight, XtX and XtY macroes from XmP.h to IntrinsicP.h
On Wed, 14 Sep 2005, Alexander Pohoyda wrote: On Tue, 13 Sep 2005, Marc Aurele La France wrote: On Tue, 13 Sep 2005, Alexander Pohoyda wrote: Don't you think it makes sense to move (some of) those macroes from Xm/XmP.h to X11/IntrinsicP.h file? They seem to belong there. Given that what you actually mean is Xt/IntrinsicP.h, I'd tend to agree with you. Especially given that, in out source tree, only Xaw references these anyway. ... even though Xm/XmP.h is a Motif thing (i.e. not distributed with any XFree86 or X.Org server, per se). You're right. I should have checked first. ' So, should I not use those macroes in libXaw at all, or should I bring them to Xt headers files like this: #ifndef XtWidth #define XtWidth(w) (((Widget)(w))-core.width) #endif ... Which solution do you prefer? My preference is definitely b, i.e. your second choice. Mind you I've no idea how this would affect the various Xm/XmP.h's out there. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Moving XtWidth, XtHeight, XtX and XtY macroes from XmP.h to IntrinsicP.h
On Tue, 13 Sep 2005, Alexander Pohoyda wrote: Don't you think it makes sense to move (some of) those macroes from Xm/XmP.h to X11/IntrinsicP.h file? They seem to belong there. Given that what you actually mean is Xt/IntrinsicP.h, I'd tend to agree with you. Especially given that, in out source tree, only Xaw references these anyway. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Moving XtWidth, XtHeight, XtX and XtY macroes from XmP.h to IntrinsicP.h
On Tue, 13 Sep 2005, Marc Aurele La France wrote: On Tue, 13 Sep 2005, Alexander Pohoyda wrote: Don't you think it makes sense to move (some of) those macroes from Xm/XmP.h to X11/IntrinsicP.h file? They seem to belong there. Given that what you actually mean is Xt/IntrinsicP.h, I'd tend to agree with you. Especially given that, in out source tree, only Xaw references these anyway. ... even though Xm/XmP.h is a Motif thing (i.e. not distributed with any XFree86 or X.Org server, per se). Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: libXaw/Viewport widget initialization
On Tue, 13 Sep 2005, Alexander Pohoyda wrote: The original problem is that when I use my experimental Hyperbolic Tree widget as a child of Viewport widget, the size of unrealized Viewport widget is not yet set and thus I cannot find out how much space I have available for layout. I have the following patch in mind and it solves the problem for me. Does it make sense or should I look for another solution? Index: Viewport.c === RCS file: /cvs/xc/lib/Xaw/Viewport.c,v retrieving revision 1.11 diff -u -r1.11 Viewport.c --- Viewport.c 14 Dec 2001 19:54:45 - 1.11 +++ Viewport.c 13 Sep 2005 18:18:07 - @@ -292,6 +292,12 @@ w-form.default_spacing = 0; /* Reset the default spacing to 0 pixels */ /* + * Get the size from the parent + */ +XtWidth(w) = XtWidth(XtParent(w)); +XtHeight(w) = XtHeight(XtParent(w)); + +/* * Initialize all widget pointers to NULL */ w-viewport.child = NULL; That looks fine to me. I do have one request though. If you are to contune with more Xaw work, please ensure you do not adversely affect Xaw6. Thanks. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: tdfx and DDC2
On Tue, 30 Aug 2005, Michael wrote: the attached patch adds DDC2/I2C support to the tdfx driver which has the distinct advantage to work anywhere since it doesn't depend on the vbe module. It will try DDC2 first and if that fails fall back to the old vbe stuff when possible. Moved mode validation and related stuff /after/ monitor detection. That looks reasonable. Does the vbe/int10 portion still need to be disabled for PowerPC? I don't see why they should be enabled - they're PC-specific and even with x86 emulation they would be pretty much useless since you're not too likely to encounter a graphics board with PC firmware in a Mac ( or other PowerPC boxes ) That's _no_ reason to disallow them. After all even your Mac has PCI slots, not Mac-PCI slots, because the later don't exist. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: tdfx and DDC2
On Tue, 30 Aug 2005, Ian Romanick wrote: Tim Roberts wrote: Michael wrote: I don't see why they should be enabled - they're PC-specific and even with x86 emulation they would be pretty much useless since you're not too likely to encounter a graphics board with PC firmware in a Mac ( or other PowerPC boxes ) Wrong. No hardware manufacturer in their right mind would build a Mac-only PCI graphics board, with the possible exception of Apple. They're going to build a generic graphics board that works in a PC and by the way also works in a Mac. Such a board will have a video BIOS. That is 100% untrue. Take *any* AGP or PCI card, with one* exception, made for the Mac and it will not work in a PC. Macs (and Suns and IBM pSeries) use OpenFirmware (byte-code compiled Forth) and PCs use compiled x86 for their respective firmwares. Neither one works with the other. Not entirely true. What you say only matters for the primary head, and only because most manufacturers package only one image (x86, EFI, OpenFirmware, etc) in their PCI ROMs. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +---+ | University of Alberta | | | Edmonton, Alberta | Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+---+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
