Re: Cannot submit merge request for xf86-video-intel

[Maarten Maathuis]

Given that the xf86-video-intel repo hasn't been been set up for PRs
it seems (as opposed to lets say the xserver).
I see in https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel
the following people having made the most recent changes:

Ville Syrjälä: ville.syrj...@linux.intel.com (found via a commit
message with sign-off tag)
Eric Anholt: e...@anholt.net
Adam Jackson: a...@nwnk.net

Throw them a mail personally explaining them your question.

On Sat, May 11, 2019 at 11:46 AM Adam Richter  wrote:
>
> Hi, everyone on xorg-devel.
>
> I am wondering what the proper procedure is for submitting a patch or
> merge request for xf86-video-intel.  I had trouble using gitlab to do it,
> so I sent the following email to intel-gfx and got no response, which
> is unsurprising to me, given that I think that that list is essentially
> for Linux DRM patches.
>
> The patch I am trying to submit, attached to this email,  is the other
> "assert(a && b) --> asert(a); assert(b)" patch that I mentioned (the
> first one being for xserver).  This one for xf86-video-intel, which I
> believe is deprecated for Linux, but I imagine might still be used
> in some circumstances.
>
> Anyhow, my original email to intel-gfx, appended here, covers
> this in slightly  more detail.  Any advice on how I should proceed
> is welcome.  Thanks in advance for any thoughts on this.
>
> Adam
>
> -- Forwarded message -
> From: Adam Richter 
> Date: Mon, May 6, 2019 at 12:27 PM
> Subject: Cannot submit merge request for xf86-video-intel
> To: 
>
>
> Hi, everyone.
>
> I am having trouble submitting a merge request on
> gitlab.freedesktop.org for xf86-video-intel, even though doing so for
> xserver works fine.  The README for xf86-video-intel states that its
> mailing list is intel-...@lists.freedesktop.org, so I am asking here,
> even though most of the discussion on this list appears to be Linux
> DRM patches.
>
> On gitlab.freedesktop.org, I forked a personal copy of
> xf86-video-intel and pushed a change to it, but when I try to create a
> new pull request, the web page only offers me the options of
> submitting the merge request to one of two other users' tree.
>
> If I explicitly type "xorg/driver/xf86-video-intel" into the pull down
> menu for "Target branch" (because the menu does have a box for
> entering the text directly), the target repository name is updated,
> but when I click on "Compare branches and continue", I get a screen
> that states "You must select different branches," and has the target
> and source both set to my repository and branch.
>
> My understanding is that, on Linux these days, the X server now has
> xf86-video-modesetting merged in and normally uses that instead of
> xf86-video-intel, but xf86-video-intel is not marked as "archived" on
> gitlab.freedesktop.org, so I am guessing that changes to it are still
> potentially useful on some other operating systems or in some other
> unusual cases.
>
> In case anyone is curious about what the patch is, it is just
> essentially mechanical conversions of "assert(a && b)" to "assert(a)"
> and "assert(b)", hopefully for more efficient diagnosis of assertion
> failure reports, which I have attached to this message for reference.
> I submitting a similar merge request for the core X server a few days
> ago, and it apparently got a positive feedback, and I expect it to be
> merged shortly.
>
> Anyhow, any advice on how I should proceed, including simply
> redirecting me to a more appropriate mailing list, would be
> appreciated.  Thanks for reading this far, and thanks in advance for
> any guidance on this.
>
> Adam
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

On Tue, Apr 25, 2017 at 4:43 AM, AceLan Kao <acelan@canonical.com> wrote:
> According the spec. I have, the values are correct.
> Please merge it, thanks.
>

Is there a reason the whole spec isn't implemented?
Is it under NDA?

> 2017-04-25 5:41 GMT+08:00 Maarten Maathuis <madman2...@gmail.com>:
>> On Mon, Apr 24, 2017 at 11:37 PM, Andy Shevchenko
>> <andy.shevche...@gmail.com> wrote:
>>> On Tue, Apr 25, 2017 at 12:29 AM, Maarten Maathuis <madman2...@gmail.com> 
>>> wrote:
>>>> Tested on HP Elite X2 1012 G1.
>>>> Matches event report of Lenovo Helix 2
>>>> (https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
>>>>
>>>
>>> Much better!
>>>
>>>> V2: Fix indent and add sign-off
>>>
>>> Usually this line goes after --- (body delimiter).
>>> No need to resend this time. I would wait a bit for actual
>>> author/driver maintainer to comment. Otherwise patch looks good enough
>>> to me.
>>
>> The intent is not have this in the commit message?
>> I'll keep an eye out if i can place it below "---" next time.
>> Although i suspect the message would end in the actual code diff,
>> which seems odd.
>>
>>>
>>>>
>>>> Signed-off-by: Maarten Maathuis <madman2...@shikahr.net>
>>>> ---
>>>>  drivers/platform/x86/intel-vbtn.c | 4 
>>>>  1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/drivers/platform/x86/intel-vbtn.c 
>>>> b/drivers/platform/x86/intel-vbtn.c
>>>> index 554e82ebe83c..1616cb9c4ae5 100644
>>>> --- a/drivers/platform/x86/intel-vbtn.c
>>>> +++ b/drivers/platform/x86/intel-vbtn.c
>>>> @@ -37,6 +37,10 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
>>>>  static const struct key_entry intel_vbtn_keymap[] = {
>>>> { KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
>>>> { KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
>>>> +   { KE_KEY, 0xC4, { KEY_VOLUMEUP} },  /* volume-up key press */
>>>> +   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },  /* volume-up key release */
>>>> +   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN } },   /* volume-down key press */
>>>> +   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } },/* volume-down key 
>>>> release */
>>>> { KE_END },
>>>>  };
>>>>
>>>> --
>>>> 2.12.2
>>>>
>>>
>>>
>>>
>>> --
>>> With Best Regards,
>>> Andy Shevchenko
>>
>>
>>
>> --
>> Far away from the primal instinct, the song seems to fade away, the
>> river get wider between your thoughts and the things we do and say.



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: [PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

On Tue, Apr 25, 2017 at 4:43 AM, AceLan Kao  wrote:
> According the spec. I have, the values are correct.
> Please merge it, thanks.
>

Is there a reason the whole spec isn't implemented?
Is it under NDA?

> 2017-04-25 5:41 GMT+08:00 Maarten Maathuis :
>> On Mon, Apr 24, 2017 at 11:37 PM, Andy Shevchenko
>>  wrote:
>>> On Tue, Apr 25, 2017 at 12:29 AM, Maarten Maathuis  
>>> wrote:
>>>> Tested on HP Elite X2 1012 G1.
>>>> Matches event report of Lenovo Helix 2
>>>> (https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
>>>>
>>>
>>> Much better!
>>>
>>>> V2: Fix indent and add sign-off
>>>
>>> Usually this line goes after --- (body delimiter).
>>> No need to resend this time. I would wait a bit for actual
>>> author/driver maintainer to comment. Otherwise patch looks good enough
>>> to me.
>>
>> The intent is not have this in the commit message?
>> I'll keep an eye out if i can place it below "---" next time.
>> Although i suspect the message would end in the actual code diff,
>> which seems odd.
>>
>>>
>>>>
>>>> Signed-off-by: Maarten Maathuis 
>>>> ---
>>>>  drivers/platform/x86/intel-vbtn.c | 4 
>>>>  1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/drivers/platform/x86/intel-vbtn.c 
>>>> b/drivers/platform/x86/intel-vbtn.c
>>>> index 554e82ebe83c..1616cb9c4ae5 100644
>>>> --- a/drivers/platform/x86/intel-vbtn.c
>>>> +++ b/drivers/platform/x86/intel-vbtn.c
>>>> @@ -37,6 +37,10 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
>>>>  static const struct key_entry intel_vbtn_keymap[] = {
>>>> { KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
>>>> { KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
>>>> +   { KE_KEY, 0xC4, { KEY_VOLUMEUP} },  /* volume-up key press */
>>>> +   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },  /* volume-up key release */
>>>> +   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN } },   /* volume-down key press */
>>>> +   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } },/* volume-down key 
>>>> release */
>>>> { KE_END },
>>>>  };
>>>>
>>>> --
>>>> 2.12.2
>>>>
>>>
>>>
>>>
>>> --
>>> With Best Regards,
>>> Andy Shevchenko
>>
>>
>>
>> --
>> Far away from the primal instinct, the song seems to fade away, the
>> river get wider between your thoughts and the things we do and say.



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: [PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

On Mon, Apr 24, 2017 at 11:37 PM, Andy Shevchenko
<andy.shevche...@gmail.com> wrote:
> On Tue, Apr 25, 2017 at 12:29 AM, Maarten Maathuis <madman2...@gmail.com> 
> wrote:
>> Tested on HP Elite X2 1012 G1.
>> Matches event report of Lenovo Helix 2
>> (https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
>>
>
> Much better!
>
>> V2: Fix indent and add sign-off
>
> Usually this line goes after --- (body delimiter).
> No need to resend this time. I would wait a bit for actual
> author/driver maintainer to comment. Otherwise patch looks good enough
> to me.

The intent is not have this in the commit message?
I'll keep an eye out if i can place it below "---" next time.
Although i suspect the message would end in the actual code diff,
which seems odd.

>
>>
>> Signed-off-by: Maarten Maathuis <madman2...@shikahr.net>
>> ---
>>  drivers/platform/x86/intel-vbtn.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/platform/x86/intel-vbtn.c 
>> b/drivers/platform/x86/intel-vbtn.c
>> index 554e82ebe83c..1616cb9c4ae5 100644
>> --- a/drivers/platform/x86/intel-vbtn.c
>> +++ b/drivers/platform/x86/intel-vbtn.c
>> @@ -37,6 +37,10 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
>>  static const struct key_entry intel_vbtn_keymap[] = {
>> { KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
>> { KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
>> +   { KE_KEY, 0xC4, { KEY_VOLUMEUP} },  /* volume-up key press */
>> +   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },  /* volume-up key release */
>> +   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN } },   /* volume-down key press */
>> +   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } },/* volume-down key 
>> release */
>> { KE_END },
>>  };
>>
>> --
>> 2.12.2
>>
>
>
>
> --
> With Best Regards,
> Andy Shevchenko



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: [PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

On Mon, Apr 24, 2017 at 11:37 PM, Andy Shevchenko
 wrote:
> On Tue, Apr 25, 2017 at 12:29 AM, Maarten Maathuis  
> wrote:
>> Tested on HP Elite X2 1012 G1.
>> Matches event report of Lenovo Helix 2
>> (https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
>>
>
> Much better!
>
>> V2: Fix indent and add sign-off
>
> Usually this line goes after --- (body delimiter).
> No need to resend this time. I would wait a bit for actual
> author/driver maintainer to comment. Otherwise patch looks good enough
> to me.

The intent is not have this in the commit message?
I'll keep an eye out if i can place it below "---" next time.
Although i suspect the message would end in the actual code diff,
which seems odd.

>
>>
>> Signed-off-by: Maarten Maathuis 
>> ---
>>  drivers/platform/x86/intel-vbtn.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/platform/x86/intel-vbtn.c 
>> b/drivers/platform/x86/intel-vbtn.c
>> index 554e82ebe83c..1616cb9c4ae5 100644
>> --- a/drivers/platform/x86/intel-vbtn.c
>> +++ b/drivers/platform/x86/intel-vbtn.c
>> @@ -37,6 +37,10 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
>>  static const struct key_entry intel_vbtn_keymap[] = {
>> { KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
>> { KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
>> +   { KE_KEY, 0xC4, { KEY_VOLUMEUP} },  /* volume-up key press */
>> +   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },  /* volume-up key release */
>> +   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN } },   /* volume-down key press */
>> +   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } },/* volume-down key 
>> release */
>> { KE_END },
>>  };
>>
>> --
>> 2.12.2
>>
>
>
>
> --
> With Best Regards,
> Andy Shevchenko



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

[PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

Tested on HP Elite X2 1012 G1.
Matches event report of Lenovo Helix 2
(https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).

V2: Fix indent and add sign-off
V3: Missing whitespace correction

Signed-off-by: Maarten Maathuis <madman2...@shikahr.net>
---
 drivers/platform/x86/intel-vbtn.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/platform/x86/intel-vbtn.c 
b/drivers/platform/x86/intel-vbtn.c
index 554e82ebe83c..dc270fe793a1 100644
--- a/drivers/platform/x86/intel-vbtn.c
+++ b/drivers/platform/x86/intel-vbtn.c
@@ -37,6 +37,10 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
 static const struct key_entry intel_vbtn_keymap[] = {
{ KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
{ KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
+   { KE_KEY, 0xC4, { KEY_VOLUMEUP } }, /* volume-up key press */
+   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },  /* volume-up key release */
+   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN } },   /* volume-down key press */
+   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } },/* volume-down key 
release */
{ KE_END },
 };
 
-- 
2.12.2

[PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

Tested on HP Elite X2 1012 G1.
Matches event report of Lenovo Helix 2
(https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).

V2: Fix indent and add sign-off
V3: Missing whitespace correction

Signed-off-by: Maarten Maathuis 
---
 drivers/platform/x86/intel-vbtn.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/platform/x86/intel-vbtn.c 
b/drivers/platform/x86/intel-vbtn.c
index 554e82ebe83c..dc270fe793a1 100644
--- a/drivers/platform/x86/intel-vbtn.c
+++ b/drivers/platform/x86/intel-vbtn.c
@@ -37,6 +37,10 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
 static const struct key_entry intel_vbtn_keymap[] = {
{ KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
{ KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
+   { KE_KEY, 0xC4, { KEY_VOLUMEUP } }, /* volume-up key press */
+   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },  /* volume-up key release */
+   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN } },   /* volume-down key press */
+   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } },/* volume-down key 
release */
{ KE_END },
 };
 
-- 
2.12.2

Re: [PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

On Mon, Apr 24, 2017 at 10:55 PM, Andy Shevchenko
<andy.shevche...@gmail.com> wrote:
> On Mon, Apr 24, 2017 at 11:47 PM, Maarten Maathuis <madman2...@gmail.com> 
> wrote:
>> Tested on HP Elite X2 1012 G1.
>> Matches event report of Lenovo Helix 2
>> (https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
>
> Thanks for the patch.
>
> A bit of work still required.
>
> According to Submitting Patches document [1] we need your Signed-off-by tag.
>
> Besides that see my comment below.
>
> [1] https://www.kernel.org/doc/Documentation/process/submitting-patches.rst
>
>
>> ---
>>  drivers/platform/x86/intel-vbtn.c | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/platform/x86/intel-vbtn.c 
>> b/drivers/platform/x86/intel-vbtn.c
>> index 554e82ebe83c..1fbebbad350d 100644
>> --- a/drivers/platform/x86/intel-vbtn.c
>> +++ b/drivers/platform/x86/intel-vbtn.c
>> @@ -35,8 +35,12 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
>>
>>  /* In theory, these are HID usages. */
>>  static const struct key_entry intel_vbtn_keymap[] = {
>
>> -   { KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
>> -   { KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
>> +   { KE_IGNORE, 0xC0, { KEY_POWER } },  /* power key press */
>> +   { KE_KEY, 0xC1, { KEY_POWER } }, /* power key release */
>
> As far as I can see nothing should happen on these lines. I think your
> editor (or maybe email setup) is configured somehow wrongly. We expect
> TAB as an indentation starter.
>
> We also encourage to use git send-email tool instead of manual
> submitting patches through some (broken) MUAs.

I fell back to an other SMTP server, until i can find a structural
long term solution.
The difference in the other two lines was due to a misunderstanding
about indenting
policy. hopefully it's better now.

>
>> +   { KE_KEY, 0xC4, { KEY_VOLUMEUP} },   /* volume-up key press */
>> +   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },   /* volume-up key release */
>> +   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN} }, /* volume-down key press */
>> +   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } }, /* volume-down key release 
>> */
>> { KE_END },
>
> --
> With Best Regards,
> Andy Shevchenko



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: [PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

On Mon, Apr 24, 2017 at 10:55 PM, Andy Shevchenko
 wrote:
> On Mon, Apr 24, 2017 at 11:47 PM, Maarten Maathuis  
> wrote:
>> Tested on HP Elite X2 1012 G1.
>> Matches event report of Lenovo Helix 2
>> (https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
>
> Thanks for the patch.
>
> A bit of work still required.
>
> According to Submitting Patches document [1] we need your Signed-off-by tag.
>
> Besides that see my comment below.
>
> [1] https://www.kernel.org/doc/Documentation/process/submitting-patches.rst
>
>
>> ---
>>  drivers/platform/x86/intel-vbtn.c | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/platform/x86/intel-vbtn.c 
>> b/drivers/platform/x86/intel-vbtn.c
>> index 554e82ebe83c..1fbebbad350d 100644
>> --- a/drivers/platform/x86/intel-vbtn.c
>> +++ b/drivers/platform/x86/intel-vbtn.c
>> @@ -35,8 +35,12 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
>>
>>  /* In theory, these are HID usages. */
>>  static const struct key_entry intel_vbtn_keymap[] = {
>
>> -   { KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
>> -   { KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
>> +   { KE_IGNORE, 0xC0, { KEY_POWER } },  /* power key press */
>> +   { KE_KEY, 0xC1, { KEY_POWER } }, /* power key release */
>
> As far as I can see nothing should happen on these lines. I think your
> editor (or maybe email setup) is configured somehow wrongly. We expect
> TAB as an indentation starter.
>
> We also encourage to use git send-email tool instead of manual
> submitting patches through some (broken) MUAs.

I fell back to an other SMTP server, until i can find a structural
long term solution.
The difference in the other two lines was due to a misunderstanding
about indenting
policy. hopefully it's better now.

>
>> +   { KE_KEY, 0xC4, { KEY_VOLUMEUP} },   /* volume-up key press */
>> +   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },   /* volume-up key release */
>> +   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN} }, /* volume-down key press */
>> +   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } }, /* volume-down key release 
>> */
>> { KE_END },
>
> --
> With Best Regards,
> Andy Shevchenko



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

[PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

Tested on HP Elite X2 1012 G1.
Matches event report of Lenovo Helix 2
(https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).

V2: Fix indent and add sign-off

Signed-off-by: Maarten Maathuis <madman2...@shikahr.net>
---
 drivers/platform/x86/intel-vbtn.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/platform/x86/intel-vbtn.c 
b/drivers/platform/x86/intel-vbtn.c
index 554e82ebe83c..1616cb9c4ae5 100644
--- a/drivers/platform/x86/intel-vbtn.c
+++ b/drivers/platform/x86/intel-vbtn.c
@@ -37,6 +37,10 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
 static const struct key_entry intel_vbtn_keymap[] = {
{ KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
{ KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
+   { KE_KEY, 0xC4, { KEY_VOLUMEUP} },  /* volume-up key press */
+   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },  /* volume-up key release */
+   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN } },   /* volume-down key press */
+   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } },/* volume-down key 
release */
{ KE_END },
 };
 
-- 
2.12.2

[PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

Tested on HP Elite X2 1012 G1.
Matches event report of Lenovo Helix 2
(https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).

V2: Fix indent and add sign-off

Signed-off-by: Maarten Maathuis 
---
 drivers/platform/x86/intel-vbtn.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/platform/x86/intel-vbtn.c 
b/drivers/platform/x86/intel-vbtn.c
index 554e82ebe83c..1616cb9c4ae5 100644
--- a/drivers/platform/x86/intel-vbtn.c
+++ b/drivers/platform/x86/intel-vbtn.c
@@ -37,6 +37,10 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
 static const struct key_entry intel_vbtn_keymap[] = {
{ KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
{ KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
+   { KE_KEY, 0xC4, { KEY_VOLUMEUP} },  /* volume-up key press */
+   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },  /* volume-up key release */
+   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN } },   /* volume-down key press */
+   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } },/* volume-down key 
release */
{ KE_END },
 };
 
-- 
2.12.2

[PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

Tested on HP Elite X2 1012 G1.
Matches event report of Lenovo Helix 2
(https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
---
 drivers/platform/x86/intel-vbtn.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/intel-vbtn.c 
b/drivers/platform/x86/intel-vbtn.c
index 554e82ebe83c..1fbebbad350d 100644
--- a/drivers/platform/x86/intel-vbtn.c
+++ b/drivers/platform/x86/intel-vbtn.c
@@ -35,8 +35,12 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
 
 /* In theory, these are HID usages. */
 static const struct key_entry intel_vbtn_keymap[] = {
-   { KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
-   { KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
+   { KE_IGNORE, 0xC0, { KEY_POWER } },  /* power key press */
+   { KE_KEY, 0xC1, { KEY_POWER } }, /* power key release */
+   { KE_KEY, 0xC4, { KEY_VOLUMEUP} },   /* volume-up key press */
+   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },   /* volume-up key release */
+   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN} }, /* volume-down key press */
+   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } }, /* volume-down key release */
{ KE_END },
 };
 
-- 
2.12.2

[PATCH] platform/x86/intel-vbtn: add volume up and down

[Maarten Maathuis]

Tested on HP Elite X2 1012 G1.
Matches event report of Lenovo Helix 2
(https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
---
 drivers/platform/x86/intel-vbtn.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/intel-vbtn.c 
b/drivers/platform/x86/intel-vbtn.c
index 554e82ebe83c..1fbebbad350d 100644
--- a/drivers/platform/x86/intel-vbtn.c
+++ b/drivers/platform/x86/intel-vbtn.c
@@ -35,8 +35,12 @@ static const struct acpi_device_id intel_vbtn_ids[] = {
 
 /* In theory, these are HID usages. */
 static const struct key_entry intel_vbtn_keymap[] = {
-   { KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
-   { KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
+   { KE_IGNORE, 0xC0, { KEY_POWER } },  /* power key press */
+   { KE_KEY, 0xC1, { KEY_POWER } }, /* power key release */
+   { KE_KEY, 0xC4, { KEY_VOLUMEUP} },   /* volume-up key press */
+   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },   /* volume-up key release */
+   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN} }, /* volume-down key press */
+   { KE_IGNORE, 0xC7, { KEY_VOLUMEDOWN } }, /* volume-down key release */
{ KE_END },
 };
 
-- 
2.12.2

Re: [PATCH 4.8 118/138] drm/i915: Clean up DDI DDC/AUX CH sanitation

[Maarten Maathuis]

Hi,

I'm merely curious why this patch isn't also included:
https://cgit.freedesktop.org/drm-intel/commit/?id=e4ab73a13291fc844c9e24d5c347bd95818544d2

When i checked it, it's also not in 4.9-rc git tree.
This patch affects HDMI, and the HDMI connector was "my problem".

@Ville: Is it intentional this one was left out?

Maarten.

On Wed, Nov 9, 2016 at 11:46 AM, Greg Kroah-Hartman
<gre...@linuxfoundation.org> wrote:
> 4.8-stable review patch.  If anyone has any objections, please let me know.
>
> --
>
> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>
> commit 0ce140d45a8398b501934ac289aef0eb7f47c596 upstream.
>
> Now that we use the AUX and GMBUS assignment from VBT for all ports,
> let's clean up the sanitization of the port information a bit.
> Previosuly we only did this for port E, and only complained about a
> non-standard assignment for the other ports. But as we know that
> non-standard assignments are a fact of life, let's expand the
> sanitization to all the ports.
>
> v2: Include a commit message, fix up the comments a bit
> v3: Don't clobber other ports if the current port has no alternate aux ch/ddc 
> pin
>
> Cc: Maarten Maathuis <madman2...@gmail.com>
> Tested-by: Maarten Maathuis <madman2...@gmail.com>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97877
> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
> Link: 
> http://patchwork.freedesktop.org/patch/msgid/1476208368-5710-4-git-send-email-ville.syrj...@linux.intel.com
> Reviewed-by: Jim Bride <jim.br...@linux.intel.com> (v2)
> (cherry picked from commit 9454fa871edf15c20a0371548b3ec0d6d944a498)
> Signed-off-by: Jani Nikula <jani.nik...@intel.com>
> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>
> ---
>  drivers/gpu/drm/i915/intel_bios.c |  122 
> +++---
>  1 file changed, 77 insertions(+), 45 deletions(-)
>
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1031,6 +1031,77 @@ static u8 translate_iboost(u8 val)
> return mapping[val];
>  }
>
> +static void sanitize_ddc_pin(struct drm_i915_private *dev_priv,
> +enum port port)
> +{
> +   const struct ddi_vbt_port_info *info =
> +   _priv->vbt.ddi_port_info[port];
> +   enum port p;
> +
> +   if (!info->alternate_ddc_pin)
> +   return;
> +
> +   for_each_port_masked(p, (1 << port) - 1) {
> +   struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
> +
> +   if (info->alternate_ddc_pin != i->alternate_ddc_pin)
> +   continue;
> +
> +   DRM_DEBUG_KMS("port %c trying to use the same DDC pin (0x%x) 
> as port %c, "
> + "disabling port %c DVI/HDMI support\n",
> + port_name(p), i->alternate_ddc_pin,
> + port_name(port), port_name(p));
> +
> +   /*
> +* If we have multiple ports supposedly sharing the
> +* pin, then dvi/hdmi couldn't exist on the shared
> +* port. Otherwise they share the same ddc bin and
> +* system couldn't communicate with them separately.
> +*
> +* Due to parsing the ports in alphabetical order,
> +* a higher port will always clobber a lower one.
> +*/
> +   i->supports_dvi = false;
> +   i->supports_hdmi = false;
> +   i->alternate_ddc_pin = 0;
> +   }
> +}
> +
> +static void sanitize_aux_ch(struct drm_i915_private *dev_priv,
> +   enum port port)
> +{
> +   const struct ddi_vbt_port_info *info =
> +   _priv->vbt.ddi_port_info[port];
> +   enum port p;
> +
> +   if (!info->alternate_aux_channel)
> +   return;
> +
> +   for_each_port_masked(p, (1 << port) - 1) {
> +   struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
> +
> +   if (info->alternate_aux_channel != i->alternate_aux_channel)
> +   continue;
> +
> +   DRM_DEBUG_KMS("port %c trying to use the same AUX CH (0x%x) 
> as port %c, "
> + "disabling port %c DP support\n",
> + port_name(p), i->alternate_aux_channel,
> + port_name(port), port_name(p));
> +
> +   /*
> +* If we have multiple ports supposedlt sharing

Re: [PATCH 4.8 118/138] drm/i915: Clean up DDI DDC/AUX CH sanitation

[Maarten Maathuis]

Hi,

I'm merely curious why this patch isn't also included:
https://cgit.freedesktop.org/drm-intel/commit/?id=e4ab73a13291fc844c9e24d5c347bd95818544d2

When i checked it, it's also not in 4.9-rc git tree.
This patch affects HDMI, and the HDMI connector was "my problem".

@Ville: Is it intentional this one was left out?

Maarten.

On Wed, Nov 9, 2016 at 11:46 AM, Greg Kroah-Hartman
 wrote:
> 4.8-stable review patch.  If anyone has any objections, please let me know.
>
> --
>
> From: Ville Syrjälä 
>
> commit 0ce140d45a8398b501934ac289aef0eb7f47c596 upstream.
>
> Now that we use the AUX and GMBUS assignment from VBT for all ports,
> let's clean up the sanitization of the port information a bit.
> Previosuly we only did this for port E, and only complained about a
> non-standard assignment for the other ports. But as we know that
> non-standard assignments are a fact of life, let's expand the
> sanitization to all the ports.
>
> v2: Include a commit message, fix up the comments a bit
> v3: Don't clobber other ports if the current port has no alternate aux ch/ddc 
> pin
>
> Cc: Maarten Maathuis 
> Tested-by: Maarten Maathuis 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97877
> Signed-off-by: Ville Syrjälä 
> Link: 
> http://patchwork.freedesktop.org/patch/msgid/1476208368-5710-4-git-send-email-ville.syrj...@linux.intel.com
> Reviewed-by: Jim Bride  (v2)
> (cherry picked from commit 9454fa871edf15c20a0371548b3ec0d6d944a498)
> Signed-off-by: Jani Nikula 
> Signed-off-by: Greg Kroah-Hartman 
>
> ---
>  drivers/gpu/drm/i915/intel_bios.c |  122 
> +++---
>  1 file changed, 77 insertions(+), 45 deletions(-)
>
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1031,6 +1031,77 @@ static u8 translate_iboost(u8 val)
> return mapping[val];
>  }
>
> +static void sanitize_ddc_pin(struct drm_i915_private *dev_priv,
> +enum port port)
> +{
> +   const struct ddi_vbt_port_info *info =
> +   _priv->vbt.ddi_port_info[port];
> +   enum port p;
> +
> +   if (!info->alternate_ddc_pin)
> +   return;
> +
> +   for_each_port_masked(p, (1 << port) - 1) {
> +   struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
> +
> +   if (info->alternate_ddc_pin != i->alternate_ddc_pin)
> +   continue;
> +
> +   DRM_DEBUG_KMS("port %c trying to use the same DDC pin (0x%x) 
> as port %c, "
> + "disabling port %c DVI/HDMI support\n",
> + port_name(p), i->alternate_ddc_pin,
> + port_name(port), port_name(p));
> +
> +   /*
> +* If we have multiple ports supposedly sharing the
> +* pin, then dvi/hdmi couldn't exist on the shared
> +* port. Otherwise they share the same ddc bin and
> +* system couldn't communicate with them separately.
> +*
> +* Due to parsing the ports in alphabetical order,
> +* a higher port will always clobber a lower one.
> +*/
> +   i->supports_dvi = false;
> +   i->supports_hdmi = false;
> +   i->alternate_ddc_pin = 0;
> +   }
> +}
> +
> +static void sanitize_aux_ch(struct drm_i915_private *dev_priv,
> +   enum port port)
> +{
> +   const struct ddi_vbt_port_info *info =
> +   _priv->vbt.ddi_port_info[port];
> +   enum port p;
> +
> +   if (!info->alternate_aux_channel)
> +   return;
> +
> +   for_each_port_masked(p, (1 << port) - 1) {
> +   struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
> +
> +   if (info->alternate_aux_channel != i->alternate_aux_channel)
> +   continue;
> +
> +   DRM_DEBUG_KMS("port %c trying to use the same AUX CH (0x%x) 
> as port %c, "
> + "disabling port %c DP support\n",
> + port_name(p), i->alternate_aux_channel,
> + port_name(port), port_name(p));
> +
> +   /*
> +* If we have multiple ports supposedlt sharing the
> +* aux channel, then DP couldn't exist on the shared
> +* port. Otherwise they share the same aux channel
> +* and system couldn't communicate with them separately.
> +*
>

Re: How to debug DEBUG_TEST_DRIVER_REMOVE hang during loading of kernel?

[Maarten Maathuis]

Anyone have advice where else I can ask?

On Sat, Oct 29, 2016 at 1:07 PM, Maarten Maathuis <madman2...@gmail.com> wrote:
> Anyone have suggestions?
>
> On Thu, Oct 27, 2016 at 8:42 PM, Maarten Maathuis <madman2...@gmail.com> 
> wrote:
>> Hi,
>>
>> I recently had trouble with loading a 4.9rcX kernel, which was hanging
>> after loading the initial kernel ramdisk. After some painful bisecting
>> I found this:
>>
>> bea5b158ff0da9c7246ff391f754f5f38e34577a is the first bad commit
>> commit bea5b158ff0da9c7246ff391f754f5f38e34577a
>> Author: Rob Herring <r...@kernel.org>
>> Date:   Thu Aug 11 10:20:58 2016 -0500
>>
>> driver core: add test of driver remove calls during probe
>>
>> In recent discussions on ksummit-discuss[1], it was suggested to do a
>> sequence of probe, remove, probe for testing driver remove paths. This
>> adds a kconfig option for said test.
>>
>> [1] 
>> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html
>>
>> Suggested-by: Arnd Bergmann <a...@arndb.de>
>> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>> Signed-off-by: Rob Herring <r...@kernel.org>
>> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>>
>> It turns out that the package i was using to build the kernel had
>> DEBUG_TEST_DRIVER_REMOVE enabled.
>>
>> How do I actually figure out why this test causes a hang. I don't have
>> a COM port available to use as serial console, and i don't know if it
>> would even help.
>>
>> Please CC me as i'm not a member of this mailinglist.
>>
>> Maarten.
>>
>> --
>> Far away from the primal instinct, the song seems to fade away, the
>> river get wider between your thoughts and the things we do and say.
>
>
>
> --
> Far away from the primal instinct, the song seems to fade away, the
> river get wider between your thoughts and the things we do and say.



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: How to debug DEBUG_TEST_DRIVER_REMOVE hang during loading of kernel?

[Maarten Maathuis]

Anyone have advice where else I can ask?

On Sat, Oct 29, 2016 at 1:07 PM, Maarten Maathuis  wrote:
> Anyone have suggestions?
>
> On Thu, Oct 27, 2016 at 8:42 PM, Maarten Maathuis  
> wrote:
>> Hi,
>>
>> I recently had trouble with loading a 4.9rcX kernel, which was hanging
>> after loading the initial kernel ramdisk. After some painful bisecting
>> I found this:
>>
>> bea5b158ff0da9c7246ff391f754f5f38e34577a is the first bad commit
>> commit bea5b158ff0da9c7246ff391f754f5f38e34577a
>> Author: Rob Herring 
>> Date:   Thu Aug 11 10:20:58 2016 -0500
>>
>> driver core: add test of driver remove calls during probe
>>
>> In recent discussions on ksummit-discuss[1], it was suggested to do a
>> sequence of probe, remove, probe for testing driver remove paths. This
>> adds a kconfig option for said test.
>>
>> [1] 
>> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html
>>
>> Suggested-by: Arnd Bergmann 
>> Cc: Greg Kroah-Hartman 
>> Signed-off-by: Rob Herring 
>> Signed-off-by: Greg Kroah-Hartman 
>>
>> It turns out that the package i was using to build the kernel had
>> DEBUG_TEST_DRIVER_REMOVE enabled.
>>
>> How do I actually figure out why this test causes a hang. I don't have
>> a COM port available to use as serial console, and i don't know if it
>> would even help.
>>
>> Please CC me as i'm not a member of this mailinglist.
>>
>> Maarten.
>>
>> --
>> Far away from the primal instinct, the song seems to fade away, the
>> river get wider between your thoughts and the things we do and say.
>
>
>
> --
> Far away from the primal instinct, the song seems to fade away, the
> river get wider between your thoughts and the things we do and say.



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: How to debug DEBUG_TEST_DRIVER_REMOVE hang during loading of kernel?

[Maarten Maathuis]

Anyone have suggestions?

On Thu, Oct 27, 2016 at 8:42 PM, Maarten Maathuis <madman2...@gmail.com> wrote:
> Hi,
>
> I recently had trouble with loading a 4.9rcX kernel, which was hanging
> after loading the initial kernel ramdisk. After some painful bisecting
> I found this:
>
> bea5b158ff0da9c7246ff391f754f5f38e34577a is the first bad commit
> commit bea5b158ff0da9c7246ff391f754f5f38e34577a
> Author: Rob Herring <r...@kernel.org>
> Date:   Thu Aug 11 10:20:58 2016 -0500
>
> driver core: add test of driver remove calls during probe
>
> In recent discussions on ksummit-discuss[1], it was suggested to do a
> sequence of probe, remove, probe for testing driver remove paths. This
> adds a kconfig option for said test.
>
> [1] 
> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html
>
> Suggested-by: Arnd Bergmann <a...@arndb.de>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Signed-off-by: Rob Herring <r...@kernel.org>
> Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
>
> It turns out that the package i was using to build the kernel had
> DEBUG_TEST_DRIVER_REMOVE enabled.
>
> How do I actually figure out why this test causes a hang. I don't have
> a COM port available to use as serial console, and i don't know if it
> would even help.
>
> Please CC me as i'm not a member of this mailinglist.
>
> Maarten.
>
> --
> Far away from the primal instinct, the song seems to fade away, the
> river get wider between your thoughts and the things we do and say.



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: How to debug DEBUG_TEST_DRIVER_REMOVE hang during loading of kernel?

[Maarten Maathuis]

Anyone have suggestions?

On Thu, Oct 27, 2016 at 8:42 PM, Maarten Maathuis  wrote:
> Hi,
>
> I recently had trouble with loading a 4.9rcX kernel, which was hanging
> after loading the initial kernel ramdisk. After some painful bisecting
> I found this:
>
> bea5b158ff0da9c7246ff391f754f5f38e34577a is the first bad commit
> commit bea5b158ff0da9c7246ff391f754f5f38e34577a
> Author: Rob Herring 
> Date:   Thu Aug 11 10:20:58 2016 -0500
>
> driver core: add test of driver remove calls during probe
>
> In recent discussions on ksummit-discuss[1], it was suggested to do a
> sequence of probe, remove, probe for testing driver remove paths. This
> adds a kconfig option for said test.
>
> [1] 
> https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html
>
> Suggested-by: Arnd Bergmann 
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Rob Herring 
> Signed-off-by: Greg Kroah-Hartman 
>
> It turns out that the package i was using to build the kernel had
> DEBUG_TEST_DRIVER_REMOVE enabled.
>
> How do I actually figure out why this test causes a hang. I don't have
> a COM port available to use as serial console, and i don't know if it
> would even help.
>
> Please CC me as i'm not a member of this mailinglist.
>
> Maarten.
>
> --
> Far away from the primal instinct, the song seems to fade away, the
> river get wider between your thoughts and the things we do and say.



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

How to debug DEBUG_TEST_DRIVER_REMOVE hang during loading of kernel?

[Maarten Maathuis]

Hi,

I recently had trouble with loading a 4.9rcX kernel, which was hanging
after loading the initial kernel ramdisk. After some painful bisecting
I found this:

bea5b158ff0da9c7246ff391f754f5f38e34577a is the first bad commit
commit bea5b158ff0da9c7246ff391f754f5f38e34577a
Author: Rob Herring 
Date:   Thu Aug 11 10:20:58 2016 -0500

driver core: add test of driver remove calls during probe

In recent discussions on ksummit-discuss[1], it was suggested to do a
sequence of probe, remove, probe for testing driver remove paths. This
adds a kconfig option for said test.

[1] 
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html

Suggested-by: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman 

It turns out that the package i was using to build the kernel had
DEBUG_TEST_DRIVER_REMOVE enabled.

How do I actually figure out why this test causes a hang. I don't have
a COM port available to use as serial console, and i don't know if it
would even help.

Please CC me as i'm not a member of this mailinglist.

Maarten.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

How to debug DEBUG_TEST_DRIVER_REMOVE hang during loading of kernel?

[Maarten Maathuis]

Hi,

I recently had trouble with loading a 4.9rcX kernel, which was hanging
after loading the initial kernel ramdisk. After some painful bisecting
I found this:

bea5b158ff0da9c7246ff391f754f5f38e34577a is the first bad commit
commit bea5b158ff0da9c7246ff391f754f5f38e34577a
Author: Rob Herring 
Date:   Thu Aug 11 10:20:58 2016 -0500

driver core: add test of driver remove calls during probe

In recent discussions on ksummit-discuss[1], it was suggested to do a
sequence of probe, remove, probe for testing driver remove paths. This
adds a kconfig option for said test.

[1] 
https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-August/003459.html

Suggested-by: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman 

It turns out that the package i was using to build the kernel had
DEBUG_TEST_DRIVER_REMOVE enabled.

How do I actually figure out why this test causes a hang. I don't have
a COM port available to use as serial console, and i don't know if it
would even help.

Please CC me as i'm not a member of this mailinglist.

Maarten.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: [Intel-gfx] [PATCH v3 3/4] drm/i915: Clean up DDI DDC/AUX CH sanitation

[Maarten Maathuis]

I meant DON't suspect

On Thu, Oct 20, 2016 at 11:53 PM, Maarten Maathuis <madman2...@gmail.com>
wrote:

> Also tested v3 on top of 4.8.3 (mainline git is a mess right now for
> booting).
>
> I did encounter a seemingly unrelated message during boot (including a
> WARN_ON):
> [drm:skylake_pfit_enable [i915]] *ERROR* Requesting pfit without getting a
> scaler first
>
> I suspect any causal relation with these patches.
>
> On Mon, Oct 17, 2016 at 8:07 PM, <ville.syrj...@linux.intel.com> wrote:
>
>> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>>
>> Now that we use the AUX and GMBUS assignment from VBT for all ports,
>> let's clean up the sanitization of the port information a bit.
>> Previosuly we only did this for port E, and only complained about a
>> non-standard assignment for the other ports. But as we know that
>> non-standard assignments are a fact of life, let's expand the
>> sanitization to all the ports.
>>
>> v2: Include a commit message, fix up the comments a bit
>> v3: Don't clobber other ports if the current port has no alternate aux
>> ch/ddc pin
>>
>> Cc: sta...@vger.kernel.org
>> Cc: Maarten Maathuis <madman2...@gmail.com>
>> Tested-by: Maarten Maathuis <madman2...@gmail.com>
>> References: https://bugs.freedesktop.org/show_bug.cgi?id=97877
>> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
>> Link: http://patchwork.freedesktop.org/patch/msgid/1476208368-5710
>> -4-git-send-email-ville.syrj...@linux.intel.com
>> Reviewed-by: Jim Bride <jim.br...@linux.intel.com> (v2)
>> ---
>>  drivers/gpu/drm/i915/intel_bios.c | 122 --
>> 
>>  1 file changed, 77 insertions(+), 45 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_bios.c
>> b/drivers/gpu/drm/i915/intel_bios.c
>> index 83667e8cdd6b..a8ff8c099685 100644
>> --- a/drivers/gpu/drm/i915/intel_bios.c
>> +++ b/drivers/gpu/drm/i915/intel_bios.c
>> @@ -1035,6 +1035,77 @@ static u8 translate_iboost(u8 val)
>> return mapping[val];
>>  }
>>
>> +static void sanitize_ddc_pin(struct drm_i915_private *dev_priv,
>> +enum port port)
>> +{
>> +   const struct ddi_vbt_port_info *info =
>> +   _priv->vbt.ddi_port_info[port];
>> +   enum port p;
>> +
>> +   if (!info->alternate_ddc_pin)
>> +   return;
>> +
>> +   for_each_port_masked(p, (1 << port) - 1) {
>> +   struct ddi_vbt_port_info *i =
>> _priv->vbt.ddi_port_info[p];
>> +
>> +   if (info->alternate_ddc_pin != i->alternate_ddc_pin)
>> +   continue;
>> +
>> +   DRM_DEBUG_KMS("port %c trying to use the same DDC pin
>> (0x%x) as port %c, "
>> + "disabling port %c DVI/HDMI support\n",
>> + port_name(p), i->alternate_ddc_pin,
>> + port_name(port), port_name(p));
>> +
>> +   /*
>> +* If we have multiple ports supposedly sharing the
>> +* pin, then dvi/hdmi couldn't exist on the shared
>> +* port. Otherwise they share the same ddc bin and
>> +* system couldn't communicate with them separately.
>> +*
>> +* Due to parsing the ports in alphabetical order,
>> +* a higher port will always clobber a lower one.
>> +*/
>> +   i->supports_dvi = false;
>> +   i->supports_hdmi = false;
>> +   i->alternate_ddc_pin = 0;
>> +   }
>> +}
>> +
>> +static void sanitize_aux_ch(struct drm_i915_private *dev_priv,
>> +   enum port port)
>> +{
>> +   const struct ddi_vbt_port_info *info =
>> +   _priv->vbt.ddi_port_info[port];
>> +   enum port p;
>> +
>> +   if (!info->alternate_aux_channel)
>> +   return;
>> +
>> +   for_each_port_masked(p, (1 << port) - 1) {
>> +   struct ddi_vbt_port_info *i =
>> _priv->vbt.ddi_port_info[p];
>> +
>> +   if (info->alternate_aux_channel !=
>> i->alternate_aux_channel)
>> +   continue;
>> +
>> +   DRM_DEBUG_KMS("port %c trying to use the same AUX CH
>> (0x%x) as port %c, "
>> + "dis

Re: [Intel-gfx] [PATCH v3 3/4] drm/i915: Clean up DDI DDC/AUX CH sanitation

[Maarten Maathuis]

Also tested v3 on top of 4.8.3 (mainline git is a mess right now for
booting).

I did encounter a seemingly unrelated message during boot (including a
WARN_ON):
[drm:skylake_pfit_enable [i915]] *ERROR* Requesting pfit without getting a
scaler first

I suspect any causal relation with these patches.

On Mon, Oct 17, 2016 at 8:07 PM, <ville.syrj...@linux.intel.com> wrote:

> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>
> Now that we use the AUX and GMBUS assignment from VBT for all ports,
> let's clean up the sanitization of the port information a bit.
> Previosuly we only did this for port E, and only complained about a
> non-standard assignment for the other ports. But as we know that
> non-standard assignments are a fact of life, let's expand the
> sanitization to all the ports.
>
> v2: Include a commit message, fix up the comments a bit
> v3: Don't clobber other ports if the current port has no alternate aux
> ch/ddc pin
>
> Cc: sta...@vger.kernel.org
> Cc: Maarten Maathuis <madman2...@gmail.com>
> Tested-by: Maarten Maathuis <madman2...@gmail.com>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97877
> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
> Link: http://patchwork.freedesktop.org/patch/msgid/1476208368-
> 5710-4-git-send-email-ville.syrj...@linux.intel.com
> Reviewed-by: Jim Bride <jim.br...@linux.intel.com> (v2)
> ---
>  drivers/gpu/drm/i915/intel_bios.c | 122 --
> 
>  1 file changed, 77 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 83667e8cdd6b..a8ff8c099685 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1035,6 +1035,77 @@ static u8 translate_iboost(u8 val)
> return mapping[val];
>  }
>
> +static void sanitize_ddc_pin(struct drm_i915_private *dev_priv,
> +enum port port)
> +{
> +   const struct ddi_vbt_port_info *info =
> +   _priv->vbt.ddi_port_info[port];
> +   enum port p;
> +
> +   if (!info->alternate_ddc_pin)
> +   return;
> +
> +   for_each_port_masked(p, (1 << port) - 1) {
> +   struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[
> p];
> +
> +   if (info->alternate_ddc_pin != i->alternate_ddc_pin)
> +   continue;
> +
> +   DRM_DEBUG_KMS("port %c trying to use the same DDC pin
> (0x%x) as port %c, "
> + "disabling port %c DVI/HDMI support\n",
> + port_name(p), i->alternate_ddc_pin,
> + port_name(port), port_name(p));
> +
> +   /*
> +* If we have multiple ports supposedly sharing the
> +* pin, then dvi/hdmi couldn't exist on the shared
> +* port. Otherwise they share the same ddc bin and
> +* system couldn't communicate with them separately.
> +*
> +* Due to parsing the ports in alphabetical order,
> +* a higher port will always clobber a lower one.
> +*/
> +   i->supports_dvi = false;
> +   i->supports_hdmi = false;
> +   i->alternate_ddc_pin = 0;
> +   }
> +}
> +
> +static void sanitize_aux_ch(struct drm_i915_private *dev_priv,
> +   enum port port)
> +{
> +   const struct ddi_vbt_port_info *info =
> +   _priv->vbt.ddi_port_info[port];
> +   enum port p;
> +
> +   if (!info->alternate_aux_channel)
> +   return;
> +
> +   for_each_port_masked(p, (1 << port) - 1) {
> +   struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[
> p];
> +
> +   if (info->alternate_aux_channel !=
> i->alternate_aux_channel)
> +   continue;
> +
> +   DRM_DEBUG_KMS("port %c trying to use the same AUX CH
> (0x%x) as port %c, "
> + "disabling port %c DP support\n",
> + port_name(p), i->alternate_aux_channel,
> + port_name(port), port_name(p));
> +
> +   /*
> +* If we have multiple ports supposedlt sharing the
> +* aux channel, then DP couldn't exist on the shared
> +* port. Otherwise they share the same aux channel
> +* and system couldn't communicate with them separately.
> +*
> +  

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Respect alternate_ddc_pin for all DDI ports

[Maarten Maathuis]

Retested the _2 branch, works fine as well.

On Wed, Oct 12, 2016 at 12:57 PM, Ville Syrjälä <
ville.syrj...@linux.intel.com> wrote:

> On Tue, Oct 11, 2016 at 10:04:00PM +0200, Maarten Maathuis wrote:
> > My name does not include the word "show" (Tested-by tag).
>
> Sorry about that. Some copy-paste fail I suspect. I'll fix it up.
>
> And you actually tested the v1 patches, so I totally forgot to note that
> in the tested-by tags :( Care to re-test these v2 versions, just to make
> sure I didn't seriously fumble anything?
>
> >
> > On Tue, Oct 11, 2016 at 7:52 PM, <ville.syrj...@linux.intel.com> wrote:
> >
> > > From: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > >
> > > The VBT provides the platform a way to mix and match the DDI ports vs.
> > > GMBUS pins. Currently we only trust the VBT for DDI E, which I suppose
> > > has no standard GMBUS pin assignment. However, there are machines out
> > > there that use a non-standard mapping for the other ports as well.
> > > Let's start trusting the VBT on this one for all ports on DDI
> platforms.
> > >
> > > I've structured the code such that other platforms could easily start
> > > using this as well, by simply filling in the ddi_port_info. IIRC there
> > > may be CHV system that might actually need this.
> > >
> > > v2: Include a commit message, include a debug message during init
> > >
> > > Cc: sta...@vger.kernel.org
> > > Cc: Maarten Maathuis <madman2...@gmail.com>
> > > Tested-by: Maarten Maatt show huis <madman2...@gmail.com>
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97877
> > > Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_hdmi.c | 84 ++
> > > -
> > >  1 file changed, 48 insertions(+), 36 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > > b/drivers/gpu/drm/i915/intel_hdmi.c
> > > index 8d46f5836746..9ca86e901fc8 100644
> > > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > > @@ -1799,6 +1799,50 @@ intel_hdmi_add_properties(struct intel_hdmi
> > > *intel_hdmi, struct drm_connector *c
> > > intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> > >  }
> > >
> > > +static u8 intel_hdmi_ddc_pin(struct drm_i915_private *dev_priv,
> > > +enum port port)
> > > +{
> > > +   const struct ddi_vbt_port_info *info =
> > > +   _priv->vbt.ddi_port_info[port];
> > > +   u8 ddc_pin;
> > > +
> > > +   if (info->alternate_ddc_pin) {
> > > +   DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c (VBT)\n",
> > > + info->alternate_ddc_pin,
> port_name(port));
> > > +   return info->alternate_ddc_pin;
> > > +   }
> > > +
> > > +   switch (port) {
> > > +   case PORT_B:
> > > +   if (IS_BROXTON(dev_priv))
> > > +   ddc_pin = GMBUS_PIN_1_BXT;
> > > +   else
> > > +   ddc_pin = GMBUS_PIN_DPB;
> > > +   break;
> > > +   case PORT_C:
> > > +   if (IS_BROXTON(dev_priv))
> > > +   ddc_pin = GMBUS_PIN_2_BXT;
> > > +   else
> > > +   ddc_pin = GMBUS_PIN_DPC;
> > > +   break;
> > > +   case PORT_D:
> > > +   if (IS_CHERRYVIEW(dev_priv))
> > > +   ddc_pin = GMBUS_PIN_DPD_CHV;
> > > +   else
> > > +   ddc_pin = GMBUS_PIN_DPD;
> > > +   break;
> > > +   default:
> > > +   MISSING_CASE(port);
> > > +   ddc_pin = GMBUS_PIN_DPB;
> > > +   break;
> > > +   }
> > > +
> > > +   DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c (platform
> > > default)\n",
> > > + ddc_pin, port_name(port));
> > > +
> > > +   return ddc_pin;
> > > +}
> > > +
> > >  void intel_hdmi_init_connector(struct intel_digital_port
> *intel_dig_port,
> > >struct intel_connector *intel_connector)
> > >  {
> > > @

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Respect alternate_ddc_pin for all DDI ports

[Maarten Maathuis]

My name does not include the word "show" (Tested-by tag).

On Tue, Oct 11, 2016 at 7:52 PM, <ville.syrj...@linux.intel.com> wrote:

> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>
> The VBT provides the platform a way to mix and match the DDI ports vs.
> GMBUS pins. Currently we only trust the VBT for DDI E, which I suppose
> has no standard GMBUS pin assignment. However, there are machines out
> there that use a non-standard mapping for the other ports as well.
> Let's start trusting the VBT on this one for all ports on DDI platforms.
>
> I've structured the code such that other platforms could easily start
> using this as well, by simply filling in the ddi_port_info. IIRC there
> may be CHV system that might actually need this.
>
> v2: Include a commit message, include a debug message during init
>
> Cc: sta...@vger.kernel.org
> Cc: Maarten Maathuis <madman2...@gmail.com>
> Tested-by: Maarten Maatt show huis <madman2...@gmail.com>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97877
> Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/intel_hdmi.c | 84 ++
> -
>  1 file changed, 48 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 8d46f5836746..9ca86e901fc8 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1799,6 +1799,50 @@ intel_hdmi_add_properties(struct intel_hdmi
> *intel_hdmi, struct drm_connector *c
> intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
>  }
>
> +static u8 intel_hdmi_ddc_pin(struct drm_i915_private *dev_priv,
> +enum port port)
> +{
> +   const struct ddi_vbt_port_info *info =
> +   _priv->vbt.ddi_port_info[port];
> +   u8 ddc_pin;
> +
> +   if (info->alternate_ddc_pin) {
> +   DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c (VBT)\n",
> + info->alternate_ddc_pin, port_name(port));
> +   return info->alternate_ddc_pin;
> +   }
> +
> +   switch (port) {
> +   case PORT_B:
> +   if (IS_BROXTON(dev_priv))
> +   ddc_pin = GMBUS_PIN_1_BXT;
> +   else
> +   ddc_pin = GMBUS_PIN_DPB;
> +   break;
> +   case PORT_C:
> +   if (IS_BROXTON(dev_priv))
> +   ddc_pin = GMBUS_PIN_2_BXT;
> +   else
> +   ddc_pin = GMBUS_PIN_DPC;
> +   break;
> +   case PORT_D:
> +   if (IS_CHERRYVIEW(dev_priv))
> +   ddc_pin = GMBUS_PIN_DPD_CHV;
> +   else
> +   ddc_pin = GMBUS_PIN_DPD;
> +   break;
> +   default:
> +   MISSING_CASE(port);
> +   ddc_pin = GMBUS_PIN_DPB;
> +   break;
> +   }
> +
> +   DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c (platform
> default)\n",
> + ddc_pin, port_name(port));
> +
> +   return ddc_pin;
> +}
> +
>  void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
>struct intel_connector *intel_connector)
>  {
> @@ -1808,7 +1852,6 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
> struct drm_device *dev = intel_encoder->base.dev;
> struct drm_i915_private *dev_priv = to_i915(dev);
> enum port port = intel_dig_port->port;
> -   uint8_t alternate_ddc_pin;
>
> DRM_DEBUG_KMS("Adding HDMI connector on port %c\n",
>   port_name(port));
> @@ -1826,12 +1869,10 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
> connector->doublescan_allowed = 0;
> connector->stereo_allowed = 1;
>
> +   intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
> +
> switch (port) {
> case PORT_B:
> -   if (IS_BROXTON(dev_priv))
> -   intel_hdmi->ddc_bus = GMBUS_PIN_1_BXT;
> -   else
> -   intel_hdmi->ddc_bus = GMBUS_PIN_DPB;
> /*
>  * On BXT A0/A1, sw needs to activate DDIA HPD logic and
>  * interrupts to check the external panel connection.
> @@ -1842,46 +1883,17 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
> intel_encoder->hpd_pin = HPD_PORT_B;
> break

Re: [Intel-gfx] [i915] monitor is not detected unless it was active during boot

[Maarten Maathuis]

I checked both monitors, on displayport they work, on HDMI they share the
same trouble.

An interesting observation is that when plug the monitor into another
system which has an older nvidia card using nouveau (only HDMI is
available, card is too old for displayport).
It seems that the i2c connection is unreliable, sometimes more or less data
is retrieved, but never all of it seems, and sometimes none.

I wonder if there is some sensitivity to i2c speed.

My general observation of these monitors is that they are slow to turn on
on displayport (locking in a mode takes some time), but on hdmi it is
faster, is there some kind of throttling going on the displayport side that
is being ignored on the HDMI side?

[768542.009520] [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is
invalid, remainder is 254
[768542.009561] Raw EDID:
[768542.009575]   00 ff ff ff ff ff ff 00 4c 2d d0 0c 56 53 4d 30
[768542.009593]   20 19 01 03 80 34 1d 78 2a 12 55 a9 54 4d 9f 25
[768542.009610]   0c 50 54 bf ef 80 71 4f 81 00 81 c0 81 80 95 00
[768542.009626]   a9 c0 b3 00 01 01 08 e8 00 30 f2 70 5a 80 b0 58
[768542.009642]   8a 00 09 25 21 00 00 1e 00 00 00 fd 00 18 4b 1e
[768542.009658]   87 3c 00 0a 20 20 20 20 20 20 00 00 00 fc 00 55
[768542.009678]   32 34 45 38 35 30 0a 20 20 20 20 20 00 00 00 ff
[768542.009694]   00 48 54 48 47 38 30 30 30 30 35 0a 20 20 07 ff
[768542.010899] nouveau :01:00.0: DRM: DDC responded, but no EDID for
HDMI-A-1
[768578.474150] [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is
invalid, remainder is 157
[768578.474171] Raw EDID:
[768578.474178]   00 ff ff ff ff ff ff 00 4c 2d d0 0c 56 53 4d 30
[768578.474187]   20 19 01 03 80 34 1d 78 2a 12 55 a9 54 4d 9f 25
[768578.474195]   0c 50 54 bf ef ff ff ff ff ff ff ff ff ff ff ff
[768578.474202]   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[768578.474210]   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[768578.474218]   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[768578.474225]   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[768578.474233]   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[768578.475264] nouveau :01:00.0: DRM: DDC responded, but no EDID for
HDMI-A-1
[768590.904774] [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is
invalid, remainder is 181
[768590.904813] Raw EDID:
[768590.904826]   00 ff ff ff ff ff ff 00 4c 2d d0 0c 56 53 4d 30
[768590.904843]   20 19 01 03 80 34 1d 78 2a 12 55 a9 54 4d 9f 25
[768590.904860]   0c 50 54 bf ef 80 71 4f 81 00 81 c0 81 80 95 00
[768590.904876]   a9 c0 b3 00 01 01 08 e8 00 30 f2 70 5a 80 b0 58
[768590.904892]   8a 00 09 25 21 00 00 1e 00 00 00 fd 00 18 4b 1e
[768590.904908]   87 3c 00 0a 20 20 20 20 20 20 00 00 00 fc 00 55
[768590.904924]   32 34 45 38 35 30 0a 20 20 20 20 20 00 00 00 ff
[768590.904940]   00 48 54 48 47 38 30 30 30 30 35 0b ff ff ff ff
[768590.906012] nouveau :01:00.0: DRM: DDC responded, but no EDID for
HDMI-A-1

On Mon, Sep 19, 2016 at 9:50 PM, Maarten Maathuis <madman2...@gmail.com>
wrote:

> The previous messages are about using the HDMI connection of my monitor on
> the HDMI 2.0->DP bridge (whatever the formal name may be) of my motherboard,
>
> Using the HDMI 1.4 connection of my motherboard:
>
> [   55.744581] [drm:intel_get_hpd_pins] hotplug event received, stat
> 0x0040, dig 0x10101210, pins 0x0040
> [   55.744589] [drm:intel_hpd_irq_storm_detect] Received HPD interrupt on
> PIN 6 - cnt: 0
> [   55.744620] [drm:i915_hotplug_work_func] running encoder hotplug
> functions
> [   55.744625] [drm:i915_hotplug_work_func] Connector HDMI-A-2 (pin 6)
> received hotplug event.
> [   55.744629] [drm:intel_hdmi_detect] [CONNECTOR:46:HDMI-A-2]
> [   55.744915] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr:
> 0050 w(1)
> [   55.744922] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK on first
> message, retry
> [   55.745190] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr:
> 0050 w(1)
> [   55.745199] [drm:drm_do_probe_ddc_edid] drm: skipping non-existent
> adapter i915 gmbus dpc
> [   55.745469] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr:
> 0040 w(1)
> [   55.745476] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK on first
> message, retry
> [   55.745744] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpc] NAK for addr:
> 0040 w(1)
>
> As for my OS, i run archlinux:
> Linux main 4.7.4-1-ARCH #1 SMP PREEMPT Thu Sep 15 15:24:29 CEST 2016
> x86_64 GNU/Linux
>
> The requested VBT information is somewhere in here, I couldn't filter it
> since i couldn't see an end marker:
>
> [2.394379] [drm:intel_detect_pch] Found SunrisePoint PCH
> [2.394380] [drm:get_allowed_dc_mask] Allowed DC state mask 03
> [2.394768] [drm:i915_dump_device_info] i915 device info: gen=9,
> pciid=0x1912 rev=0x06 flags=need_gfx_hws,is_skylake,
> has_fbc,has_hotplug,has_llc,has_ddi,has_fpga_dbg,
> [  

Re: [Intel-gfx] [i915] monitor is not detected unless it was active during boot

[Maarten Maathuis]

46] [drm:drm_mode_debug_printmodeline] Modeline 97:"800x600" 75
49500 800 816 896 1056 600 601 604 625 0x40 0x5
[2.852251] [drm:drm_mode_debug_printmodeline] Modeline 98:"800x600" 72
5 800 856 976 1040 600 637 643 666 0x40 0x5
[2.852255] [drm:drm_mode_debug_printmodeline] Modeline 85:"800x600" 60
4 800 840 968 1056 600 601 605 628 0x40 0x5
[2.852260] [drm:drm_mode_debug_printmodeline] Modeline 86:"800x600" 56
36000 800 824 896 1024 600 601 603 625 0x40 0x5
[2.852265] [drm:drm_mode_debug_printmodeline] Modeline 100:"720x576" 50
27000 720 732 796 864 576 581 586 625 0x40 0xa
[2.852270] [drm:drm_mode_debug_printmodeline] Modeline 114:"720x480" 60
27027 720 736 798 858 480 489 495 525 0x40 0xa
[2.852274] [drm:drm_mode_debug_printmodeline] Modeline 101:"720x480" 60
27000 720 736 798 858 480 489 495 525 0x40 0xa
[2.852279] [drm:drm_mode_debug_printmodeline] Modeline 87:"640x480" 75
31500 640 656 720 840 480 481 484 500 0x40 0xa
[2.852284] [drm:drm_mode_debug_printmodeline] Modeline 88:"640x480" 73
31500 640 664 704 832 480 489 492 520 0x40 0xa
[2.852288] [drm:drm_mode_debug_printmodeline] Modeline 89:"640x480" 67
30240 640 704 768 864 480 483 486 525 0x40 0xa
[2.852293] [drm:drm_mode_debug_printmodeline] Modeline 113:"640x480" 60
25200 640 656 752 800 480 490 492 525 0x40 0xa
[2.852298] [drm:drm_mode_debug_printmodeline] Modeline 90:"640x480" 60
25175 640 656 752 800 480 490 492 525 0x40 0xa
[2.852303] [drm:drm_mode_debug_printmodeline] Modeline 91:"720x400" 70
28320 720 738 846 900 400 412 414 449 0x40 0x6
[2.852306] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:52:HDMI-A-3]
[2.852310] [drm:intel_hdmi_detect] [CONNECTOR:52:HDMI-A-3]
[2.852571] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpd] NAK for addr:
0050 w(1)
[2.852578] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpd] NAK on first
message, retry
[2.852916] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpd] NAK for addr:
0050 w(1)
[2.852927] [drm:drm_do_probe_ddc_edid] drm: skipping non-existent
adapter i915 gmbus dpd
[2.853240] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpd] NAK for addr:
0040 w(1)
[2.853243] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpd] NAK on first
message, retry
[2.853543] [drm:do_gmbus_xfer] GMBUS [i915 gmbus dpd] NAK for addr:
0040 w(1)
[2.853552] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:52:HDMI-A-3] status updated from unknown to disconnected
[2.853556] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:52:HDMI-A-3] disconnected
[2.853567] [drm:drm_setup_crtcs]
[2.853575] [drm:drm_enable_connectors] connector 37 enabled? yes
[2.853578] [drm:drm_enable_connectors] connector 43 enabled? no
[2.853582] [drm:drm_enable_connectors] connector 46 enabled? no
[2.853585] [drm:drm_enable_connectors] connector 48 enabled? yes
[2.853588] [drm:drm_enable_connectors] connector 52 enabled? no
[2.853596] [drm:intel_fb_initial_config] looking for cmdline mode on
connector DP-1
[2.853599] [drm:intel_fb_initial_config] looking for preferred mode on
connector DP-1 0
[2.853607] [drm:intel_fb_initial_config] connector DP-1 on pipe A
[CRTC:26]: 3840x2160
[2.853612] [drm:intel_fb_initial_config] connector HDMI-A-1 not
enabled, skipping
[2.853617] [drm:intel_fb_initial_config] connector HDMI-A-2 not
enabled, skipping
[2.853622] [drm:intel_fb_initial_config] looking for cmdline mode on
connector DP-2
[2.853626] [drm:intel_fb_initial_config] looking for preferred mode on
connector DP-2 0
[2.853729] [drm:intel_fb_initial_config] connector DP-2 on pipe B
[CRTC:30]: 3840x2160
[2.853733] [drm:intel_fb_initial_config] connector HDMI-A-3 not
enabled, skipping
[2.853738] [drm:drm_setup_crtcs] desired mode 3840x2160 set on crtc 26
(0,0)
[2.853742] [drm] Initialized i915 1.6.0 20160425 for :00:02.0 on
minor 0

On Mon, Sep 19, 2016 at 8:46 PM, Maarten Maathuis <madman2...@gmail.com>
wrote:

> And the normal output at bootup:
>
> [2.826131] [drm:drm_helper_probe_single_connector_modes]
> [CONNECTOR:48:DP-2]
> [2.826135] [drm:intel_dp_detect] [CONNECTOR:48:DP-2]
> [2.826645] [drm:intel_dp_get_dpcd] DPCD: 12 14 c4 01 01 15 00 01 00 00
> 04 00 0f 00 00
> [2.827032] [drm:intel_dp_get_dpcd] Display Port TPS3 support: source
> yes, sink yes
> [2.827038] [drm:intel_dp_print_rates] source rates: 162000, 216000,
> 27, 324000, 432000, 54
> [2.827043] [drm:intel_dp_print_rates] sink rates: 162000, 27,
> 54
> [2.827047] [drm:intel_dp_print_rates] common rates: 162000, 27,
> 54
> [2.827905] [drm:intel_dp_probe_mst] Sink is not MST capable
> [2.828350] [drm:drm_dp_i2c_do_msg] native defer
> [2.829760] [drm:drm_dp_i2c_do_msg] native defer
> [2.831102] [d

Re: [Intel-gfx] [i915] monitor is not detected unless it was active during boot

[Maarten Maathuis]

0 900 901 904 1000 0x40 0x5
[2.870360] [drm:drm_mode_debug_printmodeline] Modeline 92:"1280x1024"
75 135000 1280 1296 1440 1688 1024 1025 1028 1066 0x40 0x5
[2.870365] [drm:drm_mode_debug_printmodeline] Modeline 81:"1280x1024"
60 108000 1280 1328 1440 1688 1024 1025 1028 1066 0x40 0x5
[2.870370] [drm:drm_mode_debug_printmodeline] Modeline 82:"1440x900" 60
88750 1440 1488 1520 1600 900 903 909 926 0x40 0x9
[2.870375] [drm:drm_mode_debug_printmodeline] Modeline 80:"1280x800" 60
71000 1280 1328 1360 1440 800 803 809 823 0x40 0x9
[2.870380] [drm:drm_mode_debug_printmodeline] Modeline 79:"1152x864" 75
108000 1152 1216 1344 1600 864 865 868 900 0x40 0x5
[2.870384] [drm:drm_mode_debug_printmodeline] Modeline 77:"1280x720" 60
74250 1280 1390 1430 1650 720 725 730 750 0x40 0x5
[2.870389] [drm:drm_mode_debug_printmodeline] Modeline 112:"1280x720"
60 74176 1280 1390 1430 1650 720 725 730 750 0x40 0x5
[2.870394] [drm:drm_mode_debug_printmodeline] Modeline 102:"1280x720"
50 74250 1280 1720 1760 1980 720 725 730 750 0x40 0x5
[2.870399] [drm:drm_mode_debug_printmodeline] Modeline 93:"1024x768" 75
78750 1024 1040 1136 1312 768 769 772 800 0x40 0x5
[2.870404] [drm:drm_mode_debug_printmodeline] Modeline 94:"1024x768" 70
75000 1024 1048 1184 1328 768 771 777 806 0x40 0xa
[2.870408] [drm:drm_mode_debug_printmodeline] Modeline 95:"1024x768" 60
65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
[2.870413] [drm:drm_mode_debug_printmodeline] Modeline 96:"832x624" 75
57284 832 864 928 1152 624 625 628 667 0x40 0xa
[2.870418] [drm:drm_mode_debug_printmodeline] Modeline 97:"800x600" 75
49500 800 816 896 1056 600 601 604 625 0x40 0x5
[2.870423] [drm:drm_mode_debug_printmodeline] Modeline 98:"800x600" 72
5 800 856 976 1040 600 637 643 666 0x40 0x5
[2.870428] [drm:drm_mode_debug_printmodeline] Modeline 85:"800x600" 60
4 800 840 968 1056 600 601 605 628 0x40 0x5
[2.870433] [drm:drm_mode_debug_printmodeline] Modeline 86:"800x600" 56
36000 800 824 896 1024 600 601 603 625 0x40 0x5
[2.870437] [drm:drm_mode_debug_printmodeline] Modeline 100:"720x576" 50
27000 720 732 796 864 576 581 586 625 0x40 0xa
[2.870442] [drm:drm_mode_debug_printmodeline] Modeline 114:"720x480" 60
27027 720 736 798 858 480 489 495 525 0x40 0xa
[2.870447] [drm:drm_mode_debug_printmodeline] Modeline 101:"720x480" 60
27000 720 736 798 858 480 489 495 525 0x40 0xa
[2.870452] [drm:drm_mode_debug_printmodeline] Modeline 87:"640x480" 75
31500 640 656 720 840 480 481 484 500 0x40 0xa
[2.870456] [drm:drm_mode_debug_printmodeline] Modeline 88:"640x480" 73
31500 640 664 704 832 480 489 492 520 0x40 0xa
[2.870461] [drm:drm_mode_debug_printmodeline] Modeline 89:"640x480" 67
30240 640 704 768 864 480 483 486 525 0x40 0xa
[2.870466] [drm:drm_mode_debug_printmodeline] Modeline 113:"640x480" 60
25200 640 656 752 800 480 490 492 525 0x40 0xa
[2.870471] [drm:drm_mode_debug_printmodeline] Modeline 90:"640x480" 60
25175 640 656 752 800 480 490 492 525 0x40 0xa
[2.870475] [drm:drm_mode_debug_printmodeline] Modeline 91:"720x400" 70
28320 720 738 846 900 400 412 414 449 0x40 0x6


On Mon, Sep 19, 2016 at 8:39 PM, Maarten Maathuis <madman2...@gmail.com>
wrote:

> Hi,
>
> I have a monitor, that when connected a skylake system, doesn't ever come
> up when hotplugging or after resume. The "bios" seems to not have problems
> bringing it up, even at the native 3840x2160 resolution, and when it works,
> all modes are correctly read (checked via xrandr).
>
> I tried both the HMDI 1.4 port, as well as the DP 1.2 -> HDMI 2.0 built in
> conversion chip.
>
> This is the dmesg output I have when plugging in this monitor, the DP-2
> connector is the one that should be detected.
>
> Any advice on how to proceed?
>
> Please be aware I am not subscribed to this mailing list, so please reply
> to me directly as well.
>
> Maarten.
>
> [ 1634.666165] [drm:intel_get_hpd_pins] hotplug event received, stat
> 0x0080, dig 0x10121010, pins 0x0080
> [ 1634.666179] [drm:intel_hpd_irq_handler] digital hpd port D - long
> [ 1634.666183] [drm:intel_hpd_irq_storm_detect] Received HPD interrupt on
> PIN 7 - cnt: 0
> [ 1634.666229] [drm:intel_dp_hpd_pulse] got hpd irq on port D - long
> [ 1634.666253] [drm:i915_hotplug_work_func] running encoder hotplug
> functions
> [ 1634.666258] [drm:i915_hotplug_work_func] Connector DP-2 (pin 7)
> received hotplug event.
> [ 1634.666261] [drm:intel_dp_detect] [CONNECTOR:48:DP-2]
> [ 1634.666273] [drm:i915_hotplug_work_func] Connector HDMI-A-3 (pin 7)
> received hotplug event.
> [ 1634.666284] [drm:intel_hdmi_detect

[Intel-gfx] [i915] monitor is not detected unless it was active during boot

[Maarten Maathuis]

Hi,

I have a monitor, that when connected a skylake system, doesn't ever come
up when hotplugging or after resume. The "bios" seems to not have problems
bringing it up, even at the native 3840x2160 resolution, and when it works,
all modes are correctly read (checked via xrandr).

I tried both the HMDI 1.4 port, as well as the DP 1.2 -> HDMI 2.0 built in
conversion chip.

This is the dmesg output I have when plugging in this monitor, the DP-2
connector is the one that should be detected.

Any advice on how to proceed?

Please be aware I am not subscribed to this mailing list, so please reply
to me directly as well.

Maarten.

[ 1634.666165] [drm:intel_get_hpd_pins] hotplug event received, stat
0x0080, dig 0x10121010, pins 0x0080
[ 1634.666179] [drm:intel_hpd_irq_handler] digital hpd port D - long
[ 1634.666183] [drm:intel_hpd_irq_storm_detect] Received HPD interrupt on
PIN 7 - cnt: 0
[ 1634.666229] [drm:intel_dp_hpd_pulse] got hpd irq on port D - long
[ 1634.666253] [drm:i915_hotplug_work_func] running encoder hotplug
functions
[ 1634.666258] [drm:i915_hotplug_work_func] Connector DP-2 (pin 7) received
hotplug event.
[ 1634.666261] [drm:intel_dp_detect] [CONNECTOR:48:DP-2]
[ 1634.666273] [drm:i915_hotplug_work_func] Connector HDMI-A-3 (pin 7)
received hotplug event.
[ 1634.666284] [drm:intel_hdmi_detect] [CONNECTOR:52:HDMI-A-3]
[ 1634.769941] [drm:intel_hdmi_detect] HDMI live status down
[ 1640.748356] [drm:intel_get_hpd_pins] hotplug event received, stat
0x0080, dig 0x10121010, pins 0x0080
[ 1640.748369] [drm:intel_hpd_irq_handler] digital hpd port D - long
[ 1640.748373] [drm:intel_hpd_irq_storm_detect] Received HPD interrupt on
PIN 7 - cnt: 0
[ 1640.748416] [drm:intel_dp_hpd_pulse] got hpd irq on port D - long
[ 1640.756938] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.765400] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.773936] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.782410] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.790910] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.799389] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.807907] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.816409] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.824895] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.833427] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.841915] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.850426] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.858919] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.867423] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.875924] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.884424] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.892899] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.901454] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.910008] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.918494] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.926994] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.935486] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.943982] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.952461] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.960971] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.969459] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.978003] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.986482] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1640.994973] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.003497] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.011986] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.020504] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.020506] [drm:drm_dp_dpcd_access] too many retries, giving up
[ 1641.020528] [drm:i915_hotplug_work_func] running encoder hotplug
functions
[ 1641.020529] [drm:i915_hotplug_work_func] Connector DP-2 (pin 7) received
hotplug event.
[ 1641.020530] [drm:intel_dp_detect] [CONNECTOR:48:DP-2]
[ 1641.029054] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.037563] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.046092] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.054583] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.063076] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.071567] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.080094] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.088568] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[ 1641.097054] 

[Intel-gfx] Hardlock problems when switching monitor channels and questions (Skylake)

[Maarten Maathuis]

Hi everyone.

I've been some hardlock problems when switching from the HDMI connection of
my monitor (connected to another PC) and the displayport (connected to the
problematic PC), several times a week at least.

In an effort to narrow down the problem I've been tried looking at drm
modeset debug information, as well try catch something with netconsole.
Neither have pointed me the root cause yet, but i do have some observations
that I cannot put into place yet and would like some feedback on prior to
opening a bug report.

My mainbord is: Asrock Fatal1ty Z170 Gaming-ITX/ac
My CPU is: Intel i7 6700
My monitor is: Samsung U24E850, equiped with both displayport 1.2 and HDMI
2.0

Kernel version: 4.3-RC7

The display connections on the mainbord are:
- DP 1.2
- HDMI 1.4
- HDMI 2.0 via DP 1.2 (recognized as DP by driver)

I notice some funny things I would like some feedback on.

1. The EDID retrieval doesn't always succeed, i've noticed this sometimes
by running "xrandr" after starting up. I've also noticed it after rebooting
from a hard lock that it goes into 1024x768 resolution instead of
3840x2160, it takes another reboot to get it right. As if it relies on the
resolution the boot used? How to troubleshoot this?

2. I notice that the driver thinks there are 3 HDMI connections, 2 of which
seem to share the same hotplug pin as the 2 DP connections, what is going
here? Could this cause trouble? The fake HDMI connections seem always to
fail edid retrieval, but I'm not a 100% sure if this also happens in the
hardlock situation (no evidence yet).

3. Switching between HDMI and DP channel on my monitor sometimes results in
a hotplug event and sometimes it does not? Any idea why this happens? I'm
curious about this because the hardlocks occur after spending a few hours
on the HDMI channel typically.

Anything I should be looking for before going down the route of a bug
report?

Sincerely,

Maarten.

P.S. I'm not subscribed to this mailinglist, so please CC me.

-- 
Far away from the primal instinct, the song seems to fade away, the river
get wider between your thoughts and the things we do and say.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: cannot find -lX11

[Maarten Maathuis]

Have you attempted to locate libX11.so in your filesystem?

On Mon, Mar 16, 2015 at 11:13 AM, Roy Schofield r...@caistor.net wrote:

  Hi,
 Grateful for some help and/or assistance with X11 configuration on
 LinuxMint 17 Cinnamon.

 I have just upgraded from Linuxmint 16 Petra to LinuxMint 17 Cinnamon and
 have a problem compiling/linking  a program with Marinas-ide which is a
 dbase/clipper compiler. All worked fine with Linuxmint 16 but now get the
 following error when compiling/linking an existing source program. The
 error is as follows:

 == Linking to make /home/roy/Marinas_Progs/Invoice_print ...

 /usr/bin/gcc -o/home/roy/Marinas_Progs/Invoice_print
 -L/home/roy/marinas-ide/gui/lib -L/home/roy/marinas-ide/harbour/lib
 -L/home/roy/marinas-ide/qt/lib -L/usr/lib
 /home/roy/Marinas_Progs/__mih_obj_m3gh/Invoice_print.o
 /home/roy/Marinas_Progs/__mih_obj_m3gh/Invoice_print_mg_hbmk2_cpp_functions_.o
 -Wl,--start-group -lmarinas-gui -lxhb -lhbct -lsupc++ -lhbextern -lhbdebug
 -lhbvm -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd -lgttrm -lgtxwc
 -lhbrdd -lhbuddall -lhbusrrdd -lrddntx -lrddcdx -lrddnsx -lrddfpt -lhbrdd
 -lhbhsx -lhbsix -lhbmacro -lhbcplr -lhbpp -lhbcommon -lm -ldl -lrt -lhbmzip
 -lminizip -lhbziparc -lhbzlib -lhbtip -lhbxdiff -lxdiff -lhbpcre -lhbzebra
 -lhbmxml -lmxml -lhbcairo -lhbcurl
 /home/roy/marinas-ide/libcurl-gnutls.so.4
 /home/roy/marinas-ide/libldap_r-2.4.so.2.5.6
 /home/roy/marinas-ide/liblber-2.4.so.2.5.6
 /home/roy/marinas-ide/libsasl2.so.2.0.23 -lhbmysql
 /home/roy/marinas-ide/libmysqlclient.so.16 -lhbssl -lhbqtcore -lhbqtgui
 -lhbqtnetwork -lhbqtwebkit -Wl,--end-group -lQt5Core -lQt5Gui -lQt5Network
 -lQt5WebKit -lQt5XmlPatterns -lQt5PrintSupport -lQt5WebKitWidgets
 -lQt5Widgets -lX11 -lX11

 /usr/bin/ld: cannot find -lX11


 Kind regards
 Roy

 --
 Working to achieve the long term economic sustainability of Caistor in 
 Lincolnshire by preserving, restoring and enhancing the historical, 
 architectural and cultural heritage of the town. For further information go 
 to http://www.caistor.net


 ___
 xorg@lists.x.org: X.Org support
 Archives: http://lists.freedesktop.org/archives/xorg
 Info: http://lists.x.org/mailman/listinfo/xorg
 Your subscription address: %(user_address)s




-- 
Far away from the primal instinct, the song seems to fade away, the river
get wider between your thoughts and the things we do and say.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

[REGRESSION] system does not resume from ram due to commit "drm/nv50/fifo: prevent races between clients updating playlists"

[Maarten Maathuis]

My NV96 does not resume from suspend to ram (the screen stays black, magic
sysrq keys do work) with the current linus git kernel, i bisected it to the
following commit.

drm/nv50/fifo: prevent races between clients updating playlists
b5096566f6e1ee2b88324772f020ae9bc0cfa9a0

It's not obvious to me how this causes problems, but reverting this commit
does solve my problem.
-- 
Far away from the primal instinct, the song seems to fade away, the river
get wider between your thoughts and the things we do and say.
-- next part --
An HTML attachment was scrubbed...
URL: 

[REGRESSION] system does not resume from ram due to commit drm/nv50/fifo: prevent races between clients updating playlists

[Maarten Maathuis]

My NV96 does not resume from suspend to ram (the screen stays black, magic
sysrq keys do work) with the current linus git kernel, i bisected it to the
following commit.

drm/nv50/fifo: prevent races between clients updating playlists
b5096566f6e1ee2b88324772f020ae9bc0cfa9a0

It's not obvious to me how this causes problems, but reverting this commit
does solve my problem.
-- 
Far away from the primal instinct, the song seems to fade away, the river
get wider between your thoughts and the things we do and say.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: (*pDamage-damageMarker) Crashes

[Maarten Maathuis]

On Sun, Jan 27, 2013 at 2:31 PM, prudhvi raj prudhvira...@gmail.com wrote:
 In Xorg-1.12.0, in a random scenario Xorg server crashes in
 damageRegionProcessPending (DrawablePtr pDrawable)
 {src/miext/damage/damage.c} when the (*pDamage-damageMarker) call is made.

 /* submit damage marker whenever possible. */
 if (pDamage-damageMarker)
 (*pDamage-damageMarker) (pDrawable, pDamage, pDamage-backupDamage,
 pDamage-pendingDamage, pDamage-closure);

 But pDamage-damageMarker is initialized with NULL in DamageCreate function,
 and there after no explicit function assignment is found in the source. Not
 clear who has assigned a valid function to pDamage-damageMarker.

 This (*pDamage-damageMarker) call crashes explicitly when it a call
 initiated from CloseDownClient () calls this.

 Can some one throw any light, on the purpose of pDamage-damageMarker
 function and what is it supposed to do? and who should be using it?

 ___
 xorg@lists.x.org: X.Org support
 Archives: http://lists.freedesktop.org/archives/xorg
 Info: http://lists.x.org/mailman/listinfo/xorg
 Your subscription address: madman2...@gmail.com

When i say your mail i vaguely remembered something, and it seems that
i wrote this support
(http://cgit.freedesktop.org/xorg/xserver/commit/?id=974db58f5b730c3770ee461665a02dd4334d1dea)
based on an idea that i had back then. But it you need a video driver
to actually activate this functionality. So you should check the
sourcecode of the driver that you are using if you can. To be honest i
don't know if anyone actually used this.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: Adding rotation to xf86-video-omapfb

[Maarten Maathuis]

On Fri, Dec 28, 2012 at 3:50 AM, Daniel Stone dan...@fooishbar.org wrote:
 Hi,


 On 28 December 2012 01:08, Maarten Maathuis madman2...@gmail.com wrote:

 As far as i remember you typically allocate a shadow (there are some
 driver hooks for that, check existing drivers like intel, radeon or
 nouveau). This will become the new scanout buffer and this has the
 rotated dimensions. The original rendering will still be done to the
 normal framebuffer. Composite with rotation in combination with
 damage (a system used in X to track what areas have been rendered to
 i.e. damaged) is used to keep the shadow up to date.

 You should probably implement the shadow hooks that are present in the
 crtc structure. You should make sure this shadow allocation gets used
 as the framebuffer. And you should check if your composite
 implementation supports rotation, if not it may be necessary to expand
 it with support for any scaling/rotation matrix or else add a special
 case for 90 degree rotation if your hardware supports that.


 As you can see from the linked diff, the fbdev driver implements rotation as
 the hardware can do it on scanout.  It also doesn't support any
 acceleration, given that OMAP carries an SGX, so neither the shadow nor
 Composite hooks are relevant here.

 Cheers,
 Daniel

The shadow + composite rotation seems to be contained in
xf86CrtcRotate function (that would be called from the set_mode_major
driver hook by drivers that want it), so you can avoid that.

To the best of my knowledge (since i can find no sign of rotating
modes) the hardware (typically) continues to be driven at the original
mode (for example 1280x1024). The X root window is resized to match
the new swapped dimensions (for example 1024x1280) and the driver is
left to make sure the content ends up in the right way.

In your case you probably get a frontbuffer with the swapped size
(1024x1280 for example), but the mode you get is 1280x1024 probably.

I think your approach of swapped width and height was a good idea (if
the kernel interface of omapfb defines that behavior) , but you have
to find out if the driver reads back those values you send to omapfb.
Because somewhere those internal details are showing up in xrandr. My
guess is you have to mangle it back in OMAPFBOutputGetModes() based on
the rotation mode.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Adding rotation to xf86-video-omapfb

[Maarten Maathuis]

On Thu, Dec 27, 2012 at 8:48 PM, Denis 'GNUtoo' Carikli
gnu...@no-log.org wrote:
 Hi,

 I've been trying to add rotation to the out of tree
 xf86-video-omapfb(I'm aware of xf86-video-omap but I've an omap3, and
 beside, it requires a staging kernel driver).

 So far I got rotation working(xrandr -o 1 works).

 But when I want to rotate back (xrandr -o 0) Xorg checks if the
 requested X resolution is smaller or equals to the masimum allowed
 Xresolution and it fails...

 The thing is that I've been using a hack to make it work:
 instead of keeping the same resolution and just making rotate the
 display content, I've changed the resolution too.

 My device is the GTA04 and it has a 480x640 display, so when rotating a
 new mode is created(640x480):
 root@om-gta04:~# xrandr -q
 Screen 0: minimum 8 x 8, current 640 x 480, maximum 480 x 640
 LCD connected 640x480+0+0 left (normal left inverted right x axis y
 axis) 0mm x 0mm
640x48066.8 +
   480x640 (0x41)   22.2MHz
 h: width   480 start  504 end  512 total  520 skew0 clock
 42.6KHz
 v: height  640 start  644 end  646 total  648   clock
 65.7Hz

 This shouldn't happen and instead I should use the normal approach,
 which is not to change the resolution...

 But that fails too: My display is in portrait mode, and so when
 rotating the image changes to 640x480, from the point 0.0 and isn't
 rotated, which result in the image going over the physical screen
 dimentions...

 The code I've been developing is here:
 https://gitorious.org/gnutoo-s-programs-for-shr/xf86-video-omapfb/commit/834a2b938cbff98e6f69ff66789cf422e3e2d483

 I'd like to make the correct way work and rotate, but I've no idea of
 how...

 Denis.
 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel

As far as i remember you typically allocate a shadow (there are some
driver hooks for that, check existing drivers like intel, radeon or
nouveau). This will become the new scanout buffer and this has the
rotated dimensions. The original rendering will still be done to the
normal framebuffer. Composite with rotation in combination with
damage (a system used in X to track what areas have been rendered to
i.e. damaged) is used to keep the shadow up to date.

You should probably implement the shadow hooks that are present in the
crtc structure. You should make sure this shadow allocation gets used
as the framebuffer. And you should check if your composite
implementation supports rotation, if not it may be necessary to expand
it with support for any scaling/rotation matrix or else add a special
case for 90 degree rotation if your hardware supports that.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: Adding rotation to xf86-video-omapfb

[Maarten Maathuis]

On Fri, Dec 28, 2012 at 2:08 AM, Maarten Maathuis madman2...@gmail.com wrote:
 On Thu, Dec 27, 2012 at 8:48 PM, Denis 'GNUtoo' Carikli
 gnu...@no-log.org wrote:
 Hi,

 I've been trying to add rotation to the out of tree
 xf86-video-omapfb(I'm aware of xf86-video-omap but I've an omap3, and
 beside, it requires a staging kernel driver).

 So far I got rotation working(xrandr -o 1 works).

 But when I want to rotate back (xrandr -o 0) Xorg checks if the
 requested X resolution is smaller or equals to the masimum allowed
 Xresolution and it fails...

 The thing is that I've been using a hack to make it work:
 instead of keeping the same resolution and just making rotate the
 display content, I've changed the resolution too.

 My device is the GTA04 and it has a 480x640 display, so when rotating a
 new mode is created(640x480):
 root@om-gta04:~# xrandr -q
 Screen 0: minimum 8 x 8, current 640 x 480, maximum 480 x 640
 LCD connected 640x480+0+0 left (normal left inverted right x axis y
 axis) 0mm x 0mm
640x48066.8 +
   480x640 (0x41)   22.2MHz
 h: width   480 start  504 end  512 total  520 skew0 clock
 42.6KHz
 v: height  640 start  644 end  646 total  648   clock
 65.7Hz

 This shouldn't happen and instead I should use the normal approach,
 which is not to change the resolution...

 But that fails too: My display is in portrait mode, and so when
 rotating the image changes to 640x480, from the point 0.0 and isn't
 rotated, which result in the image going over the physical screen
 dimentions...

 The code I've been developing is here:
 https://gitorious.org/gnutoo-s-programs-for-shr/xf86-video-omapfb/commit/834a2b938cbff98e6f69ff66789cf422e3e2d483

 I'd like to make the correct way work and rotate, but I've no idea of
 how...

 Denis.
 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel

 As far as i remember you typically allocate a shadow (there are some
 driver hooks for that, check existing drivers like intel, radeon or
 nouveau). This will become the new scanout buffer and this has the
 rotated dimensions. The original rendering will still be done to the
 normal framebuffer. Composite with rotation in combination with
 damage (a system used in X to track what areas have been rendered to
 i.e. damaged) is used to keep the shadow up to date.

 You should probably implement the shadow hooks that are present in the
 crtc structure. You should make sure this shadow allocation gets used
 as the framebuffer. And you should check if your composite
 implementation supports rotation, if not it may be necessary to expand
 it with support for any scaling/rotation matrix or else add a special
 case for 90 degree rotation if your hardware supports that.

 --
 Far away from the primal instinct, the song seems to fade away, the
 river get wider between your thoughts and the things we do and say.

I forgot to mention that decision/logic for the shadow allocation is
done inside the xserver, so it's not a choice you have.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[Nouveau] Reproducible PGRAPH TLB flush timeout hang on NV96

[Maarten Maathuis]

Hi everyone,

I was wondering what to do to dig into this problem further.The kernel
is several weeks old (nouveau tree), it's at commit
000463f13fba6b2f94a5bfcb0d615751ae9c34a0.

As you can see from the mesages below the problem is reproducable to
the point of getting exactly the same error.

Nov 25 17:57:51 madman kernel: [548360.773743] nouveau E[
PGRAPH][:01:00.0] PGRAPH TLB flush idle timeout fail: 0x019ffe03
0x00145009 0x102d 0x0034db43
Nov 25 19:34:09 madman kernel: [ 5623.952688] nouveau E[
PGRAPH][:01:00.0] PGRAPH TLB flush idle timeout fail: 0x019ffe03
0x00145009 0x102d 0x0034db43
Nov 25 22:54:47 madman kernel: [ 7854.679007] nouveau E[
PGRAPH][:01:00.0] PGRAPH TLB flush idle timeout fail: 0x019ffe03
0x00145009 0x102d 0x0034db43
Nov 25 23:04:33 madman kernel: [  540.388597] nouveau E[
PGRAPH][:01:00.0] PGRAPH TLB flush idle timeout fail: 0x019ffe03
0x00145009 0x102d 0x0034db43

I also updated the kernel to latest because it has the improved parsing:

Nov 25 23:42:57 madman kernel: [  169.014553] nouveau E[
PGRAPH][:01:00.0] PGRAPH_STATUS  : 0x019ffe03 BUSY DISPATCH VFETCH
CCACHE_UNK4 STRMOUT_GSCHED_UNK5 UNK14XX UNK24XX_CSCHED UNK1CXX CLIPID
ZCULL ENG2D UNK34XX TPRAST TPROP MP ROP
Nov 25 23:42:57 madman kernel: [  169.014564] nouveau E[
PGRAPH][:01:00.0] PGRAPH_VSTATUS0: 0x00145009 VFETCH CCACHE
Nov 25 23:42:57 madman kernel: [  169.014569] nouveau E[
PGRAPH][:01:00.0] PGRAPH_VSTATUS1: 0x102d MP
Nov 25 23:42:57 madman kernel: [  169.014573] nouveau E[
PGRAPH][:01:00.0] PGRAPH_VSTATUS2: 0x0034db43 ENG2D ROP

Do you have any ideas to find out what is causing this?

Sincerely,

Maarten.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Reproducible PGRAPH TLB flush timeout hang on NV96

[Maarten Maathuis]

On Mon, Nov 26, 2012 at 7:04 PM, Marcin Slusarz
marcin.slus...@gmail.com wrote:
 On Sun, Nov 25, 2012 at 11:50:50PM +0100, Maarten Maathuis wrote:
 Hi everyone,

 I was wondering what to do to dig into this problem further.The kernel
 is several weeks old (nouveau tree), it's at commit
 000463f13fba6b2f94a5bfcb0d615751ae9c34a0.

 As you can see from the mesages below the problem is reproducable to
 the point of getting exactly the same error.

 You missed the most important information - how do you reproduce it?
 :)

 Marcin

A specific savegame for a game called freeorion which causes the
problem within one turn typically, if you are interested in it i can
dig it up.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Reproducible PGRAPH TLB flush timeout hang on NV96

[Maarten Maathuis]

On Mon, Nov 26, 2012 at 8:28 PM, Marcin Slusarz
marcin.slus...@gmail.com wrote:
 On Mon, Nov 26, 2012 at 08:16:17PM +0100, Maarten Maathuis wrote:
 On Mon, Nov 26, 2012 at 7:04 PM, Marcin Slusarz
 marcin.slus...@gmail.com wrote:
  On Sun, Nov 25, 2012 at 11:50:50PM +0100, Maarten Maathuis wrote:
  Hi everyone,
 
  I was wondering what to do to dig into this problem further.The kernel
  is several weeks old (nouveau tree), it's at commit
  000463f13fba6b2f94a5bfcb0d615751ae9c34a0.
 
  As you can see from the mesages below the problem is reproducable to
  the point of getting exactly the same error.
 
  You missed the most important information - how do you reproduce it?
  :)
 
  Marcin

 A specific savegame for a game called freeorion which causes the
 problem within one turn typically, if you are interested in it i can
 dig it up.

 Apitrace log could be useful - if you can reproduce hang with retrace.

 Marcin

I can't even get it to run with apitrace (tried even with git master):

apitrace: redirecting dlopen(libGL.so.1, 0x102)
nv50_screen_get_param:181 - unknown PIPE_CAP 76
apitrace: warning: caught signal 11
apitrace: ignoring exception while tracing

For some reason i can't catch it with gdb, the process always exits
and then i cannot get a backtrace.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[PATCH 2/2] Add 2-level GPUVM pagetables support to radeon driver. v2

[Maarten Maathuis]

On Fri, Sep 14, 2012 at 7:49 PM, Dmitry Cherkasov  
wrote:
> +#define RADEON_PT_OFFSET(_rdev) \
> +   (RADEON_GPU_PAGE_ALIGN(RADEON_TOTAL_PDE_COUNT(rdev) * 
> RADEON_PDE_SIZE))

Shouldn't that be _rdev too?

Also a few lines above that you use rdev instead of _rdev.

I didn't check the whole thing, just noticed that when i was staring
at it for no reason :-)

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: [PATCH 2/2] Add 2-level GPUVM pagetables support to radeon driver. v2

[Maarten Maathuis]

On Fri, Sep 14, 2012 at 7:49 PM, Dmitry Cherkasov  wrote:
> +#define RADEON_PT_OFFSET(_rdev) \
> +   (RADEON_GPU_PAGE_ALIGN(RADEON_TOTAL_PDE_COUNT(rdev) * 
> RADEON_PDE_SIZE))

Shouldn't that be _rdev too?

Also a few lines above that you use rdev instead of _rdev.

I didn't check the whole thing, just noticed that when i was staring
at it for no reason :-)

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] Add 2-level GPUVM pagetables support to radeon driver. v2

