http://dri.sourceforge.net/cgi-bin/moin.cgi/Building mentions a
buildtools.patch, is this still required for xorg cvs?
--
Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED]
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd
all be running around in darkened rooms, mu
Really ? Both the register and the framebuffer apertures ?
The reason I am asking as ati driver has some code to invert the
endianness for writing Xv data to the framebuffer.
No, only framebuffer, and we used, iirc, to switch the card's swapper
off when writing Xv data (maybe we just swap the data
Hi. Sorry to be too picky, but I've found that after the Xv fix 4 pixels are
missing on the right side of the screen.
You can check a sample image to test this here (please do not abuse the
server):
http://webs.ono.com/deifo/fullscreen-test.png
Put the image as a wallpaper at 1024x768x16 and se
On Thu, 2004-10-14 at 00:27, Vladimir Dergachev wrote:
> On Wed, 13 Oct 2004, 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 d
Michel DÃnzer wrote:
Anyway, I think we're on a tangent here, as the problem doesn't seem to
be PPC specific at all.
I dug out the Rage 128 that I have for the PC, and it works just fine.
glxgears, readpix, all of it. :(
The PCI ID on on the PC version is 1002:5046, and on the Mac it's
1002:5246
On Wed, 2004-10-13 at 19:42 +0200, Felix KÃhling wrote:
> Am Mi, den 13.10.2004 schrieb Jon Smirl um 18:53:
> > I just changed DRM to alternative between zero and POLLIN This
> > will make the DRM poll() function work like the kernel expects it to
> > and still work with existing X servers. Can
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
Felix Kühling wrote:
Am Mi, den 13.10.2004 schrieb Jon Smirl um 18:53:
I just changed DRM to alternative between zero and POLLIN This
will make the DRM poll() function work like the kernel expects it to
and still work with existing X servers. Can someone please get this
incorrect code out of th
Am Mi, den 13.10.2004 schrieb Jon Smirl um 18:53:
> I just changed DRM to alternative between zero and POLLIN This
> will make the DRM poll() function work like the kernel expects it to
> and still work with existing X servers. Can someone please get this
> incorrect code out of the X server?
I just changed DRM to alternative between zero and POLLIN This
will make the DRM poll() function work like the kernel expects it to
and still work with existing X servers. Can someone please get this
incorrect code out of the X server?
On Wed, 13 Oct 2004 16:39:27 +0100, Keith Whitwell
<[EMAIL
On Wed, 13 Oct 2004 16:39:27 +0100, Keith Whitwell
<[EMAIL PROTECTED]> wrote:
> So, it's not really an unimplemented poll() function, but the
> backwards-compatible ghost of a real communications channel which is still
> polled, but never written to.
One way to fix this would be to alternately ret
On Wed, 2004-10-13 at 10:27 -0400, Vladimir Dergachev wrote:
>
> On Wed, 13 Oct 2004, 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 t
Jon Smirl wrote:
On Wed, 13 Oct 2004 10:13:50 +0100, Keith Whitwell
<[EMAIL PROTECTED]> wrote:
Felix Kühling wrote:
I think the reason that you are experiencing failures is because the X server
is trying to read or poll the drm filehandle, but Jon has recently changed the
behaviour of that filehand
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=980
[EMAIL PROTECTED] changed:
What|Removed |Added
-
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=1623
Summary: GL_CALL fixes in radeon_subset_bitmap.c
Product: Mesa
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=1623
--- Additional Comments From [EMAIL PROTECTED] 2004-10-13 07:52 ---
Created an
On Wed, 13 Oct 2004, 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 to be bigendian.
Changed
On Wed, 13 Oct 2004 10:13:50 +0100, Keith Whitwell
<[EMAIL PROTECTED]> wrote:
> Felix Kühling wrote:
> I think the reason that you are experiencing failures is because the X server
> is trying to read or poll the drm filehandle, but Jon has recently changed the
> behaviour of that filehandle to ret
Eric Anholt wrote:
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 were actually correct but it looked at least somewhat
reasonable) but didn't
Felix Kühling wrote:
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 tha
Am 2004.10.12 03:37:05 +0200 schrieb(en) Ian Romanick:
> 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 th
21 matches
Mail list logo
