RE: [Xpert]KDE3/i810 corruption - source pointers?
On Thu, 26 Sep 2002, Neale Banks wrote: Ah, that's interesting. A few of us have been plagued by a crash which happens with i810 when running two servers - and goes away when XaaNoSolidFillRect is set on. Ah, according to the README file in the driver directory: 7. Known Limitations - No 32bpp support in this driver. - Running Two Xservers on different VT's is not supported at this time. Any chance that these two problems are different manifestations of the same coding oversight? The operations you listed are two entirely different blitter instructions (SRC_COPY_BLT as opposed to COLOR_BLT). You're correct in that the code to stuff the instruction into the ring buffer is very similar, but in the first case (SRC_COPY_BLT), the 5th parameter is a 14 bit source pitch, while in the second case (COLOR_BLT), the 5th parameter is a 24 bit color. If so, what would be the correct constructs here? For the SRC_COPY_BLT, the correct code would be: OUT_RING( pI810-BR[13] 0x3FFF ); i.e. masking the value to 14 bits instead of 16. Matt had said this probaly isn't a big deal, though. Bill ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 on Solaris Sun Blade 100?
On Wed, 25 Sep 2002, Andrew P. Lentvorski wrote: Has anyone managed to get XFree86 to work on a Sun Blade 100/150/1000/2000 running Solaris? It doesn't necessarily need to work with a Sun graphics card; I would happily go get even a reasonably expensive ATI or nVidia card (which would *still* be much cheaper than anything from Sun). Work on this started after 4.2. You'll need to pick up the CVS HEAD source (see http://xfree86.org/cvs) and read README.Solaris before building it. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]MIME attachment handler in hypermail subtly corrupts attachments
Maybe this is already common knowledge, but it surprised me. I was reviewing the patches I sent to [EMAIL PROTECTED], and noticed that a patch I submitted got corrupted. The message: http://www.xfree86.org/devel/archives/patch/2002-Sep/0008.shtml The attachment: http://www.xfree86.org/devel/archives/patch/2002-Sep/handle_vetoed_suspend.diff This is the troublesome line: + if (errno = EBUSY) Of course that shouldn't be an assignment...and, in fact, it wasn't in the mail I sent out. I think there is a bug in a MIME parser somewhere, probably in hypermail, that collapsed the == to a =. I don't know how the process of patch merging works, but this sort of corruption of attachments could really waste some time and introduce some subtle bugs. -- G. Branden Robinson| Exercise your freedom of religion. Debian GNU/Linux | Set fire to a church of your [EMAIL PROTECTED] | choice. http://people.debian.org/~branden/ | msg09081/pgp0.pgp Description: PGP signature
RE: [Xpert]KDE3/i810 corruption - source pointers?
On Wed, 25 Sep 2002, Sottek, Matthew J wrote: No, blits from the Framebuffer to the Framebuffer would be correct. Blits from the pixmap cache to the framebuffer that are only 1 line would also be correct. I've posted a few example pics of the corruption I see: http://www.soudan.net/~bills/snapshot1.png - konq window w/ corrupted menubar http://www.soudan.net/~bills/snapshot2.png - gimp blown up version of corruption The corrupted regions are 14x22, with the exception of the one above 'hours'. Each region is a well-formed horizontal gradient (!). If the pitch was off while blitting from pixmap cache to framebuffer, wouldn't the corruption just be garbage? And a width of 14 seems like a really odd size for a blit to me. Maybe the problem then isn't with the blit from the pixmap cache to the framebuffer, but it's that the pixmap cache itself is getting corrupted? Jeff's memory management patch is looking fairly attractive. Bill ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]RE: Rép. : RE: [Xpert]KDE3/i810 corruption - source pointers?
There was some discussion of this problem on this list a while back. There is a separate set of overlay-fb alignment registers that are programmed relative to the timings being used. When you boot to a TV device the timings are not as programmed in the CRTC registers so the overlay is not properly aligned. The vBois put the timings in the TV timings regs and it is different depending on the 3rd part TV encoder used on your system. I thought that someone had provided a fix that programmed that register by looking at the TV timings (If the TV was being used) The register is called OVRACT, you may want to search the archives for some discussion of that register. -Matt -Original Message- From: Sebastien BASTARD [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 26, 2002 12:46 AM To: [EMAIL PROTECTED] Subject: Rép. : RE: [Xpert]KDE3/i810 corruption - source pointers? Hello, When i use xine to see the film in Xv mode, I have the screen film shift on the left (everage 16 pixels). If i set the resolution to 800x600, i have a blue screen (color_key). Is it the same problem about you talk when i use the Xv ouput on i810 ? Configuration : - XFree 4.2.1 - i810 - Resolution : 640x480x24 Thanks for all [EMAIL PROTECTED] 26/09/2002 00:07 Hola, This is just a hunch but I'm wondering if this could be a previously undetected problem in the XFree86 memory manager. I want you people who can reproduce the problem to try the above patch and tell me if it works. I unfortunately no longer have access to an i810 or i815 (or i830 or i845 for that matter.) So I can't test this to see if it works. If it does there is a problem with the memory manager using the leftover bit of memory on the side of the screen. Its probably very rare to hit the path and probably just a small calculation thats off somewhere. If this patch works it gives you a good data point at any rate, one thing which is not causing the problem. You might also try building the i810 driver with the #define XF86DRI not defined because that will make the pitch and the width always be the same. That will give you an additional data point to help you track down the problem. -Jeff ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]XFree86 CVS
Just out of curiousity i was wondering if anyone knew what features are currently only in the CVS? ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]XFree 4.2.1 and Riva 128 core dump
Hi! I have major problems with XFree 4.2.1 and RIVA 128, starting the server dumps core. I have built a debug version of the server and found out one NULL pointer... Any ideas why PCRTC is not initialized to anything meaningful? Martti --- Martti Kuparinen [EMAIL PROTECTED] NetBSD - No media hype http://www.iki.fi/kuparine/ http://www.netbsd.org/ ### Program received signal SIGSEGV, Segmentation fault. 0x8057a48 in LoadStateExt (chip=0x835e800, state=0x835e8c0) at riva_hw.c:1655 1655chip-PCRTC[0x0140/4] = 0; (gdb) (gdb) p chip $1 = (RIVA_HW_INST *) 0x835e800 (gdb) p chip-PCRTC $2 = (U032 *) 0x0 (gdb) ### XFree86 Version 4.2.1 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 3 September 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: NetBSD/i386 1.6 [ELF] The NetBSD Foundation, Inc. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Thu Sep 19 20:10:33 2002 (==) Using config file: /etc/X11/XF86Config (==) ServerLayout XFree86 Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Card0 (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc102 (**) XKB: model: pc102 (**) Option XkbLayout fi (**) XKB: layout: fi (==) Keyboard: CustomKeycode disabled (**) FontPath set to /usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/CID/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/ (**) RgbPath set to /usr/X11R6/lib/X11/rgb (--) Using pcvt driver (version 3.32) (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,7190 card , rev 02 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,7191 card , rev 02 class 06,04,00 hdr 01 (II) PCI: 00:04:0: chip 8086,7110 card , rev 02 class 06,01,00 hdr 80 (II) PCI: 00:04:1: chip 8086,7111 card , rev 01 class 01,01,80 hdr 00 (II) PCI: 00:04:2: chip 8086,7112 card , rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:04:3: chip 8086,7113 card , rev 02 class 06,80,00 hdr 00 (II) PCI: 00:0b:0: chip 1011,0009 card 1186,1100 rev 22 class 02,00,00 hdr 00 (II) PCI: 01:00:0: chip 12d2,0018 card 1092,1092 rev 10 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) PCI-to-ISA bridge: (II) PCI-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (-1,0,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0x - 0x (0x0) MX[B] (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x88 (VGA_EN is set) (II) Bus 1 I/O range: (II) Bus 1 non-prefetchable memory range: [0] -1 0xe100 - 0xe2af (0x1b0) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0xe2c0 - 0xe3ff (0x140) MX[B] (II) Bus -1: bridge is at (0:4:0), (0,-1,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus -1 I/O range: (II) Bus -1 non-prefetchable memory range: (II) Bus -1 prefetchable memory range: (--) PCI:*(1:0:0) NVidia/SGS-Thomson Riva128 rev 16, Mem @ 0xe100/24, 0xe300/24, BIOS @ 0xe2c0/22 (II) Addressable bus resource ranges are [0] -1 0x - 0x (0x0) MX[B] [1] -1 0x - 0x (0x1) IX[B] (II) OS-reported resource ranges: [0] -1 0xffe0 - 0x (0x20) MX[B](B) [1] -1 0x0010 - 0x3fff (0x3ff0) MX[B]E(B) [2] -1 0x000f - 0x000f (0x1) MX[B] [3] -1 0x000c - 0x000e (0x3) MX[B] [4] -1 0x - 0x0009 (0xa) MX[B] [5] -1 0x - 0x (0x1) IX[B] [6] -1 0x - 0x00ff (0x100) IX[B] (II) Active PCI resource ranges: [0] -1 0xe080 - 0xe0ff (0x80) MX[B]E [1] -1 0xe400 - 0xe7ff (0x400) MX[B]E [2] -1 0xe2c0 - 0xe2ff (0x40) MX[B](B) [3] -1 0xe300 - 0xe3ff (0x100) MX[B](B) [4] -1 0xe100 - 0xe1ff (0x100) MX[B](B) [5] -1 0xd000 - 0xd0ff (0x100) IX[B]E [6] -1 0xd400 -
Re: [Xpert]How to reinitialize the mouse / KVM problems
On Thu, 26 Sep 2002, Dave wrote: Hi, I think I have found a simple reproducible bug that makes the mouse/keyboard handler freak out. I don't think this has anything to do with my particular set up. I'm using Linux on Intel. The problem occurs with both the XFree86 VESA driver, and also with the closed NVidia Linux driver. Start X11 with any driver. Log in as root. Look at the date/time. Add 2 hours to the current time with 'date'. Move the time back to the correct time with 'date'. Now the keyboard and mouse will be screwed up. The keyboard no longer auto-repeats. The mouse sends incorrect click events. xev shows that when I press a mouse key, no event occurs. When I release the key, both events arrive. I can no longer move windows with the mouse (gnome/sawfish). gpm continues to work in the console. X11 auto-repeat no longer works. In my previous post, I thought this had something to do with suspend/resume. But that is simply because on my Inspiron 8200, when I come back from a suspend, my clock is wrong by a couple of hours (even if I suspend only for 5 seconds). APM resets the clock, and XFree is hosed. Can anybody else reproduce this problem? Is it Linux specific? I'd expect that time running backwards would screw up X-server events. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Bug with Matrox driver in mga_storm.c
I sumitted this bug report to [EMAIL PROTECTED], but haven't heard back... Any comments from the XFree86 team as to whether this patch is acceptable? Thanks, Ross [EMAIL PROTECTED] Regarding: Offscreen pixmap corruption can occur when switching virtual consoles Email: [EMAIL PROTECTED] XFree86 Version: 4.2.1 OS: Red Hat Linux 7.1 (2.4.2-2 kernel) Area: mga_drv.o Matrox graphics driver Server: XFree86 (The XFree86 4.x server) Server: XFree86 4.2.1 Video Card: Matrox MGA G400 AGP rev 130 Dual-Head mgag400 chipset 16 MB of Video RAM Description: With the above Matrox adapter, pixmap's can become corrupted when switching virtual consoles on Linux. The problem is that one of the Matrox specific variables that control's the source addresses for pixmap blits isn't being reset when returning to X. (see below for details) (*X output log snipped*) Repeat By: 1. Edit the /etc/X11/XF86Config-4 file and in the Section Device include: Option XaaNoMono8x8PatternFillRect on This will cause the MGA SubsequentScreenToScreenCopy()routine to be used to paint a solid color background. Also, configure this file to use an 8 bit color depth. 2. Create a ~/.xinitrc file with the contents exec fvwm2 3. run startx 4. Once X has come up, press Ctrl-Alt-F1 to return to a text virtual console. 5. Then press Alt-F7 to return back to X. The root window/background will appear corrupted, and will not display the initial color background in its original form. - Here is a technical explanation of the problem's source: The cause of the video corruption is that the Matrox video adapter's SRCORG register has an incorrect value when switching from the text console back into X. This register determines the base source address for the upcoming copy/blit operation. If the value is inaccurate, the offsets will be applied to the wrong base address, and the wrong content will be copied (hence the corruption). This register is reset to 0x0 in the MGAStormEngineInit() routine (which is invoked when switching back to X from a text console); however, the problem is that the pMga-SrcOrg variable is not. This variable is used in the SubsequentScreenToScreenCopy() and SubsequentScreenToScreenColorExpandFill () routines to determine whether the SRCORG register is current, and its value should correspond to the current SRCORG register value. The patch is to simply reset this variable to 0x0 in the MGAStormEngineInit() routine. I have tested the following patch, and it does indeed correct the situation. In addition, I have corresponded with Matrox, and they agree that the patch below addresses this problem. Please consider including it into your source code tree so this behavior will be fixed in future releases of XFree86. Many thanks, -Ross Here is the patch: --- programs/Xserver/hw/xfree86/drivers/mga/mga_storm.c Wed Sep 25 16:04:36 2002 +++ programs/Xserver/hw/xfree86/drivers/mga/mga_storm.c.fix Wed Sep 25 16:04:29 2002 @@ -1170,6 +1170,7 @@ case PCI_CHIP_MGAG400: case PCI_CHIP_MGAG200: case PCI_CHIP_MGAG200_PCI: + pMga-SrcOrg = 0; OUTREG(MGAREG_SRCORG, pMga-realSrcOrg); OUTREG(MGAREG_DSTORG, pMga-DstOrg); break; Ross A. Mikosh Software Engineer, Linux Change Team IBM Global Services [EMAIL PROTECTED], (512) 823-5606, T/L: 523-5606 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]ulong warning fixes
some recent warning fixes break cygwin compiling. e.g. in lib/Xmu/StrToCurs.c:172 a printf(%lu, sizeof(...)) was changed to printf(%lu, (ulong)sizeof(...)) and in lib/Xmu/WidgetNode.c But ulong is not defined on cygwin. What is the correct fix for this. Change the printf type to %u (which might break on 64 bit architectures) or using (unsigned long) or defining ulong for cygwin where it's needed? you must define a format string that matches your machine's size_t. try something like this: #if arch1 #define SIZE_T_FORMAT %lu #elif arch2 #define SIZE_T_FORMAT %u #else #error... #endif ... and then end up with the task of maintaining what arch1 arch2 are. Are you volunteering yourself, your children and your grandchildren for this task? Mine have better things to do. Marc. +--+---+ | Marc Aurele La France | work: 1-780-492-9310 | | Computing and Network Services | fax:1-780-492-1729 | | 352 General Services Building | email: [EMAIL PROTECTED] | | University of Alberta +---+ | Edmonton, Alberta | | | T6G 2H1 | Standard disclaimers apply| | CANADA | | +--+---+ XFree86 Core Team member. ATI driver and X server internals. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]All colors used up in PseudoColor
Hi! I have a problem running an application under XFree86 4.2.0 (RedHat Linux 7.3). The application I want to run can only be used with the X server in PseudoColor mode. It tries to allocate some private colors. When I start the X server in PseudoColor, almoast all colors are allocated by the X server itself (12 unused of 256 total). Why is this ? Can I prevent the X server from allocating the whole colormap ? Is this some kind of preallocation of colors that the X-server does to make applications use some standard color map ? I tried this by running the X server with: X -ac -noreset and from another computer (a Solaris machine) I run xdefmap -q, which sais: -- DefaultColormap Summary: unused : 12 entries shared : 244 entries private : 0 entries total : 256 entries -- SNIP I am now subscribing to the list. I first sent this mail when I was not subscribing to the list. Sorry if you get two copies. Best regards, Tobias ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 CVS
On Thu, Sep 26, 2002 at 09:03:47PM +0200, Michael wrote: Just out of curiousity i was wondering if anyone knew what features are currently only in the CVS? Not sure whether all of there already were merged, but, anyways, AFAIK, the following is in the schedule for 4.3.0: * Xft2 + fontconfig * Mesa 4 * GATOR drivers for ATI cards (gatos.sf.net) * Latest DRI code (dri.sf.net) * etc ;-) There are only the most viable for me, there might be dozens of lesser ones, surely. ./danfe ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]How to reinitialize the mouse / KVM problems
Hi, I realize that time running backwards is not supposed to happen, but it seems like things could be made a bit more robust (like gpm, which keeps running)--and re-initialization should be possible. But I get your point, I have solved my problem, and I'll shut up. Dave. Mark Vojkovich wrote: I'd expect that time running backwards would screw up X-server events. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]KDE3/i810 corruption - source pointers?
Bill Soudan writes: On Wed, 25 Sep 2002, Sottek, Matthew J wrote: No, blits from the Framebuffer to the Framebuffer would be correct. Blits from the pixmap cache to the framebuffer that are only 1 line would also be correct. I've posted a few example pics of the corruption I see: http://www.soudan.net/~bills/snapshot1.png - konq window w/ corrupted menubar http://www.soudan.net/~bills/snapshot2.png - gimp blown up version of corruption The corrupted regions are 14x22, with the exception of the one above 'hours'. Each region is a well-formed horizontal gradient (!). If the pitch was off while blitting from pixmap cache to framebuffer, wouldn't the corruption just be garbage? And a width of 14 seems like a really odd size for a blit to me. Maybe the problem then isn't with the blit from the pixmap cache to the framebuffer, but it's that the pixmap cache itself is getting corrupted? Jeff's memory management patch is looking fairly attractive. The XAA code uses ScreenToScreenCopy to create a background pixmap in offscreen memory out of the elemantary tile. In KDE the backgrounds of the menu bars are created this way. When a menu bar needs to be redrawn XAA simply copies a portion from this offscreen pixmap into the framebuffer. Now the problem: The i810 blit engine seems to be broken in that it cannot copy a portion of the framebuffer right to the right of itself if the width of this area is in a certain range. I found that out by trial and error as Intel appearantly doesn't provide errata sheets. I've attempted to make a fix for this which I will soon commit to CVS. I don't know it it catches all cases however the KDE desktop on my test machine appears to be uncorrupted now. Your milage may vary. Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]XFree86 CVS
On Fri, Sep 27, 2002 at 12:43:29PM +0200, Xavier Bestel wrote: Le ven 27/09/2002 à 12:09, Alexey Dokuchaev a écrit : On Thu, Sep 26, 2002 at 09:03:47PM +0200, Michael wrote: Just out of curiousity i was wondering if anyone knew what features are currently only in the CVS? Not sure whether all of there already were merged, but, anyways, AFAIK, the following is in the schedule for 4.3.0: * Xft2 + fontconfig * Mesa 4 * GATOR drivers for ATI cards (gatos.sf.net) * Latest DRI code (dri.sf.net) * etc ;-) Does that mean that we will need to patch our kernel by hand to use an r128 ? Right now the gatos driver seems to have problems with the stock kernels and needs its own, which is still not merged in the mainline. Dunno. Especially if you are talking about Linux kernels, since I don't run Linux anywhere near. [Hint: FreeBSD is the way to go :-P] Nevertheless, I'd like to hear from someone competent enough WRT this subject. ./danfe ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]KDE3/i810 corruption - source pointers?
On Fri, 27 Sep 2002, Egbert Eich wrote: Now the problem: The i810 blit engine seems to be broken in that it cannot copy a portion of the framebuffer right to the right of itself if the width of this area is in a certain range. Even if the source destination regions don't overlap? That sounds surprisingly broken. The problem is very intermittent on my machine. Once it happens, though, the corruption sticks around for a while. Filling up my display with konqueror windows pointed to different websites is the most reliable way I've found to trigger the bug, and likewise, closing windows and freeing resources in general seems to make it go away. Could this be explained by XAA generating blit requests for this buggy width during the times I experience the corruption? I found that out by trial and error as Intel appearantly doesn't provide errata sheets. I've attempted to make a fix for this which I will soon commit to CVS. I don't know it it catches all cases however the KDE desktop on my test machine appears to be uncorrupted now. Your milage may vary. What sort of workaround did you put in? I'd be happy to give the patch a shot if you'd like to send it this way. I did find an errata pdf on Intel's website alongside the specs, and it even lists a blitter bug, but I ignored it as it didn't sound relevant. Still doesn't, apparently a few pixels at the end of each scanline get skewed. Certainly shouldn't corrupt a vertical gradient, in any case. Thanks, Bill ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]All colors used up in PseudoColor
On Fri, 27 Sep 2002 [EMAIL PROTECTED] wrote: Hi! I have a problem running an application under XFree86 4.2.0 (RedHat Linux 7.3). The application I want to run can only be used with the X server in PseudoColor mode. It tries to allocate some private colors. When I start the X server in PseudoColor, almoast all colors are allocated by the X server itself (12 unused of 256 total). Why is this ? Can I prevent the X server from allocating the whole colormap ? Is this some kind of preallocation of colors that the X-server does to make applications use some standard color map ? It's the render extension. It's fixed in CVS. Or if you are running NVIDIA's binary Linux drivers you can specify Option NoRenderExtension in the Section Device of the XF86Config to disable the render extension. That only works with recent NVIDIA drivers though. It's not a general XFree86 option. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]MIME attachment handler in hypermail subtly corrupts attachments
On Fri, Sep 27, 2002 at 01:35:42AM -0500, Branden Robinson wrote: Maybe this is already common knowledge, but it surprised me. I was reviewing the patches I sent to [EMAIL PROTECTED], and noticed that a patch I submitted got corrupted. The message: http://www.xfree86.org/devel/archives/patch/2002-Sep/0008.shtml The attachment: http://www.xfree86.org/devel/archives/patch/2002-Sep/handle_vetoed_suspend.diff This is the troublesome line: + if (errno = EBUSY) Of course that shouldn't be an assignment...and, in fact, it wasn't in the mail I sent out. I think there is a bug in a MIME parser somewhere, probably in hypermail, that collapsed the == to a =. I don't know how the process of patch merging works, but this sort of corruption of attachments could really waste some time and introduce some subtle bugs. It looks like a problem with the mail archiver. The copy I have in my mailbox is as it should be (and that's what I always use). David -- David Dawes Release Engineer/Architect The XFree86 Project www.XFree86.org/~dawes ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Radeon clone mode bug(s) + fix
Ok, as I still have no idea about the procedure used for working with the XFree86 code in general, and with ATI Radeon driver in particular, there are (hopefully) simple questions: - what should I do in order to have a patch which fixes obvious bugs applied? - what should I do if I want to work on much less obvious things like adding support for user-selectable output config (possibly including TV output, and fixing existing problems like the one with TV connected to TV-out)? -- Krzysztof Halasa Network Administrator ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
