linux-fbdev-devel — linux-fbdev mailing list for project developers

[Linux-fbdev-devel] using fbdev

[Matan Ziv-Av <ma...@sv...>]

Hi,

I'm sorry if it is not the approrpriate forum for this question, but I
did not find a better one:

How do I make the the text contents of the console redraw at the end of
a fb using program?

The following program works as expected (on PPC, aty128fb) - paints the
top of the screen blue. When it exits the screen remains blue. A console
switch to another VC and back clears the blue and draws the text that
was there. What I want is to have this happen automatically at program's
exit.

int main() {
	int fd, i;
	unsigned char *c;

	fd=open("/dev/fb0", O_RDWR);
	c=mmap(0,0x10000, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
	for(i=0; i<0x10000; i++) *(c+i)=1;
	sleep(2);
	close(fd);
	return 0;
}

-- 
Matan Ziv-Av.                         ma...@sv...

[Linux-fbdev-devel] Re: [PATCH] fbdev logo (fwd)

[Disconnect <lk...@si...>]

Ditto - I'd like at least an option of the "incorrect" logo.  I can
(sorta) see not having it as the default.  But perhaps under the
'experimental drivers' tag, have an option of "Politically incorrect
framebuffer logo".  (If there isn't a huge outcry against it, I may work
up a patch - been meaning to get into kernel stuff, and this seems
relatively harmless.)

On Fri, 25 May 2001, Dr. Kelsey Hudson did have cause to say:

> On Thu, 10 May 2001, Geert Uytterhoeven wrote:
> >   - Political fixes:
> >       o There were still some penguins left carrying a glass of beer or wine.
> >         This problem is about 2 years old!
> 
> I still don't understand why the penguin holding beer/wine was wrong...
> 
>  Kelsey Hudson                                           kh...@ct...
>  Software Engineer
>  Compendium Technologies, Inc                               (619) 725-0771
> ---------------------------------------------------------------------------
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to maj...@vg...
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
---
   _.-=<Disconnect>=-._
