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

On Fri, 1 Jan 1999, Linus Torvalds wrote:
> On Fri, 1 Jan 1999, Geert Uytterhoeven wrote:
> > It's the other way round: the X server can't live with the frame buffer
> > console. It can live with the text console only.
>
> I know that didn't use to be true - I could start a X server from within
> another X server, and the second X server would restore the _graphics_
> mode of the first one.
>
> I suspect the fb people haven't even _talked_ to the X people. It should

Wrong assumption.

> be trivial to add an option to XFree86 to say "oh, btw, the mode is
> already set up, don't bother with modeswitching on entry or exit".

This is exactly what XF68_FBDev does.

On Fri, 1 Jan 1999, Linus Torvalds wrote:
> On Fri, 1 Jan 1999, Gerd Knorr wrote:
> >
> > In theory it should work fine. In practice some X-Servers have problems
> > to restore the video mode correctly. Maybe due to some hardware problem
> > (some video boards you can't ask about the current state), maybe becauce
> > they don't expect the console being in graphics mode. You'll end up with
> > a broken console then. This problem is'nt new...
>
> I know - we used to have problems even with restoring to normal text-mode
> if it was set to anything except for 80x25.
>
> But I really think that it should be easy to tell X not to switch modes,
> and just tell it hat mode it is in. The modeswitching part of X is the
> most fragile and yet the least important one, so this would get all of the
> advantages of having a kernel fb device with none of the disadvantages.

This is exactly what XF68_FBDev does.

The experimental version with hardware acceleration (for NCR77C32BLT, ATI
Mach64 and IMS Twin Turbo) rely on the frame buffer device for setting up the
mode, and use `normal' acceleration from user space. In the case of ATI Mach64,
this is the normal XFree86 acceleration code with some very minor
modifications. Patches against XFree86 3.3.3 are at

http://www.cs.kuleuven.ac.be/~geert/bin/xc-3.3.3-geert-19981210.diff.gz

> Dirk, who in the XFree86 team should people talk to about something like
> this? The current situation where the kernel frame buffer and a regular X
> server don't always work together is just silly.

I should talk to myself. Yes, I'm XFree86 developer.

Greetings,

Geert

--
Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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