Bug 225343 - multimedia/v4l_compat: Incorrect EVIOCGMTSLOTS ioctl which breaks libevdev
Summary: multimedia/v4l_compat: Incorrect EVIOCGMTSLOTS ioctl which breaks libevdev
Status: Closed DUPLICATE of bug 217248
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-multimedia (Nobody)
URL: https://reviews.freebsd.org/D13998
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-20 18:59 UTC by Jean-Sébastien Pédron
Modified: 2021-06-10 10:43 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (multimedia)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-Sébastien Pédron freebsd_committer 2018-01-20 18:59:24 UTC
The `EVIOCGMTSLOTS` ioctl is used to query a touchpad's multitouch state. libevdev calls it to initialise its internal state.

On Linux, this ioctl is marked as "read". However, this is incorrect on FreeBSD because the ioctl takes the multitouch attribute to query as argument. Therefore, the ioctl must be marked as "read+write". Otherwise, the attribute doesn't make it to the evdev kernel driver and ioctl(2) returns EINVAL.

The visible consequence of this problem is libinput: when you use it as your input DDX in X.Org (the same happens with Wayland probably), some touch events early in a session are dropped. You have to release and start another touch move do what you wanted in the first place (move the cursor, scroll, ...).

The reason is that the multitouch state in libevdev has all fields set to zero at first (because the ioctl(2) failed). And when it receives a first touch event which indicate a tracking ID for 0, libevdev thinks there is a bug because the tracking ID is already set to 0, and decides to drop the entire touch action. Here is the message from libevdev:

    BUG: Device "..." received a double tracking ID 0 in slot 0.

When the finger is released, the kernel sends a tracking ID of -1 which fixes libevdev internal state. Thus, the next touch action does the right thing.
Comment 1 Jean-Sébastien Pédron freebsd_committer 2018-01-20 19:02:47 UTC
I posted a patch to Phabricator:
https://reviews.freebsd.org/D13998

devel/libevdev needs to be rebuilt as well. I don't know if the Ports framework takes care of this, or it libevdev's PORTREVISION should be bumped.
Comment 2 Vladimir Kondratyev freebsd_committer 2018-01-26 10:03:49 UTC
Our userland evdev headers predated in-kernel implementation so
there are many more ioctl definitions to fix yet. Most notably EVIOCGRAB, EVIOCGREVOKE and all uinput.h stuff. Here is relevant PR:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217248
Comment 3 Jean-Sébastien Pédron freebsd_committer 2018-01-26 10:15:08 UTC
Even better! Thank you for that patch and pointing me to it!

I'm closing this PR and the associated review.

*** This bug has been marked as a duplicate of bug 217248 ***
Comment 4 commit-hook freebsd_committer 2021-06-10 10:41:59 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=aa310ebfba3d49a0b6b03a103b969731a8136a73

commit aa310ebfba3d49a0b6b03a103b969731a8136a73
Author:     Mariusz Zaborski <oshogbo@FreeBSD.org>
AuthorDate: 2021-06-09 21:46:51 +0000
Commit:     Mariusz Zaborski <oshogbo@FreeBSD.org>
CommitDate: 2021-06-10 10:41:29 +0000

    libcasper: fix descriptors numbers

    Casper services expect that the first 3 descriptors (stdin/stdout/stderr)
    will point to /dev/null. Which Casper will ensure later. The Casper
    services are forked from the original process. If the initial process
    closes one of those descriptors, Casper may reuse one of them for it on
    purpose. If this is the case, then renumarate the descriptors used by
    Casper to higher numbers. This is done already after the fork, so it
    doesn't break the parent process.

    PR:             225343
    Reported by:    Borja Marcos <borjam (at) sarenet.es>
    Tested by:      jkim@

 lib/libcasper/libcasper/libcasper_impl.c | 27 +++++++++++++++++++++++++++
 lib/libcasper/libcasper/libcasper_impl.h |  1 +
 lib/libcasper/libcasper/service.c        | 23 +++++++++++++----------
 lib/libcasper/libcasper/zygote.c         | 15 +++++++++------
 4 files changed, 50 insertions(+), 16 deletions(-)
Comment 5 Mariusz Zaborski freebsd_committer 2021-06-10 10:43:31 UTC
Ups sorry I attached wrong bug number.