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) wi
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 hea
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
> impo
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 using
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 th
> > 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 chang
> >
> > 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
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
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 Dänzer \ Debian (powerpc), X
Michel Dänzer 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:
xc/programs/Xse
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? t
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 4
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 4
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 looks
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 DRM_LO
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.
> >
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
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. T
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
Hi!
I am trying to merge the r200 driver from dri-cvs to mesa-miniglx,
finally i had most files merged but i am finding heavy X dependencies
in header files in dri-cvs (eg radeon.h), it was not supposed dri
drivers should be backend agnostic?
Is somebody working on resolving this situation? i thi
26 matches
Mail list logo
