Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#4084 closed bug (fixed)

Lack 1440x900 resolutoion

Reported by: Hubert Owned by: rudolfc
Priority: normal Milestone: R1
Component: Drivers/Graphics/nVidia Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

In hrev31459 I don't see 1440x900 resolution, native for my LCD. Why?

Attachments (25)

syslog (96.1 KB ) - added by Hubert 10 years ago.
syslog with frist boot r.32059 gcc4/gcc2
nvidia.10de_03d0_000d00.0.log (3.6 KB ) - added by Hubert 10 years ago.
syslog.2 (77.5 KB ) - added by Hubert 10 years ago.
nvidia.10de_03d0_000d00.0.2.log (87.7 KB ) - added by Hubert 10 years ago.
nv_0.94-test-i2c-noClkRead.zip (88.3 KB ) - added by rudolfc 10 years ago.
doing limited wiring test on I2C hoping to find more buses
0.94-test-i2c-noClkRead-inverse-wiring.zip (88.4 KB ) - added by rudolfc 10 years ago.
limited wiring check, plus inversed clk/datalines, (not) hoping this works..
nvidia.10de_03d0_000d00.0.3.log (93.9 KB ) - added by Hubert 10 years ago.
nv_0.94-test-i2c-noClkRead
screenshot1 (81.5 KB ) - added by Hubert 10 years ago.
I have 1440x900
nvidia.10de_03d0_000d00.0.4.log (148.5 KB ) - added by Hubert 10 years ago.
0.94-test-i2c-noClkRead-inverse-wiring
screenshot2 (80.2 KB ) - added by Hubert 10 years ago.
I have not 1440x900 again
nvidia.10de_03d0_000d00.0.5.log (87.6 KB ) - added by Hubert 10 years ago.
logfile with CRT Dell 17'
nvidia.10de_03d0_000d00.0.6.log (59.4 KB ) - added by Hubert 10 years ago.
nv_0.94-test-i2c-noClkRead with CRT 17'
nvidia-improved-i2c-timing-0.95.zip (88.2 KB ) - added by rudolfc 10 years ago.
modified I2C timing in driver for DDC comms and bus-detection. as is in svn hrev32478.
nvidia.10de_03d0_000d00.0.7.log (96.9 KB ) - added by Hubert 10 years ago.
screenshot1.png (65.9 KB ) - added by Hubert 10 years ago.
0.95_delayed_ddc_timing (88.3 KB ) - added by rudolfc 10 years ago.
extra delayed ddc timeouts
0.95_delayed_i2c_timing (88.3 KB ) - added by rudolfc 10 years ago.
extra slow i2c timing (10 times slower)
nvidia.10de_03d0_000d00.0.8.log (81.6 KB ) - added by Hubert 10 years ago.
0.95_delayed_ddc_timing
nvidia.10de_03d0_000d00.0.9.log (81.6 KB ) - added by Hubert 10 years ago.
0.95_delayed_i2c_timing
rc1-common-i2c-delay-only.zip (88.3 KB ) - added by rudolfc 10 years ago.
rc1, modified i2c common timing, only the critical ones
nvidia.10de_03d0_000d00.0.10.log (81.6 KB ) - added by Hubert 10 years ago.
nvidia.10de_03d0_000d00.0.11.log (92.6 KB ) - added by Hubert 10 years ago.
hrev32549 - res. don't work
screenshot2.png (107.8 KB ) - added by Hubert 10 years ago.
screen with current driver
nvidia.10de_03d0_000d00.0.12.log (187.7 KB ) - added by Hubert 10 years ago.
log with gcc2 hybrid - 1440x900 work
screenshot1.2.png (93.7 KB ) - added by Hubert 10 years ago.

Change History (68)

comment:1 by Hubert, 10 years ago

Strange. In r. hrev31517(gcc2/ggc4) I have 1440x900 but lack 1400x1050 or 1680x1200 etc. which were in hrev31459(gcc4/gcc2) to choice.
listdev

comment:2 by Hubert, 10 years ago

I tested hrev31607 (gcc4/gcc2 hybrid): it has not 1440x900, only 1400x1050, 1280x1024 etc. and I tested hrev31598 gcc2 with haiku-files.org: I have 1440x900 but this is a max resolution in Haiku - In earlier versions I had all resolutions to choice. Rudolf what is goes on?

comment:3 by rudolfc, 10 years ago

Hi, (back from holiday)

Since three weeks the driver asks the monitor for it's specs, and it nolonger offers (most) non-compatible modes.

Can you place the file nvidia.settings in your home/config/settings/kernel/drivers folder, enable full logging, and upload the resulting logfile here?

Thanks!

Rudolf.

comment:4 by rudolfc, 10 years ago

Hi, seems bug #4074 might be the same problem... Still, please upload a logfile!

Thanks,

Rudolf.

