Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Saul Wold <sgw@linux.intel.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
	 openembedded-core@lists.openembedded.org
Cc: "jianxun.zhang@intel.com" <jianxun.zhang@intel.com>
Subject: Re: [PATCH] xf86-video-intel: Add UXA PACKAGECONFIG and 20-intel.conf
Date: Mon, 28 Mar 2016 16:01:43 -0700	[thread overview]
Message-ID: <1459206103.18406.124.camel@linux.intel.com> (raw)
In-Reply-To: <1459204429.21672.15.camel@linuxfoundation.org>

On Mon, 2016-03-28 at 23:33 +0100, Richard Purdie wrote:
> On Mon, 2016-03-28 at 11:07 -0700, Saul Wold wrote:
> > 
> > This patch adds the UXA Packageconfig option to handle older Intel
> > Graphics
> > the uxa code when enabled needs a patch from upstream due to a
> > change
> > in the
> > API of the Xserver.
> > 
> > Also added a generic 20-intel.conf with a commented line to enable
> > the uxa
> > AccelMethod option.
> > 
> > The Packageconfig only needs to be enabled in genericx86-64 since
> > other
> > MACHINE configs (such as meta-intel) include the VAAPI acceleration
> > that
> > handle the graphics hardware corretly.
> This doesn't really look right to me. It makes the driver MACHINE
> specific which is generally bad and will fail various tests. You
> likely
> need to detect this at runtime on the relevant hardward and enable
> if/as/when needed.
> 
Yeah, I had a thought that this might cause a MACHINE specific issue,
but wanted to get eyes on the issue.

Your right this could be another example of where the Runtime Machine
Config could help, I will add it to Jianxun's list.

> Is there some way that X can correctly autodetect what its running on
> and do the right thing without requiring manual config? The fact
> we're
> having to do that seems to fly in the face of the "configurationless"
> goals X has had more recently...
> 
Unfortunately X will start correctly with the newer AccelMethod which
this particular hardware does not handle well.

Let's hold off on this patch for now, we understand that basics, better
than we did yesterday and can get it logged in the Bug.

Sau!


> Cheers,
> 
> Richard


      reply	other threads:[~2016-03-28 23:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-28 18:07 [PATCH] xf86-video-intel: Add UXA PACKAGECONFIG and 20-intel.conf Saul Wold
2016-03-28 22:33 ` Richard Purdie
2016-03-28 23:01   ` Saul Wold [this message]

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=1459206103.18406.124.camel@linux.intel.com \
    --to=sgw@linux.intel.com \
    --cc=jianxun.zhang@intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.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