[oe] [oe-commits] org.oe.dev xserver-common 1.13: Re-add calibrate-only-if-ts.patch after merge.

[Richard Purdie]

On Tue, 2007-02-20 at 22:55 +0200, Paul Sokolovsky wrote:
> > pfalcon commit schrieb:
> >> xserver-common 1.13: Re-add calibrate-only-if-ts.patch after merge.
> 
> > that's a very good idea but I am sure the patch will break calibration on quite
> > some devices because the device might have a different name. Maybe use
> > detect-stylus for this purpose.
> 
>   There was RFC to standardize name of touchscreen device in OE, and
> at the beginning of year corresponding changes were made (not by me
> ;-) ). For all 2.6 devices (which has standardized touchscreen support),
> there's a udevd rule which creates symlink from /dev/input/touchscreen0 to
> real device. Maintainers of 2.4 devices (which are mostly replaced with 2.6
> versions in OE.dev by now) are expected to provide such link by other
> means - either create link specific to some device, or use tool like
> detect-stylus.
> 
>   Such change does good job of clarifying touchscreen detection in system
> (you might remember my tries few months ago to implement it cleanly in
> Familiar).
> 
>   I understand that such a change would be too liberal for GPE mainline
> at this time, but OE.dev provides nice staging ground for that, so
> let's see how it goes.

Since I was the one who pushed some of this, let me clarify my position
at least.

My intention was to standardise all 2.6 kernels using udev to use the
udev rule, use /dev/touchscreen* and therefore remove the need for
detect-stylus and machine specific ts-conf packages. I have no problem
having custom tslib conf files for a 2.4 device which needs to work
differently. I have now changed the defaults to reflect what the
majority of new users will be using though.

As for xserver-common, I'd like to see the standard version of the
scripts remain detect-stylus free as it can work on the majority of
targets supported by OE without that now. If some legacy devices need
it, lets give them a machine specific customised xserver-common like
tslib. OE can handle that kind of thing really easily.

I make no comment about what GPE itself might want, the needs of GPE and
the needs of OE look to be differing but the patch is valid for OE's
needs even if not acceptable "upstream". Issues like this is one reason
poky "forked" those scripts as we knew our needs might not always match
GPEs or OEs.

Cheers,

Richard