DisplayPort Support?

[CrystalCowboy]

DisplayPort video cards and monitors will hit the market in 2008. Has there been any planning to support this with the radeonhd driver? Any comments on how difficult this is expected to be?

[Svartalf]

Typically the primary interface edges for video (i.e. VGA and DVI) do not need any assistance from the driver to work. You typically don't see Composite out because it's not usually turned on in the card and the driver turns it on. If DisplayPort's the new spec and there's going to be cards out for it, the odds are rather good that it'll be supported if the card is supported on Linux.

[libv]

DisplayPort video cards and monitors will hit the market in 2008. Has there been any planning to support this with the radeonhd driver? Any comments on how difficult this is expected to be?

displayport capable hardware will require some work to bring up, but it is nothing our driver model will not be able to handle beautifully.

It will just take some time to do this, and we were told that, for such major work, in future, we will get preproduction hardware for this, so that, at the time of release, we can offer immediate support.

[CrystalCowboy]

Thanks for the responses, it all sounds very promising. Waiting is the hard part.

[CrystalCowboy]

Review of the HD3670 aka RV635 XT

AMD have two version of RV635, one is Pro(core/memory: 600MHz/1000MHz),will be named as HD 3650. The other one is XT(core/memory: 800MHz/1600MHz) will be called HD 3670.

HD 3670 will hit the market in late January. And HD 3650 will begin selling in late February.

These will have DisplayPort connectors.

[CrystalCowboy]

ATI 3450, 3470, 3650 officially launched
When can support for these be expected in radeonhd, particularly if I want to use the DisplayPort output?

TIA,

[bridgman]

Current plan is to add support in two stages -- existing functionality (ie without display port) first, then adding display port support a bit later when more DP monitors were available on the market.

We're starting to organize the DP programming information now -- the changes are pretty big -- but for the short term I want us to stay focused on 3d a bit longer.

[lucky_]

We're starting to organize the DP programming information now -- the changes are pretty big -- but for the short term I want us to stay focused on 3d a bit longer.

Sounds like a warmup for the FOSDEM's doc release, right ?

[werner]

Current plan is to add support in two stages -- existing functionality (ie without display port) first, then adding display port support a bit later when more DP monitors were available on the market.

We're starting to organize the DP programming information now -- the changes are pretty big -- but for the short term I want us to stay focused on 3d a bit longer.

THE MOST IMPORTANT IS - MOST FAST - TO PROVIDE DRIVERS - NO MATTER OF OPEN OR BINARY - WHAT ONE CAN COPY IN THE SAME DIRECTORY WHERE ARE ALL OTHER 3D -RENDERING DRIVERS OF MESA , SO THAT THEY CAN USED IMEDIATELY WITHIN xorg.conf FOR HAVE WORKING COMPIZ-FUSION, WITHOUT TO CHANGING OR RE-INSTALLING ANYTHING ON THE SYSTEM -- especially without the need to install extra openGL.so files which later give problems with mesa files with the same name. Or more exactly, should be delivered binary files such like r500_dri.so , r600_dri.so (or whatever name) to be copied into /usr/lib/xorg/modules.dri , without the need of any other change of the system than type this driver name into xorg.conf

I'm maintaining a distro - SYS - and I do not support any kind of privat drivers different than that.

I can only use my old computer with 3d / compiz-fusion what has a r300 driver for mesa and a 9650 radeon card, but i cannot use a newer one what has a X 1650 ATI/GCUBE grafic card: no open or binary 3d driver.

Next thing is, that the drivers should be independent on the kernel. I compile always my kernel meself, for my own server and for the distro; currently I'm using 2.6.24-rc6-git8 . With the mesa drivers, no problem. Also any private/binary driver should work with ANY new kernel

I buyed that ATI card because I expected that it's working. When things don't becoming better, this was the last time I buyed anything from ATI

[glisse]

THE MOST IMPORTANT IS - MOST FAST - TO PROVIDE DRIVERS - NO MATTER OF OPEN OR BINARY - WHAT ONE CAN COPY IN THE SAME DIRECTORY WHERE ARE ALL OTHER 3D -RENDERING DRIVERS OF MESA , SO THAT THEY CAN USED IMEDIATELY WITHIN xorg.conf FOR HAVE WORKING COMPIZ-FUSION, WITHOUT TO CHANGING OR RE-INSTALLING ANYTHING ON THE SYSTEM -- especially without the need to install extra openGL.so files which later give problems with mesa files with the same name. Or more exactly, should be delivered binary files such like r500_dri.so , r600_dri.so (or whatever name) to be copied into /usr/lib/xorg/modules.dri , without the need of any other change of the system than type this driver name into xorg.conf

I'm maintaining a distro - SYS - and I do not support any kind of privat drivers different than that.

I can only use my old computer with 3d / compiz-fusion what has a r300 driver for mesa and a 9650 radeon card, but i cannot use a newer one what has a X 1650 ATI/GCUBE grafic card: no open or binary 3d driver.

Next thing is, that the drivers should be independent on the kernel. I compile always my kernel meself, for my own server and for the distro; currently I'm using 2.6.24-rc6-git8 . With the mesa drivers, no problem. Also any private/binary driver should work with ANY new kernel

I buyed that ATI card because I expected that it's working. When things don't becoming better, this was the last time I buyed anything from ATI

If you understand that for having support of the lastest wifi card you need to compile a new kernel than you should understand that for having support of new graphic card you might need to rebuild xserver, drm, mesa, ...

Note that in the future the critical part of the driver might end up in kernel so you will need to rebuild lastest kernel to take advantage of hw (or distro will have to backport things for you).

The open source graphic stack does not boil down to the dri module each part need sometimes to be modified to support new features.