ALSA: scarlett2: Default on?
On Wed, Jun 23, 2021 at 08:39:24AM +0200, Takashi Iwai wrote: [...]
OK, now all patches have been merged.
Thanks!
I would next like to consider how we can enable this mixer driver by default. I originally added the device_setup=1 gate because there were reports of the driver making the interface hang. These were all traced back to the problem which was resolved with the commit "Fix device hang with ehci-pci". That commit fixed the issue for those who had reported it and since then there have been no more reports that the mixer driver causes any issues.
Simply removing the device_setup=1 check would leave users with no way to disable the driver in case that turns out to be necessary for some reason though, so I don't think that's a good idea.
What I think would be the best option would be to have the driver as its own loadable module. Does this sound like a good idea to you?
Thanks, Geoffrey.
On Thu, 24 Jun 2021 17:47:39 +0200, Geoffrey D. Bennett wrote:
On Wed, Jun 23, 2021 at 08:39:24AM +0200, Takashi Iwai wrote: [...]
OK, now all patches have been merged.
Thanks!
I would next like to consider how we can enable this mixer driver by default. I originally added the device_setup=1 gate because there were reports of the driver making the interface hang. These were all traced back to the problem which was resolved with the commit "Fix device hang with ehci-pci". That commit fixed the issue for those who had reported it and since then there have been no more reports that the mixer driver causes any issues.
Simply removing the device_setup=1 check would leave users with no way to disable the driver in case that turns out to be necessary for some reason though, so I don't think that's a good idea.
They can blacklist snd-usb-audio, either the module itself (if it's the only device), or with enable option of snd-usb-audio module, if there are multiple devices bound with the driver.
What I think would be the best option would be to have the driver as its own loadable module. Does this sound like a good idea to you?
I'm not against splitting, but that is no solution at all, per se.
Takashi
On Thu, Jun 24, 2021 at 07:40:53PM +0200, Takashi Iwai wrote:
On Thu, 24 Jun 2021 17:47:39 +0200, Geoffrey D. Bennett wrote:
On Wed, Jun 23, 2021 at 08:39:24AM +0200, Takashi Iwai wrote: [...]
OK, now all patches have been merged.
Thanks!
I would next like to consider how we can enable this mixer driver by default. I originally added the device_setup=1 gate because there were reports of the driver making the interface hang. These were all traced back to the problem which was resolved with the commit "Fix device hang with ehci-pci". That commit fixed the issue for those who had reported it and since then there have been no more reports that the mixer driver causes any issues.
Simply removing the device_setup=1 check would leave users with no way to disable the driver in case that turns out to be necessary for some reason though, so I don't think that's a good idea.
They can blacklist snd-usb-audio, either the module itself (if it's the only device), or with enable option of snd-usb-audio module, if there are multiple devices bound with the driver.
But wouldn't that disable audio for the device entirely? I am talking about only disabling the mixer part of the driver (the code in mixer_scarlett_gen2.c) which uses the proprietary USB messages. So that if there is some unseen so-far bug the user can revert to previous behaviour of audio working but no proprietary controls.
What I think would be the best option would be to have the driver as its own loadable module. Does this sound like a good idea to you?
I'm not against splitting, but that is no solution at all, per se.
Takashi
On Fri, 25 Jun 2021 04:11:42 +0200, Geoffrey D. Bennett wrote:
On Thu, Jun 24, 2021 at 07:40:53PM +0200, Takashi Iwai wrote:
On Thu, 24 Jun 2021 17:47:39 +0200, Geoffrey D. Bennett wrote:
On Wed, Jun 23, 2021 at 08:39:24AM +0200, Takashi Iwai wrote: [...]
OK, now all patches have been merged.
Thanks!
I would next like to consider how we can enable this mixer driver by default. I originally added the device_setup=1 gate because there were reports of the driver making the interface hang. These were all traced back to the problem which was resolved with the commit "Fix device hang with ehci-pci". That commit fixed the issue for those who had reported it and since then there have been no more reports that the mixer driver causes any issues.
Simply removing the device_setup=1 check would leave users with no way to disable the driver in case that turns out to be necessary for some reason though, so I don't think that's a good idea.
They can blacklist snd-usb-audio, either the module itself (if it's the only device), or with enable option of snd-usb-audio module, if there are multiple devices bound with the driver.
But wouldn't that disable audio for the device entirely? I am talking about only disabling the mixer part of the driver (the code in mixer_scarlett_gen2.c) which uses the proprietary USB messages. So that if there is some unseen so-far bug the user can revert to previous behaviour of audio working but no proprietary controls.
Even if you split the mixer part to a module, it'll be always bound with the main snd-usb-audio due to dependency, so you cannot blacklist it. At most, you may add a module option for that, but it's almost equivalent to introduce a new option to snd-usb-audio such as snd_usb_audio.scarlett2_mixer=off
A conditional build would make sense for the compilation size, but it's not about the feature to turn on/off functionality on the fly.
Takashi
participants (2)
-
Geoffrey D. Bennett -
Takashi Iwai