Am Mon, 17 May 2010 08:23:15 -0600 schrieb Ignacio Galmarino <igalmarino@gmail.com>:

ATI KMS is not working. All i get is garbage on the screen.

x86_64

Ignacio

Works for me. Probably as useful as your report... -Andy

On 05/17/2010 08:10 PM, Andreas Radke wrote:

Am Mon, 17 May 2010 08:23:15 -0600 schrieb Ignacio Galmarino <igalmarino@gmail.com>:

...

ATI KMS is not working. All i get is garbage on the screen.

x86_64

Ignacio

Works for me. Probably as useful as your report...

-Andy

I have noticed that if I don't have radeon_ucode [1] installed then early or late KMS don't work and I get just a black screen. However I didn't wait 1 minute to check if after a while the boot process resumes. [1] http://aur.archlinux.org/packages.php?ID=33016 -- Mauro Santos

On 17/05/10 22:24, Mauro Santos wrote:

I have noticed that if I don't have radeon_ucode [1] installed then early or late KMS don't work and I get just a black screen. However I didn't wait 1 minute to check if after a while the boot process resumes.

[1] http://aur.archlinux.org/packages.php?ID=33016

My experience with an integrated Radeon HD 4200 card and KMS is similar. Without radeon_ucode, everything will work fine until I need to resume from suspend-to-ram. The screen will then just stay in standby mode for about a minute (a couple of seconds, give or take) before it'll come to life again. With either KMS disabled or radeon_ucode installed, this problem doesn't occur. It appears that, in my case, the card requests a firmware file named R600_rlc.bin which is included in radeon_ucode. If you google this file, you'll find several instances in which this file has been discussed. Some insightful discussion is here: http://lkml.org/lkml/2010/1/26/169. In particular, notice Alex's reply stating: --8<-------------------------------------------------------------------- In general, microcode is slowly being moved out of the kernel and into the Linux firmware tree: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree Eventually all of the radeon microcode will end up out up in that tree. --8<-------------------------------------------------------------------- I'm not sure what this means for our kernel26-firmware package, but I believe we would want to ship the files included in the "Linux firmware tree". What do you think? :)

On 18/05/10 17:28, Thomas Bächler wrote:

Am 18.05.2010 16:06, schrieb Evangelos Foutras:

...

In particular, notice Alex's reply stating:

--8<-------------------------------------------------------------------- In general, microcode is slowly being moved out of the kernel and into the Linux firmware tree: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree Eventually all of the radeon microcode will end up out up in that tree. --8<--------------------------------------------------------------------

I'm not sure what this means for our kernel26-firmware package, but I believe we would want to ship the files included in the "Linux firmware tree".

No, we don't. We want to and will ship all the firmware files that are included in the current Linux release (make install_firmware).

If the developers are not capable of ensuring that the driver and firmware versions in the Linux releases work together, that is a bug on their end. In this case, it seems they move code out of the radeon driver more quickly than into the firmware files - I am not willing to fix this screwup for them.

I see your point. It seems that upstream kernel developers don't wish to ship firmware files, which is... not ideal for downstream (e.g. Arch). However, these firmware files are needed for R600/R700/Evergreen cards [1], therefore I see two options: 1) radeon_ucode [2] can be brought to [extra] and an announcement added to the front page informing users about this. (The package should also be renamed to radeon-ucode in order for it to be consistent with the rest of the firmware packages.) 2) Alternately, the radeon firmware files could be included in the kernel26-firmware package. I like the first option better because it keeps things separate. ---- [1] http://wiki.x.org/wiki/radeonBuildHowTo#TroubleshootingExtraFirmwareforR600.... [2] http://aur.archlinux.org/packages.php?ID=33016

Am Tue, 18 May 2010 17:55:12 +0200 schrieb Thomas Bächler <thomas@archlinux.org>:

...

However, these firmware files are needed for R600/R700/Evergreen cards [1], therefore I see two options:

1) radeon_ucode [2] can be brought to [extra] and an announcement added to the front page informing users about this. (The package should also be renamed to radeon-ucode in order for it to be consistent with the rest of the firmware packages.)

This sounds like a good idea. This could even be included in core AND installed on the installation ISO. Andy, this seems like your area, what do you think?

The firmware belongs more to the kernel. At least I don't have a card to test it. If you want to bring it to the official repos go on. But I think it's not in the kernel for good reasons. Probably license issues. I haven't checked that. I don't see a problem keeping the firmware in AUR until the kernel guys pick it up. We could also add an optional dependency or post an install msg in the kernel pkg or radeon ddx pkg. Your choice. -Andy

On Tue, May 18, 2010 at 10:49 PM, Nezmer <arch@nezmer.info> wrote:

FYI, I had this discussion with the radeon guys months ago in IRC. Apparently, kernel guys (maybe Linus) decided to not add new firmware files to the kernel tree. That's why we have all those firmware packages for in-tree modules.

