linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	"Antonios Salios" <antonios@mwa.re>,
	"Deepa Dinamani" <deepa.kernel@gmail.com>
Cc: rydberg@bitmath.org, linux-input@vger.kernel.org,
	linux-kernel@vger.kernel.org, "Jan Henrik Weinstock" <jan@mwa.re>,
	"Lukas Jünger" <lukas@mwa.re>
Subject: Re: element sizes in input_event struct on riscv32
Date: Tue, 19 Dec 2023 13:53:07 +0000	[thread overview]
Message-ID: <9e97eb50-f9a6-4655-9422-fa1106fff97a@app.fastmail.com> (raw)
In-Reply-To: <ZYEFCHBC75rjCE0n@google.com>

On Tue, Dec 19, 2023, at 02:50, Dmitry Torokhov wrote:
> Hi Antonious,
>
> On Thu, Dec 14, 2023 at 11:11:18AM +0100, Antonios Salios wrote:
>> Hi all.
>> 
>> I'm having trouble getting evdev to run in a simulated Buildroot
>> environment on riscv32. Evtest (and the x11 driver) seems to be
>> receiving garbage data from input devices.
>> 
>> Analyzing the input_event struct shows that the kernel uses 32-bit (aka
>> __kernel_ulong_t) values for __sec & __usec.
>> Evtest on the other hand interprets these variables as 64-bit time_t
>> values in a timeval struct, resulting in a mismatch between the kernel
>> and userspace.
>> 
>> What would be the correct size for these values on a 32-bit
>> architecture that uses 64-bit time_t values?
>
> I think there is misunderstanding - we do not have *2* 64-bit values on
> 32-but architectures. Here is what was done:
>
>     Input: extend usable life of event timestamps to 2106 on 32 bit systems

Thanks for forwarding this to me. You are definitely right that
the user-space structure is intended to use a pair of __kernel_ulong_t
for the timestamp. Usually if an application gets this wrong, it is the
result of having copied old kernel headers the source directory that
need to be updated.

For evtest in particular, I don't see how that is possible, the source
code at [1] shows that it just includes the global linux/input.h,
which on riscv32 would have to be at least from linux-5.6 anyway
because older versions are too old to build a time64 glibc.

Antonios, can you check which header was used to build your copy
of evtest, and in case this came from /usr/include/linux, which
version it corresponds to?

      Arnd

[1] https://gitlab.freedesktop.org/libevdev/evtest/-/blob/master/evtest.c?ref_type=heads

  reply	other threads:[~2023-12-19 13:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-14 10:11 element sizes in input_event struct on riscv32 Antonios Salios
2023-12-19  2:50 ` Dmitry Torokhov
2023-12-19 13:53   ` Arnd Bergmann [this message]
2023-12-21  8:56     ` Antonios Salios
2023-12-21 12:28       ` Arnd Bergmann
2023-12-21 13:38         ` Antonios Salios
2024-01-15 15:46           ` Antonios Salios
2024-01-15 16:11             ` Arnd Bergmann

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=9e97eb50-f9a6-4655-9422-fa1106fff97a@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=antonios@mwa.re \
    --cc=deepa.kernel@gmail.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=jan@mwa.re \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas@mwa.re \
    --cc=rydberg@bitmath.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).