Software Support > GroovyMAME
Switchres: modeline generator engine
bitbytebit:
--- Quote from: bitbytebit on October 11, 2010, 09:31:13 pm ---Version 0.8 has improved things considerably, now the actual modelines are really read from xorg.conf and only uses the lrmc code in there if no modeline is listed for the "HxWxR" label in the Modes section (just like how all X drivers do but it uses the LRMC and not Vesa method unless you don't have the Option "ArcadeMonitor" set to a valid monitor name). Also bug fixes and other issues hopefully are fixed and works better now, should be easier to use and get working now.
--- End quote ---
--- Quote from: Calamity on October 12, 2010, 05:21:30 am ---
I'd like to summarize and see if I've understood right:
- We start running genres with proper params to get modelines and .inis done (at this point, I'm not sure if lrmc will use options from xorg.conf or from lrmc.conf). Modelines will be added to xorg.conf, and available when we restart.
--- End quote ---
lrmc will use the options from /etc/lrmc.conf or lrmc.conf in the working directory, I've left that the same while now the X server just reads the modelines and Hsync/Vsync ranges from xorg.conf (which really just serve to limit bad modelines and the default modelines from being used). There are default modelines that the X server part likes to force on us, not so bad since the Hsync/Vsync settings eliminate any ones out of range but also is a little annoying it does that, would be nice to figure out how to only have our modelines available.
--- Quote from: Calamity on October 12, 2010, 05:21:30 am ---- Now, we'll have ini files for Mame games with the resolution in the format WxH@R where R is a double (not integer anymore). When starting Mame, it'll push this resolution to the driver.
--- End quote ---
In Windows it'd be WxH@R but in Linux it uses WxHxD@R and it well R is a double on my local tree here but I haven't put that patch in yet. It's here, it's very simple actually for the Linux side but of course the Windows one looks limited by Windows (unless using SDL there I guess). Also I am now wanting to investigate that more that I got the X Driver behaving properly, and figure out if it really only is SDL 1.3 that listens to the refresh rate, or if I can change it so both SDL1.2 and other methods all use it. Might want to figure out ways to have MAME change the resolution with xrandr since it seems like the new and upcoming method of doing changes and possibly why they removed modeline support (xrandr can add modelines itself, and can call ours or the ones it added. The issue is that modelines it adds aren't callable by SDL for some odd reason).
Linux patch:
--- Code: ---diff -ru ../Mame_vanilla_0139u3_local/src/osd/sdl/video.c ./src/osd/sdl/video.c
--- ../Mame_vanilla_0139u3_local/src/osd/sdl/video.c 2010-10-08 14:10:30.000000000 -0500
+++ ./src/osd/sdl/video.c 2010-10-08 17:32:14.000000000 -0500
@@ -898,7 +898,8 @@
const char *defdata = options_get_string(mame_options(), SDLOPTION_RESOLUTION(""));
const char *data = options_get_string(mame_options(), name);
- config->width = config->height = config->depth = config->refresh = 0;
+ config->width = config->height = config->depth = 0;
+ config->refresh = 0.0;
if (strcmp(data, SDLOPTVAL_AUTO) == 0)
{
if (strcmp(defdata, SDLOPTVAL_AUTO) == 0)
@@ -909,7 +910,7 @@
data = defdata;
}
- if (sscanf(data, "%dx%dx%d@%d", &config->width, &config->height, &config->depth, &config->refresh) < 2 && report_error)
+ if (sscanf(data, "%dx%dx%d@%lf", &config->width, &config->height, &config->depth, &config->refresh) < 2 && report_error)
mame_printf_error("Illegal resolution value for %s = %s\n", name, data);
}
diff -ru ../Mame_vanilla_0139u3_local/src/osd/sdl/video.h ./src/osd/sdl/video.h
--- ../Mame_vanilla_0139u3_local/src/osd/sdl/video.h 2010-02-14 12:59:50.000000000 -0600
+++ ./src/osd/sdl/video.h 2010-10-08 17:29:09.000000000 -0500
@@ -82,7 +82,7 @@
int width; // decoded width
int height; // decoded height
int depth; // decoded depth
- int refresh; // decoded refresh
+ double refresh; // decoded refresh
int totalColors; // total colors from machine
};
diff -ru ../Mame_vanilla_0139u3_local/src/osd/sdl/window.h ./src/osd/sdl/window.h
--- ../Mame_vanilla_0139u3_local/src/osd/sdl/window.h 2010-10-08 14:10:30.000000000 -0500
+++ ./src/osd/sdl/window.h 2010-10-08 17:26:46.000000000 -0500
@@ -63,7 +63,7 @@
int minwidth, minheight;
int maxwidth, maxheight;
int depth;
- int refresh;
+ double refresh;
int windowed_width;
int windowed_height;
int startmaximized;
--- End code ---
Windows patch:
--- Code: ---diff -ru ../Mame_vanilla_0139u3_local/src/osd/windows/video.c ./src/osd/windows/video.c
--- ../Mame_vanilla_0139u3_local/src/osd/windows/video.c 2010-10-08 14:09:59.000000000 -0500
+++ ./src/osd/windows/video.c 2010-10-08 17:33:05.000000000 -0500
@@ -553,13 +553,14 @@
const char *defdata = options_get_string(mame_options(), WINOPTION_RESOLUTION);
const char *data = options_get_string(mame_options(), name);
- config->width = config->height = config->refresh = 0;
+ config->width = config->height = 0;
+ config->refresh = 0.0;
if (strcmp(data, "auto") == 0)
{
if (strcmp(defdata, "auto") == 0)
return;
data = defdata;
}
- if (sscanf(data, "%dx%d@%d", &config->width, &config->height, &config->refresh) < 2 && report_error)
+ if (sscanf(data, "%dx%d@%lf", &config->width, &config->height, &config->refresh) < 2 && report_error)
mame_printf_error("Illegal resolution value for %s = %s\n", name, data);
}
diff -ru ../Mame_vanilla_0139u3_local/src/osd/windows/video.h ./src/osd/windows/video.h
--- ../Mame_vanilla_0139u3_local/src/osd/windows/video.h 2009-10-12 01:45:26.000000000 -0500
+++ ./src/osd/windows/video.h 2010-10-08 17:34:11.000000000 -0500
@@ -78,7 +78,7 @@
float aspect; // decoded aspect ratio
int width; // decoded width
int height; // decoded height
- int refresh; // decoded refresh
+ double refresh; // decoded refresh
};
diff -ru ../Mame_vanilla_0139u3_local/src/osd/windows/window.h ./src/osd/windows/window.h
--- ../Mame_vanilla_0139u3_local/src/osd/windows/window.h 2010-10-08 14:09:59.000000000 -0500
+++ ./src/osd/windows/window.h 2010-10-08 17:33:51.000000000 -0500
@@ -92,7 +92,7 @@
int fullscreen;
int fullscreen_safe;
int maxwidth, maxheight;
- int refresh;
+ double refresh;
float aspect;
// rendering info
--- End code ---
--- Quote from: Calamity on October 12, 2010, 05:21:30 am ---
- The driver will parse texts labels in the Modes section of xorg.conf until it finds one that matches "WxHxR" values.
--- End quote ---
In theory yes, but still to be proven if it really always makes the right decision which depends on the above patch and figuring out SDL 1.3 possibly. Which 1.3 has been in development for years, and doesn't look like they plan on ever really releasing something that is stable, I hope it happens soon because I think it solves all these issues. I need to test it more to see if it is usable or not.
--- Quote from: Calamity on October 12, 2010, 05:21:30 am ---- Then, the driver will use this label to get the proper modeline from the Monitor section of xorg.conf, and use this modeline to program Radeon hardware :applaud:
- If the driver didn't find the mode we're asking for in the modeline table, it will produce a brand new modeline on the fly by calling lrmc.
--- End quote ---
Yep, that's the nice thing about how lrmc fits in and basically does the same as they do following the use a modeline calculator in X method. They have CVT and UMG actually available in the X Server for drivers to use, now we have lrmc support in at least the radeon driver. So you in theory could totally trust lrmc and just do a line of Mode labels with "HxWxR" formats and it'll run those using the method you choose with the "ArcadeMonitor" Option set to either using /etc/lrmc.conf if it is set to "lrmc" or one of the supported types of monitors by lrmc like cga,ega,d9800 etc.
--- Quote from: Calamity on October 12, 2010, 05:21:30 am ---This is exactly what we needed, even more.
When I have the time, I'd like to have a look at lrmc and see how things are done. I've been playing with Win32 lrmc and noticed a strange behaviour with some resolutions. I'd like to build a Win32 binary of your version, to be able to perform some tests. Eventually, I might add some of my stuff to lrmc, though I lack the C knowlegde.
--- End quote ---
That would be great, because I know lrmc isn't always making the best decisions and can tell from your program that you could probably really shape it up and get things working much nicer with better modelines generated. With that, this version of lrmc improved would be very useful to both Windows Soft15Khz users to make .ini files and modelines there and Linux users with the Radeon driver. I'm just glad that now that the Radeon driver will play ball with us and use our Modelines, we now can figure out the actual modeline generation and vsync issues. Which is the more exciting part of course, that Radeon driver was quite crazy to figure out how to read the Modelines and now looking at what I had to do it was not terribly complicated but totally undocumented and I see no other driver in X doing what I did. The modelines from the config file are all there and available to the driver but it just never took the time to get them, compare them to the Modes section, and pick the ones that matched.
--- Quote from: Calamity on October 12, 2010, 05:21:30 am ---Thanks again for the good work!
--- End quote ---
Thanks, Now I'm planning on looking through your modeline generator some and also the MAME sources to figure out more about how to make better modelines and make sure MAME can pick the right modeline, see about vsync and how that is done with SDL.
You help would be great, understand about the C code knowledge but if you had time it would be really helpful if you possibly could write out the general procedure you go through to take a games resolution from the MAME xml file, and turn that into the final .ini file resolution and modeline. Just basic outline type stuff, because I am reading but it's definitely hard to fully grasp it quickly though. I can put things into code in C but since you know the algorithms so well then will definitely be nice to combine that knowledge. Will see how quickly I can grasp from your program what your doing, think I can but may take a week of looking each day to start catching on better. Looking at what lrmc is something I need to do too because it's rather complicated from what I can tell, and seeing both compared together may be able to help me get the idea of how these modelines are computed to come up with the best final modeline.
--- Quote from: Calamity on October 12, 2010, 05:21:30 am ---
--- End quote ---
bitbytebit:
I've confirmed that it does not always set the right refresh rate with MAME and SDL 1.2 so it picks the first modeline it sees. This has two issues, one of course it's the wrong modeline, two since the X driver throws in a set of default resolutions it seems to want us to have of basic "WxH" values they always override when there's one available for that size resolution. So I'm guessing possibly SDL 1.3 doesn't have this issue, but of course we aren't there yet. So I like your idea of incrementing the first W size by one for each of our custom modelines to allow mame to call the correct ones with the .ini files referencing them. I don't know if it's possible to remove those default resolutions from X because it does that in the main xorg-server part and not the radeon driver itself. Also even if I get those to stop it, it's not a change they'd ever accept to include in the official driver (not sure they'd accept these ones I'm doing for arcade monitors, maybe just lrmc integration and an arcade setting but otherwise the philosophy of the Xorg seems to be not to let users touch modelines). Also then we'd still be needing to do your fix too for references modelines properly.
On a good note I have been able to get doublescan and interlacing support fixed since the newer radeon driver supports those and now I can display 192 Vertical resolution games perfectly with doublescan, like the transformers one. There's a few changes I have done to lrmc last night after the last 8a version of genres which allow this to work, by checking to see if it should do doublescan or not else by default enabling it allows it to do it for games it should probably not do it for. I think lrmc seems a bit untamed and sometimes goes overbounds with things like interlacing and doublescan or making the wxh too large and so I've been adding rules to fixup the wxhxr and settings it normally would choose. Hopefully it can be made to really properly calculate things a bit more controlled eventually the first time and not have to use second passes on the output.
Calamity:
Hi bitbytebit,
We also have that problem with default video modes appearing on us in Windows. Fortunately custom modelines override default modes when they match. But as room for video modes is very limited (60 by default, 200 with my hacked drivers) and these modes waste space we have to "restrict" them, there's a registry key to do this.
It would be great you got SDL to properly deal with vertical refresh. In Windows we have this "integer bottleneck" in the DirectX functions (who would ever want to deal with double precission vfreq values?), that lead me to use that system for differencing modelines. However, this system has a drawback: as variety of video modes reported by Mame xml increases with each new version, you can eventually run out of "x-labels", as fake increased xres reaches the next 8-multiple. Thus, it becomes a need to control the total number of produced modelines - which by the way I must do in Windows to keep the number below the limit - Writing an algorithm that does a good job reducing a resolution list while keeping the most important ones, is not a trivial matter, I'd say it's the most difficult part of the game. I believe lrmc has an implementation of this. There's something more to care about when using this system: Mame tries to center the game frame on the screen, so if you use a fake xres increased more than one pixel you will start loosing pixels on frame's right side, as you'll have a hardware vs logic resolution issue (Mame would work with a logical frame bigger than the screen resolution, so a patch on this would be needed). If SDL thing can be figured out, all this would not be necessary.
It's good news you have doublescan working! I haven't been able to turn it on for custom modelines in Windows (though the card is capable and it works for default modes). This is due to buggy Catalyst drivers.
By the tests done by VeS and me, lrmc seems a little twisted when dealing with low resolutions. We couldn't force it to produce an exact 256x224 resolution for Toki, using lrmc.conf to store our Hantarex settings. Maybe we're missing something?
I've devoted a lot of time to think about the best way of selecting resolutions for games. I don't believe there's a "perfect way". The selection is monitor dependent. In many cases you just have go for the less bad option, and even then it depends on taste. Now I regret all the development I've done is focused on lowres arcade monitors, but I think it won't be difficult to extend the logic to multisync monitors, and it's a good chance to do it. When I have the time I'll sketch the basic idea, it's not so complicated after all.
bitbytebit:
--- Quote from: Calamity on October 12, 2010, 03:43:34 pm ---Hi bitbytebit,
We also have that problem with default video modes appearing on us in Windows. Fortunately custom modelines override default modes when they match. But as room for video modes is very limited (60 by default, 200 with my hacked drivers) and these modes waste space we have to "restrict" them, there's a registry key to do this.
It would be great you got SDL to properly deal with vertical refresh. In Windows we have this "integer bottleneck" in the DirectX functions (who would ever want to deal with double precission vfreq values?), that lead me to use that system for differencing modelines. However, this system has a drawback: as variety of video modes reported by Mame xml increases with each new version, you can eventually run out of "x-labels", as fake increased xres reaches the next 8-multiple. Thus, it becomes a need to control the total number of produced modelines - which by the way I must do in Windows to keep the number below the limit - Writing an algorithm that does a good job reducing a resolution list while keeping the most important ones, is not a trivial matter, I'd say it's the most difficult part of the game. I believe lrmc has an implementation of this. There's something more to care about when using this system: Mame tries to center the game frame on the screen, so if you use a fake xres increased more than one pixel you will start loosing pixels on frame's right side, as you'll have a hardware vs logic resolution issue (Mame would work with a logical frame bigger than the screen resolution, so a patch on this would be needed). If SDL thing can be figured out, all this would not be necessary.
It's good news you have doublescan working! I haven't been able to turn it on for custom modelines in Windows (though the card is capable and it works for default modes). This is due to buggy Catalyst drivers.
By the tests done by VeS and me, lrmc seems a little twisted when dealing with low resolutions. We couldn't force it to produce an exact 256x224 resolution for Toki, using lrmc.conf to store our Hantarex settings. Maybe we're missing something?
I've devoted a lot of time to think about the best way of selecting resolutions for games. I don't believe there's a "perfect way". The selection is monitor dependent. In many cases you just have go for the less bad option, and even then it depends on taste. Now I regret all the development I've done is focused on lowres arcade monitors, but I think it won't be difficult to extend the logic to multisync monitors, and it's a good chance to do it. When I have the time I'll sketch the basic idea, it's not so complicated after all.
--- End quote ---
I'm thinking about hacking at the actual xserver itself, because then I can just stop it from shoving in extra modelines and also might be better to have it and the radeon driver always at the same level. It's an idea at least, I'm still not certain how practical it is to have an alternate version of it. just having the radeon driver makes sense, but the whole xserver is saying there's something really wrong. Interestingly though doing that would allow me to fix the modeline issue for all cards because that is where we could insert them for anybody. That is where they seem to have possibly removed the functionality I am guessing, and then told the drivers to all create them with the Vesa cvt program. Also I have found that it definitely isn't labels, but actual sizes that the SDL layer is commanding the X server to change to, so I can't just change the label. I have just wrote code to test this changing by 1 pixel the horizontal resolution per refresh rate. So far seems like there's really no more than up to 4-5 duplicate resolutions, but is concerning about how it has to do it this way with SDL 1.2. So from what I can tell, only SDL 1.3 fixes the refresh issue, I think it also does the vsync stuff too. Possibly looking at that next and seeing if it works at all, I think I had SDL 1.3 running before but may not have been using switchres and that might be where it is broken actually. That of course is the only reason we would want to use it, so then would negate any positives about it.
LRMC is odd, because unless you specify the -n option for no stretch, it will add tons to the low resolutions, then make sure you have -l set too for a 5Mhz pixel clock. Oddly what happens, is when you set things with the lrmc.conf file you don't get the full changes of a CGA monitor as you would with the predefined -cga option. Since it only changes those values in the config file and not the other key values for the modeline. If you can get a few good modelines, or one at least, and put it into lrmc.conf it does better at guessing the frontporch and other values like that. I definitely think lrmc could use a lot of little fixups in how it calculates things, the doublescan works well with the newest ati radeon driver it seems and was broken with the older version I had (it was a month or two old, they just fixed it in the last couple weeks from the change log). I have to basically keep lrmc under control and only say try doublescan if the resolution is <= 192, else it would do it for everything it can that wants a large resolution. It will go out of range of the proper Vsync values willingly when using doublescan, can double what you put into the config or the preset values. At least from what I can tell, I might be wrong on that, but the xrandr program says they are big. Also I have tried using xrandr and it is just very unstable and terrible at doing the resolution switching, won't even work with this ati radeon driver possibly because it's newer than the xserver I'm using. So another reason I want to look at the xserver and see about hacking at it to fix the default resolutions. overriding them is an option but it get's tricky because then you've got a resolution that isn't incremented by 1 and have to be exact while right now I'm by default incrementing them by one to avoid the default resolutions. I need to figure out how to avoid that, I have some ideas, probably just make the first label not include the refresh rate which will override the default ones. Although those default ones are annoying because it'll put 3 sometimes possibly of one resolution all with the basic label like "640x480" and I'm not sure it really will override all 3 if I add one more to that mess. So hacking the xserver would allow me to trust the resolutions to have the first one at the right Horizontal size and additional ones increment from there.
bitbytebit:
--- Quote from: bitbytebit on October 12, 2010, 04:03:33 pm ---
--- Quote from: Calamity on October 12, 2010, 03:43:34 pm ---Hi bitbytebit,
We also have that problem with default video modes appearing on us in Windows. Fortunately custom modelines override default modes when they match. But as room for video modes is very limited (60 by default, 200 with my hacked drivers) and these modes waste space we have to "restrict" them, there's a registry key to do this.
It would be great you got SDL to properly deal with vertical refresh. In Windows we have this "integer bottleneck" in the DirectX functions (who would ever want to deal with double precission vfreq values?), that lead me to use that system for differencing modelines. However, this system has a drawback: as variety of video modes reported by Mame xml increases with each new version, you can eventually run out of "x-labels", as fake increased xres reaches the next 8-multiple. Thus, it becomes a need to control the total number of produced modelines - which by the way I must do in Windows to keep the number below the limit - Writing an algorithm that does a good job reducing a resolution list while keeping the most important ones, is not a trivial matter, I'd say it's the most difficult part of the game. I believe lrmc has an implementation of this. There's something more to care about when using this system: Mame tries to center the game frame on the screen, so if you use a fake xres increased more than one pixel you will start loosing pixels on frame's right side, as you'll have a hardware vs logic resolution issue (Mame would work with a logical frame bigger than the screen resolution, so a patch on this would be needed). If SDL thing can be figured out, all this would not be necessary.
It's good news you have doublescan working! I haven't been able to turn it on for custom modelines in Windows (though the card is capable and it works for default modes). This is due to buggy Catalyst drivers.
By the tests done by VeS and me, lrmc seems a little twisted when dealing with low resolutions. We couldn't force it to produce an exact 256x224 resolution for Toki, using lrmc.conf to store our Hantarex settings. Maybe we're missing something?
I've devoted a lot of time to think about the best way of selecting resolutions for games. I don't believe there's a "perfect way". The selection is monitor dependent. In many cases you just have go for the less bad option, and even then it depends on taste. Now I regret all the development I've done is focused on lowres arcade monitors, but I think it won't be difficult to extend the logic to multisync monitors, and it's a good chance to do it. When I have the time I'll sketch the basic idea, it's not so complicated after all.
--- End quote ---
I'm thinking about hacking at the actual xserver itself, because then I can just stop it from shoving in extra modelines and also might be better to have it and the radeon driver always at the same level. It's an idea at least, I'm still not certain how practical it is to have an alternate version of it. just having the radeon driver makes sense, but the whole xserver is saying there's something really wrong. Interestingly though doing that would allow me to fix the modeline issue for all cards because that is where we could insert them for anybody. That is where they seem to have possibly removed the functionality I am guessing, and then told the drivers to all create them with the Vesa cvt program. Also I have found that it definitely isn't labels, but actual sizes that the SDL layer is commanding the X server to change to, so I can't just change the label. I have just wrote code to test this changing by 1 pixel the horizontal resolution per refresh rate. So far seems like there's really no more than up to 4-5 duplicate resolutions, but is concerning about how it has to do it this way with SDL 1.2. So from what I can tell, only SDL 1.3 fixes the refresh issue, I think it also does the vsync stuff too. Possibly looking at that next and seeing if it works at all, I think I had SDL 1.3 running before but may not have been using switchres and that might be where it is broken actually. That of course is the only reason we would want to use it, so then would negate any positives about it.
LRMC is odd, because unless you specify the -n option for no stretch, it will add tons to the low resolutions, then make sure you have -l set too for a 5Mhz pixel clock. Oddly what happens, is when you set things with the lrmc.conf file you don't get the full changes of a CGA monitor as you would with the predefined -cga option. Since it only changes those values in the config file and not the other key values for the modeline. If you can get a few good modelines, or one at least, and put it into lrmc.conf it does better at guessing the frontporch and other values like that. I definitely think lrmc could use a lot of little fixups in how it calculates things, the doublescan works well with the newest ati radeon driver it seems and was broken with the older version I had (it was a month or two old, they just fixed it in the last couple weeks from the change log). I have to basically keep lrmc under control and only say try doublescan if the resolution is <= 192, else it would do it for everything it can that wants a large resolution. It will go out of range of the proper Vsync values willingly when using doublescan, can double what you put into the config or the preset values. At least from what I can tell, I might be wrong on that, but the xrandr program says they are big. Also I have tried using xrandr and it is just very unstable and terrible at doing the resolution switching, won't even work with this ati radeon driver possibly because it's newer than the xserver I'm using. So another reason I want to look at the xserver and see about hacking at it to fix the default resolutions. overriding them is an option but it get's tricky because then you've got a resolution that isn't incremented by 1 and have to be exact while right now I'm by default incrementing them by one to avoid the default resolutions. I need to figure out how to avoid that, I have some ideas, probably just make the first label not include the refresh rate which will override the default ones. Although those default ones are annoying because it'll put 3 sometimes possibly of one resolution all with the basic label like "640x480" and I'm not sure it really will override all 3 if I add one more to that mess. So hacking the xserver would allow me to trust the resolutions to have the first one at the right Horizontal size and additional ones increment from there.
--- End quote ---
Just did some tests, got my incrementing code so it only does it when needed, I also had to make it back off and decrease by 1 for duplicates when they were at the maximum horizontal size like 640x480. Would decreasing it be an option that at least wouldn't go off screen and instead just slightly reduce the picture by a pixel or two? Basically I am now just making my modeline labels the "HxW" format to try and beat the default ones X inserts (there's only two really with my Hsync/Vsync values low enough, there's a 640x480 and 320x240, which work but the 320x240 one has too high of Vrefresh and also is off center). It looks like from what I can tell I can't really override the default ones this way, it'll just force them in there still and then it's up the the sorting process which one wins out and is on top. The duplicating method beats them it seems because they are always one pixel more and it seems to sort them by H values. I guess that's a downfall of the decreasing method, unless we can really knock those things out of there.
Also I've found that lrmc really is no good at anything besides EGA/VGA calculations, the VGA are off and then the SVGA are way off. The default resolution X windows uses seems to have been what overrides my default screen for X normally, because when I incremented them it got all warped and it turns out that the lrmc VGA resolutions are just bad. It also shows how X aggressively replaces and prioritizes the resolutions it has over your own, at least with that one it did because it's always been used even when I thought it couldn't be. This I guess is yet another sign I might need to change the xserver itself, which I know where exactly the code is to do it. Calling that function from the Radeon driver itself and redoing it might work, but I'm not sure all the code from that function can port into the Radeon driver and still work. It's the basic X xf86InitialConfiguration() function where it takes are modelines we added and the default ones it chose for us and combines them all together.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version