Donnie Berkholz wrote:
> You might like to follow https://bugs.freedesktop.org/show_bug.cgi?id=943.
I'm now stuck again with a strange crash. DRI clients
such as glxgears and glxinfo crash inside malloc(),
probably due to memory corruption:
---cut---
#0 0x006dec48 in _int_malloc () from /lib/
Bernardo Innocenti wrote:
> Maybe the fields of RADEONInfoRec should be reworked
> to use types with a predefined size. Is that right?
I've just found out I didn't apply dri-32-compat.patch,
which already addresses this problem.
Sorry for the noise.
--
// Bernardo Innocenti - Develer S.r.l.
Bernardo Innocenti wrote:
> Now libGL works, but something else fails and 32bit
> clients fall back to indirect rendering:
After digging around with GDB, I can now elaborate a
bit more.
The call to drmMap() fails because it attempts to
map 0 bytes of memory. We're in r300/radeon_screen.c:radeon
Donnie Berkholz wrote:
> Bernardo Innocenti wrote:
>>>
>>>Is there a reason why this code is not appropriate for
>>>merging into the official DRM?
>
> You might like to follow https://bugs.freedesktop.org/show_bug.cgi?id=943.
Thank you! I fetched the latest patch and it applied
quite nicely to t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bernardo Innocenti wrote:
> Hello,
>
> I extracted this patch by Egbert Eich from SuSe's kernel
> source package:
>
> http://www.develer.com/drm-ioctl32.patch
>
> It allows running 32bit DRI clients on 64bit systems,
> which is a very common situat
Hello,
I extracted this patch by Egbert Eich from SuSe's kernel
source package:
http://www.develer.com/drm-ioctl32.patch
It allows running 32bit DRI clients on 64bit systems,
which is a very common situation due to proprietary
games.
Is there a reason why this code is not appropriate for
mergi
