On Tue, 2019-08-06 at 19:43 +0200, Daniel Vetter wrote: > On Tue, Aug 6, 2019 at 4:06 PM Lisovskiy, Stanislav > <stanislav.lisovskiy@xxxxxxxxx> wrote: > > > > On Tue, 2019-08-06 at 15:51 +0200, Daniel Vetter wrote: > > > On Tue, Aug 06, 2019 at 03:55:48PM +0300, Stanislav Lisovskiy > > > wrote: > > > > This series introduce to drm a way to determine if something > > > > else > > > > except connection_status had changed during probing, which > > > > can be used by other drivers as well. Another i915 specific > > > > part > > > > uses this approach to determine if edid had changed without > > > > changing the connection status and send a hotplug event. > > > > > > Did you read through the entire huge thread on all this (with I > > > think > > > Paul, Pekka, Ram and some others)? I feel like this is mostly > > > taking > > > that > > > idea, but not taking a lot of the details we've discussed there. > > > Specifically I'm not sure how userspace should handle this > > > without > > > also > > > exposing the epoch counter, or at least generating a hotplug > > > event > > > for the > > > specific connector. All that and more we discussed there. > > > > > > And then there's the follow-up question: What's the userspace for > > > this? > > > Existing expectations are a minefield here, so even if you don't > > > plan > > > to > > > change userspace we need to know what this is aimed for, and see > > > above I > > > don't think this is possible to use without userspace changes ... > > > > Yes, sure I agree about userspace. However I guess we must start > > from > > something at least. > > I think I have seen some discussion regarding exposing this epoch > > counter as a property. Was even implementing this at some point but > > didn't dare to send to mailing list :) > > > > My idea was just to expose this epoch counter as a drm property, to > > let > > userspace then to figure out, what has happened, as imho adding > > different events for this and that is a bit of an overkill and > > brings > > additional complexity.. > > Adding Ram and link to the (warning, huge!) thread: > > https://patchwork.freedesktop.org/patch/303905/?series=57232&rev=9 > > > However, please let me know, what do you think we should do for > > userspace. > > That seems backwards, since this is an uapi change I'd expect you're > solving some specific issue in some specific userspace? If we're > doing > this just because I'm not really following. Specifically, I'm solving an issue of changed edid during suspend, like we for example have in kms_chamelium hotplug tests(some of which now fail because of that). So even if connection status hasn't changed, we still need to send hotplug event and userspace needs to be able to understand that something had changed and whether we need to do a full reprobe or not. Epoch counter property would be responsible for this. As I understand in general there might be other connector updates, except edid which we need propagate in a similar way. -Stanislav > > Cheers, Daniel > > > > > > > -Stanislav > > > > > > > -Daniel > > > > > > > > > > > Stanislav Lisovskiy (3): > > > > drm: Add helper to compare edids. > > > > drm: Introduce change counter to drm_connector > > > > drm/i915: Send hotplug event if edid had changed. > > > > > > > > drivers/gpu/drm/drm_connector.c | 1 + > > > > drivers/gpu/drm/drm_edid.c | 33 > > > > ++++++++++++++++++++ > > > > drivers/gpu/drm/drm_probe_helper.c | 29 > > > > +++++++++++++++- > > > > - > > > > drivers/gpu/drm/i915/display/intel_dp.c | 16 +++++++++- > > > > drivers/gpu/drm/i915/display/intel_hdmi.c | 16 ++++++++-- > > > > drivers/gpu/drm/i915/display/intel_hotplug.c | 21 ++++++++++ > > > > --- > > > > include/drm/drm_connector.h | 3 ++ > > > > include/drm/drm_edid.h | 9 ++++++ > > > > 8 files changed, 117 insertions(+), 11 deletions(-) > > > > > > > > -- > > > > 2.17.1 > > > > > > > > > > > > > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
