Intel i915GM with SDVO CH7021A support?

[Keith Packard]

On Mon, 2007-01-15 at 10:53 +0000, Will . wrote:
> >If you can publish a git repository with the relevant bits, we can pull
> >them into the driver. If not, you could post emails (using
> >git-format-email) containing the diffs which we could apply.
> 
> I'll try to sort out the most appropriate method, I'm away on business for 
> most of the week so hopefully at the weekend. I applied for an account to 
> push but perhaps that wasnt what I was meant to do!

Sure, that's not a problem; I do like to see a bit of code review before
you just start pushing directly to the repository; formatting style,
comment content, licensing stuff; I think it's nice to have a bit of
handholding at first.

> For the moment I set an encoder type ==...._TV_OUT, I'll set up a struct to 
> contain the tv properties and put this in the sdvo priv.

Cool.

> Sounds good, were you just commenting or can I take a look if I have time?

If you've got time, you're welcome to write any code you need. If you
have questions about how the hardware works, we can answer those as
well. I have a strong incentive to get more people involved in the
driver development...

> I have to admit I dont fully understand where you're comming from on that 
> one. Are you talking about TV aspect ratios? Can't quite remember the 
> relavance of square pixels

Yeah, analog TV has a notion of lines, but not really one of pixels, and
somehow the TV groups have decided that a 480p signal should be
represented with 720 pixels on a scanline, which leaves us with
non-square pixels. As many applications don't deal with non-square
pixels correctly (it's a significant burden on them), it's often better
to just represent the TV signal with 640 pixels on the scanline. Which
resolution you use depends on which applications you're using.

> Is what you're saying above that the tv output / format should be fixed i.e. 
> PAL / NTSC / 720p etc. and the chosen resolution should be scaled to the tv 
> format? (or have i miss understood)

Right, the TV encoder has a built-in scaler, so what resolutions we pick
is entirely up to the driver. Certainly we should offer the unscaled
resolutions so applications can get predictable output, but it's also
useful to be able to show the 'full screen' of the regular monitor,
scaling the TV output to fit.

> Ideally I'd still like to be able to dynamically adjust the tv format to 
> match the correct display resolution / refresh for video playback.

Sure, so we should advertise all of the formats that the TV encoder
supports in native form, and then selectively choose additional scaled
resolutions as we see fit. I can imagine we'll list a rathar large
number of modes.

> The collections could be brought up by name and turn on and off the correct 
> displays set appropriate output properties etc. It should then be possible 
> to create a mapping between video stream types and link them to the 
> appropriate collection above (the user can configure what they want)?

I think that kind of thing should be a client-side issue with the server
providing the mechanism alone.

-- 
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/20070116/69020a95/attachment.pgp>