Subversion Repositories SmartDukaan

Last modification

• Rev 37436 2026-08-27 06:20:52
• Author: amit

• Log message:

  Oppo: back to ASSUMED_RATIO 1.7; 0.67 was fitted to contaminated data
  
  r37433 set oppo to 0.67 on the strength of 3,694 production calibrations. It did
  not help: 14% before, 13% after, across two independent windows.
  
  Those 3,694 measurements were all taken while the slider press was leaking
  between attempts (fixed in r37435), so 79% of them started from a corrupted
  pointer state. The value was fitted to noise.
  
  With that confound removed the clean comparison is realme: identical widget,
  identical calibration code, ASSUMED_RATIO 1.7, converting 82% of drags against
  oppo's 13%. Measured post-fix on comparable gaps:
  
  Oppo 0.67 -> probe 52px, closes 37% of a 122px gap -> 13% success
  Realme 1.7 -> probe 31px, closes 11% of a 105px gap -> 82% success
  
  The smaller probe is the one that lands. A probe that eats a third of the gap
  risks crossing the target during calibration, and the gap is measured as
  |c1 - c2|, which cannot distinguish "not there yet" from "gone past" -- so the
  derived ratio comes back wrong and the main move is wrong with it.
  
  This converges on realme's value but is not a blind sync: it is the one
  configuration observed to work on this widget once the press bug was gone. The
  constants stay per-brand and independently documented.
  
  Not a certainty. r37435 improved realme by 18 points and left oppo flat, so
  something about oppo may still differ; this tests the cheapest remaining
  explanation before going after circle detection.