Do dual DRI devices work in the X Server?
I've been trying to figure out how come X wouldn't load when I have
two of the new drm-core type drivers loaded. Then if finally occurred
to me to load the old drivers and see what X does, it fails too.
I have an AGP radeon and PCI r128. modprobe in radeon and r128. I'll
attach my xconf.
Now start X. It won't start.
In programs/Xserver/GL/dri/dri.c
static int lockRefCount=0;
void
DRILock(ScreenPtr pScreen, int flags)
{
DRIScreenPrivPtr pDRIPriv = DRI_SCREEN_PRIV(pScreen);
if(!pDRIPriv) return;
if (!lockRefCount)
DRM_LOCK(pDRIPriv->drmFD, pDRIPriv->pSAREA, pDRIPriv->myContext, flags);
lockRefCount++;
}
How is this going to work with two DRI devices?
The error is that the first DRILock on the kernel context is never
set. Right before this DRM is not called with a request for a lock
when there should be one. I haven't got an X server put together for
debugging yet, but this sure looks like the likely culprit for why the
lock call isn't being made.
--
Jon Smirl
[EMAIL PROTECTED]
xorg.dual
Description: Binary data
savage test notes/glDrawPixels problem
I downloaded the latest savage and common snapshots today, and I have a few notes (thanks for the great work!): - The snapshots do not work out-of-the-box on 2.6 kernels -- the 2.6 DRM must be downloaded from CVS installed separately (this does not seem to be documented) - My previously reported problem with glDrawPixels is still happens. Card is S3 Inc. SuperSavage IX/C SDR (rev 05) on ThinkPad T23. The problem seems to be that glDrawPixels doesn't work to the back buffer. For example, the 'drawpix' demo shows blackness until the 'f' key is pressed to switch drawing to the front buffer. Drawpix works normally when LIBGL_ALWAYS_INDIRECT is set. It would appear that glDrawPixels is copying pixels to the wrong place. For example, see http://69.5.151.193/~sdh4/dribug.png. The black and colored stripes in this picture are texture portions corrupted by glDrawPixels. (There is supposed to be a map display in the lower right. The glDrawPixels() is supposed to copy this into the back buffer, instead it ends up splattered over the textures). In addition, if you look at the word 'East -76.' in the picture (under 'Marine park'), that text was written with glutBitmapCharacter() (translates to glBitmap()) to the (2D orthogonal) back buffer. Thanks, Steve --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 984] R200 rendering error in blocktube
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://freedesktop.org/bugzilla/show_bug.cgi?id=984 [EMAIL PROTECTED] changed: What|Removed |Added Summary|rendering error -- textures |R200 rendering error in |not applied |blocktube --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 17:58 --- Verified that this is still an issue in blocktube with current CVS, 2004-09-29 (Radeon 8500). -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1058] [PATCH] fix potential 64bit pointer problems
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://freedesktop.org/bugzilla/show_bug.cgi?id=1058 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 17:40 --- Committed, thanks! -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
On Wed, 2004-09-29 at 07:25, Keith Whitwell wrote:
> Jon Smirl wrote:
> >
> > Drivers provide these callbacks..
> >
> > struct drm_driver_fn {
> >u32 driver_features;
> >int dev_priv_size;
> >int permanent_maps;
> >drm_ioctl_desc_t *ioctls;
> >int num_ioctls;
>
> >int (*preinit)(struct drm_device *, unsigned long flags);
> >void (*prerelease)(struct drm_device *, struct file *filp);
> >void (*pretakedown)(struct drm_device *);
> >int (*postcleanup)(struct drm_device *);
> >int (*presetup)(struct drm_device *);
> >int (*postsetup)(struct drm_device *);
> >int (*dma_ioctl)( DRM_IOCTL_ARGS );
> >/* these are opposites at the moment */
> >int (*open_helper)(struct drm_device *, drm_file_t *);
> >void (*free_filp_priv)(struct drm_device *, drm_file_t *);
>
> >void (*release)(struct drm_device *, struct file *filp);
> >void (*dma_ready)(struct drm_device *);
>
> Is this used by any driver?
>
> >int (*dma_quiescent)(struct drm_device *);
>
> >int (*context_ctor)(struct drm_device *dev, int context);
> >int (*context_dtor)(struct drm_device *dev, int context);
> >int (*kernel_context_switch)(struct drm_device *dev, int old, int new);
> >int (*kernel_context_switch_unlock)(struct drm_device *dev);
>
> The whole context thing in the kernel is pretty much cruft. The gamma module
> used to rely on it, maybe the ffb module if that still exists? It would be
> good to see this disappear.
>
> Though the drivers don't rely on it, I don't know if the server-side code
> persists in setting it up regardless, which might make it hard to get rid of.
SiS relies on context ctor/dtor (dtor only, when I'm done) for its
kernel memory manager.
--
Eric Anholt[EMAIL PROTECTED]
http://people.freebsd.org/~anholt/ [EMAIL PROTECTED]
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
On Wed, 29 Sep 2004 23:52:38 +0200, Felix Kühling <[EMAIL PROTECTED]> wrote: > Is it normal that the savage module looks unused? I can actually rmmod > the savage module while X is running. After that direct rending fails > with some error message about permissions ... reloading savage didn't > help (of course, because X wouldn't reinitialize it). A bit later the > box locked up. Is this 0 usage count and the ability to rmmod the module > while X is running specific to the savage driver or do other drivers > show the same behaviour? This is a bug, open is marking the wrong module in use. > Some questions about future driver development: So the new linux-core > and shared-core are the place to do new driver development? If this is > correct then it will be for 2.6 kernels only, right? I suppose there > would some back-porting effort involved in getting a future savage > driver to work with 2.4 again (like adding back all the DRM() macros). There is no real difference between the code in the linux directory and linux-core except for the removal of the DRM macros and the associated restructuring needed to make everything work. When we get linux-core working without problems, it's not there yet, it could become the future 2.6 platform if everyone agrees. The impact of the linux-core changes are minimal on the board specific code. For 2.4 there is a choice: continue using the linux directory or backport linux-core to 2.4. I don't know how much effort everyone wants to put into backporting new driver development to 2.4. There are several possible choices: 1) leave 2.4 alone and stop working on it, 2.4 stays in the linux directory 2) declare the DRM version in the linux-2.4 the final version and only submit bug patches via the kernel process. 3) backport linux-core to 2.4 and so that everything will build on both OS's. Some 2.6 kernel changes are starting to make this a very cluttered option. 4) Make parallel changes to the 2.4 and 2.6 versions. 5) other combinations of these The removal of the DRM macros from files in the shared directory means that things can't be shared again unless 2.4/BSD also move the the core model. I have no strong opinions on what to do about 2.4. I'll go along with whatever the crowd picks. -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1461] missing textures in some games on r200
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://freedesktop.org/bugzilla/show_bug.cgi?id=1461 --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 16:10 --- Created an attachment (id=981) --> (https://freedesktop.org/bugzilla/attachment.cgi?id=981&action=view) work-in-progress texcoord code no problem. The code in the diff though is really in a work-in-progress state (unfortunately no progress was made in some time...), it tries to fix projected texcoords (things like mesa's projtex work in both tcl and almost in non-tcl mode (problem with hw perspective divide)), tries to fix texture coordinate generation, might even fix some problems with 3d textures in tcl/non-tcl mode (due to the previously incorrect use of R200_VTX_STQ0_D3D / texture coord/matrix swapping). texgen still doesn't work correctly in some cases, mixed texgen/nontexgen doesn't work (I still don't know if the chip itself could do it, some hints suggest it could but I couldn't made it work) - ATI doesn't get that correctly itself neither. And most notably some apps which only use normal 2d textures will not work correctly :-(. -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: compiling mach64 kernel module for 2.6.9-rc-mm4 kernel
I made the linux vs linux-2.6 split because people wanted the GPL code isolated. Anyway, it looks like linux-core may override the linux-2.6 directory when we can say it is working. I thought the snapshots were snapshoting the whole DRM tree. I tried to fix it so that if you built the linux directory from 2.6 you would get an error message from the Makefile file. Maybe that hint isn't working on some distributions. -- Jon Smirl [EMAIL PROTECTED] --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: projtex on r200, texturing problem
Am Mittwoch, 29. September 2004 17:26 schrieb Andreas Stenglein:
> maybe this help a bit.. but I think its not a full fix.
Not full for Celestia 'Earth -> ISS' (few textures are still flickering,
Eric?) and xscreensaver's 'pipe' angles are not full rendered.
-Dieter
> Index: Mesa/src/mesa/drivers/dri/r200/r200_context.h
> ===
> RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_context.h,v
> retrieving revision 1.21
> diff -u -r1.21 r200_context.h
> --- Mesa/src/mesa/drivers/dri/r200/r200_context.h 22 Sep 2004
> 06:27:02 - 1.21 +++ Mesa/src/mesa/drivers/dri/r200/r200_context.h
> 29 Sep 2004 16:09:16 - @@ -677,6 +677,11 @@
> */
> GLboolean needproj;
>
> + /**
> +* Q-coord is used for projective texturing. BIT 0..5 = TMU 0..5
> +*/
> + GLuint projtex;
> +
> struct r200_dma_region indexed_verts;
> };
>
> Index: Mesa/src/mesa/drivers/dri/r200/r200_swtcl.c
> ===
> RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_swtcl.c,v
> retrieving revision 1.15
> diff -u -r1.15 r200_swtcl.c
> --- Mesa/src/mesa/drivers/dri/r200/r200_swtcl.c 17 Aug 2004 01:41:32 -
> 1.15 +++ Mesa/src/mesa/drivers/dri/r200/r200_swtcl.c 29 Sep 2004
> 16:09:18 - @@ -89,6 +89,7 @@
> GLuint index = tnl->render_inputs;
> int fmt_0 = 0;
> int fmt_1 = 0;
> + int projtex = 0;
> int offset = 0;
>
>
> @@ -150,15 +151,17 @@
> /* r200 doesn't like 4D texcoords (is that true?):
> */
> if (sz != 4) {
> - emit = EMIT_1F + (sz - 1);
> + emit = EMIT_1F + (sz - 1); /* EMIT_SZ(sz) */
> }
> else {
>sz = 3;
> - emit = EMIT_3F_XYW;
> + emit = EMIT_3F_XYW; /* emit Q-Coord ? (projtex) */
> + projtex |= 1 << i;
> }
>
> fmt_1 |= sz << (3 * i);
> - EMIT_ATTR( _TNL_ATTRIB_TEX0+i, EMIT_SZ(sz), 0 );
> + EMIT_ATTR( _TNL_ATTRIB_TEX0+i, emit, 0 );
> +/* EMIT_ATTR( _TNL_ATTRIB_TEX0+i, EMIT_SZ(sz), 0 ); */
> }
>}
> }
> @@ -166,11 +169,13 @@
>
>
> if ( (rmesa->hw.vtx.cmd[VTX_VTXFMT_0] != fmt_0)
> - || (rmesa->hw.vtx.cmd[VTX_VTXFMT_1] != fmt_1) ) {
> + || (rmesa->hw.vtx.cmd[VTX_VTXFMT_1] != fmt_1)
> + || (rmesa->swtcl.projtex != projtex) ) {
>R200_NEWPRIM(rmesa);
>R200_STATECHANGE( rmesa, vtx );
>rmesa->hw.vtx.cmd[VTX_VTXFMT_0] = fmt_0;
>rmesa->hw.vtx.cmd[VTX_VTXFMT_1] = fmt_1;
> + rmesa->swtcl.projtex= projtex;
>
>rmesa->swtcl.vertex_size =
> _tnl_install_attrs( ctx,
>
> Index: Mesa/src/mesa/drivers/dri/r200/r200_texstate.c
> ===
> RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_texstate.c,v
> retrieving revision 1.13
> diff -u -r1.13 r200_texstate.c
> --- Mesa/src/mesa/drivers/dri/r200/r200_texstate.c 24 Sep 2004
> 04:20:58 - 1.13 +++ Mesa/src/mesa/drivers/dri/r200/r200_texstate.c
> 29 Sep 2004 16:09:19 - @@ -266,6 +266,9 @@
> (log2Width << R200_FACE_WIDTH_4_SHIFT) |
> (log2Height << R200_FACE_HEIGHT_4_SHIFT));
> }
> + else if (tObj->Target == GL_TEXTURE_2D) {
> + t->pp_txformat_x |= R200_TEXCOORD_PROJ;
> + }
>
> t->pp_txsize = (((tObj->Image[0][t->base.firstLevel]->Width - 1) << 0)
> | ((tObj->Image[0][t->base.firstLevel]->Height - 1) << 16));
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: compiling mach64 kernel module for 2.6.9-rc-mm4 kernel
On Wed, 29 Sep 2004 23:33:00 +0200 David <[EMAIL PROTECTED]> wrote: > El Miércoles, 29 de Septiembre del 2004 3:20 AM, Jon Smirl escribió: > > Get the code from here: > > cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvs/dri co drm > > and build in the linux-2.6 directory. > > > > It looks like you are missing drm_sysfs.h which is is the CVS repository. > > I'm building mach64 from CVS on my machine without problems on current > > linus-bk. > > > > There files should be in the linux-2.6 directory: > > [EMAIL PROTECTED] linux-2.6]$ ls > > CVS drm_core.h drm_sysfs.h Makefile Makefile.kernel radeon_i2c.c > > radeon_i2c.h README > > [EMAIL PROTECTED] linux-2.6]$ > > > > Only the 2.4 DRM will build from linux directory, you have to use linux-2.6 > > > > Same problem. Your solution works. > Seems that snapshots are taken from the "linux" directory. > Somebody should make a workaround to let the users (like me) download a > snapshot an install without more complications. I'm just catching up with recent DRM changes. I guess I could make the snapshots include both versions and choose the correct one in the install script based on the output of uname -r. OTOH at some point we'll have to include the new core-personality version in the snapshots. Then it would become 2.6-only. I guess poeple trying bleeding-edge snapshots wouldn't mind that. > > > On Wed, 29 Sep 2004 03:44:07 +0200, Micha Feigin <[EMAIL PROTECTED]> > wrote: [snip] > | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[r200] root window capabilities - xscreensaver need stencil
/opt/Mesa> /usr/X11R6/lib/xscreensaver/endgame -root -visual 0x24 endgame: ignoring `-visual 0x24' because of `-root'. endgame: using root window's visual 0x23. cpu vendor: AuthenticAMD cpu name: AMD Athlon(tm) MP MMX cpu detected. 3DNow! cpu detected. Testing OS support for SSE... yes. Testing OS support for SSE unmasked exceptions... SIGFPE, yes. Tests of OS support for SSE passed. SSE cpu detected. Mesa: software DXTn compression/decompression available Mesa warning: glEnable(GL_STENCIL_TEST) but no stencil buffer Mesa warning: glEnable(GL_STENCIL_TEST) but no stencil buffer Mesa warning: glEnable(GL_STENCIL_TEST) but no stencil buffer Mesa warning: glEnable(GL_STENCIL_TEST) but no stencil buffer Mesa warning: glEnable(GL_STENCIL_TEST) but no stencil buffer [-] Nothing comes up. But if I run 'xcsreensaver &' and try an 'endgame' 'Preview' it works. There are some 'textures' (text from KDE) visible for some fractions of a second in the upper left corner /opt/Mesa> glxinfo name of display: :0.0 cpu vendor: AuthenticAMD cpu name: AMD Athlon(tm) MP MMX cpu detected. 3DNow! cpu detected. Testing OS support for SSE... yes. Testing OS support for SSE unmasked exceptions... SIGFPE, yes. Tests of OS support for SSE passed. SSE cpu detected. Mesa: software DXTn compression/decompression available display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.2 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_fbconfig client glx vendor string: SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_visual_select_group OpenGL vendor string: Tungsten Graphics, Inc. OpenGL renderer string: Mesa DRI R200 20040924 AGP 4x x86/MMX+/3DNow!+/SSE TCL OpenGL version string: 1.3 Mesa 6.2 OpenGL extensions: GL_ARB_imaging, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_convolution, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_blend_equation_separate, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_MESA_window_pos, GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_texture_rectangle, GL_NV_texgen_reflection, GL_SGI_color_matrix, GL_SGI_color_table, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_S3_s3tc 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 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 None 0x24 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x25 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 Slow 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16
Re: New DRM driver model - gets rid of DRM() macros!
On Tue, 28 Sep 2004 11:54:35 -0400 Jon Smirl <[EMAIL PROTECTED]> wrote: > I've checked two new directories into DRM CVS for Linux 2.6 - > linux-core, shared-core. This code implements a new model for DRM > where DRM is split into a core piece and personality modules that > share the core. The major reason for doing this is that it allows me > to remove all of the DRM() macros; something that is causing lot's of > complaints from the Linux kernel people. A single savage works just fine. This is lsmod output with X running: Module Size Used by savage 3520 0 drm62500 3 savage Is it normal that the savage module looks unused? I can actually rmmod the savage module while X is running. After that direct rending fails with some error message about permissions ... reloading savage didn't help (of course, because X wouldn't reinitialize it). A bit later the box locked up. Is this 0 usage count and the ability to rmmod the module while X is running specific to the savage driver or do other drivers show the same behaviour? Some questions about future driver development: So the new linux-core and shared-core are the place to do new driver development? If this is correct then it will be for 2.6 kernels only, right? I suppose there would some back-porting effort involved in getting a future savage driver to work with 2.4 again (like adding back all the DRM() macros). > [snip] > -- > Jon Smirl > [EMAIL PROTECTED] | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1495] r200 Messed up display with UT2004 linux demo
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://freedesktop.org/bugzilla/show_bug.cgi?id=1495 --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 14:52 --- xdriinfo looks for the 3D driver in the same place as any other 3D application. You can override it using the environment variable LIBGL_DRIVERS_PATH. That may also help with your UT2004 problems. -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
On Mer, 2004-09-29 at 22:52, Felix KÃhling wrote: > Module Size Used by > savage 3520 0 > drm62500 3 savage > > Is it normal that the savage module looks unused? looks like a bug. If the drm layer provides the file_operations for the device node then the locking done automatically locks the wrong module. Thats easy to fix with try_module_get() and module_put() --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1495] r200 Messed up display with UT2004 linux demo
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://freedesktop.org/bugzilla/show_bug.cgi?id=1495 --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 14:25 --- Nope, no difference. Does this output from the dri mean anything? $ ./ut2004-demo WARNING: ALC_EXT_capture is subject to change! Xlib: extension "XiG-SUNDRY-NONSTANDARD" missing on display ":0.0". r200_makeX86Normal3fv/197 CVAL 0 OFFSET 14 VAL 448fc4a0 r200_makeX86Normal3fv/198 CVAL 4 OFFSET 20 VAL 448fc4a4 r200_makeX86Normal3fv/199 CVAL 8 OFFSET 25 VAL 448fc4a8 r200_makeX86Normal3fv done r200_makeX86Normal3fv/197 CVAL 0 OFFSET 14 VAL b4e2ebc r200_makeX86Normal3fv/198 CVAL 4 OFFSET 20 VAL b4e2ec0 r200_makeX86Normal3fv/199 CVAL 8 OFFSET 25 VAL b4e2ec4 r200_makeX86Normal3fv done (I know the XiG-SUNDRY-NONSTANDARD bit is irrelevant) -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: compiling mach64 kernel module for 2.6.9-rc-mm4 kernel
El Miércoles, 29 de Septiembre del 2004 3:20 AM, Jon Smirl escribió: > Get the code from here: > cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvs/dri co drm > and build in the linux-2.6 directory. > > It looks like you are missing drm_sysfs.h which is is the CVS repository. > I'm building mach64 from CVS on my machine without problems on current > linus-bk. > > There files should be in the linux-2.6 directory: > [EMAIL PROTECTED] linux-2.6]$ ls > CVS drm_core.h drm_sysfs.h Makefile Makefile.kernel radeon_i2c.c > radeon_i2c.h README > [EMAIL PROTECTED] linux-2.6]$ > > Only the 2.4 DRM will build from linux directory, you have to use linux-2.6 > Same problem. Your solution works. Seems that snapshots are taken from the "linux" directory. Somebody should make a workaround to let the users (like me) download a snapshot an install without more complications. > On Wed, 29 Sep 2004 03:44:07 +0200, Micha Feigin <[EMAIL PROTECTED]> wrote: > > I am trying to compile the mach64 drm kernel module for kernel > > 2.6.9-rc2-mm4 from latest cvs as the code from the mach64 tree from > > January is regrettably no longer compiling for me, too many changes to > > the drm code in the kernel apparently (mostly problems with drmP.h). > > > > Anyway, I downloaded the latest cvs from freedesktop.org according to > > the instructions on the site (it said something about a move of some of > > the cvs code, but didn't seem related to drm). > > > > When I tried to compile it, it gave the following warnings about missing > > symbols and then the driver won't load for the same reason: > > > > *** Warning: "mach64_sysfs_device_add" > > [/home/micha/dev/dri/new/drm/linux/mach64.ko] undefined! *** Warning: > > "remap_page_range" [/home/micha/dev/dri/new/drm/linux/mach64.ko] > > undefined! *** Warning: "mach64_sysfs_device_remove" > > [/home/micha/dev/dri/new/drm/linux/mach64.ko] undefined! *** Warning: > > "mach64_sysfs_create" [/home/micha/dev/dri/new/drm/linux/mach64.ko] > > undefined! *** Warning: "mach64_sysfs_destroy" > > [/home/micha/dev/dri/new/drm/linux/mach64.ko] undefined! > > > > Is the tree supposed to compile now, which one if so and where am I > > going wrong. If not, is there a tag/date thats known to work that I can > > use (I could really use the little acceleration drm gives me for the > > matlab work I do. Not much 3D, but enough to be intolerable without drm > > support). > > > > Thanks > > --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1495] r200 Messed up display with UT2004 linux demo
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://freedesktop.org/bugzilla/show_bug.cgi?id=1495 --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 14:22 --- Ah: $ LIBGL_DEBUG=verbose xdriinfo options r200 libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r200_dri.so Driver "r200" is not installed or does not support configuration. This is because I'm using debian dri packages (2004-07-07) with the snapshot binaries replacing the files in /usr/X11R6/lib/modules-dri-trunk/ xdriinfo is looking in the wrong place. The head of /var/log/XFree86.0.log reads: XFree86 Version 4.3.99.12 (DRI trunk) Release Date: 10 September 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.6.6-1-k7 i686 [ELF] Current Operating System: Linux trigger 2.6.8-1-k7 #1 Mon Sep 13 23:56:00 EDT 20 04 i686 Build Date: 07 July 2004 ... (==) RgbPath set to "/usr/X11R6/lib/X11/rgb" (==) ModulePath set to "/usr/X11R6/lib/modules-dri-trunk" Of course, it's possible that the libGL in there needs updating to a more recent common snapshot. I'll try that. -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1495] r200 Messed up display with UT2004 linux demo
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://freedesktop.org/bugzilla/show_bug.cgi?id=1495 --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 14:01 --- Your comment about driconf not working makes me think you're using an old driver, not the new one from the snapshot. Can you run the following command line (bash): LIBGL_DEBUG=verbose xdriinfo options r200 It should output a line about which driver it tries to load. Make sure this is the one you installed with the snapshot. -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1495] New: r200 Messed up display with UT2004 linux demo
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://freedesktop.org/bugzilla/show_bug.cgi?id=1495 Summary: r200 Messed up display with UT2004 linux demo Product: DRI Version: XOrg CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: General AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I'm using the DRI snapshot as of today (20040929). The display for the UT2004 linux demo (a 250+Mb download unfortunately :( ) is completely messed up -- there are planes of repeated textures sticking out all over the place. Btw, driconf doesn't want to talk to the driver either (?) (It says "Driver "r200" is not installed or does not support configuration.") Setting R200_NO_TCL results in a better display, but the startup sequence has a 'rippled' effect to the circular LOGO. If someone will tell me how, I'll take a screenshot ;) -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
Around 15 o'clock on Sep 29, Keith Whitwell wrote: > A future X-on-GL world where regular applications are presumably doing direct > rendering will change that assumption... I'm not planning on eliminating the X protocol in this environment, so unless cairo really takes off and applications start coding to cairo-on-GL instead of cairo-on-X-on-GL, then we'll have about the same number of contexts, although the X context will be more rational than it currently is. -keith pgpYiZtdZIDDG.pgp Description: PGP signature
Re: New DRM driver model - gets rid of DRM() macros!
On Wed, 2004-09-29 at 07:25, Keith Whitwell wrote: > The whole context thing in the kernel is pretty much cruft. The gamma module > used to rely on it, maybe the ffb module if that still exists? It would be > good to see this disappear. A few Gentoo Sparc folks use ffb, and in some cases it works (http://bugs.gentoo.org/show_bug.cgi?id=65348). -- Donnie Berkholz Gentoo Linux signature.asc Description: This is a digitally signed message part
[Bug 1461] missing textures in some games on r200
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://freedesktop.org/bugzilla/show_bug.cgi?id=1461 --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 07:47 --- I don't have neither Descent 3 nor Heavy Gear 2, but if anyone wants to debug this with free software I suggest a look at Scorched 3D. It seems to suffer from the same bug wrt the projectioned water plane around the islands. -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1220] Garbage screen after resume from suspend to disk
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://freedesktop.org/bugzilla/show_bug.cgi?id=1220 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-09-27 20:44 --- ... which initially was introduced by Michel Daenzer in DRI CVS: revision 1.78 date: 2003-11-04 00:46:05 +; author: daenzer; state: Exp; lines: +66 -25 Memory layout transition: * the 2D driver initializes MC_FB_LOCATION and related registers sanely * the DRM deduces the layout from these registers * clients use the new SETPARAM ioctl to tell the DRM where they think the framebuffer is located in the card's address space * the DRM uses all this information to check client state and fix it up if necessary This is a prerequisite for things like direct rendering with IGP chips and video capturing. Maybe he can help here? -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
Keith Whitwell wrote: Christoph Hellwig wrote: On Wed, Sep 29, 2004 at 03:12:03PM +0100, Keith Whitwell wrote: Thinking about it, it may not have been a problem of crashing, but rather that the behaviour visible from a program attempting to read (or poll) was different with noop versions of these functions to NULL versions, and that was causing problems. This is 18 months ago, so yes, I'm being vague. The X server does look at this file descriptor, which is where the problem would have arisen, but only the gamma & maybe ffb drivers do anything with it. Indeed, for read you're returning 0 now instead of the -EINVAL from common code when no ->read is present. I'd say the current drm behaviour is a bug, but if X drivers rely on it. I'd agree, but it's a widely distributed bug. I guess we can fix it in the X server, but even better would be to rip out the code as it's fundamentally misguided, based on a wierd idea that the kernel would somehow ask the X server to perform a context switch between two userspace clients... The piece of the puzzle you're missing is that the read() function really did used to do something, and was relied upon. If you want to go right back to prehistory, the drm was originally designed as a "core + personality" system, where the core supported a number of different context switching mechanisms to cover a variety of hardware cases. The gamma driver exercised one path, but everything since then has been a lot more simplistic, assuming that the hardware state is lost if another context has been active. Hardware often has the capacity to hold multiple active contexts or to perform fast hardware context save & restore. None of the DRI drivers have attempted to take advantage of that - optimization continues to focus on the single-client scenario. A future X-on-GL world where regular applications are presumably doing direct rendering will change that assumption... Keith --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
Jon Smirl wrote:
Drivers provide these callbacks..
struct drm_driver_fn {
u32 driver_features;
int dev_priv_size;
int permanent_maps;
drm_ioctl_desc_t *ioctls;
int num_ioctls;
int (*preinit)(struct drm_device *, unsigned long flags);
void (*prerelease)(struct drm_device *, struct file *filp);
void (*pretakedown)(struct drm_device *);
int (*postcleanup)(struct drm_device *);
int (*presetup)(struct drm_device *);
int (*postsetup)(struct drm_device *);
int (*dma_ioctl)( DRM_IOCTL_ARGS );
/* these are opposites at the moment */
int (*open_helper)(struct drm_device *, drm_file_t *);
void (*free_filp_priv)(struct drm_device *, drm_file_t *);
void (*release)(struct drm_device *, struct file *filp);
void (*dma_ready)(struct drm_device *);
Is this used by any driver?
int (*dma_quiescent)(struct drm_device *);
int (*context_ctor)(struct drm_device *dev, int context);
int (*context_dtor)(struct drm_device *dev, int context);
int (*kernel_context_switch)(struct drm_device *dev, int old, int new);
int (*kernel_context_switch_unlock)(struct drm_device *dev);
The whole context thing in the kernel is pretty much cruft. The gamma module
used to rely on it, maybe the ffb module if that still exists? It would be
good to see this disappear.
Though the drivers don't rely on it, I don't know if the server-side code
persists in setting it up regardless, which might make it hard to get rid of.
int (*vblank_wait)(struct drm_device *dev, unsigned int *sequence);
/* these have to be filled in */
int (*postinit)(struct drm_device *, unsigned long flags);
Maybe move this up with the other init/cleanup functions so that they are
visibly grouped? Can the large number of init/cleanup functions be
rationalized in some way?
irqreturn_t (*irq_handler)( DRM_IRQ_ARGS );
void (*irq_preinstall)(struct drm_device *dev);
void (*irq_postinstall)(struct drm_device *dev);
void (*irq_uninstall)(struct drm_device *dev);
void (*reclaim_buffers)(struct file *filp);
Maybe rename this to dma_reclaim_buffers() to make clear what code it is
associated with?
unsigned long (*get_map_ofs)(drm_map_t *map);
unsigned long (*get_reg_ofs)(struct drm_device *dev);
void (*set_version)(struct drm_device *dev, drm_set_version_t *sv);
int (*version)(drm_version_t *version);
};
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
On Wed, Sep 29, 2004 at 03:12:03PM +0100, Keith Whitwell wrote: > Thinking about it, it may not have been a problem of crashing, but rather that > the behaviour visible from a program attempting to read (or poll) was > different with noop versions of these functions to NULL versions, and that was > causing problems. This is 18 months ago, so yes, I'm being vague. > > The X server does look at this file descriptor, which is where the problem > would have arisen, but only the gamma & maybe ffb drivers do anything with it. Indeed, for read you're returning 0 now instead of the -EINVAL from common code when no ->read is present. I'd say the current drm behaviour is a bug, but if X drivers rely on it. Similar in poll your return 0 now while the generic code return (POLLIN | POLLOUT | POLLRDNORM | POLLWRNORM) for fds without ->poll, and again I'd say current drm behaviour could be considered a bug. for ->flush there's no behaviour change of not supplying it. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
Keith Whitwell wrote: Christoph Hellwig wrote: On Wed, Sep 29, 2004 at 02:29:24PM +0100, Keith Whitwell wrote: Christoph Hellwig wrote: - drm_flush is a noop. a NULL ->flush does the same thing, just easier - dito or ->poll - dito for ->read Pretty sure you couldn't get away with null for these in 2.4, at least. Umm, of course you could. There's only a hanfull instance defining a ->flush at all. Similarly all file_ops for regular files and many char devices don't have ->poll. no ->read is pretty rare but 2.4 chæcks it aswell. I tried it, led to crashes (panics, I guess) & the change had to be reverted. On reverting the crashes stopped. This was for poll and read: Thinking about it, it may not have been a problem of crashing, but rather that the behaviour visible from a program attempting to read (or poll) was different with noop versions of these functions to NULL versions, and that was causing problems. This is 18 months ago, so yes, I'm being vague. The X server does look at this file descriptor, which is where the problem would have arisen, but only the gamma & maybe ffb drivers do anything with it. Keith --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
Christoph Hellwig wrote: On Wed, Sep 29, 2004 at 03:12:03PM +0100, Keith Whitwell wrote: Thinking about it, it may not have been a problem of crashing, but rather that the behaviour visible from a program attempting to read (or poll) was different with noop versions of these functions to NULL versions, and that was causing problems. This is 18 months ago, so yes, I'm being vague. The X server does look at this file descriptor, which is where the problem would have arisen, but only the gamma & maybe ffb drivers do anything with it. Indeed, for read you're returning 0 now instead of the -EINVAL from common code when no ->read is present. I'd say the current drm behaviour is a bug, but if X drivers rely on it. I'd agree, but it's a widely distributed bug. I guess we can fix it in the X server, but even better would be to rip out the code as it's fundamentally misguided, based on a wierd idea that the kernel would somehow ask the X server to perform a context switch between two userspace clients... Keith --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1461] missing textures in some games on r200
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://freedesktop.org/bugzilla/show_bug.cgi?id=1461 --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 07:02 --- One more data point. Shogo appears to suffer from the same problems as Descent3 and HG2 with r200 cards. -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
> > - once we have Alan's idea of the graphics core implemented drm_init() >should go awaw > - drm_probe (and it's call to drm_fill_in_dev) looks a little fishy, >what about doing the full ->probe callback in each driver where it >can do basic hw setup, dealing with pci and calls back into the drm >core for minor number allocation and common structure allocations. We have mentioned this but 90% of the work done by the drivers would be common, we might do it the otherway I suppose have a driver probe that calls a function in the core, >This would get rid of the ->preinit and ->postinit hooks. > - isn't drm_order just a copy of get_order()? > - any chance to use proper kernel-doc comments instead of the bastdized >and hard to read version you have currently? I think we have doxygen comments in there at the moment - the Mesa/DRI documentation is done with doxygen... > - the coding style is a little strange, like spurious whitespaces inside >braces, maybe you could run it through scripts/Lindent there are a fair few of these in there in the kernel, it could probably do with a Lindent at some stage over the whole thing... > - care to use linux/lists.h instead of opencoded lists, e.g. in >dev->file_last/dev->file_first or dev->vmalist > - drm_flush is a noop. a NULL ->flush does the same thing, just easier > - dito or ->poll > - dito for ->read > - why do you use DRM_COPY_FROM_USER_IOCTL in Linux-specific code? > - drm__mem_info should be converted to fs/seq_file.c functions > - dito for functions in drm_proc.c I think I can apply a lot of these to the current kernel code so I'll probably just start doing patches up for these sort of issues separately I'll get time to create a bitkeeper tree taking Jons changes ready for merging to Andrew at least, and maybe Linus for 2.6.10. Dave. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
Christoph Hellwig wrote: On Wed, Sep 29, 2004 at 02:29:24PM +0100, Keith Whitwell wrote: Christoph Hellwig wrote: - drm_flush is a noop. a NULL ->flush does the same thing, just easier - dito or ->poll - dito for ->read Pretty sure you couldn't get away with null for these in 2.4, at least. Umm, of course you could. There's only a hanfull instance defining a ->flush at all. Similarly all file_ops for regular files and many char devices don't have ->poll. no ->read is pretty rare but 2.4 chæcks it aswell. I tried it, led to crashes (panics, I guess) & the change had to be reverted. On reverting the crashes stopped. This was for poll and read: revision 1.12 date: 2003-04-23 23:42:28 +; author: keithw; state: Exp; lines: +13 -0 Install dummy/noop read & poll fops unless the driver has replacements. revision 1.11 date: 2003-04-22 08:06:13 +; author: keithw; state: Exp; lines: +0 -94 remove DRM read, poll and write_string I didn't do any more investigation & the behaviour may well be different nowadays. Keith --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
On Wed, Sep 29, 2004 at 02:29:24PM +0100, Keith Whitwell wrote: > Christoph Hellwig wrote: > > > - drm_flush is a noop. a NULL ->flush does the same thing, just easier > > - dito or ->poll > > - dito for ->read > > Pretty sure you couldn't get away with null for these in 2.4, at least. Umm, of course you could. There's only a hanfull instance defining a ->flush at all. Similarly all file_ops for regular files and many char devices don't have ->poll. no ->read is pretty rare but 2.4 chæcks it aswell. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
Christoph Hellwig wrote: - drm_flush is a noop. a NULL ->flush does the same thing, just easier - dito or ->poll - dito for ->read Pretty sure you couldn't get away with null for these in 2.4, at least. Keith --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
I have the basics working alright, my only issue was with getting proper sysfs with it, I'll dig up my latest version and post it, I've also got a ported DRM for it, at the moment it was doing something like /sys/devices/vga00 /sys/devices/vga01 one for each user of the card (multi-card would look really ugly) whereas what we probably want is a directory per card along the lines of /sys/device/vga0 /vga1 and then links 0->x for each registered driver or maybe even links like common, dri , fb0 (make the names meaningful as they do have one...) Dave. On Wed, 29 Sep 2004 12:59:55 +0100, Alan Cox <[EMAIL PROTECTED]> wrote: > On Mer, 2004-09-29 at 13:37, Christoph Hellwig wrote: > > - once we have Alan's idea of the graphics core implemented drm_init() > >should go awaw > > Last I heard Dave Airlie had that working having fixed my bugs. > > > > > ___ > xorg mailing list > [EMAIL PROTECTED] > http://freedesktop.org/mailman/listinfo/xorg > --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1461] missing textures in some games on r200
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://freedesktop.org/bugzilla/show_bug.cgi?id=1461 --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 05:19 --- Roland, Celestia show some broken flickering (shadow?) textures, too. '3' (Earth) -> 'g' -> right click -> Satellites -> ISS -> Goto xscrennsaver 'pipes' have broken textures at the pipe angles. Can you test this, too or send your hack? -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: UT2003/4 nearly all textures are broken
Am Montag, 27. September 2004 19:30 schrieb Roland Scheidegger: > Dieter Nützel wrote: > >>So, it seems like we're seeing more ordering issues, now that things get > >>emitted less often. Moving the eye emit to the end mostly fixed > >>neverball's intro screen for me except for occasional flicker, and > >>in-game seemed OK. > > > > Some (little) flickering. > > > >>Do we have any systematic way to > >>figure this stuff out? > > > > Binary 'search' over all combinations? ;-) > > Thinking about it, this might not even be enough. It might be possible > some state atoms have to be reemitted even if they don't change, if some > other atom changes. In that case, simply reordering things in all > possible ways would not fix the bug. Don't know if there are cases where > this might be necessary, just a wild guess... https://freedesktop.org/bugzilla/show_bug.cgi?id=1461 This is with Eric's and Ian's fix. -Dieter --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
On Mer, 2004-09-29 at 13:37, Christoph Hellwig wrote: > - once we have Alan's idea of the graphics core implemented drm_init() >should go awaw Last I heard Dave Airlie had that working having fixed my bugs. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New DRM driver model - gets rid of DRM() macros!
On Tue, Sep 28, 2004 at 11:54:35AM -0400, Jon Smirl wrote: > I've checked two new directories into DRM CVS for Linux 2.6 - > linux-core, shared-core. This code implements a new model for DRM > where DRM is split into a core piece and personality modules that > share the core. The major reason for doing this is that it allows me > to remove all of the DRM() macros; something that is causing lot's of > complaints from the Linux kernel people. I gave it a quick look and it looks great so far. Some ideas that would be nice improvements still (not that some may be inherited from the old drm code, I just looked at the CVS checkout): - once we have Alan's idea of the graphics core implemented drm_init() should go awaw - drm_probe (and it's call to drm_fill_in_dev) looks a little fishy, what about doing the full ->probe callback in each driver where it can do basic hw setup, dealing with pci and calls back into the drm core for minor number allocation and common structure allocations. This would get rid of the ->preinit and ->postinit hooks. - isn't drm_order just a copy of get_order()? - any chance to use proper kernel-doc comments instead of the bastdized and hard to read version you have currently? - the coding style is a little strange, like spurious whitespaces inside braces, maybe you could run it through scripts/Lindent - care to use linux/lists.h instead of opencoded lists, e.g. in dev->file_last/dev->file_first or dev->vmalist - drm_flush is a noop. a NULL ->flush does the same thing, just easier - dito or ->poll - dito for ->read - why do you use DRM_COPY_FROM_USER_IOCTL in Linux-specific code? - drm__mem_info should be converted to fs/seq_file.c functions - dito for functions in drm_proc.c --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1220] Garbage screen after resume from suspend to disk
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://freedesktop.org/bugzilla/show_bug.cgi?id=1220 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 03:49 --- *** Bug 1398 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1220] Garbage screen after resume from suspend to disk
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://freedesktop.org/bugzilla/show_bug.cgi?id=1220 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 03:03 --- not in CVS yet, have to wait, till it's done -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1220] Garbage screen after resume from suspend to disk
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://freedesktop.org/bugzilla/show_bug.cgi?id=1220 --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 02:54 --- If you close the bug as FIXED it indicates that the fix is already in CVS. Is it? -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1220] Garbage screen after resume from suspend to disk
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://freedesktop.org/bugzilla/show_bug.cgi?id=1220
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
--- Additional Comments From [EMAIL PROTECTED] 2004-09-29 02:51 ---
thx for help,
the patch works fine
this is the right fix:
} else
if (!RADEONModeInit(pScrn, pScrn->currentMode)) return FALSE;
+RADEONSetFBLocation (pScrn);
#ifdef XF86DRI
if (info->directRenderingEnabled) {
/* get the Radeon back into shape after resume */
thx for your help, I hope it'll be included in the next release
--
Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1220] Garbage screen after resume from suspend to disk
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://freedesktop.org/bugzilla/show_bug.cgi?id=1220 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #975 is|0 |1 obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2004-09-29 01:15 --- Created an attachment (id=980) --> (https://freedesktop.org/bugzilla/attachment.cgi?id=980&action=view) Updated fix After reading a line or two of code I suspect that you are right. Didn't include it before the #ifdef XF86DRI, because the bug only showed up w/ dri enabled. -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
