2.6.34-rc6-git2: Reported regressions from 2.6.33
This message contains a list of some regressions from 2.6.33, for which there are no fixes in the mainline known to the tracking team. If any of them have been fixed already, please let us know. If you know of any other unresolved regressions from 2.6.33, please let us know either and we'll add them to the list. Also, please let us know if any of the entries below are invalid. Each entry from the list will be sent additionally in an automatic reply to this message with CCs to the people involved in reporting and handling the issue. Listed regressions statistics: Date Total Pending Unresolved 2010-05-04 76 26 22 2010-04-20 64 35 34 2010-04-07 48 35 33 2010-03-21 15 13 10 Unresolved regressions -- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15880 Subject : Very bad regression from 2.6.33 as of 1600f9def Submitter : Alex Elsayed eternal...@gmail.com Date: 2010-04-29 2:28 (6 days old) Message-ID : loom.20100429t041908-...@post.gmane.org References : http://marc.info/?l=linux-kernelm=127250825306178w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15863 Subject : 2.6.34-rc5-git7 (plus all patches) -- another suspicious rcu_dereference_check() usage. Submitter : Miles Lane miles.l...@gmail.com Date: 2010-04-27 0:51 (8 days old) Message-ID : h2ya44ae5cd1004261751waa5cb65ei3d139cbcfa2cc...@mail.gmail.com References : http://marc.info/?l=linux-kernelm=127232949104878w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15862 Subject : 2.6.34-rc4/5: iwlagn unusable until reload Submitter : Nico Schottelius nico-linux-20100...@schottelius.org Date: 2010-04-27 7:49 (8 days old) Message-ID : 20100427074934.gb3...@ikn.schottelius.org References : http://marc.info/?l=linux-kernelm=127235784004839w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15858 Subject : [2.6.34-rc5] bad page state copying to/from HFS+ filesystem... Submitter : Daniel J Blueman daniel.blue...@gmail.com Date: 2010-04-25 21:14 (10 days old) Message-ID : v2k6278d2221004251414kbbcc41baw78b86120d81dc...@mail.gmail.com References : http://marc.info/?l=linux-kernelm=127223008621881w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15805 Subject : reiserfs locking Submitter : Alexander Beregalov a.berega...@gmail.com Date: 2010-04-15 21:02 (20 days old) Message-ID : t2ka4423d671004151402n7b2dc425mdc9c6bb9640d6...@mail.gmail.com References : http://marc.info/?l=linux-kernelm=127136535323933w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15790 Subject : Meta-Bug: Regressions Submitter : Florian Mickler fmick...@gmx.de Date: 2010-04-15 18:21 (20 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15788 Subject : external usb sound card doesn't work after resume Submitter : François Valenduc francois.valen...@tvcablenet.be Date: 2010-04-15 10:16 (20 days old) Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15717 Subject : bluetooth oops Submitter : Pavel Machek pa...@ucw.cz Date: 2010-03-14 20:14 (52 days old) Message-ID : 20100314201434.ge22...@elf.ucw.cz References : http://marc.info/?l=linux-kernelm=126859771528426w=4 Handled-By : Marcel Holtmann mar...@holtmann.org Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15713 Subject : hackbench regression due to commit 9dfc6e68bfe6e Submitter : Alex Shi alex@intel.com Date: 2010-03-25 8:40 (41 days old) First-Bad-Commit: http://git.kernel.org/linus/9dfc6e68bfe6ee452efb1a4e9ca26a9007f2b864 Message-ID : 1269506457.4513.141.ca...@alexs-hp.sh.intel.com References : http://marc.info/?l=linux-kernelm=126950632920682w=4 Handled-By : Christoph Lameter c...@linux-foundation.org Pekka Enberg penb...@cs.helsinki.fi Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15712 Subject : [regression] 2.6.34-rc1 to -rc3 on zaurus: no longer boots Submitter : Pavel Machek pa...@ucw.cz Date: 2010-04-01 6:06 (34 days old) Message-ID : 20100401060624.ga1...@ucw.cz References : http://marc.info/?l=linux-kernelm=127010200817402w=2 Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15704 Subject : [r8169] WARNING: at net/sched/sch_generic.c Submitter : Sergey Senozhatsky sergey.senozhat...@gmail.com Date: 2010-03-31 10:21 (35 days old) Message-ID : 20100331102142.ga3...@swordfish.minsk.epam.com References : http://marc.info/?l=linux-kernelm=127003090406108w=2 Bug-Entry :
[Bug 15166] Changing brightness of backlight freezes kernel with radeon kms enabled.
https://bugzilla.kernel.org/show_bug.cgi?id=15166 --- Comment #47 from Aurélien Couderc zecou...@free.fr 2010-05-04 22:59:41 --- Yes, it's fixed in drm-radeon-testing for my laptop too. -- 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
Re: 2.6.34-rc6-git2: Reported regressions from 2.6.33
On Tue, 4 May 2010, Rafael J. Wysocki wrote: Unresolved regressions -- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15880 Subject : Very bad regression from 2.6.33 as of 1600f9def Submitter : Alex Elsayed eternal...@gmail.com Date : 2010-04-29 2:28 (6 days old) Message-ID: loom.20100429t041908-...@post.gmane.org References: http://marc.info/?l=linux-kernelm=127250825306178w=2 This looks like it wasn't a regression, but some other compile/install issue. See http://marc.info/?l=linux-kernelm=127274294422719w=2 where he reports that his self-compiled 2.6.33 doesn't boot either. There's some confusion about .config, but it might well be an install problem too (in fact, that sounds more likely - the original bug-report seems to reboot before the kernel has really even booted - it apparently hasn't done the graphics mode switch by the early bootloader) Linus -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/3] drm/radeon/kms: avoid executing dac detection table on r4xx + rv515.
From: Dave Airlie airl...@redhat.com
The DAC Load detection table is meant to take a parameter selecting the DAC
to do load detection on. However on certain BIOS revisions it accept no
parameters and load detects both DACs, with the result that load detecting on
the second DAC causes flicker on the first, which isn't really acceptable.
This also makes us report disconnected instead of unknown for the case where
we have no DAC detection.
We should code up a workaround function for these chips to workaround this
case.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/radeon/atom.c| 15 +--
drivers/gpu/drm/radeon/atom.h|2 ++
drivers/gpu/drm/radeon/radeon_encoders.c | 15 +++
3 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
index 1d56983..c1c669a 100644
--- a/drivers/gpu/drm/radeon/atom.c
+++ b/drivers/gpu/drm/radeon/atom.c
@@ -1330,12 +1330,13 @@ bool atom_parse_data_header(struct atom_context *ctx,
int index,
return true;
}
-bool atom_parse_cmd_header(struct atom_context *ctx, int index, uint8_t * frev,
- uint8_t * crev)
+bool atom_parse_cmd_header_stack(struct atom_context *ctx, int index, uint8_t
*frev,
+uint8_t *crev, uint8_t *ps_size, uint8_t
*ws_size)
{
int offset = index * 2 + 4;
int idx = CU16(ctx-cmd_table + offset);
u16 *mct = (u16 *)(ctx-bios + ctx-cmd_table + 4);
+ u16 table_attrib = CU16(idx + 4);
if (!mct[index])
return false;
@@ -1344,9 +1345,19 @@ bool atom_parse_cmd_header(struct atom_context *ctx, int
index, uint8_t * frev,
*frev = CU8(idx + 2);
if (crev)
*crev = CU8(idx + 3);
+ if (ps_size)
+ *ps_size = (table_attrib 0xe00) 8;
+ if (ws_size)
+ *ws_size = (table_attrib 0xff);
return true;
}
+bool atom_parse_cmd_header(struct atom_context *ctx, int index, uint8_t *rev,
+ uint8_t *crev)
+{
+ return atom_parse_cmd_header_stack(ctx, index, rev, crev, NULL, NULL);
+}
+
int atom_allocate_fb_scratch(struct atom_context *ctx)
{
int index = GetIndexIntoMasterTable(DATA, VRAM_UsageByFirmware);
diff --git a/drivers/gpu/drm/radeon/atom.h b/drivers/gpu/drm/radeon/atom.h
index cd1b64a..ca21357 100644
--- a/drivers/gpu/drm/radeon/atom.h
+++ b/drivers/gpu/drm/radeon/atom.h
@@ -147,6 +147,8 @@ bool atom_parse_data_header(struct atom_context *ctx, int
index, uint16_t *size,
uint8_t *frev, uint8_t *crev, uint16_t *data_start);
bool atom_parse_cmd_header(struct atom_context *ctx, int index,
uint8_t *frev, uint8_t *crev);
+bool atom_parse_cmd_header_stack(struct atom_context *ctx, int index, uint8_t
*rev,
+uint8_t *crev, uint8_t *ps_size, uint8_t
*ws_size);
int atom_allocate_fb_scratch(struct atom_context *ctx);
#include atom-types.h
#include atombios.h
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 30293be..f2ea756 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -1406,13 +1406,20 @@ atombios_dac_load_detect(struct drm_encoder *encoder,
struct drm_connector *conn
ATOM_DEVICE_CRT_SUPPORT)) {
DAC_LOAD_DETECTION_PS_ALLOCATION args;
int index = GetIndexIntoMasterTable(COMMAND, DAC_LoadDetection);
- uint8_t frev, crev;
+ uint8_t frev, crev, ps_size;
memset(args, 0, sizeof(args));
- if (!atom_parse_cmd_header(rdev-mode_info.atom_context, index,
frev, crev))
+ if (!atom_parse_cmd_header_stack(rdev-mode_info.atom_context,
index, frev, crev, ps_size, NULL))
return false;
+ /* r4xx and some early rv5xx probe all DACs, this can cause
distrubances in the force,
+ also on other DACs. - we can detect these tables as they
have a 0 sized param stack */
+ if (ps_size == 0) {
+ DRM_DEBUG(DAC load detection isn't properly supported
on this GPU\n);
+ return false;
+ }
+
args.sDacload.ucMisc = 0;
if ((radeon_encoder-encoder_id ==
ENCODER_OBJECT_ID_INTERNAL_DAC1) ||
@@ -1452,8 +1459,8 @@ radeon_atom_dac_detect(struct drm_encoder *encoder,
struct drm_connector *connec
uint32_t bios_0_scratch;
if (!atombios_dac_load_detect(encoder, connector)) {
- DRM_DEBUG(detect returned false \n);
- return connector_status_unknown;
+ DRM_DEBUG(dac detect returned false\n);
+ return connector_status_disconnected;
}
if (rdev-family =
RFC: output polling + disconnected operation
So one of the problems I want to solve for KMS it the what to do when nothing is plugged in at startup, I've fixed this for fbcon in the current tree, but when looking at X + randr clients I realised it needed a bit more work. I've pulled the polling code back into the core, and it nows can send uevents to userspace when something changes. The drivers can specify flags for each output as to whether it is hotplug capable, needs connection polling and can handle disconnection polling. A lot of outputs can't handle disconnection polling due to DAC polling causing flicker on the current output. Also things like s-video shouldn't be polled for connect or disconnect esp if sharing a dac with a VGA output. So with patch one, we can boot, start X all without anything connected, however it runs into an issue which patch 2 is an attempt to fix. 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? Dave. -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm: create fake disconnected connector for use when nothing is plugged in.
From: Dave Airlie airl...@redhat.com
The problem with using a real connector with a fake status is we have no way to
tell userspace it got disconnected if something gets plugged into it, i.e. you
use DVI-0 as the connector with an unknown or connected status, and it puts a
1024x768 mode on it. However when a monitor appears on that connector when we
send the uevent and userspace repolls the modes it won't reset the mode on that
output because the status hasn't changed sufficenetly. Unknown-connected
status changes don't cause gnome to set the mode again.
Idea from Ben Skeggs to just create a fake disconnected connector, this seems
to work well, xrandr gets a bit more info that needed, but gnome seems to work
fine.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_crtc.c| 40 +
drivers/gpu/drm/drm_crtc_helper.c | 25 --
drivers/gpu/drm/drm_fb_helper.c |2 +
include/drm/drm_crtc.h|4 +++
4 files changed, 68 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 994d23b..3b880ca 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -499,6 +499,7 @@ void drm_connector_cleanup(struct drm_connector *connector)
drm_mode_object_put(dev, connector-base);
list_del(connector-head);
mutex_unlock(dev-mode_config.mutex);
+ connector-dev = NULL;
}
EXPORT_SYMBOL(drm_connector_cleanup);
@@ -1560,6 +1561,11 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
goto out;
}
+ if (out_id ==
dev-mode_config.disconnected_connector.base.id) {
+ ret = 0;
+ goto out;
+ }
+
obj = drm_mode_object_find(dev, out_id,
DRM_MODE_OBJECT_CONNECTOR);
if (!obj) {
@@ -2655,3 +2661,37 @@ out:
mutex_unlock(dev-mode_config.mutex);
return ret;
}
+
+static void drm_connector_disconnected_dpms(struct drm_connector *connector,
int mode)
+{
+ return;
+}
+
+static enum drm_connector_status drm_connector_disconnected_detect(struct
drm_connector *connector)
+{
+ return connector_status_disconnected;
+}
+
+static int drm_connector_disconnected_fill_modes(struct drm_connector
*connector, u32 max_width, u32 max_height)
+{
+ return 0;
+}
+
+static struct drm_connector_funcs drm_disconnected_funcs = {
+ .dpms = drm_connector_disconnected_dpms,
+ .detect = drm_connector_disconnected_detect,
+ .fill_modes = drm_connector_disconnected_fill_modes,
+ .destroy = drm_connector_cleanup,
+};
+
+int drm_mode_add_disconnected_connector(struct drm_device *dev)
+{
+ if (dev-mode_config.disconnected_connector.dev == NULL) {
+ drm_connector_init(dev,
dev-mode_config.disconnected_connector,
+ drm_disconnected_funcs,
+ DRM_MODE_CONNECTOR_Unknown);
+ dev-mode_config.disconnected_connector.status =
connector_status_disconnected;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(drm_mode_add_disconnected_connector);
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index ebb7a0c..665febb 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -819,11 +819,20 @@ static void output_poll_execute(struct slow_work *work)
enum drm_connector_status old_status, status;
bool repoll = false, changed = false;
int ret;
+ bool connected = false;
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)
+
+ /* skip the special disconnected connector */
+ if (dev-mode_config.disconnected_connector == connector)
+ continue;
+ /* if this is HPD or polled don't check it -
+ TV out for instance */
+ if (!connector-polled) {
+ if (connector-status == connector_status_connected)
+ connected = true;
continue;
+ }
else if (connector-polled (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT))
repoll = true;
@@ -832,8 +841,10 @@ static void output_poll_execute(struct slow_work *work)
skip it */
if (old_status == connector_status_connected
!(connector-polled DRM_CONNECTOR_POLL_DISCONNECT)
- !(connector-polled DRM_CONNECTOR_POLL_HPD))
+ !(connector-polled DRM_CONNECTOR_POLL_HPD)) {
+
[PATCH 1/2] drm/fbdev: rework output polling to be back in the core.
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.
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_display.c |1 +
drivers/gpu/drm/i915/intel_drv.h |2 +-
drivers/gpu/drm/i915/intel_fb.c| 14 ++--
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 +---
19 files changed, 177 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..ebb7a0c 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 (status == connector_status_connected)
+ connected = 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, dev-mode_config.connector_list, head) {
+ if (connector-polled)
+ poll = true;
+ }
+ slow_work_register_user(THIS_MODULE);
+ delayed_slow_work_init(dev-mode_config.output_poll_slow_work,
+ output_poll_ops);
+
+ if (poll) {
+ ret =
Re: RFC: output polling + disconnected operation
On Wed, May 5, 2010 at 11:37 AM, Jesse Barnes jbar...@virtuousgeek.org wrote: On Wed, 5 May 2010 11:12:13 +1000 Dave Airlie airl...@gmail.com 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. It's an ugly problem... When the hotplug event is received, wouldn't you re-probe and find a digital monitor attached? If so, that would mean a mode set sent in by the X server should end up being a full one since the current config is incompatible. Which means X just has to know it forced a mode, so when any event comes in it should re-set the mode unconditionally... Userspace (as in gnome/kde/xrandr) doesn't know what is attached, digital or analog, it just sees a connected status, notices it was connected before, it still connected and doesn't do anything. 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 Wed, 5 May 2010 11:12:13 +1000 Dave Airlie airl...@gmail.com 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. It's an ugly problem... When the hotplug event is received, wouldn't you re-probe and find a digital monitor attached? If so, that would mean a mode set sent in by the X server should end up being a full one since the current config is incompatible. Which means X just has to know it forced a mode, so when any event comes in it should re-set the mode unconditionally... Jesse -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
