Opened 10 years ago

Closed 9 years ago

#3397 closed bug (fixed)

Screen: cannot set screen modes anymore

Reported by: rossi Owned by: axeld
Priority: normal Milestone: R1
Component: Drivers/Graphics/intel_extreme Version: R1/pre-alpha1
Keywords: Cc: umccullough@…
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

The Screen preferences do not work anymore for me. I cannot set a screen mode anymore, independent of the resolution I chooose. I always get the error message "The screen mode could not be set: Invalid Argument".

This happens if I use the native intel_extreme driver.

In VESA mode I can still change screen resolutions, however VESA mode doesn't offer the 1920x1200/32bit/60Hz mode ;-(

This used to work before (at least for sure until hrev29060).

The error is exposed on hrev29107.

Attachments (1)

syslog (265.0 KB) - added by rossi 10 years ago.

Download all attachments as: .zip

Change History (18)

comment:1 Changed 10 years ago by rossi

Addition: just tried some more, apperently only the 32bit resolution doesn't work, if I go down to 16bit, it works. However before I could happily use 32bit depth resolutions, including 1920x1200 ...

comment:2 Changed 10 years ago by Adek336

Sounds similar to #2995, #2188.

comment:3 Changed 10 years ago by rossi

Sounds similar, I checked them before, but the actual error message is differently and since this used to work until recently, I believe its a different isssue, even though they might of course be related.

comment:4 Changed 10 years ago by anevilyak

Is that by any chance with gcc4 Haiku? mmlr was noticing the same problem, but for him it only happens with a gcc4 build, on gcc2 haiku it still worked fine for him.

comment:5 Changed 10 years ago by rossi

Nope, it is to be exact a hybrid build, with gcc2 being the base system and gcc4 libs installed.

comment:6 Changed 10 years ago by mmlr

Interesting, if it was really introduced so recently it's possible that I don't see it because I'm lagging behind. Running on a hrev28971 base here with updated individual components.

comment:7 Changed 10 years ago by anevilyak

Component: Preferences/ScreenDrivers/Graphics/intel_extreme

If that's the case, then my guess would definitely be hrev29060.

comment:8 Changed 10 years ago by anevilyak

And if hrev29060 does indeed turn out to be the culprit, the following may be helpful to Axel in tracking it down:

"And if that does not help, can you please enable debug output in the Intel GART driver (at src/add-ons/kernel/busses/agp_gart/intel.cpp)?"

comment:9 Changed 10 years ago by umccullough

Actually, my G33-based system has this problem as well - but with one difference - it didn't work before the recent change either.

It did *appear* to work (it would tell me it was in 32bit mode when i looked at the preferences), but when I tried to change screen resolutions (smaller or larger) it would fail with "Invalid Argument" until i set it to 16bit first.

comment:10 Changed 10 years ago by umccullough

Cc: umccullough@… added

comment:11 Changed 10 years ago by axeld

I guess that's just the same bug that has recently been mentioned on the list (that the app_server does not correctly fall back if allocating memory fails).

hrev29060 should have no influence whatsoever on the i945 - the code specifically asks for the 9xx family and behaves exactly as before for those. I would just assume that you didn't notice the bug before for some reason. But in order to prove you wrong, can you please attach at least the syslog, as otherwise one can only guess.

I'm using a lower resolution (1680x1050x32), but that does not reproduce the problem.

Changed 10 years ago by rossi

Attachment: syslog added

comment:12 Changed 10 years ago by rossi

Syslog attached.

comment:13 Changed 10 years ago by rossi

I don't know what changed, but I forgot this bug and just used screen preferences to set this resolution after a week of working on the built-in laptop display and it works again. therefore I cannot say, which revision fixed this bug, but it seems fixed latest in 30935 ;-)

Should be closed as fixed.

comment:14 Changed 10 years ago by stippi

This may still be a problem, depending on some factors which have not yet revealed themselves... :-)

comment:15 Changed 10 years ago by rossi

Should those some factors reveal themselves, I'll give those factors the honor of loud crying in another comment to this ticket ;-)

comment:16 Changed 10 years ago by scottmc

Sounds like this one can be closed then?

comment:17 Changed 9 years ago by luroh

Resolution: fixed
Status: newclosed

Yep, closing.

Note: See TracTickets for help on using tickets.