Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=757
[EMAIL PROTECTED] changed:
What|Removed |Added
Hi all,
I'm happy to report that I found a solution to the merge problems Eric
and I were seeing. I believe the problem had to do with vendor branches.
They are created automatically when sources are imported using cvs
import. Many files from XFree86 had a vendor branch (e.g. revisions
1.1.1.x)
On Mon, Oct 06, 2003 at 09:40:23PM -0700, Alex Deucher wrote:
Log message:
Add Merged Framebuffer (MergedFB) support to the radeon driver. On
dualhead cards this creates a single shared framebuffer with 2 viewports
looking into it. This allows things like the DRI to work on both heads.
Felix,
On Sat, Oct 04, 2003 at 01:35:13AM +0200, Felix Kühling wrote:
Hi,
I made some modifications to the snapshot scripts in order to include
xdriinfo and its manpage in the snapshots of the config-0-0-1-branch or
the trunk after the merge. A patch is attached.
I chose to use the
On Tue, Oct 07, 2003 at 12:33:49PM +0200, Felix Kühling wrote:
Hi all,
I'm happy to report that I found a solution to the merge problems Eric
and I were seeing. I believe the problem had to do with vendor branches.
They are created automatically when sources are imported using cvs
import.
José Fonseca wrote:
On Tue, Oct 07, 2003 at 12:33:49PM +0200, Felix Kühling wrote:
Hi all,
I'm happy to report that I found a solution to the merge problems Eric
and I were seeing. I believe the problem had to do with vendor branches.
They are created automatically when sources are imported
On Tue, 07 Oct 2003 12:32:45 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
José Fonseca wrote:
On Tue, Oct 07, 2003 at 12:33:49PM +0200, Felix Kühling wrote:
Hi all,
I'm happy to report that I found a solution to the merge problems Eric
and I were seeing. I believe the problem had to
Hmm. These problems only arise because of the way the merge was done? Why
not just document the right way to do the merge?
I'd agree with Keith the proper way to merge needs documenting, CVS vendor
import is what is needed, the XFree CVS is vendor imported into our DRI
tree, the changes
I would suggest adding more ioctls:
1. Lock the drm driver against future connections from 3d driver(s).
2. Return the number of current connections.
3. Move the aperture - should only succeed when nothing else is connected.
Also, when aperture is moved DRM driver
Sorry, I forgot to post a patch of what went in. I committed this
patch:
http://www.botchco.com/alex/radeon/mergedfb/cvs/DRI/final/mergedfb-dri.diff
Alex
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Yeah. I'll work on that this week unless anyone has any objections.
Alex
--- Alan Hourihane [EMAIL PROTECTED] wrote:
On Mon, Oct 06, 2003 at 09:40:23PM -0700, Alex Deucher wrote:
Log message:
Add Merged Framebuffer (MergedFB) support to the radeon driver.
On
dualhead cards this
On Tue, 2003-10-07 at 13:32, Keith Whitwell wrote:
Hmm. These problems only arise because of the way the merge was done? Why
not just document the right way to do the merge?
I think tagging the branch point is a good idea regardless.
--
Earthling Michel Dnzer \ Debian (powerpc),
Michel Dnzer wrote:
On Tue, 2003-10-07 at 13:32, Keith Whitwell wrote:
Hmm. These problems only arise because of the way the merge was done? Why
not just document the right way to do the merge?
I think tagging the branch point is a good idea regardless.
I agree. Documenting both the right way
I have a question about the license at the top of these new files.
what should I put for the copyright? Some of the the code was written
by me, but much of it was taken from the sis and mga drivers. Also,
what to I put for the top line? the one that looks like this:
/* $XFree86:
On Tue, 2003-10-07 at 10:42, Alex Deucher wrote:
I have a question about the license at the top of these new files.
what should I put for the copyright? Some of the the code was written
by me, but much of it was taken from the sis and mga drivers. Also,
what to I put for the top line? the
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=314
--- Additional Comments From [EMAIL PROTECTED] 2003-07-10 15:15 ---
I've tried:
- XFree
I've been trying to track down a DRI client and server deadlock
problem. I think I now know the problem, I'd appreciate it if others
could confirm this is a bug or if I have a misunderstanding.
This is the scenario:
1) Client takes heavyweight lock via ioctl, lock now has DRM_LOCK_HELD
bit or'ed
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=314
--- Additional Comments From [EMAIL PROTECTED] 2003-07-10 15:13 ---
I've tried:
- XFree
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=110
--- Additional Comments From [EMAIL PROTECTED] 2003-07-10 15:51 ---
I am having what
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter your comments there.
http://bugs.xfree86.org/show_bug.cgi?id=110
[EMAIL PROTECTED] changed:
What|Removed |Added
John Dennis wrote:
I've been trying to track down a DRI client and server deadlock
problem. I think I now know the problem, I'd appreciate it if others
could confirm this is a bug or if I have a misunderstanding.
This is the scenario:
1) Client takes heavyweight lock via ioctl, lock now has
On Tue, Oct 07, 2003 at 12:23:16PM +0100, José Fonseca wrote:
On Tue, Oct 07, 2003 at 12:33:49PM +0200, Felix Kühling wrote:
Hi all,
I'm happy to report that I found a solution to the merge problems Eric
and I were seeing. I believe the problem had to do with vendor branches.
They are
On Tue, 2003-10-07 at 15:02, Vladimir Dergachev wrote:
I would suggest adding more ioctls:
1. Lock the drm driver against future connections from 3d driver(s).
2. Return the number of current connections.
3. Move the aperture - should only succeed when nothing
Brian Paul wrote:
Ian Romanick wrote:
A long time ago I promided to refactor the firstLevel / lastLevel
calculation code from the various *SetTexImages routines. I have a
patch that does this, and it follows the definition of how firstLevel
lastLevel selection should work pretty closely.
On Wed, 8 Oct 2003, Michel [ISO-8859-1] Dänzer wrote:
On Tue, 2003-10-07 at 15:02, Vladimir Dergachev wrote:
I would suggest adding more ioctls:
1. Lock the drm driver against future connections from 3d driver(s).
2. Return the number of current connections.
25 matches
Mail list logo
