On Tue, 2019-10-29 at 13:27 +0100, Kamil Paral wrote:
On Mon, Oct 28, 2019 at 4:34 PM Ben Cotton <bcotton(a)redhat.com>
> On Wed, Oct 9, 2019 at 7:11 AM Kamil Paral <kparal(a)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
> 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
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).
Yeah, it could go in as a footnote.
But, I wonder if we perhaps still could make it more stricter about
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?
I think we should ask someone with more practical knowledge about the
actual issues here. Probably a kernel developer or someone at GNOME who
has dealt with it before. All I know is that it's a tricky area.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net