On Fri, Nov 20, 2015 at 09:25:14AM +, Chris Wilson wrote:
> On Fri, Nov 20, 2015 at 09:11:00AM +0100, Daniel Vetter wrote:
> > On Thu, Nov 19, 2015 at 09:06:04PM +, Chris Wilson wrote:
> > > On Thu, Nov 19, 2015 at 05:46:50PM +0100, Daniel Vetter wrote:
> > > > To avoid even more code
On Tue, Nov 24, 2015 at 11:51:09AM +0100, Daniel Vetter wrote:
> On Fri, Nov 20, 2015 at 09:25:14AM +, Chris Wilson wrote:
> > And something like .fill_modes -> .probe (after removing .detect).
>
> Hm, not sure. For panels we never really probe anything, the important bit
> is (at least for
On Fri, Nov 20, 2015 at 09:11:00AM +0100, Daniel Vetter wrote:
> On Thu, Nov 19, 2015 at 09:06:04PM +, Chris Wilson wrote:
> > On Thu, Nov 19, 2015 at 05:46:50PM +0100, Daniel Vetter wrote:
> > > To avoid even more code duplication punt this all to the probe worker,
> > > which needs some
On Thu, Nov 19, 2015 at 09:06:04PM +, Chris Wilson wrote:
> On Thu, Nov 19, 2015 at 05:46:50PM +0100, Daniel Vetter wrote:
> > To avoid even more code duplication punt this all to the probe worker,
> > which needs some slight adjustment to also generate a uevent when the
> > status has changed
On Thu, Nov 19, 2015 at 05:46:50PM +0100, Daniel Vetter wrote:
> To avoid even more code duplication punt this all to the probe worker,
> which needs some slight adjustment to also generate a uevent when the
> status has changed to due connector->force.
>
> v2: Instead of running the
To avoid even more code duplication punt this all to the probe worker,
which needs some slight adjustment to also generate a uevent when the
status has changed to due connector->force.
v2: Instead of running the output_poll_work (which is kinda the wrong
thing and a layering violation since it's
To avoid even more code duplication punt this all to the probe worker,
which needs some slight adjustment to also generate a uevent when the
status has changed to due connector->force.
v2: Instead of running the output_poll_work (which is kinda the wrong
thing and a layering violation since it's
