-- You've heard about all the benefits
--
-- You've seen it on NBC and Oprah
--
Get your free bottle of H-G-H
today!
Visit
Us
Why was this email sent to you? At some point you registered
or made a purchase on a Web
This the appropriate place to send suggestions about the bsd drm driver?
There's an interesting amount of effort in the BSD side, to attempt to make
a more portable framework. But it's missing a few things here and there.
The first thing I've run into:
there is
#define DRM_OS_SPININIT(l,name)
On Fri, Feb 28, 2003 at 06:26:35PM -0800, Jon Smirl wrote:
--- 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
Hello, ...
As you may have noticed, i have started a (sub) thread with David Dawes
on this subject on the xfree86 list.
Friendly,
Sven Luther
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
On Fri, 28 Feb 2003 22:13:22 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
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
Andreas,
Sorry for the delay of the reply, but I took more time to review the
driver.
On Fri, Feb 28, 2003 at 05:36:54AM +0100, Andreas Karrenbauer wrote:
José Fonseca wrote:
2. Then you have BCI (Burst Command Interface - not BCE, sorry), which
can access to a subset of the registers.
Hello
I have Radeon 7500 based card and in some of GL apps I see the textures
flickering. I see the triangles flashing also. I saw other messages
discribing this bug and I wonder when it will be fixed.
---
This sf.net email is sponsored
On Sat, 1 Mar 2003, Sven Luther wrote:
What use is it for then ? Since the first card will be initialized by
the BIOS anyway. I thought the whole point of it was to be able to
initialize the other cards.
The only use is to serve as a very obfuscated documentation of the
registers on the card
On Sat, 1 Mar 2003, Sven Luther wrote:
Tell me the sequence needed and this unpaid hacker
will add a reset function to the Rage128 FB driver for free.
BTW, does the int10 and such stuff from the X driver not do this for you
Only for the first card, I gather.
? I agree, this would be too
On Sat, Mar 01, 2003 at 02:31:30PM +0100, Peter Firefly Lund wrote:
On Sat, 1 Mar 2003, Sven Luther wrote:
Tell me the sequence needed and this unpaid hacker
will add a reset function to the Rage128 FB driver for free.
BTW, does the int10 and such stuff from the X driver not do this
Felix Kühling wrote:
On Fri, 28 Feb 2003 22:13:22 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
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
On Tue, Feb 04, 2003 at 11:28:29AM -0800, Eric Anholt wrote:
[...]
There's one lock left that is never destroyed: vbl_lock. It causes a
panic: mutex vblsig 0xc6587234 already initialized
if X is restarted. Here's a patch that moves the creation from
irq_install into drm_init and destroys it in
Charl P. Botha wrote:
If by server-recycle you mean stopping and starting X, I haven't seen any
lockups with that.
An X Server recycle is something the X Server does automatically when
the last client disconnects. It basically goes thrue shutdown and
cleanup of everything, then reinitializes
--- Ian Romanick [EMAIL PROTECTED] wrote:
Daniel Vogel wrote:
To clarify: I meant what has to be done to make
DRI (direct rendering
*infrastructure*) attractive for IHVs. I didn't
mean to imply what has to be
done to get NVIDIA or ATI to release open source
drivers and whatnot.
The
Jon Smirl wrote:
--- Ian Romanick [EMAIL PROTECTED] wrote:
Daniel Vogel wrote:
To clarify: I meant what has to be done to make
DRI (direct rendering
*infrastructure*) attractive for IHVs. I didn't
mean to imply what has to be
done to get NVIDIA or ATI to release open source
drivers and
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Interesting you mention it. This is what Brian
I've done in the Mesa
embedded branch -- layered the radeon dri driver on
top of fbdev. I can also
build regular DRI drivers from a minimal tree sane
set of makefiles.
Can I run standalone
On Fri, 28 Feb 2003 22:13:22 -0800
Ian Romanick [EMAIL PROTECTED] wrote:
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
On Sat, 1 Mar 2003, Keith Whitwell wrote:
Interesting you mention it. This is what Brian I've done in the Mesa
embedded branch -- layered the radeon dri driver on top of fbdev. I can also
build regular DRI drivers from a minimal tree sane set of makefiles.
Personally, I'd rather see
Hi,
I've upgraded my system today and since xf 4.2.x
got installed X hasn't been working. I get a error about radeon.o is version
1.1.1 and 1.5 is needed
How do I patch my kernel or are there any other
ways to solve this issue ?
regards
Bachman
Jon Smirl wrote:
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Interesting you mention it. This is what Brian
I've done in the Mesa
embedded branch -- layered the radeon dri driver on
top of fbdev. I can also
build regular DRI drivers from a minimal tree sane
set of makefiles.
Can I run
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
Can I run standalone OpenGL on a Radeon with this?
Yes. Note that there is some hand tweaking of
makefiles to achieve a full
opengl -- we're targeting an embedded subset in the
standard build.
I pulled the embedded-1-branch,
On Sat, Mar 01, 2003 at 12:55:30PM +0100, sqwareq wrote:
I have Radeon 7500 based card and in some of GL apps I see the textures
flickering. I see the triangles flashing also. I saw other messages
discribing this bug and I wonder when it will be fixed.
As I wrote before - on Radeon VE there
uXD5lp5
On Sat, 2003-03-01 at 18:19, Bachman Kharazmi wrote:
Hi,
I've upgraded my system today and since xf 4.2.x got installed X
hasn't been working. I get a error about radeon.o is version 1.1.1 and
1.5 is needed
How do I patch my kernel or are there any other ways to solve this
issue ?
On Fri, 28 Feb 2003, David Bronaugh wrote:
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 like that.
So if they switched to using DRI, they would then be looking at rewriting
their own
On Sat, 1 Mar 2003, Smitty wrote:
The 3Dfx Voodoo 3 and Banshee specs are available, as are docs
for other 3D hardware. Who is working on that right now? 3Dfx
released the source code of Glide3 for example. I dont think a
single line of code has been written for Glide3 for 2 years now.
On Sat, Mar 01, 2003 at 03:05:37PM -0500, Mike A. Harris wrote:
On Sat, 1 Mar 2003, Smitty wrote:
a V3 gets smacked around by a TNT2,
Not with open source drivers it doesn't.
got some specs on how the V3 performs, with glxgears?
google only pulled up results from someone who said their
On Sat, 1 Mar 2003 15:05:37 -0500 (EST)
Mike A. Harris [EMAIL PROTECTED] wrote:
Look at the
Intel i8x0 driver for example. The Intel specs are publically
available, and Intel funds development of the driver. The
hardware is readily available too. Yet there is not any major
Jon Smirl wrote:
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
Can I run standalone OpenGL on a Radeon with this?
Yes. Note that there is some hand tweaking of
makefiles to achieve a full
opengl -- we're targeting an embedded subset in the
standard build.
I pulled the
Mike A. Harris [EMAIL PROTECTED] wrote:
On Sat, 1 Mar 2003, Smitty wrote:
Which is probably why Molton is trying to instigate a divorce
from Glide for the V3.
I certainly support that move. Anholt was working on Glide3
recently a bit as well. I dunno how far he got, but I've been
meaning
On Sat, 1 Mar 2003 03:56:42 +0200
Smitty [EMAIL PROTECTED] wrote:
Which is probably why Molton is trying to instigate a divorce from
Glide for the V3.
Well, more a merge of glide into the driver, at least short term.
(oh, and please, I prefer being referred to by my first name.)
I have two
If I were to spend the time to put together some portability patches
[for the kernel layer], would someone with cvs access volunteer interest to
review and put them in? I can potentially see a bunch of little ones
coming up, so rather than post every single one individually to the list, I
thought
On Sun, 2003-03-02 at 04:05, Mike A. Harris wrote:
On Sat, 1 Mar 2003, Smitty wrote:
Yes, it is. But you missed my point. The point being that code
exists and nobody is hacking on it. I'm not *blaming* anyone.
Volunteers work on what volunteers are interested in working on.
That's
On Sat, 1 Mar 2003, Jon Smirl wrote:
Where is the current source for the R128 DRM driver?
It's not in the DRI tree any more. I do see it under
drivers/char/drm in the Linux 2.5 tree.
On Sun, 2003-03-02 at 07:11, Linus Torvalds wrote:
On 2 Mar 2003, Antonino Daplas wrote:
AFAIK, there are at least 2 versions of the i810 framebuffer driver
publicly available, both of which are not possible without the public
docs.
I don't think that answers Mike's criticism that
On Sun, 2003-03-02 at 07:17, Mike A. Harris wrote:
On 2 Mar 2003, Antonino Daplas wrote:
I think the Intel 8x0 is also a bad example. Precisely because the
XFree86 and DRI drivers are funded by Intel that volunteer work shifts
to other areas (fbdev, DirectFB). Secondly, these old Intel
On Sat, 2003-03-01 at 23:11, Linus Torvalds wrote:
Quite frankly, DRI is the project from hell when it comes to getting
into it, and I think that's largely because you have to have all the
pieces in place to get something working, and you have to understand a
wide range of different issues
On Sat, 2003-03-01 at 20:28, Philip Brown wrote:
got some specs on how the V3 performs, with glxgears?
google only pulled up results from someone who said their setup seemd to
not be configured properly.
(68 FPS)
On the voodoo gears is a fine way to measure your monitor refresh rate. The
On 2 Mar 2003, Alan Cox wrote:
Thats one reason I'd love to see the C++ framework proposed. Hell I can
draw triangles on my SiS6326, its just there isn't a way to plug that
code into an existing framework yet.
I think this is the perfect example of hard to get into. A person who
knows what
--- Linus Torvalds [EMAIL PROTECTED] wrote:
A simpler, more direct, infrastructure to the
low-level driver might help.
X has served us well for a long time but I just don't
think it is sufficient to be the standard video
platform for desktop Linux over the next ten years.
We're not going to
On Sun, 2003-03-02 at 00:56, Jon Smirl wrote:
X has served us well for a long time but I just don't
think it is sufficient to be the standard video
platform for desktop Linux over the next ten years.
People were saying that ten years ago. They were wrong
then, and I suspect they are wrong now.
--- Alan Cox [EMAIL PROTECTED] wrote:
People were saying that ten years ago. They were
wrong then, and I suspect they are wrong now.
Looking out five years wouldn't OpenGL 2.0+ make a
better core graphics API for Linux than XLIB? Hardware
is certainly trending towards the 3D model.
I'd like
On 2 Mar 2003, Alan Cox wrote:
Since XFree 4.0 you don't have to touch the core code, you
don't have to duplicate a ton of stuff and you don't need
to know zip about DDX, MI and the other core layers.
Yeah, I don't think regular X is problematic. The Xv stuff used to be
quite messy, but
On Sat, 1 Mar 2003, Jon Smirl wrote:
I'd like to see Linux turn XFree inside out. Instead
of OpenGL/DRI being bolted onto X, bolt X onto
OpenGL/DRI.
It might not even be that painful to try. X largely should support things
like that simply thanks to the fact that people have already
On Sat, Mar 01, 2003 at 03:11:06PM -0800, Linus Torvalds wrote:
|
| ... you have to understand a
| wide range of different issues (you can't just understand hardware, you
| also have to have some understanding of OpenGL).
| ...
| Look at the size of a
On Sat, 1 Mar 2003, Allen Akin wrote:
This is largely because there's a *much* greater emphasis on performance
in the 3D world than in the 2D world. There's too much competitive
advantage to be gained by exposing hardware peculiarities and by
avoiding certain kinds of abstraction.
Well,
On Sat, 1 Mar 2003, Jon Smirl wrote:
X has served us well for a long time but I just don't
think it is sufficient to be the standard video
platform for desktop Linux over the next ten years.
We're not going to replace X overnight, but we need a
path to slowly evolve it. I am amazed at the rate of
On Sat, 1 Mar 2003 15:11:06 -0800 (PST)
Linus Torvalds [EMAIL PROTECTED] wrote:
Quite frankly, DRI is the project from hell when it comes to getting
into it, and I think that's largely because you have to have all the
pieces in place to get something working, and you have to understand a
Dear lists,
Does any of the DRI developers remember explicitly fixing the:
radeon_vtxfmt.c:1057: radeonVtxfmtUnbindContext: Assertion vb.context ==
ctx' failed. error that is so often seen running the glthreads mesademo?
I seem to remember Keith Whitwell (I *think*) saying that this was on his
On Sat, 1 Mar 2003, Allen Akin wrote:
Once you get rid of the legacy stuff in OpenGL, drivers are pretty much
the same level of complexity for OpenGL as for D3D.
I guess you also had to take away mandatory software fallbacks and the
imaging subset. In reality though, every IHV I've talked to
On Sun, Mar 02, 2003 at 12:57:42AM -0500, Daniel Vogel wrote:
I guess you also had to take away mandatory software fallbacks and the
imaging subset. In reality though, every IHV I've talked to stated their
OpenGL drivers being far more complex to maintain.
The question is does that really
On Sun, Mar 02, 2003 at 02:26:04AM +, Alan Cox wrote:
People were saying that ten years ago. They were wrong
then, and I suspect they are wrong now. Too many people
think X11 == XFree86. XFree86 is an *implementation*
(arguably two with kdrive) of X11.
Even ignoring kdrive, I'd call it
52 matches
Mail list logo