[Dri-devel] sf.net tracker

2002-09-18 Thread Michel Dänzer


So, do we want to keep the trackers? If yes, I suggest a couple
improvements:

* only allow submissions from logged in users

* send mails to dri-{devel,user} instead of dri-patches to get more
  attention


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast



---
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source  Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] MGA error: mga_get_buffer_ioctl: flush ret=-16

2002-09-18 Thread Serge Gavrilov

Hello everybody!

I have the following problem: quake2 (or even quake) started in 3d
accelerated mode hangs very quickly and completely block video card and
input devices. Xserver begin to eat 100% CPU time. Remote killing of quake2
and Xserver does not help unblock video and input devices. This happens
for any reasonable resolution (640x480 ... 1152x864) (both for xserver or
quake2-fullscreen) for any bpp (16 or 24) and any AGP mode (1 2 4).

Hardware is 

Matrox G400 AGP (rev 04) 16M
Abit KT7A motherboard with VIA KT133 chipset
Athlon 1000

OS - Debian GNU/Linux (woody)
Kernel is 2.4.19
XFree 4.1 

Before the crash quake2 outs to stderr the following error

mga_get_buffer_ioctl: flush ret=-16

I tried this with xserver and xlibmesa from XFree 4.2.1  - the result is
the same. 

Below I put output from glxinfo and XFree86.0.log.

Could you recommend me something? Is it known problem?

Thanks a lot!

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
client glx vendor string: SGI
client glx version string: 1.2
client glx extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
GLX extensions:
GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
OpenGL vendor string: VA Linux Systems Inc.
OpenGL renderer string: Mesa DRI G400 20010321 AGP 1x x86/MMX/3DNow!
OpenGL version string: 1.2 Mesa 3.4.2
OpenGL extensions:
GL_ARB_multitexture, GL_ARB_transpose_matrix, GL_EXT_abgr, 
GL_EXT_blend_func_separate, GL_EXT_clip_volume_hint, 
GL_EXT_compiled_vertex_array, GL_EXT_histogram, GL_EXT_packed_pixels, 
GL_EXT_polygon_offset, GL_EXT_rescale_normal, GL_EXT_stencil_wrap, 
GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_object, 
GL_EXT_vertex_array, GL_MESA_window_pos, GL_MESA_resize_buffers, 
GL_NV_texgen_reflection, GL_PGI_misc_hints, GL_SGIS_pixel_texture, 
GL_SGIS_texture_edge_clamp
glu version: 1.3
glu extensions:
GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
--
0x23 24 tc  0 24  0 r  y  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0x24 24 tc  0 24  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0x25 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x26 24 tc  0 24  0 r  .  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x27 24 tc  0 24  0 r  y  .  8  8  8  8  0  0  0 16 16 16  0  0 0 Slow
0x28 24 tc  0 24  0 r  .  .  8  8  8  8  0  0  0 16 16 16  0  0 0 Slow
0x29 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16  0  0 0 Slow
0x2a 24 tc  0 24  0 r  .  .  8  8  8  8  0 24  8 16 16 16  0  0 0 Slow
0x2b 24 dc  0 24  0 r  y  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0x2c 24 dc  0 24  0 r  .  .  8  8  8  8  0  0  0  0  0  0  0  0 0 None
0x2d 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x2e 24 dc  0 24  0 r  .  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x2f 24 dc  0 24  0 r  y  .  8  8  8  8  0  0  0 16 16 16  0  0 0 Slow
0x30 24 dc  0 24  0 r  .  .  8  8  8  8  0  0  0 16 16 16  0  0 0 Slow
0x31 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16  0  0 0 Slow
0x32 24 dc  0 24  0 r  .  .  8  8  8  8  0 24  8 16 16 16  0  0 0 Slow


