gatos-devel Mailing List for GATOS

Hi everyone,

  I've just released my very experimental tv output driver for ati.2.
If you want to try it out, go to GATOS CVS and check out the "tv_output" 
branch of ati.2 module, then compile and install as usual.
Once installed, you need to add the following option to the "device" section
of XF86Config-4:
    Option "TVOutput" "pal"
In future releases more tv standards will be supported and this will be
the place where to set them.

Once ati.2 is installed and "TVOption" is in place, the tv output should 
automatically activate whenever the screen resolution is set to 800x600 
(by using ctrl-alt-keypad +/- for example).

The current version of the driver has the following limitations:
- It only works on cards with 27 MHz reference frequency
- It only works at 800x600 resolution with PAL standard (I have no NTSC 
  tv set to test it on)
- It drives the tv output section of a Rage Theater chip. If your card
  has what I call an Embedded Rage Theater (ERT), i.e. a tv output
  module inside the Radeon chip and not an external RT, this driver will
  not work. But don't worry, I'm working on supporting ERT..

I'm waiting for your feedback! Let me know if you tried it, if it worked
or not, if you have any suggestion, etc. etc.

Thanks in advance.

Regards,

Federico Ulivi - Milan (Italy)
http://utenti.lycos.it/fulivi



____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005

Hi everybody,

I have compiled and installed drm-kernel and ati.2 modules in Mandrake
9.1, and they working fine with Xfree86 4.3.0. After this, I compiled km
modules for video capturing, insmod videodev module and typed make test o=
n
prompt, but I got an error message telling there's no /dev/video/videoX
device. Log files and everything else appears to be right, but videodev
module doesn't detect capture card. I don't know if is missing another
module or if kernel is not well configured or if I made something wrong.
Here, I send modules list, pci table, dmesg and Xfree86 log files for
help, and hoping that someone can help me.

Jos=E9 A. Rodr=EDguez

On Sun, 2003-09-28 at 18:58, Vladimir Dergachev wrote:
> Very interesting :))
> 
>   Do you know why aiw-specific init code does not perform as well ?
In fact no, I did not analyze what funny thing ffmpeg is doing
when it detects km.
Looking at the diff when ffmpeg detects km it calls aiw_init.
Doing the one line patch I made sure ffmpeg does not call this function
and also make sure it uses there read interface that km supports.
To my surprise this worked.

Let me know if you want me to test something specific.
My final goal is to do scheduled recording from my AIW using some GUI
interface.

