[lkml]   [1999]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: short display with 2.1.132-ac3, matroxfb and XF86_SVGA 3.3.3

On Sun, 3 Jan 1999, Geert Uytterhoeven wrote:
> > That's like separating the S3 X server into ten different X servers
> > depending on which clock chip is on the board. That would just be silly
> > and stupid, wouldn't it? But it's really almost exactly the same issue:
> > the fact that the kernel handles mode switching could just be considered
> > "a software clock chip" kind of thing. No?
> Right! Finally we're getting at the same wavelength :-)


> But for the 3.x line, XFree86 has many different accelerated X servers, each
> with their own screen init functions. The current accelerated XF68_FBDev is
> experimental, and we did it the way we did because that was the only way it
> made sense to us (at that time, 4.x is not finished).

Now this is an argument I can _completely_ buy into.

Considering XF86_FBdev to be a "interim" thing I can fully understand.
What I do NOT understand is the mentality that some people seem to have
that "it is a bug to try to use anything _but_ XF86_FBdev with CONFIG_FB".

For X servers where the mode switching works even together with CONFIG_FB
(and yes, there are tons of people that seem to use CONFIG_FB together
with some accelerated servers already), I would think we _want_ to use
those accelerated X servers - possibly with a caveat that they aren't
guaranteed to work. But the mentality that "if you have CONFIG_FB you have
to use XF86_FBdev" must go, imho. Jes, do you understand?

I already applied a documentation patch by Jes from to 2.2.0pre4 saying
that CONFIG_FB is not necessarily a good idea if you can avoid it. But
Jes, if you continue to say that if you run CONFIG_FB you _cannot_ run any
other X server, then I will just change the config option to something
like CONFIG_SCREEN_SLOW_X and change the documentation to match to make
_sure_ nobody ever does it even by mistake.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:49    [W:0.138 / U:0.844 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site