xf86-video-intel, modesetting branch

[Keith Packard]

On Sun, 2007-01-28 at 18:30 +0100, Krzysztof Halasa wrote:
> Keith Packard <keithp at keithp.com> writes:
> 
> >>         DefaultDepth    24
> >>         SubSection "Display"
> >>                 Viewport        0 0
> >>                 Virtual         1600 1200
> >>                 Depth           24
> >>                 Modes          "640x480" "800x600" "1024x768"
> >
> > Having a Modes entry here shouldn't have any effect; the only way to
> > affect which mode is used by default is to set the preferred mode option
> > in the monitor section.
> 
> Right. The problem is, I want only few modes, or even just one.

You can specify the preferred mode which will be used when the server
starts; I'm not sure what use eliminating other valid modes from the
list provided by RandR would serve.

> There are (usually) two CRT controllers (PIPEs). Each can be connected
> to any number of output devices such as analog VGA, digital DVI etc.
> But a video mode is a function of CRTC, not output device, isn't it?
> If I set 800x600 60Hz for VGA connected to PIPEA, SDVO connected to
> the same PIPEA will get the same 800x600 60 Hz.

Using the same CRTC to control multiple outputs is a fairly limited
case; in the intel hardware, you can only driver very similar outputs
from the same CRTC (SDVO + SDVO, and in some limited cases SDVO + VGA).
Other combinations are not possible, so in the bulk of the cases, you
really do drive each output with a separate CRTC.

> So I think we should have one list of video modes per pipe, not per
> output device.

Outputs present a list of supported modes; the job of selecting suitable
CRTCs to light up all of the requested outputs with the desired mode is
something the server automates so you don't have to figure out which
CRTC should be connected to each output.

As you change output configurations around, the xrandr client takes over
the job of selecting a suitable configuration of CRTCs given the desired
output mode combination. This reduces the need for the user to deal with
the hidden CRTC objects and lets them focus solely on the relationship
between the physical monitors they are using.

> Now, how do we generate the list?
> - The user could specify ModeLines in "main" monitor section
>   (the one specified in "Screen" section). The HSync and VSync values
>   would apply as well.

I don't understand how this global list should be applied though; it
surely shouldn't apply to all outputs as they rarely support the same
set of modes. It could apply to one output, but I don't know which one. 

> - Second, the "default" mode list would be used.

Right, pruned to match the frequencies reported by the output device,
which is effectively the same as output-specified modes.

> - Then, every output device could add its modes.

Through either EDID or the configuration file.

> That means pScrn->Modes would be the master list and no other mode
> list would exist after initialization.

As each output needs a separate list, we cannot just use a single global
list of modes.

Again, it is a rare configuration which can actually use the same CRTC
for two outputs. The set of outputs which prefer identical modes is
similarly limited, in most cases it only happens when you have two
identical monitors.

> - we wouldn't need monitor section for every output device

We would still need a mode list for every output device, the only
question is how to populate that from the config file. I can accept that
we need to figure out what to do with the existing monitor section, but
if you look at existing driver support for multiple monitors, they are
generally reduced to implementing a subset of the monitor configuration
for the secondary CRTC (CRT2HSync/CRT2VRefresh in the radeon driver).
Reusing the existing Monitor syntax and semantics seems far easier than
that to me. The monitor sections also provide a place for additional
per-output options, like placement and custom modes which are not
currently available in the driver-specific options.

> - less complicated code

Again, the only question I have is what to do with the existing monitor
section; I think the remaining data is better provided with per-output
monitor sections than the current mish-mash of random driver options.

> - I think this mode of operation is common to all dual+ head adapters
>   (including "clone mode" etc) and it should probably be moved outside
>   of the driver.

That's certainly the case; our intention all along has been to push all
of this code to the common layer and share it among all drivers so that
configuration can be common for these new cases. We've got most of the
code logically partitioned. The work remaining is to figure out how to
share it among multiple drivers will still allowing it to be linked
directly to individual drivers for older servers.

> Now the interlaced mode...
> It looks (please don't apply yet) the following does the trick, more
> or less. I'm using ModeLine "PAL" 28.16 1440 1482 1614 1802
> 576 580 600 625 -hsync -vsync interlace which gives 25.0033 Hz (full
> frame) and there are no field parity errors (though the player doesn't
> seem to sync frames to Vsync). It seems it sends bottom field first.
> 
> I wonder what other bits in PIPECONF do?
> bits
> 31 PIPE[AB]CONF_ENABLE
> 30 PIPE[AB]CONF_DOUBLE_WIDE
> 25 PIPECONF_FORCE_BORDER (PIPEACONF_PIPE_LOCKED?)
> 24 PIPE[AB]CONF_GAMMA
> 23-21 0 = PIPECONF_PROGRESSIVE
        1-3 = Undefined
        4 = Interlaced LVDS using vertical sync shift
        5 = Interlaced using vertical sync shift
>       6 = PIPECONF_INTERLACE_W_FIELD_INDICATION
>       7 = PIPECONF_INTERLACE_FIELD_0_ONLY
> What 1-5 values do? Perhaps it could do top field first as well?

As far as I understand, NTSC specifies that the bottom field is first.

> +++ b/src/i830_display.c
> @@ -809,6 +809,13 @@ i830_crtc_mode_set(xf86CrtcPtr crtc, DisplayModePtr mode,
>      /* Wait for the clocks to stabilize. */
>      usleep(150);
>  
> +    if (adjusted_mode->Flags & V_INTERLACE)
> +       pipeconf |= PIPECONF_INTERLACE_W_FIELD_INDICATION;
> +    else
> +       pipeconf &= ~PIPECONF_INTERLACE_W_FIELD_INDICATION;
> +
>      OUTREG(htot_reg, (adjusted_mode->CrtcHDisplay - 1) |
>         ((adjusted_mode->CrtcHTotal - 1) << 16));
>      OUTREG(hblank_reg, (adjusted_mode->CrtcHBlankStart - 1) |
> +++ b/src/i830_xf86Modes.c
> @@ -125,7 +125,7 @@ xf86SetModeCrtc(DisplayModePtr p, int adjustFlags)
>      p->CrtcVSyncEnd             = p->VSyncEnd;
>      p->CrtcVTotal               = p->VTotal;
>      if (p->Flags & V_INTERLACE) {
> -       if (adjustFlags & INTERLACE_HALVE_V) {
> +       if (adjustFlags & INTERLACE_HALVE_V & 0 /* FIXME */) {
>             p->CrtcVDisplay         /= 2;
>             p->CrtcVSyncStart       /= 2;
>             p->CrtcVSyncEnd         /= 2;
> @@ -507,6 +507,7 @@ i830xf86PruneInvalidModes(ScrnInfoPtr pScrn, DisplayModePtr 
> *modeList,
>  {
>      DisplayModePtr mode;
>  
> +    i830xf86ValidateModesUserConfig(pScrn, *modeList);
>      for (mode = *modeList; mode != NULL;) {
>         DisplayModePtr next = mode->next, first = *modeList;

Does this work in interlaced mode now? I haven't tried any interlaced
modes, having little interest in them myself.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20070128/9bc33132/attachment.pgp>