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 function.
> We also have a caps lock LED and scroll lock LED there, with separate
> functions.
> I do not need 'extra' functionality for those.
>
> > Additional config options have costs, too, and we don't want to
> > support gazillion config options.
>
> That is not the issue.
> One should have thought about stuff beforehand.
We did. And decided this is best solution.
> The non-selectability is not my fault.
It also does not affect you in any way.
Feel free to go to the mic LED discussion to see why we did it like
this. Then you can come up with better solution for problem at hand.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
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 sooner thanks to this unused code.
Compiles last longer because of this unused code.
> Feel free to go to the mic LED discussion to see why we did it like
> this. Then you can come up with better solution for problem at hand.
I did not think of forcing code onto somebody. Someone else did.
This is effectively the effect of the LEDs thing.
So why should I `fix` this when a Kconfig thing is considered 'expensive'?
If reasonable arguments fall to the floor then where do you go?
This is the same as some useless things in Fedora that one cannot simply
uninstall.
Udo
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.
> >
> > It also does not affect you in any way.
>
> It does.
> /boot fills up even sooner thanks to this unused code.
> Compiles last longer because of this unused code.
Have you measured how much slower and how much bigger it is? Do you
understand that you propose to make source code bigger and slower to
compile for everyone else?
You are filling my inbox.
> > Feel free to go to the mic LED discussion to see why we did it like
> > this. Then you can come up with better solution for problem at hand.
>
> I did not think of forcing code onto somebody. Someone else did.
> This is effectively the effect of the LEDs thing.
Without understanding what was decided and why, this discussion is not
useful.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
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 lifted in the source tree then I can live with
the 'is optimized out' predictions, assuming that gcc (from Fedora 32)
can do this.
So the request is clear; we're almost there.
Please make it so that the compiler can do the 'optimize away' work bij
changing a tad in the Realtek HDA driver, along the lines of the patch
sent to me earlier or something even more beautiful.
Thanks in advance and kind regards,
Udo
On 14-10-2020 10:37, Pavel Machek wrote:
> 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.
>>>
>>> It also does not affect you in any way.
>>
>> It does.
>> /boot fills up even sooner thanks to this unused code.
>> Compiles last longer because of this unused code.
>
> Have you measured how much slower and how much bigger it is? Do you
> understand that you propose to make source code bigger and slower to
> compile for everyone else?
>
> You are filling my inbox.
>
>>> Feel free to go to the mic LED discussion to see why we did it like
>>> this. Then you can come up with better solution for problem at hand.
>>
>> I did not think of forcing code onto somebody. Someone else did.
>> This is effectively the effect of the LEDs thing.
>
> Without understanding what was decided and why, this discussion is not
> useful.
>
>
> Pavel
>
On Mon, 19 Oct 2020 10:35:12 +0200
Udo van den Heuvel <[email protected]> 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 in
> 5.9.1) *wants* to enable LED functionality.
> I.e.: if this blockade is lifted in the source tree then I can live
> with the 'is optimized out' predictions, assuming that gcc (from
> Fedora 32) can do this.
> So the request is clear; we're almost there.
> Please make it so that the compiler can do the 'optimize away' work
> bij changing a tad in the Realtek HDA driver, along the lines of the
> patch sent to me earlier or something even more beautiful.
>
> Thanks in advance and kind regards,
> Udo
Udo,
The documentation says that LED trigger code optimises away, not LED
core.
But yes, something similar could maybe be done for the whole LED
class... (maybe!)
BTW, you are welcome to propose a patch as well, since it seems that
nobody else is interested as much as you are in this :)
Marek