Posts:
5,507
From:
US
Registered:
3/9/05
|
|
|
|
"primary-card" frame buffer driver property [PSARC/2009/596 FastTrack
timeout 11/09/2009]
Posted:
Nov 2, 2009 11:18 AM
|
|
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 dot coopersmith at sun dot 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
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
Garrett D'Amore
gdamore@sun.com
|
|
|
|
Re: "primary-card" frame buffer driver property [PSARC/2009/596
FastTrack timeout 11/09/2009]
Posted:
Nov 2, 2009 7:44 PM
in response to: alanc
|
|
"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 dot coopersmith at sun dot 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
>
>
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
43
From:
Beijing
Registered:
3/15/06
|
|
|
|
Re: "primary-controller" frame buffer driver property [PSARC/2009/596
FastTrack timeout 11/09/2009]
Posted:
Nov 3, 2009 4:54 PM
in response to: alanc
|
|
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 dot coopersmith at sun dot 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
__________________________________________
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
41
From:
Registered:
3/30/07
|
|
|
|
Re: "primary-card" frame buffer driver property [PSARC/2009/596
FastTrack timeout 11/09/2009]
Posted:
Nov 4, 2009 2:40 PM
in response to: alanc
|
|
How does a device driver know that it's a primary device?
There's no harm, is there, if a driver fails to publish this property?
One of the emails said that on SPARC the default graphics device is the
first graphics device found that can be controlled by the probe-list
words. Do I assume correctly that this isn't necessarily so, for
example when the console device is a graphics device specified by the
OpenBoot NVRAM parameter output-device?
> 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.
>
-- Eric
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
572
From:
Troy, Michigan USA
Registered:
3/9/05
|
|
|
|
Re: "primary-card" frame buffer driver property [PSARC/2009/596
FastTrack timeout 11/09/2009]
Posted:
Nov 4, 2009 3:43 PM
in response to: egs
|
|
Eric Sultan wrote:
>
> How does a device driver know that it's a primary device?
It doesn't, really, nor is it required for this project. This project
only provides identification of the primary graphics controller to
user space. We didn't make it an implementation requirement this
property existed prior to the first attach so that the driver could
query.
There are tricks on both the SPARC and x86 platforms for the
character driver to figure this out.
> There's no harm, is there, if a driver fails to publish this property?
Correct, nor is the character driver bound to the graphics controller
responsible for publishing this property.
>
> One of the emails said that on SPARC the default graphics device is
> the first graphics device found that can be controlled by the
> probe-list words. Do I assume correctly that this isn't necessarily
> so, for example when the console device is a graphics device specified
> by the OpenBoot NVRAM parameter output-device?
>
I thought I wrote that in the context of the console output device
being something other than one of the graphics controllers but now
that I've reread it, I didn't make that clear. In the case where the
graphics
controller is the console output device, it is also the primary device.
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
43
From:
Beijing
Registered:
3/15/06
|
|
|
|
Re: "primary-card" frame buffer driver property [PSARC/2009/596
FastTrack timeout 11/09/2009]
Posted:
Nov 4, 2009 4:53 PM
in response to: egs
|
|
Eric Sultan:
>
> How does a device driver know that it's a primary device?
> There's no harm, is there, if a driver fails to publish this property?
On x86, the default graphics device is the one for which the SBIOS
has enabled I/O cycles on the entire devices path. Only Xorg(libpciaccess)
on X86 requires this property now. And this case make this property name
a generic one for the future work on SPARC.
If the driver fails to publish this property, the will lead to Xorg
can not
start on the system with two and more graphics controller attached.
>
> One of the emails said that on SPARC the default graphics device is
> the first graphics device found that can be controlled by the
> probe-list words. Do I assume correctly that this isn't necessarily
> so, for example when the console device is a graphics device specified
> by the OpenBoot NVRAM parameter output-device?
Console device and the primary controller is not necessary the same,
though in most case they are the same. As we discussed above,
Xorg(libpciaccess)
is not fully ready yet and the implementation of this property will be
in the future work.
>
>
>> 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.
>>
>
> -- Eric
--
Best Regards,
Ming.
------------------------------------------
-Edward Shu
-Solaris x86 Engineering, Sun Microsystems
-tele: +86-10-62673100
__________________________________________
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
43
From:
Beijing
Registered:
3/15/06
|
|
|
|
Re: "primary-card" frame buffer driver property [PSARC/2009/596
FastTrack timeout 11/09/2009](resent it per Alan's request)
Posted:
Nov 4, 2009 9:43 PM
in response to: alanc
|
|
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 dot coopersmith at sun dot 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
__________________________________________
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
5,507
From:
US
Registered:
3/9/05
|
|
|
|
Re: "primary-controller" frame buffer driver property [PSARC/2009/596
FastTrack timeout 11/09/2009]
Posted:
Nov 9, 2009 6:46 PM
in response to: alanc
|
|
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.
Since this case has converged, and gotten it's +1, and there are no remaining
issues, it is now closed approved.
--
-Alan Coopersmith- alan dot coopersmith at sun dot com
Sun Microsystems, Inc. - X Window System Engineering
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
