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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox