From: Michal Januszewski <spock@gentoo.org> Date: 2007-06-23 11:00:40
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 <spock@gentoo.org>
---
drivers/video/modedb.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
From: Andrew Morton <akpm@linux-foundation.org> Date: 2007-06-23 18:05:26
On Sat, 23 Jun 2007 12:50:46 +0200 Michal Januszewski [off-list ref] wrote:
quoted hunk
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 <spock@gentoo.org>
---
drivers/video/modedb.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
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.
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
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2007-07-12 08:32:00
On Sat, 2007-06-23 at 12:50 +0200, Michal Januszewski wrote:
quoted hunk
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 <spock@gentoo.org>
---
drivers/video/modedb.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
How about..?
if (!refresh_specified)
diff = 0;
else
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;
}
then
if (diff < db[i].refresh) {
diff = db[i].refresh;
best = i;
}
Tony
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
From: "Antonino A. Daplas" <adaplas@gmail.com> Date: 2007-07-12 08:35:24
On Sat, 2007-06-23 at 11:04 -0700, Andrew Morton wrote:
On Sat, 23 Jun 2007 12:50:46 +0200 Michal Januszewski [off-list ref] wrote:
quoted
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 <spock@gentoo.org>
---
drivers/video/modedb.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
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.
It's only the refresh rate that will change. The current behavior is
that a user can get near random results in terms of the vertical refresh
rates. At least with this patch, we know what we get.
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.
Tony
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/