gatos-devel Mailing List for GATOS

On Thu, 31 Jan 2002, Marc Aurele La France wrote:

> On Thu, 31 Jan 2002, Vladimir Dergachev wrote:
>
> > > > > > GATOS Radeon driver has the proper handling of memory controller.
> > > > > > Consequently, usual drm modules will not work - you need to use drm-kernel
> > > > > > package  available at http://gatos.sf.net/
>
> > > > > Is there any reason the drivers can't be merged?
>
> > > > No reason at all, in fact that's what I intend to push for. Hopefully
> > > > this would be done right now so there is plenty of time till next
> > > > release to move around components. The main GATOS  CVS branch is quite
> > > > stable. As for memory controller I'll either e-mail a  separate patch to
> > > > Jens Owens, or it will go into the main XFree tree  together with the rest
> > > > of GATOS patch.
>
> > > My gameplan for this XFree86 release cycle includes finishing the GATOS
> > > merge.  As is a rework of it.  But not in that order.  Thus I see your CVS
> > > repository serving its current function for a little longer than you might
> > > prefer.
>
> > This sounds like the same thing I was thinking - include current stable
> > patch right after 4.2.0 is released, is it not ?
>
> "But not in that order" means just what it says.  The rework is to happen
> before committing this functionality to XFree86's CVS.  Both Kevin & I
> agree on this.  We see no reason to essentially duplicate what your CVS
> already provides.  Thus, a strict merge of what you call the "stable"
> branch isn't in the cards, simply because doing so isn't a step forward as
> far as the community is concerned (other than convenience issues).

I did not mean: merge it and leave it there. What I was merely suggesting
is merge in 4.2.99.x CVS tree and then move around as you please. So, for
example it would possible to see your comments on what changed how, etc.

Does this make sense ?

                          Vladimir Dergachev

>
> > GATOS CVS is not going away, even after this inclusion, there are still a
> > ton of things to do:
> >    * TV-out
> >    * AFC and support for channel scan
> >    * Support other deinterlacing modes and not only Bob.
>
> That's up to you.
>
> Marc.
>
> +----------------------------------+-----------------------------------+
> |  Marc Aurele La France           |  work:   1-780-492-9310           |
> |  Computing and Network Services  |  fax:    1-780-492-1729           |
> |  352 General Services Building   |  email:  ts...@ua...          |
> |  University of Alberta           +-----------------------------------+
> |  Edmonton, Alberta               |                                   |
> |  T6G 2H1                         |     Standard disclaimers apply    |
> |  CANADA                          |                                   |
> +----------------------------------+-----------------------------------+
> XFree86 Core Team member.  ATI driver and X server internals.
>

Ross, could you run your tests again on Avview-0.9.4 ? (or current CVS, if
the tarball is not up yet).

                      Vladimir Dergachev

Hi !

I have a problem with an AIW 128 16Mo.
Tv out is working only on console mode, not under X.
Any clue ?

Thanks.

Antoine

On Thu, 31 Jan 2002, Vladimir Dergachev wrote:

> > > > > GATOS Radeon driver has the proper handling of memory controller.
> > > > > Consequently, usual drm modules will not work - you need to use drm-kernel
> > > > > package  available at http://gatos.sf.net/

> > > > Is there any reason the drivers can't be merged?

> > > No reason at all, in fact that's what I intend to push for. Hopefully
> > > this would be done right now so there is plenty of time till next
> > > release to move around components. The main GATOS  CVS branch is quite
> > > stable. As for memory controller I'll either e-mail a  separate patch to
> > > Jens Owens, or it will go into the main XFree tree  together with the rest
> > > of GATOS patch.

> > My gameplan for this XFree86 release cycle includes finishing the GATOS
> > merge.  As is a rework of it.  But not in that order.  Thus I see your CVS
> > repository serving its current function for a little longer than you might
> > prefer.

> This sounds like the same thing I was thinking - include current stable
> patch right after 4.2.0 is released, is it not ?

"But not in that order" means just what it says.  The rework is to happen
before committing this functionality to XFree86's CVS.  Both Kevin & I
agree on this.  We see no reason to essentially duplicate what your CVS
already provides.  Thus, a strict merge of what you call the "stable"
branch isn't in the cards, simply because doing so isn't a step forward as
far as the community is concerned (other than convenience issues).

> GATOS CVS is not going away, even after this inclusion, there are still a
> ton of things to do:
>    * TV-out
>    * AFC and support for channel scan
>    * Support other deinterlacing modes and not only Bob.

That's up to you.

Marc.

+----------------------------------+-----------------------------------+
|  Marc Aurele La France           |  work:   1-780-492-9310           |
|  Computing and Network Services  |  fax:    1-780-492-1729           |
|  352 General Services Building   |  email:  ts...@ua...          |
|  University of Alberta           +-----------------------------------+
|  Edmonton, Alberta               |                                   |
|  T6G 2H1                         |     Standard disclaimers apply    |
|  CANADA                          |                                   |
+----------------------------------+-----------------------------------+
XFree86 Core Team member.  ATI driver and X server internals.

