From: Jeremy Jackson <jeremy.jackson@sympatico.ca>
To: Mark Vojkovich <mvojkovich@nvidia.com>
Cc: xpert@xfree86.org, linux-kernel@vger.kernel.org
Subject: Re: [Xpert]Video drivers and the kernel
Date: Wed, 14 Feb 2001 13:58:24 -0500 [thread overview]
Message-ID: <3A8AD550.87898BB0@sympatico.ca> (raw)
In-Reply-To: <Pine.LNX.4.21.0102131937590.1564-100000@mvojkovich1.nvidia.com>
Please CC me if sending to xpert list.
This is a big topic. I think I can contribute a whole two cents worth
though...
Interesting to note that NT's windowing system moved from being originally
in userland to inside the kernel between V3.? and 4.0. Remember mom saying
"If your friends all jump off a bridge..."
The issue I understand is that context switching kernel<>user slows things
down.
And then there's trying to make an api... XFree just maps mmio/framebuffer
and ioports
into it's own address space and bangs the hardware, so it's fast and can do
anything.
DRI extends this to client 3D code in a sense.
Bottom line for me, I don't care; as long as I still can use remote X apps,
and Quake3 uses
my 3D hardware, I'm happy to have people spend their time improving X how
they see fit,
and they're done an incredible job so far.
My only complaint is when there's a problem with X: It's cool that I can
just restart it
rather than reboot like windows. (so you can play from console of a server
right? :)
This is a benefit of it being in userspace. But it would be nice
if I didn't have to do it via telnet; sometimes I don't have a box on a
network.
(Aside, is this because X uses keyboard in raw mode? would be nice to still
be able to ctrl-alt-del to rebood from console) Anyone know about
using alt-sysrq to restore console?
So, if the kernel had a card specific module that just knew enough
to put the card back into text mode, or if it used the card's bios
to do it like the int10.a module in XFree 4.0, we would lack for nothing.
(hmm vesafb could be extended?)
> On Tue, 13 Feb 2001, Louis Garcia wrote:
>
> > I was wondering why video drivers are not part of the kernel like every
> > other piece of hardware. I would think if video drivers were part of the
> > kernel and had a nice API for X or any other windowing system, would not
> > only improve performance but would allow competing windowing systems
> > without having to develop drivers for each. Has anyone thought or
> > rejected this idea.
next prev parent reply other threads:[~2001-02-14 19:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-14 2:47 Video drivers and the kernel Louis Garcia
2001-02-14 4:02 ` [Xpert]Video " Mark Vojkovich
2001-02-14 18:58 ` Jeremy Jackson [this message]
2000-01-01 1:11 ` Pavel Machek
2001-02-14 6:04 ` Video " Jeff Garzik
2001-02-14 6:09 ` Albert D. Cahalan
2001-02-14 20:46 ` Brad Douglas
2001-02-14 16:55 ` Timur Tabi
-- strict thread matches above, loose matches on Subject: below --
2001-02-16 19:11 [Xpert]Video " James Simmons
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3A8AD550.87898BB0@sympatico.ca \
--to=jeremy.jackson@sympatico.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=mvojkovich@nvidia.com \
--cc=xpert@xfree86.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox