Re: xaa vs. WriteImage()
On Thu, Mar 6, 2008 at 4:26 PM, Michael Lorenz [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On Mar 6, 2008, at 15:58, Alex Deucher wrote:
On Thu, Mar 6, 2008 at 2:58 PM, Michael Lorenz
[EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On Mar 6, 2008, at 14:12, Alex Deucher wrote:
On Thu, Mar 6, 2008 at 2:00 PM, Michael Lorenz
[EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On Mar 5, 2008, at 19:06, Alex Deucher wrote:
On Tue, Mar 4, 2008 at 5:34 PM, Michael Lorenz
[EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
On Mar 4, 2008, at 15:37, Marc Aurele La France wrote:
On Mon, 3 Mar 2008, Michael Lorenz wrote:
I noticed the following - XAACopyArea() only attempts to use
accelerated WriteImage() when writing to a DRAWABLE_WINDOW but
not
on off-screen pixmaps. I used the following changes to make it
work:
diff -u -w -r1.1.1.3 xaaCpyArea.c
- --- xaaCpyArea.c 9 Jun 2001 15:09:02 - 1.1.1.3
+++ xaaCpyArea.c 3 Mar 2008 20:51:05 -
@@ -64,9 +64,16 @@
return (XAABitBlt( pSrcDrawable, pDstDrawable,
pGC, srcx, srcy, width, height, dstx, dsty,
XAADoBitBlt, 0L));
+} else {
+if(infoRec-ScreenToScreenBitBlt
+ CHECK_ROP(pGC,infoRec-ScreenToScreenBitBltFlags)
+ CHECK_ROPSRC(pGC,infoRec-
ScreenToScreenBitBltFlags)
+ CHECK_PLANEMASK(pGC,infoRec-
ScreenToScreenBitBltFlags))
+return (XAABitBlt( pSrcDrawable, pDstDrawable,
+pGC, srcx, srcy, width, height, dstx, dsty,
+XAADoImageWrite, 0L));
}
}
This does not look correct. Shouldn't this be more in line with
the case where the destination drawable is a window? (i.e. test
bitsPerPixel's and WritePixmap files instead of
ScreenToScreenBitBlt).
The whole logic looks a little bit fishy, I used the first if
()'s
source-in-memory branch first but wasn't quite sure if that's
doing
the right thing, where it;s now looked better to me but I won't
claim
I completely understand XAA's inner voodoo. All I want is the
make
XAA use ImageWrite()s for all RAM-to-VRAM transfers if the
driver
supports it.
Otherwise, teaching the framebuffer layer to cope with a tiled
framebuffer might be necessary in the long run, any pointers
where to
start?
Several drivers (radeon, intel, savage) in the Xorg tree provide
support for various tiling methods. Generally the chip provides a
surface control or aperture for exposing a tiled region to the
CPU as
a linear surface. For acceleration, you have to keep track of
what
buffers are tiled in the driver and do the right thing with the
blitter when using those surfaces.
Yeah, I'm dimly aware of these things - my problem is that the
hardware in question doesn't give me a linear view on the
framebuffer.
All I have is a small linear buffer I can use to DMA data in or
out
of the tiled framebuffer. The other problem is that the machine's
native pixel format is RGBA, if I want 24bit colour that's the
only
one I can use. Fortunately the DMA engine can convert pixels on
the
fly so I can pretend it's ABGR. So pixels would have to be endian-
flipped as well when the fb layer accesses VRAM - is there any
prior
art for that?
EXA has prepare/finish access hooks for CPU access to buffers. I
don't think XAA has anything similar. There's also an wrapable FB
module, although I think it's only available in Xorg.
I'll have a look at that - the main reason I'm using XFree86 is that
it's already working on NetBSD/sgimips, Xorg needs some more work
but
I'll eventually do it.
Hmm, some drivers access video memory through tiny apertures like
the
VGA range - maybe I can do something like this - let the rest of the
Xserver render into my DMA buffer and then blit it in place.
Use shadowfb and hook in a custom shadowupdate() function.
Wouldn't that interfere with XAA? If I could catch the framebuffer
writes that bypass XAA that way that would solve my problem.
Thanks!
Yeah, you gotta pick one or the other IIRC. However for most modern
desktops you either have to be entirely SW or entirely HW or
performance sucks. You lose if any sort of fallbacks cause a pixmap
migration to/from vram.
Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: xaa vs. WriteImage()
On Thu, Mar 6, 2008 at 5:17 PM, Michael Lorenz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Mar 6, 2008, at 16:40, Alex Deucher wrote: On Thu, Mar 6, 2008 at 4:26 PM, Michael Lorenz [EMAIL PROTECTED] wrote: On Mar 6, 2008, at 15:58, Alex Deucher wrote: On Thu, Mar 6, 2008 at 2:58 PM, Michael Lorenz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Mar 6, 2008, at 14:12, Alex Deucher wrote: On Thu, Mar 6, 2008 at 2:00 PM, Michael Lorenz EXA has prepare/finish access hooks for CPU access to buffers. I don't think XAA has anything similar. There's also an wrapable FB module, although I think it's only available in Xorg. I'll have a look at that - the main reason I'm using XFree86 is that it's already working on NetBSD/sgimips, Xorg needs some more work but I'll eventually do it. Hmm, some drivers access video memory through tiny apertures like the VGA range - maybe I can do something like this - let the rest of the Xserver render into my DMA buffer and then blit it in place. Use shadowfb and hook in a custom shadowupdate() function. Wouldn't that interfere with XAA? If I could catch the framebuffer writes that bypass XAA that way that would solve my problem. Thanks! Yeah, you gotta pick one or the other IIRC. However for most modern desktops you either have to be entirely SW or entirely HW or performance sucks. You lose if any sort of fallbacks cause a pixmap migration to/from vram. In my case VRAM is RAM, and the CPU is pretty slow - I've had things running entirely SW and performance sucked. Not the slowest I've ever seen but nowhere near what the HW can do. Also, many X applications have trouble with the HW's native pixel format, cairo for instance just crashes. Using the DMA engine I can pretend it's using something more common - ABGR - and those applications just work fine. I think the next thing I'll try is to pretend that we're accessing VRAM through a small window, there must be prior art for that somewhere in the source tree. the sgi impact driver I mentioned before (http://cgit.freedesktop.org/xorg/driver/xf86-video-impact/) does that. IIRC, there's no way to access the vram directly so everything gets sent to the card via dma. Alex ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: patches for Darwin /MacOSX
On 4/11/07, SciFi [EMAIL PROTECTED] wrote: On Fri 06 Apr 2007 14:01:59 -0400, Alex Deucher wrote: On 4/6/07, SciFi [EMAIL PROTECTED] wrote: Yves' changes did not help getting stuck several times during the build here. I'll be documenting as best I can and send 'em thru bugzilla. I bet we'll be too late for Apple to put this into Leopard, I have no idea what they're doing since I can't afford a $pay-for$ ADC account there or get a 'sponsor'. :( Apple has people actively working on Xorg. Most of their recent changes have been already been pushed or are pending on branches. Alex Their present X11.app on Tiger shows XFree86, not Xorg. Did they switch again??? I definitely remember a lot of us sending feedback some years ago to have them switch *TO* XFree86, which they did. Good grief I'm gettin' dizzy... ;) Again? I think they only switched once. Tiger support was written a while ago. They have people working on Xorg support for the next release or an update I assume. You'd have to ask them what the plan is. Alex ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: siliconmotion CSync output ?
On 3/12/07, bruno schwander [EMAIL PROTECTED] wrote: I used your vclk setting code as in smi_driver.c, and changed the shift in SMI_CommonCalcClock() but it seems to still have some issue. 12220 clock gives me values of SR6C: 63, SR6D: 1D That's going to give you a vclk of ~48.88 Mhz Unfortunately, the min clock on the smi is 20 Mhz (although I'd think you should be able to get down to at least the reference clock), so that may be causing a problem in the calculation function. If you want to calculate the clock yourself you can use the following formula: VCLK = 14.31818 Mhz * (VNR/VDR) * (1/(1 + PS)) VNR being SR6C and VDR and SR6D. PS is bit 7 of SR6D. I hope this helps. Alex bruno On Sun, 11 Mar 2007, Alex Deucher wrote: On 3/10/07, bruno schwander [EMAIL PROTECTED] wrote: I looked at that diff and it looks like what I added, except that I also set bits 7:6 of CCR68 to 01 because the doc I have says that will select VCLK from the programmable VCLK regs, CCR6C and CCR6D. I fixed the vclk problem. The postscalar shift was wrong in SMI_CalcClocks(). either grab my updated tree or change the shift from 6 to 7. Alex ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: siliconmotion CSync output ?
On 3/13/07, bruno schwander [EMAIL PROTECTED] wrote: On Mon, 12 Mar 2007, Alex Deucher wrote: On 3/12/07, bruno schwander [EMAIL PROTECTED] wrote: I used your vclk setting code as in smi_driver.c, and changed the shift in SMI_CommonCalcClock() but it seems to still have some issue. 12220 clock gives me values of SR6C: 63, SR6D: 1D That's going to give you a vclk of ~48.88 Mhz yeah, I know. I meant that SMI_CommonCalcClock should have come up with different values, instead it returned the values above. Unfortunately, the min clock on the smi is 20 Mhz (although I'd think hmm that would be really annoying...where do you get that ? I can't find that's just what was specified in the driver originally. smi wrote it... any mention of such a limitation. Just the hope that given the right SR6C/D values, I can get any corresponding dot clock :-) try bumping the max n1 up. see my newest code below. I did chnge the minclock values so that it accepts lower clock requests, but I have not checked it it actually generates those frequencies. Need the scope... Good luck! let me know how it goes. you should be able to get down to at least the reference clock), so that may be causing a problem in the calculation function. If you want to calculate the clock yourself you can use the following formula: VCLK = 14.31818 Mhz * (VNR/VDR) * (1/(1 + PS)) VNR being SR6C and VDR and SR6D. PS is bit 7 of SR6D. the spec I have for the smi712 (lynxEM+) says bit 7 and 6 are PS, as follows: bit 6 bit 7 vclk 0 0 PS not enabled, programmed vclk 0 1 PS enabled, vclk = 1/2 programmed vclk 1 0 PS enabled, vclk = 1/4 prog vlck 1 1 PS enabled, vclk = 1/8 prog vlck Ah, I was reading the 722 book. I didn't realize the 712 had 2 bits for PS; you might have more luck in that case. I fixed up the driver to deal with this and set the proper min/max values for the calculation. http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-siliconmotion.git;a=summary Alex bruno ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: siliconmotion CSync output ?
On 3/10/07, bruno schwander [EMAIL PROTECTED] wrote: I looked at that diff and it looks like what I added, except that I also set bits 7:6 of CCR68 to 01 because the doc I have says that will select VCLK from the programmable VCLK regs, CCR6C and CCR6D. I fixed the vclk problem. The postscalar shift was wrong in SMI_CalcClocks(). either grab my updated tree or change the shift from 6 to 7. Alex ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: siliconmotion CSync output ?
On 3/10/07, bruno schwander [EMAIL PROTECTED] wrote: I looked at that diff and it looks like what I added, except that I also set bits 7:6 of CCR68 to 01 because the doc I have says that will select VCLK from the programmable VCLK regs, CCR6C and CCR6D. Right, I should probably do that explicitly, although IIRC, the bios does that during post. Alex I'll get git and give your tree a try, thanks bruno ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: siliconmotion CSync output ?
On 3/10/07, bruno schwander [EMAIL PROTECTED] wrote: in SMI_Save(), SR6C and SR6D (and SR68) are saved only if pSmi-Dualhead, why ? seems it should always be done ? It should. Like I said this is still my untested local working tree. I'm aiming to add xrandr 1.2 support as well. in SMI_WriteMode, those 2 are written twice, once everytime + once if pSmi-Dualhead see above :) What's your take about CCR68 (SR68), also written only in dualhead mode... seems if SR6C/SR6D are to be active, SR68 has to be configured too. yup. Alex bruno ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: siliconmotion CSync output ?
On 3/9/07, bruno schwander [EMAIL PROTECTED] wrote: I keep answering my own questions. I hopI am not spamming the mailing list too much, but it's nice to get some degree of confirmation from those who know before I dive into something. so I gather now that actually I should leave the xf86SetCrtcForModes() alone, and just add setting the clock with CCR6C, CCR6D (and enabling it with CCR68). I'll see how that goes... exactly. Sorry for not responding earlier. You can use the SMI_CalcClock() function to calculate SR6C and SR6D, just like the mclk is generated. Use mode-Clock. I have a similar patch in my xorg smi tree. Alex bruno On Thu, 8 Mar 2007, bruno schwander wrote: On Thu, 8 Mar 2007, Alex Deucher wrote: The siliconmotion driver doesn't explicitly set the vclk pll. It uses the bios (if UseBIOS is set or does nothing if not). that is what I was wondering... well, if I do not Options UseBIOS false all I get is a blank screen. So I have to disable it. I did not realize that it did not set the pixel clock since when using a default VGA 640x480 resolution, it was working. So I guess it just happens to stay at whatever pixel clock the BIOS or console driver had set it to ? That seems very strange. It's trivial to add however. SR6C, SR6D are programmed similarly to the mclk. I saw that mclk/dac stuff, yes, and was wondering how the pixel clock was really set. All this makes more sense now. So what you are saying is that in smi_driver.c : SMI_PreInit(), I should replace the call to xf86SetCrtcForModes(pScrn, 0), with an alternative that programs vclk explicitely ? How can it set the crtc for several modes ? That is what xf86SetCrtcForModes() seems to do, right ? I still have a lot to learn. thanks for all the help guys, trudging along... bruno Alex Bruno On Wed, 7 Mar 2007, bruno schwander wrote: ah actually now it is not choosing my modeline and I do not understand why: (II) Silicon Motionlg: Using hsync range of 14.00-80.00 kHz (II) Silicon Motionlg: Using vrefresh range of 56.00-76.00 Hz (II) Silicon MotionClock range: 14.00 to 135.00 MHz (II) Silicon MotionMode: 640x480 16-bpp, 59.990181Hz (II) Silicon MotionNot using mode 640x480i (vrefresh out of range) (II) Silicon MotionMode: 640x350 16-bpp, 85.079948Hz (II) Silicon MotionNot using default mode 640x350 (vrefresh out of range) vrefresh range is 56-76Hz, so why is my 640x480i modeline, at 59.99Hz vrefresh, rejected ? the modeline is as follows: ModeLine 640x480i 24.44 640 680 728 776 480 480 484 525 Interlace Composite bruno On Wed, 7 Mar 2007, bruno schwander wrote: I think I figured it out, however it seems that although my modeline includes 'composite' DisplayModePtr mode-Flags V_CSYNC does not evaluate to true. I assume as long as the 'composite' keyword is found on the modeline, the flag should be set, right ? I need to add some debug messages, but this seems a little strange. Is there something else that needs to be configured, like telling that the driver actually supports the composite keyword on the modeline ? On a different note, the latest X release does not seem to work on that chip. I just get a blank screen. So I started hacking on Xorg 6.8.2 to test this stuff. I figure XFree86 4.5 should work, but 4.6 does not. I'll provide patches to all and note on which version it was tested of course, once it works :-) bruno On Tue, 27 Feb 2007, Marc Aurele La France wrote: On Sun, 25 Feb 2007, bruno schwander wrote: On Fri, 23 Feb 2007, Marc Aurele La France wrote: On Thu, 22 Feb 2007, bruno schwander wrote: A little background: I have a single board PC with a SMI712 (lynxEM+) graphic chipset. X works like a charm. The driver currently ignores the V_CSYNC mode flag, so you would need to come up with a source patch to change that. I'd be happy to provide a patch, if I can figure where to put that. Since it is only a matter of setting one register it should be simple enough. I have (had?) no idea where to start, I'll grep for V_CSYNC and see... An appropriate spot for such changes would be after calls to vgaHWInit(), which, in this case, is in SMI_ModeInit(). Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply | | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals
Re: siliconmotion CSync output ?
On 3/9/07, bruno schwander [EMAIL PROTECTED] wrote: On Fri, 9 Mar 2007, Alex Deucher wrote: On 3/9/07, bruno schwander [EMAIL PROTECTED] wrote: so I gather now that actually I should leave the xf86SetCrtcForModes() alone, and just add setting the clock with CCR6C, CCR6D (and enabling it with CCR68). I'll see how that goes... exactly. Sorry for not responding earlier. You can use the SMI_CalcClock() function to calculate SR6C and SR6D, just like the mclk is generated. Use mode-Clock. I have a similar patch in my xorg smi tree. which xorg version are you up to, that has that patch ? did you mean it is not comitted yet ? I can't get the latest either xfree86 or xorg to work at all on that board I have with the smi712. I am testing currently with xorg 6.8.2 because that is the one that still works. I will test and fold in xfree86 4.5 but so far 4.6 does not work for me either. The latest version of the siliconmotion driver in xorg git head should have the lockup fix you need. The problem is the engine doesn't need to be synced until it has been started. I've also added dualhead support. I haven't yet pushed the pll fix, that's still in my local tree at home along with some other stuff I'm working on. I can send you a patch later if you want. Alex bruno Alex bruno On Thu, 8 Mar 2007, bruno schwander wrote: On Thu, 8 Mar 2007, Alex Deucher wrote: The siliconmotion driver doesn't explicitly set the vclk pll. It uses the bios (if UseBIOS is set or does nothing if not). that is what I was wondering... well, if I do not Options UseBIOS false all I get is a blank screen. So I have to disable it. I did not realize that it did not set the pixel clock since when using a default VGA 640x480 resolution, it was working. So I guess it just happens to stay at whatever pixel clock the BIOS or console driver had set it to ? That seems very strange. It's trivial to add however. SR6C, SR6D are programmed similarly to the mclk. I saw that mclk/dac stuff, yes, and was wondering how the pixel clock was really set. All this makes more sense now. So what you are saying is that in smi_driver.c : SMI_PreInit(), I should replace the call to xf86SetCrtcForModes(pScrn, 0), with an alternative that programs vclk explicitely ? How can it set the crtc for several modes ? That is what xf86SetCrtcForModes() seems to do, right ? I still have a lot to learn. thanks for all the help guys, trudging along... bruno Alex Bruno On Wed, 7 Mar 2007, bruno schwander wrote: ah actually now it is not choosing my modeline and I do not understand why: (II) Silicon Motionlg: Using hsync range of 14.00-80.00 kHz (II) Silicon Motionlg: Using vrefresh range of 56.00-76.00 Hz (II) Silicon MotionClock range: 14.00 to 135.00 MHz (II) Silicon MotionMode: 640x480 16-bpp, 59.990181Hz (II) Silicon MotionNot using mode 640x480i (vrefresh out of range) (II) Silicon MotionMode: 640x350 16-bpp, 85.079948Hz (II) Silicon MotionNot using default mode 640x350 (vrefresh out of range) vrefresh range is 56-76Hz, so why is my 640x480i modeline, at 59.99Hz vrefresh, rejected ? the modeline is as follows: ModeLine 640x480i 24.44 640 680 728 776 480 480 484 525 Interlace Composite bruno On Wed, 7 Mar 2007, bruno schwander wrote: I think I figured it out, however it seems that although my modeline includes 'composite' DisplayModePtr mode-Flags V_CSYNC does not evaluate to true. I assume as long as the 'composite' keyword is found on the modeline, the flag should be set, right ? I need to add some debug messages, but this seems a little strange. Is there something else that needs to be configured, like telling that the driver actually supports the composite keyword on the modeline ? On a different note, the latest X release does not seem to work on that chip. I just get a blank screen. So I started hacking on Xorg 6.8.2 to test this stuff. I figure XFree86 4.5 should work, but 4.6 does not. I'll provide patches to all and note on which version it was tested of course, once it works :-) bruno On Tue, 27 Feb 2007, Marc Aurele La France wrote: On Sun, 25 Feb 2007, bruno schwander wrote: On Fri, 23 Feb 2007, Marc Aurele La France wrote: On Thu, 22 Feb 2007, bruno schwander wrote: A little background: I have a single board PC with a SMI712 (lynxEM+) graphic chipset. X works like a charm. The driver currently ignores the V_CSYNC mode flag, so you would need to come up with a source patch to change that. I'd be happy to provide a patch, if I can figure where to put that. Since it is only a matter of setting one register it should be simple enough. I have (had?) no idea where to start, I'll grep for V_CSYNC and see... An appropriate spot
Re: siliconmotion CSync output ?
On 3/9/07, bruno schwander [EMAIL PROTECTED] wrote: On Fri, 9 Mar 2007, Alex Deucher wrote: The latest version of the siliconmotion driver in xorg git head should have the lockup fix you need. The problem is the engine doesn't need to be synced until it has been started. I've also added dualhead support. I haven't yet pushed the pll fix, that's still in my local tree at home along with some other stuff I'm working on. I can send you a patch later if you want. that would be awesome, yes ! so far what I added (enabling in CCR68 vclock scaled from CCR6C and CCR6D) crashes my pc... I used SMI_CommonCalcClock() but I get wrong values back for the register values. I am certainly not calling it right. I just put my local tree up here: http://gitweb.freedesktop.org/?p=users/agd5f/xf86-video-siliconmotion.git;a=summary The relevant commit is a328d4378c28b788acf320bee9fbdfd129e0923d I haven't tested any of this new code yet, so YMMV. I haven't had time this week and I need to rebuild my laptop with the smi chip, but I hope to do that this weekend, at which point I should be able to sort out any bugs. Let me know if you haven any questions. Alex bruno ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: siliconmotion CSync output ?
On 3/8/07, bruno schwander [EMAIL PROTECTED] wrote: ah never mind. since this is interlaced, the pixel clock needs to be half that to get the right frame refresh rate (60Hz) with a pixel clock of 12.22MHz, it passes. Now, I am not sure if the pixel clock is effectively set to that, and my lcd still does not sync, so either the pixel clock is not set right or the SMI712 is not outputting composite sync (despite my hack to enable it) Time to get the oscilloscope out... The siliconmotion driver doesn't explicitly set the vclk pll. It uses the bios (if UseBIOS is set or does nothing if not). It's trivial to add however. SR6C, SR6D are programmed similarly to the mclk. Alex Bruno On Wed, 7 Mar 2007, bruno schwander wrote: ah actually now it is not choosing my modeline and I do not understand why: (II) Silicon Motionlg: Using hsync range of 14.00-80.00 kHz (II) Silicon Motionlg: Using vrefresh range of 56.00-76.00 Hz (II) Silicon MotionClock range: 14.00 to 135.00 MHz (II) Silicon MotionMode: 640x480 16-bpp, 59.990181Hz (II) Silicon MotionNot using mode 640x480i (vrefresh out of range) (II) Silicon MotionMode: 640x350 16-bpp, 85.079948Hz (II) Silicon MotionNot using default mode 640x350 (vrefresh out of range) vrefresh range is 56-76Hz, so why is my 640x480i modeline, at 59.99Hz vrefresh, rejected ? the modeline is as follows: ModeLine 640x480i 24.44 640 680 728 776 480 480 484 525 Interlace Composite bruno On Wed, 7 Mar 2007, bruno schwander wrote: I think I figured it out, however it seems that although my modeline includes 'composite' DisplayModePtr mode-Flags V_CSYNC does not evaluate to true. I assume as long as the 'composite' keyword is found on the modeline, the flag should be set, right ? I need to add some debug messages, but this seems a little strange. Is there something else that needs to be configured, like telling that the driver actually supports the composite keyword on the modeline ? On a different note, the latest X release does not seem to work on that chip. I just get a blank screen. So I started hacking on Xorg 6.8.2 to test this stuff. I figure XFree86 4.5 should work, but 4.6 does not. I'll provide patches to all and note on which version it was tested of course, once it works :-) bruno On Tue, 27 Feb 2007, Marc Aurele La France wrote: On Sun, 25 Feb 2007, bruno schwander wrote: On Fri, 23 Feb 2007, Marc Aurele La France wrote: On Thu, 22 Feb 2007, bruno schwander wrote: A little background: I have a single board PC with a SMI712 (lynxEM+) graphic chipset. X works like a charm. The driver currently ignores the V_CSYNC mode flag, so you would need to come up with a source patch to change that. I'd be happy to provide a patch, if I can figure where to put that. Since it is only a matter of setting one register it should be simple enough. I have (had?) no idea where to start, I'll grep for V_CSYNC and see... An appropriate spot for such changes would be after calls to vgaHWInit(), which, in this case, is in SMI_ModeInit(). Marc. +--+--+ | Marc Aurele La France | work: 1-780-492-9310 | | Academic Information and| fax:1-780-492-1729 | |Communications Technologies | email: [EMAIL PROTECTED] | | 352 General Services Building +--+ | University of Alberta | | | Edmonton, Alberta |Standard disclaimers apply| | T6G 2H1 | | | CANADA | | +--+--+ XFree86 developer and VP. ATI driver and X server internals. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: x86emu emulation problem
On 10/5/06, jf simon [EMAIL PROTECTED] wrote: Hi, I am trying to use the x86emu code to emulate a PCI ATI Radeon VGA bios on a powerpc platform (IBM 970 Maple). The emulation starts OK, but after some time I can see that it is making a call to a location that is outside of the VGA bios. Which causes x86emu to emulate whatever rabbish it finds here. At first I thought that maybe x86emu was emulating the wrong code (maybe got misaligned in the opcodes). But using the ndisasm x86 disassembler on the original VGA bios showed that x86emu was emulating the code correctly. I have also compared PCI traces (collected with a H/W analyser) ran on the powerpc system and on a AMD64 system (which runs the VGA BIOS OK) and I can see that x86emu on the powerpc is making the right PCI accesses to the ATI before it crashes. Which makes me thing the x86emu is working OK, at least at the beginning. The problem is on the call 0xe903 instruction. There is no code there (code is from c: to c:0d000 ). Plus there are those strange opcodes ENTER 8000,15, which are causing the SP to go from SP=DFD0, to SP=5fa4 (righ in the code!). I have read that the ENTER opcode was designed to make for high level language procedures, and their required stack frame needs. But 0x8000 seems like a lot! I am really at a loss so as what to do next... FWIW, many video card bioses mess with PCI registers and the like. Alex Thaks for any help, -jf simon 1- the x86emu trace just before the problem: cat trace.cpu c000:68dd a00080 MOV AL,[8000] AX= BX=01e3 CX=4100 DX=f004 SP=dfd0 BP=0197 SI= DI= DS= ES=c000 SS=c000 CS=c000 IP=68e2 NV UP DI PL ZR NA PE NC c000:68e0 04f5ADD AL,f5 [BP+SI]AL AX=00f5 BX=01e3 CX=4100 DX=f004 SP=dfd0 BP=0197 SI= D I= DS= ES=c000 SS=c000 CS=c000 IP=68e4 NV UP DI NG NZ NA PE NC c000:68e2 0002ADD , AX=00f5 BX=01e3 CX=4100 DX=f004 SP=dfd0 BP=0197 SI= DI= DS= ES=c000 SS=c000 CS=c000 IP=68e8 NV UP DI NG NZ AC PO CY c000:68e4 c8008015ENTER 8000 ,15 AX=00f5 BX=01e3 CX=4100 DX=f004 SP=5fa4 BP=dfce SI= DI= DS= ES=c000 SS=c000 CS=c000 IP=68e9 NV UP DI NG NZ AC PO CY c000:68e8 0e PUSH CS [00c8]AXAX=00f5 BX=01e3 CX=4100 DX=f004 SP=5fa2 BP=dfce SI= D I= DS= ES=c000 SS=c000 CS=c000 IP=68ed NV UP DI NG NZ AC PO CY c000:68e9 0106c800ADD , [BX+SI] AX=00f5 BX=01e3 CX=4100 DX=f004 SP=5fa2 BP=dfce SI= DI= DS= ES=c000 SS=c000 CS=c000 IP=68f0 NV UP DI PL NZ NA PE NC c000:68ed 80100e ADC BYTE PTR ,e [DI]AX AX=00f5 BX=01e3 CX=4100 DX=f004 SP=5fa2 BP=dfce SI= DI= DS= ES=c000 SS=c000 CS=c000 IP=68f2 NV UP DI PL NZ NA PO NC c000:68f0 0105ADD , AX=00f5 BX=01e3 CX=4100 DX=f004 SP=5fa2 BP=dfce SI= DI= DS= ES=c000 SS=c000 CS=c000 IP=68f6 NV UP DI PL NZ NA PE NC c000:68f2 c800800bENTER 8000 ,b AX=00f5 BX=01e3 CX=4100 DX=f004 SP=df8a BP=5fa0 SI= DI= DS= ES=c000 SS=c000 CS=c000 IP=68f7 NV UP DI PL NZ NA PE NC c000:68f6 0e PUSH CS [SI]AX AX=00f5 BX=01e3 CX=4100 DX=f004 SP=df88 BP=5fa0 SI= DI= DS= ES=c000 SS=c000 CS=c000 IP=68f9 NV UP DI PL NZ NA PE NC c000:68f7 0104ADD , AX=00f5 BX=01e3 CX=4100 DX=f004 SP=df88 BP=5fa0 SI= DI= DS= ES=c000 SS=c000 CS=c000 IP=68fd NV UP DI PL NZ NA PO NC c000:68f9 c8008006ENTER 8000 AX=00f5 BX=01e3 CX=4100 DX=f004 SP=5f7a BP=df86 SI= DI= DS= ES=c000 SS=c000 CS=c000 IP=68fe NV UP DI PL NZ NA PO NC c000:68fd 0e PUSH CS [BP+SI]AX AX=00f5 BX=01e3 CX=4100 DX=f004 SP=5f78 BP=df86 SI= D I= DS= ES=c000 SS=c000 CS=c000 IP=6900 NV UP DI PL NZ NA PO NC c000:68fe 0102ADD , AX=00f5 BX=01e3 CX=4100 DX=f004 SP=5f78 BP=df86 SI= DI= DS= ES=c000 SS=c000 CS=c000 IP=6903 NV UP DI PL NZ NA PE NC c000:6900 e80080 CALL e903 !!PROBLEM HERE!! [BX+SI]AL AX=00f5 BX=01e3 CX=4100 DX=f004 SP=5f76 BP=df86 SI= D I= DS= ES=c000 SS=c000 CS=c000 IP=e905 NV UP DI PL NZ NA PE NC c000:e903 ADD , [BX+SI]AL (x86emu starts emulating bad codes (all zeroes) AX=00f5 BX=01e3 CX=4100 DX=f004 SP=5f76 BP=df86 SI= D I= DS= ES=c000 SS=c000 CS=c000 IP=e907 NV UP DI PL NZ AC PE CY c000:e905 ADD , 2- The same code as seen from ndisasm: 68DA A00080mov al,[0x8000] 68DD
Re: i945G 1280x768 sync polarity bug
On 6/14/06, Barry Scott [EMAIL PROTECTED] wrote: Alex Deucher wrote: The i810 driver is limited to the modes the bios knows how to set. If the bios doesn't have the specific mode you are lookign for, then you are out of luck. There is native modesetting support in the xorg intel driver git tree if you want native modesetting. Do you know if this code made it into a released version of Xorg yet? I'll try and build the Xorg code against XFree86 and see what happens. Nope. It's still in the modesetting branch of the intel driver git tree: http://gitweb.freedesktop.org/?p=xorg-driver-xf86-video-intel;a=summary Alex Barry ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: i945G 1280x768 sync polarity bug
On 6/13/06, Barry Scott [EMAIL PROTECTED] wrote: Tim Roberts wrote: Barry Scott wrote: Using the Xfree86 4.6.0 i810 driver I'm seeing a problem with sync polarity setting. This modeline is required for 1280x768 mode: Modeline 1280x768 79.30 1280 1335 1473 1665 768 769 772 793 -hsync +vsync But the syncs, as shown on an oscilloscope are +hsync +vsync. Does this matter any more? I thought the relevance of sync polarity ended in the middle of the Clinton administration. Good question. We note that the EDID data wants these sync polarities. Does the monitor use the pulse widths or the polarity to tell one mode from another? We think that the polarity is used, but we are far from certain. Looking at the VBE code it seems that as long as the Flags are defined correctly by the driver then its down to the INT10 BIOS to set the syncs on the hardware. Do you think this is a BIOS bug or a driver bug? It may be an expectations bug. As you note, the Intel driver, like the Savage driver, relies on the BIOS to set the mode. The BIOS has a limited set of video modes, with canned parameters for each timing. It is not infinitely variable. If the BIOS thinks 1280x768 should have positive syncs, then you are going to get positive syncs I'm using 915resolution to add 1280x768 and 1360x768 into the BIOS. It seems that if there is an entry in the BIOS for 1280x768 then the driver is happy to to call INT10 to pass in the timings and sync polarity data. If as you say the BIOS timings are the only ones used then what is the point of the INT10 call to pass in the timings? I'm not familiar with the i810's bios interface, but no other chip I've ever worked on has allowed me to specify exact timings via the BIOS. It's usually either a VESA mode number or a size and a refresh rate. I doubt the i810 is much different, especially since most i810 bioses don't even support modes like 1280x768 out of the box. Alex Barry ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: SM501 driver support in XFree86
On 2/6/06, Kaliraj Kalaichelvan - CTD, Chennai [EMAIL PROTECTED] wrote: I am using XFree86 Version 4.3.0. I understand from driver folder (\xc\programs\Xserver\hw\xfree86\drivers\siliconmotion)that silicon motion driver supports for SM720, SM910, SM810, SM820, SM710, SM712. Does this same silicon motion driver in xfree86 4.3.0 work fine for SM501? If not where shall i get the SM501 driver for Xfree86 4.3.0.? Silicon motion added 501 support in xfree86 bugzilla, however, the code was never integrated. you can still grab the tarball there. I don't recall the bugzilla number off hand. Alex Kali DISCLAIMER This message and any attachment(s) contained here are information that is confidential, proprietary to HCL Technologies and its customers. Contents may be privileged or otherwise protected by law. The information is solely intended for the individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: SM501 driver support in XFree86
On 2/7/06, Kaliraj Kalaichelvan - CTD, Chennai [EMAIL PROTECTED] wrote: Hello Alex, Thank you for the directive. I have downloaded the tarball. I have a concern - the tarball is for Linux x86 platform. I believe that it supports PCI/AGP SM501. Provide your views if i need to port that for a non-x86 platform with memory mapped SM501. I currently have a SH4 processor with SM501 memory mapped. there are endian issues, IIRC, see the patches and discussion here: https://bugs.freedesktop.org/show_bug.cgi?id=312 Alex - Kaliraj Kalaichelvan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alex Deucher Sent: Wednesday, February 08, 2006 2:55 AM To: devel@xfree86.org Subject: Re: SM501 driver support in XFree86 On 2/6/06, Kaliraj Kalaichelvan - CTD, Chennai [EMAIL PROTECTED] wrote: I am using XFree86 Version 4.3.0. I understand from driver folder (\xc\programs\Xserver\hw\xfree86\drivers\siliconmotion)that silicon motion driver supports for SM720, SM910, SM810, SM820, SM710, SM712. Does this same silicon motion driver in xfree86 4.3.0 work fine for SM501? If not where shall i get the SM501 driver for Xfree86 4.3.0.? Silicon motion added 501 support in xfree86 bugzilla, however, the code was never integrated. you can still grab the tarball there. I don't recall the bugzilla number off hand. Alex Kali DISCLAIMER This message and any attachment(s) contained here are information that is confidential, proprietary to HCL Technologies and its customers. Contents may be privileged or otherwise protected by law. The information is solely intended for the individual or the entity it is addressed to. If you are not the intended recipient of this message, you are not authorized to read, forward, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: portrait mode how to
If you have a monitor that is natively portrait or will support a portrait mode, then you can just define a 768x1024 modeline and assuming the driver doesn't rely on the bios (since I doubt any bios will have a mode like that defined) it will set the mode. However, if the monitor you are trying to use is natively landscape and only supports landscape modes, then you will need to use rotation. None of the Xorg servers support xrandr rotation in 6.8.x, however, several of the drivers have a driver specific rotate option that will provide non-accelerated rotation. Alex On 11/28/05, krish ritik [EMAIL PROTECTED] wrote: Hi, I am working on X11R6.8.2. Just trying to explore if there is any posibility to put screen in portrait mode. I know about Nvidia driver. but i want to try it by myself. any hints how to put screen in 786x1024 mode (take the example of Intel card). I don;t need icon rotation and all. but just want to set the mode as 768x1024. regards, Puneet ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: I810 driver and XVIDEO for HD movies fails
On 11/28/05, Barry Scott [EMAIL PROTECTED] wrote: I'm seeing this error when I attempt to play a HD 720p (1280x720) movie in Xine: X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 143 (XVideo) Minor opcode of failed request: 19 () Serial number of failed request: 609 Current serial number in output stream: 610 I'm using Xfree86 4.5.0 on a Commel LV-670 board. lspci -v reports: 00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03) (prog-if 00 [VGA]) Subsystem: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device Flags: bus master, fast devsel, latency 0, IRQ 5 Memory at d000 (32-bit, prefetchable) [size=128M] Memory at dc20 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 1 00:02.0 Class 0300: 8086:2562 (rev 03) Subsystem: 8086:2562 ... I've added a VideoRAM 65536 to the device section but that not changed things. I'm also trying to track down where in the code the BadAlloc is being return with little success so far. I thought I had found that I should be in I810PutImage() in i810_video.c but the xf86DrvMsg call I make does not appear in the log of the servers stdout. What is the reason that the BadAlloc is being returned? What can I do about it? What more info can I provide? try disabling the DRI. The 3d driver may be grabbing most of the vram and not leaving much for the server. Alex Barry ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Xv overlays cause blue flashing
On 11/16/05, Smoof . [EMAIL PROTECTED] wrote: Hello, I am writing an application that will display up to 9 independent video streams (each stream is 320 x 240). I'm new to Xv and may not be using the correct terminology so please bear with me. I have tried two approaches: The first approach was to create one large overlay using XvShmCreateImage and tile in the video frames. Once all frames are tiled in, use XvShmPutImage to send them to the X server. This method works perfectly. However, my ultimate goal is to send each video stream to it's own GTK widget so I can have each video stream playing in a window that can be moved, be surrounded by buttons, minimized, etc... I implemented this by creating a simple GTK app with three drawing areas (ultimately I will have 9) of 320x240 and used some GDK functions to determine the X window id's for the widgets. I created a separate overlay (again using XvShmCreateImage) for each window. Then I call XvShmPutImage once for each window. Finally I call XFlush so send the requests to the X server. I tried using XSync but it seemed to interfere with the GTK event loop. The problem with this second approach is that the overlays are flashing blue (the overlay color key from what I've read). So I looking for advice on how to update multiple overlays at a rate of 24fps without any flashing. Or if you don't think this is possible then please let me know and I'll just have to get by with my first implementation. Most hardware only has one overlay so each widget will be fighting for it. only the one that has it at any given moment will actually display the video; the rest will show the colorkey. Alex Thanks for your help ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Multiple Xv overlays cause blue flashing
On 11/16/05, Smoof . [EMAIL PROTECTED] wrote: Smoof . wrote: My plan was to do all the rendering with the same client and I know that my overlay adaptor only has a single port for the YUV420 format that I am using. Can someone say if the following would be possible: Suppose I create a single overlay that is the size of the entire screen. Then I could track the absolute position and visibility of the individual widget windows I want to send the video streams to. I would then tile in the images into the correct spot in the overlay to match the window position. Now, if there were some way of using the alpha channel to only cause the certain portions of the overlay to be seen then that might do the trick. Or could I just manually fill the areas I want to expose with the color key? Please keep in mind that I really don't know what I'm talking about and have no idea if this is possible but it sounds like the only way to prevent the flashing is to use a single overlay and somehow figure out how to share it among the widget windows. Does your graphics card support OpenGL? One practical alternative is to render the movies into textures. Yes, I ran the SDL GL test program (testgl) and here is the output Screen BPP: 32 Vendor : Mesa project: www.mesa3d.org Renderer : Mesa GLX Indirect Version: 1.3 Mesa 4.0.4 Extensions : GL_ARB_imaging GL_ARB_multitexture GL_ARB_texture_border_clamp GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_transpose_matrix GL_EXT_abgr GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_lod_bias this is software OpenGL. I don't know anything about openGL or textures but I'll start doing some research. I should have mentioned earlier that for this project I can specify any video card I want. So if someone has a suggestion of what would be the best video card for this type of application please let me know. Thanks for the help. many graphics cards even support YUV textures. mesa has an extension to expose that functionality (MESA_ycbcr_texture, IIRC) Alex ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Xorg and Cue Problems
On 10/19/05, Rick Knight [EMAIL PROTECTED] wrote: I've done some more testing and the problem seems to actually be with KDE. If I start Xorg in failsafe mode and scan in the Xterm window, I can see the Cuecat's output. Also, if I open an xterm in KDE, not a KDE term, I can still scan. It seems that KDE is grabbing the CueCat's input, but I can't find anything in the KDE control center, so I guess I'll try a KDE group. KDE must be intercepting the Alt-F10 or whatever the cuecat sends first. Alex Thanks, Rick Knight ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Sun Creator and XRender
On 10/16/05, Michael [EMAIL PROTECTED] wrote: Hello, since the sunffb driver doesn't support the XRender extension but the graphics processor supports alpha blending and a few other nice tricks I've been poking around a bit to add this sort of functionality. The problem seems to be that sunffb doesn't use xaa or the standard framebuffer manager. so I couldn't get the included render code to work. So my questions are: - is there a text somewhere describing how to add xrender functionality to a driver without using fbPictureInit() ? - is there some more comprehensive ffb documentation available somewhere? I think I know how alpha blending and so on is supposed to work ( from reading the mesa driver source ) but there are still a few more questions. This has already been done in X.Org's repository and it is on my to-do-soon list to merge in. Nice :) So I'll stop reinventing the wheel, wait until you're done and then import the result into NetBSD. I wonder if they fixed DRI support too. DRI should work with xorg and mesa from cvs. Alex have fun Michael ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: [forum] Announce: xf86lite project: xplit xf86 into small pieces
On 6/1/05, Enrico Weigelt [EMAIL PROTECTED] wrote: * Stuart Anderson [EMAIL PROTECTED] wrote: Hi, I just wanted to make sure you were aware of the similar work that has been underway for several months. Details can be found at http://xorg.freedesktop.org/wiki/ModularizationWorkingGroup Sounds interesting. But is there anything actually available ? I dont really have the time for long discussions, but need some parts (ie xlib) quite now. So I have to do it *now*. yes, It's HEAVILY in progress now. http://wiki.x.org/wiki/ModularDevelopersGuide http://wiki.x.org/wiki/ModularizationDevelPlan http://www.freedesktop.org/Software/xlibs Alex cu -- - Enrico Weigelt== metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] - Realtime Forex/Stock Exchange trading powered by postgresSQL :)) http://www.fxignal.net/ - ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Fatal Error --? Video driver?
On 5/4/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Tue, May 03, 2005 at 05:18:28PM -0700, Tim Roberts wrote: [EMAIL PROTECTED] wrote: devel@XFree86.Org Hi I am trying to get XFree running on this configuration butno success so far. It looks likevsomething to do with the on board video The motherboard is ABIT VA-20 (www.abit.com) Integrated on board Unichrome Pro Graphics with 2D/3D/video controller 64 Meg of DDR ram allocated for video Total ram 1G The VIA Unichrome chip does not have a driver built-in to XFree86. VIA distributes one, but I don't know whether it plays with XFree86 4.5.0. Google for xfree86 unichrome for lots of hints. You should be able to run the vesafb driver. You won't get acceleration, but it should work. -- Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/drivers/via/ The files in there have xf-4_5 tags... And what's there should be capable of running an X natively on a standard KM400 board. Luc Verhaegen. Thanks Luc -- but forgive me - my board is a VA-20 -- do you happen to know: (a) which one of the files I need AND (b) what do I have to do to get X11R6 to use it? you need to use the via driver that's available in xfree86. Alex Thanks again David NOTE Remove from my Reply-to - all before [vizion at ixpres.com] if emailing me David Southwell Ham call sign M0TAU 40 yrs navigating and computing in blue waters. English Owner Captain of British Registered 60' bluewater Ketch S/V Taurus. Currently in San Diego, CA. sailing May bound for Europe via Panama Canal. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: External CRT works on 1024x768 but LCD not. Please Help!!!
On Fri, 18 Feb 2005 09:12:01 -0800, Bukie Mabayoje [EMAIL PROTECTED] wrote: Read my comments in blue. And I am still looking into this. Nqnsome wrote: Hi, Can someone help me, please!? I have a Compal CY27 laptop. The graphics chipset is (as reported by lspci): :00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) :00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics Device (rev 02) The 82852GM supports two independent display. You have one at 00:02:.0 and the other at 00:02.1. You are configured to use BusID PCI:0:2:0. I am not sure which video port 0:2:0 drivers. One thing you can try is change BusID to PCI:0:2:1. it should use 02.0. .1 is just a placeholder for the windows drivers AFAIK. Alex ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: External CRT works on 1024x768 but LCD not. Please Help!!!
On Fri, 18 Feb 2005 17:03:33 -0300, SLCB [EMAIL PROTECTED] wrote: Hi, Thanks a lot for replying, really! The 82852GM supports two independent display. You have one at 00:02:.0 and the other at 00:02.1. You are configured to use BusID PCI:0:2:0. I am not sure which video port 0:2:0 drivers. One thing you can try is change BusID to PCI:0:2:1.I suspect the reason it works is that your system have two graphics controller. And one of it is the 350Mhz 24-bit RAMDAC that support a regular scan analog monitor. Are these BusIDs related to the display pipes reported in the Xfree log: ... (II) I810(0): Display Info: CRT: attached: TRUE, present: TRUE, size: (800,600) (II) I810(0): Display Info: TV: attached: FALSE, present: TRUE, size: (800,600) (II) I810(0): Display Info: DFP (digital flat panel): attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Display Info: LFP (local flat panel): attached: TRUE, present: TRUE, size: (1024,768) (II) I810(0): Display Info: TV2 (second TV): attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Display Info: DFP2 (second digital flat panel): attached: FALSE, present: FALSE, size: (0,0) (II) I810(0): Currently active displays on Pipe A: (II) I810(0): CRT (II) I810(0): No active displays on Pipe B. ... I mean: Display Pipe A = BusID PCI:0:2:0 Display Pipe B = BusID PCI:0:2:1 or vice-versa? no. the second one is just a placeholder for the windows drivers so you get: Intel 82852GM Display controller Intel 82852GM Display controller (secondary) in the windows device manager. you'll want to use the primary id for both heads. Alex ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: External CRT works on 1024x768 but LCD not. Please Help!!!
On Fri, 18 Feb 2005 17:13:17 -0300, SLCB [EMAIL PROTECTED] wrote: Hi, Sorry, I forgot to comment one answer. Bukie Mabayoje wrote: I suspect the reason it works is that your system have two graphics controller. And one of it is the 350Mhz 24-bit RAMDAC that support a regular scan analog monitor. You mean the two BusIds/Pipes or really another card? If I had another card, I guess it would be reported by lspci, wouldn´t ? Sorry again, but I could not find any reference in the log to any 350Mhz 24-bit RAMDAC card. Am I missing something? your chip has two display controllers and two outputs, a DAC for analog out and a LCD controller for the laptop panel. it's all handled by one chip. Alex Thanks again. Regards, Sergio ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: External CRT works on 1024x768 but LCD not. Please Help!!!
On Fri, 18 Feb 2005 18:15:16 -0300, Nqnsome [EMAIL PROTECTED] wrote: Hi, Thanks again. Alex Deucher wrote: Alex is correct. Let focus on the primary display controller on PCI:0:2:0 with Display Pipe A and Display Pipe B. In your case you can only have PipeA=CRT and PipeB=LCD (LFP). That is why you have the following information (II) I810(0): Display Info: CRT: attached: TRUE, present: TRUE, size: (800,600) (II) I810(0): Display Info: LFP (local flat panel): attached: TRUE, present: TRUE, size: (1024,768) The problem is why XFree is saying there is no active display on Pipe B (II) I810(0): No active displays on Pipe B you can use the monitorlayout option to force on the pipes. see the i810 man page. Alex Now I understand the Pipes, but is still a mistery for me why lspci sees the 0:2:1, if it is a Windows placeholder (propably because I do not understand what a placeholder is...). when the windows driver claims the pci resources, it gives them each a name and they show up in the windows device manager. the second subfunction is just there so they can have two video devices show up in the device manager. Regarding the No active displays on Pipe B, this probably happens because, before starting X, I disable the LCD with the keyboard sequence FN+F5. If I do not do this, the screen becomes unreadble (I guess because the CRT works in 1024x768 and the LCD do not). that's the problem. the i810 driver relies on the bios to deal with outputs and modes. if tyou use the bios to disable an ouput, the driver probably has problems detecting an attached device. Thanks a lot for the explanations, but I would like to return to the question why the CRT works under 1024x768 and the LCD not. Can this be related to the VESA VBE DCC that does not work on the LCD? are you trying to get dualhead running or clone or just the LCD? Alex Thanks again. Regards, Sergio ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRI Support for ATI Radeon 9550
On Wed, 19 Jan 2005 16:32:44 +0100, Grand Apeiron [EMAIL PROTECTED] wrote: Hi, i've just noted that the XFree86 radeon driver does not support DRI (at least not for 9500/9700 series and i have a 9550). I've also tried the ATI proprietary driver but giving up after it didn't work right away and noting that it doesn't support DRI on Xinerama setups. I am using XFree86 4.3.0 with Xinerama using the radeon card and an old matrox millenium 2. So my current point is that there is no solution for me to get DRI support (or is there any solution?), and i want to ask if there is currently any planning regarding the implementation of DRI for that cards? Do you need any help regarding this? Thank you and greetings from germany, Grand Apeiron there is experimental r300/r400 support going on here: http://r300.sf.net Note, at the moment there is no support with any X server for DRI with xinerama. Alex ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRI Support for ATI Radeon 9550
On Wed, 19 Jan 2005 17:33:41 +0100, Grand Apeiron [EMAIL PROTECTED] wrote: On Wed, 2005-01-19 at 10:58 -0500, Alex Deucher wrote: there is experimental r300/r400 support going on here: http://r300.sf.net Note, at the moment there is no support with any X server for DRI with xinerama. Alex Thank you very much for your answer. Does that mean you can't have DRI at all or you can have DRI only on the first screen but not on the second? not DRI at all with xinerama at the moment. dualheaded radeon and sis chips support a special option called mergedfb which gives you dualhead with DRI. mutli-card 3d is not yet supported. Alex ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: Documentation about drivers
On Fri, 19 Nov 2004 19:05:13 +0100, Måns Rullgård [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: [EMAIL PROTECTED] writes: Hi, Where I can find the documentation about developing video driver for XFree?? I'll need to develop one to a new card we working on. Where can I find some info about it? xc/programs/Xserver/hw/xfree86/doc/DESIGN contains some useful information. Looking at the source code of existing drivers can also be helpful. Is there anyway to compile drivers without compile whole XFree? It should be possible. You just need to make sure the required header files are found. You'll need the XF86 sources, but there is no need to compile the whole lot. you can probably just run make Makefile make Makefiles make include make depend at the xc level and then just run 'make' in the directories of the drivers you want to build. Alex -- Måns Rullgård [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Maven on G550 - was Re: Matrox G550 true dual-dvi problem
On Thu, 23 Sep 2004 18:12:31 +0100 (BST), Andrew C Aitchison [EMAIL PROTECTED] wrote: On Thu, 23 Sep 2004, Klaus Dittrich wrote: I put all noDDC options in the server flags and in both monitor options as well. But nothing helped, the hangs still happen. According to the log file (excerpt appended) the module DDC is loaded and I2C bus DDC P1 is initialized _before_ the options get recognized. I'm seeing this on my G550-DVI-VGA now. DDC P1 is part of Ryan Underwood's G400 Maven changes for the DDC support on the second head, but I'm discovering that this doesn't appear to work on G550s. Does anyone know whether the G550 has a Maven chip ? no. it doesn't. The second dac was integrated on the g540 and later models, If so we need to try to get it to work; if not we should disable this on the G550. If I understand correctly, Ryan's change is intended to allow full feature support for the Dual head G400 (and G450 ?) *without* using Matrox's HAL. It's a start it that direction. all it does right now is fix DDC and DPMS on the second of G400s. The code to actually set up the mode on the maven is still missing. I still can't get dual head on G550 to work without HAL, so DDC support is moot. It should work without HAL. I had it working on my G550 (dvi + vga) a while back. Alex So if the hang occurs during this initialisation there is nothing to expect from the change. Is there an extended logging/debuging possible to find out what really happens? The logs using DDC, after the hang, always looked fine. None of the problems you described exhibited in the log files with both g550 variants. -- Klaus .. (II) LoadModule: mga_hal (II) Loading /usr/local/X11R6/lib/modules/drivers/mga_hal_drv.o (II) Module mga_hal: vendor=The XFree86 Project compiled for 4.3.0, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (==) MGA(0): Matrox HAL module used (**) MGA(0): Depth 24, (--) framebuffer bpp 32 (==) MGA(0): RGB weight 888 (**) MGA(0): Option HWcursor Off (**) MGA(0): Option PciRetry On (**) MGA(0): Option Crtc2Half On (**) MGA(0): Option AGPMode 4 (**) MGA(0): Option DigitalScreen1 Yes (**) MGA(0): Using AGP 4x mode (**) MGA(0): PCI retry enabled (--) MGA(0): Linear framebuffer at 0xFC00 (--) MGA(0): MMIO registers at 0xF010 (--) MGA(0): Pseudo-DMA transfer window at 0xF080 (==) MGA(0): BIOS at 0xC (--) MGA(0): Video BIOS info block at offset 0x07CE0 (WW) MGA(0): Video BIOS info block not detected! (II) MGA(0): MGABios.RamdacType = 0x0 (==) MGA(0): Write-combining range (0xfc00,0x200) (**) MGA(0): Crtc2 will use 16384K of VideoRam (--) MGA(0): VideoRAM: 16384 kByte (II) Loading sub module ddc (II) LoadModule: ddc (II) Loading /usr/X11R6/lib/modules/libddc.a (II) Module ddc: vendor=The XFree86 Project compiled for 4.4.99.13, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.7 (II) Loading sub module i2c (II) LoadModule: i2c (II) Loading /usr/X11R6/lib/modules/libi2c.a (II) Module i2c: vendor=The XFree86 Project compiled for 4.4.99.13, module version = 1.2.0 ABI class: XFree86 Video Driver, version 0.7 (==) MGA(0): Write-combining range (0xfc00,0x100) (II) MGA(0): vgaHWGetIOBase: hwp-IOBase is 0x03d0, hwp-PIOOffset is 0x (II) MGA(0): I2C bus DDC P1 initialized. (**) MGA(0): Option NoDDC1 (**) MGA(0): Option NoDDC (II) MGA(0): I2C Monitor info: (nil) (II) MGA(0): end of I2C Monitor info (II) MGA(0): DDC Monitor info: (nil) (II) MGA(0): end of DDC Monitor info (II) Loading sub module vbe (II) LoadModule: vbe .. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Maven on G550 - was Re: Matrox G550 true dual-dvi problem
On Thu, 23 Sep 2004 12:45:17 -0500 (CDT), Huver [EMAIL PROTECTED] wrote: Alex Deucher [EMAIL PROTECTED] writes: On Thu, 23 Sep 2004 18:12:31 +0100 (BST), Andrew C Aitchison [EMAIL PROTECTED] wrote: I still can't get dual head on G550 to work without HAL, so DDC support is moot. It should work without HAL. I had it working on my G550 (dvi + vga) a while back. How? Please tell. I'm running 4.4.0 (locally built) on a FreeBSD 4.10, G550 w/o HAL causes my monitor (DVI only) to say No INPUT and goes to sleep. I don't remember. it was probably a year or two ago at this point. I don't have the card anymore. Alex With HAL, I get the longer than 1 minute start up 9 out of 10 times after startx. The HAL was built from using Matrox's HALLib in their linux driver kit for 4.3.0. On FreeBSD, the longer-than-1-minute start-up on DVI happens with and without linux emulation loaded. -huver [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[ALPHA] Duoview support for mobile savages
At long last I've gotten duoview (dualhead) working with my savage IX! It should also work on MX and Supersavage chips, but I don't have the hardware to test. My current code is a bit of a hack, basically just 2 viewports into a big framebuffer. There are no safeguards in the code at the moment. USE AT YOUR OWN RISK! As I'm not (yet) able to change the framebuffer offset on crtc2, only left of, above, and clone orientations are supported right now. Configuration notes and support information as well as a patch and binary are available here: http://www.botchco.com/alex/new-savage/html/ Full-fledged regular multi-head and MergedFB support as well as bug fixes and new features will be added as I have time. I want to thank Tim and Austin for their help on this. I could not have done it with out them. Enjoy, Alex ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xv, radeon, alpha blending
On Wed, 23 Jun 2004 07:25:24 +0200, Stefan Lucke [EMAIL PROTECTED] wrote: On Mittwoch, 23. Juni 2004 05:32, Alex Deucher wrote: On Sat, 19 Jun 2004 10:40:49 +0200, Stefan Lucke [EMAIL PROTECTED] wrote: Hi, based upon Michael Deucher's radeon_xvalpha.diff found at It's actually Alex Deucher. Sorry for that. No problem. [ .. ] The only drawback is that any other screen region (without alpha values) is black. The reason I didn't implement per-pixel alpha blending initially was that it requires a framebuffer format with alpha values like or , etc. Without that, it's not much use. Yes, but that most parts of screen went black is more important. So I see video via Xv and a nice alpha blended OSD. I think the reason for that is that XFree has no idea of alpha and sets alpha to 0. It's been a while since I messed with this, but you may want to mess with the graphics levels since you can adjust the graphics plane and the overlay separately. Unfortunately, I don't remember how they interact in per-pixel mode. Is there a way to specify the alpha value to use (255) when operating in rgba-32 ?. Probably, when using 24 bpp, on radeon it's actually 32 bits internally. you could probably just adjust what the additional bits get set to. I suspect it's already set to 255 though. If you really wanted to you could probably also add a hack to adjust the alpha value of the framebuffer when Xv attributes are changed, however, I'm not too familiar with the DIX parts that may be involved. Alex Stefan Lucke ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: xv, radeon, alpha blending
On Sat, 19 Jun 2004 10:40:49 +0200, Stefan Lucke [EMAIL PROTECTED] wrote: Hi, based upon Michael Deucher's radeon_xvalpha.diff found at It's actually Alex Deucher. http://www.botchco.com/alex/radeon/Xv/xv_alpha/ I enabled pixel based alpha blending by attached diff. The only drawback is that any other screen region (without alpha values) is black. The reason I didn't implement per-pixel alpha blending initially was that it requires a framebuffer format with alpha values like or , etc. Without that, it's not much use. Alex -- Stefan Lucke xv-radeon-alpha.diff.gz - 1K ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Matrox I2C patch
On Sat, 12 Jun 2004 05:06:25 -0500, Ryan Underwood [EMAIL PROTECTED] wrote: I have two bugs open on the mga driver that I'd like some feedback on: http://bugs.xfree86.org/show_bug.cgi?id=1098 This one implements I2C support for G-series cards with single-chip dualhead support. (i.e. not G200 MMS) The purpose is to talk to the MGA-TVO (Maven) chip which controls everything related to TV output, but is also used for one of two monitors in a dualhead setup. There is no public documentation for Maven, so I based my code on matroxfb and OpenBeOS code. (None was directly used.) The end result is that DPMS and DDC both work on the Maven head, and also that we can tell whether a monitor is attached or not (if not, we can set timings appropriate for a TV). We also should be able to detect the version of the Maven chip, which will let us get G200-TV working, which uses an earlier version -- I implemented code for that detection based on matroxfb but I'm not sure if it is working correctly until I find a G200-TV of my own. I wish I knew how DVI support worked with it. AFAIK, no G400 was sold with a DVI port, but there exists an MAFC add-on: http://www.matrox.com/mga/products/upgrades/flat_panel_g400.cfm It looks like it can be added onto even dualhead cards as long as the upgrade connector is not occupied. I guess that is the reason they claim that it doesn't work on a single-head G400 that has been upgraded to dualhead. As I recall, they just used an external TMDS transmitter connected to one of the crtcs. One of the savage4 cards I have has a DVI port that works that way, and it works fine, including ddc. the tmds transmitter works transparently. This is the first steps towards getting rid of HALlib completely. It will not longer be necessary once we are doing our own mode setup on all heads of all G400 types, because G400 is the last one who needs the HALlib still. The TV mode setup is easy because Petr has done most of the reverse engineering already. I would really like to find someone that can check out the DVI angle (or send me a DVI monitor -- on loan of course!) I can help with the DVI stuff. I have a G550. Does anyone know what the second port on a G400-TV is: http://www.tomshardware.com/video/19991118/images/matrox_pcb.gif It would appear to be a DVI port from that side angle, but it must be for some special break-out cable with a VGA and NTSC plugs on it. http://marvel.sourceforge.net/ http://bugs.xfree86.org/show_bug.cgi?id=1401 This one is a quickie fix for a crash which occurs under the described conditions. Without this, it is impossible to run a static X server with a G400 and a dualhead configuration, or to run a dualhead configuration without HAL and have a graceful failure -- as soon as any display update occurs, you get a server segfault. -- Ryan Underwood, [EMAIL PROTECTED] signature.asc - 1K ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Screen Rotation
--- Helmar Spangenberg [EMAIL PROTECTED] wrote: Hello, I am using a tablet pc of Fujitsu Siemens, it contains an i830 chipset. Is there a possibility to rotate the screen by 90°? I know that there is an i810fb driver at sourceforge which claims to be able to do that. Does it make sense (e.g. for me) to port the code? if the i810fb supports accelerated rotation, then it might make sense to try and port it. if it does not, then it's probably easier to port the rotate option from another xfree86 DDX such as savage. See the i810 rotation thread from yesterday for more info. Alex Helmar __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: rotate functionality in i8xx driver?
--- Sebastian Wagner [EMAIL PROTECTED] wrote: So, is there a chance to get the screen rotated *somehow* especially with the i855? Maybe non-accelerated? Check the i810 driver options. there may be an option for rotaion, I'm not too familiar with the i810 driver. If not, adding roation isn't too hard. Take a look at another driver that implements it in SW (shadowfb), like savage for instance. Then port the required changes to the i810 driver. Alex Sebastian Alex Deucher wrote: As I recall, the only driver that supports HW accelerated rotation is the smi driver. several drivers support a non-accelerated rotate option. Alex --- Lucas Correia Villa Real [EMAIL PROTECTED] wrote: On Monday 07 June 2004 16:19, Mark Vojkovich wrote: On Mon, 7 Jun 2004, Lucas Correia Villa Real wrote: On Monday 07 June 2004 08:56, Sebastian Wagner wrote: Is it planned to support Rotate functionality in the i8xx X drivers (especially the i855 / intel extreme graphics 2)? Or is there yet a way to rotate the desktop? Sebastian You can give a look on Xrandr, a library designed to deal with X Rotate and Resize extensions. There's an online manual page here: http://www.xfree86.org/current/xrandr.1.html#toc2 XFree86's implementation of RandR never supported rotation. Oh, sorry. I wasn't aware of that. Cheers, Lucas __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel -- _ Dipl.-Ing. (FH) Sebastian Wagner IN - Innovative Navigation GmbH Tel.: +49 (0)7154 807156 Leibnizstr. 11 Fax: +49 (0)7154 807154 D-70806 KornwestheimMobile: +49 (0)170 8525438 Email: [EMAIL PROTECTED] Web: http://www.innovative-navigation.de Map: http://mail.map24.com/innovative-navigation _ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: rotate functionality in i8xx driver?
As I recall, the only driver that supports HW accelerated rotation is the smi driver. Alex --- Lucas Correia Villa Real [EMAIL PROTECTED] wrote: On Monday 07 June 2004 16:19, Mark Vojkovich wrote: On Mon, 7 Jun 2004, Lucas Correia Villa Real wrote: On Monday 07 June 2004 08:56, Sebastian Wagner wrote: Is it planned to support Rotate functionality in the i8xx X drivers (especially the i855 / intel extreme graphics 2)? Or is there yet a way to rotate the desktop? Sebastian You can give a look on Xrandr, a library designed to deal with X Rotate and Resize extensions. There's an online manual page here: http://www.xfree86.org/current/xrandr.1.html#toc2 XFree86's implementation of RandR never supported rotation. Oh, sorry. I wasn't aware of that. Cheers, Lucas __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon Ati IGP340
--- James Anderson [EMAIL PROTECTED] wrote: hello, I have a notebook with ATI IGP340 and I would use linux. But on this operative system my video card support only 2D, but I need 3D. :( So I would known if 3D will supported on my video card, or this is a dream :) 3d support for IGP chipsets is available in DRI cvs: http://dri.sourceforge.net/cgi-bin/moin.cgi/Download you can either download the binary snapshots or build from source. Alex Thank you for all. Sorry if my english is not good. S. __ Do you Yahoo!? Yahoo! Domains Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Is there any work on supporting portrait mode?
--- Rafa³_Rzepecki [EMAIL PROTECTED] wrote: On Friday 21 of May 2004 16:58, Barry Scott wrote: The application is to mount a Plasma screen on its side. Which means the software simulation. We have tested on Windows and the i810 driver costs about 20% extra on a 2.4GHz P4 CPU to run portrait and play a movie. So it is possible to do reasonable cost. However using the ShadowBF under X the performance is, as you say, unsatisfactory. I think some smi chips support rotation in hardware in xfree86. I don't recall which ones off hand. Alex I believe there is a filter in MPlayer that rotates the movie. If the only thing to be shown rotated is a movie, you could consider using rotation in the movie player. However, I am not sure how efficient this is, so this needs testing. -- Rafa³ Rzepecki __ Do you Yahoo!? Yahoo! Domains Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Dual Head on i810 Driver
the current i810 driver does not support dualhead. Alex --- I'm trying to get the dual head work on Fujitsu s6010 laptop, which uses 830M as VGA card (i810 driver). However, I got the error message: Fatal server error: Requested Entity already in use! Does that mean XFree86 doesn't support dual monitor mode in i810 driver? Any one got dual monitor worked with Intel i810? Thanks for your help, Sup __ Do you Yahoo!? Yahoo! Domains Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Dualhead: BusID PCI:1:0:1: No matching Device section on Solaris x86
you need to use PCI:1:0:0 for both instances. PCI:1:0:1 is just a a place holder so that two devices show up in the windows device tree. the problem is no monitor is detected on your second port: (II) RADEON(0): Displays Detected: Monitor1--Type 1, Monitor2--Type 0 you need to force it on by adding: Option monitorlayout CRT, CRT to your PriAti device section. See the radeon man page for more. Also the DVI port is always the primary crtc. Alex I have trouble getting a dualhead setup to work with a Radeon 9600 Pro card on Solaris x86 (Solaris 10 Express). The Solaris I tried came with 4.3.0, and after several days hitting my head to the wall I downloaded 4.4.0 from www.tools.de/solaris/xf86. The Radeon has a CRT plugged into the primary connector. The secondary connector has another CRT with a DVI-VGA converter. Both of the screens display the same picture, and this has been the case from day 1. The identical displays are also shown during BIOS messages etc. so it appears the dual display is on by default. __ Do you Yahoo!? Yahoo! Domains Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: radeon driver breaking LCD brightness control?
--- John Belmonte [EMAIL PROTECTED] wrote: Andrew C Aitchison wrote: Can you try XFree86 4.4, to see whether this has been fixed since 4.3 ? Fortunately, I found a usable Debian package of XFree86 4.4 (http://ftp.fifi.org/debian-local/stable/unofficial/), which probably saved me several days of work. Yes, the problem seems to have been fixed since 4.3. I think it may be worth tracking this down, because I don't know if 4.4 will make it to the Debian Sarge release. How extensive are the radeon changes between 4.3 and 4.4? They are pretty substantial, however, most (all?) of the 4.4 radeon changes are also included in x.org 6.7, so it should work either way. Alex -John -- http:// ift ile.org/ __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: radeon driver breaking LCD brightness control?
--- John Belmonte [EMAIL PROTECTED] wrote: Hello, I'm the author of the toshiba_acpi Linux driver, which allows control of LCD brightness on some Toshiba laptops. After upgrading from XFree86 4.2.1 to 4.3.0.1 on my laptop (Toshiba Libretto L5 with Radeon M6), a bizarre problem has started: if I switch to the console and back to X, my driver is no longer able to adjust the LCD brightness until the next machine reboot. The driver operates by using the ACPI extensions for display adapters defined in the appendix of the ACPI spec. I'm not sure how, but I suspect that the radeon driver may be causing the problem. It probably is the radeon driver. Unfortunately, xfree86 and it's drivers have no knowledge of acpi at the moment. probably some acpi related regs do not get properly saved by the server. Alex I'm wondering if anyone has heard of a problem like this, or if some relevant bug fix has been made to the radeon driver since XFree86 4.3. -John Belmonte -- http:// ift ile.org/ __ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: radeon driver breaking LCD brightness control?
--- John Belmonte [EMAIL PROTECTED] wrote: Alex Deucher wrote: It probably is the radeon driver. Unfortunately, xfree86 and it's drivers have no knowledge of acpi at the moment. probably some acpi related regs do not get properly saved by the server. Can you suggest how I might get to the bottom of this? I didn't have the problem in 4.2.1 but, as there are so many changes to the driver between 4.2.1 and 4.3.0, I don't know where to look. I'm not familiar with the radeon code or XFree86 display driver framework at all. Unfortunately, I'm not familiar with ACPI at all...I don't know what might have changed. You might want to check the radeon save and restore functions that save the card state when X starts. Alex -John -- http:// ift ile.org/ __ Do you Yahoo!? Yahoo! Movies - Buy advance tickets for 'Shrek 2' http://movies.yahoo.com/showtimes/movie?mid=1808405861 ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] siliconmotion - Silicon Motion video driver
post your new patches on xfree86 bugzilla: http://bugs.xfree86.org/ in addition, you can send the patches to [EMAIL PROTECTED] Alex -- Hello XFree86, Regarding the siliconmotion XFree86 driver for Silicon Motion based video cards, we would like to add one more new chipset support and update our new binary to your website. Would you please tell us what's the procedure to do it? Thanks. Francis Fung Silicon Motion Inc. Direct: 408.501.5313 __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Xv colorkey with savage driver (Was: Re: [vdr] Re: [ANN] softdevice-0.0.5-xv-patch06.bz2)
Whoops, patch attached this time.
Alex
---
Angelus sent me this patch for the problems he was having with the
colorkey on the savage driver. I've been pretty busy so I was just now
taking a look at it. I haven't tested it yet, but then again, I
haven't had any problem with Xv on savage in the basic testing I've
done. If it is indeed the correct fix, I'll apply it to the DRI savage
driver.
Alex
--- Stefan Lucke [EMAIL PROTECTED] wrote:
Hi,
I came across some troubles with colorkeying on savage driver.
From the sources I saw that there is a different handling with color
key set
to zero vs. non-zero. From my opinion black should be treated as
other colors
too.
I'd like to get some comments from driver developers.
@ Angelus: Havn't seen your bugreport so I'll posted this on X-devel.
Stefan Lucke
On Sonntag, 18. April 2004 17:01, DOm wrote:
On Sun, 18 Apr 2004 14:55:02 +0200
Stefan Lucke [EMAIL PROTECTED] wrote:
Hi Angelus,
lets see if we can fake color key handling
Set the colorkey to 0x0100. Thats an illegal value but there
are
no bound checks :-) it still works for me.
fprintf(stderr,[XvVideoOut]: setting XV_COLORKEY to
0x0100:); if
(XvSetPortAttribute(dpy,port,atom_color_key,0x0100)
==
Success) {
If that works for you then we found a driver bug. From the source
colorkey of zero is handeld different from non-zero and with
above
change we'll go the nonzero way but with a pseudo zero value :-)
.
WOW! That really works !! You're great. :))
Well my setup is not really usable yet (no audio), but i begin to
see
the light :)
With this hack the OSD is shown _over_ the picture but the OSD
background color is fully transparent not partially transparent,
but it
is not important for me.
Now, even with no active input device the osd is shown correctly,
thanks.
[ .. ]
__
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
savage_xv.patch
Description: savage_xv.patch
Re: Sis6326 register unlock problem
--- Thomas Winischhofer [EMAIL PROTECTED] wrote: harry wrote: Hi,all I met a problem while porting xfree86 to mips, it seems that I can't unlock the sis6326 registers. SR5 is used as password register in sis6326, if 86h is written into this register, then A1h will be read from this register, and unlock all the extension registers.If the value other than 86h is written into this register, then 21h will be read from this register,and lock all the extension registers. But now when I wrote 86h to this register, I always get ffh, so the display can't be initialized. Is there anyone met this problem? You have more than this locking/unlocking problem. It seems that none of the registers can be written or read, or they are being read from/written to wrong addresses. (For example, the memory clock is never 14 MHz, and there are no 2MB versions of the 6326.). Looks like a general register addressing problem. I have no experience whatsoever with mips hardware, so I can't help you further. You can, however, try the most recent driver from my website. It uses exclusivly relocated i/o ports, so perhaps this helps. You will need support for legacy IO in the kernel for using vgahw. I have no idea if the MIPS kernel supports this at the moment. See this thread for more info: http://marc.theaimsgroup.com/?t=9900895891r=1w=2 You may want to ask on the linux-mips ML. Alex Thomas -- Thomas Winischhofer Vienna/Austria thomas AT winischhofer DOT net *** http://www.winischhofer.net twini AT xfree86 DOT org __ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Recent Intel IEGD XFree86 driver discussion
Matt, Is there any chance Intel will release the source to the IEGD driver? many of the features like native mode setting and dualhead would be nice to have in the open driver. I'm sure if the source were available the features could be merged in pretty easily. Thanks, Alex --- Sottek, Matthew J [EMAIL PROTECTED] wrote: XFree developers, Recently there has been a discussion of the IEGD XFree driver developed by Intel. This driver is developed and maintained by the Embedded Intel Architecture Division (EID) for use on embedded platforms and should not be confused with the Extreme graphics drivers developed for desktop and mobile use. Many of the embedded platforms, which this driver was designed to support, contain similar components to those used in the desktop and mobile markets. Because the chipsets are often identical, it is possible that this driver could be used in some situations where the XFree86 i810 driver does not function well. Using the driver in this manner is not officially supported by the embedded division. Unfortunately the 1400x1050 mode that was discussed on this list is not supported in the IEGD driver when using the LVDS display. Although the embedded driver does not rely on the vBios for mode setting, the 1400x1050 mode requires the LVDS to run in a dual-channel mode which the IEGD driver does not currently support. Other configurations, such as 1024x768 on the LVDS display and many common CRT and TV displays are fully functional. Information regarding this driver can be found at this website: http://developer.intel.com/design/intarch/swsup/graphics_drivers.htm The User's Guide, available with the driver, provides significant details with regard to configuration and features of this driver which may be useful for those users investigating the IEGD driver. Thanks, -Matt __ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Dual Screen + i810
the opensource i810 driver doesn't support dualhead at the moment, however, it seems intel has released a binary driver on their website that supports dualhead. check the dri-devel archives for more info: http://marc.theaimsgroup.com/?t=10816138721r=1w=2 Alex -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Does somebody uses the i810 driver with dual-screen on a laptop please ? i can't make it work :( Thanks -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAhAkyH6AppSifBIcRAmdWAKCwHc8kCbtXxXAblv6gA9xrhfIsagCgpnzE JcMZUBogW/HQvqs2fDhvmpk= =QOKN -END PGP SIGNATURE- __ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.com/ph/print_splash ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: i830 screen black after resume on 4.4
--- Jeff Chua [EMAIL PROTECTED] wrote:
On Mon, 12 Apr 2004, Alan Hourihane wrote:
Have you tried adding
Option VBERestore false
Tried, but still doesn't work.
On Sun, 11 Apr 2004, Alex Deucher wrote:
Can you narrow down the exact change that caused the problem?
I looked into why 4_3_99_9 works, and anything after doesn't, and
realized
that this portion of the code causes the problem.
--- i830_driver.c.org Mon Apr 12 22:25:53 2004
+++ i830_driver.c Mon Apr 12 22:29:29 2004
@@ -2147,6 +2147,14 @@
vbeFree(pVbe);
#if defined(XF86DRI)
+ /* Load the dri module if requested. */
+ if (xf86ReturnOptValBool(pI830-Options, OPTION_DRI, FALSE)
+ !pI830-directRenderingDisabled) {
+ if (xf86LoadSubModule(pScrn, dri)) {
+xf86LoaderReqSymLists(I810driSymbols, I810drmSymbols, NULL);
+ }
+ }
+
if (!pI830-directRenderingDisabled) {
if (!xf86LoadSubModule(pScrn, shadow)) {
PreInitCleanup(pScrn);
It seems that loading the DRI causes the screen to go blank after
resume.
If I don't suspend/resume, screen works fine.
Next, I tried disabling DRI ...
Option DRI off
and that fixes the problem. Screen restores correctly after resume.
I don't know how to fix the DRI to get it to restore the screen after
resume, but if someone is willing to provide guidance, I'll be more
than
willing to help.
Unfortunately, there is no real dri support for suspend/resume. The
only driver with support is the radeon driver. you also need to have
suspend/resume support in the agp chipset driver. See this apge for
more info:
http://cpbotha.net/dri_resume.html
Feel free to implement support.
Alex
Thanks,
Jeff.
__
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway
http://promotions.yahoo.com/design_giveaway/
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: i830 screen black after resume on 4.4
--- Jeff Chua [EMAIL PROTECTED] wrote: I'm getting black screen after power resume on version 4.4.99.2. I can see the mouse, all window frames, but black contents. No such problem with 4.3.0. Tested on linux 2.4.26-rc2 and 2.6.5 I'm using apm to resume, and with 4.3.0, it works fine. You might try changing the VT prior to suspending if you are not already. Alex Thanks, Jeff [ [EMAIL PROTECTED] ] __ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [idea] bluetooth-enabled phone device keyboard/mouse driver
--- Luke Kenneth Casson Leighton [EMAIL PROTECTED] wrote: hi, i saw your web site was encouraging people to suggest ideas for xfree86, and i figured, what the heck :) i have an XDA-2 phone and have just recently managed to get the touchscreen driver working (sort-of) and also managed to get a basic framebuffer running. xtiny-fbdev works absolutely fine. anyway, i would like to be able to make use of the device to make a demonstration / talk, and to use it as part _of_ the talk. it occurred to me how i might achieve that, with the limited success so far. the idea is to use the XDA-2 touchscreen as a keyboard / mouse driver for another x-server. ... radical, huh ? :) in principle it's quite simple: run X on the XDA-2, run a small keyboard program on it which communicates over Bluetooth to _another_ X server on a machine running an overhead projector screen. in this way, i can walk around, i can use the XDA-2 to give the presentation, i can type on the mini-keyboard on the XDA-2 screen. in other words, the XDA-2 becomes like the new Logitech bluetooth keyboards that you can now buy for £200 in PC-World: for your £200 you get three devices - a full-sized bluetooth keyboard; a bluetooth mouse; a number-pad bluetooth keyboard with a 2-line LCD display. alternatively, you spend your £200 on an XDA-2, download linux, download some x-proxy-drivers and you get a phone thrown in as well, which is something a logitech bluetooth keyboard don't do :) in implementation terms, it's a kind-of extension of the VNC and rdesktop principle. the difference is that [some new?] x-windows program _generates_ x-events which need, somehow, to be treated as an Input device to a second x-windows server, but there is no requirement to forward the Screen events from the second x-windows server _back_ to the x-windows program running on the first x-server. i believe that, when it is put like that, there probably already exists some software (i recall seeing something like the xvfb package under debian? no, that's the virtual framebuffer one - i think i mean Xnest) which is typically used for testing purposes that could be adapted to do the job i describe. i don't really know - i'm just throwing in ideas, see what sticks :) l. you could run Alan's xf4vnc (http://xf4vnc.sourceforge.net/)on the remote server and then run the vnc client on your pda. That way your PDA can control the remote desktop. Alex __ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: S3 driver bug
--- root [EMAIL PROTECTED] wrote: I think there's a bug in the acceleration code of the s3 driver. When scrolling (with acceleration enabled), only parts of the screen that become newly visible really get visible, the screen doesn't scroll up. XaaNoScreenToScreenCopy option solves it. For your information: kernel: linux-2.5.6 lspci reports: 00:12.0 VGA compatible controller: S3 Inc. 86c768/765 [Trio32/64/64V+] (rev 53) (prog-if 00 [VGA]) Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Interrupt: pin A routed to IRQ 11 Region 0: Memory at dc00 (32-bit, non-prefetchable) [size=64M] Expansion ROM at dbff [disabled] [size=64K] hm, kernel in linux-2.6.5, but i am piping this text into 'mail', can't undo... Is there anyone who knows how to solve this? Take a look at s3_accel.c and see if there is a problem with it's ScreentoScreenCopy implementation. you might also want to compare it to the 3.3.x driver to see if it did anything differently. Alex Maarten Deprez __ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] Re: Xv and memory
Erik Slagter wrote: Hi, How can I calculate how much memory my frame buffer + Xv will need or actually use? I have a dual head setup on a Radeon Mobility 7500, 16 Mb memory. In my normal setup I have a panel running [EMAIL PROTECTED] and a TFT monitor running [EMAIL PROTECTED] This would imply it needs 1400x1050x4 + 1024x768x4 bytes of memory (+ some overhead), which is approx. 8.8 Mb. I can do all stuff with xv on screen #1, but Xv on screen #0 (the 1400x1050 one) fails with BadAlloc when requesting Xv for resolutions over approx 200x100. I don't understand that, where does all that memory go? I don't know exactly how the radeon driver shares the available memory among the two heads, but if it does that 50:50 as I would assume, the problem is obvious. If each screen gets 8 MB, the 1400x1050x32 screen uses almost 6MB just for the visible screen. A little bit for pixmap cache, mouse cursor, perhaps command queue and the available memory soon isn't enough for Xv (which probably uses double-bufferung for avoing tearing effects). Not even speaking of memory fragmentation after a while. For YV12/I420/NV21/NV12 video, the required memory size for one frame is calculated as follows: Size = width * height * 3 / 2 For YUV2/YUVY/YVYV/RGB5/RGB6 it is Size = width * 2 * height For double buffering, multiply this by 2. Thomas The radeon driver indeed divides memory 50/50 in dualhead mode. Thomas is right, you are probably running out of memory on 1400x1050 head. One option you have is to try the MergedFB mode available in DRI cvs (http://dri.sourceforge.net/cgi-bin/moin.cgi/Download). Since both crtcs are treated as one head, the whole 16 MB is shared by both heads. all of the available offscreen memory can then be used by either head for Xv, etc. Alex __ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: VIA drm compatibility update.
--- Thomas Hellstrom [EMAIL PROTECTED] wrote: Hi! Code for bringing the VIA 2d driver up to date with the drm module currently in dri.sourceforge.net cvs has been submitted under bugzilla 1327 /Thomas Thomas, If you'd like to keep an up-to-date 2D driver in DRI cvs that's in sync with the 3D driver and DRM, you are more than welcome to. The changes there will gets synced with Xfree86 when the trees get periodically merged. We can also provide nightly snapshots along with the other DRI drivers. Alex __ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Xfree86 sh4
I haven't looked at the code SMI code in xfree86 in a while, but if it's unsatisfactory for your needs, you should contact SMI directly. In my experience they have been pretty responsive to developers. Also full databooks for all their chips are available on their website. Alex Hi, I am a trainne at STMicroelectronics of Tunis, My project aims of runing a demo graphic of ST40 microcontroller with the silicon motion graphic card managed with th LynxEM+ video processor (under linux as an OS). ST40 is a 32 bits RISC with sh4 core (hitachi), the development platform does not a BIOS. I ask you if i can use the siliconmotion driver which you provide in your new release (4.0.0) in order to validate the SM card. Thank in advance for your collaboration, regards, Mohamed. __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Testing X on 2.6 Mega Hertz FPGA
--- Suresh Chandra Mannava [EMAIL PROTECTED] wrote: Tim Roberts wrote: Andrew E. Mileski wrote: Andrew E. Mileski wrote: Suresh Chandra Mannava wrote: Dear Friends, We are porting Xfree86 on to a new 32bit RISC processor. We have test FPGA system running at 2.6 Mega Hertz (Bogomips 0.16) on kernel 2.4.7. proposed system(ASIC) runs on ~300Mhz. Ack! I read GHz there for some reason. Sorry. I don't think it will be very useful with stock XFree86. Well, the question is not whether it would be USEFUL. The question is whether it would be POSSIBLE. They're trying to test their design in an FPGA before committing it to ASIC. It's a proof-of-concept, not a marketing trial. As long as you are patient, I don't see any reason why this shouldn't work. To the original poster, what is your video device and how is connected? Have you implemented a kernel frame buffer device so that the XFree86 frame buffer driver will work? Our video device is an add on PCI ATI Rage XL with 8MB RAM, now we are facing some problems in initializing frame-buffer. I am sure this problem will be solved before we test Xfree86. I heard that X server has its own ATI (Mach64) driver which works with out kernel frame-buffer support, Is it true? Yes. the ati wrapper loads the ati_misc driver for mach64 and older chipsets. No kernel FB is needed. Alex -- Suresh Chandra Mannava Software Engineer, Cornet Technology India, Chennai. CSE, Research Student, Vellore Institute of Technology - India. Email: mannava(at)vit.ac.in, Mobile: +919884278813 __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Xinerama xtest
--- Alan Hourihane [EMAIL PROTECTED] wrote: I remember that a couple of extra tests failed with Xinerama enabled. Weren't there also some fixes for xtest and xinerama that came from the dmx project? Were those ever integrated? The ones I'm seeing are XCopyArea and XCopyPlane. Are these the ones that are expected to fail - Mark V. ? Alan. __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [support@ati.com: XFree / Linux Support # 2118096]
--- Andreas Klemm [EMAIL PROTECTED] wrote: Hi XFree86 dev team, how good does ATI support you in comparison to nVidia ? Is it only a manpower problem, that the new ATI cards based on R3xx chips are missing 3D support (I noticed that in the 4.4 release notes) ? Or is it just because you don't get easy hardware or developer informations from them ? A few days ago I had to call ATI hotline (where you have to pay $9.90 for phone support) because of some problems under XP... There I mentioned, that I had the feeling that nVidia seems to support XFree86 team more than ATI, since - drivers of up to date cards have been available in earlier releases than 4.4 and - there are no restrictions concerning 3D mode I told ATI that for me as Windows and Unix user it had nearly been a reason, not to choose the ATI card, even if I think that ATI cards have better quality and design (256Bit RAM access, 8 parallel pixel shaders, ...). I don't know how the binary drivers compare, but from what I've heard they seem to support similar functionality. I think in general though ATI is more open to xfree86 and open soruce development. they provide databooks to just about all of their hardware and they regularly update the open source driver with new codes drops. nvidia only supports 2d in the opensource nv driver they maintain through mark v. The open source ati drivers support 2d and 3d for all chips from the mach64 to the r200 radeons. r300s only have 2d support. This is reason enough for me to buy ati products over nvidia ones. Alex ATI seems to be interested and wants to know exactly why I think, that nVidia seems to support XFree86 better. It seems for me, that this question might be a door opener for you just for the case there exist some difficulties. For me personally I'd love to see that you get all the informations you need from ATI, to make drivers of same quality and featureism (2D AND 3D) like the nVidia ones. So please tell me something concerning this issue. For those of you my translation of their mail (see attachement): + Dear Mr Klemm, concerning our phone call we'd like you to answer some questions so we can make our support better for customers in Europe. You mentioned, that you are very satisfied with ATI cards, but nVidia would offer more support for XFree / Linux. Could you please describe that for us in detail ? Do nVidia XFree/Linux driver offer more functionality ? Do the Linux Developer have better access to driver informations ? Does nVidia offer more driver for Linux than ATI does ? Does nVidia offer more support as ATI ? + Best regards Andreas /// -- http://www.64bits.de http://www.apsfilter.org http://people.FreeBSD.org/~andreas ATTACHMENT part 1.2 message/rfc822 From: ATI Technical Support (Canada) [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: XFree / Linux Support # 2118096 Date: Fri, 12 Mar 2004 05:58:16 -0500 Sehr geehrter Herr Klemm, bezüglich unseres Telefongesprächs am 11.03.2004 möchte ich Sie bitten paar Fragen zu beantworten damit wir unseren Support für unsere Kunden aus Europa verbessern können. Sie haben erwähnt, daß Sie mit ATI Karten sehr zufrieden sind aber Nvidia mehr Support für XFree / Linux bietet . Wir möchten Sie bitten dieses Thema etaws präziser für uns darzustellen. Haben XFree/Linux Treiber von Nvidia mehr Funktionen? Haben die Linux Entwicker besseren Zugang zu Treiberinformationen? Bietet Nvidia Linux Treiber öfter als ATI? Bietet Nvidia mehr Support als ATI? Mit freundlichen Grüßen Farhad Sadough Customer Service Representative ATI Technologies Inc. www.ati.com ATTACHMENT part 2 application/pgp-signature __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [support@ati.com: XFree / Linux Support # 2118096]
--- Shaul Karl [EMAIL PROTECTED] wrote: On Mon, Mar 15, 2004 at 01:06:46PM -0800, Alex Deucher wrote: I think in general though ATI is more open to xfree86 and open soruce development. they provide databooks to just about all of their hardware Does that means that everyone who is willing to pay just for the books can buy them? What about the data book for the r300s? No. you have to register as a developer at their website. it helps to have actually developed some code for their chips before hand. I think they want to limit who they give access to; they only give the books to people that will use them. I've heard they have released some 2d info for r300 but no 3D stuff. If you are an oem or a partner you can probably get any and all of the databooks, but there will be limitations on what you can do with that info. nvidia only supports 2d in the opensource nv driver they maintain through mark v. The open source ati drivers support 2d and 3d for all chips from the mach64 to the r200 radeons. r300s only have 2d support. Will the r300s have 3d support in the future? It depends whether they release 3d databooks to opensource developers or not. It might help if someone (like the weather channel) decides to write a driver for r300 and opensource it. -- If you have an apple and I have an apple and we exchange apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas. -- George Bernard Shaw (sent by shaulk @ actcom . net . il) __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] Radeon Mobility U1 accelerated 3D support yet?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 10 March 2004 9:51 am, Alex Deucher wrote: 3D support for the IGP chipsets is available in DRI cvs. You can either build from source or try the nightly binary snapshots available here: http://dri.sourceforge.net/cgi-bin/moin.cgi/Download Cool, I'll try it out. What directories should I back up so that I can revert to a previous version if the CVS is unworkable? I'm running debian. --- /usr/X11R6 Also, if you don't want to build the whole tree I believe there are debian snapshots available in addition to the nightly snapshots. Alex __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] Radeon Mobility U1 accelerated 3D support yet?
3D support for the IGP chipsets is available in DRI cvs. You can either build from source or try the nightly binary snapshots available here: http://dri.sourceforge.net/cgi-bin/moin.cgi/Download Alex - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is there any Radeon Mobility U1 accelerated 3D support yet? Any on the horizon? - -- The choices we make dictate the life we lead. To thine ownself be true. -- William Shakespeare __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Multimon failure with two identical PCI cards and driver.
--- Mike Imhoff [EMAIL PROTECTED] wrote: THE PROBLEM: When running a dual head configuration, the primary head is not drawn, while the secondary head works correctly. Failing system notes and observations: 1. The video hardware does not have a BIOS or VGA core of any kind. 2. The video driver functions properly when using a single head configuration on either head. 3. The video driver and hardware are 8 bit only, one 1200x1600 mode, with no accelerations. 4. The primary head is lit and will respond to framebuffer writes after memory mapping in the driver and the written data remains unmolested through the entire XServer session. 5. The cursor appears to move into the drawing area of the primary head, but is not visible there. 6. Running Xinerama has no effect on the failure to draw on the primary head. 7. Multimon function is correct when configured to run only one head with any DIFFERENT PCI/AGP card. 8. There are no global variables in the driver that are not required by display drivers. 9. OS is Red Hat 9.0... 2.4.x kernel. Has anyone seen this before and how was it fixed? try different PCI slots. Alex __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Multimon failure with two identical PCI cards and driver.
--- Mike Imhoff [EMAIL PROTECTED] wrote: Thanks for your reply... I'm curious why you would suggest using different PCI slots, seeing that both heads work in their respective slots under a single head configuration in item #2. I don't know why... resource allocation variations? I've had personal experience though where trying different slot configurations make it work. not only with vga cards, but also with ethernet, etc. Alex At 06:54 AM 3/5/2004 -0800, you wrote: --- Mike Imhoff [EMAIL PROTECTED] wrote: THE PROBLEM: When running a dual head configuration, the primary head is not drawn, while the secondary head works correctly. Failing system notes and observations: 1. The video hardware does not have a BIOS or VGA core of any kind. 2. The video driver functions properly when using a single head configuration on either head. 3. The video driver and hardware are 8 bit only, one 1200x1600 mode, with no accelerations. 4. The primary head is lit and will respond to framebuffer writes after memory mapping in the driver and the written data remains unmolested through the entire XServer session. 5. The cursor appears to move into the drawing area of the primary head, but is not visible there. 6. Running Xinerama has no effect on the failure to draw on the primary head. 7. Multimon function is correct when configured to run only one head with any DIFFERENT PCI/AGP card. 8. There are no global variables in the driver that are not required by display drivers. 9. OS is Red Hat 9.0... 2.4.x kernel. Has anyone seen this before and how was it fixed? try different PCI slots. Alex __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] XFree86] xfree4.4 and igp: old stuff!
4.4 did not contain DRI support for IGP chipsets. you need to use the DRI/mesa trees for DRI support. You can either build form source or try the DRI binary snapshots: http://dri.sourceforge.net/cgi-bin/moin.cgi/Download Alex -- Subject:[XFree86] xfree4.4 and igp: old stuff! From: spiritelllo () interfree ! it Date: 2004-03-05 10:34:25 Message-ID: 20040305103425.11054.qmail () community9 ! interfree ! it Hi everyone, I am new in this mailinglist and I join it for having some elucidation about ati \ radeon igp 320M. I was surfing for months in internet trying to understand if with \ the new X4.4 it could be possible to use 3D acceleration. From the status driver page \ it seems not, but then I found in \ http://dri.sourceforge.net/cgi-bin/moin.cgi/ATIRadeon#head-6a4e73023cc0fb0cfbf5bd0f19a \ 45d660193263f that there is support for 3D using opengl and mesa. What I couldn't \ understand is the procedure that I have to follow for getting my card working in 3D. \ What I have done is: 1. source xfree4.4 --- compiled (with no patch) all 7 files! 2. kernel 2.6.0 patched for igp dri/drm but xglinfo says that I am not using drm (infact xglgears gives 60fps...) So what is the exact procedure that I need to follow? Do I need to patch xfree as \ well? I tried with Radeon IGP DRI patch for XFree CVS 4.3.99.9 and compile again \ Xfree but it fails. thanks for any help regards andrea __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: ibm526 ramdac support for s3 968
Please create a bug on xfree86 bugzilla and add this patch to it.
http://bugs.xfree86.org/
Alex
--- John Hay [EMAIL PROTECTED] wrote:
Hi,
I have two old Diamond Stealth 64 VRAM cards that use the IBM 526
RAMDAC.
This patch makes XFree86 work on it again. The relevant pieces of the
log
file look like this:
(II) s3(0): VESA VBE OEM: Diamond Stealth 64 Video VRAM
(--) s3(0): Attached RAMDAC is IBM 526
(--) s3(0): MCLK 74.286 MHz
John
--
John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED]
diff -ur org/xc/programs/Xserver/hw/xfree86/drivers/s3/s3_driver.c
xc/programs/Xserver/hw/xfree86/drivers/s3/s3_driver.c
--- org/xc/programs/Xserver/hw/xfree86/drivers/s3/s3_driver.c Thu Sep
25 13:05:02 2003
+++ xc/programs/Xserver/hw/xfree86/drivers/s3/s3_driver.c Sat Jan 24
16:50:37 2004
@@ -171,6 +171,8 @@
RamDacSupportedInfoRec S3IBMRamdacs[] = {
{ IBM524_RAMDAC },
{ IBM524A_RAMDAC },
+ { IBM526_RAMDAC },
+ { IBM526DB_RAMDAC },
{ -1 }
};
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
__
Do you Yahoo!?
Yahoo! Search - Find what youre looking for faster
http://search.yahoo.com
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] Radeon 9200: DRI on one head and 2d on second head ?
--- Dominique Dumont [EMAIL PROTECTED] wrote: Alex Deucher [EMAIL PROTECTED] writes: It sounds like what you may want is my radeon driver with mergedfb support. It uses each crtc as a viewport into a single shared framebuffer so the DRI works on both heads: http://dri.sourceforge.net/cgi-bin/moin.cgi/MergedFB Looks like it. Is it provided with XFree 4.3.0 or 4.4.0 ? Neither; it hasn't been merged into the Xfree86 tree yet. It's in DRI cvs. you can either use the binary snapshots or build from source: http://dri.sourceforge.net/cgi-bin/moin.cgi/Download Alex -- [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Multiple Monitors
--- Thomas Winischhofer [EMAIL PROTECTED] wrote: Alan Hourihane wrote: I prefer option 2 because of its fewer levels of SubSections. What's the replacement for the metamodes option/concept? Will this survive? No. Hm. In that case, I don't think this is a real step forward. It requires more configuration data instead of less: Only for simple configurations... read on. The current implementation (at least in the SiS driver, can't really speak for the others), the Modes in the Display subsection are the pool from which the meta modes are composed. All modes in that (yet single) Display subsection are checked against the specs of *both* output devices (which are the Monitor section for device 1, and specific options in the Device section for the second; in both cases unless we have DDC data). If they pass this check, they can be part of a meta mode. Your modification forces the user, more or less, to enter the same data twice. I don't really see the advantage, except that it's maybe more intuitive to read the config file but that is assumingly not the goal. The fact is, more and more video cards are getting multiple heads. Even the Matrox Parhelia can drive 3 monitors. I know of others than can drive 4 monitors and it's just not user friendly/scalable with the current setup. No question. Agreed. As all the drivers seem to have their own implementation (albeit similar) AFAIK only 3 open source drivers support mergedfb yet: Matrox, SiS and radeon (in the DRI trunk). Radeon's code is nearly if not entirely identical with the SiS code as Alex Deucher took my SiS code and inserted it into the radeon driver. As regards pseudo-xinerama, I think the SiS driver is the only one currently (unsure if Alex took that over, too). The Matrox driver has no such feature. I don't think the OSX implementation is similar enough to make use of unified code but that's up the Apple folks to judge. Yup, I ported pseudo-xinerama over to radeon as well. I also plan to bring the mga driver up to speed with the other drivers as time allows, pending ryan's re-work of the dualhead/dvi stuff. The options (and their names) of all three drivers supporting mergedfb are identical; they are, conceptwise, mostly even identical to the binary NVidia driver (except that the open source drivers don't support panning domains - however useful that is anyway). (Hm, reading this might make one think that there already is something like a standard) it clutters up drivers with very very similar code too. Agreed. Yes, there might be more config to do in the config file, but the tools to setup these up hide a lot of that already. Hell, I'll even make the -configure option do the right thing too. OK In case you mean that the resolution changes in the same order the modes are given in these two Monitor sections, I find this far less easy to configure (one has to count the Modes to see which ones are being combined, etc.) And how are clone/zoom modes being configured? I'm open to suggestions on how to deal with all this, and that's why I brought it up. The current situation of 'let the driver deal with it' is just ripe for getting out of control. I am not against your idea at all, in case I made this impression. I just wanted to point out that just monitor configuration is by far not sufficient. The following is meant to give a short overview and as a basis for comments for a new configuration implementation: Summarized, the criteria for configuring mergedfb mode are - monitors and their specs; that is what your proposal so far took care of, - relative position = orientation (mon A left/right of/above/below mon B; that can be extended to 3 or 4 or whatever number of monitors easily: mon c above mon b, mon d above mon a etc) and clone/zoom (=both/all show the same image, possibly with a zoom facility) - mode selection for each monitor (read: output device); there the problem starts. As I said, right now, the drivers use the (only) Modes list as the pool, and the MetaModes statement for combining these modes. What I would find highly unpractical is leaving this out entirely and use the Modes given in the new Monitor Subsections as the modes the driver should use - in that order. From my experience, users think more in a whole when configuring mergedfb mode. Meaning that the emphasis is on the respective modes used on each output device _at_the_same_time_ = metamode. A plain list of modes for each monitor (of which assumingly many will be skipped when they exceed the specs) makes server behavior highly uncomprehendable from a user's point of view: If one or the other mode is deleted from the list, the whole list is shifted, and hence the result is an entirely different one. I find the MetaModes concept, even
RE: XAA2 namespace?
--- Sottek, Matthew J [EMAIL PROTECTED] wrote: Will there be open discussion of what makes up Xaa? I know you have already have a working design but rather than accept major changes wholesale can we discuss the finer points before they become defacto-accepted. -Matt It depends what you'd like to discuss. I already have a working implementation. It does not preclude usage of the old XAA. A driver can use either one. Nobody has to touch old drivers if they don't want to. I'd like to discuss the design details. Why don't you send the relevant parts of the header to the list for discussion before you commit it? Lets face it, once the code is committed there is not going to be as much room for change. If Xaa is being replaced then it seems fitting that everyone have a chance to review and comment on the design before it is committed. good alpha channel support would be nice too, although that might require some other changes. Alex [snip] __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Radeon 9200: DRI on one head and 2d on second head ?
-- Hello I'm trying to setup an ATI Redeon 9200 card for a multimedia PC. The goal is to be able to connect a video projector on the DVI head (screen 1) and the monitor on the main head (screen 0). And my kid would be rather disapointed if he can no longer play with gltron on the main screen, so I need a working DRI on the main head. With Xfree 4.3.0, I am able to setup DRI on one head, *or* set up a dual head (2 screens setup). But in the latter case, the DRI is disabled: Radeon driver does not support DRI with dual head setup even if the NoAccel option is set in the second Device. IS this statement correct or did I miss something ? In the xfree86 4.3/4.4 radeon driver you can't mix DRI and dualhead. It may work without xinerama, depends what you are doing. So I was considering to set up a single head configuration for X on the main head and set up a frame buffer on the second head. Thus I could use directly the -vo fbdev and display the video directly on the second head without going through X. Is that possible ? (OK, I'm drifting off-topic) Does anyone have a pointer and how to set up a radeon frame buffer on the second head ? AFAIK, the radeonfb kernel driver does not support multiple heads yet. Thanks for any help. It sounds like what you may want is my radeon driver with mergedfb support. It uses each crtc as a viewport into a single shared framebuffer so the DRI works on both heads: http://dri.sourceforge.net/cgi-bin/moin.cgi/MergedFB Alex __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Multiple Monitors
--- Alan Hourihane [EMAIL PROTECTED] wrote: I'm looking to enhance the parser in XFree86 so that a lot of redundant code in the current drivers that implement the 'mergedfb' mode can be eliminated such that they don't have to do all the monitor munging in the driver. So here's two variants of the modifications to the XF86Config I'm thinking of, and both would remove the current 'Monitor' keyword from the Screen Section, in favour of the SubSection keyword being the actual monitor it's referencing. I've already started poking around the parser to implement this, but I thought I'd ask for comments first before taking it too far, and to ask for possible enhancements that others can think of too. I like Option 1. but either is ok with me. Also, FWIW, a lot of the other mergedfb code could/should be moved into a general mergedfb lib. Stuff like pseudo-xinerama could be folded into the real xinerama extension. some of this work may already be done for the OSX port. Also how would clone modes and head orientation be handled in this model? Perhaps a clone mode of each supportable res on each monitor would be automatically added? I'm not sure what the best way to handle that is. Alex Option 1 Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 SubSection Monitor0 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection SubSection Monitor1 SubSection Display Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Display Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSubSection EndSection Or, Option 2. Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 SubSection Monitor0 Depth 16 Modes1024x768 800x600 640x480 EndSubSection SubSection Monitor0 Depth 24 Modes1024x768 800x600 640x480 EndSubSection SubSection Monitor1 Depth 24 Modes1024x768 800x600 640x480 EndSubSection EndSection Comments ? Alan. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel __ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: help new driver
--- dave [EMAIL PROTECTED] wrote: I am writing a driver and need to now what copyright GPL stuff I need to put in my source files most XFree86 device drivers has a X11/BSD style license. take a look at the other drivers in xc/programs/Xserver/hw/xfree86/drivers However, how you want to license your driver is up to you. Alex __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] 3D OpenGL for S3/Pro Savage DDR-K
Felix and I have ported S3/VIA's savage code to the current savage driver. it's available on the savage-2-0-0-branch in DRI cvs. It's still in development, but works pretty well. All savages are supported except the savage2000. http://dri.sourceforge.net/cgi-bin/moin.cgi/S3Savage see this page for info about downloading and building a branch of cvs: http://dri.sourceforge.net/cgi-bin/moin.cgi/Download Alex - I am seeking a driver, or information about a driver for Suse Linux 9.0 that will allow video accleration ( 3D OpenGL) on my brand new machine. My video chipset is a Via/S3 chipset. It's part of the VIA KM266 on the MB Northbridge The model is S3/Pro Savage DDR-K. I have found information about a basic driver, but it doesn't seem to allow 3D ( even though this chipset is quite capable of accleration, I know since I dual boot Windos ). So far, my searching has revealed: http://www.probo.com/timr/savage40.html#download In which the author says: VIA/S3 has release an updated version of THEIR Savage driver. It forked off of my source base about 3 years ago, so there are significant differences, but it looks like they have addressed a number of issues. This includes motion compensation support for MPEG playback (XvMC), and the long-awaited DRI driver for 3D OpenGL code. Ok, but on viaarena -- supposedly the /official/ support site for VIA/S3, they point back to probo.com (?##). Here's their drivers: http://www.viaarena.com/?PageID=184#ProSavageDDR I wrote Via's support department, but have not heard back. Again, is there any knowledge about a savage driver that will support 3D OpenGL acceleration. I have a desparate need to play TuxRacer :D on my new machine. __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] radeon 8500 hi-res 3d question
dan list wrote: Hi, I have a radeon 8500 card with 64MB of RAM, and my desktop resolution set to 2048x1536 I'm running the debian 4.3.0 radeon xserver. I can run 3d programs at lower resolutions or in smaller windows just fine, but at full screen I get mostly black pixels, with a few stationary pixels that are correctly rendered. I tried the ATI driver, and it renders everything fine at 2048x1536, but it was slow as hell for 2d, and crashed my system, so I think the hardware should support doing this. Is there some option I need to setup for XFree to work in 3d at this high of a resolution? This is a known bug in the 3D driver. I first noticed it with mergedfb. rendering is corrupted at with a desktop of 2048 pixels if the full screen 3D context extends to the 2048th pixel. this is the limit of the 3D engine. I'm not sure where the bug is offhand. I didn't see anything suspicious. if you try a 2047x1536 mode, it should render fine. here's the last thread on this: http://marc.theaimsgroup.com/?t=10659116373r=1w=2 Alex Thanks __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Patch: single button double-click
--- Rob Brown [EMAIL PROTECTED] wrote: Hi all, The one thing I missed from my Windows days was the ability to assign one of the mouse buttons to perform a left button double-click. It's pretty much a universal feature on Windows mouse drivers these days (with buttons being in ample supply on many mice), and I like it because I find the action of double-clicking irritating ;-).Also, my mother has arthritis, and finds double-clicking to be very awkward. She finds having a single button to do the double-clicking makes things much more comfortable. I tried to find the feature on Linux, and couldn't. I searched XFree86, qt, and kde, and it didn't seem to be there. Then I decided to implement it myself. Not being sure where to implement it, I finally decided to do it in XFree86 because then it can be useful to all of the window managers etc. I've made (pretty trivial) changes in xc/programs/Xserver/hw/xfree86/os-support/xf86OSmouse.h and xc/programs/Xserver/hw/xfree86/input/mouse/mouse.c. The result is a new option (DoubleClickButtons) where I can specify the source and target buttons, ie. pressing the source button will result in a double-click on the target button (the source button is no longer available for any other function). The double-click is just implemented by posting press-release-press-release with no delays in between. A nice side-effect is that I can decrease the double-click delay in KDE, which makes certain operations snappier. So my question is: is anyone else interested in this? I'm more than happy to make it public, but I don't know diff and I'll have to look into where these things are documented and I won't bother if no-one will use it :-) Post your patch and a description as an enhancement on xfree86 bugzilla: http://bugs.xfree86.org Alex Oh, and if the feature already exists and I just failed to find it, please let me know. If nothing else, it may at least show me where my search technique is deficient! Cheers, Rob Brown. __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon XvMc support
--- Andreas [EMAIL PROTECTED] wrote: Hi Does anyone know (or have some contacts at ATI that knows) what the current status of XvMc hardware support for radeon cards is? I'm using a fanless EPIA 5000 with fanless Radeon 9200SE PCI and really need this for smooth dvd playback. Ati hasn't released the databooks for the xvmc stuff on their chips (could be a license issue -- perhaps they licensed it from a 3rd party?). anyway, they did provide a binary module with their DDK, but at the moment, that's it. FWIW, the via and savage drivers have (apparently) working XvMC implementations. the one for savage compiles with the savage-2-0-0-branch in DRI cvs, however, I haven't gotten a chance to try it yet. Alex Thanks in advanced! -Andreas ps. I'm not part of any of the lists so please CC me on replys. ds. -- \_/ ( _ ) -(_)- Doctor... remember... ~O o~__/ \Always do the right thing. (._.) |\ -Spike Lee ___|_|_|_ __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Radeon XvMc support
--- Torgeir Veimo [EMAIL PROTECTED] wrote: On Fri, 2004-02-13 at 07:40 -0800, Alex Deucher wrote: --- Andreas [EMAIL PROTECTED] wrote: Hi Does anyone know (or have some contacts at ATI that knows) what the current status of XvMc hardware support for radeon cards is? I'm using a fanless EPIA 5000 with fanless Radeon 9200SE PCI and really need this for smooth dvd playback. Ati hasn't released the databooks for the xvmc stuff on their chips (could be a license issue -- perhaps they licensed it from a 3rd party?). anyway, they did provide a binary module with their DDK, but at the moment, that's it. FWIW, the via and savage drivers have (apparently) working XvMC implementations. the one for savage compiles with the savage-2-0-0-branch in DRI cvs, however, I haven't gotten a chance to try it yet. Is the DDK available somewhere except passing the ATI developer relation lottery test? Not that I know of. You have to be registered with ATI to access it. Alex -- Torgeir Veimo [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: SiS driver
--- Kean Johnston [EMAIL PROTECTED] wrote: All, Is there any reason why the SiS driver isnt the one Thomas Winischofer provides on his site? I recently had very negative experiences with the stock SiS driver on a 661FX that his driver solved immediately. Now I realized it may have solved just this one problem but it seems as the one on his site gets more attention. I know Thomas has submitted other fixes into the tree, and may even be the SiS maintainer. Thomas is the Sis maintainer and he updates the sis driver in xfree86 cvs regularly. They are the same driver for the most part. The changes he makes usually find their way into xfree86 within a day of two of him adding them. if you are using an older release of xfree86, then the driver is not as up to date as what's in xfree86 cvs or on Thomas' site. Alex Kean __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: do XFree86 accept XIM projects?
--- Zhang Weiwu [EMAIL PROTECTED] wrote: Hello. I'm zhangweiwu from the minichinput project. This is the first time I post to this list, so please forgive me if I posted to the wrong list. To be brief: minichinput is a Chinese input method server. Can XFree86 accept minichinput as its subproject? Minichinput is one of the most widely used *nix input server among the simplified Chinese users (or at least I think so). Linux distros like RedHat and Turbolinux adopted minichinput as the default input server. minichinput handles both GB, Big5 and UTF8, it is lightweighted, doesn't rely on gtk/qt. Who/what list should I contact if I wish to make minichinput a subproject of XFree86, and release as part of it? Do XFree86 accept this kind of subprojects? Post a patch and description as an enhancement on xfree86 bugzilla (http://bugs.xfree86.org). 4.4.0 is about to be released so if your patch goes in, I suspect it won't be until after 4.4 is released. Alex Thank you. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: currect place to submit patches
--- mel kravitz [EMAIL PROTECTED] wrote: Hi, I have a patch to ../bsd/alpha_video.c for NetBSD alpha 21164 boxes, where can i send this? Post the patch and a description of what it does on http://bugs.xfree86.org from there it will be reviewed and potentially committed. Alex -Mel -- mel kravitz [EMAIL PROTECTED] switching power inc __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Support for Radeon Mobility
--- Cyril Duveau [EMAIL PROTECTED] wrote: Hello, I am running linux on a Compaq Presario with an ATI video card, reporting the following via lspci VGA compatible controller: ATI Technologies Inc Radeon Mobility U1 PCI bridge: ATI Technologies Inc U1/A3 AGP Bridge [IGP 320M] (rev 01) I installed the Xfree 4.4.0 RC2, kernel 2.4.24. If my laptop is connected to an external screen when I launch Xfree, then the external screen does not get any signal anymore and the CRT gets a kind of backlight, appart from that it is black screens. If the laptop is not connected to an external screen, then launching xfree is ok. Is it a current functionality or should we already be able to use radeon server with external screen ? single- and dual- head including xinerama should work on IGP chipsets, but it doesn't seem to work right in certain instances: http://bugs.xfree86.org/show_bug.cgi?id=443 Alex Thanks for your good work, Cyril __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: [XFree86] ATI Radeon 9200SE, DVI output, black screen every
As I said 4.3.0 did not handle 9200 DVI ports correctly. Either of the snapshots should work fine. The DRI ones would provide the best 3d support. The DRI snapshots are pretty hassle free and only require replacing a few binaries: http://dri.sourceforge.net/cgi-bin/moin.cgi/Download read the snapshot section. --- On Fri, 2004-02-06 at 05:36, Alex Deucher wrote: 4.3.0 did not handle the DVI port on 9200 chips properly, this is fixed in cvs. Please update to the cvs version of xfree86 or try a xfree86 or DRI snapshot. Great! Do you happen to know whether or not the Radeon 9100 DVI handling is proper in 4.3.0? I have the choice between the two, and would like to keep my system hassle-free (e.g. using precompiled packages rather than compiling from source where possible). In general, which Radeon would offer the best 2d/3d performance when used with the open source drivers and the DVI output? __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: XVideo seems to work on NeoMagic NM2097
--- Karl Oberjohn [EMAIL PROTECTED] wrote: Hello, I have a Mitsubishi AMiTY CN2 notebook with a NeoMagic NM2097 (MagicGraph 128ZV+) video chipset. I was excited to see that XVideo support was added for NeoMagic chipsets in XFree86 version 4.3, but for the life of me, I could not get it to work. (I did add the OverlayMem option to my XF86Config.) xvinfo just gave me the dreaded No adapers present. I'm not much of a programmer, but I looked through the neomagic driver source code, and apparently the driver only activates a video overlay for chipsets NM2160 (MagicGraph 128XD) and newer. So just for the heck of it, I added the following line to my XF86Config: Chipset neo2160 I started up X, ran xvinfo... and I got a nice list of all the video modes supported by the NeoMagic Video Engine! Wow! Could it be that simple? I played an MPEG video in full-screen mode with XINE, and sure enough, video performance was significantly improved compared to the XShm output device. I even moved another window on top of the video, and I could see parts of the video showing through the colors that matched the chromakey. The only problem I had was the cursor turned into a scattered mess of dots instead of a nice arrow. I noticed in XFree86.0.log that the neomagic driver detected 2 MB of video memory when in fact I only have 1152 kB. So I added one more line to my XF86Config: VideoRam 1152 And that fixed the cursor. All other functions seem to work fine. I am running 800x600 @ 16 bpp. The other warning I received in the log file was: Can not reserve 829440 bytes for overlay. Resize to 218624 bytes. But I'm still able to play full-screen videos. Is there any reason the neomagic driver shouldn't activate the video overlay on a NM2097 chipset? (Maybe it would work on even older chipsets?) It would sure be a nice feature addition for the upcoming version 4.4... Thanks for your support, Karl O. Sounds like it works. Submit this as a bug on xfree86 bugzilla (http://bugs.xfree86.org) and hopefully it will be fixed. I'd imagine the patch would be pretty simple. You can probably do it yourself. It's probably only a matter of adding the 2097 to the check in the neomagic InitVideo() function. Alex __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Virtual Xinerama
--- Jan Dittmer [EMAIL PROTECTED] wrote: Hello, I recently aquired a second video card, so that I now have a triple display. I'm using a Nvidia card (with the binary drivers) in TwinView Mode to drive the first two displays and a Ati card for the third display. What really annoys me is, that as as soon as you enable TwinView together with a second card, the two displays are just seen as one screen and so every window manager only 'sees' two screens. So maximized windows etc. always strech over (at least) two displays. As I don't think Nvidia will be fixing this anytime soon and I think this could probably useful elsewhere (i.e. dividing your display into two screens so that window always are maximized to half the window, ...), I'm wanting to implement a kind of virtual xinerama support. I've thought about different ways of implementing this. The easiest solution I can see so far is to just extend the screen definitions in my ServerLayout like the following example: Section ServerLayout ... Screen 0 NvScreen Geometry 1280 1024 0 0 Screen 1 NvScreen Geometry 1280 1024 1280 0 RightOf 0 Screen 2 AtiScreen0 RightOf 1 Of course RightOf, LeftOf, etc. would have to be made to work with screen-nums and screen-ids. Also checks for non overlapping of areas would have to be done. And only dividing of hole screens will be supported, no funny part of this and part of that screen. So, what do you think of the general idea? Is this just totally bogus or may this be useful? Especially, are their other ways (other than hacking every wm out there) to do this better/cleaner/faster? Thanks for any comments, suggestions and hints, Drivers that implement their own xinerama extension are not compatible with the official xinerama extension (It's not that they are incompatiable, rather you can only have one xinerama extension registered at a time). right now you can only have one or the other. Torrey Lyons mentioned extending the xinerama extension at one point to better accomodate things like merged framebuffer modes and other windowing systems that provide their own multi-mon API such as Apple. I don't know that anyone has really done anything on this at the moment though. Take a look at the sis driver or the radeon driver in DRI cvs or the pseudo-xinerama stuff in the quartz code for an idea of how this should work for driver based xinerama extensions. Ideally the official extension would be extended to handle both cases. If you come up with a patch, please post! Alex Jan ps: I already started hacking on this. Seems like I've to dig quite deep into the xinerama layer. :-) ATTACHMENT part 2 application/pgp-signature __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[XFree86] Whats happening with S3 prosavage DDR 3D support
3D support for savage chips is going on in the savage-2-0-0 branch in DRI cvs. It will not be available in 4.4.0. Right now support is limited to prosavage/twister and savage4 chips and the drivers are still somewhat buggy. Support for older savages will come later. FOr the latest status, check out the info bage on the DRI website: http://dri.sourceforge.net/cgi-bin/moin.cgi/S3Savage Alex Hi, first pls excuse my bad english Finally is going to be support for 3D aceleration in xfree 4.4 ??? I tried to see the cvs change log with no luck to understand whats was there. Is there some place where i can see this information ?? Is there a way a can help ?? Thanks and regards Marcel MM __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
[XFree86] ATI Radeon 9200SE, DVI output, black screen every other restart
4.3.0 did not handle the DVI port on 9200 chips properly, this is fixed in cvs. Please update to the cvs version of xfree86 or try a xfree86 or DRI snapshot. Alex - Hello, I have just hooked up my new Radeon 9200SE using the DVI output to an NEC LCD 1880SX DVI input, and after putting the line Options MonitorLayout TMDS, CRT into XF86Config, am getting consistent performance. Unfortunately, it is also very consistent that the signal is completely gone to the monitor after every _second_ restart of X. Example: Boot- no signal (solid black screen). CTRL-ALT-BS - login screen. Login, Logout - no signal. CTRL-ALT-BS - login screen. CTRL-ALT-BS - no signal. CTRL-ALT-BS - login screen. CTRL-ALT-BS - no signal. ...forever So, I am sure I have overlooked something very simple in my config that is peculiar to using a single head on the DVI output. If you can help, I would be greatly appreciative. I am using Fedora Core/1, XFree86 4.3.0. __ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: Manufacturers who fully disclosed specifications for agp cards?
--- Ryan Underwood [EMAIL PROTECTED] wrote: On Tue, Feb 03, 2004 at 05:31:27PM +0100, Sven Luther wrote: On Tue, Feb 03, 2004 at 09:21:53AM -0600, Ryan Underwood wrote: On Tue, Feb 03, 2004 at 04:41:07AM -0500, Mike A. Harris wrote: That's not entirely true... Some people do have /some/ of the R300 specs under NDA. Is there some special circumstance you have to fall under to qualify for R300 specs? It seems there are a lot of people wishing they had them and not a lot of people saying I've got em... :) And in any way, i guess this doesn't include the 3D/DRI parts. Whoops, that was what I was talking about. I thought this thread was on the DRI list until I just now looked. Do we have at least 2d support for r300 cards in XFree86? Yes. even in 4.3. Alex -- Ryan Underwood, [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Why the OS hang when I transfer from graphic mode to text mode
--- Yukun Chen [EMAIL PROTECTED] wrote: Hi , All After I start my machine in graphic mode as default in X-window (Redhat9) I found my linux os hang when I execute the following script: while true do init 3 sleep 10 init 5 sleep 10 done I have traced the source code of graphic driver XFree86 (I use the 9880 card of trident) and found that the system hang in the following functions: 1.InitAndStartDevices-EnableDevice 2.vbedoEdid 3.vgaHWSave The hang issue can only be duplicated randomly , often after the above script has been run for 30 minutes. Can anybody give me some ideas about this? On some chips the VBE/DDC/i2c code causes lockups for various reasons. some seem to have to do with how the generic xfree86 i2c code works, others are due to weird quirks on chips that are not known to the driver writers, changing i2c addresses between chip revisions, monitors that return improperly formatted DDC info, etc. Alex Thanx. bst.,rgds Yukun __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Manufacturers who fully disclosed specifications for agp cards?
--- Sven Luther [EMAIL PROTECTED] wrote: On Sat, Jan 31, 2004 at 04:43:17PM +0200, Shaul Karl wrote: Excluding Nvidia and ATI, for which I believe I know the answer, what manufacturers I am likely to see on ebay that: 1) Usually fully and freely publish the specifications of their AGP hardware. 2) Got themselves an X driver? [snip] I am looking for a used old agp card. 3Dlabs older cards also work pretty well. The 3D accel is not fully working though, except for the GMX2000, but i don't know if that good is well maintained still. 3Dlabs cards with gamma chip have the potential to be of geforce 1/2 speed with regard to 3D. SMI (silicon motion) publishes full specs for their chips, however, I'm not sure you can find an agp card with an SMI chip on it. usually they are in notebooks and pdas. specs are also available for 3dfx chips. Alex __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: I would like to join the developer's list.
--- Brad Arant [EMAIL PROTECTED] wrote: Hello, I am a Linux developer and have actively been involved with the XFree X Windowing System. Would like to be a part of the developer's list and was wondering where the newsgroups and other conversations are actively taking place. devel (this list) is the main developers list for xfree86. other lists of interest to you may be: dri-devel (sourceforge) - development of open source 3D drivers mesa3d-devel (sourceforge) - development of open source openGL implementation and 3D drivers xserver (freedesktop) - discussion and development of alternative X server Let me know what I can do for you. feel free to work on whatever aspect interests you. Alex __ Brad Arant BARANT Technologies [EMAIL PROTECTED] (949) 305-2424 (949) 305-2425 Fax __ __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Questions
--- Nicolas Pascoli [EMAIL PROTECTED] wrote: Hello, Now, I'm using XFree 4.3.x but this release don't support ati radeon 9200 with DRI (no hardware acceleration). This is a problem : I can't play to game which need this acceleration under Linux. Then, when XFree 4.4.x will be distibuted as a rpm package (else where can I found sources). you can either try a 4.4 snapshot or take a look at this page: http://users.actrix.co.nz/michael/radeon9200.html Thanks, PASCOLI Nicolas __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
RE: Questions
--- Shrei Rin [EMAIL PROTECTED] wrote: Now, I'm using XFree 4.3.x but this release don't support ati radeon 9200 with DRI (no hardware acceleration). This is a problem : I can't play to game which need this acceleration under Linux. Then, when XFree 4.4.x will be distibuted as a rpm package (else where can I found sources). AFAIK XFree doesnt enable HW acceleration neither for nvidia or ati cards, instead you should install the propietary drivers of one of those companies, in your case ATI (http://www.ati.com) or just follow this link http://www.ati.com/support/drivers/linux/radeon-linux.html?type=linuxprodType=graphicprod=productsLINUXdriversubmit.x=14submit.y=11 for linux driver downloads, there you will find instructions for proper driver instalation. there are open source 3D drivers available for all ati cards up through the 9200. there is only open source 2d support for 9500 and above cards (r300). for 3d on r300 based cards you need to use the proprietary drivers. Alex Luis Cano __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ ___ 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: 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? Only the G400 needs it for dualhead and tv-out. the g450/550 need hal to use the DVI port and the g200 MMS cards need it for multi-head. it's also needed for mergedfb on all chips. the mga fb driver supports all of this, so in theory it could all be done without hal. 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
Re: [Dri-devel] MGA font corruption revisited - now reproducible
--- Ryan Underwood [EMAIL PROTECTED] wrote: On Wed, Jan 21, 2004 at 08:35:00AM -0800, Alex Deucher wrote: Only the G400 needs it for dualhead and tv-out. the g450/550 need hal to use the DVI port and the g200 MMS cards need it for multi-head. it's also needed for mergedfb on all chips. the mga fb driver supports all of this, so in theory it could all be done without hal. - Is only the G550 capable of swapping CRTC-DAC mapping or can the G400 or G450 do it too? Not sure. I think the g450 and g550 are about the same expect for the 3D engine and support for DVI. I suspect the g450 can do it, I don't know about the g400. - G450/G550 tv-out works without the HAL? (I think this is easier, since maven is integrated on these chips...) tv-out is not supported at all on g450/550, neither with HAL nor without. - what about the DVI addons for the G200 and single head G400? Of course, I've never actually seen one of these. I'm not sure. the add on cards might have their own tmds chip on them since I don't think the g200 or 400 or even 450 had a built in tmds controller. I could be wrong though. I've never seen one either. -- Ryan Underwood, [EMAIL PROTECTED] ATTACHMENT part 2 application/pgp-signature name=signature.asc __ 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
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
Re: [GATOS]how to check if hardware mpeg2 decoder is working
--- William M. Quarles [EMAIL PROTECTED] wrote: Alex Deucher wrote: try disabling fastwrites or pageflipping. Option AGPFastWrite false Option EnablePageFlip false Also make sure agpgart is loaded (kernel 2.4) or agpgart and the agp chipset specific driver (kernel 2.6). Hi Alex, I'm using Red Hat kernel 2.4.20-28.9, but a custom build from their kernel sources. The agpgart module is loaded. And the options brought the speed up a little in glxgears, but still definitely not hardware accelerated. glxinfo still shows that DRI is disabled. [EMAIL PROTECTED] root]# lsmod Module Size Used byNot tainted radeon115396 1 udf98016 0 (autoclean) emu10k169064 0 ac97_codec 14568 0 [emu10k1] sound 74196 0 [emu10k1] soundcore 6436 7 (autoclean) [emu10k1 sound] mousedev5556 1 (autoclean) input 5888 0 (autoclean) [mousedev] agpgart23952 3 parport_pc 19076 1 (autoclean) lp 8996 0 (autoclean) parport37056 1 (autoclean) [parport_pc lp] autofs 13268 0 (autoclean) (unused) tulip 43840 1 ipt_REJECT 3992 6 (autoclean) iptable_filter 2412 1 (autoclean) ip_tables 15096 2 [ipt_REJECT iptable_filter] sr_mod 18104 0 (autoclean) nls_iso8859-1 3516 1 (autoclean) nls_cp437 5148 1 (autoclean) vfat 13036 1 (autoclean) fat38808 0 (autoclean) [vfat] isa-pnp40932 0 acm 7840 0 usb-uhci 26412 0 (unused) usbcore79072 1 [acm usb-uhci] [EMAIL PROTECTED] root]# glxgears 530 frames in 5.0 seconds = 106.000 FPS 353 frames in 5.0 seconds = 70.600 FPS 423 frames in 5.0 seconds = 84.600 FPS 423 frames in 5.0 seconds = 84.600 FPS 423 frames in 5.0 seconds = 84.600 FPS 423 frames in 5.0 seconds = 84.600 FPS X connection to :0.0 broken (explicit kill or server shutdown). [EMAIL PROTECTED] root]# glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No My XFree86 log is different now, I can't find the section where DRI is verbosely disabled, but maybe that is related to the options you asked me to add. It is attached. 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. Alex Thanks, William [snip] __ 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