I've been watching this thread for awhile now, and I think it's time for me
to inject my $0.02 worth.  First, let me make sure that I've got things
straight here.

Changes have been made to the 2D X driver to support video capture on Radeon
cards.  To support this change, the way that video memory (or is it register
space?) is mapped must be changed.  A portion of this initialization is done
in the 2D X driver and the rest is done in the DRM portion (in the kernel).
Both parts must agree on how memory is to be mapped, or the system will
crash.  Am I correct so far?

Forgive my lack of understanding, but I thought that the DRM mapped
everything in the places where non-kernel drivers told it to map.  Isn't
that the point of all the drmAddMap calls?  Or do the drmAddMap calls just
provide the physical-to-virtual mapping, and the mapping that is causing the
problem here is some sort of physical-to-physical (using AGP hardware,
perhaps) mapping?

The crux of the problem is that the DRM portion is distributed with the
kernel sources and the 2D X driver portion is distributed with the XFree86
sources.  The odds that users will have matched versions are much, much
worse then Vegas odds.  Therefore, each part (DRM and 2D X driver) have to
magically detect what the other part is capable of doing, and magically do
the right thing.

Here are the possible version combinations:

1. New DRM + new 2D X driver
2. Old DRM + new 2D X driver
3. New DRM + old 2D X driver
4. Old DRM + old 2D X driver

Case 4 is trivial, and I won't consider it any further.

In the remaining cases, each the DRM and the 2D X driver need some way to
determine the capabilities of the other part so that they can know how to do
the mapping.  I believe that there is already some mechanism for determining
the DRM version (drmGetVersion?).  This makes cases 1 and 2 trivial.  The
new 2D X driver will determine the DRM version, and either setup the new
mapping and support video capture, or log a message (or something similar)
so that the user knows that video capture is unavailable.  Here we have the
potential for reduced functionality, but at least the system won't crash.

The tricky case, and the case that Vladimir is stuck on, is number 3.  How
does the DRM know what the 2D X driver is going to do?  Jens and Keith have
suggested using a new set of IOCTLs.  By this I assume that he meant having
a new IOCTL number for an old IOCTL, and the new IOCTL would do the same
thing. Simply by using the new entry point the DRM would know that the
caller (i.e., the 2D X driver) is "new." Jens & Keith, is this what you
meant?  If so, which IOCTL(s) would need "new" versions?
DRM_IOCTL_RADEON_CP_INIT?

Vladimir has suggested an alternative.  Adding a new IOCTL so that the 2D X
driver would explicitly tell the DRM which version it is.  I'm not sure that
I like this so much as presents to possibility for a whole new can of worms
in the future.  Would it maybe better to add a new IOCTL to specifically say
"Hey, use the new style memory layout"?

So, when the 2D driver detects that the DRM is "new," it would use some form
of new IOCTL.  The DRM would then know that the 2D driver is also "new," and
the DRM would perform the mapping accordingly. Otherwise, the 2D driver
detects the old DRM version and disables video capture support, or the DRM
gets the old IOCTL and performs the mapping the old way.

Now, if all (or at least all the important parts) of the above is correct,
is there any reason why we should not move forward with this solution?  At
first blush, there don't seem to be any horrible pitfalls, and I don't
really see any other way that will keep us out of trouble with Linus and
with our users.

There is (at least) one remaining issue.  In the case where a user has the
new 2D part and wants to use video capture but doesn't have a new enough
DRM, how do we effectively inform them?  I don't think that just logging a
message to the X log / syslog is good enough.  Is there any other way?
Could we do something perverted like "capture" a screen of text that says
"You must upgrade your DRM to use video capture"? :)

-- 
Tell that to the Marines!

On Thu, 31 Jan 2002, Rudolf Opalla wrote:

> Hi all,
>
> there seems to be a DRI-Bug in experimental 7 Drivers if
> GL_POLYGON_SMOOTH is enabled.
> I added a little program  (you need SDL to compile it) which hangs my
> X-Server with DRI turned on. I dont know if it's driver-specific,
> card-specific (I have a RADEON VIVO)  or in all current DRI-drivers.

Does this work with regular X drivers ? Thanks for the test program !

>
> Capturing with GATOS experimental 7 brings two problems with
> ffmpeg (from fridays CVS).
> 1. If the load gets too high ffmpeg starts to record repeately the same
>      segment of audiotrack
>       - I think it's the part which is in the buffer when some kind of
> overflow happens.
>      For my configuration the following command has always the effect:
>          ffmpeg -f video_grab_device -s 720x240 -r 50 -i /dev/video -f
> audio_device -i /dev/dsp -acodec ac3 -ar 44100 -ab 64 -vcodec mpeg4 -s
> 360x288 -r 25 -deinterlace -qscale 2 -g 400 -y test.avi
>      This is definitly a ffmpeg-problem, because I take the audio-input
> from my soundcard.
>
> 2.  ffmpeg hangs after a while, even if the load is low -
>       I can stop it with control-c, and start it again - so it
>       doesn't seem to damage the X-Server or the System.
>       I'm not sure if this is a GATOS-bug or a ffmpeg-bug.
>

Have you tried using Avview to capture ?

                          Vladimir Dergachev

>
> Ciao
>     rudi
>

On Wed, 30 Jan 2002, Jens Owen wrote:

> Vladimir Dergachev wrote:
>
> > As for Linus not wanting to accept it, 2.4 has dropped most nat filters
> > except for ftp and most of them aren't back yet. So I don't buy this
> > argument.
>
> Vladimir,
>
> This is no joke.  We absolutely need compatability.  Large amounts of
> developer pain don't even begin to compare to the enormous number of
> headaches incompatability causes our users.
>
> Regards,
> Jens

Having slept over this... Is it possible to include a new ioctl
specifically to exchange versioning info ? Something along the lines of

  struct {
      int uc_type;    /* user component type */
      int uc_major, un_minor, uc_subminor;   /* uc component info */
      int drm_major, drm_minor, drm_subminor; /* place to return drm  version info */
      } drm_version_t;

And have application (X at the moment) call it before doing anything with
drm ?

                  thanks !

                     Vladimir Dergachev

>
> --                             /\
>          Jens Owen            /  \/\ _
>   je...@tu...  /    \ \ \   Steamboat Springs, Colorado
>
> _______________________________________________
> Gatos-devel mailing list
> Gat...@li...
> https://lists.sourceforge.net/lists/listinfo/gatos-devel
>

[ton of recipients removed]


On Thu, 31 Jan 2002, Marc Aurele La France wrote:

> On Wed, 30 Jan 2002, Vladimir Dergachev wrote:
>
> > > > GATOS Radeon driver has the proper handling of memory controller.
> > > > Consequently, usual drm modules will not work - you need to use drm-kernel
> > > > package  available at http://gatos.sf.net/
>
> > > Is there any reason the drivers can't be merged?
>
> > No reason at all, in fact that's what I intend to push for. Hopefully
> > this would be done right now so there is plenty of time till next
> > release to move around components. The main GATOS  CVS branch is quite
> > stable. As for memory controller I'll either e-mail a  separate patch to
> > Jens Owens, or it will go into the main XFree tree  together with the rest
> > of GATOS patch.
>
> My gameplan for this XFree86 release cycle includes finishing the GATOS
> merge.  As is a rework of it.  But not in that order.  Thus I see your CVS
> repository serving its current function for a little longer than you might
> prefer.

This sounds like the same thing I was thinking - include current stable
patch right after 4.2.0 is released, is it not ?

GATOS CVS is not going away, even after this inclusion, there are still a
ton of things to do:
   * TV-out
   * AFC and support for channel scan
   * Support other deinterlacing modes and not only Bob.

                          Vladimir Dergachev

>
> Marc.
>
> +----------------------------------+-----------------------------------+
> |  Marc Aurele La France           |  work:   1-780-492-9310           |
> |  Computing and Network Services  |  fax:    1-780-492-1729           |
> |  352 General Services Building   |  email:  ts...@ua...          |
> |  University of Alberta           +-----------------------------------+
> |  Edmonton, Alberta               |                                   |
> |  T6G 2H1                         |     Standard disclaimers apply    |
> |  CANADA                          |                                   |
> +----------------------------------+-----------------------------------+
> XFree86 Core Team member.  ATI driver and X server internals.
>
> _______________________________________________
> Xpert mailing list
> Xp...@XF...
> http://XFree86.Org/mailman/listinfo/xpert
>

On 31 Jan 2002, Michel [ISO-8859-1] D=E4nzer wrote:

> On Mit, 2002-01-30 at 15:56, Vladimir Dergachev wrote:
> >
> > On Wed, 30 Jan 2002, Vladimir Dergachev wrote:
> >
> > > http://gatos.sf.net/ - they were there last time I submitted a patch.=
=2E but
> > > it did not get in. Just to make sure I am not pulling your leg.. Yep,=
 they
> > > are there: search for  R128WaitForIdle(pScrn) function.
> >
> > I've implemented this (easier than software CCE) scheme. If you want to
> > please try the latest ati.2 CVS code at http://gatos.sf.net - or just t=
ake
> > a look at it.
>
> I will.
>
> > Basically I put in info->accel->Sync(pScrn) at entrance points into Xv
> > driver. SetupImageVideo, StopVideo, SetPortAttribute, GetPortAttribute =
and
> > PutVideo are all "control" calls, perfomance is not critical. PutImage
> > should, arguably, take more time during image trasfer.. And if you are
> > playing Quake and watching DVD at the same you are making problems for
> > yourself anyway ;) (And the faster the card the less noticable any
> > slowdown from extra Sync calls will be)
>
> How does this interact with the CCE being used for the image transfer in
> PutImage (if at all)?

Not much. We are waiting for the card to finish doing whatever it was
doing and only then we start the transfer. The only difference is that we
wait for quiescence the right way.

                          Vladimir Dergachev


>
>
> --
> Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) develope=
r
> XFree86 and DRI project member   /  CS student, Free Software enthusiast
>

> or not present). If I then use <Ctrl>+<Alt>+<+> to switch to 800x600 it 
> displays fine - but if I try to start xfree in 800x600 the signal doesn't 
> appear to be synced properly, with the image cut in pieces and placed in 
> multiple spots on the screen - and flickering.

It looks like a black cross on the screen with the 0,0 spot being
in the bottom right under the cross? I had that happen intermittently,
so I added a total hack to call the VBE routine and set the mode again
after other things are initialized. I've attached my r128_video.c file
with the hack if you want to try it.

(second try sending this, I didn't compress the file the first time and
it was rejected for being too big)

-- 
Chris Bare                                Metro Link Incorporated
ch...@me...                       http://www.metrolink.com/

Hi all,

there seems to be a DRI-Bug in experimental 7 Drivers if
GL_POLYGON_SMOOTH is enabled.
I added a little program  (you need SDL to compile it) which hangs my
X-Server with DRI turned on. I dont know if it's driver-specific,
card-specific (I have a RADEON VIVO)  or in all current DRI-drivers.

Capturing with GATOS experimental 7 brings two problems with
ffmpeg (from fridays CVS).
1. If the load gets too high ffmpeg starts to record repeately the same
     segment of audiotrack
      - I think it's the part which is in the buffer when some kind of
overflow happens.
     For my configuration the following command has always the effect:
         ffmpeg -f video_grab_device -s 720x240 -r 50 -i /dev/video -f
audio_device -i /dev/dsp -acodec ac3 -ar 44100 -ab 64 -vcodec mpeg4 -s
360x288 -r 25 -deinterlace -qscale 2 -g 400 -y test.avi
     This is definitly a ffmpeg-problem, because I take the audio-input
from my soundcard.

2.  ffmpeg hangs after a while, even if the load is low -
      I can stop it with control-c, and start it again - so it
      doesn't seem to damage the X-Server or the System.
      I'm not sure if this is a GATOS-bug or a ffmpeg-bug.


Ciao
    rudi

On Wed, 30 Jan 2002, Vladimir Dergachev wrote:

> > > GATOS Radeon driver has the proper handling of memory controller.
> > > Consequently, usual drm modules will not work - you need to use drm-kernel
> > > package  available at http://gatos.sf.net/

> > Is there any reason the drivers can't be merged?

> No reason at all, in fact that's what I intend to push for. Hopefully
> this would be done right now so there is plenty of time till next
> release to move around components. The main GATOS  CVS branch is quite
> stable. As for memory controller I'll either e-mail a  separate patch to
> Jens Owens, or it will go into the main XFree tree  together with the rest
> of GATOS patch.

My gameplan for this XFree86 release cycle includes finishing the GATOS
merge.  As is a rework of it.  But not in that order.  Thus I see your CVS
repository serving its current function for a little longer than you might
prefer.

Marc.

+----------------------------------+-----------------------------------+
|  Marc Aurele La France           |  work:   1-780-492-9310           |
|  Computing and Network Services  |  fax:    1-780-492-1729           |
|  352 General Services Building   |  email:  ts...@ua...          |
|  University of Alberta           +-----------------------------------+
|  Edmonton, Alberta               |                                   |
|  T6G 2H1                         |     Standard disclaimers apply    |
|  CANADA                          |                                   |
+----------------------------------+-----------------------------------+
XFree86 Core Team member.  ATI driver and X server internals.

>> The assumption was only made for experimental GATOS drivers. It is a
>> practical one. More people come and ask: "I upgraded to GATOS driver and
>> DRI won't work anymore !" Answer: RTFM, upgrade drm driver.
>
>It's already been determined that:
>
>"I just upgraded my kernel, and DRI won't work anymore!"
>"RTFM, upgrade your X server"
>
>"I just upgraded my X server, and DRI doesn't work anymore!"
>"RTFM, upgrade your kernel"
>
>just doesn't cut it.  You aren't allowed to do anything that
>requires a response of "RTFM, upgrade ..."

Hrm... My understanding is that the problem is related to the
setting of MC_AGP_LOCATION (and eventually MC_FB_LOCATION) by
the DRM kernel driver, right ?

Well... The easy fix is to move that change to the XFree driver
before DRM is inited and have the kernel one just read back the
value to know which XFree driver version initialized it.

I will have to play with those values on Macs as well because of
some problems with UniNorth (I basically have to put the ring read
ptr in normal RAM, not AGP RAM, and I need the radeon to do a
normal PCI busmaster cycle to write it, not an AGP cycle).

Ben.

On Mit, 2002-01-30 at 15:56, Vladimir Dergachev wrote:
>=20
> On Wed, 30 Jan 2002, Vladimir Dergachev wrote:
>=20
> > http://gatos.sf.net/ - they were there last time I submitted a patch.. =
but
> > it did not get in. Just to make sure I am not pulling your leg.. Yep, t=
hey
> > are there: search for  R128WaitForIdle(pScrn) function.
>=20
> I've implemented this (easier than software CCE) scheme. If you want to
> please try the latest ati.2 CVS code at http://gatos.sf.net - or just tak=
e
> a look at it.

I will.

> Basically I put in info->accel->Sync(pScrn) at entrance points into Xv
> driver. SetupImageVideo, StopVideo, SetPortAttribute, GetPortAttribute an=
d
> PutVideo are all "control" calls, perfomance is not critical. PutImage
> should, arguably, take more time during image trasfer.. And if you are
> playing Quake and watching DVD at the same you are making problems for
> yourself anyway ;) (And the faster the card the less noticable any
> slowdown from extra Sync calls will be)

How does this interact with the CCE being used for the image transfer in
PutImage (if at all)?


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

Vladimir Dergachev wrote:
> 
> On Wed, 30 Jan 2002, Gareth Hughes wrote:
> 
> > > Gareth, the current driver is broken. If someone wants to use video
> > > capture they _need_ both GATOS 2d driver and GATOS drm driver, period.
> > >
> > > What's so wrong about upgrading ?
> >
> > Guaranteed, someone will get a mismatch -- your changes may go back
> > into the stock kernel, breaking DRI CVS or whatever, who knows.  Forcing
> > everyone to upgrade their kernel, 2D and 3D drivers to the right magic
> > revision is a recipe for disaster, one that the kernel people have
> > already kicked our arses over (rightly so).
> >
> > > Also, I can make drm driver work nice with older 2d drivers - as soon as
> > > someone will show me a way to tell the version of the 2d driver that is
> > > accessing the drm driver.
> >
> > Sounds like it'll need a 2D driver upgrade :-)
> >
> 
> So what are you proposing ? Not to fix it ? We have a system where a
> driver is split in three components all of which have to agree on the
> hardware state. There is just so much you can do for backward
> compatibility. You can do less if you can't find one component version
> from another one.

Do it the old way by default, and if you receive some new ioctl, do it the new
way.

> As for Linus not wanting to accept it, 2.4 has dropped most nat filters
> except for ftp and most of them aren't back yet. So I don't buy this
> argument.

Trust us.  It's the right thing to do, whether Linus or anybody else says so.

Keith

Vladimir Dergachev wrote:
> 
> On Wed, 30 Jan 2002, Gareth Hughes wrote:
> 
> > > The assumption was only made for experimental GATOS drivers. It is a
> > > practical one. More people come and ask: "I upgraded to GATOS driver and
> > > DRI won't work anymore !" Answer: RTFM, upgrade drm driver.
> >
> > It's already been determined that:
> >
> > "I just upgraded my kernel, and DRI won't work anymore!"
> > "RTFM, upgrade your X server"
> >
> > "I just upgraded my X server, and DRI doesn't work anymore!"
> > "RTFM, upgrade your kernel"
> >
> > just doesn't cut it.  You aren't allowed to do anything that
> > requires a response of "RTFM, upgrade ..."
> >
> > Start thinking of alternatives...
> 
> Gareth, the current driver is broken. If someone wants to use video
> capture they _need_ both GATOS 2d driver and GATOS drm driver, period.
> 
> What's so wrong about upgrading ?
> 
> Also, I can make drm driver work nice with older 2d drivers - as soon as
> someone will show me a way to tell the version of the 2d driver that is
> accessing the drm driver.

Perhaps you should assume it is the older version until you know otherwise.

Keith

On Thu, 31 Jan 2002 15:58, Vladimir Dergachev wrote:
> Does 800x600 work in 16bpp ?

No, I get the same problem.

-- 
Chris Jensen
ch...@dr...

Public Key: http://drspirograph.com/public_key/

Wait: Did you know that there's a direct correlation between the decline of
Spirograph and the rise in gang activity?  Think about it.
- Dr Spirograph (The Simpsons)

GNOME 1.4.x still, but running TuxRacer totally blew up X/system. I
compared this to win2k and it just blew it out of the water HARD :(

On Wed, 30 Jan 2002, Vladimir Dergachev wrote:

>
>
> On Wed, 30 Jan 2002, Shawn Starr wrote:
>
> >
> > I dont know if this is coming, or if there's any interest. But X just
> > *dies* using the CPU to redraw 2D and 3D just isn't even worth using on
> > this P200.
> >
> > I have a Mach64 chipset:
> >
> > ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT] (rev 41) 2MB
> >
> > There is no DRI support for this card (at the moment). Is there anyone out
> > there working on such a driver? I'm sure a lot of us users would be very
> > happy ;)
> >
>
> I do not have GT, but I do have GTB (Rage II+DVD) and X seem to work ok
> with it. Are you using KDE by any chance ? Something in it (lots of
> eye candy I bet) manages to slow down even the fastest cards.
>
> Why don't you try twm first and see if it is any better. Next try
> Enlightenment.. I suggest "Blue Metal" scheme as it is less pixmap
> intensive. Also reducing your resolution to 640x480 might speed up things
> as well.
>
>                              Vladimir Dergachev
>
> > Shawn.
> >
> >
> > _______________________________________________
> > Dri-devel mailing list
> > Dri...@li...
> > https://lists.sourceforge.net/lists/listinfo/dri-devel
> >
>
>
>

On Wed, Jan 30, 2002 at 08:27:49PM -0700, Jens Owen wrote:
| This is no joke.  We absolutely need compatability.  Large amounts of
| developer pain don't even begin to compare to the enormous number of
| headaches incompatability causes our users.

Not to mention that Linus will almost certainly throw DRM out of the
kernel if we don't maintain compatibility (or at least a versioning
system that detects incompatibilities and falls back to a
previously-supported configuration).

Allen

Does 800x600 work in 16bpp ?

                     Vladimir Dergachev

On Thu, 31 Jan 2002, Chris Jensen wrote:

> > Please check that setuid bit is set on Xserver binary. There really should
> > not be any difference. The other place to check is that plain users are
> > able to use DRI - the permissions in the DRI section of /etc/XF86Config.
> > Lastly some of the errors you mention are known, see below.
> >
>
> Thanks very much, I've got TV-out going now. I just have (hopefully) one more
> question. At the moment I can only display output properly in 640x480 mode.
> If I try 1024x768 my screen goes blue (my tv does that when the signal is bad
> or not present). If I then use <Ctrl>+<Alt>+<+> to switch to 800x600 it
> displays fine - but if I try to start xfree in 800x600 the signal doesn't
> appear to be synced properly, with the image cut in pieces and placed in
> multiple spots on the screen - and flickering.
> At the moment I have
> HorizSync 30-50
> VertRefresh 60
> (I'm not entirely sure this is correct - but it worked with my old nvidia
> card)
> I've attached the output from XFree when I changed from 1024x768 to 800x600
> I thought of trying to adjust the HorizSync to get it to start in 800x600
> properly - but wheather I start in 1024x768 or 800x600 it always says the
> same for 800x600
> I'm using a display depth of 24 for all the different modes.
> (**) R128(0): Default mode "800x600": 40.0 MHz, 37.9 kHz, 60.3 Hz
> (II) R128(0): Modeline "800x600"   40.00  800 840 968 1056  600 601 605 628
> +hsync +vsync
> I've attached the output to XFree86.log when I switch modes and the matching
> section from when I start up X in 800x600.
> The only difference seems to be that Rage Theatre setting standard is done
> late (but set to the same value) when starting in 800x600, and the value of
> Pitch differs.
> Is it possible to change the value of pitch?
>
> When switching to 800x600 (the working config)
> (II) R128(0): Starting up Xvideo subsystems
> (II) R128(0): Rage Theatre setting standard 0x0301
> (II) Loading sub module "vbe"
> (II) LoadModule: "vbe"
> (II) Reloading /usr/X11R6/lib/modules/libvbe.a
> (II) R128(0): Primary V_BIOS segment is: 0xc000
> (II) R128(0): VESA BIOS detected
> (II) R128(0): VESA VBE Version 2.0
> (II) R128(0): VESA VBE Total Mem: 32768 kB
> (II) R128(0): VESA VBE OEM: ATI RAGE128
> (II) R128(0): VESA VBE OEM Software Rev: 1.0
> (II) R128(0): VESA VBE OEM Vendor: ATI Technologies Inc.
> (II) R128(0): VESA VBE OEM Product: R128
> (II) R128(0): VESA VBE OEM Product Rev: 01.00
> (II) R128(0): VBEInit ok
> (II) R128(0): TV attached to the composite connector
> (II) R128(0): TV is active
> (II) R128(0): Autoswitch is active
> (II) R128(0): TV out chip revision major=0x54 minor=0x0002
> (II) R128(0): Reference frequency 27.00000
> (EE) R128(0): Failed to determine current TV standard
> (II) R128(0): ax=0xa016 bx=0x0002 cx=0x0000
> (II) R128(0): VBEGetMode ok
> (II) R128(0): VBESetMode ok (vbemode=0x122)
> (II) R128(0): Pitch: 128
> (II) R128(0): CRTC_GEN_CNTL = 0x03000600
>
> when starting in 800x600 (doesn't work):
> (II) R128(0): Starting up Xvideo subsystems
> (II) Loading sub module "vbe"
> (II) LoadModule: "vbe"
> (II) Reloading /usr/X11R6/lib/modules/libvbe.a
> (II) R128(0): Primary V_BIOS segment is: 0xc000
> (II) R128(0): VESA BIOS detected
> (II) R128(0): VESA VBE Version 2.0
> (II) R128(0): VESA VBE Total Mem: 32768 kB
> (II) R128(0): VESA VBE OEM: ATI RAGE128
> (II) R128(0): VESA VBE OEM Software Rev: 1.0
> (II) R128(0): VESA VBE OEM Vendor: ATI Technologies Inc.
> (II) R128(0): VESA VBE OEM Product: R128
> (II) R128(0): VESA VBE OEM Product Rev: 01.00
> (II) R128(0): VBEInit ok
> (II) R128(0): TV attached to the composite connector
> (II) R128(0): TV is active
> (II) R128(0): Autoswitch is active
> (II) R128(0): TV out chip revision major=0x54 minor=0x0002
> (II) R128(0): Reference frequency 27.00000
> (EE) R128(0): Failed to determine current TV standard
> (II) R128(0): ax=0xa016 bx=0x0002 cx=0x0000
> (II) R128(0): VBEGetMode ok
> (II) R128(0): VBESetMode ok (vbemode=0x122)
> (II) R128(0): Pitch: 100
> (II) R128(0): CRTC_GEN_CNTL = 0x03000600
>
> Thanks
>
> --
> Chris Jensen
> ch...@dr...
>
> Public Key: http://drspirograph.com/public_key/
>
> Wait: Did you know that there's a direct correlation between the decline of
> Spirograph and the rise in gang activity?  Think about it.
> - Dr Spirograph (The Simpsons)
>

On Wed, 30 Jan 2002, Shawn Starr wrote:

>
> I dont know if this is coming, or if there's any interest. But X just
> *dies* using the CPU to redraw 2D and 3D just isn't even worth using on
> this P200.
>
> I have a Mach64 chipset:
>
> ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT] (rev 41) 2MB
>
> There is no DRI support for this card (at the moment). Is there anyone out
> there working on such a driver? I'm sure a lot of us users would be very
> happy ;)
>

