I just found out that El Pelón, my favorite taquería (outside of Mexico, anyway), burnt down. I used to eat there a lot, when I worked in the Ximian office in the Fenway.

(There's more info on some livejournal community page, but they ruined it by adding a lolcat image. I won't link to it. Lolcats are not funny.)

Oh well. I be extra sure, now, to not miss another of my old haunts in Boston, Pino's.

Mouse, I bought a christmas calendar. The de luxe version with huge pieces of chocolate. And we had the first Glühwein yesterday. That was before we went to the Irish pub and had some chowder and that was before we went to the other Irish pub with the jam session and the Irish flag. And that was before we staggered home. And now I have this song in my head and can't get rid of it. Must have been the last song they played yesterday.

Got news from mouse. He's hooked on Reese's Peanut Buttercups. They give him so much strength that he fights all the cats in the area. He's only afraid of the whirlpool, the sissy :-).

Packaging Day has started. Be there or else!

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.

Last Monday I submitted lot of changes into Strigi’s trunk. I’ve heavily refactored some classes in order to obtain a more flexible file system notification infrastructure. Thanks to this work now it will be easier to add support for new file system notification facilities. For example, in order to add File Alteration Monitor (aka FAM) support I had to write only 576 loc (including license and documentation stuff).

So, by now, Strigi supports the following file system monitoring facilities:

• polling: used when nothing else is available
• inotify: available only on linux platform with kernel >= 2.6.13
• FAM: available on most of the *nix systems, I recommend to use Gamin instead of FAM (most linux distributions already use it by default)

Mouse is gone. He's in the US now, provided they let him in. I said good-bye to him on the historical Christmas market and refused to buy him a sword. Then I was free to walk the city. Peace and quiet (yes!) There was a big crowd and loud music. In the middle of the crowd there was a bear with a string puppet mouse which was dancing like hell. That would be the perfect job for me. Running around in a costume and having mouse on strings. We would collect money and chocolate from the audience. The perfect life.

Mouse speaking. No pizza place, but pub instead. Without me. She is afraid that I'll go to Australia again. She told me something about Samba and Sambuca. And monsters. I couldn't follow her. It was one of those rare nights when she speaks too much. I was lucky that she forgot me at home. Today is my last chance to get into the big suitcase to the US and Australia. Then you won't hear from me for a while.