dri-devel October 2021

dri-devel@lists.freedesktop.org

347 participants
825 discussions

[PATCH] drm/panel: ilitek-ili9881c: Avoid unbalance prepare/unprepare
by Michael Trimarchi 12 Dec '21

12 Dec '21

All the panel driver check the fact that their prepare/unprepare call was already called. It's not an ideal solution but fix for now the problem on ili9881c [ 9862.283296] ------------[ cut here ]------------ [ 9862.288490] unbalanced disables for vcc3v3_lcd [ 9862.293555] WARNING: CPU: 0 PID: 1 at drivers/regulator/core.c:2851 _regulator_disable+0xd4/0x190 from: [ 9862.038619] drm_panel_unprepare+0x2c/0x4c [ 9862.043212] panel_bridge_post_disable+0x18/0x24 [ 9862.048390] dw_mipi_dsi_bridge_post_disable+0x3c/0xf0 [ 9862.054153] drm_atomic_bridge_chain_post_disable+0x8c/0xd0 and: [ 9862.183103] drm_panel_unprepare+0x2c/0x4c [ 9862.187695] panel_bridge_post_disable+0x18/0x24 [ 9862.192872] drm_atomic_bridge_chain_post_disable+0x8c/0xd0 [ 9862.199117] disable_outputs+0x120/0x31c Signed-off-by: Michael Trimarchi <michael(a)amarulasolutions.com> --- drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c index 103a16018975..f75eecb0e65c 100644 --- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c +++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c @@ -52,6 +52,8 @@ struct ili9881c { struct regulator *power; struct gpio_desc *reset; + + bool prepared; }; #define ILI9881C_SWITCH_PAGE_INSTR(_page) \ @@ -707,6 +709,10 @@ static int ili9881c_prepare(struct drm_panel *panel) unsigned int i; int ret; + /* Preparing when already prepared is a no-op */ + if (ctx->prepared) + return 0; + /* Power the panel */ ret = regulator_enable(ctx->power); if (ret) @@ -745,6 +751,8 @@ static int ili9881c_prepare(struct drm_panel *panel) if (ret) return ret; + ctx->prepared = true; + return 0; } @@ -770,10 +778,16 @@ static int ili9881c_unprepare(struct drm_panel *panel) { struct ili9881c *ctx = panel_to_ili9881c(panel); + /* Unpreparing when already unprepared is a no-op */ + if (!ctx->prepared) + return 0; + mipi_dsi_dcs_enter_sleep_mode(ctx->dsi); regulator_disable(ctx->power); gpiod_set_value(ctx->reset, 1); + ctx->prepared = false; + return 0; } -- 2.25.1

3 6

[Bug 210787] New: amdgpu fan NA on multi gpu R9 nano
by bugzilla-daemon＠bugzilla.kernel.org 12 Dec '21

12 Dec '21

https://bugzilla.kernel.org/show_bug.cgi?id=210787 Bug ID: 210787 Summary: amdgpu fan NA on multi gpu R9 nano Product: Drivers Version: 2.5 Kernel Version: 5.9.12-5.10.1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: janpieter.sollie(a)edpnet.be Regression: No Created attachment 294229 --> https://bugzilla.kernel.org/attachment.cgi?id=294229&action=edit dmesg with manual GPU loading when running sensors, the 1st GPU fan (this GPU has the display attached) is unavailable: > amdgpu-pci-0700 > Adapter: PCI adapter > vddgfx: 900.00 mV > fan1: N/A (min = 1000 RPM, max = 4200 RPM) > edge: +23.0°C (crit = +89.0°C, hyst = -273.1°C) > power1: 10.23 W (cap = 150.00 W) > > amdgpu-pci-4300 > Adapter: PCI adapter > vddgfx: 850.00 mV > fan1: 1544 RPM (min = 1000 RPM, max = 4200 RPM) > edge: +26.0°C (crit = +89.0°C, hyst = -273.1°C) > power1: 10.08 W (cap = 150.00 W) blacklisting amdgpu did not help, but when breaking the config (specifying an invalid parameter in /etc/modprobe.d/amdgpu.conf), and loading it manually with correct parameters, it works. We're talking about a ryzen 1950x setup here with 2x r9 nano GPUs -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

1 7

[syzbot] WARNING in drm_wait_one_vblank
by syzbot 12 Dec '21

12 Dec '21

