Please apply this to the DRI codebase. Also forwarding it to
XFree86.
--
Mike A. Harris Shipping/mailing address:
OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie,
XFree86 maintainer Ontario, Canada, P6C 5B3
Red Hat Inc.
http://www.redhat.co
Currently running Linux GL programs on FreeBSD doesn't work for most
people because xf86drm.c checks to see if the dri device has the major
number expected. When using linux *_dri.so's (which use this code) they
find the FreeBSD dri device, which has a different number, so it either
fails if non-
On Tue, 2002-07-09 at 01:39, Mike Mestnik wrote:
> --- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> > On Mon, 2002-07-08 at 20:17, Tim Smith wrote:
> > > On Monday 08 Jul 2002 12:49 am, Michel Dänzer scribed numinously:"
> > >
> > > > The scratch register values need to be read with DRM_READ32(),
On Tue, 2002-07-09 at 03:08, Damien Miller wrote:
> On Mon, 2002-07-08 at 20:58, Michel Dänzer wrote:
>
> > > 2) when is the GATOS code planned for merging?
> >
> > Never with the DRI repository directly. Apparently their Mach64 stuff is
> > getting merged into XFree86 for 4.3.0, don't know abo
--- Eric Anholt <[EMAIL PROTECTED]> wrote:
> Currently running Linux GL programs on FreeBSD doesn't work for most
> people because xf86drm.c checks to see if the dri device has the major
> number expected. When using linux *_dri.so's (which use this code) they
> find the FreeBSD dri device, whic
First I would like to apoligize for missing the last two IRC meetings.
There was no noble reason whatsoever - I completely forgot it.
Although this is no excuse, I would like to request that a notification
message is always sent to this mailing list - as it was often done -, even if
it's sent jus
On Tue, 2002-07-09 at 15:04, Mike Mestnik wrote:
> I'm using the new linux devfs and It seams to me that the DRI can't at this time use
>devfs the way
> it should. If i'm not mistaken the kernel module dosen't realy know how to find
>supported cards,
> it leaves that to the Xserver. If some on
On Mon, 2002-07-08 at 18:36, David Willmore wrote:
> Log bits:
> (--) PCI:*(1:0:0) S3 ViRGE/MX rev 6, Mem @ 0x4000/26
> (II) LoadModule: "s3virge"
> (II) Loading /usr/X11R6/lib/modules/drivers/s3virge_drv.o
> (II) Module s3virge: vendor="The XFree86 Project"
> compiled for 4.2.0, module
--- Eric Anholt <[EMAIL PROTECTED]> wrote:
> On Tue, 2002-07-09 at 15:04, Mike Mestnik wrote:
> > I'm using the new linux devfs and It seams to me that the DRI can't at this time
>use devfs the
> way
> > it should. If i'm not mistaken the kernel module dosen't realy know how to find
>supported
On Tue, 2002-07-09 at 18:29, Mike Mestnik wrote:
> I'v looked into this, it seams that the tdfx driver dose something simular to
>FreeBSD. The code
> in drm_drv.h could be adapted to create the device nodes, via devfs. The current
>linux setup just
> allocates 1 minor number, more is supported
> I'm planing on
> having DRISUP_BOTH, DRISUP_BSD, DRISUP_LINUX, DRISUP_NONE
> defined for the 3rd element.
I dont like the "both" thing. The design looks for me rather
like a bitfild than an enum... so this would be the solution:
(DRISUP_BSD | DRISUP_LINUX)
a DRISUP_ALL would make more s
--- Alexander Stohr <[EMAIL PROTECTED]> wrote:
> > I'm planing on
> > having DRISUP_BOTH, DRISUP_BSD, DRISUP_LINUX, DRISUP_NONE
> > defined for the 3rd element.
>
> I dont like the "both" thing. The design looks for me rather
> like a bitfild than an enum... so this would be the solution:
>
On Tue, 9 Jul 2002, José Fonseca wrote:
>Date: Tue, 9 Jul 2002 22:09:58 +0100
>From: José Fonseca <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Content-Type: text/plain; charset=iso-8859-1
>List-Id:
>Subject: IRC Meetings & ML notification
>
>First I would like to apoligize for missing the last tw
13 matches
Mail list logo
