linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Antonios Salios <antonios@mwa.re>
To: Arnd Bergmann <arnd@arndb.de>,
	Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	 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: Thu, 21 Dec 2023 09:56:06 +0100	[thread overview]
Message-ID: <491250ba57be2ab983048ffcf5ffd2aec2bedb9e.camel@mwa.re> (raw)
In-Reply-To: <9e97eb50-f9a6-4655-9422-fa1106fff97a@app.fastmail.com>

On Tue, 2023-12-19 at 13:53 +0000, Arnd Bergmann wrote:
> 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

The header is included from the sysroot of the toolchain, using version
6.5.6.
I'm using glibc 2.37 with a toolchain built from Buildroot.

The problem seems to be, that __USE_TIME_BITS64 is not defined even
though riscv32 uses 64-bit time.
__BITS_PER_LONG is set to 32 & __KERNEL__ is (of course) undefined in
userspace.
The userspace therefore uses 64-bit values as opposed to the kernel,
which uses 32-bit values.

__USE_TIME_BITS64 is only set when __TIMESIZE is set to 32. [1]
Under riscv32, the default value of 64 is used. [2]


[1]
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/features-time64.h;h=af9d84daa7dfe4174e9f977b2c76c5c0df1ce47b;hb=refs/tags/glibc-2.37
[2]
https://sourceware.org/git/?p=glibc.git;a=blob_plain;f=bits/timesize.h;hb=refs/tags/glibc-2.37

-- 
Antonios Salios
Software Engineer

MachineWare GmbH | www.machineware.de
Hühnermarkt 19, 52062 Aachen, Germany
Amtsgericht Aachen HRB25734

Geschäftsführung
Lukas Jünger
Dr.-Ing. Jan Henrik Weinstock

  reply	other threads:[~2023-12-21  8:56 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
2023-12-21  8:56     ` Antonios Salios [this message]
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=491250ba57be2ab983048ffcf5ffd2aec2bedb9e.camel@mwa.re \
    --to=antonios@mwa.re \
    --cc=arnd@arndb.de \
    --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).