Hafiz Info regarding vigra
unanimity, How Vigras works. And you can better understand, what Vigras can do for you. If you are sensible about your health, reflect on what you can do for your seual health, to keep the chances that you will need Vigras as low as possible. sexist among smeared, leafing. http://www.pvmsolutions.com/index.php?pid=pharmaboss Inrease Seks Drive Bost Seual Performance Fuller & Harder Erecions Inrease Stamna & Endurance Quicker Rechages adulterers prosper Brandeis, Baden. exploiter arches cursors, words. Happy holidays, Patricia ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS XFree (savage driver) xsuite failures
Hello,
Mark Vojkovich wrote:
> On Mon, 19 Jan 2004, David Dawes wrote:
>
> > >Tests for XChangeKeyboardControl
> > >Test 9: FAIL
> > >Test 10: FAIL
> >
> > That has been showing up for a while. It should be followed up.
>
>That's been showing up for a couple years. It's a regression.
I think the tests are incorrect. Both tests try to set keyboard LEDs (using
XChangeKeyboardControl) then read the LEDs state (XGetKeyboardControl) and
compare values. The difference between the tests is that the first one tries
to change some of LEDs (uses some mask) and the second one tries to set all
LEDs together (without specifying a particular LED number).
But some LEDs can be protected from their change by client application and
reflect keyboard state only.
The man about {Change|Get}KeyboardControl tells:
XChangeKeyboardControl - "...the state of that leds is changed, if possible.."
XGetKeyboardControl - "...each bit set to 1 in led_mask indicates an LED that
is lit...". (Note "if possible" and "an LED that is lit".)
I understand it as Get returns the actual state of LEDs, those that are not
protected and were changed by Change and those that are protected but are
switched on reflecting the keyboard state.
But the tests, obviously, are written in assumption that Get should return the
LED state exactly as it was written into keyboard by Change call. It means all
LEDs should be unprotected (it is not by default) or the keyboard control
structure keeps values written by XChangeKeyboardControl call(s) and at the
XGetKeyboardControl request just returns this record instead of real state
of LEDs.
BTW, the "fix" for this "regression" is very simple. We just have to remove
one line in dix/devices.c where the LEDs mask field of the keyboard controls
structure is being reloaded with the actual LEDs state. The tests will be
passed with success. But there will not be any way (in the core protocol)
to know the real state of LEDs.
> >
> > >Tests for XRebindKeysym
> > >Test 1: FAIL
> >
> > The XRebindKeysym failure goes away if XKB is disabled.
>
>Yes, it's a XKB problem/feature.
It is a feature. :)
This problem can be fixed easy too with 'one word patch'. But there is one
unclear thing there.
The RebindKeysym mechanism allows to tie any string to a keysym or a combination
of keysym and a set of modifiers. The binding itself works well, the problem
is the modifiers set interpretation.
For example, we have a key with two keysyms [a A] and want to bind two different
strings to combiantions Alt+a and Alt+A. How should we specify the second
combination - Alt + 'A', Alt + Shift + 'a' or Alt + Shift + 'A'?
The core protocol's assumes the third variant, i.e. takes the keysym figured
out with taking in account the Shift modifier but also checks all modifiers
obtained from the key event.
But the XKB-aware XLookupString 'consumes' all modifiers used at the keysym
choosing and hide them from the routine that checks string_to_key bindins,
i.e. it expects that the combiantion is just Alt + 'A'.
BTW, this behavour can be swithed on/off with a special 'client side XKB' flag
but by default XLookupString 'eats' consumed modifiers.
Thus the problem is what modifiers set should the bindings check routine use.
Shoud it always be the original 'state' field from the key event or the
consumed modifiers may be removed from a consideration. If we require there
a full compatibility with the core protocol the answer is obvious. But some
calls in XKB-aware Xlib already have differences from core protocol ones.
And the first form of that combination seems to me more logical (IMHO,
of course).
Side note: I wonder if anybody (anything) uses this 'rebind keysym' feature
anywhere.
On the other hand the test itself could be changed. One way is to make it
XKB-aware and make it set the needed flag (that turns the XLookupString
behavior to the 'core protocol like' one). Another way is don't use the Shift
modifier (that can be 'eaten' under some circumstance) there. All other
modifiers (except Caps) would be interpreted equaly in both (with/without XKB)
cases.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: ansification of XUtil.h
David Dawes wrote: > On Mon, Jan 19, 2004 at 06:30:14AM -0600, Warren Turkal wrote: >>Here is a patch that ansifies XUtil.h. I consider this low risk because I >>did not create any of the prototypes, they were already there. I would >>like to get some input on this change though. This patch appears to also >>have some whitespace policing as well. > > I removed all the '#if NeedFunctionPrototypes' stuff about 2 months > ago in the current XFree86 CVS trunk. You must be working against some > older version. > > David Thanks...sorry. wt -- Warren Turkal President, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [GATOS]how to check if hardware mpeg2 decoder is working
Alex Deucher wrote: [snip this time the DRI was enabled: (II) RADEON(0): [drm] installed DRM signal handler (II) RADEON(0): [DRI] installation complete (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEON(0): [drm] dma control initialized, using IRQ 11 (II) RADEON(0): [drm] Initialized kernel agp heap manager, 5111808 (II) RADEON(0): Direct rendering enabled If glxinfo still shows indirect rendering, then I suspect you may have a problem with your copy of libGL. check to make sure you don't have multiple copies floating around. Use ldd to find out what version your apps are using. [snip] Alex, I can't have multiple copies floating around because I did a fresh install on a formatted partition. Also, rpm would have a hissy fit if I tried that. I checked which libGL is being used, and it is the same one that came along when I installed Red Hat Linux 9 on here. Perhaps there is some incompatibilty between the GATOS drivers and the libGL that came with Red Hat Linux 9. Do the GATOS drivers expect any particular version of libGL? Is there something besides the remap_page_range patch in the drivers' sources that I might need to patch? I'm going to write another message with a different subject asking if any other Red Hat Linux 9 users on the list have had problems, because we are way off the topic of DVD decoding now. Peace, William ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Tue, Jan 20, 2004 at 10:53:06PM -0500, David Dawes wrote: > > > >Someone needs to track down the bug that causes a server crash and > >subsequent lockup if a dualhead config is used but mga_hal is not > >available (either not around or wasn't compiled with support for it). I > >thought I fixed it with a oneliner in that patch but it turns out that > >I was using the wrong config at the time to test it. > > Does your patch reduce the need for the mga_hal module for dual-headed > configurations? That'd be nice. Yes, one goal is that I'm trying to eliminate the necessity of mga_hal at least on my G400MAX. The other is to optionally expose maven functionality in XFree86. This will be a configuration option so that we don't conflict with matroxfb maven usage. I don't know what I can do for G450/G550 since I have none of those.:( But it appears only G400 needs the HAL? #define MGA_DH_NEEDS_HAL(x) (((x)->Chipset == PCI_CHIP_MGAG400) && \ ((x)->ChipRev < 0x80)) Are all other mga chipsets HAL-free at this point? -- Ryan Underwood, <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Tue, Jan 20, 2004 at 02:13:50PM -0800, Alex Deucher wrote: > > --- Ryan Underwood <[EMAIL PROTECTED]> wrote: > [snip] > > > > No code was copied, only some defines. I need other people to check > > the > > code and tell me if it will break on other video cards. I only have > > a > > G400 DH, but there is G450, G550, G200 DH, G200 non-maven DH, etc > > which > > need to be tested, and some changes were made to the main driver code > > too so there is a potential I made a mistake that would affect even > > non-G series matrox cards. The main thing I am worrying about is how > > some of the maven registers I used will behave on different cards. > > Right now I am trying to get DDC working on port 2 so I can be sure > > my > > i2c code is 100% correct. > > > > You might ask Petr or one of the kernel fbdev or directfb developers. > they might be able to help you. unfortunately all my matrox cards have > either died or or are no longer around :( I got DDC working. It was my second monitor that was the problem; its EDID data seems to be corrupt. It doesn't even work on the first head, and I can read my first monitor's EDID on the second head, so looks like we are in business. -- Ryan Underwood, <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Tue, Jan 20, 2004 at 03:52:45PM -0600, Ryan Underwood wrote: > >On Tue, Jan 20, 2004 at 08:23:55AM -0800, Alex Deucher wrote: >> > > >> > > I don't run XFree86 except when trying to hunt DRI related bugs. >> > It's >> > > been well over a year since I really used XFree86 and I honestly >> > don't >> > > remember if DPMS ever worked with the second head. I don't have a >> > second >> > > monitor to test right now. >> > >> > I just uploaded a patch to the bug tracker that makes DPMS work on >> > the >> > second head among other things (i2c/maven related). >> >> if you copied any code directly from the mga FB driver, you need to ask >> Petr Vandrovec if you can release it with a X11 license because the FB >> driver is GPL'ed. I think in the past Petr said he didn't care, but >> it's worth asking again. FWIW, I'd love to see native maven support in >> the X11 driver. > >No code was copied, only some defines. I need other people to check the >code and tell me if it will break on other video cards. I only have a >G400 DH, but there is G450, G550, G200 DH, G200 non-maven DH, etc which >need to be tested, and some changes were made to the main driver code >too so there is a potential I made a mistake that would affect even >non-G series matrox cards. The main thing I am worrying about is how >some of the maven registers I used will behave on different cards. >Right now I am trying to get DDC working on port 2 so I can be sure my >i2c code is 100% correct. > >Someone needs to track down the bug that causes a server crash and >subsequent lockup if a dualhead config is used but mga_hal is not >available (either not around or wasn't compiled with support for it). I >thought I fixed it with a oneliner in that patch but it turns out that >I was using the wrong config at the time to test it. Does your patch reduce the need for the mga_hal module for dual-headed configurations? That'd be nice. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: -rpath not used under Linux
On Tue, Jan 20, 2004 at 10:54:05PM +0100, Martin MOKREJS wrote: >On Thu, 8 Jan 2004, David Dawes wrote: > >Hi, > so I downloaded latest cvs version of xc and compiled with defaults on >Linux. Running "ldd ./programs/xdm/xdm" show xlibs are resolved from >/usr/X11R6/lib. OK, I edited /etc/ld.so.conf and commented out line >/usr/X11R6/lib and rerun ldconfig. Ran "ldd ./programs/xdm/xdm" and yes, >xlibs are unresolved. Shutdown your xdm session and try to start again, you >will not be able to fire it up unlesss you edit ld.so.conf again and rerun >ldconfig. > > I think the default USRLIBDIRPATH ^H^H^H^H^H^H^ SHLIBDIRPATH should be >compiled in by default. Yes, some systems will need either -rpath or -R as >noted in this thread. I don't have any objections to doing this on Linux. As I said, we already do it on a range of other platforms and I'm not sure why Linux is something of an exception in this regard. Does anyone have a good reason to not do this? David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Question regarding VT switches
Oh, I forgot to inform the XFree86 release. I'm running XFree86 4.3 here (didn't test with the latest CVS version yet). Lucas On Tuesday 20 January 2004 20:10, Lucas Correia Villa Real wrote: > Hi, > > I have a problem when I boot linux (2.4.x and 2.6.x) with video=atyfb and > using the XFree86 'ati' video driver: whenever I switch to any VT console > from X (tty1, tty2, ...), a lot of green blocks appear blinking on the > screen, and then the console sessions become unusable (it's ok to switch > back to X). > > When booting with vesafb these green blocks doesn't appear when switching > back into a VT, but a blank screen appears instead. Does anyone have an > idea on where should I go to try to fix this issue (linux' vesafb + atyfb > or XFree86)? > > I don't know if this is related to the XFree86' ati driver or to the > atyfb/vesafb kernel driver, but any help will be kindly appreciated. > > This is how 'lspci' identifies my video card: > > 02:0d.0 VGA compatible controller: ATI Technologies Inc 3D Rage II+ 215GTB > [Mach64 GTB] (rev 9a) (prog-if 00 [VGA]) > Subsystem: ATI Technologies Inc 3D Rage II+ 215GTB [Mach64 GTB] > Flags: bus master, stepping, medium devsel, latency 0, IRQ 5 > Memory at ec00 (32-bit, non-prefetchable) [size=16M] > I/O ports at b800 [size=256] > Memory at eb80 (32-bit, non-prefetchable) [size=4K] > Expansion ROM at ee7c [disabled] [size=128K] > > Thanks, > Lucas > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] MGA font corruption revisited - now reproducible
--- Ryan Underwood <[EMAIL PROTECTED]> wrote: [snip] > > No code was copied, only some defines. I need other people to check > the > code and tell me if it will break on other video cards. I only have > a > G400 DH, but there is G450, G550, G200 DH, G200 non-maven DH, etc > which > need to be tested, and some changes were made to the main driver code > too so there is a potential I made a mistake that would affect even > non-G series matrox cards. The main thing I am worrying about is how > some of the maven registers I used will behave on different cards. > Right now I am trying to get DDC working on port 2 so I can be sure > my > i2c code is 100% correct. > You might ask Petr or one of the kernel fbdev or directfb developers. they might be able to help you. unfortunately all my matrox cards have either died or or are no longer around :( Alex __ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Question regarding VT switches
Hi, I have a problem when I boot linux (2.4.x and 2.6.x) with video=atyfb and using the XFree86 'ati' video driver: whenever I switch to any VT console from X (tty1, tty2, ...), a lot of green blocks appear blinking on the screen, and then the console sessions become unusable (it's ok to switch back to X). When booting with vesafb these green blocks doesn't appear when switching back into a VT, but a blank screen appears instead. Does anyone have an idea on where should I go to try to fix this issue (linux' vesafb + atyfb or XFree86)? I don't know if this is related to the XFree86' ati driver or to the atyfb/vesafb kernel driver, but any help will be kindly appreciated. This is how 'lspci' identifies my video card: 02:0d.0 VGA compatible controller: ATI Technologies Inc 3D Rage II+ 215GTB [Mach64 GTB] (rev 9a) (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc 3D Rage II+ 215GTB [Mach64 GTB] Flags: bus master, stepping, medium devsel, latency 0, IRQ 5 Memory at ec00 (32-bit, non-prefetchable) [size=16M] I/O ports at b800 [size=256] Memory at eb80 (32-bit, non-prefetchable) [size=4K] Expansion ROM at ee7c [disabled] [size=128K] Thanks, Lucas ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Radeon module memleak and buggy bios?
Hi, I'm getting with current cvs version of xc: [drm:radeon_ioremapfree:mappings] *ERROR* Attempt to free NULL pointer [drm:radeon_ioremapfree:mappings] *ERROR* Excess frees: 5 frees, 4 allocs [drm] Loading R200 Microcode [drm:radeon_ioremapfree:mappings] *ERROR* Excess frees: 9 frees, 8 allocs [drm:radeon_ioremapfree:mappings] *ERROR* Attempt to free NULL pointer [drm:radeon_ioremapfree:mappings] *ERROR* Excess frees: 10 frees, 8 allocs [drm] Loading R200 Microcode [drm:radeon_ioremapfree:mappings] *ERROR* Excess frees: 13 frees, 12 allocs [drm:radeon_ioremapfree:mappings] *ERROR* Excess frees: 14 frees, 12 allocs [drm:radeon_ioremapfree:mappings] *ERROR* Attempt to free NULL pointer [drm:radeon_ioremapfree:mappings] *ERROR* Excess frees: 15 frees, 12 allocs [drm] Loading R200 Microcode lsmod shows radeon module is load on this 2.4.25-pre4 host. (II) Setting vga for screen 0. (II) RADEON(0): MMIO registers at 0xfe8f (II) Loading sub module "vgahw" (II) LoadModule: "vgahw" (II) Loading /usr/X11R6/lib/modules/libvgahw.a (II) Module vgahw: vendor="The XFree86 Project" compiled for 4.3.99.902, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.7 (II) RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x (II) RADEON(0): PCI bus 1 card 0 func 0 (**) RADEON(0): Depth 24, (--) framebuffer bpp 32 (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) (==) RADEON(0): Default visual is TrueColor (==) RADEON(0): RGB weight 888 (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) (II) Loading sub module "int10" (II) LoadModule: "int10" (II) Loading /usr/X11R6/lib/modules/linux/libint10.a (II) Module int10: vendor="The XFree86 Project" compiled for 4.3.99.902, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.7 (II) RADEON(0): initializing int10 (WW) RADEON(0): Bad V_BIOS checksum (II) RADEON(0): Primary V_BIOS segment is: 0xc000 (--) RADEON(0): Chipset: "ATI Radeon 9200 5961 (AGP)" (ChipID = 0x5961) (--) RADEON(0): Linear framebuffer at 0xd000 (--) RADEON(0): BIOS at 0xfe8c (--) RADEON(0): VideoRAM: 131072 kByte (128 bit DDR SDRAM) (II) RADEON(0): AGP card detected I have brand new 9200 card, buggy BIOS, really? I don't remember seeing that message with 4.3.0 with the same hardware. (II) RADEON(0): [drm] created "radeon" driver at busid "PCI:1:0:0" (II) RADEON(0): [drm] added 8192 byte SAREA at 0xf8d52000 (II) RADEON(0): [drm] mapped SAREA 0xf8d52000 to 0x40016000 (II) RADEON(0): [drm] framebuffer handle = 0xd000 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x1f004a09 [AGP 0x8086/0x2578; Card 0x1002/0x5961] (II) RADEON(0): [agp] 8192 kB allocated with handle 0xf8d55000 (II) RADEON(0): [agp] ring handle = 0xe800 (II) RADEON(0): [agp] Ring mapped at 0x48267000 (II) RADEON(0): [agp] ring read ptr handle = 0xe8101000 (II) RADEON(0): [agp] Ring read ptr mapped at 0x40018000 (II) RADEON(0): [agp] vertex/indirect buffers handle = 0xe8102000 (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x48368000 (II) RADEON(0): [agp] GART texture map handle = 0xe8302000 (II) RADEON(0): [agp] GART Texture map mapped at 0x48568000 (II) RADEON(0): [drm] register handle = 0xfe8f (II) RADEON(0): [dri] Visual configs initialized (II) RADEON(0): CP in BM mode (II) RADEON(0): Using 8 MB GART aperture (II) RADEON(0): Using 1 MB for the ring buffer (II) RADEON(0): Using 2 MB for vertex/indirect buffers (II) RADEON(0): Using 5 MB for GART textures (II) RADEON(0): Memory manager initialized to (0,0) (1280,8191) (II) RADEON(0): Reserved area from (0,1024) to (1280,1026) (II) RADEON(0): Largest offscreen area available: 1280 x 7165 (II) RADEON(0): Will use back buffer at offset 0x140 (II) RADEON(0): Will use depth buffer at offset 0x190 (II) RADEON(0): Will use 100352 kb for textures at offset 0x1e0 (II) RADEON(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 Scanline Image Writes Offscreen Pixmaps Setting up tile and stipple cache: 32 128x128 slots 32 256x256 slots 16 512x512 slots (II) RADEON(0): Acceleration enabled (==) RADEON(0): Backing store disabled (==) RADEON(0): Silken mouse enabled (II) RADEON(0): Using hardware cursor (scanline 1026) (II) RADEON(0): Largest offscreen area available: 1280 x 7161 (**) Option "dpms" (**) RADEON(0): DPMS enabled (II) RADEON(0): X context handle = 0x0001 (II) RADEON(0): [drm] installed DRM signal handler (II) RADEON(0): [DRI] installation complete (II) RADEON(0): [drm] Added 32 65536 byte vertex/indirect buffers (II) RADEON(0): [drm] Mapped 32 vertex/indirect buffers (II) RADEON(0): [drm] dma control initialized, using IRQ 16 (II) RADEON(0): [drm] Initialized kernel GART
Re: -rpath not used under Linux
On Thu, 8 Jan 2004, David Dawes wrote: Hi, so I downloaded latest cvs version of xc and compiled with defaults on Linux. Running "ldd ./programs/xdm/xdm" show xlibs are resolved from /usr/X11R6/lib. OK, I edited /etc/ld.so.conf and commented out line /usr/X11R6/lib and rerun ldconfig. Ran "ldd ./programs/xdm/xdm" and yes, xlibs are unresolved. Shutdown your xdm session and try to start again, you will not be able to fire it up unlesss you edit ld.so.conf again and rerun ldconfig. I think the default USRLIBDIRPATH ^H^H^H^H^H^H^ SHLIBDIRPATH should be compiled in by default. Yes, some systems will need either -rpath or -R as noted in this thread. Ideas? Martin > On Wed, Jan 07, 2004 at 08:00:27PM +0100, Mario Klebsch wrote: > >Hi! > > > >Am Mittwoch, 07.01.04 um 14:00 Uhr schrieb Martin MOKREJ: > >> I believe -Wl,-rpath,$(SHLIBDIRPATH) should be used on Linux and > >> possibly > >> all Unix platforms. > > > >Me too, in fact, I am convinced, this should be done. But this probably > >is a religious issue. > > It is done on most platforms that support this type of thing. > > The Linux settings (in lnxLib.rules) are: > > # if LinuxBinUtilsMajorVersion >= 26 > # ifdef UseInstalled > #if LinuxBinUtilsMajorVersion < 27 > # define ExtraLoadFlags -Wl,-rpath-link,$(USRLIBDIRPATH) > #endif > # else > #define ExtraLoadFlags -Wl,-rpath-link,$(BUILDLIBDIR) <=== > # endif > # else > # define ExtraLoadFlags -Wl,-rpath,$(USRLIBDIRPATH) > # endif > > LinuxBinUtilsMajorVersion is somewhat mis-named. For binutils versions x.y.z, > > LinuxBinUtilsMajorVersion = x * 10 + yx < 2 || (x == 2 && y <= 9) > LinuxBinUtilsMajorVersion = x * 100 + y otherwise > > I don't know why ExtraLoadFlags is set this way. The setting I've marked > with "<===" is what gets used on any modern Linux. If it is a religious > issue, it's not an XFree86 religious issue, but probably a Linux one > :-). Or maybe it is just an oversight. > > What I am most curious about is why the original reporter is seeing a > problem and most others apparently do not. I never have, providing I > re-run ldconfig after installing new libraries (and I never use > LD_LIBRARY_PATH, which I agree is not a solution). > > David > -- Martin Mokrejs <[EMAIL PROTECTED]> PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [Dri-devel] MGA font corruption revisited - now reproducible
On Tue, Jan 20, 2004 at 08:23:55AM -0800, Alex Deucher wrote: > > > > > > I don't run XFree86 except when trying to hunt DRI related bugs. > > It's > > > been well over a year since I really used XFree86 and I honestly > > don't > > > remember if DPMS ever worked with the second head. I don't have a > > second > > > monitor to test right now. > > > > I just uploaded a patch to the bug tracker that makes DPMS work on > > the > > second head among other things (i2c/maven related). > > if you copied any code directly from the mga FB driver, you need to ask > Petr Vandrovec if you can release it with a X11 license because the FB > driver is GPL'ed. I think in the past Petr said he didn't care, but > it's worth asking again. FWIW, I'd love to see native maven support in > the X11 driver. No code was copied, only some defines. I need other people to check the code and tell me if it will break on other video cards. I only have a G400 DH, but there is G450, G550, G200 DH, G200 non-maven DH, etc which need to be tested, and some changes were made to the main driver code too so there is a potential I made a mistake that would affect even non-G series matrox cards. The main thing I am worrying about is how some of the maven registers I used will behave on different cards. Right now I am trying to get DDC working on port 2 so I can be sure my i2c code is 100% correct. Someone needs to track down the bug that causes a server crash and subsequent lockup if a dualhead config is used but mga_hal is not available (either not around or wasn't compiled with support for it). I thought I fixed it with a oneliner in that patch but it turns out that I was using the wrong config at the time to test it. -- Ryan Underwood, <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: CVS XFree (savage driver) xsuite failures
On Tue, Jan 20, 2004 at 10:28:16AM -0800, Mark Vojkovich wrote: > On Tue, 20 Jan 2004, Nicolas Joly wrote: > > > >If your lines are correct, you should be able to run: > > > http://www.xfree86.org/~mvojkovi/linetest.c > > > without artifacts. > > > > The lines seems wrong as i do see artifacts when running the > > program with zero width lines (works fine for w>0). > >If you add to the Section "Device" of the XF86Config file: > > Option "XaaNoSolidTwoPointLine" > > that will force the XAA to only use the driver's Bresenham line > export. Does that change the behavior? Yes ! I do not see the problem with the linetest program anymore. Will check (in a day or two) with the testsuite, and report. -- Nicolas Joly Biological Software and Databanks. Institut Pasteur, Paris. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: CVS XFree (savage driver) xsuite failures
On Tue, 20 Jan 2004, Nicolas Joly wrote: > >If your lines are correct, you should be able to run: > > http://www.xfree86.org/~mvojkovi/linetest.c > > without artifacts. > > The lines seems wrong as i do see artifacts when running the program > with zero width lines (works fine for w>0). If you add to the Section "Device" of the XF86Config file: Option "XaaNoSolidTwoPointLine" that will force the XAA to only use the driver's Bresenham line export. Does that change the behavior? Mark. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Your details
Thank you for contacting Network Solutions. We no longer use e-mailboxes with the extension @netsol.com. Please replace @netsol.com with @networksolutions.com and resubmit your question. Sincerely, Network Solutions Customer Service This e-mail was sent from a notification-only address and cannot receive incoming e-mail messages or replies. If you have any questions, contact Customer Service at [EMAIL PROTECTED] or by phone at 1-888-642-9675 within the U.S. and Canada or at 1-703-742-0914 outside the U.S. © 2003 Network Solutions, Inc. All rights reserved. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Files with wrong exec bits set
On Mon, Jan 19, 2004 at 04:46:25PM +0900, Bang Jun-Young wrote:
>Hi,
>
>There are a lot of source files that have wrong exec bits set in the
>repository. Although this is not a problem for most of cases, it bothers
>me (and possibly other subversion users as well) quite a lot when I
>import xc into the subversion repository since subversion keeps track
>of metadata changes as well as file content changes. Could anybody deal
>with that? Those file include extras/ogl-sample/../*.{c,cc,h,gl},
>Imakefile, GNUmakefile, Distfile, and etc.
I'll take a look at it.
David
--
David Dawes X-Oz Technologies
www.XFree86.org/~dawes www.x-oz.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: Spec Files and the *.ms
On Tue, Jan 20, 2004 at 12:22:27AM -0500, Wade Chandler wrote: >What type of files are the .ms files in the Spec directory? I was just >wondering. Troff/nroff, using the ms macros. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Spec files and imake
On Tue, Jan 20, 2004 at 12:36:29AM -0500, Wade Chandler wrote: >I'm not very familiar with imake, but I've been reading the man file, >and I'm not sure exactly what pieces I need to be able to generate all >the spec documents. I viewed the specindex.html file and realized the >docs aren't there. I dug deeper and realized the make file. Then I >looked up imake. It's giving me an error: Imakefile.c:35...I noticed >this is the default file which imake searches for to pre-process.it >isn't there, and there is no generation script. Any advice is greatly >appreciated as I figure these docs are a good starting point. Postscript versions of the docs can be found under xc/doc/hardcopy. I generate the html/ps/pdf/txt versions as part of a full XFree86 build by putting the following in my xc/config/cf/host.def file: #define HasLatexYES #define HasGhostScript YES #define HasGroffHtmlYES #define HasPdfLatex YES #define BuildSpecsDocs YES #define BuildAllSpecsDocs YES #define InstallHardcopyDocs YES #define HardcopyDocDirs RX XKB XPRINT David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Spec Files and the *.ms
What type of files are the .ms files in the Spec directory? I was just wondering. Thanks, Wade ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
