Custom Display Resolutions

From LinuxMCE
Jump to: navigation, search

If you have a display designed for use with a computer rather than as a regular TV, such as a plasma display, it is possible that the native resolution of the display is not one of the options presented by the AVWizard. In this case, with a small amount of tweaking it is possible to get the media director to drive the display at its native resolution, which will give you optimum picture quality.

Enable EDID

By default, LinuxMCE disables EDID - please see the EDID page for the details. However in this case you are probably better off re-enabling it. This should be done by editing /usr/pluto/templates/xorg.conf.in, which is the template from which the AVWizard automatically creates new Xorg configurations. You will find a line in this file like:

       Option "UseEDID"     "false"

Simply change false to true and save the file. Now we need to regenerate the Xorg config, but first we need to ensure that the right resolution is visible in the AVWizard.

Adding new resolutions to the A/V Wizard

The resolutions visible in the wizard are set in the file /usr/pluto/share/Resolutions.conf. The resolution you need may well already be in there, but with visibility disabled. For instance, 1360x768 is already in there, and only requires the visibility flag to be toggled to make it appear in the wizard.

If your required resolution is not in there, copy a block from one of the other resolutions and modify it accordingly.

Resolutions.conf

The Resolutions.conf file is parsed using the libconfuse library. libconfuse provides means of creating structured, yet simple, configuration files. This particular file is composed by entries like this:

resolution
{
        name = "640x480"                                                          #(1)
        width = 640                                                               #(2)
        height = 480                                                              #(2)
        aspect_ratio = "4:3"                                                      #(3)
        modeline                                                                  #(4)
        {
                refresh = 60                                                      #(4.1)
                builtin = true                                                    #(4.2)
                x11 = ""                                                          #(4.3)
                workaround                                                        #(4.4)
                {
                        driver = {"nvidia"}
                        x11 = "25.18 640 656 752 800 480 490 492 525"
                }
        }
        modeline
        {
                refresh = 75
                builtin = true
        }
        visible = true                                                            #(5)
}

(1) The "name" field

This field is used as the name of the resolution when it is displayed by the A/V Wizard, and when retrieving ModeLines with /usr/pluto/bin/X-GetModeline

(2) The "width" and "height" fields

These fields give the dimensions for the screen for the specified resolution. A resolution can have any name (even "WagaWaga" could be used, if meaningful to someone), and these values would then define the dimensions in pixels for that resolution.

(3) The "aspect_ratio" field

This field is for display purposes alone. It is displayed by the A/V Wizard next to the resolution name.

(4) The "modeline" section

This section is optional. It can be skipped. In that case, a modeline will be generated by xtiming.pl.

You can have multiple modeline sections in a resolution block.

  • (4.1) The "refresh" selector

If you include a modeline section, you must specify the "refresh" field. This field specifies to which refresh rate of the current resolution does the modeline apply.

  • (4.2) The "builtin" directive

When set to "true", this says that the X server has a built-in modeline for this resolution and refresh rate combination and no modeline should be generated

  • (4.3) The "x11" field

This field contains the modeline for this resolution and refresh rate combination, minus the modeline name, i.e. starting from the dot clock value.

If the mode is built-in, the x11 directive is ignored. If the mode is not built-in, and x11 is empty, then xtiming.pl is used to generate a modeline.

  • (4.4) The "workaround" sub-section

This section is optional. This section is used for cases when it is known that the general settings described in the section are buggy for certain display drivers.

If you include this section, you need to specify the "driver" selector. The "driver" selector is a list of the following form: {"driver1","driver2",...}

This subsection can have the "x11" and "builtin" fields, with the same meaning and syntax as described above.

(5) The "visible" directive

This directive is used by A/V Wizard to decide if to display the resolution in the resolutions box or not.

Caveat

Furthermore, unfortunately these resolutions are also hardcoded in /usr/pluto/bin/AVWizard-Common.sh - look for the line starting Resolutions_HDTV and add your custom resolution to the shell array. This is arguably a bug where the code does not gracefully handle resolutions which are listed in /usr/pluto/share/Resolutions.conf but not listed in /usr/pluto/bin/AVWizard-Common.sh.

Orbiter size

When you add a resolution, you may also want to add an Orbiter size to match it.

The Orbiter sizes are kept in the Size table. This is a good SQL statement to add a size:

INSERT INTO Size SET Description='Size Name', Width=Width, Height=Height, ScaleX=ScaleX*, ScaleY=ScaleY*, ScaleMenuBg='S', ScaleOtherGraphics='F';

I don't know what ScaleMenuBg and ScaleOtherGraphics mean, but except for the Nokia 770 size, all the other entries have them like that.

ScaleX and ScaleY

You can't set ScaleX and ScaleY just to any values. The end result depends greatly on these. If you get them wrong, the size of your Orbiter will be incorrect (and OrbiterGen will die if you set any of them to 0).

Here's how to compute the right values:

  • For 4:3 resolutions
ScaleX = int(Width / 2.84444444444)
ScaleY = int(Height / 1.6)
  • For 16:9 resolutions
ScaleX = int(Width / 2.13333333333)
ScaleY = int(Height / 1.6)

These formulas are using the value ratios determined from the existing sizes.

Another way is to use this size for reference: 2128x1596. This is the "base" resolution of UI1. The idea is that you want to scale this down to your resolution: XxY. In this case, the formulas are:

ScaleX = round(X/2128*1000)
ScaleY = round(Y/1596*1000)

UI2 seems to override these values in OrbiterGen.sh. A comment in OrbiterGen.cpp says: UI2 is always 16:9 and needs to be edge-to-edge, so we will ignore the normal scaling rules and always scale the full image

Fix me: Determine a general formula for general aspect ratios.

Run the A/V Wizard

Running the A/V Wizard will regenerate the correct Xorg configuration

Proceed through the wizard, selecting the resolution which you have just made appear, and make sure the display is happy with the setting. If not, switch to the tty1 virtual console via Control-Alt-F1, log in, and check the most recently modified Xorg logfile written by the wizard's test (this is probably /var/log/Xorg.1.log) to find out why it didn't work.

Prevent LinuxMCE from changing the Xorg config

This is a bit of an ugly hack, and if the above is done correctly I'm not sure if it's even needed. Nevertheless, if you want to get really creative and write your own xorg.conf, this is the way to protect it from being overwritten:

Edit /usr/pluto/bin/Xconfigure.sh and add the following lines immediately below the #!/bin/bash:

   echo "$0 neutered to preserve custom xorg.conf"
   exit 0


Diskless Media Director

Chroot into the MD and perform the steps mentioned above to add the custom resolution.

To chroot into the MD, first make sure it is turned off

From the web admin, determine the ID of the MD you wish to modify.

cd /usr/pluto/diskless/
sudo chroot <mediadirector-id>

Then perform the above steps.

  • This worked for me, if someone could verify and remove this remark -Pnuts