From: "Kendall Bennett" <KendallB@scitechsoft.com>
To: linux-kernel@vger.kernel.org
Subject: Re: VESA FBconsole driver?
Date: Thu, 13 Mar 2003 13:31:01 -0800 [thread overview]
Message-ID: <3E708815.23768.38089C@localhost> (raw)
In-Reply-To: <3E6F14F6.7063.2D30924F@localhost>
I wrote:
> A long time ago I remember there was a guy working on a VESA
> FBconsole driver for Linux. Then driver he was working on was
> structured as a user land daemon that the kernel console driver
> would call back into once the system was up, allowing the userland
> VESA driver to use the vm86() service to change modes, program the
> palette and other useful things that can't be done by the basic
> driver that uses a mode set previously by LILO or GRUB.
No-one has responded to this email, so either no-one remembers this is
people think someone else responded to my email ;-)
Does anyone remember this project. I checked the Linux kernel and it
presently does not seem to have any support for this. Can anyone point me
at references that will help me figure out how the kernel can make
callbacks into a user land daemon?
> My second question is, is it possible to execute vm86() services
> from *within* the kernel as opposed to from user land? I got the
> impression at the time that the userland daemon was used because
> vm86() could only be called from userland code and could not be
> called from within the kernel to execute real mode VESA BIOS
> services. Is that correct? If not, can vm86() services now be
> called from other kernel modules inside the kernel?
I checked into this some more and it is clear that vm86() is only useable
from userland code on Linux. However recently the FreeBSD kernels were
modified to support vm86() from within the kernel, and in fact the latest
FreeBSD VESA console driver uses the vm86() services so that it can do
everything using the BIOS where necessary.
Is there any reason why the vm86() services in the Linux kernel cannot be
used by other kernel code? Has anyone made an attempt to update the
vm86() services to support this?
Thanks!
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
next prev parent reply other threads:[~2003-03-13 21:20 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-12 16:07 "Cross" compilation for s390x Pete Zaitcev
2003-03-12 19:07 ` VESA FBconsole driver? Kendall Bennett
2003-03-13 21:31 ` Kendall Bennett [this message]
2003-03-13 22:11 ` Petr Vandrovec
2003-03-13 23:41 ` Kendall Bennett
2003-03-14 10:14 ` Geert Uytterhoeven
2003-03-14 18:25 ` Kendall Bennett
2003-03-14 10:21 ` Helge Hafting
2003-03-13 22:24 ` Gerd Knorr
2003-03-13 23:41 ` Kendall Bennett
2003-03-14 10:15 ` Helge Hafting
2003-03-14 18:25 ` Kendall Bennett
2003-03-15 18:04 ` Helge Hafting
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=3E708815.23768.38089C@localhost \
--to=kendallb@scitechsoft.com \
--cc=linux-kernel@vger.kernel.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