linux-kernel - Re: [RFC] enhancing the kernel's graphics subsystem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9e4733910705220902y151d1922s7e478de041062aa4@mail.gmail.com>
Date:	Tue, 22 May 2007 12:02:12 -0400
From:	"Jon Smirl" <jonsmirl@...il.com>
To:	"Jesse Barnes" <jbarnes@...tuousgeek.org>
Cc:	"Alan Cox" <alan@...rguk.ukuu.org.uk>,
	"Jeff Garzik" <jeff@...zik.org>,
	"Jesse Barnes" <jesse.barnes@...el.com>,
	linux-kernel@...r.kernel.org,
	"Antonino A. Daplas" <adaplas@...il.com>
Subject: Re: [RFC] enhancing the kernel's graphics subsystem

On 5/22/07, Jesse Barnes <jbarnes@...tuousgeek.org> wrote:
> On Tuesday, May 22, 2007, Jon Smirl wrote:
> > On 5/22/07, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> > > > you display text in graphics mode entirely in kernel context. The
> > > > driver should also attempt to stop the GPU to try and make sure it
> > > > doesn't erase the OOPS display.
> > >
> > > If we know how yes. Probably the X server needs to provide us with a
> > > simple list of operations to perform or failing that write 128K of
> > > null to the display then print the characters (the 128K should ensure
> > > any running FIFO for commands is stuffed and we get back to the
> > > framebuffer)
> > >
> > > > Another simple thing that needs to be built is a mechanism to run
> > > > the VBIOS in x86 mode when the driver is first loaded. This can be
> > >
> > > We don't want to touch the video bios for most cards, its not as good
> > > as the X mode switcher code, nor for that matter does it work in a lot
> > > of cases as they use IRQ and DMA functions sometimes.
> >
> > The only reason the VBIOS is run is to initially reset the card. Once
> > we get the card reset it isn't used any more. For almost all cards
> > this is the only way to reset them, we have insufficient information
> > to write this ourselves.
>
> We should aim to get away from this though.  For Intel and VIA chips, we
> have enough info to do full card setup ourselves.  IIRC there's some early
> code to do the same for ATI chips (not sure about other chips though).  If
> we can avoid using the VBIOS, our drivers will be far more portable and
> featureful than they'd be otherwise.  For example, current ATI drivers
> simply can't do full multihead on many setups because it relies on the
> BIOS to setup external DAC chips, and in many cases the BIOS doesn't.  In
> order to address that, we need to learn how to do it ourselves...  So if
> at all possible, I'd like to avoid baking any assumptions about VBIOS POST
> into this design.

I've talked to an ATI engineer about VBIOS initialization. The chips
may have different steppings. They flash the right VBIOS that matches
the chip into the ROM on the card.  Given all the various steppings
this is the only sane way to initialize the hardware. I don't believe
generic initialization code that can handle all of the various
steppings exists for any hardware.

-- 
Jon Smirl
jonsmirl@...il.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/