check why DRM_IOCTL_SET_UNIQUE ioctl does need root
privileges, it is more useful if access permissions could be managed via the
filesystem (eg. /dev/dri/cardX).
You shouldn't use SET_UNIQUE any more. Do SET_VERSION to 1.1 and then
get the unique (the busid).
--
Eric Anholt
On Tue, 2003-11-04 at 13:19, Jon Smirl wrote:
--- Eric Anholt [EMAIL PROTECTED] wrote:
On Tue, 2003-11-04 at 12:25, Otto Solares wrote:
On Mon, Nov 03, 2003 at 09:09:58PM -0800, Jon Smirl wrote:
I currently have this info tacked onto the end of the statistics IOCTL
(in
order
On Tue, 2003-11-04 at 13:47, Otto Solares wrote:
On Tue, Nov 04, 2003 at 01:19:54PM -0800, Jon Smirl wrote:
--- Eric Anholt [EMAIL PROTECTED] wrote:
On Tue, 2003-11-04 at 12:25, Otto Solares wrote:
On Mon, Nov 03, 2003 at 09:09:58PM -0800, Jon Smirl wrote:
I currently have this info
, José mentioned that he had trouble
uploading new snapshots recently due to problems with SourceForge shell
servers.
Should sourceforge's shell servers continue to be a problem,
pdx.freedesktop.org has a lot of capacity (cpu, disk) if there was a
desire to move snapshots there.
--
Eric Anholt
if we decide to
merge radeon and r200 DSOs at some point? Does your generic boot code
actually have nothing radeon-specific?
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
instead, because of
the radeonfb conflict. In the case of the DRM, we want drivers to
coexist, at least when loaded in the FB then DRM order. What should the
DRM be doing exactly in this case? Is it exactly what Jon Smirl said,
or something else?
--
Eric Anholt
if it actually fixed it (netboot linux kernels are
annoying to prepare), but my radeon and sis cards continued to work. If
someone could test with radeonfb and the latest DRM, that would be
great.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org
more questions now.
What is the proper way to get the equivalent of pci_name(pdev) on
pre-2.5? Also, what is the cutoff where pci_name is available? Are the
values from pci_name decimal or hex?
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org
On Wed, 2003-10-22 at 13:59, Michel Dänzer wrote:
On Wed, 2003-10-22 at 04:56, Eric Anholt wrote:
- What should the DRM do if the minor number for either DI or DD
interface is greater than the DRM knows about?
Return DRM_ERR( EINVAL ) ?
Okay, that's what it's doing.
- Do we want
(yesterday).
This is a step in the process of making the DRM attach to a specific
device. It'll help with the standalone DRI, and also with making the
DRM a proper FreeBSD driver.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt
On Mon, 2003-10-20 at 14:52, Jon Smirl wrote:
Eric Anholt is in the middle of doing a generic fix for this problem. See the
Adding hardware detection to DRI drivers thread. The current DRM drivers now
do PCI ID detection on both Linux and BSD. He is also adding an enum for chip
family but I'm
On Tue, 2003-10-21 at 15:33, Linus Torvalds wrote:
On Tue, 21 Oct 2003, Eric Anholt wrote:
What is the proper way to get the equivalent of pci_name(pdev) on
pre-2.5? Also, what is the cutoff where pci_name is available? Are the
values from pci_name decimal or hex?
The cut-off
the line, then I need the
output of scanpci, I think.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email is sponsored by OSDN developer
to move xf86drm.c to shared/drm/ (it's a shared file
anyway). Is there any value in the /proc/ support in it any more?
- drm.h should probably get re-merged and put into shared/
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL
-bit unclean. I thought I had fixed that.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email is sponsored by OSDN developer relations
to simulate it)
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your
On Sun, 2003-10-19 at 16:35, Eric Anholt wrote:
CVSROOT: /cvs/dri
Module name: xc
Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/bsd/drm/kernel/
Changes by: [EMAIL PROTECTED] 03/10/19 16:35:59
Log message:
- SMPng lock the DRM. This is only partial
in the 3d driver you could fall back to software on grabbing the
lock if the width is too large?
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net
ioctl thing would be to try
to save us needing to add too many new ioctls for smallish changes like
these.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
On Thu, 2003-10-16 at 12:41, Jon Smirl wrote:
--- Eric Anholt [EMAIL PROTECTED] wrote:
I'm still working on cleaning the PCI ID stuff up to be portable, which
I'll commit as soon as I test (I'm trying to get a multihead setup going
to see if there are problems with that as Michel Daenzer
pretty accurate lists in the BSD DRM I think. I'm going to
take a look at integrating your work and making it portable.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
going through them now to see how to
make them portable, too.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email is sponsored by: SF.net
On Wed, 2003-10-15 at 14:57, Jon Smirl wrote:
--- Eric Anholt [EMAIL PROTECTED] wrote:
If the Linux drivers go to probing PCI IDs, could it also start creating
/dev/dri/cardXs which are associated with a specific piece of hardware?
The get/set unique thing is a problem, though. It seems
I'm going to commit
this.
The SiS driver doesn't do texmem. I don't think it needs the texmem
objects, and I don't forsee it using the current incarnation of texmem.
(not an objection, since the patch is an improvement anyway, but if
you're already in the area...)
--
Eric Anholt
execution. The BSDs offer something similar to linux, I think,
but at least there isn't a module for it, so we use the generic
emulation.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
of differences
between Linux and *BSD for 2d in XFree86, I would say.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email is sponsored by: SF.net
to the XFree86 repo.
Or, you can leave it out and I think the XFree86 folks take care of
adding it when it goes into their repo.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
On Fri, 2003-10-03 at 13:55, Felix Kühling wrote:
On Fri, 03 Oct 2003 12:14:32 -0700
Eric Anholt [EMAIL PROTECTED] wrote:
Okay, I was going to merge trunk to the savage-1_0_0-branch, since
updates to the savage driver in trunk help out with that work I've been
Are you referring
. It ran for a while, and produced a large number of
conflicts. Why should there be conflicts in files that weren't touched
by the savage-branch? Is there a way to avoid having to deal with all
of those?
--
Eric Anholt[EMAIL PROTECTED]
http
On Fri, 2003-10-03 at 13:55, Felix Kühling wrote:
On Fri, 03 Oct 2003 12:14:32 -0700
Eric Anholt [EMAIL PROTECTED] wrote:
Okay, I was going to merge trunk to the savage-1_0_0-branch, since
updates to the savage driver in trunk help out with that work I've been
Are you referring
whitespace cleanup came after a bit of initial porting
work, which involved axing a bit of dead code and using some
os-independence macros. This should cover the functional changes that
came after that:
http://people.freebsd.org/~anholt/dri/files/sisdrm-functional.diff
--
Eric Anholt
things in trunk in the meantime
(I'm thinking of this i830 fix, the BSD fixes you've made)?
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This sf.net
somehow suppress the auto-wikiwording-from-source in
specific pages at least, I would put it on dri.sf.net too.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
still feel like the SiS DRM could be much smaller, but I haven't
thought about it yet.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This sf.net email
and the card_common.h in the 2d driver.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek
environment to get more information.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven
absolutely terrible, so I'm still checking out the new CVS to make sure
things work.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This sf.net email
We've got a new tarball. It missed the commits last night, but my plan
is to just replicate those commits myself in the new repository, trying
to keep history as best I can. I'll give another headsup when it's
done.
--
Eric Anholt[EMAIL PROTECTED]
http
On Mon, 2003-09-15 at 02:34, Alan Hourihane wrote:
On Sat, Sep 13, 2003 at 04:33:34PM -0700, Eric Anholt wrote:
On Sat, 2003-09-13 at 05:45, Alan Hourihane wrote:
On Sat, Sep 13, 2003 at 12:19:44PM +0100, Alan Hourihane wrote:
On Fri, Sep 12, 2003 at 12:35:30PM -0700, Eric Anholt wrote
On Sat, 2003-09-13 at 05:45, Alan Hourihane wrote:
On Sat, Sep 13, 2003 at 12:19:44PM +0100, Alan Hourihane wrote:
On Fri, Sep 12, 2003 at 12:35:30PM -0700, Eric Anholt wrote:
On Fri, 2003-09-12 at 07:22, Ian Romanick wrote:
Alan Hourihane wrote:
CVSROOT: /cvsroot/dri
tree?
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
in a previous email said the savage driver from S3 was for:
Savage MX/IX/ SuperSavage/ ProSavage/ Twister/K
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
to date. dri.freedesktop.org currently contains a snapshot
of the repo that was downloaded on September 5th. The move is stalled
waiting for cvs.sourceforge.net to get fixed so we can get a snapshot of
the repo containing everything that's happened since Sep. 4th.
--
Eric Anholt
On Sun, 2003-09-07 at 07:42, Dieter Nützel wrote:
Am Samstag, 6. September 2003 23:29 schrieb Eric Anholt:
On Sat, 2003-09-06 at 14:16, Eric Anholt wrote:
CVSROOT: /cvs/dri
Module name: xc
Repository: xc/xc/
Changes by: [EMAIL PROTECTED] 03/09/06 14:16:32
On Thu, 2003-09-04 at 03:55, Felix Kühling wrote:
On Wed, 03 Sep 2003 17:04:59 -0700
Eric Anholt [EMAIL PROTECTED] wrote:
On Wed, 2003-09-03 at 01:46, Keith Whitwell wrote:
Thomas Emmel wrote:
On Tue, 2003-09-02 at 19:40, Martin Spott wrote:
Thomas Emmel [EMAIL PROTECTED
On Wed, 2003-09-03 at 20:45, Eric Anholt wrote:
On Tue, 2003-09-02 at 09:06, Keith Whitwell wrote:
Eric Anholt wrote:
On Sun, 2003-08-31 at 03:47, Michael Schreckenbauer wrote:
Am Samstag, 30. August 2003 00:02 schrieb Eric Anholt:
My current diff is at:
http
.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
On Tue, 2003-09-02 at 09:06, Keith Whitwell wrote:
Eric Anholt wrote:
On Sun, 2003-08-31 at 03:47, Michael Schreckenbauer wrote:
Am Samstag, 30. August 2003 00:02 schrieb Eric Anholt:
My current diff is at:
http://people.freebsd.org/~anholt/dri/files/sis-14.diff
It's against DRI CVS
and integration between them has been great in p4.
If we just want to get rid of sf.net, CVS on freedesktop.org would
probably be a good place to go. Plus, then we could set up cvsup, which
offers fast checkouts/updates for folks and repository mirroring for
developers.
--
Eric Anholt
love the idea of moving to freedesktop.org right now to deal with the
anonymous cvs issue, provide cvsup, and probably a more responsive set
of admins. Is there consensus on this?
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt
On Sun, 2003-08-31 at 03:47, Michael Schreckenbauer wrote:
Am Samstag, 30. August 2003 00:02 schrieb Eric Anholt:
My current diff is at:
http://people.freebsd.org/~anholt/dri/files/sis-14.diff
It's against DRI CVS. Should work fine on Linux/FreeBSD, with or
without sisfb. I haven't
On Fri, 2003-08-29 at 17:22, Ian Romanick wrote:
Eric Anholt wrote:
My current diff is at:
http://people.freebsd.org/~anholt/dri/files/sis-14.diff
Since building the SiS driver is disabled, I don't see any reason to not
commit your changes. This will allow more adventureous people
On Mon, 2003-08-25 at 17:45, Eric Anholt wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/lib/GL/mesa/src/drv/common/
Changes by: [EMAIL PROTECTED] 03/08/25 17:45:05
Log message:
Fix config-0-0-1-branch on FreeBSD: expat is located in /usr/local, so we need
in CVS. I've
made about 100 commits to sis in my sis branch, which none of you would
have wanted to watch anyway.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
On Tue, 2003-08-26 at 03:46, Felix Kühling wrote:
On Mon, 25 Aug 2003 17:58:41 -0700
Eric Anholt [EMAIL PROTECTED] wrote:
On Mon, 2003-08-25 at 17:45, Eric Anholt wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/lib/GL/mesa/src/drv/common/
Changes
nobody minds me making massive style changes on the sis DRM
code. I find it quite ugly at the moment.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
\
--defsym glXGetVisualFromFBConfigSGIX=glXGetVisualFromFBConfig
That would work, but would it be acceptable?
Or use
static void bar(int) __attribute__ ((alias(foo)));
?
gcc-specific, but probably not worse than doing it with ld.
--
Eric Anholt[EMAIL PROTECTED
as
before, just with the window in a different place. I'll take a look at
that, though.
Another question: the advantage of Allocate/FreeOffscreenArea()s in the
TransitionTo2/3d is to leave more room for pixmaps in the 2d-only case,
right?
--
Eric Anholt[EMAIL
this cause a hang?
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500
on it. Because it's DRI related I have been granted DRI
CVS access and can do work there. But if I had been working on
something like this through XFree86 for this long without CVS access, I
would most likely have moved on to another project a while ago.
--
Eric Anholt
On Thu, 2003-03-13 at 00:51, Keith Whitwell wrote:
Eric Anholt wrote:
On Wed, 2003-03-12 at 05:57, Keith Whitwell wrote:
OK, now that the recycle lockup has been found fixed, I don't see any
problems with this patch. Has anyone got any objections to merging it to the
trunk?
Eric
Does anything use read/write/poll on the DRM? The drm-filp changes will
touch all of the device entry points for BSD, and I was wondering if
these functions are still used/useful in the current state of things.
--
Eric Anholt[EMAIL PROTECTED]
http
some fundamental braino's in the orignal drm...
It's the second thing on my list, after some mopup after the XFree86
4.3.0 update. I haven't looked at it seriously enough yet. Please give
me a few days to get it at least building again on BSD.
--
Eric Anholt
On Thu, 2003-02-20 at 16:30, Eric Anholt wrote:
I'm currently working on merging bsd-4-0-0-branch to trunk, starting
with the merge to the branch. If things stay quiet on the trunk, that
would be wonderful.
Been a busy night and cvs conflicts have been troubling me. I've got a
merged version
I'm currently working on merging bsd-4-0-0-branch to trunk, starting
with the merge to the branch. If things stay quiet on the trunk, that
would be wonderful.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
to work on this once we've got the lists issue cleared up. I
think I understand the busdma stuff pretty decently at this point.
At any rate, the remainder of the attached patch is trivial additions of
DRM_ERR, DRM_CURRENTPID, etc. and a couple of whitespace tweaks.
Looks good to me.
--
Eric
on ati_pcigart.h/drm_scatter.h conversion).
If you would approve of me moving the mach64 files to shared/drm/kernel,
I could at least work on things incrementally (much of this stuff is
mechanical changes), and then hopefully provide something pretty to
review for pci_alloc_consistent.
--
Eric Anholt
On Wed, 2003-02-12 at 04:23, Adam K Kirchhoff wrote:
Hey folks,
I'm trying to find out the branch to use for NetBSD. I know that
Eric Anholt posted it here in the not-too-distant past, but I can't seem
to find the e-mail from him anywhere (and the search mechanism on
sourceforge
On Sat, 2003-02-08 at 17:46, Eric Anholt wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/lib/GL/dri/drm/
Changes by: anholt@sc8-pr-cvs1. 03/02/08 17:46:32
Log message:
Use the right subdirs for NetBSD.
Modified files:
xc/xc/lib/GL/dri/drm
hoping to merge to
trunk soon. Sorry for the duplication of work.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.NET email is sponsored
from trunk as of a few days ago was:
http://people.freebsd.org/~anholt/dri/files/bsd-4-0-0-diff
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED
:
http://sourceforge.net/docman/display_doc.php?docid=2352group_id=1
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.NET email is sponsored
to hijack the si_code field for this
use? Where would the timestamp go that was talked about? Also,
shouldn't you be using list_add/list_del for those list things done?
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/dri
, and BuildLibraries
was is to NO for the DRI tree (I was just reverting a change made during
the 4.2.99.2 merge). libXThrStub is only used by libX11, which is also
not in the tree.
Although I haven't actually tried a build with libGLU/libGLw, I don't
expect there to be any problems.
--
Eric Anholt [EMAIL
i8xx:no
mga ? (probably doesn't work, but shouldn't be hard to fix)
tdfx:? (probably doesn't work, but shouldn't be hard to fix)
Glide3 is endian clean?
It's got code in it for PPC (Macs). I don't know about linux + PPC,
though.
--
Eric Anholt [EMAIL PROTECTED]
http
minutes. I was pretty happy.
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/dri/
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
it.
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/dri/
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Dri-devel mailing list
On Thu, 2002-09-26 at 00:58, Eric Anholt wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/lib/GL/mesa/src/drv/r200/
Changes by: anholt@usw-pr-cvs1. 02/09/26 00:58:14
Log message:
R200 sync-to-vblank support (set LIBGL_THROTTLE_REFRESH=1)
Okay, that concludes
to make that. Perhaps when I get around to looking at the gamma
code (the other major user of a future DRM_WAKEUP and friends) again
I'll try to fix that up. Or Mach64. Was there a trunk merge to mach64
after the bsd-3-0-0 merge? I should be working on it very soon.
--
Eric Anholt [EMAIL
On Tue, 2002-09-24 at 17:08, Michel Dänzer wrote:
On Die, 2002-09-24 at 10:08, Eric Anholt wrote:
On Mon, 2002-09-23 at 09:00, Michel Dänzer wrote:
I've incorporated this and turned it into a template:
http://penguinppc.org/~daenzer/DRI/drm-vblank-template.diff
I've put
SIZERES STATE C TIME WCPUCPU COMMAND
269 root 22 0 80040K 5584K rdnvbl 0 0:54 4.93% 4.93% glxgears
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/dri/
Index: lib/GL/mesa/src/drv/r200/r200_context.c
the PCI ids (so they don't get probed as
supported cards and then attach the DRM uselessly).
What does using that linux version of the struct do to improve Linux
support? (your other mail about it confused me).
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/dri
/include -c radeon_state.c -o
radeon_state.o
In file included from radeon_state.c:31:
drmP.h:170: warning: static declaration for
`vmalloc_to_page_Rsmp_667fae44' follows non-static
ld -r radeon_drv.o radeon_cp.o radeon_state.o -o radeon.o
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org
On Fri, 2002-07-12 at 06:22, Dave Jones wrote:
On Thu, Jul 11, 2002 at 02:46:24AM -0600, Eric Anholt wrote:
A better fix would be to actually enable SSE before FreeBSD does its
feature flag detection. Linux does the following very early on..
You're thinking of the wrong issue. The issue
was on the order
of 1%, so it was a poor benchmark to use.
Anyone opposed to me committing?
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/dri/
Index: extras/Mesa/src/X86/common_x86.c
===
RCS file: /cvsroot/dri/xc/xc
they have
specific examples of subrevisions. It looks like they have harvested
some nonexistent pci ids. Compare it to xf86PciInfo.h in
programs/Xserver/hw/xfree86/common/. I've had reports for just about
all of the ones listed for XFree86 which support DRI.
--
Eric Anholt [EMAIL PROTECTED]
http
? In the meantime I think I'll be making custom
linux binaries with this patch for FreeBSD.
Joe: I did it this way, because sometimes I've run a linux binary which
mangled my /dev/dri/card0, and I've used a FreeBSD binary as root to
correct it. It also seemed like an easy fix.
--
Eric Anholt [EMAIL PROTECTED
mga_warp.c
r128.h
r128_cce.c
r128_drm.h
r128_drv.h
r128_state.c
radeon.h
radeon_cp.c
radeon_drm.h
radeon_drv.h
radeon_state.c
from .../linux/drm/kernel?
Yes, they should be cvs rm'ed now.
--
Eric Anholt [EMAIL PROTECTED]
http
dying? (be sure to use
LIBGL_DEBUG=verbose)
People have had banshees working on fbsd before. One thing that some
have had to do is:
export FX_GLIDE_NUM_TMU=2
before running their apps. If you needed it too, I'll try to check in a
fix for the port.
--
Eric Anholt [EMAIL PROTECTED]
http
/radeon_drv.c'
cvs server: failed to remove tag `HEAD' from `radeon/radeon_drv.h'
cvs server: failed to remove tag `HEAD' from `radeon/radeon_state.c'
cvs commit: saving log message in /tmp/cvs80lKSc
--
Eric Anholt [EMAIL PROTECTED]
http://people.freebsd.org/~anholt/dri
On Thu, 2002-07-04 at 00:10, Keith Whitwell wrote:
Eric Anholt wrote:
Here's my current list of concerns about the state of both the branch
and the general CVS support of Radeons (since that's what another user
and I are both playing with the most).
BSD branch's fault
- I haven't
.
- graphics droppings when dragging a glxgears around with pageflip
enabled.
- white streak on the top of the screen running glxgears the first
time. (may not happen later after having run it before). Doesn't sound
like it's dependent on pageflip.
--
Eric Anholt [EMAIL PROTECTED]
http
). Same thing
happens if I add a -rbsd-3-0-0branch before the other -r arg. I would
like to be able to easily cvs diff directories between branches. I
thought from reading the manpage I could do this, but it's not working.
--
Eric Anholt [EMAIL PROTECTED]
http://lclark.edu/~eta/dri
see. Normal BSD
users won't be relying on the DRI CVS or even XFree86 release DRMs, and
instead will get them from their OS.
--
Eric Anholt [EMAIL PROTECTED]
http://gladstone.uoregon.edu/~eanholt/dri/
---
Sponsored by:
ThinkGeek at http
ambitious...
Keith
Should be fixed, going to run through testing cards on linux again.
BTW, I'm in #dri-devel for more real-time responses.
--
Eric Anholt [EMAIL PROTECTED]
http://gladstone.uoregon.edu/~eanholt/dri/
---
Sponsored by:
ThinkGeek
about the Radeon numbers.
--
Eric Anholt [EMAIL PROTECTED]
http://gladstone.uoregon.edu/~eanholt/dri/
---
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
___
Dri-devel mailing list
[EMAIL PROTECTED
it to
work.
At this point, who should review this for a merge?
--
Eric Anholt [EMAIL PROTECTED]
http://gladstone.uoregon.edu/~eanholt/dri/
---
This sf.net email is sponsored by: Jabber Inc.
Don't miss the IM event of the season | Special offer
On Wed, 2002-06-26 at 23:12, Jens Owen wrote:
Eric Anholt wrote:
Log message:
The drmCommand interface was passing a size to DRM_IOR() and friends,
when DRM_IOR was expecting a type, so on BSD only an int was copied in/out of
the kernel. Make drmCommand use new DRM_IOC
On Thu, 2002-06-20 at 23:58, Eric Anholt wrote:
CVSROOT: /cvsroot/dri
Module name: xc
Repository: xc/xc/programs/Xserver/hw/xfree86/os-support/shared/drm/kernel/
Changes by: anholt@usw-pr-cvs1. 02/06/20 22:58:50
Log message:
Hook up os-independence of r128 for Linux.
I
think it's a versioning issue.
Has anyone else seen this?
--
Eric Anholt [EMAIL PROTECTED]
http://gladstone.uoregon.edu/~eanholt/dri/
Bringing you mounds of caffeinated joy
401 - 500 of 515 matches
Mail list logo
