Opened 10 years ago

Closed 8 years ago

Last modified 8 years ago

#4166 closed bug (fixed)

Recent changes to video modes seem to have removed some modes.

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

Description (last modified by bga)

My desktop computer is connected to a Samsung Syncmaster 22" monitor with a native resolution of 1680x1050. As I am using the VESA driver ad my video card BIOS does not seem to export widescreen modes, I was using 1400x1050 as my resolution.

I just updated haiku to hrev32034 and, now, I can only set 1280x1024 as the maximum resolution.

Interesting enough, going to the boot menu and selecting a video mode to use does show 1400x1050 but selecting it has no effect (it ends up in 1280x1024 after boot).

Attachments (2)

syslog (161.0 KB) - added by bga 10 years ago.
jonas-syslog.txt (105.3 KB) - added by jonas.kirilla 10 years ago.

Download all attachments as: .zip

Change History (27)

comment:1 Changed 10 years ago by jonas.kirilla

Cc: jonas@… added

comment:2 Changed 10 years ago by jonas.kirilla

I'm in a similar situation, except that my graphics were native before but are now vesa.

I have a widescreen monitor capable of 1920x1200 (16:10) with a supported ATI card (which likewise does not export any widescreen modes) which can drive the monitor at full resolution in Linux but does not in Haiku. (Never worked.) Instead Haiku falls back to vesa in recent revisions. (No refresh rate option in Screen. Vesa accelerant in use. Max resolution 1600x1200 IIRC.) And thus loosing a few resolution options, in Screen.

comment:3 Changed 10 years ago by axeld

First of all, I would think that those are totally unrelated problems.

Then, pinpointing to the release where this happened would help tremendously helpful, as would be syslogs. There have been no changes that I know of that could produce either problem.

Changed 10 years ago by bga

Attachment: syslog added

comment:4 Changed 10 years ago by bga

Culprit is hrev32020. Reverting it got my 1400x1050 mode back.

Changed 10 years ago by jonas.kirilla

Attachment: jonas-syslog.txt added

comment:5 Changed 10 years ago by jonas.kirilla

I must have been mistaken about having native support for my graphics card, and using Vesa all along. (My card, RV710, Radeon HD 4350, appears to be unsupported by the radeon driver.)

I've attached my syslog, and wonder what the "Additional Video Mode" is. Is that just the monitor's stated preferred resolution, or an actual mode that could be used?

comment:6 Changed 10 years ago by bga

Your card is definitely not supported natively. In fact, it is in the same family as mine (which are two HD 3870).

comment:7 Changed 10 years ago by bga

Description: modified (diff)

comment:8 Changed 10 years ago by axeld

To Jonas: additional modes are modes the monitor specifically defines beyond what EDID has hard coded defines for. For flat panels it's usually the native resolution of that panel. This is just your monitor, though, and your graphics card may not even be able to deliver that mode (especially via VESA).

To Bruno: if your monitor supports that mode, this shouldn't happen. Can you add some debug output to src/add-ons/accelerants/common/create_mode_list.cpp to the EDID version of ModeList::_AddModes()? The only interesting part would be the last, where compatible base modes are added - it would be interesting to know why a particular mode was rejected.

Also, if that mode doesn't work in the boot loader, it shouldn't work with VESA either, as they use the very same mechanism to switch the mode.

comment:9 Changed 10 years ago by bga

Hi Axel.

Will add the debug and let you know. But you seem to have misunderstood me. 1400x1050 does show up in the boot menu. With hrev32020 what happened is that even with it showing there, it had no effect as when VESA took over, this mode got disabled somehow. before that revision, the mode worked both during boot and showed up in Screen preferences (so it also worked with VESA).

comment:10 Changed 10 years ago by bga

So, what would be the easiest way to dump information from an accelerant to syslog?

comment:11 Changed 10 years ago by axeld

You can best use debug_printf() - that goes through the kernel, so it will show up in the syslog as well as the serial debug output.

comment:12 Changed 10 years ago by bga

Do I need to do anything other then calling debug_printf()? I am asking because I added some of those to the code but nothing was sent to syslog. Do i need a debug build for it to work? I tried to test this but libroot is not compiling in debug mode.

comment:13 Changed 10 years ago by axeld

That should be all. If _AddModes() is not even called, then you should find out why it isn't.

comment:14 Changed 10 years ago by bga

This is weird. I added a debug_printf() to the create_display_modes() function so it looked like this:

extern "C" area_id
create_display_modes(const char* name, edid1_info* edid,
	const display_mode* initialModes, uint32 initialModeCount,
	const color_space *spaces, uint32 spacesCount,
	check_display_mode_hook hook, display_mode** _modes, uint32* _count)
{
	debug_printf("***** CREATE DISPLAY MODES *****\n");
	if (_modes == NULL || _count == NULL)
		return B_BAD_VALUE;

[...]

After this, I rebuild and installed the vesa.accelerant.

This was never printed to syslog when I rebooted so either the function is not being called (which I guess is not really an option) or debug_printf() simply is not working.

Just to confirm when you made your suggestion, you said to look into the file at src/add-ons/accelerants/common/create_mode_list.cpp, which does not exist. the file that exists and that I added the debug to is src/add-ons/accelerants/common/create_display_modes.cpp. This is the correct file, right?

comment:15 Changed 10 years ago by axeld

Yes it is. debug_printf() has not other option than to work, but its output is only visible in the syslog if that is enabled in the kernel.

comment:16 Changed 10 years ago by bga

Did not manage to include the generate the debug information yet but, just to add a bit more information, there are the modes I see before hrev32020 (these modes also show up in the fail safe boot menu before and after hrev32020):

1400x1050
1280x1024
1152x864
1024x768
800x600
720x400
640x480
640x400
640x350

And there are the modes I see after hrev32020:

1280x1024
1152x864
1024x768
800x600
640x480
640x400
640x350

So the missing resolutions are:

1400x1050
720x400

Both missing resolutions work fine in my monitor + card combination (using VESA) and the first one is the one I used as default (as this is the resolution closest to the native 1680x1050 native resolution my monitor supports).

comment:17 Changed 10 years ago by bga

Scratch that. 720x400 does not show up pre hrev32020, but 1400x1050 does, which is the resolution I am interested in getting back anyway. :)

comment:18 Changed 8 years ago by bga

