Egbert Eich

Hah, it's out - now it is official!
libv has been talking about it for ages already, but yesterday I now made the official announcement: XDC2012 - read the X.Org developers conference 2012 - will take place in Nuernberg (Germany) from September 19 through 21 and will be hosted at the company headquarters of SUSE at Maxfeldstrasse 5.
Please also check out the official announcement.
XDC takes place once a year, traditionally altering between locations in North America and Europe. It's a technical conference where people involved in technologies around the graphics stack on Open Source operating systems (like Mesa3D, Wayland, DRM, the X Window System ...) meet and discuss future plans and directions.
As a note on the side: When there were still two events each year, to distinguish both events the one taking place in North America was named XDC while the one held in Europe was called XDS. Those names stuck even when X.Org switched to one event per year. Now we decided to drop this distinction and named the European event XDC. 
The X.Org Foundation Board decided for Nuernberg last December already, it took a while until we found a date where both a suitable venue and accommodations are available (Nuernberg hosts quite a few major trade fairs, and right after the vacation season it's quite busy there).
SUSE is sponsoring the conference by providing its main meeting room including infrastructure to us free of charge. This venue is  just a few minutes away from the city center, hotels are in walking distance - the preferred conference hotel which will give us a special rate (which is still under negotiation) is just 5 minutes away from the venue.
Nuernberg is one of a few towns whose medieval city walls have not been destroyed in the 19th century and thus are still almost fully in place. Its castle and its historic inner city is just a few minutes away from the venue and definitely worth a visit. The city center offers many opportunities for after conference activities: you will also find quite many places (restaurants, pubs, bars) to gather and have conversations with others. Thus everything should be in place for a great conference.
This year marks a special occasion as on September 15th we will be celebrating the 25th anniversary of version 11 of the X Window System. (if you are wondering now how long X has been around if version 11 has now existed for 25 years now - the first 10 versions were released between May 1984 and December 1986 -  you may want to check out the excellent history on Wikipedia.
To celebrate this we will organize a beer hiking trip thru the scenic "Fränkische Schweiz" the Franconian countryside on the day after the conference where we will stop at several local brewery beer gardens. People will have the opportunity to sample a wide selection of good Franconian beers there.
Thus if you'd like to come, or even have something to present, please register! You will find details on the announcement page.

Support for the RV770 chipsets has now been added to the GIT master
branch of xf86-video-radeonhd at freedesktop.org.
So far this support has only been available in the AtomBIOS branch.
Now some investigations have unveiled that the display engine blocks
have not changed since RV620/RV635. Therefore AtomBIOS is not a strikt
prerequisite to get the latest AMD/ATI hardware to work.
Some bits to get RV770 to work have been cherry picked from the
'atombios-support' branch. These involved mainly memory controller
register programming and some small fixes to the I2C code.
Thus it was possible to provide support for this new hardware generation
without having to wait for the AtomBIOS support branch to be ready for
merging into the master branch.
Some word on the atombios_support branch: Most of the work on that
branch has been finished so that this branch will be merged into
master after some further testing and once some cleanup has taken
place.
We have been asked to provide AtomBIOS support for the RadeonHD
driver to speed up the driver bring up for future generations of
graphics hardware. It relieves ATI of the burden to have register
specification available at the time of release of new graphics hardware
and thus allow it to focus on the publication of documentation for
3D programming.

It's been a while since the last release of the RadeonHD driver.

Since then this driver has made a lot of progress:

• Support for RV620/RV635 was added. This latest generation of ATI hardware has completely revised digital blocks to  provide support for DisplayPort - a new VESA interface standard for digital displays . DisplayPort itself isn't supported yet due to the lack of hardware.
• 2D acceleration for R5xx and RS6xx have been added.
• The driver can now light up the second digital output on RS690. ATI had introduced a new digital block which so far has only shown up on RS6xx hardware. We discovered the existence of this block was only recently.
•  Support for interlaced modes was added. This is currently still disabled for digital outputs (mainly due to lack of testing) but once available it should allow to support more modes on HDTVs.
•  Some feature I have already almost have forgotten about  since it's been so long ago: We initialize secondary graphics cards using AtomBIOS.
• A huge number of bugs got fixed.

All this adds up to 9klocs of C.

A lot of distros have picked up the last release of this driver.
To give their users the benefit of these new features we today have released version 1.2.0 of the RadeonHD driver.

There are other things just right around the corner:

• RS780 support is almost ready, we are just waiting for a missing piece of information form ATI.
• Krisztian Loki provided a patch for backlight control on panels.
  
• TVout support: A lot of pieces required for this have been added already. I just need to get around to finish  it.
•  Work on DRI support is in progress.
• Once DRI support is available Xv and enhanced EXA support is not far.

 

Hurray!!! RV620/635 support is finally out!

A lot of people have been asking why there were so few commits
lately. People have been wondering if we were working on something
big.

Indeed we were:
Mode setting-wise RV620/635 ment the biggest change in subsystems
since R5xx: All outputs blocks have changed to allow for support
of Displayport.
The Displayport support is still missing as we are both lacking
hardware and programming information.

The digital outputs have been split up into an encoder and a
transmitter block which is now reflected in our programming model.
Furthermore the pixel clock PLL had been reworked completely.

We got hardware for testing as early as December 2007 however most
of the relevant documentation needed to code this has only been
received over the past four weeks.

Along with this support for dual link DVI has been added which is
still completely untested (due to lack of hardware).

So, even if you don't use any RV620/RV635 hardware,  please get it
and give it a try! We are awaiting your feedback...

The first release of the ATI RadeonHD driver is out!

Well, we did it! - We have just released xf86-video-radeonhd-1.0.0.

Sources can be found here.
More information can be found on the official radeonhd wiki.

The RadeonHD developers made the source code available to the public on September 18th (CET).
Since then a lot of people have picked up the code from the source code repository built and tested it. Some even packaged it for several popular Linux distributions and made those packages available.

A community of supporters, testers and developers have assembled around this driver. Various people have submitted code. Others are providing valuable testing feedback.

For graphics hardware this is probably needed more than for any other sort of hardware as graphics cards are shipped by a number of vendors which all provide their unique set of features to distinguish themselves from their competitors.

This release could have been done some weeks ago, but we were waiting to get feedback from users to fix problems and issues.
No driver will ever be completely free of issues and bugs of course but at least we could fix a number of things and make more users happy.

This driver supports:

• Full mode setting driver for ATI Radeon R5xx and R6xx capable of driving multiple monitors.
• Full RandR 1.2 support (with early RandR 1.3 property support).
• Full libpciaccess support.
• Supported subsystem:
  
• Outputs: DVI-A, DVI-D, DVI-I, VGA.
• Hardware cursor.
• I2C for DDC.
• Shadow framebuffer.
• AtomBIOS support for initialization, data tables.
• Backward compatibility to at least X.Org R6.9.
  

We would like our users and testers for all the valuable feedback we have received.
Also a special thank you goes to Hans Ulrich Niedermann (ndim) for thoroughly taking over build environment :)

Now there is some time to answer some questions that have been asked several times:

 Why do we do a separate driver?

We have been asked by many people why we have created a  separate module instead of extending the existing driver
for Radeon chipsets in the ATI driver for X.Org. There were several reasons:

•  Starting afresh gives the opportunity to cleanly. The Radeon driver has largely been rewritten for RandR 1.2 support but it supports a long list of chipset generations of which the earlier ones have not much in common with the latest one.
  There will always be some overlap in subsystems between chipset generations but one should think twice to use this argument to add more and more generations of chipsets to the same driver module.
• The step from R4xx to R5xx provided a good opportunity to start with a new driver module:
  The mode setting interface has changed with R5xx hardware compared to earlier hardware. As mentioned above the video overlay engine of earlier chipset generations is gone.
  The 2D and 3D engines are pretty much identical to earlier hardware. However 3D is only relevant to the extent as it is used for 2D acceleration in the X.Org driver anyway.
  Core components of the code for 2D acceleration could well be shared between the two drivers if this is desirable. 
  
• Libpciaccess should offer support to automatically identify and load the correct driver module using the PCI vendor and device IDs from the drivers - pretty much as done already in the kernel. Therefore having one driver module per hardware vendor to simplify configuration for the user is an argument that becomes pretty much irrelevant in the near future.
  I don't think we will be opposed to put the RadeonHD driver under a common umbrella with the other drivers for ATI hardware.
  There has been a wrapper that probes for the hardware and loads the appropriate module which may be interesting to use if libpciaccess doesn't perform this job already. This loader module needs some serious cleanup before though.
  

 When will feature XYZ arrive?

This mainly depends on the availability of documentation. ATI has made a tremendous job to prepare the documentation in a way that it can be released to the community without any strings attached (read no NDA required).
However this effort was driven largely by a single person at ATI - John Bridgman - who tirelessly worked to make this
initial release happen.
ATI has hired Alex Deucher - one of the leading developers of the free radeon driver - who will help to improve the information flow between ATI and he free software community.
We expect that ATI will release more information on hardware soon and the after processes for this have been fully established we will see documentation being released at a faster pace.

Here are some features people have been asking for:

•  2D acceleration (XAA/EXA). For R5xx this should be rather easy to implement as it is rather similar to earlier chipset generations and is actually on our TODO list.
  XAA will be required for backward compatibility. At least until the very recent Xserver releases EXA still had issues so it was not enabled by default.
• 3D support (DRI/DRM). Here again R5xx is not much different from earlier Radeon chipset generations thus support for this should be easy to do.
  This is not so much the concern of the X.Org driver as this is only involved in subsystem initialization.
• Video overlays
  Also video hardware overlay support as known in earlier hardware does not exist any more. In fact the video scaler is not available any more, only overlay support and some limited color space conversion is still available where the latter is rather irrelevant as these operations can be performed by modern CPUs at almost no cost.
  Full video overlay support requires some 3D support to perform the scaling of the video to the size of the window.
• TV Output.
  This is actually something what is on our todo list.
• Power management.
  This will require some more documentation also.
  

Why don't we make more use of AtomBIOS?

We are making extensive use of AtomBIOS data tables to obtain information on hardware details which are card specific. This has been very useful however we have already come across data tables which contained data which we believe does not correctly reflect the hardware situation on the card.
We use AtomBIOS code tables to initialize uninitialized hardware on secondary cards which are not POSTed at boot time.

For most hardware subsystem we are programming the hardware directly instead of using AtomBIOS code tables after having done a thorough analysis of the code tables involved.

• It is claimed that AtomBIOS code will provide support for new generations of hardware without the need to adapt the driver. This is true to some extent - however new generations of hardware may require an extension to the API of the table so the driver will still need to be fixed.
  Furthermore we have found several cases where the API of the AtomBIOS call tables has changed between different BIOS generations in a way not reflected in the header.
• We have found cases where code in the call tables contained bugs. We assume that AtomBIOS code has been tested to the extent the ATI Catalyst driver uses it. 
• Several call tables are not sufficiently atomic. Thus subsystems that should be treated independently cannot be handled this way.
  For instance SetPixelClock which programs the PLL parameters to the pixel clock also calls EnableCRTC. This functionality should clearly be left to the component handling the CRTC subsystem.
• AtomBIOS does not provide save/restore functionality. Since it is unknown which registers are touched by an AtomBIOS table it is hard to save and restore the text mode.
• Using AtomBIOS will probably work in the majority of cases but numerous users might run into problems which are hard to control as control over a released BIOS is very limited.
  Thus we expect that using AtomBIOS - although very compelling from a distance - may lead into a workaround nightmare.

Free Software driver for RadeonHD released

Last night we have pushed out the initial developers release of the RadeonHD driver for ATI's RADEON R5xx and R6xx chipsets. After a long dark period of no specifications AMD has decided to not only make code but also specifications available to the free software community.

So far we have seen specifications to do mode setting and possibly a little bit of video overlay. The specs cover most of what is needed to enable different outputs (VGA DAC, TMDA for DVI and LVDS for panels) TV out is not yet on the plate.
Also they allow to implement video overlays (classical color key overlays).

People are wondering if AMD's move was a one time PR blitz to muffle their biggest critics in the free software community.
My personal take on this is: I don't think so.
AMD has a long history of successful cooperation with the free software community. This cooperation was crucial for the success of their x86-64 project (we are only beginning to see versions of MS Windows appear which are 64bit capable).

In the past 4 month our X Developer Team at SUSE has worked extensively with AMD to make these things happen. We have only been dealing with people form AMD with technical background  - no marketing people were involved.
Everyone involved has shown a great willingness and worked hard during long hours to do whatever it takes to open up the
specs and provide whatever it takes to get a free driver going.

Yes, we did encounter delays. Most of them were due to fact that what has happened here is a novelty in the graphics chipset
industry. Tools had to be implemented, processes had to be created, legal issues had to be resolved.

How did it all start?

Around mid of April (4 1/2 month ago) I have been contacted by AMD and asked to put together a proposal how an open source driver for the latest generation of ATI hardware could become reality. Our team wrote a proposal which included as two major goals:

• involving the free software community in the development process early on  
• make chipset documentation available to the community with no strings (read NDA) attached.
  

Following this AMD and SUSE started talks about developing an initial driver to get the community process going. After the details were agreed upon we received the first set of documentation (then still under NDA) in late July and and have been hacking on this driver since then.

Linux Vendors

To most Linux OS vendors like us at SUSE the unavailability of  a free driver has created a huge burden. At SUSE we have made the conscious decision to not ship any non free software with out base product (even without this policy  in place the GPL violation issue in the kernel would have prevented us as an OS vendor to ship the proprietary driver with our base product).

This however meant we were not able to ship a proper driver for a widely used range of hardware with our product.

We at Novell as a company we worked extensively with ATI and later on with our partner AMD to explain the dilemma and find ways to change this situation. Most of these discussions have not taken place in the public eye. After all it be bad style if business partners gave each other advice in public on how to do business.

Why did it happen right now?

Changes in paradigms like what we have seen here don't happen over night. As for any commercial entity there needs to be some business justification as such steps require effort and thus cost money.
Business justifications evolve either when the business model of a company or the business environment changes.
Here both things have happened:

•  ATI has been purchased by AMD. AMD had a different business model in the Linux and free software market than ATI had.
• The business environment has changed: the b2b market (and this has been the market where conclusive data existed in terms of how much it is paying the bills) requires a free driver more than before.
  

The opportunity

To me AMD's move looks like a great opportunity. For the first time in many years graphics chipset documentation is made available to a broad public without the requirement of any NDA.

In fact I have a hard time to remember when I was able to download graphics chipset specs from a manufacturers web site without having to go through a pile of paper work.

AMD puts itself somewhat ahead of other graphics chipset vendors: In contrast to other free drivers for which only code but no documentation exists this approach allows a broad development community to poke bits and registers in crazy new ways to try out crazy things things that are not on the plate of those who are paying for the driver development.
Even if we won't see all results from these hacks appear immediately in the next release of the driver I expect it to kick off a lot of new development.
For a long time our community was somewhat cut off from the the information what state-of-the-art hardware was capable of. New features were limited to what hardware manufacturers - even those who developed free software drivers - considered to be a must-have for their drivers. This all is going to change now.