rying to use an OpenGL program and Mesa falls
> back to indirect rendering.
> I include a patch that correct the problem.
BTW, anyone knows if there is also support for the none-builtin *Chrome
graphic chips ? There are two other of those around.
F
gs have been tried why not ?
>
> At least the boycott also makes sure that people who follow it don't have
> hardware we can't write drivers for.
I wouldn call making sure people don buy useless hardware a boycott though,
but simple common sense.
Friendly,
Sven Luther
-
m/fbdev module for even the newer model of
graphic cards, and even from players like nvidia. They can hide all
their stuff in proprietary userland libraries afterward still, but the
right thing would be to have this integrated kernel driver be a real
GPLed dr
e we will depend on a non-free component in the
kernel and were we are going to forget about graphic support on anything
non-x86.
Friendly,
Sven Luther
---
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceFo
27;t
conform us with a proprietary solution. Remember that many folk build
the fbdev driver in the kernel to have early fbdev console, and this
will not be possible with a x86 binary only module.
Friendly,
Sven Luther
---
This SF.Net email is s
or linux,
> there are still other operating systems (and users who insist on open
> source drivers) that would benefit from having the specs available.
Not to speak about non x86 architectures, especially the new Apple
powerbooks with radeon mobility 9600 would benefit from it.
ervers for another bunch of high-end cards. I think
3Dlabs also announced linux support for their very high-end wildcat
cards :
http://www.3dlabs.com/whatsnew/pressreleases/pr03/03-07-09-linux.htm
But they only provide binary rpms, so i suppose it is for whatever
XFree86 Redhat 7.3 provides
when one head is DVI connected. My current XFree86
work has to do with the SDK, but i had not had as much time as i wanted
for this too.
Friendly,
Sven Luther
---
This sf.net email is sponsored by:ThinkGeek
Welcome to g
pci id information out of the xf86PciInfo.h file and into each
individual drivers. With the new (well, new as in 4.x or something such)
driver architecture, the xf86PciInfo.h is not really needed anymore,
since each driver knows how to detect s
l as well as multi-part with only html
part mail should catch most if not all of those spams.
Friendly,
Sven Luther
---
This SF.NET email is sponsored by: eBay
Great deals on office technology -- on eBay now! Click here:
http://adfarm.mediapl
year or so, AGP will likely be phased out in favour of
> PCI express anyway, so I'm not convinced that agpgart really has much
> of a future past the next 12 months.
And we will throw out all our existing hardware and run buying
PCI-Express enabled ones, right ?
Friendly,
Sven Luther
On Thu, May 29, 2003 at 11:53:32AM -0400, David Dawes wrote:
> On Thu, May 29, 2003 at 07:34:28AM +0200, Sven Luther wrote:
> >On Thu, May 29, 2003 at 12:00:22AM -0400, Mike A. Harris wrote:
> >> On Wed, 28 May 2003, Sven Luther wrote:
> >>
> >> >> > I
On Thu, May 29, 2003 at 12:00:22AM -0400, Mike A. Harris wrote:
> On Wed, 28 May 2003, Sven Luther wrote:
>
> >> > I was being sarcastic, his message was encoded with koi8-r, which, along
> >> > with being html, is one of the indescriminate reasons people block email
tml part too though,
which is not so easy to do, i think.
Friendly,
Sven Luther
---
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't
g
> including the front buffer is the long term goal.
I don't believe it frees (do you say that in english ?) the Onscreen
memeory though, i had the impression that it just allocate memory for
the maximum possible screen and use a part of it if you are using a
lesser resolution, a
is unacceptable for performance reasons. Where does
> that leave us?
What about #3, but using a common library, so the same code is linked in
in two places ?
Friendly,
Sven Luther
---
This SF.net email is sponsored by:
The
> pthreads based framework with a mock up of the kernel code ready to
Would this pthread using userland pthread using code be usable in the X
driver ?
Friendly,
Sven Luther
---
This SF.net email is sponsored by:
The Definitive IT and Netw
to set your screen accordyingly, right ? Does it not cause problems when
you move the viewport inside the virtual space ? Or did you disable this ?
Friendly,
Sven Luther
---
This SF.net email is sponsored by: Etnus, makers of TotalVie
of the two, so i forward the response from Antonino and
also start a cross-thread (or whatever that is called). I hope it is ok
for all of you.
Friendly,
Sven Luther
- Forwarded message from Antonino Daplas <[EMAIL PROTECTED]> -
On Sun, 2003-03-02 at 02:42, Jon Smirl wrote:
>
ently.
>
> The DRI tree has close to 10,000 files in it right now
> and DRI isn't even a complete X tree. That's an awful
> lot of code to read and understand as a single
> package.
But if you only look at the X drivers, they are quite small, and well
documented.
Friend
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 in
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
e for the fbdev driver, but still, you
could add a register write dump to the bios emulator to see what it does
write to the registers or something such.
That said, things like memory timings and such will be board dependant.
Friendly,
Sven Luther
t; Also, keep in mind that even the Radeon 3D drivers use the 2D engine for
> things like texture uploads.
Notice that chips like the permedia2/3 used their 3D engine for doing 2D
rendering. Sure they were chips from 3Dlabs coming from the 3D world to
the 2D one, b
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
easy. A weeks work at most if
everything works out well and you have available docs. This would
include Xv accel as well.
Now, writing the 3D driver part is quite more difficult, and will not
work on every OS XFree86 supports.
Friendly,
Sven luther
--
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
&
gate the Berlin project, which, if i am not wrong, uses
OpenGL for drawing, and aims to be a X reemplacement. Not that it is
anything near that point though.
Friendly,
Sven Luther
---
This sf.net email is sponsored by:Th
On Thu, Feb 27, 2003 at 06:58:42PM +0100, Michel Dänzer wrote:
> On Don, 2003-02-27 at 09:33, Sven Luther wrote:
> > On Thu, Feb 27, 2003 at 02:14:37AM +0100, Michel Dänzer wrote:
> > > On Mit, 2003-02-26 at 18:16, Alex Deucher wrote:
> > > > -- Sven Lu
On Thu, Feb 27, 2003 at 02:12:24AM +0100, Michel Dänzer wrote:
> On Mit, 2003-02-26 at 21:11, Sven Luther wrote:
> >
> > [...] because the DRI is just rendering to the framebuffer, it doesn't
> > know if you are displaying it or not, and doesn't even care. The onl
On Thu, Feb 27, 2003 at 02:14:37AM +0100, Michel Dänzer wrote:
> On Mit, 2003-02-26 at 18:16, Alex Deucher wrote:
> > --- Sven Luther <[EMAIL PROTECTED]> wrote:
>
> [ video memory management ]
>
> > > How is it done right now ? Is a part of the onchip memory r
On Wed, Feb 26, 2003 at 09:40:18AM -0800, Linus Torvalds wrote:
>
> On Wed, 26 Feb 2003, Sven Luther wrote:
> >
> > Yes, and you have to divide the fb memory in two, one for each head, or
> > something such, and each head will have its separate offscreen memory
>
On Wed, Feb 26, 2003 at 09:16:53AM -0800, Alex Deucher wrote:
>
> --- Sven Luther <[EMAIL PROTECTED]> wrote:
> > How is it done right now ? Is a part of the onchip memory reserved
> > for
> > framebuffer and XAA, and another part free for 3D use ?
>
> Not sur
memory manager library also available to fbdev using apps or something
such, haven't thought much about that though.
Friendly,
Sven Luther
---
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT tra
to be
done in the drm kernel module, right ? Also this would need the
offscreen memory manager to be adapted.
Well, i hope this covers it, i will no go to reread ian's proposal and
see how the XAA interaction will work out.
Are there things i have missed or additional ideas ?
Friendly,
On Mon, Feb 24, 2003 at 06:44:05PM -0800, Ian Romanick wrote:
> Sven Luther wrote:
> >On Mon, Feb 24, 2003 at 09:48:42AM -0800, Ian Romanick wrote:
> >
> >>What about apps that send uncompressed textures into the driver, expect
> >>the driver to compress then
On Mon, Feb 24, 2003 at 09:48:42AM -0800, Ian Romanick wrote:
> Sven Luther wrote:
> >Is there not a way to work around this ?
> >
> >If the hardware doesn't support s3tc, then the driver simply don't
> >advertize the that it can handle s3tc textures, s
On Mon, Feb 24, 2003 at 06:35:47PM +0100, Michel Dänzer wrote:
> On Mon, 2003-02-24 at 18:11, Sven Luther wrote:
> > On Mon, Feb 24, 2003 at 06:05:21PM +0100, Michel Dänzer wrote:
> > > On Mon, 2003-02-24 at 16:09, Sven Luther wrote:
> > > > On Mon, Feb 24, 2003
On Mon, Feb 24, 2003 at 06:35:47PM +0100, Michel Dänzer wrote:
> On Mon, 2003-02-24 at 18:11, Sven Luther wrote:
> > On Mon, Feb 24, 2003 at 06:05:21PM +0100, Michel Dänzer wrote:
> > > On Mon, 2003-02-24 at 16:09, Sven Luther wrote:
> > > > On Mon, Feb 24, 2003
On Mon, Feb 24, 2003 at 06:05:21PM +0100, Michel Dänzer wrote:
> On Mon, 2003-02-24 at 16:09, Sven Luther wrote:
> > On Mon, Feb 24, 2003 at 07:58:55AM -0700, Jens Owen wrote:
> > > A short cut to this whole thing would be to work on getting a second
> > > head suppo
On Mon, Feb 24, 2003 at 08:35:13AM -0700, Jens Owen wrote:
> Sven Luther wrote:
> >On Mon, Feb 24, 2003 at 07:58:55AM -0700, Jens Owen wrote:
> >
> >>A short cut to this whole thing would be to work on getting a second
> >>head supported on a single X1
stuff.
I think that matrox did something such in their proprietary drivers.
Friendly,
Sven Luther
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
D
t possible to tell the app that you don't know how to compress
textures, and are asked for it, then you just send the texture
uncompressed or something such.
Ideally, there would be a way to tell the apps that you can receive and
use s3tc compressed textures, but not uncompress them yoursel
nt monitors attached to them, or want to run
different apps on them ?
Friendly,
Sven Luther
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
what exactly we are going to express in this config file. Will it
include only booleans and numeric values, or maybe also matrices, or
even other stuff (graphic programs ?).
Friendly,
Sven Luther
---
This SF.
On Tue, Jan 28, 2003 at 01:25:48AM -0600, D. Hageman wrote:
> On Tue, 28 Jan 2003, Sven Luther wrote:
>
> > On Mon, Jan 27, 2003 at 06:04:19PM -0600, D. Hageman wrote:
> > >
> > > I think you misunderstand. We aren't replacing the XF86Config file here.
&g
eady
>have it.
> *) Extensible.
> *) It can be edited with any text editor.
Another disadvantage is that parsing is so damn slow.
Friendly,
Sven Luther
---
This SF.NET email is sponsored by:
SourceForge En
ing the mplayer but now the films color
>not correct on the radeon 9100, i dont now the x problem or mplayer problem.
Notice that mplayer is doing its own trick to play video, and not
directly using Xv for it, i may be wrong though, but at least that is
how it works for the permedia
e is not really all that much i can contribute to
> >this discution, since i am under NDA, but, well, virtual memory for
> >graphic chips work all the same as virtual memory for CPUs so i guess it
> >is easy to take those things into account also.
>
> Fair enough. You&#
On Mon, Jan 20, 2003 at 09:30:50AM -0800, Ian Romanick wrote:
> Sven Luther wrote:
> >On Thu, Jan 16, 2003 at 05:33:42PM -0800, Ian Romanick wrote:
> >
> >>1. Single-copy textures
> >>
> >>Right now each texture exists in two or three places. There i
basically set up the graphic boards memory as a cache memory, and
have the the MMU-like unit swap the memory pages from host memory, using
i suppose its own page replacement algorithm.
Friendly,
Sven Luther
---
This SF.NET email is sponsored by: T
> who has expressed
interrest of making the DRI work on his PCI based permedia3 board (he has
an alpha box) but i think he is doing video stuff right now.
I am interrested in doing DRI work for gamma + dual pm3 myself, but
sadly don't have the time right now.
Frien
t working. Xfree logs' say that Direct Rendering is enabled,
> but glxinfo says the oposite.
That is usually because you are using a non DRI enabled libGL.
Could you check which libGL you are using, and eventually put the path
of the DRI one in /etc/ld.so.conf and rerun ldconfig.
man ldco
That is the only way things are going to get cleaned up, process-wise.
> Not to mention greatly aiding kernel coding efforts for non-linux
> platforms.
And there are also people wanting to use the DRM outside of XFree86,
maybe even outside of the DRI, not sure though.
Friendly,
Sve
sly :
mount -o remounc,sync /var
This way, you will see everything the X server outputs, and not miss
anything, well, at least it worked with ext2. It will be very slow
though, so i would not recommend it for continous use, only for
experimenting with such problems.
Friendly,
Sven Luther
--
On Wed, Nov 13, 2002 at 04:28:05AM +0100, Dieter Nützel wrote:
> http://www.xtremepccentral.com/articles/opengl2/
It don't really says all that much more than the original openGL 2.0
presentation, which can be found from :
http://www.3dlabs.com/support/developer/ogl2/index.htm
Friendl
now (I guess it would be the prime candidate
for removal, isn't it ?)
Friendly,
Sven Luther
---
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redir
8500 as the 7500 is to the 7200 (basically). When you say
> "it's not perfect," what exactly doesn't work?
Well, i think the 9000 took the dual-head stuff from the 7500, not the
8500, so this may be one thing that is not working.
There may be other differences too.
the impression that the 9000 was just a modified R200, which
> might be expected to be software-compatible. The R300 was supposed to
> be a new architecture, no?
Yes, the patch only knows about RV250, not R300, so it will most
assuredly not
ks, like ATI
is doing in their latest 9000 and 9700 based boards, using the pixel
shaders to handle video.
Do we have documentation available on these parts of those boards ?
Friendly,
Sven Luther
---
This sf.net email is sponsore
, thus making things
easier for the folk doing the final sync.
Friendly,
Sven Luther
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
On Thu, Jul 04, 2002 at 03:23:56PM +0200, Sven Luther wrote:
> Hello, ...
>
> I have just submitted patch # 577344 via sourceforge, bue the patch did
> not get attached to the patch report, so i am sending it via the list
> also.
Forgot to attach the patch :(((
Friendl
, but i guess a better solution is
possible.
BTW, is it normal that i cannot buid the DRI server out of CVS when
changing the ProjectRoot ? It seems to try building stuff with the
installed libraries and thus fail if ProjectRoot don't point to
installed libraries.
Friendly,
S
gt; workaround has been to use the utah-glx stuff, but then I didn't get
> antialiased fonts in KDE.
Does the matrox DRI stuff still freeze on SMP boxes, like it was the case
previously ?
Friendly,
Sven Luther
___
Dri-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dri-devel
64 matches
Mail list logo
