[MPlayer-dev-eng] [PATCH] Support for QNX: QSA audio and Photon GUI.

[Mike Gorchak]

Hi Reimar,

> One problem is that the patch is mangled, there are linebreaks
> that shouldn't be there.
> That makes it impossible to apply.

This time I've attached patch and ao, vo code separately. Attached
vo_photon.c is a bit newer than in the patch, since I'm working on it.

> It would also be a good bit easier to review if the ao and vo
> was separate, but much more importantly the configure changes
> that don't have anything to do with ao and vo definitely should be
> separate.

Do I have to re-create the patch and remove ao/vo unrelated
modifications in the configure script?

>> +echores "$_qnx_cam"
>> +fi #if qnx
> These defines seem unused.

I planned to use them in VCD and CDDA modules a bit later.

>> +echocheck "QSA audio"
>> +if test "$_qsa" = auto ; then
>> +  _qsa=no
>> +  header_check sys/asoundlib.h -lasound $ld_dl $ld_pthread && _qsa=yes
>
> This check is 100% identical to the Linux ALSA check.

No, not identical. ALSA headers are located in the alsa/ subdirectory,
while QSA headers are always in sys/ subdirectory.

> This can't be working correctly.

It works correct.

> In fact, your ao_qsa seems to simply reimplement ao_alsa?!?!

No, QSA is based on ALSA 0.5 API, but not the ALSA source (FYI when
mplayer had ao_alsa5 module - it does not work well in QSA
environment). But further improvements of QSA made it uncompatible
with ALSA 0.5.

> These seem unrelated to the ao/vo, and what does _qnx_cam have
> to do with dvdread?

This is how this check works in configure script, it checks for OS and
then for raw read API/header. To pass this check I had to introduce
_qnx_cam, cam is not abbrevation for camera, it is a block device
subsystem in QNX. You could take a look on to dvdcss library, where
this interface already is used.

> Also unrelated to ao/vo support.

Could you ignore all patches unrelated to ao/vo, I will create a
separate patch for all unrelated stuff a bit later.

>> +#elif defined(__QNXNTO__)
>> +#include <gulliver.h>
>> +#define B2N_16(x) x = ENDIAN_SWAP16(x)
>> +#define B2N_32(x) x = ENDIAN_SWAP32(x)
>> +#define B2N_64(x) x = ENDIAN_SWAP64(x)
>
> libdvdread is a separate project, you should send the patch to them.
> Though IMHO it would be better to just always use the fallback code,
> and maybe the gcc bultins.
> I don't think using the OS-specific stuff has much value.

Ok.

>> +    switch (photon_mplayer_format)
>> +    {
>> +        case IMGFMT_YUY2:
>> +        case IMGFMT_YVYU:
>
> I think you should be able to avoid this switch and reduce the code
> size a lot by using vo_get_draw_alpha.

Yes, but vo_get_draw_alpha does not support V422 format and some other
which will be added later.

> I'll probably have a lot more comments on the vo, but I don't
> have time to review in detail right now.

Ok, thank you. What I have to do to apply at least vo/ao patches to
mplayer main source tree?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ao_qsa.c
Type: text/x-csrc
Size: 11750 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20130204/ec66f720/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer-qnx.diff
Type: application/octet-stream
Size: 78281 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20130204/ec66f720/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vo_photon.c
Type: text/x-csrc
Size: 54288 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20130204/ec66f720/attachment-0003.bin>