That's because, like a said earlier, the OGL output plugins convert the
YUV to RGB in software and then displays it as an RGB texture. none of
the plugins I've looked at use MESA_ycbcr_texture for YUV textures.
Alex
-
-Original Message-
From:
fifteen twist detection camp certification %RANDOM_WORD temperature direction insanity act
Broadcast Email Your Adto 28 MILLION Emails
=> ONLY $149 TODAY ONLY <=
Receive a Minimum 400% Increase in Sales and a Minimum of 750,000Web Site Hits Within 90 Days Guaranteed or Receive a Full 100%
On Mon, Jun 02, 2003 at 04:23:14PM -0600, Brian Paul wrote:
Sounds like the Mesa directory re-org should happen sooner, rather
than later.
I've been doing some research into CVS and it looks like there are two
approaches to doing the re-org:
1. Use the usual cvs add/remove/commit commands to
On Tue, Jun 03, 2003 at 01:26:04AM +0100, José Fonseca wrote:
I would also like to discuss the possibility of:
- dropping the DRM(my_func)() for drm_my_func(). If I'm not mistaken,
these symbols aren't exported to the rest of the kernel so there
isn't any conflict when several DRM's are
On Mon, 2 Jun 2003, Ian Romanick wrote:
I think you would be fine with multiple modules, but I think it would
break if you had multiple drivers built into the kernel. I'm not sure
about that, though.
Yes.
The reason for DRM(xxx) is that I personally _require_ that built-in
modules
Matt Sealey wrote:
glXDoSomething(GLXcontext, foo, bar, donkey) and so on. OS-dependant.
I dunno. What's your terminology for it? I'm going to draw attention
here to the severe lack of documentation on even what you're supposed
to call these components :)
If you are talking about glX functions,
On Tue, 3 Jun 2003, [iso-8859-15] José Fonseca wrote:
According with archives
(http://dri.sourceforge.net/doc/faq/architecture.html#DRM-SUB-DRIVERS),
Linus wanted the DRM drivers to be independent.
I wanted that because the old code was total crap, and the makefiles could
never get the
David Dawes wrote:
On Mon, Jun 02, 2003 at 04:23:14PM -0600, Brian Paul wrote:
Sounds like the Mesa directory re-org should happen sooner, rather
than later.
I've been doing some research into CVS and it looks like there are two
approaches to doing the re-org:
1. Use the usual cvs
José Fonseca wrote:
According with archives
(http://dri.sourceforge.net/doc/faq/architecture.html#DRM-SUB-DRIVERS),
Linus wanted the DRM drivers to be independent. Don't know if he still
feels the same, considering the ALSA/OSS modules, or the recent
reorganization of AGPGART. Don't know as
Brian Paul wrote:
David Dawes wrote:
On Mon, Jun 02, 2003 at 04:23:14PM -0600, Brian Paul wrote:
Sounds like the Mesa directory re-org should happen sooner, rather
than later.
I've been doing some research into CVS and it looks like there are
two approaches to doing the re-org:
1. Use the
On Tue, Jun 03, 2003 at 10:34:25AM -0600, Brian Paul wrote:
David Dawes wrote:
On Mon, Jun 02, 2003 at 04:23:14PM -0600, Brian Paul wrote:
Sounds like the Mesa directory re-org should happen sooner, rather
than later.
I've been doing some research into CVS and it looks like there are two
Linus Torvalds wrote:
To me modules are either
- distribution kernels (either things like RedHat/SuSE, or just local
MIS distrubutions)
- development (load a module, test, unload, fix, load again)
and make zero sense otherwise when you have full sources.
We also have our binary driver
Here's the latest proposed layout. It may need some fine tuning at
some point, but I think it's a pretty good starting point.
-Brian
Mesa/
docs/ - documentation
include/
GL/ - OpenGL public headers
gl.h
Quoting Brian Paul ([EMAIL PROTECTED]):
src/
mesa/
glapi/
glapi*.[ch] - dispatcher files
APIspec file
gl*.py - Python
On Tue, 3 Jun 2003, David Dawes wrote:
Does this go any way towards explaining why it seems to be getting harder
and harder to build modules outside of the kernel source tree while
still leveraging the kernel build mechanism?
No. That is explained by the inevitable lack of testing, I think.
On Tue, Jun 03, 2003 at 09:31:27AM -0700, Linus Torvalds wrote:
On Tue, 3 Jun 2003, [iso-8859-15] José Fonseca wrote:
According with archives
(http://dri.sourceforge.net/doc/faq/architecture.html#DRM-SUB-DRIVERS),
Linus wanted the DRM drivers to be independent.
I wanted that because
On Tue, 3 Jun 2003, [iso-8859-15] José Fonseca wrote:
IIUC, at least for modules, the symbols which we want to make available
to other modules usually have to be specificaly declared (with
EXPORT_SYMBOL). Therefore each module it's own namespace, i.e., two
different modules with some public
Denis Oliver Kropp wrote:
Quoting Brian Paul ([EMAIL PROTECTED]):
src/
mesa/
glapi/
glapi*.[ch] - dispatcher files
APIspec file
On Tue, Jun 03, 2003 at 12:26:03PM -0700, Linus Torvalds wrote:
If they have the same name, they must be the same function. It's that
simple. And if it's the same function and used by multiple different
drivers, then it MUST NOT have CONFIG_xxx dependencies.
Ok. Thanks for clearing this
The new attached patch also covers the drm_agpsupport.h janitorial.
As nobody stepped against it, I'll start commiting soon.
Except for this first time, I don't plan to commit more than one header
janitorial per day. This means that anybody can track regressions with
the nightly snapshots.
For
On Tue, 3 Jun 2003, [iso-8859-15] José Fonseca wrote:
Quite frankly, looking at the current DRI tree, there's not a lot of
code like this there that I can see. Almost every single library
function has intimate details about the hardware through macro
expansion.
By the
José Fonseca wrote:
The new attached patch also covers the drm_agpsupport.h janitorial.
As nobody stepped against it, I'll start commiting soon.
Except for this first time, I don't plan to commit more than one header
janitorial per day. This means that anybody can track regressions with
the
Brian Paul wrote:
Denis Oliver Kropp wrote:
Quoting Brian Paul ([EMAIL PROTECTED]):
src/
mesa/
glapi/
glapi*.[ch]- dispatcher files
APIspec file
gl*.py- Python API scripts
main/
Brian Paul wrote:
Denis Oliver Kropp wrote:
Quoting Brian Paul ([EMAIL PROTECTED]):
src/
mesa/
glapi/
glapi*.[ch]- dispatcher files
APIspec file
gl*.py- Python API scripts
main/
Jens Owen wrote:
Brian Paul wrote:
Denis Oliver Kropp wrote:
Quoting Brian Paul ([EMAIL PROTECTED]):
src/
mesa/
glapi/
glapi*.[ch]- dispatcher files
APIspec file
gl*.py- Python API scripts
Keith Whitwell wrote:
Brian Paul wrote:
Denis Oliver Kropp wrote:
Quoting Brian Paul ([EMAIL PROTECTED]):
src/
mesa/
glapi/
glapi*.[ch]- dispatcher files
APIspec file
gl*.py- Python API scripts
A few weeks ago there was some discussion about the fact that the
post-texmem merge code has broken Neverwinter Nights. Has the exact cause
been determined? If so, what needs to be done to get this working again?
Adam
---
This SF.net
On Sat, 2003-05-31 at 09:50, Paul Mackerras wrote:
I have been doing more hacking on the kernel DRM for rage 128 on my G4
powerbook. This machine has a UniNorth v1.0 host bridge which can
(allegedly) do 2x AGP. I have got DRI with AGP to work but it is a
bit of a saga. The main problem is
Quoting Jens Owen ([EMAIL PROTECTED]):
Brian Paul wrote:
Where do you propose that the files currently in Mesa/src/dri/ (such as
dri_glx.c, glxclient.h, etc) belong? src/dri-es/ is the place I was
planning on.
I'm trying to keep the tree fairly shallow (one of the things that
Quoting Brian Paul ([EMAIL PROTECTED]):
Denis Oliver Kropp wrote:
I think the DRI drivers should be moved into the dri/ directory
which itself should be in the drivers/ directory, because drivers/
contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc.
The dri/ directory will contain
Adam K Kirchhoff wrote:
A few weeks ago there was some discussion about the fact that the
post-texmem merge code has broken Neverwinter Nights.
I believe you are speaking about radeon/r200?
The post-texmem merge did not break Neverwinter Nights - it just made
some errors which were there before
Denis Oliver Kropp wrote:
Quoting Brian Paul ([EMAIL PROTECTED]):
Denis Oliver Kropp wrote:
I think the DRI drivers should be moved into the dri/ directory
which itself should be in the drivers/ directory, because drivers/
contains the public APIs of Mesa, e.g. OSMesa, fxMesa etc.
The dri/
Has the exact cause
been determined? If so, what needs to be done to get this working again?
Or are you speaking of the problem that nwn can't get a visual at
startup and just craps out? Leif Delgass has posted a patch for that
(bug in reporting visuals) but it was decided it needs more
[ Finally got some debugging time for the other DRI problem I've seen,
namely hugely flashing textures in tuxracer on i830, but _only_ iff MTRR
support is compiled into the kernel ]
On Wed, 14 May 2003, Linus Torvalds wrote:
reg00: base=0x ( 0MB), size=1024MB: write-back,
get larger balls and penís,
more
pleasure,
more
satisfactíon
Check ít out here
No more please
-=f4fthi2o1j89l=-
N¬HYÞµéX¬²'²Þu¼¶{¬© ®Ê NZXÁ8^më-¶Þi×^nè zº'¶©©Þ´7¬ ÞwØky§]y»
Title:
www.800j.cc
.
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free
On Mon, Jun 02, 2003 at 11:03:13AM +0200, Michel D?nzer wrote:
On Sun, 2003-06-01 at 03:10, Tom Vier wrote:
radeon_cp.c has TONS of casting bugs.
NOTE: please cc replies to me. i'm not on the list.
radeon_cp.c: In function `RADEON_READ_PLL':
radeon_cp.c:327: warning: cast
After Brian reported some problems to me with the fbconfig code in the
client-side GLX, I decided to make some GLX updates before leaving for
vacation (I'm away 6/10 through 6/22). I wanted to add GLX protocol
support for as many of the enum only extensions as I could. I
especially wanted to
On Tue, Jun 03, 2003 at 11:52:42AM -0700, Linus Torvalds wrote:
On Tue, 3 Jun 2003, David Dawes wrote:
Does this go any way towards explaining why it seems to be getting harder
and harder to build modules outside of the kernel source tree while
still leveraging the kernel build mechanism?
Title: biplane
HI,Dri-announce,Do you want a GOLD CARD?
If you can't get a credit card or
just need another.
The Economy is tough
So make Your Life Easy.
This is Your Chance to Change Your life!
Click
Here
no mail
gunkmantissaudjnbco wafq yulfedirhlw
jfv sgwdfj qqk venm z fywcq itkad
On Tue, 3 Jun 2003, David Dawes wrote:
So, my question is whether the new kernel build mechanism is intended
to allow this type of thing, or did it work before more by accident than
design?
Hmm.. Sounds accidental, but it might be a good idea to contact
Sam Ravnborg [EMAIL
on the web page, titled CVS fro the DRI,
linked via CVS Web Page on the documentation page
there is a comment for the mesa-4-0-4-branch
with states:
A Stable branch to be included in XFree86 4.3
XF86 4.3.0 is already out a few months,
so that line obviousely needs an update.
Thanks.
Brian Paul wrote:
Denis Oliver Kropp wrote:
Quoting Brian Paul ([EMAIL PROTECTED]):
Denis Oliver Kropp wrote:
I think the DRI drivers should be moved into the dri/ directory
which itself should be in the drivers/ directory, because drivers/
contains the public APIs of Mesa, e.g. OSMesa, fxMesa
Title:
www.800j.cc
.
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free
WHY WASTE YOUR TIME AT THE DOCTOR'S OFFICE? PRESCRIPTION MEDS PRESCRIBED ONLINE AND SHIPPED OVERNIGHT TO YOUR DOOR! How Does it Work? Buy Prescription Drugs Online!
1.
Click
here to go to getyourmedsnow.com
2.
Guaranteed Date
The biggest automated dating system
on the internet!
Submit your information today and
get a date tonight!
Click
here to Enter!
---
This SF.net email is sponsored by: Etnus, makers of TotalView, The
[This e-mail has been automatically generated.]
You have one or more bugs assigned to you in the Bugzilla
bugsystem (http://bugs.xfree86.org/) that require
attention.
All of these bugs are in the NEW state, and have not been touched
in 7 days or more. You need to take a look at
Quoting Keith Whitwell ([EMAIL PROTECTED]):
Brian Paul wrote:
dri/- dri driver interface
api/- public api
common/- reusable driver code
radeon/ - DRI driver
r200/ - DRI
Quoting Brian Paul ([EMAIL PROTECTED]):
Denis Oliver Kropp wrote:
Also, I want to try to keep all source files as leaves in the tree.
That is, a directory foo/ won't contain both files and subdirs; just
one or the other.
What about this?
dri/- dri
You are
receiving this special offer because you have provided permission to
receive email communications regarding special online promotions or
offers. If you feel you have received this message in error, or wish to be
50 matches
Mail list logo
