[yocto] cups 2.2.2 Backend filter not include serial port support.

[Life Life]

Hello,

I'm try to build cups 2.2.2. It is not included serial backend support.
How to enable serial port backend support ?

Thanks.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Fwd: cups 2.2.2 Backend filter not include serial port support.

[Life Life]

Hello,

I'm try to build cups 2.2.2. It is not included serial backend support.
How to enable serial port backend support ?

Thanks.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi] gles2 on raspi3

[Trevor Woerner]

Hi,

I seem to have all the pieces in place, but can't get gles2 to work on the
raspberry pi. Specifically I'm using the raspberry pi 3, but the 32-bit armv7
build.

gles2 is provided by userland, and I've compiled up a couple gles2 programs.
Compiling succeeds without issue, but running is another case.

E.g.

# es2_info
Error: eglGetDisplay() failed

# glmark2-es2
Error: eglGetDisplay() failed with error: 0x3000
Error: eglGetDisplay() failed with error: 0x3000
Error: main: Could not initialize canvas

# google-chrome --use-gl=egl
[3487:3487:0415/14:ERROR:gl_surface_egl.cc(605)] EGL display query 
failed with error EGL_SUCCESS
[3487:3487:0415/14:ERROR:gl_surface_egl.cc(612)] eglInitialize 
Default failed with error EGL_BAD_DISPLAY
[3487:3487:0415/14:ERROR:gl_initializer_x11.cc(142)] 
GLSurfaceEGL::InitializeOneOff failed.
[3487:3487:0415/14:ERROR:sandbox_linux.cc(343)] InitializeSandbox() 
called with multiple threads in process gpu-process. 
[3487:3487:0415/14:ERROR:gpu_child_thread.cc(348)] Exiting GPU 
process due to errors during initialization

Thoughts?

Does anyone have any of these (or something else?) working?

Thanks and best regards,
Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] unpacking deb packages

[Markus Volk]

Thank you for the reply.

It looks like the problem is gone.

i guess this one fixed it

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=283a9b3883083e45bbdaf0488a3c6c76c5b197d7


Am 14.04.2017 um 01:09 schrieb Burton, Ross:


On 10 April 2017 at 14:32, Markus Volk > wrote:


i´m building  for x86_64 using the recent master branch and
encounter problems when fetching deb packages.
With any .deb file inside SRC_URI the task do_unpack stops with
this output:

... data.tar.xz && tar --no-same-owner -xpf data.tar.xz && rm
data.tar.xz failed with return value 2
if i  retry building the same recipe for 1-5 times without any
change the task sometime completes without errors


My immediate hunch would be that it can't find a xz binary inside the 
native sysroot as it hasn't been written in there yet.  Can you 
provide a minimal recipe to test?


Ross


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Static Lib build.

[Life Life]

Hello,

I'm try to build static library for SDK.

Update the build/local.conf file with the following information

SDKIMAGE_FEATURES = "staticdev-pkgs dev-pkgs"

INHERIT += "buildhistory"
BUILDHISTORY_COMMIT = "0"
 BUILDHISTORY_FEATURES = "sdk"

But cannot create static library for SDK.


Thanks.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] yocto mail list send.

[Life Life]

Hi Sir,

I can not send mail "yocto@yoctoproject.org" though I have a valid
membership. Please check and help me.

Thanks.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] gles2 on raspi3

[Andreas Müller]

