Julien, Adam, Matthew, Matt, thanks a lot for you to give me
suggestion and explanation in detail on my patch for *_mode_valid.
Always I appreciate any feedback from the community. We are all for good
code. I am also a coder and driver maintainer, so I hate wrong code too,
especially that will lead a bug.
Thanks for Mitch's help, I know quite more on what you guys mean
in your mail, especially you are experienced coder on X.
Actually, I understand what you mean about the "wrong code" on
my patch. After the change of the last return value from MODE_BAD to
MODE_OK, that will make the whole function return ONLY "MODE_OK" VALUE.
>From the semantically point, it does same as below:
lx_output_mode_valid()
{
return MODE_OK;
}
Introducing more MODE_OK in this function seems to be no sense
for the validation. I agree. What I want for this function in the next
patch is as follows:
lx_output_mode_valid()
{
if(some state)
return MODE_CLOCK;
else if(some state)
return MODE_OK;
if(some state)
return MODE_PANEL;
...
return MODE_OK;
}
That is why I think keep the MODE_OK there(Otavio adds these
MODE_OK validation code, he must have the reason, So I keep them) is not
a big deal. I'll work with Otavio to make a better solution on that.
BTW, Alex has given me suggestion on which mode should be
filtered out in his mail:
-----
Thing you need to validate:
- max, min pixel clocks the pll is able to generate
- max, min pixel clocks supported by various encoders
(TMDS, DAC, etc.)
- fixed panel size
- memory bandwidth
----
I will follow this to write a better lx_output_mode_valid
function in the next patch to satisfy the requirement.
Glad to see you guys' more "wrong wrong wrong" reply:).
Thanks,
Frank
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
