On Mon, 19 Oct 2020 10:35:12 +0200
Udo van den Heuvel wrote:
> People,
>
> At https://www.kernel.org/doc/html/latest/leds/leds-class.html we can
> read that the LEDS code supposedly optimizes away when certain
> conditions are met.
> Especially the Realtek HDA driver *unconditionally* (as found
People,
At https://www.kernel.org/doc/html/latest/leds/leds-class.html we can
read that the LEDS code supposedly optimizes away when certain
conditions are met.
Especially the Realtek HDA driver *unconditionally* (as found in 5.9.1)
*wants* to enable LED functionality.
I.e.: if this blockade is li
On 10/13/20 9:29 PM, Udo van den Heuvel wrote:
>
>
> On 13-10-2020 18:03, Randy Dunlap wrote:
>> On 10/13/20 8:53 AM, Randy Dunlap wrote:
>>> [adding LED people + list]
>>>
>>> On 10/13/20 6:24 AM, Udo van den Heuvel wrote:
> (...)
> So how do I disable this stuff?
>
>>
>> I was able to d
On 10/13/20 9:56 PM, Udo van den Heuvel wrote:
> On 14-10-2020 06:49, Randy Dunlap wrote:
>> If you disable SND_HDA_CODEC_REALTEK, then the rest of the
>> LED kconfig symbols can be disabled.
>
> Sure,
>
> but:
>
> # dmesg|grep audi
> (...)
>
> [ 19.971537] snd_hda_codec_generic hdaudioC0D0:
On Wed 2020-10-14 10:34:21, Udo van den Heuvel wrote:
> On 14-10-2020 10:27, Pavel Machek wrote:
> >> One should have thought about stuff beforehand.
> >
> > We did. And decided this is best solution.
>
> Then the thought process went awry.
>
> >> The non-selectability is not my fault.
> >
> >
On 14-10-2020 10:27, Pavel Machek wrote:
>> One should have thought about stuff beforehand.
>
> We did. And decided this is best solution.
Then the thought process went awry.
>> The non-selectability is not my fault.
>
> It also does not affect you in any way.
It does.
/boot fills up even soon
On 10/13/20 9:39 PM, Udo van den Heuvel wrote:
> On 14-10-2020 06:34, Randy Dunlap wrote:
>> On 10/13/20 9:29 PM, Udo van den Heuvel wrote:
>>> So we still are stuck.
>
> (...)
>
>
>> Please post your .config file.
>
> Attached to this message.
> This is the version stripped from LED references
On Wed 2020-10-14 10:22:01, Udo van den Heuvel wrote:
> On 14-10-2020 10:11, Pavel Machek wrote:
> >> It's a computer, not a disco-light or anything like that.
> >
> > And you probably have numlock LED.
>
> On the case? no way.
> It is on the keyboard, a separate device, and already has a functio
On 14-10-2020 10:11, Pavel Machek wrote:
>> It's a computer, not a disco-light or anything like that.
>
> And you probably have numlock LED.
On the case? no way.
It is on the keyboard, a separate device, and already has a function.
We also have a caps lock LED and scroll lock LED there, with sepa
On 10/13/20 10:16 PM, Udo van den Heuvel wrote:
> On 14-10-2020 07:07, Randy Dunlap wrote:
>> On 10/13/20 9:56 PM, Udo van den Heuvel wrote:
>
>>> I.e.: it looks like I will lose some funcionality when I disable
>>> SND_HDA_CODEC_REALTEK.
>>
>> OK. At present you can't have it both ways, i.e., SND
On Wed, 14 Oct 2020 10:13:05 +0200,
Pavel Machek wrote:
>
> On Wed 2020-10-14 10:08:27, Takashi Iwai wrote:
> > On Wed, 14 Oct 2020 09:54:59 +0200,
> > Pavel Machek wrote:
> > >
> > > Hi!
> > >
> > > > >>> I.e.: it looks like I will lose some funcionality when I disable
> > > > >>> SND_HDA_CODEC
On Wed 2020-10-14 10:08:27, Takashi Iwai wrote:
> On Wed, 14 Oct 2020 09:54:59 +0200,
> Pavel Machek wrote:
> >
> > Hi!
> >
> > > >>> I.e.: it looks like I will lose some funcionality when I disable
> > > >>> SND_HDA_CODEC_REALTEK.
> > > >>
> > > >> OK. At present you can't have it both ways, i.e
On Wed 2020-10-14 10:05:42, Udo van den Heuvel wrote:
> On 14-10-2020 09:58, Pavel Machek wrote:
> > Contrary to his claims, Udo very probably has LEDs in his systems...
>
> We have a visible power LED.
> WE have a HDD LED.
> The board has LEDs, yes, but the SilverStone Fortress FT02 hides them
>
On Wed, 14 Oct 2020 09:54:59 +0200,
Pavel Machek wrote:
>
> Hi!
>
> > >>> I.e.: it looks like I will lose some funcionality when I disable
> > >>> SND_HDA_CODEC_REALTEK.
> > >>
> > >> OK. At present you can't have it both ways, i.e., SND_HDA_CODEC_REALTEK
> > >> with no LEDS. That driver apparent
On Wed, 14 Oct 2020 09:58:53 +0200,
Pavel Machek wrote:
>
> Hi!
>
> > > > >>> I.e.: it looks like I will lose some funcionality when I disable
> > > > >>> SND_HDA_CODEC_REALTEK.
> > > > >>
> > > > >> OK. At present you can't have it both ways, i.e.,
> > > > >> SND_HDA_CODEC_REALTEK
> > > > >> wi
On 14-10-2020 09:58, Pavel Machek wrote:
> Contrary to his claims, Udo very probably has LEDs in his systems...
We have a visible power LED.
WE have a HDD LED.
The board has LEDs, yes, but the SilverStone Fortress FT02 hides them
fairly well.
I did not ask for LEDs nor need them this way.
It's a
Hi!
> > > >>> I.e.: it looks like I will lose some funcionality when I disable
> > > >>> SND_HDA_CODEC_REALTEK.
> > > >>
> > > >> OK. At present you can't have it both ways, i.e., SND_HDA_CODEC_REALTEK
> > > >> with no LEDS. That driver apparently wants LEDS.
> > > >
> > > > Thanks but why have I
Hi!
> >>> I.e.: it looks like I will lose some funcionality when I disable
> >>> SND_HDA_CODEC_REALTEK.
> >>
> >> OK. At present you can't have it both ways, i.e., SND_HDA_CODEC_REALTEK
> >> with no LEDS. That driver apparently wants LEDS.
> >
> > Thanks but why have I gone for years without LEDS
On Wed, 14 Oct 2020 09:49:49 +0200,
Takashi Iwai wrote:
>
> On Wed, 14 Oct 2020 07:54:15 +0200,
> Randy Dunlap wrote:
> >
> > On 10/13/20 10:16 PM, Udo van den Heuvel wrote:
> > > On 14-10-2020 07:07, Randy Dunlap wrote:
> > >> On 10/13/20 9:56 PM, Udo van den Heuvel wrote:
> > >
> > >>> I.e.: i
On Wed, 14 Oct 2020 07:54:15 +0200,
Randy Dunlap wrote:
>
> On 10/13/20 10:16 PM, Udo van den Heuvel wrote:
> > On 14-10-2020 07:07, Randy Dunlap wrote:
> >> On 10/13/20 9:56 PM, Udo van den Heuvel wrote:
> >
> >>> I.e.: it looks like I will lose some funcionality when I disable
> >>> SND_HDA_COD
On 14-10-2020 07:07, Randy Dunlap wrote:
> On 10/13/20 9:56 PM, Udo van den Heuvel wrote:
>> I.e.: it looks like I will lose some funcionality when I disable
>> SND_HDA_CODEC_REALTEK.
>
> OK. At present you can't have it both ways, i.e., SND_HDA_CODEC_REALTEK
> with no LEDS. That driver apparentl
On 14-10-2020 06:49, Randy Dunlap wrote:
> If you disable SND_HDA_CODEC_REALTEK, then the rest of the
> LED kconfig symbols can be disabled.
Sure,
but:
# dmesg|grep audi
(...)
[ 19.971537] snd_hda_codec_generic hdaudioC0D0: ignore pin 0x7, too
many assigned pins
[ 19.973547] snd_hda_codec_g
On 13-10-2020 18:03, Randy Dunlap wrote:
> On 10/13/20 8:53 AM, Randy Dunlap wrote:
>> [adding LED people + list]
>>
>> On 10/13/20 6:24 AM, Udo van den Heuvel wrote:
(...)
So how do I disable this stuff?
>
> I was able to disable LEDS_CLASS and NEW_LEDS after I disabled the following
On 10/13/20 8:53 AM, Randy Dunlap wrote:
> [adding LED people + list]
>
> On 10/13/20 6:24 AM, Udo van den Heuvel wrote:
>> L.S.,
>>
>> Even after removing all LED referneces from .config, a `make oldconfig`
>> leads to:
>>
>> *
>> * LED Support
>> *
>> LED Support (NEW_LEDS) [Y/?] (NEW) y
>> LE
[adding LED people + list]
On 10/13/20 6:24 AM, Udo van den Heuvel wrote:
> L.S.,
>
> Even after removing all LED referneces from .config, a `make oldconfig`
> leads to:
>
> *
> * LED Support
> *
> LED Support (NEW_LEDS) [Y/?] (NEW) y
> LED Class Support (LEDS_CLASS) [M/y/?] (NEW) n
>
> Where
L.S.,
Even after removing all LED referneces from .config, a `make oldconfig`
leads to:
*
* LED Support
*
LED Support (NEW_LEDS) [Y/?] (NEW) y
LED Class Support (LEDS_CLASS) [M/y/?] (NEW) n
Where 'n' is not a valid choice.
So why is this LED thing forced upon us and how do we get rid of it?
O
26 matches
Mail list logo
