Keith Whitwell wrote:
>
> David Dawes wrote:
> >
> > I guess that if the HW-independent component is just a mechanism
> > for passing them transparently through to the kernel component (or
> > equivalent), then that is workable providing all different OS
> > implementations of the kernel componen
On Fri, 29 Mar 2002, Felix Kühling wrote:
> Hi,
>
> when I move a gl window to the right and/or bottom edge of the screen,
> a one pixel wide line/row is not redrawn correctly. Sometimes parts of
> previous frames remain visible and even hide new stuff. It looks to me
> as if the z-buffer is not
Hi,
when I move a gl window to the right and/or bottom edge of the screen,
a one pixel wide line/row is not redrawn correctly. Sometimes parts of
previous frames remain visible and even hide new stuff. It looks to me
as if the z-buffer is not cleared in that line/row.
I can reproduce the problem
>
> This assumes that using OS-independent tokens (like those below),
> and any associated data structures, can be accepted by a HW-independent
> layer (drmCOMMAND) and executed correctly.
>
> I guess that if the HW-independent component is just a mechanism
> for passing them transparently thro
On Thu, Mar 28, 2002 at 12:53:06PM -0800, Ian Romanick wrote:
> #0 0x4309fb0a in CreateContext (dpy=0x8075708, vis=0x0, shareList=0x0,
> allowDirect=1, contextID=0) at glxcmds.c:165
> #1 0x4309fc5d in glXCreateContext (dpy=0x8075708, vis=0x0, shareList=0x0,
> allowDirect=1) at glxcmds.c
On Thu, Mar 28, 2002 at 02:28:26PM -0700, Jens Owen wrote:
>David, Alan, Jeff and Kevin,
>
>I understand you would prefer a class of modules that are both HW
>specific and OS specific. Currently, the number of OS's supporting the
>DRM is 2; and the number of OS's the IHV's care about is 1 (linux
David, Alan, Jeff and Kevin,
I understand you would prefer a class of modules that are both HW
specific and OS specific. Currently, the number of OS's supporting the
DRM is 2; and the number of OS's the IHV's care about is 1 (linux x86 to
be specific). So, there is no short term problem with pe
> Anyone who has a licensed copy of Maya and would be interested in
> testing with the new TCL version of the Radeon driver, please send me an
> e-mail.
>
> We'd really like to get some basic Maya testing before approaching AW
> regarding support.
I now have a license for Maya 4.5beta1, and I ha
Alan Hourihane wrote:
>
> On Wed, Mar 27, 2002 at 07:22:40 -0700, Jens Owen wrote:
>
> I'll use the Linux DRM semantics which are:
> >
> > ( (direction) << 30 | (size) << 16 | (type) << 8 | (request) << 0 )
> >
> > where
> >
> > direction is: 0 for none, 1 for write, 2 for read and 3 for both
>
On Thu, Mar 28, 2002 at 10:35:16AM -0700, Jens Owen wrote:
> Alan Hourihane wrote:
> >
> > On Fri, Mar 22, 2002 at 08:03:29 -0700, Jens Owen wrote:
> > > Alan Hourihane wrote:
> > > >
> > > > On Fri, Mar 15, 2002 at 08:38:20AM -0700, Jens Owen wrote:
> > > > > I would like to move the device depe
Alan Hourihane wrote:
>
> On Fri, Mar 22, 2002 at 08:03:29 -0700, Jens Owen wrote:
> > Alan Hourihane wrote:
> > >
> > > On Fri, Mar 15, 2002 at 08:38:20AM -0700, Jens Owen wrote:
> > > > I would like to move the device dependent functionality currently
> > > > included in the drm library back in
Jeff Hartmann wrote:
> The basic point of this exercise is to make it so we can hot swap driver
> suites (or at least I'm pretty sure this is your goal.)
Yes.
> Why don't we just
> make each device have its own xfree module for its os specific part?
In an ideal world, we would have N OS indep
Hi,
> > I also tried the OpenGL Tutorials by Nate Robins from
> > http://www.xmission.com/~nate/tutors.html. When I start it the
> second
> > or later time after a fresh Xserver start it doesn't fill the entire
> > window. I can see through in the bottom of the window of, e.g. the
> fog
> > tutor
On Thu, Mar 28, 2002 at 11:15:25 -0500, David Dawes wrote:
> I'm losing track of what the goal was with the changes. If it was
> to remove hw-specifics from the libdrm.a module, then I think Jeff's
> idea of pushing them into a separate HW-specific module is worth looking at.
> By doing this, it
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Kevin E
Martin
Sent: Thursday, March 28, 2002 8:25 AM
To: David Dawes
Cc: dri-devel
Subject: Re: [Dri-devel] Restoring DRM Library Device Independence
> I'm losing track of what the goal was with the chan
On Thu, Mar 28, 2002 at 11:15:25AM -0500, David Dawes wrote:
> On Thu, Mar 28, 2002 at 09:31:40AM +, Alan Hourihane wrote:
> >On Wed, Mar 27, 2002 at 07:22:40 -0700, Jens Owen wrote:
>
> >Also, we should be able to hide the type in the Linux os support and
> >not need to pass this ?
> >
> >I'
On Thu, Mar 28, 2002 at 09:31:40AM +, Alan Hourihane wrote:
>On Wed, Mar 27, 2002 at 07:22:40 -0700, Jens Owen wrote:
>Also, we should be able to hide the type in the Linux os support and
>not need to pass this ?
>
>I've just taken a closer look at the xf86drmRadeon.c code, and in
>drmRadeonC
> I found that calls to TexParameter were not setting the texture wrapping
> and texture filter in some cases (where the driver private texture object
> struct had not already been allocated). This is now fixed and solves the
> following bugs:
Well done! It seems armagetron is really fixed.
S
To be a bit more specific the 2.4.x sound system now loads something
like (on my system)
soundcore.o ~ drm_core.o
cs46xx.o ~ drm_radeon.o
(plus codec modules)
Mike
Michael wrote:
>
> On Thu, Mar 28, 2002 at 10:13:04AM +, Keith Whitwell wrote:
> > Linus is pretty clear that he
On Thu, Mar 28, 2002 at 10:13:04AM +, Keith Whitwell wrote:
> Linus is pretty clear that he'd only accept a single module per driver - ie a
> radeon.o, but not a drm_core.o + drm_radeon.o combo.
He hasn't seen alsa or usb then...:)
--
Michael.
__
> > > We can already load a kernel module based on name via drmOpenByName,
> > > we could just implement another drmSubOpenByName command to load the sub
> > > module based on it's name.
>
Sorry, got mixed up by this paragraph.
Keith
___
Dri-devel m
On Thu, Mar 28, 2002 at 10:13:04 +, Keith Whitwell wrote:
> Alan Hourihane wrote:
> >
> > On Wed, Mar 27, 2002 at 07:22:40 -0700, Jens Owen wrote:
> > > Alan Hourihane wrote:
> > > >
> > > > On Tue, Mar 26, 2002 at 10:36:41PM -0700, Jens Owen wrote:
> > > > > I've made some headway on this to
Alan Hourihane wrote:
>
> On Wed, Mar 27, 2002 at 07:22:40 -0700, Jens Owen wrote:
> > Alan Hourihane wrote:
> > >
> > > On Tue, Mar 26, 2002 at 10:36:41PM -0700, Jens Owen wrote:
> > > > I've made some headway on this today, and could use some feedback based
> > > > on your BSD experience. I've
On Wed, Mar 27, 2002 at 07:22:40 -0700, Jens Owen wrote:
> Alan Hourihane wrote:
> >
> > On Tue, Mar 26, 2002 at 10:36:41PM -0700, Jens Owen wrote:
> > > I've made some headway on this today, and could use some feedback based
> > > on your BSD experience. I've attempted to move the packing of
>
Ian Romanick wrote:
>
> On Wed, Mar 27, 2002 at 10:53:48PM +, Keith Whitwell wrote:
>
> > Actually I think the test is correct, and that I was thinking of 16 bit
> > textures plus a full set of mipmaps at the time. Thus the numbers should be
> > doubled in the 32 bit case, rather than halve
On Wed, Mar 27, 2002 at 10:25:18 -0800, Jeff Hartmann wrote:
> Heres just a thought...
>
> When we added the usage of device specific ioctls we just linked them into
> the drm library because that was convient at the time. I think keeping this
> code os dependant is probably a good idea. This gi
26 matches
Mail list logo
