fbset problem or how to change the res?
Ron Farrer
I'm trying to change the screen res to 1024 x 768 @ 32 or 24 bpp. The
problem is that no matter what I try, I end up with a blank screen and
the only option is to blindly type and reboot... Here is what I'm doing
(perhaps I'm doing it wrong?):
fbset -g 1024 768 1024 768 24
The reason I want to change the res is because everthing is HUGE in
XF86-4 at the default 800 x 600. I have a voodoo 3000 PCI as the fb dev.
TIA,
Ron
--
To UNSUBSCRIBE, email to debian-powe...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
David Roundy
>
> I'm trying to change the screen res to 1024 x 768 @ 32 or 24 bpp. The
> problem is that no matter what I try, I end up with a blank screen and
> the only option is to blindly type and reboot... Here is what I'm doing
> (perhaps I'm doing it wrong?):
> fbset -g 1024 768 1024 768 24
>
> The reason I want to change the res is because everthing is HUGE in
> XF86-4 at the default 800 x 600. I have a voodoo 3000 PCI as the fb dev.
You don't need to use fbset to determine the resolution of X. Just edit
your /etc/X11/XF86Config-4 file, and change the resolution there. Much
easier, and safer too, since it leaves your virtual terminals untouched.
--
David Roundy
http://civet.berkeley.edu/droundy/
Ron Farrer
> You don't need to use fbset to determine the resolution of X. Just edit
> your /etc/X11/XF86Config-4 file, and change the resolution there. Much
> easier, and safer too, since it leaves your virtual terminals untouched.
I tried that first. It doesn't seem to have any effect on the resolution
at all.
Ron
Richard Watson
> David Roundy (dro...@jdj5.mit.edu) wrote:
>
> > You don't need to use fbset to determine the resolution of X. Just edit
> > your /etc/X11/XF86Config-4 file, and change the resolution there. Much
> > easier, and safer too, since it leaves your virtual terminals untouched.
>
> I tried that first. It doesn't seem to have any effect on the resolution
> at all.
What do you change? Can you post the relevant bit of your XF86Config-4 ?
--
Richard Watson
e-mail:ric...@doilywood.org.uk jabber:ric...@jabber.doilywood.org.uk
Ron Farrer
> What do you change? Can you post the relevant bit of your XF86Config-4 ?
You bet, see attached.
TIA,
Ron
Michel Dänzer
> Section "Monitor"
> Identifier "IBM Monitor"
> HorizSync 50-75
> VertRefresh 70-130
> Option "DPMS"
> EndSection
> SubSection "Display"
> Depth 24
> # Modes "1600x1200" "1280x1024" "1280x960" "1152x864" "1024x768"
> Modes "1024x768"
> EndSubSection
> EndSection
The monitor refresh ranges may not allow for the modes you want to use.
Check the server log.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
Richard Watson
> SubSection "Display"
> Depth 24
> # Modes "1600x1200" "1280x1024" "1280x960" "1152x864"
> "1024x768"
> Modes "1024x768"
> EndSubSection
OK.
Does this produce the same blank screen? If so then I'm suspecting
that there's something wrong with what you've entered for horizontal
and vertical refresh rates and your monitor is turning itself off to
stop itself exploding.
If you stick with the original configuration can you do
Ctrl-Opt-[numeric pad Plus] (or maybe it's apple instead of Opt on
your system) to change between the defined resolutions. What does that
do? Is it using the right colour depth and driver?
Ron Farrer
> The monitor refresh ranges may not allow for the modes you want to use.
> Check the server log.
The monitor refresh range was wrong, it should have been (and has been
corrected) 30-96 Hor. and 48-160 Vert.
Here's a snippet from the log:
(II) FBDev(0): Checking modes against framebuffer device...
(II) FBDev(0): mode "1024x768" test failed
(II) FBDev(0): Checking Modes against monitor...
(II) FBDev(0): Virtual size is 640x480 (pitch 640)
Which is why I was trying to change the fb to 1024x768.. but maybe
that's not the way to go? To answer the other guys question, no the
screen doesn't go blank with that setting. It works, but is unusable @
640x480... Any more ideas?
TIA,
Ron
Branden Robinson
> Section "Device"
> Identifier "3dfx Voodoo3 3000"
> Driver "fbdev"
> BusID "PCI:1:15:0"
> VideoRam 16384
> Option "UseFBDev" "true"
> EndSection
Just FYI, that VideoRam line is not necessary.
--
G. Branden Robinson | To stay young requires unceasing
Debian GNU/Linux | cultivation of the ability to
bra...@debian.org | unlearn old falsehoods.
http://people.debian.org/~branden/ | -- Robert Heinlein
Michel Dänzer
> Michel D?nzer (dae...@debian.org) wrote:
>
> > The monitor refresh ranges may not allow for the modes you want to use.
> > Check the server log.
>
> The monitor refresh range was wrong, it should have been (and has been
> corrected) 30-96 Hor. and 48-160 Vert.
>
> Here's a snippet from the log:
> (II) FBDev(0): Checking modes against framebuffer device...
> (II) FBDev(0): mode "1024x768" test failed
Hmm, for some reason, the framebuffer device refuses to display the
1024x768 mode.
> (II) FBDev(0): Checking Modes against monitor...
> (II) FBDev(0): Virtual size is 640x480 (pitch 640)
>
> Which is why I was trying to change the fb to 1024x768.. but maybe
> that's not the way to go?
It's a possible way, in particular if you just put Modes "current" in
the Display subsection.
Getting back to your original question: I guess just 'fbset 1024x768-60'
(or any other 1024x768 mode, see /etc/fb.modes) doesn't work either? Do
you use tdfxfb or OFfb? The latter can't change modes so you either have
to use tdfxfb or the tdfx X driver.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
Ron Farrer
> It's a possible way, in particular if you just put Modes "current" in
> the Display subsection.
>
> Getting back to your original question: I guess just 'fbset 1024x768-60'
> (or any other 1024x768 mode, see /etc/fb.modes) doesn't work either? Do
> you use tdfxfb or OFfb? The latter can't change modes so you either have
> to use tdfxfb or the tdfx X driver.
Ok, I tried changing the modes to "current" and 'fbset
1024x768-anything' works fine, I'm using "-100" right now. However fbset
only effects the current tty. It doesn't effect tty7. So X still runs at
640x480...
As I said in the past, setting the driver to "tdfx" causes the X server
to segfault (signal 11) at startup (see list archives.) When I built
this kernel, I said yes to tdfx framebuffer.. but how do I check if it's
being used? 'cat /proc/fb' shows:
0 3Dfx Voodoo3
1 OFfb /bandit/3Dfx,Voodoo3
Looking at that I'd gather it's using the tdfxfb driver.
As I said in a previous thread, I'd LOVE to get the fdfx driver to work.
So if anyone can help figure out why it segfaults, I'd be very happy -
especially since the fbdev isn't accelerated...
TIA,
Ron
Geert Uytterhoeven
> Michel D?nzer (dae...@debian.org) wrote:
> > It's a possible way, in particular if you just put Modes "current" in
> > the Display subsection.
> >
> > Getting back to your original question: I guess just 'fbset 1024x768-60'
> > (or any other 1024x768 mode, see /etc/fb.modes) doesn't work either? Do
> > you use tdfxfb or OFfb? The latter can't change modes so you either have
> > to use tdfxfb or the tdfx X driver.
>
> Ok, I tried changing the modes to "current" and 'fbset
> 1024x768-anything' works fine, I'm using "-100" right now. However fbset
> only effects the current tty. It doesn't effect tty7. So X still runs at
> 640x480...
>
> As I said in the past, setting the driver to "tdfx" causes the X server
> to segfault (signal 11) at startup (see list archives.) When I built
> this kernel, I said yes to tdfx framebuffer.. but how do I check if it's
> being used? 'cat /proc/fb' shows:
> 0 3Dfx Voodoo3
> 1 OFfb /bandit/3Dfx,Voodoo3
>
> Looking at that I'd gather it's using the tdfxfb driver.
Worse, it's using _both_ drivers on the same card, because tdfxfb doesn't use
resource management yet! You can fix that by saying `video=offb:off', or
better, try this patch (untested, please let me know whether it works):
--- fbdev-resource-2.4.18-rc1/drivers/video/tdfxfb.c.orig Thu Feb 14 09:56:52 2002
+++ fbdev-resource-2.4.18-rc1/drivers/video/tdfxfb.c Sat Feb 16 14:37:39 2002
@@ -1907,6 +1907,7 @@
{
struct fb_var_screeninfo var;
char *name = NULL;
+ int error = -ENXIO;
fb_info.dev = pdev->device;
@@ -1927,28 +1928,36 @@
fb_info.regbase_phys = pci_resource_start(pdev, 0);
fb_info.regbase_size = 1 << 24;
+ if (!request_mem_region(fb_info.regbase_phys, 1 << 24, "tdfxfb")) {
+ error = -EBUSY;
+ goto fail;
+ }
+
fb_info.regbase_virt = ioremap_nocache(fb_info.regbase_phys, 1 << 24);
if (!fb_info.regbase_virt) {
printk(KERN_WARNING "fb: Can't remap %s register area.\n", name);
- return -ENXIO;
+ goto release_reg;
}
fb_info.bufbase_phys = pci_resource_start (pdev, 1);
if (!(fb_info.bufbase_size = do_lfb_size())) {
- iounmap(fb_info.regbase_virt);
printk(KERN_WARNING "fb: Can't count %s memory.\n", name);
- return -ENXIO;
+ goto unmap_reg;
}
+ if (!request_mem_region(fb_info.bufbase_phys, bufbase_size,
+ "tdfxfb")) {
+ error = -EBUSY;
+ goto unmap_reg;
+ }
fb_info.bufbase_virt = ioremap_nocache(fb_info.bufbase_phys,
fb_info.bufbase_size);
if (!fb_info.regbase_virt) {
printk(KERN_WARNING "fb: Can't remap %s framebuffer.\n", name);
- iounmap(fb_info.regbase_virt);
- return -ENXIO;
+ goto release_buf;
}
fb_info.iobase = pci_resource_start (pdev, 2);
@@ -2014,7 +2023,7 @@
if (tdfxfb_decode_var(&var, &fb_info.default_par, &fb_info)) {
/* this is getting really bad!... */
printk(KERN_WARNING "tdfxfb: can't decode default video mode\n");
- return -ENXIO;
+ goto unmap_buf;
}
}
@@ -2023,18 +2032,29 @@
if (tdfxfb_set_var(&var, -1, &fb_info.fb_info)) {
printk(KERN_WARNING "tdfxfb: can't set default video mode\n");
- return -ENXIO;
+ goto unmap_buf;
}
if (register_framebuffer(&fb_info.fb_info) < 0) {
printk(KERN_WARNING "tdfxfb: can't register framebuffer\n");
- return -ENXIO;
+ goto unmap_buf;
}
printk(KERN_INFO "fb%d: %s frame buffer device\n",
GET_FB_IDX(fb_info.fb_info.node), fb_info.fb_info.modename);
return 0;
+
+unmap_buf:
+ iounmap(fb_info.bufbase_virt);
+release_buf:
+ release_mem_region(fb_info.bufbase_phys, bufbase_size);
+unmap_reg:
+ iounmap(fb_info.regbase_virt);
+release_reg:
+ release_mem_region(fb_info.regbase_phys, 1 << 24);
+fail:
+ return error;
}
/**
@@ -2058,8 +2078,10 @@
}
#endif
- iounmap(fb_info.regbase_virt);
iounmap(fb_info.bufbase_virt);
+ release_mem_region(fb_info.bufbase_phys, bufbase_size);
+ iounmap(fb_info.regbase_virt);
+ release_mem_region(fb_info.regbase_phys, 1 << 24);
}
int __init tdfxfb_init(void)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Michel Dänzer
> Michel D?nzer (dae...@debian.org) wrote:
>
> > It's a possible way, in particular if you just put Modes "current" in
> > the Display subsection.
> >
> > Getting back to your original question: I guess just 'fbset 1024x768-60'
> > (or any other 1024x768 mode, see /etc/fb.modes) doesn't work either? Do
> > you use tdfxfb or OFfb? The latter can't change modes so you either have
> > to use tdfxfb or the tdfx X driver.
>
> Ok, I tried changing the modes to "current" and 'fbset
> 1024x768-anything' works fine, I'm using "-100" right now. However fbset
> only effects the current tty. It doesn't effect tty7. So X still runs at
> 640x480...
Try fbset with -a (see fbset -h or man fbset).
> As I said in the past, setting the driver to "tdfx" causes the X server
> to segfault (signal 11) at startup (see list archives.) When I built
> this kernel, I said yes to tdfx framebuffer.. but how do I check if it's
> being used? 'cat /proc/fb' shows:
> 0 3Dfx Voodoo3
> 1 OFfb /bandit/3Dfx,Voodoo3
>
> Looking at that I'd gather it's using the tdfxfb driver.
You are, you couldn't have changed the mode with fbset otherwise.
> As I said in a previous thread, I'd LOVE to get the fdfx driver to work.
> So if anyone can help figure out why it segfaults, I'd be very happy -
> especially since the fbdev isn't accelerated...
Some people here have gotten it to work, and there's a page about how to
do it somewhere on the web.
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
Ron Farrer
> Try fbset with -a (see fbset -h or man fbset).
Interesting.. -a isn't listed in the man page (which I did read BTW.) It
is listed in the output of -h though.
Anyway, that didn't help. It still uses 640x480.
> Some people here have gotten it to work, and there's a page about how to
> do it somewhere on the web.
I've read several such pages, but most of them are for how to get things
working better AFTER X is running. As for getting X working, I've
followed the instructions to the letter. It still segfaults.
TIA,
Ron
Ron Farrer
> Worse, it's using _both_ drivers on the same card, because tdfxfb doesn't use
> resource management yet! You can fix that by saying `video=offb:off', or
> better, try this patch (untested, please let me know whether it works):
Adding "offb:off" to the video line causes the offb to become the
primary fb (see below), which causes the display to go blank,
resulting in having to log in remotely and reboot the system.
'cat /proc/fb'
0 OFfb /bandit/3Dfx,Voodoo3
1 3Dfx Voodoo3
'cat /proc/cmdline'
root=/dev/sdb4 video=tdfx:vmode=16:cmode=2,noaccel,offb:off
It doesn't matter where the "offb:off" is, it still has the same effect.
I haven't tried the patch.. if I can't find another way to fix this
problem then I will...
Ron
Ron Farrer
> Adding "offb:off" to the video line causes the offb to become the
> primary fb (see below), which causes the display to go blank,
> resulting in having to log in remotely and reboot the system.
>
> 'cat /proc/fb'
> 0 OFfb /bandit/3Dfx,Voodoo3
> 1 3Dfx Voodoo3
>
> 'cat /proc/cmdline'
> root=/dev/sdb4 video=tdfx:vmode=16:cmode=2,noaccel,offb:off
>
> It doesn't matter where the "offb:off" is, it still has the same effect.
>
> I haven't tried the patch.. if I can't find another way to fix this
> problem then I will...
Unchecking "force video setting" and checking "no video driver" got me a
working console again. It also gave me a working 1024x768 res on the
console and in X! So I'm sorta working now... Now if I could just get
the tdfx driver to work.
Some info:
'cat /proc/cmdline'
root=/dev/sdb4 video=tdfx:vmode=16:cmode=2,noaccel video=ofonly
'cat /proc/fb'
0 OFfb /bandit/3Dfx,Voodoo3
Why I it won't work with "no video driver" and "force video setting" I
have no idea..
Any ideas on how to get the tdfx driver working in X?
TIA,
Michel Dänzer
> Geert Uytterhoeven (ge...@linux-m68k.org) wrote:
>
> > Worse, it's using _both_ drivers on the same card, because tdfxfb doesn't use
> > resource management yet! You can fix that by saying `video=offb:off', or
> > better, try this patch (untested, please let me know whether it works):
>
> Adding "offb:off" to the video line causes the offb to become the
> primary fb (see below), which causes the display to go blank,
> resulting in having to log in remotely and reboot the system.
>
> 'cat /proc/fb'
> 0 OFfb /bandit/3Dfx,Voodoo3
> 1 3Dfx Voodoo3
>
> 'cat /proc/cmdline'
> root=/dev/sdb4 video=tdfx:vmode=16:cmode=2,noaccel,offb:off
Try video=tdfx:vmode=16:cmode=2,noaccel video=offb:off
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member / CS student, Free Software enthusiast
Geert Uytterhoeven
> > Adding "offb:off" to the video line causes the offb to become the
> > primary fb (see below), which causes the display to go blank,
> > resulting in having to log in remotely and reboot the system.
> >
> > 'cat /proc/fb'
> > 0 OFfb /bandit/3Dfx,Voodoo3
> > 1 3Dfx Voodoo3
> >
> > 'cat /proc/cmdline'
> > root=/dev/sdb4 video=tdfx:vmode=16:cmode=2,noaccel,offb:off
> >
> > It doesn't matter where the "offb:off" is, it still has the same effect.
> >
> > I haven't tried the patch.. if I can't find another way to fix this
> > problem then I will...
>
> Unchecking "force video setting" and checking "no video driver" got me a
> working console again. It also gave me a working 1024x768 res on the
> console and in X! So I'm sorta working now... Now if I could just get
> the tdfx driver to work.
>
> Some info:
> 'cat /proc/cmdline'
> root=/dev/sdb4 video=tdfx:vmode=16:cmode=2,noaccel video=ofonly
>
> 'cat /proc/fb'
> 0 OFfb /bandit/3Dfx,Voodoo3
If you say `video=ofonly', the `video=tdfx...' don't matter, since no other
frame buffer devices will be initialized.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Ron Farrer
> Try video=tdfx:vmode=16:cmode=2,noaccel video=offb:off
Ok, that got rid of offb and tdfx working, but I don't have a usable
console now. The text is 640x480 and is so mangled, I can _just_ barely
make it out to type out a few simple commands (like shutdown.) Issuing
the previously meantioned fbset causes the display to be set at the
proper resolution (but still mangled) - however X reverts to 640x480.
Another problem is that the fbset doesn't stick between reboots, where
with the offb it did... So basically one step forward, two steps back.
;-) Any suggestions on how to fix any or all of this would be greatly
appricated.
TIA,
Ron
Geert Uytterhoeven
> Michel D?nzer (dae...@debian.org) wrote:
>
> > Try video=tdfx:vmode=16:cmode=2,noaccel video=offb:off
>
> Ok, that got rid of offb and tdfx working, but I don't have a usable
> console now. The text is 640x480 and is so mangled, I can _just_ barely
> make it out to type out a few simple commands (like shutdown.) Issuing
> the previously meantioned fbset causes the display to be set at the
> proper resolution (but still mangled) - however X reverts to 640x480.
Add the mode you want to your XF86Config.
> Another problem is that the fbset doesn't stick between reboots, where
Pass the video mode you want as a parameter to the kernel, cfr.
linux/Documentation/fb/modedb.txt.
> with the offb it did... So basically one step forward, two steps back.
> ;-) Any suggestions on how to fix any or all of this would be greatly
> appricated.
I would be _very_ surprised if fbset would do anything at all using offb :-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Ron Farrer
> Pass the video mode you want as a parameter to the kernel, cfr.
> linux/Documentation/fb/modedb.txt.
Ok, that worked. I added "video=tdfx:1024x768@100" to the kernel
commands at boot time. So I'm back in a usable X. The console is still
hosed and unreadble, but at least I can blindly login and type 'startx'
:-)
Thanks to everyone who helped!
Ron