Thanks for your mail. I have read this part code and use DDD to debug in X
server. I can answer you question as far as I can.
See my reply below.
> OK, let me see if I can explain:
>
> The purpose of the *_mode_valid function in each device-dependent X
> ...[snip]
Agree.
>
> xf86-video-ati's h
On Mon, Oct 11, 2010 at 9:38 PM, Huang, FrankR wrote:
> [snip]
OK, let me see if I can explain:
The purpose of the *_mode_valid function in each device-dependent X
(xf86-video-ati, xf86-video-intel) is to allow the driver to decide
whether a particular mode (mode is a resolution+color depth+refr
> -Original Message-
> From: Matthew Garrett [mailto:mj...@srcf.ucam.org]
> Sent: 2010?10?12? 9:28
> To: Huang, FrankR
> Cc: Otavio Salvador; Adam Jackson; xorg-devel@lists.x.org; Geode Mailing
> List; Julien Cristau
> Subject: Re: [Xorg-driver-geode] xf86-video-geod
On Tue, Oct 12, 2010 at 09:23:35AM +0800, Huang, FrankR wrote:
> The reason why valid modes are being pruned is due to the MODE_BAD
> return in this function. In the following function
> xf86PruneInvalidModes, the modes that is not MODE_OK will be deleted.
> It is very clear. Just look at the c
:51
> To: Huang, FrankR
> Cc: Otavio Salvador; Adam Jackson; xorg-devel@lists.x.org; Geode Mailing
> List; Julien Cristau
> Subject: Re: [Xorg-driver-geode] xf86-video-geode: Changes to 'master'
>
> Your change means that the function will always return MODE_OK. If
> t
de Mailing List; q-f...@iki.fi;
> xorg-devel@lists.x.org; mj...@srcf.ucam.org
> Subject: RE: xf86-video-geode: Changes to 'master'
>
> 1On Mon, 2010-10-11 at 11:46 +0800, Huang, FrankR wrote:
>
> > First of all, I can not accept the manner you used in your mail on
>
1On Mon, 2010-10-11 at 11:46 +0800, Huang, FrankR wrote:
> First of all, I can not accept the manner you used in your mail on
> this issue. Every change has its reason in the world. I think Your
> "wrong wrong wrong" conclusion is too early. Science(absolutely
> include the software codes) has no
Your change means that the function will always return MODE_OK. If
that's what you want to happen, just remove the entirity of the
function other than the return statement. There's no point in performing
various checks that result in the same outcome. You'll probably be able
to delete some othe
bounces+frankr.huang=amd@lists.x.org] On Behalf Of Adam Jackson
> Sent: 2010年9月30日 22:14
> To: Huang, FrankR
> Cc: Geode Mailing List; q-f...@iki.fi; xorg-devel@lists.x.org; Otavio
> Salvador; Julien Cristau
> Subject: RE: xf86-video-geode: Changes to 'master'
>
&g
On Thu, Sep 30, 2010 at 08:49:55AM -0300, Otavio Salvador wrote:
> On Thu, Sep 30, 2010 at 4:46 AM, Julien Cristau wrote:
> > On Thu, Sep 30, 2010 at 15:38:07 +0800, Huang, FrankR wrote:
> >
> >> Agree.
> >> But that will revert totally 5/29/2010 patch.
> >>
> > It will be exactly equivalent to th
On Thu, 2010-09-30 at 15:49 +0800, Huang, FrankR wrote:
> So we can keep the current git code with no change.
You can, but the code is still _wrong_. Wrong wrong wrong. Your
hardware has real constraints; you have finite memory bandwidth, and
finite DAC speed, and finite CRTC addressibility. If
On Thu, Sep 30, 2010 at 4:46 AM, Julien Cristau wrote:
> On Thu, Sep 30, 2010 at 15:38:07 +0800, Huang, FrankR wrote:
>
>> Agree.
>> But that will revert totally 5/29/2010 patch.
>>
> It will be exactly equivalent to the current code. So no.
It is not equivalent.
--
Otavio Salvador
Agree.
But that will revert totally 5/29/2010 patch.
Thanks,
Frank
> -Original Message-
> From: Julien Cristau [mailto:jcris...@debian.org]
> Sent: 2010?9?30? 14:28
> To: Huang, FrankR
> Cc: Geode Mailing List; q-f...@iki.fi; xorg-devel@lists.x.org
> Subject: Re
So we can keep the current git code with no change.
> -Original Message-
> From: Julien Cristau [mailto:jcris...@debian.org]
> Sent: 2010?9?30? 15:47
> To: Huang, FrankR
> Cc: Otavio Salvador; Geode Mailing List; q-f...@iki.fi; xorg-
> de...@lists.x.org
> Subject:
On Thu, Sep 30, 2010 at 15:38:07 +0800, Huang, FrankR wrote:
> Agree.
> But that will revert totally 5/29/2010 patch.
>
It will be exactly equivalent to the current code. So no.
Cheers,
Julien
___
xorg-devel@lists.x.org: X.Org development
Archives: h
On Thu, Sep 30, 2010 at 13:56:27 +0800, Huang, FrankR wrote:
> I definitely know MODE_OK will be returned in this function now for
> every condition. But you should know my patch is based on the patch
> Otavio committed on 5/29/2010. If there is some condition we need give
> MODE_XXX, we can add c
See below:
> This looks broken. lx_output_mode_valid() now returns MODE_OK for every
> possible mode, but takes great pains to get there. The commit message
> doesn't help, I have no idea what it's trying to say.
I have not received your mail until Martin forwarded it to me just now. If you
don
On Wed, Sep 29, 2010 at 06:36:52 -0700, Martin-Éric Racine wrote:
> src/lx_output.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> New commits:
> commit 89c60efe899f0cda4a52e0574f030c021c4b1ece
> Author: Frank Huang
> Date: Wed Sep 29 16:35:46 2010 +0300
>
> Mode Validati
18 matches
Mail list logo
