Bug#1028266: libegl-mesa0: terminology segfaults after ugprade to 22.3.2-1
Control: tags -1 forwarded https://gitlab.freedesktop.org/mesa/mesa/-/issues/7949 Hello, I think this is the issue: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7949 And the fix is in this MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20479/diffs The diff applies to the version in unstable. I ran into some challenges trying to test, but will try again another day. Ross On Mon, Jan 09, 2023 at 10:19:20AM +0100, Fabio Pedretti wrote: > Can you check if a similar issue is already reported at > https://gitlab.freedesktop.org/mesa/mesa/-/issues and eventually open > a new issue there? > > Il giorno lun 9 gen 2023 alle ore 00:09 Ross Vandegrift > ha scritto: > > After upgrading to mesa 22.3.2-1, terminology (a terminal emulater, package > > has > > the same name) began randomly crashing. Crashes were triggered by tab > > switching or window resizing. Downgrading back to 22.2.4-1 fixes the issue. >
can/should x window managers depend on an X server?
Hello, I recently saw a user question regarding installing a window manager, and then not being able to run it. The user didn't have xorg installed: they probably finished d-i with no desktop tasks selected in tasksel. That crops up occasionally - I was curious if I could improve the situation for those users. I found two surprising things. First, I didn't find a solution to copy: according to a quick search [1], no x-window-manager package (directly) brings in an X server. Some will bring one in via another dependency (e.g. cinnamon -> cinnamon-core -> lightdm -> Recommends: xserver-xorg) Second, policy didn't really clarify. Sec 11.8.1 says: > Programs that can be configured with support for the X Window System > must be configured to do so and must declare any package dependencies > necessary to satisfy their runtime requirements when using the X > Window System. Historically, I can think of some reasons why this once would've clearly excluded an X server: 1. it might not've been clear which X server to install 2. X used to require elaborate config, with scary warnings 3. someone might've wanted a window manager to be displayed remotely The first two strike me as false now, and #3 is probably less common than minimall installs. So here's what I'm wondering: - can x-window-manager packages depend/recommend/suggest an X server? - should they? - if so: - what should the relationship be? - what should the target be? - should these vary depending on the WM? (ie, twm probably still works well-enough remotely. enlightenment not so much.) - should policy be updated? Thanks for your thoughts, Ross [1] - grepping the output of "aptitude search -F %p ~Px-window-manager | xargs apt show" for "xserver" and "xorg".
Bug#929822: xserver-xorg-video-amdgpu: display stops updating after VT switch
Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=110808
Bug#929822: xserver-xorg-video-amdgpu: display stops updating after VT switch
Package: xserver-xorg-video-amdgpu Version: 19.0.1-1 Severity: normal After starting Xorg with the AMDGPU driver, I switch to a different VT. When I switch back to X, the display has frozen. Only the mouse cursor moves. To reproduce: 1) From a linux console with no display manager or X session running: $ startx /usr/bin/xterm 2) Switch to a different VT and back. 3) Nothing appears in the xterm when typing. 4) Switch to a different VT and back, the old typing appears. The screen isn't updating correctly but the client & server are functioning. I can run commands in the terminal, but can't see any output without a VT switch. Exiting the xterm immediately ends the X session cleanly. The same issue is triggered by a suspend/resume cycle, as a well as loggin into an X session with gdm. In both cases, I suspect VT change is the underlying trigger. Ross -- Package-specific info: /etc/X11/X does not exist. /etc/X11/X is not a symlink. /etc/X11/X is not executable. VGA-compatible devices on PCI bus: -- 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Stoney [Radeon R2/R3/R4/R5 Graphics] [1002:98e4] (rev eb) /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 4 -rw-r--r-- 1 root root 343 May 30 19:48 libinput.conf /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-3 (2019-05-15) Xorg X server log files on system: -- -rw-r--r-- 1 ross ross 46097 May 31 13:18 /home/ross/.local/share/xorg/Xorg.1.log -rw-r--r-- 1 ross ross 35981 May 31 14:03 /home/ross/.local/share/xorg/Xorg.0.log Contents of most recent Xorg X server log file (/home/ross/.local/share/xorg/Xorg.0.log): - [ 1483.270] X.Org X Server 1.20.3 X Protocol Version 11, Revision 0 [ 1483.274] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian [ 1483.276] Current Operating System: Linux momomoto 4.19.0-5-amd64 #1 SMP Debian 4.19.37-3 (2019-05-15) x86_64 [ 1483.276] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-5-amd64 root=/dev/mapper/momomoto--vg-root ro quiet splash [ 1483.279] Build Date: 25 October 2018 06:15:23PM [ 1483.280] xorg-server 2:1.20.3-1 (https://www.debian.org/support) [ 1483.281] Current version of pixman: 0.36.0 [ 1483.284]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 1483.284] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 1483.290] (==) Log file: "/home/ross/.local/share/xorg/Xorg.0.log", Time: Fri May 31 14:02:35 2019 [ 1483.292] (==) Using config directory: "/etc/X11/xorg.conf.d" [ 1483.293] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 1483.293] (==) No Layout section. Using the first Screen section. [ 1483.293] (==) No screen section available. Using defaults. [ 1483.293] (**) |-->Screen "Default Screen Section" (0) [ 1483.293] (**) | |-->Monitor "" [ 1483.294] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 1483.294] (==) Automatically adding devices [ 1483.294] (==) Automatically enabling devices [ 1483.294] (==) Automatically adding GPU devices [ 1483.294] (==) Max clients allowed: 256, resource mask: 0x1f [ 1483.294] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 1483.294]Entry deleted from font path. [ 1483.294] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 1483.294] (==) ModulePath set to "/usr/lib/xorg/modules" [ 1483.294] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 1483.294] (II) Loader magic: 0x5590f93c8e20 [ 1483.294] (II) Module ABI versions: [ 1483.294]X.Org ANSI C Emulation: 0.4 [ 1483.294]X.Org Video Driver: 24.0 [ 1483.294]X.Org XInput driver : 24.1 [ 1483.294]X.Org Server Extension : 10.0 [ 1483.295] (++) using VT number 2 [ 1483.298] (II) systemd-logind: took control of session /org/freedesktop/login1/session/_35 [ 1483.299] (II) xfree86: Adding drm device (/dev/dri/card0) [ 1483.300] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 11 paused 0 [ 1483.305] (--) PCI:*(0@0:1:0) 1002:98e4:1028:087e rev 235, Mem @
Bug#927993: xinit: Cannot load NVIDIA drivers, doesn't connect to X server. No screens found.
Control: -1 tags moreinfo Hi Sebastian, Could you send the output of: dpkg -l '*nouveau*'? Probably the X server output would also be useful. That should be the output of xinit/startx if you use it directly, otherwise check ~/.local/xorg/ or /var/log/. Ross
Bug#900308: xserver-xorg-input-libinput: options not applied after strech->buster upgrade
This bug is gone after an upgrade yesterday. I'm still at 0.27.1-1, so not sure which package ended up fixing this. But Xorg.log now shows: [49.791] (II) config/udev: Adding input device Lite-On Technology Corp. ThinkPad USB Keyboard with TrackPoint (/dev/input/mouse2) [49.791] (**) Lite-On Technology Corp. ThinkPad USB Keyboard with TrackPoint: Applying InputClass "DisableTrackPointScrolling" Ross
Bug#832594: libinput10: Thinkpad middle mouse not functioning properly, appears to be libinput10 issue
Does this help: $ xinput set-prop "TPPS/2 IBM TrackPoint" "libinput Button Scrolling Button" 0 libinput 1.5 appears to enable scroll wheel emulation for the middle button by default. I recently hit a similar issue after a jessie -> stretch upgrade. Ross
Bug#617498: xserver-xorg-video-radeon: Driver crash when watching Youtube video
On Tue, Mar 15, 2011 at 10:00:33AM +0100, Julien Cristau wrote: On Mon, Mar 14, 2011 at 21:46:43 -0400, Ross Vandegrift wrote: Package: xserver-xorg-video-radeon Version: 1:6.13.1-2+squeeze1 Followup-For: Bug #617498 [...] I've tried this on 2.6.37 from experimental as well as 2.6.32 from wheezy. No difference. I am running Xorg from experimental and have NOT tested rolling back to wheezy packages. The version number above and the X log below don't seem to point at experimental Xorg. Which is it? Tonight I updated to the latest bits from experimental and ended up with a broken X setup. I removed my pin file and downgraded all X related packages to wheezy. The original issue reported in the bug is gone. I wonder if I somehow ended up with a mostly-working mix of package versions. If I have some time next weekend, I'll try upgrading and reproducing the issue again. Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature
Bug#599035: xserver-xorg-video-radeon: KMS causes r6xx freeze-up on shutdown
On Mon, Oct 04, 2010 at 01:22:36AM +0200, Cyril Brulebois wrote: I haven't been able to collect any information on the freeze-up, since the system is dead. If there are any suggestions, I'd be happy to try them out. Some info might have been saved in /var/log/kern* maybe? Otherwise, you might want to look into using netconsole to send logs (almost) in realtime to another machine. I configured netconsole, regenerated my initramfs to enable kernel modesetting, tested, and nothing - it all works now. Removed netsonole, tried again, it still works. So it's fixed! I notice that today I pulled in an upgrade from initramfs-tools 0.98.2 - 0.98.4. 0.98.3 began conflicting with usplash, which I had installed. So my guess is usplash was causing the problem, and the initramfs-tools upgrade that forced usplash away was ultimately the cure. Sorry for the noise, Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature
Bug#559408: xserver-xorg-core: X server memory leak
On Sat, Dec 05, 2009 at 01:58:38PM -0500, ross wrote: On Fri, Dec 04, 2009 at 09:11:23AM +0100, Julien Cristau wrote: You could try running X under valgrind (with debugging symbols installed). It would be fairly slow, but could give some hints. IIRC 1.7 fixed a memleak related to cursors, do you have some clients that create cursors? Yes, I do - I am using an E17 theme that creates custom cursors. I've disabled that and restarted, I'll try to confirm that's the issue and then look into to running X under valgrind. Yep, it looks like you pretty much hit the nail on the head. After disabling custom cursors, Xorg's RSS is at 33MiB after being left all night. It sounds like the fix is known, and I'm just waiting for 1.7 to bubble into the distro. Is there any reason you are interested in the valgrind output? I'll leave the cursors disabled for now. Thanks for the tip, Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature
Bug#559408: xserver-xorg-core: X server memory leak
On Fri, Dec 04, 2009 at 09:11:23AM +0100, Julien Cristau wrote: The leak is fairly slow - it really does take a day or two to get to the 1G mark. In the past hour or so, it's grown from 70MiB to 90MiB. I am happy to collect any information requested to help troubleshoot this - it's very annoying. You could try running X under valgrind (with debugging symbols installed). It would be fairly slow, but could give some hints. IIRC 1.7 fixed a memleak related to cursors, do you have some clients that create cursors? Yes, I do - I am using an E17 theme that creates custom cursors. I've disabled that and restarted, I'll try to confirm that's the issue and then look into to running X under valgrind. Thanks, Ross -- Ross Vandegrift r...@kallisti.us If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher. --Woody Guthrie signature.asc Description: Digital signature
