If the refresh rate hasn't been explicitly specified, fd_find_mode
currently returns the first mode with the requested resolution. Change
it so that it returns a mode with the requested resolution and the
highest refresh rate.
Also export fb_destroy_modelist, which is used in uvesafb.
Signed-off-by: Michal Januszewski <[email protected]>
---
drivers/video/modedb.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
index 3741ad7..98ee77b 100644
--- a/drivers/video/modedb.c
+++ b/drivers/video/modedb.c
@@ -606,16 +606,18 @@ done:
DPRINTK("Trying specified video mode%s %ix%i\n",
refresh_specified ? "" : " (ignoring refresh rate)", xres, yres);
+ if (!refresh_specified)
+ refresh = 200;
diff = refresh;
best = -1;
for (i = 0; i < dbsize; i++) {
if (name_matches(db[i], name, namelen) ||
(res_specified && res_matches(db[i], xres, yres))) {
if(!fb_try_mode(var, info, &db[i], bpp)) {
- if(!refresh_specified || db[i].refresh == refresh)
+ if (refresh_specified && db[i].refresh == refresh)
return 1;
else {
- if(diff > abs(db[i].refresh - refresh)) {
+ if (diff > abs(db[i].refresh - refresh)) {
diff = abs(db[i].refresh - refresh);
best = i;
}
@@ -938,6 +940,7 @@ void fb_destroy_modelist(struct list_head *head)
kfree(pos);
}
}
+EXPORT_SYMBOL_GPL(fb_destroy_modelist);
/**
* fb_videomode_to_modelist: convert mode array to mode list
On Sat, 23 Jun 2007 12:50:46 +0200 Michal Januszewski <[email protected]> wrote:
> If the refresh rate hasn't been explicitly specified, fd_find_mode
> currently returns the first mode with the requested resolution. Change
> it so that it returns a mode with the requested resolution and the
> highest refresh rate.
>
> Also export fb_destroy_modelist, which is used in uvesafb.
>
> Signed-off-by: Michal Januszewski <[email protected]>
> ---
> drivers/video/modedb.c | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/modedb.c b/drivers/video/modedb.c
> index 3741ad7..98ee77b 100644
> --- a/drivers/video/modedb.c
> +++ b/drivers/video/modedb.c
> @@ -606,16 +606,18 @@ done:
> DPRINTK("Trying specified video mode%s %ix%i\n",
> refresh_specified ? "" : " (ignoring refresh rate)", xres, yres);
>
> + if (!refresh_specified)
> + refresh = 200;
> diff = refresh;
> best = -1;
> for (i = 0; i < dbsize; i++) {
> if (name_matches(db[i], name, namelen) ||
> (res_specified && res_matches(db[i], xres, yres))) {
> if(!fb_try_mode(var, info, &db[i], bpp)) {
> - if(!refresh_specified || db[i].refresh == refresh)
> + if (refresh_specified && db[i].refresh == refresh)
> return 1;
> else {
> - if(diff > abs(db[i].refresh - refresh)) {
> + if (diff > abs(db[i].refresh - refresh)) {
> diff = abs(db[i].refresh - refresh);
> best = i;
> }
> @@ -938,6 +940,7 @@ void fb_destroy_modelist(struct list_head *head)
> kfree(pos);
> }
> }
> +EXPORT_SYMBOL_GPL(fb_destroy_modelist);
>
fbdev ignoramus asks: isn't this pretty risky? People who were previously
relying upon (or at least using) the kernel's default resolution will find
their displays coming up in a quite different resolution.
This change seems to be quite unrelated to the uvesafb stuff and should be
in a separate patch from the export, which _is_ uvesafb-related. I think.
If that's wrong then the changelog could do with some attention.
On Sat, Jun 23, 2007 at 11:04:24AM -0700, Andrew Morton wrote:
> On Sat, 23 Jun 2007 12:50:46 +0200 Michal Januszewski <[email protected]> wrote:
>
> > + if (!refresh_specified)
> > + refresh = 200;
> > diff = refresh;
> > best = -1;
> > for (i = 0; i < dbsize; i++) {
> > if (name_matches(db[i], name, namelen) ||
> > (res_specified && res_matches(db[i], xres, yres))) {
> > if(!fb_try_mode(var, info, &db[i], bpp)) {
> > - if(!refresh_specified || db[i].refresh == refresh)
> > + if (refresh_specified && db[i].refresh == refresh)
> > return 1;
> > else {
> > - if(diff > abs(db[i].refresh - refresh)) {
> > + if (diff > abs(db[i].refresh - refresh)) {
> > diff = abs(db[i].refresh - refresh);
> > best = i;
> > }
> > @@ -938,6 +940,7 @@ void fb_destroy_modelist(struct list_head *head)
> > kfree(pos);
> > }
> > }
> > +EXPORT_SYMBOL_GPL(fb_destroy_modelist);
> >
>
> fbdev ignoramus asks: isn't this pretty risky? People who were previously
> relying upon (or at least using) the kernel's default resolution will find
> their displays coming up in a quite different resolution.
The resolution will be unchanged (this part of the code is only executed
if either the name of the mode or the resolution are a match).
What can change is the refresh rate -- it can be set higher than what it
used to be before. But since we're checking all modes with fb_try_mode(),
(which calls fb_check_var()), I think that this change should be safe.
To avoid any side effects we could also do the following:
for (i = 0; i < dbsize; i++) {
if (name_matches(db[i], name, namelen) ||
(res_specified && res_matches(db[i], xres, yres))) {
if(!fb_try_mode(var, info, &db[i], bpp)) {
if (refresh_specified && db[i].refresh == refresh)
return 1;
else {
if (diff > abs(db[i].refresh - refresh)) {
diff = abs(db[i].refresh - refresh);
best = i;
}
}
}
}
}
if (best != -1) {
fb_try_mode(var, info, &db[best], bpp);
- return 2;
+ return (refresh_specified) ? 2 : 1;
}
which would ensure that 1 is returned if the refresh rate is not
explicitly specified, just as it is done currently:
if(!refresh_specified || db[i].refresh == refresh)
return 1
I might be missing something here, so it would be nice if someone
involved in the fb development could comment on the proposed change.
> This change seems to be quite unrelated to the uvesafb stuff and should be
> in a separate patch from the export, which _is_ uvesafb-related. I think.
> If that's wrong then the changelog could do with some attention.
You're right, I'll split this into two patches in the next round.
Best regards,
Michal