xserver: Branch 'master' - 2 commits

[Luc Verhaegen]

On Tue, Oct 16, 2007 at 08:43:51PM -0700, Keith Packard wrote:

> commit feac0759522cbdc3e61ccfa373df735903c5cb27
> Author: Keith Packard <keithp at koto.keithp.com>
> Date:   Wed Oct 17 11:42:28 2007 +0800
> 
>     Make config file preferred mode override monitor preferred mode.
>     
>     Add a new even-more-preferred bit to each mode which is used to make config
>     file preferences selected instead of the monitor preferred mode.
> 
> diff --git a/hw/xfree86/common/xf86str.h b/hw/xfree86/common/xf86str.h
> index 0365ddd..af98b4f 100644
> --- a/hw/xfree86/common/xf86str.h
> +++ b/hw/xfree86/common/xf86str.h
> @@ -142,6 +142,7 @@ typedef enum {
>  # define M_T_DEFAULT 0x10	/* (VESA) default modes */
>  # define M_T_USERDEF 0x20	/* One of the modes from the config file */
>  # define M_T_DRIVER  0x40	/* Supplied by the driver (EDID, etc) */
> +# define M_T_USERPREF 0x80	/* mode preferred by the user config */

Is there any reason why you chose this solution, instead of the more 
logical one that requires no additional mode typing?

This is the "original" structure of the mode types (post bug 5386 era):
# define M_T_PREFERRED 0x08     /* preferred mode within a set */
# define M_T_DEFAULT 0x10       /* (VESA) default modes */
# define M_T_USERDEF 0x20       /* One of the modes from the config file */
# define M_T_DRIVER  0x40       /* Supplied by the driver (EDID, etc) */

The higher nibble should be the first ordering mechanism:
M_T_USERDEF > M_T_DRIVER > M_T_DEFAULT.

Within each, you could have a preferred mode, by also specifying 
M_T_PREFERRED in the lower nibble. This one, when present, should get 
precedence in each of the higher nibble orderings.

Preferred modes within DM_T_DEFAULT are quite pointless.
Preferred modes witin M_T_DRIVER are EDID preferred modes, native 
resolutions of laptop panels or unscaled tv modes for the chosen 
TV standard.
Preferred modes in M_T_USERDEF are user provided preferred modes.

If the higher nibble ordering is used appropriately, then user provided 
preferred modes are already handled correctly, and we then do not need 
M_T_USERPREF as this should be fully and appropriately handled by:
(M_T_USERDEF | M_T_PREFERRED)

If M_T_USERDEF wasn't already locked at 0x20, before we defined 
M_T_DRIVER, then all of this would've even made numerical sense.

Luc Verhaegen.
SUSE/Novell X Driver Developer.