From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 11DEC52D2CF for ; Thu, 17 Sep 2026 13:30:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789651845; cv=none; b=AljasnNNClPCGd7uamrDXOTQ/wc5BjIigaHViINWDFw9Y7yJ8RL47MVnImLm849UM2TpuK4Wp21nWDQAGcw0gY9KOlTfZJWeIdVAJFZhmrJfmB4fF3AJyjO/FR2ieSCPmwSslOIlQiXi+h+TXcropbcFRP+Yq6srV781orUaTFc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789651845; c=relaxed/simple; bh=6+PGlM29eOEsGBkB+yG6PSUDSHlA3Lzb3Ck5UkwVgEg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Y0oFYVLrx5+ohc3mE0/UPyEvlGNdghJ+GeziyOvNo96njftULiPOTQTI+zC1Y89oFEVqvWoUOYZAhHGRALvj5dsPcZI6qyNR+w2kKFgtGiAr4W56mhwWgOsFPOXkVfrUmMGpSUL2c/zVtKCozJ1BU8aRaY/KzAFFY3NMrfQsBf4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ckK2LA4t; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ckK2LA4t" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 29C921F000FF; Thu, 17 Sep 2026 13:30:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789651831; bh=noxLJZR38Yz3TeQbGG3b6KFHwOyQW8b2YKhCqrxw7Jc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=ckK2LA4tRjvDuJKEpynr7q183GQTGDSDTBjrf+vdpjR1Ga1gXwbGwb9HncM6NNdNw M9fA50bIcRSY8hFfQSxRjDqqdiX92aRJLrcLHt1g2r+WWtrX+VRUHgfBvdwyh4iuuh GKeWFiWvNGgncc8HMNhQhEwHjN8j4UJpuZLykEPRBB3lwYHFrsTBsOuZidQ+5csldh s65cQGS4ENgm6RPOyVZ5tPmr7U/oOg7f9xNkdetptUNX8AdSiyA0SRTeYEPs8Uwe1R xx/o5I2h6OlNg23vAjH6luGYdcuff6Xte1pw3T404lfWKeXQrMWbC9IUzSjqyOfCQ9 SAIMYBafoFe0A== Date: Thu, 17 Sep 2026 15:30:27 +0200 From: Alexey Gladkov To: Vincent Lefevre Cc: kbd@lists.linux.dev Subject: Re: "showkey -s" prints incorrect scan codes Message-ID: References: <20260916022330.GA731654@qaa.vinc17.org> Precedence: bulk X-Mailing-List: kbd@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260916022330.GA731654@qaa.vinc17.org> On Wed, Sep 16, 2026 at 04:23:30AM +0200, Vincent Lefevre wrote: > Under Debian/unstable (package kbd 2.9.0-1), "showkey -s" prints > completely incorrect scan codes, and doesn't even print anything > for the Fn key (while evtest does). > > This is apparently a known bug: > https://wiki.archlinux.org/title/Keyboard_input > > Except from this wiki, I couldn't find any mention of this bug, > so this was rather surprising. This is written directly in the man page: In 2.6 kernels raw mode, or scancode mode, is not very raw at all. Scan codes are first translated to key codes, and when scancodes are desired, the key codes are translated back. Various transformations are involved, and there is no guarantee at all that the final result corresponds to what the keyboard hardware did send. So, if you want to know the scan codes sent by various keys it is better to boot a 2.4 kernel. Since 2.6.9 there also is the boot option atkbd.softraw=0 that tells the 2.6 kernel to return the actual scan codes. So this is a problem that has been known for a very long time. By saying that, I don't mean that it shouldn't be fixed. showkey is a very old utility, and I have to admit I had completely forgotten about a feature like getting scancodes. I think I could add support for evdev to get the correct result. I added the --device={DEV,all} option, which specifies which device to use. If it is an evdev device, a new mechanism for retrieving scancodes will be used. You can simply run: ./showkey --device=all --scancodes Could you try it in the for-master branch ? Does this behavior of the utility seem normal to you? https://github.com/legionus/kbd/compare/master...refs/heads/for-master -- Rgrds, legion