Clemens,
Thanks for your quick reply.
When a control panel wants to change several settings, it should not need to establish a CMP connection just to be able to prevent the driver from starting streaming at the same time.
There is no need to establish connection. The control panel just check the value of "peer-to-peer connection counter" field in iPCR/oPCR.
But anyway, it's better to give an easy way via the interface. I agree.
When this is possible, the kernel FireWire framework should be extended to allow the driver to prevent FFADO from using the device. However, it would be hard for the kernel to differentiate between FFADO and some control panel, so I guess FFADO should be changed to not attach to a device that already has a kernel driver.
I'm not a developer for Juju so cannot have any idea for kernel land at all. But for FFADO, I can put your idea as my future commitment.
For Fireworks devices, applications will need to send EFC commands, but will not be able to allocate the same 0xecc080000000 address, so the driver needs a SEND_EFC ioctl. (That's the same reason why snd-dice has DICE_NOTIFICATION.)
Now I understand the reason DICE_NOTIFICATION exists. Dice also have the similar issue as Fireworks has. For EFC, I'm willing to keep FFADO using "EFC over AVC" but I found this is not enough for some models with latest firmware.
Well, you said "The primary purpose is to support control panel/mixer". But this interface can also be good for prevention of conflict with FFADO driver. I wonder why you mention this first. Are there any thoughts?
Thanks
Takashi Sakamoto