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

[Linux-fbdev-devel] Re: pm3fb and new motherboard ...

[Sven <lu...@dp...>]

On Tue, Jan 08, 2002 at 03:00:12PM +0100, Romain Dolbeau wrote:
> Sven wrote:
> 
> > Well, i did try fbset 640x480, but since i could not see any output, i don't
> > believe it worked, but maybe i mistyped something.
> 
> Try using boot-time option, if possible (the theory is
> that is should'nt matter, but who knows ? :-)

Ok will try, that and vgafb, Expect my report tommorow.

Friendly,

Sven Luther

[Linux-fbdev-devel] Re: pm3fb and new motherboard ...

[Romain D. <do...@ir...>]

Sven wrote:

> Well, i did try fbset 640x480, but since i could not see any output, i don't
> believe it worked, but maybe i mistyped something.

Try using boot-time option, if possible (the theory is
that is should'nt matter, but who knows ? :-)

> mmm, nice, i suppose it is one of those new powerbooks, isn't it ?

Yes. 667 TiBook. Nice machine. Of course now I'm broke :-/

> I almost bought on of those also, do they work fine for you ?

Very nice, but there's not much point in running Linux,
as MacOS X does everything fine (except that Aqua is
really slow... nice, but sloooow :-( )

I managed to have both a FB console display and X,
thanks to the hard work of other, so it's very
usable even now with linux.

-- 
DOLBEAU Romain               |                                          
ENS Cachan / Ker Lann        | l'histoire est entierement vraie, puisque
Thesard IRISA / CAPS         |     je l'ai imaginee d'un bout a l'autre 
dol...@cl...    |           -- Boris Vian

[Linux-fbdev-devel] Re: pm3fb and new motherboard ...

[Sven <lu...@dp...>]

On Tue, Jan 08, 2002 at 02:50:34PM +0100, Romain Dolbeau wrote:
> Sven wrote:
> 
> > Romain, ... Do you know if pm3fb is still supposed to work ok with 2.4.17 ? I
> > guess yes, because it worked before. I did not yet try vgafb, will do this
> > evening.
> 
> I don't know of any problem... Is it the same pm3fb, or did you upgrade
> in the meantime ? Maybe I broke something in 1.4.10 or 1.4.9...

Well, it worked fine with 2.4.17 and the older board, so i guess it has
nothing to do with it. I guess it is something related with the agp bus, i see
no other reason.

> Does option 'printtimings' works, and if yes, what is reported
> in the kernel log ? Main change in 1.4.10 is the SDRAM bug,
> I didn't try it, only added the XFree86 workaround...

Will try.

> Did you try changing the resolution and/or color depth ?

Well, i did try fbset 640x480, but since i could not see any output, i don't
believe it worked, but maybe i mistyped something.

> > Romain, do you plan to some day have pm3fb included into the kernel, or will
> > this only happen with ruby and the 2.5/2.6 tree ?
> 
> I might try getting it integrated in 2.4, as I'm short on time
> and the Ruby version is on ice (that, and the fact I bought
> a laptop with a Radeon in it :-)

mmm, nice, i suppose it is one of those new powerbooks, isn't it ?

I almost bought on of those also, do they work fine for you ?

Friendly,

Sven Luther

[Linux-fbdev-devel] Re: pm3fb and new motherboard ...

[Romain D. <do...@ir...>]

Sven wrote:

> Romain, ... Do you know if pm3fb is still supposed to work ok with 2.4.17 ? I
> guess yes, because it worked before. I did not yet try vgafb, will do this
> evening.

I don't know of any problem... Is it the same pm3fb, or did you upgrade
in the meantime ? Maybe I broke something in 1.4.10 or 1.4.9...

Does option 'printtimings' works, and if yes, what is reported
in the kernel log ? Main change in 1.4.10 is the SDRAM bug,
I didn't try it, only added the XFree86 workaround...

Did you try changing the resolution and/or color depth ?

> Romain, do you plan to some day have pm3fb included into the kernel, or will
> this only happen with ruby and the 2.5/2.6 tree ?

I might try getting it integrated in 2.4, as I'm short on time
and the Ruby version is on ice (that, and the fact I bought
a laptop with a Radeon in it :-)

-- 
DOLBEAU Romain               |    You won't break me                    
ENS Cachan / Ker Lann        |    You won't make me                     
Thesard IRISA / CAPS         |    You won't take me                     
dol...@cl...    | -- Judas Priest, 'Blood Red Skies'

[Linux-fbdev-devel] pm3fb and new motherboard ...

[Sven <lu...@dp...>]

Hello, ...

Saturday, i upgraded my box from a K6-2 on an ali chipset wich i gave my
little brother to a duron 1000 on a sis 735 chipset, rebooted the same 2.4.17
kernel i have been using without problem with pm3fb, and ... no more pm3fb,
only a black screen with some very dark grey garbage. X launched ok though, so
i rebuilt the kernel switching the ali agpgart and ide modules with the sis
ones, and maybe some other such stuff, but no changes.

Romain, ... Do you know if pm3fb is still supposed to work ok with 2.4.17 ? I
guess yes, because it worked before. I did not yet try vgafb, will do this
evening.

Does someone have any idea on why pm3fb could be affected by this mainboard
change ? Maybe somethign related to the AGP version or something such (the old
board was AGPx2 only, while the new one supports AGP 2.0 and x4).

All messages from the kernel were ok, as if pm3fb loaded nicely.

Romain, do you plan to some day have pm3fb included into the kernel, or will
this only happen with ruby and the 2.5/2.6 tree ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] __init questions

[Jani M. <ja...@as...>]

Oh I see, I had the module_init function the same as the one called in
fbmem.Now it's surrounded by ifdef MODULE and it's OK.
Thanks

>
> BTW, which fbdev driver are you using?
tridentfb on a compaq presario with cyberbladei1 ...
this was one of the last noticable annoyances

> Bonus: your card shows up in /proc/io{mem,ports}.
I have that :)

Re: [Linux-fbdev-devel] __init questions

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

On Mon, 7 Jan 2002, Jani Monoses wrote:
> as I see the
> int __init init_XXXXfb functions are called twice at bootup,
> once by the fbmem_init() function and once when all __init
> functions are called.Is that OK?Well the only annoyance is that it prints
> twice that the board is found but still....
> Maybe there should (is there any?) be a section where functions which must
> be discarded after bootup are placed,but not necessarily and automatically
> called like __init ones.
> Then a lot of fns could be marked like that without fearing they might be
> called unexpectedly due to  link order problems...But unless I miss
> something (as usually) this is a lkml topic.

The init_XXXXfb() functions should be called only once.

Functions marked __init are not called `when all __init functions are called'.
That's true for functions marked __initcall (or __module_init) only.

BTW, which fbdev driver are you using?

>  And what is the difference(in behaviour) of drivers which use
> and those which don't use resource management;they are separated by a
> comment in the driver list in fbmem.Does it only matter when we have more
> than one in the same box?

It matters for generic drivers like vga16fb, vesafb and offb, which can work
with many cards. So the generic drivers are initialized after the chipset
specific drivers, so they don't start working with a card that already has a
driver running.

The chipset specific drivers without resource management are a real problem
though: if you compile in vga16fb and such a driver, both drivers will access
the card, and your system may crash.

Solution: add resource management to all drivers.

Resource management also protects against loading the same driver (as a
loadable driver module) multiple times.

Bonus: your card shows up in /proc/io{mem,ports}.

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] __init questions

[Jani M. <ja...@as...>]

Hi
as I see the
int __init init_XXXXfb functions are called twice at bootup,
once by the fbmem_init() function and once when all __init
functions are called.Is that OK?Well the only annoyance is that it prints
twice that the board is found but still....
Maybe there should (is there any?) be a section where functions which must
be discarded after bootup are placed,but not necessarily and automatically
called like __init ones.
Then a lot of fns could be marked like that without fearing they might be
called unexpectedly due to  link order problems...But unless I miss
something (as usually) this is a lkml topic.

 And what is the difference(in behaviour) of drivers which use
and those which don't use resource management;they are separated by a
comment in the driver list in fbmem.Does it only matter when we have more
than one in the same box?

Thank
Jani.

[Linux-fbdev-devel] Want framebuffer drive for cyrix mediaGX

[changkun74 <cha...@si...>]

I am working with a SBC (mediaGX+CS5530). I am looking for the
framebuffer driver that can running successfully. I am using kernel
2.4.16.

I had tried some ways:
1) using the native driver on the website of National-Semi, but I
found in its code:

/* If we are in hires mode, get that mode */
if (screen_info.orig_video_isVGA != VIDEO_TYPE_VLFB)
return -EBUSY;

When booting on my SBC, the value of orig_video_isVGA is 1, not
VIDEO_TYPE_VLFB(0x23), so the initialization can not go on.

2) I found that someone had said that the vesafb could work using
"vga=0x303, video=vesafb", but I also found that in the code for
vesafb, the orig_video_isVGA also would be checked.

3) I found that Alan Cox had written a drive for mediagx in 1998, but
after I looked through the code, I guess it was written for kernel 2.2
or even older, because the pci structure used there is not for kernel
2.4

There are so many kind of SBC using Nation-Semi GX processors on the
market, but I have not found a working framebuffer driver for almost
one week, can someone here help me?

changkun

 




______________________________________

===================================================================
ÐÂÀËÃâ·Ñµç×ÓÓÊÏä (http://mail.sina.com.cn)
ÐÂÀË·ÖÀàÐÅÏ¢:·ÖÀàÐÅÏ¢ Ë­´¦µß·å? ÄúͶƱ ÎÒËͽ±! (http://classad.sina.com.cn/)
ÐÂÀËÉÁ˸¶ÌÐÅÉÁÁÁµÇ³¡ ´«ÇéÎÞÏÞ (http://sms.sina.com.cn/cgi-bin/sms/smspic.cgi?spec=11&type=0)

[Linux-fbdev-devel] PATCH 2.5.2.9: fbdev kdev_t build fixes

[Jeff G. <jg...@ma...>]

This patch fixes the build for the rest of fbdev in 2.5.2-pre9...
-- 
Jeff Garzik      | Alternate titles for LOTR:
Building 1024    | Fast Times at Uruk-Hai
MandrakeSoft     | The Took, the Elf, His Daughter and Her Lover
                 | Samwise Gamgee: International Hobbit of Mystery

[Linux-fbdev-devel] Patch?: linux-2.5.2-pre8/drivers/video kdev_t compilation fixes

[Adam J. R. <ad...@yg...>]

	Most (all?) of the frame buffer drivers in
linux-2.5.2-pre8/drivers/video have a kdev_t compilation error,
because they try to set their fb_info->node field to -1 (it is
a kdev_t).  Shortly thereafter, regsiter_framebuffer sets it to
a more useful value.  So far, I have been unable to spot any
code that relies on fb_info->node being initialized to a
particular value prior to the call to register_framebuffer,
although I have not looked very hard.  What I did see was
some "???" comments beside some of the initializations to -1.
I suspsect that this is just useless initialization.

	Anyhow, deleting all of those initializations to -1
allows all of the framebuffer drivers to compile, which is
that this patch does.  I have also included a tiny patch to
a commented out line in include/linux/fb.h, updating it to
use minor() instead of MINOR(), in case it is every uncommented.

	I am still a long way from getting pre8 to run, so I
have not tested change.  Can anyone point out a place in
drivers/framebuffer that relies on fb_info->node being set to -1,
or minor(fb_info->node) being -1?

	By the way, don't worry if a few of the line offsets in this
patch are off.  That's because of some other changes I have in my
drivers/framebuffer (which I have previous posted, specifically
PCI ID tables, fb font modularization with demand loading, and the
fb core as a loadable module).


-- 
Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
ad...@yg...     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

[Linux-fbdev-devel] Re: [patch] Re: Framebuffer...Why oh Why???

[Rob L. <la...@tr...>]

On Tuesday 01 January 2002 05:42 am, Alan Cox wrote:
> > > X11 isn't always an improvement.  I've got an X hang on my laptop
> > > (about once a week) that freezes the keyboard and ignores mouse clicks.
> > >  Numlock doesn't change the keyboard LEDs, CTRL-ALT-BACKSPACE won't do
> > > a thing, and although I can ssh in and run top (and see the CPU-eating
> > > loop), kill won't take X down and kill-9 leaves the video display up so
> > > the console that thinks it's in text mode, but isn't, is still useless.
> > >  (And that's assuming I'm plugged into the network and have another box
> > > around to ssh in from...)
>
> Neomagic Magicgraph 128XD ? If so check man neomagic first 8)

Neomagic 256AV.  I'll feed it the two disables the man page recommends and 
see if that makes the problem go away.  (I can trigger it almost at will by 
playing around with kmail with the threaded view of 2500+ linux-kernel 
messages and paging up and down really fast.  Or by switching the display 
when )

Kmail seems to be the only thing that actually triggers it.  I can't think of 
a lockup where kmail wasn't involved, but killing kmail (or the whole of kde) 
won't unfreeze the display and keyboard once it's borked, and when I ssh in 
and run top it's X that's got the cpu pegged at 99%, not any of the kde 
toys...

Rob

[Linux-fbdev-devel] Re: [patch] Re: Framebuffer...Why oh Why???

[Daniel P. <phi...@bo...>]

On January 1, 2002 11:42 am, Alan Cox wrote:
> > > X11 isn't always an improvement.  I've got an X hang on my laptop (about
> > > once a week) that freezes the keyboard and ignores mouse clicks.  Numlock
> > > doesn't change the keyboard LEDs, CTRL-ALT-BACKSPACE won't do a thing, and
> > > although I can ssh in and run top (and see the CPU-eating loop), kill won't
> > > take X down and kill-9 leaves the video display up so the console that
> > > thinks it's in text mode, but isn't, is still useless.  (And that's
> > > assuming I'm plugged into the network and have another box around to ssh in
> > > from...)
> 
> Neomagic Magicgraph 128XD ? If so check man neomagic first 8)

Right, and check out the neo...@XF... mailing list archives.

I feel your pain ;)

--
Daniel

[Linux-fbdev-devel] Re: dj tree.

[Vojtech P. <vo...@su...>]

On Mon, Dec 31, 2001 at 08:31:51AM -0800, James Simmons wrote:
> 
> > > agree to use the dj tree for our work. 
> > 
> > So the `dj' tree is something like the `ac' tree, but for 2.5.x?
> > That's OK for me (world domination ;-)
> 
> Yeap. Great. I have some more stuff to push today. We can soon start
> pushing input api changes to the dj tree as well. 

Glad to hear this.

-- 
Vojtech Pavlik
SuSE Labs

[Linux-fbdev-devel] Re: [patch] Re: Framebuffer...Why oh Why???

[Marius G. <mg...@ce...>]

On Mon, Dec 31, 2001 at 04:41:19PM -0500, Rob Landley wrote:
> X11 isn't always an improvement.  I've got an X hang on my laptop (about once 
> a week) that freezes the keyboard and ignores mouse clicks.  Numlock doesn't 
> change the keyboard LEDs, CTRL-ALT-BACKSPACE won't do a thing, and although I 
> can ssh in and run top (and see the CPU-eating loop), kill won't take X down 
> and kill-9 leaves the video display up so the console that thinks it's in 
> text mode, but isn't, is still useless.  (And that's assuming I'm plugged 
> into the network and have another box around to ssh in from...)

