PDA

View Full Version : 1080p modeline works in windows but not in linux


drvik
06-03-07, 08:25 AM
Hi everyone,

I created a modeline in windows to drive a home theatre projector, and it works exactly how I want it to...


when I transferred the modeline to linux, it is validated by X, but then only produces black output...

Hardware is an onboard gf6150, outputting via DVI to a sony CRT projector.... there are no errors in xorg.log...

I think this may be some sort of error in the nvidia binary driver because nothing else is different with the setup except the OS/driver...

netllama, can you offer some assistance please!?!

drvik

edit: I confirmed that the same thing occurs when i drop in a 7300GS into the system, so it's not likely to be the onboard 6150...

pe1chl
06-03-07, 10:38 AM
Why don't you use a standard-timing 1080p modeline like this?

Modeline "1920x1080p50" 148.5 1920 2440 2456 2640 1080 1083 1085 1125 +Hsync +Vsync

You say you are outputting via DVI, do you realize that you have set the output to be analog?
Of course, this is possible on a DVI-I output and is required when you use a DVI-to-VGA adapter somewhere.

drvik
06-03-07, 09:33 PM
That standard modeline has very large porches (especially on one side), which means that my image only takes up a small area on the tube faces and is widely off center... my modeline corrects this...

I'm not sure what you mean by the analogue statement...

I have a card in my projector that takes DVI and converts it to analogue internally to feed the appropriate circuitry... I'm presuming that the nvidia driver will pass through whatever modeline I supply rather than just a select few...

drvik

rerushg
06-03-07, 10:23 PM
That standard modeline has very large porches (especially on one side), which means that my image only takes up a small area on the tube faces and is widely off center...
Seems like an "off center" condition would be a calibration function within your display.
I'm not sure what you mean by the analogue statement...
With your method you're using the DVI port but you're simply passing analog signals through it. I'm not criticizing your method; it's the common "fix" for driving HD because of glitches in the current NV Linux drivers. Indeed, "works in Windows but doesn't work in Linux" is a common comment around here.
Everything seems fine in your posted log. This suggests that NV and X are doing their thing.
That brings up a couple of thoughts:
1. Maybe the analog signal is not getting through. Suggest you check Wikipedia > DVI and make sure your cable and display port will transfer analog.
2. Maybe your display simply does not like analog via the DVI port.

Good luck.

pe1chl
06-04-07, 04:23 AM
That standard modeline has very large porches (especially on one side), which means that my image only takes up a small area on the tube faces and is widely off center... my modeline corrects this...

Does your projector in any way claim compatibility with European (50 Hz) HDTV standards? or is it just an American model you are driving at 50Hz in the hopes that it will just work?
The modeline I gave confirms to HDTV standards. What is particular in those, is that at 50Hz it uses the same dotclock as at 60Hz, but with a larger number of unused pixels in each horizontal line. What you are doing is using the number of pixels of 60Hz (2200) and lower the dotclock. While this is normal for a computer monitor modeline, it isn't normal for HDTV...

I'm not sure what you mean by the analogue statement...

I have a card in my projector that takes DVI and converts it to analogue internally to feed the appropriate circuitry...

See the comment from rerushg. When you want DVI output (the digital kind), you need to use the DFP monitor type, not CRT. In fact, you can probably just omit the monitor type.

I'm presuming that the nvidia driver will pass through whatever modeline I supply rather than just a select few...


That, unfortunately, is an incorrect assumption.
It used to be like that. You could write up anything you liked in a modeline, and XFree86 would just load it into the videocard registers and you either got the picture you wanted or maybe a big mess.
Nvidia has chosen to let the driver outwit the administrator and make all kinds of checks and corrections on what is written into the config file.
So you can find your carefully crafted modeline being bluntly rejected because the driver thinks it has a higher resolution than the monitor can handle (based on unreliable information it is auto-detecting), or some other ridiculous reason. (in the past, only the horizontal and vertical refresh frequencies were checked by XFree86)

