Re: RFC: output polling + disconnected operation
On Mit, 2010-05-05 at 11:12 +1000, Dave Airlie wrote: So at startup X drivers genearlly seem to ask for a list of connectors and status for them, and if it can't find any connected, it goes to unknown, and if none of those they fall over and X exits. Idea 1 was to just pick a connector and claim it is connected when nothing else is, however this falls over, for DVI esp on a dual-DVI card. You pick a DVI connector, claim it is connected, you most likely end up turning on the analog portion of it, you hotplug a digital connector and the uevent gets sent, the client app repolls the connector status, sees the connector is still connected so doesn't do anything. Forcing a disconnect/connect is incredibly racy and hard. So Ben Skeggs suggested we just fake a disconnected connector for this case. It looks a bit messy in xrandr, but from what I can see the gnome client ignores it as it should. Anyways any other ideas on how this might be tackled or improvements that could be made? If I understand correctly, this tries to address userspace issues (X refusing to start up with nothing connected, GNOME doing nothing when an output changes from unknown to connected) by making the kernel fake information. Wouldn't it be better to address these in userspace? Otherwise if more similar issues turn up, we might end up in a twisty maze of fake information, possibly with conflicting requirements. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: output polling + disconnected operation
2010/5/5 Michel Dänzer mic...@daenzer.net: On Mit, 2010-05-05 at 11:12 +1000, Dave Airlie wrote: So at startup X drivers genearlly seem to ask for a list of connectors and status for them, and if it can't find any connected, it goes to unknown, and if none of those they fall over and X exits. Idea 1 was to just pick a connector and claim it is connected when nothing else is, however this falls over, for DVI esp on a dual-DVI card. You pick a DVI connector, claim it is connected, you most likely end up turning on the analog portion of it, you hotplug a digital connector and the uevent gets sent, the client app repolls the connector status, sees the connector is still connected so doesn't do anything. Forcing a disconnect/connect is incredibly racy and hard. So Ben Skeggs suggested we just fake a disconnected connector for this case. It looks a bit messy in xrandr, but from what I can see the gnome client ignores it as it should. Anyways any other ideas on how this might be tackled or improvements that could be made? If I understand correctly, this tries to address userspace issues (X refusing to start up with nothing connected, GNOME doing nothing when an output changes from unknown to connected) by making the kernel fake information. Wouldn't it be better to address these in userspace? Otherwise if more similar issues turn up, we might end up in a twisty maze of fake information, possibly with conflicting requirements. The thing is current UMS drivers already do bad faking of stuff, have a look at the info-first_load_no_devices flags in -ati. So if nobody ever thought this was worth doing properly in the first place or anytime since, I'd like that KMS drivers can just follow what UMS drivers have done. Granted I could probably do the faking in the KMS X.org drivers, but since UMS drivers never had hotplug or any useful uevent mechanism they'd never see the problem, so I've fixed the drivers to work. My worry with changing X/GNOME is that it'll break some random corner case assumptions somewhere else in userspace, there are many randr clients and I don't want to hunt them all down, I'd like to advertise the protocol we have now if I can. Dave. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: output polling + disconnected operation
On Mit, 2010-05-05 at 20:25 +1000, Dave Airlie wrote: 2010/5/5 Michel Dänzer mic...@daenzer.net: On Mit, 2010-05-05 at 11:12 +1000, Dave Airlie wrote: So at startup X drivers genearlly seem to ask for a list of connectors and status for them, and if it can't find any connected, it goes to unknown, and if none of those they fall over and X exits. Idea 1 was to just pick a connector and claim it is connected when nothing else is, however this falls over, for DVI esp on a dual-DVI card. You pick a DVI connector, claim it is connected, you most likely end up turning on the analog portion of it, you hotplug a digital connector and the uevent gets sent, the client app repolls the connector status, sees the connector is still connected so doesn't do anything. Forcing a disconnect/connect is incredibly racy and hard. So Ben Skeggs suggested we just fake a disconnected connector for this case. It looks a bit messy in xrandr, but from what I can see the gnome client ignores it as it should. Anyways any other ideas on how this might be tackled or improvements that could be made? If I understand correctly, this tries to address userspace issues (X refusing to start up with nothing connected, GNOME doing nothing when an output changes from unknown to connected) by making the kernel fake information. Wouldn't it be better to address these in userspace? Otherwise if more similar issues turn up, we might end up in a twisty maze of fake information, possibly with conflicting requirements. The thing is current UMS drivers already do bad faking of stuff, have a look at the info-first_load_no_devices flags in -ati. So if nobody ever thought this was worth doing properly in the first place or anytime since, I'd like that KMS drivers can just follow what UMS drivers have done. Granted I could probably do the faking in the KMS X.org drivers, but since UMS drivers never had hotplug or any useful uevent mechanism they'd never see the problem, so I've fixed the drivers to work. Doing it in the X drivers would be less ugly IMO, at least the workaround would be in / next to the same component as one of the underlying problems. My worry with changing X/GNOME is that it'll break some random corner case assumptions somewhere else in userspace, there are many randr clients and I don't want to hunt them all down, Then how do you know none of them will trip over this change? I'd like to advertise the protocol we have now if I can. What protocol are you referring to? To me it would make more sense to address the underlying problems rather than piling up more workarounds. The KMS API should provide as accurate information as possible, not second-guess what its users might expect. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15166] Changing brightness of backlight freezes kernel with radeon kms enabled.
https://bugzilla.kernel.org/show_bug.cgi?id=15166 --- Comment #48 from Alex Deucher alexdeuc...@gmail.com 2010-05-05 15:00:30 --- One of my coworkers who is also experiencing the problem bisected it down to: f3eee54276dfd1117fd94259f2b4a38388264724: commit f3eee54276dfd1117fd94259f2b4a38388264724 Author: Yinghai Lu ying...@kernel.org Date: Mon Dec 14 11:52:15 2009 +0900 x86: Gart: fix breakage due to IOMMU initialization cleanup This fixes the following breakage of the commit 75f1cdf1dda92cae037ec848ae63690d91913eac: - GART systems that don't AGP with broken BIOS and more than 4GB memory are forced to use swiotlb. They can allocate aperture by hand and use GART. - GART systems without GAP must disable GART on shutdown. - swiotlb usage is forced by the boot option, gart_iommu_hole_init() is not called, so we disable GART early_gart_iommu_check(). Signed-off-by: Yinghai Lu ying...@kernel.org Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp LKML-Reference: 1260759135-6450-3-git-send-email-fujita.tomon...@lab.ntt.co.jp Signed-off-by: Ingo Molnar mi...@elte.hu -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15469] [Intel Graphics HD] Kernel panic on boot with certain BIOS options
https://bugzilla.kernel.org/show_bug.cgi?id=15469 --- Comment #4 from Artem S. Tashkinov t.ar...@mailcity.com 2010-05-05 19:18:57 --- It's kind of stupid to report (no i915 patches have been merged after rc5), but kernel 2.6.34-rc6 is also affected. I can post the entire backtrace in a text form if anyone's interested. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching someone on the CC list of the bug. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15469] [Intel Graphics HD] Kernel panic on boot with certain BIOS options
https://bugzilla.kernel.org/show_bug.cgi?id=15469 --- Comment #5 from Daniel Vetter dan...@ffwll.ch 2010-05-05 19:47:37 --- --- Comment #4 from Artem S. Tashkinov t.ar...@mailcity.com 2010-05-05 19:18:57 --- It's kind of stupid to report (no i915 patches have been merged after rc5), but kernel 2.6.34-rc6 is also affected. I can post the entire backtrace in a text form if anyone's interested. I have an idea of what's going on + an idea of how to prove it ;) Can you please boot your box with the crashing bios options, but don't load the i915 module (delete it if nothing else helps). Manually load the intel-agp module and post the dmesg output here (the messages by the intel-agp module are the important stuff). Thanks. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching someone on the CC list of the bug. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15469] [Intel Graphics HD] Kernel panic on boot with certain BIOS options
https://bugzilla.kernel.org/show_bug.cgi?id=15469 Artem S. Tashkinov t.ar...@mailcity.com changed: What|Removed |Added Attachment #25406|0 |1 is obsolete|| --- Comment #6 from Artem S. Tashkinov t.ar...@mailcity.com 2010-05-05 20:38:35 --- Created an attachment (id=26245) -- (https://bugzilla.kernel.org/attachment.cgi?id=26245) dmesg (In reply to comment #5) --- Comment #4 from Artem S. Tashkinov t.ar...@mailcity.com 2010-05-05 19:18:57 --- It's kind of stupid to report (no i915 patches have been merged after rc5), but kernel 2.6.34-rc6 is also affected. I can post the entire backtrace in a text form if anyone's interested. I have an idea of what's going on + an idea of how to prove it ;) Can you please boot your box with the crashing bios options, but don't load the i915 module (delete it if nothing else helps). Manually load the intel-agp module and post the dmesg output here (the messages by the intel-agp module are the important stuff). Thanks. Here it is. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching someone on the CC list of the bug. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/fbdev: rework output polling to be back in the core. (v2)
From: Dave Airlie airl...@redhat.com
After thinking it over a lot it made more sense for the core to deal with
the output polling especially so it can notify X.
v2: drop plans for fake connector - per Michel's comments - fix X patch sent to
xorg-devel, add intel polled/hpd setting, add initial nouveau polled/hpd
settings.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/Kconfig |2 +-
drivers/gpu/drm/drm_crtc_helper.c | 90 +++
drivers/gpu/drm/drm_fb_helper.c | 123 ---
drivers/gpu/drm/i915/i915_irq.c |3 +-
drivers/gpu/drm/i915/intel_crt.c|5 +
drivers/gpu/drm/i915/intel_display.c|1 +
drivers/gpu/drm/i915/intel_dp.c |2 +
drivers/gpu/drm/i915/intel_drv.h|2 +-
drivers/gpu/drm/i915/intel_fb.c | 14 ++--
drivers/gpu/drm/i915/intel_hdmi.c |1 +
drivers/gpu/drm/i915/intel_sdvo.c |2 +
drivers/gpu/drm/nouveau/nouveau_connector.c | 12 +++
drivers/gpu/drm/nouveau/nouveau_display.c |1 +
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 14 +--
drivers/gpu/drm/nouveau/nouveau_fbcon.h |2 +-
drivers/gpu/drm/nouveau/nv50_display.c |2 +-
drivers/gpu/drm/radeon/radeon_connectors.c | 13 +++
drivers/gpu/drm/radeon/radeon_display.c |9 ++
drivers/gpu/drm/radeon/radeon_fb.c | 14 +---
drivers/gpu/drm/radeon/radeon_irq_kms.c |5 +-
drivers/gpu/drm/radeon/radeon_mode.h|3 +-
include/drm/drm_crtc.h | 17
include/drm/drm_crtc_helper.h |3 +
include/drm/drm_fb_helper.h | 13 +---
24 files changed, 199 insertions(+), 154 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index be5aa7d..2583ddf 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -9,6 +9,7 @@ menuconfig DRM
depends on (AGP || AGP=n) PCI !EMULATED_CMPXCHG MMU
select I2C
select I2C_ALGOBIT
+ select SLOW_WORK
help
Kernel-level support for the Direct Rendering Infrastructure (DRI)
introduced in XFree86 4.0. If you say Y here, you need to select
@@ -23,7 +24,6 @@ config DRM_KMS_HELPER
depends on DRM
select FB
select FRAMEBUFFER_CONSOLE if !EMBEDDED
- select SLOW_WORK
help
FB and CRTC helpers for KMS drivers.
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index b142ac2..a14848d 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -807,3 +807,93 @@ int drm_helper_resume_force_mode(struct drm_device *dev)
return 0;
}
EXPORT_SYMBOL(drm_helper_resume_force_mode);
+
+static struct slow_work_ops output_poll_ops;
+
+#define DRM_OUTPUT_POLL_PERIOD (10*HZ)
+static void output_poll_execute(struct slow_work *work)
+{
+ struct delayed_slow_work *delayed_work = container_of(work, struct
delayed_slow_work, work);
+ struct drm_device *dev = container_of(delayed_work, struct drm_device,
mode_config.output_poll_slow_work);
+ struct drm_connector *connector;
+ enum drm_connector_status old_status, status;
+ bool repoll = false, changed = false;
+ int ret;
+
+ list_for_each_entry(connector, dev-mode_config.connector_list, head) {
+
+ /* if this is HPD or polled don't check it -
+ TV out for instance */
+ if (!connector-polled)
+ continue;
+
+ else if (connector-polled (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT))
+ repoll = true;
+
+ old_status = connector-status;
+ /* if we are connected and don't want to poll for disconnect
+ skip it */
+ if (old_status == connector_status_connected
+ !(connector-polled DRM_CONNECTOR_POLL_DISCONNECT)
+ !(connector-polled DRM_CONNECTOR_POLL_HPD))
+ continue;
+
+ status = connector-funcs-detect(connector);
+ if (old_status != status)
+ changed = true;
+ }
+
+ if (changed) {
+ /* send a uevent + call fbdev */
+ drm_sysfs_hotplug_event(dev);
+ if (dev-mode_config.funcs-output_poll_changed)
+ dev-mode_config.funcs-output_poll_changed(dev);
+ }
+
+ if (repoll) {
+ ret = delayed_slow_work_enqueue(delayed_work,
DRM_OUTPUT_POLL_PERIOD);
+ if (ret)
+ DRM_ERROR(delayed enqueue failed %d\n, ret);
+ }
+}
+
+void drm_kms_helper_poll_init(struct drm_device *dev)
+{
+ struct drm_connector *connector;
+ bool poll = false;
+ int ret;
+
+ list_for_each_entry(connector,