I sometimes get a similar problem on my desktop when switching between
text and X11 virtual consoles.  Keyboard + mouse die (PS/2 counter
becomes stuck according to /proc/interrupts).  ssh followed by chvt
helps.

Marius Gedminas
-- 
Of course I use Microsoft. Setting up a stable unix network is no challenge ;p

[Linux-fbdev-devel] Re: [patch] Re: Framebuffer...Why oh Why???

[Alan C. <al...@lx...>]

> > X11 isn't always an improvement.  I've got an X hang on my laptop (about
> > once a week) that freezes the keyboard and ignores mouse clicks.  Numlock
> > doesn't change the keyboard LEDs, CTRL-ALT-BACKSPACE won't do a thing, and
> > although I can ssh in and run top (and see the CPU-eating loop), kill won't
> > take X down and kill-9 leaves the video display up so the console that
> > thinks it's in text mode, but isn't, is still useless.  (And that's
> > assuming I'm plugged into the network and have another box around to ssh in
> > from...)

Neomagic Magicgraph 128XD ? If so check man neomagic first 8)

[Linux-fbdev-devel] Re: [patch] Re: Framebuffer...Why oh Why???

[Rob L. <la...@tr...>]

On Sunday 30 December 2001 07:19 pm, Linus Torvalds wrote:
> On Sun, 30 Dec 2001, Timothy Covell wrote:
> > 	When X11 locks up, I can still kill it and my box lives.  When
> > framebuffers crash, their is no recovery save rebooting.  Back in 1995
> > I thought that linux VTs and X11 implemenation blew Solaris out of the
> > water, and now we want throw away our progress?  I'm still astounded
> > by the whole "oooh I can see  a penquin while I boot-up" thing?
> > Granted, frame buffers have usage in embedded systems, but do they
> > really have to be so deeply integrated??
>
> They aren't.
>
> No sane person should use frame buffers if they have the choice.
>
> Like your mama told you: "Just say no". Use text-mode and X11, and be
> happy.
>
> Some people don't have the choice, of course.
>
> 		Linus

X11 isn't always an improvement.  I've got an X hang on my laptop (about once 
a week) that freezes the keyboard and ignores mouse clicks.  Numlock doesn't 
change the keyboard LEDs, CTRL-ALT-BACKSPACE won't do a thing, and although I 
can ssh in and run top (and see the CPU-eating loop), kill won't take X down 
and kill-9 leaves the video display up so the console that thinks it's in 
text mode, but isn't, is still useless.  (And that's assuming I'm plugged 
into the network and have another box around to ssh in from...)

Compiling a debug version of X to run under gdb via ssh is on my to-do list...

A userspace program that takes over your main I/O devices modally and keeps 
them if it hangs isn't THAT much better than having the kernel ignore you 
directly...

Rob

[Linux-fbdev-devel] Re: dj tree.

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

> > agree to use the dj tree for our work. 
> 
> So the `dj' tree is something like the `ac' tree, but for 2.5.x?
> That's OK for me (world domination ;-)

Yeap. Great. I have some more stuff to push today. We can soon start
pushing input api changes to the dj tree as well. 

[Linux-fbdev-devel] Re: [patch] Re: Framebuffer...Why oh Why???

[<gm...@in...>]

On Sun, 30 Dec 2001, Linus Torvalds wrote:

> Date: Sun, 30 Dec 2001 16:19:15 -0800 (PST)
> From: Linus Torvalds <tor...@tr...>
> To: Timothy Covell <tim...@as...>
> Cc: Andrew Morton <ak...@zi...>, lin...@vg...,
>      Linux Frame Buffer Device Development
>     <lin...@li...>,
>      Marcelo Tosatti <ma...@co...>
> Subject: Re: [patch] Re: Framebuffer...Why oh Why???
> 
> 
> On Sun, 30 Dec 2001, Timothy Covell wrote:
> >
> > 	When X11 locks up, I can still kill it and my box lives.  When
> > framebuffers crash, their is no recovery save rebooting.  Back in 1995
> > I thought that linux VTs and X11 implemenation blew Solaris out of the
> > water, and now we want throw away our progress?  I'm still astounded
> > by the whole "oooh I can see  a penquin while I boot-up" thing?
> > Granted, frame buffers have usage in embedded systems, but do they
> > really have to be so deeply integrated??
> 
> They aren't.
> 
> No sane person should use frame buffers if they have the choice.
> 
> Like your mama told you: "Just say no". Use text-mode and X11, and be
> happy.
> 
> Some people don't have the choice, of course.
> 
> 		Linus

Like the no choice if having one's 11 year old syster try to use the
thing?

Text-mode and X11 seem to work fine if you walk on egg shells but just try
switching from console to text mode and back again several
times.  Eventually it _will_ crash.  Or worse yet mix svgalib and X11.

My brother and sister both used to crash my system at least 3 times a week  
before framebuffer + fbdev came into play.

	Gerhard



 



--
Gerhard Mack

gm...@in...

<>< As a computer I find your faith in technology amusing.

[Linux-fbdev-devel] Re: dj tree.

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

On Sat, 29 Dec 2001, James Simmons wrote:
>    I talked to Dave Jones a little bit ago about accepting patches. As we
> know Linus has been busy with the block layer and hasn't been taking abny
> other patches. I like to see our work get a larger audience. So David has
> agreed to this. So Geert and Vojtech I like to push our work to the dj
> tree. Note the ruby tree will remain against the standard Linus tree but
> the dj tree will end up closer to the ruby tree. Eventually it will sync
> over to Linus tree. 
>    I already have sent patchs for the new fbdev api. The one you blessed
> Geert. I sent some of tty stuff as well. So I like to see everyone here
> agree to use the dj tree for our work. 

So the `dj' tree is something like the `ac' tree, but for 2.5.x?
That's OK for me (world domination ;-)

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] Re: [patch] Re: Framebuffer...Why oh Why???

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

On Sun, 30 Dec 2001, Timothy Covell wrote:
> 	When X11 locks up, I can still kill it and my box lives.  When
> framebuffers crash, their is no recovery save rebooting.  Back in 1995

When your SCSI driver crashes, their is no recovery save rebooting.
When your IDE driver crashes, their is no recovery save rebooting.
When your Ethernet driver crashes, their is no recovery save rebooting.
...

If a frame buffer device crashes, it's a bug in the frame buffer device driver
(unless the kernel got `tainted' by a user space application with root
 privileges that messed with the graphics card without the frame buffer device
 driver being aware of that).

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] fwd: atyfb has always failed to me

[Eddie C. D. <ec...@sk...>]

Hi,

could anyone take care of this please:


> Date: Sun, 30 Dec 2001 08:56:08 -0600
> From: Felipe Contreras <al5...@ma...>
> To: "Eddie C. Dost" <ec...@sk...>
> Subject: atyfb has always failed to me
> Message-ID: <200...@si...>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> User-Agent: Mutt/1.3.24i
> X-UIDL: d08c85eb398f93d3d19a2c7b6aaa1690
> Sender: ec...@sk...
> 
> Hi,
> 
> I have tryied to report this problem before but I have not received any
> answer. Always since I have this lap atyfb fails, I think probably it's
> because I have an ATI Rage Mobility M1 (mach64). I wonder if there is no
> support for this card.
> 
> Just to mention something svgalib do weird things, and sometimes it has
> the same problem than atyfb, the screen has like vertical blocks of
> garbage.
> 
> Felipe Contreras


Eddie C. Dost
ecd @ skynet.be

[Linux-fbdev-devel] Re: [patch] Re: Framebuffer...Why oh Why???

[Benjamin H. <be...@ke...>]

>
>On Sun, 30 Dec 2001, Timothy Covell wrote:
>>
>> 	When X11 locks up, I can still kill it and my box lives.  When
>> framebuffers crash, their is no recovery save rebooting.  Back in 1995
>> I thought that linux VTs and X11 implemenation blew Solaris out of the
>> water, and now we want throw away our progress?  I'm still astounded
>> by the whole "oooh I can see  a penquin while I boot-up" thing?
>> Granted, frame buffers have usage in embedded systems, but do they
>> really have to be so deeply integrated??
>
>They aren't.
>
>No sane person should use frame buffers if they have the choice.
>
>Like your mama told you: "Just say no". Use text-mode and X11, and be
>happy.
>
>Some people don't have the choice, of course.

Heh... well, text mode isn't that nice regarding the need for having
the "ISA memory" window available on the bus, and in general, those legacy
ISA memory and IO space needed by VGA text mode are rather a painful pile of
hack to carry on on non-x86 platforms ;)

And just my 2 cents: X11 is perfectly able to lock up the box solid. It
has root access to /dev/mem, it has direct access to video card registers,
that is enough to lockup the bus in quite a number of cases (shame on
nasty hardware). Add to that DRI with it's kernel module and bus mastering
hardware, and you obtain something with has as much chances as fbdev to
kill your box once it starts behaving erratically.

Ben.

Re: [Linux-fbdev-devel] Re: [patch] Re: Framebuffer...Why oh Why???

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

> > Granted, frame buffers have usage in embedded systems, but do they
> > really have to be so deeply integrated??
> 
> They aren't.
> 
> No sane person should use frame buffers if they have the choice.
> 
> Like your mama told you: "Just say no". Use text-mode and X11, and be
> happy.
> 
> Some people don't have the choice, of course.

Some. Try pretty much every platform except ix86. Plus now that M$ doesn't
support DOS you are starting to see graphics card manufactures dropping
VGA support. Even BIOS setup interfaces use the VESA graphics interface
these days. So VGA text days are numbered. I agree the framebuffer/console
layer really needs to reworked to do the right things. I plan to do that
for 2.5.X. 

[Linux-fbdev-devel] Re: [patch] Re: Framebuffer...Why oh Why???

[Linus T. <tor...@tr...>]

On Sun, 30 Dec 2001, Timothy Covell wrote:
>
> 	When X11 locks up, I can still kill it and my box lives.  When
> framebuffers crash, their is no recovery save rebooting.  Back in 1995
> I thought that linux VTs and X11 implemenation blew Solaris out of the
> water, and now we want throw away our progress?  I'm still astounded
> by the whole "oooh I can see  a penquin while I boot-up" thing?
> Granted, frame buffers have usage in embedded systems, but do they
> really have to be so deeply integrated??

They aren't.

No sane person should use frame buffers if they have the choice.

Like your mama told you: "Just say no". Use text-mode and X11, and be
happy.

Some people don't have the choice, of course.

		Linus