Re: [Unichrome] (EE) VIA(0): No outputs possible.

[Luc Verhaegen. <li...@sk...>]

On Thu, Aug 10, 2006 at 02:04:19PM +0100, Barry Scott wrote:
> The reason I turn off DDC/EDID is so that my users get the screen resolution
> that matches the media they have designed. For example an NEC plasma will
> report 1024x768 via EDID buts its wide screen so people design in 1280x768
> and let the plasma scale.

So it never mentions 1280x768 in the EDID, but it does downscale itself?

I think at some future point in X modesetting that might cause problems 
requiring special workarounds.

> What I really want is to have my daemon be in the loop as a policy object.
> I want to be given the data on the outputs and screens and then to apply my
> policy to choose what is used and how it is used.

Yup, we're definitely on the same page here. The most direct use of an 
attribute system would be a hardware specific gui which exposes the most 
minute details. Then there should be an X utility for the general stuff, 
then gnome and kde config supporting the general stuff. There should be 
nothing stopping other applications (except security) from controlling 
what's happening with regard to modesetting.

My (relatively) short term intention is to release a console client 
which exposes the full structure of unichrome modesetting. It will not 
be intuitive to use for the novice (well, my guess is that i'll be the 
only person who knows his way around it initially), but it will allow 
complete and full control solely depending on what the driver exposes 
(which is why it'll not be too intuitive).

The big problem is the still unresolved issues with CLE266 based panel 
and the CH7019 LVDS encoder on the Acer aspire 135x. They still are the 
nasty blind spots in my otherwise highly structured modesetting.

Luckily my work on VT3108 panel has given me some insights that allowed 
me to strip down the panel code (dropped 200+kB - notice how compiling 
via_panel.o now zips by). I am very afraid though that I will have 
broken pre-VT3108 support, but at least now it should be easier to fix.

> What I plan to do in the short term is run up X once allowing DDC/EDID to
> be probed and reported in the X log file. Then kill off X and start up again
> having applied a policy to the DDC/EDID info.

Sounds like just as much work as doing it properly from the get-go. The 
most rudimentary controls can be implemented rather quickly.

The real trouble here is that Keith Packard doesn't believe in a general 
attribute system, he prefers to continuously extend randr. I think this 
is due to the different angles the problem is approached. I'm a driver 
developer and i think from the driver up; i want to expose as much of 
the hardware as sanely possible. I believe Keith only wants to expose 
that functionality that is useful to him at a given time.

For the user, in the short term, it means that you'll end up with 2 
different systems for both this driver and the intel one.

> BTW do you know of any standalone program that can do the DDC/EDID
> query without running up X?

There's that utility that uses VBE calls, read-edid, but other than 
that, no, not really. You need to control the I2C bus to the CRT to be 
able to read EDID. And that's in the X driver.

Luc Verhaegen.