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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 19 Feb 2017 20:05:47 +0100
From:   Pavel Machek <>
To:     "H. Nikolaus Schaller" <>
Cc:     Dmitry Torokhov <>,
        Sebastian Reichel <>,
        Mark Rutland <>,
        Benoît Cousson <>,
        Tony Lindgren <>,
        Russell King <>,
        Arnd Bergmann <>,
        Michael Welling <>,
        Mika Penttilä <>,
        Javier Martinez Canillas <>,
        Igor Grinberg <>,
        "Andrew F. Davis" <>, Mark Brown <>,
        Jonathan Cameron <>,
        Rob Herring <>,
        Alexander Stein <>,
        Eric Engestrom <>,
        Hans de Goede <>,
        Benjamin Tissoires <>,
        Petr Cvek <>,
        Mauro Carvalho Chehab <>,
        Hans Verkuil <>,
        Nick Dyer <>,
        Siebren Vroegindeweij <>,
        Michel Verlaan <>,,,,,,,, Aaro Koskinen <>,
        Pali Rohár <>,
        Andrey Gelman <>,
        Haibo Chen <>
Subject: Re: [PATCH v9 1/8] drivers:input:tsc2007: add new common binding
 names, pre-calibration, flipping and rotation


> Hi Pavel,
> I love discussions with you :)

Unfortunately I can't say the same.

> > Am 19.02.2017 um 18:15 schrieb Pavel Machek <>:
> > 
> > 
> >>> Solve it properly. That means passing calibration
> >>> data from kernel to userland.
> >> 
> >> As written before, the really proper solution would be to provide floating
> >> or fixed point subpixel input events. Not arbitrarily scaling up in kernel
> >> and leaving downscaling to user space (where everybody can make it
> >> worse).
> > 
> > That has no advantages,
> It has the advantage of providing you with the full precision of raw data (but
> properly scaled) so that you don't loose any bit of information. This is what
> you just asked for - one or two mails before.

Not really, right? No matter what kind of fixed point you introduce,
you'll still loose precision.

> > and floating point in kernel is hard. Also
> > you'd either have to invent new interface, or you'd break touchscreen
> > for people that already have their touchscreens calibrated.
> No, I don't break calibration for people using a different chip.

So you propose your touchscreen to behave differently from all other
touchscreens in tree? That's just no-go.

> > Yes, that's not really proper solution, that just overengineered. Not
> > worth implementing. Pass calibration data to userland.
> You seem to repeat yourself and just say which solution you prefer,
> but I am missing the arguments why your solution (Pass calibration data
> to userland) is right and the best one.
> Which problems does it solve?

All you described.

> Which one does it solve better than others?

It is not terminally ugly.

> How can you implement it in
> a stable and portable way?


> How can you make sure that all user-space GUI
> systems can and will make use of this calibration data?

You can't, and you don't need to.

(cesky, pictures)

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)

Powered by blists - more mailing lists