On Tue, Sep 14, 2004 at 09:09:00PM +0200, Lucian Muresan wrote:
> Hi,
> 
> 
> Denis Oliver Kropp wrote:
> > Hi,
> >
> > please have a look at the new IDirectFBScreen API.
> 
> > Unfortunately, there's no real support for this new API in the Matrox
> > driver, yet.
> >
> > Apart from that the API is not finished and might lack certain 
> configuration
> > scenarios or hardware capabilities. Any help to hammer out the API is
> > welcome ;)
> 
> Well, thank you for that. But is there any other driver which is already 
> using this API?

No.

> I finished soldering my switching cable. Works perfect under windows 
> (changing cable setting in the PowerDesk driver from both "Composite or 
> S-video" and "SCART-composite" to "SCART-RGB" and back does show some 
> difference in image quality, and the "SCART-RGB" setting switches the TV 
> set into AV-mode. Setting any of the non-RGB modes "releases" the TV-set 
> on it's own AV setting (i.e. via the button on the remote).
> 
> Under DirectFB (CVS from 2 weeks ago I think), it only partially works. 
> There are several things which I find strange:
> 
> 1. If I set "matrox-cable-type=scart-rgb" in my htpc's directfbrc and 
> let it boot up with Freevo (using SDL and DirectFB), the scart 
> connection doesn't switch my TV automatically. If I manually switch the 
> TV to AV-mode, the image is there and looks really crisp (ma cable is 
> rather short, and I've done it of 6 high-quality thin coax cables, so 
> Ican't really tell just by looking at the Freevo image if it's RGB or 
> composite mode). So this was the case right at the first run of Freevo.

Are you sure it's actually reading the config file on the first run?

> 2. Now if I quit freevo and start it again, without changing the 
> "matrox-cable-type=scart-rgb" setting, it behaves like expected, my TV 
> is automatically switched into AV-mode and I cannot switch back to the 
> TV-s own tuner input from the remote, as long as the DirectFB 
> application (freevo) is running. If I now quit again freevo, the 
> switching signal disappeares as expected and I can zap my TV (why does 
> this not work in the scenario 1., at the first run of the directfb 
> application? Is it just plain composite instead of Scart-rgb? I'd think 
> so.).
> 
> 3. Now comes the really strange part. I expected to have no switching 
> signal at all, when I set "matrox-cable-type=composite", just like in 
> windows. But after having once runned DirectFB with setting SCART-RGB 
> and then quit and changed to COMPOSITE, run again, the signal is again 
> RGB, because it switches (I know that, because my cable doesn't switch 
> 12V out of nowhere, only when the RGB_ENABLE signal raises..
> I would have expected to be able to use this setting for resetting the 
> switching signal applied on the scart, but there must be something still 
> wrong in that part of the code, maybe some unclean initialized flags, 
> when setting the maven registers to do so. Until we won't get that 
> fixed, it wouldn't make sense for me to try to implement this "on the 
> fly switching" feature I started this thread with.

You have to compare the registers values and

> 
> 4. Even sranger: The setting "matrox-cable-type=scart-composite" changed 
> after once have runned directfb with scart-rgb, gives a red and black 
> image (so there is obviously a wrong-initialized RGB-mode with missing 
> G+B components instead of composite over scart).

Does scart-composite work in Windows? I have no idea how it's supposed to 
differ from plain composite. I have my TV hooked up via composite 
going through SCART but I just use the plain composite option.

> Can someone give me some pointer where to look for the cause? I'm 
> willing to try to sort this out, as it's a feature I really need (my 
> HTPC will be hooked to my "single SCART" TV via a loop-through scart of 
> my new DVB-S receiver, which has no manual switch on it's remote, so 
> making the G400 switch itself is the only way I can get the signal reach 
> the TV without having to plug/unplug scart cables...
> 
> Best regards,
> Lucian
> 
> 

-- 
Ville Syrj�l�
[EMAIL PROTECTED]
http://www.sci.fi/~syrjala/


Reply via email to