Hello, syzbot found the following issue on: HEAD commit: d2b6f8a1 Merge tag 'xfs-5.13-merge-3' of git://git.kernel... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=12c5b2c3d00000 kernel config: https://syzkaller.appspot.com/x/.config?x=65c207250bba4efe dashboard link: https://syzkaller.appspot.com/bug?extid=6f7fe2dbc479dca0ed17 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+6f7fe2dbc479dca0ed17(a)syzkaller.appspotmail.com ------------[ cut here ]------------ platform vkms: vblank wait timed out on crtc 0 WARNING: CPU: 0 PID: 11785 at drivers/gpu/drm/drm_vblank.c:1269 drm_wait_one_vblank+0x2be/0x500 drivers/gpu/drm/drm_vblank.c:1269 Modules linked in: CPU: 0 PID: 11785 Comm: syz-executor.0 Not tainted 5.12.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:drm_wait_one_vblank+0x2be/0x500 drivers/gpu/drm/drm_vblank.c:1269 Code: 85 f6 0f 84 a3 01 00 00 e8 6f f0 32 fd 4c 89 ef e8 97 68 13 00 44 89 e1 4c 89 f2 48 c7 c7 e0 eb d6 89 48 89 c6 e8 57 35 86 04 <0f> 0b e9 87 fe ff ff e8 46 f0 32 fd 31 ff 4c 89 ee e8 5c f8 32 fd RSP: 0018:ffffc90008f7fb40 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 00000000000038f8 RCX: 0000000000000000 RDX: 0000000000040000 RSI: ffffffff815c7bd5 RDI: fffff520011eff5a RBP: ffff8881437b0000 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815c1a3e R11: 0000000000000000 R12: 0000000000000000 R13: ffff88801a1c4010 R14: ffff8880161746b8 R15: ffff888142ddc830 FS: 00007f8eba6e2700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000014a53ad CR3: 0000000021583000 CR4: 00000000001506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: drm_fb_helper_ioctl+0x159/0x1a0 drivers/gpu/drm/drm_fb_helper.c:1197 do_fb_ioctl+0x1d5/0x690 drivers/video/fbdev/core/fbmem.c:1171 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1185 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:1069 [inline] __se_sys_ioctl fs/ioctl.c:1055 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:1055 do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x4665f9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f8eba6e2188 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000000000056bf60 RCX: 00000000004665f9 RDX: 0000000000000000 RSI: 0000000040044620 RDI: 0000000000000006 RBP: 00000000004bfce1 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056bf60 R13: 0000000000a9fb1f R14: 00007f8eba6e2300 R15: 0000000000022000 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

1 1

[PATCH v7 0/3] force hsa hbp hfp packets multiple of lanenum to avoid screen shift
by Jitao Shi 10 Dec '21

10 Dec '21

Changes since v6: - Add "bool hs_packet_end_aligned" in "struct mipi_dsi_device" to control the dsi aligned. - Config the "hs_packet_end_aligned" in ANX7725 .attach(). Changes since v5: - Search the anx7625 compatible as flag to control dsi output aligned. Changes since v4: - Move "dt-bindings: drm/bridge: anx7625: add force_dsi_end_without_null" before "drm/mediatek: force hsa hbp hfp packets multiple of lanenum to avoid". - Retitle "dt-bindings: drm/bridge: anx7625: add force_dsi_end_without_null". Jitao Shi (3): drm/dsi: transer dsi hs packet aligned drm/mediatek: implment the dsi hs packets aligned drm/bridge: anx7625: config hs packets end aligned to avoid screen shift drivers/gpu/drm/bridge/analogix/anx7625.c | 1 + drivers/gpu/drm/mediatek/mtk_dsi.c | 10 ++++++++++ include/drm/drm_mipi_dsi.h | 2 ++ 3 files changed, 13 insertions(+) -- 2.25.1

4 10

[PATCH 00/10] drm: Add privacy-screen class and connector properties
by Hans de Goede 10 Dec '21

10 Dec '21

