On Tue, 2003-11-04 at 03:28, Michel Dnzer wrote:
On Thu, 2003-10-30 at 11:43, Ronny V. Vindenes wrote:
(EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020
(EE) RADEON(0): GetBuffer timed out, resetting engine...
(EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020
(EE) RADEON(0):
On Tue, 2003-11-04 at 12:11, Ronny V. Vindenes wrote:
On Tue, 2003-11-04 at 03:28, Michel Dnzer wrote:
On Thu, 2003-10-30 at 11:43, Ronny V. Vindenes wrote:
(EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020
(EE) RADEON(0): GetBuffer timed out, resetting engine...
(EE)
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=819
--- Additional Comments From [EMAIL PROTECTED] 2003-04-11 10:38 ---
Robin,
When you load
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
[EMAIL PROTECTED] changed:
What|Removed |Added
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 to conserve IOCTL numbers) but there should be a better way to do it.
while you are on it, can you check why DRM_IOCTL_SET_UNIQUE ioctl does need root
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 to conserve IOCTL numbers) but there should be a better way to do it.
while you are on it, can you
--- 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 to conserve IOCTL numbers) but there should be a better
On Tue, Nov 04, 2003 at 01:08:28PM -0800, Eric Anholt 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 to conserve IOCTL numbers) but there
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 tacked onto the end of the statistics IOCTL
(in
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 to
On Tue, Nov 04, 2003 at 03:47:23PM -0600, 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
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
--- Otto Solares [EMAIL PROTECTED] wrote:
Jon, should i convert r200 in Mesa-newtree to use SET_VERSION and then
GET_UNIQUE or there is more work to be done to eliminate root privs, is
backwards compability an issue too?
The copy in bk://mesa3d.bkbits.net/jonsmirl is already converted. But
--- Eric Anholt [EMAIL PROTECTED] wrote:
I was going to add exporting of FB/MMIO size/length as a separate but
standard DRM ioctl. It's cleaner that way I think. I don't think we
have any real limit on the number of ioctls, so let's not make it a
device-specific thing if there isn't a need.
Another problem I have is determining the name of the driver DSO to load. I
would like to just take the driver name from the DRM driver, concat _dri.so to
it and load. This works for everything except the radeon driver.
There are several solutions:
1) mess with the build to make two DRM drivers,
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=819
[EMAIL PROTECTED] changed:
What|Removed |Added
On Tue, Nov 04, 2003 at 02:28:53PM -0800, Jon Smirl wrote:
--- Otto Solares [EMAIL PROTECTED] wrote:
Jon, should i convert r200 in Mesa-newtree to use SET_VERSION and then
GET_UNIQUE or there is more work to be done to eliminate root privs, is
backwards compability an issue too?
The copy
--- Otto Solares [EMAIL PROTECTED] wrote:
How can i interface with your changes?, currently i open the fbdev,
mmap fb and mmio region, set desired fbdev mode, load r200 dso, pull hooks
and
everything is ok from there. The only thing i dislike with the current
aproach
is that we need root
[EMAIL PROTECTED] is also supposed to be working on an OpenGL based
windowing
system. I don't know the status of his code.
Hi Guys-
My mike-d.org server is down, this is my work address. Here's the
status of my OpenGL window system:
client/server is working.
Right now communication is done
--- Michael Dreesen [EMAIL PROTECTED] wrote:
window compositing is working.
Only one gl context is used for the window system's drawing. Clients
draw into the back buffer. When a client wants to draw to a window, the
server checks to see if that window's back texture is already on the
I doesn't know other people was working on opengl windowing systems,
maybe we can collaborate in the future.
I think is a good idea use the X server as a trampoline as you can
use all those accelerated drivers out there, i am sticking with
Jon's work on mesa standalone as i really want to
21 matches
Mail list logo
