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
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
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 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
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.
> >
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
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
---
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=314
--- Additional Comments From [EMAIL PROTECTED] 2003-07-10 15:13 ---
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:15 ---
I've tried:
- XFree 4
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
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
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
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
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
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
> >
> > 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
> > 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
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
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, 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
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 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
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
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
---
26 matches
Mail list logo
