All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: lianzhi chang <changlianzhi@uniontech.com>
Cc: linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org,
	jirislaby@kernel.org, andriy.shevchenko@linux.intel.com,
	282827961@qq.com
Subject: Re: [PATCH v6] tty: Fix the keyboard led light display problem
Date: Sun, 24 Oct 2021 22:12:46 -0700	[thread overview]
Message-ID: <YXY8zrEbkhdO6ikS@google.com> (raw)
In-Reply-To: <20211021020511.18016-1-changlianzhi@uniontech.com>

Hi,

On Thu, Oct 21, 2021 at 10:05:11AM +0800, lianzhi chang wrote:
> @@ -1524,6 +1543,9 @@ static void kbd_event(struct input_handle *handle, unsigned int event_type,
>  	/* We are called with interrupts disabled, just take the lock */
>  	spin_lock(&kbd_event_lock);
>  
> +	if (test_bit(EV_LED, handle->dev->evbit))
> +		kbd_update_ledstate(handle->dev);
> +

Why do we need to update led state on each and every event instead of
trapping individual EV_LED/LED_x events?

But thinking about it some more, I believe doing this here is wrong.
LEDs are routed in this way:

   device <-> input core <-> input leds <-> leds core <-> VT

with the last step assuming that we are in default configuration and we
indeed assign one of the following triggers to appropriate LED on given
device:

kbd-scrolllock kbd-numlock kbd-capslock kbd-kanalock kbd-shiftlock
kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock
kbd-ctrlllock kbd-ctrlrlock

I.e. the state of LED of individual input device is not necessarily
attached to LED flag state in a given VT.

Re-reading the patch description, are we saying that we are maintaining
kbd->[s]lockstate, but losing kbd->ledflagstate when we are doing
transitions to and from VC_OFF state? We need to keep in mind that we
are trying to keep states separate on separate consoles.

Thanks.

-- 
Dmitry

  parent reply	other threads:[~2021-10-25  5:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20211021020511.18016-1-changlianzhi@uniontech.com>
2021-10-22 15:13 ` [PATCH v6] tty: Fix the keyboard led light display problem Andy Shevchenko
     [not found]   ` <202110250129181502896@uniontech.com>
2021-10-25 12:03     ` andriy.shevchenko
     [not found]       ` <202110251224440412487@uniontech.com>
2021-10-25 12:57         ` andriy.shevchenko
2021-10-25  5:12 ` Dmitry Torokhov [this message]
2021-10-21  3:02 lianzhi chang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YXY8zrEbkhdO6ikS@google.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=282827961@qq.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=changlianzhi@uniontech.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jirislaby@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.