Hi,
there were 2 reports from snapshot users on dri-users that DRI was
disabled with the new configuration stuff. In at least one case the
problem was that libexpat was not installed on the system. Could the
snapshot build be changed to link the drivers statically with libexpat?
In either case
On Thu, Oct 09, 2003 at 06:36:11PM +0100, Keith Whitwell wrote:
Alan Hourihane wrote:
On Thu, Oct 09, 2003 at 05:30:08PM +0100, Keith Whitwell wrote:
Alan Hourihane wrote:
I've just committed a version of the DRI's common code mm.[ch] linear
allocator
into the XFree86 CVS which extends
Felix,
On Fri, Oct 10, 2003 at 10:06:51AM +0200, Felix Kühling wrote:
Hi,
there were 2 reports from snapshot users on dri-users that DRI was
disabled with the new configuration stuff. In at least one case the
problem was that libexpat was not installed on the system. Could the
snapshot
Alan Hourihane wrote:
On Thu, Oct 09, 2003 at 06:36:11PM +0100, Keith Whitwell wrote:
Alan Hourihane wrote:
On Thu, Oct 09, 2003 at 05:30:08PM +0100, Keith Whitwell wrote:
Alan Hourihane wrote:
I've just committed a version of the DRI's common code mm.[ch] linear
allocator
into the XFree86
On Fri, 10 Oct 2003 10:17:23 +0100
José Fonseca [EMAIL PROTECTED] wrote:
Felix,
On Fri, Oct 10, 2003 at 10:06:51AM +0200, Felix Kühling wrote:
Hi,
there were 2 reports from snapshot users on dri-users that DRI was
disabled with the new configuration stuff. In at least one case the
On Fri, Oct 10, 2003 at 11:16:06AM +0100, Keith Whitwell wrote:
Alan Hourihane wrote:
On Thu, Oct 09, 2003 at 06:36:11PM +0100, Keith Whitwell wrote:
Alan Hourihane wrote:
On Thu, Oct 09, 2003 at 05:30:08PM +0100, Keith Whitwell wrote:
Alan Hourihane wrote:
I've just committed a
Right. And certainly now with the new linear allocator the Xserver can
manage the whole lot.
Does the X server make any promises about preserving the contents of the fb
memory? EG, if there's a VT switch, will the contents be saved somehow?
No. No preservation is done. We need to invalidate
On Fri, Oct 10, 2003 at 12:24:56PM +0100, Keith Whitwell wrote:
Right. And certainly now with the new linear allocator the Xserver can
manage the whole lot.
Does the X server make any promises about preserving the contents of the
fb memory? EG, if there's a VT switch, will the contents
Could some of the developers check out the playable demo?
There seems to be an agp memory initialisation bug.
one of the authors claims this is due to lacking s3tc support, even when
I follow steps to disable all texture compression in the config file, I
keep getting the agp memory initialisation
On Fri, Oct 10, 2003 at 12:24:56PM +0100, Keith Whitwell wrote:
|
| No. No preservation is done. We need to invalidate everything.
|
| That's a problem, as the only way we can do things like accelerated
| CopyTexSubImage() and single-copy textures is if the FB contents are
| guarenteed to be
Allen Akin wrote:
Besides performance loss and memory bloat, the lack of framebuffer
memory preservation on Windows has forced some new extensions to have
ugly semantics. See the vertex buffer object extension
http://oss.sgi.com/projects/ogl-sample/registry/ARB/vertex_buffer_object.txt
for
Right. And certainly now with the new linear allocator the Xserver can
manage the whole lot.
Does the X server make any promises about preserving the contents of the
fb memory? EG, if there's a VT switch, will the contents be saved
somehow?
No. No preservation is done. We need to invalidate
On Iau, 2003-10-09 at 17:16, Alan Hourihane wrote:
I've just committed a version of the DRI's common code mm.[ch] linear allocator
into the XFree86 CVS which extends the FBManager's ability to serve
real linear space rather than pinching it from the XY area's that's
usually occupied by the
On Gwe, 2003-10-10 at 23:16, Ian Romanick wrote:
on some it's dumped but the driver has a change to back it up, and on
others it's just dumped.
AFAIK, perhaps someone can correct me, XFree86 on Linux falls into the
last category.
It depends on the BIOS and other factors. For ACPI it is
On Fri, Oct 10, 2003 at 11:24:24PM +0100, Alan Cox wrote:
On Iau, 2003-10-09 at 17:16, Alan Hourihane wrote:
I've just committed a version of the DRI's common code mm.[ch] linear allocator
into the XFree86 CVS which extends the FBManager's ability to serve
real linear space rather than
On Fri, Oct 10, 2003 at 11:24:24PM +0100, Alan Cox wrote:
On Iau, 2003-10-09 at 17:16, Alan Hourihane wrote:
I've just committed a version of the DRI's common code mm.[ch] linear allocator
into the XFree86 CVS which extends the FBManager's ability to serve
real linear space rather than
On Thu, 2003-10-09 at 22:05, Felix Khling wrote:
earlier today I finally merged the config-0-0-1-branch into the trunk.
Congratulations for the good work!
This means that most environment variables stop working [...]
How hard do you think it would be to allow options to be overridden by
On Fri, 2003-10-10 at 11:29, Helge Hafting wrote:
It hangs at a black screen now, I don't get to play around
with the cursor for a few seconds first.
I mounted /var synchronously so I got a logfile. It
is attached as X-dri-log.
I don't see anything suspicious, this looks like a perfectly
On Fri, Oct 10, 2003 at 03:16:45PM -0700, Ian Romanick wrote:
|
| Since I was part of that working group, I'd like to clarify why some of
| those decisions were made. ...
Apologies if I sounded too critical -- I agree that compromise was a
reasonable thing to do in the VBO case.
|
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://bugs.xfree86.org/show_bug.cgi?id=778
[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 your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=778
--- Additional Comments From [EMAIL PROTECTED] 2003-11-10 01:46 ---
Patch should be
The locking problem is solved, my original analysis was incorrect. The
problem was that DRM_CAS was not correctly implemented on IA64. Thus
this was an IA64 issue only, this is consistent with others who showed
up in a google search describing the problem, all were on IA64.
I have filed an
John Dennis wrote:
The locking problem is solved, my original analysis was incorrect. The
problem was that DRM_CAS was not correctly implemented on IA64. Thus
this was an IA64 issue only, this is consistent with others who showed
up in a google search describing the problem, all were on IA64.
I
23 matches
Mail list logo
