[Xpert]Radeon 8500
Hi all, My setup.. Linux 2.4.18 (built) with X 4.2.0 (built). ATI.2 drivers on a Radeon 8500 card. The card has a vga and a DVI output. Both the heads by default are in a clone configuration (right from boot time I see the same things on both heads). I have a few questions: 1) When I run xvidtune I get a floating point exception. Why? 2) How do I check the refresh rate and the clock rate? 3) How can I run the two heads as sperate screens. I tried duplicating the screen section in XF86Config-4 but no use. --- Pranay Kumar Email: [EMAIL PROTECTED] --- ___ 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
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]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
[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]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
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
[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
[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
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]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
[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]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]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]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}, FALSE },
{ OPTION_FLAT_PANEL, FlatPanel,OPTV_BOOLEAN, {0}, FALSE },
+{ OPTION_CRTC_NUMBER, CrtcNumber, OPTV_INTEGER, {0}, FALSE },
{ -1,
[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]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]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]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. grin 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
[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]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
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
[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]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
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
[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
[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
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]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]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
[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