Hi all, Here is a new version of my privacy-screen series, addressing the review-remark from Ville on patch 10/10 from the version posted on October 2nd. This new version contains the following changes: - drm/i915: Add privacy-screen support (v3) - Move drm_privacy_screen_get() call to intel_ddi_init_dp_connector() Ville, can you (re)review "[PATCH 10/10] drm/i915: Add privacy-screen support (v3)" please ? For anyone just tuning in, here is some more info from the previous cover-letters: The first userspace consumer of the new properties is now fully ready for merging (it is just waiting for the kernel bits to land first): - https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/49 - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952 - https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1032 The new API works as designed and add the following features to GNOME: 1. Showing an OSD notification when the privacy-screen is toggled on/off through hotkeys handled by the embedded-controller 2. Allowing control of the privacy-screen from the GNOME control-panel, including the on/off slider shown there updating to match the hw-setting when the setting is changed with the control-panel open. 3. Restoring the last user-setting at login This series consists of a number of different parts: 1. A new version of Rajat's privacy-screen connector properties patch, this adds new userspace API in the form of new properties 2. Since on most devices the privacy screen is actually controlled by some vendor specific ACPI/WMI interface which has a driver under drivers/platform/x86, we need some "glue" code to make this functionality available to KMS drivers. Patches 2-4 add a new privacy-screen class for this, which allows non KMS drivers (and possibly KMS drivers too) to register a privacy-screen device and also adds an interface for KMS drivers to get access to the privacy-screen associated with a specific connector. This is modelled similar to how we deal with e.g. PWMs and GPIOs in the kernel, including separate includes for consumers and providers(drivers). 3. Some drm_connector helper functions to keep the actual changes needed for this in individual KMS drivers as small as possible (patch 5). 4. Make the thinkpad_acpi code register a privacy-screen device on ThinkPads with a privacy-screen (patches 6-8) 5. Make the i915 driver export the privacy-screen functionality through the connector properties on the eDP connector. I believe that it would be best to merge the entire series, including the thinkpad_acpi changes through drm-misc in one go. As the pdx86 subsys maintainer I hereby give my ack for merging the thinkpad_acpi changes through drm-misc. There is one small caveat with this series, which it is good to be aware of. The i915 driver will now return -EPROBE_DEFER on Thinkpads with an eprivacy screen, until the thinkpad_acpi driver is loaded. This means that initrd generation tools will need to be updated to include thinkpad_acpi when the i915 driver is added to the initrd. Without this the loading of the i915 driver will be delayed to after the switch to real rootfs. Regards, Hans Hans de Goede (9): drm: Add privacy-screen class (v4) drm/privacy-screen: Add X86 specific arch init code drm/privacy-screen: Add notifier support (v2) drm/connector: Add a drm_connector privacy-screen helper functions (v2) platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey() helper platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI handles only once platform/x86: thinkpad_acpi: Register a privacy-screen device drm/i915: Add intel_modeset_probe_defer() helper drm/i915: Add privacy-screen support (v3) Rajat Jain (1): drm/connector: Add support for privacy-screen properties (v4) Documentation/gpu/drm-kms-helpers.rst | 15 + Documentation/gpu/drm-kms.rst | 2 + MAINTAINERS | 8 + drivers/gpu/drm/Kconfig | 4 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_atomic_uapi.c | 4 + drivers/gpu/drm/drm_connector.c | 203 ++++++++ drivers/gpu/drm/drm_drv.c | 4 + drivers/gpu/drm/drm_privacy_screen.c | 467 +++++++++++++++++++ drivers/gpu/drm/drm_privacy_screen_x86.c | 86 ++++ drivers/gpu/drm/i915/display/intel_atomic.c | 1 + drivers/gpu/drm/i915/display/intel_ddi.c | 15 + drivers/gpu/drm/i915/display/intel_display.c | 23 + drivers/gpu/drm/i915/display/intel_display.h | 1 + drivers/gpu/drm/i915/i915_pci.c | 9 +- drivers/platform/x86/Kconfig | 2 + drivers/platform/x86/thinkpad_acpi.c | 137 ++++-- include/drm/drm_connector.h | 55 +++ include/drm/drm_privacy_screen_consumer.h | 65 +++ include/drm/drm_privacy_screen_driver.h | 84 ++++ include/drm/drm_privacy_screen_machine.h | 46 ++ 21 files changed, 1183 insertions(+), 49 deletions(-) create mode 100644 drivers/gpu/drm/drm_privacy_screen.c create mode 100644 drivers/gpu/drm/drm_privacy_screen_x86.c create mode 100644 include/drm/drm_privacy_screen_consumer.h create mode 100644 include/drm/drm_privacy_screen_driver.h create mode 100644 include/drm/drm_privacy_screen_machine.h -- 2.31.1

4 22

[PATCH v2] Revert "drm/fb-helper: improve DRM fbdev emulation device names"
by Javier Martinez Canillas 09 Dec '21

09 Dec '21

