public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Renninger <trenn@suse.de>
To: Zhang Rui <rui.zhang@intel.com>
Cc: Luis Henriques <henrix@sapo.pt>, linux-acpi@vger.kernel.org
Subject: Re: Problem with ACPI video
Date: Mon, 8 Sep 2008 02:20:10 +0200	[thread overview]
Message-ID: <200809080220.10657.trenn@suse.de> (raw)
In-Reply-To: <1220576561.24775.266.camel@rzhang-dt>

On Friday 05 September 2008 03:02:41 am Zhang Rui wrote:
> On Fri, 2008-09-05 at 03:44 +0800, Luis Henriques wrote:
> > Zhang Rui wrote:
> > >> It seems that acpi_video_bus_add function is invoked twice and, the
> > >> second time, it fails (maybe it is supposed to be invoked
> >
> > twice...).
> >
> > > There are two ACPI video bus devices both named "VGA" in the ACPI
> > > namespace, and each of them tries to create an entry "VGA"
> > > under /proc/acpi/video/.
> > > that's why this message is printed out.
> >
> > Sorry about my ignorance on the topic but... does this mean I do
> > actually have 2 devices?  If this is true, then I should actually have
> > "VGA1" and "VGA2" dirs in /proc, right?
>
> No, because the video driver tries to register two "VGA" procfs entry,
> we get two "VGA" dirs in /proc...
I expect Luis wants to know why there are two ACPI graphics devices
in his BIOS tables.
In most BIOSes a device for an integrated and a shared graphics solution is 
implemented in ACPI tables, read more here:
http://en.wikipedia.org/wiki/Graphics_processing_unit
(Integrated graphics solutions, or shared graphics solutions)

The reason is that it seems ACPI cannot easily check whether the graphics card 
is available at all and provide a _STA function to easily let the OS check 
that.

But you always only should have one of above devices available at a time.
The same name can be used in ACPI for different devices (in different scopes), 
which is shown by above graphics cards problem and this shows that the ACPI
proc implementation is broken by design in this respect. Anyway we always came 
away (and still do if not available dummy graphics devices are ignored, this 
is what the new patch does) with it. And sysfs will do better anyway.

The vendor could theoretically remove one implementation when the machine
is sold, but I expect it is easier for them to not do that and thus being able 
to use the same BIOS tables for models with a shared or integrated graphics
solution and let OS check which one to use.

         Thomas

  reply	other threads:[~2008-09-08  0:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-03 21:45 Problem with ACPI video Luis Henriques
2008-09-04  1:19 ` Zhang Rui
2008-09-04 19:44   ` Luis Henriques
2008-09-05  1:02     ` Zhang Rui
2008-09-08  0:20       ` Thomas Renninger [this message]
2008-09-08  3:33         ` Henrique de Moraes Holschuh

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=200809080220.10657.trenn@suse.de \
    --to=trenn@suse.de \
    --cc=henrix@sapo.pt \
    --cc=linux-acpi@vger.kernel.org \
    --cc=rui.zhang@intel.com \
    /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