This is a better patch for the three proposed IOCTLs.
1) Fixes a merge bug that made the first one segfault
2) Plays nice with framebuffer. If framebuffer is found DRM will revert to
stealth mode and disable the new features.
3) Compiles and works on 2.4. New features are disabled on 2.4 but with
I saw that the cvs dri is not based on Xfree4.4 but on a older XFree
4.3.99.12 version
what directories of my XFree 4.4 have I to up from the dri one in way to
have the latest version of dri???
I know the 4.4 release is not GPL compatible, but it's just to see if it
solve some trouble i got with my
I don't think they are necessary so the _SOLO defines could be extended. Keith
wrote the code so I'm not sure what he intentions were.
--- Dave Airlie <[EMAIL PROTECTED]> wrote:
>
> The current miniglx fakes up some DDX version numbers but these only work
> for the radeon drivers, (4.0) is used,
The current miniglx fakes up some DDX version numbers but these only work
for the radeon drivers, (4.0) is used, but the i810 drivers is only on
version 1.0,
Is there any need for this to be checked at all should the _SOLO defines
in utils.c:driCheckDriDdxDrmVersions be extended to cover the DDX
export RADEON_GARTTEXTURING_FORCE_DISABLE=1
i have this in /etc/profile, the machine has been rebooted since then, and rainbow
problem still exists.
--- On Fri 03/12, John H. < [EMAIL PROTECTED] > wrote:
From: John H. [mailto: [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTE
On Sun, 2004-03-14 at 07:14, Jon Smirl wrote:
> This is a first pass at the three new IOCTL patch.
>
> It is against the DRM copy in the Mesa tree.
And exactly why does that still exist? I know you don't listen to me,
but I don't think you can ignore Keith.
> 2) It uses the kernel to bind the
On Sun, 2004-03-14 at 21:00, Jon Smirl wrote:
>
> Linux's current design has lots of holes in it. Start two X servers on two
> different VTs (not just two sessions to the same X server)
How do you start two sessions to the same X server? *shrug*
> you're going to reboot your machine.
Works fi
In previous discussions I never said OpenGL in the kernel, I only said DRM in
the kernel. Item four was a very brief recap that left out a lot of detail. The
kernel console uses a direct entry point into the DRM driver. This direct entry
point has enough state to display no matter what is happening
Hi
Building sis dri+mesa source goes well. I followed the
dri building documentation. Still there is no luck.
It gives sis_drv unresolved symbols. Where as from
xfree86-4.4 compiles well and dri is enabled. In this
case I am getting only blank screen with glxgears.
The relavent output is
--
On Sul, 2004-03-14 at 02:50, Jon Smirl wrote:
> 1) Use SysReq to get to kernel console. In this model the kernel console is
> always active, it's just hidden. Hit SysReq and it appears. Hit an oops or panic
> and it will appear too. The video driver has enough state information to make
> this conso
On Sun, Mar 14, 2004 at 08:29:18AM -0800, Jon Smirl wrote:
>
> You're right that DRM is not tied to the OpenGL API. But what about things like
> memory management of the video RAM and AGP space? Right now that is happening
> inside of the OpenGL libraries.
Well memory management can be a bit of a
On Sul, 2004-03-14 at 16:29, Jon Smirl wrote:
> You're right that DRM is not tied to the OpenGL API. But what about things like
> memory management of the video RAM and AGP space? Right now that is happening
> inside of the OpenGL libraries.
Much of it has to. The allocation rules vary by card. DR
--- Ville Syrjälä <[EMAIL PROTECTED]> wrote:
> Is still don't understand this point. Why do you need to define a primary
> API? The DRM isn't really tied to OpenGL in any way so the common API is
> the DRM API. People should be able to implement any API on top of DRM.
>
> And speaking of the DRM
I am also seeing this problem. To be precise, the r200-20040303 snapshot from
freedesktop.org works without any problems, but from 20040304 until 20040313,
it is broken for GL apps.
[]$ glxinfo
name of display: :0.0
libGL warning: 3D driver claims to not support visual 0x23
libGL warning: 3D dri
On Sat, Mar 13, 2004 at 06:50:07PM -0800, Jon Smirl wrote:
> A fourth concept which has already been heavily discussed is making OpenGL the
> primary graphics API. OpenGL can be quite small, OpenGL-ES is already shipping
> on some phones. Just to recap OpenGL/xserver is a response to Windows Longho
15 matches
Mail list logo
