Hi, Dave.
Dave Airlie wrote:
AllowInsecureDRI is less secure than forcing users to run things as root
or fix the code. And we want that code in kernel and causing pain in
order to make people fix it 8)
I'm really with Keiths don't let them do anything until someone fixes
New patch is at
http://pdx.freedesktop.org/~anholt/dri/r200-projtex-7.diff
New in this one is reenabling vtxfmt (avoiding the crash on exit of many
apps), making vtxfmt work in texgenmix, fixing the fog/specular
EMIT_ATTR issue (like was done for savage) for r200, and cleaning a
warning.
The
El Martes, 12 de Octubre del 2004 1:02 AM, Felix Kühling escribió:
I've uploaded a Xorg-modules.tar.bz2 to the snapshots/extras dir. It
contains all (strip -g) modules except the ones included in the binary
snapshots (libGLcore.a, libglx.a, libdri.a, all 2D and 3D drivers).
David, could you
On Mon, 11 Oct 2004, Ian Romanick wrote:
I was trying to test the latest version of my ReadPixels work to make sure I
didn't break anything on big-endian. However, it seems someone beat me to it
in the Rage128 driver. :) In a nutshell, I can get one frame of gears, and
then the 3D engine is
I just wanted to add a README.Xorg in
http://freedesktop.org/~dri/snapshots/extras when I noticed that there
are two older README.* files which do not show up in http. A new
README.Xorg didn't show up either. However adding an empty file with a
different name (I tried `touch xorgstuff`) was
On Tuesday 12 October 2004 04:04, Eric Anholt wrote:
New patch is at
http://pdx.freedesktop.org/~anholt/dri/r200-projtex-7.diff
snip
This one is nowhere near as thoroughly tested as previous ones. YMMV.
This cleans up doom3 in hwtcl quite a bit. Lighting is still messed up
though. Lights
Michel Dnzer wrote:
On Mon, 2004-10-11 at 18:37 -0700, Ian Romanick wrote:
I was trying to test the latest version of my ReadPixels work to make
sure I didn't break anything on big-endian. However, it seems someone
beat me to it in the Rage128 driver. :) In a nutshell, I can get one
frame of
Andreas Stenglein wrote:
It might be unrelated (and just some other silly mistake/problem):
Using my local version of radeon (r100) driver converted to t_vertex
I discovered a similar problem recently.
1) running glxgears I get the hang with only mousepointer moving - reboot needed.
I get the
Jon Smirl wrote:
http://kerneltrap.org/node/view/3980
Marcelo Tosatti [interview] released 2.4.28-pre4 with few changes
since -pre3 a month ago [story], it contains a number of driver
updates (pcnet, e1000, gdth, prism54), a network update from David,
few more gcc3.4 warning fixes. He noted that
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1374
[EMAIL PROTECTED] changed:
What|Removed |Added
On Tue, 2004-10-12 at 08:36, Ian Romanick wrote:
It's a stock AGP G4. The card is the original Rage128. The kernel is
the debian 2.6.8-powerpc kernel (dittor for DRM), and X is yesterday's
X.org. The last time I did anything with that machine was about a month
ago with a 2.4.25 kernel
Thomas Hellström wrote:
Also, the people on the unichrome site including me are totally lost
when it comes to 3D, and you'll need
a quite detailed documentation to fix things up. I guess the 3D command
verification will be
quite some work. The best would be to convince VIA that they would very
On Tue, 12 Oct 2004 09:40:36 -0700, Ian Romanick [EMAIL PROTECTED] wrote:
Given that, it seems reasonable to not implement drm-core for 2.4. If
we need to apply bug fixes to 2.4, we'll just have to figure out how to
back-port them to the old arch.
Backporting shouldn't be too hard since the
Hi, Ian!
Ian Romanick wrote:
Thomas Hellström wrote:
Also, the people on the unichrome site including me are totally lost
when it comes to 3D, and you'll need
a quite detailed documentation to fix things up. I guess the 3D
command verification will be
quite some work. The best would be to
Dieter Nützel wrote:
NONE of your three versions gave me direct rendering?!
I've tested with and without your TLS-patch (progress?).
The symbols are in.
DRI-Mesa/Patches nm /usr/X11R6-NO-TLS/lib/modules/dri/r200_dri.so | grep
r200ReadRGBASpan_ARGB
00175714 t r200ReadRGBASpan_ARGB
00175be4
On Tue, 12 Oct 2004, Felix [ISO-8859-1] Kühling wrote:
Is there something in the httpd configuration that makes README files
invisible in directory listings? Why would anyone want to hide README
files?
Yes, it is normal in default Apache HTTP configuration. See:
# ReadmeName is the name of
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1220
--- Additional Comments From [EMAIL PROTECTED] 2004-10-12 12:33 ---
(In reply
Am 2004.10.12 18:38:18 +0200 schrieb(en) Ian Romanick:
Andreas Stenglein wrote:
It might be unrelated (and just some other silly mistake/problem):
Using my local version of radeon (r100) driver converted to t_vertex
I discovered a similar problem recently.
1) running glxgears I get the
Eric Anholt wrote:
This one is nowhere near as thoroughly tested as previous ones. YMMV.
Certain textures in ut2k3/ut2k4 are still broken (all ground textures in
dm-antalus). Water reflection in the same map is also broken (this
worked in ut2k4 before (though I have some doubts the texcoords
On Maw, 2004-10-12 at 01:14, Dave Airlie wrote:
application so it could modify them after validation if it was sufficently
sneaky enough... for the mach64 the idea was to allocate a pool of private
buffers using pci interfaces and use those to pass command streams after
verification.. the user
I tried the 20041012 common+savage snapshots with the Xorg snapshots today.
The only problem I'm seeing is that direct rendering isn't enabled.
Xorg.0.log says that DRI is enabled.
Output of glxinfo with LIBGL_DEBUG=verbose:
name of display: :0.0
libGL: XF86DRIGetClientDriverName: 1.1.16 savage
On Wed, 13 Oct 2004 00:22:34 +0200, David [EMAIL PROTECTED] wrote:
I tried the 20041012 common+savage snapshots with the Xorg snapshots today.
The only problem I'm seeing is that direct rendering isn't enabled.
Xorg.0.log says that DRI is enabled.
Output of glxinfo with LIBGL_DEBUG=verbose
On Wed, 2004-10-13 at 00:41, Vladimir Dergachev wrote:
Just to check off the obvious, are you running a recent kernel with (I
assume framebuffer) ? It could be that the default might have changed to
configure the apertures to be bigendian.
Changed ? The apertures have always been BE on PPC
On Wed, 13 Oct 2004 00:22:34 +0200
David [EMAIL PROTECTED] wrote:
I tried the 20041012 common+savage snapshots with the Xorg snapshots today.
The only problem I'm seeing is that direct rendering isn't enabled.
Xorg.0.log says that DRI is enabled.
Output of glxinfo with LIBGL_DEBUG
While investigating rare Xserver (errno=22 in select) and X client
(losing X connection) crashes that seem to be related to the new
linux-core drm I found this in savage_dri.c and several other DDX
drivers:
...driverSwapMethod = DRI_HIDE_X_CONTEXT;
This seems to indicate that the Xserver is
On Tue, 2004-10-12 at 15:18, Roland Scheidegger wrote:
Eric Anholt wrote:
This one is nowhere near as thoroughly tested as previous ones. YMMV.
Certain textures in ut2k3/ut2k4 are still broken (all ground textures in
dm-antalus). Water reflection in the same map is also broken (this
On Wed, 2004-10-13 at 09:07 +1000, Benjamin Herrenschmidt wrote:
On Wed, 2004-10-13 at 00:41, Vladimir Dergachev wrote:
Just to check off the obvious, are you running a recent kernel with (I
assume framebuffer) ? It could be that the default might have changed to
configure the apertures
27 matches
Mail list logo