Bye,
Benoit
> 
>                     best
> 
>                        Vladimir Dergachev
> 
> On Sun, 28 Sep 2003, benoit wrote:
> 
> > Bonjour,
> >
> > Here is the outcome of some testing with km and ffmpeg if anybody
> > interested.
> > - km taken from Cvs 09 sept 2003,
> > - ffmpeg cvs snapshot 27 sept 2003.
> >
> > Test 1. With these 2 version ffmpeg capture one frame every 15s or
so.
> >
> > I found out that ffmpeg has some special code to handle all in
wonder.
> > Now I apply the following patch to skip this special code.
> >
> > --- grab.c_ori  2003-09-27 21:10:06.000000000 -0400
> > +++ grab.c      2003-09-27 21:10:31.000000000 -0400
> > @@ -181,7 +181,7 @@
> >          s->use_mmap = 0;
> >
> >          /* ATI All In Wonder automatic activation */
> > -        if (!strcmp(s->video_cap.name, "Km")) {
> > +        if (!strcmp(s->video_cap.name, "KmDummy")) {
> >              if (aiw_init(s) < 0)
> >                  goto fail;
> >              s->aiw_enabled = 1;
> >
> > Just use a Dummy string so that ffmpeg does not activate Km specific
> > code.
> >
> > test 2. run
> > ./ffmpeg -s 640x240 -vd /dev/video0 -ad /dev/dsp -r 60 -b 1000
> > /tmp/toto1.avi
> >
> > Capture runs well. Playback with mplayer shows correct colors but
motion
> > is not very smooth although audio and video are in sync.
> >
> > Setup:
> > - Mandrake kernel 2.4.22-5 (From cooker),
> > - AIW 8500DV NTSC,
> > - P4 1.6 GHZ
> > - using oss drivers.
> >
> > Bye,
> > Benoit
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Gatos-devel mailing list
> > Gat...@li...
> > https://lists.sourceforge.net/lists/listinfo/gatos-devel
> >

On Sun, 28 Sep 2003, matt mercer wrote:

> Vladimir,
>
> I remember reading once that you would be opposed to merging or syncing
> GATOS dri with the offical dri project, is this still the case?  I have
> been orienting myself to the code base here and I can see there are very
> few functional differences betweem the two code bases.  If the work
> would not be unappreciated I would like to dive in an get the dri code
> in sync.

The only thing I am truly opposed to is maintaining such a merge.
Working against any CVS is hard (you might say this is why it is called
working "against" instead of working "with") and working against device
drivers in CVS is harder.

>
> My plan would be to start by syncing up all the superficial changes like
> comments and struct changes.  The I would follow up with patches to sync
> the few functional changes such as chip specific initiallization and irq
> handling. Hopefully this would amount to alot of small specific patches
> that can be easily reviewed.

It might be easier, at least at first, to just create patches against DRM
drivers. At this point the changes are few.

A more difficult - but very useful thing, would be to modify DRI code in
such a way as to make MC framebuffer offset a parameter that XFree86
driver can set (and preferably switch dynamically during runtime).

This would eliminate the need to maintain DRM and 3d drivers.
DRI folks are not totally opposed to this, but it is not an easy task and
would require quite a bit of time.

                         best

                           Vladimir Dergachev

>
> The end result in syncing the code bases would hopefully yield an easier
> project to maintain and use.
>
> Let me know.
>
> Matt
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gatos-devel mailing list
> Gat...@li...
> https://lists.sourceforge.net/lists/listinfo/gatos-devel
>

Simon wrote:

>Hi,
>
>I have an old ATI PCI card with 2MB Ram. On the card is a label which shows 
>MACH64 VT. I installed the gateos drivers an believed that there is XVideo 
>support for all ATI cards with MACH64 chip. But there seems to be no XVideo 
>support. xvinfo shows the following:
>X-Video Extension version 2.2
>screen #0
> no adaptors present
>Also mplayer and xine:
>mplayer:
>It seems there is no Xvideo support for your video card available.
>xine:
>video_out_xv: Xv extension is present but I couldn't find a usable yuv12 port.
>Looks like your graphics hardware driver doesn't support Xv?!
>
>Doesn't this hardware support xvideo? Here you can find my xfree-log:
>http://saftis.ath.cx/~simon/public/XFree86.0.log
>
>My system is a debian system with some unstable packages:
>XFree86 Version 4.3.0 (Debian 4.3.0-0ds4 20030416150820 dstone@aedificator)
>
>Greetings,
>Simon
>
>
>  
>

Only the Rage series of Mach64 chips have the overlay scalar for Xv.  
There may have been one pre-Rage release of the Mach64 with it, but they 
seem very rare if they exist at all.

Christopher Crawford

>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Gatos-devel mailing list
>Gat...@li...
>https://lists.sourceforge.net/lists/listinfo/gatos-devel
>  
>

Hi Matt,
See also:
http://dxr3.sourceforge.net/re.html
http://www.hnc3k.com/hncfilez/SoftICE%20v4.05.rar
-- 
Best regards,
 Nikolai Zhubr

> Hi,
> Thursday, 25 September, 2003, 7:31:23, matt mercer wrote:
>> So I've thought of a new approach but I'm a little stuck in how to
>> execute it.  Does anyone have any thoughts on an i/o memory sniffer? 
>> Something that can passively monitor all transactions to the range for 
>> this card under windows.  I don't have any idea where to begin with 
>> something like this or if it is even possible.
> Eh, just plain regular x86 architecture provides some
> usefull things for this already. Problem is, this has
> to be done on the system level, so some windows expert
> is necessary for that, but this is not quite right place
> to find one I'm afraid. This also depends on what kind
> of windows you are using. For win9x it might be still
> possible to find kernel-mode software debugger, though
> I'm not quite sure now. For windows NT I have no idea.
> However, if some transactions with the chip happen
> in user-mode completely then it should be much easier
> to trace them. Finally, if by some case RT200 chip needs
> to be accessed from ROM BIOS then it is a great luck -
> then an old good real-mode debugger would help quite
> a lot.
> It might also appear usefull to look into the drivers
> files - in some cases it is possible to find entry
> points to the exported functions at least.
> HTH.

hello.

a giant Thank You to all the developers involved with GATOS.
once i found you i was watching tv via my ATI AIW radeon 7500 within 
minutes. :)

now, of course, i have questions aka problems...
which would be capturing, as i cant get km to compile.
so here is my experience;
any suggestions where to go from here?:

Redhat 8.0

Linux localhost.localdomain 2.4.20-20.8 #1 Mon Aug 18 14:39:22 EDT 2003 
i686 athlon i386 GNU/Linux

model name      : AMD Athlon(tm) Processor
cpu MHz         : 1400.085

pci bus 0x0001 cardnum 0x00 function 0x00: vendor 0x1002 device 0x5157
 ATI Radeon 7500 QW

gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

the following parts came together fine and work at least to some useful 
extent:
ATI-4.2.0-16.i386.tar.gz
avview-0.12.0.tar.gz
ffmpeg-0.4.6.tar.gz
ati_remote-2.1.1.tgz

then, km-0.2.1.tgz fails to compile, as does drm-kernel-1.2.0-16.tar.gz

so, i tried cvs versions. they have fewer warnings. those errors follow. i 
have since tried all cvs versions, but cant get even ati.2 to compile due 
to complaints of missing "Imake.tmpl" and "Server.tmpl" so far..

for km:
---------------------------------
[neil@localhost km]$ make
gcc -m486 -O2 -Wall -Wstrict-prototypes -pipe -fno-strict-aliasing 
-fno-common -DMODULE -D__KERNEL__ -DLINUX -I/usr/src/linux/include -c km.c
`-m486' is deprecated. Use `-march=i486' or `-mcpu=i486' instead.
In file included from km.c:24:
km_memory.h: In function `uvirt_to_kva':
km_memory.h:34: warning: implicit declaration of function `pte_offset'
km_memory.h:34: warning: assignment makes pointer from integer without a 
cast
km.c: In function `km_probe':
km.c:207: warning: unsigned int format, pointer arg (arg 2)
km.c:115: warning: unused variable `result'
km.c:211: warning: label `fail' defined but not used
km.c:117: warning: `tag' might be used uninitialized in this function
km.c: In function `init_module':
km.c:420: warning: unused variable `i'
km_memory.h: At top level:
km.c:418: warning: `init_module' defined but not used
gcc -m486 -O2 -Wall -Wstrict-prototypes -pipe -fno-strict-aliasing 
-fno-common -DMODULE -D__KERNEL__ -DLINUX -I/usr/src/linux/include -c 
km_v4l.c
`-m486' is deprecated. Use `-march=i486' or `-mcpu=i486' instead.
In file included from km_v4l.c:20:
km_memory.h: In function `uvirt_to_kva':
km_memory.h:34: warning: implicit declaration of function `pte_offset'
km_memory.h:34: warning: assignment makes pointer from integer without a 
cast
km_v4l.c: In function `km_mmap':
km_v4l.c:212: warning: passing arg 1 of `remap_page_range_R323728a8' makes 
pointer from integer without a cast
km_v4l.c:212: incompatible type for argument 4 of 
`remap_page_range_R323728a8'
km_v4l.c:212: too few arguments to function `remap_page_range_R323728a8'
km_v4l.c: At top level:
km_v4l.c:267: warning: initialization from incompatible pointer type
make: *** [km_v4l.o] Error 1
[neil@localhost km]$
 
---------------------------------
for drm-kernel:
----------------------------------
[neil@localhost drm-kernel]$ make -f Makefile.linux
=== KERNEL HEADERS IN /lib/modules/2.4.20-20.8/build/include
=== SMP=0 MODULES=1 MODVERSIONS=1 AGP=1
=== Compiling for machine i686
=== WARNING
=== WARNING Use 2.4.x kernels ONLY !
=== WARNING
cc -O2 -pipe -fno-strict-aliasing -fno-common -Wall -Wwrite-strings 
-Wpointer-arith -Wcast-align -Wstrict-prototypes -Wnested-externs 
-Wpointer-arith -D__KERNEL__ -DMODULE -fomit-frame-pointer 
-fno-strict-aliasing -DCONFIG_AGP -DCONFIG_AGP_MODULE -DCONFIG_DRM_SIS 
-DMODVERSIONS -include 
/lib/modules/2.4.20-20.8/build/include/linux/modversions.h -DEXPORT_SYMTAB 
-I/lib/modules/2.4.20-20.8/build/include -c gamma_drv.c -o gamma_drv.o
In file included from 
/lib/modules/2.4.20-20.8/build/include/linux/irq.h:69,
                 from 
/lib/modules/2.4.20-20.8/build/include/asm/hardirq.h:6,
                 from 
/lib/modules/2.4.20-20.8/build/include/linux/interrupt.h:47,
                 from 
/lib/modules/2.4.20-20.8/build/include/asm/highmem.h:25,
                 from 
/lib/modules/2.4.20-20.8/build/include/linux/highmem.h:11,                 
from /lib/modules/2.4.20-20.8/build/include/linux/vmalloc.h:8,
                 from /lib/modules/2.4.20-20.8/build/include/asm/io.h:47,
                 from /lib/modules/2.4.20-20.8/build/include/asm/pci.h:40,
                 from 
/lib/modules/2.4.20-20.8/build/include/linux/pci.h:657,
                 from drmP.h:50,
                 from gamma_drv.c:34:
/lib/modules/2.4.20-20.8/build/include/asm/hw_irq.h: In function 
`x86_do_profile':
/lib/modules/2.4.20-20.8/build/include/asm/hw_irq.h:195: warning: nested 
extern
declaration of `prof_cpu_mask'
/lib/modules/2.4.20-20.8/build/include/asm/hw_irq.h:196: warning: nested 
extern
declaration of `_stext'
In file included from 
/lib/modules/2.4.20-20.8/build/include/linux/vmalloc.h:8,
                 from /lib/modules/2.4.20-20.8/build/include/asm/io.h:47,
                 from /lib/modules/2.4.20-20.8/build/include/asm/pci.h:40,
                 from 
/lib/modules/2.4.20-20.8/build/include/linux/pci.h:657,
                 from drmP.h:50,
                 from gamma_drv.c:34:
/lib/modules/2.4.20-20.8/build/include/linux/highmem.h: In function 
`bh_kmap':
/lib/modules/2.4.20-20.8/build/include/linux/highmem.h:20: warning: 
pointer of type `void *' used in arithmetic
In file included from gamma_drv.c:54:
drm_vm.h: In function `gamma_mmap':
drm_vm.h:462: warning: passing arg 1 of `remap_page_range_R323728a8' makes 
pointer from integer without a cast
drm_vm.h:462: incompatible type for argument 4 of 
`remap_page_range_R323728a8'
drm_vm.h:462: too few arguments to function `remap_page_range_R323728a8'
make: *** [gamma_drv.o] Error 1
[neil@localhost drm-kernel]$

Hi people,

I'd appreciate of someone (Leif?) gave me some hints
regarding drm design and possible interaction and/or
integration with capture code of km. For now, I'd like
to just have some rather basic understanding of drm so
i could then keep it in mind in order to make such
interaction/integration less painfull (in future). The
main items which might appear related/common in drm
and km are:

* detecting supported videocards;
* linking particular X display to the corresponding
  kernel device name;
* getting physical memory from the kernel for dma
  transfers ;
* preparing dma tables;
* monitoring/processing irqs;
* queueing dma transfer;
* processing some reads/writes/ioctls,
* etc.

I'd guess in some cases it would be better to have capture
separate and complitely independent of drm, while in some
other cases it would be better to have it somehow integrated.
So ideally capture stuff should be made compilable both ways
(using the same main files and some #ifdefs perhaps) and
that's what I'm currently thinking about.

BTW, I'd be happy to be able to compile mach64-0-0-6 branch
(right now it refuses to) for 2.6.0-test5 which I'm running
(though it is not strictly necessary at this point yet).
-- 
Best regards,
 Nikolai Zhubr

On Sun, 2003-09-28 at 18:58, Vladimir Dergachev wrote:
> Very interesting :))
> 
>   Do you know why aiw-specific init code does not perform as well ?
In fact no, I did not analysed what funny thing ffmpeg is doing
when it detects km.
Looking at the diff when ffmpeg detects km it calls aiw_init.
Doing the one line patch I made sure ffmpeg does not call this function
and also make sure it uses there read interface that km supports.
To my surprise this worked.

