On Thu, Feb 27, 2003 at 02:01:22PM -0800, Jon Smirl wrote:
--- Sven Luther [EMAIL PROTECTED] wrote:
Notice that the DRI drivers don't do anything like
mode setting and
such, they depend on the X drivers for that. So if
you take away the X
driver, you will not be able to get anything
On Fri, 28 Feb 2003 04:39:58 +0100
Bernhard Kaindl [EMAIL PROTECTED] wrote:
On Thu, 27 Feb 2003, Jon Smirl wrote:
Long ago I loved the command line. I was an expert at
it. When Window 1.0 came out I got my first exposure
to a mouse. For about a year I wouldn't get one, but
now I can't
Hello!
I've met this problem (see attach) a long ago but it seems
that nobody fixed that :(
This problem happens not only with this game but with quake3 too!
It looks like every odd frame contains these black squares but every
even frame is free from them that causes image flickering!
These
On Thu, Feb 27, 2003 at 06:04:36PM -0800, Jon Smirl wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
Let's see, XFree86 supports 2D for about 50
different chips, and it
supports 3D for about 5. MS might be in a position
to cast way support
for older hardware, but I don't think that
Nick Kurshev [EMAIL PROTECTED] wrote:
Image distortion became visible in oct 2002.
This probably was the time when hardware-TCL came into play !?
You could try to set $RADEON_TCL_FORCE_DISABLE to 't' and see if it makes
any difference,
Martin.
--
Unix _IS_ user friendly - it's just selective
On Fri, 2003-02-28 at 08:25, Sven Luther wrote:
Also, before you speak about unifying the 2D and 3D drivers
you need to look at how a 3D desktop would work.
I would assume roughly like the Apple renders seem to work now, or how
the opengl accelerated canvas works in E. That bit is hardly rocket
On Fri, Feb 28, 2003 at 01:14:09PM +, Alan Cox wrote:
On Fri, 2003-02-28 at 08:25, Sven Luther wrote:
Also, before you speak about unifying the 2D and 3D drivers
you need to look at how a 3D desktop would work.
I would assume roughly like the Apple renders seem to work now, or how
the
On 28 Feb 2003 12:00:48 GMT
Martin Spott [EMAIL PROTECTED] wrote:
Nick Kurshev [EMAIL PROTECTED] wrote:
Image distortion became visible in oct 2002.
This probably was the time when hardware-TCL came into play !?
You could try to set $RADEON_TCL_FORCE_DISABLE to 't' and see if it makes
On Fri, 2003-02-28 at 12:19, Sven Luther wrote:
So, No 2D windows on the face of rotating cubes ?
Once your 2D windows are textures the rest is very much free, including
scaling, rotation occlusion and alpha blending. You can use it to build
the base X interfaces then worry about exposing the
On Fre, 2003-02-28 at 13:30, Felix Kühling wrote:
On 28 Feb 2003 12:00:48 GMT
Martin Spott [EMAIL PROTECTED] wrote:
Nick Kurshev [EMAIL PROTECTED] wrote:
Image distortion became visible in oct 2002.
This probably was the time when hardware-TCL came into play !?
You could try to
On Don, 2003-02-27 at 23:01, Jon Smirl wrote:
-- Sven Luther [EMAIL PROTECTED] wrote:
Notice that the DRI drivers don't do anything like
mode setting and
such, they depend on the X drivers for that. So if
you take away the X
driver, you will not be able to get anything
outputed on
On 28 Feb 2003 14:02:14 +0100
Michel Dänzer [EMAIL PROTECTED] wrote:
On Fre, 2003-02-28 at 13:30, Felix Kühling wrote:
On 28 Feb 2003 12:00:48 GMT
Martin Spott [EMAIL PROTECTED] wrote:
Nick Kurshev [EMAIL PROTECTED] wrote:
Image distortion became visible in oct 2002.
Am Freitag, 28. Februar 2003 14:18 schrieb Felix Kühling:
On 28 Feb 2003 14:02:14 +0100
Michel Dänzer [EMAIL PROTECTED] wrote:
On Fre, 2003-02-28 at 13:30, Felix Kühling wrote:
On 28 Feb 2003 12:00:48 GMT
Martin Spott [EMAIL PROTECTED] wrote:
Nick Kurshev [EMAIL PROTECTED] wrote:
On Don, 2003-02-27 at 20:52, Martin Spott wrote:
Michel D?nzer [EMAIL PROTECTED] wrote:
The radeon driver uses the DRM for 2D acceleration when DRI is enabled,
Is the radeon driver the only one doing so ?
I think all drivers supporting the DRI have to deal with 2D and 3D
concurrency one
On Fre, 2003-02-28 at 10:11, Felix Kühling wrote:
I think this discussion is getting off track. We have to make clear what
we are talking about here. From the first mail on this subject I got the
impression, the goal was
- to implement accelerated 2D primitives using the 3D graphics
It's me Jennifer, I just wanted to send you that pic you asked for the other
day. Click
Here to catch me on my webcam & see more pics of me.
- xoxo Jennifer
áË ë^¨¥Ë)¢{(ç[É8bAzEÊÚ yé!y«Þm§ÿí)äç¤r¿±ðëׯzYX§X¬´:âuëÞX¬¶Ë(º· ~àzwÛi³ÿåËl²«qç讧zßåËlþX¬¶)ߣ÷kׯz
On Thu, 27 Feb 2003 18:17:33 -0800
Allen Akin [EMAIL PROTECTED] wrote:
Then there are the arguments for deeper color channels based on the
need for higher-precision intermediate results -- for transparency,
antialiasing, multipass rendering, etc.
On Thu, 27 Feb 2003 17:20:19 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
64-bpp or 128-bpp isn't useful for display, but
is useful.
Since you're talking intermediate, yes, agreed.
---
This sf.net email is sponsored by:ThinkGeek
Welcome to
--- Michel Dänzer [EMAIL PROTECTED] wrote:
It would be simple to lift the mode setting and
hardware identification code out of the fb drivers
But what would be the advantage over leaving it as a
framebuffer device
or whatever in the first place?
The X philosophy is to ship a
On Fri, Feb 28, 2003 at 03:04:08PM +, Ian Molton wrote:
| On Thu, 27 Feb 2003 18:17:33 -0800
| Allen Akin [EMAIL PROTECTED] wrote:
|
|
| Then there are the arguments for deeper color channels based on the
| need for higher-precision intermediate results -- for transparency,
|
On Fri, Feb 28, 2003 at 09:25:56AM +0100, Sven Luther wrote:
| On Thu, Feb 27, 2003 at 02:01:22PM -0800, Jon Smirl wrote:
|... Moore's law
| means that everyone is going to have super 3D hardware
| in a couple of years.
|
| Even Embeded or handheld
Dear Homeowner,
Interest Rates are at their lowest point in 40 years! We help you find the
best rate for your situation by matching your needs with hundreds of
lenders!
Home Improvement, Refinance, Second Mortgage,
Home Equity Loans, and much, much more!
You're eligible even with less than
On Fri, Feb 28, 2003 at 03:29:51PM +0100, Michel Dänzer wrote:
On Fre, 2003-02-28 at 10:11, Felix Kühling wrote:
I think this discussion is getting off track. We have to make clear what
we are talking about here. From the first mail on this subject I got the
impression, the goal was
It is a fact that Microsoft Longhorn and the Mac GUI
are moving towards 3D hardware for their base GUI. It
is also a fact that it will take a lot of effort and
probably several years to move X in the same
direction. Personally I don't want to see Linux in the
position of having the new 3D effects
So what is the best design for achieving this? The
project has to have DRI at it's core since it's the
only choice for 3D acceleration on Linux.
Ironically, the only real choice for 3D acceleration on Linux is using
NVIDIA and ATI's (non DRI) binary drivers.
Does DRI have a future with
--- Daniel Vogel [EMAIL PROTECTED] wrote:
Does DRI have a future with neither NVIDIA nor ATI
participating?
I really don't understand ATI's position on Linux
drivers. They have better hardware but they are losing
because of their drivers. I can't think of a better
solution than having a couple
On Fri, 28 Feb 2003, Jon Smirl wrote:
Does DRI have a future with neither NVIDIA nor ATI
participating?
I really don't understand ATI's position on Linux
drivers. They have better hardware but they are losing
because of their drivers. I can't think of a better
solution than having a couple
Hi all, I want to know where I can fine The texmem trunk of DRI,
possibly in debian packages. And if there aren't debian packages the
other ways ;-) .
Anyone can tell me the known bugs that actually these drivers have?
Thanks
Bye
---
Jon Smirl wrote:
I really don't understand ATI's position on Linux
drivers. They have better hardware but they are losing
because of their drivers. I can't think of a better
solution than having a couple hundred highly skilled,
performance obsessed, unpaid hackers fixing their code
for
--- Mike A. Harris [EMAIL PROTECTED] wrote:
On Fri, 28 Feb 2003, Jon Smirl wrote:
I don't see 100 unpaid hackers hacking feverishly on
anything X
Obviously you wouldn't see 100 people working full
time but you might get detailed bug reports or patches
from 100 people. I know I get patches
On Fri, 28 Feb 2003 10:03:10 -0800 (PST)
Jon Smirl [EMAIL PROTECTED] wrote:
It is a fact that Microsoft Longhorn and the Mac GUI
are moving towards 3D hardware for their base GUI. It
is also a fact that it will take a lot of effort and
probably several years to move X in the same
direction.
Does DRI have a future with neither NVIDIA nor ATI participating?
Are people actually talking to them about why they don't use it and
what has to be done to remedy this fact? Shouldn't this be a top priority?
To clarify: I meant what has to be done to make DRI (direct rendering
On Fri, Feb 28, 2003 at 03:00:03PM -0500, Daniel Vogel wrote:
So what is the best design for achieving this? The
project has to have DRI at it's core since it's the
only choice for 3D acceleration on Linux.
Ironically, the only real choice for 3D acceleration on Linux is using
NVIDIA and
On Fri, 28 Feb 2003, Daniel Vogel wrote:
Does DRI have a future with neither NVIDIA nor ATI participating?
Are people actually talking to them about why they don't use it and
what has to be done to remedy this fact? Shouldn't this be a top priority?
To clarify: I meant what has to be
Hello,
I just started working on a revision of the DRI Configuration design doc
based on the feedback I received. As Brian suggested I want to implement
the functionality for acquiring available configuration options in
libGL. I had a look at xc/lib/GL/dri and it looks as if dri_glx.[ch]
would be
On Fri, Feb 28, 2003 at 09:45:26PM +, José Fonseca wrote:
Even if DRI stops being the main source of 3D drivers for Linux/BSD, it
will remain to be the main source of _open_source_ 3D drivers. That,
alone, gives DRI a competitive advantage over any other solution. Just
in the same way
On Fri, Feb 28, 2003 at 05:06:15PM +0100, Michel Dänzer wrote:
I haven't look at this but if the DRM modules know
about setting up the hardware and changing resolutions
then there may be no need for framebuffer any more.
You could write a generic framebuffer driver that was
implemented
My point was/is that without NVIDIA or ATI using the DRI
infrastructure it is doomed to fail.
Uhmmm... ATI *does* use the DRI infrastructure for their drivers.
Googled for it a while but couldn't find any hints that they do so I assumed
they don't. Thanks for the clarification.
So, are
Now that XFree86 4.3.0 is tagged/released, is there a plan for merging
4.3.0 into the DRI trunk?
--
Leif Delgass
http://www.retinalburn.net
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
On Fri, 28 Feb 2003, Daniel Vogel wrote:
Does DRI have a future with neither NVIDIA nor ATI participating?
Are people actually talking to them about why they don't use it and
what has to be done to remedy this fact? Shouldn't this be a top priority?
To clarify: I meant what has to be done to
Well... for starters ATI *is* using the DRI infrastructure.
Does that mean that you think DRI is doomed to success now?
I guess it means that it's at least not fundamentaly flawed ;-)
Fragmention still isn't good, which brings me back to my original question
whether folks are talking to
On Fre, 2003-02-28 at 23:11, Philip Brown wrote:
On Fri, Feb 28, 2003 at 05:06:15PM +0100, Michel Dänzer wrote:
I haven't look at this but if the DRM modules know
about setting up the hardware and changing resolutions
then there may be no need for framebuffer any more.
You could write
On Fri, Feb 28, 2003 at 05:15:58PM -0500, Daniel Vogel wrote:
So, are there technical reasons for NVIDIA not to use the DRI if ATI does?
yes.
NVIDIA already has their own cross-platform low level driver, with a
cross-platform 3d API. It's their UDI, Unified Driver Interface,
or something
On Fri, 28 Feb 2003, Jon Smirl wrote:
I don't see 100 unpaid hackers hacking feverishly on
anything X
Obviously you wouldn't see 100 people working full
time
Obviously. Not even part time. I doubt you'd see more than
20-30 people working on it at all. And by that I mean making
any
On Fri, Feb 28, 2003 at 05:33:29PM -0500, Daniel Vogel wrote:
Fragmention still isn't good, which brings me back to my original question
whether folks are talking to NVIDIA why they aren't using the DRI framework.
Probably because of theirs UDA? I suspect it is easear to support 'more'
common
NVidia wanted to keep the source code base of the Windows drivers and the
Linux drivers as close as possible, including what would be considered
kernel mode stuff. They started with windows drivers and adapted that to
linux. Part of their porting effort was bulding a kernel level wrapper,
which
On Fre, 2003-02-28 at 19:03, Jon Smirl wrote:
It is a fact that Microsoft Longhorn and the Mac GUI
are moving towards 3D hardware for their base GUI. It
is also a fact that it will take a lot of effort and
probably several years to move X in the same
direction. Personally I don't want to see
Felix Kühling wrote:
Hello,
I just started working on a revision of the DRI Configuration design doc
based on the feedback I received. As Brian suggested I want to implement
the functionality for acquiring available configuration options in
libGL. I had a look at xc/lib/GL/dri and it looks as if
NVidia wanted to keep the source code base of the Windows drivers and the
Linux drivers as close as possible, including what would be considered
kernel mode stuff. They started with windows drivers and adapted that to
linux. Part of their porting effort was bulding a kernel level wrapper,
On Fri, 28 Feb 2003, Daniel Vogel wrote:
Fragmention still isn't good, which brings me back to my
original question whether folks are talking to NVIDIA why they
aren't using the DRI framework.
I'm sure if Nvidia wanted to use DRI they would do so. What
benefit would there be to Nvidia really of
On Fre, 2003-02-28 at 21:51, AnonimoVeneziano wrote:
Hi all, I want to know where I can fine The texmem trunk of DRI,
possibly in debian packages. And if there aren't debian packages the
other ways ;-) .
I'm not aware of any Debian packages of the texmem branch, I spend quite
some time
On Fri, 28 Feb 2003 15:56:41 -0500 (EST)
Mike A. Harris [EMAIL PROTECTED] wrote:
I don't see 100 unpaid hackers hacking feverishly on anything X
related right now. Why would 100 unpaid hackers come out of the
woodwork all of a sudden? Quite unrealistic.
If you stood a chance in hell of
--- Mike A. Harris [EMAIL PROTECTED] wrote:
I don't see 100 unpaid hackers hacking feverishly
Since you have the specs, tell me how to reset a
Rage128 from protected mode so that I can add it to
the framebuffer driver.
I know about going into real mode and calling C000:3.
This can't be done
Title: AD 3
IT'S NEVER BEEN EASIER TO ORDER YOUR PRESCRIPTIONS ONLINE
We are the largest U.S. Company specializing in Prescriptions for VIAGRA & other FDA approved medications.
Order from the comfort of your own home
** Free
On Fri, 28 Feb 2003 14:57:35 -0800
Philip Brown [EMAIL PROTECTED] wrote:
On Fri, Feb 28, 2003 at 05:15:58PM -0500, Daniel Vogel wrote:
So, are there technical reasons for NVIDIA not to use the DRI if ATI does?
yes.
NVIDIA already has their own cross-platform low level driver, with
Ct0I6f
Felix Kühling wrote:
Hello,
I just started working on a revision of the DRI Configuration design doc
based on the feedback I received. As Brian suggested I want to implement
the functionality for acquiring available configuration options in
libGL. I had a look at xc/lib/GL/dri and it looks as if
Daniel Vogel wrote:
Does DRI have a future with neither NVIDIA nor ATI participating?
Are people actually talking to them about why they don't use it and
what has to be done to remedy this fact? Shouldn't this be a top priority?
To clarify: I meant what has to be done to make DRI (direct rendering
On Fri, Feb 28, 2003 at 10:29:04PM -0800, Ian Romanick wrote:
Daniel Vogel wrote:
Does DRI have a future with neither NVIDIA nor ATI participating?
Are people actually talking to them about why they don't use it and
what has to be done to remedy this fact? Shouldn't this be a top priority?
59 matches
Mail list logo
