On Thu, 7 Jun 2001, Brian Paul wrote:
> Pontus Hedman wrote:
> >
> > > Either submit the patch here if it's small enough, or submit
> > > to patches on the DRI sourceforge page.
> >
> > Ok; it's a trivial one-liner to r128ConvertTexture32bpp.
> > See below.
> >
> > It's probably more of a work
Andrew James Richardson wrote:
> Brian,
>
>I thought that in the C specs you can't be guarenteed the order of
> evaluation in an if brace. Surely a safer bet is
>
> if(!image){
> if(!image->Data){
> ...
> }
> }
You're r
--- "R. Reucher" <[EMAIL PROTECTED]> wrote:
> Andrew James Richardson wrote:
>
> > Brian,
> >
> >I thought that in the C specs you can't be
> guarenteed the order of
> > evaluation in an if brace. Surely a safer bet is
> >
> > if(!image){
> > if(!image->Data){
> >
On Fri, 8 Jun 2001, Andrew James Richardson wrote:
>> > > > ---
>> > >if ( !image || !image->Data)
>> >
>
>Brian,
>
> I thought that in the C specs you can't be guarenteed the order of
>evaluation in an if brace. Surely a safer bet is
>
> if(!image){
>
On Fri, 8 Jun 2001, Joaquin Cuenca Abela wrote:
>> You're right here. But as as long as you only READ
>> it should make no
>> difference (IMHO)...
>
>if it's right, it makes a big difference. If you try:
>
>if (!image->Data || !image)
>
>the program will segfault trying to access the member
>Dat
On Fri, 8 Jun 2001, Mike A. Harris wrote:
> On Fri, 8 Jun 2001, Andrew James Richardson wrote:
>
> >> > >> > ---
> >> > >if ( !image || !image->Data)
> >> >
> >
> >Brian,
> >
> > I thought that in the C specs you can't be guarenteed the order of
> >evaluation in an if
On Fri, 8 Jun 2001, Andrew James Richardson wrote:
>> The original says "if a and b then c", while yours says:
>>
>> "if a and b then c"
>>
>> Your multiple if block is syntactically equivalent to
>>
>> if ( !image && !image->Data)
>>
>> Notice the flipping of || to && from the original example.
> Brian,
>
>I thought that in the C specs you can't be guarenteed the order of
> evaluation in an if brace. Surely a safer bet is
>
> if(!image){
> if(!image->Data){
> ...
> }
> }
Order of operations is actually guaranteed in this case. See
http://www.faqs.org/faqs/C-faq/faq/ (item 3.5).
You
Just wondering if anyone else saw something like this unresolved symbol
in their X11 logs:
(II) TDFX(0): Primary V_BIOS segment is: 0xc000
(II) TDFX(0): VESA BIOS detected
(II) TDFX(0): VESA VBE DDC supported
Symbol DRIMoveBuffersHelper from module /usr/X11R6/lib/modules/drivers/tdfx_drv.o
is u
[EMAIL PROTECTED] wrote:
>
> Just wondering if anyone else saw something like this unresolved symbol
> in their X11 logs:
>
> (II) TDFX(0): Primary V_BIOS segment is: 0xc000
> (II) TDFX(0): VESA BIOS detected
> (II) TDFX(0): VESA VBE DDC supported
> Symbol DRIMoveBuffersHelper from module /usr/X
Sounds like you haven't updated all your modules to 4.1.0.
Alan.
On Fri, Jun 08, 2001 at 08:39:00AM -0500, [EMAIL PROTECTED] wrote:
> Just wondering if anyone else saw something like this unresolved symbol
> in their X11 logs:
>
> (II) TDFX(0): Primary V_BIOS segment is: 0xc000
> (II) TDFX(0):
> From: zifnab <[EMAIL PROTECTED]>
> I am running CVS from Tuesday and I was playing Tribes 2 with no problem.
> Then I came back a few hours later and started it up again. It took quite
> a while to start up (at first I thought X had crashed but then Tribes
> finally started). When I started
At Fri, 08 Jun 2001 07:04:31 -0600, Brian Paul <[EMAIL PROTECTED]> wrote:
>
>[EMAIL PROTECTED] wrote:
>>
>> Just wondering if anyone else saw something like this unresolved symbol
>> in their X11 logs:
>>
>> (II) TDFX(0): Primary V_BIOS segment is: 0xc000
>> (II) TDFX(0): VESA BIOS detected
>>
I don't want to beat it to death, but following the "Announcement" sparked
discussion I wanted to mention my take:
One of my problems (time being the biggest one of course :) with getting
involved with the code-part of the DRI project was the developer documentation.
I am greatful for having
The documentation makes a good base and is mostly still correct. The
problem is that this stuff is growing very quickly. For example, we've
come up with fairly standardized ways of writing a device driver. From
an architectural point of view it's still just a device driver, but from
an implementat
On 07 Jun 2001 17:26:07 -0600, zifnab wrote:
> No I will next time. I'm also using a Radeon 64DDR on a TBird 900 (VIA
> KT-133) if that makes any difference.
Hm. I and a few others have been having problems with the 64DDR,
although much more extreme than yours. It seems that the problems are
AM
[EMAIL PROTECTED] wrote:
>
> At Fri, 08 Jun 2001 07:04:31 -0600, Brian Paul <[EMAIL PROTECTED]> wrote:
>
> >
> >[EMAIL PROTECTED] wrote:
> >>
> >> Just wondering if anyone else saw something like this unresolved symbol
> >> in their X11 logs:
> >>
> >> (II) TDFX(0): Primary V_BIOS segment is: 0x
On Fri, Jun 08, 2001 at 04:30:05PM -0400, Vladimir Vukicevic wrote:
> > No I will next time. I'm also using a Radeon 64DDR on a TBird 900 (VIA
> > KT-133) if that makes any difference.
>
> Hm. I and a few others have been having problems with the 64DDR,
> although much more extreme than yours.
Joseph Carter <[EMAIL PROTECTED]> writes:
> On Fri, Jun 08, 2001 at 04:30:05PM -0400, Vladimir Vukicevic wrote:
> > > No I will next time. I'm also using a Radeon 64DDR on a TBird 900 (VIA
> > > KT-133) if that makes any difference.
> >
> > Hm. I and a few others have been having problems with
Alan Cox posted this on the kernel list. Matrox should fix this in their
driver.
- |Daryll
> [BUG] ouch x 2: no check either way.
>
>/u2/engler/mc/oses/linux/2.4.5-ac8/drivers/char/drm/mga_state.c:835:mga_iload:+ERROR:RANGE:827:835:
> Using user
On Fri, Jun 08, 2001 at 05:10:56PM -0400, Trond Eivind Glomsrød wrote:
> > They extend beyond that. VIA KT133A-based Abit KT7A (friend has KT7-RAID
> > which is KT133 based and has the same problem..) 30 seconds or so after
> > we start any serious 3D app, down goes the entire box.
>
> FTR, I'v
Joseph Carter <[EMAIL PROTECTED]> writes:
> On Fri, Jun 08, 2001 at 05:10:56PM -0400, Trond Eivind Glomsrød wrote:
> > > They extend beyond that. VIA KT133A-based Abit KT7A (friend has KT7-RAID
> > > which is KT133 based and has the same problem..) 30 seconds or so after
> > > we start any seri
Hi,
Does the mga driver support the -HSync -VSync options?
If I compare mga_dac3026.c and mga_dacG.c, I see the former does some
stuff to the RAMDAC to set sync polarity, but I don't see any of that in
the latter.
I'm trying to output PAL-rate interlaced video. But my TV won't
sync. Don't hav
Trond Eivind Glomsrød wrote:
>
> Joseph Carter <[EMAIL PROTECTED]> writes:
>
> > They extend beyond that. VIA KT133A-based Abit KT7A (friend has KT7-RAID
> > which is KT133 based and has the same problem..) 30 seconds or so after
> > we start any serious 3D app, down goes the entire box.
>
>
>
>I thought that in the C specs you can't be guarenteed the order of
> evaluation in an if brace. Surely a safer bet is
>
> if(!image){
> if(!image->Data){
> ...
> }
> }
>
> If you know better I stand corrected, I'm just think
On Fri, Jun 08, 2001 at 03:01:03AM -0700, Joaquin Cuenca Abela wrote:
>
> --- "R. Reucher" <[EMAIL PROTECTED]> wrote:
> > Andrew James Richardson wrote:
> >
> > > Brian,
> > >
> > >I thought that in the C specs you can't be
> > guarenteed the order of
> > > evaluation in an if brace. Surely
On Fri, Jun 08, 2001 at 02:08:29PM -0700, Joseph Carter wrote:
> On Fri, Jun 08, 2001 at 04:30:05PM -0400, Vladimir Vukicevic wrote:
> > > No I will next time. I'm also using a Radeon 64DDR on a TBird 900 (VIA
> > > KT-133) if that makes any difference.
> >
> > Hm. I and a few others have been h
On Sat, Jun 09, 2001 at 09:10:13AM +1000, Gareth Hughes wrote:
> Trond Eivind Glomsr?d wrote:
> >
> > Joseph Carter <[EMAIL PROTECTED]> writes:
> >
> > > They extend beyond that. VIA KT133A-based Abit KT7A (friend has KT7-RAID
> > > which is KT133 based and has the same problem..) 30 seconds o
28 matches
Mail list logo
