Re: (xfree86) dri kernel modules (sis-6326)
On Sun, 28 Nov 2004 23:36:04 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hello, > > I would like to know if a dri kernel module for the sis-6326 video card > is in development or if a version is available for download? I am using > Fedora Core 1. Eric Anholt and Alan Cox were working on it a while back. Alan had a tarball of it on his ftp or www site. I think it's still there. If you can't find it let me know and I'll see if I can dig up the link. Alex > > Jeff > --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: (xfree86) dri kernel modules (sis-6326)
On Sul, 2004-11-28 at 23:36, [EMAIL PROTECTED] wrote: > Hello, > > I would like to know if a dri kernel module for the sis-6326 video card > is in development or if a version is available for download? I am using > Fedora Core 1. I got it vaguely working but never had time to debug textures or some strange Z buffer problems. Its such a slower card however nowdays .. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
(xfree86) dri kernel modules (sis-6326)
Hello, I would like to know if a dri kernel module for the sis-6326 video card is in development or if a version is available for download? I am using Fedora Core 1. Jeff --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1773] DRI with radeon7500 causes lockups
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=1773
--- Additional Comments From [EMAIL PROTECTED] 2004-11-28 12:24 ---
(In reply to comment #6)
> I tried and it still locks up.
Yes it still locks up and from strace I can see it loops forever.
But somewhing has changed now because previously I got
gettimeofday({1099555005, 69646}, NULL) = 0
gettimeofday({1099555005, 69665}, {4294967236, 0}) = 0
beatween ioctl() calls.. in strace.log
Now the strace looks like
ioctl(4, 0x4008642a, 0xba48)= 0
write(3, "\200\t\3\0\0\0\0\0\2\0`\0", 12) = 12
read(3, "\f\n\37\0\2\0`\0\0\0\0\0,\1,\1\0\0t\10\250 w\10\210\363"..., 32) = 32
read(3, "\1\0 \0\5\0\0\0\0\0\0\0\1\1\0\0\0\0\0\0,\1,\1\1\0\0\0\0"..., 32) = 32
read(3, "\1\0\0\0", 4) = 4
read(3, "\0\0\0\0,\1,\1", 8)= 8
read(3, "\0\0\0\0,\1,\1", 8)= 8
ioctl(4, 0x4008642a, 0xba48)= 0
ioctl(3, FIONREAD, [0]) = 0
ioctl(4, 0x40106450, 0xb8f0)= 0
ioctl(4, 0xc0086451, 0xb9b8)= 0
ioctl(4, 0x40106450, 0xb930)= 0
ioctl(4, 0x40186448, 0xbab0)= 0
ioctl(4, 0xc0286429, 0xb390)= 0
ioctl(4, 0x40106450, 0xbfffd3f0)= 0
ioctl(4, 0x40106450, 0xb450)= 0
ioctl(4, 0x40106450, 0xba70)= 0
ioctl(4, 0xc0086451, 0xbaa0)= 0
ioctl(4, 0xc010643a, 0xbab0)= 0
ioctl(4, 0x6447, 0) = 0
gettimeofday({1101672442, 574975}, NULL) = 0
gettimeofday({1101672442, 575002}, {4294967236, 0}) = 0
ioctl(3, FIONREAD, [0]) = 0
ioctl(4, 0x40106450, 0xb8f0)= 0
ioctl(4, 0xc0086451, 0xb9b8)= 0
ioctl(4, 0x40106450, 0xb930)= 0
ioctl(4, 0x40186448, 0xbab0)= 0
ioctl(4, 0x40106450, 0xb450)= 0
ioctl(4, 0x40106450, 0xba70)= 0
ioctl(4, 0xc0086451, 0xbaa0)= 0
ioctl(4, 0xc0086451, 0xbaa0)= 0
ioctl(4, 0xc0086451, 0xbaa0)= 0
ioctl(4, 0xc0086451, 0xbaa0)= 0
ioctl(4, 0xc0086451, 0xbaa0)= 0
ioctl(4, 0xc0086451, 0xbaa0)= 0
and so on... filling free disk space...
What steps I need to do in order to debug it more precisly ?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel thoughts of a Linux user
On Wed, Nov 24, 2004 at 12:31:05PM +0100, Tomas Carnecky wrote: > Helge Hafting wrote: > >>From the [ruby patch] documentation: > >>The main problem up to this date (November 2004) is that linux kernel > >>has only one behaviour regarding multiple keyboards : any key pressed > >>catched on any keyboard is redirected to the one and only active > >>Virtual Terminal (VT). > >> > >>Will this be changed/improved when the console code is moved into > >>userspace, like some have proposed? > > > > > >I don't know about any userspace console, but the ruby patch lets > >you have several independent active VTs at the same time. So > >the above mentioned problem is solved - they keyboards does > >not interfere with each other. > > > > I think the it would be much nicer to habe the console code in > userspace, ruby is only a patch, not in the mainline kernel, and AFAIK > not even in any experimental (-mm/-ac/-etc) tree. So what? It may not be ready for inclusion yet, how does that matter? It is being worked on. I see problems with a userspace implememtation, the console have to be available - but a userspace console can be killed. By the never perfect OOM-killer, for example. > There are many aproaches how to solve the problem of having more than > one ative VT, and the userspace console seems to be the nicest one. > Why nicest? Of course ruby isn't there right now - but is there a working userspace console anywhere? > I know that Jon Smirl wrote an email some time ago, here it is: > http://lkml.org/lkml/2004/8/2/111, look at point 15. I like the idea and > I've written him several times, but he didn't answer :( Interesting ideas and many good points there. The console is only a small part of it though, it seems to be mostly 2D/3D/framebuffer/drm problems. A console is a small thing and separating it from the rest is a good idea. I am not so sure putting it in userspace is though. Helge Hafting --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Current DRI/Mesa CVS compilation error
Dieter NÃtzel wrote: DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA-c xm_api.c In file included from /opt/Mesa/src/mesa/main/context.h:51, from xm_api.c:66: /opt/Mesa/src/mesa/glapi/glapi.h:54: Warnung: function declaration isn't a prototype xm_api.c: In function `xmesa_alloc_back_buffer': xm_api.c:592: error: structure has no member named `width' xm_api.c:592: error: structure has no member named `height' make[7]: *** [xm_api.o] Fehler 1 Fixed. -Brian --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Current DRI/Mesa CVS compilation error
DGLX_DIRECT_RENDERING -DGLX_USE_DLOPEN -DGLX_USE_MESA-c xm_api.c In file included from /opt/Mesa/src/mesa/main/context.h:51, from xm_api.c:66: /opt/Mesa/src/mesa/glapi/glapi.h:54: Warnung: function declaration isn't a prototype xm_api.c: In function `xmesa_alloc_back_buffer': xm_api.c:592: error: structure has no member named `width' xm_api.c:592: error: structure has no member named `height' make[7]: *** [xm_api.o] Fehler 1 -Dieter --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R100 readpixels acceleration
Ok, here is a new patch.
Stephane
diff -x CVS -Naur ../../../../../Mesa.orig/src/mesa/drivers/dri/common/clip.h
./common/clip.h
--- ../../../../../Mesa.orig/src/mesa/drivers/dri/common/clip.h 1970-01-01
01:00:00.0 +0100
+++ ./common/clip.h 2004-11-16 01:01:55.0 +0100
@@ -0,0 +1,42 @@
+#include "drm.h"
+
+/*
+ * Clips a rect (x,y,width,height) to the clipping boxes
+ * Returns the area in the (mx1,my1) (mx2,my2) rect
+ *
+ * Merges the rects for performance reasons (doing a single read)
+ */
+
+static __inline__ void dri_read_screen_clip(int* mx1,int* mx2,int* my1,int*
my2,int x,int y,int width,int height,drm_clip_rect_t *box,int nbox)
+{
+ int mw,mh,i;
+ *mx1 = box[0].x1;
+ *my1 = box[0].y1;
+ *mx2 = box[0].x2;
+ *my2 = box[0].y2;
+ mw=mx2-mx1;
+ mh=my2-my1;
+
+ /* merge the rects */
+ for (i = 1 ; i < nbox ; i++)
+ {
+ if (box[i].x1 < *mx1) *mx1 = box[i].x1;
+ if (box[i].y1 < *my1) *my1 = box[i].y1;
+ if (box[i].x2 > *mx2) *mx2 = box[i].x2;
+ if (box[i].y2 > *my2) *my2 = box[i].y2;
+ }
+ mw=*mx2-*mx1;
+ mh=*my2-*my1;
+
+ /* intersect with the area we are supposed to read */
+ if (*mx1 < x) mw -= x - *mx1, *mx1 = x;
+ if (*my1 < y) mh -= y - *my1, *my1 = y;
+ if (*mx1 + mw > x + width) mw = x + width - *mx1;
+ if (*my1 + mh > y + height) mh = y + height - *my1;
+ if (mw <= 0) return;
+ if (mh <= 0) return;
+ *mx2=*mx1+mw;
+ *my2=*my1+mh;
+}
+
+
diff -x CVS -Naur ../../../../../Mesa.orig/src/mesa/drivers/dri/radeon/Makefile
./radeon/Makefile
--- ../../../../../Mesa.orig/src/mesa/drivers/dri/radeon/Makefile
2004-11-11 21:44:34.0 +0100
+++ ./radeon/Makefile 2004-11-03 17:07:59.0 +0100
@@ -22,6 +22,7 @@
radeon_context.c \
radeon_ioctl.c \
radeon_lock.c \
+ radeon_pixel.c \
radeon_screen.c \
radeon_state.c \
radeon_state_init.c \
diff -x CVS -Naur
../../../../../Mesa.orig/src/mesa/drivers/dri/radeon/radeon_context.c
./radeon/radeon_context.c
--- ../../../../../Mesa.orig/src/mesa/drivers/dri/radeon/radeon_context.c
2004-11-28 16:40:11.0 +0100
+++ ./radeon/radeon_context.c 2004-11-28 16:26:27.0 +0100
@@ -343,7 +343,14 @@
ctx->Const.MaxLineWidth = 10.0;
ctx->Const.MaxLineWidthAA = 10.0;
ctx->Const.LineWidthGranularity = 0.0625;
-
+ if (screen->cpp == 4)
+ {
+ ctx->Const.ColorReadFormat = GL_BGRA;
+ ctx->Const.ColorReadType = GL_UNSIGNED_INT_8_8_8_8_REV;
+ } else {
+ ctx->Const.ColorReadFormat = GL_BGR;
+ ctx->Const.ColorReadType = GL_UNSIGNED_SHORT_5_6_5_REV;
+ }
/* Set maxlocksize (and hence vb size) small enough to avoid
* fallbacks in radeon_tcl.c. ie. guarentee that all vertices can
* fit in a single dma buffer for indexed rendering of quad strips,
diff -x CVS -Naur
../../../../../Mesa.orig/src/mesa/drivers/dri/radeon/radeon_context.h
./radeon/radeon_context.h
--- ../../../../../Mesa.orig/src/mesa/drivers/dri/radeon/radeon_context.h
2004-11-11 21:44:34.0 +0100
+++ ./radeon/radeon_context.h 2004-11-08 21:25:50.0 +0100
@@ -847,6 +847,7 @@
#define DEBUG_DRI 0x200
#define DEBUG_DMA 0x400
#define DEBUG_SANITY0x800
+#define DEBUG_PIXEL 0x2000
#endif
#endif /* __RADEON_CONTEXT_H__ */
diff -x CVS -Naur
../../../../../Mesa.orig/src/mesa/drivers/dri/radeon/radeon_ioctl.c
./radeon/radeon_ioctl.c
--- ../../../../../Mesa.orig/src/mesa/drivers/dri/radeon/radeon_ioctl.c
2004-11-28 16:40:11.0 +0100
+++ ./radeon/radeon_ioctl.c 2004-11-28 16:26:29.0 +0100
@@ -59,7 +59,7 @@
static void radeonWaitForIdle( radeonContextPtr rmesa );
-static int radeonFlushCmdBufLocked( radeonContextPtr rmesa,
+int radeonFlushCmdBufLocked( radeonContextPtr rmesa,
const char * caller );
static void print_state_atom( struct radeon_state_atom *state )
@@ -523,7 +523,7 @@
}
-static int radeonFlushCmdBufLocked( radeonContextPtr rmesa,
+int radeonFlushCmdBufLocked( radeonContextPtr rmesa,
const char * caller )
{
int ret, i;
@@ -757,6 +757,8 @@
rmesa->dma.current.ptr += bytes; /* bug - if alignment > 7 */
rmesa->dma.current.start =
rmesa->dma.current.ptr = (rmesa->dma.current.ptr + 0x7) & ~0x7;
+
+ assert( rmesa->dma.current.ptr <= rmesa->dma.current.end );
}
void radeonAllocDmaRegionVerts( radeonContextPtr rmesa,
@@ -1245,6 +1247,30 @@
radeonWaitForIdle( rmesa );
}
+GLboolean radeonIsGartMemory( radeonContextPtr rmesa, const GLvoid *pointer,
+ GLint size )
+{
+ ptrdiff_t offset = (char *)pointer - (char
*)rmesa->radeonScreen->gartTextures.map;
+ int valid = (size >= 0 &&
+ offset >= 0 &&
+ offset + size < rmesa->radeonScreen->g
Re: tvout support for mach64
On Sun, 28 Nov 2004, Lukas wrote:
> On Sat, 27 Nov 2004 16:55:13 +0200
> Micha Feigin <[EMAIL PROTECTED]> wrote:
>
> > At Fri, 26 Nov 2004 21:10:00 +0100,
> > Lukas wrote:
> >> I am looking for something similar to the patch available from
> >> http://www.retinalburn.net/linux/tvout.html, but suitable for the
> >> current CVS or at least more current than the above. Please give me
> >>> some pointers where I can find the patch you mentioned, or even>
> >better send it me.
> >
> > Its the same patch. There were a couple of rejects IIRC that related
> > to code that was no longer there and I just dropped them. Works for
> > me.
>
> Thanks for the patch. It mostly works for me too. "atitvout" and the
> Fn-F7 key have the desired effects again.
>
> > I attached the patch I am currently using.
> >
> > Also if you want I implemented suspend support for mach64 (basically
> > a port of the radeon suspend code).
>
> Yes, I am interested. I use software suspend 2.0.67 at the moment. After
> resume, "atitvout" no longer works ("VBE call failed."), the Fn-X keys
> still work though. It would be nice if you sent me the additional patch
> too.
>
the suspend is for dri. Didn't check if it affects tvout, but maybe. I
need to clean up the comments a bit and I will send it allong.
> I still have two problems with the mach64:
> - Sometimes (maybe 1 out of 20), the X server crashes when XV is
> initialized, i.e. when mplayer starts. This problem is fairly recent.
Never seen that.
> - Sometimes, the X-Server dies on VT switch, but I think only if
> drm is activated, so this is no real problem.
I have that also, although didn't see it for a while (knock wood ;-)
Just to make sure, did you see that before aplying the patch (I was
suspecting the suspend support patch, so its good to know that its not
that, just to make sure that its not the tvout patch).
I've actually only seen that on calling chvt for suspend not when using
Alt-Ctrl-Fn, switching VT using Alt-Ctrl-Fn before calling the hibernation
script that uses chvt seems to have solved it but I'm not sure, could be
something else.
> Regards, Lukas
>
>
>
> ---
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> --
> ___
> Dri-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>
> +++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.
>
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tvout support for mach64
On Sat, 27 Nov 2004 16:55:13 +0200
Micha Feigin <[EMAIL PROTECTED]> wrote:
> At Fri, 26 Nov 2004 21:10:00 +0100,
> Lukas wrote:
>> I am looking for something similar to the patch available from
>> http://www.retinalburn.net/linux/tvout.html, but suitable for the
>> current CVS or at least more current than the above. Please give me
>>> some pointers where I can find the patch you mentioned, or even>
>better send it me.
>
> Its the same patch. There were a couple of rejects IIRC that related
> to code that was no longer there and I just dropped them. Works for
> me.
Thanks for the patch. It mostly works for me too. "atitvout" and the
Fn-F7 key have the desired effects again.
> I attached the patch I am currently using.
>
> Also if you want I implemented suspend support for mach64 (basically
> a port of the radeon suspend code).
Yes, I am interested. I use software suspend 2.0.67 at the moment. After
resume, "atitvout" no longer works ("VBE call failed."), the Fn-X keys
still work though. It would be nice if you sent me the additional patch
too.
I still have two problems with the mach64:
- Sometimes (maybe 1 out of 20), the X server crashes when XV is
initialized, i.e. when mplayer starts. This problem is fairly recent.
- Sometimes, the X-Server dies on VT switch, but I think only if
drm is activated, so this is no real problem.
Regards, Lukas
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
