I updated the name of the property based on the discussion above.
------------------------------------------------------------------
1. Introduction
1.1. Project/Component Working Name:
"primary-controller" 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-controller driver property Committed primary graphics device
Every frame buffer driver will create a "primary-controller" for it. And
the value is a boolean value. True on the primary device and false on
the others.
Alan Coopersmith:
> 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
>
>
--
Best Regards,
Ming.
------------------------------------------
-Edward Shu
-Solaris x86 Engineering, Sun Microsystems
-tele: +86-10-62673100
__________________________________________
