Will be able to choose the init system we prefer to use?

Do you have anything odd in your boot lines?

Not that I'm aware of.

Can you try doing the whole sequence with a different monitor attached?

Tried that already when I used the Live USB with my old computer and installed nvidia-xconfig which produced the same results as on the target PC even though a different graphics card was being used.

Those are the only things left that I can think of if 3.2.0-4 kernel, nvidia drivers, and nvidia-xconfig don't solve it.

The monitor and graphical rendering are functioning fine with the Option "metamodes" line and the HorizSync and VertRefresh I have specified in the xorg.conf file.

If you have space on the drive, crunchbang 11 or antix 13.2 and debian wheezy all have worked for me doing it that way.  Antix is a quick install.

I have antiX 14R Alpha 2 on a Live USB. Should installing nvidia-xconfig on it produce the results you are anticipating?

Hi All,

So, having solved the driver configuration issues for the LCD monitor (BenQ GW2265) using the VGA connection, it was time to turn my attention to the CRT monitor (LG Flatron ez T530S) using the same connection.

The EDID data for the T530S reported 2 Modes (1024x768 and 800x600) whereas only 1 was reported for the GW2265 (1920x1080).

Starting with the xorg.conf file for the GW2265 as a template, I replaced the 1 ModeLine parameter line with 2 ModeLine parameter lines with what was acquired from the EDID data for the T530S.

I placed the 800x600 resolution first because that has the highest Vertical Refresh Rate (85 as opposed to 60 for the 1024x768 resolution). I thought this would allow a person to easily switch between the 2 resolutions.

However, as far as I have been able to ascertain, by having 2 resolutions specified in the xorg.conf file the NVIDIA driver automatically creates a Virtual environment with its Size set to the largest of the specified resolutions.

It "threw me for a six" for a while before I properly determined what was going on but what this does is allow a certain resolution to be used for setting the DPI and, then, within the window of that resolution you can Pan (up and down and left to right) the larger Virtual environment by moving the Mouse Pointer to the edges of the screen.

I don't see a lot of benefit in this, except to provide an easier way to scroll within a certain area if you are working on a large spreadsheet or some other document, because it applies to all windows and means that extra moves of the mouse are required to bring interface features (e.g. Title Bar, Close button) into view before you can use them. When you open a window and then maximise it the window resizes to the size of the resolution of the Virtual environment and not to the size of the screen. So, then, part of the window becomes invisible to the right and the bottom of the screen and in order to see it you have to move the mouse pointer to the corresponding edge of the screen. If you move the mouse pointer to the bottom edge to see that "hidden" part of the window then you have to move the mouse pointer to the top edge of the screen to be able to interact with menus etc.

Well, whilst composing the above, it gave me some more time to think about it. Maybe it's just a matter of adaptation or preference.

However, it probably requires more memory to facilitate such a feature which is something you may be wanting to avoid on a computer with low memory resources.

So, after more testing and analysis, I have decided that the xorg.conf file (for the NVIDIA driver) should only have the 1 resolution specified and for a CRT monitor it's usually best to use the highest frequency with the highest resolution that can use that frequency. For the T530S that is 800x600 @ 85Hz. Afterwards, you adjust the monitor's Size and Position settings via its OSD (On Screen Display) menus. To use any other resolution would require changes to the OSD configuration which would be a tiresome effort if for any reason someone needed to change the resolution on a frequent basis.

To do this the Screen Section should have an Option "metamodes" line with ony 1 resolution as follows.

Option "metamodes" "800x600_85"

If, however, a person did want to change the resolution and save that setting in the xorg.conf file via the NVIDIA X Server Settings GUI (graphical user interface), they could inadvertently experience the same problems with a virtual environment as I did because this application, by my reckoning and experience, is not consistent with how it saves a Configuration to the xorg.conf file. Checking and unchecking the checkbox (Merge with existing file.) appears to have inconsistent  effects. If you selected a different frequency for the current resolution, an additional entry was added for that frequency for the current resolution. So, now you have 2 entries and if you change the resolution to something else only the first of those entries will be replaced or maybe the new entry will be added to the front of them. When X is next started, the NVIDIA driver sees the 2 or more entries and uses the one with the highest resolution to create and set the size for a Virtual screen environment. I haven't been able to find a way to turn that off.

The entries that are created, via the GUI, use the Option "metamodes" syntax. When there are Option "metamodes" lines in the Screen Section, the NVIDIA driver appears to ignore ModeLine lines in the Montior Section. Therefore it would appear of no use to have any ModeLine lines in the configuration file at least for a CRT monitor as far as I can tell.

