[Xpert]twinview question
Hello Mark, all. I've just gotten twinview set up on my GeForce 4 Ti4600 board (VisionTek). I've got a 1600x1200 CRT to the left and a 1200x1024 FP to the right. I've got two metamodes defined (for now): Section "Screen" Identifier "screen1" Device "NVIDIA GeForce4" Monitor "Panasonic|Panasonic S21" Option "TwinView" "On" Option "SecondMonitorHorizSync" "31-68" Option "SecondMonitorVertRefresh" "60-76" Option "MetaModes" "1600x1200, 1280x1024 @1280x1200; 1600x1200, null" Option "TwinViewOrientation""rightof" EndSection Questions: 1: Do I need to do anything special to enable the xinerama extension mentioned in the Nvidia Readme? I ask because KDE seems to like to put windows up right across the boundary between the two monitors and the Readme indicates that the xinerama extension should prevent this. What am I missing. 2: When I change modes to the 2nd mode KDE keeps the virtual desktop size of the first metamode. The FP shuts off alright but the CRT has a 2800x1200 virtual desktop. How can I make the virtual desktop snap to the CRT resolution when in the second mode? I note that, again, the Nvidia Readme seems to indicate (in the FAQ section) that the xinerama extension in conjunction with the XF86VidMode extension should take care of letting the window manager know there's been a mode change. 3: This XF86Config file I've cobbled together comes from an older single-head one. So following the stuff above there's all the "Display" subsections I had before. Is this now cruft that I can remove? What about DefaultColorDepth? Thanks. Dean ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]r128, DRI and XaaNoPixmapCache
Hi! I just found out that unless you use XaaNoPixmapCache, dri on r128 freezes (== complete system lockup) pretty often. I use yesterday's XF86 CVS. Well, I thought it might be a good idea to write this on the webpage or into docs with BIG letters, because otherwise gaming is pretty unusable if it freezes every hour or so. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- ...and that is how we know the Earth to be banana-shaped. msg07288/pgp0.pgp Description: PGP signature
[Xpert]Help with developing !!!
Hi@all,Need help in develop with Xfree86:How can i create a Scrollwindow andwhat functions i need ?
[Xpert]fbset modes ?
Hello, I would like to use KDrive's XFBDev server along with a National framebuffer. I successfully ran both, switched modes without any problem with busybox's fbset. However, even after changing to another mode than the one given to the kernel with vga= (I basically boot in 800x600x8, then switch manually to 1024x768x16 on the console), the X server goes back to 800x600x8 resolution. My XF86Config uses the "default" resolution. How do I define other resolutions in XF86Config, or else is it possible to change the default mode (even with rebooting, but not changing vga= setting) ? Thanks for upcoming help, Rolland Dudemaine ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon HARDWARE_CLIP_SCREEN_TO_SCREEN_COPY fixed?
On Mon, 2002-07-01 at 01:38, Andrew P. Lentvorski wrote: > I note that HARDWARE_CLIP_SCREEN_TO_SCREEN_COPY is enabled on the latest > Radeon accelerated driver. > > Has the bug with this been fixed? No, it has required rather serious surgery, please try http://www.penguinppc.org/~daenzer/DRI/radeon_accel.diff It's against DRI CVS and also contains other minor fixes but should be straightforward to merge into XFree86 CVS. I suspect there are still problems related to hardware clipping and/or transparency, but at least the teststipple program someone posted here works now. > Also, is there a bug reporting form somewhere that I can dump problem > reports into rather than just splashing them to the entire mailing list? There's a form somewhere on xfree86.org but I forget where. :/ -- 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]fbset modes ?
On Mon, 2002-07-01 at 11:39, Rolland Dudemaine wrote: > I would like to use KDrive's XFBDev server along with a National > framebuffer. > I successfully ran both, switched modes without any problem with > busybox's fbset. However, even after changing to another mode than the > one given to the kernel with vga= (I basically boot in 800x600x8, then > switch manually to 1024x768x16 on the console), the X server goes back > to 800x600x8 resolution. > My XF86Config uses the "default" resolution. > How do I define other resolutions in XF86Config, or else is it possible > to change the default mode (even with rebooting, but not changing vga= > setting) ? XFBDev doesn't use a config file. It just uses the mode of the VT it runs on, which is apparently still the one you specified at boot. Try changing it with fbset -a. -- 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]r128, DRI and XaaNoPixmapCache
Hi, I think I have the same problem. I'm using the r128 driver and after upgrading to RedHat 7.2 and XFree86 4.2.0, I experienced freezes, especially when moving long scollbars and playing DVD's. I added the lines Option "XaaNoOffscreenPixmaps" Option "XaaNoPixmapCache" to the Screen Section of the XF86config file, but that didn't help. Adding the line Option "Accel" "off" did help, but that made X really slow. So, does anyone know of a better workaround for the problem, until it's resolved? By the way, there was a thread with the subject "[Xpert]4.2.0 R128 hanging" on this mailing list in February, which IMHO discussed the same issue. Seems like they didn't find a solution, though. Thanks for your help, Levin Fritz On Mon, 1 Jul 2002 09:24:02 +0200 Peter Surda <[EMAIL PROTECTED]> wrote: > Hi! > > I just found out that unless you use XaaNoPixmapCache, dri on r128 > freezes (== complete system lockup) pretty often. I use yesterday's XF86 > CVS. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon HARDWARE_CLIP_SCREEN_TO_SCREEN_COPY fixed?
On 1 Jul 2002, Michel Dänzer wrote: > On Mon, 2002-07-01 at 01:38, Andrew P. Lentvorski wrote: > > I note that HARDWARE_CLIP_SCREEN_TO_SCREEN_COPY is enabled on the latest > > Radeon accelerated driver. > > > > Has the bug with this been fixed? > > No, it has required rather serious surgery, please try > > http://www.penguinppc.org/~daenzer/DRI/radeon_accel.diff > > It's against DRI CVS and also contains other minor fixes but should be > straightforward to merge into XFree86 CVS. I suspect there are still problems > related to hardware clipping and/or transparency, but at least the > teststipple program someone posted here works now. Merging with XFree86 CVS is highly non-trivial (the .rej reject output is longer than the patch :-(). While attempting to generate a merge I note that the RADEONInfoRec struct has no member dp_gui_master_cntl_cache or trans_color. Does radeon.h need patching too ? -- 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
Re: [Xpert]A few questions regarding the XFree86-DGA extension
MV> DGA really shouldn't be used and I regret that it's still in the MV> X-server. I would like it to disappear in XFree86 5.0. Mark, I fully agree with your feeling, and I am sincerely sorry to say what I'm about to say. There is no denying, though, that there are applications that want to do client-side rendering -- and I think that's a perfectly legitimate thing to do. The obvious solutions (PutImage and ShmPutImage) either involve one copy too many, or else require you to put your rendering buffers in a shared memory segment. I may be mistaken, but as far as I can see, the only way to do a direct blit from a random client-specified buffer is DGA. Unless we provide a different way to do that, there is little chance of DGA going away with no loss. Juliusz ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon HARDWARE_CLIP_SCREEN_TO_SCREEN_COPY fixed?
On Mon, 2002-07-01 at 17:00, Dr Andrew C Aitchison wrote: > On 1 Jul 2002, Michel Dänzer wrote: > > > On Mon, 2002-07-01 at 01:38, Andrew P. Lentvorski wrote: > > > I note that HARDWARE_CLIP_SCREEN_TO_SCREEN_COPY is enabled on the latest > > > Radeon accelerated driver. > > > > > > Has the bug with this been fixed? > > > > No, it has required rather serious surgery, please try > > > > http://www.penguinppc.org/~daenzer/DRI/radeon_accel.diff > > > > It's against DRI CVS and also contains other minor fixes but should be > > straightforward to merge into XFree86 CVS. I suspect there are still problems > > related to hardware clipping and/or transparency, but at least the > > teststipple program someone posted here works now. > > Merging with XFree86 CVS is highly non-trivial (the .rej reject > output is longer than the patch :-(). Well, I wouldn't measure the non-triviality in lines of code. :) It's mostly due to Kevin's cleanups of the formatting, isn't it? > While attempting to generate a merge I note that the RADEONInfoRec > struct has no member dp_gui_master_cntl_cache or trans_color. > Does radeon.h need patching too ? Yes, thanks for pointing that out. Patch updated. -- 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]change X resolution
> Hello, > > I know about CTR-ALT- + for moving from 1024x768 to 640x480 on fly without > restart X. > > How could i move from 1024x768 to 640x480 in my program code? > Any examples. See the source code for xvidtune. If you run 'xvidtune -next', you'll get the same behaviour as Ctrl-Alt-Plus and 'xvidtune -prev' switches to the previous mode like Ctrl-Alt-Minus. If you have several modes and the one you want doesn't happen to be the next or previous one, you have two choices: (1) do a next/prev switch repeatedly or (2) use XF86VidModeSwitchToMode(). See the XF86VidMode man page for details. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]change X resolution
On Mon, 1 Jul 2002, nikita wrote: > Hello, > > I know about CTR-ALT- + for moving from 1024x768 to 640x480 on fly without > restart X. > > How could i move from 1024x768 to 640x480 in my program code? See the man page on XF86VidModeSwitchMode. This is an XFree86- specific extension and will only work on XFree86. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]twinview question
On Mon, 1 Jul 2002, Dean S. Messing wrote: > > > Hello Mark, all. > > I've just gotten twinview set up on my GeForce 4 Ti4600 board (VisionTek). > I've got a 1600x1200 CRT to the left and a 1200x1024 FP to the right. > I've got two metamodes defined (for now): > > Section "Screen" > Identifier "screen1" > Device "NVIDIA GeForce4" > Monitor "Panasonic|Panasonic S21" > > Option "TwinView" "On" > Option "SecondMonitorHorizSync" "31-68" > Option "SecondMonitorVertRefresh" "60-76" > Option "MetaModes" "1600x1200, 1280x1024 @1280x1200; 1600x1200, >null" > Option "TwinViewOrientation""rightof" > > > > EndSection > > Questions: > > 1: Do I need to do anything special to enable the xinerama extension >mentioned in the Nvidia Readme? I ask because KDE seems >to like to put windows up right across the boundary between the >two monitors and the Readme indicates that the xinerama extension >should prevent this. What am I missing. The Xinerama extension does not prevent this. The Xinerama extension gives the window manager a mechanism to prevent this. Window managers must specifically support this. Some do, some don't. I don't know about KDE. Some window managers try to do this and are broken and have behavior worse than if they did nothing at all so we have an option to disable advertising of the Xinerama extension. > > 2: When I change modes to the 2nd mode KDE keeps the virtual desktop >size of the first metamode. The FP shuts off alright but >the CRT has a 2800x1200 virtual desktop. How can I make the >virtual desktop snap to the CRT resolution when in the second mode? The root window can never change size throughout the X session, Even with a single head, there is no mechanism in the X-window system to resize the desktop. XFree86 hotkeys for mode switching merely change the size of the viewport, not the root window. There is that panning domain stuff in TwinView that might at least let you prevent the one head from panning outside of its square of the screen. > > 3: This XF86Config file I've cobbled together comes from >an older single-head one. So following the stuff above there's >all the "Display" subsections I had before. Is this now cruft that >I can remove? What about DefaultColorDepth? > I thought DefaultColorDepth was a XFree86 3.x keyword? There is a DefaultDepth in 4.x. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]A few questions regarding the XFree86-DGA extension
On 1 Jul 2002, Juliusz Chroboczek wrote: > MV> DGA really shouldn't be used and I regret that it's still in the > MV> X-server. I would like it to disappear in XFree86 5.0. > > Mark, > > I fully agree with your feeling, and I am sincerely sorry to say what > I'm about to say. > > There is no denying, though, that there are applications that want to > do client-side rendering -- and I think that's a perfectly legitimate > thing to do. The obvious solutions (PutImage and ShmPutImage) either > involve one copy too many, or else require you to put your rendering > buffers in a shared memory segment. > > I may be mistaken, but as far as I can see, the only way to do a > direct blit from a random client-specified buffer is DGA. Unless we > provide a different way to do that, there is little chance of DGA > going away with no loss. > DGA going a away is a security gain, and also removes a sticky and frequently broken part of driver operation. Good riddence. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]XIM, kinput2, and keyboard input in XDarwin
When running XDarwin (based on XFree86) on MacOSX, it is possible, even desirable, to have the OS handle all the keyboard layout. The main case where this is an issue is in Asian languages. For asian languages, it would be desirable to have the OS handle the input method (IME). In this case, key presses need to be sent to the IME instead of the client, and when the IME sends back the actual value it should be sent to the X client in such a way that the keysym gets converted to the Unicode value. One possibility would be to use the OS's built-in IME instead of Wnn or Canna as the back-end for kinput2. In searching for a Japanese IME for X, I found references to XIM. I found a band called XIM out of the UK, but that doesn't help :-) It appears that kinput2 and Wnn or Canna are what I need, but I can't find where to actually download source from. I found RPMs for Intel-based systems, but Macs are not Intel :-( -- Dave Williss--Meddle not in the affairs of dragons, for you are crunchy and taste good with catsup
Re: [Xpert]twinview question
Le lun 01/07/2002 à 19:36, Mark Vojkovich a écrit : > The root window can never change size throughout the X session, > Even with a single head, there is no mechanism in the X-window system > to resize the desktop. XFree86 hotkeys for mode switching merely > change the size of the viewport, not the root window. Could you clarify one point: I tought the RandR extension was done to enable the root window to resize. Am I right ? If yes, how will unaware application react ? Is there some doc somewhere discussing this I could read ? Thanks, Xav ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]xawtv issues with 24bpp matrox x session
I normally stick to 16bpp mode and everything works fine. I wanted to see if maybe I was missing out on any alpha blending/anti-aliasing features that are finally making it's way into programs for X thanks to XRender and since the mga driver for the Matrox G450 doesn't support 32bpp and thus doesn't support alpha layers I was wondering if this is possible at all to see (XRender's alpha blending and such) Since i couldn't go to 32bpp, i tried 24bpp just for the hell of it since it's closer to true color and tv broadcasts and such might seem better. Xawtv seems to have major issues with being 24bpp though. I get funky vertical lines throughout 90% of the tv window. I'm using v4l and overlay with xvideo. no in anything but bpp. Has anyone else had this problem ? When i shrink the window down to about 1/4 normal size it is clear. but stretching it causes more and more of these vertical lines. Problem in the xvideo code? I'm using debian's unstable version of X which i believe is still 4.1 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]A few questions regarding the XFree86-DGA extension
Juliusz Chroboczek <[EMAIL PROTECTED]> writes: > MV> DGA really shouldn't be used and I regret that it's still in the > MV> X-server. I would like it to disappear in XFree86 5.0. > > Mark, > > I fully agree with your feeling, and I am sincerely sorry to say what > I'm about to say. > > There is no denying, though, that there are applications that want to > do client-side rendering -- and I think that's a perfectly legitimate > thing to do. The obvious solutions (PutImage and ShmPutImage) either > involve one copy too many, or else require you to put your rendering > buffers in a shared memory segment. > > I may be mistaken, but as far as I can see, the only way to do a > direct blit from a random client-specified buffer is DGA. Unless we > provide a different way to do that, there is little chance of DGA > going away with no loss. If you are willing to give up the "Random" then, you can use ShmPixmaps or ShmImages and have: Blit from framebuffer specified data to screen - XShmPutImage Blit from RGB data to screen - RENDER Blit from YUV, etc to screen - Xv (I know less about the last.) In the cases that this doesn't work, well, the overhead of an extra memory => memory copy is just not all that significant these days. I don't think it is worth throwing away the security and robustness model and using DGA. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]twinview question
On 1 Jul 2002, Xavier Bestel wrote: > Le lun 01/07/2002 à 19:36, Mark Vojkovich a écrit : > > > The root window can never change size throughout the X session, > > Even with a single head, there is no mechanism in the X-window system > > to resize the desktop. XFree86 hotkeys for mode switching merely > > change the size of the viewport, not the root window. > > Could you clarify one point: I tought the RandR extension was done to > enable the root window to resize. Am I right ? If yes, how will unaware Yes, the RandR extension was created to support that. XFree86's driver model doesn't support RandR though. > application react ? Is there some doc somewhere discussing this I could > read ? > Unaware apps will think the root window is the old size and have artifacts that reflect that. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]twinview question
On Mon, 1 Jul 2002, Mark Vojkovich wrote: :: On Mon, 1 Jul 2002, Dean S. Messing wrote: :: > 1: Do I need to do anything special to enable the xinerama extension :: >mentioned in the Nvidia Readme? I ask because KDE seems :: >to like to put windows up right across the boundary between the :: >two monitors and the Readme indicates that the xinerama extension :: >should prevent this. What am I missing. :: ::The Xinerama extension does not prevent this. The Xinerama :: extension gives the window manager a mechanism to prevent this. :: Window managers must specifically support this. Some do, some don't. :: I don't know about KDE. Some window managers try to do this and :: are broken and have behavior worse than if they did nothing at all :: so we have an option to disable advertising of the Xinerama extension. This is a pain. Is there an easy way to find out what KDE 2.2.2 is capable of? Anyone in the forum running KDE 2.2.2 with TwinView on a single card? Will an upgrade to KDE 3 fix things? Will going to "straight xinerama" be better? :: :: > :: > 2: When I change modes to the 2nd mode KDE keeps the virtual desktop :: >size of the first metamode. The FP shuts off alright but :: >the CRT has a 2800x1200 virtual desktop. How can I make the :: >virtual desktop snap to the CRT resolution when in the second mode? :: :: The root window can never change size throughout the X session, :: Even with a single head, there is no mechanism in the X-window system :: to resize the desktop. XFree86 hotkeys for mode switching merely :: change the size of the viewport, not the root window. :: :: There is that panning domain stuff in TwinView that might at :: least let you prevent the one head from panning outside of its :: square of the screen. Yes, I'll try this. But, unfortunately it does not solve the basic problem. So for example, when I start ImageMagick `display' with an image that's bigger than my 1600x1200 CRT display, and I'm running with the FP off, I should get a "panning window" generated by `display' to let me pan around the displayed image. But I don't because it still thinks my desktop is 2800x1200. Also when the screensaver comes up it is no longer centered in one display but away off to the right. I'll try playing with panning and offset as you suggest and see what happens. Maybe I can try running _two_ xservers (instead of two modes) and hot_key between them? Another pain. This two display stuff isn't all it's cracked up to be :-) :: > :: > 3: This XF86Config file I've cobbled together comes from :: >an older single-head one. So following the stuff above there's :: >all the "Display" subsections I had before. Is this now cruft that :: >I can remove? What about DefaultColorDepth? :: > :: ::I thought DefaultColorDepth was a XFree86 3.x keyword? There :: is a DefaultDepth in 4.x. :: :: :: Mark. Yes, I think I grabbed this from an older XF86Config for 3.3.6. As I understand it, the binary NVidia driver runs at 24 by default so I'm seeing 24 bpp and thinking it's due to the DefaultColorDepth. Any general solutions to my questions will be _greatly_ appreciated. Dean ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Unresolved symbol vgaHWUnmapMem in nv_drv.o for XFree86 4.2.0
Hi, I just graduated from college with a BS in Physics and CS. Besides using Solaris to compile and run programs that I wrote on my school's computer system, I don't have any experience in Unix. I downloaded and installed FreeBSD 4.6 Saturday afternoon, and since then I've been trying to get the x-server to run properly. It seems that after I finish configuring it, whenever I do "startx" I get the error: "Symbol vgaHWUnmapMem from module /usr/X11R6/lib/modules/drivers/nv_drv.o is unresolved!" I've looked online and read about MANY people having unresolved symbol problems (nearly all seem to be posted to this group). However, I cannot find a solution to the problem. Since these posts go back all the way to 1998, I assume that some of these people have probably figured the problem. However, I have no clue. I even re-installed all of FreeBSD to make sure that I'd done it properly. I've deinstalled and reinstalled XFree86 several times. I've also run through the configuration using "xf86cfg -textmode" and "xf86config" both through the /stand/sysinstall program, and through the command line. I'm considering getting the Linux driver for my video card and trying to install it this way, but I don't have any clue if that will work or even fix my problem. According to the XFree86 docs, the "nv" driver is supposed to support GeForce 3 cards. I can even find the card in the list when I do "xf86cfg -textmode". I would appreciate any help someone could give me. As stated, I'm using FreeBSD 4.6 - stable I've installed XFree86 4.2.0 through the normal /stand/sysintsall program supplied with FreeBSD that runs when you install it. Video card: AOpen NVidia GeForce 3 Ti200 with 128MB of DDR RAM I'm using the "nv" driver supplied with XFree86 4.2.0 Below is the full contents of XFree86.0.log Thank you very much in advance! -James Turnbull --- XFree86 Version 4.2.0 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 18 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: FreeBSD 4.6 i386 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Sun Jun 30 23:54:47 2002 (==) Using config file: "/etc/X11/XF86Config" (==) ServerLayout "Layout0" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "Card0" (**) |-->Input Device "Keyboard0" (**) Option "XkbModel" "pc101" (**) XKB: model: "pc101" (**) Option "XkbLayout" "us" (**) XKB: layout: "us" (==) Keyboard: CustomKeycode disabled (**) |-->Input Device "Mouse0" (==) FontPath set to "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/ lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/font s/100dpi/" (==) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules" (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.5 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on freebsd (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="The XFree86 Project" compiled for 4.2.0, 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.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,1a30 card 1043,8088 rev 11 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,1a31 card , rev 11 class 06,04,00 hdr 01 (II) PCI: 00:1d:0: chip 8086,24c2 card 1043,8089 rev 01 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,24c4 card 1043,8089 rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,24c7 card 1043,8089 rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:1d:7: chip 8086,24cd card 1043,8089 rev 01 class 0c,03,20 hdr 00 (II) PCI: 00:1e:0: chip 8086,244e card , rev 81 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,24c0 card , rev 01 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,24cb card 1043,8089 rev 01 class 01,01,8a hdr 00 (II) PCI: 01:00:0: chip 10de,0201 card , rev a3 class 03,00,00 hdr 00 (II) PCI: 02:03:0: chip 13f6,0111 card 1043
Re: [Xpert]twinview question
On Mon, 1 Jul 2002, Dean S. Messing wrote: > > > On Mon, 1 Jul 2002, Mark Vojkovich wrote: > :: On Mon, 1 Jul 2002, Dean S. Messing wrote: > > :: > 1: Do I need to do anything special to enable the xinerama extension > :: >mentioned in the Nvidia Readme? I ask because KDE seems > :: >to like to put windows up right across the boundary between the > :: >two monitors and the Readme indicates that the xinerama extension > :: >should prevent this. What am I missing. > :: > ::The Xinerama extension does not prevent this. The Xinerama > :: extension gives the window manager a mechanism to prevent this. > :: Window managers must specifically support this. Some do, some don't. > :: I don't know about KDE. Some window managers try to do this and > :: are broken and have behavior worse than if they did nothing at all > :: so we have an option to disable advertising of the Xinerama extension. > > This is a pain. > Is there an easy way to find out what KDE 2.2.2 is capable of? > Anyone in the forum running KDE 2.2.2 with TwinView on a single card? > Will an upgrade to KDE 3 fix things? > Will going to "straight xinerama" be better? From the client's point of view there is no difference between actual Xinerama running or NVIDIA's TwinView advertising Xinerama. > Maybe I can try running _two_ xservers (instead of two modes) > and hot_key between them? > Another pain. > Yes, two X-servers with different sized root windows is a solution to the fixed root window size problem, provided you don't mind having to VT switch between the two. MArk. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Setting FP Registers
I am running a Redhat 7.1 installation, but I decided to install XFree86 myself. I installed 4.2.0 from the sources. Everything works fine, except for this error message in my log file: (WW) R128(0): Can't determine panel dimensions, and none specified. Disabling programming of FP registers. I tried adding these lines to the Device section of my XF86Config-4 file, as I saw this in an earlier post: Option"PanelWidth""800" Option"PanelHeight" "600" I still receive the error message though. Am I doing something wrong? Thanks, Kyle Super _ Send and receive Hotmail on your mobile device: http://mobile.msn.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Library Files
I recently installed Xfree86 4.2.0 on a Redhat 7.1 system. Everything seems to be working, but I noticed that when installing some RPMs, the library files located in /usr/X11R6/lib were not being recognized. I tried adding that location to the ld.so.conf file and running ldconfig, but that did not solve the problem. How do I get my system to recogize the XFree86 library files? Thanks, Kyle Super _ Send and receive Hotmail on your mobile device: http://mobile.msn.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Unresolved symbol vgaHWUnmapMem in nv_drv.o for XFree864.2.0
This looks like a FreeBSD specific XFree86 problem, and probably unrelated to the unresolved symbol. The server never got far enough to even load the vgahw module - it segfaulted before then. Probably in the int10 code from the looks of the log file. This is probably not specific to the "nv" driver. Mark. On Mon, 1 Jul 2002, James wrote: > Hi, I just graduated from college with a BS in Physics and CS. Besides > using Solaris to compile and run programs that I wrote on my school's > computer system, I don't have any experience in Unix. I downloaded and > installed FreeBSD 4.6 Saturday afternoon, and since then I've been trying to > get the x-server to run properly. > > It seems that after I finish configuring it, whenever I do "startx" I get > the error: > > "Symbol vgaHWUnmapMem from module /usr/X11R6/lib/modules/drivers/nv_drv.o is > unresolved!" > > I've looked online and read about MANY people having unresolved symbol > problems (nearly all seem to be posted to this group). However, I cannot > find a solution to the problem. Since these posts go back all the way to > 1998, I assume that some of these people have probably figured the problem. > However, I have no clue. I even re-installed all of FreeBSD to make sure > that I'd done it properly. I've deinstalled and reinstalled XFree86 several > times. I've also run through the configuration using "xf86cfg -textmode" > and "xf86config" both through the /stand/sysinstall program, and through the > command line. > > I'm considering getting the Linux driver for my video card and trying to > install it this way, but I don't have any clue if that will work or even fix > my problem. > According to the XFree86 docs, the "nv" driver is supposed to support > GeForce 3 cards. I can even find the card in the list when I do > "xf86cfg -textmode". > > I would appreciate any help someone could give me. > > As stated, I'm using FreeBSD 4.6 - stable > I've installed XFree86 4.2.0 through the normal /stand/sysintsall program > supplied with FreeBSD that runs when you install it. > Video card: AOpen NVidia GeForce 3 Ti200 with 128MB of DDR RAM > I'm using the "nv" driver supplied with XFree86 4.2.0 > > Below is the full contents of XFree86.0.log > Thank you very much in advance! > -James Turnbull > --- > > XFree86 Version 4.2.0 / X Window System > (protocol Version 11, revision 0, vendor release 6600) > Release Date: 18 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: FreeBSD 4.6 i386 [ELF] > Module Loader present > Markers: (--) probed, (**) from config file, (==) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (==) Log file: "/var/log/XFree86.0.log", Time: Sun Jun 30 23:54:47 2002 > (==) Using config file: "/etc/X11/XF86Config" > (==) ServerLayout "Layout0" > (**) |-->Screen "Screen0" (0) > (**) | |-->Monitor "Monitor0" > (**) | |-->Device "Card0" > (**) |-->Input Device "Keyboard0" > (**) Option "XkbModel" "pc101" > (**) XKB: model: "pc101" > (**) Option "XkbLayout" "us" > (**) XKB: layout: "us" > (==) Keyboard: CustomKeycode disabled > (**) |-->Input Device "Mouse0" > (==) FontPath set to > "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/ > lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/font > s/100dpi/" > (==) RgbPath set to "/usr/X11R6/lib/X11/rgb" > (==) ModulePath set to "/usr/X11R6/lib/modules" > (--) Using syscons driver with X support (version 2.0) > (--) using VT number 9 > > (II) Module ABI versions: > XFree86 ANSI C Emulation: 0.1 > XFree86 Video Driver: 0.5 > XFree86 XInput driver : 0.3 > XFree86 Server Extension : 0.1 > XFree86 Font Renderer : 0.3 > (II) Loader running on freebsd > (II) LoadModule: "bitmap" > (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a > (II) Module bitmap: vendor="The XFree86 Project" > compiled for 4.2.0, 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.0, module version = 0.1.0 > ABI class: XFree86 Video Driver, version 0.5 > (II) PCI: Probing config type using method 1 > (II) PCI: Config type is 1 > (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 > (II) PCI: PCI scan (all values are in hex) > (II) PCI: 00:00:0: chip 8086,1a30 card 1043,8088 rev 11 class 06,00,00 hdr > 00 > (II) PCI: 00:01:0: chip 8086,1a31 card , rev 11 class 06,04,00 hdr > 01 > (II) PCI: 00:1d:0: chip 8086,24c2 card 1043,8089 rev 01 class 0c,03,00 hdr >
Re: [Xpert]twinview question
Le lun 01/07/2002 à 20:26, Mark Vojkovich a écrit : > On 1 Jul 2002, Xavier Bestel wrote: > > > Le lun 01/07/2002 à 19:36, Mark Vojkovich a écrit : > > > > > The root window can never change size throughout the X session, > > > Even with a single head, there is no mechanism in the X-window system > > > to resize the desktop. XFree86 hotkeys for mode switching merely > > > change the size of the viewport, not the root window. > > > > Could you clarify one point: I tought the RandR extension was done to > > enable the root window to resize. Am I right ? If yes, how will unaware > > Yes, the RandR extension was created to support that. XFree86's > driver model doesn't support RandR though. Is it something planned in the near future ? Or totally undoable with current X API, and to be done in XFree 5 ? Xav ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Library Files
On Mon, 1 Jul 2002, Kyle Super wrote: > > I recently installed Xfree86 4.2.0 on a Redhat 7.1 system. Everything seems > to be working, but I noticed that when installing some RPMs, the library > files located in /usr/X11R6/lib were not being recognized. I tried adding > that location to the ld.so.conf file and running ldconfig, but that did not > solve the problem. How do I get my system to recogize the XFree86 library > files? > > Thanks, > Kyle Super > What do mean by it not recognizing them? Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Unresolved symbol vgaHWUnmapMem in nv_drv.o for XFree86 4.2.0
Thanks for the info. If it's a FreeBSD problem, should I try to re-install using FreeBSD 4.5? I really don't have a clue what I'd need to do to fix this. Could you point me towards some more information? Thank you, -James Turnbull - Original Message - From: "Mark Vojkovich" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 01, 2002 1:05 PM Subject: Re: [Xpert]Unresolved symbol vgaHWUnmapMem in nv_drv.o for XFree86 4.2.0 > > This looks like a FreeBSD specific XFree86 problem, and probably unrelated > to the unresolved symbol. The server never got far enough to even load > the vgahw module - it segfaulted before then. Probably in the int10 > code from the looks of the log file. This is probably not specific > to the "nv" driver. > > > Mark. > > > On Mon, 1 Jul 2002, James wrote: > > > Hi, I just graduated from college with a BS in Physics and CS. Besides > > using Solaris to compile and run programs that I wrote on my school's > > computer system, I don't have any experience in Unix. I downloaded and > > installed FreeBSD 4.6 Saturday afternoon, and since then I've been trying to > > get the x-server to run properly. > > > > It seems that after I finish configuring it, whenever I do "startx" I get > > the error: > > > > "Symbol vgaHWUnmapMem from module /usr/X11R6/lib/modules/drivers/nv_drv.o is > > unresolved!" > > > > I've looked online and read about MANY people having unresolved symbol > > problems (nearly all seem to be posted to this group). However, I cannot > > find a solution to the problem. Since these posts go back all the way to > > 1998, I assume that some of these people have probably figured the problem. > > However, I have no clue. I even re-installed all of FreeBSD to make sure > > that I'd done it properly. I've deinstalled and reinstalled XFree86 several > > times. I've also run through the configuration using "xf86cfg -textmode" > > and "xf86config" both through the /stand/sysinstall program, and through the > > command line. > > > > I'm considering getting the Linux driver for my video card and trying to > > install it this way, but I don't have any clue if that will work or even fix > > my problem. > > According to the XFree86 docs, the "nv" driver is supposed to support > > GeForce 3 cards. I can even find the card in the list when I do > > "xf86cfg -textmode". > > > > I would appreciate any help someone could give me. > > > > As stated, I'm using FreeBSD 4.6 - stable > > I've installed XFree86 4.2.0 through the normal /stand/sysintsall program > > supplied with FreeBSD that runs when you install it. > > Video card: AOpen NVidia GeForce 3 Ti200 with 128MB of DDR RAM > > I'm using the "nv" driver supplied with XFree86 4.2.0 > > > > Below is the full contents of XFree86.0.log > > Thank you very much in advance! > > -James Turnbull > > --- > > > > XFree86 Version 4.2.0 / X Window System > > (protocol Version 11, revision 0, vendor release 6600) > > Release Date: 18 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: FreeBSD 4.6 i386 [ELF] > > Module Loader present > > Markers: (--) probed, (**) from config file, (==) default setting, > > (++) from command line, (!!) notice, (II) informational, > > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > > (==) Log file: "/var/log/XFree86.0.log", Time: Sun Jun 30 23:54:47 2002 > > (==) Using config file: "/etc/X11/XF86Config" > > (==) ServerLayout "Layout0" > > (**) |-->Screen "Screen0" (0) > > (**) | |-->Monitor "Monitor0" > > (**) | |-->Device "Card0" > > (**) |-->Input Device "Keyboard0" > > (**) Option "XkbModel" "pc101" > > (**) XKB: model: "pc101" > > (**) Option "XkbLayout" "us" > > (**) XKB: layout: "us" > > (==) Keyboard: CustomKeycode disabled > > (**) |-->Input Device "Mouse0" > > (==) FontPath set to > > "/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/ > > lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/font > > s/100dpi/" > > (==) RgbPath set to "/usr/X11R6/lib/X11/rgb" > > (==) ModulePath set to "/usr/X11R6/lib/modules" > > (--) Using syscons driver with X support (version 2.0) > > (--) using VT number 9 > > > > (II) Module ABI versions: > > XFree86 ANSI C Emulation: 0.1 > > XFree86 Video Driver: 0.5 > > XFree86 XInput driver : 0.3 > > XFree86 Server Extension : 0.1 > > XFree86 Font Renderer : 0.3 > > (II) Loader running on freebsd > > (II) LoadModule: "bitmap" > > (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a > > (II) Module bitmap: vendor="The XFree86 Project" > > compiled for 4.2.0, 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/X1
[Xpert]Disabling video card stored pixmaps
A few months ago I asked about slow XCopyArea() calls and the response was that they were due to having one pixmap in the video card's memory and one in system memory. Switching all pixmaps to shared memory pixmaps fixed the problem. Now, we need a remote capable solution. :) Would something as simple as specifying the amount of video ram to be only slightly higher than the fbbpp * resolution be valid or would this screw up hardware cursor and other things? Ideally, we'd like to fix this on the client (code), but a server side hack is not out of the question. Any ideas? Jeff ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]twinview question
On 1 Jul 2002, Xavier Bestel wrote: > Le lun 01/07/2002 à 20:26, Mark Vojkovich a écrit : > > On 1 Jul 2002, Xavier Bestel wrote: > > > > > Le lun 01/07/2002 à 19:36, Mark Vojkovich a écrit : > > > > > > > The root window can never change size throughout the X session, > > > > Even with a single head, there is no mechanism in the X-window system > > > > to resize the desktop. XFree86 hotkeys for mode switching merely > > > > change the size of the viewport, not the root window. > > > > > > Could you clarify one point: I tought the RandR extension was done to > > > enable the root window to resize. Am I right ? If yes, how will unaware > > > > Yes, the RandR extension was created to support that. XFree86's > > driver model doesn't support RandR though. > > Is it something planned in the near future ? Or totally undoable with > current X API, and to be done in XFree 5 ? > I don't know if it's possible to extend XFree86 4 to optionally support that kind of thing without breaking driver compatibility. I would guess not, but I haven't really thought about it much. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Unresolved symbol vgaHWUnmapMem in nv_drv.o for XFree864.2.0
On Mon, 1 Jul 2002, James wrote: > Thanks for the info. > If it's a FreeBSD problem, should I try to re-install using FreeBSD 4.5? > I really don't have a clue what I'd need to do to fix this. Could you point > me towards some more information? > > Thank you, > -James Turnbull I think you should wait for some feedback from FreeBSD users on this list. I would imagine that someone has seen this before. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Disabling video card stored pixmaps
On 1 Jul 2002, Jeff Brubaker wrote: > A few months ago I asked about slow XCopyArea() calls and the response > was that they were due to having one pixmap in the video card's memory > and one in system memory. Switching all pixmaps to shared memory > pixmaps fixed the problem. > > Now, we need a remote capable solution. :) > > Would something as simple as specifying the amount of video ram to be > only slightly higher than the fbbpp * resolution be valid or would this > screw up hardware cursor and other things? > > Ideally, we'd like to fix this on the client (code), but a server side > hack is not out of the question. Any ideas? > You can disable offscreen pixmaps with Option "XaaNoOffscreenPixmaps" Using shared pixmaps was just a way to prohibit putting them in video ram for your app without effecting other apps. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon HARDWARE_CLIP_SCREEN_TO_SCREEN_COPY fixed?
On 1 Jul 2002, Michel [ISO-8859-1] Dänzer wrote: > Well, I wouldn't measure the non-triviality in lines of code. :) It's > mostly due to Kevin's cleanups of the formatting, isn't it? Thanks for the response. I guess I should sit tight until your patch hits the main CVS tree before downloading and recompiling. -a ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Unresolved symbol vgaHWUnmapMem in nv_drv.o for XFree86 4.2.0
>I think you should wait for some feedback from FreeBSD users on this > list. I would imagine that someone has seen this before. Ok, I'll do that. I know stuff like this has been in this list before -- I was reading through a lot of them. However, I've never seen a fix to it. Either the people figured it out or stopped asking for some other reason. It's not a driver problem, is it? Thank you very much. -James Turnbull ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Disabling video card stored pixmaps
On Mon, 2002-07-01 at 16:59, Mark Vojkovich wrote: > Option "XaaNoOffscreenPixmaps" Thanks, Mark! Jeff ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]PATCH: X-Video support for Radeon 8500
On Thu, 27 Jun 2002, James Ralston wrote: > On Wed, 26 Jun 2002, Keith Packard wrote: > > > A single binary now works on all of my radeon chips (7500, M6, > > 8500). It needs testing on earlier chips (SDR, DDR radeons, 7000, > > 7200). > > I have access to a 64MB DDR VIVO; I will test your revised patch on > it and report back... Okay, I had a chance to do some testing with Keith's Radeon X-Video patches. The good news is that on the Radeons I have access to (Radeon 64 DDR, Radeon Mobility M6 LY, Radeon 8500 128MB), X-Video works. Ok, now the bad news... In the 2002-06-23 CVS checkout, 3D support doesn't work for either the Radeon 64 DDR or the Radeon Mobility M6 LY. This *isn't* related to the patch, as I tested the 2002-06-23 CVS checkout both with and without it; 3D support doesn't work either way. Since I'm a Red Hat user, the way I was building XFree86 was via rpm (using Mike Harris' SRPM package from Red Hat 7.3). When I built from CVS, I was still applying all of Mike's patches that didn't conflict with CVS. Thinking that perhaps Mike's patches were breaking something in recent CVS builds (even though they applied cleanly), I rebuilt XFree86 from CVS without applying any Red Hat patches whatsoever. Unfortunately; this didn't change the results of my 3D support tests; 3D support still didn't work for either the Radeon 64 DDR or the Radeon Mobility M6 LY. So, it would appear that 3D support for the Radeon 64 DDR and the Radeon Mobility M6 LY (and I suspect all Radeons) was accidentally broken in CVS sometime on or before 2002-06-23. At any rate, since Keith committed his patch to CVS, now I'm off to update my CVS tree and rebuild. I'll report back when I have a chance to test the latest CVS. Regards, -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Unresolved symbol vgaHWUnmapMem in nv_drv.o for XFree864.2.0
On Mon, 1 Jul 2002, James wrote: > >I think you should wait for some feedback from FreeBSD users on this > > list. I would imagine that someone has seen this before. > > Ok, I'll do that. I know stuff like this has been in this list before -- I > was reading through a lot of them. However, I've never seen a fix to it. > Either the people figured it out or stopped asking for some other reason. I suspect that it's not related to the unresolved symbol. The vgahw module wasn't loaded yet so I'd expect that and other vgahw symbols to be unresolved at that point. > > It's not a driver problem, is it? I don't think so since it works on Linux. Does your server have debug info in it? Could you get a gdb backtrace on the core dump? That may narrow down the problem. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon HARDWARE_CLIP_SCREEN_TO_SCREEN_COPY fixed?
On 1 Jul 2002, Michel Dänzer wrote: > On Mon, 2002-07-01 at 17:00, Dr Andrew C Aitchison wrote: > > On 1 Jul 2002, Michel Dänzer wrote: > > > > > On Mon, 2002-07-01 at 01:38, Andrew P. Lentvorski wrote: > > > > I note that HARDWARE_CLIP_SCREEN_TO_SCREEN_COPY is enabled on > > > > the latest Radeon accelerated driver. > > > > > > > > Has the bug with this been fixed? > > > > > > No, it has required rather serious surgery, please try > > > > > > http://www.penguinppc.org/~daenzer/DRI/radeon_accel.diff > > > > > > It's against DRI CVS and also contains other minor fixes but > > > should be straightforward to merge into XFree86 CVS. I suspect > > > there are still problems related to hardware clipping and/or > > > transparency, but at least the teststipple program someone > > > posted here works now. > > > > Merging with XFree86 CVS is highly non-trivial (the .rej reject > > output is longer than the patch :-(). > > Well, I wouldn't measure the non-triviality in lines of code. :) > It's mostly due to Kevin's cleanups of the formatting, isn't it? Alas, it probably isn't: the Radeon X-Video patch which Keith committed on 2002-06-27 changed many parts of radeon_accel.c and radeon.h. :( Trying to apply your patch to current CVS yields: 21 out of 36 hunks FAILED -- saving rejects to file radeon_accel.c.rej Either tonight or tomorrow night, I'm going to be rebuilding from current CVS. I will attempt to integrate your patch then. > > While attempting to generate a merge I note that the RADEONInfoRec > > struct has no member dp_gui_master_cntl_cache or trans_color. > > Does radeon.h need patching too ? > > Yes, thanks for pointing that out. Patch updated. Well, at least the 2-line patch to radeon.h applied cleanly. ;) -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Unresolved symbol vgaHWUnmapMem in nv_drv.o for XFree86 4.2.0
> > It's not a driver problem, is it? >I don't think so since it works on Linux. See, the thing is, there are other people who have installed the same FreeBSD version as I have with no problems, but they have different video cards. So XFree86 4.2.0 has worked on FreeBSD 4.6. >Does your server have > debug info in it? Could you get a gdb backtrace on the core dump? That > may narrow down the problem. I'm really new to this (2 days). Could you please tell me where I could go to find out that information? Thank you, -James Turnbull ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon HARDWARE_CLIP_SCREEN_TO_SCREEN_COPY fixed?
On Tue, 2002-07-02 at 00:17, James Ralston wrote: > On 1 Jul 2002, Michel Dänzer wrote: > > > On Mon, 2002-07-01 at 17:00, Dr Andrew C Aitchison wrote: > > > On 1 Jul 2002, Michel Dänzer wrote: > > > > > > > On Mon, 2002-07-01 at 01:38, Andrew P. Lentvorski wrote: > > > > > I note that HARDWARE_CLIP_SCREEN_TO_SCREEN_COPY is enabled on > > > > > the latest Radeon accelerated driver. > > > > > > > > > > Has the bug with this been fixed? > > > > > > > > No, it has required rather serious surgery, please try > > > > > > > > http://www.penguinppc.org/~daenzer/DRI/radeon_accel.diff > > > > > > > > It's against DRI CVS and also contains other minor fixes but > > > > should be straightforward to merge into XFree86 CVS. I suspect > > > > there are still problems related to hardware clipping and/or > > > > transparency, but at least the teststipple program someone > > > > posted here works now. > > > > > > Merging with XFree86 CVS is highly non-trivial (the .rej reject > > > output is longer than the patch :-(). > > > > Well, I wouldn't measure the non-triviality in lines of code. :) > > It's mostly due to Kevin's cleanups of the formatting, isn't it? > > Alas, it probably isn't: the Radeon X-Video patch which Keith > committed on 2002-06-27 changed many parts of radeon_accel.c and > radeon.h. :( Didn't even touch radeon_accel.c. > Trying to apply your patch to current CVS yields: > > 21 out of 36 hunks FAILED -- saving rejects to file radeon_accel.c.rej Kevin E. Martin cleaned the driver up a while ago. Look at the rejects and you see that they are only due to formatting changes. -- 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]Unresolved symbol vgaHWUnmapMem in nv_drv.o for XFree864.2.0
On Mon, 1 Jul 2002, James wrote: > > > It's not a driver problem, is it? > >I don't think so since it works on Linux. > > See, the thing is, there are other people who have installed the same > FreeBSD version as I have with no problems, but they have different video > cards. So XFree86 4.2.0 has worked on FreeBSD 4.6. Could be something special that the "nv" driver is doing that makes it not work on FreeBSD, but I've never heard of that. I think somebody would have complained already. > > >Does your server have > > debug info in it? Could you get a gdb backtrace on the core dump? That > > may narrow down the problem. > > I'm really new to this (2 days). Could you please tell me where I could go > to find out that information? > 1) If core dumps aren't turned on in your shell, turn them on. For tcsh it's a command like "limit coredumpsize 20" For bash it was something like "ulimit -c". See the man page. 2) When the server crashes and you get a core file, run gdb on it. gdb -c core /usr/X11R6/bin/XFree86 3) From the gdb prompt type "bt" to get a backtrace. Hopefully you have symbols and it will give us an idea where it actually segfaulted. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]PATCH: X-Video support for Radeon 8500
On Mon, 2002-07-01 at 23:53, James Ralston wrote: > On Thu, 27 Jun 2002, James Ralston wrote: > > In the 2002-06-23 CVS checkout, 3D support doesn't work for either the > Radeon 64 DDR or the Radeon Mobility M6 LY. This *isn't* related to > the patch, as I tested the 2002-06-23 CVS checkout both with and > without it; 3D support doesn't work either way. > > Since I'm a Red Hat user, the way I was building XFree86 was via rpm > (using Mike Harris' SRPM package from Red Hat 7.3). When I built from > CVS, I was still applying all of Mike's patches that didn't conflict > with CVS. Thinking that perhaps Mike's patches were breaking > something in recent CVS builds (even though they applied cleanly), I > rebuilt XFree86 from CVS without applying any Red Hat patches > whatsoever. Unfortunately; this didn't change the results of my 3D > support tests; 3D support still didn't work for either the Radeon 64 > DDR or the Radeon Mobility M6 LY. > > So, it would appear that 3D support for the Radeon 64 DDR and the > Radeon Mobility M6 LY (and I suspect all Radeons) was accidentally > broken in CVS sometime on or before 2002-06-23. How does it fail? Note that much progress has been made on the 3D driver in DRI CVS, while it's still basically the same as in 4.2.0 in XFree86 CVS. -- 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]PATCH: X-Video support for Radeon 8500
Around 17 o'clock on Jul 1, James Ralston wrote: > So, it would appear that 3D support for the Radeon 64 DDR and the > Radeon Mobility M6 LY (and I suspect all Radeons) was accidentally > broken in CVS sometime on or before 2002-06-23. It's been broken for me on my M6 LY ever since Mesa 4 hit XFree86 CVS shortly after 4.2. I use the DRI tcl-0-0 branch on my 7500, but that wasn't working on my M6 when I last tried it a month or so ago. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Setting FP Registers
On Mon, 2002-07-01 at 21:46, Kyle Super wrote: > > I am running a Redhat 7.1 installation, but I decided to install XFree86 > myself. I installed 4.2.0 from the sources. Everything works fine, except > for this error message in my log file: > > (WW) R128(0): Can't determine panel dimensions, and none specified. > Disabling programming of FP registers. > > I tried adding these lines to the Device section of my XF86Config-4 file, as > I saw this in an earlier post: > > Option"PanelWidth""800" > Option"PanelHeight" "600" > > I still receive the error message though. Am I doing something wrong? No. I added these options primarily with PPC machines which can't determine the dimensions through a BIOS or DDC in mind, it's possible that they get overridden by either of these methods on x86. If that leads to bogus dimensions, there's a problem anyway. -- 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]Radeon HARDWARE_CLIP_SCREEN_TO_SCREEN_COPY fixed?
On 2 Jul 2002, Michel Dänzer wrote: > On Tue, 2002-07-02 at 00:17, James Ralston wrote: > > On 1 Jul 2002, Michel Dänzer wrote: > > > > > On Mon, 2002-07-01 at 17:00, Dr Andrew C Aitchison wrote: > > > > On 1 Jul 2002, Michel Dänzer wrote: > > > > > > > > > On Mon, 2002-07-01 at 01:38, Andrew P. Lentvorski wrote: > > > > > > I note that HARDWARE_CLIP_SCREEN_TO_SCREEN_COPY is enabled > > > > > > on the latest Radeon accelerated driver. > > > > > > > > > > > > Has the bug with this been fixed? > > > > > > > > > > No, it has required rather serious surgery, please try > > > > > > > > > > http://www.penguinppc.org/~daenzer/DRI/radeon_accel.diff > > > > > > > > > > It's against DRI CVS and also contains other minor fixes but > > > > > should be straightforward to merge into XFree86 CVS. I > > > > > suspect there are still problems related to hardware > > > > > clipping and/or transparency, but at least the teststipple > > > > > program someone posted here works now. > > > > > > > > Merging with XFree86 CVS is highly non-trivial (the .rej > > > > reject output is longer than the patch :-(). > > > > > > Well, I wouldn't measure the non-triviality in lines of code. :) > > > It's mostly due to Kevin's cleanups of the formatting, isn't it? > > > > Alas, it probably isn't: the Radeon X-Video patch which Keith > > committed on 2002-06-27 changed many parts of radeon_accel.c and > > radeon.h. :( > > Didn't even touch radeon_accel.c. > > > Trying to apply your patch to current CVS yields: > > > > 21 out of 36 hunks FAILED -- saving rejects to file > > radeon_accel.c.rej > > Kevin E. Martin cleaned the driver up a while ago. Look at the > rejects and you see that they are only due to formatting changes. You're correct; I was confusing radeon_accel.c and radeon_video.c. My bad. I'll integrate your patch into current CVS, test it, and make the revised version available. -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Unresolved symbol vgaHWUnmapMem in nv_drv.o for XFree86 4.2.0
>Could be something special that the "nv" driver is doing that makes > it not work on FreeBSD, but I've never heard of that. I think somebody > would have complained already. I'd think so. But it looks like people have come up with similar problems: http://www.google.com/search?hl=en&lr=&ie=ISO-8859-1&as_qdr=all&q=nv_drv.o%2 Bunresolved%2B2002+site%3Axfree86.org I can't seem to find any solutions, though. :( >2) When the server crashes and you get a core file, run gdb on it. > > gdb -c core /usr/X11R6/bin/XFree86 Where core is the XFree86.core file in my root directory? > >3) From the gdb prompt type "bt" to get a backtrace. Hopefully you > have symbols and it will give us an idea where it actually segfaulted. Ok, I did this on XFree86.core found in my root directory. Here is the output I got (I'm typing this, since I don't know how to use gdb to send output to files): #0 0x282187b4 in kill () from /usr/lib/libc.so.4 #1 0x28258b26 in abort () from /usr/lib/libc.so.4 #2 0x806cd9a in ddxGiveUp () #3 0x806ce3e in AbortDDX () #4 0x80d2e88 in GiveUp () #5 0x80d41c9 in FatalError () #6 0x807ed39 in xf86SigHandler () #7 0xbfbfffac in ?? () #8 0x87ec290 in ?? () #9 0x87cca4a in ?? () #10 0x806c260 in InitOutput () #11 0x80be47a in main () #12 0x806badd in _start () Thank you, -James Turnbull ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]PATCH: X-Video support for Radeon 8500
On Tue, 2002-07-02 at 01:28, Keith Packard wrote: > > Around 17 o'clock on Jul 1, James Ralston wrote: > > > So, it would appear that 3D support for the Radeon 64 DDR and the > > Radeon Mobility M6 LY (and I suspect all Radeons) was accidentally > > broken in CVS sometime on or before 2002-06-23. > > It's been broken for me on my M6 LY ever since Mesa 4 hit XFree86 CVS > shortly after 4.2. > > I use the DRI tcl-0-0 branch on my 7500, but that wasn't working on my M6 > when I last tried it a month or so ago. The TCL branch has been merged into the trunk, which should work with all Radeons again. Please report to dri-devel if it doesn't. -- 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]Unresolved symbol vgaHWUnmapMem in nv_drv.o for XFree864.2.0
On Mon, 1 Jul 2002, James wrote: > #0 0x282187b4 in kill () from /usr/lib/libc.so.4 > #1 0x28258b26 in abort () from /usr/lib/libc.so.4 > #2 0x806cd9a in ddxGiveUp () > #3 0x806ce3e in AbortDDX () > #4 0x80d2e88 in GiveUp () > #5 0x80d41c9 in FatalError () > #6 0x807ed39 in xf86SigHandler () > #7 0xbfbfffac in ?? () > #8 0x87ec290 in ?? () > #9 0x87cca4a in ?? () > #10 0x806c260 in InitOutput () > #11 0x80be47a in main () > #12 0x806badd in _start () > OK, that's not too useful. Those are probably in modules someplace and you'd need the special gdb to resolve those. Lets see what some FreeBSD people have to say. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]A few questions regarding the XFree86-DGA extension
Owen Taylor wrote: > Juliusz Chroboczek <[EMAIL PROTECTED]> writes: > > >>MV> DGA really shouldn't be used and I regret that it's still in the >>MV> X-server. I would like it to disappear in XFree86 5.0. >> >>Mark, >> >>I fully agree with your feeling, and I am sincerely sorry to say what >>I'm about to say. >> >>There is no denying, though, that there are applications that want to >>do client-side rendering -- and I think that's a perfectly legitimate >>thing to do. The obvious solutions (PutImage and ShmPutImage) either >>involve one copy too many, or else require you to put your rendering >>buffers in a shared memory segment. >> >>I may be mistaken, but as far as I can see, the only way to do a >>direct blit from a random client-specified buffer is DGA. Unless we >>provide a different way to do that, there is little chance of DGA >>going away with no loss. >> > > If you are willing to give up the "Random" then, you can use ShmPixmaps > or ShmImages and have: > > Blit from framebuffer specified data to screen - XShmPutImage > Blit from RGB data to screen - RENDER > Blit from YUV, etc to screen - Xv > > (I know less about the last.) I'll add that image transfers can also be done via OpenGL using direct rendering. That would be a more secure and reliable as well. > In the cases that this doesn't work, well, the overhead of an extra > memory => memory copy is just not all that significant these days. > I don't think it is worth throwing away the security and robustness > model and using DGA. I'd like to see DGA go away, too. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Unresolved symbol vgaHWUnmapMem in nv_drv.o for XFree86 4.2.0
Ok. Thank you very much for your help and concern. :) -James Turnbull - Original Message - From: "Mark Vojkovich" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 01, 2002 5:57 PM Subject: Re: [Xpert]Unresolved symbol vgaHWUnmapMem in nv_drv.o for XFree86 4.2.0 > On Mon, 1 Jul 2002, James wrote: > > > #0 0x282187b4 in kill () from /usr/lib/libc.so.4 > > #1 0x28258b26 in abort () from /usr/lib/libc.so.4 > > #2 0x806cd9a in ddxGiveUp () > > #3 0x806ce3e in AbortDDX () > > #4 0x80d2e88 in GiveUp () > > #5 0x80d41c9 in FatalError () > > #6 0x807ed39 in xf86SigHandler () > > #7 0xbfbfffac in ?? () > > #8 0x87ec290 in ?? () > > #9 0x87cca4a in ?? () > > #10 0x806c260 in InitOutput () > > #11 0x80be47a in main () > > #12 0x806badd in _start () > > > >OK, that's not too useful. Those are probably in modules > someplace and you'd need the special gdb to resolve those. Lets > see what some FreeBSD people have to say. > > > Mark. > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Library Files
When I try to install an RPM requiring a library file in the /usr/X11R6/lib directory, the rpm says the library is missing. Thanks, Kyle Super _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Setting FP Registers
Is there anything I can do about the warning? I am not sure it really does anything anyhow..the x server starts up fine. Thanks, Kyle Super _ Send and receive Hotmail on your mobile device: http://mobile.msn.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: [Dri-devel] r128, DRI and XaaNoPixmapCache
On Mon, 2002-07-01 at 09:24, Peter Surda wrote: > > I just found out that unless you use XaaNoPixmapCache, dri on r128 freezes (== > complete system lockup) pretty often. I use yesterday's XF86 CVS. You might see it more often with current DRI CVS, because there's more 2D acceleration with DRI enabled there. :/ > Well, I thought it might be a good idea to write this on the webpage or into > docs with BIG letters, because otherwise gaming is pretty unusable if it > freezes every hour or so. Maybe you can fix it instead? It could be a similar problem to the one Tim Smith just tracked down in the radeon driver: it didn't always have the 3D engine wait for the 2D engine to go idle before doing something (see the RADEON_WAIT_UNTIL_[23]D_IDLE() macros). I don't think the r128 driver has any of this yet. -- 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]SIS630 Chip Set
Hi there I have an SIS630 chipset on a notebook, that seems to work ok under X, but if you swap back to a virtual console the screen turns to junk. Is this a configuration issue or a driver bug in X4.2.0 Protocol Version 11 revision 0 vendor release 6600. FreeBSD package 4.2.0_1,1. Thanks David Hunt ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]ATI Expert 2000
Hi Everyone, I'm new to this list. I joined because I have an ATI Expert 2000 card. I have Mandrake 8.2 with the default Xfree 4.2.0 installed. I am experiencing random lockups. The whole machine locks up. I can move the mouse pointer around but cannot click on anything. The ONLY thing that works is either a manual machine reset or Alt+SysReq+K which kills X and allows me to restart X with the mouse. I've been reading about the problems others have had with this driver/card, is there any easy workaround or fix for this problem? I mean, is there an easy hack I can perform that will stop these annoying lockups? Also, I have an ATI Radeon 7200 card that I cannot get setup. Does Xfree 4.2.0 support this card? Is this 7200 a good card? Thanks for your patience ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Unresolved symbol vgaHWUnmapMem in nv_drv.o for XFree86 4.2.0
When I run XFree86 -configure the output changes to what I pasted in below. Hopefully this will give people some cluse. Thanks, -James Turnbull --- XFree86 Version 4.2.0 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 18 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: FreeBSD 4.6 i386 [ELF] Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/XFree86.0.log", Time: Mon Jul 1 21:26:26 2002 (--) Using syscons driver with X support (version 2.0) (--) using VT number 9 (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.5 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on freebsd (II) LoadModule: "bitmap" (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor="The XFree86 Project" compiled for 4.2.0, 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.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,1a30 card 1043,8088 rev 11 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,1a31 card , rev 11 class 06,04,00 hdr 01 (II) PCI: 00:1d:0: chip 8086,24c2 card 1043,8089 rev 01 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,24c4 card 1043,8089 rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,24c7 card 1043,8089 rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:1d:7: chip 8086,24cd card 1043,8089 rev 01 class 0c,03,20 hdr 00 (II) PCI: 00:1e:0: chip 8086,244e card , rev 81 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,24c0 card , rev 01 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,24cb card 1043,8089 rev 01 class 01,01,8a hdr 00 (II) PCI: 01:00:0: chip 10de,0201 card , rev a3 class 03,00,00 hdr 00 (II) PCI: 02:03:0: chip 13f6,0111 card 1043,80e2 rev 10 class 04,01,00 hdr 00 (II) PCI: 02:0a:0: chip 1317,0985 card 1317,0574 rev 11 class 02,00,00 hdr 00 (II) PCI: 02:0b:0: chip 9005,0080 card 9005,e2a0 rev 02 class 01,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.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) UnloadModule: "scanpci" (II) Unloading /usr/X11R6/lib/modules/libscanpci.a (II) Host-to-PCI bridge: (II) PCI-to-ISA bridge: (II) PCI-to-PCI bridge: (II) PCI-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 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0x - 0x (0x0) MX[B] (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x08 (VGA_EN is set) (II) Bus 1 I/O range: (II) Bus 1 non-prefetchable memory range: [0] -1 0xee00 - 0xef5f (0x160) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0xef70 - 0xf7ff (0x890) MX[B] (II) Bus 2: bridge is at (0:30:0), (0,2,2), BCTRL: 0x06 (VGA_EN is cleared) (II) Bus 2 I/O range: [0] -1 0xb000 - 0xb0ff (0x100) IX[B] [1] -1 0xb400 - 0xb4ff (0x100) IX[B] [2] -1 0xb800 - 0xb8ff (0x100) IX[B] [3] -1 0xbc00 - 0xbcff (0x100) IX[B] (II) Bus 2 non-prefetchable memory range: [0] -1 0xec80 - 0xed7f (0x100) MX[B] (II) Bus 2 prefetchable memory range: [0] -1 0xef60 - 0xef6f (0x10) MX[B] (II) Bus -1: bridge is at (0:31:0), (0,-1,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus -1 I/O range: (II) Bus -1 non-prefetchable memory range: (II) Bus -1 prefetchable memory range: (--) PCI:*(1:0:0) NVidia GeForce3 Ti 200 rev 163, Mem @ 0xee00/24, 0xf000/27, 0xef80/19, BIOS @ 0xef7f/16 List of video drivers: atimisc r128 radeon mga glint nv tga s3 s3virge sis rendition neomagic i740 tdfx savage cirrus vmware tseng trident chips apm fbdev i128 ati i810 ark cyrix siliconmotion vesa vga (II) LoadModule: "atimisc" (II) Loading /usr/X11R6/lib/modules/drivers/atimisc_drv.o (II) Module atimisc: vendor="The XFree86 Project" compiled for 4.2.0, module version = 6.4.8 Module c
Re: [Xpert]Best way to handle Resize and move ?
tchiwam wrote: > I don't know if this belong here at all so please reply so reply to me > directly. > > I am Writing some simple GLX viewer and I am wondering what is the best > way to handle resize and move since one render takes few seconds. I know > that expose has a count that you can use to redraw, but for the Configure > Notify what is the best way to Fix it so it doesn't redraw all the frames > on each resize or move step ? Philippe, I'll add to Mark's comments by saying some hw/driver configurations can help minimize expose events. If your hardware supports RGB overlays, and the driver supports two seperate cliplists for image and overlay planes, then expose events can be minimized. Your GUI (including all pop up and transient windows) would run in the overlays (they would need to be your default visual), and then your application should create it's main viewing window in the image planes. In this configuration, transient overlay windows do not destroy color data in the image planes. Consequently, the server would not need to generate expose events for this case. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Basic QUS
Hello All, If i am running one client application in local machine and the remote server sends the event, Expose Event, notifications to the client application thru XProtocol. Now client application need to redraw its content in the local machine screen. For this Expose operation whether Client application will contact the remote server [ server does not know client machine HW, server is responsible for all HW related operations(?) ] OR it will handle locally. [ Thru Xserver only we can contact the HW(?), Locally there no Xserver ] Explain the steps related to it. Thanks, -- --==| Bharathi S | BSB-364 DONLab | IIT-Madras |==-- Like friendship what's so hard to gain? That guards one against acts villain? *In Tirukkural of Holy Tamil poet Tiruvalluvar. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