This reverts commit b3484d2b03e4c940a9598aa841a52d69729c582a. That change attempted to improve the DRM drivers fbdev emulation device names to avoid having confusing names like "simpledrmdrmfb" in /proc/fb. But unfortunately, there are user-space programs such as pm-utils that match against the fbdev names and so broke after the mentioned commit. Since the names in /proc/fb are used by tools that consider it an uAPI, let's restore the old names even when this lead to silly names like the one mentioned above. Fixes: b3484d2b03e4 ("drm/fb-helper: improve DRM fbdev emulation device names") Reported-by: Johannes Stezenbach <js(a)sig21.net> Signed-off-by: Javier Martinez Canillas <javierm(a)redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- Changes in v2: - Add a comment explaining that the current /proc/fb names are an uAPI. - Add a Fixes: tag so it can be cherry-picked by stable kernels. - Add Ville Syrjälä's Reviewed-by tag. drivers/gpu/drm/drm_fb_helper.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 8e7a124d6c5a..22bf690910b2 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -1743,7 +1743,13 @@ void drm_fb_helper_fill_info(struct fb_info *info, sizes->fb_width, sizes->fb_height); info->par = fb_helper; - snprintf(info->fix.id, sizeof(info->fix.id), "%s", + /* + * The DRM drivers fbdev emulation device name can be confusing if the + * driver name also has a "drm" suffix on it. Leading to names such as + * "simpledrmdrmfb" in /proc/fb. Unfortunately, it's an uAPI and can't + * be changed due user-space tools (e.g: pm-utils) matching against it. + */ + snprintf(info->fix.id, sizeof(info->fix.id), "%sdrmfb", fb_helper->dev->driver->name); } -- 2.31.1

2 2

[BUG] gpu: drm: amd: amdgpu: possible ABBA deadlock in amdgpu_set_power_dpm_force_performance_level() and amdgpu_debugfs_process_reg_op()
by Jia-Ju Bai 09 Dec '21

09 Dec '21

Hello, My static analysis tool reports a possible ABBA deadlock in the amdgpu driver in Linux 5.10: amdgpu_debugfs_process_reg_op() mutex_lock(&adev->grbm_idx_mutex); --> Line 250 (Lock A) mutex_lock(&adev->pm.mutex); --> Line 259 (Lock B) amdgpu_set_power_dpm_force_performance_level() mutex_lock(&adev->pm.mutex); --> Line 381 (Lock B) pp_dpm_force_performance_level() --> function pointer via "amdgpu_dpm_force_performance_level()" pp_dpm_en_umd_pstate() amdgpu_device_ip_set_clockgating_state() gfx_v7_0_set_clockgating_state() --> function pointer via "funcs->set_clockgating_state()" gfx_v7_0_enable_mgcg() mutex_lock(&adev->grbm_idx_mutex); --> Line 3646 (Lock A) mutex_lock(&adev->grbm_idx_mutex); --> Line 3697 (Lock A) When amdgpu_debugfs_process_reg_op() and amdgpu_set_power_dpm_force_performance_level() are concurrently executed, the deadlock can occur. I am not quite sure whether this possible deadlock is real and how to fix it if it is real. Any feedback would be appreciated, thanks :) Reported-by: TOTE Robot <oslab(a)tsinghua.edu.cn> Best wishes, Jia-Ju Bai

1 1

[PATCH] drm/msm/dp: Move debugfs files into subdirectory
by Bjorn Andersson 08 Dec '21

08 Dec '21

In the cleanup path of the MSM DP driver the DP driver's debugfs files are destroyed by invoking debugfs_remove_recursive() on debug->root, which during initialization has been set to minor->debugfs_root. To allow cleaning up the DP driver's debugfs files either each dentry needs to be kept track of or the files needs to be put in a subdirectory which can be removed in one go. By choosing to put the debugfs files in a subdirectory, based on the name of the associated connector this also solves the problem that these names would collide as support for multiple DP instances are introduced. One alternative solution to the problem with colliding file names would have been to put keep track of the individual files and put them under the connector's debugfs directory. But while the drm_connector has been allocated, its associated debugfs directory has not been created at the time of initialization of the dp_debug. Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> --- This depends on https://lore.kernel.org/linux-arm-msm/20211010030435.4000642-1-bjorn.anders… reducing the connector from a double pointer. drivers/gpu/drm/msm/dp/dp_debug.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/msm/dp/dp_debug.c b/drivers/gpu/drm/msm/dp/dp_debug.c index da4323556ef3..67da4c69eca1 100644 --- a/drivers/gpu/drm/msm/dp/dp_debug.c +++ b/drivers/gpu/drm/msm/dp/dp_debug.c @@ -210,26 +210,29 @@ static const struct file_operations test_active_fops = { static int dp_debug_init(struct dp_debug *dp_debug, struct drm_minor *minor) { int rc = 0; + char path[64]; struct dp_debug_private *debug = container_of(dp_debug, struct dp_debug_private, dp_debug); - debugfs_create_file("dp_debug", 0444, minor->debugfs_root, + snprintf(path, sizeof(path), "msm_dp-%s", debug->connector->name); + + debug->root = debugfs_create_dir(path, minor->debugfs_root); + + debugfs_create_file("dp_debug", 0444, debug->root, debug, &dp_debug_fops); debugfs_create_file("msm_dp_test_active", 0444, - minor->debugfs_root, + debug->root, debug, &test_active_fops); debugfs_create_file("msm_dp_test_data", 0444, - minor->debugfs_root, + debug->root, debug, &dp_test_data_fops); debugfs_create_file("msm_dp_test_type", 0444, - minor->debugfs_root, + debug->root, debug, &dp_test_type_fops); - debug->root = minor->debugfs_root; - return rc; } -- 2.29.2

