On Tue, Mar 16, 2004 at 05:00:37PM -0800, Jon Smirl wrote:
>I've started putting the DRM files into a drm module in the dri project. I'm
>copying the v files so that we will maintain history.
>
>Imakefile isn't needed in the new scheme, right, so I don't need a copy in the
>new project?
>
>I also
On Mon, Mar 01, 2004 at 07:43:51PM -0700, [EMAIL PROTECTED] wrote:
>> On Mon, Mar 01, 2004 at 06:44:38PM +, Alan Cox wrote:
>>>On Llu, 2004-03-01 at 14:34, Adam K Kirchhoff wrote:
The client libraries are still distributed under the old license, so
there is no problem linking GPLed li
On Mon, Mar 01, 2004 at 06:44:38PM +, Alan Cox wrote:
>On Llu, 2004-03-01 at 14:34, Adam K Kirchhoff wrote:
>> The client libraries are still distributed under the old license, so there
>> is no problem linking GPLed libraries or apps to the 4.4 libraries. Which
>> means there is no longer a r
On Mon, Mar 01, 2004 at 02:15:13PM +, Alan Hourihane wrote:
>On Mon, Mar 01, 2004 at 02:37:37PM +0100, Dieter Nützel wrote:
>> Someone preparing a merge?
>
>Possibly,
>
>for the binary packages we need to include the LICENSE documents.
Including the LICENSE documents is, strictly speaking, req
On Mon, Mar 01, 2004 at 09:34:57AM -0500, Adam K Kirchhoff wrote:
>
>On Mon, 1 Mar 2004, Alan Swanson wrote:
>
>> On Mon, 2004-03-01 at 13:37, Dieter Nützel wrote:
>> > Someone preparing a merge?
>>
>> To which release?
>>
>> The official 4.4 release that Red Hat, SUSE, Debian, Mandrake, Gentoo
>>
/span data.
I've attached a version of the patch relative to the XFree86 version of
this code, which I'm also committing there. Have there been any further
updates on this?
David
--
David Dawes
developer/release engineer The XFree86 Project
www.XFree86.org/~dawes
&g
On Tue, Jan 27, 2004 at 07:52:32PM +, Alan Hourihane wrote:
>On Tue, Jan 27, 2004 at 02:21:42PM -0500, David Dawes wrote:
>> On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote:
>> >On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote:
>> >>
On Tue, Jan 27, 2004 at 06:45:10PM +, Alan Hourihane wrote:
>On Tue, Jan 27, 2004 at 12:37:51PM -0500, David Dawes wrote:
>> There are quite a few Radeon-related bugs still outstanding in
>> bugs.xfree86.org, including several related to DRI lockups.
>>
>>
There are quite a few Radeon-related bugs still outstanding in
bugs.xfree86.org, including several related to DRI lockups.
Has anyone followed them up?
David
--
David Dawes
developer/release engineer The XFree86 Project
www.XFree86.org/~dawes
) ( uint64_t * ust );
David
--
David Dawes
developer/release engineer The XFree86 Project
www.XFree86.org/~dawes
---
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and
at it shouldn't be given to a newly inserted
device?
Also, I think that unmapped PCI ROMs are only mapped in (to PCI and user
space) by XFree86 long enough to read their contents, but I'd need to
double check that.
I'm sure I'm missing something. I'm just trying to fig
in X. Mapping
>the ROM in from user space without the kernel's knowledge is asking for trouble
>on hotplug systems.
How is it possible to map the ROM into user space without the kernel's
knowledge?
David
--
David Dawes
developer/release engineerT
t;
>
>--- Additional Comments From [EMAIL PROTECTED] 2003-07-11 06:30 ---
>So why this bug is closed? This is METABUG
It is closed because it is neither a bug report or a submission, and is
irrelevant to anyone tracking bugs for a release. This type of stuff
belongs in your w
OMs in without
>informing the kernel and that can definitely cause problems. I'm looking at
>adding the resource marking code right now.
Can't the kernel figure out which resources are mapped by user-land by
monitoring mmaps of /dev/mem or the /proc/bus/pci/... nodes?
David
--
ologies in the Linux
kernel, each struggling for supremacy. Come back to us when you know
who the winner is. At that time I'm sure you'll feel free to re-write
history and claim that we should have been doing things that way all
along.
David
--
David Dawes
Founder/committer/developer
On Fri, Oct 03, 2003 at 06:13:37PM +0100, José Fonseca wrote:
>On Fri, Oct 03, 2003 at 12:35:42PM -0400, David Dawes wrote:
>> On Fri, Oct 03, 2003 at 07:31:49AM -0700, Alex Deucher wrote:
>>
>> >his thoughts. Will there be another xfree86<->DRI merge before the
&g
s should be separated out and submitted to XFree86
for consideration for the upcoming release before the deadline(s). New
stuff should be discussed in advance on the broader XFree86 development
list so that there are no surprises, and it'd be helpful all around if
you guys maintained some sort
similar purpose in XFree86
(the pcidata and scanpci modules, and the scanpci utility).
David
--
David Dawes
Founder/committer/developer The XFree86 Project
www.XFree86.org/~dawes
---
This SF.Net email sponsored by: Free pre-b
s where nobody has needed it enough to
actually implement it.
David
--
David Dawes
Founder/committer/developer The XFree86 Project
www.XFree86.org/~dawes
---
This SF.net email is sponsored by: VM Ware
With VMware you can run mu
On Tue, Jun 03, 2003 at 11:52:42AM -0700, Linus Torvalds wrote:
>
>On Tue, 3 Jun 2003, David Dawes wrote:
>>
>> Does this go any way towards explaining why it seems to be getting harder
>> and harder to build modules outside of the kernel source tree while
>> sti
On Tue, Jun 03, 2003 at 10:34:25AM -0600, Brian Paul wrote:
>David Dawes wrote:
>> On Mon, Jun 02, 2003 at 04:23:14PM -0600, Brian Paul wrote:
>>
>>>Sounds like the Mesa directory re-org should happen sooner, rather
>>>than later.
>>>
>>>I
conflict when several DRM's are loaded simulatenously on
> the kernel (or is there?) Besides of reducing some visual clutter
Is that also true when multiple DRM drivers are built-in to the kernel?
David
--
David Dawes
Founder/committer/developer The XFr
ither be removed or renamed.
Another option is to keep the old repository as-is, and start a new one
(i.e., a new top level directory under the same $CVSROOT), seeded with
the reorganised files from the old one.
David
--
David Dawes
Founder/committe
s up to 2.5.69. 2.5.70 seems
to have presented another wrinkle to overcome. Is the ability to build
modules located outside of the kernel source tree a consideration at
all in the kernel module build process, or am I going down the wrong
path with this?
David
--
David Dawes
Founder/commi
d on platforms
like Solaris wouldn't be too common. Then there's 'nasm', which uses
the Intel-style syntax, and I think someone had an interest in using
that at some point.
David
--
David Dawes
Founder/committer/developer
On Fri, May 30, 2003 at 01:58:40PM +0200, Sven Luther wrote:
>On Thu, May 29, 2003 at 11:53:32AM -0400, David Dawes wrote:
>> On Thu, May 29, 2003 at 07:34:28AM +0200, Sven Luther wrote:
>> >On Thu, May 29, 2003 at 12:00:22AM -0400, Mike A. Harris wrote:
>> >> On
g a few levels deep of nesting (which I've
seen in some spam). It does catch the occasional false-positive, but
it's fairly rare, and a reasonable tradeoff given its effectiveness.
>Anyway, i have almost managed to write a sed script doing this, but i am
>not sure if it is possib
On Fri, Feb 14, 2003 at 06:24:50PM -0500, Leif Delgass wrote:
>On Fri, 14 Feb 2003, David Dawes wrote:
>
>[snip]
>
>> There are some more serious things holding up 4.3, including the issue
>> that Leif mentioned here a couple of days ago. I haven't seen anyone
>&g
he subscriber-only restriction.
A small amount of spam gets past the filter, but it's minor compared
with the total volume and the manual intervention required now is
very close to zero.
>I mean I've heard of Viagra and Propecia (I think) but w
a couple of days
ago. I haven't seen anyone comment on his proposed solution for that
one either...
David
--
David Dawes
Release Engineer/Architect The XFree86 Project
www.XFree86.org/~dawes
---
This SF.NET email is spo
I meant to add that it'd be good if something along the lines of Michel
Dänzer's work to allow DRI to be reinitialised at VT switch was added in
after 4.3. I'm curious why it didn't made it into the DRI trunk already.
David
On Fri, Feb 14, 2003 at 04:17:16PM -0500, David
nges the handle to be the "key" value.
I'm wary of making changes like this so close to the 4.3 release, but
I would like to see this problem fixed in 4.3. Does anyone see any
potential problems with the attached patch?
David
--
David Dawes
Release Engineer/A
On Fri, Feb 07, 2003 at 08:36:27AM -0700, Brian Paul wrote:
>David Dawes wrote:
>> On Fri, Feb 07, 2003 at 10:55:33AM +1000, Chris Ison wrote:
>>
>>>in XFree86 log
>>>
>>>Symbol xf86strtof from module
>>>/usr/X11R6/lib/modules/extensions/libG
is used in extras/Mesa/src/imports.c
>
>did someone forget to commit its definition?
strtof isn't very portable (C99), so something else should be used (maybe
sscanf, for example).
David
--
David Dawes
Release Engineer/Architect The X
preview snapshots. The source can be
checked out from the XFree86 CVS (see <http://www.xfree86.org/cvs/>),
and some binaries are available at:
ftp://ftp.xfree86.org/pub/XFree86/snapshots/4.2.99.4/binaries/
David
--
David Dawes
Release Engineer/
c/drv/radeon'
>>
>>
>> I don't have the time tonight to look after this :-(
>
>David's merge may still be in progress, update from CVS tomorrow and try
>again.
It's done now. I had my local copy done and building last night, but it
took most of today
On Tue, Dec 17, 2002 at 01:02:45AM +, Keith Whitwell wrote:
>David Dawes wrote:
>> On Mon, Dec 16, 2002 at 12:44:15PM -0500, David Dawes wrote:
>>
>>>On Sat, Dec 14, 2002 at 07:02:50PM +0100, Michel Dänzer wrote:
>>>
>>>>On Sam, 2002-12-14 at 1
On Mon, Dec 16, 2002 at 12:44:15PM -0500, David Dawes wrote:
>On Sat, Dec 14, 2002 at 07:02:50PM +0100, Michel Dänzer wrote:
>>On Sam, 2002-12-14 at 18:42, Michel Daenzer wrote:
>>> CVSROOT:/cvsroot/dri
>>> Module name:xc
>>> Repository: xc/xc/pr
re various locks in the repository
from the first aborted attempt.
Anyway, the pre-merge tag is "mesa-4-0-4-20021214" and when I can finally
finish committing the merge, the post-merge tag will be
"mesa-4-0-4-20021215".
David
--
Dav
nch sometime this weekend.
David
--
David Dawes
Release Engineer/Architect The XFree86 Project
www.XFree86.org/~dawes
---
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use
he 845G docs on
Intel's public web site show that the behaviour is like the 845 when
the on-board graphics isn't enabled. I made that change in my
locally maintained version of the agpgart driver a little while ago,
but haven't had the opportunity to test it with an ex
set in EnterVT().
By default, XFree86 handles APM events via EnterVT/LeaveVT. It's possible
for a driver to provide a separate function to handle PM events, but in
most cases it shouldn't be needed.
I just had another look at your patch, and I didn't see any obvious
problem w
On Mon, Nov 25, 2002 at 04:02:49PM -0700, Brian Paul wrote:
>Michel Dänzer wrote:
>> On Mon, 2002-11-25 at 23:21, Brian Paul wrote:
>>
>>>There are two places in radeon_ioctl.c where the INREG() macro is used to
>>>read register values (RADEON_LAST_FRAME_REG and RADEON_LAST_CLEAR_REG).
>>>
>>>It l
On Mon, Nov 25, 2002 at 09:44:46AM +, Keith Whitwell wrote:
>
>>>I think I found the problem. usleep() gets defined as a macro to xf86usleep()
>>>in xf86_ansi.h (via radeon_regs.h) and needs to be #undefined.
>>
>>
>> Do we know why xf86_ansi.h is getting included in the client-side module?
On Sat, Nov 23, 2002 at 07:51:08AM -0700, Brian Paul wrote:
>Adam K Kirchhoff wrote:
>> On Fri, 22 Nov 2002, Brian Paul wrote:
>>
>>
>>>Adam K Kirchhoff wrote:
>>>
I would be worried that whatever is causing the server from the mesa-41
branch to crash under FreeBSD is going to make it way
On Fri, Nov 22, 2002 at 04:55:55PM -0700, Brian Paul wrote:
>
>David,
>
>I think this is a CVS problem that we've seen before.
>
>After merging from the DRI trunk and checking in the changes to the mesa-41
>branch I'm finding that a number of files in xc/programs/Xserver/hw/xfree86
>drivers/geode a
On Thu, Nov 07, 2002 at 04:32:03PM +, Keith Whitwell wrote:
>Michel Dänzer wrote:
>> On Don, 2002-11-07 at 16:56, Keith Whitwell wrote:
>>
>>>Michel Dänzer wrote:
>>>
These no longer get built by default. Any objections against the
attached patch?
>>>Actually if they're not built,
On Wed, Nov 06, 2002 at 03:43:02PM -0800, Ian Romanick wrote:
>> Is this hammered in stone?
>> When will we see the next XFree86 release (4.4.0), then.
>> Shouldn't OpenGL 1.4 better go in sooner then later?
>
>Would the Mesa 5.x merge be too large of a change for XFree86 4.3.1? There
Yes, it wo
On Wed, Oct 30, 2002 at 11:53:31AM -0700, Brian Paul wrote:
>David Dawes wrote:
>> On Tue, Oct 29, 2002 at 05:01:51PM +0100, Michel Dänzer wrote:
>>
>>
>>>>Conclusion: DoLoadableServer being defined somehow makes XFree86Module
>>>>be defin
On Tue, Oct 29, 2002 at 05:01:51PM +0100, Michel Dänzer wrote:
>> Conclusion: DoLoadableServer being defined somehow makes XFree86Module
>> be defined.
>
>I thought it was only defined when DoLoadableServer is defined as YES,
>but it turns out it's always defined. Is that a bug, or should we real
On Mon, Oct 28, 2002 at 08:10:13PM -0600, David D. Hagood wrote:
>Brian Paul wrote:
>
>>
>>
>> The glheader.h file includes assert.h
>>
>> I don't know what's causing the error.
>>
>> -Brian
>>
>>
>I moved the #include of assert.h out of the #ifdef XFree86Module
>section, and all the compile error
On Fri, Oct 25, 2002 at 01:15:15PM +0200, Michel Dänzer wrote:
>On Don, 2002-10-24 at 14:25, David Dawes wrote:
>> On Thu, Oct 24, 2002 at 02:00:48PM +0200, Michel Dänzer wrote:
>> >On Don, 2002-10-24 at 13:52, Alan Hourihane wrote:
>> >> On Thu, Oct 24, 2002 at 0
On Thu, Oct 24, 2002 at 06:08:37AM -0700, Ian Romanick wrote:
>On Thu, Oct 24, 2002 at 01:34:33AM +0200, Felix Kühling wrote:
>> On Wed, 23 Oct 2002 13:24:32 -0700
>> Ian Romanick <[EMAIL PROTECTED]> wrote:
>>
>> > On Wed, Oct 23, 2002 at 09:22:05PM +0200, Felix Kühling wrote:
>> > > Hi,
>> > >
>
On Thu, Oct 24, 2002 at 02:00:48PM +0200, Michel Dänzer wrote:
>On Don, 2002-10-24 at 13:52, Alan Hourihane wrote:
>> On Thu, Oct 24, 2002 at 01:47:01PM +0200, Michel Dänzer wrote:
>> > > That certainly shouldn't be needed for shared entities. Where exactly
>> > > was it crashing ?
>> >
>> > XAA d
On Mon, Oct 21, 2002 at 12:30:24PM +0200, Michel Dänzer wrote:
>For your reference, here's what I committed to DRI CVS. The check for
>the XAA minor version could probably be done more elegantly in XFree86
>CVS though.
Adding checks like that to the XFree86 CVS version isn't encouraged,
because c
On Mon, Oct 21, 2002 at 08:56:57AM -0400, Kevin E Martin wrote:
>I admit I didn't think through all of the implications of the XAA
>change, but, rather, I put the new items in the XAAInfoRec where they
>logically should go -- next to the functions they effect. Michel caught
>my oversight and has
On Mon, Oct 21, 2002 at 02:52:29AM +0200, Dieter Nützel wrote:
>Should we have a pull "in time" to get it all working together properly?
I sent a note about DRI and RandR to the xpert list a couple of days
ago. To get the full benefits of a combined RandR and DRI, the DRI
needs to be more run-tim
On Fri, Oct 18, 2002 at 07:42:23PM -0400, Mike A. Harris wrote:
>On Thu, 17 Oct 2002, Marc Aurele La France wrote:
>
>>> The problem WAS that this re-enabling did not always take place before
>>> Marc's changes, which is why we added the explicit call to do this. I've
>>> checked the code in curre
On Fri, Oct 18, 2002 at 12:12:03AM +0200, Charl P. Botha wrote:
>On Thu, Oct 17, 2002 at 02:51:57PM -0600, Marc Aurele La France wrote:
>> The question on my, and David's, mind is whether or not bus mastering was
>> enabled on server entry.
>
>According to lspci, it was definitely enabled.
I'm rel
e XFree86 developers. That
intent needs to be backed up by some reasonable evidence when applying
for membership.
David
--
David Dawes
Release Engineer/Architect The XFree86 Project
www.XFree86.org/~dawes
---
This sf.ne
evelopment cycle. When the DRI developers
are ready to work with code closer to the XFree86 trunk than to
XFree86 4.2, that resync will happen. I don't think this is impeding
DRI development progress, but it if is, someone should let me know.
David
--
David Dawes
Release Engineer/Arc
On Thu, May 23, 2002 at 10:44:20PM +0200, Felix Kühling wrote:
>Hi,
>
>I had trouble when compiling DRI with g++ 3.0.4 and -O3 related to
>function inlining. The function swap is declared static globally in
>quicksort.cc. In function quicksort it is redeclared. The redeclaration
>prevents g++ from
new branch yet, so maybe
that would answer my questions.
David
--
David Dawes
Senior X Architect Tungsten Graphics, Inc
www.XFree86.org/~dawes www.tungstengraphics.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
0x07
>+#define DRM_RADEON_CLEAR 0x08
>+#define DRM_RADEON_VERTEX 0x09
>+#define DRM_RADEON_INDICES0x0a
>+#define DRM_RADEON_STIPPLE0x0c
>+#define DRM_RADEON_INDIRECT 0x0d
>+#define DRM_RADEON_TEXTURE
This would simplify things to
the point where the OS-specific parts are built-in to the X server
and the HW specific parts are all in the video driver module.
David
--
David Dawes
Senior X Architect Tungsten Graphics, Inc
www.XFree86.org/~dawes
ards compatibility
>to XFree86...
The backwards compatibility works in the directions of the X server
being able to use older drivers. The other direction isn't
guaranteed. The situation is basically the the same as with DRM
modules in the sense that the provider of the interfaces will w
Over the next week Keith Whitwell and I are planning to merge trunk
into the mesa-4-0 branch then the result into the trunk.
David
--
David Dawes
Senior X Architect Tungsten Graphics, Inc
www.XFree86.org/~dawes www.tungstengraphics.com
rhaps you should assume it is the older version until you know otherwise.
I agree. I think it would be useful to have a way for the 2D driver
to tell the drm driver what version it is, but if a 2D driver
doesn't, you have to assume an older version. Older X servers and
applications mus
On Wed, Jan 30, 2002 at 10:31:42AM -0700, Brian Paul wrote:
>Dieter Nützel wrote:
>>
>> Or is all together merged into the trunk?
>
>I'm not sure if David's finished merging XFree86 4.2 into the DRI trunk
>or not.
Yes, that merge i
This is a heads up that I'm planning to resync the DRI trunk with
XFree86 4.2.0 some time in the next few days.
David
--
David Dawes Email: [EMAIL PROTECTED]
Tungsten Graphics, Inc http://www.tungstengraphics.com
Founder/President, Re
would succeed (and maybe other reasons?).
If you're using the BSD driver as a reference, use a recent version.
Until recently it didn't allow the unbind/release/acquire/rebind
sequence (the release freed all allocations), and this broke VT
switching with the i810 driver.
David
--
Dav
provided in XFree86's os-support layer.
XFree86 drivers that need AGP GART functionality, like the i810
driver, use solely those interfaces. You can hide the OS-specific
details in the Solaris part of the XFree86 os-support lyaer.
David
--
David Dawes
> 4.2 step
while still not resolving the 4.0.x -> 4.1 incompatibility. I think the
best thing is to use the versioning in 4.1 as the baseline.
David
--
David Dawes Email: [EMAIL PROTECTED]
Founder/President, Release Engineer Phone: +1 570 764 0
;at presenet.
That's not true. The tree IS consistent at present. Having a full
installation of a recent XFree86 version is now a pre-requisite. No
building hacks are required. This is an intentional consequence of
pruning the DRI source tree.
David
--
David Dawes
The DRI CVS trunk has now been resynced with XFree86 4.1.0. The differences
between the two are now small, the main ones being that the DRI CVS trunk
has some post-3.4.2 Mesa updates.
David
--
David Dawes Email: [EMAIL PROTECTED]
Founder/President, The
0.0 1.0+.x
Note: "N+" means values >= N. The checks imply that drm modules with newer
minor version numbers will work with older XFree86 driver modules
(if the major version number hasn't changed), and that patchlevel changes
indicate changes that
m is defined as:
#ifndef CPPOnlyAsm
#define CPPOnlyAsm(basename,options) RemoveFile(basename.i) @@\
$(CPP) AsmDefines $(DEFINES) $(INCLUDES) options basename.S | \ @@\
grep -v '^\#' > basename.i
#endif
$(CPP) is set to 'CppCmd $(STD_CPP_DEFIN
On Wed, May 02, 2001 at 02:48:10PM -0500, Andy Isaacson wrote:
>Does the DRI project offer CVSUp access? I'm collecting CVS trees in
>the interest of being able to do speedy local CVS operations, and CVSUp
>is the most efficient method of getting the repository.
It doesn't, but I'd like to see i
On Tue, Apr 10, 2001 at 08:02:38PM +0200, Michel Dänzer wrote:
>David Dawes wrote:
>
>> Log message:
>> Use X_BYTE_ORDER rather than the non-portable endian.h
>>
>> Modified files:
>> xc/xc/lib/GL/mesa/src/drv/r128/:
>> Imakefile
On Tue, Mar 27, 2001 at 07:13:34PM +1000, Gareth Hughes wrote:
>I've looked into the 'making clean in /usr/local' build problem. Here's
>the lowdown:
>
>Despite what Keith P's HOWTO says, you can't just add this to your
>host.def:
>
> #define Freetype2Dir/usr/local
>
>By
80 matches
Mail list logo
