No announcement yet.

"Ask ATI" dev thread

  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by mr_ed View Post
    i cannot get tv-in working with the open source driver.

    I tried several options:

    (**) radeon(0): Option "ragetheatrecrystal" "2950"
    (**) radeon(0): Option "ragetheatretunerport" "0"
    (**) radeon(0): Option "ragetheatrecompositeport" "2"
    (**) radeon(0): Option "ragetheatresvideoport" "6"
    (**) radeon(0): Option "tunertype" "0"
    (**) radeon(0): Option "ragetheatremicrocpath" "/usr/lib/xorg/modules/multimedia/ativmc20.cod"
    (**) radeon(0): Option "ragetheatremicroctype" "binary"
    (**) radeon(0): Option "defaultconnectortable" "on"
    (**) radeon(0): Option "tvstandard" "pal"

    but the only output i get in xorg.log:

    (ii) module exa: Vendor=" foundation"
    compiled for 1.5.3, module version = 2.4.0
    abi class: video driver, version 4.1
    (**) radeon(0): Rage theatre crystal frequency was specified as 29.50 mhz
    (**) radeon(0): Rage theatre tuner port was specified as 0
    (**) radeon(0): Rage theatre composite port was specified as 2
    (**) radeon(0): Rage theatre svideo port was specified as 6
    (**) radeon(0): Tuner type was specified as 0
    (**) radeon(0): Rage theatre microcode path was specified as /usr/lib/xorg/modules/multimedia/ativmc20.cod
    (**) radeon(0): Rage theatre microcode type was specified as binary
    (==) radeon(0): Assuming overlay scaler buffer width is 1920
    (ii) radeon(0): Cannot access bios or it is not valid.
    If your card is tv-in capable you will need to specify options ragetheatrecrystal, ragetheatretunerport,
    ragetheatresvideoport and tunertype in /etc/x11/xorg.conf.
    (!!) radeon(0): For information on using the multimedia capabilities
    of this adapter, please see

    With previous versions of the driver it was no problem.

    Can somebody help me?

    this also is solved for me setting the *nomodeset* parameter.



    • Radeon Microcode

      There is microcode (a "binary blob") in the Radeon driver in the Linux kernel. Because of this, according to the Free Software Definition, the open source Radeon drivers are non-free software.

      Has the information about what this microcode does been released by ATI? Is there anything stopping ATI from releasing it?

      The microcode appears to only be used to initialize the Radeon command processor. With proper documentation for the microcode, the open source Radeon drivers could be 100% free software. This would allow free software users the opportunity to use many powerful Radeon video cards for 3D graphics in GNU/Linux.

      Thank you so much!


      • This is one of the few places where I suspect the Free Software Definition is being misapplied, or at least being used in a way which brings unintended consequences. I can't believe that the definition was written to deliberately penalize hardware vendors who load microcode in the driver rather than autoloading it from ROM or permanently storing the microcode on-chip, but that is what is happening right now.

        We are documenting all of the programming information required to write 100% free, highly functional and performant drivers. We are not documenting the internal functioning of the hardware, and the microcode images are part of that internal hardware function. No GPU vendor allows modification of the internal microcode, whether it be stored permanently on the chip or loaded at power-up. If I was being told that all microcode was evil and that you were not going to use any chips which run internal microcode unless you had source for that microcode I could understand, but that is not the case here.

        The argument, as I understand it, is "since your microcode image is loaded at power-up by the driver then the microcode needs to meet all the rules we apply to the rest of the driver code, even though it is not driver code, is never executed by the CPU, and once it is loaded it is NO DIFFERENT from microcode which had been permanently stored in the chip or autoloaded from ROM".

        Honestly I don't see why a microcode image loaded at power-up is any less free than the same microcode stored permanently in the chip. Neither one can be read or understood, neither one allows learning or changing or redistributing the changes, yet apparently one is Good and one is Evil. I can't believe that was Mr. Stallman's intention.

        AFAIK most of the older Radeon GPUs can use the 3D engine *without* the command processor, albeit more slowly, since there is a command FIFO which can accept command packets without requiring that the microcode images be loaded. I have mentioned this to a couple of developers but so far there hasn't been much interest. Only the 6xx-and-up parts absolutely require the command processor microcde for 3D.
        Last edited by bridgman; 17 March 2009, 03:31 PM.
        Test signature


        • also - gpu's aren't the only microcode users. If you are anal about that, there are a lot more drivers you couldn't use. SCSI, gb-ethernet, 10gb-ethernet and a couple of others ...


          • Bridgman, when ATI says that it is dropping support for R300-R500 support in Catalyst does that include the windows side of the driver?


            • Sort of. We're moving the current code off into a legacy branch and then removing 3xx-5xx code from the main driver source tree, so beginning with Cat 9.4 all monthly Catalyst drivers will only support 6xx and up. This applies to all OSes.

              Separately, we plan to provide quarterly updates for Windows off the legacy branch, but that will mostly be fixes for security issues and maybe newly released apps/games. No support for new OS releases.

              That model won't work with Linux, since :

              (a) the equivalent of new OS releases come along pretty much every month so the legacy branch would quickly fall behind, and

              (b) most Linux users are not just expecting the current level of fglrx functionality on their 3xx-5xx GPUs but ongoing improvements in areas like video playback, 2D performance and suspend/resume.

              We looked at the options and decided that it made more sense to provide ongoing support via the open source drivers than by spending the same effort porting the current fglrx functionality to new OS and kernel versions.
              Last edited by bridgman; 17 March 2009, 04:13 PM.
              Test signature


              • Thanks for clearing that up for me bridgman!


                • Hello bridgman, I have a question about the open source drivers and Ubuntu 9.04.

                  I will have to use the radeon or radeonhd driver since Catalyst 9.4 won't support my x1600 mobility. I use my laptop to work at school, and with fglrx I always set the powerstate option to 1, it saves my battery and keeps my computer quiet (thank you AMD for the auto-powerstate option :love: ).
                  The question is: Will I be able to do the same thing with the open-source drivers?

                  The different powerstates seem to be coded in the bios of the card (or something like thats), so maybe it is possible to set the state I want to use in the xorg.conf?


                  • bridgman, thanks for the quick response. I personally really like everything possible to be free on a system, but I can understand that in some cases there are mitigating circumstances that can prevent this. However, do you know if there are any specific problems with getting the Radeon CP microcode in a non-blob and documented format? Has ATI said they have any problems with this in the past, and has anyone asked them?

                    Thank you!


                    • @static_drc have you asked Intel about their microcode blob for their cpus?