This is a pre-release version of XFree86, and is not supported in any
way.  Bugs may be reported to [EMAIL PROTECTED] and patches submitted
to [EMAIL PROTECTED]  Before reporting bugs in pre-release versions,
please check the latest version in the XFree86 CVS repository
(http://www.XFree86.Org/cvs)

XFree86 Version 4.1.0.1 / X Window System
(protocol Version 11, revision 0, vendor release 6510)
Release Date: 21 December 2001
If the server is older than 6-12 months, or if your card is
newer than the above date, look for a newer version before
reporting problems.  (See http://www.XFree86.Org/FAQ)
Build Operating System: Linux 2.4.17 i686 [ELF] 
Module Loader present
(==) Log file: /var/log/XFree86.0.log, Time: Wed Sep 18 14:10:02 2002
(++) Using config file: /etc/X11/XF86Config-4
Markers: (--) probed, (**) from config file, (==) default setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) ServerLayout Default Layout
(**) |--Screen Default Screen (0)
(**) |   |--Monitor Flatron795FT
(**) |   |--Device Matrox G400
(**) |   |--VideoAdaptor MGA_XV
(**) |--Input Device Generic Keyboard
(**) Option XkbKeymap mine(ru_mine)
(**) XKB: keymap: mine(ru_mine) (overrides other XKB settings)
(==) Keyboard: CustomKeycode disabled
(**) |--Input Device Configured Mouse
(**) |--Input Device Generic Mouse
(**) FontPath set to 

Re: [Dri-devel] MGA error: mga_get_buffer_ioctl: flush ret=-16

2002-09-18 Thread Alan Cox

On Wed, 2002-09-18 at 14:14, Serge Gavrilov wrote:
 OS - Debian GNU/Linux (woody)
 Kernel is 2.4.19
 XFree 4.1 

My 3D was never stable with 4.1. With 4.2 it was pretty good. With 4.2
and Jonny Strom's patch its not died yet.



---
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source  Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] Typo on http://dri.sourceforge.net/other/radeon_dri_features.html

2002-09-18 Thread Mike A. Harris

There's a typo on the Radeon features webpage:

http://dri.sourceforge.net/other/radeon_dri_features.html

At the bottom it has IcDT  Gatos

Should be iDCT

(Discreet Cosine Transform)



-- 
Mike A. Harris  ftp://people.redhat.com/mharris
OS Systems Engineer
XFree86 maintainer
Red Hat Inc.



---
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source  Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] how are the S3TC discussions going with VIA?

2002-09-18 Thread Brian Paul

Ian Molton wrote:
 See subject ;-)
 
 Where can us mortals get info on this?

Daniel Vogel sent a message to his contact at S3 and I sent a follow-up.
The S3 person replied that he's checking internally before saying
anything.  That was yesterday.

-Brian




---
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source  Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] [Fwd: [Dri-patches] [ dri-Bugs-602843 ] MGA dual-head cloned console]

2002-09-18 Thread Jens Owen

Keith,

Since nobody is tracking bugs submitted via the DRI bug data base, I'll 
try to respond to some of these requests that come in and ask them to 
submit their support requests to the DRI-users list.

Please add this canned response to the list of responses (I don't have 
admin privledges) at:

https://sourceforge.net/tracker/admin/?group_id=387atid=100387add_canned=1

begin canned response

Thanks you for sending your support requests to the DRI bug database. 
This database is *not* being monitored for support requests.  We 
recommend you e-mail your request to [EMAIL PROTECTED]

Thanks,
The DRI Development Team

end canned response

-- 
/\
  Jens Owen/  \/\ _
   [EMAIL PROTECTED]  /\ \ \   Steamboat Springs, Colorado

---BeginMessage---

Bugs item #602843, was opened at 2002-08-31 07:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=100387aid=602843group_id=387

Category: MGA X Server
Group: Other
Status: Open
Resolution: None
Priority: 5
Submitted By: Bryan Hundven (bhundven)
Assigned to: Nobody/Anonymous (nobody)
Summary: MGA dual-head cloned console

Initial Comment:
When I start my computer in text mode, only the primary
head has a console (expected).

I startx then close it and I now have the same console
on both monitors and it won't go away until I reboot.

BTW... I am not using fb!

I am using:
mga-20020831-linux.i386
Linux 2.4.19
XFree86 4.2.0-8 (redhat 7.3)

Running on:
Matrox G550 (32M ddr-sdram ver.)

Bryan Hundven
[EMAIL PROTECTED]

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=100387aid=602843group_id=387


---
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source  Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab
___
Dri-patches mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-patches



---End Message---


Re: [Dri-devel] sf.net tracker

2002-09-18 Thread Jens Owen

Michel Dänzer wrote:
 So, do we want to keep the trackers?

It has been used in the past, but currently, most of the primary 
developers have *not* found it useful.  I don't think anybody would be 
disappointed if it were turned off...at least for now.

 If yes, I suggest a couple
 improvements:
 
 * only allow submissions from logged in users

If we keep it on, that's a good idea.

 * send mails to dri-{devel,user} instead of dri-patches to get more
   attention

I was going to send a canned response to have the poster submit to 
dri-users.  I didn't realize we could change the list these get posted 
on.  I'm not sure we want these automatically posted.  There appears to 
be less follow up on the submitters end via this route.  That's why I 
think a push back to the submitter is just fine.

-- 
/\
  Jens Owen/  \/\ _
   [EMAIL PROTECTED]  /\ \ \   Steamboat Springs, Colorado



---
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source  Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



[Dri-devel] GLX/DRI always tries to connect :0.0

2002-09-18 Thread Stefan Dirsch

Hi

Looks like the XFree86 GLX/DRI OpenGL client lib always tries to
connect to :0.0, even if DISPLAY=machine:10.0. Any fix known for
this issue? I'm using XFree86 4.2.0 on Linux.

xxx@machine1 ssh -X machine2
xxx@machine2 echo $DISPLAY
localhost:10.0
xxx@machine2 gears
Xlib: connection to :0.0 refused by server
Xlib: No protocol specified

The OpenGL program starts regularly on the DISPLAY, which was
specified. It's more a confusing warning.

Best regards,
Stefan

Public Key available

Stefan Dirsch (Res.  Dev.)   SuSE Linux AG
Tel: 0911-740530  Deutschherrnstr. 15-19
FAX: +49 911 741 77 55D-90429 Nuernberg
http://www.suse.deGermany 



---
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source  Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] MGA error: mga_get_buffer_ioctl: flush ret=-16

2002-09-18 Thread Serge Gavrilov

On Wed, Sep 18, 2002 at 05:49:29PM +0300, Jonny.Strom wrote:
 Hi
 
 Yes it is known problem try out my patch that is attached to this mail, 
 and let the dri-devel list
 know the result.
 
 The file to patch is: /usr/src/linux/drivers/char/drm/mga_dma.c
 
 Cheers Johnny

Thanks a lot! This fixes the problem.


-- 
Serge


---
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source  Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] Typo on http://dri.sourceforge.net/other/radeon_dri_features.html

2002-09-18 Thread Brian Paul

Mike A. Harris wrote:
 There's a typo on the Radeon features webpage:
 
 http://dri.sourceforge.net/other/radeon_dri_features.html
 
 At the bottom it has IcDT  Gatos
 
 Should be iDCT
 
 (Discreet Cosine Transform)

Fixed.

-Brian



---
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source  Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] sf.net tracker

2002-09-18 Thread Michel Dänzer

On Mit, 2002-09-18 at 18:00, Jens Owen wrote: 
 Michel Dänzer wrote:
  So, do we want to keep the trackers?
 
 It has been used in the past, but currently, most of the primary 
 developers have *not* found it useful.  I don't think anybody would be 
 disappointed if it were turned off...at least for now.
 
  If yes, I suggest a couple
  improvements:
  
  * only allow submissions from logged in users
 
 If we keep it on, that's a good idea.
 
  * send mails to dri-{devel,user} instead of dri-patches to get more
attention
 
 I was going to send a canned response to have the poster submit to 
 dri-users.  I didn't realize we could change the list these get posted 
 on.  I'm not sure we want these automatically posted.  There appears to 
 be less follow up on the submitters end via this route.  That's why I 
 think a push back to the submitter is just fine.

If we require login, we'd have at least a mail address to follow up to.
I think disabling the trackers would be better than a canned response
because users might get annoyed by the latter after having entered a
tracker entry.


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast



---
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source  Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] sf.net tracker

2002-09-18 Thread Jens Owen

Michel Dänzer wrote:

 I think disabling the trackers would be better than a canned response
 because users might get annoyed by the latter after having entered a
 tracker entry.

I agree.

I have somewhat disabled the bug tracker, support request tracker, patch 
tracker and feature request tracker.

I didn't find a means to completely turn these trackers off, but I was 
able to disable them from being public and put messages like this on the 
submital pages:

   The DRI feature request page is not currently being maintained.
   Please send all feature requests directly to
   [EMAIL PROTECTED]

   Thanks,
   The DRI Development Team

Hopefully, that will do the trick.

-- 
/\
  Jens Owen/  \/\ _
   [EMAIL PROTECTED]  /\ \ \   Steamboat Springs, Colorado



---
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source  Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel



Re: [Dri-devel] sf.net tracker

2002-09-18 Thread Michel Dänzer

On Mit, 2002-09-18 at 23:48, Jens Owen wrote:
 Michel Dänzer wrote:
 
  I think disabling the trackers would be better than a canned response
  because users might get annoyed by the latter after having entered a
  tracker entry.
 
 I agree.
 
 I have somewhat disabled the bug tracker, support request tracker, patch 
 tracker and feature request tracker.
 
 I didn't find a means to completely turn these trackers off, but I was 
 able to disable them from being public and put messages like this on the 
 submital pages:
 
The DRI feature request page is not currently being maintained.
Please send all feature requests directly to
[EMAIL PROTECTED]
 
Thanks,
The DRI Development Team
 
 Hopefully, that will do the trick.

Sounds good to me, thanks!


-- 
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast



---
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source  Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel