[Xpert]Re: Re: Decimal key on European keyboard layouts
On Sun, 15 Dec 2002, Robin Rosenberg wrote: Date: Sun, 15 Dec 2002 23:45:38 +0100 From: Robin Rosenberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: Multipart/Mixed; boundary=Boundary-00=_SYQ/92hEB/phM+d List-Id: An all-purpose XFree86 discussion forum xpert.XFree86.Org Subject: Re: Re: Decimal key on European keyboard layouts söndagen den 15 december 2002 21.31 skrev Mike A. Harris: I believe the correct fix is to use KP_Separator Didn't know of that one (as most other internals in XFree). I made new patches (against CVS this time). I noted that the german keyboard was fixed a while ago, and this is the same patch. To apply the patch directly to an installed XFree do: cd /etc/X11/xkb/symbols patch -p3 -b keypad-se+no-dk-fi.diff Where do I send the patch (attached) so It gets itself into CVS? [EMAIL PROTECTED] A related question is: Where do I find a working archive of the mailing lists? There are some people who archive them out there, although I don't remember the URL. theaimsgroup.com comes to mind. HTH -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Decimal key on European keyboard layouts
On Sun, 15 Dec 2002, Robin Rosenberg wrote: Date: Sun, 15 Dec 2002 18:26:02 +0100 From: Robin Rosenberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: Multipart/Mixed; boundary=Boundary-00=_qsL/93nkgcL75pr List-Id: An all-purpose XFree86 discussion forum xpert.XFree86.Org Subject: Re: Decimal key on European keyboard layouts söndagen den 15 december 2002 00.08 skrev Christian Rose: [...] So it seems the comment is only about that it should really be a decimal comma and not just an ordinary comma. It seems the comment is not about the purpose of the fix being wrong. The problem, I assume, is that there may be applications looking at the key symbol, and not just the associated character and those might be broken by the fix. I don't know if there are any such, since the fix should only apply when NumLock is on. If anyone can give any pointers on how to correctly adapt this fix for the se, fi, dk, nl, no, de_CH, and de layouts, that would be most helpful. I'm not sure I understand the file format well enough. I can't resist an attempt. My server(s) eat the attached patches. Apply using: patch -p0 -b sekp.patch Since I'm not sure Iceland is not included. Should it? I believe the correct fix is to use KP_Separator -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Will virgin XFree86 run under LINUX?
On Sat, 14 Dec 2002, F. Heitkamp wrote: I'm working with current CVS without any patch and I don't see any crash. Frequently the distribution maintainers include patches to fix some issues with hardware but generally they also send it to the XFree86 developers so they are integrated into the main tree. I too have successfully installed X from CVS numerous times. I think that the proper way to build XFree86, before do a 'make World', is at least read the documentation included in the distribution and look at the configuration options in xc/config/cf. Tell this to the folks at your local LUG. You should probably check for a custom host.def in your /usr/X11R6/lib/X11/config directory. I suppose there may be a custom one there. You could use that for the new build. I usually move the installed XFree to a temporary location before attempting a permanent install. i.e. cd /usr/; mv X11R6 X11R6.bak; cd /path/to/build; make install; If the install goes off without a hitch and the new X runs OK, I them move the saved version back and do a make install over the top. I've noticed that sometimes even though the make World goes off without a hitch the make install will sometimes fail. The problem with that though, is that XFree86 is not the only thing that plunks files under /usr/X11R6. Many other applications infect the /usr/X11R6 heirarchy with their own files. If you move the directory, these applications become inaccessible unless they are still in your path. You can redefine ProjectRoot in host.def to make X install to a separate location however. #define ProjectRoot /usr/local/X11R6 #define NothingOutsideProjectRoot YES #define EtcX11Directory ProjectRoot/etc Hope this helps. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Re: Missing EuroSign on AltGr+5 on Swedish/Finnish keyboardlayout
On 13 Dec 2002, Christian Rose wrote: Date: 13 Dec 2002 05:10:38 +0100 From: Christian Rose [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain List-Id: An all-purpose XFree86 discussion forum xpert.XFree86.Org Subject: Re: Re: Missing EuroSign on AltGr+5 on Swedish/Finnish keyboard layout fre 2002-12-13 klockan 04.33 skrev Mike A. Harris: This is my first attempt at a patch, please let me know if there is something wrong. At a quick glance, the patch looks ok. Patches should be submitted to [EMAIL PROTECTED], in order to go into the patch queue for inclusion. Thanks. I've done so now. It's been applied to CVS now. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Mouse no longer working in Quake3?
On Thu, 12 Dec 2002, Mark Vojkovich wrote: Date: Thu, 12 Dec 2002 16:42:16 -0800 (PST) From: Mark Vojkovich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: TEXT/PLAIN; charset=US-ASCII List-Id: An all-purpose XFree86 discussion forum xpert.XFree86.Org Subject: Mouse no longer working in Quake3? I just noticed that the mouse no longer works in Quake3. The only significant change I made to this system (with regards to the mouse, that is) was syncing and rebuilding XFree86 from CVS. I don't suppose anyone managed to get CVS (I synced at 18:31 on Dec 11) and Quake3 (ver. 1.32) to have working mouse support. At first I thought it was DGA stuff that was broken, but the mouse works fine in my DGA test app. Xev shows that Quake3 isn't getting any events in fullscreen or windowed mode, DGA mouse support or not. Update to quake3 1.32b, should work if it is the same problem I know someone else had earlier today. Hope this helps, TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Missing EuroSign on AltGr+5 on Swedish/Finnish keyboard layout
On 13 Dec 2002, Christian Rose wrote: Date: 13 Dec 2002 02:20:02 +0100 From: Christian Rose [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain List-Id: An all-purpose XFree86 discussion forum xpert.XFree86.Org Subject: Missing EuroSign on AltGr+5 on Swedish/Finnish keyboard layout The standard placement for the Euro sign on the Swedish (and many other layouts) is on AltGr+e, but some older and odd keyboards have the sign on AltGr+5. Windows does accomodate for this and allows the EuroSign to be entered both ways. I'm attaching an attempt to patch this (don't know if it is correct or if I'm even patching the correct file) for both the Swedish and Finnish layouts (they are pretty much identical). [SNIP] This is my first attempt at a patch, please let me know if there is something wrong. At a quick glance, the patch looks ok. Patches should be submitted to [EMAIL PROTECTED], in order to go into the patch queue for inclusion. Hope this helps. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Linux 8.0 - Replacing Gnome with XDM
On Thu, 12 Dec 2002 [EMAIL PROTECTED] wrote: Date: Thu, 12 Dec 2002 20:43:04 -0500 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii List-Id: An all-purpose XFree86 discussion forum xpert.XFree86.Org Subject: Re: Linux 8.0 - Replacing Gnome with XDM Feigning erudition, Herman Buel wrote: % % What is the standard way to disable GNOME and only come up with XDM ? I presume that Linux 8.0 means Red Hat Linux 8.0 (or perhaps SuSE or Mandrake) -- there being no such monster as Linux 8.0 that I'm aware of. If you are talking about Red Hat Linux 8.0, the way I would do it is to edit /etc/sysconfig/desktop and set DESKTOP=, then to edit /etc/X11/prefdm and change the line that reads preferred= to read preferred=xdm. If memory serves, you might be able to use the GUI Login Manager tool to change the display manager, but I don't use Crimson Fedora, so you're on your own there. In /etc/sysconfig/desktop, set: DISPLAYMANAGER=xdm -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: compiling libXxf86dga.so.1
On Tue, 10 Dec 2002, k-essej wrote: i'm in need of libXxf86dga.so.1, i have the source of my current xfree86 build (4.2.1). now how do i compile the library? blah blah bluh That library should never be shared. You are trying to run a movie player or similar application such as mplayer/xine (the most popular ones to show this issue) which was compiled on a Linux distribution which provides shared versions of these libraries (but should not). The proper solution, is to download the mplayer/xine/whatever source code or src.rpm and recompile it on your system, then install it and it should just work. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: 3d accelleration support
On Mon, 2 Dec 2002, Noah L. Meyerhans wrote: Date: Mon, 2 Dec 2002 16:40:09 -0500 From: Noah L. Meyerhans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary=EmDgyYu839ff8lqi List-Id: An all-purpose XFree86 discussion forum xpert.XFree86.Org Subject: 3d accelleration support I'll admit that I don't pay super close attention, but it seems to me that there's a growing trend among the top 3d chipset makers to provide their own proprietary accellerated drivers for XFree86. ATI and NVidia are the two examples I can think of, and it seems like they're the best 3d chipset makers. I'm still using an older 3dfx Voodoo3 because I know that the full programming specs are available and I can get open source accellerated drivers for it. If I were to replace this card with another 3d card, what would be a safe chipset to select if I want to stick with open source drivers? For Red Hat Linux 8.0 - ATI Radeon 7500. Or, if you can live without 3D until the next release, or until it is fully working in rawhide - an ATI Radeon 8500 -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer - XFree86 maintainer - Red Hat ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Re: 2D problems with Matrox G400 (Anti-aliased Fonts and cursors)
On Thu, 28 Nov 2002 [EMAIL PROTECTED] wrote: Date: Thu, 28 Nov 2002 07:40:44 -0500 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii List-Id: General X Discussion xpert.XFree86.Org Subject: Re: Re: 2D problems with Matrox G400 (Anti-aliased Fonts and cursors) On Wed, Nov 27, 2002 at 09:39:34AM -0500, Mike A. Harris wrote: On Wed, 27 Nov 2002, Panagiotis Papadakos wrote: Also because I am using my Matrox dualheaded, sometimes the cursor is drawn on the second head despite the fact that the mouse cursor is on the first head. This probably has nothing to do with the colour of the cursor (if the cursor is rendered dark red or white). So sometimes my second screen may get corrupted with many cursors drawn on it, and I have to place a window over them, in order to clear it. I've also heard this reported. I believe this is due to the Matrox driver's render acceleration being broken if Xinerama is used. I've got a test driver on ftp://people.redhat.com/mharris/test-drivers/mga_drv.o that resolves this. If you test it, please let me know if it also resolves the cursor issue for you as I suspect. Is test-driver built aginst CVS? Yes, it is a CVS driver. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer XFree86 maintainer Red Hat Inc. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: intel 845 support
On Thu, 28 Nov 2002, [ISO-8859-2] Maróy Ákos wrote: I just installed RedHat Linux on a Dell system with an intel 82845G/GL video card. XFree86 2.0 doesn't seem to support this card. So I You mean XFree86 4.2.0. downloaded RPM from the rawhide distribution with the name XFree86-4.2.99.2-0.20021122.2 This seems to support the 845 chipset through an i830 driver (somehow embedded in the i810 driver). But when I start up X, it only shows a blank screen, than crashes. The end of the server log is: Error in I830WaitLpRing(), now is 13819, start is 11818 pgetbl_ctl: 0xffe0001 pgetbl_err: 0x49 ipeir: 0 iphdr: 0 LP ring tail: 8 head: 0 len: 0 start 0 eir: 0 esr: 10 emr: ff7b instdone: ffc0 instpm: 0 memmode: 0 instps: 0 hwstam: ier: 0 imr: iir: 0 space: 65520 wanted 65528 (II) I810(0): [drm] removed 1 reserved context for kernel (II) I810(0): [drm] unmapping 8192 bytes of SAREA 0xd09b6000 at 0x40013000 Fatal server error: lockup I could send the whole log, but it's rather long. Anyway, what could be the problem? Is there support for this card under Linux? Very commonly reported bug. Someone reports it to me about once every couple of days. I don't have any i8x0 video hardware to test with however. The problem is widely reported so I figured it was just due to the developmental state of current CVS, and that it will be addressed by someone before the final release. If need be, I can provide gobs of bug reports to anyone who has the hardware and is interested in taking a poke at fixing it. Hope this helps, TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer XFree86 maintainer Red Hat Inc. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: 2D problems with Matrox G400 (Anti-aliased Fonts and cursors)
On Wed, 27 Nov 2002, Panagiotis Papadakos wrote: I have the following two problems with my Matrox... a) The new cursor with the whiteglass theme, sometimes is rendered with a dark red colour, especially when the cursor is over a textbox or the edjes of a button. Yes, this is easily reproduceable, and has been present since whiteglass went in. It is most noticeable in Red Hat Linux 8.0 when running Evolution and using the calendar views. This is a cursor bug, whoever created the cursors used redglass as a base, but didn't finish it off properly it seems, so redglass gets used sometimes. Also because I am using my Matrox dualheaded, sometimes the cursor is drawn on the second head despite the fact that the mouse cursor is on the first head. This probably has nothing to do with the colour of the cursor (if the cursor is rendered dark red or white). So sometimes my second screen may get corrupted with many cursors drawn on it, and I have to place a window over them, in order to clear it. I've also heard this reported. I believe this is due to the Matrox driver's render acceleration being broken if Xinerama is used. I've got a test driver on ftp://people.redhat.com/mharris/test-drivers/mga_drv.o that resolves this. If you test it, please let me know if it also resolves the cursor issue for you as I suspect. b) Also sometimes the same happens and with anti-aliased fonts, especially when I am doing something which for example scrolls down very fast my terminal which uses anti-aliased fonts. For example if I run configure on my anti-aliased kosnole. Most of the times the fonts are drawn at the left side of my second screen, which has a smaller resolution than my first head (1024x768 instead of 1280x1024). Also the fonts which are drawn in the second head are whole lines from the application which scrolls very fast on the first head. Most of the times this happens with some mouse cursors around him, as I described in problem a). Yep, my above driver was created to test fix this problem. Actually, it isn't a fix, it is a workaround for now. I am using mga_hal_drv.o, but probably this is not the problem, because I tried once an Xserver without loading mga_hal_drv.o and the cursor again changed colours. Without mga_hal_drv.o I can't have dualhead mode, so I don't know for the other problems. No, it's definitely not a hallib bug. Easily reproduceable in 4.2.0 and higher at least using the stock mga driver with Xinerama, and anything that uses Xrender, with G400, G450, G550 When I used Option NoAccel 1, everything works fine, but the server is too slow Yes that will work around the problem also, but there is a faster workaround. I won't tell you what though, because I want you to test my driver, so I can troubleshoot the true cause of this and hopefully fix it. ;o) As I can understand this is probably a Xrender problem for the mga driver. I would like to search a bit, but I don't know how Xrender is used by the mga driver. Yep, it definitely is a Xinerama+Render bug on the mga driver. I've received countless bug reports on this. Worst case scenario if I can't figure out the root cause and fix it is to simply disable Render acceleration in the mga driver when Xinerama is used, until someone can fix it. Let me know how testing goes with my above driver. TTYL -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer XFree86 maintainer Red Hat Inc. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: 2D problems with Matrox G400 (Anti-aliased Fonts and cursors)
On Wed, 27 Nov 2002, Klaus Dittrich wrote: I used a G400 in dualhead mode before without any problems, now a G550 with the configuration below. The hal_module is from mgadrivers-2.0.tgz. If you are not using Render applications with antialiased fonts, or using the new CVS X color mouse pointers, you likely won't ever notice the problem. -- Mike A. Harris ftp://people.redhat.com/mharris OS Systems Engineer XFree86 maintainer Red Hat Inc. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nvidia GEForce4 Mx440
On Sun, 2002-11-24 at 01:42, Mark Vojkovich wrote: On Wed, 20 Nov 2002, George Gopie wrote: I have installed Linux Red Hat Advanced Server 2.4.9-e.3 on my intel server with a 64MB nvidia #DGeForce4 Mx440 series video card. I am unable to get it to work with X. I have down loaded XFRee86 4.0.2 and installed it., but when I try to start the configuration with XFree86 -configure i get that the Following: Fatal Server error: XFree86 has found a valid card configuration. Unfortunately the appropriate data has not been added to the xf86PciInfo.h. This card is relatively new and there has been no official XFree86 release since that card has come out so there is no official release supporting it (certainly not 4.0.2 which is two years old). You either have to build XFree86 from CVS or install the binary drivers from nvidia's web site, or *maybe* replacing the /usr/X11R6/lib/modules/drivers/nv_drv.o with the one on my web page http://www.xfree86.org/~mvojkovi/nv_drv.o will work if you start the server with the -ignoreABI option (ie. startx -- -ignoreABI) - that certainly works with 4.2.0, but I don't know about 4.0.2. Relatively new? - just use the nv driver I attach my XF86Config if you want to use it (I have a 440mx as well) It has worked with 4.1 4.2 and cvs - havn't checked 4.0.2 but the nv driver has been around a while Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert # XFree86 4.0 configuration generated by Xconfigurator Section ServerLayout Identifier XFree86 Configured Screen 0 Screen0 0 0 InputDeviceMouse0 CorePointer InputDeviceKeyboard0 CoreKeyboard EndSection # By default, Red Hat Linux 6.0 and later use xfs Section Files FontPath unix/:7100 EndSection # Module loading section Section Module Load dbe # Double-buffering Load GLcore # OpenGL support Load dri # Direct rendering infrastructure Load glx # OpenGL X protocol interface Load extmod # Misc. required extensions Load v4l # Video4Linux # Load pex5 # PHIGS for X 3D environment (obsolete) # Load record# X event recorder # Load xie # X Image Extension (obsolete) # You only need the following two modules if you do not use xfs. # Load freetype # TrueType font handler # Load type1 # Adobe Type 1 font handler EndSection Section InputDevice Identifier Keyboard0 Driver keyboard Option XkbLayout gb EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Device /dev/mouse Option Protocol IMPS/2 Option Emulate3Buttons off Option ZAxisMapping 4 5 EndSection Section Monitor Identifier Maxdata Belinea 10 40 10 VendorName Unknown ModelName Unknown HorizSync 30.0-48.5 VertRefresh 50.0-120.0 Option dpms EndSection Section Device Identifier My Video Card Driver nv BoardName Unknown EndSection Section Device Identifier Linux Frame Buffer Driver fbdev BoardName Unknown EndSection Section Screen Identifier Screen0 Device My Video Card Monitor Maxdata Belinea 10 40 10 DefaultDepth 24 Subsection Display Depth 24 Modes 1024x768 EndSubSection EndSection Section DRI Mode 0666 EndSection
[Xpert]RE: Xpert digest, Vol 1 #2411 - 17 msgs
As my agent now in India I would like to pass you all our leads and have you persue them vigorously. How would you like work with us? Would you prefer to work for a commission or would you prefer to be a distributor? Mike -Original Message- From: [EMAIL PROTECTED] [mailto:xpert-admin;XFree86.Org]On Behalf Of [EMAIL PROTECTED] Sent: 03 November 2002 13:00 To: [EMAIL PROTECTED] Subject: Xpert digest, Vol 1 #2411 - 17 msgs Send Xpert mailing list submissions to [EMAIL PROTECTED] To subscribe or unsubscribe via the World Wide Web, visit http://XFree86.Org/mailman/listinfo/xpert or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of Xpert digest... Today's Topics: 1. Re: More on the new cursor (Keith Packard) 2. Re: Xnest (Brian Wellington) 3. Re: Proposal for mouse speed acceleration settings (Michael Toomim) 4. Re: Re: Proposal for mouse speed acceleration settings (Michael Toomim) 5. Re: Intel 845G onboard video on FreeBSD 4.7 (Andy Sparrow) 6. Older S3 chipsets (was: Re: [Xpert]Driver work for S3 864 chipsets) (Tothwolf) 7. Trio 64 3D (Frank v Waveren) 8. Re: Trio 64 3D (Frank v Waveren) 9. Re: private mailing lists - an archive or read only access? (Dr Andrew C Aitchison) 10. Re: Radeon mobility and external monitor (Dr Andrew C Aitchison) 11. Re: X Windows System problem for RedHat 8.0 on IBM Thinkpad R32 on Windows-hosted vmware (Dr Andrew C Aitchison) 12. Re: private mailing lists - an archive or read only access? (=?iso-8859-15?Q?Jos=E9?= Fonseca) 13. Re: private mailing lists - an archive or read only access? (Juliusz Chroboczek) 14. Re: VNC and freetype - please Help! (Juliusz Chroboczek) 15. Re: Questions about TinyX (simultaneous monochrome color screen xserver) (Juliusz Chroboczek) 16. Re: private mailing lists - an archive or read only access? (Dr Andrew C Aitchison) --__--__-- Message: 1 To: [EMAIL PROTECTED] cc: Keith Packard [EMAIL PROTECTED] Subject: Re: [Xpert]More on the new cursor From: Keith Packard [EMAIL PROTECTED] Date: Sat, 02 Nov 2002 21:24:41 -0800 Reply-To: [EMAIL PROTECTED] Around 21 o'clock on Oct 30, oliver wrote: So if i get things right by reading these couple posts, it means that this pretty ARGB cursor I'm getting is software based. The Radeon driver now has HW support for ARGB cursors; the nVidia driver should have support shortly. Adding support to other cards that have appropriate hardware will be easy for someone with the hardware and the docs. Keith PackardXFree86 Core TeamHP Cambridge Research Lab --__--__-- Message: 2 Date: Sat, 2 Nov 2002 22:02:36 -0800 (PST) From: Brian Wellington [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Xpert]Xnest Reply-To: [EMAIL PROTECTED] On Thu, 31 Oct 2002, Ulrich Hobelmann wrote: I have a problem with Xnest (running XFree 4.2.0 on NetBSD 1.6/i386). I start it as usual with XNest :1, but when I try connecting via xterm -display :1 or use any client after setting DISPLAY I get the following message: Xlib: connection to :1.0 refused by server Xlib: No protocol specified xterm Xt error: Can't open display: :1 At the same time Xnest writes AUDIT: Thu Oct 31 20:43:59 2002: 825 Xnest: client 1 rejected from local host I've tried connecting as root, or starting Xnest as root, but this doesn't help. I've also tried setting DISPLAY to localhost:1.0 and stuff... I ran into the same problem yesterday (4.2.0 on Red Hat 8), and was able to use Xnest by running it as: Xnest :1 -auth /dev/null I'm sure that's not the correct solution, but it worked for me. Brian --__--__-- Message: 3 Date: Sat, 02 Nov 2002 22:38:10 -0800 From: Michael Toomim [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: [Xpert]Re: Proposal for mouse speed acceleration settings Reply-To: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: You keep saying that the resolution can't be changed without editing the XF86Config file, but the XFree86-Misc extension has made it possible for years to change that setting on the fly. It's just a matter of having a client to interface to that extension and there are a few available, such as the xmseconfig program that used to be distributed with XFree86. xset does use the XFree86-Misc extension, but only for changing keyboard settings. There's no reason it couldn't be changed to do the same for the mouse. There's one problem: The following option will set the mouse device resolution to N counts per inch, if possible: OptionResolution N Not all mice and OSs can support this option. This option can be set in the XF86Setup program. Does anyone know where I can find out which mice and/or OS's don't support the resolution parameter? Does
[Xpert]VNC and freetype - please Help!
Hi, I have got X4.2.1 running on my gentoo system with truetype fonts rendering nicely. However, the system is going to be serving a number of remote clients, using vnc. When I'm running X as a local user, truetype fonts render perfectly. When I use VNC, I get no truetype fonts at all. Can anyone tell me what I should do to get them to appear in Xvnc? Many thanks, Mike ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert](EE) NVIDIA(0): Failed to initialize the NVdriverkernel module!
On Mon, 2002-10-28 at 11:30, Marius Leahu wrote: Hi I cannot start KDE in Red Hat 7.3 because of this error : '(EE) NVIDIA(0): Failed to initialize the NVdriver kernel module!' I have an Athlon XP 2100+ on a ABIT NV7m motherboard. This motherboard has integrated a GeForce 2 GPU, NVIDIA nForce APU and also a LAN adapter. Monitor: Samsung SyncMaster 755DFX with frequency domains: H: 30-85 KHz, V: 50-160 Hz. XConfigurator recognize my video card as a GeForce 2 MX (generic) and choose 'nv' as video driver. When I try to start KDE, my computer get stucked, everything is freezing. I installed the NVIDIA_kernel-1.0-3123.rh73up.athlon.rpm, NVIDIA_GLX-1.0-3123.i386.rpm and NVIDIA_nforce-1.0-0241.rh73up.athlon.rpm downloaded from www.nvidia.com. The last rpm package is sound driver which is working fine. With this video driver installed ( I strictly followed instructions from nvidia 'readme' file), 'startx' command finish with error: '(EE) NVIDIA(0): Failed to initialize the NVdriver kernel module!' After that, I try 'vesa' driver which works only in certain circumstancies, like: I run 'startx' with 'nvidia' driver, crash, I change to 'vesa' driver and it wokrs. If I restart my system and run 'startx' with 'vesa' driver, it crash saying that it cannot init GL extension driver ! Could anybody help me with this ? When you install the NVidia driver it hides the standard glx drivers - uncomment the glx entries in XF86Config and it should work (BTW you may prefer using nv driver rather than vesa) Home, no matter how far... http://www.home.ro ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert -- Linux, Gnome what more do you need http://www.redtux.demon.co.uk ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Probable return of Radeon, R128 XFree86 crash at VTswitch
On Thu, 17 Oct 2002, Charl P. Botha wrote: Marc's change means that drivers don't need to care about bus mastering being enabled because it will now be enabled automatically for PCI cards that are being used by the X server. Sounds good, unfortunately it doesn't seem to work for the original poster - any idea why? Charl P. Botha did not actually try it. Thus, the key word in your sentence above remains seem. Sorry for the long quote above, but this should be almost the last mail in this thread. I've tested with CVS XFree86, and all is well. Bus mastering gets disabled when switched to VT but gets enabled again when switching back to X. The problem WAS that this re-enabling did not always take place before Marc's changes, which is why we added the explicit call to do this. I've checked the code in current XFree86 CVS, but would very much like to know (just for interest's sake) WHERE exactly the PCI enable (or whatnot) is called from that re-enables bus mastering after a VT switch. Thanks and my apologies for the upset. I haven't tested the current CVS stuff out with DRI yet for this problem. I can say 100% that this patch both for Radeon and Rage 128 has solved the lockup problems on over 100 users of Red Hat Linux (after that I stopped keeping track), and has caused no negative effects. I'm not sure if it is the correct solution to the problem, or the best solution, but it definitely was _a_ solution, and one certainly acceptable to me as it solves lockups that occured for numerous users for 9 months+. If the CVS code has a solution in it that makes the patch Charl created unnecessary, that's even better. If the CVS code does lockup however, then I think it makes sense to put Charl's patch back in. -- Mike A. Harris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: ATI Radeon 7500 fails in XFree 4.2
On Mon, 14 Oct 2002, Apostolod Dimitromanolakis wrote: Date: Mon, 14 Oct 2002 20:39:11 -0400 From: Apostolod Dimitromanolakis [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: multipart/mixed; boundary=030900090501070904020308 Subject: ATI Radeon 7500 fails in XFree 4.2 Hi to everybody, I have some trouble trying to make my new ATI RADEON 7500 (OEM, made by ATI) work with XFree 4.2.0/1. When X Server start no problems are reported but the screen goes to standby mode. Of course there is nothing on the screen and moreover when I switch desktops the screen does not turn on. However the sustem keeps working ok and does not halt. I have tried disabling acceleration (noaccel) and the card works ok. Also the VESA driver works fine. The video card works fine in Win32. I'm sending you my config file and the X Server log. Your video card was not made by ATI. ATI made video hardware has a vendor ID and subvendor ID of 0x1002, yours has a subvendor ID of 0x174b, which is a Powered by ATI board made by PC Partner Limited. From your log file: (II) PCI: 01:00:0: chip 1002,5157 card 174b,7161 rev 00 class 03,00,00 hdr 00 ATI made chip ATI didn't make card -- Mike A. Harris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: SIGFPE in Radeon 7500 DRI support
On 17 Oct 2002, David Hampton wrote: Date: 17 Oct 2002 11:20:11 -0700 From: David Hampton [EMAIL PROTECTED] To: Michel Dänzer [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary==-8s6sbAjyd7r4JyTRNESM Subject: Re: SIGFPE in Radeon 7500 DRI support On Thu, 2002-10-17 at 05:06, Michel Dänzer wrote: Program received signal SIGFPE, Arithmetic exception. 0x40771fbb in gl_test_os_katmai_exception_support () from /usr/X11R6/lib/modules/dri/radeon_dri.so (gdb) bt #0 0x40771fbb in gl_test_os_katmai_exception_support () ^^^ This is such a wonderfully expressive function name, why doesn't anybody read it? :/ Yes, it is a nice expressive name, but my expertise is in network protocols not in video drivers. I don't know what Katmai is, why I need it, why its not in my Red Hat kernel, where to find it, or why the lack of it is crashing every OpenGL application on my computer. If this function is expected to create a SIGFPE, why isn't it trapped and handled? It's actually a poorly named function all around IMHO. A better name would be s/katmai/sse/ -- Mike A. Harris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Help needed - Issues with X cvs - module loading broken
Hi I have just downloaded and built (several times) X cvs I have some issues On my current build (which generally works) The mouse is big and red and cant be changed I get messages related Xlib not supporting my locale #, which is 1so 889915 If I build a non-static server On nearly every module I get errors while loading On GL modules it is various unresolved symbol errors On all driver modules I get with nv as an example nv driver needs nvmoduleData My system is RH7.3 base Glibc and gcc from RH8 (glibc-2.2.93 and gcc3.2) Help appreciated -- Linux, Gnome what more do you need http://www.redtux.demon.co.uk ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Issues with X cvs
Hi I have just downloaded and built (several times) X cvs I have some issues On my current build (which generally works) The mouse is big and red and cant be changed I get messages related Xlib not supporting my locale #, which is 1so 889915 On my last build which I had to revert On nearly every module I get errors while loading On GL modules it is various unresolved symbol errors On all driver modules I get with nv as an example nv driver needs nvmoduleData The build that is working by mistake I think I must have set it to compile all the drivers inside the server My system is RH7.3 base Glibc and gcc from RH8 (glibc-2.2.93 and gcc3.2) Help appreciated -- Linux, Gnome what more do you need http://www.redtux.demon.co.uk ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Cyrix Geode/Kahlua problems...
On Tue, 10 Sep 2002, Erich Schubert wrote: Date: Tue, 10 Sep 2002 02:52:37 +0200 From: Erich Schubert [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 Subject: Cyrix Geode/Kahlua problems... I have machines here with the Cyrix 5530 Kahlua Video chipset. They currently run with a 8 MB Disc-On-Chip system and work fine (apparently using xfree 3.3.3.1) but sometimes lock up. (they're from www.igel.de, some older model, IGEL-W) I tried running a Debian system from a HD, but both the Xfree 4.1 and the 3.3.6 driver kill the system (not pingable any more) I've read that some people have the same problem, and are trying to repair these drivers - any progress on this issue? http://people.redhat.com/alan Hope this helps, TTYL -- Mike A. Harris Nobody will ever need more than 640 kB RAM. (Bill Gates, 1983) Windows 98 requires 16 MB RAM. (Bill Gates, 1999) Logical conclusion: Nobody will ever need Windows 98. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XML format for XF86Config
On Mon, Sep 30, 2002 at 02:58:02PM -0700, Michael Michael wrote: Like i said its usefulness is proven in many areas. I see no reason not to use it. It could be introduced without effecting the current parser. Current parser aside, how do you deal with the people who want to: root# vi /etc/X11/XF86config-4 ? I can change any option in seconds this way. wading thru an ncurses-based configurator is just plain silly. MM The XF86Config maps well to XML ... I can map /etc/passwd maps to xml... what's your point? ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]TV Out - Recommendations?
Hi all, I am putting together a set top box running linux for movies / web usage and would like to hear what TV Out cards you have seen best results from under Linux. I have tried TV out using a low end Geforce 4 with the nvidia binary drivers but there are some strange effects when watching movies through the TV Out (in scenes where there is a lot of action there is a split in the middle of the screen running horizontally, the upper half of the screen updates just before the bottom half and its very annoying!) Many thanks, Mike ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Re: [Dri-devel] Radeon switch to VT and back X freeze POSSIBLEFIX
On Wed, 28 Aug 2002, Egbert Eich wrote: Date: Wed, 28 Aug 2002 12:33:02 +0200 (MEST) From: Egbert Eich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Subject: Re: Re: [Dri-devel] Radeon switch to VT and back X freeze POSSIBLE FIX Carlos O'Donell writes: dri-devel, Just coming out of the woodwork to post a few ideas... It would be interesting to see if bus mastering gets disabled on any other PCI devices? Anyone have a PCI logic analyzer? :) Would it be the norm to expect that a VT switch (going through though the BIOS) would cause a BM disable in order to cancel pending transactions (similar to soft reset)? A VT switch restores the PCI state to the situation when the Xserver was started. Therefore if BM was enabled when X was started (ie by the BIOS at boot time) it will remain enabled. Otherwise it will be disabled and will remain disabled until the driver explicitely reenables it. At the time this decision was made it sounded like the most reasonable approach to leave as little as possible behind when terminating/VT switching X. I'm pretty sure some of the X drivers still force busmastering on when it is needed and found off during startup to get around BIOS bugs in some laptop computers that do not enable BM but require it. In the Radeon VT switch case however this is a different issue. What is happening, is: Start computer, do not start X: Busmastering is enabled Start up X: Busmastering still enabled VTswitch: Now in console, Busmaster is disabled VTswitch back to X: Busmastering disabled still - BOOM. Why busmastering is getting disabled during VTswitch is probably something that should be determined. Why it only happens for some people, and the busmaster patch fixes it is probably just a hack around the real problem. Anyone feel like figuring out the root cause? ;o) -- Mike A. Harris I'd offer to change your mind for you, but I don't have a fresh diaper. -- Leah to pro-spammer in news.admin.net-abuse.email ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]display problems on Sony Vaio PCG FX-705 notepad
Joshua D. Knowles wrote: I recently installed Red Hat 7.3 on my Vaio notepad. Everything works except for the display, which has the following strange behaviour. If I do startx then I do not get a functioning display and I have tried lots of different settings in Xconfig - none work when I probe. HOWEVER, if I do startx with my laptop plugged into an external monitor AND THEN switch back to the laptop's display then I get a full, high-resolution picture and everything is fine from then on! (But I don't really want to walk round with a 19 CRT monitor). Does anyone know why I get this strange behaviour and how to fix it? I guess there must be a quick fix since the display works perfectly after I do the switch. The details of the display and the video card are: 1400 x 1050 15 display ATI Rage Mobility M1 8MB graphic card I am using the XFree86 4.2 driver Thanks a lot for any replies, Joshua i just got back from vacation and checked my mail... i may be able to fix your problem. i actually had posted about this a few weeks ago on a few different lists. here's a summary of my vaio display issues: the redhat 7.3 installer detected and tested my video card perfectly during the install (showed a nice 1400x1050 gnome screen)... upon reboot, x would not work... it would bring up a messed up wiggly grey screen with a little flashing white box in one corner. however, if i then plugged the laptop into my 17 monitor, switched to the crt and then back to the lcd, x worked fine. the fact that redhat's installer worked bothered me... so i went digging around at the redhat installer console (ctrl-alt-f2 while redhat is installing) and discovered that the install program itself is running a 640x480 framebuffer xserver at :1 and the 'test config' section loads up a normal xserver on :0. so i rebooted, told grub to pass 'vga=788' to the kernel, and booted up. now i have really nice big consoles, a tux on my screen at bootup, and x works with no problems. to clarify, i am not using a framebuffer xserver. i just have the kernel activate the framebuffer device at bootup and that mysteriously makes x work fine. strange... but i'll take it! :-) so, at your grub screen, append 'vga=788' to the kernel line and boot... please do let me know if that helps! i'm really curious if this was just a fluke with my specific laptop... good luck!! -mike ps - my laptop is an fxa59 -- -- | Michael D. Labriola | |[EMAIL PROTECTED]| || | Admiralty Drive West Apt F4 | | Middletown, RI 02842 | |(401)846-4085 | -- ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: 845 driver (again)
On 3 Sep 2002, Biswapesh Chattopadhyay wrote: Date: 03 Sep 2002 17:16:18 +0530 From: Biswapesh Chattopadhyay [EMAIL PROTECTED] To: XPert [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: text/plain Subject: 845 driver (again) Hi all I compiled the XFree86 SRPM from RH RawHide but Xconfigurator still does not show the 845 driver :-( So, can anyone point me to the Intel patch ? Can it be applied on 4.2 ? Xconfigurator gets it's configuration data from a database Cards and has nothing to do with XFree86. The Cards database is manually edited each release to add support for new hardware. Since i845 isn't supported, it doesn't show up. You need to manually configure your card, or choose i830 or i810, and tweak the config if need be. -- Mike A. Harris Foot and mouth disease is believed by experts to be the first virus that is unable to spread via Microsoft Outlook. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Redhat 7.3 X problem
On Tue, 3 Sep 2002, shiljo san wrote: Date: Tue, 3 Sep 2002 21:20:32 -0700 (PDT) From: shiljo san [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: multipart/alternative; boundary=0-246327448-1031113232=:44622 Subject: Redhat 7.3 X problem Hi, I installed new Redhat 7.3, configured everything as in the earlier 7.1, which used to work flawlessly. I have a X won't start by any means, startx gives a flicker and then the screen freezes, Ctrl-Alt-Break, Ctrl-Alt-+, etc. How can I solve this problem. My video card is S3 Trio3D/2X. Any solution will be highly appreciated. Reconfigure and choose the vesa driver manually. -- Mike A. Harris Definition: MCSE - Microsoft Certified Solitaire Expert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Hot corners
Some screensavers in the Win / Mac world let you set hot corners and cold
corners, which respectively immediately activate the screen saver and
inhibit it.
I'm working on a program that lets you do this with X11. It almost
works. The problem is that it only notices if the corner belongs to the root
window -- if another window is covering the root, my program doesn't get
notified of the PointerMotion event.
Since it's so tiny, i've attached it. I was wondering if anyone could take a
quick look. I imagine it would be a simple fix; but i've never programmed in
X before, and i'm sort of figuring it out as i go along by ripping apart
other programs.
Thanks
/* By Mike Schiraldi [EMAIL PROTECTED] */
/* Compile with -Wall -L/usr/X11R6/lib -lX11 */
#include stdlib.h
#include stdio.h
#include unistd.h
#include string.h
#include X11/Xlib.h
#include X11/Xutil.h
int
main(int argc, char **argv)
{
Display *display;
Screen *screen;
Window root;
int height;
int width;
int i;
char * commands[4] = {NULL, NULL, NULL, NULL};
if (argc 2) {
usage:
fprintf (stderr,
Specify commands for, respectively, the northwest, northeast, southwest, and
southeast corners of the screen. Use - for no command. For example:
%s - 'script1.sh' 'script2.sh' -
will run script1.sh when the pointer is in the northeast corner and script2.sh
when it's in the southwest.
Written by Mike Schiraldi [EMAIL PROTECTED]\n, argv[0]);
exit(1);
}
if (strcmp (argv[1], -h) == 0) goto usage;
if (strcmp (argv[1], -help) == 0) goto usage;
if (strcmp (argv[1], --help) == 0) goto usage;
if (strcmp (argv[1], -v) == 0) goto usage;
if (strcmp (argv[1], -version) == 0) goto usage;
if (strcmp (argv[1], --version) == 0) goto usage;
for (i = 1; i = 4 i argc; i++) {
if (strcmp (argv[i], -) != 0)
commands[i - 1] = argv[i];
}
if ((display = XOpenDisplay(NULL)) == NULL) {
fprintf(stderr, %s: can't open %s\en, argv[0], XDisplayName(NULL));
exit(1);
}
root = DefaultRootWindow (display);
screen = XDefaultScreenOfDisplay(display);
height = XHeightOfScreen(screen) - 1;
width = XWidthOfScreen(screen) - 1;
XSelectInput (display, root, PointerMotionMask);
while (1) {
int x, y, rv;
char * command;
Window junk1, junk2;
int junk3, junk4;
unsigned int junk5;
XEvent junk6;
XNextEvent(display, junk6);
fprintf (stderr, Pointer motion!\n);
rv = XQueryPointer (display, root, junk1, junk2, x, y,
junk3, junk4, junk5);
if (!rv) {
fprintf (stderr, XQueryPointer failed. Send me an email about it.\n);
}
if (x == 0 y == 0) {
command = commands[0];
} else if (x == width y == 0) {
command = commands[1];
} else if (x == 0 y == height) {
command = commands[2];
} else if (x == width y == height) {
command = commands[3];
} else {
command = NULL;
}
if (command) {
fprintf (stderr, Running %s\n, command);
}
}
exit(1);
}
[Xpert]Errors in xkbd us_intl symbols file
The file /etc/X11/xkb/symbols/us_intl is missing commas
in it which prevent the proper setup of my keyboard for using accents.
This is under XFree86 version 4.2.0.
According to the header, this file appears to have been last modified
by someone at Conectiva in Brazil (http://www.conectiva.com.br).
I find it suprising that this file was submitted this way without
testing whether the accents work correctly. Especially in Brazil,
where this keyboard mode is used everyday. Who's looking at this?
My XF86Config has the following lines:
XkbRulesxfree86
XkbModelpc102
XkbLayout us_intl
XkbVariant basic
Attached is a version of the corrected us_intl file which works on my PC.
If anyone has a better way of doing this I'd love hear it.
Thanks.
=== CUT: /etc/X11/xkb/symbols/us_intl
partial default alphanumeric_keys
xkb_symbols basic {
name[Group1]= US/ASCII;
// Alphanumeric section
key TLDE {[ dead_grave, dead_tilde ],
[ grave, asciitilde ] };
key AE06 {[ 6,dead_circumflex ],
[ asciicircum, asciicircum ] };
key AC11 {[ dead_acute, dead_diaeresis ],
[ apostrophe, quotedbl] };
key AE09 {[ 9,parenleft ],
[ dead_breve, dead_breve ] };
key AE10 {[ 0,parenright ],
[ dead_abovering, dead_abovering ] };
key AE11 {[ minus,underscore ],
[ dead_macron, dead_belowdot ] };
key AE12 {[ equal,plus],
[ dead_doubleacute,dead_horn ] };
key AC10 {[ semicolon,colon ],
[ dead_ogonek, dead_diaeresis ] };
key AB08 {[ comma,less],
[ dead_cedilla,dead_caron ] };
key AB09 {[period,greater ],
[ dead_abovedot, dead_circumflex ] };
key AB10 {[ slash,question],
[ dead_hook, dead_hook ] };
// End alphanumeric section
};
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
[Xpert]xfree86-4.2.0 problems on a sony vaio fxa59
i just compiled xfree86-4.2.0 on my brand new sony vaio fxa59 and i'm having some strange issues getting x to start correctly. here's the quick rundown. everything compiled and installed fine, and i'm using the attached XF86Config. as you can see from the attached XFree86.0.log file, there are no obvious error messages popping up on me... but instead of getting a nice x screen when i 'startx', i get a jagged lined (almost like chain links) and speckled grey screen with a little white box in the upper left corner (about 1 square). this is not the x is running but there's no wm screen... the specs sheet that came with the laptop says it has an ATI 3D RAGE MOBILITY-M1 and a 15.0 SXGA TFT screen that's supposed to run at 1400x1050. now i was completely stumped for a while, but i've actually made a positive discovery... oddly enough, if i plug a monitor into the vga out on the laptop and switch the display over to it (which works) and then switch it back to the lcd, the lcd works correctly. now, this is a good thing... but having to plug the thing into a monitor whenever i want to use x kinda defeats the entire purpose of a laptop... ;-) baby steps in the right direction, though. if i log into x, do the external monitor trick, log out of x, and log back in the lcd still does not work. (i have to do the external monitor trick again) i also have to redo the external monitor trick if i do a 'ctrl-alt-+' to change the active resolution. so, anyone have any idea whether this is a video card driver problem with x? or an lcd compatibility problem with x? or just an XF86Config problem? (starting to doubt that last one...) someone else i spoke with actually suggested that it might be a problem with x not detecting the route from my video card to my lcd screen. is this a posibility? thanks in advance! -mike ps - as an odd side note, when i attempted to install redhat 7.3 on the laptop, the graphical install worked fine (doesn't that use an x-server?) and it even succeeded in testing the video settings... but when i started up x after installing, it did the same thing. but still, why would redhat's graphical install and x test thing work during the install? i believe the graphical install uses a framebuffer x server... but why would that be so different? (i obviously don't know what a framebuffer x server is, or i wouldn't present such a silly question...) pps - my appologies for the novel. ;-) you'de be writing books trying to fix this too if your brand new $1700 laptop had no x. !@#$% -- -- | Michael D. Labriola | |[EMAIL PROTECTED]| || | Admiralty Drive West Apt F4 | | Middletown, RI 02842 | |(401)846-4085 | -- XF86Config.gz Description: application/gunzip XFree86.0.log.gz Description: application/gunzip
Re: [Xpert]xfree86-4.2.0 problems on a sony vaio fxa59
Brian T. Schellenberger wrote: On Tuesday 20 August 2002 09:29 pm, Mike Labriola wrote: | | so, anyone have any idea whether this is a video card driver problem with | x? or an lcd compatibility problem with x? or just an XF86Config problem? | (starting to doubt that last one...) I fear that I can't answer this question . . . | ps - as an odd side note, when i attempted to install redhat 7.3 on the | laptop, the graphical install worked fine (doesn't that use an x-server?) | and it even succeeded in testing the video settings... but when i started | up x after installing, it did the same thing. but still, why would | redhat's graphical install and x test thing work during the install? But I can answer this one. It uses a VGA X server. *That* uses a compatibility mode that is present in all graphics chips and it works everywhere. But it limits the display to 640x480 (or maybe 800x600). You could actually use this driver in the meantime to use it as a laptop, but I don't think you'd be satisfied running such a low resolution on your new laptop either. And frankly X (at least with most window managers) is really pretty painfaul--certainly less well-adapted than Microsoft Windows--at anything less than 1024x768. Still it might be a feasible workaround in the meantime. i had suspected that... but here's the trully odd part. the 'test config' thing that tests your x configuration successfully loads up a 1400x1050 screen (looks like an old screenshot of gnome 1.2) during the install. this of course leads to an almost viable solution question: can the vga server be made to run at 1400x1050? and if not, how the hell is redhat pulling this off? (and as a side note, isn't that a pretty unreliable way of testing the x config...?) -mike -- -- | Michael D. Labriola | |[EMAIL PROTECTED]| || | Admiralty Drive West Apt F4 | | Middletown, RI 02842 | |(401)846-4085 | -- ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xfree86-4.2.0 problems on a sony vaio fxa59
Brian T. Schellenberger wrote: BTW, my suggestion #1 always is to check out the Linux for Laptops page (even if you don't run Linux) for your machine and see if anybody there has a working XF86Config for you box screen. actually, i did look into 'linux for laptops'... that's why i got this particular laptop. according to pages linked from linux-laptops.net, every bit of hardware in the slightly cheaper model can be made to work... but i got the one with the faster chip and LARGER LCD SCREEN... (my bad) -mike -- -- | Michael D. Labriola | |[EMAIL PROTECTED]| || | Admiralty Drive West Apt F4 | | Middletown, RI 02842 | |(401)846-4085 | -- ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Question about XFree86 4.2
Thanks Mark On Thu, 2002-08-08 at 18:04, Mark Vojkovich wrote: On 8 Aug 2002, Mike Manchester wrote: I know that the old version of XFree86 used XF86Config and the new version uses XF86Config-4. But why is there both in the X11 dir and which should I be changing? Does XFree86 first load the XF86Config and then the XF86Config-4? I couldn't find an explanation in the docs. Also If I have X working with the older 3.3 or 4.0 can I use the XF86Config file for it for the new XF86 and should it work if it worked with 3.3 or 4.0? XFree86 4 will load the XF86Config-4 first and the XF86Config second if XF86Config-4 does not exist. This was done so XFree86 3 and XFree86 4 servers could exist on the same machine. XFree86 4 cannot read XFree86 3 config files. 4.2 should be able to read a 4.0 config file. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Question about XFree86 4.2
I know that the old version of XFree86 used XF86Config and the new version uses XF86Config-4. But why is there both in the X11 dir and which should I be changing? Does XFree86 first load the XF86Config and then the XF86Config-4? I couldn't find an explanation in the docs. Also If I have X working with the older 3.3 or 4.0 can I use the XF86Config file for it for the new XF86 and should it work if it worked with 3.3 or 4.0? This Thinkpad 760XL with the trident 9385 chip at 800x600 is driving me crazy. At first I thought the problem may be with RedHat as the Xconfig during the install works. I can see the screen just fine but after reboot it's hosed. But I've also tried Debian and it also has the same problem. I really don't want to make this a windows only machine but as of now that's the only thing that will run on it as far as a GUI is concerned. I've tried many different XF86Config files and Hz and Vert sync with no luck. I've even spent time with Alan on this problem. I don't know what changed between 4.0 and 4.2 but what ever it was broke the 760XL in anything other than standard SVGA mode. I have to rule out the hardware as windows and RedHat 7.1 run fine on it. Mike Manchester ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Option accel question
On Sat, 3 Aug 2002, Daniel Sheltraw wrote: Date: Sat, 03 Aug 2002 09:45:57 -0600 From: Daniel Sheltraw [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain List-Id: General X Discussion xpert.XFree86.Org Subject: Re: Option accel question Michel Thanks for the reply and thanks for helping us get an answer to our MB problem that Marc ultimately solved. Is the accel option implemeted using PCI DMA. I do not really understand what accel is all about. Can someone please shed a little light on the subject for me :-) ? Short answer: it depends on chip, driver and configuration. :) Slightly longer answer: most accel is done with MMIO access to chip registers. How does using the MMIO accelerate graphics? Confused. I just really do not know what acceleration means. Video hardware acceleration is the implementation in the video hardware itself of common graphics primatives and operations. Without hardware acceleration, the CPU has to do all the work. The CPU calculates the pixels when drawing lines, polygons, etc. and writes them into video memory. The CPU does all the work. With a 2D acceleration engine, like all video hardware has nowadays, instead of the CPU doing all this work, the CPU merely tells the video card draw a rectangle with these co-ordinates, then the video hardware's 2D acceleration engine draws that rectangle internally on the video card itself. This moves the drawing logic off the host CPU and onto the video card. There are all sorts of operations which are accelerated in hardware including line drawing, rectangles, fills, blitting images, etc. MMIO is memory mapped IO, which maps the hardware's IO register space into the memory map. This is one way of communicating with the hardware. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]nvidia binary driver: kernel BUG at page_alloc.c
On Fri, Jul 26, 2002 at 11:18:13AM -0700, Mark Vojkovich wrote: On Fri, 26 Jul 2002, Luca Olivetti wrote: Mike Stilson wrote: | BTW: Since I stepped back to 2314 it's been nice and stable (Only 3 days | so far but better than the 10 hours I could manage with the latest | driver.) I'm using this release now and while it seems better, it's still not totally reliable: it just killed X while using xvideo (this is probably the reason I've been upgrading nvidia drivers, to see if problems went away), but it seems it isn't screwing up anything else. Let's see how it works and if nvidia do care about fixing its driver (which I doubt). Don't use AGPGART. Use NVGART instead. It's not clear that this is NVIDIA's bug, and even if it were, it would definitely be in the open source part of the driver. I have option nvagp 0 in my config file. This didn't get changed at all. The absolute only change when my problems started was the upgrade to the latest NV_kern and NV_GL. If I remember, the longest it was stable with the latest one was 2 days, and I wasn't even stressing it with anything even close to xvideo. It would just decide to oops when it was doing basically nothing but blinking a cursor in an xterm. Changing back to my original 2314 rpm's, without even touching the config file has done away with all the problems. -mike -- Windows has detected that you have moved your mouse. Your system must now be restarted for the changes to take effect. - Unknown ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Re: Xpert digest, Vol 1 #2013 - 11 msgs
On Tue, 16 Jul 2002, David Dawes wrote: Date: Tue, 16 Jul 2002 10:06:53 -0400 From: David Dawes [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 List-Id: General X Discussion xpert.XFree86.Org Subject: Re: Re: Xpert digest, Vol 1 #2013 - 11 msgs On Mon, Jul 15, 2002 at 02:43:04PM +0200, Xavier Bestel wrote: Le lun 15/07/2002 à 14:20, Mike A. Harris a écrit : what you are asking for is the RandR (Resize and Rotate) extention. This extension is implemented already, and support for it is available in the kdrive X server included with XFree86. The core server simply has not had RandR functionality added yet. It isn't funded development, so it will be done whenever someone cares to do it and has the time. I'm interested in working on it, but it hasn't been priority one for me yet. IIRC Mark said the API between the core server and the drivers doesn't allow for RandR to be implemented. Most of the Resize part could probably be implemented within the current driver API, but as Mark said, a fully featured implementation is probably better targetted for XFree86 5.0. Resize is what I'm interested in, and have discussed with Keith a few months back. The only thing preventing me from working on it is a busy schedule... The rotate and depth stuff doesn't interest me at least not currently. It will be nice to have when it happens though. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Option nomtrr
A user has suggested that Option nomtrr has solved a problem for him, and would like me to make this option default for his card in the Cards database. I looked through the documentation briefly, and also greped the source tree. I see the option in the sources, but not in the documentation. Just wondering if I'm not looking in the right spot, or if it's just missing from the docs? If it is just missing, let me know and I'll update the XF86Config manpage, and send in a patch. Thanks -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: nvidia binary driver: kernel BUG at page_alloc.c
On Wed, Jul 24, 2002 at 01:43:54AM -0400, Mike A. Harris wrote: The Nvidia kernel module very much does and should taint the kernel. Yes, I see that now. The problem I've got right now is... why ISN'T it? -me ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]nvidia binary driver: kernel BUG at page_alloc.c
On Mon, Jul 22, 2002 at 11:25:35PM +0200, Luca Olivetti wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Stilson wrote: Are you sure the nvidia module was loaded at the time of this crash? It would taint the kernel if loaded: Jul 7 20:20:54 pippo kernel: kernel BUG at page_alloc.c:216! Jul 7 20:20:54 pippo kernel: invalid operand: Jul 7 20:20:54 pippo kernel: CPU:0 Jul 7 20:20:54 pippo kernel: EIP:0010:[rmqueue+479/544]Tainted: P Jul 7 20:20:54 pippo kernel: EIP:0010:[c012e68f]Tainted: P Just to follow up after giving a little more thought... The kernel module doesn't taint it since I'm recompiling it from source. the NVdriver.o module (although it doesn't specifically have a MODULE_LICENSE(GPL)) also doesn't have any conflicting or proprietary license. Now my understanding might be wrong, but it SHOULDN'T be tainting the kernel. Only the X driver (nvidia_drv.o) is closed source. Perhaps you have something else tainting it? -me -- Windows has detected that you have moved your mouse. Your system must now be restarted for the changes to take effect. - Unknown ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]nvidia binary driver: kernel BUG at page_alloc.c
On Tue, Jul 23, 2002 at 01:36:39PM +0200, Charl P. Botha wrote: On Tue, Jul 23, 2002 at 07:16:50AM -0400, Mike Stilson wrote: Just to follow up after giving a little more thought... The kernel module doesn't taint it since I'm recompiling it from source. the NVdriver.o module (although it doesn't specifically have a MODULE_LICENSE(GPL)) also doesn't have any conflicting or proprietary license. Now my understanding might be wrong, but it SHOULDN'T be tainting the kernel. Only the X driver (nvidia_drv.o) is closed source. The kernel module *does* taint it. You're only building three of the objects and then linking with Module-nvkernel, which is binary and which is where most of the juicy bits are. Ok, that being the case, any idea as to why it's not tainted? The module is remaining loaded. -- Windows has detected that you have moved your mouse. Your system must now be restarted for the changes to take effect. - Unknown ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: nvidia binary driver: kernel BUG at page_alloc.c
On Tue, 23 Jul 2002, Mike Stilson wrote: Date: Tue, 23 Jul 2002 07:16:50 -0400 From: Mike Stilson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii List-Id: General X Discussion xpert.XFree86.Org Subject: Re: nvidia binary driver: kernel BUG at page_alloc.c On Mon, Jul 22, 2002 at 11:25:35PM +0200, Luca Olivetti wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Stilson wrote: Are you sure the nvidia module was loaded at the time of this crash? It would taint the kernel if loaded: Jul 7 20:20:54 pippo kernel: kernel BUG at page_alloc.c:216! Jul 7 20:20:54 pippo kernel: invalid operand: Jul 7 20:20:54 pippo kernel: CPU:0 Jul 7 20:20:54 pippo kernel: EIP:0010:[rmqueue+479/544]Tainted: P Jul 7 20:20:54 pippo kernel: EIP:0010:[c012e68f]Tainted: P Just to follow up after giving a little more thought... The kernel module doesn't taint it since I'm recompiling it from source. the NVdriver.o module (although it doesn't specifically have a MODULE_LICENSE(GPL)) also doesn't have any conflicting or proprietary license. Now my understanding might be wrong, but it SHOULDN'T be tainting the kernel. Only the X driver (nvidia_drv.o) is closed source. Perhaps you have something else tainting it? The Nvidia kernel module very much does and should taint the kernel. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]nvidia binary driver: kernel BUG at page_alloc.c
On Mon, Jul 22, 2002 at 03:16:40PM +0200, Luca Olivetti wrote:
Anyway, I was having a lot of these messages (kernel BUG at
page_alloc.c) with the current version of nvidia driver (1.0-2960) and
afterwards the system is unpredictable (possible hard locks, file system
corruption, anything).
At first I didn't relate this to the nvidia driver, but I've looked at
the kernel mailing list and everybody says that the problem is NVIDIA
related (I tried to contact nvidia but it seems that
[EMAIL PROTECTED] is redirected to /dev/null).
It is related, and yeah, I'm pretty sure they dump it. I haven't heard
anything back since reporting the problem about a week after their
latest drivers were available. (Took it that long to isolate their
driver as the culprit. The oops'es were unpredictable and I still
haven't found what the actual cause is.)
I'm beginning to think that it is true, because, tired of all the
problems with this driver (earlier versions just froze X but this one is
more serious), I switched to the xfree nv driver and the system has
been rock solid since then, the only problem is that I cannot play
tuxracer anymore ;-)
I'm running Mandrake 8.2 with the updated kernel
Redhat (mixed up versions, I handle my own tarballs) with 2.4.18.
I didn't try the nv driver though. I tried it to start with and had
some problems I don't remember specifically at the moment.
FWIW I had the same issues.
The problem I had was that it would crash kswapd with the following
kernel: kernel BUG at page_alloc.c:82!
kernel: invalid operand:
kernel: CPU:0
kernel: EIP:0010:[__free_pages_ok+66/688]Not tainted
kernel: EIP:0010:[c012a7e2]Not tainted
kernel: EFLAGS: 00010286
kernel: eax: 001f ebx: c10dfd9c ecx: c0286fa0 edx: 0001332c
kernel: esi: c10dfd80 edi: ebp: esp: c3ec5f20
kernel: ds: 0018 es: 0018 ss: 0018
kernel: Process kswapd (pid: 4, stackpage=c3ec5000)
kernel: Stack: c0239c40 0052 c10dfd9c c10dfd80 001c c10dfd80 01d0
kernel:c10dfd9c c10dfd80 c012a072 c012b077 c012a0ab 0020 01d0 0020
kernel:0006 c3ec4000 008a 057c 01d0 c0288308 c012a2c0 0006
kernel: Call Trace: [shrink_cache+506/780] [__free_pages+27/28] [shrink_cache+563/780]
[shrink_caches+88/136] [try_to_free_ pages+60/92]
kernel: Call Trace: [c012a072] [c012b077] [c012a0ab] [c012a2c0] [c012a32c]
kernel:[kswapd_balance_pgdat+67/140] [kswapd_balance+18/40] [kswapd+153/188]
[kernel_thread+40/56]
kernel:[c012a3c3] [c012a41e] [c012a52d] [c0105478]
kernel:
kernel: Code: 0f 0b 83 c4 08 89 f0 2b 05 6c 3f 2f c0 c1 f8 06 3b 05 60 3f
(ksymoops output)
EIP; c012a7e2 __free_pages_ok+42/2b0 =
Trace; c012a072 shrink_cache+1fa/30c
Trace; c012b077 __free_pages+1b/1c
Trace; c012a0ab shrink_cache+233/30c
Trace; c012a2c0 shrink_caches+58/88
Trace; c012a32c try_to_free_pages+3c/5c
Trace; c012a3c3 kswapd_balance_pgdat+43/8c
Trace; c012a41e kswapd_balance+12/28
Trace; c012a52d kswapd+99/bc
Trace; c0105478 kernel_thread+28/38
Code; c012a7e2 __free_pages_ok+42/2b0
_EIP:
Code; c012a7e2 __free_pages_ok+42/2b0 =
0: 0f 0b ud2a =
Code; c012a7e4 __free_pages_ok+44/2b0
2: 83 c4 08 add$0x8,%esp
Code; c012a7e7 __free_pages_ok+47/2b0
5: 89 f0 mov%esi,%eax
Code; c012a7e9 __free_pages_ok+49/2b0
7: 2b 05 6c 3f 2f c0 sub0xc02f3f6c,%eax
Code; c012a7ef __free_pages_ok+4f/2b0
d: c1 f8 06 sar$0x6,%eax
Code; c012a7f2 __free_pages_ok+52/2b0
10: 3b 05 60 3f 00 00 cmp0x3f60,%eax
This vanished when I backed down to NVIDIA_kernel-2314.
No big loss to me except I miss the loss of DigitalVibrance.
If only I could grab the source I'd backport it, and alas my asm
(especially gdb disassembling it) is pretty rusty.
$ cat /proc/driver/nvidia/cards/0
Model: GeForce2 MX/MX 400
IRQ: 10
Video BIOS: 03.11.00.18
Card Type: AGP
$ cat /proc/driver/nvidia/agp/card
Fast Writes: Supported
SBA: Not Supported
AGP Rates: 4x 2x 1x
Registers: 0x1f17:0x1f000104
$ cat /proc/driver/nvidia/agp/host-bridge
Host Bridge: Via Apollo Pro KT133
Fast Writes: Not Supported
SBA: Supported
AGP Rates: 4x 2x 1x
Registers: 0x1f000207:0x0104
$ cat /proc/driver/nvidia/agp/status
Status: Enabled
Driver: AGPGART
AGP Rate:4x
Fast Writes: Disabled
SBA: Disabled
$ cat /proc/driver/nvidia/version
NVRM version: NVIDIA NVdriver Kernel Module 1.0-2960 Tue May 14
07:41:42 PDT 2002
GCC version: gcc version 2.96 2731 (Mandrake Linux 8.2 2.96-0.76mdk)
$ find /proc/nv -type f -exec cat {} ';'
- Driver Info -
NVRM Version: NVIDIA NVdriver Kernel Module 1.0.2314 Fri Nov 30 19:33:20 PST 2001
Compiled with: gcc version 2.95.3 20010315 (release)
-- Card Info --
Model:
Re: [Xpert]nvidia binary driver: kernel BUG at page_alloc.c
On Mon, Jul 22, 2002 at 11:25:35PM +0200, Luca Olivetti wrote: Mike Stilson wrote: | FWIW I had the same issues. | The problem I had was that it would crash kswapd with the following In my case it was either kdeinit, xmessage, kswapd, startkde,... 99% of the time it would crash kswapd, more or less causing a cascade from there. Usually one or two apps running on the desktop would oops, then X itself. Sometimes it would prevent you from switching to a vc (just a garbled screen) but would let you return to the x desktop fine. Other times it took a hard reset to do anything. | kernel: kernel BUG at page_alloc.c:82! | kernel: invalid operand: | kernel: CPU:0 | kernel: EIP:0010:[__free_pages_ok+66/688]Not tainted | kernel: EIP:0010:[c012a7e2]Not tainted Are you sure the nvidia module was loaded at the time of this crash? It would taint the kernel if loaded: Jul 7 20:20:54 pippo kernel: kernel BUG at page_alloc.c:216! Jul 7 20:20:54 pippo kernel: invalid operand: Jul 7 20:20:54 pippo kernel: CPU:0 Jul 7 20:20:54 pippo kernel: EIP:0010:[rmqueue+479/544]Tainted: P Jul 7 20:20:54 pippo kernel: EIP:0010:[c012e68f]Tainted: P positive. I've wondered about that myself several times, so I made quite sure to check whenever possible. Unless it was doing something VERY strange, it most definitely was loaded for all of them. In fact, several other oopses (unrelated) while the nvdriver was loaded weren't tainted either. BTW: Since I stepped back to 2314 it's been nice and stable (Only 3 days so far but better than the 10 hours I could manage with the latest driver.) -me -- Windows has detected that you have moved your mouse. Your system must now be restarted for the changes to take effect. - Unknown ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: ATI Radeon 8500 support
On Wed, 17 Jul 2002, Eric Sprague wrote: Date: Wed, 17 Jul 2002 20:25:31 -0700 (PDT) From: Eric Sprague [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii List-Id: General X Discussion xpert.XFree86.Org Subject: Re: ATI Radeon 8500 support You'll need a very recent distribution, since only XFree86 4.2.0 supports this card. I know that Gentoo 1.2 has it, though I wouldn't recommend that one for a beginner. You might try SuSE 8.0 or Red Hat 7.3, though I'm not sure about those either. Red Hat Linux 7.3 supports the Radeon 8500, and includes XFree86 4.2.0. This is 2D only support of course, until 3D support is completed by Tungsten Graphics. The Weather Channel has funded the open source 3D development for the ATI Radeon 8500 (r200 based boards). Hope this helps, TTYL -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Is the XFree development stuck in a dead end?
On Mon, 15 Jul 2002, Christian Berger wrote: Netscape is much faster than Mozilla. I think it's just that some design decisions in the X version of Mozilla, which is probably much different than the Window's version, are suboptimal. Having seen enough Well I doubt Mozilla for Windows is faster than Mozilla for Linux. You've not tried it then. Mozilla for Windows running on my box on one processor runs faster than Mozilla in Linux running on both processors. (Win98SE). Application startup time is faster for Mozilla in Windows, as is runtime execution. Not measured or benchmarked mind you. It is visibly noticeable. If it were faster in Linux, I certainly wouldn't say it was faster in Windows. Mozilla (GNU-Version) is still a bit slower than Netscape Navigator 4.x, but that's an application problem, not a graphics problem. Indeed. And in fairness to the Mozilla developers whom are doing a fantastic job of developing the browser, every version of Mozilla for Linux that I've upgraded to has been noticeably faster and less buggy. I've been using Mozilla as my primary browser now for almost 2 years if not longer. It has come a long way in a short time IMHO. I'm confident that the performance issues that remain, will get resolved all in due time. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Is the XFree development stuck in a dead end?
? Perhaps something is messed up with that process. I'm sorry to say that is the kind of attitude that you (and others like you) have towards potential new developers that is holding the XFree86 development down. You fail to realize that there is a thin line between the experienced and not experienced, and that those who do have the experience also have the power to quickly transform an unexperience yet motivated soul into an experienced one. Again, I think you've misinterpreted what Mark is trying to say, and have taken it as an insult personally. I'm willing to wager that Mark's intentions are not as you've perceived them. Either way, more developers are needed in order to get a lot more work done. Those developers can be anyone, experienced or not. Someone experienced is likely to be able to contribute more than someone not experienced - at least until the lesser experienced person gains experience. That is just common sense. dream Give CVS access for more people, open up the development, close the closed development mailing lists, substitute the central development model for effective QA, incentivate people to help, and make sure their involvement is appreciate... /dream I'm all for seeing the developmental processes continue to become more open. For the record though, the private mailing lists truely do not contain much content at all. There might be one or two mails a week, and they are generally nothing that important at all. People who think a large amount of discussion goes on in private mailing lists of the XFree86 project are simply wrong. Everything is done right here on xpert list. In fact, any time someone does start a discussion on a private list, Keith or someone else tend to tell them to move the discussion to xpert list. There is little if any discussion I've seen on the private lists that really are private. For all realistic purposes, the lists don't really exist. More people with CVS write access to the trunk is something that I think should be very carefully considered. David et al need to be comfortable that giving someone write access is the right thing to do first. That is something one has to earn by showing they know what they're doing, and that having write access would alleviate core members from having to commit things. I don't see any problems that would be caused however from having branches of CVS available that other developers could use. That would be a good thing IMHO. If there were a larger number of active contributors contributing frequently in a linux-kernel style, that increased the patch submission burden beyond what core developers could handle, and some of those developers obviously showed skill at separating the good stuff from the bad, I've a feeling David would have little objection to adding more people as long as it saved him work and didn't create him work (or other core members). That's my personal opinion though, I can't speak for the core team. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Re: Is the XFree development stuck in a dead end?
On Tue, 16 Jul 2002, Geoffrey wrote: Date: Tue, 16 Jul 2002 09:29:02 -0400 From: Geoffrey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed List-Id: General X Discussion xpert.XFree86.Org Subject: Re: Re: Is the XFree development stuck in a dead end? Mike A. Harris wrote: On Mon, 15 Jul 2002, Christian Berger wrote: Netscape is much faster than Mozilla. I think it's just that some design decisions in the X version of Mozilla, which is probably much different than the Window's version, are suboptimal. Having seen enough Well I doubt Mozilla for Windows is faster than Mozilla for Linux. You've not tried it then. Mozilla for Windows running on my box on one processor runs faster than Mozilla in Linux running on both processors. (Win98SE). Application startup time is faster for Mozilla in Windows, as is runtime execution. Not measured or benchmarked mind you. It is visibly noticeable. I'm really hoping this thread dies soon, but I've got to chime in here. There is absolutely no comparison between the windows gui and X. I routinely have 10-15 windows open, which would include at least 2 mozilla mail windows and minimally 3-4 browser windows. I also have 2 desktops with 3 virtual desktops each. You just don't get that kind of functionality with a Windows gui and if you tried to have that many windows open on win95, win98, nt, win2k, it would purely meltdown. I have no experience with winxp and don't plan to, but I suspect it's no different. The above argument appears to revolve around Mozilla, not X. I think perhaps you've misinterpreted what I've said. My above claims did not really have anything at all to do with comparing X to Windows. What I was saying was that Mozilla is slower in Linux than it is in Windows, and that the reason for that is a Mozilla issue, not an X issue or a Windows issue. Mozilla shares code between Windows and X11, however the Windows specific Mozilla code is more optimized than the X specific Mozilla code. Basically, the fact Mozilla is slower in Linux/X has nothing to do with X, and is no indicator that X is slower than Windows. The entire Mozilla discussion is a sidetrack from the $topic actually. I just wanted to set the record straight that Mozilla *is* faster in Windows contrary to the given hypothesis that it would not be faster in Windows. I mostly use Mozilla in Linux, however any time I get stuck in a Windows environment and need a browser, that browser is Mozilla, and since I use it all the time, seeing it start up and run several times faster than I'm used to in Linux, is a noticeable thing. I've never assumed that this was due to Windows being faster. IMHO, any slow GUI code running in X, is more likely to be a poorly written *application* or an unoptimized app, or unoptimized toolkit or similar. In the end however, only true profiling can be the judge in any particular case of a slow app. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]re:xf86_svga server
On Tue, 16 Jul 2002, Peter Johnson wrote: XF86_SVGA is the old (v 3.3.6) X server for a wide range of svga-capable chips, including some of the Chips and Technologies video controllers. Redhat does some odd stuff with X; check /etc/X11 directory to see whether you're configured for v 3.3.6 (XF86Config only) or v 4.1 (XF86Config-4 is present). You'll find that most distributions out there ship both 3.3.6 and 4.x X servers and allow the end user to switch between them in order to get the best support. This isn't a Red Hat thing, it is something that was done so that people who had hardware unsupported by XFree86 4.x, could still use the system during the beginning of the changeover to 4.x. All Linux distributions have shipped both, and follow a similar way of allowing them to co-exist. Nonetheless, I'm interested on hearing from you what exactly is odd about the way we do things, and how that differs from what other distributions have done to allow coexistance. You may also be interested to find out that the whole XF86Config/XF86Config-4 config files are something which was created by XFree86.org to allow the coexistance of both versions of XFree86 until the older hardware could have drivers ported to the new architecture, or become irrelevant. Many people have thought this was some Red Hat invention. They are wrong, and hopefully now informed of reality. Red Hat, like other distributions, have used this functionality graciously provided by the XFree86 team to allow coexistance and maximize the number of users that could use XFree86 in the distribution. Those who have read the documentation provided by XFree86 however would already know this. man XF86Config Note the location of the config files. Note that Red Hat did not modify this. If you must use Redhat, use Xconfigurator to keep this silliness straight and make sure things are done as Redhat expects. Again, you only illustrate your lack of knowledge of XFree86, and that this is not a Red Hat whim. It is a documented feature of XFree86 which exists for a reason. Read that documentation, and learn before rambling FUD. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Re: Is the XFree development stuck in a dead end?
On Tue, 16 Jul 2002, Andrew P. Lentvorski wrote: Date: Tue, 16 Jul 2002 10:52:22 -0700 (PDT) From: Andrew P. Lentvorski [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: TEXT/PLAIN; charset=X-UNKNOWN List-Id: General X Discussion xpert.XFree86.Org Subject: Re: Re: Is the XFree development stuck in a dead end? On Tue, 16 Jul 2002, [iso-8859-1] José Fonseca wrote: My interest in the XFree86 development is infact rather specific: the RandR extension will be a crucial brick for a proper 3D support on lower end cards such as Mach64 which have little onboard memory. My question to you is: why do you want to spend your time on this when you can buy a *much* higher end card than a Mach for $40 US? Your time is worth than that, even if you are a student. One of the primary time-wasters in open-source is that developers spend a lot of time on support for hardware which is obsolete. When obsolete hardware was much cheaper than brand new hardware, this support for was important. Now, however, that difference is pretty minimal. Buy a new card and save yourself lots of pain. The primary motivating factor behind such an effort is laptops. You can't generally replace the video hardware in /most/ laptops, and as such, if you have a Mach64 based laptop, and no reason to shell out $2000-3000 because the machine is suitable still for what you require, then having 3D work on it may be worth the effort. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Is the XFree development stuck in a dead end?
with a fastpath to avoid protocol encode/decode for the local server case. Both of these projects (and likely many more) have gotten basically nowhere. Reinventing the wheel from scratch is 1 times more complex than improving the current X11 system. Why? Because you have to learn all of the same mistakes yourself that existing X developers already know. People tend to simplify systems by making them do what _they_ want/need/see as relevant, and ignoring what others want/need. Then over time that new system gets hacked and kludged by various people to do more and more what the existing system does. In the end, you've reinvented the wheel. But, if there isn't enough people working on X currently, there would be much less people available to reinvent it, so the idea is fruitless IMHO. Nonetheless, feel free to start a new project on sourceforge to do so if you think it is a meritable idea. Or just take over one of the many other projects that have been started and dropped. I know this would be a pretty radical cut, but I personally don't see any alternative to overcome the current problems of XFree. Yes, there are problems with XFree86/X11, and people are working on them. There are finite people, and finite resources. We don't really need or benefit from people pointing out the flaws of the system (or percieved flaws), but we do benefit from people writing code and volunteering to make the system better. Anyone working on X right now, is probably quite unlikely to consider workign on a new graphical system from scratch, which makes the pool of people quite small who would venture into such an idea. Volunteer to help fix the problem: - extend X to add features that are not present but required or would-be-nice - write new software to make using X/configuring it, etc easier - fix bugs in the existing code - write new video drivers, or improve existing ones, fix driver bugs. - write new documentation, or complete existing but incomplete documentation. - advocate helping people becoming involved - write FAQ's and other helpful guides to help new developers - help beta test the code, use CVS, etc. so bugs can be found and fixed faster. The main problem with a new graphics API would be to keep backward compatibility with the current application base. But this problem is easy to solve by just porting XFree to the new API, the way it is done for OS X and Windows. The main problem with a new graphics API is that it is irrelevant and unnecessary. We've got an API already that is just fine, and anything it lacks, it is flexible enough to be sanely extended. Who wants to go and rewrite every app out there to use a new API? There are tonnes of efforts already to write new API's, and nobody has jumped to support them in a large manner yet, nor are they likely to. X11 and XFree86 are here to stay, and nothing is likely to challenge that IMHO. People can grumble about it's current shortcomings and become part of the problem, or they can participate in writing code or documentation, or otherwise contributing constructively and usefully, advocating improvements, testing, etc., and be a part of the solution. My $0.02 -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Is the XFree development stuck in a dead end?
On Sun, 14 Jul 2002, Mark Vojkovich wrote: I know there have been countless discussions on the X messaging system, but most of them missed the point. That is that such a messaging system introduces an enormous amount of complexity. As far as I know the only reason for having the X messaging system is the remote display feature. But I guess that less than 5% of the XFree users are actually using this feature and there are already other solutions like VNC available. Another source of complexity comes from the ancient, more than 10 years old X API. Many people argue that one just has to add new extensions to keep XFree up to date. But this way X gets more and more complex. And why are the X is highly extensible by design. It's far less complex than alternative window systems like MS Windows or OS-X and is probably more extensible. I'd definitely have to agree with that for sure. As a result of this complexity the developers working on XFree are less efficient and it also keeps new developers from joining this project. What I want to suggest is to start from scratch and design a new, clean and modern windowing system without any legacy. I know this would be a pretty radical cut, but I personally don't see any alternative to overcome the current problems of XFree. The main problem with a new graphics API would be to keep backward compatibility with the current application base. But this problem is easy to solve by just porting XFree to the new API, the way it is done for OS X and Windows. I think you have the wrong mailing list. XFree86 is an implementation of the X-Window system. The key phrase here is the X-Window System. XFree86 is headed in the directions of an X-Window compatible system, meaning we intend to extend XFree86 well beyond the base sample implementation, and in many regards we have done this already, but we have no intention of dropping what you call legacy support. As far as development being stuck, no, I don't think so. It's just that the people who know enough about anything to get things done are very few. I think that pretty much hits the nail on the head right there. An effort at a website with tutorials, HOWTO's and other developer related help information geared at helping NEW developers get up to scratch on given areas would be very useful if someone has the time to work on it. I've been writing some things for a while, none of which are complete. Something like the dri website's new developer info, etc. That would start to help anyway. I think it will happen in time. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Is the XFree development stuck in a dead end?
On 15 Jul 2002, Xavier Bestel wrote: Date: 15 Jul 2002 01:56:41 +0200 From: Xavier Bestel [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 List-Id: General X Discussion xpert.XFree86.Org Subject: Re: Is the XFree development stuck in a dead end? Le lun 15/07/2002 à 01:39, Nick Name a écrit : (3. It should be possible to configure XFree over a dialog that is intergrated in Gnome and Kde.) Someone should write it. Indeed I think there are: I personally use debian, but Mandrake, Suse and RedHat users continuously say that their distribution can do everything graphically. Better yet, XFree shouldn't need configuration at all with modern hardware: config is just needed for some old un-probable chips, and some settings such as resolution, depth, etc. (which should be settable on the fly, BTW) That is true in many aspects, and XFree86 is definitely headed more in that direction. It does not happen overnight however. The issue is really manpower, and developers interested in volunteering to do the work, or companies who want feature foo implemented funding development of foo. I personally don't see any alternative to overcome the current problems of XFree. I don't see real problems in XFree, and think that one of the best features of X is the networking capabilities. Indeed, have a look to how easy is to have xinerama on two different video cards. Do this with windows or macos. It's hard, if not impossible at all. Is that a joke ? Did you ever try to set up a second gfx card and monitor under Mac OS ? It's a breeze, just point'n'click. Whereas in X, you have to hunt for the Xinerama HOWTO and mess with the config file. xf86cfg has multihead configuration built in, although it isn't what I personally consider user friendly. This is something that will become more friendly in the future though as multihead becomes much more popular. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Is the XFree development stuck in a dead end?
On Mon, 15 Jul 2002, Nick Name wrote: Date: Mon, 15 Jul 2002 02:22:37 +0200 From: Nick Name [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII List-Id: General X Discussion xpert.XFree86.Org Subject: Re: Is the XFree development stuck in a dead end? On 15 Jul 2002 01:56:41 +0200 Xavier Bestel [EMAIL PROTECTED] wrote: Is that a joke ? Did you ever try to set up a second gfx card and monitor under Mac OS ? It's a breeze, just point'n'click. Whereas in X, you have to hunt for the Xinerama HOWTO and mess with the config file. Ok, sorry. I just made THE mistake: speaking 'bout what I don't know. Sorry. But really, I've tried to simply install a second video card, different from the first, in win98. Freeze. Stop. No way, I had to remove the card, and manually remove the driver... still I can't remember how I got out of that mess. In the same period, with X, I could do everything I want, even get two 3d games running at the same time, one on a matrox, and another on a s3/3dfx pair... simple: use two X servers :) For this example, I'd have to say it is not really too relevant because just as many people are likely to have had the reverse happen, where it just worked in Windows, and it was a big pain in the ass in XFree86/Linux et al. I've personally experienced both depending on the hardware. Getting an i740 working in Linux a couple years back took 20 minutes, while getting it working in Windows involved reinstalling the OS, installing USB support in Windows 95 to get some random DLL, flashing my BIOS, then installing about 7 things in a particular order. I had to reinstall Windows twice actually because I screwed up on step. I've had the reverse experience with other hardware, where it worked great in Windows and sucked in Linux and was a pain in the ass to get working (if it worked at all). Same goes for configuration of various hardware. Sometimes it is straightforward, other times it is not. It depends on so many different variables, there is no one best system or one best solution. And what works great for one person, may work crappy for another depending on hardware combinations, etc. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Xpert digest, Vol 1 #2013 - 11 msgs
On Sun, 14 Jul 2002, Joseph Pingenot wrote: Date: Sun, 14 Jul 2002 22:04:39 -0500 From: Joseph Pingenot [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii List-Id: General X Discussion xpert.XFree86.Org Subject: Re: Xpert digest, Vol 1 #2013 - 11 msgs From: Lukas Molzberger [EMAIL PROTECTED] (3. It should be possible to configure XFree over a dialog that is intergrated in Gnome and Kde.) I think what he means here is resizing the screen *without* going to a virtual screensize. One can resize the screen via keys or via a GUI (e.g. wmxres), but the problem is that it's a *virtual* screen then, and, instead of acting like a full screen, one scrolls around on the larger virtual screen. I don't see the connection to that from what he said, however what you are asking for is the RandR (Resize and Rotate) extention. This extension is implemented already, and support for it is available in the kdrive X server included with XFree86. The core server simply has not had RandR functionality added yet. It isn't funded development, so it will be done whenever someone cares to do it and has the time. I'm interested in working on it, but it hasn't been priority one for me yet. What would be nice is a way to have X not make the new screen res virtual, but actual. :) RandR BTW, what Xlib calls are involved to change screen resolution? I couldn't find one in the manpages, so far as I can tell. None, it is the vidmode extension which changes video modes currently, but that doesn't resize the root window. RandR is needed for that. So this one feature is more or less 90% done already. Not something worth rewriting a new GUI from scratch over, and it illustrates how easily XFree86 can be extended to add new features as new requirements and problems present themselves as being important to solve, and developers exist to implement the new solutions. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Is the XFree development stuck in a dead end?
On Mon, 15 Jul 2002, Lukas Molzberger wrote: Date: Mon, 15 Jul 2002 09:34:11 +0200 From: Lukas Molzberger [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 List-Id: General X Discussion xpert.XFree86.Org Subject: Re: Is the XFree development stuck in a dead end? On Monday 15 July 2002 01:39, Nick Name wrote: 1. XFree is far too slow. I don't know what your terms of comparison are, but for example return to castle wolfenstein on same hardware runs really faster than on windows, with maximum settings. Dunno if this means anything. Sorry, I should've written clearer what I mean. Only the 2d performance of XFree is slow. For example XVideo Opengl are indeed very nice. I don't use WinXP for other reasons, but just compare it with XFree. I think the feeling is just so much better. I mean thats not a special XFree problem. I've worked on IRIX machines for a long time and there you have the same problem. I mean I know that it's not all XFrees fault. The Toolkits also play an important role. You're claiming it isn't XFree86's fault now, whereas your last email was suggesting someone should set out to reimplement XFree86 because it was slow. Why reimplement a GUI if it isn't slow. Guessing at the problem, and shooting in the dark doesn't solve the problem. Use profiling software such as oprofile to find what is slow, and either fix it, or provide your profiling results to the community so other potential developers can work on improving the situation. The more we work together to find the problems of the _existing_ system we have, and fix them, the betteer the system will be. Dividing ourselves and randomly reimplimenting things from scratch only slows development down even further. 2. What is presented on the screen should always be consistent (i.e. no flickering). It is already? No, just move one Window over another or do an opaque window resize and you'll see artefacts all over the place. Works fine for me. Most likely your video driver is buggy, or acceleration is disabled. The solution to that, is to debug it, and fix it, or report the bug, and hopefully someone else with the hardware and specs can debug and fix it. (3. It should be possible to configure XFree over a dialog that is intergrated in Gnome and Kde.) I would like to apologize in case I didn't find the right words. I just think there is a problem with XFree and don't see it going away anytime soon. Sure, there are problems with XFree86, just like any software. Those problems will get solved as more people who care enough about them being solved join in the effort at solving them. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Is the XFree development stuck in a dead end?
their existance on a system or not, does not make learning X more or less difficult. Don't need XIE or PEX? Don't read their documentation, or use them. If they're not used, then they pose no negative aspect on the system at all. So I don't at all see the point of your age argument. Should some new GUI be designed every 5 years and the existing GUI of the time thrown out, because it is now 5 years old? That is what it sounds like you're advocating. Doesn't make much sense if the existing system works well and is easily extensible to add new features as needed. 2d graphics drivers in users space while the 3d drivers are in kernel space? You are mistaken. 3D drivers are not in kernel space. OpenGL is in user space in every OS I can think of. I'm pretty sure there is 3D driver part in kernel space. And I think it would be a good idea to also put the 2D part there. For example to have access to the interrupts. Again, you're pretty sure but wrong. The 3D driver code and the 2D driver code are in userland. There is the DRI, of which the kernel portion is the DRM. The DRM allows userland video driver code to do DMA to the video hardware. ALL of the driver code itself is in userland. No, it is not a good idea to put it in the kernel. And as stated in a previous message, the Radeon driver is one which takes advantage of the DRM interface for both 2D and 3D when DRI is enabled. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]i830 support on a sony vaio R600
Did you get an answer to this? I found the instructions at http://www.jongans.com/gateway1450.html got my X server running, but the bottom half of the screen leaves crap laying around. I only had about an hour to work on it so probably I missed something; none the less I got 1024x768 24-bit color mode on my Dell Inspiron, which is certainly a step in the right direction! Mike On Thu, 4 Jul 2002, Fabrice Desré was heard whispering through the Net: fabric Hello, fabric fabric I'm trying to set up XFree86 on my sony laptop using a CVS version of fabricXFree 4.2. This version contains the i810 patch to enable more video fabricthan the 1mb provided by the BIOS. fabric However, i still can't get it to work. It seems that a dual-headed fabricsupport is detected, but that the driver doesn't support it. However i fabriccan live without the dual head support (this would be extremely nice to fabrichave it working, but not a priority) so I wonder if the issue is in my fabricconfig file or with the driver support for my hardware. fabric You'll find my XF86Config-4 file and the XFree error log as attachments. fabric fabric Thanks for any help, fabric fabric Fabrice fabric-- fabricFabrice Desré - FT.BD/FTRD/DTL/TAL fabricTél: (33) 2 96 05 31 43 fabricFax: (33) 2 96 05 39 45 fabric ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Xpert digest, Vol 1 #1943 - 1 msg (OUT OF THE OFFICE)
PROTECTED]) 5. Re: Re: 10-bits per colour ([EMAIL PROTECTED]) 6. Re: Help about woking of X-server (Michel =?ISO-8859-1?Q?D=E4nzer?=) -- __--__-- Message: 1 Date: Sun, 23 Jun 2002 12:51:48 -0600 From: Jason Craddock [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Xpert]Re: Xpert digest, Vol 1 #1940 - 8 msgs (OUT OF THE OFFICE) Reply-To: [EMAIL PROTECTED] This message has been automatically generated. Jason will be out of the office from June 24th through July 1st. If you need immediate assistance please contact Alisa Ott at [EMAIL PROTECTED] or by calling 801-225-6080. Thank you, Jason Craddock [EMAIL PROTECTED] 06/23/02 13:00 Send Xpert mailing list submissions to [EMAIL PROTECTED] To subscribe or unsubscribe via the World Wide Web, visit http://XFree86.Org/mailman/listinfo/xpert or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of Xpert digest... Today's Topics: 1. Radeon 7500 TV out works partially... (Nils Philippsen) 2. Re: Trident bug (Egbert Eich) 3. Re: is ATI Radeon 7000 Video w/ 64MB supported with xfree86 for redhat Linux 7.1 (Mike A. Harris) 4. Re: Trident 9660 Xv bug? (Alan Hourihane) 5. Re: Radeon 7500 QW and sgi 1600sw with MLA (Michel =?ISO-8859-1?Q?D=E4nzer?=) 6. Re: Trident bug (kiss the sun and walk on air) 7. Re: Re: 10-bits per colour ([EMAIL PROTECTED]) -- __--__-- Message: 1 From: Nils Philippsen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: 23 Jun 2002 09:42:38 +0200 Subject: [Xpert]Radeon 7500 TV out works partially... Reply-To: [EMAIL PROTECTED] --=-oXlCRW3t8eTIaatvCxrl Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ... well, for the 80x25 text console anyway when enabling TV out with atitvout. I have spent the better part of yesterday afternoon to come up with a modeline that would display my screen to the TV and got as far as having a screen with proper vsync, i.e. the lines didn't run through, stayed at the places they were. AFAICS the hsync isn't working, because the individual lines are too short and each one is offset in relation to the preceding line. I got these best results with NTSC modes even though my TV is really a PAL one (that only happens to display NTSC as well if I guess correctly). This seems consistent with the text console showing properly as it's got 60Hz vsync also. Now my maybe uninformed idea is, should I get hold of a modeline with the same parameters as the 80x25@60Hz text console, I should get a valid picture on the TV. I tried to get the necessary information to do this yesterday but to no avail, so: Does anyone know a modeline that resembles the text console? Or pursuing another direction: I know that there's some Windows tool which tells you the modeline for the currently set graphics mode (I don't know its URL at the moment, does anyone else?), can anyone with Windows run it when the TV out is working? Ah yes, other details: Red Hat Linux 7.3, packaged XFree86-4.2.0-8, atitvout-0.2b TIA, Nils --=20 Nils Philippsen / Berliner Stra=DFe 39 / D-71229 Leonberg // +49.7152.209647 [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] Ever noticed that common sense isn't really all that common? --=-oXlCRW3t8eTIaatvCxrl Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9FXvuR9ibZWlRMBERAsKfAJ9dEpqQsJZc01kfNgtbz53nWplCZQCgkbdI b+AoNSBCWD/nD6kPx99Zjeo= =DGw6 -END PGP SIGNATURE- --=-oXlCRW3t8eTIaatvCxrl-- -- __--__-- Message: 2 Date: Sun, 23 Jun 2002 10:19:47 +0200 From: Egbert Eich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Xpert]Trident bug Reply-To: [EMAIL PROTECTED] kiss the sun and walk on air writes: Agreed. A positive value exacerbates the the problem. The ability to go farther in the negative direction is needed to find the best value. OK. Well like I've said already. I added this using some older manuals taking some educated guesses. Egbert. -- __--__-- Message: 3 Date: Sun, 23 Jun 2002 06:12:20 -0400 (EDT) From: Mike A. Harris [EMAIL PROTECTED] To: [EMAIL PROTECTED] Organization: Red Hat Inc. Subject: [Xpert]Re: is ATI Radeon 7000 Video w/ 64MB supported with xfree86 for redhat Linux 7.1 Reply-To: [EMAIL PROTECTED] On Sun, 23 Jun 2002, Walter Logeman wrote: Date: Sun, 23 Jun 2002 15:35:19 +1200 From: Walter Logeman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii List-Id: General X Discussion xpert.XFree86.Org Subject: Re: is ATI Radeon 7000 Video w/ 64MB supported with xfree86 for redhat Linux 7.1 Dr Andrew C Aitchison, IIRC xf86config
[Xpert]Re: Weird scan-rate related crash in Radeon driver
On Sun, 23 Jun 2002, David D. Hagood wrote: My questions are: 1) How can I get symbols loaded on the drivers, so that I can debug this in a civilized fashion? Do I need to build the Radeon driver into X (i.e. is the module load process stripping the symbol data)? Install the XFree86 src.rpm, edit the spec file, change the line DebuggableBuild to 1, and append dbg do the Release number. Then do: rpm -bb XFree86.spec The resulting packages contain full debug code and symbols for everything. You can debug it then with gdb from: ftp://people.redhat.com/mharris/gdb-xfree86 Additional information: System is a PIII-800 running RH7.2 with 2.4.18 with pre-empt and XFS. Card is a Radeon 7500 I've seen this both with the binaries on XFree and with my own builds from today's CVS from DRI. Red Hat Linux 7.2 doesn't support the Radeon 7500. You need XFree86 4.2.0 for Radeon 7500 support, which comes with Red Hat Linux 7.3. good luck, TTYL -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: AW: Re: again firegl8700
On Fri, 21 Jun 2002, Johannes Rath wrote: Date: Fri, 21 Jun 2002 11:20:05 +0200 From: Johannes Rath [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 List-Id: General X Discussion xpert.XFree86.Org Subject: AW: Re: again firegl8700 Mike, that's not correct. 1002:5148 is the chip ID for the r200 (used on both boards) The boards can be found in the subdevice ID: ATI FireGL 8700 1002:0172 ATI FireGL 8800 1002:0152 Even better. Thanks John, I will update the list to detect both of these cards now. No idea if both cards work with the open source driver or not, but it doesn't hurt to find out. ;o) At least it wont show up autodetected improperly, or not at all in an lspci listing. Thanks again. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Re: again firegl8700
On Fri, 21 Jun 2002, Dr Andrew C Aitchison wrote: 01:00.0 Class 0300: 1002:5148 (rev 80) thank you No, thank you! ;o) I've just updated our hardware database to autodetect the FireGL 8700 as 1002:5148 Does anyone know what the ATI FireGL 8800's PCI ID is? I'll add that one too. Is there enough pattern to the ATI PCI chip ids to guess which driver to use for unknown chips? The ATI hardware documentation provides enough information to know what family (Mach64/R128/Radeon R100/RV100/R200/RV200) wether or not it is a Mobility chip, and which one, etc. I haven't noticed anywhere in the docs which show the actual board names used to market the video hardware such as Xpert@Work 98, FireGL 8700, etc. A fair number of these ID's we can autodetect and point to the right driver, since if XFree86 supports the card, then it has the PCI ID listed internally, and we can just use that info to provide the right driver. If I'm unsure if a card will work or not, and don't have one, I look at the docs, and the code, and try to add support that will hopefully work (and mostly has so far). However I may not know a given card is a ATI Radeon 7200 per se. (random example). So users wont actually see ATI Radeon 7200 show up as autodetected currently, they'll see ATI Radeon QD or whatever it happens to be. By the way... what is the lspci -vn output of a Radeon 7000, 7200 so I can make these autodetect with proper names. ;o) For example we could have guessed that the 1002:5148 would user the same driver as 1002:5144 - 1002:5148. When we add the ID to the hardware database it isn't as if we actually change the driver in any way. Well, when it is added to XFree86 xf86PciInfo.h, the driver does need to change, so whoever is making those changes needs to know if it is a Radeon or whatever, or what driver it should get added to, as the conditional code paths in the given driver will need to be updated for the new card. That coupled with the ATI tech specs allows me to set up the PCItable to choose the right driver. For some hardware we may not know if it _works_, but that is what beta testing is for. If something doesn't work, it can be fixed and/or disabled, or the vesa driver used temporarily instead. I'm looking into getting a more proper official list of the PCI ID's and the marketing names they map into, so users will see the name of their actual card as it says on the box rather than seeing ATI Radeon QW or similar in dialogs, etc. Take care! TTYL -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: XF4.2 and RADEON Support
On Thu, 13 Jun 2002, [EMAIL PROTECTED] wrote: Date: Thu, 13 Jun 2002 09:44:58 -0400 From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 List-Id: General X Discussion xpert.XFree86.Org Subject: XF4.2 and RADEON Support What is the current status of support (xf v4.2) in terms of an accelerated driver for the ATI RADEON cards, specifically the M6, 7500 and FireGL 7800 cards?? XFree86 4.2.0 supports the M6, 7500 however it doesn't support the FireGL 7800 out of the box. I have written a patch that adds support for the FireGL 7800 which seems to work for at least one user, however I do not have the hardware to officially test it on myself. The patch is included in Red Hat Linux 7.3 and has also been submitted to XFree86.org. You can dig the patch out of our src.rpm if you like as well, it is the following patch: # ATI Radeon Mobility M7 (LX) support - Mike A. Harris [EMAIL PROTECTED] Patch130: XFree86-4.2.0-ati-radeon-mobility-LX.patch I don't know if 3D works or not, and I haven't touched any 3D code in the above patch. If you try it out, and 3D works also, please let me know. Thanks. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Question about your DRI HOWTO
On Sat, 15 Jun 2002, Malverian ... wrote: I read your Radeon DRI Howto on ispep.cx. You stated that glxgears would give you 1180 frames per second I have followed the instructions listed here but I still get 450-500 frames per second I am using X4.2.0 and have DRM support in the kernel. I have tried 1.1.1 and 1.2.0 and have the same results. My card is an ATI Radeon 7500 DDR 64MB, and my processor is an AMD Athlon 1800+. Other information is that my system memory is 256MB DDR. I followed the instructions in your howto very carefully, I also set my AGPMode to 4x which gave a slight increase in speed. However, I am still FAR below the 1000 mark, still lingering at about 500. Any help you could give would be greatly appreciated, and thankyou for the time and effort. (Please reply via email if possible) You might also want to try the [EMAIL PROTECTED] and [EMAIL PROTECTED] mailing lists. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Gateway 1450se w/Intel 830m
I recently purchased a Gateway 1450se, which uses the Intel 830m chipset. I have compiled the kernel with AGP GART support, along with the support for the i810,i815,i830m adapters. The system BIOS has dedicated 8 megs of ram for video, but for some reason, when I use the configuration suggested by both XFree86.org and Intel, I get an error that says there is not enough memory to support the mode selected. I am having to use the vesa driver, which with 8 megs of ram, should give me up to 1024x768 resolution, but the best I can get is 640x480. I am sure this means that even though the BIOS is dedicating the proper amount of memory, the system itself is only seeing 512K or so. Does anyone have any suggestions? At this point, I am dual booting with Windows XP, but would like dump XP all together. Any help would be much appreciated. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Gateway 1450se w/Intel 830m
On Tue, 18 Jun 2002, Mike Honeyman wrote: Date: Tue, 18 Jun 2002 10:55:19 -0600 From: Mike Honeyman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii List-Id: General X Discussion xpert.XFree86.Org Subject: Gateway 1450se w/Intel 830m I recently purchased a Gateway 1450se, which uses the Intel 830m chipset. I have compiled the kernel with AGP GART support, along with the support for the i810,i815,i830m adapters. The system BIOS has dedicated 8 megs of ram for video, but for some reason, when I use the configuration suggested by both XFree86.org and Intel, I get an error that says there is not enough memory to support the mode selected. I am having to use the vesa driver, which with 8 megs of ram, should give me up to 1024x768 resolution, but the best I can get is 640x480. I am sure this means that even though the BIOS is dedicating the proper amount of memory, the system itself is only seeing 512K or so. Does anyone have any suggestions? At this point, I am dual booting with Windows XP, but would like dump XP all together. Any help would be much appreciated. There are now various laptops out there which use the Intel i830m and do not follow Intel's documentation aparently. These laptops lock-in the stolen memory to 1Mb or possibly even less, and do not allow the user to properly configure it in the CMOS settings. In these cases, it is a BIOS flaw, and Intel comments to that effect on the Intel developer site. In lieu of a BIOS update for such laptops, the only way to work around the issue is to have the video driver program the chipset directly. There was a patch floating around which claimed to fix this, however testing the patch resulted in a non working driver that did not solve the problems either. Intel has not yet released the i830 documentation to the public however to my knowledge, and so there's no way anyone can write a proper workaround. Does anyone have a contact at Intel who might be able to help out with this problem? -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: XF4.2 and RADEON Support
On 18 Jun 2002, Michel Dänzer wrote: Date: 18 Jun 2002 09:55:50 +0200 From: Michel Dänzer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 List-Id: General X Discussion xpert.XFree86.Org Subject: Re: XF4.2 and RADEON Support On Thu, 2002-06-13 at 15:44, [EMAIL PROTECTED] wrote: What is the current status of support (xf v4.2) in terms of an accelerated driver for the ATI RADEON cards, specifically the M6, 7500 2D, 3D, XVideo and dual head hardware support. and FireGL 7800 cards?? For FireGL cards ATI's binary drivers are probably the best bet. Not for this FireGL board however. ATI's binary drivers for FireGL are for the R200 hardware, specifically the FireGL 8700 and 8800, but also work with the 8500 to some degree of success. The RV200 boards are not supported by their drivers at all, at least to my knowledge. The FireGL 7800 is named FireGL, but it is basically a Radeon Mobility M7 with a different PCI ID, clocked higher. It is similar to a Radeon 7500 for all intents and purposes. I'm still interested in hearing if any Red Hat Linux 7.3 users with the FireGL 7800 have 3D working out of the box. 2D is reported to work fine. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: XF4.2 and RADEON Support
On Tue, 18 Jun 2002, Mark Cuss wrote: Date: Tue, 18 Jun 2002 08:35:47 -0600 From: Mark Cuss [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 List-Id: General X Discussion xpert.XFree86.Org Subject: Re: XF4.2 and RADEON Support This will probably sound like a stupid question, but where does one find the ATI binary drivers? I've known about and used the Nvidia ones before, but I've never seen the ATI ones (barely heard of them, actually). If someone can point me in the right direction I'd appreciate it. http://www.ati.com/support/drivers/firegl/linux/linuxfiregl8x00x420131.html Officially for FireGL 8700/8800 only, but also works experimentally on 8500. Doesn't work on other hardware. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Support for DVMT (dynamic video memory technology)?
On 11 Jun 2002, Henri Muurimaa wrote: Date: 11 Jun 2002 11:51:36 +0300 From: Henri Muurimaa [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: text/plain List-Id: General X Discussion xpert.XFree86.Org Subject: Re: Support for DVMT (dynamic video memory technology)? It is specifically a problem in the laptop's BIOS. There are Dell laptops that suffer from this shortcoming as well. So it isn't an XFree86 bug, but rather the lack of a certain feature that shouldn't need to exist in the first place if they made the laptop BIOS correct in the first place. Thats how I understand it anyway. Yes, this is how I see it as well. I contacted Intel about this, and they said that they are considering to release the needed information here: http://developer.intel.com/design/chipsets/manuals/ The person who answered my questions didn't know for sure if the specs will be released, or when. I've also tried to contact HP about this, but since only Windows is officially supported, they are reluctant to update the BIOS to include the required switch to select reserved video memory amount. If believe the XiG X server works around this issue, so it should be possible for someone familiar with the driver to add support as well given access to the necessary docs from Intel, etc. The Intel rep said that they'd rather release the spec to the public than to a select group of people with NDA's. Hope they don't decide not to release the spec... Please keep me in the CC list in replies, as I'm not subscribed to the list. Someone submitted a patch to workaround this problem a day or so ago. It is currently untested, but I am building new RPM packages for internal testing on a C400. Rawhide 4.2.0-50.17 also has the workaround in it. Again, no idea if it works or not, or if it is a proper long-term solution. Hopefully Intel will release the docs also. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Re: Radeon 8500 kernel module
On Mon, 10 Jun 2002, Kurt Wall wrote: Date: Mon, 10 Jun 2002 21:20:33 -0400 From: Kurt Wall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII List-Id: General X Discussion xpert.XFree86.Org Subject: Re: Re: Radeon 8500 kernel module [EMAIL PROTECTED] wrote: [snippage] If you go back a day or so in the list archives however you'll find a posting from Tungsten Graphics stating they're being funded by The Weather Channel to write a DRI driver for the 8500 which will be released in Q4 2002. Fascinating -- The Weather Channel? Yes, it is a television channel in the US. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Re: XIE and PEX5?
On Mon, 10 Jun 2002, Egbert Eich wrote: Date: Mon, 10 Jun 2002 11:36:26 +0200 From: Egbert Eich [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii List-Id: General X Discussion xpert.XFree86.Org Subject: Re: Re: XIE and PEX5? Mike A. Harris writes: Both XIE and PEX are obsolete, and XFree86 now disables them by default. If you need either extension, or their libraries, you need to edit host.def et al. and manually re-enable them. The only problem that we've had reported to us here at Red Hat so far due to XFree86 disabling these two items, has been an older version of Mozilla needing XIE. Any mozilla from the last year or so, no longer requires XIE. As far as I know Mozilla never called any XIE functions even in the older versions. The libXIE was just included in the list of libs to link against. It could be removed. When I disabled PEX and XIE about a year ago in our builds, Mozilla no longer worked at the time, so I re-enabled it just for Mozilla (X 4.1.0). Chris Blizzard made sure that Mozilla didn't need XIE after that, but I don't know what all was involved specifically. I did get various bug reports from Mozilla users that Mozilla no longer worked after I disabled XIE though. No bugs were reported to us for any other software though. Appearantly noone uses XIE at the moment. Hope not. ;o) Even moreso I hope nobody uses PEX. ;o) Take care, TTYL -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Radeon 8500 kernel module
On Mon, 10 Jun 2002, Fred Heitkamp wrote: Date: Mon, 10 Jun 2002 09:02:57 -0400 (EDT) From: Fred Heitkamp [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: TEXT/PLAIN; charset=US-ASCII List-Id: General X Discussion xpert.XFree86.Org Subject: Radeon 8500 kernel module I suppose every knows this, if so please ignore. I have a dual Athlon 1600+MP. I tried the 2.5.21 kernel enabled with the radeon module. My machine goes completely dead when I start X. I have a Radeon 8500. There is no Radeon 8500 DRI support currently, so thats no surprise. ;o) If you go back a day or so in the list archives however you'll find a posting from Tungsten Graphics stating they're being funded by The Weather Channel to write a DRI driver for the 8500 which will be released in Q4 2002. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Support for DVMT (dynamic video memory technology)?
On 7 Jun 2002, Henri Muurimaa wrote: Date: 07 Jun 2002 12:07:44 +0300 From: Henri Muurimaa [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain List-Id: General X Discussion xpert.XFree86.Org Subject: Support for DVMT (dynamic video memory technology)? Hello, First of all, let me thank you for all your hard work on the everybody's favourite X-window system! To my question: what are my chances to have support for DVMT, as specified here: http://support.intel.com/support/graphics/intel830m/tti004.htm in any near future? You see, I've acquired a HP Omnibook 510 with the i830 graphics chipset (which is supported by XFree 4.2.0, thank you!), but the stupid BIOS will allocate only 1M of legacy video memory for the card. Thus I can get at best only 1024x768x8bpp in X. Needless to say, the Windows driver supports DVMT, and I can get full 32-bit resolutions in XP. One way around this would be to select more video memory to be allocated in the BIOS setup. Unfortunately the BIOS does not support that, and HP seems to be unwilling to fix the problem, as Linux is not supported - which is stupid since I received the laptop from a HP event with only Linux pre-installed. Intel acknowledges the potential problem in here: http://support.intel.com/support/graphics/intel830m/tti013.htm but I've yet to receive an answer from them on who could and/or would fix the problem. Would you guys have any insights on the problem? Does the problem lie in a kernel module, or in XFree, ie. who's the party I should bug about this? It is specifically a problem in the laptop's BIOS. There are Dell laptops that suffer from this shortcoming as well. So it isn't an XFree86 bug, but rather the lack of a certain feature that shouldn't need to exist in the first place if they made the laptop BIOS correct in the first place. Thats how I understand it anyway. If believe the XiG X server works around this issue, so it should be possible for someone familiar with the driver to add support as well given access to the necessary docs from Intel, etc. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Appearance in X...
On Fri, 7 Jun 2002, Rolland Dudemaine wrote: Date: Fri, 07 Jun 2002 17:40:48 + From: Rolland Dudemaine [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed List-Id: General X Discussion xpert.XFree86.Org Subject: Re: Appearance in X... If so, wouldn't it be a good idea to make the default fonts true type ? Then, the fonts would look good by default. And basic people would not complain about this ugly font problem anymore... Of course, this should go without deprecating other font types, but that goes without saying ... That is entirely a configuration issue. Put TrueType font directories first in your font path, and then they'll be looked at first. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Problems with Kyro and XFree86 4.2
On Sun, 9 Jun 2002, David Loszewski wrote: Date: Sun, 09 Jun 2002 01:52:58 -0500 From: David Loszewski [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed List-Id: General X Discussion xpert.XFree86.Org Subject: Re: Problems with Kyro and XFree86 4.2 the vesa drivers didn't work for me, ideas? XFree86 does not have Kyro drivers. That leaves you with the binary-only drivers from PowerVR being the best option. If they do not work for you, and the vesa driver or the vga driver doesn't work either, your only real alternative is a commercial X server (if any of them support this chip). Personally, I would buy a new card that is supported before I paid money for a binary-only commercial X server though. It's probably cheaper also. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Appearance in X...
On Fri, 7 Jun 2002, Xpert wrote: Date: Fri, 7 Jun 2002 18:41:06 +1000 From: Xpert [EMAIL PROTECTED] To: Xpert mailing list [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii List-Id: General X Discussion xpert.XFree86.Org Subject: Appearance in X... Can anyone shed any light on why KDE looks so bad compared to Windows? The KDE fonts are really rough and difficult to read, particularly when they are small. I don't know that it is just just the lack of True Type fonts (although this is probably a contributing factor) as I have installed a whole bunch of Windows TTFs and it has made little difference. I have tried using True Type fonts and have checked the Anti-Aliasing for Fonts box in the KDE Control Centre, but they are still quite fuzzy compared to those in Windows. I am trying to get Red Hat 7.3 installed at my work to replace our network of aging Win95 PCs, but I just _know_ that as soon as the staff see the terrible fonts that they will reject it out of hand. I am evaluating Galeon, OpenOffice 1.0 and Evolution as that is all most of our office will need, but the appearance compared to IE, MS Office and Outlook is terrible. Can anyone offer any information/advice/website that will help me to get them a Windows-quality display? Make absolutely sure that you do not have any scaled bitmap fonts in your fontpath. By default, if you list a directory containing bitmap fonts in your font path, they will be made available both scaled and unscaled. Scaled bitmap fonts look atrocious. ie: Bad: /usr/X11R6/lib/X11/fonts/75dpi Good: /usr/X11R6/lib/X11/fonts/75dpi:unscaled Note that this only pertains to the core X fonts served by xfs or the X server itself. Check your xfs config /etc/X11/fs/config and ensure that all bitmap font directories contain the :unscaled suffix. A large majority of ugly font issues are due to this problem. Future versions of XFree86 will come with bitmap fonts defaulting to unscaled only, and require usage of the new :scaled attribute on font path elements to select the ugly scaled bitmap fonts (for compatibility with any broken apps requiring them). Another possibility is that you just do not have decent fonts installed. Out of the box, there are not a lot of Truetype fonts installed on the system. This is due to there simply being a distinct lack of freely available and redistributeable truetype fonts. As such, a default install, will give you the default few truetype and type1 fonts. You will need to install Microsoft webfonts and/or other truetype fonts from Windows or other software which you have legal license of, or download other fonts off the web. There are tonnes of free fonts out there. We would include many of them if the licencing terms allowed us to do so, however they do not. If the problem you're describing is determined to be due to something else, we'll need a lot more information, screenshots, etc. to be able to hazard a guess as to what is going wrong. Linux/XFree86/KDE/GNOME is certainly becoming a very good desktop, however it does still require a bit of tweaking ala fonts et al. before it looks reasonably like our Windows counterpart. If you're looking to avoid the Microsoft tax, and you're willing to tweak a bit (for the time being), the benefits of using Linux are well worth it IMHO. Also, there is much work being done in the area of fonts within the XFree86 community, in particular Keith Packard's Xft2 and fontconfig. I believe within 8-12 months, most of the font related headaches that are frequently problems to XFree86 users, will have become a thing of the past. Hope this helps. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Server crash with NFS root
On Wed, 5 Jun 2002, Skip Gaede wrote: Date: Wed, 5 Jun 2002 09:43:32 -0400 From: Skip Gaede [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii List-Id: General X Discussion xpert.XFree86.Org Subject: Server crash with NFS root Hi, What troubleshooting techniques are available for debugging server crashes on startup? I am using XFree 4.2.0 with the fbdev driver. I can start it without error when the filesystem is local, or if I put the same filesystem on a server, mount it RW and chroot to it. If I mount it RO (using tmpfs and symlinks ...) the driver displays about the top half of the screen and then crashes with no error indication other than Fatal server error: Caught signal 11. Server aborting. With the same NFS setup, I can startup the 3.3.6 XF68_FBDev driver. If you're using Red Hat Linux, or some other distro which is rpm based, you can take our XFree86 source RPM (src.rpm) and install it, then edit the XFree86.spec file and change the DebuggableBuild line to: %define DebuggableBuild 1 Then append dbg to the Release: line, and do rpm -bb XFree86.spec and the resultant XFree86 packages, server, modules, libs, programs, will be fully debuggable. To debug the server or it's modules, you will need to replace your currently installed GNU debugger (gdb) with the gdb available on my ftpsite: ftp://people.redhat.com/mharris/gdb-xfree86 For those using other distributions, the full source tarballs, and patches etc. should be on there as well. By looking at the XFree86.spec file you should be able to determine how to do a debuggable build in a non-rpm environment also. Hope this is helpful. Take care, TTYL -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: XIE and PEX5?
On Wed, 5 Jun 2002, Pat Suwalski wrote: Date: Wed, 05 Jun 2002 10:46:55 -0400 From: Pat Suwalski [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed List-Id: General X Discussion xpert.XFree86.Org Subject: XIE and PEX5? Hello again! Could anyone tell me briefly what happened to libpex5 and libxie between 4.1.0 and 4.2.0? They still have directories under xc/programs/Xserver, but they don't actually product the libraries anymore as far as I can tell. Thanks! Both XIE and PEX are obsolete, and XFree86 now disables them by default. If you need either extension, or their libraries, you need to edit host.def et al. and manually re-enable them. The only problem that we've had reported to us here at Red Hat so far due to XFree86 disabling these two items, has been an older version of Mozilla needing XIE. Any mozilla from the last year or so, no longer requires XIE. Hope this helps. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Radeon VE QY (PCI)
On Mon, 3 Jun 2002, Keith Gross wrote: Date: Mon, 3 Jun 2002 10:55:23 -0500 From: Keith Gross [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii List-Id: General X Discussion xpert.XFree86.Org Subject: Radeon VE QY (PCI) I have a radeon 7000 (PCI) running on my machine under XFree 4.2.0. I'm hoping to find out the state of 3D for this card. I see that the AGP version of the this card does 3D but that the PCI version only works on the Alpha platform. I searched the mailing list for the last 2 years and noticed several mentions by people that the Alpha platform code should work on Intel but I don't see indications in the code that the situation has changed. Has anyone tried the experiement of removing the #ifdefs that enable the support on Alpha and tried the drivers on Intel? If not does anybody have any suggestions if I wanted to try the experiemtn myself? After hearing a few reports from people that the Radeon PCI DRI code worked on x86, I removed the blocks which disabled the code, and built X with support for Radeon PCI DRI. Red Hat Linux 7.3 comes with this enabled. Since release however, I've gotten back 2 bug reports from users that it does not work properly for them. I don't know if it is a chipset specific issue or what it is, so I have just disabled support for it again. There doesn't seem to be many people with Radeon PCI hardware out there. It'd be a good project for someone who does have one to debug it and get it working with DRI though. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Re: Radeon VE QY (PCI)
On Tue, 4 Jun 2002, Keith Gross wrote: Date: Tue, 4 Jun 2002 20:57:06 -0500 From: Keith Gross [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 List-Id: General X Discussion xpert.XFree86.Org Subject: Re: Re: Radeon VE QY (PCI) I do most of my work on the weekends so I'll try setting this up this wekend. What would be the easiest way to get the changes you made to enable the support so I could start from there. The patch is in the RHL 7.3 XFree86 src.rpm package, as well as buried somewhere under my testing dir in my sig. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Enlightenment 16.5 on a Redhat 7.3 - Error
On Tue, 4 Jun 2002, Gregory S. Cadabes wrote: Date: Tue, 4 Jun 2002 20:49:07 -0700 From: Gregory S. Cadabes [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: multipart/alternative; boundary==_NextPart_000_000E_01C20C09.451AF9F0 List-Id: General X Discussion xpert.XFree86.Org Subject: Enlightenment 16.5 on a Redhat 7.3 - Error Hello all, I have compiled Enlightenment 16.5 on Redhat 7.3. I am running 3DFX VooDoo3. When I invoke 'startx' I get the message below: *** on 4.2.0 (Red Hat Linux release: 4.2.0-8) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 23 January 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.17-0.13smp i686 [ELF] Build Host: daffy.perf.redhat.com Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Thu May 30 22:57:06 2002 (==) Using config file: /etc/X11/XF86Config-4 (EE) TDFX(0): [dri] tdfx DRI not supported in 32 bpp mode, disabling DRI. ^^^ /usr/local/bin/enlightenment: error while loading shared libraries: libFnlib.so.0: cannot open shared object file: No such file or directory waiting for X server to shut down *** does anyone know what is going on? Your video hardware can only do 3D acceleration in 16bit depth. You've got 2 options: 1) Switch to 16 bit depth or 2) Disable DRI 3D acceleration. Note: This is a Voodoo hardware limitation, not a software limitation. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Mesa 4.0.2 by next XFree86 release?
On Sat, 1 Jun 2002, José Fonseca wrote: Date: Sat, 1 Jun 2002 08:58:33 +0100 From: José Fonseca [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Content-Type: text/plain; format=flowed; charset=ISO-8859-1 List-Id: General X Discussion xpert.XFree86.Org Subject: Re: Mesa 4.0.2 by next XFree86 release? On 2002.06.01 04:46 Alexey Dokuchaev wrote: Hi! While there is stable Mesa version (4.0.2) lying around for a pretty long time already, is there any chance for us to see it merged in XFree86 by next release? ;-P It's already on DRI CVS. Frankly, I see very little point of having Mesa3 in current version. The Mesa version included in XFree86 4.2.0 is around 3.3.x I think, but surely below 3.5.x which was the development version before 4.0. If you Mesa 3.4.2 is what has been in the last several X releases. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: use of pseudoColor in v4.2.0
On Tue, 28 May 2002, Kuiper, Luuk wrote: Date: Tue, 28 May 2002 11:05:34 +0200 From: Kuiper, Luuk [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 List-Id: General X Discussion xpert.XFree86.Org Subject: use of pseudoColor in v4.2.0 Hello fellow users of XFree86 I followed the discussions in the treads 'all color cells preallocated in pseudoColor mode in 4.2.0' and 'Allocated colormaps and 4.2.0', so I know what the problem is. But my problem is that I have to go further now with my developments. What is the best way to continue now? Shall I use a version 4.0.2? Where can I get that when I am using SuSE 7.3? Shall is export the latest version from CVS? Is that stable enough? Shall I wait for an offical release in which the RENDER built-in module is adapted? In one of the threads Keith Packard stated that Current XFree86 CVS reduces the RENDER extension's colormap appetite to a much more modest portion. What does that mean? How many colours will be available for applications? I need about 120 colours. All information and suggestions on the subject are welcome. If Render is causing problems... why not just _disable_ the Render extension entirely in your config file. Seems the simple logical workaround to me. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]ParallelMFlags issue...
When setting ParallelMFlags during build, this gets stored in the config files in /usr/X11R6/lib/X11/config/* These files get packaged up afterward with fixed ParallelMFlags set. The problem, is that when these packages are installed on another system, that system now inherits this option. So, if XFree86 was built on an 8 way system, in which -j8 was used, then other software which uses Imake for portability, will end up inheriting this -j8 flag even though the machine may be a uniprocessor machine, dual, or quad, or something else. As such the flags are correct for X during build, but not for software being built on the system the X build gets installed on. The way I ran into this, was that a particular piece of software (xpilot) would randomly fail when building. It built fine on other single and dual processor systems however. When built on a 4way or 8way box, the parallelism seems to create a race condition. The xpilot and other software obviously shouldn't have such race conditions, so that can be considered a bug in that particular software and certainly not an XFree86 bug. However, unless I misunderstand the Imake configuration, and ParallelMFlags, it probably should not propagate into the installed systems. Is this a bug in the way I am using ParallelMFlags perhaps, or is it a problem in the Imakefiles that should be addressed? -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: SWcursor with ATI Rage XL
On Tue, 28 May 2002, Brian McGrew wrote: Date: Tue, 28 May 2002 14:10:17 -0700 From: Brian McGrew [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Content-Type: multipart/alternative; boundary=_=_NextPart_001_01C2068C.11611B80 List-Id: General X Discussion xpert.XFree86.Org Subject: SWcursor with ATI Rage XL Hi folks! Quick one ... Running XFree86 4.2.0 with RedHat 7.3 on a Dell 1400SC. This machine has an ATI Rage XL card which X uses the Mach64 server for. I need to turn on the copy of SWcursor (or sw_cursor, whichever one is correct). I've looked through the docs and can't seem to manage to get this option to turn on. I've placed an 'Option' line in the XF86Config file with no luck. How do I force this option on? The reason being, is that the hw_cursor option option (default?) is eating 1k off the top of my video ram that I need. Please help. Wrong config file. You modified the 3.3.6 config. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: SWcursor with ATI Rage XL
On Tue, 28 May 2002, Kurt Wall wrote: Date: Tue, 28 May 2002 17:32:44 -0400 From: Kurt Wall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii List-Id: General X Discussion xpert.XFree86.Org Subject: Re: SWcursor with ATI Rage XL Scribbling feverishly on May 28, Brian McGrew managed to emit: Hi folks! Quick one ... Running XFree86 4.2.0 with RedHat 7.3 on a Dell 1400SC. This machine has an ATI Rage XL card which X uses the Mach64 server for. I need to turn on the copy of SWcursor (or sw_cursor, whichever one is correct). I've looked through the docs and can't seem to manage to get this option to turn on. I've placed an 'Option' line in the XF86Config file with no luck. It's a boolean option now: Option SWCursor True. Put this in the Device section, I believe. It always was boolean. And True is merely syntactic sugar and unrequired. Option HWcursor false Option swcursor Option swcursor on Option HW c u r s o R N o Option SwCuR soR Should all be treated identical by the X server as described in the XF86Config manpage. They are case insensitive and whitespace stripped. Boolean options have several ways equivalent of indicating 1 or 0. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Version conflicts
On Wed, 22 May 2002, Ruben Fritts wrote: Date: Wed, 22 May 2002 11:23:08 -0500 From: Ruben Fritts [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 List-Id: General X Discussion xpert.XFree86.Org Subject: Version conflicts I have a brand new laptop and need to install RH 7.1. The application we are running has only been developed for 7.1. So I can't upgrade to RH 7.3 like I want to. the Video Card it has is compatible. with RH 7.3 running 4.2.0 Xfree86. But not compatible with RH 7.1 Running 4.0.3 Xfree86.Can I upgrade to Xfree86 and stay with RH 7.1? I Found the upgrade/install instructions on Xfree86.org web site but only mentioned going from RH 7.2. You can upgrade XFree86, Xconfigurator, freetype, hwdata, and various other dependancies from 7.3 onto your 7.1 system. You'll first need to upgrade to the RHL 7.3 kernel and all of its dependancies however (for DRI support). Note however that while this is fairly simple to do, and should work fairly well, that it is not officially supported by Red Hat. That said, I'm running this way on two systems right now. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Where Should I Be Sending Patches?
doesn't have the resources to respond to every bug report right away, or at all in many cases, and that they should watch the Changelog for their bug to get fixed, as this allows developers to spend more time fixing bugs, and doing work on X than emailing people. Generally though, people tend to not care about that, they just expect to get an acknowledgment, and they seem discouraged when they don't get it. I get this sometimes even _with_ bugzilla. So I understand the difficulty involved with responding to every single bug report. The problem with our bugzilla though, is that we do not have expertise in all of the areas bugs are reported. Also, we do not support every tiny piece of XFree86 100%, so many issues reported are considered by us to be low priority and/or WONTFIX. In these cases, I recommend to people to report the bug upstream to [EMAIL PROTECTED] and/or [EMAIL PROTECTED] in hopes the maintainer will fix it, or at least that more people who could potentially fix the bug are looking at it. Since I am also on the receiving end of XFree86 bug reports (via our bugzilla, with emails sent to me upon new bug report submissions and updates), I know the volume of incoming reports can be a bit staggering, and that many are bogus and/or user misconfiguraton issues, or people just looking for free-ride tech support. However, for both bug reports, and for patches/fixes, I strongly feel that the administrative overhead that bugzilla would require would be small compared to the service that it provides, the patches it harvests into one common place, and to the two-way communication mechanism it would establish between X users, the XFree86 core team, and other XFree86 developers like myself. Red Hat used to deal with bug reports via email a long time ago as well. The problem with it was that it was not scalable, it did not allow a good two-way communication between bug reporter and bug fixer(s), and it did not allow for bug tracking, co-ordination, or allow for searching for already reported bugs, and their solutions/workarounds. Also, the details of a user's given bug report could easily be lost in email, or forgotten entirely. Developers can't keep track easily of what issues are being worked on by other developers. Bugzilla IMHO would allow more people who are not on the core team to be aware of more of the bugs that are being reported, and would result in more people fixing more bugs. People often come to me and express an interest in working on X, but don't know where to start or what to work on. I refer them to our bugzilla, as there isn't a way they can find out about bugs at XFree86.org currently. Some tell me I don't use Red Hat, somehow thinking that all XFree86 bugs in our bugzilla are specific to Red Hat Linux, others not wanting to contribute code that does Red Hat's job for them like somehow fixing every bug reported is our job. I would much rather be able to point people at a central bugzilla tracker on XFree86.org, and to be able to consolidate non-distribution specific bug reports in one place, which will remove some level of duplication among all distributions, and including the core team itself. This topic has come up before on private XFree86 mailing lists, and I've also discussed it a bit with Keith Packard (whom I've added to the CC) and Jim Gettys. Keith set up bugzilla a while back to investigate it, and I've poked around a bit locally with it as well. I dunno how far he's gotten with it, but I havn't had much time to dig into it, and I presume he hasn't either. Almost all major projects out there (Mozilla, GNOME, KDE, etc.) have a web based bug tracker, and most of the larger projects use bugzilla for the large number of features that it has that cater to large projects like XFree86. I think XFree86 really needs a bugzilla bug tracker in order to harvest the wealth of developers that are out there that currently see X as a black art, or a mysterious voodoo tarball. Lets make XFree86 development, and bug fixing more scalable, and pool the community of developers and users together. Lets work together to put up a bugzilla bug tracker on XFree86.org and use it as the primary tracker of bug reports. I think that would benefit everyone, and most importantly the end user. TTYL -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Where Should I Be Sending Patches?
On Tue, 14 May 2002, Dr Andrew C Aitchison wrote: -- From xc/programs/Xserver/hw/xfree86/doc/README: 3.4 Xpert If instead you are the lone developer who is improving XFree86 on an ad hoc basis for your particular environment (I want to get my mouse or video card to work), and need a specific question asked then you should go over to our Xpert list where such questions are raised and answered by our technical development staff. Remember you do not have to be a member to write fixes to our code base and if your changes are discrete and self-contained the volume of developer mail may just be too noisy. Once your work is finished (coded, debugged and documented) please send your fix to [EMAIL PROTECTED]. This will ensure that they are included in future releases. And thanks! You make this truly an Open group. To be truely open, it needs to be viewable/queryable by members of the community, and trackable. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]RE: Where Should I Be Sending Patches?
On Tue, 14 May 2002, Dr Andrew C Aitchison wrote: There are about a handful of people who see these patches, I'm not sure that any of them are paid to work on XFree86, so you are asking a volounteer developer to spend time understanding someone else's patch (including the issues involved) and then do the boring administrative stuff of integrating it. Indeed, and it is understandable that volunteer work can only accomplish so much in a given amount of time. I think the problem is not that patches/fixes don't get integrated instantly, but rather that there is no two way communication mechanism present. An automated system can help with this. I think code cutting is fun, but I wouldn't enjoy integrating patches. I also agree with that. When a bug report comes into bugzilla, once I am looking into the issue, I have the bug number on hand, and have it open in a web browser. Once the fix is applied - either included with the bug report, or whipped up or from elsewhere, I can then make a comment in the report which takes virtually zero time/effort fixed in 4.2.0-9 in rawhide, please reopen if the problem persists or somesuch, and click CLOSED-RAWHIDE or some other resolution that is fitting. The end user receives an email on this, as do any other people who have added themselves to the bug CC list, informing them the issue is resolved. It takes me no more time to do this, than it would to read an email, fix a bug, add a changelog entry. I think the gains it brings far outweigh any /perceived/ disadvantages by far. If I were running a large project on a volunteer basis, I would definitely use bugzilla to manage it, as it saves time, rather than requiring more time. If all projects using bugzilla didn't result in more being done in less time, by those same volunteers they likely wouldn't use it at all IMHO if it just created more work. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]RE: Where Should I Be Sending Patches?
On 14 May 2002, Michel Dänzer wrote: This is all very well, but i sent patches to [EMAIL PROTECTED] nearly 3 weeks ago and i've had nothing back apart from an automatic response! does *ANYONE* read it? There is another list for registered developers to submit patches, and the turn around can be as bad as that, although I would usually expect to see my changes in CVS within 2 weeks. You're lucky. Now that Red Hat 7.3 ships 4.2, I get private mail about a problem in the r128 and radeon drivers for which I submitted a fix (#5199) on March 9th, without any response yet... Bummer, I didn't see that fix, and so didn't apply it to our package. I've just applied it to my development build however. If this was on a public bugzilla tracker on XFree86.org for example, there's more likelyhood of more widespread testing/feedback occuring, as well as those interested in the specific bug being able to opt-in on receiving updates to that bug report, including good/bad feedback from those who have tested it and confirmed it to work, or found it to not work. Distribution maintainers querying for bug reports, could find the issue, the patch, the collaborative bug tracking details from people who have tried the fix, and can communicate among those affected, and other developers working on the issue more readily. As it is now, to find it, you have to be an XFree86.org member, and read every incoming email, hoping not to misplace one, and/or exercise your MUA search feature to hopefully find fixes submitted by others. No multi-way communication mechanism is really present or easily possible. There are about a handful of people who see these patches, I'm not sure that any of them are paid to work on XFree86, so you are asking a volounteer developer to spend time understanding someone else's patch (including the issues involved) and then do the boring administrative stuff of integrating it. I think code cutting is fun, but I wouldn't enjoy integrating patches. There are certainly more interesting things, but I'd be willing to do a share if I get a chance. As would I as time permits. I think the number of I would too's present would be large enough to make it quite beneficial to the project overall. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: i810 chipset
On Wed, 15 May 2002, Bertoldi Andrea wrote: I've just recompiled the kernel of my Linux system, and X does not work anymore. But some details more: 1. my system runs a RedHat7.1 with kernel release 2.4.2 and XFree86 version 4.0.3 without problems. Those are both ancient releases. You should update your kernel and XFree86 to the currently released erratum packages for Red Hat Linux 7.1 2. I compiled the 2.4.9 kernel with RTAI-2.4.6a patch Now the system works, except for graphic interface. In what follows I added the full ouput of the X server, when invoked by startx from runlevel 3. Keep in mind, recompiling your kernel, especially with external patches can cause problems. Make sure if you experience problems that they are not due to your customizations. One thing more: I looked on intel site, as regarding with my chipset. I tried without success what they suggest to do with the two rpm files that can be downloaded ( i810gtt-0.2-4.src.rpm and xfcom_i810-1.2-3.i386.rpm). That stuff is totally ancient and should not be used. (WW) AGPIOC_ACQUIRE failed (Device or resource busy) (EE) GARTInit: AGPIOC_INFO failed (Invalid argument) Looks like you don't have AGPgart support compiled. Symbol VBEInit from module /usr/X11R6/lib/modules/drivers/i810_drv.o is unresolved! Symbol vbeDoEDID from module /usr/X11R6/lib/modules/drivers/i810_drv.o is unresolved! Ancient bug, long since fixed in newer releases. (0): [drm] drmSetBusid failed (5, PCI:0:2:0) (EE) I810(0): DRIScreenInit failed DRI can't start if AGPgart isn't loaded. If I'm not mistaken, the Intel chipsets require AGP support wether or not you actually use DRI. Someone will correct me if I'm wrong. You can try to disable DRI as well and test to see if it works or not. Hope this helps. TTYL -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Where do you send specs to upgrade the monitor database.
On Wed, 15 May 2002, Paul Elliott wrote: Date: Wed, 15 May 2002 17:44:08 -0500 From: Paul Elliott [EMAIL PROTECTED] To: Xpert Xfree86 mailing list [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary=Dxnq1zWXvFF0Q93v Subject: Where do you send specs to upgrade the monitor database. There used to be something called the monitor database. Where do you send the specs of your monitor that is not recognized by XF86cfg? Thank You. I maintain the MonitorsDB database. The entries are added from Microsoft Windows .INF files. The best way to have them added, is to file a bug report in Red Hat bugzilla against XFree86 or Xconfigurator and attach the .INF file for your specific monitor, or a manufacturer's line of monitors. I generally let them save up for a bit, then hunt bugzilla for them all and gang apply them all at once. I'd also like to make a note that anyone else is free to take this Monitor database and use it under GPL license or XFree86 license. The XFree86 team can include it in XFree86 directly as well if that is useful. I'd even volunteer to maintain it there as well. Hope this helps. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Voodoo 3 and 4.2.0
On Wednesday, May 8, 2002, Cory Lueninghoener [EMAIL PROTECTED] wrote: Ok, so I am a fool and didn't actually attach the files I claimed I would. There they are now... On Tue, 7 May 2002, Cory Lueninghoener wrote: Well, after a day of fiddling on and off I still have had no luck. Attached to this piece of mail are the server logs and outputs of glxinfo for both 4.1 and 4.2, in case anybody wants to take a look. Part of the problem may indeed be the fact that it doesn't look like the tdfx kernel module is getting loaded, but even when I load it myself it doesn't work. The XFree package I installed was actually the one that is shipped with Red Hat 7.3, so I am beginning to suspect their build is flawed (as I have read stuff on google searches making it sound like things are working for other people). Sometime soonish I will see about getting a clean build of XFree done on my own and see how things work. Either way, though, that error message _is_ coming from someplace, so I ponder it's meaning when other people sound like things work for them. On 7 May 2002, Mike wrote: On Tuesday, May 7, 2002, Cory Lueninghoener [EMAIL PROTECTED] wrote: I just grabbed a copy of XFree86 4.2.0 and installed it, and afterwards when I tried running some OpenGL stuff at 1280x1024 I saw no sign of acceleration. So I took a look at /var/log/XFree86.0.log and saw this line: (WW) TDFX(0): [dri] To use DRI, with a 16Mb Voodoo 3 or Banshee card, you must invoke the server using a maximum resolution of 1024x768 or lower. This confuses me greatly, as it had worked perfectly fine at that resolution with 4.1. Did something major change between the two versions? Or is there something I am overlooking? For reference, here is some random extra information: OS: Red Hat Linux 7.2 i386 (Kernel 2.4.18) Video card: 3dfx Voodoo3 3500 XFree86: 4.2.0 Any help on getting things working again in 3d accelerated mode would be greatly appreciated. Thanks, -- Cory Lueninghoener http://www.thepests.com/~cluening Perl, C, Linux Hackerhttp://labs.thepests.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert 4.2.0 works fine at 1280 x 1024 with my Voodoo 3 and games will run with no problems so far. Have you checked your server log to see if the tdfx.o kernel module has loaded? What does glxinfo say? Have you tried compiling the new kernel module that is hidden in the depths of the 4.2.0 source tree? Michael. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert -- Cory Lueninghoener http://www.thepests.com/~cluening Perl, C, Linux Hackerhttp://labs.thepests.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert -- Cory Lueninghoener http://www.thepests.com/~cluening Perl, C, Linux Hackerhttp://labs.thepests.com Well its like the Redhat guy said he's disabled the DRI for desktop resolutions above 1024x768 so you might want to download and compile XFree86's official source for 4.2.0 because I have done a bit of weekend testing and Quake was fragging all through the night with it at 1280x1024 (@20fps) with a desktop resolution of 1280x1024 so Redhat must have broken their setup with one of their patches. I'll continue testing through the week with Wolfenstein. Michael. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Unresolved symbols in Xserver startup
On Sun, 12 May 2002, Axel H. Siebenwirth wrote: XFree86 Version 4.2.99.1 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: xx January 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.19-pre8-ac2 i686 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Sun May 12 20:04:24 2002 (==) Using config file: /etc/X11/XF86Config (==) ServerLayout Layout[all] (**) |--Screen Screen[0] (0) (**) | |--Monitor Monitor[0] (**) | |--Device Device[0] (**) |--Input Device Keyboard[0] (**) Option Protocol Standard (**) Option AutoRepeat 200 35 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc104 (**) XKB: model: pc104 (**) Option XkbLayout de (**) XKB: layout: de (**) Option XkbVariant nodeadkeys (**) XKB: variant: nodeadkeys (==) Keyboard: CustomKeycode disabled (**) |--Input Device Mouse[1] (WW) The directory /usr/X11R6/lib/X11/fonts/URW does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/kwintv does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/uni does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/misc/sgi does not exist. Entry deleted from font path. (WW) The directory /usr/X11R6/lib/X11/fonts/xtest does not exist. Entry deleted from font path. (**) FontPath set to /usr/X11R6/lib/X11/fonts/misc:unscaled,/usr/X11R6/lib/X11/(**) RgbPath set to /usr/X11R6/lib/X11/rgb (**) ModulePath set to /usr/X11R6/lib/modules (**) Option AllowMouseOpenFail (**) Option Xinerama off (--) using VT number 7 (WW) Open APM failed (/dev/apm_bios) (No such device) (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a Not loading .rodata.str1.1 Not loading .rodata.str1.32 Not loading .rodata.cst8 Not loading .rodata.str1.1 Not loading .rodata.str1.32 Not loading .rodata.str1.32 Not loading .rodata.str1.1 Not loading .rodata.cst8 Not loading .rodata.str1.32 Not loading .rodata.str1.1 Not loading .rodata.str1.32 Not loading .rodata.str1.1 Not loading .rodata.str1.32 Not loading .rodata.str1.32 Not loading .rodata.str1.1 Not loading .rodata.str1.32 Not loading .rodata.str1.1 (II) Symbol from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved! Symbol from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved! (this last line is repeated about 250 times!) *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. Fatal server error: Caught signal 11. Server aborting -- Then I tried to scan the pci bus..: Not loading .rodata.str1.1 Not loading .rodata.str1.32 Segmentation fault New versions of the gcc compiler have an optimization called string merging which is enabled by default. The XFree86 module loader chokes on the ELF sections that this optimization adds to the ELF objects. To work around this XFree86 module loader limitation, you need to pass -fno-merge-constants to the linker when modules are being built. This can be done from host.def with: ModuleLdFlags -fno-merge-constants This was automatically detected in later 4.1.0 CVS, and also in 4.2.0 CVS however it looks like someone removed the automatic checks in head CVS. The above #define must be set as above when compiling with all newer versions of gcc 3.x, as well as gcc 2.96. Hope this helps, TTYL -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: Re: Re: Re: Voodoo 3 and 4.2.0
On Thursday, May 9, 2002, Mike A. Harris [EMAIL PROTECTED] wrote: On Thu, 9 May 2002, Frank Van Damme wrote: Might not sound insane, but the bare fact is that it does not work in XFree86. I could care less personally if it ever does, as it is obsolete hardware. I only care that XFree86 does not crash. If nobody else is interested in fixing it either, then I believe the X/DRI sources should detect this problem and disable it by default as I have done, unless we now consider it ok for the X server to crash for no reason other than it being configured in a way that the drivers do not support currently. Not as obsolete as you think. Untill a few months ago I ran a voodoo3 3000 That depends on your definition of obsolete. Obsolete does not mean non-existant, nor not-in-use-anymore. Obsolete, means that the company that manufactures the product no longer supports it. In the case of the Voodoo hardware, it means that the company that used to manufacture the hardware does not exist anymore. Since they do not exist, there is no interest in anyone funding the development of this technology. As such, it is considered obsolete. That doesn't mean that you should throw away the hardware, nor that someone who has a personal interest in hacking on the drivers should not do so. I encourage anyone who is interested in hacking on the tdfx drivers to add support or fix bugs to go ahead and do so, and if I can help out in some way, I'll certainly try to answer any questions I can if I'm familiar with the particular area of inquiry. I'm sure any other developers would also be willing to help someone interested in hacking on X. Just keep in mind that while this is all perfectly good working hardware, that it is ultimately several generations old now compared to modern hardware, and that it is considered obsolete. for playing quake which is bearable @ 920*7something. Still it would make no sense to run it @1600*1200 (no question) so you're using OR dri, OR desktop@1600*1200. Conclusion: no problem at all. I agree with that. But some people out there do want to use 1600x1200 on such hardware that is 3 or more generations old. If the drivers were reprogrammed to actually work under those constraints, I believe the 3D would be so slow that software GL would not be much slower. Nonetheless, people want to do it if they can. As a general guideline of what is realistically possible with such hardware, one might try Windows, and see what 3D video modes are available on these cards in Windows while running a 3D game. Whatever windows can do with the 3Dfx drivers, it is theoretically possible that X can do also. However in addition to the problems in the current driver, there is an additional problem that XFree86 can't reclaim video memory used by 2D. Unless this has changed and slipped by me recently. I think if someone were to fix the drivers, that 1280x1024 might be possible, but I doubt much beyond that could run stable in 3D. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert So youre saying that Windows is better than Xfree86 and us Voodoo 3 owners should go back to using it to get the most from our cards? I would only say that the Voodoo 3 is 2 generations old if you look at from a memory timing/core clock speed point of view rather than an Nvidia new chip with not widely used features and larger heatsink every 6 months point of view. I'll test my card out with Quake 3 and Unreal Tournament this weekend to see how it fares. Michael. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: Re: Re: Voodoo 3 and 4.2.0
On Thu, 9 May 2002, Michael wrote: High resolution video requires a lot of video memory. DRI requires approximately four TIMES that much video memory to work properly. However, people are using insane high resolutions like 1600x1200 and using DRI, then running Wolfenstein 3D, and it crashes. Hmm, gee... I wonder why. Perhaps because the voodoo3 will happily run at these resolutions? Doesn't sound insane to me. Might not sound insane, but the bare fact is that it does not work in XFree86. I could care less personally if it ever does, as it is obsolete hardware. I only care that XFree86 does not crash. If nobody else is interested in fixing it either, then I believe the X/DRI sources should detect this problem and disable it by default as I have done, unless we now consider it ok for the X server to crash for no reason other than it being configured in a way that the drivers do not support currently. I am interested in hearing the opinions of DRI and XFree86 project members on the this particular issue with the tdfx driver. I have a feeling however that the DRI developers favor stability, reliability, and security over driver features, supported resolutions and the like. If someone wants to modify a driver and use it in a known unstable manner, and they're lucky enough to not trigger problem behaviour, or to trigger it infrequently enough that it doesn't bother them, that is their perogative. But it is not acceptable IMHO to knowingly ship a driver which crashes, and for which the reason for the crash can be easily fixed or worked around by detecting problem configurations and disabling features known to be unstable. If someone wants to see this problem fixed in a better way than just being worked around by disabling the known problematic configuration, then it is a good project for someone to work on as a personal itch to scratch, and to ensure that the tdfx drivers continue to function and to access as many features of the hardware as possible. Unmaintained drivers eventually become non-working drivers, and eventually become completely disabled drivers. As hardware becomes older, and nobody is funding development of the code, there is less and less incentive to fix bugs in the code, when there are fixed amount of human resources available, and newer drivers for more modern hardware have their own fare share of bugs needing fixing. It makes the most sense to spend resources first on the modern hardware, and much lower priority on the older hardware. It is in these situations when the open source development community needs to step in and scratch their personal itch by hacking on code and contributing it. Not unlike the Linux kernel's own developmental processes. Fortunately, due to the good work that the DRI guys, and others have done in the past on the tdfx drivers, they are in fairly good shape now. This one problem is the only major problem that pops up now that I can think of on Voodoo 3/Banshee hardware. If someone is interested in solving this for real, let me know, and I will put the Voodoo 3 specs up and provide a URL to them. Also, it would be a good idea to join the #dri-devel meetings on irc.openprojects.net on Mondays at 4pm EST to discuss how one might go about finding/fixing the problem. I'm sure that Daryll Strauss, and others who have worked on this code before, will be glad to help out anyone interested by providing pointers. But until such bugs are truely fixed, stability trumps whiz-bang. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]3Dfx Voodoo 3, Banshee, Voodoo 1/2, and Voodoo Rush technicalspecifications
Anyone who might be interested on enhancing the XFree86 tdfx video driver, for 2D or 3D, or other functionality, will likely require the technical specs for the cards. The specs for all of these cards can be found in PDF format at the URL below. http://www.medex.hu/~danthe/tdfx/ Hopefully this information will be useful for some would be X hackers out there who have the hardware and would like to enhance support and/or fix bugs. I thought by providing links to the docs, it might help one get further along. Hope someone finds them useful. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
