On Sat, 24 Aug 2019 at 06:24, Francis, David <David.Francis@xxxxxxx> wrote: > > Adding DSC functionality to drm_dp_mst_atomic_check() is a good idea. > However, until amdgpu switches over to that system, I wouldn't be able > to test those changes. Making that switch is on our TODO list, and it would > fix a number of problems with our current MST implementation, but > it's going to be a major rewrite. > > MST DSC hardware is already on the market. It would be expedient to > merge the patches we need for Navi support sooner and update > drm_dp_mst_atomic_check when we're able to test it. Is there any commitment to rewriting it, a timeline or anything? The problem with this situation is there is always new hardware coming onto the market, and there is always pressure to support all the features of that new hardware, and the pressure always comes like this and being expedient. However I've found that a lot of the time the required refactor or work is never done, because the time is being allocated now to the next GPU that is coming on the market, and nobody ever cares enough to clean up their technical debt. How come the needs for MST DSC support wasn't identified earlier, blocked on refactoring of the code to use common code, and then that task made a higher priority? I'm sorta inclined to say no we shouldn't be merging any driver specific code here, because this is the only point we can push pressure on to refactor the MST implementation, which I guess otherwise we'll just keep avoiding until Lyude ends up doing it for you. Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
