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:   Mon, 20 Feb 2017 21:20:20 +0100
From:   "H. Nikolaus Schaller" <>
To:     Pavel Machek <>
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 <>,,
        devicetree <>,
        LKML <>,
        linux-omap <>,
        Discussions about the Letux Kernel 
        <>,,, 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,

> Am 20.02.2017 um 20:29 schrieb Pavel Machek <>:
> Hi!
>> As long as it is small (I expect <1.01 = 1% error in scale) it is
>> barely noticeable.
>> Therefore, I asked before: how big in pixels is your finger or stylus?
>> Does this effect matter?
> If I draw a line in gimp, I don't expect it to have steps because of
> "barely noticeable" errors.

You can't draw a line with exactly 1 pixel distance on such a touch screen.

>> A resistive touch is a man-machine-interface where people press buttons of at
>> least 12x12 pixels size (or they are no longer visually recognizable).
> Resistive touch is used for drawing, too.

Yes, for taking handwritten notes but not for high-precision graphics design.
For that you take a bigger screen and zoom the relevant areas.

>> So the discussion boils down to "what gives the better usability?":
>> a) getting rid of the nasty user-space calibration step (and plethora of different tools)
>> b) getting highest theoretical precision which has a low practical relevance
>> I am in favor of a). Like most users we ask. A minority is in favor of b).
>> Since we don't exclude b) users from reconfiguring their system to get it done
>> as they like. I think this is the best we can achieve.
> Do you even read what I wrote?
> Because I presented way to have both a) _and_ b).

I am not aware that you did this. You made a proposal for the X system but not
for others, e.g. Replicant.

>>>>> No. You have to design interface such that they _can_ be improved, and
>>>>> what you propose does not work that way.
>>>> It works. Please do real world tests...
>>> You do a real world test on N900, and propose upgrade path.
>> I have no N900 running. But since it uses a tsc2004/5 controller which seems
>> to be quite similar, you can likely copy&paste some code or add the algorithm:
>> ABS_X = (touchscreen-size-x * (adc_x - adc_min_x)) / (adc_max_x - adc_min_x)
>> Thats it.
>> If you set touchscreen-size-x = (adc_max_x - adc_min_x) you get maximum precision
>> you can achieve with integer arithmetic. And if you set adc_min_x = 0 your
>> user-space gets what it would have got before adding such a formula and then you
>> can and must do calibration there.
>> Taking this as the defaults if none of the new properties is specified, makes
>> the scaling feature completely disappear. And I don't care about 2 additional
>> subtractions, one multiplication and one division per axis.
>> So the upgrade path is:
>> 1. introduce new optional properties, parse and store them in the struct
>> 2. set defaults for the optional properties as described above
>> 3. add the formula to the code (1 line for each axis)
>> 4. deploy - nobody will notice
> Good so far.


>> 5. update the DT and remove user-space calibration - people will be happy
>>   that they do not have to calibrate first any more
> You can't do this. And this is fatal problem with your proposal.

> If I update the DT in the kernel, my users will be very unhappy,
> because their screens will now be miscalibrated.

If you tell them that they should recalibrate once, after they upgrade
to Linux 4.12 because they no longer need it I doubt they will not be very

And as said I do not expect or force you to take step 5 for the N900 touch
screen. Not even step 1.

I would take this more sensitive if you would use the same chip.

> New kernel must not
> force users to update their userland at the same time.

Yes, it shouldn't. But to be honest, this is not my experience. I have to
tweak userland a little almost every time a new kernel merge window is done.
Admittedly not in the input system. And I may be using the wrong distribution.

But if you ever want to deploy better features it is really difficult to avoid.

Nevertheless, what problem do you have to implement steps 1-4 in kernel
and step 5 outside?

BR and thanks,

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

Powered by blists - more mailing lists