Adding relevant mailing lists, please don't forget that next time around. At least with haswell based models the most likely cause for this is lack of DP mst support. We have something from Dave Airlie queued up for 3.17. -Daniel On Fri, Jul 25, 2014 at 10:19 PM, <Mario_Limonciello@xxxxxxxx> wrote: > Hi Jani and Daniel, > > I'm Mario Limonciello, I'm one of the engineers on the Dell Linux team. A variety of customers have been reporting into our pro-support staff problems related to DP docking on Latitude laptops and current kernels. I've been trying to get caught up to speed what's happened in this arena and our staff shared with me this issue: > > http://www.libreoffice.org/bugzilla/show_bug.cgi?id=73694 > > It seems that there was a patch proposed by Daniel that made things follow spec more closely. This was submitted to the kernel, and expectedly some regressions came up with some HW. > > commit 38aecea0ccbb909d635619cba22f1891e589b434 > Author: Daniel Vetter <daniel.vetter@xxxxxxxx> > Date: Mon Mar 3 11:18:10 2014 +0100 > > I saw that a commit was made by Jani to address some of this: > > commit f4cdbc21444a45d207a8dc175f44d2facfbd0845 > Author: Jani Nikula <jani.nikula@xxxxxxxxx> > Date: Wed May 14 13:02:19 2014 +0300 > > I then saw after that some regressions were found on Lenovo docks in SST mode and David Airlie reverted the original patch. > > commit c6930992948adf0f8fc1f6ff1da51c5002a2cf95 > Author: Dave Airlie <airlied@xxxxxxxxxx> > Date: Mon Jul 14 11:04:39 2014 +1000 > > I know there is this (arbitrary) rule within the kernel that you can't cause regressions with some hardware which makes getting things like this resolved difficult (eg where some HW follows spec but the code won't work because other hardware doesn't follow spec). > > Is there a middle ground we could land on here somewhere? Maybe something with at least adding a modprobe option to adjust the behavior? Or maybe some quirks specifically for the hardware that's out of spec to follow the codepath differently? > > I'd like to look out for our customers and try to get them a solution that doesn't require them having to build kernels with their own patches, and I think that starts with having mainline functional. > > Thank you, > > Mario Limonciello > Dell | EUC SW Dev Engineering > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