I do not have GT, but I do have GTB (Rage II+DVD) and X seem to work ok
with it. Are you using KDE by any chance ? Something in it (lots of
eye candy I bet) manages to slow down even the fastest cards.

Why don't you try twm first and see if it is any better. Next try
Enlightenment.. I suggest "Blue Metal" scheme as it is less pixmap
intensive. Also reducing your resolution to 640x480 might speed up things
as well.

                             Vladimir Dergachev

> Shawn.
>
>
> _______________________________________________
> Dri-devel mailing list
> Dri...@li...
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

> Please check that setuid bit is set on Xserver binary. There really should
> not be any difference. The other place to check is that plain users are
> able to use DRI - the permissions in the DRI section of /etc/XF86Config.
> Lastly some of the errors you mention are known, see below.
>

Thanks very much, I've got TV-out going now. I just have (hopefully) one more 
question. At the moment I can only display output properly in 640x480 mode.
If I try 1024x768 my screen goes blue (my tv does that when the signal is bad 
or not present). If I then use <Ctrl>+<Alt>+<+> to switch to 800x600 it 
displays fine - but if I try to start xfree in 800x600 the signal doesn't 
appear to be synced properly, with the image cut in pieces and placed in 
multiple spots on the screen - and flickering.
At the moment I have
HorizSync 30-50
VertRefresh 60
(I'm not entirely sure this is correct - but it worked with my old nvidia 
card)
I've attached the output from XFree when I changed from 1024x768 to 800x600
I thought of trying to adjust the HorizSync to get it to start in 800x600 
properly - but wheather I start in 1024x768 or 800x600 it always says the 
same for 800x600
I'm using a display depth of 24 for all the different modes.
(**) R128(0): Default mode "800x600": 40.0 MHz, 37.9 kHz, 60.3 Hz
(II) R128(0): Modeline "800x600"   40.00  800 840 968 1056  600 601 605 628 
+hsync +vsync
I've attached the output to XFree86.log when I switch modes and the matching 
section from when I start up X in 800x600.
The only difference seems to be that Rage Theatre setting standard is done 
late (but set to the same value) when starting in 800x600, and the value of 
Pitch differs.
Is it possible to change the value of pitch?