However, that is not what is happening in your case. It *does* "helpfully" add a useless nvidia_auto_select modeline, but it does not reject the modeline you have written.

drvik
06-17-07, 11:19 PM
Problem fixed... no thanks to nvidia...

I'll highlight a few things I learned along the way...

My DVI card in my CRT projector is only a DVI-D... so only digital signals are utilised (ConnectedMonitor=DFP)

Also... unless you place ExactModeTimings DVI in your SCREEN section, as opposed to your DEVICE section, they will be ignored. Until I did this, no matter which custom 1080p modeline I sent the projector, it would always display the built in 1080p50 (which was always badly ofset to the left)... unfortunately it took about 3 days to work this last point out and it is not covered in the nvidia readme.... without this option, the nvidia driver will ignore your custom modeline and just feed the losest one to that one that it can find... how ridiculous nvidia! If I am referring to a custom modeline then of course I want it used! This setting should either be removed or the default behaviour should be set to on!!!!!!!!!!!!!

so the upshot of this is... I am now feeding a custom 1080p 50Hz modeline to my old Sony 1292 CRT over a digital DVI link and not exceeding the 125MHz bandwidth

Modeline "1920x1080@50" 123.750 1920 2016 2096 2200 1080 1108 1118 1125 +hsync +vsync

pe1chl
06-18-07, 06:01 AM
I think the main problem is that you are trying to use SMPTE 274M standard 50Hz HDTV timing with a product that is incompatible with that standard.

rerushg
06-18-07, 03:53 PM
Problem fixed...

Way to go; glad you got fixed.
Interesting point about the ExactModeTimings DVI option. Thanks for the feed-back.
Good luck with it.

Xevious
06-18-07, 03:59 PM
I think the main problem is that you are trying to use SMPTE 274M standard 50Hz HDTV timing with a product that is incompatible with that standard.

I think it came down to that he was using a custom modeline via DVI-D. The drivers in linux do not like to do this unless you have several options in your "Device" section. I just got a 1080p HDTV which can only do 58Hz @ 1080p but EDID info has no 1080p mode at all. I had to use these options to use custom modes:

Option "ExactModeTimingsDVI" "true"
Option "ModeValidation" "AllowNon60HzDFPModes, NoEdidModes, NoEdidDFPMaxSizeCheck, NoVertRefreshCheck, NoHorizSyncCheck, NoMaxSizeCheck, NoDFPNativeResolutionCheck, NoEdidMaxPClkCheck"

It was even more trouble on my system at work to run a custom 2x1920x2400 @ 33.7 Hz with the correct DPI and twinview settings I needed these options:


Option "TwinView"
Option "NoTwinViewXineramaInfo" "1"
Option "MetaModes" "1920x2400,1920x2400; 1920x1200,NULL; 1600x1200,NULL; 1600x1200, 1600x1200; 1280x1024, 1280x1024; 1280x1024 , NULL; 1024x768, 1024x768; 1024x768, NULL; 800x600,800x600; 800x600, NULL; 640x480, 640x480; 640x480, NULL"
Option "TwinViewOrientation" "RightOf"
Option "ConnectedMonitor" "DFP-0, DFP-1"
Option "DPI" "75 x 75"
Option "ExactModeTimingsDVI" "true"
Option "UseEDID" "FALSE"
Option "ModeValidation" "AllowNon60HzDFPModes, NoEdidModes, NoEdidDFPMaxSizeCheck, NoVertRefreshCheck, NoHorizSyncCheck, NoMaxSizeCheck, NoDFPNativeResolutionCheck"

With my custom modeline:

Modeline "1920x2400" 164.999 1920 1936 1968 2032 2400 2401 2404 2409 -hsync +vsync

It shows that linux can be a bit of pain to do custom modes since the newer nvidia drivers. Too bad I didn't see this post earlier as I am sure I could have pointed the poster in the right direction.