[Maarten Maathuis]

On Fri, Sep 14, 2012 at 7:49 PM, Dmitry Cherkasov dcherkas...@gmail.com wrote:
 +#define RADEON_PT_OFFSET(_rdev) \
 +   (RADEON_GPU_PAGE_ALIGN(RADEON_TOTAL_PDE_COUNT(rdev) * 
 RADEON_PDE_SIZE))

Shouldn't that be _rdev too?

Also a few lines above that you use rdev instead of _rdev.

I didn't check the whole thing, just noticed that when i was staring
at it for no reason :-)

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] Add 2-level GPUVM pagetables support to radeon driver. v2

[Maarten Maathuis]

On Fri, Sep 14, 2012 at 7:49 PM, Dmitry Cherkasov dcherkas...@gmail.com wrote:
 +#define RADEON_PT_OFFSET(_rdev) \
 +   (RADEON_GPU_PAGE_ALIGN(RADEON_TOTAL_PDE_COUNT(rdev) * 
 RADEON_PDE_SIZE))

Shouldn't that be _rdev too?

Also a few lines above that you use rdev instead of _rdev.

I didn't check the whole thing, just noticed that when i was staring
at it for no reason :-)

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Does Xorg'x XRender implementation support better-than-bilinear interpolation?

[Maarten Maathuis]