When switching to 800x600 (the working config)
(II) R128(0): Starting up Xvideo subsystems
(II) R128(0): Rage Theatre setting standard 0x0301
(II) Loading sub module "vbe"
(II) LoadModule: "vbe"
(II) Reloading /usr/X11R6/lib/modules/libvbe.a
(II) R128(0): Primary V_BIOS segment is: 0xc000
(II) R128(0): VESA BIOS detected
(II) R128(0): VESA VBE Version 2.0
(II) R128(0): VESA VBE Total Mem: 32768 kB
(II) R128(0): VESA VBE OEM: ATI RAGE128
(II) R128(0): VESA VBE OEM Software Rev: 1.0
(II) R128(0): VESA VBE OEM Vendor: ATI Technologies Inc.
(II) R128(0): VESA VBE OEM Product: R128
(II) R128(0): VESA VBE OEM Product Rev: 01.00
(II) R128(0): VBEInit ok
(II) R128(0): TV attached to the composite connector
(II) R128(0): TV is active
(II) R128(0): Autoswitch is active
(II) R128(0): TV out chip revision major=0x54 minor=0x0002
(II) R128(0): Reference frequency 27.00000
(EE) R128(0): Failed to determine current TV standard
(II) R128(0): ax=0xa016 bx=0x0002 cx=0x0000
(II) R128(0): VBEGetMode ok
(II) R128(0): VBESetMode ok (vbemode=0x122)
(II) R128(0): Pitch: 128
(II) R128(0): CRTC_GEN_CNTL = 0x03000600

when starting in 800x600 (doesn't work):
(II) R128(0): Starting up Xvideo subsystems
(II) Loading sub module "vbe"
(II) LoadModule: "vbe"
(II) Reloading /usr/X11R6/lib/modules/libvbe.a
(II) R128(0): Primary V_BIOS segment is: 0xc000
(II) R128(0): VESA BIOS detected
(II) R128(0): VESA VBE Version 2.0
(II) R128(0): VESA VBE Total Mem: 32768 kB
(II) R128(0): VESA VBE OEM: ATI RAGE128
(II) R128(0): VESA VBE OEM Software Rev: 1.0
(II) R128(0): VESA VBE OEM Vendor: ATI Technologies Inc.
(II) R128(0): VESA VBE OEM Product: R128
(II) R128(0): VESA VBE OEM Product Rev: 01.00
(II) R128(0): VBEInit ok
(II) R128(0): TV attached to the composite connector
(II) R128(0): TV is active
(II) R128(0): Autoswitch is active
(II) R128(0): TV out chip revision major=0x54 minor=0x0002
(II) R128(0): Reference frequency 27.00000
(EE) R128(0): Failed to determine current TV standard
(II) R128(0): ax=0xa016 bx=0x0002 cx=0x0000
(II) R128(0): VBEGetMode ok
(II) R128(0): VBESetMode ok (vbemode=0x122)
(II) R128(0): Pitch: 100
(II) R128(0): CRTC_GEN_CNTL = 0x03000600

Thanks

-- 
Chris Jensen
ch...@dr...

Public Key: http://drspirograph.com/public_key/

Wait: Did you know that there's a direct correlation between the decline of
Spirograph and the rise in gang activity?  Think about it.
- Dr Spirograph (The Simpsons)

I dont know if this is coming, or if there's any interest. But X just
*dies* using the CPU to redraw 2D and 3D just isn't even worth using on
this P200.

I have a Mach64 chipset:

ATI Technologies Inc 3D Rage I/II 215GT [Mach64 GT] (rev 41) 2MB

There is no DRI support for this card (at the moment). Is there anyone out
there working on such a driver? I'm sure a lot of us users would be very
happy ;)

Shawn.

On Wed, 30 Jan 2002, Jens Owen wrote:

> Vladimir Dergachev wrote:
>
> > Also, I can make drm driver work nice with older 2d drivers - as soon as
> > someone will show me a way to tell the version of the 2d driver that is
> > accessing the drm driver.
>
> How about using a new set of IOCTL numbers for the new interface--then
> you'll know whether you have an old or new driver accessing it.
>

Jens, it is not a new interface. It is simply a matter of moving AGP and
framebuffer apertures within cards internal address space. If it is moved
the buffers (texture, ring buffer, indirect, etc)  need to have their
addresses adjusted. (that was the place where documentation was wrong..
it named those fields as "offsets" but they are absolute addresses). Once
it is setup and the buffer addresses are ok everything goes in as before.
But if any component gets the wrong idea and tells the card "go get a texture
from the wrong place" it all locks up.

To reiterate it is simply a matter of initializing the card.

The problem arises from the fact that initialization is done both in 2d
driver and drm driver. DRM initializes the ring buffer and 2d driver sets up
framebuffer and passes down various buffers - texture, stencil, depth,
etc. If either is wrong lockup results.

                                  Vladimir Dergachev

> --                             /\
>          Jens Owen            /  \/\ _
>   je...@tu...  /    \ \ \   Steamboat Springs, Colorado
>

Vladimir Dergachev wrote:

> As for Linus not wanting to accept it, 2.4 has dropped most nat filters
> except for ftp and most of them aren't back yet. So I don't buy this
> argument.

Vladimir,

This is no joke.  We absolutely need compatability.  Large amounts of
developer pain don't even begin to compare to the enormous number of
headaches incompatability causes our users.

Regards,
Jens

--                             /\
         Jens Owen            /  \/\ _    
  je...@tu...  /    \ \ \   Steamboat Springs, Colorado