Intel i915GM with SDVO CH7021A support?

Eric Anholt eric at anholt.net
Wed Jan 3 15:12:14 PST 2007


On Wed, 2007-01-03 at 22:56 +0000, Will . wrote:
> >Yeah, doing it in the modesetting branch should be much more satisfying.
> >
> >Also, in the future, diff -u is greatly preferred to traditional context
> >diffs.
> 
> Thanks for the tip, I'm a relative newb to linux so I find I'm often at a 
> loss to know what the correct way to do things is etc. Guess I was quite 
> excited to be able to post something too :)
> 
> I did try and cut the diff down a bit so it didn't contain so much 
> superfluous code, but there is still plenty in there which can probably be 
> thrown out.
> 
> I'm happy to try to move the code to the modesetting branch at some point. 
> Would you have the time to look at merging/committing the code at some point 
> if I did this?

Yeah, if you can bring your stuff over to current modesetting code, I'll
do my best to get it merged.

> Am I free to do this any way I like, e.g. how to implement the overscan, 
> contrast, width settings, how well does it need to work to be useful, how to 
> support multiple outputs, etc etc  It'd be quite nice to present some of 
> these features in a way that's adjustable within X, but perhaps that isn't 
> appropriate?

Our plan for implementing all these crazy options that TV allows has
been to have them be set as output properties through RandR 1.2.  We
still haven't hooked up some necessary code for that, though.  For the
first cut, I'd love to see it just turn the output on to some reasonable
default.

> Presumably it has to be presented in a way which will not affect any 
> existing functionality?

You should be able to work entirely within i830_sdvo.c, I think, which
should help ensure that you won't have side-effects on other code.

> I'd like to contribute something but I don't know what model to follow, also 
> I do still want support for the features I'm after myself. Perhaps I can get 
> listed as a contributor if I do a good job :)

One of the nice features of git for revision control is that even people
without upstream commit ability get their names forever in the history
for the patches they create.  So git-annotate shows who did the work,
for example.

-- 
Eric Anholt                             anholt at FreeBSD.org
eric at anholt.net                         eric.anholt at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20070103/c69ae54b/attachment.pgp>


More information about the xorg mailing list