Re: [Xpert]adding radeon driver documentation
On Sun, 21 Jul 2002, Dr Andrew C Aitchison wrote: While the most asked question is Does the driver support my card ? I'm uncomfortable about the man page listing the supported cards, for several reasons: 1) For the most part the driver supports chips, not cards. ATI have a strong habit of releasing chips with new IDs without necessarily changing the name on the box or card. I'd be happy to replace that section with a pointer to a more up-to-date list of supported Radeon cards, but I know of no such source of information. (Even the driver status notes for 4.2.0 just say Radeon chips.) I was tempted to break down support by chipsets instead of cards, but I didn't know enough of the mappings among PCI IDs, Radeon chipsets, and card names. (For example, to my knowledge, all Radeon 8500 cards are using the R200 core/chipsets. What do the QL, QN, QO, Ql, and BB revisions mean? I don't know.) It would be worth documenting the work around for unsupported chips: If your card is unsupported, try adding the line ChipId 0xPQRS to the Devices section of your config file. Sorry, I don't know the radeon well enough to suggest the correct value, or values to try in PQRS, we may need to list different values for single and dual head, desktop and laptop, and radeon generations. Can anyone else help here? If I can get some good info on this, I'll be happy to document it, but if not, then I'd rather not mention it at all. 2) Man pages are not as frequently maintained as drivers. You should (must) put a prominent line in the list, saying something like: The list of cards known to work changes frequently (monthly?) As of 21 July 2002 the following cards are known to work: Will do. Dac6Bit: SWcursor: Thanks for the info; I've updated the man page. (I haven't included an updated version, because very little changed.) Again, I solicit feedback from the entire list. 14 FIXMEs remain, and I know that for each remaining FIXME, there are people reading this list who can easily complete/reconcile the information... -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]two x-server on one vt
i want to start two x-server on one vt but on two different monitors. i get this correctly by using startx -- :0 -xf86config XF86Config0 vt07 startx -- :1 -xf86config XF86Config1 vt07 so i can see two displays with different mouse pointer and one keyboard. and there are the problems: - the two mouse pointers are working correct - but the keyboard not. when i will type something on the first x sometimes it will do this and sometimes it write it on the second x. so it is not correctly configured? - and when i want to start a application at the first x it will work correctly. but on the second x the warning can't do this! please start the docpserver!. What's this? who can help me? XF86Config0: # /.../ # SaX generated XFree86 config file # Created on: 1998-01-22. # # Version: 4.3 # Contact: Marcus Schaefer [EMAIL PROTECTED], 2001 # # Automatically generated by [SaX2] (4.3) # PLEASE DO NOT EDIT THIS FILE! # Section Files FontPath /usr/X11R6/lib/X11/fonts/misc:unscaled FontPath /usr/X11R6/lib/X11/fonts/local FontPath /usr/X11R6/lib/X11/fonts/75dpi:unscaled FontPath /usr/X11R6/lib/X11/fonts/100dpi:unscaled FontPath /usr/X11R6/lib/X11/fonts/Type1 FontPath /usr/X11R6/lib/X11/fonts/URW FontPath /usr/X11R6/lib/X11/fonts/Speedo FontPath /usr/X11R6/lib/X11/fonts/PEX FontPath /usr/X11R6/lib/X11/fonts/cyrillic FontPath /usr/X11R6/lib/X11/fonts/latin2/misc:unscaled FontPath /usr/X11R6/lib/X11/fonts/latin2/75dpi:unscaled FontPath /usr/X11R6/lib/X11/fonts/latin2/100dpi:unscaled FontPath /usr/X11R6/lib/X11/fonts/latin2/Type1 FontPath /usr/X11R6/lib/X11/fonts/latin7/75dpi:unscaled FontPath /usr/X11R6/lib/X11/fonts/baekmuk:unscaled FontPath /usr/X11R6/lib/X11/fonts/japanese:unscaled FontPath /usr/X11R6/lib/X11/fonts/kwintv FontPath /usr/X11R6/lib/X11/fonts/truetype FontPath /usr/X11R6/lib/X11/fonts/uni FontPath /usr/X11R6/lib/X11/fonts/CID FontPath /usr/X11R6/lib/X11/fonts/ucs/misc FontPath /usr/X11R6/lib/X11/fonts/ucs/75dpi:unscaled FontPath /usr/X11R6/lib/X11/fonts/ucs/100dpi:unscaled FontPath /usr/X11R6/lib/X11/fonts/hellas/misc:unscaled FontPath /usr/X11R6/lib/X11/fonts/hellas/75dpi:unscaled FontPath /usr/X11R6/lib/X11/fonts/hellas/100dpi:unscaled FontPath /usr/X11R6/lib/X11/fonts/hellas/Type1 FontPath /usr/X11R6/lib/X11/fonts/misc/sgi FontPath /usr/X11R6/lib/X11/fonts/xtest ModulePath /usr/X11R6/lib/modules RgbPath /usr/X11R6/lib/X11/rgb EndSection Section ServerFlags Option AllowMouseOpenFail EndSection Section Module Load type1 Load speedo Load extmod Load freetype EndSection Section InputDevice Driver Keyboard Identifier Keyboard[0] Option Protocol Standard Option XkbLayout de Option XkbModel pc104 Option XkbRules xfree86 Option XkbVariant nodeadkeys EndSection Section InputDevice Driver mouse Identifier Touch Option Device /dev/ttyS0 Option Name Autodetection Option Protocol IntelliMouse Option Vendor Sysp EndSection Section Monitor HorizSync27-65 Identifier Testdsp ModelName640X480@70HZ VendorName -- LCD VertRefresh 55-60 UseModes Modes[0] EndSection Section Modes Identifier Modes[0] Modeline 640x480 23.96 640 656 720 864 480 480 484 501 EndSection Section Screen DefaultDepth 16 SubSection Display Depth 15 Modes 640x480 EndSubSection SubSection Display Depth 16 Modes 640x480 EndSubSection SubSection Display Depth 24 Modes 640x480 EndSubSection SubSection Display Depth 32 Modes 640x480 EndSubSection SubSection Display Depth 8 Modes 640x480 EndSubSection Device Device[0] Identifier Screen[0] Monitor Testdsp EndSection Section Device BoardNameVoodoo 3 BusID2:11:0 Driver tdfx Identifier Device[0] VendorName 3Dfx EndSection Section ServerLayout Identifier Layout[0] InputDevice Keyboard[0] CoreKeyboard InputDevice Touch CorePointer Option Clone off Option Xinerama off Screen Screen[0] EndSection Section DRI Group video Mode 0660 EndSection XF86Config1: # /.../ # SaX generated XFree86 config file # Created on: 1998-01-22. # # Version: 4.3 # Contact: Marcus Schaefer [EMAIL PROTECTED], 2001 # # Automatically generated by [SaX2] (4.3) # PLEASE DO NOT EDIT THIS FILE! # Section Files FontPath /usr/X11R6/lib/X11/fonts/misc:unscaled FontPath /usr/X11R6/lib/X11/fonts/local FontPath /usr/X11R6/lib/X11/fonts/75dpi:unscaled FontPath /usr/X11R6/lib/X11/fonts/100dpi:unscaled FontPath /usr/X11R6/lib/X11/fonts/Type1 FontPath /usr/X11R6/lib/X11/fonts/URW FontPath
Re: [Xpert]Opengl program performance drops after upgrading toXFree86 4.2
On Tue, 2002-07-23 at 05:43, Jason Hu Huang wrote: I have just upgraded my RH7.2 box's x server from 4.1 to 4.2. I found the performance of the opengl program that I am working on drops significantly. The original framerate is 40 fps, and now it is only around 20 fps. Can anyone tell me why this happens, and how I can solve it. Is direct rendering enabled with 4.2? Check the server log and/or glxinfo output. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Dual-head + dri on an ATI Radeon VE video card
On Sun, 2002-07-21 at 07:51, Angus Wallace wrote: I've got a quick question regarding an ATI Raedon VE dual-VGA-out card. I've read in several places that the driver doesn't currently support both dri and dual-head at the same time. Is this still the case? Yes. Is it likely to be addressed in the future, and if so when? The best solution would probably be to implement what nVidia calls 'TwinView' and Matrox calls 'merged display' I think. There were plans to do so but I don't know about the current status. Meanwhile, if you don't need DRI on both heads, run one server dualheaded with no DRI and another singleheaded with DRI. Very easy with gdm. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]nvidia binary driver: kernel BUG at page_alloc.c
On Mon, Jul 22, 2002 at 11:25:35PM +0200, Luca Olivetti wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Stilson wrote: Are you sure the nvidia module was loaded at the time of this crash? It would taint the kernel if loaded: Jul 7 20:20:54 pippo kernel: kernel BUG at page_alloc.c:216! Jul 7 20:20:54 pippo kernel: invalid operand: Jul 7 20:20:54 pippo kernel: CPU:0 Jul 7 20:20:54 pippo kernel: EIP:0010:[rmqueue+479/544]Tainted: P Jul 7 20:20:54 pippo kernel: EIP:0010:[c012e68f]Tainted: P Just to follow up after giving a little more thought... The kernel module doesn't taint it since I'm recompiling it from source. the NVdriver.o module (although it doesn't specifically have a MODULE_LICENSE(GPL)) also doesn't have any conflicting or proprietary license. Now my understanding might be wrong, but it SHOULDN'T be tainting the kernel. Only the X driver (nvidia_drv.o) is closed source. Perhaps you have something else tainting it? -me -- Windows has detected that you have moved your mouse. Your system must now be restarted for the changes to take effect. - Unknown ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]nvidia binary driver: kernel BUG at page_alloc.c
On Tue, Jul 23, 2002 at 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. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]two x-server on one vt
On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote: - and when i want to start a application at the first x it will work correctly. but on the second x the warning can't do this! please start the docpserver!. What's this? That's a KDE problem (it says dcopserver, right?). KDE programs use the X server for interprocess communication, together with a litle helper application called the DCOPserver. Maybe KDE doesn't particularly like it if you are using two X servers with one user. What if you create a dummy user that belongs to the same group as your ordinary user (so they can read/write each other's files) and have the dummy user start the second X server? Since you are tyring to run two different X servers anyway, I guess you are not expecting programs on one screen to be able to cooperate with those on the other so you don't loose anything there. -Peter ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]adding radeon driver documentation
On Tue, 23 Jul 2002, James Ralston wrote: I was tempted to break down support by chipsets instead of cards, but I didn't know enough of the mappings among PCI IDs, Radeon chipsets, and card names. (For example, to my knowledge, all Radeon 8500 cards are using the R200 core/chipsets. What do the QL, QN, QO, Ql, and BB revisions mean? I don't know.) For those particular letters I don't know, but it isn't hard to pick two ATI chid IDs for which the the answer would be: No-one at XFree86 knows the difference between these chips, but if you have server CVS version XXX one of the chips is supported and the other isn't. Support for the second chip is included from CVS version YYY. I've never been convinced that there was a reliable mapping between the chip id and the name on the box* so I wouldn't trust a list of card names to be accurate enough to say whether the driver will work with a particular card. *I've bought many ATI cards in a white box with no name, or installed in a new computer with no box at all, where I've had only the sticker on the card to identify it. The supplier might have sent a revised version without changing the name on the pricelist, so the card name isn't necessarily more help than the chip ID when I try to install linux. It would be worth documenting the work around for unsupported chips: If your card is unsupported, try adding the line ChipId 0xPQRS to the Devices section of your config file. Sorry, I don't know the radeon well enough to suggest the correct value, or values to try in PQRS, we may need to list different values for single and dual head, desktop and laptop, and radeon generations. Can anyone else help here? If I can get some good info on this, I'll be happy to document it, but if not, then I'd rather not mention it at all. I can understand your reluctance, but making people aware that this can be done is going to help many people to get their card working. Given that a graphics card becomes obsolete about as fast as a new version of XFree86 comes out, for anyone who buys a new ATI card, this trick is about the only alternative to running a CVS version of the server. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Antwort: Re: [Xpert]two x-server on one vt
What if you create a dummy user that belongs to the same group as your ordinary user (so they can read/write each other's files) and have the dummy user start the second X server? OK, that's fine. I tried this, and it works. Now I have a problem when I want to logout. If I want to logout, the X-Server is chrashing. So I get no screen and it hangs up. What's about this? -Thorsten ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: Antwort: Re: [Xpert]two x-server on one vt
On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote: OK, that's fine. I tried this, and it works. Now I have a problem when I want to logout. If I want to logout, the X-Server is chrashing. So I get no screen and it hangs up. What's about this? Dunno... why do you want them to use the same virtual terminal? (which one of the X servers crash on you?) -Peter If Bush is serious about his goal of having Palestine democratically choosing a replacement for Arafat, he's sending the wrong people. He shouldn't send Colin Powell. The one he should send is Katherine Harris. (seen on advogato.org/person/raph) ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Antwort: Re: Antwort: Re: [Xpert]two x-server on one vt
On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote: OK, that's fine. I tried this, and it works. Now I have a problem when I want to logout. If I want to logout, the X-Server is chrashing. So I get no screen and it hangs up. What's about this? Dunno... why do you want them to use the same virtual terminal? I've two monitors at two Graphic Cards. Now I want to display one X-Server at one of them. This is only possible, when I start the X-Servers at ONE vt. One time with :0 and one time with :1 and different XF86Configfiles. Isn't it correct?? I will see the two X-Servers at the same time and when I tried to display them at different vt's I have to change between them with str+alt+(f7/8. That isn't what I want. (which one of the X servers crash on you?) I don't know? Where can I seen this? It's so, that when I press the logout-Button one display will be black, and the other shows on one half the KDE on the other half a very bad text console. -Thorsten ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: Antwort: Re: Antwort: Re: [Xpert]two x-server on one vt
On Tue, Jul 23, 2002 at 03:01:44PM +0200, [EMAIL PROTECTED] wrote: On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote: OK, that's fine. I tried this, and it works. Now I have a problem when I want to logout. If I want to logout, the X-Server is chrashing. So I get no screen and it hangs up. What's about this? Dunno... why do you want them to use the same virtual terminal? I've two monitors at two Graphic Cards. Now I want to display one X-Server at one of them. This is only possible, when I start the X-Servers at ONE vt. One time with :0 and one time with :1 and different XF86Configfiles. Isn't it correct?? I will see the two X-Servers at the same time and when I tried to display them at different vt's I have to change between them with str+alt+(f7/8. That isn't what I want. To get two vt's displaying at once you need kernel support. The linuxconsole project guys are working on this, and I hear are doing pretty well so far - check freshmeat or something. I don't think you can have two x-servers on one VT, but I don't really know either way :) (which one of the X servers crash on you?) I don't know? Where can I seen this? It's so, that when I press the logout-Button one display will be black, and the other shows on one half the KDE on the other half a very bad text console. -Thorsten ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert -- msg07931/pgp0.pgp Description: PGP signature
Re: [Xpert]Re: ATI Radeon 8500 support
Check out http://dri.sourceforge.net/snapshots/bleeding-edge/ (r200) Here you will find the CVS snapshots of Tungsten's Radeon 8500 driver. It works (a bit slow though) on my machine. /Anders On Thu, 2002-07-18 at 10:37, Ani Joshi wrote: Or for 3D 8500 support you could download the FireGL 8xxx driver from ATI's website and install that rpm. I don't know about RedHat 7.3, but it works fine on RedHat 7.2. ani On Thu, 18 Jul 2002, Mike A. Harris wrote: 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 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert -- Med venlig hilsen - Best regards Anders Saaby Systems Engineer __ Cohaesio A/S - Phone: +45 45 880 888 Maglebjergvej 5D - Fax: +45 45 880 777 DK-2800 Lyngby - e-mail: [EMAIL PROTECTED] __ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]adding radeon driver documentation
On Sun, 2002-07-21 at 10:56, James Ralston wrote: On 17 Jul 2002, Michel Dänzer wrote: On Wed, 2002-07-17 at 08:58, James Ralston wrote: (I'd be willing to take a crack at writing a man page for the radeon driver, Great! That's very much appreciated. Attached is the first draft. Besides general proofreading and review, there are 16 FIXMEs in the first draft; I would appreciate help in clarifying the points they raise. While you're at it, please also add the documentation for options to programs/Xserver/hw/xfree86/Options, which can be used by configuration tools like xf86cfg. I'll do that once I have something approaching a final version for the radeon(4x) man page (to minimize the number of edits I'll have to do in two places). Good. Comments (mostly looking at the FIXMEs :): - reports are probably best directed to this list - I'd rephrase the description of Option UseFBDev along the lines of: Option UseFBDev boolean If set to true, XFree86 will attempt to use use an OS-specific framebuffer device interface. See fbdevhw(4x) for further information. XFree86 will fail to start up if this doesn't work. The default is false (meaning, an OS-specific framebuffer device interface will not be used, the chip will be programmed directly). Don't miss the 'device' after 'framebuffer'. :) - the video key is a special color value which is replaced by the video overlay if and where it's active. It only needs to be changed if the default value causes undesired effects. - I think it's correct that the multihead options have no effect with cards without multiple ports (assuming that all cards with multihead capable chips have multiple ports) - I think the comment in RADEONPreInitModes() is accurate, the one in RADEONGetBIOSParameters() is probably outdated - the DRI options (except the AGP options) are mostly for debugging and shouldn't normally be needed. I think describing them might cause more confusion than it helps. FWIW the r128 manpage doesn't document them. - yes, Option AGPMode does override the AGP mode. I think the speed-stability tradeoff is well described. - I don't think Option AGPSize is related to the AGP aperture size. It determines how much of it the driver actually uses, so I'd expect it to be limited by the aperture size. Again, this shouldn't need to be changed, certainly not until the driver supports AGP texturing. Hope this helps, keep up the good work -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]XSendEvent and Capital/Small Letters.
Hi, I have a problem with the sending of keys using XSendEvent. When I send a letter, for example the letter a sends it correctly but when sends the letter A does not send it correctly, but it sends the small letter (a). I have made a function that sends a string: SendString(display, window, string) and I need that the chain sends it correctly. Somebody knows since I can do this? Thanks. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: Antwort: Re: Antwort: Re: [Xpert]two x-server on one vt
On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote: I've two monitors at two Graphic Cards. Now I want to display one X-Server at one of them. This is only possible, when I start the X-Servers at ONE vt. One time with :0 and one time with :1 and different XF86Configfiles. Isn't it correct?? Not really. I will see the two X-Servers at the same time and when I tried to display them at different vt's I have to change between them with str+alt+(f7/8. That isn't what I want. That explains the vt thing. But why aren't you using Xinerama? It's much better suited to your needs - actually I thought you were going to use that as per the earlier discussion on using multiple mice. http://www.tldp.org/HOWTO/Xinerama-HOWTO.html I don't know? Where can I seen this? It's so, that when I press the logout-Button one display will be black, and the other shows on one half the KDE on the other half a very bad text console. The one with half a KDE image would be my guess ;) -Peter ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: Antwort: Re: Antwort: Re: [Xpert]two x-server on one vt
On Tue, 23 Jul 2002 [EMAIL PROTECTED] wrote: I will see the two X-Servers at the same time and when I tried to display them at different vt's I have to change between them with str+alt+(f7/8. That isn't what I want. You are using the same keyboard (standard PC compatible) with both X servers, as far as I can tell from your config files!?!? How does that work? Honestly, I can't how it should work at all. Not with the X servers being on the same virtual terminal. I think you should take a look at Xinerama - remember you can use two (or more) mice if you want to. -Peter ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]nvidia binary driver: kernel BUG at page_alloc.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. No, you're just recompiling some glue code, the real module is binary only. | 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. Yes, it should, in fact I think that kernel developers introduced the Tainted flag specifically for the nvidia module, see this message from Alan Cox, http://old.lwn.net/2001/0906/a/ac-license.php3, where he states: Unfortunately I get so many bug reports caused by the nvidia modules and people lying when asked if they have them loaded that some kind of action has to occur, otherwise I'm going to have to stop reading bug reports from anyone I don't know personally. Bye - -- Luca Olivetti Note.- This message reached you today, it may not tomorrow if you are using MAPS services. They arbitrarily include in their lists IP addresses not related in any way to spam, and in so doing are disrupting Internet connectivity. Please stop supporting them. See http://slashdot.org/article.pl?sid=01/05/21/1944247 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: http://www.gnupg.org iD8DBQE9PWC+CQPXTRx9NmQRAk9YAKCsQ4Vs/WbeYpLIZkifnwgEras7DACgs33R YImr5J3DGqYfftYR5hPbO8g= =dE9X -END PGP SIGNATURE- ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]MotionNotify
Hi Xperts, I want to get all the mouse move events. I'm using all masks ButtonMotionMask (for all 5 buttons), PointerMotionMask. Still my window is not getting the MotionNotify events whenever i move the mouse. I read PointerMotionHint Mask will reduce the motion events to one. Hence i have not used it. Which is hogging my MotionNotify events? Thanks, JeyaSudha. **Disclaimer** Information contained in this E-MAIL being proprietary to Wipro Limited is 'privileged' and 'confidential' and intended for use only by the individual or entity to which it is addressed. You are notified that any use, copying or dissemination of the information contained in the E-MAIL in any manner whatsoever is strictly prohibited.
Re: [Xpert]XVideo extension docs
I'm coming (butting?) into the middle of this so my comments may not be germane (in which case I won't be offended if you tell me to buzz off). No, many thanks for your in depth explanation. I'm not quite sure what YUV2 is but ordinary MPEG2 YUV (more properly, Y, Cb, Cr) is such that U and V are subsampled x2 horizontally w.r.t. Y and that is how you get 16 bits. I'am far from xpert at this area - so maybe i'am wrong at this ml anyway mayself ;-) Bit chopping does not, technically speaking, result in loss of resolution. Instead you get various contouring and other artifacts due to the Exactly that is what i see! But what to do now? Is there a way to support more ximage input formats? But, this is going OT now - as it was about Xvideo docs. Still got no detailed explanation why i should use the XvPutVideo() function call at all, which i thought would solve btw, the problem of the high CPU-load (at least reported to me with V3K + NVIDIA + Matrox cards). ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]nvidia binary driver: kernel BUG at page_alloc.c
On Tue, Jul 23, 2002 at 01:36:39PM +0200, Charl P. Botha wrote: On Tue, Jul 23, 2002 at 07:16:50AM -0400, Mike Stilson wrote: Just to follow up after giving a little more thought... The kernel module doesn't taint it since I'm recompiling it from source. the NVdriver.o module (although it doesn't specifically have a MODULE_LICENSE(GPL)) also doesn't have any conflicting or proprietary license. Now my understanding might be wrong, but it SHOULDN'T be tainting the kernel. Only the X driver (nvidia_drv.o) is closed source. The kernel module *does* taint it. You're only building three of the objects and then linking with Module-nvkernel, which is binary and which is where most of the juicy bits are. Ok, that being the case, any idea as to why it's not tainted? The module is remaining loaded. -- Windows has detected that you have moved your mouse. Your system must now be restarted for the changes to take effect. - Unknown ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Radeon switch to VT and back X freeze POSSIBLE FIX
On Tue, Jul 23, 2002 at 06:33:27PM +0200, Benjamin Herrenschmidt wrote: So, appended is a patch that changes the RADEONEnterVT code in radeon_driver.c so that it re-enables bus mastering mode. Michel has tested it on his TiBook (which doesn't have the problem) and the patch doesn't seem to break anything. Please apply to the DRI trunk and XFree86 CVS if you think this is applicable. If you can keep my name in the source, I'll be even happer. Yes, small things amuse small minds. ;) I don't think this is the proper fix. It's probably only a workaround. It stops the card from bus mastering, thus probably aborting any bus master transaction (so all ring operations), but that should _fix_ any problem unless the card is still doing something it shouldn't do at this point. Actually, even if I know no fbdev driver doing so, those could well want bus mastering as well and might be confused by XFree disabling it. The patch doesn't disable bus mastering, but ENABLES it when we return to X. We still don't know why it gets disabled in the first place when switching to a VT, as the X code does NOT disable bus mastering at all. Our current suspect is card/agp firmware. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Radeon switch to VT and back X freeze POSSIBLE FIX
On Tue, Jul 23, 2002 at 01:04:56PM -0500, Steven Walter wrote: So, appended is a patch that changes the RADEONEnterVT code in radeon_driver.c so that it re-enables bus mastering mode. Michel has tested it on his TiBook (which doesn't have the problem) and the patch doesn't seem to break anything. Please apply to the DRI trunk and XFree86 CVS if you think this is applicable. If you can keep my name in the source, I'll be even happer. Yes, small things amuse small minds. ;) I have just tried your fix with a Radeon 7500 QW and have gotten some interesting, and perhaps hopeful, results. To summarize, this patch seems only the make the lock-ups less reproducible. Sometimes it takes 3, sometimes four, sometimes 2. I don't think I've gotten a lock on the first switch, yet. I'm using the radeonfb; I'll have to attempt without. Additionally, I'd like to see what, if any, effect XVidMode has, as it changed the situation before the fix. However, using radeonfb and with XVidMode enable, the lock-up IS STILL THERE. But I have a feeling you are now much closer. Hmm, can you do a lspci -vvv before and after the crash? (if you have a machine from which you can ssh in to the crashed machine) In addition, also do a lspci -vvv just after you've switched to the VT. Thanks, Charl -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Radeon switch to VT and back X freeze POSSIBLE FIX
On Tue, Jul 23, 2002 at 01:46:34PM -0500, Steven Walter wrote: On Tue, Jul 23, 2002 at 01:04:56PM -0500, Steven Walter wrote: To summarize, this patch seems only the make the lock-ups less reproducible. Sometimes it takes 3, sometimes four, sometimes 2. I don't think I've gotten a lock on the first switch, yet. I'm using the radeonfb; I'll have to attempt without. Additionally, I'd like to see what, if any, effect XVidMode has, as it changed the situation before the fix. However, using radeonfb and with XVidMode enable, the lock-up IS STILL THERE. But I have a feeling you are now much closer. Okay, I have tried without xvidmode and without radeonfb, and the lockups still occur. Additionally, I have induced the lock-up on the first VT switch. Really, all this patch has accomplished for me is that sometimes, the patch occurs on the 3rd or 4th vt-switch, instead of reproducibly the first as before. It was noted that this patch was tried on a machine that didn't experience the problem, and that nothing broke. Has anyone actually tried the patch on a machine with the problem, and have the problem solved? If not, it seems to me that this patch doesn't buy us all that much. I have just tested on my laptop which had the problem (and which is why I started spending time on this in the first time). I've just done 13 VT switches, with and without glxgears running and have not been able to induce the crash. I'm even getting tired of VT switching... ;) Which patch are you using? The one I sent, or the one Michel committed? I am concerned (and Michel, correct me if I'm blundering) that the DRI commit has the bus master enable AFTER RADEONEngineRestore(). I am still interested to see the 3 lspci -vvv's, your XF86Config-4 and your XFree86.log. Thanks, Char -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] Radeon switch to VT and back X freeze POSSIBLE FIX
On Tue, Jul 23, 2002 at 08:57:29PM +0200, Charl P. Botha wrote: Which patch are you using? The one I sent, or the one Michel committed? I am concerned (and Michel, correct me if I'm blundering) that the DRI commit has the bus master enable AFTER RADEONEngineRestore(). I've tested with Michel's DRI commit and it's rock-solid. I can NOT make the machine crash by VT switching, no matter how many times I switch to VT and back. I even did the hitherto unthinkable (with this Radeon) and switched with a Viewperf 6.1.2 benchmark running. More testing anyone? Happiness, Charl Ps. Now on to making agpgart + dri work with swsusp, which was the whole point of this exercise. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Xserver won\'t recognize PCI card
On Wed, 2002-07-24 at 00:33, Daniel Sheltraw wrote: It appears that, in the machine which is unable to function as expected, there is a problem with the Xserver recognizing the PCI card despite the fact we have told it where on the bus to find the card in the XF86Config-4 file. Also both cards are recognized by Linux as indicated in /proc/pci and both cards do function. The only idea I have is that the bus ID you specify isn't correct. A common cause of confusion is that lspci shows hex numbers, but X takes decimal. At any rate, the correct bus ID should be in the log in a line like (--) PCI:*(0:16:0) ATI Radeon Mobility M7 LW rev 0, Mem @ 0xb800/27, 0xb000/16, I/O @ 0x0400/8, BIOS @ 0xb002/17 -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XVideo extension docs
Michel Lanners ([EMAIL PROTECTED]): On 23 Jul, this message from Guido Fiala echoed through cyberspace: moving YUV across the bus, but it should use no CPU. Yes, so i thought. But that would mean, that the XServer loads it's data directly from the v4l device itself (mmap-io or direct write into AGP-memory?) The latter should work if the ximage is a contigous array in AGP memory only. No, it's the video input hardware that pushes the data with DMA to an off-screen VRAM memory area, and the graphic chip then copies and color-converts on the fly to the visible window. Wouldn't it be great if they were actually in sync so they wouldn't tear, or so that we could handled interlaced streams better. The v4l-module architecture needs to be reworked. -- Billy Biggs [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Debugging server crash?
I'm getting server crashes with the latest CVS build. I have attached a server log, but unfortunately I am not seeing any cores left around to debug this with. Any ideas on how I can try to get more information to debug this? This usually seems to happen when a OpenGL screensaver is running. I'm on a Radeon 8500 128M. -- Manuel A. McLure KE6TAW [EMAIL PROTECTED] http://www.mclure.org ...for in Ulthar, according to an ancient and significant law, no man may kill a cat. -- H.P. Lovecraft This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs) XFree86 Version 4.2.99.1 (Custom Build: 4.2.0-20020711_CVS) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 7 June 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.18-5-mppe i686 [ELF] Build Host: ulthar.internal.mclure.org 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: Tue Jul 23 19:34:46 2002 (==) Using config file: /etc/X11/XF86Config-4 (==) ServerLayout XFree86 Configured (**) |--Screen Screen0 (0) (**) | |--Monitor NEC FE950+ (**) | |--Device ATI Radeon 8500 (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (**) Option XkbLayout us (**) XKB: layout: us (**) Option XkbOptions ctrl:swapcaps (**) XKB: options: ctrl:swapcaps (==) Keyboard: CustomKeycode disabled (**) FontPath set to unix/:7100 (==) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (--) using VT number 7 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.2.99.1, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.2.99.1, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x8048, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1022,700e card , rev 13 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1022,700f card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:07:0: chip 1106,0686 card 147b,a702 rev 40 class 06,01,00 hdr 80 (II) PCI: 00:07:1: chip 1106,0571 card 1106,0571 rev 06 class 01,01,8a hdr 00 (II) PCI: 00:07:2: chip 1106,3038 card 0925,1234 rev 1a class 0c,03,00 hdr 00 (II) PCI: 00:07:3: chip 1106,3038 card 0925,1234 rev 1a class 0c,03,00 hdr 00 (II) PCI: 00:07:4: chip 1106,3057 card 1106,3057 rev 40 class 0c,05,00 hdr 00 (II) PCI: 00:09:0: chip 1013,6003 card 1681,0050 rev 01 class 04,01,00 hdr 00 (II) PCI: 00:0b:0: chip 1317,0985 card 1317,0574 rev 11 class 02,00,00 hdr 00 (II) PCI: 00:0d:0: chip 10cd,1300 card 10cd,1310 rev 03 class 01,00,00 hdr 00 (II) PCI: 00:0f:0: chip 104c,8019 card 11bd,000e rev 00 class 0c,00,10 hdr 00 (II) PCI: 01:05:0: chip 1002,514c card 1002,013a rev 00 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) LoadModule: scanpci (II) Loading /usr/X11R6/lib/modules/libscanpci.a (II) Module scanpci: vendor=The XFree86 Project compiled for 4.2.99.1, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.6 (II) UnloadModule: scanpci (II) Unloading /usr/X11R6/lib/modules/libscanpci.a (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (-1,0,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x0e (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0xc000 - 0xc0ff (0x100) IX[B] [1] -1 0 0xc400 - 0xc4ff (0x100) IX[B] [2] -1 0
[Xpert]Re: nvidia binary driver: kernel BUG at page_alloc.c
On Tue, 23 Jul 2002, Mike Stilson wrote: Date: Tue, 23 Jul 2002 07:16:50 -0400 From: Mike Stilson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii List-Id: General X Discussion xpert.XFree86.Org Subject: Re: nvidia binary driver: kernel BUG at page_alloc.c On Mon, Jul 22, 2002 at 11:25:35PM +0200, Luca Olivetti wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Stilson wrote: Are you sure the nvidia module was loaded at the time of this crash? It would taint the kernel if loaded: Jul 7 20:20:54 pippo kernel: kernel BUG at page_alloc.c:216! Jul 7 20:20:54 pippo kernel: invalid operand: Jul 7 20:20:54 pippo kernel: CPU:0 Jul 7 20:20:54 pippo kernel: EIP:0010:[rmqueue+479/544]Tainted: P Jul 7 20:20:54 pippo kernel: EIP:0010:[c012e68f]Tainted: P Just to follow up after giving a little more thought... The kernel module doesn't taint it since I'm recompiling it from source. the NVdriver.o module (although it doesn't specifically have a MODULE_LICENSE(GPL)) also doesn't have any conflicting or proprietary license. Now my understanding might be wrong, but it SHOULDN'T be tainting the kernel. Only the X driver (nvidia_drv.o) is closed source. Perhaps you have something else tainting it? The Nvidia kernel module very much does and should taint the kernel. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]adding radeon driver documentation
- Original Message - From: James Ralston [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, July 21, 2002 1:56 AM Subject: [Xpert]adding radeon driver documentation Attached is the first draft. Good to see the new Radeon man page being worked on. I'll try to explain some of FIXMEs below. In particular, the following cards are known to work (FIXME: check list): ATI Radeon 8500 series All-In-Wonder Radeon 8500 All-In-Wonder Radeon 8500DV Radeon 8500 128MB Radeon 8500 64MB Radeon 8500LE ATI Radeon 7500 series All-In-Wonder Radeon 7500 Radeon 7500 ATI Radeon 7000 series Radeon 7000 (also known as the Radeon VE) ATI Radeon series Radeon All-In-Wonder Radeon 64MB DDR (VIVO) Radeon 64MB SDR Radeon 32MB DDR Radeon 32MB SDR ATI Radeon Mobility series Radeon Mobility M6 Radeon Mobility M7 The supported chips (series) in the list are almost complete, except 7200 series (new version of old Radeon). I'm not sure if we should list all memory+connector configurations here. There are quite a few OEM versions of Radeon boards which may have different configurations. Note that the following cards are known not to work with the radeon driver. Support for these cards will be added in a future release of XFree86 (FIXME: check both of these assertions): ATI Radeon 9700 series ATI Radeon 9000 series These cards (also M9, using the same RV250 core as 9000) will be supported (at least 2D part) in the near future. Note that not all monitors and not all Radeon cards support the VESA DDC/CI standard. If DDCMode is enabled, but the monitor and/or card does not support the VESA DDC/CI standard, then XFree86 will emit a warning message and use the standard VESA mode timings instead. All Radeon cards can do DDC probe, while some old CRTs or LCDs may not be DDC capable. The advantage of not using DDCMode is that the VESA standard mode timings are supported by virtually all monitors. Additionally, a monitor which does not support the VESA standard mode timings will almost certainly not support the VESA DDC/CI standard. The last statement is a bit confusing and may not be true. Traditionally, the driver uses lookup-best-refresh routine looking for the best refresh mode within standard VESA modes according to the specified VRefresh/HSync ranges. It should work well for most of displays. The advantage of using DDCMode is that your particular monitor may support non-standard non-VESA) mode timings which are better (e.g., a higher refresh rate) than the VESA standard mode timings. Additionally, for flat panel displays being used in analog mode, DDCMode will avoid using unstable modes (some VESA standard modes don't really work with these panels). This is okay. VideoKey Option This Option can be used to override the default video key value (FIXME: what does the video key do? Why would one want to override the default value?) VideoKey (aka colorkey) color is used by hardware overlay for displaying. The hardware overlay image is only visible on the colorkey color. When an application (like gtv) calls into driver for displaying a frame of video, the driver will paint the background of the application window to the colorkey color so that the hardware overlay can display on it. When another window overlaps on top of the video window, the overlay (video image) will be covered as long as the colors in the overlapped window do not match the colorkey color. If one color in the overlapped window matches the colorkey color, that part of window will appear to be transparent (you can see thru it to the underneath video image). To avoid this, you can specify an uncommon color to your system as the colorkey. The following Options are designed for Radeon cards with multiple video ports, Specifying these Options for cards without multiple video ports will have no effect. (FIXME: is this true?) True. The Options are: Option CloneDisplay boolean If set to true, then the DVI port will be cloned onto the CRT port. The default is false (meaning, the DVI port will not be cloned onto the CRT port). This option may be set to default on in future after more tests. All clone mode stuffs shouldn't have any effect if only one monitor connected or if there are two Screen sections. FIXME: the Here is a hack for cloning first display on the second head comments in radeon_driver.c (in the RADEONPreInitModes function) seem to imply that if both the DVI and CRT ports are being used, and both have displays connected to them, and only one screen is defined in XF86Config, and CloneDisplay isn't being used, then the monitor connected to the CRT port will be driven according to the capability of the monitor/panel connected to the DVI port. But the VE and M6 have both DVI and CRT ports comments (in the RADEONGetBIOSParameters function) seem to imply that if both the DVI and CRT ports are being used, and both have displays connected to them, and