by Hubert, 10 years ago

Attachment: syslog added

syslog with frist boot r.32059 gcc4/gcc2

comment:5 by Hubert, 10 years ago

I threw in there empty text file nvidia.settings ( there is no another in system) but how I have to enable full logging in this file? btw, I upload syslog file

comment:6 by Hubert, 10 years ago

I place the file nvidia.settings (with src) in my home/config/settings/kernel/drivers folder but where enabled full logging ( of course I have enabled logging in kernel.txt file)?

comment:7 by Hubert, 10 years ago

OK. I enabled logging and upload logs.

by Hubert, 10 years ago

by Hubert, 10 years ago

Attachment: syslog.2 added

comment:8 by rudolfc, 10 years ago

Hi there,

The file you uploaded indeed contains some lines from a nvidia driver logfile. Unfortunately, it's far from complete.

You should enable the line for 'full logging'(all F's) in nvidia.settings, then reboot, and then grab the logfile. It should be around 50-100kB in size..

Thanks!

Rudolf.

comment:9 by Hubert, 10 years ago

OK. I uplod new and I think correctly logfile.

by Hubert, 10 years ago

comment:10 by rudolfc, 10 years ago

Hi,

Thanks for the new log, it's indeed complete.

The problem isnow much more clear: on your card only I2C (DDC) bus #1 is detected, #0 and #2 seem to be not wired. On bus #1 no EDID capable monitor is found.

The driver does detect a analog connected screen on DAC1 which seems correct since you have a picture.

Since the monitor is connected via VGA (analog type connection) the driver has to assume you are using a 4:3 aspect screen. Therefore all non-4:3 aspect modes are 'erased' from the screen preflet.

The tweak you need atm is setting force_ws to true to tell the driver you have a widescreen.

I'll upload a tweaked version of the driver asap here: I hope you can test it and upload a new logfile from that one (delete the current logfile before you reboot).

I'll force the driver to try and find your screen on the apparantly non-functional other I2C buses. Maybe I need to update the detection routine for that..

Bye!

Rudolf.

in reply to:  10 comment:11 by umccullough, 10 years ago

Replying to rudolfc:

Since the monitor is connected via VGA (analog type connection) the driver has to assume you are using a 4:3 aspect screen. Therefore all non-4:3 aspect modes are 'erased' from the screen preflet.

I don't understand this assumption at all.... I have been connecting widescreen monitors to analog VGA for several years now. In fact, there are still new motherboards coming out with integrated video that only has VGA connectors (including my GeForce 6150)

comment:12 by stippi, 10 years ago

I second Urias' opinion. The logic should be reversed: Whenever the driver has too little information (like EDID info missing and so on), it should instead show a mode listing that is as complete as possible, so that the user can pick the best mode. If EDID info is available, and you can detect a 4:3 or 16:9 screen, then you could filter out unwanted modes, but I don't even know if it should go that far, the user may still know best what he wants/needs. EDID should then be used for automatically starting in the native screen mode when no there is no previous configuration, but not much more.

comment:13 by Hubert, 10 years ago

The tweak you need atm is setting force_ws to true to tell the driver you have a widescreen.

Yes, I change that after upload last logfile and this is work but earlier I not needed this do?

I'll upload a tweaked version of the driver asap here: I hope you can test it and upload a new logfile from that one (delete the current logfile before you reboot).

OK. But where is upload that driver?

comment:14 by rudolfc, 10 years ago

Sorry guys: I won't reverse the ws versus 4:3 aspect logic we are talking about !!

You have to understand we are talking _fallback_ operation here. Last I looked max. compatibility was important...

The driver don't let you set WS modes since most 4:3 screens will shut_off (or be possibly destroyed if older). This combined with the fact WS screens mostly also support 4:3 modes it makes perfectly sense to keep 4:3 as the base if _trouble arises_. Which is the case here!

BTW: you probably did not notice: there were a number of users reporting trouble indeed when force_ws was enabled by default: more serious and more often than now.

About analog connected screens: be adviced that using DDC/EDID those report their capabilities. The driver collects that information these days and _will_ report WS modes. Unless of course this communication fails! (hence fallback operation).

Greetings.

Rudolf.

comment:15 by rudolfc, 10 years ago

Oh, since we are on the subject:

Also: in my opinion the driver settings file should be included in the image by default, and docs should be available to the user to manually tweak the driver's behaviour. This driver supports 100+ types of cards, with numerous monitors. Now multiply those two things and you know how difficult it is to make the driver work on all setups.

_this is not going to happen!_. Period.

So, instead it's a question of percentages. The goal is to get the driver to work on the highest number of systems possible. That means, the defaults need to be failsave, not optimum. And the user should have the option to manually tweak for optimum behaviour on a non-optimal working system.

This is the main thought behind my drivers.

Bye!

Rudolf.

PS: The tweaked driver will get uploaded, but not today. Be patient please.

comment:16 by Hubert, 10 years ago

I'll upload a tweaked version of the driver asap here: I hope you can test it and upload a new logfile from that one (delete the current logfile before you reboot).

OK. But where is upload that driver?

upss, sorry, I bad read, it was "I'll upload", he he, sorry once again.

by rudolfc, 10 years ago

doing limited wiring test on I2C hoping to find more buses

by rudolfc, 10 years ago

limited wiring check, plus inversed clk/datalines, (not) hoping this works..

comment:17 by rudolfc, 10 years ago

Hi again Hubert,

I uploaded two tweaked drivers.

Please first test nv_0.94-test-i2c-noClkRead.zip, and upload a full logfile from it.

Secondly please test 0.94-test-i2c-noClkRead-inverse-wiring.zip and upload a full logfile from that as well..

I also have another question: would you happen to have another monitor you could connect to your card instead of this one, use the original driver, and upload a logfile from that as well? If so, please do..

Thanks for testing in advance!!

Rudolf.

by Hubert, 10 years ago

nv_0.94-test-i2c-noClkRead

by Hubert, 10 years ago

Attachment: screenshot1 added

I have 1440x900

by Hubert, 10 years ago

0.94-test-i2c-noClkRead-inverse-wiring

by Hubert, 10 years ago

Attachment: screenshot2 added

I have not 1440x900 again

comment:18 by Hubert, 10 years ago

OK. I upload logfile with tweaked drivers. Soon I upload logfile with another monitor.

by Hubert, 10 years ago

logfile with CRT Dell 17'

comment:19 by rudolfc, 10 years ago

Hi,

Cool! Thanks for testing this. Can you test driver:

nv_0.94-test-i2c-noClkRead

with the CRT Dell 17 inch ??

Thanks in advance...

Meanwhile: We are getting somewhere! I'll search trough the DDC/EDID common accelerant code soon to see if it fully adheres to the I2C spec speed and skew-wise since apparantly the read timing is not OK..

If not fixable there I am going to disable the clock readback function for a number of cards at least...

Meanwhile you can stick with the nv_0.94-test-i2c-noClkRead driverversion as that behaves fully OK for you!

Bye!

Rudolf.

comment:20 by rudolfc, 10 years ago

Oh, please don't forget to upload the log from the test I requested just now.. :-)

Rudolf.

by Hubert, 10 years ago

nv_0.94-test-i2c-noClkRead with CRT 17'

comment:21 by Hubert, 10 years ago

ok. I upload logfile with nv_0.94-test-i2c-noClkRead on CRT 17

by rudolfc, 10 years ago

modified I2C timing in driver for DDC comms and bus-detection. as is in svn hrev32478.

comment:22 by rudolfc, 10 years ago

Hi again,

Can you please test the current driver I uploaded? I found a possible shortcoming in the timing (Depending on the hardware implementation of the I2C port that is).

This modification is also in svn. Can you test and upload another log for me??? Thanks!

(sorry about the delays.. :-)

Rudolf.

by Hubert, 10 years ago

by Hubert, 10 years ago

Attachment: screenshot1.png added

comment:23 by Hubert, 10 years ago

Not work correctly with new driver:(

by rudolfc, 10 years ago

Attachment: 0.95_delayed_ddc_timing added

extra delayed ddc timeouts

by rudolfc, 10 years ago

Attachment: 0.95_delayed_i2c_timing added

extra slow i2c timing (10 times slower)

comment:24 by rudolfc, 10 years ago

OK Hubert,

Here are two more drivers to test, one with delayed ddc timing (mod on common code), and one with extreme slow I2c handling (inside common code).

Please test them for me if you still have the drive and energy. Logs would be appreciated.

Bye!

Rudolf.

by Hubert, 10 years ago

0.95_delayed_ddc_timing

by Hubert, 10 years ago

0.95_delayed_i2c_timing

comment:25 by Hubert, 10 years ago

With this driver, 1440x900(widescreen)is display correctly.

by rudolfc, 10 years ago

rc1, modified i2c common timing, only the critical ones

comment:26 by rudolfc, 10 years ago

Thanks a lot Hubert,

Now can you test the rc1-commong-i2c-delay-only version for me (just uploaded) and upload it's log? I'm now trying to determine exactly which timing part is the problem. If it works with this version, I'll commit a change for the common i2c code..

Bye!

Rudolf.

by Hubert, 10 years ago

comment:27 by Hubert, 10 years ago

rc1-common-i2c-delay-only - display 1440x900

comment:28 by rudolfc, 10 years ago

Resolution: fixed
Status: newclosed

Hi again Hubert,

I committed the solution in R32540. Please doublecheck if it's now correct by default. Closing this ticket, feel free to reopen if it's not OK after all..

Thanks for your cooperation: worked perfectly!

Rudolf.

by Hubert, 10 years ago

hrev32549 - res. don't work

comment:29 by Hubert, 10 years ago

Resolution: fixed
Status: closedreopened

Hi Rudolf,

Unfortunately, the changes do not work, still I do not have a native resolution.

comment:30 by rudolfc, 10 years ago

Hmm.

Can you boot up a number of times with the current driver (and the rc1 driver) and tell me if both work consistently? That is, rc1 always detects your screen/gives the native resolution, and

current svn never gives you the native resolution/ never detects your screen?

I'm thinking the timing might still be critical, and works sometimes, sometimes not..

Thanks!

Rudolf.

comment:31 by Hubert, 10 years ago

I reboot Haiku by five times (5 with current and 5 with rc driver) and always detect resolution with rc1 and never detect with svn. BTW. with rc1 not member resolution after restart and I had every time change on 1440x900. I try to put the log with the same revision gcc2 if still work correctly.

by Hubert, 10 years ago

Attachment: screenshot2.png added

screen with current driver

by Hubert, 10 years ago

log with gcc2 hybrid - 1440x900 work

by Hubert, 10 years ago

Attachment: screenshot1.2.png added

comment:32 by Hubert, 10 years ago

In gcc2 1440x900 work of course but now not rebember resolution settings too:/

in reply to:  32 comment:33 by anevilyak, 10 years ago

Replying to Hubert:

In gcc2 1440x900 work of course but now not rebember resolution settings too:/

That's an unrelated bug that's been fixed in svn in the meantime.

comment:34 by rudolfc, 10 years ago

OK,

Thanks. So do I understand correctly that a GCC2 compiled version of the driver works correctly, while a GCC4 compiled version does not?

The rc1 driver and SVN should be identical...

Can someone have a look at the common accelerant code to see if there are gcc4 related problems? I never compiled with gcc4 yet.

The driver by itself, and the common code should be OK (gcc2).

Rudolf.

comment:35 by rudolfc, 10 years ago

BTW: if you by any chance manually checked out the driver, make sure you also check out/update the accelerants/common code since the actual improvement for the driver is in the timing used there!

Bye!

Rudolf.

comment:36 by Hubert, 10 years ago

So do I understand correctly that a GCC2 compiled version of the driver works correctly, while a GCC4 compiled version does not?

Correct. I was write that on beginning

The rc1 driver and SVN should be identical...

yes, of course

in reply to:  34 ; comment:37 by anevilyak, 10 years ago

Replying to rudolfc:

Thanks. So do I understand correctly that a GCC2 compiled version of the driver works correctly, while a GCC4 compiled version does not?

This may possibly be unrelated, but I see a similar problem here with the radeon driver: gcc2 version works perfectly, with the gcc4 version I go into an out of range monitor mode as soon as the app_server starts.

Don't know if they're sharing any code or not though.

comment:38 by rudolfc, 10 years ago

Yes, they are sharing code: accelerants/common.

This is the DDC/EDID code that detects the monitor's specifications via built-in I2C and two callback functions inside the drivers themselves:

get_signals() set_signals().

I hope this can be nailed.. How should we proceed? (Do I have to checkout a gcc4 build, checkout the sources, and jam from there? Or is there someone who can quickly scan the code and 'detect' typical gcc4 like errors?)

Bye!

Rudolf.

in reply to:  38 comment:39 by mmlr, 10 years ago

Replying to rudolfc:

(Do I have to checkout a gcc4 build, checkout the sources, and jam from there? Or is there someone who can quickly scan the code and 'detect' typical gcc4 like errors?)

I'm looking over it right now. Will report my findings if there are any.

in reply to:  37 comment:40 by umccullough, 10 years ago

Replying to anevilyak:

This may possibly be unrelated, but I see a similar problem here with the radeon driver: gcc2 version works perfectly, with the gcc4 version I go into an out of range monitor mode as soon as the app_server starts.

Don't know if they're sharing any code or not though.

FWIW, I also see differences in detected screen resolution between GCC2 and GCC4 builds using the intel_extreme driver on my G33...

Works perfect in gcc2, chooses a lower resolution in gcc4 (and I have to manually adjust it).

comment:41 by mmlr, 10 years ago

Resolution: fixed
Status: reopenedclosed

Fixed the GCC4 issue in hrev32593. Closing again.

comment:42 by rudolfc, 10 years ago

Thanks a lot mmlr!

Great to wake up this morning and see it fixed!! 8-)

Bye!

Rudolf.

comment:43 by Hubert, 10 years ago

Yep, I tested hrev32595 and now work. Thanks everyone for help. BTW, I have still much the same problem in #4269 - network work in gcc2 hybrid but not work in gcc4 hybrid.

Note: See TracTickets for help on using tickets.