xserver issueshttps://gitlab.freedesktop.org/xorg/xserver/-/issues2022-10-16T00:10:48Zhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/99modesetting doesn't fall back to shm if glamor_init() fails2022-10-16T00:10:48ZBugzilla Migration Usermodesetting doesn't fall back to shm if glamor_init() fails## Submitted by Javier
Assigned to **Xorg Project Team**
**[Link to original bug (#98605)](https://bugs.freedesktop.org/show_bug.cgi?id=98605)**
## Description
Created attachment 127794
Xorg log with glamor warning and server erro...## Submitted by Javier
Assigned to **Xorg Project Team**
**[Link to original bug (#98605)](https://bugs.freedesktop.org/show_bug.cgi?id=98605)**
## Description
Created attachment 127794
Xorg log with glamor warning and server error
On a Toshiba NB505 I have no problem when using the "xf86-video-intel" driver. However when trying to use the "modesetting" driver now embedded into the Xorg server I get:
[ 26.287] (WW) glamor requires at least 128 instructions (64 reported)
[ 26.287] (EE) modeset(0): Failed to initialize glamor at ScreenInit() time.
[ 26.287] (EE)
Fatal server error:
[ 26.287] (EE) AddScreen/ScreenInit failed for driver 0
[ 26.287] (EE)
[ 26.287] (EE)
I'm using the "i915" linux gpu driver, while lspci shows:
VGA compatible controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller
And according to the specs under:
https://www.cnet.com/products/toshiba-nb505-n500bl-10-1-atom-n455-1-gb-ram-250-gb-hdd-us/specs
Then:
CPU Intel Atom N455 / 1.66 GHz
...
Graphics Processor Intel GMA 3150
Sounds like a bug in the glamor acceleration...
**Attachment 127794**, "Xorg log with glamor warning and server error":
[Xorg.0.log](/uploads/dc3b33ec7aeb20986230eccae8006096/Xorg.0.log)https://gitlab.freedesktop.org/xorg/xserver/-/issues/74X modesetting problem on dell laptop2018-12-17T17:42:00ZBugzilla Migration UserX modesetting problem on dell laptop## Submitted by Klaus Kusche
Assigned to **Xorg Project Team**
**[Link to original bug (#98145)](https://bugs.freedesktop.org/show_bug.cgi?id=98145)**
## Description
When I returned to our university after my summer holidays,
I no...## Submitted by Klaus Kusche
Assigned to **Xorg Project Team**
**[Link to original bug (#98145)](https://bugs.freedesktop.org/show_bug.cgi?id=98145)**
## Description
When I returned to our university after my summer holidays,
I noticed that all our VGA beamers in the lecture halls no longer
synced to my laptop (they did with no problem several months ago).
In detail:
* All the beamers are 1024x768@60, no more.
Some of them send broken EDID data,
some of them do not send EDID at all
(I'm not sure if any beamer sends valid EDID data).
Doesn't make any visible difference for my problem.
* The linux kernel configures them correctly in framebuffer text mode.
* After starting X, they are out of sync.
* Setting the VGA mode with xrandr takes 10-20 seconds
(laptop completely blocked) and results in the wrong mode:
No matter if I specify the mode as 1024x768, or as 1024x768 at 60,
or by hex (0x59), or if I define my own 1024x768@60 mode and use that
(as I did for the log files attached: Added a VESA-compatible 1024x768 mode
and set the VGA output to that),
in most cases the VGA output is (again?) set to a 1024x768 @ 120 mode
(hex 0x58, 1024x768 @ 60 double scan, detected by the beamers as
2048x1536 or 1024x768@120, not syncable), and in rare cases it is set
to some seemingly random mode (also too fast for the beamers).
* Turning the VGA output off with xrandr and setting it again
in many cases results in the correct 1024x768@60 after many seconds,
the beamers sync.
Sometimes, this results in the same unuseable 1024x768 doublescan mode
as before.
Strange observations:
* The evil 0x58 double scan mode cannot be removed from the VGA output
or the mode table by xrandr. It seems to be hardcoded
(and it seems to be a valid mode for the builtin laptop display).
* In some rare cases, xrandr --verbose shows the output in the desired
0x59 mode (1024x768@60), but the VGA output is actually still running
at 0x58 1024x768 doublescan
(i.e. what xrandr thinks is not what the hardware does)!
* Even setting the VGA output to 1024x768@60 the hard way
(using a "video" kernel boot parameter) does not keep X
from setting it to 1024x768 double scan.
Hardware and software:
* Dell precision M6700 laptop with ATI "cap verde" graphics:
[drm] initializing kernel modesetting (VERDE 0x1002:0x6825 0x1028:0x053F 0x00)
Of course, dell configures it as a professional "fire" graphics card...
* Recent Dell BIOS, which causes an error message in the kernel:
radeon 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xffff
ATOM BIOS: Heathrow
Tried several BIOS versions, reflashed several times, error persists.
* Gentoo linux, locally compiled kernel, up to date (currently 4.7.6),
up-to-date radeon microcode (loads without errors).
* Kernel modesetting & drm, X started after login
in existing framebuffer vt and login session (not opening a new vt),
in non-root (non-suid) mode.
* Xorg server version 1.18.4, running builtin modesetting driver
( *not* radeon driver, but the last time I tried the radeon driver
some months ago, modesetting behaviour was identical in both drivers).
Problems (I think these are really two distinct and independent problems?!):
1.) Where does that evil 0x58 1024x768 doublescan mode
listed by xrandr as a valid mode for the VGA output (!) come from?
(definitely not from any beamer's EDID !)
And why does X choose that mode as the default mode for VGA on startup?
Especially if the beamer is not sending EDID (or a broken EDID),
1024x768@120 is *not* a reasonable default VGA mode
(by far too fast for all common VGA devices)!
The kernel knows that 1024x768@60 is the mode to use
and sets it correctly without even trying 1024x768@120.
Why is X pretending to know better than the kernel?
There is a correct builtin 1024x768@60 mode listed in xrandr,
it should be used by default at startup
(especially if the kernel was started with video=VGA-1:1024x768M@60 !)
And why is the hardware set to this mode 0x58 by xrandr
even if a completely different 1024x768 mode (0x59 or user-defined)
is specified in xrandr?
(and why does the mode shown in xrandr in rare cases not correspond
to the mode the hardware uses)?
2.) Why is any mode change taking ages (many seconds),
with the laptop being blocked and the displays (both internal
and external) being all black or randomly flashing or out of sync
or showing only part of the screen?
There are some ATOMbios errors related to that (see dmesg),
but I think only for xrandr mode changes.
As for as I can tell, there are no errors for the initial modeset.
Unfortunately, I can't bisect.
Last known good is not known and at least 6-12 months in the past,
and I use Gentoo (rolling upgrades) and update every week...
I'll attach Xorg.log and dmesg.https://gitlab.freedesktop.org/xorg/xserver/-/issues/63Brightness change not supported by modesetting2018-12-17T17:41:59ZBugzilla Migration UserBrightness change not supported by modesetting## Submitted by nic..@..us.org
Assigned to **Xorg Project Team**
**[Link to original bug (#97452)](https://bugs.freedesktop.org/show_bug.cgi?id=97452)**
## Description
Hello,
using modesetting with the intel HD5500 results in bac...## Submitted by nic..@..us.org
Assigned to **Xorg Project Team**
**[Link to original bug (#97452)](https://bugs.freedesktop.org/show_bug.cgi?id=97452)**
## Description
Hello,
using modesetting with the intel HD5500 results in backlight properties not being accessible:
[18:12] wurzel:~% xbacklight -set 20
No outputs have backlight property
Even though they are present and also picked up by the intel driver:
[18:12] wurzel:~% cat /sys/class/backlight/intel_backlight/brightness
511
It would be awesome if the modesetting driver was supporting this, as it's the only drawback of it compared to the intel driver (which is horribly slow).https://gitlab.freedesktop.org/xorg/xserver/-/issues/35External screen turns off randomly2018-12-17T17:41:57ZBugzilla Migration UserExternal screen turns off randomly## Submitted by nic..@..us.org
Assigned to **Xorg Project Team**
**[Link to original bug (#97436)](https://bugs.freedesktop.org/show_bug.cgi?id=97436)**
## Description
Created attachment 125941
xorg logfile
I've just changed from...## Submitted by nic..@..us.org
Assigned to **Xorg Project Team**
**[Link to original bug (#97436)](https://bugs.freedesktop.org/show_bug.cgi?id=97436)**
## Description
Created attachment 125941
xorg logfile
I've just changed from xf86-video-intel to modesetting, as the intel driver (especially with SNA) is extremly slow.
The modesetting is *much* faster (2-4 times in rendering windows) especially with bigger screens (2560x1440 + 3840x2160).
However there is one bug with modesetting: the external monitor (3840x2160) turns off / blanks frequently for about 1-2 seconds and then comes back instantly.
This has never happened with xf86-video-intel.
Attached is the Xorg.0.log - let me know if you need more information about my system.
It's btw. very impressive how fast modesetting (or how slow the intel driver) is!
**Attachment 125941**, "xorg logfile":
[Xorg.0.log](/uploads/d0b8101dc3a31c52fd867d6efef93dbc/Xorg.0.log)https://gitlab.freedesktop.org/xorg/xserver/-/issues/53amdgpu: crash when PCI rescan discovers new card2018-12-17T17:41:59ZBugzilla Migration Useramdgpu: crash when PCI rescan discovers new card## Submitted by jim..@..il.com
Assigned to **Xorg Project Team**
**[Link to original bug (#97313)](https://bugs.freedesktop.org/show_bug.cgi?id=97313)**
## Description
This is semi-related to another bug: https://bugzilla.kernel.o...## Submitted by jim..@..il.com
Assigned to **Xorg Project Team**
**[Link to original bug (#97313)](https://bugs.freedesktop.org/show_bug.cgi?id=97313)**
## Description
This is semi-related to another bug: https://bugzilla.kernel.org/show_bug.cgi?id=150731
And by semi, I mean it's either completely related or completely not related, and I don't know which yet.
If I boot my computer with my AMD video card bound to a driver besides amdgpu (like vfio-pci for my Windows virtual machine), then unbind it from that driver, intending to bind to to amdgpu for Linux gaming...
EXPECTED BEHAVIOR: I can unbind, remove the card, rescan (echo 1 > /sys/bus/pci/rescan), then bind the card to amdgpu, using DRI3 and the DRI_PRIME variable for games. This is a process that some successfully do with the radeon driver on older AMD cards.
ACTUAL BEHAVIOR: At the moment that I rescan (echo 1 > /sys/bus/pci/rescan), X crashes and restarts, booting me back to the login screen, and something (I guess either the kernel or X) has automatically bound the card to amdgpu on its own, without me entering those echo commands (echo "`<card's vendor ID>`" "`<card's device ID>`" > /sys/bus/pci/drivers/amdgpu/new_id) to bind it.
DESIRED BEHAVIOR: I can get my card bound to amdgpu, whether it's automatic or by my own typed bind commands, WITHOUT a boot-me-to-login-screen X crash.
The X crash log is at https://bugzilla.kernel.org/attachment.cgi?id=228411
The crash, starting at [456.336], has no errors. It seems to be just reconfiguring the graphics because it noticed a new available card, and somehow that resulted in me being booted back to the login screen.
The log that was made after the crash, when I logged back in, is at https://bugzilla.kernel.org/attachment.cgi?id=228421https://gitlab.freedesktop.org/xorg/xserver/-/issues/179Support intel-virtual-output with modesetting2019-12-15T22:24:48ZBugzilla Migration UserSupport intel-virtual-output with modesetting## Submitted by mai..@..il.com
Assigned to **Xorg Project Team**
**[Link to original bug (#97186)](https://bugs.freedesktop.org/show_bug.cgi?id=97186)**
## Description
Many laptops come with Intel graphics and a dedicated GPU that...## Submitted by mai..@..il.com
Assigned to **Xorg Project Team**
**[Link to original bug (#97186)](https://bugs.freedesktop.org/show_bug.cgi?id=97186)**
## Description
Many laptops come with Intel graphics and a dedicated GPU that can be switched on on-demand. It's called Optimus. Some laptop makers wire the Displayport, HDMI, etc outputs to the dGPU. As a result, the dGPU needs to be running to use these outputs.
The only way to make Optimus work dynamically on non-Windows OS is to use Bumblebee. With it, X runs on the Intel GPU, and the tool switches on the dGPU and starts a separate X server with the nvidia driver when necessary, then transfers images back to the Intel X server
Displays hooked up to the dGPU's outputs result a sort of reversed situation. xf86-video-intel provides the intel-virtual-output tool, which acts as a display proxy between the X servers and transfers video data to the nvidia X server.
i-v-o won't work when modesetting is used instead of xf86-video-intel. The first problem I ran into is that modesetting does not provide and VIRTUAL outputs like the intel driver does. Can these be added somehow?https://gitlab.freedesktop.org/xorg/xserver/-/issues/26Modesetting driver rejects modes with vertical refresh above 602022-08-25T15:55:28ZBugzilla Migration UserModesetting driver rejects modes with vertical refresh above 60## Submitted by roc..@..il.com
Assigned to **Xorg Project Team**
**[Link to original bug (#97163)](https://bugs.freedesktop.org/show_bug.cgi?id=97163)**
## Description
I'm using the modesetting driver in xserver 1.18.4 (1.18.4-1ub...## Submitted by roc..@..il.com
Assigned to **Xorg Project Team**
**[Link to original bug (#97163)](https://bugs.freedesktop.org/show_bug.cgi?id=97163)**
## Description
I'm using the modesetting driver in xserver 1.18.4 (1.18.4-1ubuntu4 on Ubuntu 16.10).
For my 4K screen, the driver is rejecting any modelines with vertical refresh above 60, so for instance 2560x1440 is not shown by the modesetting driver, but I can use it with the intel driver.
The reason the modes are rejected is because hw/xfree86/drivers/modesetting/drmmode_display.c#add_gtf_modes() hard-codes the max vertical refresh to 60 + 1%, and since it calculates frequencies of 65 to 85 for the missing modes, it flags them as invalid so later they get pruned. However, my laptop monitor can handle between 56.25 to 120 according to its MonPtr structure, so I think they shouldn't be flagged as invalid.
Would a solution be to have hw/xfree86/drivers/modesetting#get_modes() pass the monitor info (it reads it in already just before the call to add_gtf_modes) and have add_gtf_modes() use the actual monitor maximum refresh? This is what hw/xfree86/modes/xf86Modes.c#xf86ValidateModesSync() appears to do, but it isn't actually passed anything to check in this case.
See also https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1606103 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832432#15.
Version: githttps://gitlab.freedesktop.org/xorg/xserver/-/issues/503XQueryBestCursor returns 0,0 (Tegra K1 and others)2019-05-09T20:20:25ZBugzilla Migration UserXQueryBestCursor returns 0,0 (Tegra K1 and others)## Submitted by Christoph Haag
Assigned to **Xorg Project Team**
**[Link to original bug (#97105)](https://bugs.freedesktop.org/show_bug.cgi?id=97105)**
## Description
This is a similar bug report to https://bugs.launchpad.net/uni...## Submitted by Christoph Haag
Assigned to **Xorg Project Team**
**[Link to original bug (#97105)](https://bugs.freedesktop.org/show_bug.cgi?id=97105)**
## Description
This is a similar bug report to https://bugs.launchpad.net/unity-mir/+bug/1250613
That one was for xmir, but I am using X with modesetting + hacked in glamor/nouveau support and I am experiencing the very same problem.
I first thought it was a problem with this setup and reported it there:
https://github.com/Gnurou/xserver/issues/1
For the used hacks, just look at the latest 4 commits in this repository.
As I described over there, I looked a little bit at the modesetting initialization and it calls xf86_cursors_init and sets the cursor size to 64x64. But these values get lost somewhere in X or Xlib and XQueryBestCursor returns 0x0 for the cursor size. As a workaround I am currently using a workaround library that sets these values to 32x32, code is in that bug report too.
As further argument that this is an issue somewhere: Matrox graphics with KMS:
https://forums.opensuse.org/showthread.php/489277-java-problems-with-opensuse-12-3https://gitlab.freedesktop.org/xorg/xserver/-/issues/47xbacklight doesn't work with modesetting on intel2023-11-26T16:14:04ZBugzilla Migration Userxbacklight doesn't work with modesetting on intel## Submitted by Vincent Bernat
Assigned to **Xorg Project Team**
**[Link to original bug (#96572)](https://bugs.freedesktop.org/show_bug.cgi?id=96572)**
## Description
Created attachment 124584
xorg.log
Hey!
After switching from...## Submitted by Vincent Bernat
Assigned to **Xorg Project Team**
**[Link to original bug (#96572)](https://bugs.freedesktop.org/show_bug.cgi?id=96572)**
## Description
Created attachment 124584
xorg.log
Hey!
After switching from intel to modesetting, xbacklight doesn't work anymore:
$ xbacklight = 20
No outputs have backlight property
However, a backlight control is present in sysfs:
/sys/class/backlight/intel_backlight
In Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824987
**Attachment 124584**, "xorg.log":
[Xorg.0.log](/uploads/05a0f6a5c6bc905b26826820d7d69559/Xorg.0.log)https://gitlab.freedesktop.org/xorg/xserver/-/issues/30[intel HD Graphics 4000] modesetting_drv renders multiple mouse pointers2018-12-17T17:41:57ZBugzilla Migration User[intel HD Graphics 4000] modesetting_drv renders multiple mouse pointers## Submitted by Jiri Slaby
Assigned to **Xorg Project Team**
**[Link to original bug (#94988)](https://bugs.freedesktop.org/show_bug.cgi?id=94988)**
## Description
Created attachment 123025
xorg log for modesetting_drv
I tried to...## Submitted by Jiri Slaby
Assigned to **Xorg Project Team**
**[Link to original bug (#94988)](https://bugs.freedesktop.org/show_bug.cgi?id=94988)**
## Description
Created attachment 123025
xorg log for modesetting_drv
I tried to switch from intel_drv to modesetting_drv, but it does not work well.
My adapter:
00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller])
Subsystem: Lenovo Device [17aa:21fa]
Flags: bus master, fast devsel, latency 0, IRQ 29
Memory at f0000000 (64-bit, non-prefetchable) [size=4M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
I/O ports at 5000 [size=64]
Expansion ROM at `<unassigned>` [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features
Kernel driver in use: i915
Kernel modules: i915
My kernel:
Linux anemoi 4.5.1-1.gf5f7dfc-default #1 SMP PREEMPT Wed Apr 13 14:25:59 UTC 2016 (f5f7dfc) x86_64 x86_64 x86_64 GNU/Linux
I see many copies of mouse pointers, screen flickering etc. This is with plasma 5, compositing enabled, running on OpenGL. With XRender, it does not show the artefacts that often. Without compositing, it is still unusable as plasmashell starts looping on one CPU and stops reacting on user input eventually. It spins on calling drm_ioctl_wait_vblank ioctl repeatedly.
**Attachment 123025**, "xorg log for modesetting_drv":
[Xorg.0.log.old](/uploads/6650c8b1fbf7913457f8dc399f10f6fb/Xorg.0.log.old)
Version: githttps://gitlab.freedesktop.org/xorg/xserver/-/issues/23Fix null pointer in FreeRec()2022-08-25T15:55:27ZBugzilla Migration UserFix null pointer in FreeRec()## Submitted by Thomas Meyer
Assigned to **Xorg Project Team**
**[Link to original bug (#93779)](https://bugs.freedesktop.org/show_bug.cgi?id=93779)**
## Description
There seem to be a bug in the modesetting driver:
(gdb) p (mode...## Submitted by Thomas Meyer
Assigned to **Xorg Project Team**
**[Link to original bug (#93779)](https://bugs.freedesktop.org/show_bug.cgi?id=93779)**
## Description
There seem to be a bug in the modesetting driver:
(gdb) p (modesettingPtr)((scrn)->driverPrivate)
$6 = (struct _modesettingRec *) 0x0
driverPrivate is NULL. It is set to NULL in FreeRec function:
625│ return;
626│-> pScrn->driverPrivate = NULL;
627│
628│ if (ms->fd > 0) {
629│ modesettingEntPtr ms_ent;
630│ int ret;
631│
632├> ms_ent = ms_ent_priv(pScrn);
633│ ms_ent->fd_ref--;
634│ if (!ms_ent->fd_ref) {
635│ if (ms->pEnt->location.type == BUS_PCI)
636│ ret = drmClose(ms->fd);
637│ else
638│ #ifdef XF86_PDEV_SERVER_FD
639│ if (!(ms->pEnt->location.type == BUS_PLATFORM &&
/usr/src/debug/xorg-server-1.18.0/hw/xfree86/drivers/modesetting/driver.c
line 626 clears the pointer and in line 632 it's used later on again by ms_ent_priv().
See also https://bugzilla.redhat.com/show_bug.cgi?id=1273183
Version: githttps://gitlab.freedesktop.org/xorg/xserver/-/issues/38AMD Pitcairn (7870) video issues (Chrome+Netflix) playback on 2 monitor desktop2018-12-17T17:41:58ZBugzilla Migration UserAMD Pitcairn (7870) video issues (Chrome+Netflix) playback on 2 monitor desktop## Submitted by Mike
Assigned to **Xorg Project Team**
**[Link to original bug (#93277)](https://bugs.freedesktop.org/show_bug.cgi?id=93277)**
## Description
git sources from Dec04 on: Mesa, Xorg-server, xf86-video-ati; using -999...## Submitted by Mike
Assigned to **Xorg Project Team**
**[Link to original bug (#93277)](https://bugs.freedesktop.org/show_bug.cgi?id=93277)**
## Description
git sources from Dec04 on: Mesa, Xorg-server, xf86-video-ati; using -9999 packages from x11 and ixit(mesa) gentoo overlays on Sabayon.
DRI3 enabled, Modesetting DDX, acceleration glamor
Desktop compositing enabled; kwin5; vsync with 'full screen redraw'. I found no difference in other modes.
Hardware Acceleration enabled in chrome by default; disabling causes 2d tearing in all aspects of chrome use regardless, and massive cpu usage for h264 decoding as expected.
3d rendering works well, on-par performancewise with radeon ddx in DRI3
2d rendering works well, similarly on-par.
Video playback with Netflix however, starts off a chain of events ending in a very weird effect of historical frame skipping back about a second, then skipping forward again.
Playback on primary display works well, for a time. Dragging window via alt-mouse to the other display immediately starts a stuttering effect felt xserver wide.
The video playback drops to perhaps 1 frame every 3-4 seconds; at the point that the frame updates, a 'back in time' aspect was realized in kwin to repaint instances of every x-client window occurring 1-3 seconds in the past.
Typing in hexchat for example would be a series of:
start typing and entering text at about 50wpm.
see 14 characters vanish
see no updates for a second
see new text, typing normally for a short while
see last 10 chars vanish, at a newer point in time than the last vanishing segment; likely timed with the point-in-time that the video frame updated last, but this is just a theory not proven without taking a 60fps video and looking very closely. I can take one soon if you'd like.
Switching to DRI2 does not make a good difference; infact, immediately after loading Chrome the same stuttering effect occurs, with moderately lesser effect, maybe one skip every couple seconds, lasting a very short while, instead of the massive second-long judders when playing back a video.
The only "winning" combination so far, for latency in frame output (as detailed by the kwin fps meter effect) Radeon DDX; DRI3; Full scene repaints in Kwin for vsync; until tearfree has page flipping, its not going to work well enough for fluid desktop use. It also doesn't sync any in-window 2d drawing like kwin full-screen redraw.
Of other note, Chrome does appear to drop out of HW decode into CPU decode at regular points, which causes a noticeable increase in frame latency spikes, and corresponding CPU usage. This causes video stutter, whereas full HW decode is nearly liquid smooth, perhaps 1 jitter in the course of 5-10 seconds down to 30 fps and then right back to 60fps and smooth for another 5-10 seconds. This is acceptable to me, although not 100% ideal. I don't know if its related and likely should be a different bugreport against Chrome.
Please let me know what further information you would like.
Mike
Version: githttps://gitlab.freedesktop.org/xorg/xserver/-/issues/50X crash when plugging in vga2018-12-17T17:41:58ZBugzilla Migration UserX crash when plugging in vga## Submitted by dou..@..rd.net
Assigned to **Xorg Project Team**
**[Link to original bug (#93044)](https://bugs.freedesktop.org/show_bug.cgi?id=93044)**
## Description
I'm using ubunutu 15.10 with the nvidia blob driver and when p...## Submitted by dou..@..rd.net
Assigned to **Xorg Project Team**
**[Link to original bug (#93044)](https://bugs.freedesktop.org/show_bug.cgi?id=93044)**
## Description
I'm using ubunutu 15.10 with the nvidia blob driver and when plugging in the external monitor using unity, unity quits and I am greeted with the login screen.
[ 14.272749] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 14.272816] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 14.272862] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 14.272906] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 14.272951] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 14.273110] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 14.273252] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 14.273298] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 14.379592] IPv6: ADDRCONF(NETDEV_UP): enp0s25: link is not ready
[ 14.425157] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 14.614149] IPv6: ADDRCONF(NETDEV_UP): wlp3s0: link is not ready
[ 14.639431] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 14.639638] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 14.639835] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 14.640004] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 17.953797] Bluetooth: RFCOMM TTY layer initialized
[ 17.953804] Bluetooth: RFCOMM socket layer initialized
[ 17.953807] Bluetooth: RFCOMM ver 1.11
[ 17.982058] e1000e: enp0s25 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[ 17.982149] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s25: link becomes ready
[ 40.845621] [drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch fifo underrun on pch transcoder A
[ 40.845662] [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
[ 40.847192] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe B
[ 40.847232] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
[ 40.995011] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 41.034905] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 41.035010] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 41.035096] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 41.035171] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 41.035234] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 41.035403] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 41.035559] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 41.035617] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 41.099075] ACPI Warning: \_SB_.PCI0.PEG_.VID_._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150619/nsarguments-95)
[ 42.633352] [drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch fifo underrun on pch transcoder A
[ 42.633368] [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
[ 42.641986] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe B
[ 42.641999] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
[ 44.506683] [drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch fifo underrun on pch transcoder A
[ 44.506699] [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
[ 44.516557] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe B
[ 44.516574] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
[ 59.152180] show_signal_msg: 39 callbacks suppressed
[ 59.152185] compiz[2643]: segfault at 7f1ecdcea5c0 ip 00007f1ecbcc81cb sp 00007ffcbebb82a0 error 4 in libc-2.21.so[7f1ecbc49000+1c0000]
[ 60.694512] [drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch fifo underrun on pch transcoder A
[ 60.694527] [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
[ 60.705547] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe B
[ 60.705560] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
[ 62.500059] [drm:intel_set_pch_fifo_underrun_reporting [i915]] *ERROR* uncleared pch fifo underrun on pch transcoder A
[ 62.500072] [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun
[ 62.511028] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe B
[ 62.511037] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun
Version: githttps://gitlab.freedesktop.org/xorg/xserver/-/issues/64Segmentation Fault in modesetting driver with multiple NV124 devices2018-12-17T17:41:59ZBugzilla Migration UserSegmentation Fault in modesetting driver with multiple NV124 devices## Submitted by Barry G
Assigned to **Xorg Project Team**
**[Link to original bug (#92051)](https://bugs.freedesktop.org/show_bug.cgi?id=92051)**
## Description
Created attachment 118366
xorg.conf
My computer features two GTX 980...## Submitted by Barry G
Assigned to **Xorg Project Team**
**[Link to original bug (#92051)](https://bugs.freedesktop.org/show_bug.cgi?id=92051)**
## Description
Created attachment 118366
xorg.conf
My computer features two GTX 980 devices (ASUS Strix).
If I enable any ONE device using the modesetting driver in Linux 4.1.6-1-ARCH using xorg-server 1.17.2-4 everything is fine and the display works. I would like to use Xinerama and combine the two video cards to drive six monitors.
If I add driver lines to xorg.conf to enable both devices, my Xorg crashes with:
[ 222.290] (II) modeset(1): Output DisplayPort-2 connected
[ 222.290] (II) modeset(1): Using exact sizes for initial modes
[ 222.290] (II) modeset(1): Output DVI-0 using initial mode 1280x1024
[ 222.290] (II) modeset(1): Output DisplayPort-2 using initial mode 1280x1024
[ 222.290] (II) modeset(1): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated.
[ 222.290] (==) modeset(1): DPI set to (96, 96)
[ 222.290] (II) Loading sub module "fb"
[ 222.290] (II) LoadModule: "fb"
[ 222.290] (II) Loading /usr/lib/xorg/modules/libfb.so
[ 222.290] (II) Module fb: vendor="X.Org Foundation"
[ 222.290] compiled for 1.17.2, module version = 1.0.0
[ 222.290] ABI class: X.Org ANSI C Emulation, version 0.4
[ 222.290] (II) Loading sub module "shadow"
[ 222.290] (II) LoadModule: "shadow"
[ 222.290] (II) Loading /usr/lib/xorg/modules/libshadow.so
[ 222.290] (II) Module shadow: vendor="X.Org Foundation"
[ 222.290] compiled for 1.17.2, module version = 1.1.0
[ 222.290] ABI class: X.Org ANSI C Emulation, version 0.4
[ 222.290] (==) Depth 24 pixmap format is 32 bpp
[ 222.302] (==) modeset(0): Backing store enabled
[ 222.302] (==) modeset(0): Silken mouse enabled
[ 222.302] (II) modeset(0): RandR 1.2 enabled, ignore the following RandR disabled message.
[ 222.302] (==) modeset(0): DPMS enabled
[ 222.302] (EE)
[ 222.302] (EE) Backtrace:
[ 222.303] (EE) 0: /usr/lib/xorg-server/Xorg (OsLookupColor+0x139) [0x596d09]
[ 222.306] (EE) 1: /usr/lib/libc.so.6 (__restore_rt+0x0) [0x7f268065a67f]
[ 222.306] (EE) 2: /usr/lib/xorg/modules/drivers/modesetting_drv.so (_init+0x49cf) [0x7f267b35c0af]
[ 222.307] (EE) 3: /usr/lib/xorg/modules/drivers/modesetting_drv.so (_init+0x6333) [0x7f267b35f5f3]
[ 222.307] (EE) 4: /usr/lib/xorg/modules/drivers/modesetting_drv.so (_init+0x300a) [0x7f267b35909a]
[ 222.307] (EE) 5: /usr/lib/xorg/modules/drivers/modesetting_drv.so (_init+0x33d6) [0x7f267b3594b6]
[ 222.308] (EE) 6: /usr/lib/xorg-server/Xorg (AddScreen+0x101) [0x439161]
[ 222.308] (EE) 7: /usr/lib/xorg-server/Xorg (InitOutput+0x43a) [0x47bb5a]
[ 222.308] (EE) 8: /usr/lib/xorg-server/Xorg (remove_fs_handlers+0x22a) [0x43cd5a]
[ 222.309] (EE) 9: /usr/lib/libc.so.6 (__libc_start_main+0xf0) [0x7f2680647610]
[ 222.309] (EE) 10: /usr/lib/xorg-server/Xorg (_start+0x29) [0x427319]
[ 222.310] (EE) 11: ? (?+0x29) [0x29]
[ 222.310] (EE)
[ 222.310] (EE) Segmentation fault at address 0x2d0
[ 222.310] (EE)
Fatal server error:
[ 222.310] (EE) Caught signal 11 (Segmentation fault). Server aborting
[ 222.310] (EE)
[ 222.310] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
[ 222.310] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[ 222.310] (EE)
[ 222.374] (EE) Server terminated with error (1). Closing log file.
A not-so-useful backtrace shows:
```
#0 0x00007f268065a5f8 in raise () from /usr/lib/libc.so.6
[Current thread is 1 (Thread 0x7f2682644940 (LWP 1424))]
(gdb) bt
#0 0x00007f268065a5f8 in raise () from /usr/lib/libc.so.6
#1 0x00007f268065ba7a in abort () from /usr/lib/libc.so.6
#2 0x00000000005992ee in OsAbort ()
#3 0x000000000047a41c in ddxGiveUp ()
#4 0x000000000059ef02 in ?? ()
#5 0x000000000059fd3d in FatalError ()
#6 0x0000000000596c4e in ?? ()
#7 <signal handler called>
#8 0x00007f267b357a87 in ?? () from /usr/lib/xorg/modules/drivers/modesetting_drv.so
#9 0x00007f267b3593eb in ?? () from /usr/lib/xorg/modules/drivers/modesetting_drv.so
#10 0x00007f267b3560c2 in ?? () from /usr/lib/xorg/modules/drivers/modesetting_drv.so
#11 0x00007f267b35648e in ?? () from /usr/lib/xorg/modules/drivers/modesetting_drv.so
#12 0x0000000000439161 in AddScreen ()
#13 0x000000000047bb5a in InitOutput ()
#14 0x000000000043cd1a in ?? ()
#15 0x00007f2680647610 in __libc_start_main () from /usr/lib/libc.so.6
#16 0x0000000000427319 in _start ()
(gdb)
```
I will work on building a version with more symbols.
**Attachment 118366**, "xorg.conf":
[xorg.conf](/uploads/f124c8c731a3bf689d826e4ac4ee2185/xorg.conf)https://gitlab.freedesktop.org/xorg/xserver/-/issues/51"modesetting" does not use my second card's output2018-12-17T17:41:59ZBugzilla Migration User"modesetting" does not use my second card's output## Submitted by mon..@..eal.ca
Assigned to **Xorg Project Team**
**[Link to original bug (#91109)](https://bugs.freedesktop.org/show_bug.cgi?id=91109)**
## Description
Created attachment 116715
Xorg.2.log
I have two video cards, ...## Submitted by mon..@..eal.ca
Assigned to **Xorg Project Team**
**[Link to original bug (#91109)](https://bugs.freedesktop.org/show_bug.cgi?id=91109)**
## Description
Created attachment 116715
Xorg.2.log
I have two video cards, each connected to one monitor via DVI.
The first card is a Poulsbo (using the gma500_gfx kernel module), the second is a displaylink (using the udl kernel module). They both have an entry in /dev/dri.
My xorg.conf is just:
Section "Device"
Identifier "Video Device"
driver "modesetting"
Option "ModeDebug" "true"
EndSection
The X server does see both cards (e.g., "xrandr --listproviders" shows the two cards), but only sees (and sets up) the output of the Poulsbo ("xrandr" only lists the DVI-0 output).
The Xorg.log (attached) mentions a DVI-1-0 output connected on the displaylink card, but for some reason it doesn't try to get the EDID and "xrandr" can't use it (e.g. if I try "xrandr --output DVI-1-0 --auto" it tells me there's no such output).
**Attachment 116715**, "Xorg.2.log":
[Xorg.2.log](/uploads/dbecc467ab5e1b3c75a382ddb4a838fc/Xorg.2.log)
Version: 7.7 (2012.06)https://gitlab.freedesktop.org/xorg/xserver/-/issues/40NV50: modesetting - Segmentation fault at address 0x02018-12-17T17:41:58ZBugzilla Migration UserNV50: modesetting - Segmentation fault at address 0x0## Submitted by poma
Assigned to **Xorg Project Team**
**[Link to original bug (#90978)](https://bugs.freedesktop.org/show_bug.cgi?id=90978)**
## Description
Created attachment 116494
Xorg.0.log.old - modeset
Family : NV50
Chipse...## Submitted by poma
Assigned to **Xorg Project Team**
**[Link to original bug (#90978)](https://bugs.freedesktop.org/show_bug.cgi?id=90978)**
## Description
Created attachment 116494
Xorg.0.log.old - modeset
Family : NV50
Chipset: G98 (NV98)
GeForce 8400 GS
$ rpm -qf /usr/lib/xorg/modules/drivers/modesetting_drv.so
xorg-x11-server-Xorg-1.17.1-15.fc22.i686
$ cat /etc/X11/xorg.conf.d/00-modesetting.conf
Section "Device"
Identifier "video0"
Driver "modesetting"
EndSection
$ cat /var/log/Xorg.0.log.old
...
[ 240.719] (EE)
[ 240.719] (EE) Backtrace:
[ 240.719] (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x146) [0x81fd486]
[ 240.719] (EE) 1: ? (?+0x146) [0xb7785cf5]
[ 240.720] (EE) 2: /usr/lib/xorg/modules/drivers/modesetting_drv.so (_init+0x5c9f) [0xb6d9013f]
[ 240.720] (EE) 3: /usr/libexec/Xorg (xf86DetachAllCrtc+0x880) [0x8104220]
[ 240.720] (EE) 4: /usr/libexec/Xorg (xf86DestroyCursorInfoRec+0xd93) [0x810fe73]
[ 240.720] (EE) 5: /usr/libexec/Xorg (RamDacHandleColormaps+0x935) [0x810e345]
[ 240.720] (EE) 6: /usr/libexec/Xorg (miPointerUpdateSprite+0x262) [0x81e2cb2]
[ 240.720] (EE) 7: /usr/libexec/Xorg (miPointerUpdateSprite+0x4c6) [0x81e3366]
[ 240.721] (EE) 8: /usr/libexec/Xorg (CompositeRegisterImplicitRedirectionException+0x43f9) [0x81213c9]
[ 240.721] (EE) 9: /usr/libexec/Xorg (PanoramiXRenderReset+0x908) [0x816f238]
[ 240.721] (EE) 10: /usr/libexec/Xorg (ConfineToShape+0x9fa) [0x8087b2a]
[ 240.721] (EE) 11: /usr/libexec/Xorg (WindowHasNewCursor+0x3b) [0x80886fb]
[ 240.721] (EE) 12: /usr/libexec/Xorg (ChangeWindowAttributes+0xb68) [0x80b0fa8]
[ 240.721] (EE) 13: /usr/libexec/Xorg (ProcBadRequest+0x250) [0x8076960]
[ 240.721] (EE) 14: /usr/libexec/Xorg (SendErrorToClient+0x3c5) [0x807d635]
[ 240.722] (EE) 15: /usr/libexec/Xorg (remove_fs_handlers+0x4ba) [0x8081cfa]
[ 240.722] (EE) 16: /usr/libexec/Xorg (miPolyFillRect+0x26d) [0x806a2cd]
[ 240.722] (EE) 17: /lib/libc.so.6 (__libc_start_main+0xf7) [0xb71816c7]
[ 240.722] (EE) 18: /usr/libexec/Xorg (_start+0x21) [0x806a0d6]
[ 240.722] (EE)
[ 240.722] (EE) Segmentation fault at address 0x0
[ 240.722] (EE)
Fatal server error:
[ 240.722] (EE) Caught signal 11 (Segmentation fault). Server aborting
[ 240.722] (EE)
...
**Attachment 116494**, "Xorg.0.log.old - modeset":
[Xorg.0.log.old-modeset](/uploads/b7fcda72bdbdaf96124a6b162848c456/Xorg.0.log.old-modeset)https://gitlab.freedesktop.org/xorg/xserver/-/issues/59modesetting driver plus DRI3 causes extremely slow scrolling with WebKitGTK+ ...2018-12-17T17:41:59ZBugzilla Migration Usermodesetting driver plus DRI3 causes extremely slow scrolling with WebKitGTK+ in accelerated compositing mode## Submitted by Michael Catanzaro
Assigned to **Xorg Project Team**
**[Link to original bug (#85064)](https://bugs.freedesktop.org/show_bug.cgi?id=85064)**
## Description
With Epiphany/WebKitGTK+, scrolling on many pages (such as ...## Submitted by Michael Catanzaro
Assigned to **Xorg Project Team**
**[Link to original bug (#85064)](https://bugs.freedesktop.org/show_bug.cgi?id=85064)**
## Description
With Epiphany/WebKitGTK+, scrolling on many pages (such as any search results page on duckduckgo.com) is extremely slow and choppy. Launching epiphany with LIBGL_DRI3_DISABLE=1 causes these pages to work perfectly.
This is a critical bug for us since DuckDuckGo is our default search engine.
mesa-dri-drivers-10.3-1.20140927.fc21.x86_64
kernel-3.17.0-300.fc21.x86_64
### See also
* https://bugs.freedesktop.org/show_bug.cgi?id=81623
* [Bug 768478](https://bugzilla.gnome.org/show_bug.cgi?id=768478)
* https://bugs.webkit.org/show_bug.cgi?id=160491
* https://bugzilla.redhat.com/show_bug.cgi?id=1367894
* https://launchpad.net/bugs/1615871https://gitlab.freedesktop.org/xorg/xserver/-/issues/39xf86-video-modesetting-0.7.0 and 0.8.0 - no signal when i try to rotate screen2018-12-17T17:41:58ZBugzilla Migration Userxf86-video-modesetting-0.7.0 and 0.8.0 - no signal when i try to rotate screen## Submitted by Mikhail
Assigned to **Xorg Project Team**
**[Link to original bug (#65678)](https://bugs.freedesktop.org/show_bug.cgi?id=65678)**
## Description
xf86-video-modesetting-0.7.0 and 0.8.0 - no signal when i try to rota...## Submitted by Mikhail
Assigned to **Xorg Project Team**
**[Link to original bug (#65678)](https://bugs.freedesktop.org/show_bug.cgi?id=65678)**
## Description
xf86-video-modesetting-0.7.0 and 0.8.0 - no signal when i try to rotate screen
xrandr -o left
no errors o warnings in log