"primary-card" is a terrible name -- how about "primary-display"
instead? (The primary display may be on the motherboard!)
What is the purpose of this, is it for console support?
How is the decision about whether a display the primary or not made? Is
this user-configurable? Does it access underlying BIOS structures?
What about in unconventional configurations, such as display mirroring
or TwinView?
- Garrett
Alan Coopersmith wrote:
> I am sponsoring this case on behalf of Edward Shu of the x86 video driver
> team. The timeout is set for next Monday, November 9. The case requests
> a patch release binding. While the case is defined in a platform
> independent manner, the initial implementation will only cover x86 platforms
> as SPARC graphics drivers live in another consolidation.
>
> -Alan Coopersmith- alan.coopersmith at sun.com
> Sun Microsystems, Inc. - X Window System Engineering
>
> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
> This information is Copyright 2009 Sun Microsystems
> 1. Introduction
> 1.1. Project/Component Working Name:
> "primary-card" frame buffer driver property
> 1.2. Name of Document Author/Supplier:
> Author: Edward Shu
> 1.3 Date of This Document:
> 02 November, 2009
> 4. Technical Description
>
> 1. Summary
>
> The frame buffer driver property will expose the primary
> device to Xorg server or console driver. It is particularly
> helpful to the system with two or more graphics card attached.
> For the Xorg server, it must find the primary device to start
> at. Also, console must start on the primary graphics device
> when it is not directed to non-graphics device.
>
> 2. Discussion
>
> The frame buffer driver can also use visual ioctl to expose the
> primary graphics card information. But there are some drawbacks
> for adding the visual ioctl to the frame buffer driver.
>
> 1) It is difficult for the console query code to leverage the
> ioctl interface. Because the code there was bundled with
> "dev_info" pointer instead of standard driver interfaces
> like open, ioctl, etc.
>
> 2) The user land code don't know how many frame buffer driver
> that it should query using the ioctl. It can only enumerate
> the frame buffer device links, like /dev/fb0, fb1, fb2, fb3.
> Most likely, the links will not be extended to fb4 and more.
> But it is not guaranteed.
>
> So a driver property is used to expose the information.
>
> 3. Interface table
>
> Interface Name Classification Comments
> ------------------------------------------------------------------
> primary-card driver property Committed primary graphics device
>
> Every frame buffer driver will create a "primary-card" for it. And
> the value is a boolean value. True on the primary device and false on
> the others.
>
>
> 6. Resources and Schedule
> 6.4. Steering Committee requested information
> 6.4.1. Consolidation C-team Name:
> ON
> 6.5. ARC review type: FastTrack
> 6.6. ARC Exposure: open
>
>
