Adding encoder/transmitter support (to via or stand-alone)
philipp_subx at redfish-solutions.com
Mon Apr 16 11:06:38 PDT 2007
Philip Prindeville wrote:
> Keith Packard wrote:
>> On Mon, 2007-04-09 at 21:32 -0600, Philip Prindeville wrote:
>>> I grabbed:
>> The 2.0 RC candidates are completely different and the DVO drivers are
>> designed to be stand alone in that environment. Please fetch from git,
>> or use the rawhide bits.
> Ok, got the master branch from git...
> A couple of stupid questions:
Some of which I think I was able to figure out myself..
> * why do the guts of sil164_mode_set() not do anything?
Because it assumes (perhaps naively, since there are a lot
of broken BIOSes out there ;-) that BIOS sets it up
and then it doesn't change from there... though admittedly,
there's not that much that would need to change on the fly...
MSEL might be something that the caller would want to specify.
> * and what should sil164_mode_valid() be doing (optimally)?
It could probably make the same test the ch7xxx/ driver
code does... > 165000 ...
> * how do you know if the hardware can handle 24-bit or full-pixel
> per cycle mode (instead of half-pixels)?
> * how is the interrupt on HOTPLUG handled by the GPU code?
> * why set the I2C address as 0x38<<1 (SIL164_ADDR_1<<1) instead
> of just 0x70?
Because the low-bit isn't really an address bit, it's a
R/W mode selector... so 0x38 << 1 is 0x70...
BTW: since the address is vendor specified, I'm
thinking that maybe the caller doesn't need to specify
an address at all, just let if default... unless it needs to
> * and should be I2C address reside in _I830DVODriver, or in
> I830I2CVidOutputRec or SIL164Rec? It seems to be chip-specific,
> not board-specific...
> * what are the chances of _I830DVODriver becoming _Xf86DVODriver
> * ditto for I830I2CVidOutputRec...
Oh, and lastly, where's the configure.ac file for the root
of the intel driver?
More information about the xorg