[alsa-devel] Merging alsa-firmware into linux-firmware
Hi,
Chase Douglas (@canonical) and I plan to take what's left of alsa-firmware and try to merge it into linux-firmware, this might happen now or in the coming weeks. This will make alsa-firmware obsolete as all firmware will be provided by linux-firmware instead.
Any words of disagreement, warnings or encouragement before we do so?
-- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
On Tue, 2010-07-20 at 11:38 +0100, David Henningsson wrote:
Hi,
Chase Douglas (@canonical) and I plan to take what's left of alsa-firmware and try to merge it into linux-firmware, this might happen now or in the coming weeks. This will make alsa-firmware obsolete as all firmware will be provided by linux-firmware instead.
Any words of disagreement, warnings or encouragement before we do so?
Encouragement, certainly...
On 2010-07-20 12:51, David Woodhouse wrote:
On Tue, 2010-07-20 at 11:38 +0100, David Henningsson wrote:
Hi,
Chase Douglas (@canonical) and I plan to take what's left of alsa-firmware and try to merge it into linux-firmware, this might happen now or in the coming weeks. This will make alsa-firmware obsolete as all firmware will be provided by linux-firmware instead.
Any words of disagreement, warnings or encouragement before we do so?
Encouragement, certainly...
Great!
There are a few firmwares (e g echoaudio and hdsploader) that actually are .c files with a big constant array in it, like this:
static u_int32_t digiface_firmware[24413] = { 0xffffffff, 0x66aa9955, 0x8001000c, 0xe0000000, 0x8006800c, 0xb0000000, 0x8004800c, 0xb4fc0100, 0x8003000c, 0x00000000, 0x8001000c, 0x90000000, ...etc...
Would you prefer the actual .c files in the linux-firmware git tree source (and the makefile that goes with it), or just the output from them (the binary firmware files)?
On Wed, 2010-07-21 at 11:29 +0200, David Henningsson wrote:
On 2010-07-20 12:51, David Woodhouse wrote:
On Tue, 2010-07-20 at 11:38 +0100, David Henningsson wrote:
Hi,
Chase Douglas (@canonical) and I plan to take what's left of alsa-firmware and try to merge it into linux-firmware, this might happen now or in the coming weeks. This will make alsa-firmware obsolete as all firmware will be provided by linux-firmware instead.
Any words of disagreement, warnings or encouragement before we do so?
Encouragement, certainly...
Great!
There are a few firmwares (e g echoaudio and hdsploader) that actually are .c files with a big constant array in it, like this:
static u_int32_t digiface_firmware[24413] = { 0xffffffff, 0x66aa9955, 0x8001000c, 0xe0000000, 0x8006800c, 0xb0000000, 0x8004800c, 0xb4fc0100, 0x8003000c, 0x00000000, 0x8001000c, 0x90000000, ...etc...
Would you prefer the actual .c files in the linux-firmware git tree source (and the makefile that goes with it), or just the output from them (the binary firmware files)?
If it's just a big constant array, you might as well just give me the binary. If there's *real* source, we'd want that too.
2010-07-20 12:51, David Woodhouse skrev:
On Tue, 2010-07-20 at 11:38 +0100, David Henningsson wrote:
Hi,
Chase Douglas (@canonical) and I plan to take what's left of alsa-firmware and try to merge it into linux-firmware, this might happen now or in the coming weeks. This will make alsa-firmware obsolete as all firmware will be provided by linux-firmware instead.
Any words of disagreement, warnings or encouragement before we do so?
Encouragement, certainly...
Okay, so now there's a preliminary version up for review here: git://kernel.ubuntu.com/diwic/linux-firmware.git, alsa-merge branch.
Feel free to either merge it if you think it's okay, or if it needs adjustments, let me know (or fix them yourself, whatever is simplest...).
Note that once this one's through, we should adjust alsa-tools for usx2y to point to /lib/firmware/usx2y and nothing else.
At Mon, 26 Jul 2010 10:15:10 +0200, David Henningsson wrote:
2010-07-20 12:51, David Woodhouse skrev:
On Tue, 2010-07-20 at 11:38 +0100, David Henningsson wrote:
Hi,
Chase Douglas (@canonical) and I plan to take what's left of alsa-firmware and try to merge it into linux-firmware, this might happen now or in the coming weeks. This will make alsa-firmware obsolete as all firmware will be provided by linux-firmware instead.
Any words of disagreement, warnings or encouragement before we do so?
Encouragement, certainly...
Okay, so now there's a preliminary version up for review here: git://kernel.ubuntu.com/diwic/linux-firmware.git, alsa-merge branch.
Feel free to either merge it if you think it's okay, or if it needs adjustments, let me know (or fix them yourself, whatever is simplest...).
Note that once this one's through, we should adjust alsa-tools for usx2y to point to /lib/firmware/usx2y and nothing else.
This is a regression. It should check both paths if the path is changed.
Takashi
David Henningsson wrote:
Chase Douglas (@canonical) and I plan to take what's left of alsa-firmware and try to merge it into linux-firmware, this might happen now or in the coming weeks. This will make alsa-firmware obsolete as all firmware will be provided by linux-firmware instead.
Good idea; these packages have exactly the same purpose.
Any words of ... warnings
I wonder what you're going to do about the multisound firmware files; the /lib/firmware/turtlebeach/*.bin files are just symbolic links to the actual files in /etc/sound that owners of these cards (if any such still exist) are supposed to have.
The stuff in emi_26_62 isn't used. (Er, wasn't there a regression introduced in the emi62 firmware in 2.6.27?)
Regards, Clemens
On 2010-07-20 15:31, Clemens Ladisch wrote:
David Henningsson wrote:
Chase Douglas (@canonical) and I plan to take what's left of alsa-firmware and try to merge it into linux-firmware, this might happen now or in the coming weeks. This will make alsa-firmware obsolete as all firmware will be provided by linux-firmware instead.
Good idea; these packages have exactly the same purpose.
Any words of ... warnings
I wonder what you're going to do about the multisound firmware files; the /lib/firmware/turtlebeach/*.bin files are just symbolic links to the actual files in /etc/sound that owners of these cards (if any such still exist) are supposed to have.
Ah, thanks for bringing this up to my attention. From where do these .bin-files come originally? Can we include them?
The stuff in emi_26_62 isn't used. (Er, wasn't there a regression introduced in the emi62 firmware in 2.6.27?)
I noticed that linux-firmware had one emi26 and one emi62 directory, as opposed to alsa-firmware that puts it in the emagic directory. So given your comment, I'll just drop them from the emagic dir.
David Henningsson wrote:
On 2010-07-20 15:31, Clemens Ladisch wrote:
I wonder what you're going to do about the multisound firmware files; the /lib/firmware/turtlebeach/*.bin files are just symbolic links to the actual files in /etc/sound that owners of these cards (if any such still exist) are supposed to have.
Ah, thanks for bringing this up to my attention. From where do these .bin-files come originally?
I don't know more than what Documentation/sound/oss/MultiSound says. The download links in there are, of course, broken; with Google, I've found msndvkit.zip but not pnddk100.zip.
Can we include them?
| This developer's kit does not provide you with a license to distribute | any of the contained software, including, but not limited to | DSPCODE.OBJ, MCONTROL.C. Developers wishing to use these in specific | applications can do so by requesting and returning the "MultiSound DSP | OEM Licensing Agreement". | | Turtle Beach's policy on redistribution is simple. For a license fee | of $1, we allow developers to distribute the above code modules along | with their products, provided that MultiSound hardware is included in | the target product. Since DSP_CODE.OBJ only works with MultiSound | hardware, this is the only logical use of the code.
Try asking Turtle Beach.
(Er, wasn't there a regression introduced in the emi62 firmware in 2.6.27?)
http://xiphmont.livejournal.com/46858.html
Regards, Clemens
On 2010-07-21 08:53, Clemens Ladisch wrote:
David Henningsson wrote:
On 2010-07-20 15:31, Clemens Ladisch wrote:
I wonder what you're going to do about the multisound firmware files; the /lib/firmware/turtlebeach/*.bin files are just symbolic links to the actual files in /etc/sound that owners of these cards (if any such still exist) are supposed to have.
Ah, thanks for bringing this up to my attention. From where do these .bin-files come originally?
I don't know more than what Documentation/sound/oss/MultiSound says. The download links in there are, of course, broken; with Google, I've found msndvkit.zip but not pnddk100.zip.
Can we include them?
| This developer's kit does not provide you with a license to distribute | any of the contained software, including, but not limited to | DSPCODE.OBJ, MCONTROL.C. Developers wishing to use these in specific | applications can do so by requesting and returning the "MultiSound DSP | OEM Licensing Agreement". | | Turtle Beach's policy on redistribution is simple. For a license fee | of $1, we allow developers to distribute the above code modules along | with their products, provided that MultiSound hardware is included in | the target product. Since DSP_CODE.OBJ only works with MultiSound | hardware, this is the only logical use of the code.
Try asking Turtle Beach.
Right. I'll leave them out for now (i e I'll not merge them) for the following reasons:
1) The people having these files could just put them in /lib/firmware instead of in /etc/sound
2) The symlinks never worked on Medibuntu, and Medibuntu got no bugs about that, so probably noone out there uses the firmware anyway. ;-)
(Er, wasn't there a regression introduced in the emi62 firmware in 2.6.27?)
The emi26/emi62 firmware already exists in linux-firmware, so I won't merge them either (and that patch in the link is against linux-firmware and not alsa-firmware).
On Wed, 2010-07-21 at 14:31 +0100, David Henningsson wrote:
The emi26/emi62 firmware already exists in linux-firmware, so I won't merge them either (and that patch in the link is against linux-firmware and not alsa-firmware).
I think the *wrong* version is in linux-firmware. But nobody ever offered a patch to fix that (only a kernel source patch).
On 2010-07-21 16:02, David Woodhouse wrote:
On Wed, 2010-07-21 at 14:31 +0100, David Henningsson wrote:
The emi26/emi62 firmware already exists in linux-firmware, so I won't merge them either (and that patch in the link is against linux-firmware and not alsa-firmware).
I think the *wrong* version is in linux-firmware.
But the alsa-firmware package currently puts the firmware into the emagic/ directory, which AFAIK is not used at all by the current kernel.
But nobody ever offered a patch to fix that (only a kernel source patch).
I think the link Clemens just posted goes to such a patch.
At Tue, 20 Jul 2010 12:38:01 +0200, David Henningsson wrote:
Hi,
Chase Douglas (@canonical) and I plan to take what's left of alsa-firmware and try to merge it into linux-firmware, this might happen now or in the coming weeks. This will make alsa-firmware obsolete as all firmware will be provided by linux-firmware instead.
Any words of disagreement, warnings or encouragement before we do so?
Please go ahead. I wanted to do it in this or next week anyway :)
But grab the very latest alsa-firmware from git tree. There was an update of asihpi firmwares.
We'll likely keep alsa-firmware as the "upstream", since it also provides the file installation for 2.2 / 2.4 kernels. But, once when files are merged to linux-firmware, we'll eventually forward any changes in future to linux-firmware tree to sync.
thanks,
Takashi
Okay, I think I got most of it sorted out:
emi_26_62 / emagic korg1212 / korg maestro3 / ess sb16 / sb16 wavefront / yamaha ymfpci / yamaha ...are already in linux-firmware so they won't be merged.
multisound / turtlebeach symlinks won't be merged for the time being, since the original firmware isn't easily accessible.
usx2yloader however seems to put files outside the /lib/firmware path (/usr/share/alsa/...), and I believe it has a userspace firmware loader triggered by an udev event. I'll put it into /lib/firmware/tascam or something like that, but we need to update the loader as well to use the new path.
The rest should merge without trouble.
On 2010-07-20 12:38, David Henningsson wrote:
Hi,
Chase Douglas (@canonical) and I plan to take what's left of alsa-firmware and try to merge it into linux-firmware, this might happen now or in the coming weeks. This will make alsa-firmware obsolete as all firmware will be provided by linux-firmware instead.
Any words of disagreement, warnings or encouragement before we do so?
-- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic
At Thu, 22 Jul 2010 12:07:33 +0200, David Henningsson wrote:
Okay, I think I got most of it sorted out:
emi_26_62 / emagic korg1212 / korg maestro3 / ess sb16 / sb16 wavefront / yamaha ymfpci / yamaha ...are already in linux-firmware so they won't be merged.
multisound / turtlebeach symlinks won't be merged for the time being, since the original firmware isn't easily accessible.
usx2yloader however seems to put files outside the /lib/firmware path (/usr/share/alsa/...), and I believe it has a userspace firmware loader triggered by an udev event.
These are basically for 2.2 / 2.4 kernels. Don't touch them unless you are 100% sure you do right :)
Takashi
On 2010-07-22 13:20, Takashi Iwai wrote:
At Thu, 22 Jul 2010 12:07:33 +0200, David Henningsson wrote:
usx2yloader however seems to put files outside the /lib/firmware path (/usr/share/alsa/...), and I believe it has a userspace firmware loader triggered by an udev event.
These are basically for 2.2 / 2.4 kernels. Don't touch them unless you are 100% sure you do right :)
Assuming you mean the tascam usx2yloader, a little digging shows that,
1) the usx2y driver never calls request_firmware (unless I really missed something)
2) there is an Ubuntu specific patch which creates an udev rule for calling tascam_fw and tascam_fpga (from alsa-tools) when a tascam device is connected.
Are you saying that the tascam devices (us122, us224, us428) no longer need that firmware?
At Thu, 22 Jul 2010 14:41:20 +0200, David Henningsson wrote:
On 2010-07-22 13:20, Takashi Iwai wrote:
At Thu, 22 Jul 2010 12:07:33 +0200, David Henningsson wrote:
usx2yloader however seems to put files outside the /lib/firmware path (/usr/share/alsa/...), and I believe it has a userspace firmware loader triggered by an udev event.
These are basically for 2.2 / 2.4 kernels. Don't touch them unless you are 100% sure you do right :)
Assuming you mean the tascam usx2yloader, a little digging shows that,
Ah, OK, I was somehow confused about hdsploader & co installing to different paths. About usx2y stuff, it's like what you wrote below.
- the usx2y driver never calls request_firmware (unless I really missed
something)
- there is an Ubuntu specific patch which creates an udev rule for
calling tascam_fw and tascam_fpga (from alsa-tools) when a tascam device is connected.
Are you saying that the tascam devices (us122, us224, us428) no longer need that firmware?
They need the firmware files.
Takashi
participants (4)
-
Clemens Ladisch -
David Henningsson -
David Woodhouse -
Takashi Iwai