Two module_param problems with Linux 2.6.4
Two small problems I had with Linux 2.6.4: 1. In order to make drm_stub.c compile without errors I had to #include linux/moduleparam explicitly. 2. drm_compat.h defines an empty module_param if it's undefined. It should do the same for module_param_named. Regards, Felix -- | 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: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Latest Mesa CVS (DRI) do not compile (since glx indirect?)
On Wed, Oct 27, 2004 at 04:31:13PM -0700, Ian Romanick wrote: Dieter Nützel wrote: gcc -c -I../../include -I../../src/mesa -I../../src/mesa/main -I../../src/mesa/glapi -I../../src/mesa/math -I../../src/mesa/tnl-I../../src/mesa/shader -I../../src/mesa/swrast -I../../src/mesa/swrast_setup -Wall -O -march=athlon -ansi -pedantic -fPIC -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -DUSE_XSHM -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DPTHREADS -I/usr/X11R6/include glapi/glapi.c -o glapi/glapi.o In file included from glapi/glapi.c:129: glapi/glapitemp.h: In function `NoOpGetInfoLogARB': glapi/glapitemp.h:3783: error: parameter name omitted glapi/glapitemp.h:3783: error: parameter name omitted glapi/glapitemp.h:3783: error: parameter name omitted glapi/glapitemp.h:3785: error: parse error before ',' token I just saw this as well. It appears to be related to the recent GLSL changes. I'll try to poke around at it tonight, if nobody beats me to it. So GLSL will be supported in Mesa/DRI in the near future? :) -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
sparc ffb drm driver... (fwd)
I've just sent this to lkml, anyone here any views on it? Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person -- Forwarded message -- Date: Thu, 28 Oct 2004 12:38:08 +0100 (IST) From: Dave Airlie [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: sparc ffb drm driver... This driver is broken and has been since my first CVS merge went in back in April, I just noticed there now when trying to fix it up for some other changes that I was making, List of issues: a) no-one has complained or noticed it has been broken for at least 4 months b) there is no current user space to go with the kernel space driver (Mesa DRI driver is broken as far as I know) c) no-one has stepped up to maintain it d) no-one has a working user space to tell me I broke the kernel space or test it for me .. Unless we can up with some plan for the future (user and kernel space), this driver will be marked broken in my next merge and may in fact end up broken as a side effect of the changes for the core/personality split.. Dave. p.s. I'd love to take it on, but I've no sparc hardware and no real spare time even if I had... -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Wiki Spam
Am Mi, den 27.10.2004 schrieb Adam Jackson um 21:46: On Wednesday 27 October 2004 14:49, Alan Swanson wrote: Until someone has the time to upgrade the Wiki to a newer version with anti-spam features could we at least block any commits which don't have comments? Just that none of the spam commits ever have comments, plus it would make tracking changes easier. I'm tempted to just turn off all updates for the moment. I attempted to use one of the antispam scripts for moinmoin but it made everything return with 500 errors. #moin thinks we're insane for using such an old version. The pages themselves should be compatible with the newer versions so we may want to upgrade. The problem seems to be that there's a different version of python in use depending on whether you're on the web server or the shell server. Can someone with more sourceforge-fu than myself clarify the situation? Last thing I heard of it was that the web server uses a ridiculously old python version. One thought that occurred to me was to move the Wiki to fd.o. We don't have to use the fd.o wiki system (Tiki AFAIK) but we could use a local MoinMoin installation in ~dri. The sf.net page could automatically forward to it. Newer MoinMoin versions support user authentication which should put a stop to Wiki spam. Another problem is that José Fonseca made some modifications to MoinMoin that would have to be ported to the new version. I'm not sure what those changes are. José, are you reading this? - ajax -- | 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: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sparc ffb drm driver... (fwd)
you may have beta-testers / developpers on #gentoo-sparc on freenode... people there have that kind of hardware. just my 2 cents, of course. François On Thu, 28 Oct 2004 12:42:09 +0100 (IST) Dave Airlie [EMAIL PROTECTED] wrote: I've just sent this to lkml, anyone here any views on it? Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person -- Forwarded message -- Date: Thu, 28 Oct 2004 12:38:08 +0100 (IST) From: Dave Airlie [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: sparc ffb drm driver... This driver is broken and has been since my first CVS merge went in back in April, I just noticed there now when trying to fix it up for some other changes that I was making, List of issues: a) no-one has complained or noticed it has been broken for at least 4 months b) there is no current user space to go with the kernel space driver (Mesa DRI driver is broken as far as I know) c) no-one has stepped up to maintain it d) no-one has a working user space to tell me I broke the kernel space or test it for me .. Unless we can up with some plan for the future (user and kernel space), this driver will be marked broken in my next merge and may in fact end up broken as a side effect of the changes for the core/personality split.. Dave. p.s. I'd love to take it on, but I've no sparc hardware and no real spare time even if I had... -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: What is driverSwapMethod = DRI_HIDE_X_CONTEXT?
Jon Smirl wrote: I just changed DRM to alternative between zero and POLLIN This will make the DRM poll() function work like the kernel expects it to and still work with existing X servers. Can someone please get this incorrect code out of the X server? I got some mysterious server crashes since some time (week or so), about once per day, so it looks like the alternate polling isn't working. Just as Felix I got the WaitForSomething(): select: errno=22 error message. The corresponding bugzilla entry is here: http://freedesktop.org/bugzilla/show_bug.cgi?id=1505. This is with the radeon DDX (rv250), and Xorg cvs (10 days old currently). I've switched back to the non-core drm version for now and will see if this indeed fixes that crash. Roland --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Problems with compiling new savage patch.
Well, it seemed to install fine, but direct rendering is disabled. I also get this error in my Xorg.0.log: Symbol SavageInitStreamsNew from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol SavageInitStreams2000 from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol SavageInitStreamsOld from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! [EMAIL PROTECTED] ~ $ glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: No 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_SGIS_multisample OpenGL vendor string: Mesa project: www.mesa3d.org OpenGL renderer string: Mesa GLX Indirect OpenGL version string: 1.2 (1.5 Mesa 6.1) OpenGL extensions: GL_ARB_depth_texture, GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, GL_ARB_transpose_matrix, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate, GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array, GL_APPLE_packed_pixels, GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, GL_ATIX_texture_env_combine3, GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, GL_MESA_pack_invert, GL_MESA_ycbcr_texture, GL_NV_blend_square, GL_NV_point_sprite, GL_NV_texgen_reflection, GL_NV_texture_rectangle, GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SGIX_depth_texture, GL_SGIX_shadow, GL_SGIX_shadow_ambient, GL_SUN_multi_draw_arrays 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 -- 0x22 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x23 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 0 0 0 0 0 0 None 0x24 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow 0x25 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 0 0 0 0 0 0 Slow 0x26 16 tc 0 16 0 r y . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x27 16 tc 0 16 0 r . . 5 6 5 0 0 16 0 16 16 16 0 0 0 Slow 0x28 16 tc 0 16 0 r y . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow 0x29 16 tc 0 16 0 r . . 5 6 5 0 0 16 8 16 16 16 0 0 0 Slow [EMAIL PROTECTED] ~ $ lsmod Module Size Used by ds 14404 2 yenta_socket 18880 0 pcmcia_core60420 2 ds,yenta_socket ipv6 223040 8 snd_via82xx22916 0 snd_ac97_codec 73632 1 snd_via82xx snd_mpu401_uart 6144 1 snd_via82xx snd_rawmidi20772 1 snd_mpu401_uart snd_seq_oss32384 0 snd_seq_midi_event 6336 1 snd_seq_oss snd_seq50256 4 snd_seq_oss,snd_seq_midi_event snd_seq_device 6860 3 snd_rawmidi,snd_seq_oss,snd_seq snd_pcm_oss50536 0 snd_pcm86408 3 snd_via82xx,snd_ac97_codec,snd_pcm_oss snd_timer 22084 2 snd_seq,snd_pcm snd_page_alloc 7496 2 snd_via82xx,snd_pcm snd_mixer_oss 17920 1
Re: What is driverSwapMethod = DRI_HIDE_X_CONTEXT?
On Thu, 28 Oct 2004 15:11:26 +0200, Roland Scheidegger [EMAIL PROTECTED] wrote: Jon Smirl wrote: I just changed DRM to alternative between zero and POLLIN This will make the DRM poll() function work like the kernel expects it to and still work with existing X servers. Can someone please get this incorrect code out of the X server? I got some mysterious server crashes since some time (week or so), about once per day, so it looks like the alternate polling isn't working. Just as Felix I got the WaitForSomething(): select: errno=22 error message. The corresponding bugzilla entry is here: http://freedesktop.org/bugzilla/show_bug.cgi?id=1505. This is with the radeon DDX (rv250), and Xorg cvs (10 days old currently). I've switched back to the non-core drm version for now and will see if this indeed fixes that crash. I just changed this to always return the broken response of zero. When this gets fixed in the Xserver we can use a DRM interface version number to control returning the correct response. Meanwhile I guess the kernel developers are going to have to live with Xserver/DRM making up their own rules for how poll() works. -- Jon Smirl [EMAIL PROTECTED] --- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sparc ffb drm driver... (fwd)
On Thu, 2004-10-28 at 05:04, khaqq wrote: you may have beta-testers / developpers on #gentoo-sparc on freenode... people there have that kind of hardware. just my 2 cents, of course. Ferris McCormick (fmccor) in that channel definitely has the hardware -- not sure who else. I know he's gotten in touch with you at some point about ffb, as well as with Jon Smirl. As far as the status goes, http://bugs.gentoo.org/show_bug.cgi?id=65348 has a little info. It worked (sort of) in xorg 6.8. I would guess many users don't bother using CVS but just wait for the next xorg release, so that's why you aren't getting reports from an already small community. --- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 depth buffer
Hi, First of all, you should really check out the r300_driver module from CVS of the r300 project on SourceForge, and especially have a look at docs/r300_reg.h, which is where I put all register information that I and others have found so far. On Tuesday 26 October 2004 14:18, Jerome Glisse wrote: Hi, I was playing a little around with r300 mainly looking at depth buffer. I'm still unable to make it work properly. Thus i have few questions. In radeon driver it seems that default value for z_scale z_offset are 0 (radeon/radeon_state_init.c) Why are they set like that ? I changed the depth in order to have something more conveniant on screen : adaptor.depth_pitch=display_width | (0x8 16); maybe better to write it as : adaptor.depth_pitch=display_width | (0x4 17); As long as we don't know what these constants mean, is there really a difference? in void Emit3dRegs(void) i used informations from radeon register. /* do not enable either of stencil, Z or anything else */ e32(CP_PACKET0(RADEON_RB3D_CNTL,0)); e32(RADEON_COLOR_FORMAT_ARGB | RADEON_Z_ENABLE); e32(CP_PACKET0(RADEON_RB3D_ZSTENCILCNTL,0)); e32(RADEON_Z_WRITE_ENABLE | RADEON_DEPTH_FORMAT_32BIT_FLOAT_Z | RADEON_Z_TEST_LESS); Basically everything in the 3D hardware interface has changed from R200 to R300, so the above almost certainly doesn't do what you want. Again, have a look at r300_reg.h Also, my work-in-progress driver can already clear the depth buffer in hardware in a way that is consistent with the software fallback, so you can have a look at how the registers are set up there, in r300_ioctl.c and r300_state.c. Maybe we should put somewhere a list of things to find and who is working on it, thus people won't work on the same things in the mean time or they could work together more eviciently. Also maybe it could be usefull to make a plan of things we want to discover. z buffer stencil buffer That would be very helpful. I haven't looked at stencil settings at all, and I'm kind of confused about the Z-buffer format. The R300 seems to use ZZZS format for 24bit depth/8bit stencil where the R300 used SZZZ. matrix stack for modelview, projection texture (is the information of radeon enought ?) I think I've pretty much got that down. The R300 has a very flexible programmable vertex processor, and the driver is responsible for setting up the correct matrices. TL route Again, I think I've got most of that down. If you could help with texture specification/formats, I'd be very thankful. The register addresses are already in r300_reg.h, but the texture format itself, how mipmaps work etc. is still a mystery. I think with this feature we could make a quite good first hardware accelerated driver. By the way i find that clear_depth_buffer clear_color_buffer are quite complex. Is all the stuff they have in really necessary ? (i will try to look at that latter but if someone already done it). No, most of those are redundant state updates produced by ATI's proprietary driver. Again, look at how the work-in-progress DRI driver does it. Oh yes i almost forgot :) my device id is 0x4e4a (it is a radeon 9800) I've added this and other IDs from pciids.sf.net to the experimental driver in r300_driver/drm cu, Nicolai Jerome Glisse pgpvsr9MCtyY6.pgp Description: PGP signature
Re: X11R6.8.2 maintenance release plans and call for comments.
Hello, On Wed, 2004-10-27 at 09:28, Ely Levy wrote: I supported it then and I still think it's a great idea, It would let people feel that they have influance and let us see what people want (but we said it all in the thread there). what I would like to see, is two trees one for testings (stable) and one for development (unstable) The one for developing should have also development of Mesa and drm (that it is now on trunk tree) and the test tree should be updated ( drives , dri-drives, Mesa, drm and whatever ) only when is consolidated the development. Conclusion in my point of view: The development tree should be, what is now the trunk tree and xorg tree should be more stable, if someone want try experimental code can do it in trunk (of course trunk has to be one xorgR6.8.1). thats my opinion. thats, -- Sérgio M. B. --- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[ dri-Bugs-1056280 ] supplied host.def missing keyboard driver
Bugs item #1056280, was opened at 2004-10-28 12:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=100387aid=1056280group_id=387 Category: Other Group: Build/Compile Fails Status: Open Priority: 5 Submitted By: jholt (jholt1234) Assigned to: Nobody/Anonymous (nobody) Summary: supplied host.def missing keyboard driver Initial Comment: the host.def referenced in the Building DRI is missing the keyboard driver in #define XinputDrivers here is a patch that builds both the keyboard and mouse input drivers for XOrg -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=100387aid=1056280group_id=387 --- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
glxtest with fglrx / r200
For anyone interested, I have attached a modified pretty_print_command_stream.tcl. It should make it easier to analyze the fglrx driver on r200 cards, since it knows all register names (which are documented) of the r200. (This version is certainly useless on r300 based cards.) I have also inserted some register names from the original radeon, if they looked like they have the same purpose than on r200 based cards (those names which have prefix R200 are from the r200_reg.h, those with RADEON are from radeon_reg.h or from radeon_drv.h). Some interesting (imho) things I found: The fglrx driver uses the old txformat/txfilter etc. registers from the radeon for tex units 0-2, since it never run on the old radeon cards this is a bit weird. It writes to some undocumented registers: - 0x1c30, right between RB3D_ZSTENCILCNTL and RB3D_ZMASKOFFSET. Seems to write always 0 though. - 0x2cf8. No idea what this is good for, but in the couple of demos I tried the driver always wrote 0x17. - 0x2680. Always 0. - 0x2210, 0x2214, 0x2218, 0x221c. Those actually exist in radeon_reg.h, but I have some doubts they have the same use (they are the emmissive part of the material property, but other parts of the same material use registers which are for something different on r200). - 0x2284. This one is interesting. The script gives this the name X_VAP_PVS_WAITIDLE, the driver always emits this right before R200_SE_VAP_CNTL. Apparently it exists on r200 too. Looks like it forces the VAP (whatever that stands for...) to wait. Would we need to emit that too? - 0x3254 (ZCACHE_CTLSTAT, I only saw the value 0x05), 0x325c (only saw 0x03), 3260 (only saw 0x0). Roland r200_pretty_print_command_stream.tcl Description: Tcl script
Re: glxtest with fglrx / r200
On Thursday 28 October 2004 20:11, Roland Scheidegger wrote: - 0x2284. This one is interesting. The script gives this the name X_VAP_PVS_WAITIDLE, the driver always emits this right before R200_SE_VAP_CNTL. Apparently it exists on r200 too. Looks like it forces the VAP (whatever that stands for...) to wait. Would we need to emit that too? The guessed register name is from me. On the R300, fglrx almost always writes 0 to this register before changing any vertex processor-related state, so I assume that it has some kind of serialising purpose. However, I have yet to run into any situation where emitting it makes any difference in my own code, so I don't know this for sure. cu, Nicolai pgp0GdyzVtEM4.pgp Description: PGP signature
Re: Problems with compiling new savage patch.
Hi, Felix I had also problem to compile your patches and after check and recheck if isn't my fault, I get the conclusion that I can compile mesa with make in /opt/trunk/Mesa, but can't compile it if I try compile from xorg cvs ( with extra/Mesa linked to /opt/trunk/Mesa). sorry for unfinish message but I will without net in 4 minutes, thanks, -- Srgio M. B.
[PATCH 9/23] Lock initializer unifying Batch 2 (DRM)
To make spinlock/rwlock initialization consistent all over the kernel, this patch converts explicit lock-initializers into spin_lock_init() and rwlock_init() calls. Currently, spinlocks and rwlocks are initialized in two different ways: lock = SPIN_LOCK_UNLOCKED spin_lock_init(lock) rwlock = RW_LOCK_UNLOCKED rwlock_init(rwlock) this patch converts all explicit lock initializations to spin_lock_init() or rwlock_init(). (Besides consistency this also helps automatic lock validators and debugging code.) The conversion was done with a script, it was verified manually and it was reviewed, compiled and tested as far as possible on x86, ARM, PPC. There is no runtime overhead or actual code change resulting out of this patch, because spin_lock_init() and rwlock_init() are macros and are thus equivalent to the explicit initialization method. That's the second batch of the unifying patches. Signed-off-by: Thomas Gleixner [EMAIL PROTECTED] Acked-by: Ingo Molnar [EMAIL PROTECTED] --- drm_drv.h |2 +- gamma_lists.h |6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) --- diff -urN 2.6.10-rc1/drivers/char/drm/drm_drv.h 2.6.10-new/drivers/char/drm/drm_drv.h --- 2.6.10-rc1/drivers/char/drm/drm_drv.h 2004-10-18 23:54:55.0 +0200 +++ 2.6.10-new/drivers/char/drm/drm_drv.h 2004-10-25 16:17:49.0 +0200 @@ -447,7 +447,7 @@ dev = (DRM(device)[DRM(numdevs)]); memset( (void *)dev, 0, sizeof(*dev) ); - dev-count_lock = SPIN_LOCK_UNLOCKED; + spin_lock_init(dev-count_lock); init_timer( dev-timer ); sema_init( dev-struct_sem, 1 ); sema_init( dev-ctxlist_sem, 1 ); diff -urN 2.6.10-rc1/drivers/char/drm/gamma_lists.h 2.6.10-new/drivers/char/drm/gamma_lists.h --- 2.6.10-rc1/drivers/char/drm/gamma_lists.h 2004-10-18 23:53:44.0 +0200 +++ 2.6.10-new/drivers/char/drm/gamma_lists.h 2004-10-25 16:17:47.0 +0200 @@ -45,8 +45,8 @@ bl-rp = bl-bufs; bl-wp = bl-bufs; bl-end= bl-bufs[bl-count+1]; - bl-write_lock = SPIN_LOCK_UNLOCKED; - bl-read_lock = SPIN_LOCK_UNLOCKED; + spin_lock_init(bl-write_lock); + spin_lock_init(bl-read_lock); return 0; } @@ -110,7 +110,7 @@ bl-low_mark = 0; bl-high_mark = 0; atomic_set(bl-wfh, 0); - bl-lock = SPIN_LOCK_UNLOCKED; + spin_lock_init(bl-lock); ++bl-initialized; return 0; } --- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Latest Mesa CVS (DRI) do not compile (since glx indirect?)
Am Donnerstag, 28. Oktober 2004 01:31 schrieb Ian Romanick: Dieter Ntzel wrote: gcc -c -I../../include -I../../src/mesa -I../../src/mesa/main -I../../src/mesa/glapi -I../../src/mesa/math -I../../src/mesa/tnl-I../../src/mesa/shader -I../../src/mesa/swrast -I../../src/mesa/swrast_setup -Wall -O -march=athlon -ansi -pedantic -fPIC -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -DUSE_XSHM -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DPTHREADS -I/usr/X11R6/include glapi/glapi.c -o glapi/glapi.o In file included from glapi/glapi.c:129: glapi/glapitemp.h: In function `NoOpGetInfoLogARB': glapi/glapitemp.h:3783: error: parameter name omitted glapi/glapitemp.h:3783: error: parameter name omitted glapi/glapitemp.h:3783: error: parameter name omitted glapi/glapitemp.h:3785: error: parse error before ',' token I just saw this as well. It appears to be related to the recent GLSL changes. I'll try to poke around at it tonight, if nobody beats me to it. Now, I get this in Mesa CVS: gcc -I../../include -Wall -O -march=athlon -ansi -pedantic -fPIC -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -DUSE_XSHM -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DPTHREADS -I/usr/X11R6/include arbfplight.c -L../../lib -lglut -lGLU -lGL -lm -o arbfplight arbfplight.c: In function `Init': arbfplight.c:236: Warnung: string length `900' is greater than the length `509'ISO C89 compilers are required to support arbfplight.c:262: Warnung: string length `729' is greater than the length `509'ISO C89 compilers are required to support ../../lib/libGL.so: undefined reference to `_mesa_AttachObjectARB' ../../lib/libGL.so: undefined reference to `_mesa_Uniform1iARB' ../../lib/libGL.so: undefined reference to `_mesa_Uniform1fvARB' ../../lib/libGL.so: undefined reference to `_mesa_Uniform3fvARB' ../../lib/libGL.so: undefined reference to `_mesa_GetObjectParameterivARB' ../../lib/libGL.so: undefined reference to `_mesa_GetObjectParameterfvARB' ../../lib/libGL.so: undefined reference to `_mesa_CreateProgramObjectARB' ../../lib/libGL.so: undefined reference to `_mesa_Uniform1fARB' ../../lib/libGL.so: undefined reference to `_mesa_GetAttachedObjectsARB' ../../lib/libGL.so: undefined reference to `_mesa_UniformMatrix3fvARB' ../../lib/libGL.so: undefined reference to `_mesa_GetActiveAttribARB' ../../lib/libGL.so: undefined reference to `_mesa_ShaderSourceARB' ../../lib/libGL.so: undefined reference to `_mesa_GetInfoLogARB' ../../lib/libGL.so: undefined reference to `_mesa_ValidateProgramARB' ../../lib/libGL.so: undefined reference to `_mesa_LinkProgramARB' ../../lib/libGL.so: undefined reference to `_mesa_DeleteObjectARB' ../../lib/libGL.so: undefined reference to `_mesa_CompileShaderARB' ../../lib/libGL.so: undefined reference to `_mesa_Uniform3iARB' ../../lib/libGL.so: undefined reference to `_mesa_GetShaderSourceARB' ../../lib/libGL.so: undefined reference to `_mesa_GetHandleARB' ../../lib/libGL.so: undefined reference to `_mesa_GetUniformfvARB' ../../lib/libGL.so: undefined reference to `_mesa_Uniform3fARB' ../../lib/libGL.so: undefined reference to `_mesa_Uniform4iARB' ../../lib/libGL.so: undefined reference to `_mesa_Uniform2ivARB' ../../lib/libGL.so: undefined reference to `_mesa_Uniform4fARB' ../../lib/libGL.so: undefined reference to `_mesa_GetAttribLocationARB' ../../lib/libGL.so: undefined reference to `_mesa_UniformMatrix2fvARB' ../../lib/libGL.so: undefined reference to `_mesa_Uniform3ivARB' ../../lib/libGL.so: undefined reference to `_mesa_Uniform2fARB' ../../lib/libGL.so: undefined reference to `_mesa_GetActiveUniformARB' ../../lib/libGL.so: undefined reference to `_mesa_GetUniformLocationARB' ../../lib/libGL.so: undefined reference to `_mesa_GetUniformivARB' ../../lib/libGL.so: undefined reference to `_mesa_Uniform4fvARB' ../../lib/libGL.so: undefined reference to `_mesa_Uniform4ivARB' ../../lib/libGL.so: undefined reference to `_mesa_Uniform2iARB' ../../lib/libGL.so: undefined reference to `_mesa_Uniform2fvARB' ../../lib/libGL.so: undefined reference to `_mesa_DetachObjectARB' ../../lib/libGL.so: undefined reference to `_mesa_Uniform1ivARB' ../../lib/libGL.so: undefined reference to `_mesa_CreateShaderObjectARB' ../../lib/libGL.so: undefined reference to `_mesa_BindAttribLocationARB' ../../lib/libGL.so: undefined reference to `_mesa_UniformMatrix4fvARB' ../../lib/libGL.so: undefined reference to `_mesa_UseProgramObjectARB' collect2: ld returned 1 exit status make[3]: *** [arbfplight] Fehler 1 make[3]: Leaving directory `/opt/Mesa/progs/demos' make[2]: *** [subdirs] Fehler 1 make[2]: Leaving directory `/opt/Mesa/progs' make[1]: *** [default] Fehler 1 make[1]: Leaving directory `/opt/Mesa' make: *** [linux-x86] Fehler 2 0.444u 0.135s 0:00.61 93.4% 0+0k 0+0io 0pf+0w And in DRI XFree86: making all in programs/Xserver/GL/mesa/main... make[7]: Entering directory
Re: X11R6.8.2 maintenance release plans and call for comments.
--- Sérgio M. Basto [EMAIL PROTECTED] wrote: Hello, On Wed, 2004-10-27 at 09:28, Ely Levy wrote: I supported it then and I still think it's a great idea, It would let people feel that they have influance and let us see what people want (but we said it all in the thread there). what I would like to see, is two trees one for testings (stable) and one for development (unstable) The one for developing should have also development of Mesa and drm (that it is now on trunk tree) and the test tree should be updated ( drives , dri-drives, Mesa, drm and whatever ) only when is consolidated the development. There is another problem with the Xorg(stable or unstable) tree getting too far ahead of the Mesa/drm trees, AKA can't build Mesa with latesed Xorg. As A solution I propose that branch tags be added to the Xorg tree for Mesa/drm developement. 1. These branchs should have corrisponding statik/regular tags in the Mesa and drm trees. 2. This way if you look for the tag(in Mesa) for the last tag-id your CO had, you could CO that branch from Xorg and it would allways(IAPW) build. 3. When Mesa development needs another feature(or bugfix from another Xorg branch) added to there branch it's easy. 4. These changes would be folded into Xorg's unstable whenever Mesa's code is knowen to build with it... The Xorg branch gets mearged to unstable. Another Xorg branch is created. The Mesa and drm trees get taged with the new tag-id used in Xorg's CVS. Conclusion in my point of view: The development tree should be, what is now the trunk tree and xorg tree should be more stable, if someone want try experimental code can do it in trunk (of course trunk has to be one xorgR6.8.1). thats my opinion. thats, -- Sérgio M. B. --- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail --- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[2.6 patch] DRM: remove unused functions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The patch below removes two unused functions from DRM.
diffstat output:
drivers/char/drm/i810_dma.c | 18 --
drivers/char/drm/i915_dma.c | 18 --
2 files changed, 36 deletions(-)
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
- --- linux-2.6.10-rc1-mm1-full/drivers/char/drm/i810_dma.c.old 2004-10-28
22:55:34.0 +0200
+++ linux-2.6.10-rc1-mm1-full/drivers/char/drm/i810_dma.c 2004-10-28
22:55:45.0 +0200
@@ -51,24 +51,6 @@
#define up_write up
#endif
- -static inline void i810_print_status_page(drm_device_t *dev)
- -{
- - drm_device_dma_t *dma = dev-dma;
- - drm_i810_private_t *dev_priv = dev-dev_private;
- - u32 *temp = dev_priv-hw_status_page;
- - int i;
- -
- - DRM_DEBUG( hw_status: Interrupt Status : %x\n, temp[0]);
- - DRM_DEBUG( hw_status: LpRing Head ptr : %x\n, temp[1]);
- - DRM_DEBUG( hw_status: IRing Head ptr : %x\n, temp[2]);
- - DRM_DEBUG( hw_status: Reserved : %x\n, temp[3]);
- - DRM_DEBUG( hw_status: Last Render: %x\n, temp[4]);
- - DRM_DEBUG( hw_status: Driver Counter : %d\n, temp[5]);
- - for(i = 6; i dma-buf_count + 6; i++) {
- - DRM_DEBUG( buffer status idx : %d used: %d\n, i - 6, temp[i]);
- - }
- -}
- -
static drm_buf_t *i810_freelist_get(drm_device_t *dev)
{
drm_device_dma_t *dma = dev-dma;
- --- linux-2.6.10-rc1-mm1-full/drivers/char/drm/i915_dma.c.old 2004-10-28
22:56:35.0 +0200
+++ linux-2.6.10-rc1-mm1-full/drivers/char/drm/i915_dma.c 2004-10-28
22:56:47.0 +0200
@@ -13,24 +13,6 @@
#include i915_drm.h
#include i915_drv.h
- -static inline void i915_print_status_page(drm_device_t * dev)
- -{
- - drm_i915_private_t *dev_priv = dev-dev_private;
- - u32 *temp = dev_priv-hw_status_page;
- -
- - if (!temp) {
- - DRM_DEBUG(no status page\n);
- - return;
- - }
- -
- - DRM_DEBUG(hw_status: Interrupt Status : %x\n, temp[0]);
- - DRM_DEBUG(hw_status: LpRing Head ptr : %x\n, temp[1]);
- - DRM_DEBUG(hw_status: IRing Head ptr : %x\n, temp[2]);
- - DRM_DEBUG(hw_status: Reserved : %x\n, temp[3]);
- - DRM_DEBUG(hw_status: Driver Counter : %d\n, temp[5]);
- -
- -}
- -
/* Really want an OS-independent resettable timer. Would like to have
* this loop run for (eg) 3 sec, but have the timer reset every time
* the head pointer changes, so that EBUSY only happens if the ring
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFBgW+HmfzqmE8StAARAttqAJ4h16xPCGoaSdpSQISliKrGQ4U6xwCgqOwN
uU4Jwi0yuUSGoB4AbZHHN1U=
=Oppa
-END PGP SIGNATURE-
---
This Newsletter Sponsored by: Macrovision
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate
today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 930] glxgears segfault only when resolution 1024x768
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=930 --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 15:33 --- This is likely bug 1730. -- 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 Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 930] glxgears segfault only when resolution 1024x768
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=930 --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 15:36 --- (I should note that the fix described in 1730 isn't going to make the card work at higher resolutions, it should just make glxgears/glxinfo not segfault when failing to initialize DRI) -- 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 Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1731] New: Savage: Stray scissoring
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=1731 Summary: Savage: Stray scissoring Product: Mesa Version: CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Drivers/DRI/Savage AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] savageDDRenderStart() contains: /* set scissor to the first clip box*/ savageDDScissor(ctx,pbox-x1,pbox-y1,pbox-x2,pbox-y2); If GL_SCISSOR_TEST is off, this has no effect. If GL_SCISSOR_TEST is on, it overrides the applications scissor and also causes incorrect clipping because savageDDScissor takes coordinates that are drawable relative (like glScissor), not screen relative like the clip rects. There seems to be quite a lot of rotted code around clipping in the savage driver; I'm still trying to figure out how things are supposed to work and what the correct fix is. -- 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 Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Two module_param problems with Linux 2.6.4
Am Donnerstag, 28. Oktober 2004 12:42 schrieb Felix Kühling: Two small problems I had with Linux 2.6.4: 1. In order to make drm_stub.c compile without errors I had to #include linux/moduleparam explicitly. You mean: --- linux-core/drm_stub.c 2004-10-28 17:44:45.192753118 +0200 +++ linux-core/drm_stub.c.new 2004-10-28 17:43:35.379578727 +0200 @@ -35,6 +35,7 @@ #include drmP.h #include drm_core.h +#include linux/moduleparam.h unsigned int cards_limit = 16; /* Enough for one machine */ unsigned int drm_debug = 0;/* 1 to enable debug output */ ;-) Works for me (r200, dual Athlon MP). SuSE Kernel 2.6.5-7.108-smp (.111). 2. drm_compat.h defines an empty module_param if it's undefined. It should do the same for module_param_named. Cheers, Dieter --- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: Latest Mesa CVS (DRI) do not compile (since glx indirect?)
Dieter Ntzel wrote: Now, I get this in Mesa CVS: gcc -I../../include -Wall -O -march=athlon -ansi -pedantic -fPIC -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -DUSE_XSHM -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -DPTHREADS -I/usr/X11R6/include arbfplight.c -L../../lib -lglut -lGLU -lGL -lm -o arbfplight arbfplight.c: In function `Init': arbfplight.c:236: Warnung: string length `900' is greater than the length `509'ISO C89 compilers are required to support arbfplight.c:262: Warnung: string length `729' is greater than the length `509'ISO C89 compilers are required to support ../../lib/libGL.so: undefined reference to `_mesa_AttachObjectARB' ../../lib/libGL.so: undefined reference to `_mesa_Uniform1iARB' I can compile the dri linux target, but when I try to compile progs/tests I get something similar: gcc -I. -I../../include -DDRI_NEW_INTERFACE_ONLY -Wall -g -O -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -std=c99 -ffast-math -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -I/usr/X11R6/include -I/usr/X11R6/include/X11/extensions antialias.c -L../../lib -lglut -lGLU -lGL -lm -o antialias ../../lib/libGL.so: undefined reference to `XF86VidModeQueryVersion' ../../lib/libGL.so: undefined reference to `XF86VidModeGetModeLine' collect2: ld returned 1 exit status make: *** [antialias] Fehler 1 Looks like it's related to the now-built dri-aware libGL.so. Simply removing this libGL.so fixed compiling the tests. And in DRI XFree86: In file included from dispatch.c:86: /opt/Mesa/src/mesa/glapi/glapitemp.h:3829: error: conflicting types for `glGetActiveAttribARB' looks like glapi trouble. Due to the very recent changes, I'd try again. I hope these changes aren't supposed to break XFree86/Xorg builds? Roland --- This Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: Latest Mesa CVS (DRI) do not compile (since glx indirect?)
On Thursday 28 October 2004 19:58, Roland Scheidegger wrote: I can compile the dri linux target, but when I try to compile progs/tests I get something similar: gcc -I. -I../../include -DDRI_NEW_INTERFACE_ONLY -Wall -g -O -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -std=c99 -ffast-math -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -I/usr/X11R6/include -I/usr/X11R6/include/X11/extensions antialias.c -L../../lib -lglut -lGLU -lGL -lm -o antialias ../../lib/libGL.so: undefined reference to `XF86VidModeQueryVersion' ../../lib/libGL.so: undefined reference to `XF86VidModeGetModeLine' collect2: ld returned 1 exit status make: *** [antialias] Fehler 1 Looks like it's related to the now-built dri-aware libGL.so. Simply removing this libGL.so fixed compiling the tests. Good catch. Add -lXxf86vm to GL_LIB_DEPS in the appropriate config file, or just update from CVS (just committed the fix). - ajax pgptUO9wobWgT.pgp Description: PGP signature
[Bug 930] glxgears segfault only when resolution 1024x768
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=930 --- Additional Comments From [EMAIL PROTECTED] 2004-10-28 18:58 --- I don't know how I never noticed this bug before. Hmm...anyway, the r128 driver seems to have to odd quirk that it will try to enable direct-rendering even when there is no on-card memory available for textures. I don't think any of the other drivers do this, but I'd have to check. The issues that the DRI driver assumes that there will be on-card memory but that there may or may not be AGP memory available. It should be fairly easy to modify the init code in the DRI driver (r128_context.c, line 159) to not crash if r128scrn-texSize[0] == 0. The only tricky part is that there may be places that assume rmesa-texture_heaps[0] is on-card memory. -- 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 Newsletter Sponsored by: Macrovision For reliable Linux application installations, use the industry's leading setup authoring tool, InstallShield X. Learn more and evaluate today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[2.6 patch] DRM: remove unused functions
[ this time without the problems due to a digital signature... ]
The patch below removes two unused functions from DRM.
diffstat output:
drivers/char/drm/i810_dma.c | 18 --
drivers/char/drm/i915_dma.c | 18 --
2 files changed, 36 deletions(-)
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
--- linux-2.6.10-rc1-mm1-full/drivers/char/drm/i810_dma.c.old 2004-10-28
22:55:34.0 +0200
+++ linux-2.6.10-rc1-mm1-full/drivers/char/drm/i810_dma.c 2004-10-28
22:55:45.0 +0200
@@ -51,24 +51,6 @@
#define up_write up
#endif
-static inline void i810_print_status_page(drm_device_t *dev)
-{
- drm_device_dma_t *dma = dev-dma;
- drm_i810_private_t *dev_priv = dev-dev_private;
- u32 *temp = dev_priv-hw_status_page;
- int i;
-
- DRM_DEBUG( hw_status: Interrupt Status : %x\n, temp[0]);
- DRM_DEBUG( hw_status: LpRing Head ptr : %x\n, temp[1]);
- DRM_DEBUG( hw_status: IRing Head ptr : %x\n, temp[2]);
- DRM_DEBUG( hw_status: Reserved : %x\n, temp[3]);
- DRM_DEBUG( hw_status: Last Render: %x\n, temp[4]);
- DRM_DEBUG( hw_status: Driver Counter : %d\n, temp[5]);
- for(i = 6; i dma-buf_count + 6; i++) {
- DRM_DEBUG( buffer status idx : %d used: %d\n, i - 6, temp[i]);
- }
-}
-
static drm_buf_t *i810_freelist_get(drm_device_t *dev)
{
drm_device_dma_t *dma = dev-dma;
--- linux-2.6.10-rc1-mm1-full/drivers/char/drm/i915_dma.c.old 2004-10-28
22:56:35.0 +0200
+++ linux-2.6.10-rc1-mm1-full/drivers/char/drm/i915_dma.c 2004-10-28
22:56:47.0 +0200
@@ -13,24 +13,6 @@
#include i915_drm.h
#include i915_drv.h
-static inline void i915_print_status_page(drm_device_t * dev)
-{
- drm_i915_private_t *dev_priv = dev-dev_private;
- u32 *temp = dev_priv-hw_status_page;
-
- if (!temp) {
- DRM_DEBUG(no status page\n);
- return;
- }
-
- DRM_DEBUG(hw_status: Interrupt Status : %x\n, temp[0]);
- DRM_DEBUG(hw_status: LpRing Head ptr : %x\n, temp[1]);
- DRM_DEBUG(hw_status: IRing Head ptr : %x\n, temp[2]);
- DRM_DEBUG(hw_status: Reserved : %x\n, temp[3]);
- DRM_DEBUG(hw_status: Driver Counter : %d\n, temp[5]);
-
-}
-
/* Really want an OS-independent resettable timer. Would like to have
* this loop run for (eg) 3 sec, but have the timer reset every time
* the head pointer changes, so that EBUSY only happens if the ring
---
This Newsletter Sponsored by: Macrovision
For reliable Linux application installations, use the industry's leading
setup authoring tool, InstallShield X. Learn more and evaluate
today. http://clk.atdmt.com/MSI/go/ins003001msi/direct/01/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
