Its a pretty big step to even have SPARC Xorg drivers. Its taken a very long time to get even this far. Patience! In order to pursue consistency, the SPARC graphics engineers need to engage with the Xorg community and start sharing ideas.
Garrett D'Amore wrote: > Thanks for the explanation. It would be nice if we had some kind of > consistency across platforms for these kinds of settings (the ones not > related to resolution), though. I'm not asking for a change to this > case, just wishful thinking, I guess. > > -- Garrett > > Eric Sultan wrote: >> This project is delivering into SPARC because it's those users that >> have been using fbconfig to specify device configuration and so it's >> those users for whom a seamless migration path will be useful. >> >> There's nothing in fbconfig that precludes its use for x86 systems, >> but x86 has not previously used fbconfig. >> >> In an Xorg environment, fbconfig is not expected to be used as much >> for managing display device resolutions as is currently done in an >> Xsun environment. In Xorg, it is expected that auotconfigure will >> manage most display resolution requirements. >> >> The fbconfig utility will be as useful in Xorg as in Xsun for >> specifying configuration parameters that autoconfigure cannot >> manage. Autoconfigure won't, for example, how to manage doublewide, >> stereo, multisampling and its parameters, gamma override or gamma >> tables, and so forth. >> >> There will be instances in which users will want to use a different >> resolution than autoconfigure will set up. At this point, I'm enough >> of an Xorg newbie to know whether or not non-fbconfig means exist to >> handle those cases. >> >> -- Eric >> >> >> >> Garrett D'Amore wrote: >>> 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 >>>> >>> >> >