Depending on what direction the kernel guys have taken, there is another option worth considering. If firmware is now only added to a separate repository, namely linux-firmware.git [1], it probably wouldn't be a bad idea to switch our kernel firmware package to that [2]. Fedora has done something similar with their linux-firmware [3] package. Anyway, I'm not really sure what the best course of action is here. The above option does seem like a more general and future-proof solution to this kind of issues. As a bonus, it also covers several Intel wireless cards, thus making their respective -ucode packages [4] in [core] redundant. @Devs: The final decision is yours. :) [1] http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=summary [2] http://www.kernel.org/pub/linux/kernel/people/dwmw2/firmware/ [3] http://cvs.fedoraproject.org/viewvc/rpms/linux-firmware/ [4] http://www.archlinux.org/packages/?q=-ucode

Am 19.05.2010 00:47, schrieb Thomas Bächler:

Am 18.05.2010 21:49, schrieb Nezmer:

...

FYI, I had this discussion with the radeon guys months ago in IRC. Apparently, kernel guys (maybe Linus) decided to not add new firmware files to the kernel tree. That's why we have all those firmware packages for in-tree modules.

So, they ship firmware files with the kernel, but only SOME firmware files? And arbitrarily, others are not being shipped? In particular, old ones are shipped, and new ones aren't? This annoys me already - but before I start any discussion, I want to have a source for that. It might be time to annoy the lkml with this.

Okay, this is confusing. It seems that linux-firmware is a superset of the firmware in kernel26 and includes lots of files, including the intel iwlwifi firmware and the ralink firmware. This file lacks some conflicts/provides, but you should be able to install it instead of kernel26-firmware. http://dev.archlinux.org/~thomas/linux-firmware-git-20100519-1-any.pkg.tar.x... Let me know what you think. Also, there have been some reports about missing ralink firmware files, those might be in here as well.

Am 19.05.2010 10:56, schrieb Evangelos Foutras:

Also did a diff [1] between the file lists of kernel26-firmware-2.6.34-1 and linux-firmware-git-20100519-1. It shows that ralink firmware has indeed been added to the linux-firmware repository, which should resolve FS#19519 [2].

I did that too and noticed the same. It would also replace all intel ucode packages, and some more I don't know about. However, it is considerably bigger than kernel26-firmware (2MB vs. 12MB).

Am 19.05.2010 16:19, schrieb Dan McGee:

On Wed, May 19, 2010 at 6:10 AM, Thomas Bächler <thomas@archlinux.org> wrote:

...

Am 19.05.2010 10:56, schrieb Evangelos Foutras:

...

Also did a diff [1] between the file lists of kernel26-firmware-2.6.34-1 and linux-firmware-git-20100519-1. It shows that ralink firmware has indeed been added to the linux-firmware repository, which should resolve FS#19519 [2].

I did that too and noticed the same. It would also replace all intel ucode packages, and some more I don't know about. However, it is considerably bigger than kernel26-firmware (2MB vs. 12MB).

How often does it need to be updated? We now (needlessly?) have the firmware package track the actual kernel package so it ends up getting re-downloaded a lot more often than probably necessary, so the above package, while large, would probably be updated less anyway (and would be an 'any' package?).

Everytime someone complains about a firmware file missing. Seriously, look at the commit log, it only had 23 commits this year: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=summary I guess we would upgrade it at most once a month.

On Wed, May 19, 2010 at 9:43 AM, Jan de Groot <jan@jgc.homeip.net> wrote:

On Wed, 2010-05-19 at 16:39 +0200, Thomas Bächler wrote:

...

Am 19.05.2010 16:19, schrieb Dan McGee:

...

On Wed, May 19, 2010 at 6:10 AM, Thomas Bächler <thomas@archlinux.org> wrote:

...

Am 19.05.2010 10:56, schrieb Evangelos Foutras:

...

Also did a diff [1] between the file lists of kernel26-firmware-2.6.34-1 and linux-firmware-git-20100519-1. It shows that ralink firmware has indeed been added to the linux-firmware repository, which should resolve FS#19519 [2].

I did that too and noticed the same. It would also replace all intel ucode packages, and some more I don't know about. However, it is considerably bigger than kernel26-firmware (2MB vs. 12MB).

How often does it need to be updated? We now (needlessly?) have the firmware package track the actual kernel package so it ends up getting re-downloaded a lot more often than probably necessary, so the above package, while large, would probably be updated less anyway (and would be an 'any' package?).

Everytime someone complains about a firmware file missing.

Seriously, look at the commit log, it only had 23 commits this year: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=summary

I guess we would upgrade it at most once a month.

+1 for replacing all firmware packages included in this one. I don't care about the few extra megabytes on my system. This saves us uploading and downloading a binary firmware package on every kernel update, generates less packages in the repositories and moves kernel26-firmware to an arch=any package. The only disadvantage is the 10MB extra size, but the advantages are bigger than that.

yes i agree too. kernel is big already with oodles of modules enabled by default to satisfy everyone, whats a few more MB to ensure that things like KMS (nearly commonplace) and friends work smoothly. there isn't a simple way (or reason) to needlessly break them [firmware] out into individual packages, as there isn't a way to effectively depend on the package (would have to start breaking out modules themselves into packages, no?, in order to build the dep tree?) C Anthony

* Ignacio Galmarino <igalmarino@gmail.com> [17.05.2010 16:23]:

ATI KMS is not working. All i get is garbage on the screen.

x86_64

Ignacio

ATI KMS is working fine here on i686 with radeon % lspci | grep ATI 01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] But I'll check dmesg if there are any critical lines