> c040-c043 : eth1
> d000-dfff : :00:00.0
> e000-e7ff : PCI Bus #01
> e000-e7ff : :01:00.0
> e000-e059b8bf : vesafb
this is the culprit .. vesafb is loaded...
Jon can you figure out what do in this situation?
Dave.
> ff80- : reserv
> > However, I can draw accelerated rectangles, pixmaps, lines, polygons (I
> > haven't quite worked the stipple out as yet), alpha blending, gradients
> > et al. And acceleration on this card is, well, SGI standard :)
> Have you figured out enough to do basic 3D accel as well?
Yes, but setup has
On Thu, Aug 19, 2004 at 09:13:44AM -0400, Robert S. Kerr wrote:
> If that turns out to be right, my next adventure is to figure out how to
> debug a running driver. Pointing gdb at my rotyuv process doesn't let
> me look down into the XvShmPutImage method. Suggestions are welcome.
Debian at le
Dave Airlie <[EMAIL PROTECTED]> writes:
> can you insert the module with drm_opts=debug option and see what it
> says..
[drm] Debug messages ON
ACPI: PCI interrupt :01:00.0[A] -> GSI 4 (level, low) -> IRQ 4
[drm:radeon_register_regions] *ERROR* cannot reserve FB region
Unable to handle kernel
This patch adds two new ioctl's to the VIA Unichrome/Pro DRM driver:
DRM_IOCTL_VIA_DMA_INIT
DRM_IOCTL_VIA_CMDBUFFER
The first call sets up an area in AGP memory that will be used as the
ring buffer. The second call copies a command buffer from user space
memory to the ring buffer
El Jueves, 19 de Agosto del 2004 3:13 PM, Robert S. Kerr escribiÃ:
> >Yep. In a small window the image shows right. In medium windows there are
> > 2 "zones". In a fullscreen window (1024x768) I can see 3 zones.
> >It's strange that nobody noticed it before.
>
> I've been experimenting with this pr
Since there was a discussion of DRIVER_DATE some time ago and
it seemed like this should be updated with every modification
to the driver here is the patch with the driver date updated.
Philipp Klaus Krause
65c65
< #define DRIVER_DATE "20030328"
---
> #define DRIVER_DATE &q
Attached are patches to enable support for GL_ARB_vertex_program in the
r200 driver. I've tested it on my Radeon 9000 Pro and found no problems.
I decided against including support for GL_NV_vertex_program, since
the only programs that support the NV version but not the ARB one are
some Nvidia demo
On Thu, 19 Aug 2004 10:11:36 -0400, Robert S. Kerr <[EMAIL PROTECTED]> wrote:
> Alex Deucher wrote:
>
> >On Thu, 19 Aug 2004 09:13:44 -0400, Robert S. Kerr <[EMAIL PROTECTED]> wrote:
> >
> >
> >>I've been experimenting with this problem a bit and I'm pretty sure at
> >>this point it relates to som
Alex Deucher wrote:
On Thu, 19 Aug 2004 09:13:44 -0400, Robert S. Kerr <[EMAIL PROTECTED]> wrote:
I've been experimenting with this problem a bit and I'm pretty sure at
this point it relates to something in the horizontal scaling portions of
the savage Xv stuff. I found a simple program
(http:/
On Thu, 19 Aug 2004 09:13:44 -0400, Robert S. Kerr <[EMAIL PROTECTED]> wrote:
>
> >Yep. In a small window the image shows right. In medium windows there are 2
> >"zones". In a fullscreen window (1024x768) I can see 3 zones.
> >It's strange that nobody noticed it before.
> >
> >
>
> I've been expe
On Thu, 19 Aug 2004 08:10:57 +0200 (MET DST), Stanislaw Skowronek
<[EMAIL PROTECTED]> wrote:
> Hello!
>
> I would like to make a SGI Octane (ImpactSR) X driver. The problem with
> this device is that it is a pure graphics pipeline, i.e. there is no
> directly mapped access to the framebuffer.
>
>
Yep. In a small window the image shows right. In medium windows there are 2
"zones". In a fullscreen window (1024x768) I can see 3 zones.
It's strange that nobody noticed it before.
I've been experimenting with this problem a bit and I'm pretty sure at
this point it relates to something in th
Okay I've removed nearly every macro I can from the drmfntbl-0-0-2-branch.
The two remaining things are the IOCTLS and COUNTERS stuff, I think I
might merge fntbl-0-0-2 back to HEAD and maybe tackle those two last ones
in a third and final drmfntbl-0-0-3-branch.
I can defo say two things, gamma
Dave Airlie wrote:
That would be fine with me... Dave, AlanH, has the moment arrived?
Okay I'll stick with chopping it, what the best way to go about it - will
I just let it break naturally (that'll take about 5 mins...) or will I
actively remove it?
Removing it would be cleaner, but either way's
How does this function work?
To me it seems it assigns undefined things to
members of a vfmt struct.
I didn't see things like r200_Fallback_DrawElements
anywhere else in the code.
I looked at this since I tried enabling GL_EXT_multi_draw_arrays
and get crashes (an assertion fails in t_array_api.c:3
> >
>
> That would be fine with me... Dave, AlanH, has the moment arrived?
Okay I'll stick with chopping it, what the best way to go about it - will
I just let it break naturally (that'll take about 5 mins...) or will I
actively remove it?
What about the kernel one, can I just mark it as broken?
On Wed, 18 Aug 2004 18:09:44 +0200, Philipp Klaus Krause <[EMAIL PROTECTED]> wrote:
> I've just added vertex program support to the r200 driver.
> It uses the software emulation Mesa provies, though the
> hardware could do accelerated vertex programs.
Thats really cool.
--
Patrick "Diablo-D3" Mc
18 matches
Mail list logo
