http://bugs.freedesktop.org/show_bug.cgi?id=13494
[EMAIL PROTECTED] changed:
What|Removed |Added
AssignedTo|dri-|[EMAIL PROTECTED]
|
http://bugs.freedesktop.org/show_bug.cgi?id=13488
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEEDINFO|NEW
--
Configure bugmail: http://
http://bugs.freedesktop.org/show_bug.cgi?id=13507
--- Comment #3 from [EMAIL PROTECTED] 2007-12-05 22:19 PST ---
Could someone offer some insight into how to approach this damn bug? X just
crashed literally times in the last 5 minutes (once while trying to select
metacity as my window
http://bugs.freedesktop.org/show_bug.cgi?id=13507
--- Comment #2 from [EMAIL PROTECTED] 2007-12-05 21:15 PST ---
Created an attachment (id=12973)
--> (http://bugs.freedesktop.org/attachment.cgi?id=12973&action=view)
Another Xorg log
This one is probably very similar to the first. Ve
http://bugs.freedesktop.org/show_bug.cgi?id=13358
--- Comment #4 from [EMAIL PROTECTED] 2007-12-05 21:04 PST ---
I changed it from a specific driver to mesa core because this is happening with
software, and all the radeon drivers. This is also on the AMD64 platform with
xorg-server 1.
http://bugs.freedesktop.org/show_bug.cgi?id=13358
[EMAIL PROTECTED] changed:
What|Removed |Added
Component|Drivers/DRI/r300|Mesa core
--- Comment #3 from
http://bugs.freedesktop.org/show_bug.cgi?id=13543
--- Comment #1 from [EMAIL PROTECTED] 2007-12-05 18:42 PST ---
Created an attachment (id=12972)
--> (http://bugs.freedesktop.org/attachment.cgi?id=12972&action=view)
test case
With i915 driver, we got result:
draw pixel at (0, 0): 0
http://bugs.freedesktop.org/show_bug.cgi?id=13543
Summary: Draw bitmap incorrect if DepthFunc is GL_LESS
Product: Mesa
Version: CVS
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority:
http://bugs.freedesktop.org/show_bug.cgi?id=13327
--- Comment #4 from [EMAIL PROTECTED] 2007-12-05 17:05 PST ---
At the crash point, could you "print *texImage"?
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: -
On Wed, 2007-12-05 at 12:12 -0800, Ian Romanick wrote:
> It is probably worth bumping the minor (or the driver date) just to make
> it easier to determine what the user has installed when / if bug reports
> come in. Debugging possible interactions between pre-optimization vs.
> post-optimization
Since the _DRM_DRIVER mapping stuff went in, i915 has been panicing at
unload time. However, the driver appears to be correctly using the new
_DRM_DRIVER flag, so it's not immediately obvious what's going wrong.
This hacky workaround prevents the crash.
Jesse
diff --git a/shared-core/i915_dma
If drmMinor >= 6, the intel DDX driver will enable vblank events on both
pipes. If drmMinor >= 10 on pre-965 chipsets, the intel DDX driver
will swap the pipe<->plane mapping to allow for framebuffer compression
on laptop screens. This means the secondary vblank counter
(corresponding to pipe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Keith Packard wrote:
> Yes, it should be backward compatible. The req is smaller than the rep,
> so adding new members won't change the alignment. Also, as the flag
> indicates whether the additional data is present, older clients won't
> accidentally
Keith Packard wrote:
>On Wed, 2007-12-05 at 18:24 +0100, Thomas Hellström wrote:
>
>
>
>>I have nothing against wrapping the drm_bo_kmap() function with a
>>wait
>>for fence and another function name, but the current version is just a
>>convenience function to find the right pages to map and m
On Wed, 2007-12-05 at 18:24 +0100, Thomas Hellström wrote:
> I have nothing against wrapping the drm_bo_kmap() function with a
> wait
> for fence and another function name, but the current version is just a
> convenience function to find the right pages to map and map them in the
> right way,
http://bugs.freedesktop.org/show_bug.cgi?id=13391
--- Comment #6 from [EMAIL PROTECTED] 2007-12-05 09:35 PST ---
Well, it seems that the apparent cessation of crashes due to this bug was a
mere coincidence. Just in the last day, compiz has crashed 7 times.
Unfortunately, the server ra
Keith Packard wrote:
>On Wed, 2007-12-05 at 08:47 +0100, Thomas Hellström wrote:
>
>
>
>>In the case of a re-used batch-buffer, user-space mapping will wait for
>>the right fence before filling it, so when the buffer is submitted to
>>the super-ioctl and validated, it's put on the unfenced lis
On Wed, 2007-12-05 at 08:47 +0100, Thomas Hellström wrote:
> In the case of a re-used batch-buffer, user-space mapping will wait for
> the right fence before filling it, so when the buffer is submitted to
> the super-ioctl and validated, it's put on the unfenced list, cannot
> move while patch
On Wed, 2007-12-05 at 10:48 +0100, Thomas Hellström wrote:
> Ugh, Actually I do think we need to bump major.
> Consider the case with an old client and a new kernel;
> the new kernel will copy the new size whereas the old client provides
> only the old size, which may
> lead to copy_from_user()
http://bugs.freedesktop.org/show_bug.cgi?id=13527
--- Comment #8 from [EMAIL PROTECTED] 2007-12-05 06:30 PST ---
That patch fixes it for HomeworldSDL, thanks.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because:
Thomas Hellström wrote:
>
>>
>>> Is this meant to be backwards compatible with an older kernel? In
>>> that case
>>> we should bump DRM_BO_INIT_MINOR. If not, we should put the new
>>> member with the other 64-bit members at the top of the struct and
>>> bump DRM_BO_INIT_MAJOR.
>>>
>>
>> Yes,
http://bugs.freedesktop.org/show_bug.cgi?id=13442
[EMAIL PROTECTED] changed:
What|Removed |Added
Summary|[i965-TTM]mesa demo |[GM965 TTM]mesa demo
http://bugs.freedesktop.org/show_bug.cgi?id=13442
--- Comment #4 from [EMAIL PROTECTED] 2007-12-05 00:26 PST ---
this case run normally on g965 .
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are
23 matches
Mail list logo