On Mon, Sep 10, 2012 at 11:05 PM, Clemens Eisserer linuxhi...@gmail.com wrote:
 Hi,

 I just realized that at least on my machine (fedora 17 + intel 20.2),
 the only interpolation modes offered by Xrender are: {nearest ,
 bilinear , convolution, fast , good, best}
 I always thought best translates into something better than bilinear,
 but it seems to be just equal to it.

 Is there any way to archive bicubic interpolation or any other
 higher-than-bilinear interpolation using xrender?
 As Java2D offers bicubic interpolation, it would mean a fallback to
 software-rendering every time a program requests high-quality
 interpolation.

 Thank you in advance, Clemens
 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel

I don't see it in the renderproto, so it's probably not possible
without a spec extension.

http://cgit.freedesktop.org/xorg/proto/renderproto/tree/render.h

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [Nouveau] [PATCH 10/10] drm/nouveau: fix off-by-one bugs related to command submission in IB mode

[Maarten Maathuis]

On Mon, Aug 20, 2012 at 11:41 PM, Marcin Slusarz
marcin.slus...@gmail.com wrote:
 On Tue, Aug 21, 2012 at 07:13:23AM +1000, Ben Skeggs wrote:
Am Dienstag, 21. August 2012 schrieb Marcin Slusarz :

  On Mon, Aug 20, 2012 at 04:33:24PM +1000, Ben Skeggs wrote:
   On Sun, Aug 19, 2012 at 11:02:00PM +0200, Marcin Slusarz wrote:
Commit drm/nouveau: port all engines to new engine module
  format changed
IB size calculation to be less wasteful, but didn't take into
  account already
existing off-by-one bugs :).
   
So:
- ib_max is the last entry, so we need to +1 when calculating
  number of
  free entries
- nv50_dma_wait already does +1 (for FIRE_RING), so we don't
  need another +1
  on nouveau_gem_ioctl_pushbuf side
- there are 512 allocated IB entries (and it needs to be round
  number), so we
  can accept at most 511 entries from userspace (we need one for
  FIRE_RING) -
  fortunately userspace already flushes at 511, so nr_push check
  change won't
  have any impact
   Also skipped this patch for now as I have work in progress that
  will improve this and
   related code.  I should have it in the tree soon.
  Maybe I should have written this in the changelog, but this patch
  fixes total
  mayhem seen in warsow and nexuiz (at least). It's better to
  integrate it sooner
  than later.

I presume bumping the IB size to 8KiB also helps?

 Yes, my first patch did exactly this and it worked.

 However, Maarten can still reproduce this bug, so my patch is not completely
 correct. I discovered that RING_SPACE calls nouveau_dma_wait with slots=1 and
 nv50_dma_wait increases it again, so we need to move +1 from nv50_dma_wait
 to nouveau_gem_ioctl_pushbuf. But once I do this everything explodes, because
 we do 2 FIRE_RING's (one from fence_emit, and one from nv50_dma_wait), so...

I prefer this in the
meantime, and it's probably best to do anyway, I didn't take into
account what we allow userspace to do in one shot.  If this works too,
i'll push that change this morning.

 ... it's probably a good idea to do this and forget about the problem.

I did try and reproduce on a couple of cards with warsow and wasn't
able to.

 Nexuiz is even better. It draws artifacts immediately after demo start.

Also, what happened to instmem being the culprit here?

 It was bad bisection. Once I knew what is the problem, I verified
 drm/nouveau: port all engines to new engine module format is the first
 bad commit.

 Marcin
 ___
 Nouveau mailing list
 Nouveau@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/nouveau

One thing, i think FIRE_RING should check for available ib slots,
currently it doesn't and that seems a bit dangerous. Just a thought
for Ben :-)

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 10/10] drm/nouveau: fix off-by-one bugs related to command submission in IB mode

[Maarten Maathuis]

On Sun, Aug 19, 2012 at 11:02 PM, Marcin Slusarz
marcin.slus...@gmail.com wrote:
 Commit drm/nouveau: port all engines to new engine module format changed
 IB size calculation to be less wasteful, but didn't take into account already
 existing off-by-one bugs :).

 So:
 - ib_max is the last entry, so we need to +1 when calculating number of
   free entries
 - nv50_dma_wait already does +1 (for FIRE_RING), so we don't need another +1
   on nouveau_gem_ioctl_pushbuf side
 - there are 512 allocated IB entries (and it needs to be round number), so we
   can accept at most 511 entries from userspace (we need one for FIRE_RING) -
   fortunately userspace already flushes at 511, so nr_push check change won't
   have any impact

 Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
 ---
  drivers/gpu/drm/nouveau/nouveau_chan.c |2 +-
  drivers/gpu/drm/nouveau/nouveau_dma.c  |2 +-
  drivers/gpu/drm/nouveau/nouveau_gem.c  |4 ++--
  3 files changed, 4 insertions(+), 4 deletions(-)

 diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c 
 b/drivers/gpu/drm/nouveau/nouveau_chan.c
 index fd15ebf..d0c0271 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_chan.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
 @@ -318,7 +318,7 @@ nouveau_channel_init(struct nouveau_channel *chan, u32 
 vram, u32 gart)
 chan-dma.ib_base =  0x1 / 4;
 chan-dma.ib_max  = (0x01000 / 8) - 1;
 chan-dma.ib_put  = 0;
 -   chan-dma.ib_free = chan-dma.ib_max - chan-dma.ib_put;
 +   chan-dma.ib_free = chan-dma.ib_max - chan-dma.ib_put + 1;
 chan-dma.max = chan-dma.ib_base;
 break;
 }
 diff --git a/drivers/gpu/drm/nouveau/nouveau_dma.c 
 b/drivers/gpu/drm/nouveau/nouveau_dma.c
 index 40f91e1..e814fab 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_dma.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_dma.c
 @@ -128,7 +128,7 @@ nv50_dma_push_wait(struct nouveau_channel *chan, int 
 count)

 chan-dma.ib_free = get - chan-dma.ib_put;
 if (chan-dma.ib_free = 0)
 -   chan-dma.ib_free += chan-dma.ib_max;
 +   chan-dma.ib_free += chan-dma.ib_max + 1;
 }

 return 0;
 diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
 b/drivers/gpu/drm/nouveau/nouveau_gem.c
 index 6454370..d19c7aa 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
 @@ -662,7 +662,7 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void 
 *data,
 if (unlikely(req-nr_push == 0))
 goto out_next;

 -   if (unlikely(req-nr_push  NOUVEAU_GEM_MAX_PUSH)) {
 +   if (unlikely(req-nr_push = NOUVEAU_GEM_MAX_PUSH)) {
 NV_ERROR(drm, pushbuf push count exceeds limit: %d max %d\n,
  req-nr_push, NOUVEAU_GEM_MAX_PUSH);
 return nouveau_abi16_put(abi16, -EINVAL);
 @@ -718,7 +718,7 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void 
 *data,
 }

 if (chan-dma.ib_max) {
 -   ret = nouveau_dma_wait(chan, req-nr_push + 1, 16);
 +   ret = nouveau_dma_wait(chan, req-nr_push, 16);
 if (ret) {
 NV_ERROR(drm, nv50cal_space: %d\n, ret);
 goto out;
 --
 1.7.8.6


Tested-by: Maarten Maathuis madman2...@gmail.com

I would however like to voice a concern about the reinterpretation of
MAX_PUSH. Strictly speaking the number needs to go down one as far as
i'm concerned. But i'll Ben decide about the API/ABI concerns :-)

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [bisected] nouveau: "Failed to idle channel x" after resume

[Maarten Maathuis]

On Mon, Aug 13, 2012 at 9:49 PM, Maxim Levitsky  
wrote:
> On Mon, 2012-08-13 at 18:22 +0200, Sven Joachim wrote:
>> On 2012-08-08 08:18 +0200, Sven Joachim wrote:
>>
>> > On 2012-08-08 08:08 +0200, Ben Skeggs wrote:
>> >
>> >> On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
>> >>> Not for me on my GeForce 8500 GT, and I still cannot suspend more than
>> >>> once, subsequent attempts fail:
>> >>>
>> >>> ,
>> >>> | Aug 8 07:49:16 turtle kernel: [ 91.697068] nouveau W[
>> >>> | PGRAPH][:01:00.0][0x0200502d][880037be1d40] parent failed
>> >>> | suspend, -16
>> >>> | Aug  8 07:49:16 turtle kernel: [   91.697078] nouveau  [ 
>> >>> DRM][:01:00.0] resuming display...
>> >>> `
>> >> Interesting.  Were there any messages prior to that?
>> >
>> > Nothing interesting:
>> >
>> > ,
>> > | Aug  8 07:49:16 turtle kernel: [   89.655362] nouveau  [ 
>> > DRM][:01:00.0] suspending fbcon...
>> > | Aug  8 07:49:16 turtle kernel: [   89.655367] nouveau  [ 
>> > DRM][:01:00.0] suspending display...
>> > | Aug  8 07:49:16 turtle kernel: [   89.696888] nouveau  [ 
>> > DRM][:01:00.0] unpinning framebuffer(s)...
>> > | Aug  8 07:49:16 turtle kernel: [   89.696909] nouveau  [ 
>> > DRM][:01:00.0] evicting buffers...
>> > | Aug  8 07:49:16 turtle kernel: [   89.696913] nouveau  [ 
>> > DRM][:01:00.0] suspending client object trees...
>> > `
>> >
>> >> I guess the the fifo
>> >> code detected a timeout when trying to save the graphics context, I have
>> >> I have other patches in my tree (I'll push them soon, tied up with other
>> >> work atm) that might help here.
>> >
>> > Thanks, I'll try them when they are available.
>>
>> With current nouveau master ("drm/nouveau: fix find/replace bug in
>> license header") suspending works again, thanks!  However, it is a bit
>> slow, taking between two and five seconds:
>>
>> ,
>> | Aug 13 18:17:56 turtle kernel: [  678.524814] PM: Syncing filesystems ... 
>> done.
>> | Aug 13 18:18:09 turtle kernel: [  678.639202] Freezing user space 
>> processes ... (elapsed 0.01 seconds) done.
>> | Aug 13 18:18:09 turtle kernel: [  678.649954] Freezing remaining freezable 
>> tasks ... (elapsed 0.01 seconds) done.
>> | Aug 13 18:18:09 turtle kernel: [  678.663298] Suspending console(s) (use 
>> no_console_suspend to debug)
>> | Aug 13 18:18:09 turtle kernel: [  678.680884] sd 0:0:0:0: [sda] 
>> Synchronizing SCSI cache
>> | Aug 13 18:18:09 turtle kernel: [  678.681000] sd 0:0:0:0: [sda] Stopping 
>> disk
>> | Aug 13 18:18:09 turtle kernel: [  678.695141] parport_pc 00:07: disabled
>> | Aug 13 18:18:09 turtle kernel: [  678.695204] serial 00:06: disabled
>> | Aug 13 18:18:09 turtle kernel: [  678.695209] serial 00:06: wake-up 
>> capability disabled by ACPI
>> | Aug 13 18:18:09 turtle kernel: [  678.695235] nouveau  [ 
>> DRM][:01:00.0] suspending fbcon...
>> | Aug 13 18:18:09 turtle kernel: [  678.695239] nouveau  [ 
>> DRM][:01:00.0] suspending display...
>> | Aug 13 18:18:09 turtle kernel: [  678.742111] nouveau  [ 
>> DRM][:01:00.0] unpinning framebuffer(s)...
>> | Aug 13 18:18:09 turtle kernel: [  678.742189] nouveau  [ 
>> DRM][:01:00.0] evicting buffers...
>> | Aug 13 18:18:09 turtle kernel: [  682.357319] nouveau  [ 
>> DRM][:01:00.0] suspending client object trees...
>> | Aug 13 18:18:09 turtle kernel: [  683.526646] PM: suspend of devices 
>> complete after 4863.181 msecs
>> `
>>
>> With the 3.4.8 kernel, suspending takes little more than one second.
>>
>> Cheers,
>>Sven
> I confirm exactly the same thing.
>
> Here suspend takes more that 10 seconds:
>
> [ 2165.363878] nouveau  [ DRM][:01:00.0] suspending fbcon...
> [ 2165.363885] nouveau  [ DRM][:01:00.0] suspending display...
> [ 2165.475791] sd 0:0:0:0: [sda] Stopping disk
> [ 2166.396877] nouveau  [ DRM][:01:00.0] unpinning
> framebuffer(s)...
> [ 2166.396926] nouveau  [ DRM][:01:00.0] evicting buffers...
> [ 2174.809084] nouveau  [ DRM][:01:00.0] suspending client
> object trees...
> [ 2177.950222] nouveau :01:00.0: power state changed by ACPI to D3
>
>
> Best regards,
> Maxim Levitsky
>
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

In my case suspend also takes longer than usual, in the order of 10 seconds.

@Ben: Have you been able to reproduce this?

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: [Nouveau] [bisected] nouveau: "Failed to idle channel x" after resume

[Maarten Maathuis]

On Mon, Aug 13, 2012 at 9:49 PM, Maxim Levitsky  wrote:
> On Mon, 2012-08-13 at 18:22 +0200, Sven Joachim wrote:
>> On 2012-08-08 08:18 +0200, Sven Joachim wrote:
>>
>> > On 2012-08-08 08:08 +0200, Ben Skeggs wrote:
>> >
>> >> On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
>> >>> Not for me on my GeForce 8500 GT, and I still cannot suspend more than
>> >>> once, subsequent attempts fail:
>> >>>
>> >>> ,
>> >>> | Aug 8 07:49:16 turtle kernel: [ 91.697068] nouveau W[
>> >>> | PGRAPH][:01:00.0][0x0200502d][880037be1d40] parent failed
>> >>> | suspend, -16
>> >>> | Aug  8 07:49:16 turtle kernel: [   91.697078] nouveau  [ 
>> >>> DRM][:01:00.0] resuming display...
>> >>> `
>> >> Interesting.  Were there any messages prior to that?
>> >
>> > Nothing interesting:
>> >
>> > ,
>> > | Aug  8 07:49:16 turtle kernel: [   89.655362] nouveau  [ 
>> > DRM][:01:00.0] suspending fbcon...
>> > | Aug  8 07:49:16 turtle kernel: [   89.655367] nouveau  [ 
>> > DRM][:01:00.0] suspending display...
>> > | Aug  8 07:49:16 turtle kernel: [   89.696888] nouveau  [ 
>> > DRM][:01:00.0] unpinning framebuffer(s)...
>> > | Aug  8 07:49:16 turtle kernel: [   89.696909] nouveau  [ 
>> > DRM][:01:00.0] evicting buffers...
>> > | Aug  8 07:49:16 turtle kernel: [   89.696913] nouveau  [ 
>> > DRM][:01:00.0] suspending client object trees...
>> > `
>> >
>> >> I guess the the fifo
>> >> code detected a timeout when trying to save the graphics context, I have
>> >> I have other patches in my tree (I'll push them soon, tied up with other
>> >> work atm) that might help here.
>> >
>> > Thanks, I'll try them when they are available.
>>
>> With current nouveau master ("drm/nouveau: fix find/replace bug in
>> license header") suspending works again, thanks!  However, it is a bit
>> slow, taking between two and five seconds:
>>
>> ,
>> | Aug 13 18:17:56 turtle kernel: [  678.524814] PM: Syncing filesystems ... 
>> done.
>> | Aug 13 18:18:09 turtle kernel: [  678.639202] Freezing user space 
>> processes ... (elapsed 0.01 seconds) done.
>> | Aug 13 18:18:09 turtle kernel: [  678.649954] Freezing remaining freezable 
>> tasks ... (elapsed 0.01 seconds) done.
>> | Aug 13 18:18:09 turtle kernel: [  678.663298] Suspending console(s) (use 
>> no_console_suspend to debug)
>> | Aug 13 18:18:09 turtle kernel: [  678.680884] sd 0:0:0:0: [sda] 
>> Synchronizing SCSI cache
>> | Aug 13 18:18:09 turtle kernel: [  678.681000] sd 0:0:0:0: [sda] Stopping 
>> disk
>> | Aug 13 18:18:09 turtle kernel: [  678.695141] parport_pc 00:07: disabled
>> | Aug 13 18:18:09 turtle kernel: [  678.695204] serial 00:06: disabled
>> | Aug 13 18:18:09 turtle kernel: [  678.695209] serial 00:06: wake-up 
>> capability disabled by ACPI
>> | Aug 13 18:18:09 turtle kernel: [  678.695235] nouveau  [ 
>> DRM][:01:00.0] suspending fbcon...
>> | Aug 13 18:18:09 turtle kernel: [  678.695239] nouveau  [ 
>> DRM][:01:00.0] suspending display...
>> | Aug 13 18:18:09 turtle kernel: [  678.742111] nouveau  [ 
>> DRM][:01:00.0] unpinning framebuffer(s)...
>> | Aug 13 18:18:09 turtle kernel: [  678.742189] nouveau  [ 
>> DRM][:01:00.0] evicting buffers...
>> | Aug 13 18:18:09 turtle kernel: [  682.357319] nouveau  [ 
>> DRM][:01:00.0] suspending client object trees...
>> | Aug 13 18:18:09 turtle kernel: [  683.526646] PM: suspend of devices 
>> complete after 4863.181 msecs
>> `
>>
>> With the 3.4.8 kernel, suspending takes little more than one second.
>>
>> Cheers,
>>Sven
> I confirm exactly the same thing.
>
> Here suspend takes more that 10 seconds:
>
> [ 2165.363878] nouveau  [ DRM][:01:00.0] suspending fbcon...
> [ 2165.363885] nouveau  [ DRM][:01:00.0] suspending display...
> [ 2165.475791] sd 0:0:0:0: [sda] Stopping disk
> [ 2166.396877] nouveau  [ DRM][:01:00.0] unpinning
> framebuffer(s)...
> [ 2166.396926] nouveau  [ DRM][:01:00.0] evicting buffers...
> [ 2174.809084] nouveau  [ DRM][:01:00.0] suspending client
> object trees...
> [ 2177.950222] nouveau :01:00.0: power state changed by ACPI to D3
>
>
> Best regards,
> Maxim Levitsky
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

In my case suspend also takes longer than usual, in the order of 10 seconds.

@Ben: Have you been able to reproduce this?

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Nouveau] [bisected] nouveau: Failed to idle channel x after resume

[Maarten Maathuis]

On Mon, Aug 13, 2012 at 9:49 PM, Maxim Levitsky maximlevit...@gmail.com wrote:
 On Mon, 2012-08-13 at 18:22 +0200, Sven Joachim wrote:
 On 2012-08-08 08:18 +0200, Sven Joachim wrote:

  On 2012-08-08 08:08 +0200, Ben Skeggs wrote:
 
  On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
  Not for me on my GeForce 8500 GT, and I still cannot suspend more than
  once, subsequent attempts fail:
 
  ,
  | Aug 8 07:49:16 turtle kernel: [ 91.697068] nouveau W[
  | PGRAPH][:01:00.0][0x0200502d][880037be1d40] parent failed
  | suspend, -16
  | Aug  8 07:49:16 turtle kernel: [   91.697078] nouveau  [ 
  DRM][:01:00.0] resuming display...
  `
  Interesting.  Were there any messages prior to that?
 
  Nothing interesting:
 
  ,
  | Aug  8 07:49:16 turtle kernel: [   89.655362] nouveau  [ 
  DRM][:01:00.0] suspending fbcon...
  | Aug  8 07:49:16 turtle kernel: [   89.655367] nouveau  [ 
  DRM][:01:00.0] suspending display...
  | Aug  8 07:49:16 turtle kernel: [   89.696888] nouveau  [ 
  DRM][:01:00.0] unpinning framebuffer(s)...
  | Aug  8 07:49:16 turtle kernel: [   89.696909] nouveau  [ 
  DRM][:01:00.0] evicting buffers...
  | Aug  8 07:49:16 turtle kernel: [   89.696913] nouveau  [ 
  DRM][:01:00.0] suspending client object trees...
  `
 
  I guess the the fifo
  code detected a timeout when trying to save the graphics context, I have
  I have other patches in my tree (I'll push them soon, tied up with other
  work atm) that might help here.
 
  Thanks, I'll try them when they are available.

 With current nouveau master (drm/nouveau: fix find/replace bug in
 license header) suspending works again, thanks!  However, it is a bit
 slow, taking between two and five seconds:

 ,
 | Aug 13 18:17:56 turtle kernel: [  678.524814] PM: Syncing filesystems ... 
 done.
 | Aug 13 18:18:09 turtle kernel: [  678.639202] Freezing user space 
 processes ... (elapsed 0.01 seconds) done.
 | Aug 13 18:18:09 turtle kernel: [  678.649954] Freezing remaining freezable 
 tasks ... (elapsed 0.01 seconds) done.
 | Aug 13 18:18:09 turtle kernel: [  678.663298] Suspending console(s) (use 
 no_console_suspend to debug)
 | Aug 13 18:18:09 turtle kernel: [  678.680884] sd 0:0:0:0: [sda] 
 Synchronizing SCSI cache
 | Aug 13 18:18:09 turtle kernel: [  678.681000] sd 0:0:0:0: [sda] Stopping 
 disk
 | Aug 13 18:18:09 turtle kernel: [  678.695141] parport_pc 00:07: disabled
 | Aug 13 18:18:09 turtle kernel: [  678.695204] serial 00:06: disabled
 | Aug 13 18:18:09 turtle kernel: [  678.695209] serial 00:06: wake-up 
 capability disabled by ACPI
 | Aug 13 18:18:09 turtle kernel: [  678.695235] nouveau  [ 
 DRM][:01:00.0] suspending fbcon...
 | Aug 13 18:18:09 turtle kernel: [  678.695239] nouveau  [ 
 DRM][:01:00.0] suspending display...
 | Aug 13 18:18:09 turtle kernel: [  678.742111] nouveau  [ 
 DRM][:01:00.0] unpinning framebuffer(s)...
 | Aug 13 18:18:09 turtle kernel: [  678.742189] nouveau  [ 
 DRM][:01:00.0] evicting buffers...
 | Aug 13 18:18:09 turtle kernel: [  682.357319] nouveau  [ 
 DRM][:01:00.0] suspending client object trees...
 | Aug 13 18:18:09 turtle kernel: [  683.526646] PM: suspend of devices 
 complete after 4863.181 msecs
 `

 With the 3.4.8 kernel, suspending takes little more than one second.

 Cheers,
Sven
 I confirm exactly the same thing.

 Here suspend takes more that 10 seconds:

 [ 2165.363878] nouveau  [ DRM][:01:00.0] suspending fbcon...
 [ 2165.363885] nouveau  [ DRM][:01:00.0] suspending display...
 [ 2165.475791] sd 0:0:0:0: [sda] Stopping disk
 [ 2166.396877] nouveau  [ DRM][:01:00.0] unpinning
 framebuffer(s)...
 [ 2166.396926] nouveau  [ DRM][:01:00.0] evicting buffers...
 [ 2174.809084] nouveau  [ DRM][:01:00.0] suspending client
 object trees...
 [ 2177.950222] nouveau :01:00.0: power state changed by ACPI to D3


 Best regards,
 Maxim Levitsky

 ___
 Nouveau mailing list
 nouv...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/nouveau

In my case suspend also takes longer than usual, in the order of 10 seconds.

@Ben: Have you been able to reproduce this?

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [bisected] nouveau: Failed to idle channel x after resume

[Maarten Maathuis]

On Mon, Aug 13, 2012 at 9:49 PM, Maxim Levitsky maximlevit...@gmail.com wrote:
 On Mon, 2012-08-13 at 18:22 +0200, Sven Joachim wrote:
 On 2012-08-08 08:18 +0200, Sven Joachim wrote:

  On 2012-08-08 08:08 +0200, Ben Skeggs wrote:
 
  On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
  Not for me on my GeForce 8500 GT, and I still cannot suspend more than
  once, subsequent attempts fail:
 
  ,
  | Aug 8 07:49:16 turtle kernel: [ 91.697068] nouveau W[
  | PGRAPH][:01:00.0][0x0200502d][880037be1d40] parent failed
  | suspend, -16
  | Aug  8 07:49:16 turtle kernel: [   91.697078] nouveau  [ 
  DRM][:01:00.0] resuming display...
  `
  Interesting.  Were there any messages prior to that?
 
  Nothing interesting:
 
  ,
  | Aug  8 07:49:16 turtle kernel: [   89.655362] nouveau  [ 
  DRM][:01:00.0] suspending fbcon...
  | Aug  8 07:49:16 turtle kernel: [   89.655367] nouveau  [ 
  DRM][:01:00.0] suspending display...
  | Aug  8 07:49:16 turtle kernel: [   89.696888] nouveau  [ 
  DRM][:01:00.0] unpinning framebuffer(s)...
  | Aug  8 07:49:16 turtle kernel: [   89.696909] nouveau  [ 
  DRM][:01:00.0] evicting buffers...
  | Aug  8 07:49:16 turtle kernel: [   89.696913] nouveau  [ 
  DRM][:01:00.0] suspending client object trees...
  `
 
  I guess the the fifo
  code detected a timeout when trying to save the graphics context, I have
  I have other patches in my tree (I'll push them soon, tied up with other
  work atm) that might help here.
 
  Thanks, I'll try them when they are available.

 With current nouveau master (drm/nouveau: fix find/replace bug in
 license header) suspending works again, thanks!  However, it is a bit
 slow, taking between two and five seconds:

 ,
 | Aug 13 18:17:56 turtle kernel: [  678.524814] PM: Syncing filesystems ... 
 done.
 | Aug 13 18:18:09 turtle kernel: [  678.639202] Freezing user space 
 processes ... (elapsed 0.01 seconds) done.
 | Aug 13 18:18:09 turtle kernel: [  678.649954] Freezing remaining freezable 
 tasks ... (elapsed 0.01 seconds) done.
 | Aug 13 18:18:09 turtle kernel: [  678.663298] Suspending console(s) (use 
 no_console_suspend to debug)
 | Aug 13 18:18:09 turtle kernel: [  678.680884] sd 0:0:0:0: [sda] 
 Synchronizing SCSI cache
 | Aug 13 18:18:09 turtle kernel: [  678.681000] sd 0:0:0:0: [sda] Stopping 
 disk
 | Aug 13 18:18:09 turtle kernel: [  678.695141] parport_pc 00:07: disabled
 | Aug 13 18:18:09 turtle kernel: [  678.695204] serial 00:06: disabled
 | Aug 13 18:18:09 turtle kernel: [  678.695209] serial 00:06: wake-up 
 capability disabled by ACPI
 | Aug 13 18:18:09 turtle kernel: [  678.695235] nouveau  [ 
 DRM][:01:00.0] suspending fbcon...
 | Aug 13 18:18:09 turtle kernel: [  678.695239] nouveau  [ 
 DRM][:01:00.0] suspending display...
 | Aug 13 18:18:09 turtle kernel: [  678.742111] nouveau  [ 
 DRM][:01:00.0] unpinning framebuffer(s)...
 | Aug 13 18:18:09 turtle kernel: [  678.742189] nouveau  [ 
 DRM][:01:00.0] evicting buffers...
 | Aug 13 18:18:09 turtle kernel: [  682.357319] nouveau  [ 
 DRM][:01:00.0] suspending client object trees...
 | Aug 13 18:18:09 turtle kernel: [  683.526646] PM: suspend of devices 
 complete after 4863.181 msecs
 `

 With the 3.4.8 kernel, suspending takes little more than one second.

 Cheers,
Sven
 I confirm exactly the same thing.

 Here suspend takes more that 10 seconds:

 [ 2165.363878] nouveau  [ DRM][:01:00.0] suspending fbcon...
 [ 2165.363885] nouveau  [ DRM][:01:00.0] suspending display...
 [ 2165.475791] sd 0:0:0:0: [sda] Stopping disk
 [ 2166.396877] nouveau  [ DRM][:01:00.0] unpinning
 framebuffer(s)...
 [ 2166.396926] nouveau  [ DRM][:01:00.0] evicting buffers...
 [ 2174.809084] nouveau  [ DRM][:01:00.0] suspending client
 object trees...
 [ 2177.950222] nouveau :01:00.0: power state changed by ACPI to D3


 Best regards,
 Maxim Levitsky

 ___
 Nouveau mailing list
 Nouveau@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/nouveau

In my case suspend also takes longer than usual, in the order of 10 seconds.

@Ben: Have you been able to reproduce this?

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [bisected] nouveau: Failed to idle channel x after resume

[Maarten Maathuis]

On Mon, Aug 13, 2012 at 9:49 PM, Maxim Levitsky maximlevit...@gmail.com wrote:
 On Mon, 2012-08-13 at 18:22 +0200, Sven Joachim wrote:
 On 2012-08-08 08:18 +0200, Sven Joachim wrote:

  On 2012-08-08 08:08 +0200, Ben Skeggs wrote:
 
  On Wed, Aug 08, 2012 at 08:00:21AM +0200, Sven Joachim wrote:
  Not for me on my GeForce 8500 GT, and I still cannot suspend more than
  once, subsequent attempts fail:
 
  ,
  | Aug 8 07:49:16 turtle kernel: [ 91.697068] nouveau W[
  | PGRAPH][:01:00.0][0x0200502d][880037be1d40] parent failed
  | suspend, -16
  | Aug  8 07:49:16 turtle kernel: [   91.697078] nouveau  [ 
  DRM][:01:00.0] resuming display...
  `
  Interesting.  Were there any messages prior to that?
 
  Nothing interesting:
 
  ,
  | Aug  8 07:49:16 turtle kernel: [   89.655362] nouveau  [ 
  DRM][:01:00.0] suspending fbcon...
  | Aug  8 07:49:16 turtle kernel: [   89.655367] nouveau  [ 
  DRM][:01:00.0] suspending display...
  | Aug  8 07:49:16 turtle kernel: [   89.696888] nouveau  [ 
  DRM][:01:00.0] unpinning framebuffer(s)...
  | Aug  8 07:49:16 turtle kernel: [   89.696909] nouveau  [ 
  DRM][:01:00.0] evicting buffers...
  | Aug  8 07:49:16 turtle kernel: [   89.696913] nouveau  [ 
  DRM][:01:00.0] suspending client object trees...
  `
 
  I guess the the fifo
  code detected a timeout when trying to save the graphics context, I have
  I have other patches in my tree (I'll push them soon, tied up with other
  work atm) that might help here.
 
  Thanks, I'll try them when they are available.

 With current nouveau master (drm/nouveau: fix find/replace bug in
 license header) suspending works again, thanks!  However, it is a bit
 slow, taking between two and five seconds:

 ,
 | Aug 13 18:17:56 turtle kernel: [  678.524814] PM: Syncing filesystems ... 
 done.
 | Aug 13 18:18:09 turtle kernel: [  678.639202] Freezing user space 
 processes ... (elapsed 0.01 seconds) done.
 | Aug 13 18:18:09 turtle kernel: [  678.649954] Freezing remaining freezable 
 tasks ... (elapsed 0.01 seconds) done.
 | Aug 13 18:18:09 turtle kernel: [  678.663298] Suspending console(s) (use 
 no_console_suspend to debug)
 | Aug 13 18:18:09 turtle kernel: [  678.680884] sd 0:0:0:0: [sda] 
 Synchronizing SCSI cache
 | Aug 13 18:18:09 turtle kernel: [  678.681000] sd 0:0:0:0: [sda] Stopping 
 disk
 | Aug 13 18:18:09 turtle kernel: [  678.695141] parport_pc 00:07: disabled
 | Aug 13 18:18:09 turtle kernel: [  678.695204] serial 00:06: disabled
 | Aug 13 18:18:09 turtle kernel: [  678.695209] serial 00:06: wake-up 
 capability disabled by ACPI
 | Aug 13 18:18:09 turtle kernel: [  678.695235] nouveau  [ 
 DRM][:01:00.0] suspending fbcon...
 | Aug 13 18:18:09 turtle kernel: [  678.695239] nouveau  [ 
 DRM][:01:00.0] suspending display...
 | Aug 13 18:18:09 turtle kernel: [  678.742111] nouveau  [ 
 DRM][:01:00.0] unpinning framebuffer(s)...
 | Aug 13 18:18:09 turtle kernel: [  678.742189] nouveau  [ 
 DRM][:01:00.0] evicting buffers...
 | Aug 13 18:18:09 turtle kernel: [  682.357319] nouveau  [ 
 DRM][:01:00.0] suspending client object trees...
 | Aug 13 18:18:09 turtle kernel: [  683.526646] PM: suspend of devices 
 complete after 4863.181 msecs
 `

 With the 3.4.8 kernel, suspending takes little more than one second.

 Cheers,
Sven
 I confirm exactly the same thing.

 Here suspend takes more that 10 seconds:

 [ 2165.363878] nouveau  [ DRM][:01:00.0] suspending fbcon...
 [ 2165.363885] nouveau  [ DRM][:01:00.0] suspending display...
 [ 2165.475791] sd 0:0:0:0: [sda] Stopping disk
 [ 2166.396877] nouveau  [ DRM][:01:00.0] unpinning
 framebuffer(s)...
 [ 2166.396926] nouveau  [ DRM][:01:00.0] evicting buffers...
 [ 2174.809084] nouveau  [ DRM][:01:00.0] suspending client
 object trees...
 [ 2177.950222] nouveau :01:00.0: power state changed by ACPI to D3


 Best regards,
 Maxim Levitsky

 ___
 Nouveau mailing list
 nouv...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/nouveau

In my case suspend also takes longer than usual, in the order of 10 seconds.

@Ben: Have you been able to reproduce this?

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Nouveau] BIG changes to kernel module

[Maarten Maathuis]

On Mon, Aug 6, 2012 at 8:58 AM, Ben Skeggs skeg...@gmail.com wrote:
 On Sun, Aug 05, 2012 at 10:56:37PM +0200, Marcin Slusarz wrote:
 On Sun, Aug 05, 2012 at 12:40:15PM +1000, Ben Skeggs wrote:
  Hey all,
 
  I've just pushed a major rework/rewrite of the Nouveau kernel module to 
  git[1].
 
  Details of the whys and what-nots of the rework are in the various commit
  messages.  At this point don't expect any exciting cool functionality, the
  work so far is merely a restructure to allow moving forward on a number
  of fronts in the future.
 
  I expect that for a while there will be a *lot* of stupid typos/thinkos 
  that
  cause all sorts of breakage, so please test everything any anything you can
  and report *regressions* from the pre-rework code (vs 3.6-rc1 for example).
 
  I'll endeavour to hunt down and fix the regressions as quickly as 
  possible, so
  please report any issues to this list and/or the freedesktop bugzilla.
 
  There's two areas that didn't get properly ported over, that is 
  PM-related
  things and modesetting.  I'll be handling the modesetting and clk/volt 
  reworks
  starting from nowish (in between fixing regressions), and I suspect Martin
  will handle the rest of the PM bits (therm and fanctrl) since he knows the
  design he's going for there.
 
  One thing to note is that some kernel module options have changed now, the
  more important ones are:
 
  nouveau.vbios=blah - nouveau.config=NvBIOS=blah
  nouveau.noaccel=bool - nouveau.config=PGRAPH=bool
 
  Multiple options are specified like:
 
  nouveau.config=NvBIOS=ACPI,PGRAPH=1
 
  The nouveau.noaccel option now controls acceleration enable/disable for the
  DRM's own GPU usage, and for the abi16 (the new interfaces aren't even
  exposed to userspace yet) interfaces.
 
  The DRM debugging options (drm.debug=bitfield) now only effect the DRM
  specific parts of the nouveau module.  To enable additional debugging etc
  for the core, incantations like the following are used now:
 
  for debug output
 
  nouveau.debug=debug
 
  or for even more verbose debug output
 
  nouveau.debug=trace
 
  or for trace output for everything, and register write logging from POST
 
  nouveau.debug=trace,DEVINIT=spam
 
  Each individual subdev/engine module has its own debug level that can
  override the master debug level.

 It would be very helpful to document this convention and all options in some
 text file in-tree (and later update it when things change).
 Yes, good point.  I'll see to that before any of this hits Linus'.


 Some things I noticed:
 - corruptions / lockups in Warsow (1.0) on one of the bomb maps (I didn't 
 test
   too much, so it might happen on others too) - initially bisected to
   drm/nouveau/instmem: completely new implementation, as a subdev module,
   but I'm not so sure about it - with this commit most textures are corrupted
   and there are PGRAPH_TRAP_MP_EXEC errors in dmesg, but on HEAD I see total
   mayhem with DATA_ERROR, followed by TRAP_MP_EXEC and endless stream of page
   faults
 - new lockups triggerable by piglit
 - VRAM leak? (probably triggered by piglit)
 I'll see if I can reproduce these at all during the week.

 - missing channel id in error messages
 This is actually deliberate, since technically the channel address *is* the
 chid on most engines.  PFIFO errors still log the chid, because there are
 actually indices there.

 I do see how it can be useful to have the PFIFO channel ID too though in
 error messages, so I'll bring them back.

 - debugfs removed (not advertised in any commit, so I don't know if it's
   intentional or not)
 Oops, that *was* a separate commit at some point.  Might have accidentally
 squashed it.  It's intentional for now, it'll come back (better) later.

 - some leftovers:
   - XXX_THIS_IS_A_HACK
   - /* yell very loudly!! */ (no code implementing yelling ;)
 Oops, thanks.  I've fixed both of these and I'll push them shortly.

 Thanks a LOT for looking this over for me.

 Cheers,
 Ben.


 Marcin
 ___
 Nouveau mailing list
 Nouveau@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/nouveau

I've also noticed some problems with huge lag in freespace 2 open, i
see this in dmesg:

[111545.883979] nouveau E[ DRM][:01:00.0] nv50cal_space: -16

I can't find anything obviously wrong with the code checking that we
haven't locked up, but that doesn't mean you shouldn't check it :-)

Note that in the past there were always scenes that were a bit laggy,
but these things are almost like temporary lockups.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Mesa build issue... is it just me?

[Maarten Maathuis]

On Sun, Jul 29, 2012 at 7:14 PM, Andrew Green andrew.green...@gmail.com wrote:
 Anyone else getting this when building the latest mesa?

 make[3]: Entering directory
 `/usr/local/nouveau/mesa2/mesa/src/gallium/targets/dri-nouveau'
 gcc -c -I. -I../../../../src/mesa/drivers/dri/common -Iserver
 -I../../../../include -I../../../../include/GL/internal
 -I../../../../src/mapi -I../../../../src/gallium/include
 -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers
 -I../../../../src/gallium/winsys -I../../../../src/mesa
 -I../../../../src/mesa/main -I../../../../src/mesa/math
 -I../../../../src/mesa/transform -I../../../../src/mesa/shader
 -I../../../../src/mesa/swrast -I../../../../src/mesa/swrast_setup
 -I../../../../src/egl/main -I../../../../src/egl/drivers/dri
 -I/usr/local/include -I/usr/local/include/libdrm-g -O2 -Wall -std=c99
 -Werror=implicit-function-declaration -Werror=missing-prototypes
 -fno-strict-aliasing -fno-builtin-memcmp -g -g -O2 -fPIC -D_GNU_SOURCE
 -DPTHREADS -DDEBUG -DTEXTURE_FLOAT_ENABLED -DHAVE_POSIX_MEMALIGN -DUSE_XCB
 -DGLX_INDIRECT_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DPTHREADS
 -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DHAVE_ALIAS -fvisibility=hidden
 -DGALLIUM_RBUG -DGALLIUM_TRACE target.c -o target.o
 /bin/sh ../../../../bin/mklib -o nouveau_dri.so.tmp -noprefix -linker 'g++'
 -ldflags '' \
 target.o ../../../../src/mesa/drivers/dri/common/utils.o
 ../../../../src/mesa/drivers/dri/common/dri_util.o
 ../../../../src/mesa/drivers/dri/common/xmlconfig.o
 ../../../../src/gallium/state_trackers/dri/drm/libdridrm.a
 ../../../../src/gallium/winsys/nouveau/drm/libnouveaudrm.a
 ../../../../src/gallium/drivers/trace/libtrace.a
 ../../../../src/gallium/drivers/rbug/librbug.a
 ../../../../src/gallium/drivers/nv30/libnv30.a
 ../../../../src/gallium/drivers/nv50/libnv50.a
 ../../../../src/gallium/drivers/nvc0/libnvc0.a
 ../../../../src/gallium/drivers/nouveau/libnouveau.a \
 -Wl,--start-group ../../../../src/mesa/libmesagallium.a
 ../../../../src/gallium/auxiliary/libgallium.a -Wl,--end-group \
   ../../../../lib/libdricore8.1.0.so  -L/usr/local/lib -ldrm
 -lexpat -lm -lpthread -ldl -ldrm_nouveau
 mklib: Making Linux shared library:  nouveau_dri.so.tmp
 g++ -g -O2 -Wall -std=c99 -Werror=implicit-function-declaration
 -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -g -g
 -O2 -fPIC -D_GNU_SOURCE -DPTHREADS -DDEBUG -DTEXTURE_FLOAT_ENABLED
 -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DGLX_INDIRECT_RENDERING
 -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1
 -DIN_DRI_DRIVER -DHAVE_ALIAS -fvisibility=hidden -o nouveau_dri.so.test
 ../../../../src/mesa/drivers/dri/common/dri_test.o nouveau_dri.so.tmp
 ../../../../lib/libdricore8.1.0.so  -L/usr/local/lib -ldrm   -lexpat -lm
 -lpthread -ldl -ldrm_nouveau   ;
 /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libdrm_nouveau.so:
 undefined reference to `drmPrimeHandleToFD'
 /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libdrm_nouveau.so:
 undefined reference to `drmPrimeFDToHandle'
 collect2: error: ld returned 1 exit status

 I'm on a mixed Debian testing/unstable/experimental, with Linux
 3.4-trunk-amd64. Didn't have any build issues before doing a git pull and an
 apt-get upgrade just prior.

 I noticed this (refers to intel and drm):
 http://blog.gmane.org/gmane.comp.video.dri.patches . Says something about
 distributions having changed ld to default to --no-copy-dt-needed-entries.

 Many thanks in advance for any suggestions, greetings,
 Andrew

 P.S. Here is my config:

 ./autogen.sh --prefix=/usr --bindir=/usr/bin --libdir=/usr/lib
 --includedir=/usr/include --with-dri-drivers=
 --with-gallium-drivers=swrast,nouveau --enable-debug --enable-texture-float
 --disable-asm --enable-opengl --disable-gles2 --disable-openvg
 --enable-texture-float --disable-asm --enable-opengl --disable-gles2
 --disable-openvg --enable-dri --enable-glx --enable-xvmc --disable-va
 --disable-vdpau --disable-osmesa --disable-egl --disable-xorg
 --disable-d3d1x --disable-xa --disable-gbm --disable-xlib-glx
 --disable-gallium-egl --disable-gallium-gbm --disable-gallium-llvm
 --enable-driglx-direct --enable-glx-tls --enable-glu --prefix=/usr/


 ___
 Nouveau mailing list
 Nouveau@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/nouveau


Sounds like something is wrong with your libdrm install if i had to guess.

Those symbols were added recently it seems:
http://cgit.freedesktop.org/mesa/drm/commit/?id=cc0a14575d9fd0aafe73cb4aa445eaf024436114

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[PATCH] nouveau: Add irq waiting as alternative to busywait

[Maarten Maathuis]

On Fri, Jul 13, 2012 at 11:35 PM, Maarten Lankhorst
 wrote:
> A way to trigger an irq will be needed for optimus support since
> cpu-waiting isn't always viable there. This could also be nice for
> power saving on since cpu would no longer have to spin, and
> performance might improve slightly on cpu-limited workloads.
>
> Some way to quantify these effects would be nice, even if the
> end result would be 'no performance regression'. An earlier
> version always emitted an interrupt, resulting in glxgears going
> from 8k fps to 7k. However this is no longer the case, as I'm
> using the kernel submission channel for generating irqs as
> needed now.
>
> On nv84 I'm using NOTIFY_INTR, but that might have been
> removed on fermi, so instead I'm using invalid command
> 0x0058 now as a way to signal completion.

Out of curiosity, isn't this like a handcoded version of software
methods? If so, why handcoded? Or are software methods not supported
on NVC0?

>
> Signed-off-by: Maarten Lankhorst 
>
> ---
>  drivers/gpu/drm/nouveau/nouveau_drv.h   |2 +
>  drivers/gpu/drm/nouveau/nouveau_fence.c |   49 
> ---
>  drivers/gpu/drm/nouveau/nouveau_fifo.h  |1 +
>  drivers/gpu/drm/nouveau/nouveau_state.c |1 +
>  drivers/gpu/drm/nouveau/nv04_fifo.c |   25 
>  drivers/gpu/drm/nouveau/nv84_fence.c|   18 +--
>  drivers/gpu/drm/nouveau/nvc0_fence.c|   12 ++--
>  drivers/gpu/drm/nouveau/nvc0_fifo.c |3 +-
>  drivers/gpu/drm/nouveau/nve0_fifo.c |   15 +++--
>  9 files changed, 110 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
> b/drivers/gpu/drm/nouveau/nouveau_drv.h
> index f97a1a7..d9d274d 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drv.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
> @@ -707,6 +707,7 @@ struct drm_nouveau_private {
> struct drm_mm heap;
> struct nouveau_bo *bo;
> } fence;
> +   wait_queue_head_t fence_wq;
>
> struct {
> spinlock_t lock;
> @@ -1656,6 +1657,7 @@ nv44_graph_class(struct drm_device *dev)
>  #define NV84_SUBCHAN_WRCACHE_FLUSH   
> 0x0024
>  #define NV10_SUBCHAN_REF_CNT 
> 0x0050
>  #define NVSW_SUBCHAN_PAGE_FLIP   
> 0x0054
> +#define NVSW_SUBCHAN_FENCE_WAKE  
> 0x0058
>  #define NV11_SUBCHAN_DMA_SEMAPHORE   
> 0x0060
>  #define NV11_SUBCHAN_SEMAPHORE_OFFSET
> 0x0064
>  #define NV11_SUBCHAN_SEMAPHORE_ACQUIRE   
> 0x0068
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 
> b/drivers/gpu/drm/nouveau/nouveau_fence.c
> index 3c18049..3ba8dee 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_fence.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
> @@ -68,7 +68,7 @@ nouveau_fence_update(struct nouveau_channel *chan)
>
> spin_lock(>lock);
> list_for_each_entry_safe(fence, fnext, >pending, head) {
> -   if (priv->read(chan) < fence->sequence)
> +   if (priv->read(chan) - fence->sequence >= 0x8000U)
> break;
>
> if (fence->work)
> @@ -111,11 +111,9 @@ nouveau_fence_done(struct nouveau_fence *fence)
> return !fence->channel;
>  }
>
> -int
> -nouveau_fence_wait(struct nouveau_fence *fence, bool lazy, bool intr)
> +static int nouveau_fence_wait_busy(struct nouveau_fence *fence, bool lazy, 
> bool intr)
>  {
> unsigned long sleep_time = NSEC_PER_MSEC / 1000;
> -   ktime_t t;
> int ret = 0;
>
> while (!nouveau_fence_done(fence)) {
> @@ -127,7 +125,7 @@ nouveau_fence_wait(struct nouveau_fence *fence, bool 
> lazy, bool intr)
> __set_current_state(intr ? TASK_INTERRUPTIBLE :
>TASK_UNINTERRUPTIBLE);
> if (lazy) {
> -   t = ktime_set(0, sleep_time);
> +   ktime_t t = ktime_set(0, sleep_time);
> schedule_hrtimeout(, HRTIMER_MODE_REL);
> sleep_time *= 2;
> if (sleep_time > NSEC_PER_MSEC)
> @@ -144,6 +142,47 @@ nouveau_fence_wait(struct nouveau_fence *fence, bool 
> lazy, bool intr)
> return ret;
>  }
>
> +static int nouveau_fence_wait_event(struct nouveau_fence *fence, bool intr)
> +{
> +   struct drm_nouveau_private *dev_priv = 
> fence->channel->dev->dev_private;
> +   unsigned long timeout = fence->timeout;
> +   int ret = 0;
> +   struct nouveau_channel *chan = dev_priv->channel;
> +   struct nouveau_channel *prev = fence->channel;
> +   struct nouveau_fence_priv *priv = nv_engine(chan->dev, 
> NVOBJ_ENGINE_FENCE);
> +
> +   if (nouveau_fence_done(fence))
> +   return 0;
> +
> +   if (!timeout)
> 

Re: [PATCH] nouveau: Add irq waiting as alternative to busywait

[Maarten Maathuis]

On Fri, Jul 13, 2012 at 11:35 PM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote:
 A way to trigger an irq will be needed for optimus support since
 cpu-waiting isn't always viable there. This could also be nice for
 power saving on since cpu would no longer have to spin, and
 performance might improve slightly on cpu-limited workloads.

 Some way to quantify these effects would be nice, even if the
 end result would be 'no performance regression'. An earlier
 version always emitted an interrupt, resulting in glxgears going
 from 8k fps to 7k. However this is no longer the case, as I'm
 using the kernel submission channel for generating irqs as
 needed now.

 On nv84 I'm using NOTIFY_INTR, but that might have been
 removed on fermi, so instead I'm using invalid command
 0x0058 now as a way to signal completion.

Out of curiosity, isn't this like a handcoded version of software
methods? If so, why handcoded? Or are software methods not supported
on NVC0?


 Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com

 ---
  drivers/gpu/drm/nouveau/nouveau_drv.h   |2 +
  drivers/gpu/drm/nouveau/nouveau_fence.c |   49 
 ---
  drivers/gpu/drm/nouveau/nouveau_fifo.h  |1 +
  drivers/gpu/drm/nouveau/nouveau_state.c |1 +
  drivers/gpu/drm/nouveau/nv04_fifo.c |   25 
  drivers/gpu/drm/nouveau/nv84_fence.c|   18 +--
  drivers/gpu/drm/nouveau/nvc0_fence.c|   12 ++--
  drivers/gpu/drm/nouveau/nvc0_fifo.c |3 +-
  drivers/gpu/drm/nouveau/nve0_fifo.c |   15 +++--
  9 files changed, 110 insertions(+), 16 deletions(-)

 diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
 b/drivers/gpu/drm/nouveau/nouveau_drv.h
 index f97a1a7..d9d274d 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_drv.h
 +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
 @@ -707,6 +707,7 @@ struct drm_nouveau_private {
 struct drm_mm heap;
 struct nouveau_bo *bo;
 } fence;
 +   wait_queue_head_t fence_wq;

 struct {
 spinlock_t lock;
 @@ -1656,6 +1657,7 @@ nv44_graph_class(struct drm_device *dev)
  #define NV84_SUBCHAN_WRCACHE_FLUSH   
 0x0024
  #define NV10_SUBCHAN_REF_CNT 
 0x0050
  #define NVSW_SUBCHAN_PAGE_FLIP   
 0x0054
 +#define NVSW_SUBCHAN_FENCE_WAKE  
 0x0058
  #define NV11_SUBCHAN_DMA_SEMAPHORE   
 0x0060
  #define NV11_SUBCHAN_SEMAPHORE_OFFSET
 0x0064
  #define NV11_SUBCHAN_SEMAPHORE_ACQUIRE   
 0x0068
 diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 
 b/drivers/gpu/drm/nouveau/nouveau_fence.c
 index 3c18049..3ba8dee 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_fence.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
 @@ -68,7 +68,7 @@ nouveau_fence_update(struct nouveau_channel *chan)

 spin_lock(fctx-lock);
 list_for_each_entry_safe(fence, fnext, fctx-pending, head) {
 -   if (priv-read(chan)  fence-sequence)
 +   if (priv-read(chan) - fence-sequence = 0x8000U)
 break;

 if (fence-work)
 @@ -111,11 +111,9 @@ nouveau_fence_done(struct nouveau_fence *fence)
 return !fence-channel;
  }

 -int
 -nouveau_fence_wait(struct nouveau_fence *fence, bool lazy, bool intr)
 +static int nouveau_fence_wait_busy(struct nouveau_fence *fence, bool lazy, 
 bool intr)
  {
 unsigned long sleep_time = NSEC_PER_MSEC / 1000;
 -   ktime_t t;
 int ret = 0;

 while (!nouveau_fence_done(fence)) {
 @@ -127,7 +125,7 @@ nouveau_fence_wait(struct nouveau_fence *fence, bool 
 lazy, bool intr)
 __set_current_state(intr ? TASK_INTERRUPTIBLE :
TASK_UNINTERRUPTIBLE);
 if (lazy) {
 -   t = ktime_set(0, sleep_time);
 +   ktime_t t = ktime_set(0, sleep_time);
 schedule_hrtimeout(t, HRTIMER_MODE_REL);
 sleep_time *= 2;
 if (sleep_time  NSEC_PER_MSEC)
 @@ -144,6 +142,47 @@ nouveau_fence_wait(struct nouveau_fence *fence, bool 
 lazy, bool intr)
 return ret;
  }

 +static int nouveau_fence_wait_event(struct nouveau_fence *fence, bool intr)
 +{
 +   struct drm_nouveau_private *dev_priv = 
 fence-channel-dev-dev_private;
 +   unsigned long timeout = fence-timeout;
 +   int ret = 0;
 +   struct nouveau_channel *chan = dev_priv-channel;
 +   struct nouveau_channel *prev = fence-channel;
 +   struct nouveau_fence_priv *priv = nv_engine(chan-dev, 
 NVOBJ_ENGINE_FENCE);
 +
 +   if (nouveau_fence_done(fence))
 +   return 0;
 +
 +   if (!timeout)
 +   timeout = jiffies + 3 * DRM_HZ;
 +
 +   if (prev != 

Re: I can not use 120Hz with nouveau

[Maarten Maathuis]

If you look at xrandr --verbose you will see an property that is
called scaling mode, set that to none and that should give the same
effect.

But i still get the impression that the 120Hz mode doesn't even stick,
regardless of whether it's using the native mode or not.

On Fri, Jul 6, 2012 at 9:52 AM, HacKurx hack...@gmail.com wrote:
 For 120Hz with nvidia driver I had to disable the following option:
 http://img15.hostingpics.net/pics/250362Nvidia120Hz.png

 Force Full GPU Scaling.

 Thanks

 2012/7/6 HacKurx hack...@gmail.com:
 Thank you for your reply, I tried but it does not change, here is what
 appears in my log :

 [   428.160] (II) NOUVEAU(0): EDID vendor SAM, prod id 1258
 [   428.160] (II) NOUVEAU(0): Using hsync ranges from config file
 [   428.160] (II) NOUVEAU(0): Using vrefresh ranges from config file
 [   428.160] (II) NOUVEAU(0): Printing DDC gathered Modelines:
 [   428.160] (II) NOUVEAU(0): Modeline 1680x1050x0.0  119.00  1680
 1728 1760 1840  1050 1053 1059 1080 +hsync -vsync (64.7 kHz eP)
 [   428.160] (II) NOUVEAU(0): Modeline 1680x1050x0.0  238.46  1680
 1728 1760 1840  1050 1053 1059 1080 +hsync +vsync (129.6 kHz e)
 [   428.160] (II) NOUVEAU(0): Modeline 1680x1050x0.0  218.59  1680
 1728 1760 1840  1050 1053 1059 1080 +hsync +vsync (118.8 kHz e)
 [   428.160] (II) NOUVEAU(0): Modeline 1680x1050x0.0  198.72  1680
 1728 1760 1840  1050 1053 1059 1080 +hsync +vsync (108.0 kHz e)

 Thanks

 2012/7/5 Maarten Maathuis madman2...@gmail.com:
 On Thu, Jul 5, 2012 at 8:38 PM, HacKurx hack...@gmail.com wrote:
 Hello,

 Can you help me?
 I cannot use 120Hz on my Samsung 2233RZ with nouveau.

 My xorg.conf :
 https://forums.gentoo.org/viewtopic-t-929124.html

 Thanks

 Best regards,

 HacKurx
 www.hackurx.info
 ___
 xorg@lists.x.org: X.Org support
 Archives: http://lists.freedesktop.org/archives/xorg
 Info: http://lists.x.org/mailman/listinfo/xorg
 Your subscription address: madman2...@gmail.com

 Have you tried xrandr --output DVI-I-1 --mode 1680x1050 --rate 120?

 --
 Far away from the primal instinct, the song seems to fade away, the
 river get wider between your thoughts and the things we do and say.



 --
 Best regards,

 HacKurx
 www.hackurx.info



 --
 Best regards,

 HacKurx
 www.hackurx.info



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: I can not use 120Hz with nouveau

[Maarten Maathuis]

On Thu, Jul 5, 2012 at 8:38 PM, HacKurx hack...@gmail.com wrote:
 Hello,

 Can you help me?
 I cannot use 120Hz on my Samsung 2233RZ with nouveau.

 My xorg.conf :
 https://forums.gentoo.org/viewtopic-t-929124.html

 Thanks

 Best regards,

 HacKurx
 www.hackurx.info
 ___
 xorg@lists.x.org: X.Org support
 Archives: http://lists.freedesktop.org/archives/xorg
 Info: http://lists.x.org/mailman/listinfo/xorg
 Your subscription address: madman2...@gmail.com

Have you tried xrandr --output DVI-I-1 --mode 1680x1050 --rate 120?

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.x.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

[Nouveau] [PATCH 1/2] nouveau/exa: unref bo if map failed

[Maarten Maathuis]

Signed-off-by: Maarten Maathuis madman2...@gmail.com
---
 src/nouveau_exa.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/src/nouveau_exa.c b/src/nouveau_exa.c
index 55dce99..c51a799 100644
--- a/src/nouveau_exa.c
+++ b/src/nouveau_exa.c
@@ -175,11 +175,15 @@ nouveau_exa_scratch(NVPtr pNv, int size, struct 
nouveau_bo **pbo, int *off)
ret = nouveau_bo_new(pNv-dev, NOUVEAU_BO_GART | NOUVEAU_BO_MAP,
 0, NOUVEAU_ALIGN(size, 1 * 1024 * 1024),
 NULL, bo);
-   if (ret == 0)
-   ret = nouveau_bo_map(bo, NOUVEAU_BO_RDWR, pNv-client);
if (ret != 0)
return ret;
 
+   ret = nouveau_bo_map(bo, NOUVEAU_BO_RDWR, pNv-client);
+   if (ret != 0) {
+   nouveau_bo_ref(NULL, bo);
+   return ret;
+   }
+
nouveau_bo_ref(bo, pNv-transfer);
pNv-transfer_offset = 0;
}
-- 
1.7.8.6

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 14/14] drm/nouveau/therm: Rework nouveau_therm_create()

[Maarten Maathuis]

On Mon, May 21, 2012 at 8:30 AM, Ben Skeggs skeg...@gmail.com wrote:
 On Mon, May 21, 2012 at 12:15:03AM +0100, Emil Velikov wrote:
 It contains a few changes mainly targeting the following
  * Therm table is present in BIT vbios
  * Parse the vbios table before hooking temp_get(), as it contains the therm
 sensor calibration data
  * Add dummy_therm_temp_get() function to prevent multiple null dereff's

 I didn't take this patch at all yet.  I'll let Martin put his input into
 this instead.  I didn't really touch the thermal stuff aside from matching
 APIs because he's got an overhaul pending anyway.

 Comments on specific pieces inline as they may be useful.


 Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
 ---
  drivers/gpu/drm/nouveau/nouveau_pm.c    |    2 +-
  drivers/gpu/drm/nouveau/nouveau_therm.c |   63 
 ---
  2 files changed, 50 insertions(+), 15 deletions(-)

 diff --git a/drivers/gpu/drm/nouveau/nouveau_pm.c 
 b/drivers/gpu/drm/nouveau/nouveau_pm.c
 index 9dd34fe..1b4422b 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_pm.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_pm.c
 @@ -693,7 +693,7 @@ nouveau_hwmon_init(struct nouveau_device *ndev)
       }

       /* if the card can read the fan rpm */
 -     if (nouveau_gpio_func_valid(ndev, DCB_GPIO_FAN_SENSE)) {
 +     if (pfan  pfan-sense(pfan) = 0) {
               ret = sysfs_create_group(dev-pdev-dev.kobj,
                                        hwmon_fan_rpm_attrgroup);
               if (ret)
 diff --git a/drivers/gpu/drm/nouveau/nouveau_therm.c 
 b/drivers/gpu/drm/nouveau/nouveau_therm.c
 index acf81a9..91095be 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_therm.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_therm.c
 @@ -30,6 +30,12 @@
  #include nouveau_pm.h
  #include nouveau_therm.h

 +static inline int
 +dummy_therm_temp_get(struct nouveau_therm *ptherm)
 +{
 +     return 0;
 +}
 +
 I don't really like this, if we can't expose any thermal data I think we
 just shouldn't create a thermal subdev?

  static int
  nv40_sensor_setup(struct nouveau_therm *ptherm)
  {
 @@ -181,7 +187,7 @@ nouveau_therm_vbios_parse(struct nouveau_therm *ptherm, 
 u8 *temp)
       temp = temp + headerlen;

       /* Read the entries from the table */
 -     for (i = 0; i  entries; i++) {
 +     for (i = 0; i  entries; i++, temp += recordlen) {
               s16 value = ROM16(temp[1]);

               switch (temp[0]) {
 @@ -228,7 +234,6 @@ nouveau_therm_vbios_parse(struct nouveau_therm *ptherm, 
 u8 *temp)
                       ptherm-fan.pwm_freq = value;
                       break;
               }
 -             temp += recordlen;
       }

       nouveau_therm_safety_checks(ptherm);
 @@ -299,6 +304,12 @@ nouveau_therm_probe_i2c(struct nouveau_device *ndev)
                            probe_monitoring_device, NV_I2C_DEFAULT(0));
  }

 +static void
 +nouveau_ptherm_destroy(struct nouveau_device *ndev, int subdev)
 +{
 +// XXX: Undo probe_monitoring_device
 +}
 +
  int
  nouveau_therm_create(struct nouveau_device *ndev, int subdev)
  {
 @@ -307,29 +318,53 @@ nouveau_therm_create(struct nouveau_device *ndev, int 
 subdev)
       u8 *temp = NULL;
       int ret;

 -     ret = nouveau_subdev_create(ndev, subdev, THERM, thermal, ptherm);
 -     if (ret)
 -             return ret;
 +     if (bios-type == NVBIOS_BIT) {
 +             if (bit_table(ndev, 'P', P))
 +                     return 0;
 The BIT check isn't necessary, bit_table() will fail if it's not a BIT BIOS.


 -     if (ndev-chipset = 0x40  ndev-chipset  0x84)
 -             ptherm-temp_get = nv40_therm_temp_get;
 -     else
 -     if (ndev-chipset = 0xd9)
 -             ptherm-temp_get = nv84_therm_temp_get;
 -
 -     if (bit_table(ndev, 'P', P) == 0) {
               if (P.version == 1)
                       temp = ROMPTR(ndev, P.data[12]);
               else
               if (P.version == 2)
                       temp = ROMPTR(ndev, P.data[16]);
 -             else
 +             else {
                       NV_WARN(ndev, unknown temp for BIT P %d\n, 
 P.version);
 +             }
 +     } else {
 +             return 0;
 +     }

 -             nouveau_therm_vbios_parse(ptherm, temp);
 +     if (!temp) {
 +             NV_DEBUG(ndev, temp table pointer invalid\n);
 +             return 0;
       }

 +     ret = nouveau_subdev_create(ndev, subdev, THERM, thermal, ptherm);
 +     if (ret)
 +             return ret;
 +
 +     nouveau_therm_vbios_parse(ptherm, temp);
       nouveau_therm_probe_i2c(ndev);

 +     ptherm-base.destroy = nouveau_ptherm_destroy;
 +     switch (ndev-card_type) {
 +     case NV_40:
 +     case NV_50:
 +     case NV_C0:
 +     case NV_D0:
 +     case NV_E0:
 +             if (ndev-chipset  0x84) {
 +                     ptherm-temp_get = nv40_therm_temp_get;
 +                     break;
 +             } else
 +             if (ndev-chipset = 0xd9) {
 +                     ptherm-temp_get = nv84_therm_temp_get;
 +                     break;
 +     

Re: lack of reviewers

[Maarten Maathuis]

On Fri, May 18, 2012 at 1:17 PM, Michal Suchanek hramr...@gmail.com wrote:
 On 18 May 2012 12:40, Peter Hutterer peter.hutte...@who-t.net wrote:
 On 18/05/12 19:26 , Michal Suchanek wrote:

 On 18 May 2012 01:14, Peter Huttererpeter.hutte...@who-t.net  wrote:

 On Thu, May 17, 2012 at 10:39:55AM +0200, Ernst Sjöstrand wrote:

 Hi,

 (sorry for jumping in from the outside and breaking the thread!)

 I read about this problem and wanted to offer a suggestion!

 What if you set up a Gerrit server for git.freedesktop.org? That's the
 tool the Android OpenSource project uses among other things:
 https://android-review.googlesource.com/
 Perhaps if it was easier to contribute to reviewing code, more people
 would do it more often?


 It's also a very nice tool I have to say, I use it every day at work.
 It's easy to integrate with automatic
 testing of patchsets before they're submitted to the repository for
 example.


 tbh I doubt what we have is a tool problem. Patches are sent to the list
 and
 can be reviewed quite easily there (for subscribers, anyway). The issue
 we
 have is manpower and, more importantly, manpower of people with enough
 knowledge to judge whether a patchset has side-effects beyond the
 obvious.

 in the end, such patches tend fall on the shoulders of a few and adding
 another tool that they have to check will increase, not decrease, the
 workload for those.


 tbh using a mailing list for that looks very impractical.

 - patches get missed completely


 true. we do encourage people to re-submit. which, aside from the obvious
 disadvantage, has advantages too. I found the problem with any todo list is
 that sooner or later it becomes so long that you either have to wipe it (by
 switching to a different system sometimes) or you start ignoring stuff
 anyway.

 given that one of the problems is reviewer bandwidth, I expect this to
 happen with any new tool. patchwork was great in the first few weeks, now
 it's a kitchensink great for getting URLs and not much else.

 Given that reviewer bandwidth is scarce it would be perhaps helpful to
 spare it by having a tool that presents all the not-yet-reviewed
 patches in one place rather than reviewers fishing for them in the
 mailing list or in the patchwork.


 requiring people to ping when patches get missed at least notifies us which
 patches have people behind them that care. a feature that gets submitted
 once, forgotten and no-one pings for it may not have been that important to
 begin with.

 When you get the 5th patch for the same regression submitted the third
 time it starts to look like shouting your patches off a cliff in the
 dead of the night.




 - there is no track of what is related to what (as in the part of the
 same patchset or new revision of the same patchset)


 patch are usually in numbered series, in threads, with new revisinos being
 prefixed with v2, v3, etc. requires submitter discipline but it works to
 some degree.

 And as some of the patches get replies they get out of order and
 completely out of context.



 - you get a lots of list noise due to patches being sent one by one


 I'm not sure I follow this argument, can you expand?

 Like a series of 10+ patches for some part of the X server I do not
 understand landing on the list several times.

 I guess some people are fond of replying to the patches and quoting
 them in their email client and I can see that as nice feature but it's
 paid for by tons of list traffic. Necessarily large part of that is
 meaningless to most.

 The alternative is, of course, a link to git branch or something like that.

 Thanks

 Michal
 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel

I think that a tool that allows you to see diffs in a web interface
and do point-and-click defect submission would never hurt. As long as
it doesn't interfere with existing processes (too much).

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: lack of reviewers

[Maarten Maathuis]

On Fri, May 18, 2012 at 5:56 PM, Michal Suchanek hramr...@gmail.com wrote:
 On 18 May 2012 17:38, Maarten Maathuis madman2...@gmail.com wrote:


 I think that a tool that allows you to see diffs in a web interface
 and do point-and-click defect submission would never hurt. As long as
 it doesn't interfere with existing processes (too much).

 Of course it interferes with the existing process.

 If it was not used it would be of no use.

 Thanks

 Michal

You don't have to make it required, if the system is successful people
will migrate out of free will.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: [Nouveau] NV43: Native resolution not available on Dell 2007FP

[Maarten Maathuis]

On Fri, May 4, 2012 at 5:55 PM, Mark Hills m...@pogo.org.uk wrote:
 I have a Dell 2007FP monitor. NV43 (GeForce 6600) can not use the native
 resolution.

 1600x1200 is listed under DDC gathered Modelines with the rest of the
 info, but then is missing from probed modes.

 I have a secondary card, NV4a (GeForce 6200, PCI). It works with this
 card. This card does not show DDC gathered modelines at all, and
 1600x1200 is listed under probed modes.

 Does this mean the NV4a card is not using the DDC info? Is it a bug
 preventing 1600x1200 being used with the NV43, or some consequence of DDC
 info?

 I am using Nouveau from Git, and kernel 3.4.0-rc4. The proprietary NVidia
 driver fully works, as does another 1600x1200 monitor (Lacie).

 Thanks

 --
 Mark



 [  4676.920] (--) NOUVEAU(0): Chipset: NVIDIA NV43
 [  4676.920] (II) NOUVEAU(0): Creating default Display subsection in Screen 
 section
        Default Screen Section for depth/fbbpp 24/32
 [  4676.920] (==) NOUVEAU(0): Depth 24, (--) framebuffer bpp 32
 [  4676.920] (==) NOUVEAU(0): RGB weight 888
 [  4676.920] (==) NOUVEAU(0): Default visual is TrueColor
 [  4676.920] (==) NOUVEAU(0): Using HW cursor
 [  4676.920] (==) NOUVEAU(0): GLX sync to VBlank disabled.
 [  4676.920] (==) NOUVEAU(0): Page flipping enabled
 [  4676.920] (==) NOUVEAU(0): Swap limit set to 1 [Max allowed 2]
 [  4676.940] (II) NOUVEAU(0): Output DVI-I-1 has no monitor section
 [  4676.966] (II) NOUVEAU(0): Output DVI-I-2 has no monitor section
 [  4677.054] (II) NOUVEAU(0): Output TV-1 has no monitor section
 [  4677.073] (II) NOUVEAU(0): EDID for output DVI-I-1
 [  4677.073] (II) NOUVEAU(0): Manufacturer: DEL  Model: a021  Serial#: 
 809779539
 [  4677.073] (II) NOUVEAU(0): Year: 2006  Week: 21
 [  4677.073] (II) NOUVEAU(0): EDID Version: 1.3
 [  4677.074] (II) NOUVEAU(0): Digital Display Input
 [  4677.074] (II) NOUVEAU(0): Max Image Size [cm]: horiz.: 41  vert.: 31
 [  4677.074] (II) NOUVEAU(0): Gamma: 2.20
 [  4677.074] (II) NOUVEAU(0): DPMS capabilities: StandBy Suspend Off
 [  4677.074] (II) NOUVEAU(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
 [  4677.074] (II) NOUVEAU(0): Default color space is primary color space
 [  4677.074] (II) NOUVEAU(0): First detailed timing is preferred mode
 [  4677.074] (II) NOUVEAU(0): redX: 0.640 redY: 0.330   greenX: 0.300 greenY: 
 0.600
 [  4677.074] (II) NOUVEAU(0): blueX: 0.150 blueY: 0.060   whiteX: 0.312 
 whiteY: 0.329
 [  4677.074] (II) NOUVEAU(0): Supported established timings:
 [  4677.074] (II) NOUVEAU(0): 720x400@70Hz
 [  4677.074] (II) NOUVEAU(0): 640x480@60Hz
 [  4677.074] (II) NOUVEAU(0): 640x480@75Hz
 [  4677.074] (II) NOUVEAU(0): 800x600@60Hz
 [  4677.074] (II) NOUVEAU(0): 800x600@75Hz
 [  4677.074] (II) NOUVEAU(0): 1024x768@60Hz
 [  4677.074] (II) NOUVEAU(0): 1024x768@75Hz
 [  4677.074] (II) NOUVEAU(0): 1280x1024@75Hz
 [  4677.074] (II) NOUVEAU(0): Manufacturer's mask: 0
 [  4677.074] (II) NOUVEAU(0): Supported standard timings:
 [  4677.074] (II) NOUVEAU(0): #0: hsize: 1280  vsize 1024  refresh: 60  vid: 
 32897
 [  4677.074] (II) NOUVEAU(0): #1: hsize: 1600  vsize 1200  refresh: 60  vid: 
 16553
 [  4677.074] (II) NOUVEAU(0): #2: hsize: 1152  vsize 864  refresh: 75  vid: 
 20337
 [  4677.074] (II) NOUVEAU(0): Supported detailed timing:
 [  4677.074] (II) NOUVEAU(0): clock: 162.0 MHz   Image Size:  367 x 275 mm
 [  4677.074] (II) NOUVEAU(0): h_active: 1600  h_sync: 1664  h_sync_end 1856 
 h_blank_end 2160 h_border: 0
 [  4677.074] (II) NOUVEAU(0): v_active: 1200  v_sync: 1201  v_sync_end 1204 
 v_blanking: 1250 v_border: 0
 [  4677.074] (II) NOUVEAU(0): Serial No: Y992365P0DAS
 [  4677.074] (II) NOUVEAU(0): Monitor name: DELL 2007FP
 [  4677.074] (II) NOUVEAU(0): Ranges: V min: 56 V max: 76 Hz, H min: 30 H 
 max: 83 kHz, PixClock max 175 MHz
 [  4677.074] (II) NOUVEAU(0): EDID (in hex):
 [  4677.074] (II) NOUVEAU(0):   000010ac21a053414430
 [  4677.074] (II) NOUVEAU(0):   1510010380291f7891a3544c9926
 [  4677.074] (II) NOUVEAU(0):   0f5054a54b008180a940714f01010101
 [  4677.074] (II) NOUVEAU(0):   010101010101483f403062b0324040c0
 [  4677.074] (II) NOUVEAU(0):   13006f13111e00ff00593939
 [  4677.074] (II) NOUVEAU(0):   3233363550304441530a00fc0044
 [  4677.074] (II) NOUVEAU(0):   454c4c203230303746500a2000fd
 [  4677.074] (II) NOUVEAU(0):   00384c1e5311000a2020202020200084
 [  4677.074] (II) NOUVEAU(0): EDID vendor DEL, prod id 40993
 [  4677.074] (II) NOUVEAU(0): Using EDID range info for horizontal sync
 [  4677.074] (II) NOUVEAU(0): Using EDID range info for vertical refresh
 [  4677.074] (II) NOUVEAU(0): Printing DDC gathered Modelines:
 [  4677.074] (II) NOUVEAU(0): Modeline 1600x1200x0.0  162.00  1600 1664 
 1856 2160  1200 1201 1204 1250 +hsync +vsync (75.0 kHz)
 [  4677.074] (II) NOUVEAU(0): Modeline 800x600x0.0   40.00  800 840 968 
 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
 [  4677.074] (II) NOUVEAU(0): Modeline 640x480x0.0   31.50  640 656 720 840 
  480 481 484 500 

Linux 3.4-rc4

[Maarten Maathuis]

On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
 wrote:
> On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
>> On 2012-04-28 02:19 -0400, Alex Deucher wrote:
>> > On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler  
>> > wrote:
>> > > Hi Ben,
>> > >
>> > > On 2012-04-27 15:20 +1000, Ben Skeggs wrote:
>> > >> Does this patch help you at all?
>> > >>
>> > >> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305
>> > >
>> > > Yes. ?I cherry-picked this patch on top of Linus' master (3.4-rc4+) and
>> > > this appears to solve the "black screen on VGA" problem described in the
>> > > original report. ?Thanks!
>> > >
>> > > Unfortunately, that's not the end of my VGA-related regressions. :(
>> > >
>> > > While tracking down the black screen issue, I've been having the monitor
>> > > directly connected to the video card the whole time, but now when I'm
>> > > connected through my KVM switch (an IOGear GCS1804), it appears that
>> > > something's going wrong with reading the EDID, because the available
>> > > modes are all screwed up (both console and X decide they want to drive
>> > > the display at 1024x768). ?Here's the output of xrandr on 3.2.15:
>> > >
>> > > ?% xrandr
>> > > ?Screen 1: minimum 320 x 200, current 1600 x 1200, maximum 4096 x 4096
>> > > ?VGA-1 connected 1600x1200+0+0 (normal left inverted right x axis y 
>> > > axis) 352mm x 264mm
>> > > ? ? 1600x1200 ? ? ?75.0*+ ? 70.0 ? ? 65.0 ? ? 60.0
>> > > ? ? 1280x1024 ? ? ?85.0 + ? 75.0 ? ? 60.0
>> > > ? ? 1920x1440 ? ? ?60.0
>> > > ? ? 1856x1392 ? ? ?60.0
>> > > ? ? 1792x1344 ? ? ?60.0
>> > > ? ? 1920x1200 ? ? ?74.9 ? ? 59.9
>> > > ? ? 1680x1050 ? ? ?84.9 ? ? 74.9 ? ? 60.0
>> > > ? ? 1400x1050 ? ? ?85.0 ? ? 74.9 ? ? 60.0
>> > > ? ? 1440x900 ? ? ? 84.8 ? ? 75.0 ? ? 59.9
>> > > ? ? 1280x960 ? ? ? 85.0 ? ? 60.0
>> > > ? ? 1360x768 ? ? ? 60.0
>> > > ? ? 1280x800 ? ? ? 84.9 ? ? 74.9 ? ? 59.8
>> > > ? ? 1152x864 ? ? ? 75.0
>> > > ? ? 1280x768 ? ? ? 84.8 ? ? 74.9 ? ? 59.9
>> > > ? ? 1024x768 ? ? ? 85.0 ? ? 75.1 ? ? 75.0 ? ? 70.1 ? ? 60.0 ? ? 43.5 ? ? 
>> > > 43.5
>> > > ? ? 832x624 ? ? ? ?74.6
>> > > ? ? 800x600 ? ? ? ?85.1 ? ? 72.2 ? ? 75.0 ? ? 60.3 ? ? 56.2
>> > > ? ? 848x480 ? ? ? ?60.0
>> > > ? ? 640x480 ? ? ? ?85.0 ? ? 75.0 ? ? 72.8 ? ? 72.8 ? ? 66.7 ? ? 60.0 ? ? 
>> > > 59.9
>> > > ? ? 720x400 ? ? ? ?85.0 ? ? 87.8 ? ? 70.1
>> > > ? ? 640x400 ? ? ? ?85.1
>> > > ? ? 640x350 ? ? ? ?85.1
>> > > ? ? 320x200 ? ? ? 165.1
>> > >
>> > > And on 3.4-rc4+ (with your patch cherry-picked):
>> > >
>> > > ?% xrandr
>> > > ?Screen 1: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
>> > > ?VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 
>> > > 0mm x 0mm
>> > > ? ? 1024x768 ? ? ? 60.0*
>> > > ? ? 800x600 ? ? ? ?60.3 ? ? 56.2
>> > > ? ? 848x480 ? ? ? ?60.0
>> > > ? ? 640x480 ? ? ? ?59.9
>> > > ? ? 320x200 ? ? ? 165.1
>> > >
>> > > Running xrandr on 3.4-rc4+ also causes the screen to go black for a
>> > > second when it does not on 3.2.15. ?It also causes several messages of
>> > > the form
>> > >
>> > > ?[drm] nouveau :01:00.0: Load detected on output B
>> > >
>> > > to be logged. ?Also, looking at /sys/class/drm/card0-VGA-1/edid I see
>> > > that it is empty on 3.4-rc4+ and it is correct on 3.2.15. ?Things seem
>> > > to work OK when the KVM is not involved.
>> >
>> > Were you ever able to fetch a EDID with the KVM involved? ?KVMs are
>> > notorious for not connecting the ddc pins.
>>
>> Yes, it works on 3.2.15 as described above.
>
> I have the same (or similar) KVM (not in the office at the moment) and I
> can confirm that with newer kernels EDID fecthing in flaky. It's 50/50
> if EDED retrieval succeeds or if it fails with:
>
> Apr 26 13:06:57 dtor-d630 kernel: [13464.936336] [drm:drm_edid_block_valid] 
> *ERROR* EDID checksum is invalid, remainder is 208
> Apr 26 13:06:57 dtor-d630 kernel: [13464.955317] [drm:drm_edid_block_valid] 
> *ERROR* EDID checksum is invalid, remainder is 208
> Apr 26 13:06:57 dtor-d630 kernel: [13464.973879] [drm:drm_edid_block_valid] 
> *ERROR* EDID checksum is invalid, remainder is 208
> Apr 27 09:13:03 dtor-d630 kernel: [44602.087659] [drm:drm_edid_block_valid] 
> *ERROR* EDID checksum is invalid, remainder is 208
> Apr 27 09:13:03 dtor-d630 kernel: [44602.107147] [drm:drm_edid_block_valid] 
> *ERROR* EDID checksum is invalid, remainder is 208
> Apr 27 09:13:03 dtor-d630 kernel: [44602.126908] [drm:drm_edid_block_valid] 
> *ERROR* EDID checksum is invalid, remainder is 208
> Apr 27 09:13:03 dtor-d630 kernel: [44602.146277] [drm:drm_edid_block_valid] 
> *ERROR* EDID checksum is invalid, remainder is 208
> Apr 27 09:13:03 dtor-d630 kernel: [44602.297659] [drm:drm_edid_block_valid] 
> *ERROR* EDID checksum is invalid, remainder is 208
> Apr 27 09:13:03 dtor-d630 kernel: [44602.317063] [drm:drm_edid_block_valid] 
> *ERROR* EDID checksum is invalid, remainder is 208
>
> Earlier kernels were able to retrieve EDEDs reliably.
>
> This is with:
>
> [ ? 

Re: Linux 3.4-rc4

[Maarten Maathuis]

On Mon, Apr 30, 2012 at 12:37 AM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
 On Sat, Apr 28, 2012 at 11:33:50AM -0400, Nick Bowler wrote:
 On 2012-04-28 02:19 -0400, Alex Deucher wrote:
  On Fri, Apr 27, 2012 at 8:39 PM, Nick Bowler nbow...@elliptictech.com 
  wrote:
   Hi Ben,
  
   On 2012-04-27 15:20 +1000, Ben Skeggs wrote:
   Does this patch help you at all?
  
   http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=a3a285f17867f0018de798b5ee85731ec1268305
  
   Yes.  I cherry-picked this patch on top of Linus' master (3.4-rc4+) and
   this appears to solve the black screen on VGA problem described in the
   original report.  Thanks!
  
   Unfortunately, that's not the end of my VGA-related regressions. :(
  
   While tracking down the black screen issue, I've been having the monitor
   directly connected to the video card the whole time, but now when I'm
   connected through my KVM switch (an IOGear GCS1804), it appears that
   something's going wrong with reading the EDID, because the available
   modes are all screwed up (both console and X decide they want to drive
   the display at 1024x768).  Here's the output of xrandr on 3.2.15:
  
    % xrandr
    Screen 1: minimum 320 x 200, current 1600 x 1200, maximum 4096 x 4096
    VGA-1 connected 1600x1200+0+0 (normal left inverted right x axis y 
   axis) 352mm x 264mm
       1600x1200      75.0*+   70.0     65.0     60.0
       1280x1024      85.0 +   75.0     60.0
       1920x1440      60.0
       1856x1392      60.0
       1792x1344      60.0
       1920x1200      74.9     59.9
       1680x1050      84.9     74.9     60.0
       1400x1050      85.0     74.9     60.0
       1440x900       84.8     75.0     59.9
       1280x960       85.0     60.0
       1360x768       60.0
       1280x800       84.9     74.9     59.8
       1152x864       75.0
       1280x768       84.8     74.9     59.9
       1024x768       85.0     75.1     75.0     70.1     60.0     43.5     
   43.5
       832x624        74.6
       800x600        85.1     72.2     75.0     60.3     56.2
       848x480        60.0
       640x480        85.0     75.0     72.8     72.8     66.7     60.0     
   59.9
       720x400        85.0     87.8     70.1
       640x400        85.1
       640x350        85.1
       320x200       165.1
  
   And on 3.4-rc4+ (with your patch cherry-picked):
  
    % xrandr
    Screen 1: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
    VGA-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 
   0mm x 0mm
       1024x768       60.0*
       800x600        60.3     56.2
       848x480        60.0
       640x480        59.9
       320x200       165.1
  
   Running xrandr on 3.4-rc4+ also causes the screen to go black for a
   second when it does not on 3.2.15.  It also causes several messages of
   the form
  
    [drm] nouveau :01:00.0: Load detected on output B
  
   to be logged.  Also, looking at /sys/class/drm/card0-VGA-1/edid I see
   that it is empty on 3.4-rc4+ and it is correct on 3.2.15.  Things seem
   to work OK when the KVM is not involved.
 
  Were you ever able to fetch a EDID with the KVM involved?  KVMs are
  notorious for not connecting the ddc pins.

 Yes, it works on 3.2.15 as described above.

 I have the same (or similar) KVM (not in the office at the moment) and I
 can confirm that with newer kernels EDID fecthing in flaky. It's 50/50
 if EDED retrieval succeeds or if it fails with:

 Apr 26 13:06:57 dtor-d630 kernel: [13464.936336] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 26 13:06:57 dtor-d630 kernel: [13464.955317] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 26 13:06:57 dtor-d630 kernel: [13464.973879] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 27 09:13:03 dtor-d630 kernel: [44602.087659] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 27 09:13:03 dtor-d630 kernel: [44602.107147] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 27 09:13:03 dtor-d630 kernel: [44602.126908] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 27 09:13:03 dtor-d630 kernel: [44602.146277] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 27 09:13:03 dtor-d630 kernel: [44602.297659] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208
 Apr 27 09:13:03 dtor-d630 kernel: [44602.317063] [drm:drm_edid_block_valid] 
 *ERROR* EDID checksum is invalid, remainder is 208

 Earlier kernels were able to retrieve EDEDs reliably.

 This is with:

 [    1.678392] [drm] nouveau :01:00.0: Detected an NV50 generation card 
 (0x086b00a2)

 Thanks.

 --
 Dmitry
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel


Just a crazy thought, 

Re: [Nouveau] [PATCH 2/2] drm/nouveau: implement precise vblank timestamping

[Maarten Maathuis]

It seems a bit strange to go in between a register and defines that
probably belong to that register.

On Thu, Apr 26, 2012 at 12:26 AM, Lucas Stach d...@lynxeye.de wrote:
  #define NV_PCRTC_ENGINE_CTRL                           0x00600860
 +#define NV_PCRTC_STAT(i0)                      (0x00600868 + 0x2000*(i0))
  #      define NV_CRTC_FSEL_I2C                                 (1  4)
  #      define NV_CRTC_FSEL_OVERLAY                             (1  12)



-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] rendering problems with latest ddx driver (nv50)

[Maarten Maathuis]

On Tue, Apr 24, 2012 at 8:36 PM, Martin Peres martin.pe...@free.fr wrote:
 Le 24/04/2012 20:14, Maarten Maathuis a écrit :

 Do you get rendering errors also when using a nv50 class gpu? I seem
 to get them in firefox.

 I also noticed a huge amount of failures when running rendercheck -t
 gradients, which i find odd, because they are not supposed to be
 accelerated.

 Hi,

 By any chance, are you using cairo 1.12? If so, try downgrading to cairo
 1.10.

 Martin

No, i'm using cairo 1.10.2. Also rendercheck isn't affected by cairo.
The last driver upgrade included at least the migration to the new
libdrm and everything that came after it. That's when the rendering
corruption started.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] nvidia gt 545 and nouveau

[Maarten Maathuis]

On Thu, Apr 5, 2012 at 2:25 AM, Daniel Wallace
daniel.wall...@gatech.edu wrote:
 I have 2 monitors plugged into the same nvidia card
 (running nouveau) one can be either DVI-I or VGA(vga right now) and the
 other is hdmi, right now, I am just trying to get the monitors to not
 be clones of each other and to be side by side. When i do xrandr
 --output HDMI-1 --pos 0x0 --output VGA-1 --auto --right-of HDMI-1, the
 whole screen freezes with the mouse in between the 2 monitors and I
 can't do anything except kill the power and reboot, Anyone have any
 ideas where to start, because I have looked for several hours now and I
 can't find anything that would be causing this issue.

 What happens when It freezes is the mouse literally gets stuck in
 between the two screens (half on either screen) and since I am unable
 to do any commands with the keyboard I can't take a screen shot.  I
 would really like to be able to use nouveau and xrandr, because I don't
 really want to use Xinerama with the proprietary drivers because then I
 am unable to use compositing.

 Any thoughts and questions would be greatly appreciated.

 Thanks,
 Daniel Wallace

 ___
 Nouveau mailing list
 Nouveau@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/nouveau


What happens if you want to set the framebuffer size to the size of
your two monitors combined?

1280x1024+1280x1024 would be:
xrandr --fb 2560x1024

Afterwards xrandr should say current 2560x1024 somewhere at the
beginning of it's output.

I assume your two monitors work in clone, so i i'm wondering if it's
the framebuffer allocation that causes the problem.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] nvidia gt 545 and nouveau

[Maarten Maathuis]

On Fri, Apr 6, 2012 at 12:36 AM, Daniel Wallace
daniel.wall...@gatech.edu wrote:
 here are my some logs if anyone is interested
 Xorg.0.log http://sprunge.us/CIgO?text
 dmesg http://sprunge.us/cegQ?text

 and
 Xorg.0.log after applying this patch
 http://permalink.gmane.org/gmane.comp.freedesktop.xorg.devel/29650

 http://sprunge.us/LMjV?text


 here is all the information I get from inxi -F
 http://sprunge.us/TOef
 any help would be appreciated,
 Thank you,
 Daniel Wallace

 On Thu, Apr 05, 2012 at 04:24:46AM -0400, Daniel Wallace wrote:
 On Thu, Apr 05, 2012 at 08:46:01AM +0200, Maarten Maathuis wrote:
  On Thu, Apr 5, 2012 at 2:25 AM, Daniel Wallace
  daniel.wall...@gatech.edu wrote:
   I have 2 monitors plugged into the same nvidia card
   (running nouveau) one can be either DVI-I or VGA(vga right now) and the
   other is hdmi, right now, I am just trying to get the monitors to not
   be clones of each other and to be side by side. When i do xrandr
   --output HDMI-1 --pos 0x0 --output VGA-1 --auto --right-of HDMI-1, the
   whole screen freezes with the mouse in between the 2 monitors and I
   can't do anything except kill the power and reboot, Anyone have any
   ideas where to start, because I have looked for several hours now and I
   can't find anything that would be causing this issue.
  
   What happens when It freezes is the mouse literally gets stuck in
   between the two screens (half on either screen) and since I am unable
   to do any commands with the keyboard I can't take a screen shot.  I
   would really like to be able to use nouveau and xrandr, because I don't
   really want to use Xinerama with the proprietary drivers because then I
   am unable to use compositing.
  
   Any thoughts and questions would be greatly appreciated.
  
   Thanks,
   Daniel Wallace
  
   ___
   Nouveau mailing list
   Nouveau@lists.freedesktop.org
   http://lists.freedesktop.org/mailman/listinfo/nouveau
  
 
  What happens if you want to set the framebuffer size to the size of
  your two monitors combined?
 
  1280x1024+1280x1024 would be:
  xrandr --fb 2560x1024
 
  Afterwards xrandr should say current 2560x1024 somewhere at the
  beginning of it's output.
 
  I assume your two monitors work in clone, so i i'm wondering if it's
  the framebuffer allocation that causes the problem.
 
  --
  Far away from the primal instinct, the song seems to fade away, the
  river get wider between your thoughts and the things we do and say.

 with xrandr --fb 3840x1080 then
 xrandr --output HDMI-1 --pos 0x0 --output VGA-1 --right-of HDMI-1

 it now shows both screens, and everything looks fine, except for the
 fact that the mouse is on the border of both screens, half on both and
 I can't move it or have any keyboard actions, just have to reboot the
 computer



Based on the xorg log this looks like some kind cursor/mouse/input
related bug. Its probably a good idea to try either the xorg
mailinglist or simply file a bug. You should do something like:

If you ask on the mailinglist i would put this (BUG: triggered 'if
(!dev-valuator || dev-valuator-numAxes  2)' BUG: getevents.c:845
in scale_to_desktop()) in the title, this hopefully triggers whoevers
knows what the problem could be to look at it.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

BUG: drm_crtc_helper_set_config does not work

[Maarten Maathuis]

On Fri, Mar 9, 2012 at 5:28 PM, Yufeng Shen  wrote:
> On Fri, Mar 9, 2012 at 3:15 AM, Maarten Maathuis  
> wrote:
>> On Fri, Mar 9, 2012 at 2:50 AM, Yufeng Shen  wrote:
>>> So a simple case of ?disabling a CRTC and then re-enabling it.
>>>
>>> Disabling:
>>>
>>> CRTC X is originally connected to output Y
>>>
>>> 1. XRRSetCrtcConfig() ? ?is called to disable CRTC ?X
>>>
>>> 2. drm_helper_connector_dpms() ? then gets called on the connector
>>> connected to CRTC X,
>>> ? ?in the function,
>>> ? ?the ?connector->encoder ?is set to DPMS OFF, ? and the
>>> encoder->crtc ?set to DPMS OFF
>>> ? ?but the ?encoder->crtc ? is still CRTC X
>>>
>>> Re-enabling:
>>>
>>> 3. XRRSetCrtcConfig() ? ?is called to to enable CRTC ?X ?on output Y
>>>
>>> 4. drm_crtc_helper_set_config () ?is now called,
>>> suppose ? fb is not changed, ?mode is not changed, encoder is not changed
>>> and the ? encoder->crtc ?is not changed,
>>> then we have ? mode_changed == false ? ?and ?the mode is not reset
>>>
>>> So the CRTC X won't be connected to output Y.
>>>
>>> What I don't understand the code is that why ?XRRSetCrtcConfig() ?ends
>>> up only calling ?drm_helper_connector_dpms() ??
>>> I think it should do more than that, at least it should set the
>>> related ?encoder->crtc = NULL
>>>
>>> any comments ?
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>> As far as i know DPMS designed is a simple switch, meaning that the
>> mode remains active, so if you do DPMS ON it should come back. If for
>> some reason the driver is disconnecting the encoder from the crtc,
>> then it is the drivers responsibility to reconnect it when DPMS ON
>> happens.
>>
>> But don't take my word for it, others may have more/other information.
>>
>
> Yes, I was thinking ideally DPMS call should enable/disable DPMS state, and
> XRRSetCrtcConfig call should enable/disable CRTC.
>
> But it seems that, when using XRRSetCrtcConfig to disable CRTC,
> the CRTC itself is disabled, the DPMS is disabled (DPMS OFF),
> and then when using XRRSetCrtcConfig to re-enable the CRTC,
> it only checks whether the CRTC that connected to the encoder is
> changed (whether a new crtc is assigned), but does not check whether
> the CRTC itself is previously disabled or not. ?So it considers the encoder
> is connected to the same CRTC and does no thing to re-enable the CRTC.
>
>
>> --
>> Far away from the primal instinct, the song seems to fade away, the
>> river get wider between your thoughts and the things we do and say.

What i meant is that you should get a DPMS ON call somewhere in the
driver. The driver should then re-enable things. If the driver
disconnects the encoder for DPMS OFF, then it will also have to
reconnect it for DPMS ON.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

BUG: drm_crtc_helper_set_config does not work

[Maarten Maathuis]

On Fri, Mar 9, 2012 at 2:50 AM, Yufeng Shen  wrote:
> So a simple case of ?disabling a CRTC and then re-enabling it.
>
> Disabling:
>
> CRTC X is originally connected to output Y
>
> 1. XRRSetCrtcConfig() ? ?is called to disable CRTC ?X
>
> 2. drm_helper_connector_dpms() ? then gets called on the connector
> connected to CRTC X,
> ? ?in the function,
> ? ?the ?connector->encoder ?is set to DPMS OFF, ? and the
> encoder->crtc ?set to DPMS OFF
> ? ?but the ?encoder->crtc ? is still CRTC X
>
> Re-enabling:
>
> 3. XRRSetCrtcConfig() ? ?is called to to enable CRTC ?X ?on output Y
>
> 4. drm_crtc_helper_set_config () ?is now called,
> suppose ? fb is not changed, ?mode is not changed, encoder is not changed
> and the ? encoder->crtc ?is not changed,
> then we have ? mode_changed == false ? ?and ?the mode is not reset
>
> So the CRTC X won't be connected to output Y.
>
> What I don't understand the code is that why ?XRRSetCrtcConfig() ?ends
> up only calling ?drm_helper_connector_dpms() ??
> I think it should do more than that, at least it should set the
> related ?encoder->crtc = NULL
>
> any comments ?
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

As far as i know DPMS designed is a simple switch, meaning that the
mode remains active, so if you do DPMS ON it should come back. If for
some reason the driver is disconnecting the encoder from the crtc,
then it is the drivers responsibility to reconnect it when DPMS ON
happens.

But don't take my word for it, others may have more/other information.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: BUG: drm_crtc_helper_set_config does not work

[Maarten Maathuis]

On Fri, Mar 9, 2012 at 2:50 AM, Yufeng Shen mile...@chromium.org wrote:
 So a simple case of  disabling a CRTC and then re-enabling it.

 Disabling:

 CRTC X is originally connected to output Y

 1. XRRSetCrtcConfig()    is called to disable CRTC  X

 2. drm_helper_connector_dpms()   then gets called on the connector
 connected to CRTC X,
    in the function,
    the  connector-encoder  is set to DPMS OFF,   and the
 encoder-crtc  set to DPMS OFF
    but the  encoder-crtc   is still CRTC X

 Re-enabling:

 3. XRRSetCrtcConfig()    is called to to enable CRTC  X  on output Y

 4. drm_crtc_helper_set_config ()  is now called,
 suppose   fb is not changed,  mode is not changed, encoder is not changed
 and the   encoder-crtc  is not changed,
 then we have   mode_changed == false    and  the mode is not reset

 So the CRTC X won't be connected to output Y.

 What I don't understand the code is that why  XRRSetCrtcConfig()  ends
 up only calling  drm_helper_connector_dpms()  ?
 I think it should do more than that, at least it should set the
 related  encoder-crtc = NULL

 any comments ?
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

As far as i know DPMS designed is a simple switch, meaning that the
mode remains active, so if you do DPMS ON it should come back. If for
some reason the driver is disconnecting the encoder from the crtc,
then it is the drivers responsibility to reconnect it when DPMS ON
happens.

But don't take my word for it, others may have more/other information.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: BUG: drm_crtc_helper_set_config does not work

[Maarten Maathuis]

On Fri, Mar 9, 2012 at 5:28 PM, Yufeng Shen mile...@chromium.org wrote:
 On Fri, Mar 9, 2012 at 3:15 AM, Maarten Maathuis madman2...@gmail.com wrote:
 On Fri, Mar 9, 2012 at 2:50 AM, Yufeng Shen mile...@chromium.org wrote:
 So a simple case of  disabling a CRTC and then re-enabling it.

 Disabling:

 CRTC X is originally connected to output Y

 1. XRRSetCrtcConfig()    is called to disable CRTC  X

 2. drm_helper_connector_dpms()   then gets called on the connector
 connected to CRTC X,
    in the function,
    the  connector-encoder  is set to DPMS OFF,   and the
 encoder-crtc  set to DPMS OFF
    but the  encoder-crtc   is still CRTC X

 Re-enabling:

 3. XRRSetCrtcConfig()    is called to to enable CRTC  X  on output Y

 4. drm_crtc_helper_set_config ()  is now called,
 suppose   fb is not changed,  mode is not changed, encoder is not changed
 and the   encoder-crtc  is not changed,
 then we have   mode_changed == false    and  the mode is not reset

 So the CRTC X won't be connected to output Y.

 What I don't understand the code is that why  XRRSetCrtcConfig()  ends
 up only calling  drm_helper_connector_dpms()  ?
 I think it should do more than that, at least it should set the
 related  encoder-crtc = NULL

 any comments ?
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel

 As far as i know DPMS designed is a simple switch, meaning that the
 mode remains active, so if you do DPMS ON it should come back. If for
 some reason the driver is disconnecting the encoder from the crtc,
 then it is the drivers responsibility to reconnect it when DPMS ON
 happens.

 But don't take my word for it, others may have more/other information.


 Yes, I was thinking ideally DPMS call should enable/disable DPMS state, and
 XRRSetCrtcConfig call should enable/disable CRTC.

 But it seems that, when using XRRSetCrtcConfig to disable CRTC,
 the CRTC itself is disabled, the DPMS is disabled (DPMS OFF),
 and then when using XRRSetCrtcConfig to re-enable the CRTC,
 it only checks whether the CRTC that connected to the encoder is
 changed (whether a new crtc is assigned), but does not check whether
 the CRTC itself is previously disabled or not.  So it considers the encoder
 is connected to the same CRTC and does no thing to re-enable the CRTC.


 --
 Far away from the primal instinct, the song seems to fade away, the
 river get wider between your thoughts and the things we do and say.

What i meant is that you should get a DPMS ON call somewhere in the
driver. The driver should then re-enable things. If the driver
disconnects the encoder for DPMS OFF, then it will also have to
reconnect it for DPMS ON.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] [Patches][nouveau/kms]: Precise Vblank and pageflip timestamping v2

[Maarten Maathuis]

On Tue, Feb 21, 2012 at 8:04 PM, Mario Kleiner
mario.klei...@tuebingen.mpg.de wrote:
 On Feb 20, 2012, at 8:24 AM, Lucas Stach wrote:

 Just updated versions of the patches send by Mario Kleiner. This ones are
 rebased on top of the nouveau tree and updated according to the review
 feedback.

 This time hopefully the right ones.

 Regards,
 Lucas



 Ben, thanks for the feedback. I've resteted the v2 of Lucas new reworked and
 rebased patches, everything fine and precise wrt. to timing precision.

 For my personal education: Is my understanding correct that these registers
 are basically double-buffered, and the NV50_PDISPLAY_CRTC_C macro accesses
 the current state, whereas the NV50_PDISPLAY_CRTC_P macro provides/sets the
 programmed values that will be latched into the _C registers at some later
 time, e.g., modeset?

 thanks,
 -mario


 ___
 Nouveau mailing list
 Nouveau@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/nouveau

The proposed registers show the value that has submitted (via the
modesetting/display fifo), but they haven't been put into effect yet
by the update command. The registers (both the current and proposed
ones) are only intended for reading. At least that is my
understanding, perhaps Ben can tell you more.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [Patches][nouveau/kms]: Precise Vblank and pageflip timestamping v2

[Maarten Maathuis]

On Tue, Feb 21, 2012 at 8:26 PM, Maarten Maathuis madman2...@gmail.com wrote:
 On Tue, Feb 21, 2012 at 8:04 PM, Mario Kleiner
 mario.klei...@tuebingen.mpg.de wrote:
 On Feb 20, 2012, at 8:24 AM, Lucas Stach wrote:

 Just updated versions of the patches send by Mario Kleiner. This ones are
 rebased on top of the nouveau tree and updated according to the review
 feedback.

 This time hopefully the right ones.

 Regards,
 Lucas



 Ben, thanks for the feedback. I've resteted the v2 of Lucas new reworked and
 rebased patches, everything fine and precise wrt. to timing precision.

 For my personal education: Is my understanding correct that these registers
 are basically double-buffered, and the NV50_PDISPLAY_CRTC_C macro accesses
 the current state, whereas the NV50_PDISPLAY_CRTC_P macro provides/sets the
 programmed values that will be latched into the _C registers at some later
 time, e.g., modeset?

 thanks,
 -mario


 ___
 Nouveau mailing list
 Nouveau@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/nouveau

 The proposed registers show the value that has submitted (via the
 modesetting/display fifo), but they haven't been put into effect yet
 by the update command. The registers (both the current and proposed
 ones) are only intended for reading. At least that is my
 understanding, perhaps Ben can tell you more.

 --
 Far away from the primal instinct, the song seems to fade away, the
 river get wider between your thoughts and the things we do and say.

That should be have been submitted not has submitted.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Why do non-lvds monitors default to dithering these days?

[Maarten Maathuis]

On Thu, Dec 22, 2011 at 3:41 PM, Maarten Maathuis madman2...@gmail.com wrote:
 On Sun, Dec 18, 2011 at 8:47 PM, Maarten Maathuis madman2...@gmail.com 
 wrote:
 In the past we assumed that external displays did their own dithering
 if needed. GPU based dithering is only needed for laptop displays if i
 had to guess.

 I was almost thinking my monitor was malfunctioning because of strange
 barely visible flickering. Now it *seems* as if dithering was the
 problem, although time will have to tell, because it's subtle to see
 these effects.

 Ofcource i can try and find a way to set the connector property more
 permanently (if anyone has suggestions besides sticking an xrandr
 command in my .xinitrc please let me know), but i don't see why we
 would need to assume that anything but lvds and eDP needs to be
 dithered.

 --
 Far away from the primal instinct, the song seems to fade away, the
 river get wider between your thoughts and the things we do and say.

 Ping.

 --
 Far away from the primal instinct, the song seems to fade away, the
 river get wider between your thoughts and the things we do and say.

Anyone?

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Why do non-lvds monitors default to dithering these days?

[Maarten Maathuis]

On Sun, Dec 18, 2011 at 8:47 PM, Maarten Maathuis madman2...@gmail.com wrote:
 In the past we assumed that external displays did their own dithering
 if needed. GPU based dithering is only needed for laptop displays if i
 had to guess.

 I was almost thinking my monitor was malfunctioning because of strange
 barely visible flickering. Now it *seems* as if dithering was the
 problem, although time will have to tell, because it's subtle to see
 these effects.

 Ofcource i can try and find a way to set the connector property more
 permanently (if anyone has suggestions besides sticking an xrandr
 command in my .xinitrc please let me know), but i don't see why we
 would need to assume that anything but lvds and eDP needs to be
 dithered.

 --
 Far away from the primal instinct, the song seems to fade away, the
 river get wider between your thoughts and the things we do and say.

Ping.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] Why do non-lvds monitors default to dithering these days?

[Maarten Maathuis]

In the past we assumed that external displays did their own dithering
if needed. GPU based dithering is only needed for laptop displays if i
had to guess.

I was almost thinking my monitor was malfunctioning because of strange
barely visible flickering. Now it *seems* as if dithering was the
problem, although time will have to tell, because it's subtle to see
these effects.

Ofcource i can try and find a way to set the connector property more
permanently (if anyone has suggestions besides sticking an xrandr
command in my .xinitrc please let me know), but i don't see why we
would need to assume that anything but lvds and eDP needs to be
dithered.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Gentoo HOWTO is outdated

[Maarten Maathuis]

On Wed, Dec 14, 2011 at 6:15 PM, Stayvoid stayv...@gmail.com wrote:
 Hi there!

 This HOWTO is outdated:
 http://nouveau.freedesktop.org/wiki/GentooEbuilds

 x11-base/nouveau-drm from the x11 overlay asks for the 3.2 version of
 kernel, but the latest version is 3.1.5.

 This advice is also wrong: These ebuilds do not have any keyword, as
 it is usual with cvs/svn/git releases. To be able to install them, you
 have to mark them with ** in package.keywords.
 Nowadays you should use package.unmask for such purposes.


 Cheers!
 ___
 Nouveau mailing list
 Nouveau@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/nouveau

It's a wiki, you can edit it, you just need to be logged in.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: 8k resolution video causes X Error

[Maarten Maathuis]

On Sun, Dec 4, 2011 at 6:11 PM, Donald McLachlan
donald.mclach...@crc.ca wrote:
 Hi,

 I don't know where to start to resolve this problem and guessed maybe this
 is a good place to start. If not, please point me in the right direction.

 Our ultimate goal is to stream 8k resolution video using sage (see
 www.sagecommons.org).

 - We first used ffmpeg to convert a 4k resolution video file to yuv format,
 and we were able to view it with ffplay, mplayer, and crcview (an in house
 program).
 - We then used ffmpeg to convert/resample the same 4k resolution video file
 to yuv/8k resolution; the conversion completed without error.
 - When trying to view the resulting yuv/8k resolution file all three viewer
 programs failed with the same X Error.  For example, here is the output from
 ffplay:

 ffplay -i Lupe.8k.yuv -s 8192x4320 -pix_fmt yuv420p -x 1920 -y 1080
 ffplay version 0.8, Copyright (c) 2003-2011 the FFmpeg developers
   built on Nov 30 2011 13:01:22 with gcc 4.5.1 20101208 [gcc-4_5-branch
 revision 167585]
   configuration:
   libavutil    51.  9. 1 / 51.  9. 1
   libavcodec   53.  7. 0 / 53.  7. 0
   libavformat  53.  4. 0 / 53.  4. 0
   libavdevice  53.  1. 1 / 53.  1. 1
   libavfilter   2. 23. 0 /  2. 23. 0
   libswscale    2.  0. 0 /  2.  0. 0
 [rawvideo @ 0x129d740] Estimating duration from bitrate, this may be
 inaccurate
 Input #0, rawvideo, from 'Lupe.8k.yuv':
   Duration: N/A, start: 0.00, bitrate: N/A
     Stream #0.0: Video: rawvideo, yuv420p, 8192x4320, 25 tbr, 25 tbn, 25 tbc
 X Error of failed request:  BadLength (poly request too large or internal
 Xlib length error)
   Major opcode of failed request:  132 (XVideo)
   Minor opcode of failed request:  18 ()
   Serial number of failed request:  23
   Current serial number in output stream:  24

 In case it matters, we are using openSuse 11.4 64 bit linux, on an ASUS P6T7
 WS Supercomputer motherboard, with 12 G RAM, and a ASUS GTX590 video card.

 My guess is the 8k resolution video format is exceeding a buffer size limit
 somewhere, either in software, or maybe on the video card.
 Is there a way to find out what buffers are affected and is there a way to
 overcome these limits?

 Thanks for any assistance you can provide,
 Don


 ___
 xorg@lists.freedesktop.org: X.Org support
 Archives: http://lists.freedesktop.org/archives/xorg
 Info: http://lists.freedesktop.org/mailman/listinfo/xorg
 Your subscription address: madman2...@gmail.com

If this is using the nouveau driver (check lsmod or xorg log), i see
that for some reason that it's limited to 4096x4096 for xvideo.

See this line: 
http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/src/nouveau_xv.c#n2031

And then check the contents of DummyEncodingTex and you'll find it
refers to the maximum sizes.

The command xvinfo confirms this.

NV50 and higher (everything starting geforce 8) are able to do
8192x8192, it should just be a matter of making a NV50 specific
DummyEncodingTex structure.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: EXA and damage performance problem

[Maarten Maathuis]

On Tue, Nov 29, 2011 at 2:33 PM, Christoph Bartoschek
bartosc...@or.uni-bonn.de wrote:
 Hi,

 I am moving the thread EXA performance problem from xorg to xorg-devel and
 hope to get some help here.

 To sum up the problem: We use an application that displays vector pictures.
 We use it mostly to display pictures with millions of rectangles. Using our
 old X11 thin clients (XFree86) the performance was acceptable. The speed was
 about 1 mio rectangles per second. After upgrading to newer thin clients
 (Xorg) the performance dropped significantly.

 I have a testcase where displaying the picture now takes 90 seconds. It was
 below one second on the older thin clients.

 The profiler says that 95% of the runtime is spent in pixman region
 operations.

 The application draws polyRectangle most of the time. And I see that nearly
 100% of time is spent in damagePolyRectangle and the functions below.

 33% of the time in damagePolyRectangle is spent in the while loop to
 construct the damage region. The algorithm runs in O(n^2) because it adds
 one rectangle at a time. This can be fixed by constructing the damage region
 in one step. The attached patch does this.

 However after fixing this most of the time is spent in ExaCheckPolylines
 which is called by this chain:


 damagePolyRectangle - miPolyRectangle - exaPolylines - ExaCheckPolylines

 I've measured the runtime of the steps in ExaCheckPolylines:


 void
 ExaCheckPolylines (DrawablePtr pDrawable, GCPtr pGC,
                  int mode, int npt, DDXPointPtr ppt)
 {
  EXA_PRE_FALLBACK_GC(pGC);
  EXA_FALLBACK((to %p (%c), width %d, mode %d, count %d\n,
                pDrawable, exaDrawableLocation(pDrawable),
                pGC-lineWidth, mode, npt));

  exaPrepareAccess (pDrawable, EXA_PREPARE_DEST);       // Step1: 55 s
  exaPrepareAccessGC (pGC);                             // Step2: 2.4 s
  pGC-ops-Polylines (pDrawable, pGC, mode, npt, ppt); // Step3: 2.4 s
  exaFinishAccessGC (pGC);                              // Step4: 2.2 s
  exaFinishAccess (pDrawable, EXA_PREPARE_DEST);        // Step5: 2.2 s
  EXA_POST_FALLBACK_GC(pGC);
 }

 We see that exaPrepareAccess needs most of the time. Is that expected?

I don't know which driver this is (and which type of EXA), but worst
case scenario the destination is a tiled frontbuffer that gets copied
back and forth for every operation (you want to see the framebuffer,
so you can't wait). If it's done using a hardware copy the software
needs to wait for the copy to be finished. The other way around can be
faster (and relatively non-blocking) depending on how it's
implemented. I think the interfaces inside the xserver are the main
reason it's done this way. The truth is that the whole thing was never
designed for modern hardware, so EXA can only do so much. You could
define new interfaces inside the xserver, but if your app does a call
for each rectangle, then that won't help much. At some point it
becomes easier to change the app if you can (rendering to a pixmap
instead of the frontbuffer should help a lot already if you are
bottlenecked by frontbuffer copies).


 Inside there are several operations on the damage region. This makes
 damagePolyRectangle a quadratic algorithm.

 For N rectangles the damage region has O(N) rectangles. And for each
 Rectangle there are operations on the damage region. The result is O(N^2).

 Is it necessary to call exaPrepareAccess for each of the rectangles?

No, but unless the app gives you all rectangles at once i don't see
any other way.


 Has anyone an idea how to improeve this?

 Christoph

 ___
 xorg-devel@lists.x.org: X.Org development
 Archives: http://lists.x.org/archives/xorg-devel
 Info: http://lists.x.org/mailman/listinfo/xorg-devel




-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: EXA and damage performance problem

[Maarten Maathuis]

On Tue, Nov 29, 2011 at 11:29 PM, Christoph Bartoschek
bartosc...@or.uni-bonn.de wrote:
 Am 29.11.2011 23:19, schrieb Maarten Maathuis:

 On Tue, Nov 29, 2011 at 2:33 PM, Christoph Bartoschek
 bartosc...@or.uni-bonn.de  wrote:

 Hi,

 I am moving the thread EXA performance problem from xorg to xorg-devel
 and
 hope to get some help here.

 To sum up the problem: We use an application that displays vector
 pictures.
 We use it mostly to display pictures with millions of rectangles. Using
 our
 old X11 thin clients (XFree86) the performance was acceptable. The speed
 was
 about 1 mio rectangles per second. After upgrading to newer thin clients
 (Xorg) the performance dropped significantly.

 I have a testcase where displaying the picture now takes 90 seconds. It
 was
 below one second on the older thin clients.

 The profiler says that 95% of the runtime is spent in pixman region
 operations.

 The application draws polyRectangle most of the time. And I see that
 nearly
 100% of time is spent in damagePolyRectangle and the functions below.

 33% of the time in damagePolyRectangle is spent in the while loop to
 construct the damage region. The algorithm runs in O(n^2) because it adds
 one rectangle at a time. This can be fixed by constructing the damage
 region
 in one step. The attached patch does this.

 However after fixing this most of the time is spent in ExaCheckPolylines
 which is called by this chain:


 damagePolyRectangle -  miPolyRectangle -  exaPolylines -
  ExaCheckPolylines

 I've measured the runtime of the steps in ExaCheckPolylines:


 void
 ExaCheckPolylines (DrawablePtr pDrawable, GCPtr pGC,
                  int mode, int npt, DDXPointPtr ppt)
 {
  EXA_PRE_FALLBACK_GC(pGC);
  EXA_FALLBACK((to %p (%c), width %d, mode %d, count %d\n,
                pDrawable, exaDrawableLocation(pDrawable),
                pGC-lineWidth, mode, npt));

  exaPrepareAccess (pDrawable, EXA_PREPARE_DEST);       // Step1: 55 s
  exaPrepareAccessGC (pGC);                             // Step2: 2.4 s
  pGC-ops-Polylines (pDrawable, pGC, mode, npt, ppt); // Step3: 2.4 s
  exaFinishAccessGC (pGC);                              // Step4: 2.2 s
  exaFinishAccess (pDrawable, EXA_PREPARE_DEST);        // Step5: 2.2 s
  EXA_POST_FALLBACK_GC(pGC);
 }

 We see that exaPrepareAccess needs most of the time. Is that expected?

 I don't know which driver this is (and which type of EXA), but worst
 case scenario the destination is a tiled frontbuffer that gets copied
 back and forth for every operation (you want to see the framebuffer,
 so you can't wait). If it's done using a hardware copy the software
 needs to wait for the copy to be finished. The other way around can be
 faster (and relatively non-blocking) depending on how it's
 implemented. I think the interfaces inside the xserver are the main
 reason it's done this way. The truth is that the whole thing was never
 designed for modern hardware, so EXA can only do so much. You could
 define new interfaces inside the xserver, but if your app does a call
 for each rectangle, then that won't help much. At some point it
 becomes easier to change the app if you can (rendering to a pixmap
 instead of the frontbuffer should help a lot already if you are
 bottlenecked by frontbuffer copies).


 Inside there are several operations on the damage region. This makes
 damagePolyRectangle a quadratic algorithm.

 For N rectangles the damage region has O(N) rectangles. And for each
 Rectangle there are operations on the damage region. The result is
 O(N^2).

 Is it necessary to call exaPrepareAccess for each of the rectangles?

 No, but unless the app gives you all rectangles at once i don't see
 any other way.

 I do not know whether it gives all rectangles at once. But I see that
 damagePolyRectangle is called with chunks of 2044 rectangles.

Then consider making a multiPolylines or multiPolyRectangle interface
or something like that, then you can override the mi implementation in
exa.


 It is miPolyRectangle that iterates over all rectangles.

 Christoph





-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: EXA performance problem

[Maarten Maathuis]

On Mon, Nov 28, 2011 at 4:49 PM, Christoph Bartoschek
bartosc...@or.uni-bonn.de wrote:
 Am 28.11.2011 10:35, schrieb Christoph Bartoschek:

 Now one has to look at
 (*pGC-ops-PolyRectangle)(pDrawable, pGC, nRects, pRects);

 Here is what I see so far:

 - damagePolyRectangle is called for 2044 rectangles.

 - the damage region is computed it consists of about 1000 rectangles each
 time.

 - miPolyRectangle is called.

 - the function iterates over all rectangles and calls exaPolylines for each
 of them because most have only a width and height of 0

 - exaPolylines calls ExaCheckPolylines.


 We see that for each rectanlge ExaCheckPolylines is called. I have added
 timers to this function to see what costs time:


 void
 ExaCheckPolylines (DrawablePtr pDrawable, GCPtr pGC,
                  int mode, int npt, DDXPointPtr ppt)
 {
  EXA_PRE_FALLBACK_GC(pGC);
  EXA_FALLBACK((to %p (%c), width %d, mode %d, count %d\n,
                pDrawable, exaDrawableLocation(pDrawable),
                pGC-lineWidth, mode, npt));

  exaPrepareAccess (pDrawable, EXA_PREPARE_DEST);       // Step1: 55 s
  exaPrepareAccessGC (pGC);                             // Step2: 2.4 s
  pGC-ops-Polylines (pDrawable, pGC, mode, npt, ppt); // Step3: 2.4 s
  exaFinishAccessGC (pGC);                              // Step4: 2.2 s
  exaFinishAccess (pDrawable, EXA_PREPARE_DEST);        // Step5: 2.2 s
  EXA_POST_FALLBACK_GC(pGC);
 }


 We see that exaPrepareAccess needs most of the time. Is that expected?

 Inside we see that there are some region operations on the damage region in
 exaCopyDirty. As said before the damage region contains about 1000
 rectangles. So we have 2000 times several operations on 1000 rectangeles.

 I think this explains the runtime.

 Isn't it somehow possible to batch the rectangle drawing such that the
 region operations are not neccessary for each rectangle?

 Isn't is possible to expand the damage region such that it contains less
 rectangles?

 Is this still the correct list, or should I ask the EXA questions elsewhere?

 Christoph
 ___
 xorg@lists.freedesktop.org: X.Org support
 Archives: http://lists.freedesktop.org/archives/xorg
 Info: http://lists.freedesktop.org/mailman/listinfo/xorg
 Your subscription address: madman2...@gmail.com


EXA doesn't have a seperate list, but now that you ask, you should
probably move to the xorg-devel mailinglist :-)

I don't have any answers right now, but i'll think about it.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: EXA performance problem

[Maarten Maathuis]

On Sun, Nov 27, 2011 at 3:55 PM, Christoph Bartoschek
bartosc...@or.uni-bonn.de wrote:
 Hi,

 I still have a huge performance problem with Xorg. One application that
 painted 2 Mio rectangles on the screen within a second or so with XFree86
 needs about a minute with Xorg.

 Most of the time is spent in libpixman. I've added some debug statements and
 see that pixman_raster_op is called about 7.2 mio times during my testcase.

 I do not think that pixman itself is the problem. It is just used too often
 by EXA.

 Is there anything I can do about this? Is there a better list where I can
 ask? Or do you know a person that might be interested in solving such a
 problem?

 Christoph
 ___
 xorg@lists.freedesktop.org: X.Org support
 Archives: http://lists.freedesktop.org/archives/xorg
 Info: http://lists.freedesktop.org/mailman/listinfo/xorg
 Your subscription address: madman2...@gmail.com


As far as i know it basically boils down to this, rendering rectangles
is done in a software library as you observed. If your pixmap happens
to be outside normal ram then a lot of reads will kill performance.
These days the aim should be to use as little core rendering as
possible. A modern toolkit or a rendering library like cairo should
handle this far better.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: EXA performance problem

[Maarten Maathuis]

On Sun, Nov 27, 2011 at 9:40 PM, Christoph Bartoschek
bartosc...@or.uni-bonn.de wrote:
 Am 27.11.2011 16:13, schrieb Maarten Maathuis:

 On Sun, Nov 27, 2011 at 3:55 PM, Christoph Bartoschek
 bartosc...@or.uni-bonn.de  wrote:

 Hi,

 I still have a huge performance problem with Xorg. One application that
 painted 2 Mio rectangles on the screen within a second or so with XFree86
 needs about a minute with Xorg.

 Most of the time is spent in libpixman. I've added some debug statements
 and
 see that pixman_raster_op is called about 7.2 mio times during my
 testcase.

 I do not think that pixman itself is the problem. It is just used too
 often
 by EXA.

 Is there anything I can do about this? Is there a better list where I can
 ask? Or do you know a person that might be interested in solving such a
 problem?

 Christoph
 ___
 xorg@lists.freedesktop.org: X.Org support
 Archives: http://lists.freedesktop.org/archives/xorg
 Info: http://lists.freedesktop.org/mailman/listinfo/xorg
 Your subscription address: madman2...@gmail.com


 As far as i know it basically boils down to this, rendering rectangles
 is done in a software library as you observed. If your pixmap happens
 to be outside normal ram then a lot of reads will kill performance.
 These days the aim should be to use as little core rendering as
 possible. A modern toolkit or a rendering library like cairo should
 handle this far better.


 How can I check whether the pixmap is outside the normal ram? For me it does
 not look as if pixman is used for rendering the image. It looks as if EXA is
 managing the region that needs updates with pixman routines. But I could be
 wrong here.

 Christoph


Only the driver knows that. If you know what driver it is, you can
also figure out if the driver handles pixmap allocation themselves.
Then you can see if they (are likely) to use dedicated video ram,
which is the only uncached memory (=slow read) i can think of right
now. I don't know off the top of my head how to determine if a pixmap
is offscreen (for a driver that allocates pixmaps this means that
the pixmap is under driver control, the alternative is that it's a
malloc private to exa).

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: EXA performance problem

[Maarten Maathuis]

On Mon, Nov 28, 2011 at 2:41 AM, Christoph Bartoschek
bartosc...@or.uni-bonn.de wrote:
 I have new information. I am no longer sure whether it is a problem with
 EXA.

 I have a testcase that currently takes 90 seconds to draw all rectangles. I
 see that in damage.c two functions are mainly used:

 damagePolyRectangle
 damagePolyFillRectangle

 The first function calls for each given rectangle up to four times
 damageDamageBox (pDrawable, box, pGC-subWindowMode);
 which adds the box to a region. The function then calls damageRegionAppend.

 This part takes in sum 30 seconds of my testcase. I think the code has
 quadratic behaviour here becuase it adds rectangle by rectangle instead of
 first adding them to a region and then calling damageRegionAppend. I think
 removing the quadratic behaviour can reduce the runtime significantly.

 About 60 seconds are spent in the calls

 (*pGC-ops-PolyRectangle)(pDrawable, pGC, nRects, pRects);
 (*pGC-ops-PolyFillRect)(pDrawable, pGC, nRects, pRects);

 However I do not yet know why they are so slow.

 Is damage.c part of EXA?

 Christoph
 ___
 xorg@lists.freedesktop.org: X.Org support
 Archives: http://lists.freedesktop.org/archives/xorg
 Info: http://lists.freedesktop.org/mailman/listinfo/xorg
 Your subscription address: madman2...@gmail.com


No, damage is an extention, it is called by EXA, it's probably adding
all you rectangles to a damage region used to determine how much data
is actually valid (needed for ram--vram migrations for example).

One thing that just comes to mind, if you are rendering a million
rectangles, how many of those do you actually see on your screen?

Anyway, you can try optimizing damaga, exa and either fb or mi (for
PolyRectangle PolyFillRect software ops). I don't know how efficient
the region code is at reducing the number of rectangles if they
overlap, a region is built up out of rectangles as well.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

Re: EXA performance problem

[Maarten Maathuis]

On Mon, Nov 28, 2011 at 7:43 AM, Maarten Maathuis madman2...@gmail.com wrote:
 On Mon, Nov 28, 2011 at 2:41 AM, Christoph Bartoschek
 bartosc...@or.uni-bonn.de wrote:
 I have new information. I am no longer sure whether it is a problem with
 EXA.

 I have a testcase that currently takes 90 seconds to draw all rectangles. I
 see that in damage.c two functions are mainly used:

 damagePolyRectangle
 damagePolyFillRectangle

 The first function calls for each given rectangle up to four times
 damageDamageBox (pDrawable, box, pGC-subWindowMode);
 which adds the box to a region. The function then calls damageRegionAppend.

 This part takes in sum 30 seconds of my testcase. I think the code has
 quadratic behaviour here becuase it adds rectangle by rectangle instead of
 first adding them to a region and then calling damageRegionAppend. I think
 removing the quadratic behaviour can reduce the runtime significantly.

 About 60 seconds are spent in the calls

 (*pGC-ops-PolyRectangle)(pDrawable, pGC, nRects, pRects);
 (*pGC-ops-PolyFillRect)(pDrawable, pGC, nRects, pRects);

 However I do not yet know why they are so slow.

 Is damage.c part of EXA?

 Christoph
 ___
 xorg@lists.freedesktop.org: X.Org support
 Archives: http://lists.freedesktop.org/archives/xorg
 Info: http://lists.freedesktop.org/mailman/listinfo/xorg
 Your subscription address: madman2...@gmail.com


 No, damage is an extention, it is called by EXA, it's probably adding
 all you rectangles to a damage region used to determine how much data
 is actually valid (needed for ram--vram migrations for example).

 One thing that just comes to mind, if you are rendering a million
 rectangles, how many of those do you actually see on your screen?

 Anyway, you can try optimizing damaga, exa and either fb or mi (for
 PolyRectangle PolyFillRect software ops). I don't know how efficient
 the region code is at reducing the number of rectangles if they
 overlap, a region is built up out of rectangles as well.

 --
 Far away from the primal instinct, the song seems to fade away, the
 river get wider between your thoughts and the things we do and say.


s/damaga/damage and s/extention/extension and s/you rectangles/your rectangles

It was too early in the morning :-)

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com

KMS cursor BO semantics

[Maarten Maathuis]

On Fri, Nov 11, 2011 at 8:10 PM, Maarten Maathuis  
wrote:
> On Fri, Nov 11, 2011 at 7:17 PM, James Simmons  
> wrote:
>>
>>> On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote:
>>> > I'm not sure whether / how you handle the case of hardware render to
>>> > cursor surfaces on i915, but it seems to me like if a lot of drivers
>>> > need to implement driver specific "tricks" to meet the semantics of
>>> > a generic interface, we should perhaps consider specifying those
>>> > semantics in a way that helps avoid driver-specific workarounds?
>>>
>>> We don't handle really hanlde rendering to cursor objects. I think the
>>> "require a set_cursor after every cursor bo change" semantic is good, I've
>>> just feared that when only vmgfx needs this, no generic kms user will
>>> actually implement it. But nouveau seems to require this too, so I think
>>> at least for this case reality (and generic kms clients) will play along.
>>
>> I know this is a bit off topic but I see two approaches to the cursor api.
>> One is the nouveau method which is
>>
>> ...
>> ? ? ? ?drm_gem_object_lookup
>> ? ? ? ?internal_mmap gem object
>> ? ? ? ?copy to another internally allocated buffer objec
>> ? ? ? ?unmap gem object
>> ? ? ? ?drm_gem_object_unreference_unlocked
>> ...
>>
>> Or the radeon approach
>>
>> ...
>> ? ? ? ?drm_gem_object_lookup
>> ? ? ? ?gem_object_pin
>> ? ? ? ?program cursor location
>> ? ? ? ?gem_object_unpin
>> ? ? ? ?drm_gem_object_unreference_unlocked
>> ...
>>
>> What are the pros and cons to each method?
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
> Copying means you can convert the cursor to another format if needed.
>
> --
> Far away from the primal instinct, the song seems to fade away, the
> river get wider between your thoughts and the things we do and say.
>

Also no worries about strange side effects if people decide to render
to the cursor. Although i don't know if this is really an issue.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

KMS cursor BO semantics

[Maarten Maathuis]

On Fri, Nov 11, 2011 at 7:17 PM, James Simmons  
wrote:
>
>> On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote:
>> > I'm not sure whether / how you handle the case of hardware render to
>> > cursor surfaces on i915, but it seems to me like if a lot of drivers
>> > need to implement driver specific "tricks" to meet the semantics of
>> > a generic interface, we should perhaps consider specifying those
>> > semantics in a way that helps avoid driver-specific workarounds?
>>
>> We don't handle really hanlde rendering to cursor objects. I think the
>> "require a set_cursor after every cursor bo change" semantic is good, I've
>> just feared that when only vmgfx needs this, no generic kms user will
>> actually implement it. But nouveau seems to require this too, so I think
>> at least for this case reality (and generic kms clients) will play along.
>
> I know this is a bit off topic but I see two approaches to the cursor api.
> One is the nouveau method which is
>
> ...
> ? ? ? ?drm_gem_object_lookup
> ? ? ? ?internal_mmap gem object
> ? ? ? ?copy to another internally allocated buffer objec
> ? ? ? ?unmap gem object
> ? ? ? ?drm_gem_object_unreference_unlocked
> ...
>
> Or the radeon approach
>
> ...
> ? ? ? ?drm_gem_object_lookup
> ? ? ? ?gem_object_pin
> ? ? ? ?program cursor location
> ? ? ? ?gem_object_unpin
> ? ? ? ?drm_gem_object_unreference_unlocked
> ...
>
> What are the pros and cons to each method?
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

Copying means you can convert the cursor to another format if needed.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: KMS cursor BO semantics

[Maarten Maathuis]

On Fri, Nov 11, 2011 at 7:17 PM, James Simmons jsimm...@infradead.org wrote:

 On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote:
  I'm not sure whether / how you handle the case of hardware render to
  cursor surfaces on i915, but it seems to me like if a lot of drivers
  need to implement driver specific tricks to meet the semantics of
  a generic interface, we should perhaps consider specifying those
  semantics in a way that helps avoid driver-specific workarounds?

 We don't handle really hanlde rendering to cursor objects. I think the
 require a set_cursor after every cursor bo change semantic is good, I've
 just feared that when only vmgfx needs this, no generic kms user will
 actually implement it. But nouveau seems to require this too, so I think
 at least for this case reality (and generic kms clients) will play along.

 I know this is a bit off topic but I see two approaches to the cursor api.
 One is the nouveau method which is

 ...
        drm_gem_object_lookup
        internal_mmap gem object
        copy to another internally allocated buffer objec
        unmap gem object
        drm_gem_object_unreference_unlocked
 ...

 Or the radeon approach

 ...
        drm_gem_object_lookup
        gem_object_pin
        program cursor location
        gem_object_unpin
        drm_gem_object_unreference_unlocked
 ...

 What are the pros and cons to each method?
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel


Copying means you can convert the cursor to another format if needed.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: KMS cursor BO semantics

[Maarten Maathuis]

On Fri, Nov 11, 2011 at 8:10 PM, Maarten Maathuis madman2...@gmail.com wrote:
 On Fri, Nov 11, 2011 at 7:17 PM, James Simmons jsimm...@infradead.org wrote:

 On Fri, Nov 04, 2011 at 11:30:06PM +0100, Thomas Hellstrom wrote:
  I'm not sure whether / how you handle the case of hardware render to
  cursor surfaces on i915, but it seems to me like if a lot of drivers
  need to implement driver specific tricks to meet the semantics of
  a generic interface, we should perhaps consider specifying those
  semantics in a way that helps avoid driver-specific workarounds?

 We don't handle really hanlde rendering to cursor objects. I think the
 require a set_cursor after every cursor bo change semantic is good, I've
 just feared that when only vmgfx needs this, no generic kms user will
 actually implement it. But nouveau seems to require this too, so I think
 at least for this case reality (and generic kms clients) will play along.

 I know this is a bit off topic but I see two approaches to the cursor api.
 One is the nouveau method which is

 ...
        drm_gem_object_lookup
        internal_mmap gem object
        copy to another internally allocated buffer objec
        unmap gem object
        drm_gem_object_unreference_unlocked
 ...

 Or the radeon approach

 ...
        drm_gem_object_lookup
        gem_object_pin
        program cursor location
        gem_object_unpin
        drm_gem_object_unreference_unlocked
 ...

 What are the pros and cons to each method?
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel


 Copying means you can convert the cursor to another format if needed.

 --
 Far away from the primal instinct, the song seems to fade away, the
 river get wider between your thoughts and the things we do and say.


Also no worries about strange side effects if people decide to render
to the cursor. Although i don't know if this is really an issue.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] Option Rotate is not used

[Maarten Maathuis]

On Thu, Nov 10, 2011 at 10:36 PM, Grant emailgr...@gmail.com wrote:
 I just switched from nvidia to nouveau and I get the following in 
 Xorg.0.log:

 (WW) NOUVEAU(0): Option Rotate is not used

 I have the following in xorg.conf because I've rotated the LCD screen
 to change its orientation:

 Option Rotate CCW

 Can this be done with nouveau?  BTW, I can't say for sure that nouveau
 isn't rotating the screen image because the workstation is remote.
 Sure it can, nouveau is a randr 1.2 driver - so adding 'Option Rotate
 Left' to the monitor section of your xorg.conf will work instead.

 Ben.

 Thanks Ben, that worked great.

 - Grant

 I spoke too soon.  I don't get the warning in Xorg.0.log anymore, but
 someone tried to use the system and told me the screen was not rotated
 as it should be.  I tried both of these in xorg.conf with the same
 result:

 Section Monitor
        Identifier mymonitor
        Option Rotate Left
 EndSection

 Section Monitor
        Identifier mymonitor
        Option Rotate CCW
 EndSection

 Any ideas?

 - Grant
 ___
 Nouveau mailing list
 Nouveau@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/nouveau


You might need to add something like:

Option DVI-I-1 mymonitor

To your device section, ofcource choose the right connector/output.
Grep the xorg log for output and you should be able to find it.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Option Rotate is not used

[Maarten Maathuis]

On Thu, Nov 10, 2011 at 11:27 PM, Grant emailgr...@gmail.com wrote:
 I just switched from nvidia to nouveau and I get the following in 
 Xorg.0.log:

 (WW) NOUVEAU(0): Option Rotate is not used

 I have the following in xorg.conf because I've rotated the LCD screen
 to change its orientation:

 Option Rotate CCW

 Can this be done with nouveau?  BTW, I can't say for sure that nouveau
 isn't rotating the screen image because the workstation is remote.
 Sure it can, nouveau is a randr 1.2 driver - so adding 'Option Rotate
 Left' to the monitor section of your xorg.conf will work instead.

 Ben.

 Thanks Ben, that worked great.

 - Grant

 I spoke too soon.  I don't get the warning in Xorg.0.log anymore, but
 someone tried to use the system and told me the screen was not rotated
 as it should be.  I tried both of these in xorg.conf with the same
 result:

 Section Monitor
        Identifier mymonitor
        Option Rotate Left
 EndSection

 Section Monitor
        Identifier mymonitor
        Option Rotate CCW
 EndSection

 Any ideas?

 - Grant

 You might need to add something like:

 Option DVI-I-1 mymonitor

 To your device section, ofcource choose the right connector/output.
 Grep the xorg log for output and you should be able to find it.

 I added it like this:

 Section Device
        Identifier mydevice
        Driver nouveau
        Option VGA-1 mymonitor
 EndSection

 But I get this from Xorg.0.log:

 Option VGA-1 is not used

 I also tried VGA-I-1 to match your example with the same result.  I
 have this in Xorg.0.log so I think VGA-1 is correct:

 (II) NOUVEAU(0): Output VGA-1 has no monitor section
 ...
 (II) NOUVEAU(0): Output VGA-1 connected

 Is my syntax off somehow?

 - Grant
 ___
 Nouveau mailing list
 Nouveau@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/nouveau


My mistake, it should monitor-VGA-1 instead.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

KMS cursor BO semantics

[Maarten Maathuis]

On Fri, Nov 4, 2011 at 11:59 PM, Thomas Hellstrom  
wrote:
> On 11/04/2011 11:49 PM, Maarten Maathuis wrote:
>>
>> On Fri, Nov 4, 2011 at 11:30 PM, Thomas Hellstrom
>> ?wrote:
>>
>>>
>>> On 11/04/2011 04:34 PM, Daniel Vetter wrote:
>>>
>>>>
>>>> On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote:
>>>>
>>>>
>>>>>
>>>>> Hi.
>>>>>
>>>>> I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR
>>>>> iotcl:
>>>>>
>>>>> Some hardware (vmware's virtual in particular) may not be able to
>>>>> pick up the changes from a bo directly, since the cursor data is
>>>>> sent though the command stream. Hence we need a notification when
>>>>> the cursor image has changed.
>>>>>
>>>>> Could we *require* that a cursor image change needs to be followed
>>>>> by an ioctl call with the flag
>>>>> DRM_MODE_CURSOR_BO?
>>>>>
>>>>>
>>>>
>>>> On i915 we need the cursor in physical memory for some (old) platforms,
>>>> which is seperate storage from the bo backing storage. So we have the
>>>> same
>>>> problem. We've solved it by intercepting pwrite ioctl calls and
>>>> demanding
>>>> that userspace only uses these for cursor updates. Is there a special
>>>> reason you can't use such a driver-specific trick?
>>>> -Daniel
>>>>
>>>>
>>>
>>> We have something similar in use today: We snoop DMAs to hardware
>>> cursor surfaces, but this gets a bit nasty when apps start to do hardware
>>> render to cursor surfaces, and
>>> we simply ignore that today.
>>>
>>> Furthermore, ?maps rather than pwrites are the common usage-pattern for
>>> buffer-backed cursors on vmwgfx, and while it's possible to dirty those
>>> buffers based on page-faults, like we do with fb surfaces, we'd rather
>>> avoid
>>> having to implement and maintain that.
>>>
>>> I'm not sure whether / how you handle the case of hardware render to
>>> cursor
>>> surfaces on i915, but it seems to me like if a lot of drivers need to
>>> implement driver specific "tricks" to meet the semantics of a generic
>>> interface, we should perhaps consider specifying those semantics in a way
>>> that helps avoid driver-specific workarounds?
>>>
>>> /Thomas
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>>
>>
>> As far as i know nouveau keeps an internal buffer object for the
>> cursor and relies purely on the ioctl to copy the cursor into the
>> actual cursor memory area. So why do you need tricks?
>>
>>
>
> Because I have a hard time judging whether the Intel implementation (needs
> tricks) or the Nouveau implementation (doesn't need tricks) should define
> the semantics of the ioctl, although I would prefer we could all agree on
> the "doesn't need tricks" semantics and put that down in writing in the
> drm_mode.h header file.
>
> /Thomas
>
>
>
>

I see your point, i certainly prefer the "doesn't need tricks"
approach. Maybe allow for some kind of hybrid approach, require the
ioctl for every cursor change, but allow drivers to do a kind of lazy
implementation that simply attaches the buffer to the hardware and let
it handle it. If they want to avoid copying overhead or stuff like
that. This would impose some restrictions on what you can do with a
cursor buffer after calling the ioctl, specifically you would be
required to leave the content alone, except for cursor updates.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

KMS cursor BO semantics

[Maarten Maathuis]

On Fri, Nov 4, 2011 at 11:30 PM, Thomas Hellstrom  
wrote:
> On 11/04/2011 04:34 PM, Daniel Vetter wrote:
>>
>> On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote:
>>
>>>
>>> Hi.
>>>
>>> I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl:
>>>
>>> Some hardware (vmware's virtual in particular) may not be able to
>>> pick up the changes from a bo directly, since the cursor data is
>>> sent though the command stream. Hence we need a notification when
>>> the cursor image has changed.
>>>
>>> Could we *require* that a cursor image change needs to be followed
>>> by an ioctl call with the flag
>>> DRM_MODE_CURSOR_BO?
>>>
>>
>> On i915 we need the cursor in physical memory for some (old) platforms,
>> which is seperate storage from the bo backing storage. So we have the same
>> problem. We've solved it by intercepting pwrite ioctl calls and demanding
>> that userspace only uses these for cursor updates. Is there a special
>> reason you can't use such a driver-specific trick?
>> -Daniel
>>
>
> We have something similar in use today: We snoop DMAs to hardware
> cursor surfaces, but this gets a bit nasty when apps start to do hardware
> render to cursor surfaces, and
> we simply ignore that today.
>
> Furthermore, ?maps rather than pwrites are the common usage-pattern for
> buffer-backed cursors on vmwgfx, and while it's possible to dirty those
> buffers based on page-faults, like we do with fb surfaces, we'd rather avoid
> having to implement and maintain that.
>
> I'm not sure whether / how you handle the case of hardware render to cursor
> surfaces on i915, but it seems to me like if a lot of drivers need to
> implement driver specific "tricks" to meet the semantics of a generic
> interface, we should perhaps consider specifying those semantics in a way
> that helps avoid driver-specific workarounds?
>
> /Thomas
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

As far as i know nouveau keeps an internal buffer object for the
cursor and relies purely on the ioctl to copy the cursor into the
actual cursor memory area. So why do you need tricks?

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.

Re: KMS cursor BO semantics

[Maarten Maathuis]

On Fri, Nov 4, 2011 at 11:30 PM, Thomas Hellstrom thellst...@vmware.com wrote:
 On 11/04/2011 04:34 PM, Daniel Vetter wrote:

 On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote:


 Hi.

 I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR iotcl:

 Some hardware (vmware's virtual in particular) may not be able to
 pick up the changes from a bo directly, since the cursor data is
 sent though the command stream. Hence we need a notification when
 the cursor image has changed.

 Could we *require* that a cursor image change needs to be followed
 by an ioctl call with the flag
 DRM_MODE_CURSOR_BO?


 On i915 we need the cursor in physical memory for some (old) platforms,
 which is seperate storage from the bo backing storage. So we have the same
 problem. We've solved it by intercepting pwrite ioctl calls and demanding
 that userspace only uses these for cursor updates. Is there a special
 reason you can't use such a driver-specific trick?
 -Daniel


 We have something similar in use today: We snoop DMAs to hardware
 cursor surfaces, but this gets a bit nasty when apps start to do hardware
 render to cursor surfaces, and
 we simply ignore that today.

 Furthermore,  maps rather than pwrites are the common usage-pattern for
 buffer-backed cursors on vmwgfx, and while it's possible to dirty those
 buffers based on page-faults, like we do with fb surfaces, we'd rather avoid
 having to implement and maintain that.

 I'm not sure whether / how you handle the case of hardware render to cursor
 surfaces on i915, but it seems to me like if a lot of drivers need to
 implement driver specific tricks to meet the semantics of a generic
 interface, we should perhaps consider specifying those semantics in a way
 that helps avoid driver-specific workarounds?

 /Thomas

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel


As far as i know nouveau keeps an internal buffer object for the
cursor and relies purely on the ioctl to copy the cursor into the
actual cursor memory area. So why do you need tricks?

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: KMS cursor BO semantics

[Maarten Maathuis]

On Fri, Nov 4, 2011 at 11:59 PM, Thomas Hellstrom thellst...@vmware.com wrote:
 On 11/04/2011 11:49 PM, Maarten Maathuis wrote:

 On Fri, Nov 4, 2011 at 11:30 PM, Thomas Hellstromthellst...@vmware.com
  wrote:


 On 11/04/2011 04:34 PM, Daniel Vetter wrote:


 On Fri, Nov 04, 2011 at 12:59:59PM +0100, Thomas Hellstrom wrote:



 Hi.

 I have a question about the semantics of the DRM_IOCTL_MODE_CURSOR
 iotcl:

 Some hardware (vmware's virtual in particular) may not be able to
 pick up the changes from a bo directly, since the cursor data is
 sent though the command stream. Hence we need a notification when
 the cursor image has changed.

 Could we *require* that a cursor image change needs to be followed
 by an ioctl call with the flag
 DRM_MODE_CURSOR_BO?



 On i915 we need the cursor in physical memory for some (old) platforms,
 which is seperate storage from the bo backing storage. So we have the
 same
 problem. We've solved it by intercepting pwrite ioctl calls and
 demanding
 that userspace only uses these for cursor updates. Is there a special
 reason you can't use such a driver-specific trick?
 -Daniel



 We have something similar in use today: We snoop DMAs to hardware
 cursor surfaces, but this gets a bit nasty when apps start to do hardware
 render to cursor surfaces, and
 we simply ignore that today.

 Furthermore,  maps rather than pwrites are the common usage-pattern for
 buffer-backed cursors on vmwgfx, and while it's possible to dirty those
 buffers based on page-faults, like we do with fb surfaces, we'd rather
 avoid
 having to implement and maintain that.

 I'm not sure whether / how you handle the case of hardware render to
 cursor
 surfaces on i915, but it seems to me like if a lot of drivers need to
 implement driver specific tricks to meet the semantics of a generic
 interface, we should perhaps consider specifying those semantics in a way
 that helps avoid driver-specific workarounds?

 /Thomas

 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel



 As far as i know nouveau keeps an internal buffer object for the
 cursor and relies purely on the ioctl to copy the cursor into the
 actual cursor memory area. So why do you need tricks?



 Because I have a hard time judging whether the Intel implementation (needs
 tricks) or the Nouveau implementation (doesn't need tricks) should define
 the semantics of the ioctl, although I would prefer we could all agree on
 the doesn't need tricks semantics and put that down in writing in the
 drm_mode.h header file.

 /Thomas





I see your point, i certainly prefer the doesn't need tricks
approach. Maybe allow for some kind of hybrid approach, require the
ioctl for every cursor change, but allow drivers to do a kind of lazy
implementation that simply attaches the buffer to the hardware and let
it handle it. If they want to avoid copying overhead or stuff like
that. This would impose some restrictions on what you can do with a
cursor buffer after calling the ioctl, specifically you would be
required to leave the content alone, except for cursor updates.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Nouveau] custom monitor formats

[Maarten Maathuis]

On Mon, Oct 31, 2011 at 8:34 PM, William Moss bill.m.m...@gmail.com wrote:
 I recently updated from OpenSUSE 11.3 to 11.4.
 The proprietary Nvidia driver will no longer work, even the latest
 NVIDIA...run.
 I removed it and set up nouveau, which works fine except it ignores my
 customized
 /etc/xorg.conf.d files and sets my monitor to 1024x768.

 The monitor, an ACER AL1916W should be run at 1440x900 and this is the
 preferred
 mode (modeline) in the configuration files. This is how it worked with the
 NVIDIA
 drivers and should be still true.

 Apparently, the nouveau module (driver) is ignoring the settings in the
 /etc/xorg.d/50-device.conf and the associated conf files that are bound
 in the server conf file.

 I tested the setup with
        xinit -- :0
 which works but at the incorrect resolution.

 I even tried a customized and compiled 3.0.4 Kernel, to no avail.

 Any help would be appreciated.
 I have no problem with compiling and installing or even modifying source.

In general it is helpful to include xorg.conf and the xorg log, in
this specific case it might also be useful to include the output of
xrandr --verbose.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] enable ctxprog xfer only when we need it to save power introduces big performance regression

[Maarten Maathuis]

On Sat, Oct 29, 2011 at 7:29 PM, Marcin Slusarz
marcin.slus...@gmail.com wrote:
 On Sat, Oct 29, 2011 at 07:08:01PM +0200, Marcin Slusarz wrote:
 Hi

 I've bisected pretty big performance regression (nv92):

 $ git bisect good
 b2737681d5442f05ab6419e05468c3d2511a5ced is the first bad commit
 commit b2737681d5442f05ab6419e05468c3d2511a5ced
 Author: Martin Peres martin.pe...@ensi-bourges.fr
 Date:   Sat Jul 30 23:08:45 2011 +0200

     drm/nv50/gr: enable ctxprog xfer only when we need it to save power

 Weird, reverting it on top of current git does not restore it - in
 glxgears it's even worse (-~50%).

 Marcin
 ___
 Nouveau mailing list
 Nouveau@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/nouveau


Before this patch, what ensured that context switching was enabled?

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

nouveau page_flip function implement not wait vblank, which cause screen garbage

[Maarten Maathuis]

2011/10/25 chris :
> Can anyone give a suggestion, is wait-vblank fully implemented in
> page_flip() for nouveau drm driver?
>
>
> At 2011-10-24 14:30:55,chris? wrote:
>
> Dear,
>
> I use NVidia Geforce 7300GT graphics card in my PC, and Linux 3.1rc4 kernel
> code, git drm 2.4.36.
> ? When I run the vbltest program, it prints? "60HZ"? which indicated the
> implementation of drmWaitVBlank() and drm_vblank_wait()? is correct.
> ? But when I run modetest with option " -v -s 12:1280x1024" , it prints high
> fresh rate up to "150 HZ" .? I examing the code , and found that no waiting
> vblank operation is processed in nouveau_crtc_ page_flip() function. The
> screen? produced lots of garbage and blink very much.
> ?int
> nouveau_crtc_page_flip(struct drm_crtc *crtc, struct drm_framebuffer *fb,
> ?? struct drm_pending_vblank_event *event)
> {
> ..
> }
> I study the i915 intel_crtc_page_flip implementation.
> static int intel_crtc_page_flip(stru ct drm_crtc *crtc,
> ??? struct drm_framebuffer *fb,
> ??? struct drm_pending_vblank_event *event)
> {
> ..
>
> ??? ret = drm_vblank_get(dev, intel_crtc->pipe);
> ??? if (ret)
> ??? goto cleanup_objs;
>
> ??? work->pending_flip_obj = obj;
>
> ??? work->enable_stall_check = true;
>
> ??? /* Block clients from rendering to the new back buffer until
>  * the flip occurs and the object is no longer visible.
>  */
> ??? atomic_add(1 << intel_crtc->plane, >old_fb_obj->pending_flip);
>
> ??? ret = dev_priv->display.queue_flip(dev, crtc, fb, obj);
> ? p;nb sp;? if (ret)
> ??? goto cleanup_pending;
> ..
> }
>
> after vblank irq acquired, the interrupt isr will wakup the runqueue.
> 6159 static void do_intel_finish_page_flip(struct drm_device *dev,
> 6160?? struct drm_crtc *crtc)
> 6161 {
> ..
> 6211 list_add_tail(>base.link,
> 6212?? >base.file_priv->event_list);
> 6213 wake_up_interruptible(>base.file_priv->event_wait);
> 6214 }
> 6215
> 6216 drm_vblank_put(dev, intel_crtc->pipe);
> 6217
>
>
> Is there anyone use the same? driver and foun d this issues can tell me "is
> it a bug"?
>
> Thanks!
>
>
>
>
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>

It seems to be, the actual page flipping is done by software method
(see nv04_graph_mthd_page_flip). There is one thing i'm unsure about
and that is that we wait for the rendering to be done to the current
frontbuffer and not the current backbuffer (this is only done if the
page flip channel is different than the rendering channel). Maybe
someone else can comment on that.

-- 
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.