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: 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
> >&g
Re: xaa vs. WriteImage()
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.
The sgi impact driver does something similar:
http://cgit.freedesktop.org/xorg/driver/xf86-video-impact/
Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: xaa vs. WriteImage()
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.
Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: xaa vs. WriteImage()
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.
Alex
> So far my driver supports image writes, screen-to-screen copies,
> rectangle fills, solid and dashed lines, colour expansion and alpha
> textures. ARGB textures should work as well but I couldn't find a
> user for those - nothing in xfce4 or windowmaker seems to do anything
> with that.
> Another thing - I sprinkled xf86Msg()s all over XAA, sometimes
> XCopyArea() calls seem to end up writing to the framebuffer but not
> through xaaCopyArea() - any ideas?
Sorry, I'm not that familiar with XAA.
Alex
>
> have fun
> Michael
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.7 (Darwin)
>
> iQEVAwUBR89I6cpnzkX8Yg2nAQIkHAgAribd+WTw/t5Xv5nunNUZn6hrwluv+e7J
> ox9Hg9V/Yp2CVZVPgSc+3aJOjLPUTPg6L/4tVuNBQLSVnbMO2j7MdGLkhxGznGzl
> iv5NNqqToXDO2MM9ctBo8dNB1o3RU76dnbs4QomHYqi/HpNmG+JLJLu3L1+uNjoC
> cKjTsUEKWM/UgK+A2UMkjV9vpdEEYoYz2zRu6Njy3bfP7Jyoyh7mwl/c/kamWvU6
> k8KnHcRalgsXjmhNRGSV4VOmpc3c/JubHROYTrG5T61aNVge1GAi2jLl27I99vhR
> 0Bv8iA6juJ5KxZpUajbHSL5vXAZk/QaXss1g7AuVSGCphqE3IC/kHA==
> =wynV
> -END PGP SIGNATURE-
> ___
> 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: xaa vs. WriteImage()
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.
Alex
___
Devel mailing list
Devel@XFree86.Org
http://XFree86.Org/mailman/listinfo/devel
Re: X driver: Using offscreen memory manager for Xv
On Nov 26, 2007 8:08 PM, Bankim Bhavsar <[EMAIL PROTECTED]> wrote: > I'm implementing Xv extension of linux X driver. > > I need to use offscreen memory to allocate space for incoming video-frames. > Currently, I am using xf86InitFBManager() part of xf86fbman.h to > initialize offscreen memory by specifying a BoxPtr. The offscreen > memory is initialized such that it starts just after the on-screen > memory (using Frame Buffer Size). > > > When there is a ModeSwitch the Frame Buffer Size changes and the > offscreen memory previously allocated becomes a part of the on-screen > memory and causes X to crash. I was thinking of re-initalizing the > Offscreen memory manager on ModeSwitch and modify the previously > allocated pointers accordingly but I don't see a way to re-initialize > the offscreen memory. > > > One possible solution would be to leave some space before starting the > offscreen memory. That would work for common case but still doesn't > guarantee the framebuffer extending into the previously initialized > offscreen memory. > > > I also looked into EXA but doesn't seem to serve the purpose either. > > > Am I missing out on something? Any other possible solution? > Can someone point me to a driver that uses EXA and handles the offscreen > memory on ModeSwitch? I believe nv does this. 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: patches for Darwin /MacOSX
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 ___ 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/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/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: 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/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/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/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 t
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: >
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] 6
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: i945G 1280x768 sync polarity bug
On 6/12/06, Barry Scott <[EMAIL PROTECTED]> 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. > > I added debug messages to show the Flags used. And here is a section > of the log: > > (II) I810(0): Not using built-in mode "1280x1024" (height too large > for virtual size) > (II) I810(0): Not using built-in mode "1360x768" (width too large for > virtual size) > (II) I810(0): Increasing the scanline pitch to allow tiling mode (1280 > -> 2048). > (--) I810(0): Virtual size is 1280x768 (pitch 2048) > (**) I810(0): *Built-in mode "1280x768" > (**) I810(0): Built-in mode "1024x768" > (**) I810(0): Built-in mode "800x600" > (**) I810(0): Built-in mode "640x480" > (II) I810(0): Attempting to use 60.06Hz refresh for mode "1280x768" (85a) > (II) I810(0): I830SetModeParameters() Flags pMode->Flags 0x6 > block->Flags 0x4 > (II) I810(0): Attempting to use 75.08Hz refresh for mode "1024x768" (854) > (II) I810(0): I830SetModeParameters() Flags pMode->Flags 0x5 > block->Flags 0x0 > (II) I810(0): Attempting to use 75.00Hz refresh for mode "800x600" (852) > (II) I810(0): I830SetModeParameters() Flags pMode->Flags 0x5 > block->Flags 0x0 > (II) I810(0): Attempting to use 75.00Hz refresh for mode "640x480" (850) > (II) I810(0): I830SetModeParameters() Flags pMode->Flags 0xa > block->Flags 0xc > > This shows that the I830SetModeParameters() has the correct values in > but pMode-Flags > and block->Flags. > > I have also tested other modes as listed here > > ModeFlags Syncs on wire > 640x4800xC -hsync -vsync > 800x6000x0 +hsync +vsync > 1024x7680xC -hsync -vsync > 1280x1024 0x0 +hsync +vsync > 1280x7680x4 +hsync +vsync > > As you can see all the Syncs track the Flags except 1280x768. > > 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? > > Barry I've just noticed that the refresh rate is 52.73Hz not 60Hz as expected. Clearly the mode is not being honored. 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. Alex Barry ___ 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: 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: 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: 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: 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: 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: 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 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: External CRT works on 1024x768 but LCD not. Please Help!!!
On Fri, 18 Feb 2005 12:02:37 -0800, Bukie Mabayoje <[EMAIL PROTECTED]> wrote: > > > Alex Deucher wrote: > > > 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 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 > > > > > > > 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 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 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: x86 emulator bug
On Thu, 10 Feb 2005 10:08:20 -, Charles Dobson <[EMAIL PROTECTED]> wrote:
> I am not sure if I should post this here or on bugzilla.
post your patch in bugzilla.
Thanks,
Alex
>
> While trying to get a Silicon Motion SM722 video controller
> working with Solaris, I have discovered a problem with the
> emulation of the SHLD and SHRD (double precision shift)
> instructions of the x86 emulator.
> According to the Intel Pentium User Guide Vol 3, these
> instructions can shift upto 31 bits with both 16 and 32
> bit operands. The emulator code will only work with shifts
> of upto 15 bits for 16 bit operands.
>
> The file is
> xc/extras/x86emu/src/x86emu/prim_ops.c
>
> I have modified the two functions as below.
> I am not positive the flags are set correctly so
> would appreciated someone else to check these.
>
> u16 shld_word (u16 d, u16 fill, u8 s)
> {
> unsigned int cnt, res, cf;
>
> if (s < 32) {
> cnt = s % 32;
> if (cnt > 0) {
> if (cnt > 15) {
> res = (unsigned int)fill << (cnt - 16);
> if (cnt == 16)
> cf = d & 0x1;
> else
> cf = res & 0x1;
> }
> else {
> res = (d << cnt) | (fill >> (16-cnt));
> cf = d & (1 << (16 - cnt));
> }
> CONDITIONAL_SET_FLAG(cf, F_CF);
> CONDITIONAL_SET_FLAG((res & 0x) == 0, F_ZF);
> CONDITIONAL_SET_FLAG(res & 0x8000, F_SF);
> CONDITIONAL_SET_FLAG(PARITY(res & 0xff), F_PF);
> } else {
> res = d;
> }
> if (cnt == 1) {
> CONDITIONAL_SET_FLAGres & 0x8000) == 0x8000) ^
> (ACCESS_FLAG(F_CF) != 0)), F_OF);
> } else {
> CLEAR_FLAG(F_OF);
> }
> } else {
> res = 0;
> CONDITIONAL_SET_FLAG((d << (s-1)) & 0x8000, F_CF);
> CLEAR_FLAG(F_OF);
> CLEAR_FLAG(F_SF);
> SET_FLAG(F_PF);
> SET_FLAG(F_ZF);
> }
> return (u16)res;
> }
>
> u16 shrd_word (u16 d, u16 fill, u8 s)
> {
> unsigned int cnt, res, cf;
>
> if (s < 32) {
> cnt = s % 32;
> if (cnt > 0) {
> if (cnt > 15) {
> if (cnt == 16)
> cf = d & 0x8000;
> else
> cf = fill & (1 << (cnt - 17));
> res = fill >> (cnt - 16);
> } else {
> cf = d & (1 << (cnt - 1));
> res = (d >> cnt) | (fill << (16 - cnt));
> }
> CONDITIONAL_SET_FLAG(cf, F_CF);
> CONDITIONAL_SET_FLAG((res & 0x) == 0, F_ZF);
> CONDITIONAL_SET_FLAG(res & 0x8000, F_SF);
> CONDITIONAL_SET_FLAG(PARITY(res & 0xff), F_PF);
> } else {
> res = d;
> }
>
> if (cnt == 1) {
> CONDITIONAL_SET_FLAG(XOR2(res >> 14), F_OF);
> } else {
> CLEAR_FLAG(F_OF);
> }
> } else {
> res = 0;
> CLEAR_FLAG(F_CF);
> CLEAR_FLAG(F_OF);
> SET_FLAG(F_ZF);
> CLEAR_FLAG(F_SF);
> CLEAR_FLAG(F_PF);
> }
> return (u16)res;
> }
>
> Charles Dobson.
> Concurrent Technologies Plc.
>
> ___
> 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: DRM kernel source broken/incomplete
On Tue, 8 Feb 2005 18:40:07 -0500, David Dawes <[EMAIL PROTECTED]> wrote: > On Tue, Feb 08, 2005 at 11:24:43PM +, Alan Hourihane wrote: > >On Tue, Feb 08, 2005 at 06:17:50PM -0500, David Dawes wrote: > >> On Tue, Feb 08, 2005 at 05:12:29PM +, Alan Hourihane wrote: > >> >On Tue, Feb 08, 2005 at 11:59:15AM -0500, David Dawes wrote: > >> >> On Tue, Feb 08, 2005 at 04:40:42PM +, Alan Hourihane wrote: > >> >> >On Tue, Feb 08, 2005 at 11:32:56AM -0500, David Dawes wrote: > >> >> >> It looks like the DRM kernel source in xc/extras/drm is broken and > >> >> >> incomplete, especially for BSD platforms. The Linux version only > >> >> >> appears to build for a narrow range of kernels, and this either > >> >> >> needs to be fixed, or the minimum kernel requirements enforced in > >> >> >> the Makefile. > >> >> >> > >> >> >> Perhaps we'll have to roll back to an older version that does build? > >> >> > > >> >> >I suspect pulling in a newer snapshot would be better, although it's > >> >> >a little more complicated now because the drm has split out support > >> >> >for linux 2.4 and 2.6 kernels is separate subdirectories. > >> >> > >> >> Does the build automatically figure out which to use based on the > >> >> kernel version, and what range of kernels has it been verified on? > >> > > >> >No. > >> > >> Any imports/updates need to address our requirements in this regard. > > > >If we import the current DRM trunk code, there are three linux directories. > > > >1. linux for 2.4 kernels (monolithic) > >2. linux-2.6 for 2.6 kernels (monolithic) > >3. linux-core for 2.6 kernels with modular drm.ko and .ko > > > >and two for bsd > > > >1. bsd monolithic > >2. bsd-coremodular as above > > > >The -core are the new ones going forward and which I believe has been > >merged in linux 2.6.11. > > > >So, for now the linux-2.6, linux and bsd directories are the ones to stick > >with for stability. But things are changing. > > > >There'll be necessary build tweaks to select which directories are needed. > > At this point in our release cycle, the priorities are: > > 1st: It builds/runs and is reasonably stable on a good range of platforms. > 2nd: It supports as many DRI features as possible consistent with the >first priority. > > I don't think that even changing from the existing single Linux directory > to two different kernel-specific directories is appropriate at this point > in our release cycle. The time for such a change was before the feature > freeze. > > If what we have now is too broken to be fixed without major structural > changes, then it will need to be rolled back. why not just let the kernel provide the drm? Most if not all recent linux and bsd kernels (last few years) have drm support. The dri and ddx will adapt depending on what's available in the kernel. Alex > > David ___ 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: 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: 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 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
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: i855 crt out
Post you patches on either xfree86 or xorg bugzilla and we can take a look at integrating them. FWIW, the new intel DDX code drop in cvs includes full multi-head support. I'm not sure how that affects your patches. Alex On Sun, 25 Jul 2004 15:09:18 +0200, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi! > I'm the author of the little utility named i855crt. > It's basically a little 'userspace sub-driver' that works in cooperation with > X (and eventually the fb driver) to enable CRT out on Intel 855 laptop cards. > It includes also two little patches for X to enable hw cursor on the CRT and > to let the user choose to have xvideo on crt or LCD . > I'm interested in evaluating and discussing the possibility to have some sort > of integration with the X driver. Some people also asked me about it. > The driver can be found on sourceforge named i855crt. > It's released under GPL, i have no idea of what differ than X licence, since > i'm not experienced with legal stuff. > Anyway if someone is interested to discuss about it i will enjoy it. > I'm not subrisbed to the mailing list, so *please CC me*. > > Thanks, > Andrea Merello ___ 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: How the screen to be Rotate 90deg
check the xfree86 or xorg devel mailing lists. Someone posted a patch for i8xx rotation (no accel, using shadowfb). Alex On Wed, 14 Jul 2004 11:52:42 +0530, NaggarajaVignesh.R <[EMAIL PROTECTED]> wrote: > Hi > > Iam trying to Rotate the Screen 90 in Red Hat Linux 9.0 with System > Configuration intel 845 graphics card .The error msg is > > X Error of failed request: BadMatch (invalid parameter attributes) > Major opcode of failed request: 156 (RANDR) > Minor opcode of failed request: 2 (RRSetScreenConfig) > Serial number of failed request: 12 > Current serial number in output stream: 12 > > can any one help me . > > Thanks in advance > > regards > Vignesh > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://XFree86.Org/mailman/listinfo/devel > ___ 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 Sun, 13 Jun 2004 03:34:33 -0500, Ryan Underwood <[EMAIL PROTECTED]> wrote: > > > On Sat, Jun 12, 2004 at 12:11:48PM -0400, Alex Deucher wrote: > > > > I can help with the DVI stuff. I have a G550. > > What's the port configuration on it? I have a nagging curiosity that > the G450 may be able to swap the DAC<->connector mapping like the G550 > can. But it only seems that this swap would happen if: It's got a DVI port and a vga port and you can swap the port to crtc mapping. > > - you have a card with a DVI and an analog output > - you ignore the DVI connector and put an analog monitor on the analog > connector. if you only have one head connected, that port gets crtc1. > > Not a common scenario. I know a lot of G550's come with a DVI and an > analog connector, but I've never seen a G450 like that. (The G450 > manual claims that they exist., however.) > > Anyway, if I can find someone with a G450 with that configuration, and > your G550 has the same, then we could verify that the two chips do both > indeed have the capability to swap DACs. G400-DH definitely does not, > because the Maven chip's DAC is hardwired to the second port. > > The fact that you can change both the CRTC<->DAC mapping and the > DAC<->connector mappings is a little confusing to say the least but I > think I've got a handle on it. > > Something else I'm curious about is hooking up two DVI monitors to a > G450 or G550 using a dual DVI cable. I guess in that case the DacG and > MGA-TVO are ignored completely, so do these cards have two TMDS > transmitters (one for each monitor on the cable)? Or are the TMDS > chips internal to the dual digital cables? Is that even possible? I though matrox sold a special version of tha card with 2 dvi ports in order to do that. As far as I recall, the g550 only had 1 integrated tmds transmitter. the cards with 2 dvi ports probably had an external transmitter for the second port. Alex > > > > -- > Ryan Underwood, <[EMAIL PROTECTED]> > > > > signature.asc - 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. 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
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
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: > 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
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: 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=9900895891&r=1&w=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: 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: Xv colorkey with savage driver (Was: Re: [vdr] Re: [ANN] softdevice-0.0.5-xv-patch06.bz2)
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
___
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
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've checked the CVS, and found that the i810 driver up to 4_3_99_9 > works > after resume, but anything after 4_3_99_9 has the same problem of > displaying black screen after apm resume. > Can you narrow down the exact change that caused the problem? Alex > Is there anyone else having this problem? I'm running on IBM X30 > ThinkPad. > > > Thanks, > Jeff > > On Sat, 10 Apr 2004, Jeff Chua wrote: > > > > > still doesn't work. But why _old_ version works better than new > one? > > > > Usually newer version should works better, but in this case, it > looks like > > going one step back ... > > > > > > Thanks, > > Jeff > > [ [EMAIL PROTECTED] ] > > > > On Fri, 9 Apr 2004, Alex Deucher wrote: > > > > > --- 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! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html ___ 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- > MAbort- >SERR-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: [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: 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: 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
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: [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: [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: 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: 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
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: 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: Multiple Monitors
--- Ryan Underwood <[EMAIL PROTECTED]> wrote: > > On Tue, Mar 02, 2004 at 05:56:01AM -0800, Alex Deucher wrote: > > > 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. > > Yeah, I need to get back to that. I got sidetracked with studies and > the last weekend was eaten trying to beat some sense into the > rendition > driver. Did you ever get your G550? I have two systems now, one > with > DH G400 and one with SH G400 + a millenium II. So hopefully I can at > least verify that me stuff is working on at least one DH card and at > least one multi-mga configuration. Take your time. I'm in no hurry. I got my G550 back, but I've mostly been working on savage stuff so I haven't really played with mga much. Alex > > -- > Ryan Underwood, <[EMAIL PROTECTED]> > > ATTACHMENT part 2 application/pgp-signature name=signature.asc __ 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: 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
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
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 > Modes"1024x768" "800x600" "640x480" > EndSubSection > SubSection "Display" > Depth 24 > Modes"1024x768" "800x600" "640x480" > EndSubSection > EndSubSection > SubSection "Monitor1" > SubSection "Display" > Depth 16 > Modes"1024x768" "800x600" "640x480" > EndSubSection > SubSection "Display" > Depth 24 > Modes"1024x768" "800x600" "640x480" > EndSubSection > EndSubSection > EndSection > > Or, Option 2. > > Section "Screen" > Identifier "Screen0" > Device "Videocard0" > DefaultDepth 24 > SubSection "Monitor0" > Depth 16 > Modes"1024x768" "800x600" "640x480" > EndSubSection > SubSection "Monitor0" > Depth 24 > Modes"1024x768" "800x600" "640x480" > EndSubSection > SubSection "Monitor1" > Depth 24 > Modes"1024x768" "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
S3 Savage Duoview support - almost there
I've been trying to implement duoview support on savage mx/ix chips on and off for a while now. I've got some info on virge mx and for the most part it seems to apply to savage. There are two crtcs and two dot clocks and either of which can be used to control/drive either or both outputs, flatpanel or crt in this case. I've narrowed the problem down to the second crt controller. no matter which dot clock or output I use it with it, I get no signal. the monitor just goes into powersave mode on the crt port and the FP just blooms. I've verified that both dotclocks work and I can set them up correctly, but the second crtc just refuses to work. I've double checked with register dumps that both crtcs seem to be set up correctly, but only the first one works. CRTC DCLKOutput Result --- crtc1dclk1 FP/CRT/Both Works crtc1dclk2 FP/CRT/Both Works crtc2dclk1 FP/CRT/Both No signal crtc2dclk2 FP/CRT/Both No signal the crtc registers are paried and share the same vga cr io space, you can switch between them using one of the sr regs. Does anyone out there have any idea what I may be missing? maybe some crtc2 enable bit somewhere? You can see my source code and progress here: http://www.botchco.com/alex/new-savage/html/ Thanks, Alex __ 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
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
--- 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: 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: 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: 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: 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: 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: 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. > > [snip] I've opened a bug for this. Try one of the binaries or patches there. http://bugs.xfree86.org/show_bug.cgi?id=1161 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: 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
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
--- 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=linux&prodType=graphic&prod=productsLINUXdriver&submit.x=14&submit.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: 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: [Dri-devel] MGA font corruption revisited - now reproducible
--- Ryan Underwood <[EMAIL PROTECTED]> wrote: > > On Wed, Jan 21, 2004 at 01:08:10PM -0800, Alex Deucher wrote: > > > > > > - 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. > > It looks like G400 is a static mapping (CRTC2->DAC2) but it appears > some > strange things can be done with the G450/G550 i.e. to display > backend-scaler output on the second head. Also, the HAL seems to > support TV cables plugged into the first head and DVI into the > second, > which as far as I know would imply a CRTC swap; afaik CRTC1 can only > output DVI/analog and CRTC2 can only output TV or analog. (is this > right??) Sounds right, but your best bet it to ask Ville or Petr or on one of the directfb ML's as they are more familiar with the hardware. > > > > - 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. > > Okay, this is also something that matroxfb can do, so I suspect it > will > be related to shoving some registers at maven to get it working. > yeah the second dac and tv controller are integrated on the newer cards. > > > - 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. > > Looks like the DVI addon on G400 uses CRTC2 so it won't work at the > same > time with TV output. Still no idea about the G200. > > I noticed Matrox has a "single head to dual head" G450 upgrade that > involves a cable and entering a registration key into windows. > Hardware > crippled intentionally by software? Bah... > > -- > 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