Let me know if you want me to test something specific.
My final goal is to do scheduled recording from my AIW using some GUI
interface.

Bye,
Benoit
> 
>                     best
> 
>                        Vladimir Dergachev
> 
> On Sun, 28 Sep 2003, benoit wrote:
> 
> > Bonjour,
> >
> > Here is the outcome of some testing with km and ffmpeg if anybody
> > interested.
> > - km taken from Cvs 09 sept 2003,
> > - ffmpeg cvs snapshot 27 sept 2003.
> >
> > Test 1. With these 2 version ffmpeg capture one frame every 15s or so.
> >
> > I found out that ffmpeg has some special code to handle all in wonder.
> > Now I apply the following patch to skip this special code.
> >
> > --- grab.c_ori  2003-09-27 21:10:06.000000000 -0400
> > +++ grab.c      2003-09-27 21:10:31.000000000 -0400
> > @@ -181,7 +181,7 @@
> >          s->use_mmap = 0;
> >
> >          /* ATI All In Wonder automatic activation */
> > -        if (!strcmp(s->video_cap.name, "Km")) {
> > +        if (!strcmp(s->video_cap.name, "KmDummy")) {
> >              if (aiw_init(s) < 0)
> >                  goto fail;
> >              s->aiw_enabled = 1;
> >
> > Just use a Dummy string so that ffmpeg does not activate Km specific
> > code.
> >
> > test 2. run
> > ./ffmpeg -s 640x240 -vd /dev/video0 -ad /dev/dsp -r 60 -b 1000
> > /tmp/toto1.avi
> >
> > Capture runs well. Playback with mplayer shows correct colors but motion
> > is not very smooth although audio and video are in sync.
> >
> > Setup:
> > - Mandrake kernel 2.4.22-5 (From cooker),
> > - AIW 8500DV NTSC,
> > - P4 1.6 GHZ
> > - using oss drivers.
> >
> > Bye,
> > Benoit
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Gatos-devel mailing list
> > Gat...@li...
> > https://lists.sourceforge.net/lists/listinfo/gatos-devel
> >

Very interesting :))

  Do you know why aiw-specific init code does not perform as well ?

                    best

                       Vladimir Dergachev

