[Xpert]give option interactively to the shadowfb ( rotation )
Hi how can i give the shadowfb interactively an option , so that it would rotate the screen live without the need to restart the X-server i know how to rotate , but i dont know how to do that in realtime ( on a press of a butten --- doing a command ) Rob ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Larger than Largo - load testing X windows
HI! 1) Xnee can record X11 data (e.g. Events) and distribute them. It has no built-in way for faking events from another X session than itself, but if you find Xnee interresting enough I can look into that. 2) With Xnee you can record a users session and later on (or simultaneously) replay and distribute the session. 3) Benchmarking, no... Xnee can be found at http://www.sandklef.com/xnee/ Best regards, Henrik /hesa On Tue, 2002-04-23 at 04:37, Stuart Guthrie wrote: > There is a green field site in Australia that > could be potentially larger than Largo. They wish to > test more than 450 users running thin-client X on a > server without having to have 450 client terminals. Is > there a simple method to do this, I've thought of: > > 1) Recording X network packets then sending them from > multiple dummy 'clients' on the same PC. (This was > done during the Mindcraft benchmarking episode by > simulating 'netbench'). > 2) Some sort of scripting process that can simulate a > use on the server. > 3) Expensive load testing software eg mercury > interactive (not an option). > > As you can see, this is not my area of expertise but > help is most appreciated. > > Any ideas most welcome, > > Stuart Guthrie > > > __ > Do You Yahoo!? > Yahoo! Games - play chess, backgammon, pool and more > http://games.yahoo.com/ > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert > > -- Henrik Sandklef http://www.sandklef.com/hesa/ Email [EMAIL PROTECTED] Software http://www.sandklef.com/software/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Why no RGBA visual in XFree 4.1 software Mesa?
Unfortunately, I've had no luck with this problem on newbie or #xfree86, so hopefully one of you has the answer -- upgrading to the latest 4.1.0-16 Debian packages hasn't changed anything. And if not, I'll accept pointers to documentation that will (somewhat gently) introduce me to the Mesa and/or XF4 code bases, and I'll try to figure it out myself . . . . Despite what it says below, I have not attached all of those files . . . the newbie MLM barfed the first time I sent it, claiming the mail was too big, so I suspect xpert's MLM may do the same. Ask if you want everything, but this time I've attached just the output from xdpyinfo and glxinfo. -'f - Forwarded message from Geoffrey Broadwell <[EMAIL PROTECTED]> - I'm trying to get Perl's OpenGL support working on my systems, which do not currently have hardware acceleration support under Mesa. However, Perl's OpenGL support requires an RGBA visual, but for some reason the visuals available under software Mesa (the one builtin to XFree 4.1) are all RGB-only for me. I've hit the same problem on both a laptop and a desktop, both installed recently with Debian Woody, and both running the 4.1.0-14 xfree packages. The XF86Config-4 files were both built using the debconf magic in the xfree packages. Both are running at 1024x768, 24-bit color, with 4MB RAM. The systems both have lots of system memory available, 128MB on one, and 256MB on the other. Attached are the output of xdpyinfo and glxinfo, and the contents of the XF86Config-4 and XFree86.0.log files. Anyone have any clue what's going on? As far as I can interpret the tea leaves, it looks like I'm really running with 32-bit pixels, so I don't see a problem there . . . . -'f name of display: :0.0 display: :0 screen: 0 direct rendering: No server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context client glx vendor string: SGI client glx version string: 1.2 client glx extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context GLX extensions: GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context OpenGL vendor string: VA Linux Systems, Inc. OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.2 Mesa 3.4.2 OpenGL extensions: GL_ARB_multitexture, GL_EXT_abgr, GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract glu version: 1.3 glu extensions: GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x23 24 tc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None 0x24 24 tc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None 0x25 24 dc 0 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None 0x26 24 dc 0 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None name of display::0.0 version number:11.0 vendor string:The XFree86 Project, Inc vendor release number:4011 XFree86 version: 4.1.0.1 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, LSBFirst, 32 image byte order:LSBFirst number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0x1f0, revert to Parent number of extensions:28 BIG-REQUESTS DOUBLE-BUFFER DPMS Extended-Visual-Information FontCache GLX LBX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RECORD RENDER SECURITY SGI-GLX SHAPE SYNC TOG-CUP XC-APPGROUP XC-MISC XFree86-Bigfont XFree86-DGA XFree86-Misc XFree86-VidModeExtension XIE XInputExtension XKEYBOARD XTEST XVideo default screen number:0 number of screens:1 screen #0: dimensions:1024x768 pixels (302x232 millimeters) resolution:86x84 dots per inch depths (7):24, 1, 4, 8, 15, 16, 32 root window id:0x31 depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x20 default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store NO, save-unders NO largest cursor:64x64 current input event mask:0x5a20bd KeyPressMask ButtonPressMask ButtonReleaseMask EnterWindowMask LeaveWindowMask PointerMotionHintMask ButtonMotionMask Structure
[Xpert]XF 4.2 (cvs april 7) Nvidia GeForce2 Go (bug) - Flatpanel Dell Inspiron
First of all I'd like to report a possible bug I'm not sure where the appropriate place to do that is. I'm using xfree built from april 7 cvs under NetBSD 1.5. The video chipset is the Nvidia GeForce2 Go - distributed with Dell mobile Inspiron 8000's. bug #1 (bug?) When x is required to draw a lot of high contrast edges there are noticable horizontal white lines that flicker on the left side of the root window. It's reproducable with an all black root window and a lot of white backgrounded xterm's. (opening and running xmms in addition to or something that has a timer continually updating helps to reproduce the undesired effect. bug #2 (possibly the fault of x) If a ps/2 mouse is plugged into the notebook while x is running all mouse devices become unusable. It's only remedied by exiting x and restarting it. It's reproducable by starting x and plugging in a ps/2 mouse. I'm not entirely sure if this is the fault of the operating system or x. update #1 I reported a problem where if the screen was blanked by x while the notebook was running on dc power the screen was being improperly re-drawn when it was un-blanked. Someone had replied to this and said they were getting ahold of a similar unit to try and reproduce can anyone comment on whether or not it's been fixed? Anyway thats the end, Thanks Rob ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]UPDATE kernel module version incorrect
On Mon, 22 Apr 2002 [EMAIL PROTECTED] wrote: > I downloaded and compiled the DRM drivers from xfee86.org as suggested > by two very helpful people. I copied the r128.o file to > /lib/modules/2.4.9-31/kernel/drivers/char/drm/r128.o and restarted X. > I checked the permissions so don't tell me to fix that. Stupid question. Did you unload the module (with modload -r perhaps) or reboot ? If not, the old module will still be in use even though the file does not exist. > It would appear that the version on xfree86.org is not any newer > than what I already had. Perhaps I copied it to the wrong location? If you compiled XFree86 yourself, you can separately compile the module with: cd xc/programs/Xserver/hw/xfree86/os-support/linux/drm/kernel make -f Makefile.linux this will give you a module which matches your kernel and your X 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
Re: [Xpert]xfree86 3.3.5 to 4.2.0
Hi Faruk xf86AllocateOffscreenLinear seems to be right function. The pixmap cache thing was never working anyway because greedy 2D driver was using all the offscreen memory for pixmap cache and that was never fixed in xfree 3.x check out RADEONAllocateMemory to see an example on how to use xf86AllocateOffscreenLinear. If you need any help with reading my lousy code please e-mail me. -- Dominik Behr On Mon, 22 Apr 2002 13:23:49 -0600 Faruk Grozdanic <[EMAIL PROTECTED]> wrote: > Hello, > > I am trying to port the utah-glx s3savage drivers from xfree86 3.3.x to > 4.2.0 . Old code calls xf86AccelInfoRec.PixmapCacheMemoryStart & > xf86AccelInfoRec.PixmapCacheMemoryEnd to get the memory range to use. > In xf86 4.2.0 these do not exist. My understanding is to use > xf86AllocateOffscreenLinear (from xf86fbman.h) for this task. Can I call > this function directly or should I use FBManagerFuncs structure to do this? > Also, if there is a better way of allocatiing VideoRam please let me know. > > Thanks > > Faruk G. > > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Using Radeon with two heads?
> I tried a two-headed configuration, with the CRT defined in separate monitor > and device sections. That worked once or twice, but usually caused the LCD > to bloom. I've tried changing the modules, excluding various ones in some > experiments. It seems to be very sensitive to whether the monitor (a > Viewsonic G810) is connected, so it's some interaction of the laptop BIOS and > DDC, I guess. For example, when I have a single-screen configuration, set to > 1280x1024 (so that both the CRT and LCD can display it), and I've turned the > LCD off with the keyboard function-key control, then when I fire up X the LCD > always turns back on so that both the CRT and LCD are on. > > I've been looking for a way to keep the LCD off so that I can drive the CRT at > a nice high resolution that both the CRT and Radeon support (exceeding the > specs on the LCD). crt_screen option is broken. This option was originally intended to do exactly what you want, but the part of code for turning off panel is missing somehow. So when you use this option, both heads are driven by the same CRTC according to the capability of the CRT connected. This causes the problem on your panel. The new approach to this issue in upcoming driver: When both heads have monitor connected, the driver will always use a different CRTC to control each head and bring both monitor up according to the spec of individual monitor. This does not require the dual-head setup in your config file and two monitors are in "clone" mode. Some people do wish to have two monitors mirroring each other (for example, when connecting a projector to the laptop). There is an option (PanelOff) to turn off your panel if you don't want to see anything there. When in "clone" mode, the two monitors don't have to be in same resolution and DRI, overlay will all work correctly on both monitors. For example, in your case, you can use a normal single-head config with 1600x1200 in the Device section. The driver will bring up your LCD to 1400x1050 and CRT to 1600x1200 (driver will also handle panning). You can turn your LCD off with the PanelOff option. This part of work (along with other things) is being merged into current CVS tree (not finished yet). I have working code in my system. If you want a give it a try, I can send you the binary for x420 or the source. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Rage 128 Mobility and DRI
On Mon, Apr 22, 2002 at 10:32:36PM -0400, Doug Alcorn wrote: > Vladimir Dergachev <[EMAIL PROTECTED]> writes: > > > Most likely you do not have enough video ram for this. One suggestion is > > to switch to 16bpp. > > I've gotten several comments of this nature. I have 8MB of video > ram. According to the DRI calculator, I should be able to do > 1400x1050 in 16bpp. That is not the case. I can only do 1280x1024 in > 16bpp. I can't do DRI in 24bpp and 1280x1024. Of course, my LCD does > 1400x1050. Running 1280x1024 on it looks cruddy. > Correct. The DRI calculator must be wrong. 1400*1050*2 = 2870KB. You need to multiply this figure by 3 for the front, back and depth buffers which gives 8610KB. More than the 8192KB of video memory you have. Alan. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Larger than Largo - load testing X windows
There is a green field site in Australia that could be potentially larger than Largo. They wish to test more than 450 users running thin-client X on a server without having to have 450 client terminals. Is there a simple method to do this, I've thought of: 1) Recording X network packets then sending them from multiple dummy 'clients' on the same PC. (This was done during the Mindcraft benchmarking episode by simulating 'netbench'). 2) Some sort of scripting process that can simulate a use on the server. 3) Expensive load testing software eg mercury interactive (not an option). As you can see, this is not my area of expertise but help is most appreciated. Any ideas most welcome, Stuart Guthrie __ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]ATI Rage 128 Mobility and DRI
Vladimir Dergachev <[EMAIL PROTECTED]> writes: > Most likely you do not have enough video ram for this. One suggestion is > to switch to 16bpp. I've gotten several comments of this nature. I have 8MB of video ram. According to the DRI calculator, I should be able to do 1400x1050 in 16bpp. That is not the case. I can only do 1280x1024 in 16bpp. I can't do DRI in 24bpp and 1280x1024. Of course, my LCD does 1400x1050. Running 1280x1024 on it looks cruddy. > On 21 Apr 2002, Doug Alcorn wrote: > > > I thought I would post this mainly to populate google. I can't > > remember where I saw the user comment with the solution. Probably on > > the dri.sourceforge.net site. Anyway, my Rage 128 Mobility LF won't > > do DRI at resolutions higher than 1280x1024. I don't know if this is > > a limited by the chipset or the dri drives. Wouldn't hurt if this was > > documented in a manpage or something. -- (__) Doug Alcorn - Unix/Linux/Web Developing oo / PGP 02B3 1E26 BCF2 9AAF 93F1 61D7 450C B264 3E63 D543 |_/ mailto:[EMAIL PROTECTED] http://www.lathi.net ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nvidia 2GO Suspend problem
Scribbling feverishly on April 22, Jim Gettys managed to emit: > There could indeed be GeForce2 specific problems, but note that the > bug Keith uncovered is generic, and can happen on *any* machine > (for example, Keith's and my Compaq Evo N600c with Radeon Mobility; > his more than mine, but I see the problem sometimes as well). > > It therefore is probably a good bet, being known to occur for any > and all laptops, independent of APM/ACPI. This bug is entirely > dependent on timing, and can potentially occur on any system. A race? I would think lkml would be interested in fixing that... Kurt -- To get something done, a committee should consist of no more than three people, two of them absent. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]UPDATE kernel module version incorrect
I downloaded and compiled the DRM drivers from xfee86.org as suggested by two very helpful people. I copied the r128.o file to /lib/modules/2.4.9-31/kernel/drivers/char/drm/r128.o and restarted X. I checked the permissions so don't tell me to fix that. This is the result from my log file: * (EE) R128(0): [dri] R128DRIScreenInit failed because of a version mismatch. [dri] r128.o kernel module version is 2.1.6 but version 2.2 or greater is needed. [dri] Disabling the DRI. (EE) R128(0): [drm] failed to remove DRM signal handler * It would appear that the version on xfree86.org is not any newer than what I already had. Perhaps I copied it to the wrong location? Any one care to take a stab at this one? -- Mark LaPierre ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]kernel module version incorrect
On Mon, 2002-04-22 at 21:39, [EMAIL PROTECTED] wrote: > [dri] r128.o kernel module version is 2.1.6 but version 2.2 or greater > is needed. Right, your kernel module is too old. http://xfree86.org/~alanh/ should help. -- 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]ATI Rage 128 Mobility and DRI
Most likely you do not have enough video ram for this. One suggestion is to switch to 16bpp. Vladimir Dergachev On 21 Apr 2002, Doug Alcorn wrote: > I thought I would post this mainly to populate google. I can't > remember where I saw the user comment with the solution. Probably on > the dri.sourceforge.net site. Anyway, my Rage 128 Mobility LF won't > do DRI at resolutions higher than 1280x1024. I don't know if this is > a limited by the chipset or the dri drives. Wouldn't hurt if this was > documented in a manpage or something. > -- > (__) Doug Alcorn - Unix/Linux/Web Developing > oo / PGP 02B3 1E26 BCF2 9AAF 93F1 61D7 450C B264 3E63 D543 > |_/ mailto:[EMAIL PROTECTED] http://www.lathi.net > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]ATI Rage 128 Mobility and DRI
I thought I would post this mainly to populate google. I can't remember where I saw the user comment with the solution. Probably on the dri.sourceforge.net site. Anyway, my Rage 128 Mobility LF won't do DRI at resolutions higher than 1280x1024. I don't know if this is a limited by the chipset or the dri drives. Wouldn't hurt if this was documented in a manpage or something. -- (__) Doug Alcorn - Unix/Linux/Web Developing oo / PGP 02B3 1E26 BCF2 9AAF 93F1 61D7 450C B264 3E63 D543 |_/ mailto:[EMAIL PROTECTED] http://www.lathi.net ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: SAVESET extension proposal
Keith Packard <[EMAIL PROTECTED]> writes: > > ChangeSaveSetValues > > I think all you need is the ability to reparent to the root. As the > embedded window isn't override-redirect, the remapping will be redirected > giving the window manager a chance to peer at the window. A suitable WM > convention could be developed to get the embedded window moved to its > final resting place. As you say in your proposal, other alternatives > involve significantly more error checking and validation at many points in > the server. Since I don't actually need anything but reparenting to the root, and I can't think of any good reason for reparenting to an arbitrary window, I'm happy to simplify things in that area. I'd rather avoid getting the window manager involved too much here; perhaps the "two's company, three's a crowd" principle applies when trying to make things robust. What I'd like to achieve is that when the embedder dies, the embedding protocol ends simply and cleanly; if we need to extend the X protocol, we might as well solve the problem completely (if it's only a few lines of extra code) rather than also require a new window manager convention, and a cooperating window manager. Also, I think adding window manager conventions like "don't map windows with the _XEMBED_INFO property on them" is a little dubious ... I think conventions are best when, if the window manager doesn't support them the fallback behavior is reasonable. > This would also eliminate the need for x-offset/y-offset values, so the > extension could contain only a single request identical to ChangeSaveSet > with an additional mode (SetModeInsertRoot). The x-offset/y-offset addition is really quite separate thing, with the only connection being that had been pointed out to me as a problem, and it was very easy to fix at the same time. The problem basically is that the ICCCM specifies positioning adjustments on startup and shutdown (gravity point on unmanaged and managed windows should be on the same place) and the shutdown adjustments won't be made if the window manager terminates abnormally. It could certainly be fixed without any X additions if window managers consistently supported looking for some _NET_WM_CRASH_OFFSETS property at start. Ugly, but it certainly better than extending the X protocol just for this reason. But, it seemed to me that if we could fix it easily here we might want to do it. Since the only people who regularly switch window managers, or have their window manager crash notice problems here, and the problems (drifting windows) aren't severe, it's not really a problem for end-users. I'm certainly not strongly attached to either: a) Making it a separate request instead of a ChangeSaveSet replacement b) Using a fixed set of parameters rather than a ChangeGCValues They are just fairly arbitrary protocol design issues; the basic I reasons I had for them were: a) Reuse as much existing API as possible. (And the x-offset/y-offset values are likely to need to be changed if things like the window manager b) There were four parameters that could be set; this is enough that it doesn't seem like a "fixed number", but rather a variable quantity. > Are there other WM related extensions that we could usefully merge with > this extension? I'd like to solve any outstanding issues all at once, > rather than with a zillion tiny extensions. The main other area where I'm aware of where an extension might be needed is in some issues related to selections ... it would take me a while to remember all the issues, but when I was trying to figure out how to fix some of the problems with implementing a full-featured clipboard in X, there were issues that were really hard to deal with without notification of selection ownership changes. This doesn't really seem very related, but I suppose we could make a "client communication" extension that just contained "random" things related to ICCCM / desktop issues and plan to increase the minor number as necessary if we add more stuff in the future. Regards, Owen ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]GeForce4-400-Go and the nv driver
I just tried CVS on a Dell Latitude with GeForce 440 Go. It works fine for me. Mark. On Mon, 22 Apr 2002, Mark Vojkovich wrote: > On Sun, 21 Apr 2002, Roger W.Brown wrote: > > > > > Hi, > > > > Mark Vojkovich, in a most helpful reply to my posting > > "XFree86 and the "nvidia" driver", (see > > http://www.xfree86.org/pipermail/xpert/2002-April/016928.html), > > confirmed that: "The "nvidia" driver requires that the server > > have Xinerama support". He also suggests that GeForce4 400 Go > > hardware should work with the "nv" driver. > > > > Today, I took a CVS copy of the xc directory (21-April-2002, 03:30 GMT) > > and rebuilt X11, for a DeLL Latitude C840 laptop, running linux-2.4.18. > > > > The resulting X server fails to run and the last part of the > > XFree86.0.log reads: > > > > (WW) NV(0): Failed to set up write-combining range (0xe00a,0xf0) > > (WW) NV(0): Failed to set up write-combining range (0xe008,0xf2) > > (WW) NV(0): Failed to set up write-combining range (0xe006,0xf4) > > (WW) NV(0): Failed to set up write-combining range (0xe004,0xf6) > > (WW) NV(0): Failed to set up write-combining range (0xe002,0xf8) > > (WW) NV(0): Failed to set up write-combining range (0xe000,0xfa) > > (II) NV(0): Using XFree86 Acceleration Architecture (XAA) > > Screen to screen bit blits > > Solid filled rectangles > > 8x8 mono pattern filled rectangles > > Indirect CPU to Screen color expansion > > Solid Lines > > Offscreen Pixmaps > > Setting up tile and stipple cache: > > 32 128x128 slots > > 22 256x256 slots > > (==) NV(0): Backing store disabled > > (==) NV(0): Silken mouse enabled > > (WW) NV(0): Option "noLogo" is not used > > (WW) NV(0): Option "ignoreEDID" is not used > > (II) Initializing built-in extension MIT-SHM > > (II) Initializing built-in extension XInputExtension > > (II) Initializing built-in extension XTEST > > (II) Initializing built-in extension XKEYBOARD > > (II) Initializing built-in extension LBX > > (II) Initializing built-in extension XC-APPGROUP > > (II) Initializing built-in extension SECURITY > > (II) Initializing built-in extension XINERAMA > > (II) Initializing built-in extension XFree86-Bigfont > > (II) Initializing built-in extension RENDER > > (II) Keyboard "Generic Keyboard" handled by legacy driver > > (**) Option "Protocol" "ImPS/2" > > (**) Generic Mouse: Protocol: "ImPS/2" > > (**) Option "CorePointer" > > (**) Generic Mouse: Core Pointer > > (**) Option "Device" "/dev/input/mouse0" > > (**) Option "ZAxisMapping" "4 5" > > (**) Generic Mouse: ZAxisMapping: buttons 4 and 5 > > (**) Generic Mouse: Buttons: 5 > > (II) XINPUT: Adding extended input device "Generic Mouse" (type: MOUSE) > > > > Fatal server error: > > Caught signal 11. Server aborting > >This doesn't look like a driver specific problem. > > > > > > > Also, linux reports: > > > > Apr 21 15:16:17 aegis kernel: mtrr: no more MTRRs available > > Apr 21 15:16:17 aegis kernel: mtrr: no more MTRRs available > > > > > > Should I build kernels without MTRR support ? > > > >You should have MTRR support. What's /proc/mtrr say? > >You build this one yourself right? Can you run gdb on > the core dump and get a backtrace? > > > Mark. > > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Using Radeon with two heads?
On Monday 22 April 2002 01:02 pm, Michel Dänzer wrote: > > > I'm trying to use "crt_screen" to drive just the external monitor, i.e., > > turn off the LCD. For example, I configure XF86Config-4 for 1280x1024, > > and put Option "crt_screen" into the Device and/or Screen section, boot > > the laptop with the external screen plugged in with the Alt-F8 (BIOS?) > > switched so that both the LCD and CRT are on, but when I startx, both the > > LCD and CRT stay on. I was expecting the LCD to turn off. > > Other people have reported the same behaviour with this option; I > suspect it may have got broken when multihead support was added. > > What if you put > > Screen 1 > > in the device section instead? Thank you for your reply. I tried a two-headed configuration, with the CRT defined in separate monitor and device sections. That worked once or twice, but usually caused the LCD to bloom. I've tried changing the modules, excluding various ones in some experiments. It seems to be very sensitive to whether the monitor (a Viewsonic G810) is connected, so it's some interaction of the laptop BIOS and DDC, I guess. For example, when I have a single-screen configuration, set to 1280x1024 (so that both the CRT and LCD can display it), and I've turned the LCD off with the keyboard function-key control, then when I fire up X the LCD always turns back on so that both the CRT and LCD are on. I've been looking for a way to keep the LCD off so that I can drive the CRT at a nice high resolution that both the CRT and Radeon support (exceeding the specs on the LCD). -- ==Leonard E. Sitongia Visualization and Enabling Technologies / Scientific Computing Division National Center for Atmospheric Research P.O. Box 3000 Boulder CO 80307 USA [EMAIL PROTECTED]voice: (303)497-2454 fax: (303)497-1239 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xfree86 3.3.5 to 4.2.0
On Mon, 22 Apr 2002, Faruk Grozdanic wrote: > Hello, > > I am trying to port the utah-glx s3savage drivers from xfree86 3.3.x to > 4.2.0 . Old code calls xf86AccelInfoRec.PixmapCacheMemoryStart & > xf86AccelInfoRec.PixmapCacheMemoryEnd to get the memory range to use. > In xf86 4.2.0 these do not exist. My understanding is to use > xf86AllocateOffscreenLinear (from xf86fbman.h) for this task. Can I call > this function directly or should I use FBManagerFuncs structure to do this? > Also, if there is a better way of allocatiing VideoRam please let me know. > xf86AllocateOffscreenLinear is what would be used to allocate offscreen memory. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]kernel module version incorrect
Hello, My log file indicates a version mis-match with the r128.o kernel module. It claims I need version 2.2 or greater but /lib/modules/2.4.9-31/kernel/drivers/char/drm/r128.o is version is 2.1.6. Here's my question. Where can I get the appropriate r128.o version or the source to build it? My log file says: (II) R128(0): [drm] loaded kernel module for "r128" driver (II) R128(0): [drm] created "r128" driver at busid "PCI:1:0:0" (II) R128(0): [drm] added 8192 byte SAREA at 0xd8898000 (II) R128(0): [drm] mapped SAREA 0xd8898000 to 0x40018000 (II) R128(0): [drm] framebuffer handle = 0xd400 (II) R128(0): [drm] added 1 reserved context for kernel (EE) R128(0): [dri] R128DRIScreenInit failed because of a version mismatch. [dri] r128.o kernel module version is 2.1.6 but version 2.2 or greater is needed. [dri] Disabling the DRI. (EE) R128(0): [drm] failed to remove DRM signal handler (II) R128(0): [drm] removed 1 reserved context for kernel DRIUnlock called when not locked (II) R128(0): [drm] unmapping 8192 bytes of SAREA 0xd8898000 at 0x40018000 System Info: RH Linux 7.0 kernel 2.4.9-31 XFree86 2.4.0 ATI Expert 128 AGP Thanks for the help. Mark LaPierre ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]GeForce4-400-Go and the nv driver
On Sun, 21 Apr 2002, Roger W.Brown wrote: > > Hi, > > Mark Vojkovich, in a most helpful reply to my posting > "XFree86 and the "nvidia" driver", (see > http://www.xfree86.org/pipermail/xpert/2002-April/016928.html), > confirmed that: "The "nvidia" driver requires that the server > have Xinerama support". He also suggests that GeForce4 400 Go > hardware should work with the "nv" driver. > > Today, I took a CVS copy of the xc directory (21-April-2002, 03:30 GMT) > and rebuilt X11, for a DeLL Latitude C840 laptop, running linux-2.4.18. > > The resulting X server fails to run and the last part of the > XFree86.0.log reads: > > (WW) NV(0): Failed to set up write-combining range (0xe00a,0xf0) > (WW) NV(0): Failed to set up write-combining range (0xe008,0xf2) > (WW) NV(0): Failed to set up write-combining range (0xe006,0xf4) > (WW) NV(0): Failed to set up write-combining range (0xe004,0xf6) > (WW) NV(0): Failed to set up write-combining range (0xe002,0xf8) > (WW) NV(0): Failed to set up write-combining range (0xe000,0xfa) > (II) NV(0): Using XFree86 Acceleration Architecture (XAA) > Screen to screen bit blits > Solid filled rectangles > 8x8 mono pattern filled rectangles > Indirect CPU to Screen color expansion > Solid Lines > Offscreen Pixmaps > Setting up tile and stipple cache: > 32 128x128 slots > 22 256x256 slots > (==) NV(0): Backing store disabled > (==) NV(0): Silken mouse enabled > (WW) NV(0): Option "noLogo" is not used > (WW) NV(0): Option "ignoreEDID" is not used > (II) Initializing built-in extension MIT-SHM > (II) Initializing built-in extension XInputExtension > (II) Initializing built-in extension XTEST > (II) Initializing built-in extension XKEYBOARD > (II) Initializing built-in extension LBX > (II) Initializing built-in extension XC-APPGROUP > (II) Initializing built-in extension SECURITY > (II) Initializing built-in extension XINERAMA > (II) Initializing built-in extension XFree86-Bigfont > (II) Initializing built-in extension RENDER > (II) Keyboard "Generic Keyboard" handled by legacy driver > (**) Option "Protocol" "ImPS/2" > (**) Generic Mouse: Protocol: "ImPS/2" > (**) Option "CorePointer" > (**) Generic Mouse: Core Pointer > (**) Option "Device" "/dev/input/mouse0" > (**) Option "ZAxisMapping" "4 5" > (**) Generic Mouse: ZAxisMapping: buttons 4 and 5 > (**) Generic Mouse: Buttons: 5 > (II) XINPUT: Adding extended input device "Generic Mouse" (type: MOUSE) > > Fatal server error: > Caught signal 11. Server aborting This doesn't look like a driver specific problem. > > > Also, linux reports: > > Apr 21 15:16:17 aegis kernel: mtrr: no more MTRRs available > Apr 21 15:16:17 aegis kernel: mtrr: no more MTRRs available > > > Should I build kernels without MTRR support ? > You should have MTRR support. What's /proc/mtrr say? You build this one yourself right? Can you run gdb on the core dump and get a backtrace? Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]xfree86 3.3.5 to 4.2.0
On Monday 22 Apr 2002 8:23 pm, Faruk Grozdanic wrote: > I am trying to port the utah-glx s3savage drivers from xfree86 3.3.x to > 4.2.0 . Old code calls xf86AccelInfoRec.PixmapCacheMemoryStart & Look on the archives of [EMAIL PROTECTED] I believe someone has laready donw this. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]xfree86 3.3.5 to 4.2.0
Hello, I am trying to port the utah-glx s3savage drivers from xfree86 3.3.x to 4.2.0 . Old code calls xf86AccelInfoRec.PixmapCacheMemoryStart & xf86AccelInfoRec.PixmapCacheMemoryEnd to get the memory range to use. In xf86 4.2.0 these do not exist. My understanding is to use xf86AllocateOffscreenLinear (from xf86fbman.h) for this task. Can I call this function directly or should I use FBManagerFuncs structure to do this? Also, if there is a better way of allocatiing VideoRam please let me know. Thanks Faruk G. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Clipped stippled polygon and pixmap cache bug on ATIRadeon VE w/ 4.2.0
On 22 Apr 2002, Michel [ISO-8859-1] Dänzer wrote: > Well, I think I may look into fixing the clipping for the CP case but > otherwise won't worry about performance until someone complains. Thanks > for the insights. Well, the program which found this bug is a VLSI layout editor. I can assure you that I will be complaining later on. In all seriousness, correct is more important than fast for the moment. Anyone running a VLSI layout editor is *not* running on a commputer which is slow or small. As an aside, does this bug also affect the XRENDER extensions? I was looking into usng OpenGL primarily to gain compositing/transparency effects. However, the XRENDER extensions seem to cover what I need without all the OpenGL baggage. -a ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Using Radeon with two heads?
On Mon, 2002-04-22 at 07:12, Leonard Sitongia wrote: > > I'm running XFree86 4.2 on Linux RH 7.2 on a Dell Inspiron 4100 with a > 1400x1050 LCD display and an external monitor. This has the ATI Radeon > Mobility LY (AGP) hardware. > > I'm trying to find documentation specific to the radeon driver, because the > document for the "ati" driver in XF 4.2 says that the radeon is not supported > in the ati driver, and to see the documentation provided with it's driver. > I've searched with Google, and I can't find the documentation. There's no manpage for the radeon driver yet, I might write one for 4.3.0 if I get around to it but to be honest there's a lot of other stuff I'd rather do (hint, hint :)... > I'm trying to use "crt_screen" to drive just the external monitor, i.e., turn > off the LCD. For example, I configure XF86Config-4 for 1280x1024, and put > Option "crt_screen" into the Device and/or Screen section, boot the laptop > with the external screen plugged in with the Alt-F8 (BIOS?) switched so that > both the LCD and CRT are on, but when I startx, both the LCD and CRT stay on. > I was expecting the LCD to turn off. Other people have reported the same behaviour with this option; I suspect it may have got broken when multihead support was added. What if you put Screen 1 in the device section instead? -- 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]Window ID
On Mon, 22 Apr 2002, Bharathi S wrote: > On Mon, 22 Apr 2002, Vladimir Dergachev wrote: > > > > How find the window id by using the following structures > > > Display, Drawable, Graphics Context ? > > > > AFAIK, Window id is the same thing as the drawable, provided the drawable > > points to the window. I.e. where the man page says Xblahblah function > > takes a drawable as an argument it means that you can either pass a window > > id or a pixmap (but not XImage) handle to it. > > Thank you Vladimir Dergachev > > Most of the functions taking Pixmap(DRAWABLE) as argument. > I need the window id for maintaining a virtual buffer > and window id as the key. > > How the Xserver finding the window id ? > Bcoz we are sending only dpy, pixmap, GC ! You lost me at this point. Could you provide more detail about what is it you are trying to do ? Is it in the user application or in Xserver code ? best Vladimir Dergachev > > Thank you, > Bharathi S > -- > --==| Bharathi S | BSB-364 DONLab | IIT-Madras |==-- > The words of mouth are of no use > When eye to eye agrees the gaze. > *In Tirukkural of Holy Tamil poet Tiruvalluvar. > > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]What causes LCDs to "burn" at wrong res?
On Sun, 21 Apr 2002, Leonard Sitongia wrote: > I'm trying to get my laptop to display on both the LCD and an external CRT. > > Often the setting will cause the LCD to start rapidly brightening, with it > appearing to burn in. I don't know what to call this. It looks bad, so I > immediately power it off (ctrl-alt-backspace doesn't kill it, so X probably > isn't running far enough along to do that). > > What causes this? Is it really as bad as it seems? :-) > > I'm tempted to hypothesize that this is caused by driving the LCD at a higher > res/rate than it supports, but it's not clearly the case, because I can > sometimes get it to work (it=driving the CRT at a higher res than the LCD), > but it seems to depend on whether the LCD and CRT are both initially on (via > Fn-F8). In my experience (#9 Ticket To Ride IV, Permedia-3 1600SW, SGI 1600SW), the incorrect polarity of the hsync and/or vsync causes the *exact* effect you mention. In my case, it had _nothing_ to do with the rate at which the LCD was being driven. That said, LCDs can be fried, and your case may be different. I didn't wait to see how a prolonged exposure to this effect affected the LCD. :-) Ctrl-Alt-Backspace always killed the X server and cleared the effect. Nikola Miljanic [Nick] || Metro Link, Inc. [EMAIL PROTECTED] || http://www.metrolink.com progress [n.] 1. In computing; advancing from one error message to the next ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]GeForce4-400-Go and the nv driver
Hi, Mark Vojkovich, in a most helpful reply to my posting "XFree86 and the "nvidia" driver", (see http://www.xfree86.org/pipermail/xpert/2002-April/016928.html), confirmed that: "The "nvidia" driver requires that the server have Xinerama support". He also suggests that GeForce4 400 Go hardware should work with the "nv" driver. Today, I took a CVS copy of the xc directory (21-April-2002, 03:30 GMT) and rebuilt X11, for a DeLL Latitude C840 laptop, running linux-2.4.18. The resulting X server fails to run and the last part of the XFree86.0.log reads: (WW) NV(0): Failed to set up write-combining range (0xe00a,0xf0) (WW) NV(0): Failed to set up write-combining range (0xe008,0xf2) (WW) NV(0): Failed to set up write-combining range (0xe006,0xf4) (WW) NV(0): Failed to set up write-combining range (0xe004,0xf6) (WW) NV(0): Failed to set up write-combining range (0xe002,0xf8) (WW) NV(0): Failed to set up write-combining range (0xe000,0xfa) (II) NV(0): Using XFree86 Acceleration Architecture (XAA) Screen to screen bit blits Solid filled rectangles 8x8 mono pattern filled rectangles Indirect CPU to Screen color expansion Solid Lines Offscreen Pixmaps Setting up tile and stipple cache: 32 128x128 slots 22 256x256 slots (==) NV(0): Backing store disabled (==) NV(0): Silken mouse enabled (WW) NV(0): Option "noLogo" is not used (WW) NV(0): Option "ignoreEDID" is not used (II) Initializing built-in extension MIT-SHM (II) Initializing built-in extension XInputExtension (II) Initializing built-in extension XTEST (II) Initializing built-in extension XKEYBOARD (II) Initializing built-in extension LBX (II) Initializing built-in extension XC-APPGROUP (II) Initializing built-in extension SECURITY (II) Initializing built-in extension XINERAMA (II) Initializing built-in extension XFree86-Bigfont (II) Initializing built-in extension RENDER (II) Keyboard "Generic Keyboard" handled by legacy driver (**) Option "Protocol" "ImPS/2" (**) Generic Mouse: Protocol: "ImPS/2" (**) Option "CorePointer" (**) Generic Mouse: Core Pointer (**) Option "Device" "/dev/input/mouse0" (**) Option "ZAxisMapping" "4 5" (**) Generic Mouse: ZAxisMapping: buttons 4 and 5 (**) Generic Mouse: Buttons: 5 (II) XINPUT: Adding extended input device "Generic Mouse" (type: MOUSE) Fatal server error: Caught signal 11. Server aborting Also, linux reports: Apr 21 15:16:17 aegis kernel: mtrr: no more MTRRs available Apr 21 15:16:17 aegis kernel: mtrr: no more MTRRs available Should I build kernels without MTRR support ? Any comments most welcome. Thanks, Roger Brown ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 4.2, Powermac ADC connector, Nvidia
Use the version in cvs right now, or use the attatched patch against 4.2.0
nv driver.
ani
On Sat, 20 Apr 2002, Richard Chan wrote:
> Folks,
>
> Using XFree86 4.2 with nv driver on G4 PowerMAC with Nvidia GeForce2/MX card (VGA
>and ADC)
> Debian Linux Woody, 2.4.18-newpmac kernel
>
> Everything works great with VGA out or text console on ADC and XFree86 on VGA -
>however
> I just can't figure out how to get XFree86 appearing on the ADC output ( with an
>Apple Studio
> Display 17" CRT - not the current LCD display offerings).
>
> Is there some special nv Option or is this a "known problem" with Apple's
>proprietary stuff.
>
> Thanks for any enlightenment.
>
> Richard
>
diff -uNr nv.orig/nv_cursor.c nv/nv_cursor.c
--- nv.orig/nv_cursor.c Mon Feb 25 22:54:49 2002
+++ nv/nv_cursor.c Mon Feb 25 22:54:45 2002
@@ -109,7 +109,7 @@
NVPtr pNv = NVPTR(pScrn);
pNv->riva.ShowHideCursor(&pNv->riva, 0);
-*(pNv->riva.CURSORPOS) = (x & 0x) | (y << 16);
+pNv->riva.PRAMDAC[0x300/4] = (x & 0x) | (y << 16);
pNv->riva.ShowHideCursor(&pNv->riva, 1);
}
@@ -123,8 +123,10 @@
back = ConvertToRGB555(bg);
#if X_BYTE_ORDER == X_BIG_ENDIAN
-fore = (fore << 8) | (fore >> 8);
-back = (back << 8) | (back >> 8);
+if((pNv->Chipset & 0x0ff0) == 0x0110) {
+ fore = (fore << 8) | (fore >> 8);
+ back = (back << 8) | (back >> 8);
+}
#endif
if (pNv->curFg != fore || pNv->curBg != back) {
diff -uNr nv.orig/nv_dac.c nv/nv_dac.c
--- nv.orig/nv_dac.cMon Feb 25 22:54:49 2002
+++ nv/nv_dac.c Mon Feb 25 22:54:45 2002
@@ -71,6 +71,15 @@
if(mode->Flags & V_INTERLACE)
vertTotal |= 1;
+if(pNv->FlatPanel) {
+ vertStart = vertTotal - 3;
+ vertEnd = vertTotal - 2;
+ vertBlankStart = vertStart;
+ horizStart = horizTotal - 3;
+ horizEnd = horizTotal - 2;
+ horizBlankEnd = horizTotal + 4;
+}
+
pVga->CRTC[0x0] = Set8Bits(horizTotal);
pVga->CRTC[0x1] = Set8Bits(horizDisplay);
pVga->CRTC[0x2] = Set8Bits(horizBlankStart);
@@ -147,6 +156,8 @@
if(pNv->riva.Architecture >= NV_ARCH_10)
pNv->riva.CURSOR = (U032 *)(pNv->FbStart + pNv->riva.CursorStart);
+pNv->riva.LockUnlock(&pNv->riva, 0);
+
pNv->riva.CalcStateExt(&pNv->riva,
nvReg,
i,
@@ -156,6 +167,24 @@
mode->Clock,
mode->Flags);
+nvReg->scale = pNv->riva.PRAMDAC[0x0848/4] & 0xfff000ff;
+if(pNv->FlatPanel) {
+ nvReg->pixel |= (1 << 7);
+ nvReg->scale |= (1 << 8) ;
+}
+if(pNv->SecondCRTC) {
+ nvReg->head = 0;
+ nvReg->head2 = 0x;
+ nvReg->crtcOwner = 3;
+ nvReg->pllsel |= 0x2800;
+ nvReg->vpll2 = nvReg->vpll;
+} else {
+ nvReg->head = 0x;
+ nvReg->head2 = 0;
+ nvReg->crtcOwner = 0;
+ nvReg->vpll2 = pNv->riva.PRAMDAC0[0x0520/4];
+}
+
return (TRUE);
}
@@ -184,8 +213,17 @@
{
NVPtr pNv = NVPTR(pScrn);
DEBUG(xf86DrvMsg(pScrn->scrnIndex, X_INFO, "NVDACSave\n"));
-vgaHWSave(pScrn, vgaReg, VGA_SR_MODE | (saveFonts? VGA_SR_FONTS : 0));
+
+#if defined(__powerpc__)
+saveFonts = FALSE;
+#endif
+
+vgaHWSave(pScrn, vgaReg, VGA_SR_CMAP | VGA_SR_MODE |
+ (saveFonts? VGA_SR_FONTS : 0));
pNv->riva.UnloadStateExt(&pNv->riva, nvReg);
+
+if((pNv->Chipset & 0x0ff0) == 0x0110)
+ nvReg->crtcOwner = ((pNv->Chipset & 0x0fff) == 0x0112) ? 3 : 0;
}
#define DEPTH_SHIFT(val, w) ((val << (8 - w)) | (val >> ((w << 1) - 8)))
diff -uNr nv.orig/nv_dga.c nv/nv_dga.c
--- nv.orig/nv_dga.cMon Feb 25 22:54:49 2002
+++ nv/nv_dga.c Mon Feb 25 22:54:45 2002
@@ -234,8 +234,8 @@
NVAdjustFrame(pScrn->pScreen->myNum, x, y, flags);
- while(pNv->riva.PCIO[0x3da] & 0x08);
- while(!(pNv->riva.PCIO[0x3da] & 0x08));
+ while(VGA_RD08(pNv->riva.PCIO, 0x3da) & 0x08);
+ while(!(VGA_RD08(pNv->riva.PCIO, 0x3da) & 0x08));
pNv->DGAViewportStatus = 0;
}
diff -uNr nv.orig/nv_driver.c nv/nv_driver.c
--- nv.orig/nv_driver.c Mon Feb 25 22:54:49 2002
+++ nv/nv_driver.c Mon Feb 25 22:54:45 2002
@@ -179,13 +179,11 @@
"vgaHWGetHWRec",
"vgaHWGetIndex",
"vgaHWInit",
-"vgaHWLock",
"vgaHWMapMem",
"vgaHWProtect",
"vgaHWRestore",
"vgaHWSave",
"vgaHWSaveScreen",
-"vgaHWUnlock",
"vgaHWddc1SetSpeed",
NULL
};
@@ -305,7 +303,8 @@
OPTION_FBDEV,
OPTION_ROTATE,
OPTION_VIDEO_KEY,
-OPTION_FLAT_PANEL
+OPTION_FLAT_PANEL,
+OPTION_CRTC_NUMBER
} NVOpts;
@@ -319,6 +318,7 @@
{ OPTION_ROTATE, "Rotate", OPTV_ANYSTR,{0}, FALSE },
{ OPTION_VIDEO_KEY,"VideoKey", OPTV_INTEGER, {0}, FALS
[Xpert]New mpeg2play hacked for XvMC
In this new version I fixed a few things: 1) Problems with interleaved video 2) Problems with DualPrime motion 3) Added support for HD program streams 4) Removed some of the fast paths in the macroblock code because they were broken and keeping HD from working. Unfortunately, this slows down the player a bit. I've added some hacky support for dlopening vendor specific dynamic libraries (eg. libXvMCI810.so) so you don't have to recompile every time you get a new vendor libXvMC. This isn't turned on by default, but you can see where that's at in the Makefile. I added some trivial speedups, but not enough to make up for the removal of the broken fast paths so this decoder is still dog slow. Never-the-less I'm still able to peg 720p to the refresh rate (77Hz) on a 1.4 Gig P4 with GeForce4 MX running with IDCT acceleration. Mark. mpeg2play_accel.tar.gz Description: mpeg2play_accel.tar.gz
Re: [Xpert]What causes LCDs to "burn" at wrong res?
On Sun, 21 Apr 2002, Leonard Sitongia wrote: > > I'm trying to get my laptop to display on both the LCD and an external CRT. > > Often the setting will cause the LCD to start rapidly brightening, with it > appearing to burn in. I don't know what to call this. It looks bad, so I "blooming" > immediately power it off (ctrl-alt-backspace doesn't kill it, so X probably > isn't running far enough along to do that). > > What causes this? Is it really as bad as it seems? :-) This happens when the timings are far enough off. I've been told that it can be bad for the panel, but I'm not really sure. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Re: SAVESET extension proposal
> ChangeSaveSetValues I think all you need is the ability to reparent to the root. As the embedded window isn't override-redirect, the remapping will be redirected giving the window manager a chance to peer at the window. A suitable WM convention could be developed to get the embedded window moved to its final resting place. As you say in your proposal, other alternatives involve significantly more error checking and validation at many points in the server. This would also eliminate the need for x-offset/y-offset values, so the extension could contain only a single request identical to ChangeSaveSet with an additional mode (SetModeInsertRoot). Are there other WM related extensions that we could usefully merge with this extension? I'd like to solve any outstanding issues all at once, rather than with a zillion tiny extensions. Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nvidia 2GO Suspend problem
There could indeed be GeForce2 specific problems, but note that the bug Keith uncovered is generic, and can happen on *any* machine (for example, Keith's and my Compaq Evo N600c with Radeon Mobility; his more than mine, but I see the problem sometimes as well). It therefore is probably a good bet, being known to occur for any and all laptops, independent of APM/ACPI. This bug is entirely dependent on timing, and can potentially occur on any system. I wanted to make the list aware that if they have problems with suspend, it may not in fact be X's fault at all. Keith, you should at least post your kernel patch, so that people can verify if suspend problems are the kernel, or the X server. - Jim -- Jim Gettys Cambridge Research Laboratory Compaq Computer Corporation [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]What causes LCDs to "burn" at wrong res?
I'm trying to get my laptop to display on both the LCD and an external CRT. Often the setting will cause the LCD to start rapidly brightening, with it appearing to burn in. I don't know what to call this. It looks bad, so I immediately power it off (ctrl-alt-backspace doesn't kill it, so X probably isn't running far enough along to do that). What causes this? Is it really as bad as it seems? :-) I'm tempted to hypothesize that this is caused by driving the LCD at a higher res/rate than it supports, but it's not clearly the case, because I can sometimes get it to work (it=driving the CRT at a higher res than the LCD), but it seems to depend on whether the LCD and CRT are both initially on (via Fn-F8). TIA! -- ==Leonard E. Sitongia Visualization and Enabling Technologies / Scientific Computing Division National Center for Atmospheric Research P.O. Box 3000 Boulder CO 80307 USA [EMAIL PROTECTED]voice: (303)497-2454 fax: (303)497-1239 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nvidia 2GO Suspend problem
On Mon, 22 Apr 2002, Jim Gettys wrote: > There are bugs in suspend in general with Linux (having nothing to do with > X per' se'). Keith Packard has sent Linus a patch; not a great one, > (loop after a pause for a long time), but one that works. Actually, in the case of GeForce2 Go there is more to it than this. The video bios does not have APM support. It's ACPI only and this is not something well supported in Linux kernel. Mark. > > Basically, if the system is busy at the instant that the > suspend request is made, it fails. This can happen if the disk or > other device is busy at that instant, which can happen as the X server > writes its log that it is suspending (or other logging activity). > > This will depend on exactly the hardware/software combination, and may > or may not be repeatable (until you change something!). > > Keith, any news on that patch from Linus? >- Jim > > -- > Jim Gettys > Cambridge Research Laboratory > Compaq Computer Corporation > [EMAIL PROTECTED] > > ___ > Xpert mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/xpert > ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Using Radeon with two heads?
Hello, I'm running XFree86 4.2 on Linux RH 7.2 on a Dell Inspiron 4100 with a 1400x1050 LCD display and an external monitor. This has the ATI Radeon Mobility LY (AGP) hardware. I'm trying to find documentation specific to the radeon driver, because the document for the "ati" driver in XF 4.2 says that the radeon is not supported in the ati driver, and to see the documentation provided with it's driver. I've searched with Google, and I can't find the documentation. I'm trying to use "crt_screen" to drive just the external monitor, i.e., turn off the LCD. For example, I configure XF86Config-4 for 1280x1024, and put Option "crt_screen" into the Device and/or Screen section, boot the laptop with the external screen plugged in with the Alt-F8 (BIOS?) switched so that both the LCD and CRT are on, but when I startx, both the LCD and CRT stay on. I was expecting the LCD to turn off. I want to drive the external monitor at a higher res (1600x1200) than the LCD supports, so I want to turn the LCD off. Since crt_screen doesn't do this, I assumed that there was another option for the radeon driver, so I'm looking for the document for the driver to see. TIA! -- ==Leonard E. Sitongia Visualization and Enabling Technologies / Scientific Computing Division National Center for Atmospheric Research P.O. Box 3000 Boulder CO 80307 USA [EMAIL PROTECTED]voice: (303)497-2454 fax: (303)497-1239 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]SAVESET extension proposal
Here's a proposal for a tiny protocol extension (one request other than
QueryVersion) that would help a lot in making inter-client embedding
robust.
I'm willing to do the work in implementing this for XFree86, though
I might need help in checking the protocol for sanity and figuring
out how to implement it. (A separate library for one request seems
like overkill, but I'm not sure that adding it to XLib would be
legitimate.)
Does this proposal make sense?
Thanks,
Owen
ChangeSaveSetValues
window: WINDOW
value-mask: BITMASK
value-list: LISTofVALUE
Errors: Window, Match
Sets the save-set values for WINDOW. window must be in the client's
save-set or Match error occurs.
The value-mask and value-list contain the attributes to change. The
possible values are:
target: WINDOW or None
map-action: { Nothing, Map, Unmap }
x-offset: INT16
y-offset: INT16
When the client's resources are destroyed, if window is an inferior of a
window
created by the client,window is:
Reparented to the target value window, or if None, to the closest
ancestor such that window is not an inferior of a window created
by the client.
Mapped if map-action is Map, unmapped if map-action is Unmap.
Moved such that if the original root-window location of the client's
upper left corner is x,y then the new location is x + x-offset,
y + y-offset.
The default component values when a window is added to the client's save-set
correspond to the core protocol behavior and are:
Component Default
---
target None
map-action Map
x-offset0
y-offset0
Rationale:
Being able to set the target is important when doing-interclient
embedding as in the XEmbed protocol.
(http://www.freedesktop.org/standards/xembed.html.) If the
embedder is unexpectedly killed, the behavior of the core protocol is to
reparent the client to the window manager's frame and map it. Since the
window manager then destroys its frame, the client window is not saved,
and the client application will likely crash. The client application may
have a separate toplevel (e.g. an application with a status docklet in
the desktop's panel) or windows embedded elsewhere, so this is highly
undesirable.
Setting the map-action so that the window is unnmapped rather than
mapped is desirable to keep the window from temporarily being visible as
a child of the root window. (Note that unmapping and reparented back to
the root window not result in a "lost" window, since this is the normal
termination of the XEmbed protocol and clients are required to watch for
it.)
x-offset and y-offset can be used by a reparenting window manager so
that if it is killed unexpectedly then when a new window manager is
started, windows appear in their original location, rather than offset
by the frame thickness.
Possible Issues:
Allowing the target to be a WINDOW may complicate implementation to
handle the case where the target is destroyed between the
ChangeSaveSaveSetValues call and the client being destroyed. An
alternative which handles the use case is to make it an enumeration with
the possible values { NearestParent, Root }.
The save-set values are per-client, per-window rather than per-window.
I think being per-client is more logical and probably easier to
implement since the save-set itself is per-client.
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Nvidia 2GO Suspend problem
There are bugs in suspend in general with Linux (having nothing to do with X per' se'). Keith Packard has sent Linus a patch; not a great one, (loop after a pause for a long time), but one that works. Basically, if the system is busy at the instant that the suspend request is made, it fails. This can happen if the disk or other device is busy at that instant, which can happen as the X server writes its log that it is suspending (or other logging activity). This will depend on exactly the hardware/software combination, and may or may not be repeatable (until you change something!). Keith, any news on that patch from Linus? - Jim -- Jim Gettys Cambridge Research Laboratory Compaq Computer Corporation [EMAIL PROTECTED] ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Window ID
Bharathi S wrote: > > On Mon, 22 Apr 2002, Vladimir Dergachev wrote: > > > > How find the window id by using the following structures > > > Display, Drawable, Graphics Context ? > > > > AFAIK, Window id is the same thing as the drawable, provided the drawable > > points to the window. I.e. where the man page says Xblahblah function > > takes a drawable as an argument it means that you can either pass a window > > id or a pixmap (but not XImage) handle to it. > > Thank you Vladimir Dergachev > > Most of the functions taking Pixmap(DRAWABLE) as argument. > I need the window id for maintaining a virtual buffer > and window id as the key. > > How the Xserver finding the window id ? > Bcoz we are sending only dpy, pixmap, GC ! Bharathi, A pixmap is a drawable, a window is a drawable, but a pixmap is *not* a window. You can, however get the root window from a display structure. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Monitor problems
Title: Monitor problems Hi. I just recently upgraded our Xfree86 from 4.0.3 to 4.2.0. I am running on SCO Unixware 2.1.3. After upgrading, some of the older monitors we have go blank when xdm is brought up. I am using the same information for HorizSync and VertRefresh in /etc/X11/XF86Config file. I have tried resetting those variables to other values such as VertRefresh 60 and using ranges (preferable to us) like 50-100, but they still do not work. When I use a newer monitor, everything is fine. I was wondering if I am missing something. I have checked the RELNOTES and found nothing so far. Is there something I can do to use the older monitors? Thanks for any help. Keith _ Keith Fitts 954 958 3900 x3214 CyberGuard Corp. 2000 W. Commercial Blvd. Suite 200 Fort Lauderdale, Fl 33309 See the LX, a new, low-cost EAL4 certified firewall/VPN compact appliance! http://www.cyberguard.com/SOLUTIONS/Solutions_lx1.html
RE: [Xpert]Radeon 8500
On Mon, 2002-04-22 at 11:48, Pranay Kumar wrote: > > Floating point exception in xvidtune: > > Output: > > Vendor: DEL, Model: DEL 1701FP > Num hsync: 0, Num vsync: 0 > Floating point exception Most likely an xvidtune bug then. You could try to track it down with gdb. -- 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 8500
Hi, Floating point exception in xvidtune: Output: Vendor: DEL, Model: DEL 1701FP Num hsync: 0, Num vsync: 0 Floating point exception I have also attached my XF86Config and Xfree log. Regards, Pranay >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >On Behalf Of Michel Dänzer >Sent: Monday, April 22, 2002 4:46 PM >To: Pranay Kumar >Cc: Xpert Mailing list >Subject: Re: [Xpert]Radeon 8500 > > >On Mon, 2002-04-22 at 08:45, Pranay Kumar wrote: >> >> 1) When I run xvidtune I get a floating point exception. Why? > >Does xvidtune or the X server get the exception? > >> 2) How do I check the refresh rate and the clock rate? > >Look at the server log? > >> 3) How can I run the two heads as sperate screens. I tried >duplicating >> the screen section in XF86Config-4 but no use. > >See http://xfree86.org/current/XF86Config.5.html (or man XF86Config or >XF86Config-4) about the Screen directive in device sections. > > >-- >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 > XF86Config-4 Description: Binary data XFree86.0.log Description: Binary data
Re: [Xpert]Radeon 8500
On Mon, 2002-04-22 at 08:45, Pranay Kumar wrote: > > 1) When I run xvidtune I get a floating point exception. Why? Does xvidtune or the X server get the exception? > 2) How do I check the refresh rate and the clock rate? Look at the server log? > 3) How can I run the two heads as sperate screens. I tried duplicating > the screen section in XF86Config-4 but no use. See http://xfree86.org/current/XF86Config.5.html (or man XF86Config or XF86Config-4) about the Screen directive in device sections. -- 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]Nvidia 2GO Suspend problem
Hi, a Linux system (Dell C810 Notebook, Rh 7.2, Kernel 2.4.16) won't suspend after X has been loaded (apm -s results in a message saying that the resource isn't available). I've got NVdriver glx 1.0.2880 and w-kernel 1.0.2880 installed. The system will suspend if graphics isn't loaded. Any ideas ? Thanx, Aron -- === Aron Vrtala| Internet eMail: Zentraler Informatikdienst der | [EMAIL PROTECTED] Universitaet Wien | [EMAIL PROTECTED] | -- Abteilung Dezentrale Systeme| eMail Hotline-Service: Aussenstelle Physik | [EMAIL PROTECTED] | -- Boltzmanngasse 5, A-1090 Vienna| Tel: +43-1-4277 /14102,Hotline: /14100 Austria, Europe| Fax: +43-1-4277 /9141 === - -->--> This message was sent using only 100 % recycled electrons & photons. <--<-- -BEGIN PGP PUBLIC KEY BLOCK- Version: 2.6.3i mQCNAzXF2vcAAAEEALtcyrg4NOfLdcQTKMP3rUa67lb3Sp25gn9fNMQ68Iyc7roX Y0dhcQXbWxGDvId1CQJGzB1JdYFPXGcmSh2Qj2B3DL6Mm6dLwNJLI2pHJzsSAdxj wEDhr869Jb3bdntETNFXs4Wh+G/QrZZi4R1MJxrtQP6DNaC6PhIZWDFPoJ1xAAUR tAtBcm9uLlZydGFsYYkAlQMFEDXF2vcSGVgxT6CdcQEBeq4EAKD5h5d3VZYAqCE9 VyNsqv9ZlUeIt1srehyrRSi2uojT53F5TDXrsNNgTrakoE+XLsF1QRoqgTnbZOE8 hmRKUwGq2HPEHzUQpFm8K0vzAQcrKXKf9IqfXqmD8I5aGJMeYMZtEFWYdZJ4VGA8 SB/IqlUqZFaMK23fGzF2r9SkP8Wb =foVl -END PGP PUBLIC KEY BLOCK- ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Clipped stippled polygon and pixmap cache bug on ATIRadeon VE w/ 4.2.0
On Sun, 2002-04-21 at 21:34, Mark Vojkovich wrote: > On 21 Apr 2002, Michel Dänzer wrote: > > > On Sat, 2002-04-20 at 20:26, Mark Vojkovich wrote: > > > On 20 Apr 2002, Michel Dänzer wrote: > > > > > > > On Fri, 2002-04-12 at 02:23, Andrew P. Lentvorski wrote: > > > > > Okay, after tracking this, it turns out to be a pixmap cache bug. At > > > > > least, I can stop the problem from occurring by adding the "Option > > > > > "XaaNoPixmapCache"" line to my XF86Config file. > > > > > > > > That's coincidence, the same is true for "XaaNoScreenToScreenCopy". > > > > > > > > The problem is that RADEONCPSetClippingRectangle() is called between > > > > RADEONSetupForScreenToScreenCopy() and > > > > RADEONSubsequentScreenToScreenCopy() and messes up the > > > > DP_GUI_MASTER_CNTL register. > > > > > > > > I don't see a proper solution to this problem so the attached patch just > > > > disables hardware clipping for screen to screen copies. I wonder what > > > > impact on performance this has, if any - Mark? > > > > > > Hard to say. In some hardware implementations, hardware clipping > > > is slower and it's fastest to clip in software. It depends on how well > > > the hardware optimizes away the unrendered pixels. > > > > Can you recommend any benchmarks? > >There aren't any. x11perf with the window half offscreen would > test that though. It's only used in "one-rect" situations. If > we don't have a complex cliplist (many rects) we know that we > don't need to software clip any geometry, we can just set the > hardware clip rect and send it all down without checking any of > the primitives at all. With smart hardware this is a win on a > slow CPU. It's less important as the CPU gets faster. Well, I think I may look into fixing the clipping for the CP case but otherwise won't worry about performance until someone complains. Thanks for the insights. -- 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]joystick woes
> > this should not be being compiled in the make install file!!! > It was already compiled during make World and already failed then. make > World doesn't abort on errors by default, it's a good idea to redirect > its output into a file and check it for errors, or just run make > afterwards, ... thanks! i didnt know that, i did pipe the output to a file, but it was too big to check for errors ;) does anyone have a fix for this file to compile correctly then? im not in any hurry as i dont have a joystick on THIS machine... and will the fix be in the next release? cheers again, Sam -- A lifetime isn't nearly long enough to figure out what it's all about. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]joystick woes
On Mon, 2002-04-22 at 10:35, Sam Halliday wrote: > > > this should not be being compiled in the make install file!!! > > It was already compiled during make World and already failed then. make > > World doesn't abort on errors by default, it's a good idea to redirect > > its output into a file and check it for errors, or just run make > > afterwards, ... > thanks! i didnt know that, i did pipe the output to a file, but it was too > big to check for errors ;) grep '\*\*\*' should do the trick. -- 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]joystick woes
On Mon, 2002-04-22 at 09:34, Sam Halliday wrote: > this should not be being compiled in the make install file!!! It was already compiled during make World and already failed then. make World doesn't abort on errors by default, it's a good idea to redirect its output into a file and check it for errors, or just run make afterwards, ... -- 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]joystick woes
i just tried compiling (well, i finally succeeded) XFree86-4.2, i ran make World, then make install after my setup files were in place... but i got this error in make install for the file lnx_jstk.c: In file included from ../../../../../../programs/Xserver/hw/xfree86/common/xf86.h:17, from lnx_jstk.c:40: ../../../../../../programs/Xserver/hw/xfree86/common/xf86str.h:250: parse error before `0x10' lnx_jstk.c: In function `linux_jstkModuleInit': lnx_jstk.c:179: `MAGIC_DONE' undeclared (first use in this function) make[6]: *** [lnx_jstk.o] Error 1 make[6]: Leaving directory `/usr/src/xc/programs/Xserver/hw/xfree86/os-support/linux' this should not be being compiled in the make install file!!! it meant my whole system of libs and drivers was overwritten with new ones but the binary executable wasnt, so i didnt have any X for a while! i recompield without joystick support and it worked, this was fine in 4.1, is this a known problem? will it be fixed in next release? i run linux-2.4.18, gcc-2.95.3 thanks in advance! Sam -- If pro is the opposite of con, what is the opposite of progress? ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