|     di...@si...    | And Remember...
\  sh...@he...  / He who controls Purple controls the Universe..
 PGP Key given on Request  Or at least the Purple parts!

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1 [www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C++++$ ULBS*++++$ P- L+++>+++++ 
E--- W+++ N+@ o+>$ K? w--->+++++ O- M V-- PS+() PE Y+@ PGP++() t
5--- X-- R tv+@ b++++>$ DI++++ D++(+++) G++ e* h(-)* r++ y++
------END GEEK CODE BLOCK------

[Linux-fbdev-devel] Re: [PATCH] fbdev logo (fwd)

[Dr. K. H. <ke...@bl...>]

On Thu, 10 May 2001, Geert Uytterhoeven wrote:
>   - Political fixes:
>       o There were still some penguins left carrying a glass of beer or wine.
>         This problem is about 2 years old!

I still don't understand why the penguin holding beer/wine was wrong...

 Kelsey Hudson                                           kh...@ct...
 Software Engineer
 Compendium Technologies, Inc                               (619) 725-0771
---------------------------------------------------------------------------

Re: [Linux-fbdev-devel] vfb + mmap

[Geert U. <ge...@li...>]

On Fri, 25 May 2001, Fabien Lebaillif Delamare wrote:
> I send the previous too fast ;-p sorry.
> 
> Does anyone has succeed to do a mmap() on the vfb.
> For me it doesn't work. I always get an adress out of bound.
> 
> Do I have to write a fb_mmap function to handle the vmalloc from the vfb
> or used the default one.

mmap() is known not to work on vfb. After all vfb is just a test driver.

You could make it mmap()able using the code from vga256fb, which was announced
here recently.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

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

[Linux-fbdev-devel] vfb + mmap

[Fabien L. D. <fa...@ce...>]

I send the previous too fast ;-p sorry.

Does anyone has succeed to do a mmap() on the vfb.
For me it doesn't work. I always get an adress out of bound.

Do I have to write a fb_mmap function to handle the vmalloc from the vfb
or used the default one.

Thanks for your help.

--
------------------------+
Fabien Lebaillif Delamare
R&D Engineer
------------------------+
Office : +65 844 1301
HP : +65 9848 1431
------------------------+
18 Tannery Lane 
#03-05 Lian Tong Building
Singapore 347780
------------------------+

[Linux-fbdev-devel] vfb + mmap

[Fabien L. D. <fa...@ce...>]

Does anyone has succeed to do a mmap on the vfb.
For me it doesn't work. I always get 

--
------------------------+
Fabien Lebaillif Delamare
R&D Engineer
------------------------+
Office : +65 844 1301
HP : +65 9848 1431
------------------------+
18 Tannery Lane 
#03-05 Lian Tong Building
Singapore 347780
------------------------+

[Linux-fbdev-devel] Re:[PATCH] hga depmod fix

[Bakonyi F. <fe...@dr...>]

> Date: 23 May 2001 22:44:38 +0200
> From: Juan Quintela <qui...@ma...>
> To: al...@re..., lin...@vg...
> Subject: [PATCH] hga depmod fix
> 
> 
> Hi
>         if you compile hga as a module, you get unresolved symbols,
>         you need the following patch for it.
>         The patch is trivial.  Apply, please.
> 
> Later, Juan.

The patch seems to be trivial but it isn't. This patch breaks the 
normal behavior of hgafb. I'll investigate this issue further.

Regards:
	Ferenc Bakonyi


> 
> --- linux/drivers/video/hgafb.c.~1~	Mon May 21 08:56:08 2001
> +++ linux/drivers/video/hgafb.c	Mon May 21 09:04:00 2001
> @@ -712,7 +712,7 @@
>  
>  	hga_gfx_mode();
>  	hga_clear_screen();
> -#ifdef MODULE
> +#ifndef MODULE
>  	if (!nologo) hga_show_logo();
>  #endif /* MODULE */

[Linux-fbdev-devel] RE: [linux-fbdev] frame buffer / fixed freq mon question

[Larry M. <lm...@MR...>]

ok, I am basically running right now in 1024x768x16bit... How can I figure
out what the equivalent settings are when transcribing them from X speak to
FB speak?  Any help would be appreciated... Thanks


-Larry Mulder
lr...@ez...

-----Original Message-----
From: Jim Hague [mailto:jim...@ac...]
Sent: Friday, May 18, 2001 4:31 AM
To: Larry Mulder
Cc: Linux Fbdev development list
Subject: RE: [linux-fbdev] frame buffer / fixed freq mon question


On 17-May-2001 Larry Mulder wrote:
> I have X windows (XFree86-3.3.6) setup with a mach64 based video card to
> drive a fixed frequency Sun monitor OEM's by SONY (GDM-1962B),   However,
> you might well know that when connected to a PC, these fixed frequency
> monitors don't understand standard VGA text mode... I am just curious if
it
> would be possible to modify either the atyfb or the vesafb driver in the
> linux kernel to drive this monitor using the fixed freq signals it needs?

I have (nearly) exactly the setup you describe - fixed frequency Sun monitor
driven from a PC. I am using a Permedia card not Mach64, but just because a
Permedia card is what I had. And I am using the frame buffer driver to get a
very loverly console.

I suspect (but don't know for definite) that the vesafb driver won't work,
as
I think it uses only VESA sanctioned modes available from the card, and
Sun's
resolution isn't one of those.

But I would hope that the atyfb driver would allow you to set your own
output
mode, either via boot parameters (if you can with atyfb) or by using fbset
on
boot. Here's my fbset settings (given in X style first for comparison with
your
X settings):

mail:/home/jim# fbset -s -x

Mode "1152x900"
    # D: 92.945 MHz, H: 61.799 kHz, V: 65.954 Hz
    DotClock 92.946
    HTimings 1152 1184 1312 1504
    VTimings 900 902 906 937
    Flags    "-HSync" "-VSync"
EndMode

mail:/home/jim# fbset -s

mode "1152x900-66"
    # D: 92.945 MHz, H: 61.799 kHz, V: 65.954 Hz
    geometry 1152 900 1152 900 16
    timings 10759 192 32 31 2 128 4
    rgba 5/11,6/5,5/0,0/0
endmode

Set your own mode, and you should get a properly working console.

In the case of the Permedia driver, you can only set a precanned mode from
boot
parameters, so I added a 'Sun fixed frequency' mode and rebuilt. (I did once
submit a patch to the driver author to add specifying mode by its
components,
but it never made it).

-- 
Jim Hague - jim...@in... (Work), ji...@be... (Play)
Never trust a computer you can't lift.

[Linux-fbdev-devel] [PATCH] hga depmod fix (fwd)

[James S. <jsi...@tr...>]

---------- Forwarded message ----------
Date: 23 May 2001 22:44:38 +0200
From: Juan Quintela <qui...@ma...>
To: al...@re..., lin...@vg...
Subject: [PATCH] hga depmod fix


Hi
        if you compile hga as a module, you get unresolved symbols,
        you need the following patch for it.
        The patch is trivial.  Apply, please.

Later, Juan.

--- linux/drivers/video/hgafb.c.~1~	Mon May 21 08:56:08 2001
+++ linux/drivers/video/hgafb.c	Mon May 21 09:04:00 2001
@@ -712,7 +712,7 @@
 
 	hga_gfx_mode();
 	hga_clear_screen();
-#ifdef MODULE
+#ifndef MODULE
 	if (!nologo) hga_show_logo();
 #endif /* MODULE */
 


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to maj...@vg...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linux-fbdev-devel] Riva framebuffer boot options

