So I confess that I don't understand why X server configuration is
necessary on SPARC, but not on x86.
Has EDID technology finally reached the pervasiveness that we never need
to configure resolutions or displays manually? If so, then why is this
true on SPARC but not on x86? Or is the situation such that UI-based
configuration tools can be used? (And if so, what happens when someone
has a monitor that is either misreporting its EDID or is not functional
at EDID resolutions for somesuch... I've often seen monitors that don't
work properly at their stated limits.)
What kind of sacrifices will x86 users have to make, in
customizability? Will end users still be able to tweak resolutions
using the GUI tools?
I suspect that the answer to all of the above is that
1) resolution switching can be done using the Gnome desktop tools
2) fbconfig is primarily being provided to retain interface
familiarity for sparc users, Xsun may not support dynamic resolutions
I'd like to hear that for certain though. I'd also like to know whether
there ever exists a need to change the default resolution(s) for a
platform from the CLI, ala fbconfig, even for x86 platforms?
-- Garrett
Mike Riley wrote:
> Just curious about platform parity is all.
>
> Mike
>
> Alan Coopersmith wrote:
>> What configuration do you think is needed on x86? We're moving away
>> from
>> xorg.conf for anything but customizations that can't be done at
>> runtime and
>> which shouldn't be the defaults.
>>
>> We do pass through nvidia's configuration utilities with their
>> drivers, but
>> for most drivers, there is little to no configuration needed.
>>
>> -Alan Coopersmith- alan.coopersmith at sun.com
>> Sun Microsystems, Inc. - X Window System Engineering
>>
>>
>> Mike Riley wrote:
>>> So you are saying that X86 should remain with no way to configure Xorg
>>> displays, except manually editing the xorg.conf file, and only a
>>> deprecated method for configuring Xsun displays?
>>>
>>> This makes no sense to me.
>>>
>>> Mike
>>>
>>> Stuart Kreitman wrote:
>>>> This should be exclusive to Sparc, because x86 never had fbconfig, It
>>>> had kdmconfig which is quite deprecated,
>>>> see the man page on it. kdmconfig was kept specific to Xsun and has
>>>> nothing to do with xorg.conf.
>>>>
>>>>
>>>> Stuart
>>>>
>>>>
>>>> Mike Riley wrote:
>>>>> Is this for both X86 and Sparc then?
>>>>>
>>>>> I am asking because the platform is not mentioned here and fbconfig
>>>>> does not (yet) exist on X86 and Xorg is just starting to show up for
>>>>> Sparc.
>>>>>
>>>>> Mike
>>>>>
>>>>> Eric Sultan wrote:
>>>>>> I'm sponsoring this proposal for David Paist, the timeout to
>>>>>> expire on
>>>>>> 06/30/2008. The requested release binding is patch.
>>>>>>
>>>>>> -- Eric
>>>>>>
>>>>>>
>>>>>> Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI
>>>>>> This information is Copyright 2008 Sun Microsystems
>>>>>> 1. Introduction
>>>>>> 1.1. Project/Component Working Name:
>>>>>> fbconfig configuration utility for Xorg
>>>>>> 1.2. Name of Document Author/Supplier:
>>>>>> Author: David Paist
>>>>>> 1.3 Date of This Document:
>>>>>> 23 June, 2008
>>>>>> 4. Technical Description
>>>>>>
>>>>>> This project modifies fbconfig, the frame buffer configuration
>>>>>> utility, to support both the Xorg and the Xsun versions of the X
>>>>>> server. A goal is to provide seamless support in Xorg
>>>>>> environments
>>>>>> for current fbconfig(1M) users.
>>>>>>
>>>>>> The current /usr/sbin/fbconfig program will be modified to
>>>>>> retrieve
>>>>>> the name of the currently-configured X server from the service
>>>>>> configuration repository. If the server is Xsun, fbconfig will
>>>>>> operate as it currently does for Xsun, modifying if necessary
>>>>>> the
>>>>>> OWConfig database.
>>>>>>
>>>>>> If the server is Xorg, fbconfig will invoke a new program
>>>>>> fbconf-xorg, which in turn will invoke a device-specific
>>>>>> module to
>>>>>> provide the configuration operations for the device named in the
>>>>>> command line.
>>>>>>
>>>>>> A new library, libfbconf-xorg.so, is provided to provide
>>>>>> functions
>>>>>> common to fbconf-xorg and to the device-dependent modules.
>>>>>>
>>>>>> The device-dependent module names are formed from the identifier
>>>>>> returned by the VIS_GETIDENTIFIER ioctl, in a manner similar
>>>>>> to the
>>>>>> practice for fbconfig modules for Xsun. For Xorg, the
>>>>>> modules are
>>>>>> named lib<Corporate Identifier><Device Name>_conf.so. For
>>>>>> example,
>>>>>> the module for kfb is libSUNWkfb_conf.so.
>>>>>>
>>>>>> Durable data will be stored in /etc/X11/xorg.conf. If that file
>>>>>> does
>>>>>> not exist, it will be created with a minimal configuration
>>>>>> necessary
>>>>>> to support the requested configuration.
>>>>>>
>>>>>> Interfaces exported:
>>>>>>
>>>>>> /usr/sbin/fbconfig Uncommitted
>>>>>> modified program
>>>>>> /usr/lib/fbconfig/fbconf-xorg Uncommitted new
>>>>>> /usr/lib/fbconfig/libfbconf-xorg.so Uncommitted new
>>>>>> /usr/lib/fbconfig/libSUNWkfb_conf.so Uncommitted new,
>>>>>> kfb-specific
>>>>>> /usr/share/man/man1m/fbconfig.1m Uncommitted
>>>>>> modified man page
>>>>>> /usr/share/man/man1m/fbconf-xorg.1m Uncommitted new
>>>>>> man page
>>>>>> /etc/X11/xorg.conf Uncommitted
>>>>>>
>>>>>>
>>>>>> Initial support will be for the XVR-2500 graphics accelerator
>>>>>> (kfb).
>>>>>>
>>>>>> This project does not grovide the DCMTool GUI support for Xorg.
>>>>>>
>>>>>> 6. Resources and Schedule
>>>>>> 6.4. Steering Committee requested information
>>>>>> 6.4.1. Consolidation C-team Name:
>>>>>> Graphics
>>>>>> 6.5. ARC review type: FastTrack
>>>>>> 6.6. ARC Exposure: open
>
