[ptxdist] libjpeg-turbo and libjpeg

[ptxdist] libjpeg-turbo and libjpeg

[Guillermo Rodriguez Garcia]

[-- Attachment #1.1: Type: text/plain, Size: 1665 bytes --]

Hi all,

I need to use libjpeg-turbo for some apps that rely on specific
libjpeg-turbo extensions that are not available in the standard (IJG's)
libjpeg library. So I started to create a set of ptxdist rules for
libjpeg-turbo.

libjpeg-turbo is supposed to provide a drop-in replacement for the standard
IJG's libjpeg, and in fact many Linux distributions have already switched
to it. So most packages that currently depend on LIBJPEG should be able to
use libjpeg-turbo as well without any changes.

Example: gst-plugins-good1.in currently does the following:

select LIBJPEG if GST_PLUGINS_GOOD1_JPEG

However, gst-plugins-good1 should work just fine with libjpeg-turbo as
well. In fact the upstream gst-plugins already switched to libjpeg-turbo
some time ago (see the Cerbero scripts)

So, what is the recommended way to approach this in ptxdist? I can imagine
some options:

1. Provide a separate set of .in/.make files for libjpeg-turbo and a
separate LIBJPEG_TURBO package. So new packages that want to use
libjpeg-turbo would need to explicitly select LIBJPEG_TURBO (instead of
LIBJPEG). But this means that packages that currently use libjpeg would not
be able to benefit from the performance improvements in libjpeg-turbo. Also
I am not sure whether these two libraries (libjpeg and libjpeg-turbo) can
actually coexist in the same system.

2. Modify the LIBJPEG rules to provide an option to select between the
standard (IJG) libjpeg, or libjpeg-turbo. This would be similar to what is
done in alsa.in/alsa.make to select between the "full" and "light" versions
of the library.

3. Other?

Thank you,

Guillermo Rodriguez Garcia
guille.rodriguez@gmail.com

[-- Attachment #1.2: Type: text/html, Size: 2303 bytes --]

[-- Attachment #2: Type: text/plain, Size: 91 bytes --]

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] libjpeg-turbo and libjpeg

[Michael Olbrich]

Hi,

On Tue, Feb 13, 2018 at 10:23:09AM +0100, Guillermo Rodriguez Garcia wrote:
> I need to use libjpeg-turbo for some apps that rely on specific
> libjpeg-turbo extensions that are not available in the standard (IJG's)
> libjpeg library. So I started to create a set of ptxdist rules for
> libjpeg-turbo.
> 
> libjpeg-turbo is supposed to provide a drop-in replacement for the standard
> IJG's libjpeg, and in fact many Linux distributions have already switched
> to it. So most packages that currently depend on LIBJPEG should be able to
> use libjpeg-turbo as well without any changes.
> 
> Example: gst-plugins-good1.in currently does the following:
> 
> select LIBJPEG if GST_PLUGINS_GOOD1_JPEG
> 
> However, gst-plugins-good1 should work just fine with libjpeg-turbo as
> well. In fact the upstream gst-plugins already switched to libjpeg-turbo
> some time ago (see the Cerbero scripts)
> 
> So, what is the recommended way to approach this in ptxdist? I can imagine
> some options:
> 
> 1. Provide a separate set of .in/.make files for libjpeg-turbo and a
> separate LIBJPEG_TURBO package. So new packages that want to use
> libjpeg-turbo would need to explicitly select LIBJPEG_TURBO (instead of
> LIBJPEG). But this means that packages that currently use libjpeg would not
> be able to benefit from the performance improvements in libjpeg-turbo. Also
> I am not sure whether these two libraries (libjpeg and libjpeg-turbo) can
> actually coexist in the same system.

No.

> 2. Modify the LIBJPEG rules to provide an option to select between the
> standard (IJG) libjpeg, or libjpeg-turbo. This would be similar to what is
> done in alsa.in/alsa.make to select between the "full" and "light" versions
> of the library.

Either this ...

> 3. Other?

... or change the libjpeg rule to always build libjpeg-turbo instead.

I would prefer to avoid an option. But I'm not sure
1. if there are use-cases where libjpeg is preferable
2. if there are packages that fail to build with libjpeg-turbo

I have some libjpeg-turbo stuff lying around here somewhere. It was just
never finished. I've just dumped it in my test BSP so see if anythings
fails to build. I'll report the result later.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] libjpeg-turbo and libjpeg

[Guillermo Rodriguez Garcia]

[-- Attachment #1.1: Type: text/plain, Size: 2763 bytes --]

2018-02-13 16:37 GMT+01:00 Michael Olbrich <m.olbrich@pengutronix.de>:

> Hi,
>
> On Tue, Feb 13, 2018 at 10:23:09AM +0100, Guillermo Rodriguez Garcia wrote:
> > I need to use libjpeg-turbo for some apps that rely on specific
> > libjpeg-turbo extensions that are not available in the standard (IJG's)
> > libjpeg library. So I started to create a set of ptxdist rules for
> > libjpeg-turbo.
> >
> > libjpeg-turbo is supposed to provide a drop-in replacement for the
> standard
> > IJG's libjpeg, and in fact many Linux distributions have already switched
> > to it. So most packages that currently depend on LIBJPEG should be able
> to
> > use libjpeg-turbo as well without any changes.
> >
> > Example: gst-plugins-good1.in currently does the following:
> >
> > select LIBJPEG if GST_PLUGINS_GOOD1_JPEG
> >
> > However, gst-plugins-good1 should work just fine with libjpeg-turbo as
> > well. In fact the upstream gst-plugins already switched to libjpeg-turbo
> > some time ago (see the Cerbero scripts)
> >
> > So, what is the recommended way to approach this in ptxdist? I can
> imagine
> > some options:
> >
> > 1. Provide a separate set of .in/.make files for libjpeg-turbo and a
> > separate LIBJPEG_TURBO package. So new packages that want to use
> > libjpeg-turbo would need to explicitly select LIBJPEG_TURBO (instead of
> > LIBJPEG). But this means that packages that currently use libjpeg would
> not
> > be able to benefit from the performance improvements in libjpeg-turbo.
> Also
> > I am not sure whether these two libraries (libjpeg and libjpeg-turbo) can
> > actually coexist in the same system.
>
> No.
>
> > 2. Modify the LIBJPEG rules to provide an option to select between the
> > standard (IJG) libjpeg, or libjpeg-turbo. This would be similar to what
> is
> > done in alsa.in/alsa.make to select between the "full" and "light"
> versions
> > of the library.
>
> Either this ...
>
> > 3. Other?
>
> ... or change the libjpeg rule to always build libjpeg-turbo instead.
>
> I would prefer to avoid an option. But I'm not sure
> 1. if there are use-cases where libjpeg is preferable
> 2. if there are packages that fail to build with libjpeg-turbo
>

Judging from the wide adoption of libjpeg-turbo by many popular Linux
distros, I'd say that if we had to choose one, libjpeg-turbo may actually
be the "safe" choice.


>
> I have some libjpeg-turbo stuff lying around here somewhere. It was just
> never finished. I've just dumped it in my test BSP so see if anythings
> fails to build. I'll report the result later.
>

Let me know if you need help; I am also working on this now (since I do
have an app that explicitly needs libjpeg-turbo and doesn't work with the
stock libjpeg)

Best,

Guillermo Rodriguez Garcia
guille.rodriguez@gmail.com

[-- Attachment #1.2: Type: text/html, Size: 3919 bytes --]

[-- Attachment #2: Type: text/plain, Size: 91 bytes --]

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] libjpeg-turbo and libjpeg

[Michael Olbrich]

On Tue, Feb 13, 2018 at 05:12:14PM +0100, Guillermo Rodriguez Garcia wrote:
> 2018-02-13 16:37 GMT+01:00 Michael Olbrich <m.olbrich@pengutronix.de>:
> > On Tue, Feb 13, 2018 at 10:23:09AM +0100, Guillermo Rodriguez Garcia wrote:
> > > I need to use libjpeg-turbo for some apps that rely on specific
> > > libjpeg-turbo extensions that are not available in the standard (IJG's)
> > > libjpeg library. So I started to create a set of ptxdist rules for
> > > libjpeg-turbo.
> > >
> > > libjpeg-turbo is supposed to provide a drop-in replacement for the
> > standard
> > > IJG's libjpeg, and in fact many Linux distributions have already switched
> > > to it. So most packages that currently depend on LIBJPEG should be able
> > to
> > > use libjpeg-turbo as well without any changes.
> > >
> > > Example: gst-plugins-good1.in currently does the following:
> > >
> > > select LIBJPEG if GST_PLUGINS_GOOD1_JPEG
> > >
> > > However, gst-plugins-good1 should work just fine with libjpeg-turbo as
> > > well. In fact the upstream gst-plugins already switched to libjpeg-turbo
> > > some time ago (see the Cerbero scripts)
> > >
> > > So, what is the recommended way to approach this in ptxdist? I can
> > imagine
> > > some options:
> > >
> > > 1. Provide a separate set of .in/.make files for libjpeg-turbo and a
> > > separate LIBJPEG_TURBO package. So new packages that want to use
> > > libjpeg-turbo would need to explicitly select LIBJPEG_TURBO (instead of
> > > LIBJPEG). But this means that packages that currently use libjpeg would
> > not
> > > be able to benefit from the performance improvements in libjpeg-turbo.
> > Also
> > > I am not sure whether these two libraries (libjpeg and libjpeg-turbo) can
> > > actually coexist in the same system.
> >
> > No.
> >
> > > 2. Modify the LIBJPEG rules to provide an option to select between the
> > > standard (IJG) libjpeg, or libjpeg-turbo. This would be similar to what
> > is
> > > done in alsa.in/alsa.make to select between the "full" and "light"
> > versions
> > > of the library.
> >
> > Either this ...
> >
> > > 3. Other?
> >
> > ... or change the libjpeg rule to always build libjpeg-turbo instead.
> >
> > I would prefer to avoid an option. But I'm not sure
> > 1. if there are use-cases where libjpeg is preferable
> > 2. if there are packages that fail to build with libjpeg-turbo
> >
> 
> Judging from the wide adoption of libjpeg-turbo by many popular Linux
> distros, I'd say that if we had to choose one, libjpeg-turbo may actually
> be the "safe" choice.
> 
> 
> >
> > I have some libjpeg-turbo stuff lying around here somewhere. It was just
> > never finished. I've just dumped it in my test BSP so see if anythings
> > fails to build. I'll report the result later.
> >
> 
> Let me know if you need help; I am also working on this now (since I do
> have an app that explicitly needs libjpeg-turbo and doesn't work with the
> stock libjpeg)

My test build looks good. No failed packages. So I pushed what I have to
master. Please test it and compare it with what you have so far.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] libjpeg-turbo and libjpeg

[Guillermo Rodriguez Garcia]

[-- Attachment #1.1: Type: text/plain, Size: 4327 bytes --]

Hi Michael,

2018-02-14 8:49 GMT+01:00 Michael Olbrich <m.olbrich@pengutronix.de>:

> On Tue, Feb 13, 2018 at 05:12:14PM +0100, Guillermo Rodriguez Garcia wrote:
> > 2018-02-13 16:37 GMT+01:00 Michael Olbrich <m.olbrich@pengutronix.de>:
> > > On Tue, Feb 13, 2018 at 10:23:09AM +0100, Guillermo Rodriguez Garcia
> wrote:
> > > > I need to use libjpeg-turbo for some apps that rely on specific
> > > > libjpeg-turbo extensions that are not available in the standard
> (IJG's)
> > > > libjpeg library. So I started to create a set of ptxdist rules for
> > > > libjpeg-turbo.
> > > >
> > > > libjpeg-turbo is supposed to provide a drop-in replacement for the
> > > standard
> > > > IJG's libjpeg, and in fact many Linux distributions have already
> switched
> > > > to it. So most packages that currently depend on LIBJPEG should be
> able
> > > to
> > > > use libjpeg-turbo as well without any changes.
> > > >
> > > > Example: gst-plugins-good1.in currently does the following:
> > > >
> > > > select LIBJPEG if GST_PLUGINS_GOOD1_JPEG
> > > >
> > > > However, gst-plugins-good1 should work just fine with libjpeg-turbo
> as
> > > > well. In fact the upstream gst-plugins already switched to
> libjpeg-turbo
> > > > some time ago (see the Cerbero scripts)
> > > >
> > > > So, what is the recommended way to approach this in ptxdist? I can
> > > imagine
> > > > some options:
> > > >
> > > > 1. Provide a separate set of .in/.make files for libjpeg-turbo and a
> > > > separate LIBJPEG_TURBO package. So new packages that want to use
> > > > libjpeg-turbo would need to explicitly select LIBJPEG_TURBO (instead
> of
> > > > LIBJPEG). But this means that packages that currently use libjpeg
> would
> > > not
> > > > be able to benefit from the performance improvements in
> libjpeg-turbo.
> > > Also
> > > > I am not sure whether these two libraries (libjpeg and
> libjpeg-turbo) can
> > > > actually coexist in the same system.
> > >
> > > No.
> > >
> > > > 2. Modify the LIBJPEG rules to provide an option to select between
> the
> > > > standard (IJG) libjpeg, or libjpeg-turbo. This would be similar to
> what
> > > is
> > > > done in alsa.in/alsa.make to select between the "full" and "light"
> > > versions
> > > > of the library.
> > >
> > > Either this ...
> > >
> > > > 3. Other?
> > >
> > > ... or change the libjpeg rule to always build libjpeg-turbo instead.
> > >
> > > I would prefer to avoid an option. But I'm not sure
> > > 1. if there are use-cases where libjpeg is preferable
> > > 2. if there are packages that fail to build with libjpeg-turbo
> > >
> >
> > Judging from the wide adoption of libjpeg-turbo by many popular Linux
> > distros, I'd say that if we had to choose one, libjpeg-turbo may actually
> > be the "safe" choice.
> >
> >
> > >
> > > I have some libjpeg-turbo stuff lying around here somewhere. It was
> just
> > > never finished. I've just dumped it in my test BSP so see if anythings
> > > fails to build. I'll report the result later.
> > >
> >
> > Let me know if you need help; I am also working on this now (since I do
> > have an app that explicitly needs libjpeg-turbo and doesn't work with the
> > stock libjpeg)
>
> My test build looks good. No failed packages. So I pushed what I have to
> master. Please test it and compare it with what you have so far.
>

No build issues here and I can confirm that both gst-plugins-good1 (with
the jpeg plugin) and imagemagick both work fine with libjpeg-turbo on my
target platform.

Some comments:

- According to the documentation (
https://github.com/libjpeg-turbo/libjpeg-turbo/blob/master/BUILDING.md), NASM
or YASM are required if building x86 or x86-64 SIMD extensions. I have not
verified this ,yself (I'm building for an ARM target) but since we are
enabling SIMD, shouldn't the .in file select HOST_NASM? (ideally for
ARCH_X86 only but it seems that this can't be checked in the .in file?)

- For ARM targets, --with-simd requires NEON support. Perhaps the .make
file should do something like this:

# For ARM, enable SIMD extensions only if NEON is available
ifdef PTXCONF_ARCH_ARM_NEON
LIBJPEG_CONF_OPT += --with-simd
endif
# For architectures other than ARM, enable SIMD extensions unconditionally
ifndef PTXCONF_ARCH_ARM
LIBJPEG_CONF_OPT += --with-simd
endif


Best regards,

Guillermo Rodriguez Garcia
guille.rodriguez@gmail.com

[-- Attachment #1.2: Type: text/html, Size: 6113 bytes --]

[-- Attachment #2: Type: text/plain, Size: 91 bytes --]

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] libjpeg-turbo and libjpeg

[Guillermo Rodriguez Garcia]

[-- Attachment #1.1: Type: text/plain, Size: 4906 bytes --]

2018-02-14 10:22 GMT+01:00 Guillermo Rodriguez Garcia <
guille.rodriguez@gmail.com>:

> Hi Michael,
>
> 2018-02-14 8:49 GMT+01:00 Michael Olbrich <m.olbrich@pengutronix.de>:
>
>> On Tue, Feb 13, 2018 at 05:12:14PM +0100, Guillermo Rodriguez Garcia
>> wrote:
>> > 2018-02-13 16:37 GMT+01:00 Michael Olbrich <m.olbrich@pengutronix.de>:
>> > > On Tue, Feb 13, 2018 at 10:23:09AM +0100, Guillermo Rodriguez Garcia
>> wrote:
>> > > > I need to use libjpeg-turbo for some apps that rely on specific
>> > > > libjpeg-turbo extensions that are not available in the standard
>> (IJG's)
>> > > > libjpeg library. So I started to create a set of ptxdist rules for
>> > > > libjpeg-turbo.
>> > > >
>> > > > libjpeg-turbo is supposed to provide a drop-in replacement for the
>> > > standard
>> > > > IJG's libjpeg, and in fact many Linux distributions have already
>> switched
>> > > > to it. So most packages that currently depend on LIBJPEG should be
>> able
>> > > to
>> > > > use libjpeg-turbo as well without any changes.
>> > > >
>> > > > Example: gst-plugins-good1.in currently does the following:
>> > > >
>> > > > select LIBJPEG if GST_PLUGINS_GOOD1_JPEG
>> > > >
>> > > > However, gst-plugins-good1 should work just fine with libjpeg-turbo
>> as
>> > > > well. In fact the upstream gst-plugins already switched to
>> libjpeg-turbo
>> > > > some time ago (see the Cerbero scripts)
>> > > >
>> > > > So, what is the recommended way to approach this in ptxdist? I can
>> > > imagine
>> > > > some options:
>> > > >
>> > > > 1. Provide a separate set of .in/.make files for libjpeg-turbo and a
>> > > > separate LIBJPEG_TURBO package. So new packages that want to use
>> > > > libjpeg-turbo would need to explicitly select LIBJPEG_TURBO
>> (instead of
>> > > > LIBJPEG). But this means that packages that currently use libjpeg
>> would
>> > > not
>> > > > be able to benefit from the performance improvements in
>> libjpeg-turbo.
>> > > Also
>> > > > I am not sure whether these two libraries (libjpeg and
>> libjpeg-turbo) can
>> > > > actually coexist in the same system.
>> > >
>> > > No.
>> > >
>> > > > 2. Modify the LIBJPEG rules to provide an option to select between
>> the
>> > > > standard (IJG) libjpeg, or libjpeg-turbo. This would be similar to
>> what
>> > > is
>> > > > done in alsa.in/alsa.make to select between the "full" and "light"
>> > > versions
>> > > > of the library.
>> > >
>> > > Either this ...
>> > >
>> > > > 3. Other?
>> > >
>> > > ... or change the libjpeg rule to always build libjpeg-turbo instead.
>> > >
>> > > I would prefer to avoid an option. But I'm not sure
>> > > 1. if there are use-cases where libjpeg is preferable
>> > > 2. if there are packages that fail to build with libjpeg-turbo
>> > >
>> >
>> > Judging from the wide adoption of libjpeg-turbo by many popular Linux
>> > distros, I'd say that if we had to choose one, libjpeg-turbo may
>> actually
>> > be the "safe" choice.
>> >
>> >
>> > >
>> > > I have some libjpeg-turbo stuff lying around here somewhere. It was
>> just
>> > > never finished. I've just dumped it in my test BSP so see if anythings
>> > > fails to build. I'll report the result later.
>> > >
>> >
>> > Let me know if you need help; I am also working on this now (since I do
>> > have an app that explicitly needs libjpeg-turbo and doesn't work with
>> the
>> > stock libjpeg)
>>
>> My test build looks good. No failed packages. So I pushed what I have to
>> master. Please test it and compare it with what you have so far.
>>
>
> No build issues here and I can confirm that both gst-plugins-good1 (with
> the jpeg plugin) and imagemagick both work fine with libjpeg-turbo on my
> target platform.
>
> Some comments:
>
> - According to the documentation (https://github.com/libjpeg-
> turbo/libjpeg-turbo/blob/master/BUILDING.md), NASM or YASM are required
> if building x86 or x86-64 SIMD extensions. I have not verified this ,yself
> (I'm building for an ARM target) but since we are enabling SIMD, shouldn't
> the .in file select HOST_NASM? (ideally for ARCH_X86 only but it seems that
> this can't be checked in the .in file?)
>
> - For ARM targets, --with-simd requires NEON support. Perhaps the .make
> file should do something like this:
>
> # For ARM, enable SIMD extensions only if NEON is available
> ifdef PTXCONF_ARCH_ARM_NEON
> LIBJPEG_CONF_OPT += --with-simd
> endif
> # For architectures other than ARM, enable SIMD extensions unconditionally
> ifndef PTXCONF_ARCH_ARM
> LIBJPEG_CONF_OPT += --with-simd
> endif
>

BTW one more comment:

If --with-jpeg8 is specified, --with-jpeg7 has no effect. See configure.ac:

  if test "x${with_jpeg8}" = "xyes"; then
    JPEG_LIB_VERSION=80
  else
    if test "x${with_jpeg7}" = "xyes"; then
      JPEG_LIB_VERSION=70
    else
      JPEG_LIB_VERSION=62
    fi
  fi

So you may want to remove --with-jpeg7 from the .make file.

Best,

Guillermo Rodriguez Garcia
guille.rodriguez@gmail.com

[-- Attachment #1.2: Type: text/html, Size: 7267 bytes --]

[-- Attachment #2: Type: text/plain, Size: 91 bytes --]

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de

Re: [ptxdist] libjpeg-turbo and libjpeg

[Michael Olbrich]

Hi,

On Wed, Feb 14, 2018 at 10:57:06AM +0100, Guillermo Rodriguez Garcia wrote:
> 2018-02-14 10:22 GMT+01:00 Guillermo Rodriguez Garcia <
> guille.rodriguez@gmail.com>:
> > No build issues here and I can confirm that both gst-plugins-good1 (with
> > the jpeg plugin) and imagemagick both work fine with libjpeg-turbo on my
> > target platform.
> >
> > Some comments:
> >
> > - According to the documentation (https://github.com/libjpeg-
> > turbo/libjpeg-turbo/blob/master/BUILDING.md), NASM or YASM are required
> > if building x86 or x86-64 SIMD extensions. I have not verified this ,yself
> > (I'm building for an ARM target) but since we are enabling SIMD, shouldn't
> > the .in file select HOST_NASM? (ideally for ARCH_X86 only but it seems that
> > this can't be checked in the .in file?)

Yes the dependency should be there. Hopefully my build tests will tell me
the same thing :-).
It's true, that we cannot define the dependency for x86 only, but maybe I
can hack this. I didn't bother with it for gst-libav but libjpeg is
significantly smaller. I need to think about this.

> > - For ARM targets, --with-simd requires NEON support. Perhaps the .make
> > file should do something like this:
> >
> > # For ARM, enable SIMD extensions only if NEON is available
> > ifdef PTXCONF_ARCH_ARM_NEON
> > LIBJPEG_CONF_OPT += --with-simd
> > endif
> > # For architectures other than ARM, enable SIMD extensions unconditionally
> > ifndef PTXCONF_ARCH_ARM
> > LIBJPEG_CONF_OPT += --with-simd
> > endif

Indeed.

> BTW one more comment:
> 
> If --with-jpeg8 is specified, --with-jpeg7 has no effect. See configure.ac:
> 
>   if test "x${with_jpeg8}" = "xyes"; then
>     JPEG_LIB_VERSION=80
>   else
>     if test "x${with_jpeg7}" = "xyes"; then
>       JPEG_LIB_VERSION=70
>     else
>       JPEG_LIB_VERSION=62
>     fi
>   fi
> 
> So you may want to remove --with-jpeg7 from the .make file.

We try to set all regular options, even if they are no-ops. This way, the
next person doing a version bump won't have to recheck existing options.

Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de