lkml.org 
[lkml]   [1999]   [Jan]   [6]   [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 4 Jan 1999, Jes Sorensen wrote:

> >>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:
>
> Linus> For X servers where the mode switching works even together with
> Linus> CONFIG_FB (and yes, there are tons of people that seem to use
> Linus> CONFIG_FB together with some accelerated servers already), I
> Linus> would think we _want_ to use those accelerated X servers -
> Linus> possibly with a caveat that they aren't guaranteed to work. But
> Linus> the mentality that "if you have CONFIG_FB you have to use
> Linus> XF86_FBdev" must go, imho. Jes, do you understand?
>
> In some cases it will work and in some it is damn hard to make it
> work.

The only reason that it ever works at all is that, up until this
point, very few fbdev drivers tried to do anything complex with the
hardware, and thus there are relatively few ways for the fbdev drivers to
clash with the XFree86 drivers. This Mach64 problem is just a taste of
the problems that are sure to come, though, as people try to actually
write fbdev drivers that work properly and consistently.

> I am by no way an X expert, I just hacked up a an acceleration
> module (from the NetBSD in fact) to work on the NCR chip I have on my
> video card).

This is not at all an X issue. It is an issue of hardware state
maintenance and locking.

> Geert gave me an example earlier today as to why, let me try to quote
> it from memory: One problem is that some X servers (like the Mach64
> one) reads memory clock settings from the BIOS on the card instead of
> reading them from the registers. The frame buffer driver does not
> necessarily use the same settings as in the BIOS and in this case you
> may see unpredictable results when running the X server.

Lack of proper state maintenance and locking in the kernel is what
causes this, and there are zillions more of these gotchas lurking out
there. The classic one involves MMIO relocation, which many of the X
servers do. Load an fbdev driver for a card, then run an X server for the
same card which does an MMIO reloc, and then switch away from the X
virtual console and "watch" (actually your display will be dead and maybe
the whole kernel as well) the fbdev driver oops with a bus error as it
attempts to write data to a framebuffer which has moved.

> What else some X servers will read from board BIOSes is beyond me but
> there is a potential danger here. I strongly support the idea of
> making the general X server FB aware, whether we refer to it as the
> new SVGA server, the FBDev server or something else I expect it to be
> the same thing.

It *has* to be this way. Userspace code cannot just go around
blindly reconfiguring the hardware out from under the kernel drivers. You
can argue forever about what should and should not go into the fbdev
drivers (acceleration, mode timing calculations, etc) but the ability to
lock framebuffer and MMIO region accesses and maintain hardware state
**MUST** be present in the kernel drivers, and **ALL** userspace code
**MUST** conform to the kernel's way of doing things.

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed


-
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.241 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site