[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 >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: 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: 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 >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 >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: 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 >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: 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 >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: 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 >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: 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 >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: 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: Re: CVS Build Failing
On Mon, 9 Dec 2002 [EMAIL PROTECTED] wrote: >> >Aargh. I'm still having trouble getting CVS to build because of the >> >new XFixes stuff. Here's my host.def >> [SNIP] >> > >> >I get this error even after removing build/xmakefile and re-executing >> >"make World". build is a shadow directory created using lndir. Could >> >someone kindly hit me with a clue bat? Thanks. >> >> At a glance it looks like your CVS checkout is not clean. I'd >> recommend doing a fresh checkout and try again. > >Hmm. I wonder how that happened? A fresh checkout was next on my list, >but I was trying to save bandwidth and avoid that. In any event, a >fresh checkout seemed to solve the problem. Thanks, Andrew and Mike. Using cvsup instead of straight cvs is a better way of saving bandwidth. You might want to consider giving it a whirl too. It's a very useful tool. Take care, 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: CVS Build Failing
On Mon, 9 Dec 2002 [EMAIL PROTECTED] wrote: >Aargh. I'm still having trouble getting CVS to build because of the >new XFixes stuff. Here's my host.def [SNIP] > >I get this error even after removing build/xmakefile and re-executing >"make World". build is a shadow directory created using lndir. Could >someone kindly hit me with a clue bat? Thanks. At a glance it looks like your CVS checkout is not clean. I'd recommend doing a fresh checkout and try again. -- 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 >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: 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: 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 >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: 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
[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
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 InputDevice"Mouse0" "CorePointer" InputDevice"Keyboard0" "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 co
[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
[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]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
Re: [Dri-devel] Re: [Xpert]Re: Probable return of Radeon, R128XFree86 crash at VT switch
On Thu, 17 Oct 2002, Marc Aurele La France wrote: >> 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. > >The question on my, and David's, mind is whether or not bus mastering was >enabled on server entry. I can't say for every reported case, but I can say that on the cases I examined personally, that the video hardware had Bus Mastering enabled prior to the X server being started (lspci -vvv), as well as while the X server was running. Switching to a VT and doing lspci -vvv then showed bus mastering disabled. I witnessed this on 3 different systems personally, and via testing feedback from various users got similar responses back. Not sure if all systems were this way, but some were at least. For the current CVS code, I don't know if the problem is present or not. I've disabled Charl's patch for now in order to have the stock code well tested. Our kernel hasn't been updated with the latest DRM source however, so testing hasn't begun yet. Sometime in the next couple weeks I'll likely have our kernel DRM updated, and bang on the Radeon a bit. If the problems recur, I'll try out Charl's patch again, and possibly do a debug session with Charl and MrCooper again if they're game. Has anyone else already tested it for hanging? TTYL -- Mike A. Harris ___ 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]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]Help needed - 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]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
Re: [Xpert]XML format for XF86Config
On Mon, Sep 30, 2002 at 12:00:22PM -0700, Andrew P. Lentvorski wrote: >On Mon, 30 Sep 2002, Michael Michael wrote: >> after 1990... Note these arguments are the standard >> anti-xml arguments given by most idots.. (Sorry but this is a reply moreso to the original that I deleted without thinking... but, on further thought I had to say something.) I don't post here much if at all, but uh... Would you rather be told: "Find the line that says 'Option "Protocol" "IMPS/2"' and change it to "PS/2"? or: "Wade through this arcane XML format to something that says "IMPS/2", hope you have the right place, and change it to "PS/2"." ? As annoying as the amount of trouble it CAN (not is.. and I've changed monitors and graphic cards 4 times on one machine, and set up 7 others since 4.2 came out) be to get X up and running, it's been INFINITELY easier because the format is just like it is... plain, simple, easy to understand that is, unless you're an idot(whatever the hell an idot is) who can't read some docs and manpages. -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]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: 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]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
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: 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
[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
#include
#include
#include
#include
#include
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:
XkbRules"xfree86"
XkbModel"pc102"
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 {[ dead_grave, dead_tilde ],
[ grave, asciitilde ] };
key {[ 6,dead_circumflex ],
[ asciicircum, asciicircum ] };
key {[ dead_acute, dead_diaeresis ],
[ apostrophe, quotedbl] };
key {[ 9,parenleft ],
[ dead_breve, dead_breve ] };
key {[ 0,parenright ],
[ dead_abovering, dead_abovering ] };
key {[ minus,underscore ],
[ dead_macron, dead_belowdot ] };
key {[ equal,plus],
[ dead_doubleacute,dead_horn ] };
key {[ semicolon,colon ],
[ dead_ogonek, dead_diaeresis ] };
key {[ comma,less],
[ dead_cedilla,dead_caron ] };
key {[period,greater ],
[ dead_abovedot, dead_circumflex ] };
key {[ slash,question],
[ dead_hook, dead_hook ] };
// End alphanumeric section
};
___
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]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
[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
[Xpert]Re: Floating point exception in Radeon driver at 1400x1050
On Sun, 11 Aug 2002, David D. Hagood wrote: >Date: Sun, 11 Aug 2002 09:03:20 -0500 >From: David D. Hagood <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Reply-To: [EMAIL PROTECTED] >Content-Type: text/plain; charset=us-ascii; format=flowed >Subject: Re: Floating point exception in Radeon driver at 1400x1050 > >Mike A. Harris wrote: > >>>According to earlier Xpert posts, it also happens with 1600x1200. >> >> >> Hmm. I'm using 1600x1200 on my one machine all the time.. > >It seems to be related to the available monitor scan rates - if I >configure my monitor for a maximum horizontal scan rate of 85 kHz, I get >the fault, but if I configure it for 80 kHz, I don't. > >Perhaps there is a numeric overflow somewhere? Hmm, this info should be very useful in debugging.. Thanks. 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
[Xpert]Re: Continuing Radeon DRI problems
On 3 Aug 2002, Angus Wallace wrote: >I'm still having problems, and am thinking that some more detailed >information would be in order. > >I'm running Redhat 7.3 with the 2.4.18-3 kernel that comes with it. I've >recompiled that with AGPgart support, and modular support for DRI on the >Radeon. I've then downloaded the DRI drivers, and installed them. The Red Hat kernel comes with agpgart and drm support both modular already. Unless you were using the i386 kernels, which DRI is incompatible with, you shouldn't need to recompile anything. >I've looked at the 'DRI user guide', and checked for things like the >presence of the driver, using lsmod, and looking in the log file created >by X, DRI is enabled. Similarly, glxinfo says that it is enalbed, also. > >Does this mean I have a 'dud' VE that hangs on the current DRI code? >(with TCL added.) Radeon VE doesn't have a TCL engine IIRC. If it weren't for C, we'd all be programming in BASI and OBOL. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Re: [Dri-devel] Floating point exception in Radeon driverat 1400x1050
On 11 Aug 2002, Michel Dänzer wrote: >On Sun, 2002-08-11 at 12:04, Mike A. Harris wrote: >> There is an easily reproduceable FPE in the Radeon driver at >> a resolution of 1400x1050. > >According to earlier Xpert posts, it also happens with 1600x1200. Hmm. I'm using 1600x1200 on my one machine all the time.. perhaps it is card specific.. I'll have to check that out as well... >> I'm just beginning to debug it, but wondered if anyone else has >> encountered this and might already have a solution. > >Have you tried the XFree86 CVS trunk? Not yet, but I'll have a look through the cvs commits. Thanks TTYL ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Floating point exception in Radeon driver at 1400x1050
There is an easily reproduceable FPE in the Radeon driver at a resolution of 1400x1050. I'm just beginning to debug it, but wondered if anyone else has encountered this and might already have a solution. Program received signal SIGFPE, Arithmetic exception. 0x085abcdf in RADEONDiv (n=2648700, d=0) at radeon_driver.c:700 (gdb) bt #0 0x085abcdf in RADEONDiv (n=2648700, d=0) at radeon_driver.c:700 #1 0x085b34bd in RADEONInitDDARegisters (pScrn=0x84d4860, save=0x8450348, pll=0x844fa28, info=0x844f998) at radeon_driver.c:4104 #2 0x085b375d in RADEONInit (pScrn=0x84d4860, mode=0x85f1088, save=0x8450348) at radeon_driver.c:4234 #3 0x085b3831 in RADEONModeInit (pScrn=0x84d4860, mode=0x85f1088) at radeon_driver.c:4266 #4 0x085b01f4 in RADEONScreenInit (scrnIndex=0, pScreen=0x86aa558, argc=1, argv=0xbaf4) at radeon_driver.c:2512 #5 0x080e4365 in AddScreen (pfnInit=0x85b00c4 , argc=1, argv=0xbaf4) at main.c:768 #6 0x0806ecd7 in InitOutput (pScreenInfo=0x82427e0, argc=1, argv=0xbaf4) at xf86Init.c:819 #7 0x080e35c5 in main (argc=1, argv=0xbaf4, envp=0xbafc) at main.c:380 #8 0x400861f6 in __libc_start_main (main=0x80e32b0 , argc=1, ubp_av=0xbaf4, init=0x806c9a0 <_init>, fini=0x81e7220 <_fini>, rtld_fini=0x4000cfe8 <_dl_fini>, stack_end=0xbaec) at ../sysdeps/generic/libc-start.c:129 This is in xf-4_2-branch -- 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]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 >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
[Xpert]RE: XftConfig is ignored
On Mon, 29 Jul 2002, Balarama Chandra N R wrote: >Date: Mon, 29 Jul 2002 12:03:59 +0530 >From: Balarama Chandra N R <[EMAIL PROTECTED]> >To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> >Content-Type: text/plain; > charset="iso-8859-1" >List-Id: General X Discussion >Subject: RE: XftConfig is ignored > >Just sharing a thought, If you are not running a font server I don't think >this XftConfig file will be used, as u said check out in cf files >xc/config/cf and also in xf86site.def/host.def to see if font server is been >created at the time of compilation of XFree86. The font server does not use XftConfig at all. XftConfig is the config file in XFree86 4.2.0 for Xft. It is configuration of client side fonts, and completely unrelated to the font server (which serves server side fonts). >DISCLAIMER: Information contained and transmitted by this E-MAIL is >proprietary to Mascot Systems Limited and is intended for use only by the >individual or entity to which it is addressed, and may contain information >that is privileged, confidential or exempt from disclosure under applicable >law. If this is a forwarded message, the content of this E-MAIL may not have >been sent with the authority of the Company. If you are not the intended >recipient, an agent of the intended recipient or a person responsible for >delivering the information to the named recipient, you are notified that any >use, distribution, transmission, printing, copying or dissemination of this >information in any way or in any manner is strictly prohibited. If you have >received this communication in error, please delete this mail & notify us >immediately at [EMAIL PROTECTED] Before opening attachments, >please scan for viruses. Such disclaimers do not actually serve any useful purpose other than consuming bandwidth unnecessarily. -- 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: XftConfig is ignored
On Sun, 28 Jul 2002, Paul Hoepfner-Homme wrote: >Date: Sun, 28 Jul 2002 22:16:16 -0400 >From: Paul Hoepfner-Homme <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Content-Type: text/plain; > charset="us-ascii" >List-Id: General X Discussion >Subject: XftConfig is ignored > >Hello, > >I've been trying to figure out why I can't enable sub-pixel antialiasing with >my Radeon card in XFree86 4.2.0 (actually the DRI CVS branch), and I've now >concluded that it's because no XFT configuration files are ever being read. > >I have the file /usr/X11R6/lib/X11/XftConfig with a bunch of font directories >and match settings listed, including the line "match edit rgba = rgb;" to >enable sub-pixel antialiasing. That line didn't seem to have any effect (nor >did changing it to bgr, vrgb, or vbgr). So I also added the line "match edit >antialias = false;" to the file just to see if the file was even being read. >I then ran "xterm -fa 'lucida console' -fs 10", expecting fonts not to be >antialiased, but they still were! > >So then I tried setting XFT_CONFIG to /usr/X11R6/lib/X11/XftConfig, but that >made no difference. I can't get XFT to use the settings in XftConfig. > >Anyone have a clue why XftConfig isn't being used? Do I have to enable some >option before compiling XFree86 to say that I want to be able to use an >XftConfig file? DRI-CVS might be using the new Xft code. If so, then XftConfig is obsolete, having been replaced by fontconfig. -- 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 >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
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
[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
[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
>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:[]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 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
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:[]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 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:[]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:[]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
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:[]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: [] [] [] [] []
kernel:[kswapd_balance_pgdat+67/140] [kswapd_balance+18/40] [kswapd+153/188]
[kernel_thread+40/56]
kernel:[] [] [] []
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
Trace; c012b077 <__free_pages+1b/1c>
Trace; c012a0ab
Trace; c012a2c0
Trace; c012a32c
Trace; c012a3c3
Trace; c012a41e
Trace; c012a52d
Trace; c0105478
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:GeForce2 MX/MX 400
IRQ: 5
Video BIOS: 03.11.01.37
-- PCI Only ---
--
Windows has detected that you have moved your mouse.
Your system must now be r
[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 >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: 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 >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: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, 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 >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: Re: Is the XFree development stuck in a dead end?
On Tue, 16 Jul 2002 [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. >> >> 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. > > :-) > > I wan't to stop someday and write code for a better multihead configuration >interface in the textmode (currently it just adds new screens to the left of >the last one). For the graphics interface, I plan to write a wizard mode, >similar to the text interface. And also, make this wizard mode allow configuring >everything without the need of a working mouse; curently if the mouse does >not work, it is required to use xkb mousekeys, and this really is not user >friendly :-) > > Anyway, the code is there, and I don't mind if someone uses part (or all) of >the xf86cfg code in a Gtk or Kde interface. I just think that any such code >should use libxf86config, so that if it reads an existing XF86Config file, >when writing a new one, does not miss any information from the previous >configuration file (in the current libxf86config, comments may be rewritten out >of order, but are not lost). Our current tool under development is using libxf86config exactly for the reasons you suggest. ;o) It made no sense to reinvent the wheel. Those wishing to try the tool out, and comment about it, please do! redhat-config-xfree86 is the name of the tool/package and it is currently in rawhide. It is written in python/C and uses GTK+. All feedback and suggestions would be greatly appreciated. I'd like to see the tool enhanced over time to be a very user friendly tool for both GNOME and KDE users, and potentially users not using GNOME or KDE as well. Any requests for enhancement, etc. should be filed in bugzilla preferably also. Thanks for libxf86config! -- 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?
e been trying to join the XFree86 >developer team but after all this time this process still didn't >finish... and every now and then one reads threads about how the XFree86 >developers can't cope with the number of patches and feature requests... Well, I'd be surprised if you would be rejected from joining the XFree86 member development team after your current efforts working on DRI with Mach64. How exactly have you been attempting to join? 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. > >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... > 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: 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?
e X11 API are you refering to which is now aged and irrelevant. Also, how does that particular item negatively effect current development, current software, or present barriers to new developers to enter into the foray of development? I can't think of any part of X11 et al which stands in the way of progress. Extensions which themselves have become irrelevant and obsolete, have been deprecated. ie: XIE and PEX. They are no longer built by default, however 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
[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 >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: 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 >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, 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 >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: 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 >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 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?
t to do so. There are many people who have stated just that in the past. Generally, they do not understand X at all, and set out to reinvent the wheel, rather than making the wheel better. There is the Berlin Project, and there is another project linuxgfx which set out to reimplement X 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
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 fabric>XFree 4.2. This version contains the i810 patch to enable more video fabric>than the 1mb provided by the BIOS. fabric> However, i still can't get it to work. It seems that a dual-headed fabric>support is detected, but that the driver doesn't support it. However i fabric>can live without the dual head support (this would be extremely nice to fabric>have it working, but not a priority) so I wonder if the issue is in my fabric>config 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>-- fabric>Fabrice Desré - FT.BD/FTR&D/DTL/TAL fabric>Tél: (33) 2 96 05 31 43 fabric>Fax: (33) 2 96 05 39 45 fabric> ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[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: Xpert digest, Vol 1 #1943 - 1 msg (OUT OF THE OFFICE)
e contact Alisa Ott at >[EMAIL PROTECTED] or by calling 801-225-6080. > >Thank you, >Jason Craddock > >>>> "[EMAIL PROTECTED]" 06/23/02 16:05 >>> > >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: Xpert digest, Vol 1 #1940 - 8 msgs (OUT OF THE OFFICE) (Jason Craddock) > 2. Compaq Presario 2800 (info @ saudiabm) > 3. Re: Re: 10-bits per colour (Detlef Grittner) > 4. Re: Re: 10-bits per colour ([EMAIL 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: ap
[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: 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 >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: again firegl8700
On Fri, 21 Jun 2002 [EMAIL PROTECTED] 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. TIA -- 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 >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: XF4.2 and RADEON Support
On Tue, 18 Jun 2002, Doug Alcorn wrote: >Date: Tue, 18 Jun 2002 09:39:05 -0400 >From: Doug Alcorn <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Content-Type: text/plain; charset=iso-8859-1 >List-Id: General X Discussion >Subject: Re: XF4.2 and RADEON Support > >Michel Dänzer <[EMAIL PROTECTED]> writes: > >>> and FireGL 7800 cards?? >> >> For FireGL cards ATI's binary drivers are probably the best bet. > >I just ordered an IBM A31p with the FireGL2 7800 in it. I passed up >the Dell with an Nvidia card because I thought choosing ATI was >choosing open source. :( > >Has ATI published any information on the FireGL 7800? Is there any >hope for a free driver? My recent emails about this card seem to not be getting out, or are being missed somehow. ;o) Red Hat Linux 7.3 comes with open source support for this card, which is otherwise unsupported in the stock XFree86 4.2.0 releases. I don't know if current CVS supports it yet or not either. The reason it came to be supported is a bit funny however, so I'll share the full story in case someone else gets a laugh... In order to maximize compatibility with the distro for various hardware each release, and to autodetect as much hardware as possible, even if it is unsupported, I go through published PCI ID data that I can get my hands on, and use it to update our pcitable, Cards database for Xconfigurator et al. and also occasionally xf86PciInfo.h etc. While perusing the ATI ID list in the R200 specs, and updating our pcitable entries and checking against xf86PciInfo.h to see if I needed to add an entry to Cards, I discovered that one of the Radeon Mobility M7 cards (the LX) was not supported by XFree86, so I thought I'd take a stab at adding the necessary bits by basically cloning the existing support for the other M7 to work with the LX also. Without having the actual hardware, worst case is that it just doesn't work, so no harm done as it doesn't work with stock X either. Up until about a week ago I had no idea if the patch worked or not, and no good or bad feedback about it. A week ago, a user who has a FireGL 7800 told me "it just works" with RHL 7.3 after I told him it was unsupported hardware. I asked him to give me the PCI ID, and after looking it up discovered that the FireGL 7800 *is* the Radeon Mobility M7 (LX). ;o) So the joke was on me. Not only, have I been telling people that that card is not supported, but I actually wrote the support for it unknowingly. ;o) If anyone else has one (since I don't), I would greatly appreciate hearing feedback on what works/doesn't work so that I can more accurately inform others who happen to inquire. In particular I would like to know how well 2D/3D/Xvideo works and what (if any) problems there are, and I'll try to fix/enhance it if possible. The patch is submitted to XFree86.org, and is available in our src.rpm package. I've also uploaded the patch to the following URL so that other distributions, people, etc can use it more easily: ftp://people.redhat.com/mharris/patches/ Enjoy! -- 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 >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: 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 >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]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: 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]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 >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: 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 >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 >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: 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 >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: 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 >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: 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 >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, 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 >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: 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 >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, 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 >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: 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 >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: 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 >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: 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 >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: 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 >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: 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 >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: 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 >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: 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 >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: 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 >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
