Opened 15 years ago

Closed 13 years ago

Last modified 13 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:
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 15 years ago.
jonas-syslog.txt (105.3 KB ) - added by jonas.kirilla 15 years ago.

Download all attachments as: .zip

Change History (27)

comment:1 by jonas.kirilla, 15 years ago

Cc: jonas@… added

comment:2 by jonas.kirilla, 15 years ago

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 by axeld, 15 years ago

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.

by bga, 15 years ago

Attachment: syslog added

comment:4 by bga, 15 years ago

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

by jonas.kirilla, 15 years ago

Attachment: jonas-syslog.txt added

comment:5 by jonas.kirilla, 15 years ago

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 by bga, 15 years ago

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

comment:7 by bga, 15 years ago

Description: modified (diff)

comment:8 by axeld, 15 years ago

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 by bga, 15 years ago

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 by bga, 15 years ago

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

comment:11 by axeld, 15 years ago

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 by bga, 15 years ago

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 by axeld, 15 years ago

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

comment:14 by bga, 15 years ago

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 by axeld, 15 years ago

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 by bga, 15 years ago

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 by bga, 15 years ago

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 by bga, 13 years ago

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 by bga, 13 years ago

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 by bga, 13 years ago

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.

in reply to:  20 comment:21 by axeld, 13 years ago

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 by bga, 13 years ago

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 by bga, 13 years ago

Resolution: fixed
Status: newclosed

Fixed in hrev42600.

comment:24 by tqh, 13 years ago

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 by ttcoder, 13 years ago

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 13 years ago by ttcoder (previous) (diff)
Note: See TracTickets for help on using tickets.