CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/10/23 04:03:25 Log message: Snapshot: 4.7.99.4 Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG xf86Date.h xf86Version.h Revision ChangesPath 3.3919+4 -2 xc/programs/Xserver/hw/xfree86/CHANGELOG 1.148 +2 -2 xc/programs/Xserver/hw/xfree86/xf86Date.h 3.662 +2 -2 xc/programs/Xserver/hw/xfree86/xf86Version.h ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
Re: TWM: truetype support
(I always considered the significantly simpler approach being enough: the user in enabling TWM_USE_XFT voluntarily passes the point of no return; if xft-font problems arise, then these are to be solved.) Well, that's the point. As you have it, the end user does _not_ in fact decide on TWM_USE_XFT. The distributor does. Marc. I not quite sure if this is the essential point in our case who and how compiles twm, but which fonts are installed and what stands in system.twmrc for a user not wishing to touch the default, distributor-provided configuration. Having not verified, but I strongly suspect if starting the unmodified twm having first removed the 'misc/' font directory entirely, then X is not going to find 'fixed', and as of now, twm refuses to start. It appears, 'fixed' is an alias to something like '-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1' according to misc/fonts.alias; and the key is, this name is XLFD compliant. So, luckily we are now a step closed to the solution: let's not use 'fixed' as coded-in-default in twm.c if TWM_USE_XFT is defined, but '-*-fixed-*-*-*-*-*-*-*-*-*-*-*-*', and neither XListFonts() nor XftFontOpenXlfd() have any further difficulties! (Is XListFonts() supposed to translate font alias names at all?) This looks a good idea, in fact this is what you suggested first: let XListFonts() resolve 'fixed' and then use it. Now we know how to do that. :-) (As a backside, we then remove the flexibility in twm to use the 'fixed'-alias-redirection to an arbitrary font.) Greetings, Eeri Kask P.S. We could use some better initialisation for 'fixed' as above, maybe '-*-fixed-medium-r-normal--*-100-*-*-*-*-iso8859-1' or whatever. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
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
[XFree86] Linux root file system with X window support for a powerpc board
Hi all Can anybody help me how to create a Linux root file system with X window support for a powerpc 74xx based board ? Any documents/links related to that is also welcome Thanks in advance R.Mahendravarman
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
[XFree86] xfree /SM722 reg
Hi I have downloaded Xfree source for SM722. Since iam new to this field, Can anybody help me how to install this xfree driver of SM722 for X window support ? Thanks in advance R.Mahendravarman
[XFree86] reg SM722 and Xfree
Hi all Iam working on a SM722 based Graphics card We ported linux 2.6.21 (took from the open source path sourceforge) on a powerpc based board The graphics card sits on the PMC of the above linux ported board. I have successfully integrated the framebuffer driver for the board Now I want to port xfree 86 to the board. I got the Xfree driver for the SM722 . Can anybody help me how to install xfree to the linux 2.6 or linux 2.4 and how to integrate the SM722 xfree driver ..? Thanks in advance R.Mahendravarman
[XFree86] Missing separator error when building
Trying to build on Solars 10 SPARC. XFree86 version 4.7.0 Using GNU Make, not Sun's make. Get this error: gmake[3]: Entering directory `/apps/XFree86/v4.7.0/xc/lib/freetype2' Makefile:1152: *** missing separator. Stop. Note that the word separator in the make lingo means tab character. When I look at the Makefile in the freetype2 directory I can see what the problem is. There is a section that looks like this: install:: \ @if [ -f $(DESTDIR)$(INCDIR)/freetype2/ft2build.h ]; then \ \ (set -x; $(RM) -f $(DESTDIR)$(INCDIR)/freetype2/ft2build.h) \ \ fi What make is saying is that after a target (in this case 'install') the actions under that target must be indented by a tab character. As you can see this is not the case because of those lines with a single initial backslash on them. I'm really a newbie on make and the circus around it so I do not know how to proceed. I understand that the Makefile in question is generated every time I run the 'make World' command but I'm not clever enough to follow the track and pinpoint where this goes wrong. thanks for any help you can give.
RE: [XFree86] Missing separator error when building
I've worked it out (possibly). In file .../xc/´lib/freetype2/Imakefile I've removed some trailing '@@\' from lines in the section with the install target. This avoids lines with only a '\' in the resulting Makefile. That made it work. It must admit I do not have a clue as to what I'm doing, but it worked for now. -- original message below - Trying to build on Solars 10 SPARC. XFree86 version 4.7.0 Using GNU Make, not Sun's make. Get this error: gmake[3]: Entering directory `/apps/XFree86/v4.7.0/xc/lib/freetype2' Makefile:1152: *** missing separator. Stop. Note that the word separator in the make lingo means tab character. When I look at the Makefile in the freetype2 directory I can see what the problem is. There is a section that looks like this: install:: \ @if [ -f $(DESTDIR)$(INCDIR)/freetype2/ft2build.h ]; then \ \ (set -x; $(RM) -f $(DESTDIR)$(INCDIR)/freetype2/ft2build.h) \ \ fi What make is saying is that after a target (in this case 'install') the actions under that target must be indented by a tab character. As you can see this is not the case because of those lines with a single initial backslash on them. I'm really a newbie on make and the circus around it so I do not know how to proceed. I understand that the Makefile in question is generated every time I run the 'make World' command but I'm not clever enough to follow the track and pinpoint where this goes wrong. thanks for any help you can give. ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] multiple users feature (not remote, two-keyboard)
Hi Folks, i got an question about multiple users on one machine. Its an simple calculation of my own: 1x PC 2x Keyboard (ps2, usb) 2x Graphiccard (R350 (AGP), Voodoo Banshee (PCI)) 2x Monitor 2x person (me, my girlfriend) So iv created 2 serverlayouts in my xorg.conf (but unconfigured keyboard and mices - think both serverlayouts uses corekeyboard) Sitouations: Iv started startx -- -layout voodoo :0 The left(primary voodoo) monitor gets blank. The right(secondary R350) monitor open up the graphic-mode, showing the goodold system-window-manager. ... Fine i think. i have openup the xconsole an type: startx -- layout radeon :1 oops! Unexpected termination so my question: is it possible to use linux by two persons at the same time? may is it possible to execute two instances of x? if its so, what do i have to do to do so!? --- Dis is kein Spam _ Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! http://smartsurfer.web.de/?mc=100071distributionid=0066 ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Debugging Xvfb
On 27/09/2007 10:03 AM, Marc Aurele La France wrote: On Thu, 27 Sep 2007, Duncan Murdoch wrote: Marc Aurele La France wrote: On Tue, 25 Sep 2007, Duncan Murdoch wrote: I am writing some code using OpenGL, and when run under Xvfb on MacOS it dies, with the error message X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 17 Current serial number in output stream: 19 There are a number of different reasons for which XCreateWindow() would return BadMatch. Check the man page. I have rebuilt X from XFree86 version 4.7.0 and the error has gone away. Originally the last line of man Xvfb was X Version 11 Release 6.6 XVFB(1) but now it says XFree86 Version 4.7.0 XVFB(1) So this looks like it's probably a bug in the Xvfb that Apple distributes, and the bug isn't present in XFree86 4.7.0. Still, if I could I'd like to try to work around the bug: any idea where I'd find the source for the original Xvfb, so I could try to determine what it's complaining about? Quite a bit of Apple's sources can be found at ... http://www.opensource.apple.com/darwinsource A followup on this, in case it ever bites anyone else. Source that behaves like the OSX 10.4 release of X11 is at http://www.opensource.apple.com/darwinsource/tarballs/other/X11-0.46.4.tar.gz (I'm not completely sure that's exactly what is on the CD, but it was close enough to solve my problem.) And the solution to my problem was to specify CWBorderPixel when I called XCreateWindow. Without that my call failed in the CreateWindow function in xc/programs/Xserver/dix/window.c. I don't know why no other X server cares about this. Duncan Murdoch ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: TWM: truetype support
Oops. Use this one instead. Marc. Thank you very much! (In the moment I have to finish a conference paper but in few days I'll be back at twm.) Actually I only had in mind the part considering the memory leak. You have apparently completed a huge work in delaing with fallback to bitmap raster fonts if some xft font problems arise. I never wanted to make this issue that complicated (I never even thought about this possibility), :-) so momentarily I don't yet have any opinion about reusing your work in full in this regard. (I always considered the significantly simpler approach being enough: the user in enabling TWM_USE_XFT voluntarily passes the point of no return; if xft-font problems arise, then these are to be solved.) Greetings, Eeri Kask ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] Fonts in Tinyx
Hi, i tried to find my fonts path using xset utility. but it says unable to open the display. i had export the path as: export DISPLAY=:0. .but then also i'm getting the same error . Any suggestions for this ? saravanan.
Re: [XFree86] Fonts in Tinyx
Mr Saminath, I could not find teh 'xfs' executable in my xc directory. There is a folder in /buildroot/build_mipsel/xc-011010/programs/xfs but no executables are present. Is there any file wherein i should enable this ? saravanan.
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/10/10 08:23:03 Log message: More cleanups Modified files: xc/programs/twm/: add_window.c add_window.h events.c icons.c list.h menus.c session.c util.c Revision ChangesPath 1.18 +1 -6 xc/programs/twm/add_window.c 1.9 +1 -2 xc/programs/twm/add_window.h 1.18 +1 -4 xc/programs/twm/events.c 1.11 +1 -2 xc/programs/twm/icons.c 1.8 +1 -2 xc/programs/twm/list.h 1.27 +1 -2 xc/programs/twm/menus.c 3.14 +2 -2 xc/programs/twm/session.c 1.17 +1 -6 xc/programs/twm/util.c ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
Re: TWM: truetype support
Oh, I am happy you take the time to work on twm, big thanks! :-) (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. Oops, I see, I'am very sorry about that! Now as you say, I'll understand the problem. May I kindly ask you to give me your corrections if you don't mind, as it would be pointless by me to investigate issues you have already solved (and it would save time). (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. I agree and I'll put these changes inside #ifdef TWM_USE_XFT as well. Configurable ... in what sense? Using some compile-time #define? If you prefer this, I'll do it that way. (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. I have thought about your standpoint here. This may be Xorg functionality, but if twm is run to manage the Xorg server, this functionality will be available to twm, regardless which X11 implementation/distribution twm belongs to. So I'd suggest this functionality be available as twm patch, and its everyone's own decision to include/apply it ... or not. (I have all respect in your preference not to do this if you so like.) (I am even considering to very slightly enlarge opacity support in the sense that twm should intercept these opacity property change requests from client windows and propagate them to self-created frame-windows of these top-level clients. The user is responsible to run xcompmgr in the backround, twm will not be dealing with transparency in any other way. This increases opacity code in twm maybe about ten lines or so in HandlePropertyNotify() in events.c. So if some client asks for transparency, twm wouldn't stand in the way.) (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. If you didn't, I would have asked you to do 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. (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. Other 'fixes' in this diff somehow clarify the MoveIconManager() (which is the second most heavily modified function next to DrawIconManagerEntry()), with the purpose of returning a mapped (not iconified or unmapped) client window if the icon manager window is *not* mapped. I noticed that f.forwiconmgr gets stuck on some unmapped/iconified window if the icon manager is not mapped as well, leaving the mouse sporadically somewhere on the root window (exactly there, where the iconified client window would appear if it where mapped -- and if this falls inside some other mapped window, the f.forwiconmgr cycling starts from this client again; a kind of sub-cycling emerges). So in the end one can step along *all* windows if the icon manager is mapped, and only along *mapped* windows if the icon manager is not mapped. This was my intended solution to the mouse getting lost problem. (2) In events.c.diff6 in HandleEnterNotify() I discovered a situation where entering the root window (one can enter the root window in leaving some client window on the same screen; and in leaving some other screen) while coming from some other screen and then --- being on the screen just entered NotActiveIconManager() gets called with the UnHighLight_win client window data structure on the screen just left in order to paint the iconmanager entry on that
Re: TWM: truetype support
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. Greetings, Eeri Kask ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: TWM: truetype support
On Wed, 10 Oct 2007, Eeri Kask wrote: (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. Oops, I see, I'am very sorry about that! Now as you say, I'll understand the problem. May I kindly ask you to give me your corrections if you don't mind, as it would be pointless by me to investigate issues you have already solved (and it would save time). 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. (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. I agree and I'll put these changes inside #ifdef TWM_USE_XFT as well. Configurable ... in what sense? Using some compile-time #define? If you prefer this, I'll do it that way. By configurable, I meant through .twmrc. But this might be more trouble than it's worth. So, I'd settle on adjusting spacing only for Xft fonts. (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. I have thought about your standpoint here. This may be Xorg functionality, but if twm is run to manage the Xorg server, this functionality will be available to twm, regardless which X11 implementation/distribution twm belongs to. So I'd suggest this functionality be available as twm patch, and its everyone's own decision to include/apply it ... or not. (I have all respect in your preference not to do this if you so like.) (I am even considering to very slightly enlarge opacity support in the sense that twm should intercept these opacity property change requests from client windows and propagate them to self-created frame-windows of these top-level clients. The user is responsible to run xcompmgr in the backround, twm will not be dealing with transparency in any other way. This increases opacity code in twm maybe about ten lines or so in HandlePropertyNotify() in events.c. So if some client asks for transparency, twm wouldn't stand in the way.) I doubt very much anyone would ever use XFree86's twm with X.Org's xcompmgr. But I understand your point. (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. If you didn't, I would have asked you to do this. :-) OK. Let me know when it's ready. (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. Other 'fixes' in this diff somehow clarify the MoveIconManager() (which is the second most heavily modified function next to DrawIconManagerEntry()), with the purpose of returning a mapped (not iconified or unmapped) client window if the icon manager window is *not* mapped. I noticed that f.forwiconmgr gets stuck on some unmapped/iconified window if the icon manager is not mapped as well, leaving the mouse sporadically somewhere on the root window (exactly there, where the iconified client
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
[XFree86] Fonts in Tinyx
Hi, i had compiled buildroot with tinyx (xc-011010.tar.bz2) support for MIPS development board.but i could not find any fonts being built with the tinyx? can anyone say me how to enable fonts in tinyx or where to find the fonts ? thanks in advance,
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/10/09 04:03:36 Log message: Snapshot: 4.7.99.3 Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG xf86Date.h xf86Version.h Revision ChangesPath 3.3918+4 -2 xc/programs/Xserver/hw/xfree86/CHANGELOG 1.147 +2 -2 xc/programs/Xserver/hw/xfree86/xf86Date.h 3.661 +2 -2 xc/programs/Xserver/hw/xfree86/xf86Version.h ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/10/09 17:31:40 Log message: Whitespace cleanup and ANSIfication Modified files: xc/programs/twm/: Imakefile add_window.c add_window.h cursor.c events.c gc.c gram.y iconmgr.c iconmgr.h icons.c icons.h lex.l list.c list.h menus.c parse.c parse.h resize.c screen.h session.c session.h twm.c twm.h twm.man util.c util.h xc/programs/twm/sample-twmrc/: keith.twmrc lemke.twmrc Revision ChangesPath 3.18 +7 -7 xc/programs/twm/Imakefile 1.17 +128 -145 xc/programs/twm/add_window.c 1.8 +2 -2 xc/programs/twm/add_window.h 1.7 +7 -11 xc/programs/twm/cursor.c 1.17 +119 -139 xc/programs/twm/events.c 1.8 +18 -16xc/programs/twm/gc.c 3.11 +60 -64xc/programs/twm/gram.y 1.8 +52 -59xc/programs/twm/iconmgr.c 1.8 +2 -2 xc/programs/twm/iconmgr.h 1.10 +31 -51xc/programs/twm/icons.c 1.7 +5 -5 xc/programs/twm/icons.h 3.17 +5 -5 xc/programs/twm/lex.l 1.11 +14 -24xc/programs/twm/list.c 1.7 +3 -3 xc/programs/twm/list.h 1.26 +216 -278 xc/programs/twm/menus.c 1.21 +68 -82xc/programs/twm/parse.c 1.14 +4 -4 xc/programs/twm/parse.h 1.11 +296 -321 xc/programs/twm/resize.c 1.9 +3 -3 xc/programs/twm/screen.h 3.12 +51 -133 xc/programs/twm/session.c 1.3 +2 -2 xc/programs/twm/session.h 3.18 +36 -42xc/programs/twm/twm.c 3.16 +4 -4 xc/programs/twm/twm.h 1.16 +145 -145 xc/programs/twm/twm.man 1.16 +68 -122 xc/programs/twm/util.c 1.9 +8 -8 xc/programs/twm/util.h 1.2 +1 -1 xc/programs/twm/sample-twmrc/keith.twmrc 1.2 +15 -15xc/programs/twm/sample-twmrc/lemke.twmrc ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/10/08 08:11:29 Log message: Fix typo. Modified files: xc/doc/man/X11/: XCreWin.man Revision ChangesPath 1.8 +2 -2 xc/doc/man/X11/XCreWin.man ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
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.
[XFree86] how to make xwindow working on top of v4l apis
hi, i want to bring xwindow up by using using v4l apis on bottom of xserver . i don't have a framebuffer device. can it be implemented using v4l driver (programs/Xserver/hw/xfree86/drivers/v4l/v4l.c) supplied with the XFree86-4.7.0. If not is it possible through anyother way ? Thanks in advance -Jenny
Re: [XFree86] how to make xwindow working on top of v4l apis
On Mon, 8 Oct 2007, jenny tc wrote: i want to bring xwindow up by using using v4l apis on bottom of xserver . i don't have a framebuffer device. can it be implemented using v4l driver (programs/Xserver/hw/xfree86/drivers/v4l/v4l.c) supplied with the XFree86-4.7.0. If not is it possible through anyother way ? The V4L X driver doesn't require a kernel framebuffer device any more than its kernel counterpart does, so it should work with any other X driver that also supporrts XVideo surfaces. 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. ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/10/03 07:28:21 Log message: Slight correction to prior commit to ensure saveBIOSMemSize is set to 0 should attempts to retrieve this value from the BIOS fail. Modified files: xc/programs/Xserver/hw/xfree86/drivers/i810/: i830_driver.c Revision ChangesPath 1.101 +4 -1 xc/programs/Xserver/hw/xfree86/drivers/i810/i830_driver.c ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
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
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/10/02 07:47:30 Log message: 11. Fix i830 driver bug that occurs when the amount of video memory initially reported by the BIOS is zero (Marc La France). Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG xc/programs/Xserver/hw/xfree86/drivers/i810/: i830_driver.c Revision ChangesPath 3.3917+3 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG 1.100 +15 -13 xc/programs/Xserver/hw/xfree86/drivers/i810/i830_driver.c ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
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
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. (Regarding other aspects in XFT-font loading code I followed your suggestions.) Greetings, Eeri Kask ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: TWM: truetype support
Eeri Kask wrote: This means, any performance degrading or huge memory footprint you are going to observe from now on will hopefully reveal problems only in the xft-subsystem and not in twm. Xft has disclosed probably a very old bug in twm! :-) (Drawing with a current screen GC onto a 'noncurrent' screen.) 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. (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.] (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. 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.) (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] (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. 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.) (6) twm-1.0.3-diff6.Fixes.tgz Here are bugs I encountered in twm as improving icon manager functionality; some are serious. (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. These are the most important modifications I feeled necessary to turn the icon manager --- mostly by popping it on and off on demand --- into a useful tool for keyboard-driven focus and mouse navigation along client windows. Please let me know if you have problems, differing preferences or further good ideas regarding this. As further work the icon manager has few bugs remaining I have observed but not yet investigated (some occurring in multiscreen environments). How it now looks like you can see at www.inf.tu-dresden.de/~ek1/TheGIMP-iconmgr-screenshot.png (Btw. menutitle is painted with titlebar font (as a menu-title-bar), not included in the patches. There are some font height issues to be decided regarding this in order to make it 'failsafe'.) Greetings, and have fun, Eeri Kask P.S. If you don't mind tweaking in these patches, then please help test diff7, diff6 and diff5 first. :-) I'll consider diff1...diff4 finished if no bugs (and needed spacing corrections) become apparent. 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'.) :-) twm-1.0.3-diff1.MyFont_ChangeGC.tgz Description: application/compressed-tar twm-1.0.3-diff2.TWM_USE_XFT.tgz Description: application/compressed-tar twm-1.0.3-diff3.Spacing.tgz Description: application/compressed-tar twm-1.0.3-diff4.TWM_USE_OPACITY.tgz Description: application/compressed-tar twm-1.0.3-diff5.Appearance.tgz Description: application/compressed-tar twm-1.0.3-diff6.Fixes.tgz Description: application/compressed-tar twm-1.0.3-diff7.Improvements.tgz
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/28 08:53:28 Log message: 10. Fix byte-swapping issues in libXft's handling of XImages (Alan Brown, Bugzilla #1687). Modified files: xc/lib/Xft/: xftswap.c xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 1.2 +8 -3 xc/lib/Xft/xftswap.c 3.3916+3 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
Re: TWM: truetype support
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;
(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?)
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.
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... :-)
Greetings,
Eeri Kask
___
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
Marc Aurele La France wrote: 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. It makes sense if I extract the iconmanager window entry drawing from (4)-Appearance patchset and move it to (6)-Improvements; then swap (4) and (3)-Opacity, so patches (1)...(3) replace bitmap font rendering with xft including all vertical spacing changes, and these improvements can be treated as a whole. So I'll do that. [] 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. :-) This can be remedied with the use of XListFonts(). Marc. I don't quite catch your suggestion, please help, be more specific. :-) It seems XftFontOpenName() is quite robust, even if I give it '\0' character as a font name, it returns a quite good replacement. So the easiest way would be to rely on the smartness of XftFontOpenName()? (In fact, I suspect we will never know for sure if our requested font is really what we get out of XftFontOpenName() in the end, so maybe it doesn't make much sense to do lots of work in formulating the fallback/default replacement request?) Greetings, Eeri Kask ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re Re: another i810 crash when switching bewteen X and text console
Marc Aurele La France [EMAIL PROTECTED] : 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. Oops, I'm not sure to have the experience (and time ...) to do that. I'm more a sysadmin that a programmer. 865patch is a userland program (used lrmi library) and is written in a completely different way compared to the i810 driver. Loïc
Re: TWM: truetype support
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 ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: TWM: truetype support
Eeri Kask wrote: Wait, please, don't commit yet! :-) [] Here are my current twm improvement patches, organised thematically: (1) Preparatory font rendering cleanup (should have no changes compared to last time). (2) Xft-support for twm, besides macro renaming the main improvement is: use_fontset is back again, now meaning to use XftDrawStringUtf8() instead of XftDrawString8() if locale is set. (What it effectively means I don't know as I don't have anybody using twm in Chinese or Japanese, so if someone can try it out and explain me the difference, I'd be happy!) :-) (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. (4) Xft-related apperance fixes: all fixed-pixel-height based spacing computations are converted to scalable, font height-dependent spacing computations. These are effectively one-line improvements which don't (should not) have side effects. Here is one exception though -- iconmanager window entry layout. Previously iconmanager was highlighted by calling DrawIconManagerBorder(). This function now draws the whole iconmanager window label entry, and I renamed it therefore to DrawIconManagerEntry(). This is the most radical change I have made to twm and it is not that fully tested (in regard to bugs and side effects which may arise). So in case of problems let this function be as it was; and then don't remove MyFont_DrawString() at the end of HandleExpose() in events.c as well. This issue should affect no other places. I only was trying to streamline iconmanager and twm menu appearance, I was in opinion they should look somewhat similar. Or alternatively I'll try to optimise iconmanager to having only one row (not one column) with text in huge letters, like as if one had IconManagerFont sans-13:bold IconManagerGeometry =1500x10+200-300 10 IconManagerForeground white IconManagerBackground grey15 IconManagerHighlightgrey65 IconForeground white IconBackground grey15 IconBorderColor black in .twmrc. As apparent, iconmanager appearance is not completed and I am more than eager to discuss what you are thinking. This patchset (4) introduces DefaultFont keyword as it is critical to have all appearance parameters configurable from the outside and this font is used prominently in InfoWindow text rendering. Having that done I personally find twm regarding its appearance finished for now for me; and I'll continue working in my spare time in tracing bugs and put some focus and iconmanager control/usability tweaks into it, to make twm fully keyboard-usable in regard to present day GUI applications. (5) Fixes patchset is where I'll try to gather bugs/fixes as I'll find them and find fixes. (6) Then there is an Improvements patchset which is currently empty, but should include experiments with new, selected features. (In the sense of improving twm current usability, and not introducing completely new functionality. :-) Probably (1)...(4) can be made stable and completed quickly; I consider (1)...(3) finished myself if they only prove to being bugfree. Greetings, Eeri Kask twm-1.0.3-diff1.MyFont_ChangeGC.tgz Description: application/compressed-tar twm-1.0.3-diff2.TWM_USE_XFT.tgz Description: application/compressed-tar twm-1.0.3-diff3.TWM_USE_OPACITY.tgz Description: application/compressed-tar twm-1.0.3-diff4.Appearance.tgz Description: application/compressed-tar twm-1.0.3-diff5.Fixes.tgz Description: application/compressed-tar
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: [XFree86] Debugging Xvfb
On Tue, 25 Sep 2007, Duncan Murdoch wrote: I am writing some code using OpenGL, and when run under Xvfb on MacOS it dies, with the error message X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 17 Current serial number in output stream: 19 There are a number of different reasons for which XCreateWindow() would return BadMatch. Check the man page. I think MacOS uses the XFree86 version of Xvfb, but my first question is how can I tell for sure, and how do I determine which version I've got? The XFree86, or X.Org, version associated with Xvfb should at the bottom of Xvfb's man page. (I note that on the MacOS system I have access to here, X support is a mixture of various XFree86 and X.Org versions.) 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. ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/25 08:24:10 Log message: Fix minor build glitch Modified files: xc/programs/x11perf/: Imakefile Revision ChangesPath 3.15 +6 -4 xc/programs/x11perf/Imakefile ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
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
[XFree86] Debugging Xvfb
I am writing some code using OpenGL, and when run under Xvfb on MacOS it dies, with the error message X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 17 Current serial number in output stream: 19 I think MacOS uses the XFree86 version of Xvfb, but my first question is how can I tell for sure, and how do I determine which version I've got? Xvfb on other platforms (including Cygwin, I normally work in Windows) is fine, but I've no idea how to tell version numbers. Duncan Murdoch ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Debugging Xvfb
Hello, Start up X11 and select About X11 from the X11 menu. It will tell you which version of XFree86 you are using. Frank On Sep 25, 2007, at 5:47 PM, Duncan Murdoch wrote: I am writing some code using OpenGL, and when run under Xvfb on MacOS it dies, with the error message X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 17 Current serial number in output stream: 19 I think MacOS uses the XFree86 version of Xvfb, but my first question is how can I tell for sure, and how do I determine which version I've got? Xvfb on other platforms (including Cygwin, I normally work in Windows) is fine, but I've no idea how to tell version numbers. Duncan Murdoch ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86 ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/23 04:08:29 Log message: Snapshot: 4.7.99.2 Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG xf86Date.h xf86Version.h Revision ChangesPath 3.3914+4 -2 xc/programs/Xserver/hw/xfree86/CHANGELOG 1.146 +2 -2 xc/programs/Xserver/hw/xfree86/xf86Date.h 3.660 +2 -2 xc/programs/Xserver/hw/xfree86/xf86Version.h ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/23 13:46:18 Log message: 9. Fix the SDK's header directory structure (Marc La France). Modified files: xc/include/: Imakefile xc/include/extensions/: Imakefile xc/include/fonts/: Imakefile xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.32 +13 -11xc/include/Imakefile 3.62 +21 -16xc/include/extensions/Imakefile 3.10 +5 -5 xc/include/fonts/Imakefile 3.3915+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/22 19:21:27 Log message: Add missing shared libraries. Modified files: xc/programs/Xserver/hw/xfree86/etc/bindist/NetBSD-ix86/: bin-list Revision ChangesPath 1.20 +6 -0 xc/programs/Xserver/hw/xfree86/etc/bindist/NetBSD-ix86/bin-list ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: xf-4_7-branch)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/22 19:20:57 Log message: Add missing shared libraries. Modified files: xc/programs/Xserver/hw/xfree86/etc/bindist/NetBSD-ix86/: Tag: xf-4_7-branch bin-list Revision ChangesPath 1.19.4.1 +6 -0 xc/programs/Xserver/hw/xfree86/etc/bindist/NetBSD-ix86/bin-list ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
Re: [XFree86] basic video functionality on MPC8560
On Wed, 15 Aug 2007, Mel Davey wrote: Hi, old programmer here, but new to linux and hardware side. I have a custom developed MPC8560 freescale processor board w/ 3 PCI slots. I would like to add one pci video board and get something to display on my LCD at 800x600, 16bbp res. I have 3 video board choices right now: NVidia GeForceMX 4000, ATI 128RagePro, ATI Radeon 9250, all PCI. Keep in mind I need to cross-compile anything I add to this board, so I can't use any newer ATI or NVidia proprietary drivers. I'm also new to cross-compiling in general, so its taking a bit of time just to get X compiled to the PPC. When booting the kernel, I first notice no /dev/fb or /dev/fb0, etc. These cmds do not produce a fb: modprobe nvidiafb modprobe radeonfb This does: modprobe vga16fb but I can' do a: fbset -g 800 600 800 600 16 on i, it hangs. The vga16fb loaded, but seg faulted as well, although it did make a /dev/fb0 that I can do fbset -i on? So I move on to get the X server running anyway, as it shou work with no fb. No luck? I've tried to just start it up with: X -allowMouseOpenFail notice I don't yet have a mouse. I want to eventually ue the touch screen as my only pointer, but that will happen later I assume, just want to see stuff on the LCD first. Stuff like: lspci -vvv seem to work fine, and report back seemingly good info. Thoughts? You have a PCI Radeon? Drool. I wasn't aware any had actually been manufactured. In any case, it appears there's no support for it, either in the kernel, in X. Although you might be able to get it to work in X with a DeviceID override. I'm somewhat surprised nvidiafb doesn't find the GeForce. That adapter should work in X, with or without a /dev/fb*. The Rage128 should be found by the kernel's aty128fb module. It should also work in X. Beyond that, I can't really guess what the problem(s) might be, without looking over a copy of your /var/log/XFree86.0.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 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
TWM: truetype support
Hello, in order to reach broader audience I'll post my recent twm activities besides [EMAIL PROTECTED] here as well (assuming these audiences do not 100% cover)... :-) For twm users here are two patchsets introducing truetype font support into twm in two steps. (1) twm-1.0.3-MyFont_ChangeGC.tgz cleans up some bitmap font rendering infrastructure as a preparatory step. (2) twm-1.0.3-TWM_USE_XFT.tgz then applied ontop introduces truetype font support enclosed in #ifdef TWM_USE_XFT. So compile with -DTWM_USE_XFT -I/usr/include/freetype2 -lXft Then insert TitleFont sans-9 MenuFontsans-9 IconFontsans-9:bold IconManagerFont sans-9 ResizeFont sans-10:bold into .twmrc and have fun! How it looks like you can see at www.inf.tu-dresden.de/~ek1/TheGIMP-screenshot.png (Opacity visible there is not yet finished and present here.) Step (1) actually does nothing in appearance and in speed, but as intended, all bugs, if any, should come in here. Step (2) then effectively only replaces XmbDrawString() by XftDrawString8() for text rendering in util.c so any performance or memory footprint issues coming up disclose problems hopefully only in xft. I tried to keep the Hamming distance to the original xorg twm-1.0.3 source code minimal, i.e. touch as few code lines as possible. If you are a twm user, please test it; what do you think? :-) Greetings, Eeri Kask twm-1.0.3-MyFont_ChangeGC.tgz Description: application/compressed-tar twm-1.0.3-TWM_USE_XFT.tgz Description: application/compressed-tar
Re: [XFree86] Licensing fiasco of 2004
A belated thanks to all who responded. Much appreciated. On Fri, 24 Aug 2007, Shentino wrote: Oh, well in that case I agree with you, at least to a point. Can't say I agree with xfree86's licensing, nor can I say I disagree. What does bother me is that the FSF would be so abruptly hardassed about it instead of trying to negotiate. I was curious if there might be something from xfree86's point of view that wasn't given any light, hence my post here on getting the inside scoop. What I found about gpl incompatibility was colorful dialog between the FSF and XF86, but didn't give me any solid info. Either I read the wrong thread or I suck at reading. ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/16 09:38:21 Log message: More warnings. Modified files: xc/extras/Mesa/src/mesa/drivers/dri/mga/: mga_xmesa.h xc/extras/Mesa/src/mesa/drivers/dri/r128/: r128_screen.h xc/extras/Mesa/src/mesa/drivers/dri/r200/: r200_ioctl.c r200_screen.c r200_screen.h xc/extras/Mesa/src/mesa/drivers/dri/radeon/: radeon_screen.c radeon_screen.h Revision ChangesPath 1.3 +2 -2 xc/extras/Mesa/src/mesa/drivers/dri/mga/mga_xmesa.h 1.2 +3 -4 xc/extras/Mesa/src/mesa/drivers/dri/r128/r128_screen.h 1.6 +2 -2 xc/extras/Mesa/src/mesa/drivers/dri/r200/r200_ioctl.c 1.8 +3 -3 xc/extras/Mesa/src/mesa/drivers/dri/r200/r200_screen.c 1.2 +9 -7 xc/extras/Mesa/src/mesa/drivers/dri/r200/r200_screen.h 1.8 +2 -2 xc/extras/Mesa/src/mesa/drivers/dri/radeon/radeon_screen.c 1.3 +2 -2 xc/extras/Mesa/src/mesa/drivers/dri/radeon/radeon_screen.h ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/16 10:26:04 Log message: - Remove ability to generate checksums and filelists (best done with devel module's `updatebindists` script). Both 'from-dir' and 'to-dir' must be absolute paths. Modified files: xc/programs/Xserver/hw/xfree86/etc/bindist/: build-bindist Revision ChangesPath 1.8 +12 -38 xc/programs/Xserver/hw/xfree86/etc/bindist/build-bindist ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
Re: [XFree86] Ati help please
On Sun, 16 Sep 2007, Serpentus wrote: I have an ATI Radean x1650 PRO AGP. Drivers: latest, 8.40.4 downloaded from ati.amd.com Well, unfortunately I have a lot of problems: Primary Monitor: SyncMaster 205BW (Digital Connector) Secondary Monitor: SyncMaster 793DF (Analog) (The issues described below happens even if I disconnect the secondary screen) First: When I set initial to dual-head and overlay Xv or OpenGL or disabled and reset the pc the mouse pointer gets corrupted. (And I've tried lots of other configurations in xorg.conf and still happens). Second: Catalyst reports Bus Settings 0x (AGP). ONLY on linux, under windows it is detected as 8x. So I think it is not a Mother board issue. Third: I get a black screen before playing a video. Fourth: EXTREME low performance. example: Stellarium: 0.125 fps; full screen videos skips lots of frames (only tried VLC), and with lots of other applications is the same. Thanks in advanced! Alejandro Marzuca Santiago, Chile P.S.: Sorry for my english, I know it sucks =P Your English is not that bad, actually. Certainly better that my Espanol. Unfortunately, you are inquiring about ATI's properietary drivers, which we cannot support here. Your best bet is to contact ATI/AMD. Beyond that, I'll venture a guess that you are not running the kernel module that ATI also provides for your adapter. 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. ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/15 16:43:41 Log message: Fix dates Modified files: ./: Install.txt README.txt xc/programs/Xserver/hw/xfree86/doc/: Install README xc/programs/Xserver/hw/xfree86/doc/sgml/: Install.sgml Revision ChangesPath 1.5 +3 -3 xc/Install.txt 1.7 +2 -2 xc/README.txt 1.41 +3 -3 xc/programs/Xserver/hw/xfree86/doc/Install 3.154 +2 -2 xc/programs/Xserver/hw/xfree86/doc/README 1.23 +2 -2 xc/programs/Xserver/hw/xfree86/doc/sgml/Install.sgml ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/15 17:14:43 Log message: 1. Remove (what's left of) the build's dependencies on the Glide2 and Glide3 libraries. What remains are run-time only dependencies in the 2D glide driver (Glide2) and the tdfx DRI driver (Glide3) (Marc La France). Modified files: xc/config/cf/: Imake.tmpl xf86site.def xfree86.cf xc/extras/Mesa/src/mesa/drivers/dri/tdfx/: tdfx_glide.h xc/lib/GL/GL/: Imakefile xc/programs/Xserver/hw/xfree86/: CHANGELOG xc/programs/Xserver/hw/xfree86/drivers/glide/: Imakefile glide_driver.c xc/programs/Xserver/hw/xfree86/etc/bindist/Linux-axp/: host.def xc/programs/Xserver/hw/xfree86/etc/bindist/Linux-ix86/: host.def Revision ChangesPath 3.181 +1 -31 xc/config/cf/Imake.tmpl 3.194 +1 -29 xc/config/cf/xf86site.def 3.518 +3 -14 xc/config/cf/xfree86.cf 1.2 +1 -8 xc/extras/Mesa/src/mesa/drivers/dri/tdfx/tdfx_glide.h 1.32 +2 -2 xc/lib/GL/GL/Imakefile 3.3906+8 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG 1.14 +5 -14 xc/programs/Xserver/hw/xfree86/drivers/glide/Imakefile 1.35 +6 -21 xc/programs/Xserver/hw/xfree86/drivers/glide/glide_driver.c 1.9 +1 -5 xc/programs/Xserver/hw/xfree86/etc/bindist/Linux-axp/host.def 1.10 +1 -9 xc/programs/Xserver/hw/xfree86/etc/bindist/Linux-ix86/host.def ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/15 17:15:27 Log message: Missing file Added files: xc/programs/Xserver/hw/xfree86/drivers/glide/: glide.h ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/15 17:24:57 Log message: Typo Modified files: xc/config/cf/: bsdi.cf Revision ChangesPath 3.43 +2 -2 xc/config/cf/bsdi.cf ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/15 18:37:27 Log message: 2. On SVR4 variants (including SunOS Solaris), use the `make` implementation found in $PATH, instead of a hard-wired one (Marc La France). Modified files: xc/config/cf/: svr4.cf xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.56 +1 -4 xc/config/cf/svr4.cf 3.3907+4 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/15 18:42:22 Log message: 3. Change `lndir` utility to trim off trailing self-references (i.e. / and /. from its from argument (Marc La France). Modified files: xc/config/util/: lndir.c xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 3.27 +12 -5 xc/config/util/lndir.c 3.3908+3 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/15 18:49:15 Log message: 4. Darwin build fix, for the case where an X11 implementation has yet to be installed (Marc La France, problem reported by Yves de Champlain). Modified files: xc/lib/GL/glx/: glxcmds.c xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 1.40 +3 -1 xc/lib/GL/glx/glxcmds.c 3.3909+3 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/15 18:54:24 Log message: 5. Fix bug in Xdmx's handling of USB devices (Marc La France). Modified files: xc/programs/Xserver/hw/dmx/input/: usb-other.c xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 1.2 +2 -2 xc/programs/Xserver/hw/dmx/input/usb-other.c 3.3910+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/15 19:10:28 Log message: 6. Fix stipples in Xigs and Xsis530 servers (Marc La France). Modified files: xc/programs/Xserver/hw/tinyx/igs/: igsdraw.c xc/programs/Xserver/hw/tinyx/sis530/: sisdraw.c xc/programs/Xserver/hw/xfree86/: CHANGELOG Revision ChangesPath 1.4 +2 -2 xc/programs/Xserver/hw/tinyx/igs/igsdraw.c 1.4 +2 -2 xc/programs/Xserver/hw/tinyx/sis530/sisdraw.c 3.3911+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/15 19:13:09 Log message: Remove references to the GATOS project. Modified files: xc/programs/Xserver/hw/xfree86/drivers/ati/: atipreinit.c r128_driver.c radeon_driver.c Revision ChangesPath 1.93 +1 -6 xc/programs/Xserver/hw/xfree86/drivers/ati/atipreinit.c 1.98 +1 -5 xc/programs/Xserver/hw/xfree86/drivers/ati/r128_driver.c 1.137 +1 -5 xc/programs/Xserver/hw/xfree86/drivers/ati/radeon_driver.c ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/15 19:39:50 Log message: 7. Speed up Mach64 block transfers on AMD64s (Marc La France). Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG xc/programs/Xserver/hw/xfree86/drivers/ati/: atimach64io.h ativersion.h Revision ChangesPath 3.3912+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG 1.21 +4 -2 xc/programs/Xserver/hw/xfree86/drivers/ati/atimach64io.h 1.91 +2 -2 xc/programs/Xserver/hw/xfree86/drivers/ati/ativersion.h ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/15 19:50:38 Log message: Fix up Xbin.tgz's file list for Darwin. Modified files: xc/programs/Xserver/hw/xfree86/etc/bindist/Darwin-ix86/: bin-list xc/programs/Xserver/hw/xfree86/etc/bindist/Darwin-ppc/: bin-list Revision ChangesPath 1.12 +2 -8 xc/programs/Xserver/hw/xfree86/etc/bindist/Darwin-ix86/bin-list 1.12 +2 -8 xc/programs/Xserver/hw/xfree86/etc/bindist/Darwin-ppc/bin-list ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/15 19:54:57 Log message: 8. 64-bit fix in XAAValidateGC() (Marc La France). Modified files: xc/programs/Xserver/hw/xfree86/: CHANGELOG xc/programs/Xserver/hw/xfree86/xaa/: xaaGC.c Revision ChangesPath 3.3913+2 -1 xc/programs/Xserver/hw/xfree86/CHANGELOG 1.21 +6 -5 xc/programs/Xserver/hw/xfree86/xaa/xaaGC.c ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/15 20:36:21 Log message: Build fix for the !XF86Server case. Modified files: xc/programs/Xserver/hw/xfree86/: Imakefile xc/programs/Xserver/hw/xfree86/common/: Imakefile xc/programs/Xserver/hw/xfree86/os-support/bus/: Imakefile xc/programs/Xserver/include/: Imakefile Revision ChangesPath 3.94 +2 -1 xc/programs/Xserver/hw/xfree86/Imakefile 3.169 +1 -8 xc/programs/Xserver/hw/xfree86/common/Imakefile 1.39 +3 -1 xc/programs/Xserver/hw/xfree86/os-support/bus/Imakefile 3.24 +2 -1 xc/programs/Xserver/include/Imakefile ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/15 20:44:18 Log message: Miscellaneous warning fixes Modified files: xc/config/makedepend/: parse.c xc/extras/Mesa/src/mesa/drivers/dri/common/: dri_util.c xc/extras/Mesa/src/mesa/drivers/dri/gamma/: gamma_tris.c xc/extras/Mesa/src/mesa/drivers/dri/i810/: i810tris.c xc/extras/Mesa/src/mesa/drivers/dri/mga/: mgatris.c xc/extras/Mesa/src/mesa/drivers/dri/r128/: r128_tris.c xc/extras/Mesa/src/mesa/drivers/dri/r200/: r200_swtcl.c xc/extras/Mesa/src/mesa/drivers/dri/radeon/: radeon_swtcl.c xc/extras/Mesa/src/mesa/tnl_dd/: t_dd_dmatmp.h xc/extras/Xpm/lib/: s_popen.c xc/include/extensions/: xtrapbits.h xc/lib/X11/: XKBMisc.c imRm.c lcFile.c lcGenConv.c xc/lib/Xaw/: XawIm.c xc/lib/Xp/: XpContext.c XpNotifyPdm.c XpPrinter.c xc/programs/Xserver/Xprint/: attributes.c xc/programs/Xserver/dix/: devices.c xc/programs/Xserver/hw/tinyx/trio/: s3.h xc/programs/Xserver/hw/xfree86/drivers/mga/: mga_driver.c mga_esc.c xc/programs/Xserver/hw/xfree86/etc/: pcitweak.c xc/programs/mkfontscale/: mkfontscale.c xc/programs/xtrap/: xtrapin.c xtrapinfo.c xtrapout.c xtrapproto.c xtrapreset.c xtrapstats.c Revision ChangesPath 1.19 +2 -2 xc/config/makedepend/parse.c 1.5 +2 -2 xc/extras/Mesa/src/mesa/drivers/dri/common/dri_util.c 1.2 +7 -6 xc/extras/Mesa/src/mesa/drivers/dri/gamma/gamma_tris.c 1.2 +6 -6 xc/extras/Mesa/src/mesa/drivers/dri/i810/i810tris.c 1.2 +6 -6 xc/extras/Mesa/src/mesa/drivers/dri/mga/mgatris.c 1.2 +200 -190 xc/extras/Mesa/src/mesa/drivers/dri/r128/r128_tris.c 1.5 +5 -5 xc/extras/Mesa/src/mesa/drivers/dri/r200/r200_swtcl.c 1.7 +2 -2 xc/extras/Mesa/src/mesa/drivers/dri/radeon/radeon_swtcl.c 1.2 +12 -13xc/extras/Mesa/src/mesa/tnl_dd/t_dd_dmatmp.h 1.4 +2 -2 xc/extras/Xpm/lib/s_popen.c 1.2 +7 -2 xc/include/extensions/xtrapbits.h 3.9 +2 -2 xc/lib/X11/XKBMisc.c 3.15 +3 -3 xc/lib/X11/imRm.c 3.35 +2 -3 xc/lib/X11/lcFile.c 3.30 +30 -2 xc/lib/X11/lcGenConv.c 1.17 +7 -7 xc/lib/Xaw/XawIm.c 1.9 +2 -2 xc/lib/Xp/XpContext.c 1.10 +5 -5 xc/lib/Xp/XpNotifyPdm.c 1.11 +3 -3 xc/lib/Xp/XpPrinter.c 1.25 +13 -13xc/programs/Xserver/Xprint/attributes.c 3.24 +2 -2 xc/programs/Xserver/dix/devices.c 1.2 +2 -2 xc/programs/Xserver/hw/tinyx/trio/s3.h 1.262 +13 -22 xc/programs/Xserver/hw/xfree86/drivers/mga/mga_driver.c 1.6 +2 -66 xc/programs/Xserver/hw/xfree86/drivers/mga/mga_esc.c 1.20 +2 -2 xc/programs/Xserver/hw/xfree86/etc/pcitweak.c 1.26 +2 -4 xc/programs/mkfontscale/mkfontscale.c 1.5 +2 -2 xc/programs/xtrap/xtrapin.c 1.3 +2 -2 xc/programs/xtrap/xtrapinfo.c 1.5 +2 -2 xc/programs/xtrap/xtrapout.c 1.6 +2 -2 xc/programs/xtrap/xtrapproto.c 1.3 +2 -2 xc/programs/xtrap/xtrapreset.c 1.3 +2 -2 xc/programs/xtrap/xtrapstats.c ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
another i810 crash when switching bewteen X and text console
Hello, 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). Have a nice day. Loïc, Toulouse, France
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/09/09 04:02:51 Log message: Snapshot: 4.7.99.1 Modified files: xc/programs/Xserver/hw/xfree86/: xf86Date.h xf86Version.h Revision ChangesPath 1.145 +2 -2 xc/programs/Xserver/hw/xfree86/xf86Date.h 3.659 +3 -3 xc/programs/Xserver/hw/xfree86/xf86Version.h ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
R: R: [XFree86] xfbdev alpha channel
On Mon, 27 Aug 2007, Tabaro Toni wrote: On Mon, 27 Aug 2007, Marc Aurele La France wrote: On Mon, 27 Aug 2007, Tabaro Toni wrote: Hi, i have succesfully cross-compiled the xfree 4.7.0 on a embedded board with mipsel processor and framebuffer on a 2.6.12 linux environment, with the framebuffer running at 960x1080x32 ARGB or 1280x720x16 ARGB1555. The Xfbdev program start and work (if i export a display on a i386 machine and start xclock the xclock program work). The problem is: to see the image on the board i must run a program in background which set the alpha bit to 1 (on the 1280x720x16 ARGB 1555 frame buffer) or byte to 0xff (in the case of 960x1080x32 ARGB), otherwise the screen remains black. That is an oddball alpha implementation. What adapter is this? Does the (text) screen appear correctly before starting Xfbdev? A im not using the text mode, on that embedded system there is only console /dev/ttyS0 and framebuffer is on graphics hardware. This is an implementation on one stb, the graphic plane is over a video plane and the alpha is needed for seeing the video under graphics That's not the point. Xfbdev will not function at all without a kernel driver for your adapter. Therefore, the kernel must be displaying something before the X server starts, unless that too is being blacked out. So, again, what does the screen show before starting Xfbdev? The screen is not showing anything before Xfbdev becouse there is no console on framebuffer, the boot is on console /dev/ttyS0 and the 1st program using framebuffer is Xfbdev. The kernel driver for framebuffer is working and fbset show: mode 960x1080-80 # D: 103.691 MHz, H: 86.410 kHz, V: 80.009 Hz geometry 960 1080 960 1080 32 timings 9644 120 0 0 0 120 0 accel false rgba 8/16,8/8,8/0,8/24 endmode I have made a program which write some rgb rectangles on the framebuffer, the screen show these rectangles, but when i start Xfbdev the screen become full transparent, in other part of this email every time i have written black screen i made a mistake, the screen is full transparent, i see black becouse before the underling plane was black, now i have a mpeg video looping on that plane and i see the video when graphic is transparent. I think the Xfbdev can't handle the alpha channel correctly, leaving it to 0. I dont need the translucency or other features, only see the image on screen, maybe i can patch the framebuffer code to leave the alpha at fixed value, is someone able to help me by suggest the part of code to patch? I searched on the programs/Xserver/hw/tinyx/fbdev/ or programs/Xserver/fb/ path, but i am not able to understand how the alpha is handled :-( The X server does not touch the alpha channel, but uses whatever applications provide in that field. Maybe i have not explained well the problem, i try on another way: When normally i start Xfbdef -ac on another board with different processor (powerpc) the screen show the X tiled background with the xcursor, on board with mips the Xfbdev -ac show black screen but is running fine. If i change the alpha channel bit directly to the frambuffer with a c program and with the Xfbdev program running i see the X bacground and the mouse, if this c program repeat that function every second the x is running refreshing itself every second (every time my prog touch the alpha bit). This without an X application running, if the X application is running i see the app on screen only when my c program do the alpha bit set. I think the Xfbdev on framebuffer is tested on a framebuffer without real alpha channel, on PC, my boards are embedded board with real alpha used to create holes on graphics needed for seeing underlining video plane over it. which means this is a problem with your adapter, not with Xfbdev. Xfbdev is designed to use a dumb framebuffer through a kernel interface. No alpha channel support whatsoever. Xfbdev is intentionally too generic to have knowledge of the chipset specifics necessary to control an alpha channel. I have a doubt: the small program i have made for testing the framebuffer for writing something on the screen must set the alpha byte to 0xff, maybe this is not the right convention? I mean: is 0x00 for alpha full trasparency and 0xff opaque or the opposite? If is opposite i simply change the framefuffer driver and X start working rigth. As far as I can tell, your options are: 1) There might be a jumper or firmware/BIOS setting that reverses the meaning of the alpha channel, or disables it. 2) There might be an ioctl you can use (in a modified Xfbdev) to do so. 3) There might be another X server more specific to your adapter, with an option to control the alpha channel. What does `lspci` say? 4) You say the adapter
[XFree86] xfbdev alpha channel
Hi, i have succesfully cross-compiled the xfree 4.7.0 on a embedded board with mipsel processor and framebuffer on a 2.6.12 linux environment, with the framebuffer running at 960x1080x32 ARGB or 1280x720x16 ARGB1555. The Xfbdev program start and work (if i export a display on a i386 machine and start xclock the xclock program work). The problem is: to see the image on the board i must run a program in background which set the alpha bit to 1 (on the 1280x720x16 ARGB 1555 frame buffer) or byte to 0xff (in the case of 960x1080x32 ARGB), otherwise the screen remains black. I think the Xfbdev can't handle the alpha channel correctly, leaving it to 0. I dont need the translucency or other features, only see the image on screen, maybe i can patch the framebuffer code to leave the alpha at fixed value, is someone able to help me by suggest the part of code to patch? I searched on the programs/Xserver/hw/tinyx/fbdev/ or programs/Xserver/fb/ path, but i am not able to understand how the alpha is handled :-( Thanks, Pierantonio.
Re: [XFree86] xfbdev alpha channel
On Mon, 27 Aug 2007, Tabaro Toni wrote: Hi, i have succesfully cross-compiled the xfree 4.7.0 on a embedded board with mipsel processor and framebuffer on a 2.6.12 linux environment, with the framebuffer running at 960x1080x32 ARGB or 1280x720x16 ARGB1555. The Xfbdev program start and work (if i export a display on a i386 machine and start xclock the xclock program work). The problem is: to see the image on the board i must run a program in background which set the alpha bit to 1 (on the 1280x720x16 ARGB 1555 frame buffer) or byte to 0xff (in the case of 960x1080x32 ARGB), otherwise the screen remains black. That is an oddball alpha implementation. What adapter is this? Does the (text) screen appear correctly before starting Xfbdev? I think the Xfbdev can't handle the alpha channel correctly, leaving it to 0. I dont need the translucency or other features, only see the image on screen, maybe i can patch the framebuffer code to leave the alpha at fixed value, is someone able to help me by suggest the part of code to patch? I searched on the programs/Xserver/hw/tinyx/fbdev/ or programs/Xserver/fb/ path, but i am not able to understand how the alpha is handled :-( The X server does not touch the alpha channel, but uses whatever applications provide in that field. 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. ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] problem at startx
when i type startx it will not display any gui instead it is reporting problem as you selected fvwm2 as your window manager but your installation does not appear to be functional. The executable /usr/X11R6/bin/fvm2 was not found on your system waiting for xserver to shut down xterm.fatal IO error32(broken pipe) or killclient on xserver 0.0 so please give me the appropriate solution to this problem - Unlimited freedom, unlimited storage. Get it now
Re: R: [XFree86] xfbdev alpha channel
On Mon, 27 Aug 2007, Tabaro Toni wrote: On Mon, 27 Aug 2007, Marc Aurele La France wrote: On Mon, 27 Aug 2007, Tabaro Toni wrote: Hi, i have succesfully cross-compiled the xfree 4.7.0 on a embedded board with mipsel processor and framebuffer on a 2.6.12 linux environment, with the framebuffer running at 960x1080x32 ARGB or 1280x720x16 ARGB1555. The Xfbdev program start and work (if i export a display on a i386 machine and start xclock the xclock program work). The problem is: to see the image on the board i must run a program in background which set the alpha bit to 1 (on the 1280x720x16 ARGB 1555 frame buffer) or byte to 0xff (in the case of 960x1080x32 ARGB), otherwise the screen remains black. That is an oddball alpha implementation. What adapter is this? Does the (text) screen appear correctly before starting Xfbdev? A im not using the text mode, on that embedded system there is only console /dev/ttyS0 and framebuffer is on graphics hardware. This is an implementation on one stb, the graphic plane is over a video plane and the alpha is needed for seeing the video under graphics That's not the point. Xfbdev will not function at all without a kernel driver for your adapter. Therefore, the kernel must be displaying something before the X server starts, unless that too is being blacked out. So, again, what does the screen show before starting Xfbdev? I think the Xfbdev can't handle the alpha channel correctly, leaving it to 0. I dont need the translucency or other features, only see the image on screen, maybe i can patch the framebuffer code to leave the alpha at fixed value, is someone able to help me by suggest the part of code to patch? I searched on the programs/Xserver/hw/tinyx/fbdev/ or programs/Xserver/fb/ path, but i am not able to understand how the alpha is handled :-( The X server does not touch the alpha channel, but uses whatever applications provide in that field. Maybe i have not explained well the problem, i try on another way: When normally i start Xfbdef -ac on another board with different processor (powerpc) the screen show the X tiled background with the xcursor, on board with mips the Xfbdev -ac show black screen but is running fine. If i change the alpha channel bit directly to the frambuffer with a c program and with the Xfbdev program running i see the X bacground and the mouse, if this c program repeat that function every second the x is running refreshing itself every second (every time my prog touch the alpha bit). This without an X application running, if the X application is running i see the app on screen only when my c program do the alpha bit set. I think the Xfbdev on framebuffer is tested on a framebuffer without real alpha channel, on PC, my boards are embedded board with real alpha used to create holes on graphics needed for seeing underlining video plane over it. ... which means this is a problem with your adapter, not with Xfbdev. Xfbdev is designed to use a dumb framebuffer through a kernel interface. No alpha channel support whatsoever. Xfbdev is intentionally too generic to have knowledge of the chipset specifics necessary to control an alpha channel. As far as I can tell, your options are: 1) There might be a jumper or firmware/BIOS setting that reverses the meaning of the alpha channel, or disables it. 2) There might be an ioctl you can use (in a modified Xfbdev) to do so. 3) There might be another X server more specific to your adapter, with an option to control the alpha channel. What does `lspci` say? 4) You say the adapter supports depths 15/16 and 24/32, and imply you have some means of switching between them. Does the adapter support depth 24/24 (i.e. eliminate the alpha channel alltogether)? 5) You might be stuck with your program to invert the alpha channel. 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. ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Configuration collapsed..
Marc Aurele La France wrote: On Thu, 23 Aug 2007, Dinesh wrote: I'm just a novice Linux user and not sure what I did a few days before.. I just created some new users.. Now I'm unable to get GUI of my linux version.. Upon booting, the command prompt comes up.. When I give startx command from any user, the following errors come up, --- Using authority file /home/tdb.xauthority Writing authority file /home/tdb.xauthority Using authority file /home/tdb.xauthority Writing authority file /home/tdb.xauthority Authentication failed - cannot start x server. Perhaps you do not have consolce ownership ? giving up. xinit: No such file or directory. (errorno 2): unable to connect to x server. xinit: No such process. (errorno 3): Server error. --- tdb is the user name.. But I'm able to get GUI through root user, but its strictly warning not to do that.. OS and Version :::Mandrake 9.1.. (Lonestar) Kernel :: Kernel 2.4.21-0.18mdk XFree86 version 4.3.0 I don't know what video hardware I'm using.. Please let me know how to find it or further details.. I have attached the XFree86 log and configuration files.. Was that a log produced while running as root? If so, the likely problem is that the server isn't set-uid root. Try, as root, ... chmod u+s `which X` 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. ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86 Hello Marc, Thats the log file in var/log folder.. Its not generated on running as root.. You mentioned the commandchmod u+s `which X` ... In that, what is that which X ? .. I don't understand.. Can you please explain ? Dinesh. ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Licensing fiasco of 2004
On Fri, 24 Aug 2007, Shentino wrote: Oh, well in that case I agree with you, at least to a point. Can't say I agree with xfree86's licensing, nor can I say I disagree. What does bother me is that the FSF would be so abruptly hardassed about it instead of trying to negotiate. I was curious if there might be something from xfree86's point of view that wasn't given any light, hence my post here on getting the inside scoop. What I found about gpl incompatibility was colorful dialog between the FSF and XF86, but didn't give me any solid info. Either I read the wrong thread or I suck at reading. No. It's just that you are more likely to find such things because that's predominantly what's out there. Alright, I'll bite... Those who believe the fork was caused by the licence change have their chronology completely backwards. Those who promote that view have a vested interest in doing so. As I've said before, the license change was used as a smokescreen to tie up otherwise idle minds, distracting them from figuring out what was really going on and coming up with their own, more informed, opinions. In fact, the argument that the 1.1 license is incompatible with the GPL is a circular one, relying on its own assertion to prove its own truth. You either believe, or you don't. No, the fork in question here pre-dates the license change by a long shot. In retrospect, there were signs of it even back in the late nineties. But forks, especially one of the size this project once had, take time, people, leadership and financial resources to organise themselves enough to get off the ground. We never opposed forks. In fact, we can't do so, because they have existed, in one form or another, since day one. For examples, look at the *BSD's and every single Linux distribution out there, that have distributed our code base but kept their changes to it largely to themselves. When there's gobs of money to be made, commercial interests have a nasty habit of waltzing into a project and start dictating to it. Some volunteers, understandably, don't take kindly to this behaviour. The license change was our answer. That they rejected the new license simply means that ours is the only copyright that, to this day, they refuse to acknowledge to their end users. We knew that they would reject the new license in spite, because we told them, in effect, to take a flying leap, insisting that the project remain in the hands of the volunteers who contribute to it. That, in itself, ensured the XFree86 Project would continue to exist, free(-er) of hidden agendas. _That_, my friend, is the biggest difference between a Free Software Project and an Open Software Project. It is also, unfortunately, a natural consequence of this dog-eat-dog world of computing. ...btw... Anyone know who's bright idea it was to put penises in the GLsnake screensaver? I certainly hope it wasn't any of you guys...lol... Not guilty. We've dealt with enough snakes already. 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. ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Configuration collapsed..
On Sat, 25 Aug 2007, Dinesh wrote: Marc Aurele La France wrote: On Thu, 23 Aug 2007, Dinesh wrote: I'm just a novice Linux user and not sure what I did a few days before.. I just created some new users.. Now I'm unable to get GUI of my linux version.. Upon booting, the command prompt comes up.. When I give startx command from any user, the following errors come up, --- Using authority file /home/tdb.xauthority Writing authority file /home/tdb.xauthority Using authority file /home/tdb.xauthority Writing authority file /home/tdb.xauthority Authentication failed - cannot start x server. Perhaps you do not have consolce ownership ? giving up. xinit: No such file or directory. (errorno 2): unable to connect to x server. xinit: No such process. (errorno 3): Server error. --- tdb is the user name.. But I'm able to get GUI through root user, but its strictly warning not to do that.. OS and Version :::Mandrake 9.1.. (Lonestar) Kernel :: Kernel 2.4.21-0.18mdk XFree86 version 4.3.0 I don't know what video hardware I'm using.. Please let me know how to find it or further details.. I have attached the XFree86 log and configuration files.. Was that a log produced while running as root? If so, the likely problem is that the server isn't set-uid root. Try, as root, ... chmod u+s `which X` You mentioned the commandchmod u+s `which X` ... In that, what is that which X ? .. There are man pages that explain this. In delving into your report a little further, I infer that you have installed a PAM-aware X server. Either, you do not have PAM installed, /etc/pam.d/xserver doesn't exist, or its contents are incorrect. In all three cases, this is not an X problem, so you might want to post your query on Mandrake's support lists. 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. ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Licensing fiasco of 2004
Oh, well in that case I agree with you, at least to a point. Can't say I agree with xfree86's licensing, nor can I say I disagree. What does bother me is that the FSF would be so abruptly hardassed about it instead of trying to negotiate. I was curious if there might be something from xfree86's point of view that wasn't given any light, hence my post here on getting the inside scoop. What I found about gpl incompatibility was colorful dialog between the FSF and XF86, but didn't give me any solid info. Either I read the wrong thread or I suck at reading. I'm hoping that X/FSF and XF86 can be friends again. I'm stuck with the fedora line due to lack of knowhow and resources required to build my own system from scratch, so I don't exactly have much of a choice in what I use. Maybe it's good I was stuck in a cave, it saved me from a gut-wrenching moment watching this heartbreak of an infight. ...btw... Anyone know who's bright idea it was to put penises in the GLsnake screensaver? I certainly hope it wasn't any of you guys...lol... ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Licensing fiasco of 2004
On Wed, 22 Aug 2007, Shentino wrote: No offense intended, I'm just a humble (and apparently ignorant) end user who has been stuck in the jungle for a few years and that link was the first I ever heard about it. My apologies if I came off as an arrogant one-sided clod. Not you. No. I was refering to the coverage given to the incident. 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. ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Licensing fiasco of 2004
No offense intended, I'm just a humble (and apparently ignorant) end user who has been stuck in the jungle for a few years and that link was the first I ever heard about it. My apologies if I came off as an arrogant one-sided clod. ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Licensing fiasco of 2004
I read a bit on http://iiichan.net/stuff/xfree86.html but I thought I'd get the inside scoop. Any details I might have missed? Just found out about this whole thing (currently on fedora core 1) and it was a real shocker! ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
Re: ANNOUNCE: XFree86 4.7.0 is now available
Le 07-08-19 à 22:13, Marc Aurele La France a écrit : Anyway, the attached seems to fix this. Indeed, thanks yves ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: ANNOUNCE: XFree86 4.7.0 is now available
Hi 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 ? yves ___ 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
Hi Congrats for the new release ! 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 The GLX_DIRECT_RENDERING is defined in darwin.cf : # if OSMajorVersion = 7 # define HasXplugin YES ... # if HasXplugin # define BuildAppleDRIYES ... # if BuildAppleDRI # define GlxExtraDefines -DGLX_DIRECT_RENDERING -DGLX_USE_APPLEGL GlxArchDefines Any advice about this ? thanks yves ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: ANNOUNCE: XFree86 4.7.0 is now available
Le 07-08-19 à 19:41, Yves de Champlain a écrit : Hi Congrats for the new release ! 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 The GLX_DIRECT_RENDERING is defined in darwin.cf : # if OSMajorVersion = 7 # define HasXplugin YES ... # if HasXplugin # define BuildAppleDRIYES ... # if BuildAppleDRI # define GlxExtraDefines -DGLX_DIRECT_RENDERING -DGLX_USE_APPLEGL GlxArchDefines Any advice about this ? 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 yves ___ 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
[XFree86] 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 xfree86@xfree86.org list. Development issues and specific bugs should be reported to our [EMAIL PROTECTED] 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. ___ XFree86 mailing list XFree86@XFree86.Org http://XFree86.Org/mailman/listinfo/xfree86
CVS Update: xc (branch: xf-4_7-branch)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/08/16 09:06:56 Log message: update dates Modified files: xc/programs/Xserver/hw/xfree86/doc/sgml/: Tag: xf-4_7-branch README.sgml index.pre Revision ChangesPath 3.149.4.1 +2 -2 xc/programs/Xserver/hw/xfree86/doc/sgml/README.sgml 1.30.4.1 +2 -2 xc/programs/Xserver/hw/xfree86/doc/sgml/index.pre ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
CVS Update: xc (branch: trunk)
CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 07/08/16 09:06:32 Log message: update dates Modified files: xc/programs/Xserver/hw/xfree86/doc/sgml/: README.sgml index.pre Revision ChangesPath 3.150 +2 -2 xc/programs/Xserver/hw/xfree86/doc/sgml/README.sgml 1.31 +2 -2 xc/programs/Xserver/hw/xfree86/doc/sgml/index.pre ___ Cvs-Commit mailing list Cvs-Commit@XFree86.Org http://XFree86.Org/mailman/listinfo/cvs-commit
How to xclient and xserver through LAN?
Hello, I am interested in installation of system with X application server and X terminal computer under Linux. I will get powerful server runing linux. The things I want to build are to run an X application (eg: firefox) on the powerful server (with 3D acceleration)and use my old desktop as just a terminal. All works via ethernet 100mpbs. I specify that runing a local application must works too. The desktop are neither thin client nor diskless. It is just PC under linux with GNOME or KDE. First question: could someone tell me how to set up linux on the server to send and listen x11 data through TCPIP / LAN ? Second question: how to config users on the server because I plan to work with many terminal and many people, not only me. Third question: how to tell my old desktop PC to listen and send x11 protocole through TCPIP/LAN ? Any http links and case studied in the past are welcomed. Thank you. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
