not work in YPbPr mode.
--- Alex Deucher <[EMAIL PROTECTED]> wrote:
> On 8/6/05, Steven Newbury <[EMAIL PROTECTED]> wrote:
> > --- Alex Deucher <[EMAIL PROTECTED]> wrote:
> >
> > > Not really. Ati hasn't released any information about setting
--- Alex Deucher <[EMAIL PROTECTED]> wrote:
> Not really. Ati hasn't released any information about setting up the
> chip for component output. Perhaps you can dump the radeon registers
> in windows and compare how that driver sets things up, or perhaps the
> fglrx driver supports component out
Thanks for the quick reply.
--- Alex Deucher <[EMAIL PROTECTED]> wrote:
> On 8/5/05, Steven Newbury <[EMAIL PROTECTED]> wrote:
> >
> > --- Alex Deucher <[EMAIL PROTECTED]> wrote:
> >
> > > You may also want to take a look at my unfinished radeon
--- Alex Deucher <[EMAIL PROTECTED]> wrote:
> You may also want to take a look at my unfinished radeon tv-out patch:
>
> http://www.botchco.com/alex/xorg/radeon_tvout.c
> http://www.botchco.com/alex/xorg/radeon_tvout.h
> http://www.botchco.com/alex/xorg/radeon_tvout.diff
>
> one of the regs (DA
Okay. Thanks, I'll take a look. Unfortuneately I've only got net access on my
mobile phone at the moment. It won't be until next week that I can
realistically have a go, but I'll post any progress. If I can't get it to
work, I'll install Windows and try to get a register dump with it working. Is
t
--- [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
=?iso-8859-1?B?SSByZWFsaXNlIHRoaXMgaXMgc2xpZ2h0bHkgb2ZmIHRvcGljLCBidXQgSSBmaWd1cmVkIG91dHNpZGUgb2YgQVRJIEknZCBtb3N0DQ==?=
>
=?iso-8859-1?B?bGlrZWx5IGZpbmQgc29tZW9uZSBoZXJlIHdobyBrbm93cy4gSSd2ZSByZWFkIHRoYXQgdGhlIFdpbmRvd3MgZHJpdmVyIGFsbG93cw0=?=
>
--- Steven Newbury <[EMAIL PROTECTED]> wrote:
> --- Adam Jackson <[EMAIL PROTECTED]> wrote:
>
> > On Wednesday 18 May 2005 23:53, Michel Dänzer wrote:
> > > On Wed, 2005-05-18 at 22:47 +0100, Steven Newbury wrote:
> > > > 1) When I move a window over
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-05-18 at 22:47 +0100, Steven Newbury wrote:
> > 4) UseFBDev results in the following error and failed initialisation:
> > (EE) RADEON(0): FBIOPUT_VSCREENINFO: Invalid argument
>
> Either you aren't
--- Adam Jackson <[EMAIL PROTECTED]> wrote:
> On Wednesday 18 May 2005 23:53, Michel Dänzer wrote:
> > On Wed, 2005-05-18 at 22:47 +0100, Steven Newbury wrote:
> > > 1) When I move a window over a 3D rendering window the contents jumps to
> > > the top left han
Issues with the current Mesa CVS r200 driver (current CVS xorg, Linus' 'git'
kernel and CVS DRM ):
1) When I move a window over a 3D rendering window the contents jumps to the
top left hand part of the display. If I move the output (say the glxgears)
window to the top left I see the output centre
er. The glibc lib is compiled
multiple times with support for tls and architecture optimisations
(usually i686), no support for tls but with architecture optimisations,
and for i386 (ie no optimisations).
I suspect the libGL is explicitly loading TLS libraries rathe
It seems the /tmp filesystem is full on the CVS server.
[EMAIL PROTECTED] dri-trunk]$ cvs update -dP
cannot mkdir /tmp/cvs-serv6716/lib/lbxutil
No space left on device
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
h
On Thu, 2003-08-14 at 19:06, Alex Deucher wrote:
> I haven't tried multiple radeon cards, but I seem to recall several
> people having this problem right around when 4.3.0 was released. I
> don't think a "proper" fix ever went in and I think the issue was to be
> revisited later. I don't know if
Keith Whitwell wrote:
Linus Torvalds wrote:
On Sat, 22 Feb 2003, Keith Whitwell wrote:
What about processes that *don't* do a close - that just use an fd
and exit.
The exit does a close, and you'll see a flush() from the dying process
(and a release() if that was the last user).
In the threa
A short cut to this whole thing would be to work on getting a second
head supported on a single X11 screen. Then 3D comes for free:
http://www.tungstengraphics.com/dri/Simple_Xinerama_DH.txt
This solution provides Xinerama functionality without actually using the
Xinerama wrapper.
Wouldn't
Dieter Nützel wrote:
Grepped latest stuff but multiple threads/apps do not work reliable.
Try 2 times "ipers" => X server locks up (hard).
First system run (?) but after SYSRQ+'K' hard hang.
SYSRQ+'S|U' works sometimes but after that SYSRQ+'B' do not ;-(
I do not belive that even Viewperf-6.1.2/
Leif Delgass wrote:
I've opened a new mach64 branch (mach64-0-0-6-branch), which has now been
updated from the current DRI trunk with X 4.2.99.2 and Mesa 5.x. I've
updated the mach64 driver to Mesa 5 based on the changes to the Rage 128
driver. Testing hasn't shown any problems so far.
I haven'
There has been a problem with DRI CVS trunk with Radeon r200 for some
time w.r.t restarting the graphics engines of various games. I don't
know if this is also the case for other chipsets but suspect that it is
not, otherwise it would have been fixed?
In quake3 based games, vid_restart causes
Ian Romanick wrote:
On Tue, Dec 10, 2002 at 05:14:37PM +, Steven Newbury wrote:
I have got DRI running with Dual Screens with DRI working on display
:0.0 and Indirect rendering on :0.1.
If I attempt to enable DRI on the second screen if fails to open
/dev/dri/card0 because it is busy
I have got DRI running with Dual Screens with DRI working on display
:0.0 and Indirect rendering on :0.1.
If I attempt to enable DRI on the second screen if fails to open
/dev/dri/card0 because it is busy. It is ready used for the first
screen. On failing to access the device DRI is then disa
Ian Molton wrote:
How does one check out the DRI project?
assume there is no existing X at all.
can it be done?
Just check it out, it is a trimmed down tree containing all you need to
compile server,libs and drivers only. If you want the rest of the
4.2.99.x distribution you will have t
I would like to get my dual-head setup working with my Radeon 8500. I
noticed that the current CVS r200 driver disables DRI if dual-head is
enabled. Looking at the source it states the reason is due to
syncronisation issues with xinerama, however since xinerama isn't the
only way to do dual-h
L_DEBUG enabled but it doesn't report anything out of the
ordinary.
I will next try a debug build of X and try to track this down, however I do
not fully understand the full workings of the code yet...
--
Steven Newbury [EMAIL PROTECTED]
___
Dr
L_DEBUG enabled but it doesn't report anything out of the
ordinary.
I will next try a debug build of X and try to track this down, however I do
not fully understand the full workings of the code yet...
--
Steven Newbury [EMAIL PROTECTED]
___
Dr
L_DEBUG enabled but it doesn't report anything out of the
ordinary.
I will next try a debug build of X and try to track this down, however I do
not fully understand the full workings of the code yet...
--
Steven Newbury [EMAIL PROTECTED]
___
Dr
L_DEBUG enabled but it doesn't report anything out of the
ordinary.
I will next try a debug build of X and try to track this down, however I do
not fully understand the full workings of the code yet...
--
Steven Newbury [EMAIL PROTECTED]
___
Dr
L_DEBUG enabled but it doesn't report anything out of the
ordinary.
I will next try a debug build of X and try to track this down, however I do
not fully understand the full workings of the code yet...
--
Steven Newbury [EMAIL PROTECTED]
___
Dr
At 19:19 26/05/2001 +0100, Steven Newbury wrote:
>On Saturday 26 May 2001 18:11, ralf willenbacher wrote:
>> Steven Newbury wrote:
>> > On Friday 25 May 2001 01:22, ralf willenbacher wrote:
>> It starts up fine but seems to only have a couple of Mb of
>>
>>
At 10:37 31/05/2001 -0400, Mark Crichton wrote:
>Hello,
>
>I've been mucking around in the mesa-3-5 DRI branch, and was wondering
>if I should be reporting bugs (and fixes) for it?
>
>I've found some issues in lib/GL/mesa/src/drv/mga/mgatris.c w.r.t. some
>of the inline assembly (newer gcc's will
On Saturday 26 May 2001 18:11, ralf willenbacher wrote:
> Steven Newbury wrote:
> > On Friday 25 May 2001 01:22, ralf willenbacher wrote:
> > > thanks for trying it out.
> > > i fixed a typo (again)..
> >
> >
> > In your patch you changed 't
On Friday 25 May 2001 01:22, ralf willenbacher wrote:
> thanks for trying it out.
> i fixed a typo (again)..
In your patch you changed 'totalcard = b->size' and 'totalagp=b->size' to
'totalcard += b->size' and 'totalagp += b->size' in
xc/lib/GL/mesa/src/drv/mga/mgatexmem.c. This change stop
On Thursday 24 May 2001 04:59, Steven Newbury wrote:
> >Aaron Holtzman wrote:
> >> It would seem that Gareth Hughes ([EMAIL PROTECTED]) said:
> >> > At no time has the Matrox DRI driver used AGP memory for textures.
> >>
> >> Can you give us a qu
>Aaron Holtzman wrote:
>>
>> It would seem that Gareth Hughes ([EMAIL PROTECTED]) said:
>> > At no time has the Matrox DRI driver used AGP memory for textures.
>>
>> Can you give us a quick outline of the work required to make this
>> happen?
>>
>> cheers,
>> aaron
>>
>
>well.. i tried but cou
At 13:36 29/03/2001 +, Karl Lessard wrote:
>Hi,
>
>Starting gears under XFree86 4.0.3-3 with DRI enabled freeze my system.
>It seems to happened when the app needs to render back its content from
>a passive state (as a example, when I drag another window to entirely
>cover it, and move it b
At 19:13 27/03/2001 +1000, Gareth Hughes wrote:
>I've looked into the 'making clean in /usr/local' build problem. Here's
>the lowdown:
>
>Despite what Keith P's HOWTO says, you can't just add this to your
>host.def:
>
> #define Freetype2Dir/usr/local
>
>By default, our h
35 matches
Mail list logo
