> radeon/r200 have some 32 Byte alignment restrictions for all textures), though
> I just noticed a small error in the patch:
>
> + case MESA_FORMAT_RGB_DXT1:
> + t->texelBytes = 2;
> + textureFormat = (MAPSURF_COMPRESSED | MT_COMPRESS_DXT1);
> + break;
> + case MESA_FORMAT_RGBA_D
--- Daniel Stone <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 13, 2004 at 10:42:58PM -0700, Jon Smirl wrote:
> > X on GL won't ship anywhere for at least a year. It will probably be two
> years
> > before it is in wide spread use. You can get good 3D cards for $35 now, in
> two
> > years due to Longhor
X on GL won't ship anywhere for at least a year. It will probably be two years
before it is in wide spread use. You can get good 3D cards for $35 now, in two
years due to Longhorn all systems will be shipping with them.
I still own an 8086 based machine with no protected mode, does that mean that
X on GL has no impact on remote X. Tests with glitz show a 100:1 speed
improvement for local drawing.
--- Daniel Stone <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 13, 2004 at 12:13:43PM -0700, Jon Smirl wrote:
> > So if my ideas are so bad, why don't you propose your own solution to the
> > Longhorn
On Sun, Jun 13, 2004 at 08:47:37PM +0100, Matt Sealey wrote:
>
> Having a capable accelerated 2D and 3D architecture, something
> like DirectFB but at more of a "core" and "commercial" level
> would benefit everyone. Building a single DDX driver to
> interface with this would simplify support for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sunday 13 June 2004 20:22, Keith Packard wrote:
> Around 10 o'clock on Jun 12, Eric Anholt wrote:
> > I am definitely in favor of the DRI X tree stuff being a branch on the
> > X.Org tree.
>
> "me too".
>
> A question is how the future modularizatio
Around 20 o'clock on Jun 13, Alan Cox wrote:
> Secondly every line of code you put in the kernel has to be audited,
> analysed and can introduce security holes or crash the machine.
The same is (alas) all too true for code within the X server as well. An
ideal situation would have the X server
Around 21 o'clock on Jun 13, Philipp Klaus Krause wrote:
> There would be no 2d drivers, only some basic mode switching and cursor
> support and OpenGL?
For systems which would support OpenGL, this would be all that was required.
However, we still need to deal with the unwashed masses yearning
Around 10 o'clock on Jun 12, Eric Anholt wrote:
> I am definitely in favor of the DRI X tree stuff being a branch on the
> X.Org tree.
"me too".
A question is how the future modularization of the system would impact this
process. I'm hoping the answers will be "mostly positive", but discussio
On Sun, 2004-06-13 at 12:35 -0700, Jon Smirl wrote:
>
> 2) copy of the user space code from XFree86 into a standalone library - now you
> have to be root to play with the chip.
> 3) Add a couple of IOCTLs to DRM to support modes/cursors. Do as much of the
> work as possible in user space and just
I think this has been covered mostly I just want to add that kernel
interface DRM is allready needed for most of todays cards. For older
cards the older system should still be used and supported, this is not
what were talking about with the r200.
The DRM is a kernel driver that allowes the user-a
I think the existing(older) system should be used on older cards. If
developers start using OpenGL over libX11 then users will have to upgrade
or use the slower software Mesa, this dose not change anything where
talking about.
--- Philipp Klaus Krause <[EMAIL PROTECTED]> wrote:
> Jon Smirl schrie
--- John Dennis <[EMAIL PROTECTED]> wrote:
> > With a properly designed kernel driver the X server does not need
> > to map the hardware into user space and run as root.
>
> How do you efficiently control the hardware then without incuring the overhead
> of user/system transition on ioctl's? How m
--- Matt Sealey <[EMAIL PROTECTED]> wrote:
> We need a low-level "kernel" graphics API (much like Windows
> has, although Windows favours microkernels with high-level
> kernel functionality, rather than monolithic kernels with
> user-level functionality.. the two philosophies are at odds)
> which c
> With a properly designed kernel driver the X server does not need
> to map the hardware into user space and run as root.
How do you efficiently control the hardware then without incuring the overhead
of user/system transition on ioctl's? How many iotcl's and at what granularity
are you suggestin
--- Alan Cox <[EMAIL PROTECTED]> wrote:
> On Sul, 2004-06-13 at 20:20, Torgeir Veimo wrote:
> > At least he is trying. There's no need for bashing people who try to
> > implement new ideas.
>
> I'm not. I'd rather he listened to new ideas and took feedback but that
> is his business and the commu
--- Alan Cox <[EMAIL PROTECTED]> wrote:
> Secondly every line of code you put in the kernel has to be audited,
> analysed and can introduce security holes or crash the machine. Its
> harder to debug and its harder to write in the first place. There are
> very good reasons (see the original DRI pape
If it's like you say why not pick up the glove and
create a tree for it?
orginize a tree with a workplan I'm sure most people would be happy to
contribute, I know I would.
Ely Levy
System group
Hebrew University
Jerusalem Israel
On Sun, 13 Jun 2004, Jon Smirl wrote:
> --- Alan Cox <[EMAIL PROT
Alan Coopersmith wrote:
> >>>Why not help getting mesa-solo working so that we can move to X on top of
> >>>OpenGL?
> >>
> >>For one, in the two years that is going to take to bear fruit, we need a
> >>working X server. Two because mesa-solo isnt supported on most of
> >>the Xorg platforms.
> >
> >
On Sun, 13 Jun 2004, Alan Cox wrote:
> On Sul, 2004-06-13 at 16:34, Jon Smirl wrote:
> > The Microsoft Longhorn UI is going to trounce Linux on the desktop if we don't
> > get to work on a response. Getting mesa-solo running everywhere wouldn't take
> > two years if more people would pitch in and
Jon Smirl wrote:
--- Alan Cox <[EMAIL PROTECTED]> wrote:
On Sul, 2004-06-13 at 03:07, Jon Smirl wrote:
Why not help getting mesa-solo working so that we can move to X on top of
OpenGL?
For one, in the two years that is going to take to bear fruit, we need a
working X server. Two because mesa-solo i
I agree with both you guys :)
Linux basically falls behind on two simple fronts at the moment:
it has no "simple" 2D or 3D framework capable of much more than
simple framebuffer support. So, unless you buy Qt, the deeply
embedded market is out from an "out of the box" standpoint,
where developer
> -Original Message-
> From: Alan Cox [mailto:[EMAIL PROTECTED]
> Sent: 13 June 2004 20:04
> To: [EMAIL PROTECTED]
> Cc: Jon Smirl; Eric Anholt; Alex Deucher; DRI Devel;
> [EMAIL PROTECTED]
> Subject: RE: [Xorg] DRI merging
>
>
> On Sul, 2004-06-13 at 20:47, Matt Sealey wrote:
> > Linux
Alan Cox wrote:
On Sul, 2004-06-13 at 16:34, Jon Smirl wrote:
The Microsoft Longhorn UI is going to trounce Linux on the desktop if we don't
get to work on a response. Getting mesa-solo running everywhere wouldn't take
two years if more people would pitch in and quit arguing. Right now we should
Jon Smirl schrieb:
fbdev dependence is a very small part of mesa-solo that I would like to remove.
fbdev is only used to set the video mode and control the cursor. Both of these
of done in user space in the current XFree XAA drivers.
There are three main solutions to mode/cursors problem that no on
--- Alan Coopersmith <[EMAIL PROTECTED]> wrote:
> But fbdev only covers one of the supported OS'es right? Xorg runs on the
> BSD's, Solaris, Windows/Cygwin, MacOS X, and many other platforms without
fbdev, so
> it's very premature to say that work on anything else is wasted.
The work that would b
--- Ely Levy <[EMAIL PROTECTED]> wrote:
> If it's like you say why not pick up the glove and
> create a tree for it?
> orginize a tree with a workplan I'm sure most people would be happy to
> contribute, I know I would.
The work is already underway:
mesa-solo is here: http://mesa3d.sourceforge.net
--- Alan Cox <[EMAIL PROTECTED]> wrote:
> You have no solution to non 3D heavy cards, you have no solution to
> non-Linux hardware platforms. Most of your linux ideas have been thrown
> out repeatedly as half-baked on multiple lists.
>
> mesa-solo is a *research* project. If it works out then in t
On Sun, Jun 13, 2004 at 08:34:46AM -0700, Jon Smirl wrote:
> --- Alan Cox <[EMAIL PROTECTED]> wrote:
> > On Sul, 2004-06-13 at 03:07, Jon Smirl wrote:
> > > Why not help getting mesa-solo working so that we can move to X on top of
> > > OpenGL?
> >
> > For one, in the two years that is going to ta
--- Alan Cox <[EMAIL PROTECTED]> wrote:
> On Sul, 2004-06-13 at 03:07, Jon Smirl wrote:
> > Why not help getting mesa-solo working so that we can move to X on top of
> > OpenGL?
>
> For one, in the two years that is going to take to bear fruit, we need a
> working X server. Two because mesa-solo i
--- Martijn Sipkema <[EMAIL PROTECTED]> wrote:
> > Why not help getting mesa-solo working so that we can move to X on top of
> > OpenGL?
>
> Where can I find more information about mesa-solo? Is this the same as
> miniglx?
Same thing. http://mesa3d.sourceforge.net/fbdev-dri.html
>
> > Keithp is
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://freedesktop.org/bugzilla/show_bug.cgi?id=733
--- Additional Comments From [EMAIL PROTECTED] 2004-06-13 07:00 ---
(In reply to comment #
Am Sonntag, 13. Juni 2004 09:01 schrieb Dieter Nützel:
> Empty black window.
> With 'Point' and 'Linear' Filtered.
>
> Mesa (LIBGL_ALWAYS_INDIRECT) works.
Argh, I've forgotten to mention the hardware...
r200
-Dieter
---
This SF.Net email is s
Empty black window.
With 'Point' and 'Linear' Filtered.
Mesa (LIBGL_ALWAYS_INDIRECT) works.
-Dieter
---
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the
one installati
34 matches
Mail list logo
