#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 )
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)
Change History (27)
comment:1 by , 15 years ago
Cc: | added |
---|
comment:2 by , 15 years ago
comment:3 by , 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 , 15 years ago
by , 15 years ago
Attachment: | jonas-syslog.txt added |
---|
comment:5 by , 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 , 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 , 15 years ago
Description: | modified (diff) |
---|
comment:8 by , 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 , 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 , 15 years ago
So, what would be the easiest way to dump information from an accelerant to syslog?
comment:11 by , 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 , 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 , 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 , 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 , 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 , 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 , 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 , 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 , 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?
follow-up: 21 comment:20 by , 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.
comment:21 by , 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 , 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:24 by , 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 , 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.
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.