linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Antonino Daplas <adaplas@pol.net>
To: Jon Smirl <jonsmirl@yahoo.com>
Cc: Kendall Bennett <KendallB@scitechsoft.com>,
	Linux Fbdev development list
	<linux-fbdev-devel@lists.sourceforge.net>,
	DirectFB-devel <directfb-dev@directfb.org>
Subject: Re: [ANNOUNCE]: VM86 Daemon
Date: 01 Apr 2003 17:41:03 +0800	[thread overview]
Message-ID: <1049188090.1031.41.camel@localhost.localdomain> (raw)
In-Reply-To: <20030401040106.65664.qmail@web14906.mail.yahoo.com>

On Tue, 2003-04-01 at 12:01, Jon Smirl wrote:
> --- Antonino Daplas <adaplas@pol.net> wrote:
> > A new device seems more powerful and more generic. 
> > Generic in a sense
> > that other subsystems besides fbdev can use it to
> > access the BIOS or
> 
> The new device is going to need to sort out multiple
> adapters. Using /dev/fbX avoids that problem. You'll

No, it won't.  If multiple graphics adapters are to be supported, what's
needed is a hardware unique identifier that is known to both caller and
callee.  /dev/fbX will not tell you anything about the device.  This
unique ID can be the bus, device and function number.  So whether the
request is done through /dev/fbX or /dev/vm86, the ID must still be
specified.

> also be able to get the /dev/fb code into the kernel.
> Getting a driver in that creates /dev/vm86 is going to
> be harder. 

I would rather have the code rejected than back-dooring it behind fbdev.
If it's going to be accepted, it has to be on its own merit.

> 
> I'm not clear on what /dev/vm86 does. Why couldn't the

/dev/vm86 just controls how data gets to and from the daemon.  What kind
of data passes through it does not matter.  Only the daemon and the
caller should know what protocol is used.

> radeon driver exec vm86d with a parameter of /dev/fb0.
> vm86d would then open/IOCTL the radeon driver to
> identify the PCI device and what actions are needed.
> After it resets and gets the EDID data it would IOCTL
> them back into /dev/fb0 and exit. You need to know
> which PCI device so that you can set up the right
> VBIOS ROM. Each adapter would get it's own vm86d, but
> they wouldn't hang around long.
> 

Yes, in a similar manner, fbdev can pass a request through /dev/vm86
that says "run expansion ROM code of device with this unique ID".  The
daemon will then do just that.  It does not matter if the device is a
VGA controller, or some other PCI device.  It also will not matter if
the expansion ROM is in x86 form, OpenFirmware, etc, it's up to the
daemon.

The hardest part that the daemon will do is maintaining separate virtual
mode environments if the device happens to be a VGA controller.  This is
only needed if the VBIOS are to be consistently required. Other types of
PCI devices should not suffer the same limitation.
 

Tony




-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

  reply	other threads:[~2003-04-01 10:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-31  9:53 [ANNOUNCE]: VM86 Daemon Antonino Daplas
2003-04-01  0:07 ` Jon Smirl
2003-04-01  0:27   ` Kendall Bennett
2003-04-01  1:27     ` Antonino Daplas
2003-04-01  8:29       ` Benjamin Herrenschmidt
2003-04-01  9:41         ` Antonino Daplas
2003-04-01 11:34           ` Benjamin Herrenschmidt
2003-04-01 13:38             ` Antonino Daplas
2003-04-01 13:53               ` Benjamin Herrenschmidt
2003-04-01 15:32                 ` Antonino Daplas
2003-04-01 15:22               ` Jon Smirl
2003-04-01 16:25                 ` Antonino Daplas
2003-04-01 16:44                   ` Benjamin Herrenschmidt
2003-04-01 18:30                   ` Small API change Benjamin Herrenschmidt
2003-04-01 20:10                     ` Geert Uytterhoeven
2003-04-01 22:03                       ` Benjamin Herrenschmidt
2003-04-02 22:01                         ` James Simmons
2003-04-02 22:11                           ` Benjamin Herrenschmidt
2003-04-01  1:04   ` [ANNOUNCE]: VM86 Daemon Antonino Daplas
2003-04-01  4:01     ` Jon Smirl
2003-04-01  9:41       ` Antonino Daplas [this message]
     [not found]         ` <20030401120835.GA30421@skunk.convergence.de>
2003-04-01 13:38           ` [directfb-dev] " Antonino Daplas

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=1049188090.1031.41.camel@localhost.localdomain \
    --to=adaplas@pol.net \
    --cc=KendallB@scitechsoft.com \
    --cc=directfb-dev@directfb.org \
    --cc=jonsmirl@yahoo.com \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    /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;
as well as URLs for NNTP newsgroup(s).