From: Grzegorz A. H. <gr...@ti...> - 2005-04-25 09:14:03
|
Hi. I have fbset 2.1 (23/06/1999) and I'm running kernel 2.6.10 with Matrox g450 support built into the kernel as well as fbcon. Standing on a console I try running "fbset -a resolution" or "fbset --all resolution" where resolution is one of the modes listed in /etc/fb.modes. However, only the current console's resolution is changed. Is this a bug in fbset? Is there any new version of this software? I remember using fbset on a 2.4.x kernel with the same video card without problems. |
From: Petr V. <van...@vc...> - 2005-04-25 13:26:27
|
Grzegorz Adam Hankiewicz wrote: > Hi. > > I have fbset 2.1 (23/06/1999) and I'm running kernel 2.6.10 with > Matrox g450 support built into the kernel as well as fbcon. Standing > on a console I try running "fbset -a resolution" or "fbset > --all resolution" where resolution is one of the modes listed > in /etc/fb.modes. However, only the current console's resolution > is changed. > > Is this a bug in fbset? Is there any new version of this software? I > remember using fbset on a 2.4.x kernel with the same video card > without problems. As far as I can tell it behaves as designed. If you are not satisifed, try some of matroxfb-* patches from http://platan.vc.cvut.cz/ftp/pub/linux/matrox-latest (either matroxfb-2.6.10.gz, or upgrade to 2.6.12-rc3 and apply relevant matroxfb-2.6.12-rc3.gz). This patch contains 2.4.x fbcon ported to 2.6.x fbdev layer, besides random matroxfb updates, and so fbset should work in a way you are used to after that. On Linus's 2.6.x you are supposed to use stty cols & rows to change resolution, and you are not supposed to change color depth. Petr Vandrovec |
From: Grzegorz A. H. <gr...@ti...> - 2005-04-27 12:02:38
|
On 2005-04-25, Petr Vandrovec <van...@vc...> wrote: > As far as I can tell it behaves as designed. Well, if fbset has an "--all" parameter which doesn't affect all consoles... I guess you mean that the current kernel fb support is designed to not allow this, and it's just fbset which hasn't been updated? > If you are not satisifed, try some of matroxfb-* patches from > http://platan.vc.cvut.cz/ftp/pub/linux/matrox-latest (either > matroxfb-2.6.10.gz, or upgrade to 2.6.12-rc3 and apply relevant > matroxfb-2.6.12-rc3.gz). This patch contains 2.4.x fbcon ported > to 2.6.x fbdev layer, besides random matroxfb updates, and so > fbset should work in a way you are used to after that. Thanks. I've tried using the matroxfb-2.6.10 patch, but at some points complains about tileops structure not being a complete type. A grep in the subdirectory doesn't show where this structure is being defined, so I don't know how to fix this: In file included from /linux-2.6.10/drivers/video/matrox/matroxfb_base.c:= 106: /linux-2.6.10/drivers/video/matrox/matroxfb_base.h:519: error: field `til= eops' has incomplete type /linux-2.6.10/drivers/video/matrox/matroxfb_base.c: En la funci=F3n `init= Matrox2': /linux-2.6.10/drivers/video/matrox/matroxfb_base.c:1980: error: structure= has no member named `tileops' matroxfb_accel complains too if I use "make -k". > On Linus's 2.6.x you are supposed to use stty cols & rows to > change resolution, and you are not supposed to change color depth. I'm shocked. Is he going to ban changing color depth at all in the future? Right now I boot into some vesa mode and need fbset to set the same resolution with hardware acceleration to avoid it being so sluggish. Is there a way to do this with stty rather than fbset? |
From: Antonino A. D. <ad...@ho...> - 2005-04-28 03:33:22
|
On Wednesday 27 April 2005 20:25, Grzegorz Adam Hankiewicz wrote: > On 2005-04-25, Petr Vandrovec <van...@vc...> wrote: > I'm shocked. Is he going to ban changing color depth at all in the > future? Right now I boot into some vesa mode and need fbset to set > the same resolution with hardware acceleration to avoid it being > so sluggish. Is there a way to do this with stty rather than fbset? fbset has been working for 2-3 kernel versions already, well, except for the fbset -a part, which for some time I've known not to work. I decided to fix it only if someone complains. Tony |
From: James S. <jsi...@ww...> - 2005-04-26 20:43:01
|
> On Linus's 2.6.x you are supposed to use stty cols & rows to change resolution, > and you are not supposed to change color depth. You can use fbset. It works. |
From: Antonino A. D. <ad...@ho...> - 2005-04-26 03:39:42
|
On Monday 25 April 2005 18:17, Grzegorz Adam Hankiewicz wrote: > Hi. > > I have fbset 2.1 (23/06/1999) and I'm running kernel 2.6.10 with > Matrox g450 support built into the kernel as well as fbcon. Standing > on a console I try running "fbset -a resolution" or "fbset > --all resolution" where resolution is one of the modes listed > in /etc/fb.modes. However, only the current console's resolution > is changed. > > Is this a bug in fbset? Is there any new version of this software? I > remember using fbset on a 2.4.x kernel with the same video card > without problems. > Not a bug in fbset, but is due to changes in fbcon code from 2.4->2.6. Now, only the visible console will respond to fbset requests. I'll see what I can do about this bug. Tony |
From: Grzegorz A. H. <gr...@ti...> - 2005-04-26 13:26:51
|
On 2005-04-26, "Antonino A. Daplas" <ad...@ho...> wrote: > Not a bug in fbset, but is due to changes in fbcon code from > 2.4->2.6. Now, only the visible console will respond to fbset > requests. > > I'll see what I can do about this bug. Tell me if I can help in any way. |
From: Antonino A. D. <ad...@ho...> - 2005-04-27 06:08:43
|
On Tuesday 26 April 2005 22:30, Grzegorz Adam Hankiewicz wrote: > On 2005-04-26, "Antonino A. Daplas" <ad...@ho...> wrote: > > Not a bug in fbset, but is due to changes in fbcon code from > > 2.4->2.6. Now, only the visible console will respond to fbset > > requests. > > > > I'll see what I can do about this bug. > > Tell me if I can help in any way. Can you test this patch? This is against my tree which is based on 2.6.12-rc2-mm3 for this patch, but you can use other kernels if you're willing to fix hunks. Tony diff -Nru a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c --- a/drivers/video/console/fbcon.c 2005-03-23 11:53:44 +08:00 +++ b/drivers/video/console/fbcon.c 2005-04-27 11:37:20 +08:00 @@ -2598,6 +2598,51 @@ } } +static void fbcon_set_all_vcs(struct fb_info *info) +{ + struct fbcon_ops *ops = info->fbcon_par; + struct vc_data *vc; + struct display *p; + int i, rows, cols; + + if (!ops || ops->currcon < 0) + return; + + for (i = 0; i < MAX_NR_CONSOLES; i++) { + vc = vc_cons[i].d; + if (!vc || vc->vc_mode != KD_TEXT || + registered_fb[con2fb_map[i]] != info) + continue; + + p = &fb_display[vc->vc_num]; + + info->var.xoffset = info->var.yoffset = p->yscroll = 0; + var_to_display(p, &info->var, info); + cols = info->var.xres / vc->vc_font.width; + rows = info->var.yres / vc->vc_font.height; + vc_resize(vc, cols, rows); + + if (CON_IS_VISIBLE(vc)) { + updatescrollmode(p, info, vc); + scrollback_max = 0; + scrollback_current = 0; + update_var(vc->vc_num, info); + fbcon_set_palette(vc, color_table); + update_screen(vc); + if (softback_buf) { + int l = fbcon_softback_size / vc->vc_size_row; + if (l > 5) + softback_end = softback_buf + l * vc->vc_size_row; + else { + /* Smaller scrollback makes no sense, and 0 + would screw the operation totally */ + softback_top = 0; + } + } + } + } +} + static int fbcon_mode_deleted(struct fb_info *info, struct fb_videomode *mode) { @@ -2712,6 +2757,9 @@ break; case FB_EVENT_MODE_CHANGE: fbcon_modechanged(info); + break; + case FB_EVENT_MODE_CHANGE_ALL: + fbcon_set_all_vcs(info); break; case FB_EVENT_MODE_DELETE: mode = event->data; diff -Nru a/drivers/video/fbmem.c b/drivers/video/fbmem.c --- a/drivers/video/fbmem.c 2005-04-14 12:06:43 +08:00 +++ b/drivers/video/fbmem.c 2005-04-27 11:37:20 +08:00 @@ -729,11 +729,13 @@ if (!err && info->flags & FBINFO_MISC_USEREVENT) { struct fb_event event; + int evnt = (var->activate & FB_ACTIVATE_ALL) ? + FB_EVENT_MODE_CHANGE_ALL : + FB_EVENT_MODE_CHANGE; info->flags &= ~FBINFO_MISC_USEREVENT; event.info = info; - notifier_call_chain(&fb_notifier_list, - FB_EVENT_MODE_CHANGE, + notifier_call_chain(&fb_notifier_list, evnt, &event); } } diff -Nru a/include/linux/fb.h b/include/linux/fb.h --- a/include/linux/fb.h 2005-04-14 12:44:11 +08:00 +++ b/include/linux/fb.h 2005-04-27 11:37:20 +08:00 @@ -495,6 +495,9 @@ #define FB_EVENT_BLANK 0x08 /* Private modelist is to be replaced */ #define FB_EVENT_NEW_MODELIST 0x09 +/* The resolution of the passed in fb_info about to change and + all vc's should be changed */ +#define FB_EVENT_MODE_CHANGE_ALL 0x0A struct fb_event { struct fb_info *info; |
From: Grzegorz A. H. <gr...@ti...> - 2005-04-27 16:26:32
|
> Can you test this patch? This is against my tree which is based > on 2.6.12-rc2-mm3 for this patch, but you can use other kernels > if you're willing to fix hunks. This makes fbset -a work again. Thanks. I had to modify it for 2.6.10. The worst change was I had to get rid of this check: > + if (!vc || vc->vc_mode != KD_TEXT || Apparently my version doesn't have a vc_mode field. Not a problem for me, since by the time I use fbset all my consoles are text mode. |
From: James S. <jsi...@ww...> - 2005-04-26 20:42:26
|
> > Matrox g450 support built into the kernel as well as fbcon. Standing > > on a console I try running "fbset -a resolution" or "fbset > > --all resolution" where resolution is one of the modes listed > > in /etc/fb.modes. However, only the current console's resolution > > is changed. > > > > Is this a bug in fbset? Is there any new version of this software? I > > remember using fbset on a 2.4.x kernel with the same video card > > without problems. > > > > Not a bug in fbset, but is due to changes in fbcon code from 2.4->2.6. > Now, only the visible console will respond to fbset requests. > > I'll see what I can do about this bug. This was done because sometimes the user entered a bad mode which the driver could not handle. As a result all the VCs went blank and became useless. The only fix was to reboot the box. |
From: Antonino A. D. <ad...@ho...> - 2005-04-28 03:33:15
|
On Wednesday 27 April 2005 04:42, James Simmons wrote: > > > Matrox g450 support built into the kernel as well as fbcon. Standing > > > on a console I try running "fbset -a resolution" or "fbset > > > --all resolution" where resolution is one of the modes listed > > > in /etc/fb.modes. However, only the current console's resolution > > > is changed. > > > > > > Is this a bug in fbset? Is there any new version of this software? I > > > remember using fbset on a 2.4.x kernel with the same video card > > > without problems. > > > > Not a bug in fbset, but is due to changes in fbcon code from 2.4->2.6. > > Now, only the visible console will respond to fbset requests. > > > > I'll see what I can do about this bug. > > This was done because sometimes the user entered a bad mode which the > driver could not handle. As a result all the VCs went blank and became > useless. The only fix was to reboot the box. > One of the reasons why /dev/fb should be root-access only. Anyway, if that happens, one can always blindly type fbset commands that can restore the fb console. And if incorrectly using fbset renders the console permanently useless that the only fix is to reboot the box, then it doesn't really matter if one uses fbset with or without the '--all' argument. Tony |
From: James S. <jsi...@ww...> - 2005-04-28 22:28:47
|
> > This was done because sometimes the user entered a bad mode which the > > driver could not handle. As a result all the VCs went blank and became > > useless. The only fix was to reboot the box. > > > > One of the reasons why /dev/fb should be root-access only. > > Anyway, if that happens, one can always blindly type fbset commands that > can restore the fb console. And if incorrectly using fbset renders the > console permanently useless that the only fix is to reboot the box, then it > doesn't really matter if one uses fbset with or without the '--all' > argument. Also the other issue is what if the user only changes the color depth and the VCs are at different resolution. Some resolutions can handle the new depth but others can't. How do we handle this? |
From: Grzegorz A. H. <gr...@ti...> - 2005-04-29 09:36:36
|
On 2005-04-28, James Simmons <jsi...@pe...> wrote: > Also the other issue is what if the user only changes the color > depth and the VCs are at different resolution. Some resolutions > can handle the new depth but others can't. How do we handle this? Fail like fbset fails to set an unknown mode for the current console. fbset would print an error for all the consoles which could not be changed and return nonzero on exit. |
From: Antonino A. D. <ad...@ho...> - 2005-05-07 03:14:24
|
On Friday 29 April 2005 06:28, James Simmons wrote: > > > This was done because sometimes the user entered a bad mode which the > > > driver could not handle. As a result all the VCs went blank and became > > > useless. The only fix was to reboot the box. > > > > One of the reasons why /dev/fb should be root-access only. > > > > Anyway, if that happens, one can always blindly type fbset commands that > > can restore the fb console. And if incorrectly using fbset renders the > > console permanently useless that the only fix is to reboot the box, then > > it doesn't really matter if one uses fbset with or without the '--all' > > argument. > > Also the other issue is what if the user only changes the color depth and > the VCs are at different resolution. Some resolutions can handle the new > depth but others can't. How do we handle this? The way fbset -a works is that all vc's will have the var of the current display. Tony |
From: James S. <jsi...@ww...> - 2005-05-11 16:00:46
|
> > Also the other issue is what if the user only changes the color depth and > > the VCs are at different resolution. Some resolutions can handle the new > > depth but others can't. How do we handle this? > > The way fbset -a works is that all vc's will have the var of the current display. So all is really ALL. Then that is okay :-) |