Lack 1440x900 resolutoion

[Hubert]

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

[Hubert]

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

[Hubert]

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?

[rudolfc]

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.

[rudolfc]

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

Thanks,

Rudolf.

[Hubert]

syslog with frist boot r.32059 gcc4/gcc2

[Hubert]

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

[Hubert]

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)?

[Hubert]

OK. I enabled logging and upload logs.

[rudolfc]

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.

[Hubert]

OK. I uplod new and I think correctly logfile.

[rudolfc]

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.

[umccullough]

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)

[stippi]

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.

[Hubert]

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?

[rudolfc]

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.

[rudolfc]

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.

[Hubert]

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.

[rudolfc]

doing limited wiring test on I2C hoping to find more buses

[rudolfc]

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

[rudolfc]

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.

[Hubert]

nv_0.94-test-i2c-noClkRead

[Hubert]

I have 1440x900

[Hubert]

0.94-test-i2c-noClkRead-inverse-wiring

[Hubert]

I have not 1440x900 again

[Hubert]

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

[Hubert]

logfile with CRT Dell 17'

[rudolfc]

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.

[rudolfc]

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

Rudolf.

[Hubert]

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

[Hubert]

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

[rudolfc]

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

[rudolfc]

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.

[Hubert]

Not work correctly with new driver:(

[rudolfc]

extra delayed ddc timeouts

[rudolfc]

extra slow i2c timing (10 times slower)

[rudolfc]

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.

[Hubert]

0.95_delayed_ddc_timing

[Hubert]

0.95_delayed_i2c_timing

[Hubert]

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

[rudolfc]

rc1, modified i2c common timing, only the critical ones

[rudolfc]

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.

[Hubert]

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

[rudolfc]

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.

[Hubert]

hrev32549 - res. don't work

[Hubert]

Hi Rudolf,

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

[rudolfc]

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.

[Hubert]

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.

[Hubert]

screen with current driver

[Hubert]

log with gcc2 hybrid - 1440x900 work

[Hubert]

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

[anevilyak]

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.

[rudolfc]

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.

[rudolfc]

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.

[Hubert]

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

[anevilyak]

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.

[rudolfc]

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.

[mmlr]

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.

[umccullough]

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).

[mmlr]

Fixed the GCC4 issue in hrev32593. Closing again.

[rudolfc]

Thanks a lot mmlr!

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

Bye!

Rudolf.

[Hubert]

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.