I am revisiting this. Right now the situation is still the same with the difefrence that if I select fail safe video mode in the boot menu and select 1400x1050 resolution, it actually boots to that resolution without any issues whatsoever. I will add debugging and report back (if I remember correctly there was really a bug with debug_printf() that was fixed at some point.

comment:19 Changed 8 years ago by bga

Ok. Done.

So what happens is that 1400x1050 is on the list of video modes to compare to but, somehow, is not on the list of modes it is checking. For reference, here is what I get on bootup:

KERN: VESA version = 3.0, capabilities 1
KERN: OEM string: ATI ATOMBIOS
KERN:  0x100: 640 x 400 x 8 (a = 187, mem = 4, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
KERN:  0x101: 640 x 480 x 8 (a = 187, mem = 4, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
KERN:  0x103: 800 x 600 x 8 (a = 187, mem = 4, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
KERN:  0x105: 1024 x 768 x 8 (a = 187, mem = 4, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
KERN:  0x107: 1280 x 1024 x 8 (a = 187, mem = 4, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
KERN:  0x111: 640 x 480 x 16 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
KERN:  0x114: 800 x 600 x 16 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
KERN:  0x117: 1024 x 768 x 16 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
KERN:  0x11a: 1280 x 1024 x 16 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
KERN:  0x10e: 320 x 200 x 16 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
KERN:  0x120: 320 x 200 x 32 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
KERN:  0x193: 320 x 240 x 8 (a = 187, mem = 4, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
KERN:  0x195: 320 x 240 x 16 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
KERN:  0x196: 320 x 240 x 32 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
KERN:  0x1b3: 512 x 384 x 8 (a = 187, mem = 4, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
KERN:  0x1b5: 512 x 384 x 16 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
KERN:  0x1b6: 512 x 384 x 32 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
KERN:  0x1c3: 640 x 350 x 8 (a = 187, mem = 4, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
KERN:  0x1c5: 640 x 350 x 16 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
KERN:  0x1c6: 640 x 350 x 32 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
KERN:  0x183: 640 x 400 x 8 (a = 187, mem = 4, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
KERN:  0x185: 640 x 400 x 16 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
KERN:  0x186: 640 x 400 x 32 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
KERN:  0x133: 720 x 400 x 8 (a = 187, mem = 4, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
KERN:  0x135: 720 x 400 x 16 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
KERN:  0x136: 720 x 400 x 32 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
KERN:  0x153: 1152 x 864 x 8 (a = 187, mem = 4, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
KERN:  0x155: 1152 x 864 x 16 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
KERN:  0x156: 1152 x 864 x 32 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
KERN:  0x163: 1280 x 1024 x 8 (a = 187, mem = 4, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
KERN:  0x165: 1280 x 1024 x 16 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
KERN:  0x166: 1280 x 1024 x 32 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
KERN:  0x121: 640 x 480 x 32 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
KERN:  0x122: 800 x 600 x 32 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
KERN:  0x123: 1024 x 768 x 32 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
KERN:  0x124: 1280 x 1024 x 32 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
KERN:  0x143: 1400 x 1050 x 8 (a = 187, mem = 4, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
KERN:  0x145: 1400 x 1050 x 16 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
KERN:  0x146: 1400 x 1050 x 32 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
KERN:  0x173: 1600 x 1200 x 8 (a = 186, mem = 4, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
KERN:  0x175: 1600 x 1200 x 16 (a = 186, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
KERN:  0x176: 1600 x 1200 x 32 (a = 186, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
KERN:  0x183: 640 x 400 x 8 (a = 187, mem = 4, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
KERN:  0x185: 640 x 400 x 16 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
KERN:  0x186: 640 x 400 x 32 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
KERN:  0x1d3: 1856 x 1392 x 8 (a = 186, mem = 4, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
KERN:  0x1d5: 1856 x 1392 x 16 (a = 186, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
KERN:  0x1d6: 1856 x 1392 x 32 (a = 186, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
KERN:  0x1e3: 1920 x 1440 x 8 (a = 186, mem = 4, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
KERN:  0x1e5: 1920 x 1440 x 16 (a = 186, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
KERN:  0x1e6: 1920 x 1440 x 32 (a = 186, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0
KERN: Using mode 0x123
KERN: VESA compatible graphics!
KERN: EDID1: 4f
KERN: EDID2: ebx 102
KERN: EDID3: 4f
KERN: Vendor: SAM
KERN: Product ID: 639
KERN: Serial #: 1296380466
KERN: Produced in week/year: 45/2007
KERN: EDID version: 1.3
KERN: Type: Digital
KERN: Size: 47 cm x 30 cm
KERN: Gamma=2.2
KERN: White (X,Y)=(0.313,0.329)
KERN: Supported Future Video Modes:
KERN: 1680x1680@60Hz (id=179)
KERN: 1280x1024@60Hz (id=32897)
KERN: 1280x960@60Hz (id=16513)
KERN: 1152x864@75Hz (id=20337)
KERN: Supported VESA Video Modes:
KERN: 720x400@70Hz
KERN: 640x480@60Hz
KERN: 640x480@67Hz
KERN: 640x480@72Hz
KERN: 640x480@75Hz
KERN: 800x600@56Hz
KERN: 800x600@60Hz
KERN: 800x600@72Hz
KERN: 800x600@75Hz
KERN: 832x624@75Hz
KERN: 1024x768@60Hz
KERN: 1024x768@70Hz
KERN: 1024x768@75Hz
KERN: 1280x1024@75Hz
KERN: 1152x870@75Hz
KERN: Additional Video Mode (1680x1050@59Hz):
KERN: clock=119 MHz
KERN: h: (1680, 1728, 1760, 1840)
KERN: v: (1050, 1053, 1059, 1080)

So, my question is: Why is 1400x1050 not in the list of video modes to try and how to make it show up there? Note it is listed here:

KERN:  0x143: 1400 x 1050 x 8 (a = 187, mem = 4, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 0 0 g: 0 0 b: 0 0 dcmi: 0
KERN:  0x145: 1400 x 1050 x 16 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 5 11 g: 6 5 b: 5 0 dcmi: 0
KERN:  0x146: 1400 x 1050 x 32 (a = 187, mem = 6, phy = c0000000, p = 1, b = 1)
KERN: 	mask: r: 8 16 g: 8 8 b: 8 0 dcmi: 0

But not here:

KERN: Supported VESA Video Modes:
KERN: 720x400@70Hz
KERN: 640x480@60Hz
KERN: 640x480@67Hz
KERN: 640x480@72Hz
KERN: 640x480@75Hz
KERN: 800x600@56Hz
KERN: 800x600@60Hz
KERN: 800x600@72Hz
KERN: 800x600@75Hz
KERN: 832x624@75Hz
KERN: 1024x768@60Hz
KERN: 1024x768@70Hz
KERN: 1024x768@75Hz
KERN: 1280x1024@75Hz
KERN: 1152x870@75Hz

And, again, the mode does work flawlessly on my configuration. As a reference, I checked the list of modes being checked in the is_supported_mode() call in vesa/mode.cpp.

Any ideas?

comment:20 Changed 8 years ago by bga

Ok, I guess I figured it out.

The problem is that the EDID info does not contain all modes that are supported for some reason while the vesa modes list does. In vesa/mode.cpp, there is the following code:

/*!	Creates the initial mode list of the primary accelerant.
	It's called from vesa_init_accelerant().
*/
status_t
create_mode_list(void)
{
	const color_space kVesaSpaces[] = {B_RGB32_LITTLE, B_RGB24_LITTLE,
		B_RGB16_LITTLE, B_RGB15_LITTLE, B_CMAP8};

	// Create the initial list from the support mode list - but only if we don't
	// have EDID info available, as that should be good enough.
	display_mode* initialModes = NULL;
	uint32 initialModesCount = 0;
	if (!gInfo->shared_info->has_edid) {
		initialModes = (display_mode*)malloc(
			sizeof(display_mode) * gInfo->shared_info->vesa_mode_count);
		if (initialModes != NULL) {
			initialModesCount = gInfo->shared_info->vesa_mode_count;
			vesa_mode* vesaModes = gInfo->vesa_modes;

			for (uint32 i = gInfo->shared_info->vesa_mode_count; i-- > 0;) {
				compute_display_timing(vesaModes[i].width, vesaModes[i].height,
					60, false, &initialModes[i].timing);
				fill_display_mode(vesaModes[i].width, vesaModes[i].height,
					&initialModes[i]);
			}
		}
	}

	gInfo->mode_list_area = create_display_modes("vesa modes",
		gInfo->shared_info->has_edid ? &gInfo->shared_info->edid_info : NULL,
		initialModes, initialModesCount,
		kVesaSpaces, sizeof(kVesaSpaces) / sizeof(kVesaSpaces[0]),
		is_mode_supported, &gInfo->mode_list, &gInfo->shared_info->mode_count);

	free(initialModes);

	if (gInfo->mode_list_area < 0)
		return gInfo->mode_list_area;

	gInfo->shared_info->mode_list_area = gInfo->mode_list_area;
	return B_OK;
}

The initial mode list does not include the vesa modes if EDID information is present. I got it working as expected by simply removing the check for has_edid. This wll populate the initila mode list with the vesa modes and, then, the mode I want will be picked up later as expected and I will be able to select it.

Does this change seem reasonable? It seems, based on the comment in the code, that not filling the initial mode list with the vesa modes when we have EDID is simply an optimization and does not really serve any other purpose and the EDID info alone is not "good enough", as can be noticed in my case.

comment:21 in reply to:  20 Changed 8 years ago by axeld

Replying to bga:

Does this change seem reasonable? It seems, based on the comment in the code, that not filling the initial mode list with the vesa modes when we have EDID is simply an optimization and does not really serve any other purpose and the EDID info alone is not "good enough", as can be noticed in my case.

The reason for putting that check in there was because to lower the number of extraneous resolutions presented in the Screen preferences. However, that's really not the place where this filtering should be done, so your change definitely sound reasonable.

We should just put some filter in the Screen preferences (possibly one that can be disabled if needed), so that you only get a few common modes, and not so many of them, most of them unusable anyway.

comment:22 Changed 8 years ago by bga

Makes sense. I will commit my change then and we can look at the extraneous video modes after that. We could also filter mode with height < 480. This would take care of at least some stray video modes.

comment:23 Changed 8 years ago by bga

Resolution: fixed
Status: newclosed

Fixed in hrev42600.

comment:24 Changed 8 years ago by tqh

Does this mean that some computers will select invalid modes during booting, or is it just what is reported back for screen preferences?

comment:25 Changed 8 years ago by ttcoder

IIUC, it's the latter.

The vesa_init_accelerant() -> create_mode_list() -> create_display_modes() call chain is the one called by the app_server (and Screen prefs ..etc), whereas the boot menu and "icons" splash screen uses functions from system/boot/bios_ia32/video.cpp. These ones are not affected by hrev42600 (IIUC).

This is why Bruno could select the mode from the boot menu, yet that mode would not be present in Screen.

Also (and apologies for digging up a 2 years old comment, num. 8, to reply on ;-) ,

Also, if that mode doesn't work in the boot loader, it shouldn't work with VESA either, as they use the very same mechanism to switch the mode.

Well I have first-hand experience of an exception to this one ;-) , that is to say, a mode which blanks out the monitor if selected in the boot loader "safe mode options", even though that very same mode works perfectly if selected in Screen when VESA.accelerant kicks in (so it's the opposite of Bruno's problem, where a mode works a bootup but not in VESA.accelerant). I have a new monitor now anyway, so no urgency to work on that one, but who knows if it's a small symptom of a more significant problem lurking in there.

Last edited 8 years ago by ttcoder (previous) (diff)
Note: See TracTickets for help on using tickets.