[James S. <jsi...@tr...>]

> I've got a Geforce256 Graphics card and run the Riva framebuffer.
> Now I would like to change the video mode right on startup instead of
> changing it later with fbset.
> I tried the following lilo config (bit in vein :) :
> 
> ---
> image=/boot/vmlinuz-2.4.4
> append="video=rivafb:xres:1024,yres:768,pixclock:9091,left:280,right:0,upper:16,lower:0,hslen:88,vslen:0,depth:32"


Replace rivafb with riva. It will work then.

[Linux-fbdev-devel] Riva framebuffer boot options

[Martin B. <mar...@gm...>]

Hi,

I've got a Geforce256 Graphics card and run the Riva framebuffer.
Now I would like to change the video mode right on startup instead of
changing it later with fbset.
I tried the following lilo config (bit in vein :) :

---
image=3D/boot/vmlinuz-2.4.4
append=3D"video=3Drivafb:xres:1024,yres:768,pixclock:9091,left:280,right:0,=
upper:16,lower:0,hslen:88,vslen:0,depth:32"
---

it has no effect, my linux still boots in 640x480x8@60Hz :/
changing the mode later with fbset is no problem.

Please cc me because i am not subscribed to this list.

Martin
--=20
[this line is intentionally left blank]

Re: [Linux-fbdev-devel] Frame buffer drivers compiled as mo

[Petr V. <VAN...@vc...>]

On 22 May 01 at 22:03, Otto Wyss wrote:
> I should have used fbset --help beside man fbset, so I don't had to ask
> about "-a". I've the same version and "fbset 800x600-72 -a" works. But
> the post-install in modules.conf
> 
> options aty128fb 800x600@72
> post-install aty128fb fbset 800x600-72 -a
> 
> doesn't. Modprobe is version 2.4.6 and my system is an uptodate Debian
> woody with kernel 2.4.3.

Try post-install aty128fb -- fbset 800x600-72 -a
Otherwise you have to create shell script...
                                                        Petr
                                                        

Re: [Linux-fbdev-devel] Frame buffer drivers compiled as mo

[Otto W. <ott...@bl...>]

> Then you have either broken system or broken fbset:
> 
> bash:/tmp# fbset --help
> Linux Frame Buffer Device Configuration Version 2.1 (23/06/1999)
> ...
>     -a, --all               : change all virtual consoles on this device
> ...
>
I should have used fbset --help beside man fbset, so I don't had to ask
about "-a". I've the same version and "fbset 800x600-72 -a" works. But
the post-install in modules.conf

options aty128fb 800x600@72
post-install aty128fb fbset 800x600-72 -a

doesn't. Modprobe is version 2.4.6 and my system is an uptodate Debian
woody with kernel 2.4.3.

O. Wyss