The only sane way to save a new configuration via the GUI, it appears, is to not use the Merge checkbox and to use the Preview pane to make sure that you only have 1 entry for the Option "metamodes" line.

What a shambles!

Hasta luego, Michael.

Well, I started thinking about revising my options for this old PC I've been working on part-time for months now and I took a closer look at GALPon (based in Pontevedra, Galicia - north-west corner of Spain which I personally know is a rather pretty part of the planet) and discovered their MiniNo Ártabros 2.1 Full distro.

I saw some forum topics about installing nvidia drivers and decided to download it and discovered that it was using the linux-image-3.2.0-4-686-pae kernel which caught my attention as my attempt to install the nvidia-glx-legacy-96xx package on wattOS indicated that it was looking for a 3.2.0-4 version of the kernel.

So, I proceeded to install the nvidia-detect, nvidia-glx-legacy-96xx and nvidia-xconfig packages.

Everything appeared to install successfully and so I executed nvidia-xconfig and reboot the PC.

You can see the outcome of that in the topic Problema con la Instalación del Controlador NVIDIA (http://minino.galpon.org/es/node/439) I posted on the MiniNo forum.

After re-reading, more closely, the terminal output for the installation of the nvidia-glx-legacy-96xx package, I did some research regarding "Module build for the currently running kernel was skipped since the kernel source for this kernel does not seem to be installed." which indicated that the Linux-Headers needed installing which I had thought should have been automatic.

Why are these linux-headers-* packages not flagged as a dependency for packages such as nvidia-kernel-legacy-96xx-dkms? Is there some logical reason for this?

It was then that I recalled the instructions offered by ausmuso and what I had seen on the Debian Wiki (https://wiki.debian.org/NvidiaGraphicsDrivers).

However, for documentation purposes for inexperienced computer users, I wanted to achieve everything via Synaptic.

With some searching, about the removal of NVIDIA driver packages, I used the following command in Terminal.

aptitude purge nvidia-kernel-legacy-96xx-dkms nvidia-glx-legacy-96xx

Using Synaptic, I marked the package "linux-headers-686-pae" for installation. This also marked the required dependencies (linux-headers-3.2.0-4-686-pae, linux-kbuild-3.2, linux-headers-3.2.0-4-common, gcc-4.6, cpp-4.6 and gcc-4.6-base) for installation. Then I clicked the Apply button to activate the installation.

Next, I marked the package nvidia-glx-legacy-96xx and activated its installation.

I executed nvidia-xconfig from the command line again and rebooted.

Success

However, I noticed the screen flickering (it was also happening with the nouveau driver but I wasn't paying attention) which involved more analysis and testing to resolve what appears to be possibly a common problem at least across all the configurations of monitors, graphics cards and computers I have at my disposal.  With the default wallpaper enabled there is a lot of flickering of the screen. I can see this via the following page in my browser also.

minino-wallpaper-2_1280x1024

Try downloading it and using it as a wallpaper and let me know whether you see the same flickering effect and perhaps explain why it is happening with this particular image.

At first, I didn't notice that the flickering was associated with the wallpaper. I looked at the Monitor Settings applet which was displaying a Refresh Rate of 50.0 and the only other options were auto and 51.0. So, that didn't seem correct.

Also, the nvidia-settings GUI was reporting the Monitor as being a CRT type which was strange given that it is an LCD monitor.

Along the way I discovered various command line tools such as cvt, gtf, xresprobe, ddcprobe, i2c Tools, read-edid and parse-edid.

On the target PC, xresprobe reported a Segmentation Fault with id, res and freq as blank and disptype as crt and ddcprobe reported a Segmentation Fault and nothing more.

With the GUI for nvidia-settings, it appeared I could extract the EDID data but opening the file with Leafpad did not produce anything I could read.

So, with more searching for solutions and my Laptop (Manjaro 0.8.10 XFCE with Intel HD4000 Graphics and VGA and HDMI ports) and Old Desktop (using MiniNo Ártabros on the Live USB with a Graphics Card using a GeForce 6200 GPU and VGA and DVI ports), I peformed various combinations of testing connections which allowed me to properly determine the values for the HorizSync, VertRefresh and Modeline parameters by reading the Xorg.o.log files. It was during this phase of analysis and testing that I discovered read-edid and, hence, parse-edid which enabled me to read the EDID data I had previously acquired and confirm what I had seen by using my old desktop PC.

So, nvidia-settings could extract the correct data for the monitor but nvidia-xconfig couldn't. nvidia-xconfig created and configured the xorg.conf file with values for the HorizSync and VertRefresh parameters that did not match those reported by nouveau, ddcprobe (on my old PC) and nvidia-settings (via the Acquire EDID button that appears for the monitor entry under the GPU entry in the left pane of the interface) on the target PC.

ddcprobe appears to not fully function for non-VGA connections. When I tried it on my old PC using the DVI connection it failed when trying to read the EDID data. Using the VGA connection it reported the same values I had seen in the Xorg.o.log file for the nouveau driver.

With the nouveau driver, Monitor Settings, reports 60.0 as the refresh rate.

In the nvidia-settings GUI, the refresh rate is reported as 60.0.

Also, discovered the following this morning.

http://forums.linuxmint.com/viewtopic.php?f=59&t=91923&p=528528#p528059
https://bbs.archlinux.org/viewtopic.php?pid=853138#p853138

So, the Monitor Settings (lxrandr) applet is not able to correctly report the Refresh Rate being used when the NVIDIA driver is being used because the NVIDIA driver does not report the real refresh rates to xrandr.

If I run xrandr from the command line, it also reports 50.0 and 51.0 for the 1920 * 1080 resolution.

Using nvidia-settings -nt -q RefreshRate reported a Refresh Rate of 60.

The NVIDIA driver appears to function properly whether either the HorizSync and VertRefresh or the Modeline parameters are used. If a Modeline parameter is not used the nvidia-settings GUI reports the Resolution to be auto and defaults to the native resolution. I'm going to use the Modeline parameter for the native resolution fior the LCD monitor because instinct says it's possibly more efficient.

So, after all this, I can report that with the NVIDIA Driver the Graphics are properly rendered without having to scroll panes or move the mouse over a checkbox, for example, as with the nouveau driver.

I also tried configuring a Live USB with Persistence with the NVIDIA driver but, yes, it appears that Debian based Live ISOs use their own Xorg configuration file (in etc/X11/xorg.conf.d) which appears to be created when the Live environment is booted. So, hopefully a Remaster will solve that issue. Can ayone advise otherwise or as to which file(s) would need to be modified to permit this?

Even though the monitor I have been using with the target PC is mine, and not the one that will be used by the people concerened, it was important to go through this process in case they want to upgrade from the old 15" CRT sometime in the future when they can afford it.

For the CRT monitor, I am guessing that I will be creating multiple Modeline parameters for the Monitor section for the xorg.conf file.

As xrandr is not compatible with the NVIDIA driver, I will "hide" those applications from the Menu.

It will be interesting to see what happens now when I connect the CRT monitor. Fingers crossed

So, MiniNo Ártabros 2.1 is as fast as, or a little faster than, wattOS and somewhat leaner in memory usage. It gets to the desktop with less than 60MB used -  .

It comes with applets for the managment of Language and Keyboard layout. 

There is no Update Manager in the default installation but its available in the Repositories. Does anyone know how Update Manager categorises packages as a Security Update? I can't see anything in Synaptic that allows such filtering.

Midori crashed the first time I was using it. So, I'll probably replace that with Qupzilla if I can't install Pale Moon for Linux.

One disappointment, however, is that the translations are not complete, with it neither, which means I still have some work to do in that regard. You would think a distro produced in the Iberian Peninsula could at least get that right - come on! 

Most of them appear to be fully translated but there are some with a few missing translations and there is one that is missing most of the translations.

Installation is a bit different and I will reinstall for documentation purposes once I've gotten the translations completed as much as is possible in preparation for the second post-installation configuration. Unless there is something I missed configuring when I first used the Live environment, the installation interface is only in English. I will communicate with the people at GALPon about this.

One of the installation differences is that it doesn't include the configuration of a User. It uses the same User account as the Live environment. However, there is an applet for the management of Users and Groups including an option to specify that a Password is required when initiating a Session.

I had looked at antiX 14R Alpha 2. It's fast and light on resources too but not as User Friendly I feel but there are some applications, like CENI for example, that I am interested in exploring.

Well, I think that covers it for now. Hopefully someone else will benefit from this saga.

Thanks for the input guys!

Hasta pronto, Michael.

With wattOS R8 LXDE 32-bit, the Installation interface was not presented in Spanish even though Spanish (Peru) was selected for the installation.

Also, there is no Spanish .mo file in /boot/grub/locale which is rather incomprehensible given that Spanish is the second most common language.

Pale Moon for Linux Browser

Multi-Pane File Manager with better Archive Manager integration (e.g. Xarchiver wouldn't include .img files in an Archive)

An Archive Manager that includes a pane for viewing Folders in a Treeview. This feature does not function in the version of file-roller that can be installed in LXDE R8.

Is there any chance that an Update Manager (properly translated of course) similar to that in Mint could be included?