On Sun, 28 Sep 2003, benoit wrote:

> Bonjour,
>
> Here is the outcome of some testing with km and ffmpeg if anybody
> interested.
> - km taken from Cvs 09 sept 2003,
> - ffmpeg cvs snapshot 27 sept 2003.
>
> Test 1. With these 2 version ffmpeg capture one frame every 15s or so.
>
> I found out that ffmpeg has some special code to handle all in wonder.
> Now I apply the following patch to skip this special code.
>
> --- grab.c_ori  2003-09-27 21:10:06.000000000 -0400
> +++ grab.c      2003-09-27 21:10:31.000000000 -0400
> @@ -181,7 +181,7 @@
>          s->use_mmap = 0;
>
>          /* ATI All In Wonder automatic activation */
> -        if (!strcmp(s->video_cap.name, "Km")) {
> +        if (!strcmp(s->video_cap.name, "KmDummy")) {
>              if (aiw_init(s) < 0)
>                  goto fail;
>              s->aiw_enabled = 1;
>
> Just use a Dummy string so that ffmpeg does not activate Km specific
> code.
>
> test 2. run
> ./ffmpeg -s 640x240 -vd /dev/video0 -ad /dev/dsp -r 60 -b 1000
> /tmp/toto1.avi
>
> Capture runs well. Playback with mplayer shows correct colors but motion
> is not very smooth although audio and video are in sync.
>
> Setup:
> - Mandrake kernel 2.4.22-5 (From cooker),
> - AIW 8500DV NTSC,
> - P4 1.6 GHZ
> - using oss drivers.
>
> Bye,
> Benoit
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gatos-devel mailing list
> Gat...@li...
> https://lists.sourceforge.net/lists/listinfo/gatos-devel
>

s/
I remember reading once that you would
/
I remember reading once that you wouldn't


I think faster than I type sometimes :)

Matt

Vladimir,

I remember reading once that you would be opposed to merging or syncing 
GATOS dri with the offical dri project, is this still the case?  I have 
been orienting myself to the code base here and I can see there are very 
few functional differences betweem the two code bases.  If the work 
would not be unappreciated I would like to dive in an get the dri code 
in sync.

My plan would be to start by syncing up all the superficial changes like 
comments and struct changes.  The I would follow up with patches to sync 
the few functional changes such as chip specific initiallization and irq 
handling. Hopefully this would amount to alot of small specific patches 
that can be easily reviewed.

The end result in syncing the code bases would hopefully yield an easier 
project to maintain and use.

Let me know.

Matt

Bonjour,

Here is the outcome of some testing with km and ffmpeg if anybody
interested.
- km taken from Cvs 09 sept 2003,
- ffmpeg cvs snapshot 27 sept 2003.

Test 1. With these 2 version ffmpeg capture one frame every 15s or so.

I found out that ffmpeg has some special code to handle all in wonder.
Now I apply the following patch to skip this special code.

--- grab.c_ori  2003-09-27 21:10:06.000000000 -0400
+++ grab.c      2003-09-27 21:10:31.000000000 -0400
@@ -181,7 +181,7 @@
         s->use_mmap = 0;
         
         /* ATI All In Wonder automatic activation */
-        if (!strcmp(s->video_cap.name, "Km")) {
+        if (!strcmp(s->video_cap.name, "KmDummy")) {
             if (aiw_init(s) < 0)
                 goto fail;
             s->aiw_enabled = 1;

Just use a Dummy string so that ffmpeg does not activate Km specific
code.

test 2. run
./ffmpeg -s 640x240 -vd /dev/video0 -ad /dev/dsp -r 60 -b 1000
/tmp/toto1.avi 

Capture runs well. Playback with mplayer shows correct colors but motion
is not very smooth although audio and video are in sync.

Setup:
- Mandrake kernel 2.4.22-5 (From cooker),
- AIW 8500DV NTSC,
- P4 1.6 GHZ
- using oss drivers.

Bye,
Benoit

Bonjour,

Here is the outcome of some testing with km and ffmpeg if anybody
interested.
- km taken from Cvs 09 sept 2003,
- ffmpeg cvs snapshot 27 sept 2003.

Test 1. With these 2 version ffmpeg capture one frame every 15s or so.

I found out that ffmpeg has some special code to handle all in wonder.
Now I apply the following patch to skip this special code.

--- grab.c_ori  2003-09-27 21:10:06.000000000 -0400
+++ grab.c      2003-09-27 21:10:31.000000000 -0400
@@ -181,7 +181,7 @@
         s->use_mmap = 0;
         
         /* ATI All In Wonder automatic activation */
-        if (!strcmp(s->video_cap.name, "Km")) {
+        if (!strcmp(s->video_cap.name, "KmDummy")) {
             if (aiw_init(s) < 0)
                 goto fail;
             s->aiw_enabled = 1;

Just use a Dummy string so that ffmpeg does not activate Km specific
code.

test 2. run
./ffmpeg -s 640x240 -vd /dev/video0 -ad /dev/dsp -r 60 -b 1000
/tmp/toto1.avi 

Capture runs well. Playback with mplayer shows correct colors but motion
is not very smooth although audio and video are in sync.

Setup:
- Mandrake kernel 2.4.22-5 (From cooker),
- AIW 8500DV NTSC,
- P4 1.6 GHZ
- using oss drivers.

Bye,
Benoit

Bonjour,

Here is the outcome of some testing with km and ffmpeg if anybody
interested.
- km taken from Cvs 09 sept 2003,
- ffmpeg cvs snapshot 27 sept 2003.

Test 1. With these 2 version ffmpeg capture one frame every 15s or so.

I found out that ffmpeg has some special code to handle all in wonder.
Now I apply the following patch to skip this special code.

--- grab.c_ori  2003-09-27 21:10:06.000000000 -0400
+++ grab.c      2003-09-27 21:10:31.000000000 -0400
@@ -181,7 +181,7 @@
         s->use_mmap = 0;
         
         /* ATI All In Wonder automatic activation */
-        if (!strcmp(s->video_cap.name, "Km")) {
+        if (!strcmp(s->video_cap.name, "KmDummy")) {
             if (aiw_init(s) < 0)
                 goto fail;
             s->aiw_enabled = 1;

Just use a Dummy string so that ffmpeg does not activate Km specific
code.

test 2. run
./ffmpeg -s 640x240 -vd /dev/video0 -ad /dev/dsp -r 60 -b 1000
/tmp/toto1.avi 

Capture runs well. Playback with mplayer shows correct colors but motion
is not very smooth although audio and video are in sync.

Setup:
- Mandrake kernel 2.4.22-5 (From cooker),
- AIW 8500DV NTSC,
- P4 1.6 GHZ
- using oss drivers.

Bye,
Benoit

Hmmm.. Did I ask you before to try and not load your eth0 driver ?

                          best

                             Vladimir Dergachev

On Sat, 27 Sep 2003, Matt Hamilton wrote:

> One additional comment.  If instead of clicking the record button in avview,
> if I instead just cat /dev/video>video.raw, I see the same symptoms -- very
> little data gets captures, and the same messages about the queue being full
> show up in the syslog.
>
> -Matt
>
> On Saturday 27 September 2003 21:42, Matt Hamilton wrote:
> > I have changed the order to have km load at boot time, so it comes before
> > DRM; and I have disabled DRM completely.  Here is the /proc/interrupts with
> > DRM disabled...
> >            CPU0
> >   0:      22268          XT-PIC  timer
> >   1:        609          XT-PIC  keyboard
> >   2:          0          XT-PIC  cascade
> >   5:          0          XT-PIC  ehci-hcd
> >   8:          1          XT-PIC  rtc
> >   9:          0          XT-PIC  acpi
> >  10:      74265          XT-PIC  usb-uhci, VIA8233
> >  11:        260          XT-PIC  usb-uhci, usb-uhci, eth0, km_ati (Radeon)
> >  12:       3429          XT-PIC  PS/2 Mouse
> >  14:      15688          XT-PIC  ide0
> >  15:         61          XT-PIC  ide1
> > NMI:          0
> > LOC:      22228
> > ERR:         22
> > MIS:          0
> >
> > ... and with km loaded at boot time, before DRM ...
> >            CPU0
> >   0:       9960          XT-PIC  timer
> >   1:        163          XT-PIC  keyboard
> >   2:          0          XT-PIC  cascade
> >   5:          0          XT-PIC  ehci-hcd
> >   8:          1          XT-PIC  rtc
> >   9:          0          XT-PIC  acpi
> >  10:       1026          XT-PIC  usb-uhci, VIA8233
> >  11:        247          XT-PIC  usb-uhci, usb-uhci, km_ati (Radeon), eth0,
> > radeon@PCI:1:0:0
> >  12:        399          XT-PIC  PS/2 Mouse
> >  14:      14799          XT-PIC  ide0
> >  15:         61          XT-PIC  ide1
> > NMI:          0
> > LOC:       9921
> > ERR:          2
> > MIS:          0
> >
> > Both cases yield same results.  This is km from CVS, and I get no video
> > frames recorded at all or very few.  When I had km loaded before DRM, I did
> > manage to get about 6 frames captured in 30-60 seconds.  I was monitoring
> > the syslog during that time, and I saw several messages such as the
> > following:
> >
> > Sep 27 21:35:19 hamilton kernel: km: GUI_DMA queue (size=10) is full
> > first=4 last=3 flag=0x80000001
> >
> > The first & last values varied, but there were many of those messages.
> > Also, upon startup of avview, I found the following messages curious -- do
> > these have anything to do with it or is that just a standard scan of the
> > most commonly used video channels?  Obviously /dev/video0 exists, but
> > video[1-7] do not.
> >
> > Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module
> > char-major-81-1
> > Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module
> > char-major-81-2
> > Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module
> > char-major-81-3
> > Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module
> > char-major-81-4
> > Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module
> > char-major-81-5
> > Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module
> > char-major-81-6
> > Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module
> > char-major-81-7
> >
> > -Matt
> >
> > On Thursday 25 September 2003 06:36, Vladimir Dergachev wrote:
> > > Well, it should be no problem for km to share interrupts, except for
> > > another driver accessing the same hardware. Try to change the order in
> > > which drivers are loaded, i.e. try to load km after DRM driver or vice
> > > versa or simply try to prevent DRM driver from loading.
> > >
> > >                          best
> > >
> > >                             Vladimir Dergachev
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gatos-devel mailing list
> Gat...@li...
> https://lists.sourceforge.net/lists/listinfo/gatos-devel
>

One additional comment.  If instead of clicking the record button in avview, 
if I instead just cat /dev/video>video.raw, I see the same symptoms -- very 
little data gets captures, and the same messages about the queue being full 
show up in the syslog.

-Matt

On Saturday 27 September 2003 21:42, Matt Hamilton wrote:
> I have changed the order to have km load at boot time, so it comes before
> DRM; and I have disabled DRM completely.  Here is the /proc/interrupts with
> DRM disabled...
>            CPU0
>   0:      22268          XT-PIC  timer
>   1:        609          XT-PIC  keyboard
>   2:          0          XT-PIC  cascade
>   5:          0          XT-PIC  ehci-hcd
>   8:          1          XT-PIC  rtc
>   9:          0          XT-PIC  acpi
>  10:      74265          XT-PIC  usb-uhci, VIA8233
>  11:        260          XT-PIC  usb-uhci, usb-uhci, eth0, km_ati (Radeon)
>  12:       3429          XT-PIC  PS/2 Mouse
>  14:      15688          XT-PIC  ide0
>  15:         61          XT-PIC  ide1
> NMI:          0
> LOC:      22228
> ERR:         22
> MIS:          0
>
> ... and with km loaded at boot time, before DRM ...
>            CPU0
>   0:       9960          XT-PIC  timer
>   1:        163          XT-PIC  keyboard
>   2:          0          XT-PIC  cascade
>   5:          0          XT-PIC  ehci-hcd
>   8:          1          XT-PIC  rtc
>   9:          0          XT-PIC  acpi
>  10:       1026          XT-PIC  usb-uhci, VIA8233
>  11:        247          XT-PIC  usb-uhci, usb-uhci, km_ati (Radeon), eth0,
> radeon@PCI:1:0:0
>  12:        399          XT-PIC  PS/2 Mouse
>  14:      14799          XT-PIC  ide0
>  15:         61          XT-PIC  ide1
> NMI:          0
> LOC:       9921
> ERR:          2
> MIS:          0
>
> Both cases yield same results.  This is km from CVS, and I get no video
> frames recorded at all or very few.  When I had km loaded before DRM, I did
> manage to get about 6 frames captured in 30-60 seconds.  I was monitoring
> the syslog during that time, and I saw several messages such as the
> following:
>
> Sep 27 21:35:19 hamilton kernel: km: GUI_DMA queue (size=10) is full
> first=4 last=3 flag=0x80000001
>
> The first & last values varied, but there were many of those messages. 
> Also, upon startup of avview, I found the following messages curious -- do
> these have anything to do with it or is that just a standard scan of the
> most commonly used video channels?  Obviously /dev/video0 exists, but
> video[1-7] do not.
>
> Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module
> char-major-81-1
> Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module
> char-major-81-2
> Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module
> char-major-81-3
> Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module
> char-major-81-4
> Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module
> char-major-81-5
> Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module
> char-major-81-6
> Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module
> char-major-81-7
>
> -Matt
>
> On Thursday 25 September 2003 06:36, Vladimir Dergachev wrote:
> > Well, it should be no problem for km to share interrupts, except for
> > another driver accessing the same hardware. Try to change the order in
> > which drivers are loaded, i.e. try to load km after DRM driver or vice
> > versa or simply try to prevent DRM driver from loading.
> >
> >                          best
> >
> >                             Vladimir Dergachev

Hi Simon :)

  I don't think you hardware is supported by GATOS driver (as far as Xv is
concerned).

  Two reasons:

  * the YUV scaler cannot support larger resolutions required by DVDs (or TV signal)

  * you do not have enough video ram to fit framebuffer, YUV image and
    mouse cursor simultaneously.

                            best

                                Vladimir Dergachev


On Sat, 27 Sep 2003, Simon wrote:

> Hi,
>
> I have an old ATI PCI card with 2MB Ram. On the card is a label which shows
> MACH64 VT. I installed the gateos drivers an believed that there is XVideo
> support for all ATI cards with MACH64 chip. But there seems to be no XVideo
> support. xvinfo shows the following:
> X-Video Extension version 2.2
> screen #0
>  no adaptors present
> Also mplayer and xine:
> mplayer:
> It seems there is no Xvideo support for your video card available.
> xine:
> video_out_xv: Xv extension is present but I couldn't find a usable yuv12 port.
> Looks like your graphics hardware driver doesn't support Xv?!
>
> Doesn't this hardware support xvideo? Here you can find my xfree-log:
> http://saftis.ath.cx/~simon/public/XFree86.0.log
>
> My system is a debian system with some unstable packages:
> XFree86 Version 4.3.0 (Debian 4.3.0-0ds4 20030416150820 dstone@aedificator)
>
> Greetings,
> Simon
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gatos-devel mailing list
> Gat...@li...
> https://lists.sourceforge.net/lists/listinfo/gatos-devel
>

I have changed the order to have km load at boot time, so it comes before DRM; 
and I have disabled DRM completely.  Here is the /proc/interrupts with DRM 
disabled...
           CPU0
  0:      22268          XT-PIC  timer
  1:        609          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:          0          XT-PIC  ehci-hcd
  8:          1          XT-PIC  rtc
  9:          0          XT-PIC  acpi
 10:      74265          XT-PIC  usb-uhci, VIA8233
 11:        260          XT-PIC  usb-uhci, usb-uhci, eth0, km_ati (Radeon)
 12:       3429          XT-PIC  PS/2 Mouse
 14:      15688          XT-PIC  ide0
 15:         61          XT-PIC  ide1
NMI:          0
LOC:      22228
ERR:         22
MIS:          0

... and with km loaded at boot time, before DRM ...
           CPU0
  0:       9960          XT-PIC  timer
  1:        163          XT-PIC  keyboard
  2:          0          XT-PIC  cascade
  5:          0          XT-PIC  ehci-hcd
  8:          1          XT-PIC  rtc
  9:          0          XT-PIC  acpi
 10:       1026          XT-PIC  usb-uhci, VIA8233
 11:        247          XT-PIC  usb-uhci, usb-uhci, km_ati (Radeon), eth0, 
radeon@PCI:1:0:0
 12:        399          XT-PIC  PS/2 Mouse
 14:      14799          XT-PIC  ide0
 15:         61          XT-PIC  ide1
NMI:          0
LOC:       9921
ERR:          2
MIS:          0

Both cases yield same results.  This is km from CVS, and I get no video frames 
recorded at all or very few.  When I had km loaded before DRM, I did manage 
to get about 6 frames captured in 30-60 seconds.  I was monitoring the syslog 
during that time, and I saw several messages such as the following:

Sep 27 21:35:19 hamilton kernel: km: GUI_DMA queue (size=10) is full first=4 
last=3 flag=0x80000001

The first & last values varied, but there were many of those messages.  Also, 
upon startup of avview, I found the following messages curious -- do these 
have anything to do with it or is that just a standard scan of the most 
commonly used video channels?  Obviously /dev/video0 exists, but video[1-7] 
do not.

Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module 
char-major-81-1
Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module 
char-major-81-2
Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module 
char-major-81-3
Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module 
char-major-81-4
Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module 
char-major-81-5
Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module 
char-major-81-6
Sep 27 21:34:28 hamilton modprobe: modprobe: Can't locate module 
char-major-81-7

-Matt

On Thursday 25 September 2003 06:36, Vladimir Dergachev wrote:
> Well, it should be no problem for km to share interrupts, except for
> another driver accessing the same hardware. Try to change the order in
> which drivers are loaded, i.e. try to load km after DRM driver or vice
> versa or simply try to prevent DRM driver from loading.
>
>                          best
>
>                             Vladimir Dergachev

Hi,

I have an old ATI PCI card with 2MB Ram. On the card is a label which shows 
MACH64 VT. I installed the gateos drivers an believed that there is XVideo 
support for all ATI cards with MACH64 chip. But there seems to be no XVideo 
support. xvinfo shows the following:
X-Video Extension version 2.2
screen #0
 no adaptors present
Also mplayer and xine:
mplayer:
It seems there is no Xvideo support for your video card available.
xine:
video_out_xv: Xv extension is present but I couldn't find a usable yuv12 port.
Looks like your graphics hardware driver doesn't support Xv?!

Doesn't this hardware support xvideo? Here you can find my xfree-log:
http://saftis.ath.cx/~simon/public/XFree86.0.log

My system is a debian system with some unstable packages:
XFree86 Version 4.3.0 (Debian 4.3.0-0ds4 20030416150820 dstone@aedificator)

Greetings,
Simon

I have some thermal problems with my Radeon 8500, mainly because I
have a SMP-machine and one of the processors is 5 mm from the graphics card.

So I'm wondering, can I use gatos to underclock my Radeon 8500? Or can
I do that with the standard XFree86-4.3.0 drivers? Can I do it manually
through some strange /proc-entry? Is there any program that does it?

I've found some references to gatos.conf having an overclock setting,
but that looks fairly old.

/Carl-Johan Kjellander
please, CC me as I'm not on the list


-- 
begin 644 carljohan_at_kjellander_dot_com.gif
Y1TE&.#=A(0`F`(```````/___RP`````(0`F```"@XR/!\N<#U.;+MI`<[U(>\!UGQ9BGT%>'D2I
Y*=NX,2@OUF2&<827ILW;^822C>\7!!Z1,!K'B5(6H<SH-"E*TJ3%*/>QI6:7"A>Y?):D2^*U@NCV
R<MOQ=]V(B6>LZYD-_T1U<@3W]A4(^$-W4]A#V")W6#.R"$;IR'@).46BN7$9>5D``#L`

Hi,
Thursday, 25 September, 2003, 7:31:23, matt mercer wrote:
> So I've thought of a new approach but I'm a little stuck in how to
> execute it.  Does anyone have any thoughts on an i/o memory sniffer? 
> Something that can passively monitor all transactions to the range for 
> this card under windows.  I don't have any idea where to begin with 
> something like this or if it is even possible.
Eh, just plain regular x86 architecture provides some
usefull things for this already. Problem is, this has
to be done on the system level, so some windows expert
is necessary for that, but this is not quite right place
to find one I'm afraid. This also depends on what kind
of windows you are using. For win9x it might be still
possible to find kernel-mode software debugger, though
I'm not quite sure now. For windows NT I have no idea.
However, if some transactions with the chip happen
in user-mode completely then it should be much easier
to trace them. Finally, if by some case RT200 chip needs
to be accessed from ROM BIOS then it is a great luck -
then an old good real-mode debugger would help quite
a lot.
It might also appear usefull to look into the drivers
files - in some cases it is possible to find entry
points to the exported functions at least.
HTH.
-- 
Best regards,
 Nikolai Zhubr

> Matt



> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gatos-devel mailing list
> Gat...@li...
> https://lists.sourceforge.net/lists/listinfo/gatos-devel

Hi,

I think I had found the problem. The different I read in the=20
XFree86.0.log. At first with ati.2 (file: ATI-4.3.0-10.i386.tar.gz)

(a part of logfile)
ATI Radeon 8500 Ql (AGP), ATI Radeon 8500 BB (AGP),
ATI Radeon 7500 QW (AGP), ATI Radeon 7500 QX (AGP),
ATI Radeon 9000 Id (AGP), ATI Radeon 9000 Ie (AGP),
ATI Radeon 9000 If (AGP), ATI Radeon 9000 Ig (AGP),
ATI Radeon Mobility M9 Ld (AGP), ATI Radeon Mobility M9 Le (AGP),
ATI Radeon Mobility M9 Lf (AGP), ATI Radeon Mobility M9 Lg (AGP),
ATI Radeon 9500 AD (AGP), ATI Radeon 9500 AE (AGP),
ATI Radeon 9500 AF (AGP), ATI FireGL Z1/X1 AG (AGP),
ATI Radeon 9700 Pro ND (AGP), ATI Radeon 9700/9500Pro NE (AGP),
ATI Radeon 9700 NF (AGP), ATI FireGL X1 NG (AGP)

Second XFree86.0.log with orginal files.

ATI Radeon 9000 Id (AGP), ATI Radeon 9000 Ie (AGP),
ATI Radeon 9000 If (AGP), ATI Radeon 9000 Ig (AGP),
ATI Radeon Mobility M9 Ld (AGP), ATI Radeon Mobility M9 Le (AGP),
ATI Radeon Mobility M9 Lf (AGP), ATI Radeon Mobility M9 Lg (AGP),
ATI Radeon 9200 5960 (AGP), ATI Radeon 9200 5961 (AGP),
ATI Radeon 9200 5962 (AGP), ATI Radeon 9200 5963 (AGP),
ATI Radeon M9+ 5968 (AGP), ATI Radeon M9+ 5969 (AGP),
ATI Radeon M9+ 596A (AGP), ATI Radeon M9+ 596B (AGP),
ATI Radeon 9500 AD (AGP), ATI Radeon 9500 AE (AGP),
ATI Radeon 9500 AF (AGP), ATI FireGL Z1/X1 AG (AGP),
ATI Radeon 9700 Pro ND (AGP), ATI Radeon 9700/9500Pro NE (AGP),
ATI Radeon 9700 NF (AGP), ATI FireGL X1 NG (AGP)

The driver von ati.2 don't my "ATI radeon 9200".

My Question.

Which ati.2-Version and drm-kernel I must used for radeon 9200???

Bye Maik

P.S.: Sorry for my bad English. :-)

Jos=E9 Moreira schrieb:
> On Wed, 2003-09-24 at 13:34, Maik Sturm wrote:
>=20
>>Hello,
>>
>>I use "ati radeon 9200 card" and can't used the DVI-out for my Flatscre=
en.
>>
>>Ich had compile the drm-kernel and load the radeon-Modul with ./insmod
>>radeon ; modprobe radeon. Thats ok!
>>
>>Than I had copy the files from ati to /usr/X11R6 and restart "X".
>>
>>But X don't start.
>>
>>ERROR:

On Thu, 2003-09-25 at 15:43, Vladimir Dergachev wrote:
> Does it help if you do chmod 777 /dev/dri ? Also, on my system, the group
> is also root.
I've tried it, but it changed nothing. 
That the dri group is video and has the permission 770 allows me to
implement a little more security, only users of the group video are
allowed to use dri. Other doesn't get the hardware acceleration.

Greetings Ben

Does it help if you do chmod 777 /dev/dri ? Also, on my system, the group
is also root.

                       best

                          Vladimir Dergachev

On Thu, 25 Sep 2003, Benjamin Mesing wrote:

> >
> > Hmm.. What are the permissions on /dev/dri and /dev/dri/* ?
>
> ~> ll -d /dev/dri/
> drwxrwx---    2 root     video          56 2003-07-31 19:51 /dev/dri/
>
> ~>  ll -d /dev/dri/*
> crw-rw----    1 root     video    226,   0 2003-03-31 16:27 /dev/dri/card=
0
>
> Greetings Ben
>
>
> --
> NEU F=DCR ALLE - GMX MediaCenter - f=FCr Fotos, Musik, Dateien...
> Fotoalbum, File Sharing, MMS, Multimedia-Gru=DF, GMX FotoService
>
> Jetzt kostenlos anmelden unter http://www.gmx.net
>
> +++ GMX - die erste Adresse f=FCr Mail, Message, More! +++
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gatos-devel mailing list
> Gat...@li...
> https://lists.sourceforge.net/lists/listinfo/gatos-devel
>