Re: [Linux-fbdev-devel] Frame buffer drivers compiled as mo

[Petr V. <VAN...@vc...>]

On 22 May 01 at 21:23, Otto Wyss wrote:
> > > refresh rate). What's the meaning of the "-a" at the end? Neither man
> > > modules.conf nor man fbset shows its meaning.
> > 
> > Set resolution on all consoles ;-)
> > 
> Not on my system (currently aty128fb), I tried with and without "-a",
> same effect.

Then you have either broken system or broken fbset:

bash:/tmp# fbset --help
Linux Frame Buffer Device Configuration Version 2.1 (23/06/1999)
...
    -a, --all               : change all virtual consoles on this device
...

and of course it works here with matroxfb, atyfb and vga16fb. As it
is done on fbcon layer, fbdev type should not matter.
                                                    Petr Vandrovec
                                                    van...@vc...
                                                    

Re: [Linux-fbdev-devel] Frame buffer drivers compiled as mo

[Otto W. <ott...@bl...>]

> > refresh rate). What's the meaning of the "-a" at the end? Neither man
> > modules.conf nor man fbset shows its meaning.
> 
> Set resolution on all consoles ;-)
> 
Not on my system (currently aty128fb), I tried with and without "-a",
same effect.

O. Wyss

Re: [Linux-fbdev-devel] Frame buffer drivers compiled as mo

[Petr V. <VAN...@vc...>]

On 22 May 01 at 21:09, Otto Wyss wrote:
> > post-install atyfb fbset 1280x1024@100 -a
> > 
> > into modules.conf.
> > 
> I just discovered that at the first console (the one this command get
> executed) uses a wrong font, any "=E4=F6=FC" gets printed like "*=F7y".

You have to reload your translation tables after each mode switch
afaik.
                                                    Petr Vandrovec
                                                    van...@vc...
                                                    

Re: [Linux-fbdev-devel] Frame buffer drivers compiled as mo

[Petr V. <VAN...@vc...>]

On 22 May 01 at 20:46, Otto Wyss wrote:
> > someone have to change types for curblink, noaccel and default_vram to
> > int and then add
> > 
> > MODULE_PARM(curblink, "i"); MODULE_PARM(noaccel, "i") ... and so on.

> I'm not a kernel/driver developer and have not enough time to get used
> to it.

Then build driver into kernel.
 
> I tried it and the post-install works on the first console but not on
> others. Besides fbset needs HHHHxVVVV-RR (note the "-" before the

Sorry.

> refresh rate). What's the meaning of the "-a" at the end? Neither man
> modules.conf nor man fbset shows its meaning.

Set resolution on all consoles ;-)
 
> [OFF TOPIC ON]
> With only 3 different graphics card I could easily compile all into the
> kernel. But I thought it might be a good time to try the modularized
> versions. It's just a matter of time until all drivers where able to run
> as modules and only the absolute essentials will be kept in the kernel.
> With the introduction of the hotplug feature drivers slowly will be uses
> as modules and than made hotplugable even if the never get
> plugged/unplugged. So it might be a good idea to care about it as well.
> [OFF TOPIC OFF]

It looks like that it is trivially fixable (except modedb):
remove all #if[n]def MODULE, create

static const char* opt = NULL;
MODULE_PARM(opt, "s");

