#2764 closed bug (fixed)
Scrambled video with intel i865 with r26762 and up
Reported by: | umccullough | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Drivers/Graphics/intel_extreme | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
On my Dell Optiplex GX270, I started getting scrambled video using the intel_extreme driver with my 1920x1280 samsung display and the integrated i865 chip (with analog video).
This started with hrev26762, and reverting back to hrev26761 fixes the problem.
Choosing a fail-safe video resolution doesn't change anything, but choosing "Use fail-safe video mode" from the safe mode options works (apparently in VESA mode).
Attachments (4)
Change History (15)
by , 16 years ago
Attachment: | haiku_r26761_i865.txt added |
---|
by , 16 years ago
Attachment: | r26762_scrambled_i865_video.png added |
---|
scrambled screenshot from hrev26762
follow-up: 2 comment:1 by , 16 years ago
The video mode selection is only for booting and VESA (well, not really anymore, since Jan's VBE mode switch changes). Only if you select "fail safe video mode", the graphics driver is not used, but VESA instead.
One very important info is missing from this report, though: before that revision, it used 1600x1200, not 1920x1280. That means this revision only made it no longer ignore the native monitor resolution, but the Intel driver apparently has problems to switch to that resolution with the i865.
Unfortunately, I don't have a monitor that could display this resolution, so I'm not sure how I can look into it.
follow-up: 3 comment:2 by , 16 years ago
Replying to axeld:
One very important info is missing from this report, though: before that revision, it used 1600x1200, not 1920x1280. That means this revision only made it no longer ignore the native monitor resolution, but the Intel driver apparently has problems to switch to that resolution with the i865.
Ah, is it possible that not enough RAM has been "stolen" from the system memory to support this resolution then? I think I saw in the serial log that only 7mb had been stolen (should have been 8mb) - seems a bit tight either way, no?
Unfortunately, I don't have a monitor that could display this resolution, so I'm not sure how I can look into it.
I'd let you borrow mine... but the shipping cost would be horrendous ;)
follow-up: 4 comment:3 by , 16 years ago
Replying to umccullough:
Ah, is it possible that not enough RAM has been "stolen" from the system memory to support this resolution then? I think I saw in the serial log that only 7mb had been stolen (should have been 8mb) - seems a bit tight either way, no?
While the driver should be able to allocate more on the fly, I don't think I ever tested this with the i865, at least not with the frame buffer (IIRC overlay didn't work anymore there, either).
I'd let you borrow mine... but the shipping cost would be horrendous ;)
Indeed, that really wouldn't make much sense. Maybe someone brings such a panel to BeGeistert :-)
comment:4 by , 16 years ago
Replying to axeld:
Replying to umccullough:
Ah, is it possible that not enough RAM has been "stolen" from the system memory to support this resolution then? I think I saw in the serial log that only 7mb had been stolen (should have been 8mb) - seems a bit tight either way, no?
While the driver should be able to allocate more on the fly, I don't think I ever tested this with the i865, at least not with the frame buffer (IIRC overlay didn't work anymore there, either).
In the past, I got a similar experience when the BIOS was set to only steal 1mb (it would load up scrambled in a similar way on the i845 and i865 both IIRC), but then I went into the BIOS and set it to steal 8mb - so I'm guessing the driver itself does not support this feature yet.
Overlay definitely doesn't work on the i865 :)
Is there anything I can do to assist with this?
comment:5 by , 16 years ago
I looked at the syslogs closer, and I can see that after hrev26762, the intel driver tries to allocate more memory than it did before the change. This might indicate that it has decided to use a higher resolution than previously, and needs more than the pre-allocated (bound?) memory - and proceeds to allocate more but fails.
The difference between them can be seen here:
before change: http://dev.haiku-os.org/attachment/ticket/2764/haiku_r26761_i865.txt#L1463 after change: http://dev.haiku-os.org/attachment/ticket/2764/haiku_r26762_i865.txt#L1464
comment:6 by , 16 years ago
Can you retry with hrev29060? 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:7 by , 16 years ago
Yep - that seems to have done the trick!
Booted up into 1920x1200x32bpp with no issues :) (so far anyway)
comment:8 by , 16 years ago
Forgot to mention, VLC overlay support works again on i865 for me.
Axel: did you still want any debug output? or does the fact that it works mean we're good to go now? :)
comment:9 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
It works fine again here, so I guess we're good. Does the "GTT fallback" line appear in the syslog?
comment:10 by , 16 years ago
Yep, it does.
I attached the relevant part of my syslog in case you're curious.
hrev26761 serial log