ATI Linux fglrx driver version 8.39.4
Release Date: 23 July, 2007
- The kernel module build no longer fails on kernel version 2.6.22. Further details can be found in topic number 737-28556
- Starting AMD CCC-LE no longer fails with a floating-point exception when started in certain configurations. Further details can be found in topic number 737-28557
- When playing videos in I420 color format using the Xv extension and TexturedVideo (the default on R5xx), colors are no longer displayed incorrectly. Further details can be found in topic number 737-28558
- Running aticonfig --initial in X with the Vesa driver no longer segfaults resulting in the xorg.conf file not being available. Further details can be found in topic number 737-28559
- Video Tearing may be seen during playback in XV using GLESX. Further details can be found in topic number 737-26984
- A black screen may be observed on some hardware when switching to the console or leaving the X window system when a Vesa framebuffer console driver is used. Further details can be found in topic number 737-28558
- Corruption may be observed with certain applications on some Linux distributions which enable the Composite extension by default, e.g., RHEL 5. If you are observing application corruption, please disable the Composite extension. Further details can be found in topic number 737-28224
- Using the xgl enabled x-server interface disables display switching hot plug support
- There is no support for video playback on the second head in dual head mode. Further details can be found in topic number 737-26985
Feature Wish List
The following features are still not supported properly by ATI's driver:
- Composite Extension: The ATI driver is far behind other open source Xorg drivers in supporting Composite extension. Clearly they are not keeping up and will benefit significantly by releasing their source code under GPL or BSD or MIT license.
- Removing the need to enable module support in the kernel to fully install the driver. It will work without it, but that doesn't enable DRI. This is possible by releasing their source code under the GPL license, and creating a patch for the kernel.
In about Time Perception by Edward Willett, the author talks about the foniwollg test:Dr. Anthony Chaston and Dr. Alan Kingstone of the University of Alberta's Department of Psychology gave subjects tests that required them to find specific items in various images. Before they began, they were told that once the test was over, they would be asked to estimate how long it took. In the simplest of the seven different levels of test, the items sought were a different colour than everything else, or hardly hidden at all. In the more difficult levels, the items were placed among many similar-looking items--or weren't even present. It showed something that most people are familiar with:The harder the search task, the smaller the estimate of how long the test had taken. In other words, the more engaged the mind on a task, the faster time seems to go by.I have lost track of time while being immersed in some heavy thinking. But this is an interesting observation. Because if an application keeps on engaging a user's brain even during a refresh of a screen or retrieval of information, the perceived time spent waiting will be lower than the actual time spent. I experience that myself with AJAX -based Web applications where a lot of the retrieval is done in the background and the applications keep the user engaged. These application just feel a lot quicker and they probable are not. Another interesting quote:... because people are generally better at predicting how long a task will take than estimating how long it took.I think this is directly relevant to the whole response times issue. The moment that people complain about the response time is when their estimation/expectation is not met. Fascinating mix of psychology and technology. Roland Stens firstname.lastname@example.org