and add atyfb_setup(opt) at the beginning of its init_module()
function, just before atyfb_init() - then atyfb will understand
opt="font:VGA8x16,noblink,noaccel,vram:123,pll:456,mclk:789" (do not
forget " around the string, otherwise insmod splits string at commas).
Just something to think about...
                                            Petr Vandrovec
                                            van...@vc...
                                            

Re: [Linux-fbdev-devel] Frame buffer drivers compiled as mo

[Otto W. <ott...@bl...>]

> post-install atyfb fbset 1280x1024@100 -a
>=20
> into modules.conf.
>=20
I just discovered that at the first console (the one this command get
executed) uses a wrong font, any "=E4=F6=FC" gets printed like "*=F7=FF".

O. Wyss

Re: [Linux-fbdev-devel] Frame buffer drivers compiled as mo

[Otto W. <ott...@bl...>]

> someone have to change types for curblink, noaccel and default_vram to
> int and then add
> 
> MODULE_PARM(curblink, "i"); MODULE_PARM(noaccel, "i") ... and so on.
> 
I'm not a kernel/driver developer and have not enough time to get used
to it.

> If you compiled driver as module, then mode database is not available
> (it is __init thing), so there is no way how to get non-default resolution.
> But you can add
> 
> post-install atyfb fbset 1280x1024@100 -a
> 
> into modules.conf.
> 
I tried it and the post-install works on the first console but not on
others. Besides fbset needs HHHHxVVVV-RR (note the "-" before the
refresh rate). What's the meaning of the "-a" at the end? Neither man
modules.conf nor man fbset shows its meaning.

> > Why do they have to wait after / is mounted r/w? If a driver doesn't
> > write to the drive there is no need. What's the difference between a
> > linked and a modularized driver besides just store in different places.
> 
> /etc/modules is usually parsed after / remounted r/w. If you trigger
> module load by accessing /dev/fb*, then it is different, of course.
> Difference between built in and modularized driver is that builtin
> driver can get options from kernel commandline and is initialized before
> system comes up. Modularized drivers can be loaded only after / filesystem
> was mounted (at least read-only), so couple of things have to happen
> before. You should built-in all drivers for hardware your machine has into
> kernel unless you are just developing that drivers. It saves you from
> couple of troubles...
>
[OFF TOPIC ON]
With only 3 different graphics card I could easily compile all into the
kernel. But I thought it might be a good time to try the modularized
versions. It's just a matter of time until all drivers where able to run
as modules and only the absolute essentials will be kept in the kernel.
With the introduction of the hotplug feature drivers slowly will be uses
as modules and than made hotplugable even if the never get
plugged/unplugged. So it might be a good idea to care about it as well.
[OFF TOPIC OFF]

O. Wyss

Re: [Linux-fbdev-devel] Frame buffer drivers compiled as mo

[Petr V. <VAN...@vc...>]

On 21 May 01 at 23:09, Otto Wyss wrote:

> > Drivers do not read options from modules.conf, modprobe does. When built
> > into kernel, fbdev drivers support unified 'video=<fbdevname>:options'
> > kernel cmdline argument, but when they are built as modules, it differs
> > from driver to driver (f.e. matroxfb supports all these options,
> > instead of video=matrox:a:b you write 'insmod matroxfb_base a=b')
> > 
> And what if drivers gets loaded if the kernel module loader calls
> modprobe? 

modprobe reads modules.conf and creates correct insmod line.

> As far as I understand, in the atyfb, aty128fb the option processing are
> disabled through a compile time option (#ifndef MODULE).

someone have to change types for curblink, noaccel and default_vram to
int and then add

MODULE_PARM(curblink, "i"); MODULE_PARM(noaccel, "i") ... and so on.

If you compiled driver as module, then mode database is not available
(it is __init thing), so there is no way how to get non-default resolution.
But you can add

post-install atyfb fbset 1280x1024@100 -a

into modules.conf.

> > I do not understand. Of course that if you compiled these drivers as modules
> > then they are started after / is mounted r/w. What else do you expect
> > from modules? And if you are talking about fbdev drivers in kernel, then
> > 
> Why do they have to wait after / is mounted r/w? If a driver doesn't
> write to the drive there is no need. What's the difference between a
> linked and a modularized driver besides just store in different places.

/etc/modules is usually parsed after / remounted r/w. If you trigger
module load by accessing /dev/fb*, then it is different, of course.
Difference between built in and modularized driver is that builtin
driver can get options from kernel commandline and is initialized before
system comes up. Modularized drivers can be loaded only after / filesystem
was mounted (at least read-only), so couple of things have to happen
before. You should built-in all drivers for hardware your machine has into
kernel unless you are just developing that drivers. It saves you from
couple of troubles...
                                            Best regards,
                                                Petr Vandrovec
                                                van...@vc...
                                                

Re: [Linux-fbdev-devel] Frame buffer drivers compiled as mo

[Otto W. <ott...@bl...>]

> > What's the reason for this? It might be that the lilo kernel parameters
> > won't get routed to the modularized drivers but why weren't options read
> > from modules.conf?
> 
> Drivers do not read options from modules.conf, modprobe does. When built
> into kernel, fbdev drivers support unified 'video=<fbdevname>:options'
> kernel cmdline argument, but when they are built as modules, it differs
> from driver to driver (f.e. matroxfb supports all these options,
> instead of video=matrox:a:b you write 'insmod matroxfb_base a=b')
> 
And what if drivers gets loaded if the kernel module loader calls
modprobe? 

As far as I understand, in the atyfb, aty128fb the option processing are
disabled through a compile time option (#ifndef MODULE).

> > It seems the the frame buffer drivers gets started rather late in the
> > startup process. What defines this order, could frame buffer drivers be
> > moved more to the beginning?
> 
> I do not understand. Of course that if you compiled these drivers as modules
> then they are started after / is mounted r/w. What else do you expect
> from modules? And if you are talking about fbdev drivers in kernel, then
> 
Why do they have to wait after / is mounted r/w? If a driver doesn't
write to the drive there is no need. What's the difference between a
linked and a modularized driver besides just store in different places.

O. Wyss

Re: [Linux-fbdev-devel] Frame buffer drivers compiled as mo

[Petr V. <VAN...@vc...>]

On 21 May 01 at 22:21, Otto Wyss wrote:

> What's the reason for this? It might be that the lilo kernel parameters
> won't get routed to the modularized drivers but why weren't options read
> from modules.conf?

Drivers do not read options from modules.conf, modprobe does. When built
into kernel, fbdev drivers support unified 'video=<fbdevname>:options' 
kernel cmdline argument, but when they are built as modules, it differs
from driver to driver (f.e. matroxfb supports all these options,
instead of video=matrox:a:b you write 'insmod matroxfb_base a=b')

> It seems the the frame buffer drivers gets started rather late in the
> startup process. What defines this order, could frame buffer drivers be
> moved more to the beginning?

I do not understand. Of course that if you compiled these drivers as modules
then they are started after / is mounted r/w. What else do you expect
from modules? And if you are talking about fbdev drivers in kernel, then
I think that they are started too early. Currently my kernel initializes
all device drivers after all other subsystems were initialized, just before
mounting root read-only, and I'm very happy from this. Only problem is that
I had to do some hotplugging fixes in some code.
                                    Best regards,
                                            Petr Vandrovec
                                            van...@vc...
                                            

[Linux-fbdev-devel] Frame buffer drivers compiled as modules

[Otto W. <ott...@bl...>]

Since I got my third different graphics card (two different computers) I
tried to compile the frame buffer drivers as modules. Now I discovered
that neither atyfb nor aty128fb supports startup options in this case. I
guess also the other drivers won't.

What's the reason for this? It might be that the lilo kernel parameters
won't get routed to the modularized drivers but why weren't options read
from modules.conf?

It seems the the frame buffer drivers gets started rather late in the
startup process. What defines this order, could frame buffer drivers be
moved more to the beginning?

O. Wyss

PS. Please CC, I'm not on the list.
PPS. Linux 2.4.3 on i386, Debian woody.

Re: [Linux-fbdev-devel] LCD FB + VC

[James S. <jsi...@tr...>]

> I am currently developping a frame buffer drivers for a Samsung LCD. The
> LCD is connected to the system trough the USB chain, but fb access works
> fine (I can draw ;-p ). The only annoying thing is that when I register my
> fb driver it takes over all my VC.
> 
> How can I create a new VC (tty?) using my fb driver only?
> How can I keep my already existing VC using vgacon ? 

   With the standard kenel you can't :-( When you load the new fbdev
driver it takes over. What you can do is get a second card that is
supported by fbcon. Then migrate some of the VCs to that card. 
   
P.S

  For 2.5.X this will be fixed :-) 

[Linux-fbdev-devel] linuxtv directfb

[Scott A M. <sam...@co...>]

Does anyone know what this is about?

http://www.linuxtv.org/
http://directfb.org/


An interesting picture:

http://directfb.org/screenshots/dfbsee.png


What's their beef with X?


-- 
Scott A. McConnell