[ANNOUNCE] xf86-input-evdev 2.0.99.2

Søren Hauberg hauberg at gmail.com
Mon Oct 27 01:20:55 PDT 2008


2008/10/27 Peter Hutterer <peter.hutterer at who-t.net>:
> On Mon, Oct 27, 2008 at 08:44:24AM +0100, Søren Hauberg wrote:
>> Just a quick thought: double-scaling means we transform one coordinate
>> from [a, b] to [c, d] in the driver, and then from [c, d] to [e, f] in
>> the server, right? Here [a, b] is determined by the hardware. What if
>> we choose [c, d] equal to [e, f] ? Then the scaling in the server
>> would be from [e, f] to [e, f] i.e. a unit scaling, which I assume
>> doesn't affect the precision (if it does, then we could let the server
>> check if the scaling is a unit-scaling, and only perform the actual
>> scaling if it is not).
>
> uhm. we seem to be coming back round in a full circle here.
> As I said in an earlier email, we don't need scaling in the driver if you can
> specify the min/max range at startup. So in your example, you only need
> scaling in the driver if you want to change [c, d] at runtime. If you can just
> set it up to [e, f], then you can just skip the scaling altogether.
>
> Our problem is that we don't konw [a, b] at server startup, isn't it?

Yes, not knowing [a, b] at server startup is indeed the real problem.
If we want to support run-time calibration, then it simply won't be
possible to fix these parameters at startup. From what I understand,
it is only the driver that supports changing parameters at run-time,
so support for run-time calibration requires some sort of scaling in
the driver, right?

I see three issues with scaling in the driver

1) Performance: we'll do scaling twice, which requires cpu cycles.

2) Clutter: scaling in the driver requires more code in the driver.
This will add clutter to a currently quite clean piece of code.

3) Precision: as Simon pointed out, double scaling might introduce
numerical issues since calculations are performed using integers.

My previous e-mail was just saying: if we can't get around
double-scaling, then we can solve the precision issue by scaling
directly to [e, f] in the driver. This doesn't solve any other issues,
though...

Søren



More information about the xorg mailing list