[Dri-devel] Re: radeon cast problem (2.6.1-rc2-bk1)

2004-01-07 Thread Stephen Waters
System: MSI K8T Master2-FAR Dual Opteron Radeon VE Debian 'sid' (32-bit Xfree86) Kernel 2.6.1-rc2-bk1 On Tue, 2004-01-06 at 11:51, Xavier Hienne wrote: > On [EMAIL PROTECTED], Stephen Waters wrote: > > I wonder if this bug could explain my X problems... > > --- > > drivers/char/drm/radeon_state.c:

Re: [Dri-devel] Re: [trunk] r200 __driConfigOptions bug since 05.01.2004

2004-01-07 Thread Felix Kühling
Pavel, after reading your patch more carfully I decided to write the number parsing functions myself. No offense, but your version does not parse numbers in scientific notation like 1.5e-8, it is not good enough at detecting errors in the input and in some cases it is even wrong. I tested my funct

[Dri-devel] Re: S3 Savage DRM

2004-01-07 Thread Alex Deucher
just as a follow up, I got the DRM to build under 2.4.24, (redhat uses 2.6 MM in rh9). Unfortunately, I can't get pcmcia to work for me in 2.4.24, so I can either hack on the savage driver or have network access, depending on which kernel I boot. I need to get that sorted out. anyone hear of any

Re: [Dri-devel] is cursor movement allowed on radeon after LOCK_HARDWARE( rmesa) ?

2004-01-07 Thread Michel Dänzer
On Wed, 2004-01-07 at 22:47, Andreas Stenglein wrote: > after setting a breakpoint in radeonFlushCmdBuf and > then single stepping I noticed that while beeing > between LOCK_HARDWARE() and UNLOCK_HARDWARE() > the Xserver "freezes" but cursor movement still occured. > > Is this A) allowed Yes, the

[Dri-devel] is cursor movement allowed on radeon after LOCK_HARDWARE( rmesa) ?

2004-01-07 Thread Andreas Stenglein
after setting a breakpoint in radeonFlushCmdBuf and then single stepping I noticed that while beeing between LOCK_HARDWARE() and UNLOCK_HARDWARE() the Xserver "freezes" but cursor movement still occured. Is this A) allowed or should B) nothing "touch" the hardware at this time? greetings, Andrea

[Dri-devel] Re: S3 Savage DRM

2004-01-07 Thread Felix Kühling
2.4.24 is probably rather too new than too old. I compiled the DRM successfully on 2.4.21. See the workaround that I added for 2.6 kernels. It disables the driver-specific ioctls completely as I didn't want to bother figuring out a real solution at that time, knowing that the DRM driver would be co

[Dri-devel] S3 Savage DRM

2004-01-07 Thread Alex Deucher
Nevermind. seems to be a redhat only problem (they use the 2.6 MM stuff in rh9)... I got it working using a vanilla kernel. Alex - Felix, I'm having trouble getting the savage DRM to build. Perhaps my kernel is too old. As I recall remap_page_range() changed. perhaps that's the proble

[Dri-devel] S3 Savage DRM

2004-01-07 Thread Alex Deucher
Felix, I'm having trouble getting the savage DRM to build. Perhaps my kernel is too old. As I recall remap_page_range() changed. perhaps that's the problem. any idea how I can get it working with my current kernel? I'm having trouble getting 2.4.24 working properly for my set up. Alex gcc -I

[Dri-devel] Re: [Mesa3d-dev] Mesa 6.0 release plans

2004-01-07 Thread Eric Anholt
On Wed, 2004-01-07 at 11:13, Felix Kühling wrote: > On Wed, 07 Jan 2004 08:01:54 -0700 > Brian Paul <[EMAIL PROTECTED]> wrote: > > > > > The Mesa 5.1 release seems to have been fairly solid so I'm planning > > on releasing Mesa 6.0 (stabilized release advertising OpenGL 1.5 > > support) pretty

[Dri-devel] Re: [Mesa3d-dev] Mesa 6.0 release plans

2004-01-07 Thread Felix Kühling
On Wed, 07 Jan 2004 08:01:54 -0700 Brian Paul <[EMAIL PROTECTED]> wrote: > > The Mesa 5.1 release seems to have been fairly solid so I'm planning > on releasing Mesa 6.0 (stabilized release advertising OpenGL 1.5 > support) pretty soon. > > So, if anyone has any bug fixes or changes, get them

Re: [Dri-devel] Re: [trunk] r200 __driConfigOptions bug since 05.01.2004

2004-01-07 Thread Felix Kühling
On Wed, 7 Jan 2004 16:41:38 +0100 (CET) Pavel harry_x Palát <[EMAIL PROTECTED]> wrote: > > Looks like a problem with the new def_max_anisotropy option. It's the > > first floating-point option. I don't understand why this is happening, > > though. It works just fine in the radeon driver and the de

Re: [Dri-devel] Radeon state change lockup: new theory

2004-01-07 Thread Roland Scheidegger
Felix Kühling wrote: A patch is attached. The order in which state atoms are emitted now is pretty arbitrary. It may be worth finding out exactly which permutations of state changes trigger the lockup. In the interest of security we could detect them in the DRM driver and emit a 3D idle to prevent

Re: [Dri-devel] Re: [trunk] r200 __driConfigOptions bug since 05.01.2004

2004-01-07 Thread Pavel harry_x Palát
> Looks like a problem with the new def_max_anisotropy option. It's the > first floating-point option. I don't understand why this is happening, > though. It works just fine in the radeon driver and the definitions of > __driConfigOptions are identical in both drivers (see r200_screen.c). > > Also,

[Dri-devel] Re: [trunk] r200 __driConfigOptions bug since 05.01.2004

2004-01-07 Thread Felix Kühling
On Wed, 7 Jan 2004 07:47:08 +0100 Dieter Nützel <[EMAIL PROTECTED]> wrote: > SuSE 9.0 > > Yast2 wouldn't start the YOU online update subthread anylonger. > > SunWave1 /home/nuetzel# Fatal error in __driConfigOptions line 63, column 0: > illegal default value: 1.0. > /sbin/yast2: line 184: 26298