Re: [xine-devel] [patch][xine-ui] dont redirect stdout in stdctl mode

[Darren S. <li...@yo...>]

I demand that Stas Sergeev may or may not have written...

> Darren Salt wrote:
>> I demand that Stas Sergeev may or may not have written...

> Please, what does this mean?

Read "The Hitch-Hiker's Guide to the Galaxy" and you may - or may not! - be
enlightened.
 
>>> You missed the rdtsc patches it seems. They are needed on x86_64, as
>>> otherwise the xine would just crash on startup.
>> They are?

> Sure. The "A" constraint on x86_64 seems to use the rax:rdx regs, while the
> rdtsc works exactly the way the x86 version works, that is, uses eax:edx.
> On x86_64, gcc moves only rdx to the "x" var.

Right...

>> It would? Works for me without these...

> I would post an assembly code here, but now as Diego have confirmed the
> crash, I think this is not necessary.

Fair enough...

>> Well... that or add a one-line summary and, optionally, a description to
>> each.

> If you really want this, then why not there is a patch tracker yet? :)

You can use the bug tracker for this; the same kind of thing applies there.
However, it's less convenient: it's necessary to visit the bug tracker
because attachments are not mailed to the bugs list.

> I of course can do what you say, but I wonder what will happen if I post,
> say, 10 patches in 10 separate mails, then post an updated versions on 6 of
> them in 6 mails more, and then another few updates. [...]

It can become confusing, certainly :-)

But if you send it as a follow-up to the replaced patch, that should help; so
long as the subject describes the patch and the start of the patch
description is clear, I don't see any particular problem - unless the patch
which it's replacing has been committed...

>> The ideal situation is that we can use 'hg import'

> Well, AFAICS xine-ui is not in a hg, only xine-lib is. So I don't think I
> can do that, or...?

True. However, I'm only concerned with the xine-lib patches.

> Btw, I am having a problem with current xine-lib code: the colors are
> completely messed up while playing all videos (mpeg4).

Which branch? Internal or external ffmpeg? If external, what revision no.?

Also, a sample video may help; if you're using any video post-plugins, switch
them off or play with their configurations to see if that helps. (For
example, I see overflow errors in the h1 and v1 filters in the 'pp'
post-plugin - some pixels which should be black are being shown as white.
OTOH, this error is documented in the source...)

> They all look greenish and weird. And on the xine-0.99.5 which comes in
> Fedora Extras, everything is fine.

Hmm. Presumably it's using Fedora-supplied xine-lib 1.1.6...?

> Just a quick query if maybe this is a known problem, or something on my
> side is wrong...

Right now, I couldn't say :-)

-- 
| Darren Salt    | linux or ds at              | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
| + Use more efficient products. Use less.          BE MORE ENERGY EFFICIENT.

Democracy is based on the theorem that many men are smarter than one.