On Mon, 2005-09-26 at 01:54 +0100, Dave Airlie wrote:
> I was talking to Ben on IRC about this and I realised I wasn't really sure
> about this..
>
> At the moment we allow the DRI client full r/w access to the framebuffer
> if I'm not mistaken (for software fallbacks and the like)..
>
> If I put
I was talking to Ben on IRC about this and I realised I wasn't really sure
about this..
At the moment we allow the DRI client full r/w access to the framebuffer
if I'm not mistaken (for software fallbacks and the like)..
If I put the PCIE GART table into fb memory (which I've no choice in), the
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://bugs.freedesktop.org/show_bug.cgi?id=4590
Summary: SegFault with glxinfo in savage_xmesa.c
Product: DRI
Alan Cox wrote:
On Sul, 2005-09-25 at 15:06 +0200, Thomas Hellstrom wrote:
*VIA docs are rumored to require the (src_addr%4 == dest_addr%4) for all
lines, and this is what is implemented as a sanity check. However,
apparently there is a bug in the chip that also requires (system_
On Sul, 2005-09-25 at 15:06 +0200, Thomas Hellstrom wrote:
> *VIA docs are rumored to require the (src_addr%4 == dest_addr%4) for all
> lines, and this is what is implemented as a sanity check. However,
> apparently there is a bug in the chip that also requires (system_addr&15
> == 0) for all li
On Sun, 2005-09-25 at 00:56 +0100, Dave Airlie wrote:
> >
> > drivers/char/drm/drmP.h defines a macro DRM_ARRAY_SIZE(x) for
> > determining the size of an array. kernel.h already provides one.
> >
> > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
>
> Nak.
>
> We have DRM_ for cross platform
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://bugs.freedesktop.org/show_bug.cgi?id=4508
--- Additional Comments From [EMAIL PROTECTED] 2005-09-25 07:18 ---
How e
Hi.
I've now commited the via PCI DMA bitblt code to DRM CVS
The first client will probably be Xv image transfer.
Some caveats:
*Needs porting to FreeBSD.
*Transfer rate is not very fast. About 50MB/s including building and
destroying mappings. The big gain is transferring from frame-buffer to
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://bugs.freedesktop.org/show_bug.cgi?id=2164
[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://bugs.freedesktop.org/show_bug.cgi?id=2164
[EMAIL PROTECTED] changed:
What|Removed |Added
--
>
> ok so this brings the question: how does naming it DRM_ARRAY_SIZE make
> it more portable than naming it ARRAY_SIZE?
> If *BSD doesn't have ARRAY_SIZE, then surely naming it ARRAY_SIZE is
> easy for them to provide (after all they need to provide it already just
> called DRM_ARRAY_SIZE); if th
11 matches
Mail list logo