On Sat, Apr 15, 2017 at 3:39 PM, Trevor Woerner  wrote:
> Hi,
>
> I seem to have all the pieces in place, but can't get gles2 to work on the
> raspberry pi. Specifically I'm using the raspberry pi 3, but the 32-bit armv7
> build.
>
> gles2 is provided by userland, and I've compiled up a couple gles2 programs.
> Compiling succeeds without issue, but running is another case.
>
> E.g.
>
> # es2_info
> Error: eglGetDisplay() failed
>
> # glmark2-es2
> Error: eglGetDisplay() failed with error: 0x3000
> Error: eglGetDisplay() failed with error: 0x3000
> Error: main: Could not initialize canvas
>
> # google-chrome --use-gl=egl
> [3487:3487:0415/14:ERROR:gl_surface_egl.cc(605)] EGL display 
> query failed with error EGL_SUCCESS
> [3487:3487:0415/14:ERROR:gl_surface_egl.cc(612)] eglInitialize 
> Default failed with error EGL_BAD_DISPLAY
> [3487:3487:0415/14:ERROR:gl_initializer_x11.cc(142)] 
> GLSurfaceEGL::InitializeOneOff failed.
> [3487:3487:0415/14:ERROR:sandbox_linux.cc(343)] 
> InitializeSandbox() called with multiple threads in process gpu-process.
> [3487:3487:0415/14:ERROR:gpu_child_thread.cc(348)] Exiting GPU 
> process due to errors during initialization
>
> Thoughts?
>
> Does anyone have any of these (or something else?) working?
>
Ehm userland gles2 on X11? I would not expect that to work. Experts
correct me but userland acceleration works for fullscreen apps only.
Why not using FOSS VC4+mesa?

Andreas
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] gles2 on raspi3

[Trevor Woerner]

On Sat 2017-04-15 @ 04:46:14 PM, Andreas Müller wrote:
> > Does anyone have any of these (or something else?) working?
> >
> Ehm userland gles2 on X11? I would not expect that to work. Experts
> correct me but userland acceleration works for fullscreen apps only.

I have made this work before (which, as you'll see later in this email,
doesn't imply that's how it's supposed to work!):
https://twoerner.blogspot.ca/2015/09/oe-build-of-glmark2-running-on.html

Oh, and I did try both with and without "--fullscreen".

> Why not using FOSS VC4+mesa?

Now's probably a good time to point out I only have a vague idea of what I'm
doing ;-)

I didn't try vc4 because the raspi recipes implied (to me) it was for aarch64
only. The "vc4graphics" MACHINE_FEATURES is only added for raspberrypi3-64.
I'll give this a try though.

Here's another question that only shows my inexperience in this area... does
using mesa always imply software-only rendering? mali (for example) would be
hardware rendering (though through a binary blob) and mesa is the software
fallback?

By the way, with my current setup I have been able to run openGL apps (e.g.
glmark2 by itself) albeit most definitely non-accelerated!

A lot of google searches talk about setting environment variables. Are there
any that might apply?

Best regards,
Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] gles2 on raspi3

[Andreas Müller]

On Sat, Apr 15, 2017 at 6:35 PM, Trevor Woerner  wrote:
> On Sat 2017-04-15 @ 04:46:14 PM, Andreas Müller wrote:
>> > Does anyone have any of these (or something else?) working?
>> >
>> Ehm userland gles2 on X11? I would not expect that to work. Experts
>> correct me but userland acceleration works for fullscreen apps only.
>
> I have made this work before (which, as you'll see later in this email,
> doesn't imply that's how it's supposed to work!):
> https://twoerner.blogspot.ca/2015/09/oe-build-of-glmark2-running-on.html
>
> Oh, and I did try both with and without "--fullscreen".
>
>> Why not using FOSS VC4+mesa?
>
> Now's probably a good time to point out I only have a vague idea of what I'm
> doing ;-)
>
> I didn't try vc4 because the raspi recipes implied (to me) it was for aarch64
> only. The "vc4graphics" MACHINE_FEATURES is only added for raspberrypi3-64.
> I'll give this a try though.
Oh yes you are right - it is long time ago - maybe this was one of the
reasons for my vc4-only fork. I thought it is an option set in
local.conf.
>
> Here's another question that only shows my inexperience in this area... does
> using mesa always imply software-only rendering? mali (for example) would be
> hardware rendering (though through a binary blob) and mesa is the software
> fallback?
I am also no expert here but Mesa is the open source userspace part
for accelerated graphics. Mesa-SW rendering driver is a fallback in
case no driver is supported/implemented. This is what you have seen
for glmark2. Since the VC4-Mesa was implemented, for me RaspberryPi
turned into the reference hardware regarding graphics. You can have
accelerated X11 + wayland in one image without any trouble with proper
working modesetting (and HDMI sound is on it's way). I've never had
this before on other machines where closed source blobs do graphics
acceleration. Either you have fb only (no X11/wayland) or you have to
decide either X11 or wayland - and worst: With every new version of
xserver you have to expect trouble.
>
> By the way, with my current setup I have been able to run openGL apps (e.g.
> glmark2 by itself) albeit most definitely non-accelerated!
mesa-gl builds swrast - mentioned above
>
> A lot of google searches talk about setting environment variables. Are there
> any that might apply?
>
For the first shot I would add vc4graphics to MACHINE_FEATURES in
raspberrypi3.conf. The required settings should happen (see recipe
rpi-config).

In the long run I would start a discussion:

* Mesa/VC4 is not a machine feature only available on 64Bit Pi3 only:
It is common to all version of RaspberryPi. Using mesa should be a
decision easily selected by a setting somewhere. The only reason 64Bit
Pi3 gets VC4 by default is that userland is not working for 64Bit -
see commit 9d418db5ed2962821987ac90c07c3a61e40c0814)
* Why still use userland? Dropping it would make things MUCH easier:
All the decisions based vc4graphics in MACHINE_FEATURES could be
removed (that's what my fork does)

Andreas
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Symbolic link to ld-linux-armhf.so.3

[Alvaro Garcia]

Hi, I made a recipe for hamachi. Hamachi looks for /lib/ld-linux.so.3 but
in my poky build this file is /lib/ld-linux-armhf.so.3.

If I do ln -s /lib/ld-linux-armhf.so.3 /lib/ld-linux.so.3 hamachi runs fine
so the solution its just a symbolic link. My problem is that I cant make
this link from my recipe.

Into my do_install I do: ln -s /lib/ld-linux-armhf.so.3
${D}/lib/ld-linux.so.3
But later it does not exist in the rootfs. But if I do:
ln -sf/lib/ld-linux-armhf.so.3 ${D}/lib/MYPRETTYLIB
then the link "MYPRETTYLIB" is there. Its like "ld-linux.so.3" is forbidden
for some reason.

I read that some guy had this problem and solved it by using a glibc
bbappend but it didnt work for me.

Do I need to do something special to get the "ld-linux.so.3" link?

Thank you
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] gles2 on raspi3

[Trevor Woerner]

w00T! \O/

Swapping out meta-raspberrypi for your meta-raspi-light works!!! I now have
accelerated glmark2-es2 ~40FPS :-D

Now I have to figure out why...

Also, chromium wouldn't build with meta-raspi2-light, but that's probably a
quick fix, GL/glx.h was missing.

Adding 'MACHINE_FEATURES_append = " vc4graphics"' to local.conf with
meta-raspberrypi caused a kernel Oops. The system continues to run, but
graphics/X doesn't work.

One thing I've noticed about both meta-raspberrypi and meta-raspi-light are
that in both cases (using vc4) the boot colour square (firmware?), processor
core count berries, and kernel splash screen are missing. But that's not too
important.

Thank you very much for your explanations, they really cleared up a lot of
stuff in my head. Already I'm 10x smarter on this stuff (which doesn't say
much about where I started!) ;-) It was probably a good thing I spent the last
couple days grinding away, your explanations were perfect for where I'm at.

Any idea how mesa and mesa-gl differ? That one's still an outlier for me; they
both come from the same source base!

On Sat 2017-04-15 @ 08:09:02 PM, Andreas Müller wrote:
> In the long run I would start a discussion:
> 
> * Mesa/VC4 is not a machine feature only available on 64Bit Pi3 only:
> It is common to all version of RaspberryPi. Using mesa should be a
> decision easily selected by a setting somewhere. The only reason 64Bit
> Pi3 gets VC4 by default is that userland is not working for 64Bit -
> see commit 9d418db5ed2962821987ac90c07c3a61e40c0814)
> * Why still use userland? Dropping it would make things MUCH easier:
> All the decisions based vc4graphics in MACHINE_FEATURES could be
> removed (that's what my fork does)

Agreed! Maybe a new thread? I'd want to do more experiments wrt 32 vs 64 and
vc4 vs userland before being able to contribute.

On a related topic, I wasn't able to get any graphics to work when I did a
raspberrypi3-64 build, which (presumably) already pulled in and configured the
build for vc4. I'll dig in a bit more on that topic to see if I can reduce it
to some succinct issue.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto