linux-kernel - Re: [PATCH] MAINTAINERS: Update rydberg's addresses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAN+gG=EUNk8AR4PR3qk8L05stx1jUEn9anA6xi+1Qjob00h_hg@mail.gmail.com>
Date:	Wed, 21 Jan 2015 11:23:59 -0500
From:	Benjamin Tissoires <benjamin.tissoires@...il.com>
To:	Henrik Rydberg <rydberg@...math.org>
Cc:	Peter Hutterer <peter.hutterer@...-t.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Joe Perches <joe@...ches.com>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	linux-input <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] MAINTAINERS: Update rydberg's addresses

On Wed, Jan 21, 2015 at 10:25 AM, Henrik Rydberg <rydberg@...math.org> wrote:
> Hi Peter,
>
>> it wasn't the first reaction. it was the third, after we hacked up
>> synaptics [1], then libinput [2], both rather unsatisfactory. Not sure what
>> chromeos does but they'll probably would need similar code. And any other
>> users of the evdev API of course.
>
> So if this approach did not work very well in userland, why would it work any
> better in the kernel?
>

I would have thought that Peter's answer was clear enough:
- there is a fragmentation problem: we would have to fix the bug in
xorg-synaptics (which is slowly waiting for its death), libinput,
ChromeOS, Qt Embedded, Kivy (I think), etc... We can do it, to some
extend, but we will have to explain the following to our users:
- it means that the mt protocol B can not be relied upon, because even
if we state that each touch has its own slot, then it is false in this
case. This was Peter last point.

Also, if you compare the libinput implementation of the handling of
the cursors jumps and the kernel implementation I proposed, there is a
big difference in term of simplicity.

In the kernel, while we are assigning the tracking IDs, we detect that
there is a jump, and we "just" have to generate a new slot and close
the first (done by 1 assignment of -1 to the current tracking ID).

In Libinput, well, you receive a slot, there is a jump, you detect it,
then you have to create a new fake kernel event to stop the current
slot, create a new one, and you then have to rewind the current state
of the buttons, the hysteresis, add special case handling and
hopefully, you did not introduced a bug in all the complex code. So
you need to write unit tests (not an argument, I concede, but this is
extra work), and in the future, someone will not understand what this
is all about because the kernel should guarantee that the slots are
sane.

If I were grumpy (and I can be, ask Peter), I would say that sure, we
can add such a case in the mtdev library, but the point of having the
in-kernel tracking system was to slowly get away from the head over
added by mtdev.

Cheers,
Benjamin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/