2 5

[Bug 205185] New: amdgpu compile failure
by bugzilla-daemon＠bugzilla.kernel.org 08 Dec '21

08 Dec '21

https://bugzilla.kernel.org/show_bug.cgi?id=205185 Bug ID: 205185 Summary: amdgpu compile failure Product: Drivers Version: 2.5 Kernel Version: 5.3.5 - 5.3.6 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: stijn+bugs(a)linux-ipv6.be Regression: No 5.3.5 and 5.3.6 do not compile: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_dpp.c: In function ‘dpp2_cnv_setup’: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_dpp.c:94:30: note: byref variable will be forcibly initialized struct out_csc_color_matrix tbl_entry; ^~~~~~~~~ CC [M] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hubbub.o drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c: In function ‘dcn20_init_hw’: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c:589:37: error: ‘const struct resource_caps’ has no member named ‘num_dsc’; did you mean ‘num_ddc’? for (i = 0; i < res_pool->res_cap->num_dsc; i++) ^~~~~~~ num_ddc drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c:590:3: error: implicit declaration of function ‘dcn20_dsc_pg_control’; did you mean ‘dcn20_dpp_pg_control’? [-Werror=implicit-function-declaration] dcn20_dsc_pg_control(hws, res_pool->dscs[i]->inst, false); ^~~~~~~~~~~~~~~~~~~~ dcn20_dpp_pg_control drivers/gpu/drm/amd/amdgpu/../display/dc/dcn20/dcn20_hwseq.c:590:39: error: ‘struct resource_pool’ has no member named ‘dscs’; did you mean ‘dpps’? dcn20_dsc_pg_control(hws, res_pool->dscs[i]->inst, false); ^~~~ dpps -- You are receiving this mail because: You are watching the assignee of the bug.

1 4

[Bug 53391] New: nouveau: wrong display output order
by bugzilla-daemon＠bugzilla.kernel.org 08 Dec '21

08 Dec '21

https://bugzilla.kernel.org/show_bug.cgi?id=53391 Summary: nouveau: wrong display output order Product: Drivers Version: 2.5 Kernel Version: 3.8-rc6 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: stijn+bugs(a)linux-ipv6.be Regression: No My graphics card is a Gainward GTX480 (http://www.gainward.com/main/vgapro.php?id=238). It has 2 DVI outputs, and 1 mini HDMI output. The DVI outputs are numbered on the card, with DVI 1 being the closest to the PCIe slot, then DVI 2, and finally the mini HDMI. My primary (left) monitor, is connected to DVI 1, my secondary (right) monitor to DVI 2. When I boot the computer, the BIOS initializes and uses the monitor on DVI 1. Grub is displayed on the primary monitor, and the kernel initially outputs to the primary monitor as well. However, as soon as the nouveau module is loaded, the primary monitor goes to standby and the kernel now uses the secondary monitor (on DVI 2) as primary. When X starts (no Xorg.conf file), it is also displayed on the secondary monitor. When using either efifb, vesafb or uvesafb, the monitor on DVI 1 is always the primary monitor. X with nvidia.ko also uses DVI 1 as the primary display. Finally, when booting Windows, the startup screen is also displayed on the monitor connected to DVI 1. Here comes the weird part: when I am in X, and run xrandr, it does show 3 connected devices: DVI-I-1, DVI-I-2, and HDMI-1, with DVI-I-2 being the only active one. So it seems that in X, the output order is correct, but with nouveaufb the DVI connectors are swapped. I will attach the output of dmesg here. If anything else is needed, please let me know and I'll be happy to add it. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 13

← Newer
1
...
6
7
8
9
10
11
12
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2021