2008/10/27 Peter Hutterer <[EMAIL PROTECTED]>: > 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 _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
