From: Hartmut Niemann <niemann@cip.e-technik.uni-erlangen.de>
  To  : ggi-develop@eskimo.com
  Date: Thu, 9 Jul 1998 13:58:30 +0200 (MESZ)

Re: set_mode complexity

The more I think about the timing negotiation, the more I find it
interesting.

First thing: I am sure that all driver types can be folded into
one driver that
- supports multisync ranges as the current multisync driver
- supports several of them.
So Monosync is a multisync with very small ranges,
timelist is several small sync ranges.

Then:
It would be enouigh if the kernel part ONLY CHECKS the timing, if a complete
user-defined timing can be passed down from userspace, which is, AFAIK,
currently not possible. So if I can request a mode with a complete Xish
mode line, then the kernel only has to check whether it is possible at all.
It does not need to worry about preferred modes or I-don't-want-text-with
-200Hz. It's a simple go/nogo decision.

But then the libggi part of the mode negotiation does the work:
look if there are preferred mode lines ...
It would need to know the monitor (a config file would do) and the
card limits as well.
But we'd have to reconfigure *something* in this system anyway if
we change monitor and/or card, so this is not worse than the current 
solution.

This would need to go so far to check whether a dot clock can be 
done by the PLL, whether sync lengths have to be multiples of 8 etc, so
it would most probably go into the vendor-specific libggi part.

But with such a method the kernel part gets minimum size, the system
gains maximum flexibility, because you could change the preferences
on the fly without needing any (root) privileges, and security
would not be compromised.

So could all mode *negotiation* be moved to libggi's check*mode (set_mode)
calls, and only the mode *checking* remain in-kernel?
Maybe some get_timing call would need to be added?

Hartmut
--  
Hartmut Niemann   --   niemann(a)cip.e-technik.uni-erlangen.de
http://cip2.e-technik.uni-erlangen.de:8080/hyplan/niemann/index_en.html [/ggi]