Hello.

Adrian Bunk wrote:

Sorry for the silly question, but are there serious usecases where people in very space limited environments and with CONFIG_INPUT=n want PC-Speaker support?

I don't know, but there might be someone who wants the PCM support from pc-speaker, and hates the beeps at the same time. So they can disable it forever. :) I also want to resolve the conflict with INPUT_PCSPKR somehow. Making the input part of snd-pcsp optional looks like the first step to me. It became known to me that loading multiple drivers for the same device will be possible in the future. I want to get everything ready for loading pcspkr and snd-pcsp together. And overall, having snd-pcsp to depend on CONFIG_INPUT only because it can do a console beeps as a bonus, looks ill- behaved to me. So I just propose that patch as a small logical correction and cleanup, rather than a new feature.

On Thu, May 08, 2008 at 10:25:49PM +0400, Stas Sergeev wrote:

Hello.

Adrian Bunk wrote:

...

Sorry for the silly question, but are there serious usecases where people in very space limited environments and with CONFIG_INPUT=n want PC-Speaker support?

Oh, I've just heard youre screaming "this all is not worth a new config option!". :)

Here's another patch instead. Without exporting a new option to the user this time. ... +config SND_PCSP_INPUT

• def_bool y
• depends on INPUT
• depends on SND_PCSP

...

The number of users with CONFIG_INPUT=n on a PC might be more or less zero (even more considering the fact that you have to set CONFIG_EMBEDDED=y for being able to disable INPUT) - your patch adds a few #ifdef's that don't have any effect in practice.

And your patches breaks the compilation with CONFIG_SND_PCSP=y, CONFIG_INPUT=m if anyone will ever try this combination.

The latter is not unfixable, and I might be very nitpicking here, but I do simply not see the point why we need this more complicated.

cu Adrian

On Fri, May 09, 2008 at 02:38:46AM +0400, Stas Sergeev wrote:

Hello.

Adrian Bunk wrote:

...

And your patches breaks the compilation with CONFIG_SND_PCSP=y, CONFIG_INPUT=m if anyone will ever try this combination.

OK, that's nasty indeed... Then I guess it is not a big deal to leave that dependancy as-is until the real need in changing it appear.

Btw, is there really no way at all to tell kconfig something like depends on INPUT if SND_PCSP_INPUT or similar?

There are different ways how you could express this in kconfig depending on what exactly would be intended.

But the stuff we already have in kconfig has enough problematic cornercases, and making anything more complicated IMHO requires a justification that there's a real need for it.

cu Adrian