Bug 2551

If this is FRI2 speific issue, I will not be able to test it, because I have FRI1 and not FRI2 yet.

It's not fri2-specific.  You should be able to do the same thing on crownbay.

Basically just remove the same bits for crownbay as were added for fri2 in this meta-intel commit:

8bc2fa135060e941bcbb4dcfb664e175a3eb871d

tomz: I am not fully clear about this task yet to estimate time needed. What is the mechanism to include or exclude (opt-in or opt-out) the video acceleration ?

To turn off the video acceleration, you should be able to just specify:

VA_FEATURES ?= ""

The problem is that the emgd recipe also pulls in the emgd video components, which have a dependency on libva, which normally the VA_FEATURES provide (via va-intel).  So if the above us used, building the filesystem fails because libva isn't pulled in.

So one fix would be to only include the emgd video components when the video feature is turned on, thus getting rid of the dependency on libva when the video feature is turned off.

Tom,

As I understand so far (which may be wrong), the new way to enable/disable video acceleration for a BSP is to have this line in the local.conf or not.

VA_FEATURES ?= ""

Having this line will disable video acceleration, and dropping this line will enable video acceleration.

Then would this functionality replace BSP configs like crownbay-noemgd ? if yes then when this functionality is enabled then, crownbay-noemgd kind of BSP configs will be removed from  meta-intel repo. And crownbay BSP config will handle both BSPs, with a setting in local.conf for enabling or disabling video acceleration.


If my understanding so far is correct, then following difference in crownbay & crownbay-noemgd BSP configs, need to be handled inside crownbay BSP config file only.

--- crownbay.conf
+++ crownbay-noemgd.conf	
@@ -9,19 +9,9 @@
 require conf/machine/include/tune-atom.inc
 require conf/machine/include/ia32-base.inc
 
-MACHINE_FEATURES += "gst-va-mixvideo"
-
 XSERVER ?= "${XSERVER_IA32_BASE} \
            ${XSERVER_IA32_EXT} \
-           ${XSERVER_IA32_EMGD} \
+           ${XSERVER_IA32_VESA} \
            "
 

Please confirm/correct my understanding so far.

Thanks,
Nitin

The intent with VA_FEATURES was that you put the below into the machine config to enable video acceleration:

VA_FEATURES ?= "gst-va-intel va-intel"

which would add video acceleration to that BSP by default, but and if you wanted to build that BSP without video acceleration, you'd put:

VA_FEATURES ?= ""

in your local.conf when building it.

So for example the first is added to the crownbay.conf, while for crownbay-noemgd.conf, there isn't a VA_FEATURES statement at all, meaning it never gets video acceleration.

So it has no bigger implication for the machine configs other than having a VA_FEATURES in a machine config means the machine gets video accceleration or it doesn't if not there, and if it does it's toggleable by emptying the string in e.g. local.conf.

Regardless of the question of whether it should be made into a more non-local feature, as it stands the problem with it is that, for the emgd case, setting VA_FEATURES ?= "" for crownbay (or simply removing VA_FEATURES altogether) causes a rootfs problem because the emgd recipe unconditionally brings in the mixvideo components, which require libva be included in the image to avoid the rootfs problem.  Adding the VA_FEATURES ?= "gst-va-intel va-intel" to the emgd BSP gets around the problem because it results in adding libva to the dependencies.

Tom,
 does it mean that, for the crownbay BSP Xserver always has EMGD driver, in both cases of video acceleration enabled or disabled?
 So the crownbay BSP may or may not have video acceleration but will use the EMGD Xserver driver. And crownbay-noemgd BSP will not have video acceleration and will have VESA Xserver driver instead of EMGD.

 This makes 3 configurations of BSPs for corwnbay:
  1. EMGD + VA : for graphics performance
  2. EMGD & no-VA
  3. VESA & no-EMGD & no-VA : for open license

I understand need of EMGD_VA & no-EMGD configurations. What is the need of EMGD + no-VA configuration?

Thanks,
Nitin

(In reply to comment #7)
> Tom,
>  does it mean that, for the crownbay BSP Xserver always has EMGD driver, in
> both cases of video acceleration enabled or disabled?
>  So the crownbay BSP may or may not have video acceleration but will use the
> EMGD Xserver driver. And crownbay-noemgd BSP will not have video
> acceleration and will have VESA Xserver driver instead of EMGD.
> 
>  This makes 3 configurations of BSPs for corwnbay:
>   1. EMGD + VA : for graphics performance
>   2. EMGD & no-VA
>   3. VESA & no-EMGD & no-VA : for open license
> 
> I understand need of EMGD_VA & no-EMGD configurations. What is the need of
> EMGD + no-VA configuration?
> 
> Thanks,
> Nitin

Yes, crownbay always uses emgd, but the user may not want video support, so should be able to turn off VA i.e. it's not a license consideration.

Tom,
 I am not finding any build issues with this.

1. added this to local.conf
  VA_FEATURES = ""
2. did this 1st:
  bitbake -f -c cleansstate va-intel gst-va-intel
3. then did this:
  bitbake core-image-sato

And this build did not build the cleaned VA components, and succeeded without any errors. And VA_FEATURES is set equal to "va-intel gst-va-intel" in crownbay.conf, which gets overridden by the local.conf setting.

Does this mean that, the issue is not present anymore?

Thanks,
Nitin

waiting confirmation from Tom.

With emgd 1.14, this no longer seems to be an issue.  Turning the VA_FEATURES off I had a successful build and didn't see any of the VA_FEATURES packages in the build.  So I'd say that if this is the case, it's no longer a problem.

Thanks tom for the confirmation.

With the new gst-ffmpeg LICENSE_FLAGS="commercial" change, we need to be able to build without video acceleration again, but trying that again now gives the same old problem.  I'll add something to fix this as part of dealing with the LICENSE_FLAGS, but just reopening this to track the problem until then.

poky/master: c4a923bcb0194c05b14d40be7ad4ecd193eb7a69
meta-intel/master: 8f9963b46f0923b6efd076e365f17b4a3de065e1

ERROR: Function failed: do_rootfs (see /home/trz/yocto/ffmpeg-off-test/build/tmp/work/crownbay-poky-linux/core-image-sato-1.0-r0/temp/log.do_rootfs.29673 for further information)
ERROR: Logfile of failure stored in: /home/trz/yocto/ffmpeg-off-test/build/tmp/work/crownbay-poky-linux/core-image-sato-1.0-r0/temp/log.do_rootfs.29673
Log data follows:
| DEBUG: Executing shell function do_rootfs
| Generating solve db for /home/trz/yocto/ffmpeg-off-test/build/tmp/deploy/rpm/crownbay...
| Generating solve db for /home/trz/yocto/ffmpeg-off-test/build/tmp/deploy/rpm/core2...
| Generating solve db for /home/trz/yocto/ffmpeg-off-test/build/tmp/deploy/rpm/all...
|    total:               1      0.000000 MB      4.258908 secs
|    fingerprint:      1134      0.056330 MB      0.396327 secs
|    install:           378      0.000000 MB      1.395128 secs
|    digest:            756      8.258656 MB      0.045984 secs
|    signature:         756      0.000000 MB      1.651027 secs
|    dbadd:             378      0.000000 MB      1.373580 secs
|    dbget:           17085      0.000000 MB      0.019269 secs
|    dbput:             378      4.558772 MB      0.702524 secs
|    readhdr:          3781      9.008704 MB      0.019153 secs
|    hdrload:          1896     13.500084 MB      0.020049 secs
|    hdrget:          67801      0.000000 MB      0.106189 secs
|    total:               1      0.000000 MB     61.959093 secs
|    fingerprint:     17382      0.213712 MB      1.121506 secs
|    install:          5794      0.000000 MB     24.355046 secs
|    digest:          11588     48.683034 MB      0.380680 secs
|    signature:       11588      0.000000 MB     25.559824 secs
|    dbadd:            5794      0.000000 MB     23.748516 secs
|    dbget:           79790      0.010656 MB      0.604791 secs
|    dbput:            5794     30.221040 MB     13.433801 secs
|    readhdr:         57941     60.178426 MB      0.258118 secs
|    hdrload:         30630     98.373902 MB      0.289933 secs
|    hdrget:        1092051      0.000000 MB      1.578090 secs
| Generating solve db for /home/trz/yocto/ffmpeg-off-test/build/tmp/deploy/rpm/all...
| Processing locale-base-en-us...
| Processing locale-base-en-gb...
| Processing packagegroup-core-ssh-dropbear...
| Processing packagegroup-core-x11-sato-games...
| Processing packagegroup-core-x11-base...
| Processing zypper...
| Processing psplash...
| Processing packagegroup-core-x11-sato...
| Processing packagegroup-base-extended...
| Processing rpm...
| Processing packagegroup-core-boot...
| error: Failed dependencies:
| 	libva.so.1 is needed by libegl1-1.14-r1.core2
| 	libva-tpi.so.1 is needed by libegl1-1.14-r1.core2
| 	libva-x11.so.1 is needed by libegl1-1.14-r1.core2
| ERROR: Function failed: do_rootfs (see /home/trz/yocto/ffmpeg-off-test/build/tmp/work/crownbay-poky-linux/core-image-sato-1.0-r0/temp/log.do_rootfs.29673 for further information)
ERROR: Task 7 (/home/trz/yocto/ffmpeg-off-test/meta/recipes-sato/images/core-image-sato.bb, do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 5504 tasks of which 360 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
  /home/trz/yocto/ffmpeg-off-test/meta/recipes-sato/images/core-image-sato.bb, do_rootfs
Summary: There were 26 WARNING messages shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

The issue is not present in the current master.

Tested with these commits.
poky master: 8b3aa00029e62df6d05710cf166fd5d09bdb29cf
meta-intel master: 1cd94a80c8481593f636076f55c89b1739ce46e2

I removed the "commercial" from LICENSE_FLAGS_WHITELIST, so that VA_FEATURES becomes empty disabling the va-intel parts. And come-image-sato builds fine.

Tested under the the same commits as Nitin (comment 14) by following the presented steps:
-> Build a core-image-sato for the FRI2
-> Add VA_FEATURES= "" in local.conf
-> Rebuild a core-image-sato for the FRI2

After the build is completed, I ran:
  bitbake -f -c cleansstate va-intel gst-va-intel
Result: va-intel and gst-va-intel are rebuilt.
The "commercial" flag must be removed from fri2.conf file? Or, if this changes the behavior, how can I remove it via local.conf file?

All the BSPs that don't use emgd have this, which completely turns off VA_FEATURES if 'commmercial' isn't in the whitelist (and the same thing could be accomplished by setting VA_FEATURES = "" in local.conf):

VA_FEATURES = "${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", \
	    "commercial", "gst-va-intel va-intel", "", d)}"

The emgd BSPS have this, which still adds va-intel for the reasons already mentioned in the discussion above (and why VA_FEATURES = "" for emgd BSPs like fri2 will also fail):

VA_FEATURES = "${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", \
	    "commercial", "gst-va-intel va-intel", "va-intel", d)}"

The reason as mentioned above as well is that the emgd install unconditioanlly adds the video components which have that dependency.

Getting rid of that dependency by separating out the video components was the original intent of his bug and what is discussed above.  If that's still a requirement for some reason, this bug should be re-opened and fixed as originally intended.

Tom, Darren,
  I am not clear why the VA_FEATURES line is different for FRI2 & crownbay in the previous comment to this. Shouldn't both be same?

I don't see any difference between what's in crownbay and what's in fri2 - please elaborate.

Tom, 
   My bad. I misunderstood your comment #16.

So if intention is to let a user disable VA from local.conf by defining VA_FEATURES as empty, then "va-intel" can be taken out from VA_FEATURES, and put into a new variable such as NEEDED_VA_FEATURES.

Is this an accepted solution?

Nitin

(In reply to comment #19)
> Tom, 
>    My bad. I misunderstood your comment #16.
> 
> So if intention is to let a user disable VA from local.conf by defining
> VA_FEATURES as empty, then "va-intel" can be taken out from VA_FEATURES, and
> put into a new variable such as NEEDED_VA_FEATURES.
> 
> Is this an accepted solution?
> 
> Nitin

OK, to recap, before the changes making ffmpeg 'commercial', a BSP could simply define a VA_FEATURES value that would unconditionally add video acceleration to the machine e.g.: 

VA_FEATURES ?= "gst-va-intel va-intel"

If the user didn't want video acceleration, he could override that with the following:

VA_FEATURES ?= ""

That wouldn't work if using emgd for the reasons mentioned (the emgd video components had a dependency on va-intel and thus would need to specify the following to get the same effect:

VA_FEATURES ?= "va-intel" 

The change to a 'commercial' license for one of the components doesn't really change things, other than the fact that if 'commercial' is not specified in LICENSE_FLAGS_WHITELIST, VA_FEATURES now defaults to "va-intel" for the emgd BSPs and avoids the build problem by default (which turns off video acceleration as a side effect):

VA_FEATURES = "${@bb.utils.contains("LICENSE_FLAGS_WHITELIST", \
	    "commercial", "gst-va-intel va-intel", "va-intel", d)}"

In this case as well, if the user specifies

VA_FEATURES ?= ""

to turn off video acceleration, the build problem will still occur.

The build needs to still work if the user does this, and furthermore the 'commercial' restriction on video acceleration due to ffmpeg will soon go away, so VA_FEATURES ?= "" will have to work at that point.

Packaging the video components separately should fix this problem i.e. if the user specifies VA_FEATURES ?= "" in emgd, the effect would be that the video package would not be included in that case.  There is a more explicit bug for that in case we need it, but I was thinking it may be a duplicate of this, since I don't see a need for that bug outside of this one.

Bug 3258 - EMGD should package MIX separately
https://bugzilla.yoctoproject.org/show_bug.cgi?id=3258

I have these lines in local.conf

MACHINE = "crownbay"
LICENSE_FLAGS_WHITELIST += "license_emgd-driver-bin_1.14"
LICENSE_FLAGS_WHITELIST += "commercial"
VA_FEATURES = ""

And the build of core-image-sato succeeded fine.

Does that mean this issue is not present anymore?

(In reply to comment #21)
> I have these lines in local.conf
> 
> MACHINE = "crownbay"
> LICENSE_FLAGS_WHITELIST += "license_emgd-driver-bin_1.14"
> LICENSE_FLAGS_WHITELIST += "commercial"
> VA_FEATURES = ""
> 
> And the build of core-image-sato succeeded fine.
> 
> Does that mean this issue is not present anymore?

Can you explain why?

We closed it once before because it 'worked' but had to re-open it again because it really didn't.

I think the underlying problem is still the same.

I think it was reopened because something (probably packaging changes of related recipes) broke it again. I think this time Ross's changes for packaging of graphics related recipes are fixing the issue this time.
  IMO the test I did last in the comment #21 says that the issue is not present now. If that is not the case then, what is the criteria to say that the issue is still present?

(In reply to comment #23)
> I think it was reopened because something (probably packaging changes of
> related recipes) broke it again. I think this time Ross's changes for
> packaging of graphics related recipes are fixing the issue this time.
>   IMO the test I did last in the comment #21 says that the issue is not
> present now. If that is not the case then, what is the criteria to say that
> the issue is still present?

Well, the issue is still present because the emgd recipe still unconditionally installs the mixvideo components, which still require libva.

So it's still a requirement that libva be installed if emgd is installed, which it shouldn't be.  If [Bug 3258 - EMGD should package MIX separately] is implemented  (which should actually be a duplicate of this bug and I was just about to mark it as such as mentioned in that bug some weeks ago), then libva indeed will not be required if the user doesn't include the mixvideo components.

It may be that your build again included libva even though you specified VA_FEATURES ?= "" and you didn't see the problem again, but at some point another change may take libva out again and the problem will reappear.

So unless you can explain why this is by design rather than accident no longer a problem, or change the criteria to require the user always has to install video if they install emgd, this bug should remain open.

Since we have a workaround we can release note, this shouldn't be a blocker for 1.3, but it shouldn't be closed either.

Document for 1.3, THEN move to 1.4

*** Bug 3258 has been marked as a duplicate of this bug. ***

Here's the 1.3 meta-intel release not for this bug:

For meta-intel BSPs, users can normally specify the following in their local.conf:

VA_FEATURES ?= ""

which essentially says that they don't want video acceleration features in their images.

For BSPs that use EMGD (crownbay, fri2, sys940x) however, VA_FEATURES must include "va-intel" rather than the empty string: 

VA_FEATURES ?= "va-intel"

The reasons for this are detailed in Yocto Bug 2551 [EMGD requires video acceleration].

2nd try [minor fixes]

Here's the 1.3 meta-intel release note for this bug:

For meta-intel BSPs, users can normally specify the following in their local.conf in order to disable video acceleration for the BSP:

VA_FEATURES ?= ""

This essentially tells the build not to include any video acceleration features in the image.

For BSPs that use EMGD (crownbay, fri2, sys940x), however, VA_FEATURES must include "va-intel" rather than the empty string: 

VA_FEATURES ?= "va-intel"

The reasons for this are detailed in Yocto Bug 2551 [EMGD requires video acceleration].

A patch sent to meta-intel ML which fixes this. - Nitin

Fixed by meta-intel commit: 95c9b6ced869ebab7c778b2741c963496140c00f