On Wed, 19 Dec 2001, Mariano Alvarez Fernandez wrote:
Hi, Andris
What is Your plans with linuxfb driver. It's very likely I'll need that to provide real time display of some measurement data (it would be best not to use X11 or svgalib in this case). It seems to be mostly working except of "amnesia" after switching virtual consoles
Well, I was very excited with the framebuffer driver, the video driver was very easy to write, the stock GRX framedrivers do all the hard work. Thanks for test it, it's the first "feed-back" I have about it.
Current problems I know, from www.gnu.de/software/GRX/problems.html:
- Try to change modes if the underlaying framebuffer driver allow it.
I used VESA framebuffer support, so it's set at boot time. I don't know whether I can change a resolution after that.
- Hide the text cursor.
Haven't looked into that. At least I don't see text cursor in allegro-4.0.0 demo program running with framebuffer driver.
- Working mouse (this is not trivial), GRX linux console mouse is handled by
svgalib functions, but obviously this not work with the framebuffer driver, a new mouse driver is necesary, but Linux don't have a real mouse driver, and the user program must handle all the possible mouse types.
Maybe one can use GPM directly, however I don't know whether it can be done for framebuffer mode (whether resulution is good enough)
Now I have two more things:
- It doesn't work in my recently installed Mandrake 8.1, the device driver has
changed from /dev/fb to /dev/fb0, but a simple change to the file to open doesn't work, I have to investigate it.
Same for Slackware-8.0: I added /dev/fb as symlink to /dev/fb0 before even trying (looked in source of driver and noticed that immediatelly)
- Optionally make a framebuffer only GRX library.
Maybe drivers could be loaded at run time. At least it could be possible for Linux.
Perhaps I could try to port virtual console switching code from Allegro-4.0.0 (allegro-4.0.0/src/linux/vtswitch.c), but not immediatelly now, now perhaps not earlier than in begin of next year. This is perhaps most annoying thing for me now.
This will be great! (but, can we apply the GRX license to the ported code?)
Perhaps I should put console switching code (if I'll write it) at first in my program and only after that to move it to try to put it into a driver. So I could tell program to redraw all when coming back.
Absence of 8bpp mode there is currently not critical for me.
I think this is not difficult, but with my graphics card I can't switch the fb color resolution except at boot I time, so I didn't work on it.
The same for me. Tried to do the same under Allegro, and my program have a different problems and works in 8bpp mode only. But these are results of rather few hours hacking, so it's much too early for real conclusions.
Another thing is similar "amnesia" for X11 driver (verified now with 2.4.4p2): if I obscure GRX window, the contents is lost. I would write related code
I have a workarround for this, from www.gnu.de/software/GRX/problems.html again:
- The driver can't respond to PAINT events, so it has problems with XFree86 v4
because the backing-store is not enabled by default. The best solution is to have a context to save the actual window (and the GrPixel problem can be solved too). The workaround is to add next lines to the /etc/X11/XF86Config-4 file, in the Device section:
Option "BackingStore" Option "SaveUnders"
Thanks. Only how it would influence performance of X server. Currently I installed XFree86-4.1.99.2, at lesat 4.1 and earlier 4.X versions have problems for me one box I'm using most often, development versions seems to work better (if they are not temporary broken)
, I would prefer to use gtk+ and gdk, build image in pixmap and blit it to screen as needed (tried to wrote some related custom widgets recently). Maybe it's worth to have such GTK+ driver (maybe it could be useable also for Windows, as there is Windows port of gtk+)
I don't know how to use GTK, are you speaking a GRX driver over GTK is possible?
I also don't know. How about having GTK widget we can draw with GRX or BGI functions with. Perhaps we should need something similar as I wrote for initialization of printing code to use GrContext but not to go throu´h full GrSetMode (as far as I remeber, it was long time ago) as one may want to draw on more than one widget.
Andris