Results 1 to 10 of 13
Enjoy an ad free experience by logging in. Not a member yet? Register.
Running links in the framebuffer - it runs but I can't see it
I can create a framebuffer device /dev/fb0 by loading a driver module (I've been using vga16, which is a general-purpose one that is supposed to work on most graphics chips). Then, if I chmod it so that I can read and write to it as a normal user, I can launch links in graphical mode without getting any errors. But the weird thing is that it doesn't show the page I requested; it shows the console instead.
I can see that it's a framebuffer console, not the normal one, because the colours are quite different and much brighter. If I interrupt or kill links, the normal virtual console comes back.
At first I thought that links might have opened a new virtual console to show its own pages but I checked them all and none of them was showing links. Just what is going on here?
- Join Date
- Apr 2009
- I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
Sorry I can't help Hazel. I haven't futzed with raw frame buffers since back in the old vga days (1980's - early 90's). Anyway, I think that if you use a framebuffer, you also need to low-level program the graphics chip to go into raw vga mode. I think you are 1/2 the way there.Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!
- Join Date
- Nov 2009
I don't think it's possible to switch from text-mode to a graphics console by loading a module.
Try this: zcat /proc/config.gz |grep CONFIG_FB_VESA
If the reply is CONFIG_FB_VESA=y, you can boot Linux with a framebuffer console by changing the vga parameter.
# VESA framebuffer console @ 1024x768x64k
# VESA framebuffer console @ 1024x768x32k
# VESA framebuffer console @ 1024x768x256
# VESA framebuffer console @ 800x600x64k
# VESA framebuffer console @ 800x600x32k
# VESA framebuffer console @ 800x600x256
# VESA framebuffer console @ 640x480x64k
# VESA framebuffer console @ 640x480x32k
# VESA framebuffer console @ 640x480x256
Well, actually I don't want a framebuffer console. It's Links that I want to run in the framebuffer. But after a few experiments I think I have diagnosed the problem (not that that gets me any closer to a solution!)
I think that Links is reading and displaying the framebuffer correctly but, for some reason, can't write to it. So what I see is what was already in video memory: a copy of what I had previously written on the console.
The keyboard and mouse seem dead only because Links can't respond to them by modifying the display. I can still do things like using alt-Fn to switch consoles or ctrl-C to crash Links.
I have a gut feeling that this has to do with something called directfb because, when I installed Links on Debian, directfb came over as a dependency, and I actually can run Links in the framebuffer on that system.
I'm going to do some research on this. I hate mysteries.
- Join Date
- Nov 2009
If there is a framebuffer device, links is probably writing to it, but links is not allowed to display it - that's what the kernel module is supposed to do. If you don't use a framebuffer console, your graphics card is using hardware text mode and is not able to display graphics.
As I said, I think you have to boot with a framebuffer console if you want to use links' framebuffer driver.
However, links also has an SVGAlib driver and it is possible to switch from text mode to graphics mode with SVGAlib, but you need to run links as root to do this.
If I just type "links2 -g" or "xlinks2", I get it running with directfb. There's a fixed (rather low) resolution and text is practically illegible. But otherwise it works.
If I set a mode to get good resolution, that triggers svgalib. Then of course I have to be root or I get permissions problems. It works, up to a point, and it's legible but it freezes easily. According to the links manual, that's svgalib's fault, not theirs!
Either way, I think X is better!
Well, I finally cracked it! To use the framebuffer without directfb, you don't need special boot parameters but you do need to have two kernel modules loaded: the framebuffer driver for your video chip/card (in my case i810fb) and the framebuffer console driver, fbcon. And gpm for your mouse (though I already knew that).
So there are actually three ways links can run graphically without X:
1) Directly on the framebuffer as above.
2) Indirectly on the framebuffer via libdirectfb (which is how Debian does it)
3) via SVGAlib (also available in Debian).
The caveat with 1) and 2) is that the display is lousy and you can hardly read it. 3) gives a nice display but crashes easily because of some kind of incompatibility between SVGAlib and links. And when it does crash, your console is dead so you have to switch off your computer. And of course you need to run it SUID, or actually as root.
It's all very interesting but I still think I prefer X!
... I was playing with links -g in Arch I just installed links-g-directfb from the AUR and it just worked. In Gentoo I set fbcon and directfb flags for links and emerge'd link - but used modeset=1 option to get links -g to work (I'm using nouveau for the nvidia graphics card) ...
I was thinking I'd use links without the X overhead on a hardware limited laptop ...
Well, that's what I was thinking too. And on Debian, links -g does "just work". But if I can barely read the text, what is the point of it? I'd be interested to know what kind of resolution you are getting.
Additional material: I found this HOWTO on building gtk for the framebuffer. Once you have done this, I suppose you can build and run any gtk program to run this way.
Last edited by hazel; 08-06-2011 at 05:02 PM.
- Join Date
- Nov 2009
For me, links looks exactly the same on the framebuffer and in X, but I use the VESA framebuffer driver, which has to be started at boot time. I don't understand why you are so deeply opposed to this; if you are going to use a framebuffer driver, why not boot with it?