On Mon, Jun 10, 2013 at 12:27 AM, Chris Wilson chris@chris-wilson.co.uk wrote:
It is these machines that require the per-connector quirk to turn off hotplug detection anyway. And there are users that need to turn off all hotplug detection (hardware and polling) on certain connectors whilst plugged into their kvm.
I think it'd be useful to take one step back and lock at the intended result (i.e. use-cases) a bit first, so cut out all the other discussion.
Pondering this a bit more I see a bunch of things we could aim for: - Giving userspace more rope to make even horribly broken systems useful. We have the hpd storm stuff and the connector state forcing, but atm the story is still imcomplete there I think. I guess it would be useful to expose the connector->force attribute (maybe through sysfs, tends to be easier to set correctly with scripts), so that users with really flaky hw could update the forced state at runtim. Then we could make the EDID firmware loading a bit more flexible (again maybe expose the firmware filename in sysfs per-connector) and users would be able to fake any setup. The last missing puzzle piece would be to add a new FORCE_INTEGRATED mode which also eschews the repeated ->get_modes calls when ->num_modes > 0 or so.
- Allowing some fine-tuning of the hpd storm detection engine. Since we don't yet have much real-world usage data I'm not sure what we could want here, so probably best to postpone for now.
- Disabling polling. Presuming we have the pimped connector forcing infrastructure described above I'm not sure whether we really need more than what the global tunable already affords us. Thanks to locking reworks and a few other things the poll work is really unobtrusive nowadays (especially if all outputs claim to support hotplug).
- Better caching of EDID data and connector state. My favourite approach for this would be some opportunistic caching for e.g. 1 second in the ->fill_modes callback. Hotplug interrupts would invalidate the caching (and since we already filter hotplug interrupts to only touch relevant outputs with Egbert's latest patches, that should be fairly good). Of course caching the edid like this in a reality with horribly unreliable hpd will add new races and inconsistencies between reality and what the kernel reports. But in those cases hotplug reporting is already horribly racy, so not really a real degration. Like the poll intervall we could make that tuneable.
- Full EDID caching when the hotplug interrupt is actually reliable. I think that this is the case for native DP outputs, at least I'm not aware of any bug report. And maybe we'll figure out the few holdouts for HDMI hpd handling. If we have the opportunistic caching infrastructure from the previous point we could simply disable the time-based invalidation for those, and only invalidate the edid/connector state on a hotplug event. But even for DP I think it's better if the kernel is in charge of setting this, since e.g. plugging in a DP->VGA converter means that we need to disable full caching and switch back to opportunistic caching. And then back again if a native DP monitor is plugged in.
Hopefully this dump here is useful to broaden the discussion a bit. Thoughts?
Cheers, Daniel
-- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch