On Wed, Oct 9, 2019 at 7:11 AM Kamil Paral <kparal@redhat.com> wrote:

> I guess the proposed criterion should get adjusted per our latest discussion in blocker review meeting, i.e. this one:
>
> 16:28:24 <adamw> #agreed 1755898 - AcceptedBlocker (Final) - per list and meeting discussion of bcotton's proposed criterion, we agree in principle to block on modifier key toggling working well and consistently throughout the system, but not on the light state being correct (as that is difficult to guarantee). consequently the 'shell and apps behave differently' portion of this is accepted
> https://meetbot.fedoraproject.org/fedora-blocker-review/2019-10-07/f31-blocker-review.2019-10-07-16.02.log.html
>
Based on this, I am presenting a modified proposal:

== Keyboard toggle keys ==

For all release-blocking desktops, the Caps Lock and Num Lock keys
must correctly toggle the relevant behavior for the desktop and all
applications.

I believe we should explicitly state that the light state might not match. Otherwise we'll forget about this discussion and many of us will assume the light state must match as well (and then Adam will have to use his infinite memory and dig through the archives to prove us wrong once again).

But, I wonder if we perhaps still could make it more stricter about the light indicator. The argument was that there is some hardware that doesn't allow querying or something, and that's why we can't guarantee that. Well, what if we said the light state must reflect the reality in principle, but it doesn't need to work for hardware that doesn't support necessary capabilities or is otherwise hard to work with? Because if there's a race condition that lights up the indicator randomly whenever you boot, I'd like to cover that case with the criterion. If the light state is clearly broken in software, because it's inverted on *all* keyboards out there, I'd like to cover that case with the criterion. Only with problematic hardware, I'd make it non-blocking. What do you think?