-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Jan 5, 2007, at 08:20, Jachym Holecek wrote:

> Please go ahead :-).

Yay, that's 100% positive feedback so far ;)

> Hopefully, this could give us a sane way to read wsfb parameters 
> (instead of current ad-hoc ioctl mess) as a side effect?

Not really related - what I want to change is the way wsdisplay drivers 
get parameters etc. from the kernel to avoid having machine- or at 
least architecture-dependent firmware calls in otherwisely 
machine-independent drivers. This has no influence on ioctl()s at all.

> (BTW I think we should prefix wsfb property names with "fb-" or 
> something
> to be future-safe when new (classes of) properties get invented)

Good point, on the other hand proplib has sub-dictionaries.

Another thing - some firmware provides EDID data even on chipsets where 
we can't easily obtain them ourselves ( mach64 for instance - each 
variety has its own way to talk to the i2c bus, some don't support it 
at all ) or - as some macs do - provides EDID data only as a firmware 
property, not via DDC at all.

So I hereby amend my proposal:
- - wsdisplay drivers shall look for an EDID property containing monitor 
identification data and use those if present. Only if there is no valid 
EDID property drivers are allowed to try to obtain these data via DDC.

have fun
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBRZ8fz8pnzkX8Yg2nAQLxLggAh+9TC8xGzpKSL+LzNcWh9Ow6mUQiP/jw
wpUIvagvMwEqnpctBXWI6wbPbsJRmKuvGu9oKB7ocLjZs5BoFIJU/Y5YoSF3+/+L
OYNTvI9gPwkZhb8FdQwDC3pQBN5kXxs7iR7lFPjrvVUH2AhKp+3V+YQSt9jq2rvE
NszHNA0nZTrEy1hFGGx+KKM5zWCfBctKEvVygsScfKfYxZ80V0WxQ6fE9TrdBWP9
Nq+3QbV7m527LoiLVIbFyTroWMUfskArB1GBZW73Q7UUAZqmEkdZ2XPDRk0AQnPq
cwjCbMO+XrLYgnkap6CplqE0iNJ4zAnJliGosv//S/QBCpLgzJ6nXA==
=RJ6G
-----END PGP SIGNATURE-----