I recently took delivery of a new Lenovo T420 laptop for my new job at Nexenta.
The plan was/is to run a variant of Solaris/Illumos on the machine and having worked at Sun Microsystems for 12 years, I knew it would be good to get something with an NVIDIA chipset to drive the Xorg server (having suffered awful and frequent crashes with the Intel i915 driver).
I tried the current (151a) build of OpenIndiana and it refused to install, so back to Solaris 11 and this installed fairly comfortably – except that after installation X came up in the cruddy old vesa mode and seemed to be using the xorg.conf.vesa file.
I knew this because when I grepped for Xorg I could see a -config xorg.conf.vesa file being passed in as an argument, which made sense when the installer was running but now? Can I have something a bit more modern please?
Various documentation suggested all I needed to do was to run nvidia-xconfig
and it would generate me a file in /etc/X11 as xorg.conf, so I did, it did and then I restarted Xorg only to find it was still wanting the vesa config file. Right, time to roll up the sleeves!
Using ptree I noticed that gdm-binary called gdm-simple-slave which in turn called Xorg with the following arguments:
/usr/bin/Xorg :0 -nolisten tcp -config xorg.conf.vesa ...
Why was it not picking up the blasted /etc/X11/xorg.conf file and defaulting to the vesa version? More importantly where was this set so I could change it? The start method for svc:/application/graphical-login/gdm:default might give me an idea:
# svcprop -p start/exec svc:/application/graphical-login/gdm /lib/svc/method/svc-gdm\ start
Looking at the start method showed a variety of properties under gdm/args such as –fatal-warnings but these were gdm specific and not for Xorg.
Back to Google and I eventually found the following PSARC 2010/161 http://arc.opensolaris.org/caselog/PSARC/2010/161/mail
This PSARC seemed to have the answer right there in front of me:
1) Xorg -config xorg.conf.vesa When Xorg is called directly, using the command line flag "-config xorg.conf.vesa" will cause it to start with the VESA driver. 2) svc:/application/x11/x11-server property options/config_file When the SMF property options/config_file is set to a string value, that string will be passed as the -config argument to the X server when started via one of the mechanisms that uses the /usr/bin/X or /usr/bin/Xserver commands to start the X server with the options specified in SMF. This allows passing this option when the X server is started indirectly, such as via the gdm display manager.
However I could not find an x11/server SMF service, even though there’s an x11-server.xml manifest in /lib/svc/manifest/application/x11 and even more annoying the damned thing won’t import, giving me a message along the lines of having to restart svc:/system/manifest-import.
Eventually I went old school to track this down by running a strings on the SMF repository database to find that config_file was being set from a site profile in /etc/svc/profile/site which had a file called x11_vesa.xml which looked like:
<?xml version='1.0'?> <!DOCTYPE service_bundle SYSTEM '/usr/share/lib/xml/dtd/service_bundle.dtd.1'> <!-- Service profile generated by installer to configure X to use the VESA driver --> <service_bundle type='profile' name='x11_vesa' xmlns:xi='http://www.w3.org/2003/XInclude' > <service name='application/x11/x11-server' version='1' type='service'> <property_group name="options" type="application"> <propval name="config_file" type="astring" value="xorg.conf.vesa"/> </property_group> </service> </service_bundle>
Eureka! I’d found it!
One swift move of this file to a safe location and a restart of Xorg later, the system picked up the NVIDIA driver for Xorg via gdm and I could start to play with different resolutions and even setting up a dual head configuration.
jasonbanham 