Re: [PATCH xf86-video-ati] Only change Set/MoveCursor hooks from what we expect

2018-03-10 Thread Mario Kleiner



On 03/08/2018 06:00 PM, Michel Dänzer wrote:

On 2018-03-07 10:33 AM, Mario Kleiner wrote:

On 03/07/2018 09:50 AM, Michel Dänzer wrote:

On 2018-03-07 04:45 AM, Mario Kleiner wrote:

On 03/05/2018 10:56 PM, Alex Deucher wrote:

On Mon, Mar 5, 2018 at 12:44 PM, Michel Dänzer 
wrote:

From: Michel Dänzer 

Since xf86CursorCloseScreen runs after RADEONCloseScreen_KMS,
PointPriv->spriteFuncs doesn't point to the same struct in the
latter as
in RADEONCursorInit_KMS. So we were restoring info->Set/MoveCursor to
the wrong struct. Then in the next server generation,
info->Set/MoveCursor would end up pointing to
drmmode_sprite_set/move_cursor, resulting in an infinite loop if
one of
them was called.

To avoid this, only change the Set/MoveCursor hooks if their values
match our expectations, otherwise leave them as is. This is kind of a
hack, but the alternative would be invasive and thus risky changes to
the way we're wrapping CloseScreen, and it's not even clear that can
work without changing xserver code.

Fixes: 1fe8ca75974c ("Keep track of how many SW cursors are visible on
     each screen")
Signed-off-by: Michel Dänzer 


Acked-by: Alex Deucher 



Nope, not quite, unfortunately. Tested against x-server master, mesa
master, ati-ddx master, with sddm login manager. With a freshly started
server, now on a dual-x-screen setup, instead of an infinite loop, i get
a server crash as soon as i move the mouse cursor from X-Screen 0 to
X-Screen 1:


Well, that's not the same issue I was seeing after all. I'll take
another look.


Bedtime here, but fwiw from some debug statements i added, it seems as
if on dual-x-screen init, x-screen 1 somehow inherits the
PointPriv->spriteFuncs->SetCursor = drmmode_sprite_set_cursor assignment
done on x-screen 0, and therefore already has it ==
drmmode_sprite_set_cursor, so during RADEONCursorInit_KMS for x-screen 1
the assignments get skipped, which leaves the info->SetCursor for
x-screen 1 == NULL. Therefore cursor update for x-screen 1 = boom!


Yeah, I was already suspecting something like that.


I've pushed fixes for this to both drivers. If you're still seeing an
issue with those, I need to know by early next week, otherwise I may not
be able to make releases with a fix before April.




Works now, as tested on the ati-ddx, can't test on amdgpu-ddx atm. 
Thanks for fixing this quickly!


-mario
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: ROCm installation from source

2018-03-10 Thread Bridgman, John
If you look about half way down this page under "The latest ROCm platform - 
ROCm 1.7" you should see a list of links to component repos. Each of those 
component repos has information on building:


https://github.com/RadeonOpenCompute/ROCm


If you have questions or problems building/installing you can use the "Issues" 
button at the top level repo or the component level repo to contact the ROC 
development team.



From: amd-gfx  on behalf of Joseph Wang 

Sent: March 10, 2018 5:30 AM
To: amd-gfx@lists.freedesktop.org
Subject: ROCm installation from source

Is there a document that describes the steps necessary to run an ROCm setup 
from source?

Thanks.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


Re: [PATCH] drm/amdgpu/dce: Don't turn off DP sink when disconnected

2018-03-10 Thread Michel Dänzer
On 2018-03-09 09:26 PM, Alex Deucher wrote:
> On Fri, Mar 9, 2018 at 12:27 PM, Michel Dänzer  wrote:
>> From: Michel Dänzer 
>>
>> Turning off the sink in this case causes various issues, because
>> userspace expects it to stay on until it turns it off explicitly.
>>
>> Instead, turn the sink off and back on when a display is connected
>> again. This dance seems necessary for link training to work correctly.
>>
>> Bugzilla: https://bugs.freedesktop.org/105308
>> Signed-off-by: Michel Dänzer 
> 
> Reviewed-by: Alex Deucher 

Thanks! Is it okay to add Cc: stable as well?


> Care to send a similar patch for radeon as well?

Will do.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx


ROCm installation from source

2018-03-10 Thread Joseph Wang
Is there a document that describes the steps necessary to run an ROCm setup
from source?

Thanks.
___
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx