Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
| 1999 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(115) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2000 |
Jan
(143) |
Feb
(177) |
Mar
(390) |
Apr
(285) |
May
(316) |
Jun
(241) |
Jul
(303) |
Aug
(504) |
Sep
(322) |
Oct
(368) |
Nov
(398) |
Dec
(474) |
| 2001 |
Jan
(734) |
Feb
(712) |
Mar
(736) |
Apr
(358) |
May
(403) |
Jun
(317) |
Jul
(286) |
Aug
(299) |
Sep
(304) |
Oct
(398) |
Nov
(169) |
Dec
(313) |
| 2002 |
Jan
(406) |
Feb
(506) |
Mar
(520) |
Apr
(629) |
May
(714) |
Jun
(711) |
Jul
(761) |
Aug
(665) |
Sep
(542) |
Oct
(713) |
Nov
(641) |
Dec
(639) |
| 2003 |
Jan
(468) |
Feb
(748) |
Mar
(781) |
Apr
(812) |
May
(789) |
Jun
(731) |
Jul
(567) |
Aug
(579) |
Sep
(624) |
Oct
(647) |
Nov
(387) |
Dec
(422) |
| 2004 |
Jan
(592) |
Feb
(630) |
Mar
(514) |
Apr
(457) |
May
(647) |
Jun
(388) |
Jul
(276) |
Aug
(528) |
Sep
(840) |
Oct
(831) |
Nov
(350) |
Dec
(458) |
| 2005 |
Jan
(584) |
Feb
(654) |
Mar
(706) |
Apr
(229) |
May
(411) |
Jun
(594) |
Jul
(341) |
Aug
(435) |
Sep
(251) |
Oct
(297) |
Nov
(196) |
Dec
(286) |
| 2006 |
Jan
(295) |
Feb
(378) |
Mar
(300) |
Apr
(204) |
May
(241) |
Jun
(316) |
Jul
(256) |
Aug
(346) |
Sep
(338) |
Oct
(352) |
Nov
(288) |
Dec
(272) |
| 2007 |
Jan
(194) |
Feb
(242) |
Mar
(329) |
Apr
(357) |
May
(254) |
Jun
(309) |
Jul
(291) |
Aug
(370) |
Sep
(279) |
Oct
(336) |
Nov
(357) |
Dec
(465) |
| 2008 |
Jan
(396) |
Feb
(370) |
Mar
(407) |
Apr
(350) |
May
(337) |
Jun
(339) |
Jul
(352) |
Aug
(314) |
Sep
(338) |
Oct
(299) |
Nov
(279) |
Dec
(365) |
| 2009 |
Jan
(596) |
Feb
(601) |
Mar
(588) |
Apr
(542) |
May
(731) |
Jun
(701) |
Jul
(673) |
Aug
(1050) |
Sep
(740) |
Oct
(750) |
Nov
(774) |
Dec
(1044) |
| 2010 |
Jan
(835) |
Feb
(1215) |
Mar
(1249) |
Apr
(485) |
May
(138) |
Jun
(164) |
Jul
(143) |
Aug
(148) |
Sep
(102) |
Oct
(121) |
Nov
(74) |
Dec
(83) |
| 2011 |
Jan
(131) |
Feb
(200) |
Mar
(122) |
Apr
(111) |
May
(125) |
Jun
(6) |
Jul
|
Aug
|
Sep
(1) |
Oct
(6) |
Nov
(1) |
Dec
(4) |
| 2012 |
Jan
|
Feb
(4) |
Mar
(2) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
| 2013 |
Jan
(4) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
(6) |
Nov
(15) |
Dec
|
| 2014 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
(6) |
Feb
(10) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
(22) |
2
(49) |
3
(88) |
4
(20) |
5
(16) |
6
(4) |
|
7
(3) |
8
(4) |
9
(38) |
10
(21) |
11
(16) |
12
(24) |
13
(12) |
|
14
(21) |
15
(10) |
16
(34) |
17
(15) |
18
(10) |
19
(16) |
20
(18) |
|
21
(16) |
22
(13) |
23
(16) |
24
(1) |
25
(21) |
26
(34) |
27
(7) |
|
28
(12) |
29
(23) |
30
(40) |
|
|
|
|
|
From: <bugzilla-daemon@bu...> - 2003-09-21 23:30:36
|
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=717
------- Additional Comments From michel@... 2003-21-09 19:30 -------
> How does that explain the "used" status of a drm module that should not be used
> at all ?
It doesn't, that's a different bug.
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|
|
From: <bugzilla-daemon@bu...> - 2003-09-21 22:43:10
|
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=717
------- Additional Comments From ndeb@... 2003-21-09 18:43 -------
> From Jon Smirl 2003-09-21 18:16 -------
> I have also
> noticed that the in-use count does not decrement after the module has been
> opened and you can not rmmod it.
Exactly the same experience here. Problem is with the r128 module. Fortunately,
I did not see this bug in the tdfx module.
> It's the X server, as I tried to indicate with the new summary.
drmAvailable()
> only checks that a DRM is loaded, not whether it's the correct one.
How does that explain the "used" status of a drm module that should not be used
at all ? Also, this bug affects the r128 module, not the tdfx module, as shown
below by lsmod (note that DRI is disabled now):
Module Size Used by Not tainted
tdfx 35384 0
r128 81364 1
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|
|
From: <bugzilla-daemon@bu...> - 2003-09-21 22:29:51
|
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=717
------- Additional Comments From michel@... 2003-21-09 18:29 -------
It's the X server, as I tried to indicate with the new summary. drmAvailable()
only checks that a DRM is loaded, not whether it's the correct one. I have an
idea how to fix it, but I'm very busy right now, hopefully I'll get around to it
in one or two weeks, unless someone beats me to it.
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|
|
From: <bugzilla-daemon@bu...> - 2003-09-21 22:16:08
|
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=717
------- Additional Comments From jonsmirl@... 2003-21-09 18:16 -------
I believe the close code in the r128 kernel module is broken. I have also
noticed that the in-use count does not decrement after the module has been
opened and you can not rmmod it.
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|
|
From: <bugzilla-daemon@bu...> - 2003-09-21 22:05:10
|
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=717
------- Additional Comments From ndeb@... 2003-21-09 18:05 -------
> The usage count of a module is increased when a process opens its device
node.
Thats obvious. But which process ? Neither "lsof" nor "fuser" shows any for the
device /dev/dri/card0 (taken up by r128 whose used count is 1). Any suggestions
?
> It doesn't matter anyway in that case, but as I said this shouldn't even
prevent
> the other server from using it at the same time.
So, what do u think is the problem, kernel/DRM or the X server or both ?
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|
|
From: <bugzilla-daemon@bu...> - 2003-09-21 19:36:54
|
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=717
------- Additional Comments From michel@... 2003-21-09 15:36 -------
> > I guess the X server doesn't close /dev/dri/card0 even though it doesn't use
> > it.
>
> From lsmod, the r128 module is still being "used".
The usage count of a module is increased when a process opens its device node.
> > Again, this shouldn't prevent it from being used by another server though,
> > or does it?
>
> There is _always_ only one X server running at any given time.
It doesn't matter anyway in that case, but as I said this shouldn't even prevent
the other server from using it at the same time.
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|
|
From: <bugzilla-daemon@bu...> - 2003-09-21 15:41:49
|
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=716
------- Additional Comments From ndeb@... 2003-21-09 11:41 -------
Output of "LIBGL_DEBUG=verbose MESA_DEBUG=verbose glxinfo" ->
name of display: :1.0
display: :1 screen: 0
direct rendering: No
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
client glx vendor string: SGI
client glx version string: 1.2
client glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
GLX extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
OpenGL vendor string: Mesa project: http://www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.3 Mesa 4.0.4
OpenGL extensions:
GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_border_clamp,
GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3,
GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_blend_color,
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_texture_env_add,
GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3,
GL_EXT_texture_lod_bias
glu version: 1.3
glu extensions:
GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess
visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav
id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat
----------------------------------------------------------------------
0x23 24 tc 1 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None
0x24 24 tc 1 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None
0x25 24 tc 1 24 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
0x26 24 tc 1 24 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
0x27 24 dc 1 24 0 r y . 8 8 8 0 0 16 0 0 0 0 0 0 0 None
0x28 24 dc 1 24 0 r y . 8 8 8 0 0 16 8 16 16 16 0 0 0 None
0x29 24 dc 1 24 0 r y . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
0x2a 24 dc 1 24 0 r . . 8 8 8 8 0 16 8 16 16 16 16 0 0 None
Nothing useful here.
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|
|
From: <bugzilla-daemon@bu...> - 2003-09-21 15:07:28
|
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=717
------- Additional Comments From ndeb@... 2003-21-09 11:07 -------
> Good. So the real problem seems to be that the X server doesn't load the
correct
> DRM if another one is already loaded. Changing the bug summary accordingly.
Thats only part of the problem. From lsmod, its clear that the r128 module is
being used even though it is not supposed to used (since there is no X server
using the rage128 card). It makes no sense that both r128 and tdfx modules
being "used" when there is only one X server and that is using only the 3dfx
card.
> I guess the X server doesn't close /dev/dri/card0 even though it doesn't use
it.
From lsmod, the r128 module is still being "used".
> Again, this shouldn't prevent it from being used by another server though,
or
> does it?
There is _always_ only one X server running at any given time. And as is clear
by now, if I load the drm module manually _before_ starting X, DRI works fine.
But not otherwise (see comment #4 ).
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|
|
From: Rafael Maximo <maximo@gl...> - 2003-09-21 13:08:38
|
>The drmCommandRead and friends are a wrapper for ioctl. I think the >idea was that they were for portability, but I can't remember. Note >that the numbering of the commands for drmCommand* are different from >the ioctl numbers (subtract 0x40 iirc) -- look at the <card>.h in the >DRM and the <card>_common.h in the 2d driver. > Should i use drmCommand* instead of ioctl? If so, do i need to change the=20 numbering on <card>_common.h ? >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Dri-devel mailing list >Dri-devel@... >https://lists.sourceforge.net/lists/listinfo/dri-devel Rafael M=E1ximo=20 |
|
From: <bugzilla-daemon@bu...> - 2003-09-21 11:42:04
|
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=717
michel@... changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|X server should unload DRM |X server doesn't load
|module when X quits |correct DRM if another one
|(prevents DRI on multiple |is already loaded
|cards) |
------- Additional Comments From michel@... 2003-21-09 07:42 -------
> > [...] I don't agree with your analysis of the cause or conclusion what
> > should be done about it.
>
> My thoughts were based on comment #1 which suggested that the "r128 DRM in
> kernel 2.4.22 doesn't deinitialize correctly".
Well, you engraved your conclusion in the bug summary from the very beginning...
> Thanks for the suggestion. I let the "r128" stay loaded (after quitting X).
> Then I manually loaded the tdfx module and then started X on the voodoo3 card
> and DRI worked !!
Good. So the real problem seems to be that the X server doesn't load the correct
DRM if another one is already loaded. Changing the bug summary accordingly.
> Also, it appears from lsmod that the r128 module is still being used (even
> though X is not using the rage128 card).
I guess the X server doesn't close /dev/dri/card0 even though it doesn't use it.
Again, this shouldn't prevent it from being used by another server though, or
does it?
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|
|
From: <bugzilla-daemon@bu...> - 2003-09-21 11:33:26
|
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=716
------- Additional Comments From michel@... 2003-21-09 07:33 -------
Of course they are nowhere in lib/GL, they're in the 2D driver... and they're
just cosmetic artifacts of direct rendering being disabled, unrelated to the
problem.
To the submitter: Please read my earlier comment more carefully, the value
assigned to LIBGL_DEBUG matters.
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|
|
From: Eric Anholt <eta@lc...> - 2003-09-21 07:23:01
|
On Fri, 2003-09-19 at 20:29, Rafael Maximo wrote: > At 12:44 AM 19/9/2003, Dimitry N. Naldaev wrote: > >Ð ÑообÑении Ð¾Ñ 18 СенÑÑбÑÑ 2003 08:06 Rafael Maximo > >напиÑал: > > > Hi, > > > > > > Some of you already know that i'm trying to work on the savage > > > driver, i'm working on the 3D driver (/lib/GL/mesa/src/drv) and now it is > > > compiling and i'll test it but i got some other problems. After compiling > > > everything (2D, 3D, kernel modules, etc.) my screen on xfree 4.3.0 is a > > > little corrupted (http://max.brz.net/screen.png), > > > >try to switch to another VT and back. does the screen still corrupted ?? > > I tried that, but no change. > > Now glxinfo reposts direct rendering enable and i tried to run glxgear and > i got a real lockup :( > > I also notice that the 3D driver call drmCommandRead() or drmCommandWrite() > where it used to call ioctl(), what exactly drmCommand like functions > differ from ioctl() ? The drmCommandRead and friends are a wrapper for ioctl. I think the idea was that they were for portability, but I can't remember. Note that the numbering of the commands for drmCommand* are different from the ioctl numbers (subtract 0x40 iirc) -- look at the <card>.h in the DRM and the <card>_common.h in the 2d driver. -- Eric Anholt eta@... http://people.freebsd.org/~anholt/ anholt@... |
|
From: <bugzilla-daemon@bu...> - 2003-09-21 03:45:45
|
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=716
------- Additional Comments From idr@... 2003-20-09 23:45 -------
I would investigate the unresolved symboles. Do a 'grep ^Symbol' on the
XFree86.1.log that is attached. That seems hinkey to me. I did a 'grep -r' in
lib/GL in DRI CVS for each of those symbols, and *none* of them appear anywhere
in the source code. Since they don't exist in the source, it seems odd that the
.so should depend on them.
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|
|
From: Rafael Maximo <maximo@gl...> - 2003-09-21 02:50:58
|
Brian, I'm interested seeing the savage driver working on XFfree86 4.3.0 with mesa= =20 5.0.x, you are using a savage driver that is supposed to work on xfree86=20 4.2.0 and i'm working on the same driver but trying to make it works on=20 xfree86 4.3.0 bye. At 08:28 PM 20/9/2003, Brian Penix wrote: >I have been following with interest your trials and tribulations with the >Savage 3D driver. I too am working on it and may have some info for you. I >have all the driver functions working here but only in XFree86 4.2.0. (mesa >3.4.2) I am currently looking for info on the changes to T&L and SWRAST= that >seems to be the tie up for this driver. As it stands, mesa 5.0.x seems= screwy >to me and I have to learn bunches more on it. If you want I can give you= what >I have so far (meaning my mesa 5.0.x based driver files). I am not >experiencing the artifacts you are but maybe my card is slightly different. >In any event, if you want to collaborate with me I think we can figure this >out. To show you that it can work here is my current mesa 3.4.2 glxinfo: > >[penix1@... penix1]$ glxinfo >name of display: :0.0 >Using AGP dma| >DBflag:0 >display: :0 screen: 0 >direct rendering: Yes >server glx vendor string: SGI >server glx version string: 1.2 >server glx extensions: > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context >client glx vendor string: SGI >client glx version string: 1.2 >client glx extensions: > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context >GLX extensions: > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context >OpenGL vendor string: S3 Graphics Inc. >OpenGL renderer string: Mesa DRI SAVAGE Linux_1.1.18 >OpenGL version string: 1.2 Mesa 3.4.2 >OpenGL extensions: > GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_EXT_abgr, > GL_EXT_blend_func_separate, GL_EXT_clip_volume_hint, > GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, > GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_stencil_wrap, > GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_object, > GL_EXT_texture_lod_bias, GL_EXT_vertex_array, GL_MESA_window_pos, > GL_MESA_resize_buffers, GL_NV_texgen_reflection, GL_PGI_misc_hints, > GL_SGIS_pixel_texture, GL_SGIS_texture_edge_clamp >glu version: 1.3 >glu extensions: > GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess > > visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav > id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat >---------------------------------------------------------------------- >0x23 24 tc 0 24 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None >0x24 24 tc 0 24 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None >0x25 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None >0x26 24 tc 0 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None >0x27 24 tc 0 24 0 r y . 8 8 8 8 0 0 0 16 16 16 0 0 0 Slow >0x28 24 tc 0 24 0 r . . 8 8 8 8 0 0 0 16 16 16 0 0 0 Slow >0x29 24 tc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 0 0 0 Slow >0x2a 24 tc 0 24 0 r . . 8 8 8 8 0 24 8 16 16 16 0 0 0 Slow >0x2b 24 dc 0 24 0 r y . 8 8 8 8 0 0 0 0 0 0 0 0 0 None >0x2c 24 dc 0 24 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None >0x2d 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None >0x2e 24 dc 0 24 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None >0x2f 24 dc 0 24 0 r y . 8 8 8 8 0 0 0 16 16 16 0 0 0 Slow >0x30 24 dc 0 24 0 r . . 8 8 8 8 0 0 0 16 16 16 0 0 0 Slow >0x31 24 dc 0 24 0 r y . 8 8 8 8 0 24 8 16 16 16 0 0 0 Slow >0x32 24 dc 0 24 0 r . . 8 8 8 8 0 24 8 16 16 16 0 0 0 Slow > > >Brian Penix. > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Dri-devel mailing list >Dri-devel@... >https://lists.sourceforge.net/lists/listinfo/dri-devel Rafael M=E1ximo=20 |
|
From: <bugzilla-daemon@bu...> - 2003-09-21 02:34:53
|
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=717
------- Additional Comments From ndeb@... 2003-20-09 22:34 -------
> That's the symptom, but I don't agree with your analysis of the cause or
> conclusion what should be done about it.
My thoughts were based on comment #1 which suggested that the "r128 DRM in
kernel 2.4.22 doesn't deinitialize correctly".
> Does it also fail if you load the other DRM manually (instead of unloading
the
> first one) before starting the second server?
Thanks for the suggestion. I let the "r128" stay loaded (after quitting X).
Then I manually loaded the tdfx module and then started X on the voodoo3 card
and DRI worked !!
This is what I have from lsmod:
Module Size Used by Not tainted
tdfx 35384 17
r128 81364 1
agpgart 47524 1 (autoclean)
I also have:
crw-rw-rw- 1 root root 226, 0 Sep 20 12:33 /dev/dri/card0
crw-rw-rw- 1 root root 226, 1 Sep 20 22:23 /dev/dri/card1
In other words, manual loading works. Also, it appears from lsmod that the
r128 module is still being used (even though X is not using the rage128 card).
Any ideas ?
--
Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|
|
From: Alan Cox <alan@lx...> - 2003-09-21 00:17:01
|
On Gwe, 2003-09-12 at 19:53, Maximo wrote: > As i know CLE266 works only on Xfree86 4.2.0, what i'm doing is make > it work on xfree86 4.3.0 I promised folks I'd get around to putting up the XFree 4.3.0 port of the DRI stuff (or what works so far). Don't get too excited as it works if 1. 2D accel is off, 2. The 3D window is on the top 3. It feels like it 4. You run glxgears and not much else. The tar ball of the via gl directory can be found at. http://www.linux.org.uk/~alan/via-gl.tar.gz and is hopefully useful for building a proper via branch in CVS. |
