From: Richard Purdie <rpurdie@rpsys.net>
To: Florian Boor <florian.boor@kernelconcepts.de>
Cc: openembedded-devel@openembedded.org
Subject: Re: [oe-commits] org.oe.dev xserver-common 1.13: Re-add calibrate-only-if-ts.patch after merge.
Date: Thu, 22 Feb 2007 00:49:08 +0000 [thread overview]
Message-ID: <1172105348.5790.71.camel@localhost.localdomain> (raw)
In-Reply-To: <45DCD020.1050002@kernelconcepts.de>
On Thu, 2007-02-22 at 00:05 +0100, Florian Boor wrote:
> Richard Purdie wrote:
> > 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.
>
> It should not be necessary to have machine specific versions of that package
> which is something we should try to avoid where ever possible.
> Just make that patch a little bit more smart... maybe check if TSLIB_TSDEVICE is
> set and honor is in this case.
If it references detect-stylus in the script, it RDEPENDS on
detect-stylus and we have a needless dependency. This is why I'm
suggesting two versions as a lot of devices don't need that dependency.
> > 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
>
> Well... in this case it is that easy to avoid forking, so why wasting
> time maintaining a fork?
I didn't and don't want to spend time having to justify whatever changes
we make in poky in that area to OE/GPE/whoever. I can guarantee I've
already spent more time in this thread than any time I've spent
maintaining that "fork". I say "fork" as I'm not blocking changes
passing to/from poky, I actively encourage it and if I made any
fundamental changes useful to upstream I would pass them on. I just know
we need certain changes in Poky but I know upstream won't like certain
changes and therefore I choose not to sync them. Some of the changes
we're discussing originated in poky which kind of proves my point :-(.
Cheers,
Richard
next prev parent reply other threads:[~2007-02-22 0:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1HFb2e-0007GK-Jp@linuxtogo.org>
2007-02-19 16:27 ` [oe-commits] org.oe.dev xserver-common 1.13: Re-add calibrate-only-if-ts.patch after merge Florian Boor
2007-02-20 20:55 ` Paul Sokolovsky
2007-02-20 22:14 ` Richard Purdie
2007-02-21 23:05 ` Florian Boor
2007-02-22 0:49 ` Richard Purdie [this message]
2007-02-22 7:23 ` Koen Kooi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1172105348.5790.71.camel@localhost.localdomain \
--to=rpurdie@rpsys.net \
--cc=florian.boor@kernelconcepts.de \
--cc=openembedded-devel@lists.openembedded.org \
--cc=openembedded-devel@openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.