brian.paul at tungstengraphics.com
Wed Mar 16 18:16:37 PST 2005
Jon Smirl wrote:
> On Thu, 17 Mar 2005 12:36:23 +1100, Benjamin Herrenschmidt
> <benh at kernel.crashing.org> wrote:
>>Jon, I don't understand. On one side, you talk about beeing able to
>>propose nice GUIs to the user, and on the other, you takl about having
>>to edit /etc/fb.modes ... People are quite used to deal with the refresh
>>rate (ok, maybe not all the secretaries, but it's still a common thing,
>>even Windows and MacOS give you access to that in their front end, I
>>think that should be part of the API).
> I was losing the GUI argument so I switched to the minimalist one.
> GUI strings was my first choice.
>>I think that the mode setting API should be able to handle everything
>>that has a user impact. That does not include tweakign the low level
>>timing details, but that definitely includes things like what mode is
>>native to the panel, the v refresh rate, eventually the scaling used on
>>flat panels, the TV standard, etc...
> The question is, what is the set of visible attibutes in EGL?
> width/height is the low end
> thirty various mode details is the high end
> Picking either end of the spectrum is fine with me, it's picking
> something in the middle that I'm having trouble with. How do you
> determine what are the important attributes, and who are they
> important to?
I don't think it's as hard to make that determination as you think.
Let's go with width, height, refresh rate and interlace flag for now
and see if the spec reviewers find that sufficient.
> Once you pick the set how does EGL know how to rank them?
We can certainly come up with rules for ranking. Of course, that's
only significant for eglChooseConfigMESA() which can be bypassed by
EGL programmers if desired.
More information about the dri-egl