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 23:29:18 +0100
From:   Andreas Kemnade <>
To:     Pavel Machek <>
Cc:     "H. Nikolaus Schaller" <>,
        Mark Rutland <>,
        Andrey Gelman <>,
        Michel Verlaan <>,
        Nick Dyer <>,
        Tony Lindgren <>,,
        Benjamin Tissoires <>,, Russell King <>,
        Aaro Koskinen <>,
        Javier Martinez Canillas <>,
        Igor Grinberg <>,
        Hans Verkuil <>,,,
        Pali Rohár <>,
        Arnd Bergmann <>,
        Eric Engestrom <>,
        Hans de Goede <>,
        Rob Herring <>,
        Mika Penttilä <>,
        Mauro Carvalho Chehab <>,
        Petr Cvek <>,
        Siebren Vroegindeweij <>,
        Haibo Chen <>,
        Dmitry Torokhov <>,
        Sebastian Reichel <>,,
        "Andrew F. Davis" <>, Mark Brown <>,
        Benoît Cousson <>,, Michael Welling <>,, Jonathan Cameron <>,
        Alexander Stein <>
Subject: Re: [Letux-kernel] [PATCH v9 1/8] drivers:input:tsc2007: add new
 common binding names, pre-calibration, flipping and rotation


On Sun, 19 Feb 2017 21:57:08 +0100
Pavel Machek <> wrote:

> Hi!
> > But as said I don't think we need float or fixed point for
> > practical systems at all.
> So you are going to loose precision. And if userspace decides to
> calibrate it slightly differently from kernel, lost precision will
> matter.
> > >>> 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?
> > 
> > No. I only propose that my touch screen behaves properly and in the
> > best way it can. If others are worse, they should also be improved
> > at some time.
> Different from all other drivers. Read: broken.
> No. You have to design interface such that they _can_ be improved, and
> what you propose does not work that way. 
Then the consequent way would be to use i2c directly from userspace.
Because maybe for some really, really unusual you can do
something better there. Maybe adjust on-chip filtering (here the
MAV-filter) to interact better with your userspace filtering or
something like that if you want to exactly detect where maybe a
mosquito tries to drill into your touch screen (if the pressure would
be enough...) 

> > And note that I am not making things different from others in tree,
> > I am making the tsc2007 right (incl. following the touchscreen
> > bindings which define the touchscreen size in "Pixels").
> Your touch screen is not in any way special, so it has to behave in
> the same way others do.

I agree, the tsc2007 (=what the interface provides to userspace) should
not behave special, for example it should behave like the virtual
touchscreen (=what the interface provides to userspace) virtualbox
gives. No need to be calibrated. Well, the internals are different. But
that is what the kernel is good for, abstract such things.
Conclusion: It cannot be totally wrong behavior to have pixel values

And the generic touchscreen bindings describe the size in "Pixels" as
said by Nikolaus,

And here it is up to the dt to decide whether the touch screen is good
enough in position so it does not need to be manually calibrated or
there are chances to improve something. If there is no calibration in
the dt, then nothing changes.


Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists