Bug#1020715:
A correction for a mistake in my previous message: > Because Debian builds packages from a fixed build path, neither the > 'reprotest' > utility in Salsa-CI, nor the Reproducible Builds team's package test > infrastructure for Debian[1] currently check for equivalent binary package > output from differing source package build paths. > > This means that your package will pass current reproducibility tests; ... > [ snip ] Currently the 'reprotest' job in Salsa-CI does in fact continue to exercise variations of the build-path, and will fail if it builds binary packages that contain different contents as a result.
Bug#1020715:
Control: severity -1 wishlist Dear Maintainer, Because Debian builds packages from a fixed build path, neither the 'reprotest' utility in Salsa-CI, nor the Reproducible Builds team's package test infrastructure for Debian[1] currently check for equivalent binary package output from differing source package build paths. This means that your package will pass current reproducibility tests; however we believe that source code and/or build steps still embed the build path into the binary package output, making it more difficult than necessary for independent consumers to check the integrity of those packages by rebuilding them themselves. As a result, this bugreport will remain open and be re-assigned the 'wishlist' severity[2]. For more information about build paths and how they can affect reproducibility, please refer to: https://reproducible-builds.org/docs/build-path/ Thanks, James [1] - https://tests.reproducible-builds.org/debian/reproducible.html [2] - https://www.debian.org/Bugs/Developer#severities
Bug#1065666: Compiz 0.8.18 appears to be broken in testing
Hi This address is listed as a maintainer on the Compiz package search page. 0.8.18 black screens on boot after a recent update when building a iso with livebuild. I have been building the xfce-Compiz iso for about 4 months without issue. The xfce (testing amd64) iso is built without errors, but it is unusable with the black screen. Rebuilding the source package does not fix it. I cant seem to get any more info with the black screen, ctrl+alt+F(any number) stays a black screen and booting into safe mode also results in a black screen. Xfce images without compiz build and work fine. Thanks Jim
Bug#1065666: Compiz 0.8.18 appears to be broken in testing
Not sure if this helps, but I keep package lists of each build. Here is a diff of 2/24 build (works) vs 3/24 (broken). https://spins.tuxfamily.org/package-list-diff.txt I dont know if any changes would break compiz, but at least its more info. Jim On 3/6/24 11:25, Steve Langasek wrote: On Wed, Mar 06, 2024 at 06:19:48PM +0100, Colomban Wendling wrote: Le 06/03/2024 à 17:31, Steve Langasek a écrit : On Wed, Mar 06, 2024 at 03:46:41PM +0100, Colomban Wendling wrote: Anyway, I'm CCing Steve (who did the unstable NMU) and Samuel in case they have extra clues. The only change in the NMU was to rename the libdecoration0 package to libdecoration0t64 for the 64-bit time_t transition. Unless this managed to break the *contents* of that package (i.e. the library has gone missing), this should not have had any effect on the behavior of compiz. So the package has not been rebuilt with different flags or anything? Not *deliberately* as part of this upload. The only change to flags should be on 32-bit architectures, excluding i386. I have assumed you are not trying to run compiz on one of these archs! But the toolchain also evolves over time, so this could certainly be a misbuild due to underlying changes. Anyway, I hardly expect this to be an issue, I just wanted to eliminate the only Compiz-side change that happened in the last months.
Bug#1059145: libpixman-1-0: arm64 segfault while using proxmox console mode
Package: libpixman-1-0 Version: 0.42.2-1 Severity: important X-Debbugs-Cc: ja...@coppermoth.com Dear Maintainer, While using proxmox 8 (arm64 port) and viewing the console of a kvm session in novnc the kvm process regularly terminates. Using gdb and installing symbols I have traced this to libpixman-1-0 Thread 15 "SPICE Worker" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xfffab37ea3e0 (LWP 238200)] 0xf7ef913c in pixman_composite_src___asm_neon () at ../../pixman/pixman-arma64-neon-asm.S:1331 Downloading source file /build/pixman-phIJcH/pixman-0.42.2/build/pixman/../../pixman/pixman-arma64-neon-asm.S 1331../../pixman/pixman-arma64-neon-asm.S: Directory not empty. I am making the assumption that libpixman should not cause the segfault and the bug should be reported here; if I should raise against kvm please advise -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: arm64 (aarch64) Kernel: Linux 6.1.0-16-arm64 (SMP w/80 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpixman-1-0 depends on: ii libc6 2.36-9+deb12u3 libpixman-1-0 recommends no packages. libpixman-1-0 suggests no packages. -- no debconf information
Bug#1016530:
It looks like this might be https://gitlab.freedesktop.org/mesa/demos/-/issues/27 / https://gitlab.freedesktop.org/mesa/demos/-/merge_requests/84. signature.asc Description: Message signed with OpenPGP
Bug#943844: nouveau: cannot create GPU channel in Buster (worked in Stretch) - GeForce 6150
I reported this bug a long time ago. I had been hoping that by now some update to Debian would contain a fixed Nouveau that would work as expected with this old hardware. I'm still hoping ... I have also been playing around with this myself -- I don't know enough about video hardware (or anything about the Nouveau driver) to try to meddle with the source, but I've changed configuration options in a number of ways to see what would happen. The first thing I should say is that I think the error lines in Xorg.0.log are misleading. I had tried to disable acceleration in Nouveau because it had caused problems in Stretch and earlier. The error message lines: [45.875] (EE) NOUVEAU(0): Error creating GPU channel: -19 [45.875] (EE) NOUVEAU(0): Error initialising acceleration. Falling back to NoAccel [45.875] (**) NOUVEAU(0): [COPY] acceleration disabled seemed to me to be showing that the system was trying to use acceleration. I have tried disabling acceleration by providing a kernel parameter (either "noaccel" or "nouveau-noaccel=1") which I think worked in Stretch, but this does NOT seem to disable acceleration in Buster, which why I was getting the errors above. Those errors appear to have masked the actual error, making it harder to diagnose the problem. If I create a fairly minimal xorg.cong file containing just: Section "Device" Identifier "GeForce_6150" Driver "nouveau" VendorName "NVIDIA Corporation" Option "NoAccel" Option "AccelMethod" "None" EndSection Section "Monitor" Identifier "Default monitor" VendorName "DELL" ModelName "U2410" EndSection Section "Screen" Identifier "Screen0" Device "GeForce_6150" Monitor "Default monitor" EndSection then acceleration DOES seem to be disabled and I no longer get the errors in Xorg.0.log. In this state Buster boots to the login/greeting screen in the monitor's default resolution of 1920x1200 and I can enter a username and password. These are validated correctly and the screen blanks for a few moments and returns to the login/greeter. If I open a commandline console with ALT+F1 I can log in. If I then try to start an X session with startx I get the following. (Sorry, this is retyped by hand on another machine and may not be 100% correct (and lines may have wrapped). Many of the original lines were terminated with LF but not CR at the end and so the following lines appeared indented. X.Org X Server 1.20.4 X Protocol Version 11, Revision 0 Build Operating System: Linux 4.19.0-12-amd64 x86_64 Debian Current Operating System: Linux welly-buster 4.19.0-16-amd64 #1 SMP Debian 4.19.191-1 (2021-03-19) x86_64 Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-16-amd64 root=UUID=4abd25ab-9425-42ee-8612-75c0164d13d5 ro noapic Build Date: 01 December 2020 05:59:57PM xorg-server 2:1.20.4-1+deb10u2 (https://www.debian.org/support) Current version of pixman: 0.36.0 Before reporting problems, check http://wiki.x.org to make sure you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warnoing, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/home/daniel/.local/share/xorg/Xorg.1.log", Time: Sat Mar 27 23:32:08 2021 (==) Using config file: "/etc/X11/xorg.conf" (==) Uing system config directory "/usr/share/X11/xorg.conf.d" resize called 1920 1200 usr/lib/xorg/Xorg: symbol lookup error: /usr/lib/xorg/modules/drivers/nouveau_drv.so: undefined symbol: exaGetPixmapDriverPrivate xinit: connection to X server lost It now seems to me that the main problem is this undefined symbol error, which is causing the xorg to fail to load. I hope this is useful. Is there any more information I can provide to help get this matter resolved? -- Regards, Daniel James
Bug#943844: nouveau: cannot create GPU channel in Buster (worked in Stretch) - GeForce 6150
On Thu, 31 Oct 2019 15:46:30 + Daniel James wrote: I normally try to stay clear of testing and unstable, but I'll try those when I get a chance ... Sorry it's taken a while. With Testing (Kernel 5.2.0, Nouveau 1.0.16) the system boots to a full-screen graphical login. I can enter my username and password, and the screen then switches to a garbled version of the desktop (a bit like an old CRT television whose horizontal hold is incorrectly set, but static not moving). On this system, "dmesg | grep -E '(drm|nouveau)'" (as root) gives: [2.743125] nouveau :00:05.0: NVIDIA C51 (04e000a2) [2.752186] nouveau :00:05.0: bios: version 05.51.22.33.07 [2.753091] nouveau :00:05.0: fb: 128 MiB of unknown memory type [4.052950] nouveau :00:05.0: DRM: VRAM: 125 MiB [4.052985] nouveau :00:05.0: DRM: GART: 512 MiB [4.053022] nouveau :00:05.0: DRM: TMDS table version 1.1 [4.053058] nouveau :00:05.0: DRM: DCB version 3.0 [4.053094] nouveau :00:05.0: DRM: DCB outp 00: 02000300 0023 [4.053131] nouveau :00:05.0: DRM: DCB outp 01: 03011312 [4.053168] nouveau :00:05.0: DRM: DCB outp 02: 020023f1 0040c080 [4.053205] nouveau :00:05.0: DRM: DCB conn 00: [4.053240] nouveau :00:05.0: DRM: DCB conn 01: 0131 [4.053275] nouveau :00:05.0: DRM: DCB conn 02: 0210 [4.053311] nouveau :00:05.0: DRM: DCB conn 03: 0211 [4.053346] nouveau :00:05.0: DRM: DCB conn 04: 0213 [4.054701] nouveau :00:05.0: DRM: MM: using M2MF for buffer copies [4.055157] nouveau :00:05.0: DRM: Saving VGA fonts [4.093998] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [4.094037] [drm] Driver supports precise vblank timestamp query. [4.095028] nouveau :00:05.0: DRM: Setting dpms mode 3 on TV encoder (output 2) [4.176611] nouveau :00:05.0: DRM: allocated 1920x1200 fb: 0x9000, bo (ptrval) [4.218180] fbcon: nouveaudrmfb (fb0) is primary device [4.329239] nouveau :00:05.0: fb0: nouveaudrmfb frame buffer device [4.345656] [drm] Initialized nouveau 1.3.1 20120801 for :00:05.0 on minor 0 Interestingly, when I switch between "terminals" (is that the right word?) with Ctrl+Alt+F1 and back with Ctrl+Alt+F7 I see a perfect desktop display briefly before changing away to the text terminial, and again when I switch back but this then changes to the garbled display again. Every time I switch away from the graphics terminal to a text one and back this happens, for slightly varying time periods but never more than about half a second. There are no obvious relevant errors in /var/log/Xorg.0.log (and it's quite long) -- should I post it here? I've yet to try unstable ... I haven't any more spare hard drives so I'd have to overwrite the testing system and I don't want to do that if there's a chance that it may tell us something. --
Bug#943844: nouveau: cannot create GPU channel in Buster (worked in Stretch) - GeForce 6150
On Thu, 31 Oct 2019 10:31:48 +0100 Sven Joachim wrote: With nomodeset X will fallback to the fbev or vesa drivers. The latter has very limited support for modern wide screens, the former does not let you change the resolution at all. Yes, I assumed vesa. inxi -G says: Graphics: Device-1: NVIDIA C51PV [GeForce 6150] driver: N/A Display: x11 server: X.Org 1.20.4 driver: nouveau,vesa unloaded: fbdev,modesetting resolution: 1280x1024~N/A OpenGL: renderer: llvmpipe (LLVM 7.0 128 bits) v: 3.3 Mesa 18.3.6 I can change to lower resolutions, and back, just not to higher ones. > The system uses an Asus M2NPV-VM motherboard with NForce 430 chipset > and GeForce 61500 onboard graphics. The monitor is a Dell U2410 which > has a native resolution of 1920x1200 pixels. There have been many problems with these onboard graphics, quite a large fraction of the nouveau bug reports in Debian are from system with it. Agreed ... but note that this hardware had no difficulties with graphics in Debian Stretch or Jessie. The failure is new with Buster. > On Debian 9 "Stretch" it was not necessary to specify "nomodeset", and > the full screen resolution was used. > > This bug report is being prepared from a text console after booting > WITHOUT "nomodeset". The errors ("EE") at 45.875 seem to be crucial. I think you are right here. > [45.875] (EE) NOUVEAU(0): Error creating GPU channel: -19 > [45.875] (EE) NOUVEAU(0): Error initialising acceleration. > Falling back to NoAccel > [45.875] (**) NOUVEAU(0): [COPY] acceleration disabled That's not good. Can you please send some kernel logs? Run "sudo dmesg| grep -E '(drm|nouveau)" to retrieve them. Without nomodeset I get: [2.722181] nouveau :00:05.0: NVIDIA C51 (04e000a2) [2.731283] nouveau :00:05.0: bios: version 05.51.22.33.07 [2.732373] nouveau :00:05.0: fb: 128 MiB of unknown memory type [4.033290] nouveau :00:05.0: DRM: VRAM: 125 MiB [4.033325] nouveau :00:05.0: DRM: GART: 512 MiB [4.033363] nouveau :00:05.0: DRM: TMDS table version 1.1 [4.033399] nouveau :00:05.0: DRM: DCB version 3.0 [4.033435] nouveau :00:05.0: DRM: DCB outp 00: 02000300 0023 [4.036555] nouveau :00:05.0: DRM: DCB outp 01: 03011312 [4.036592] nouveau :00:05.0: DRM: DCB outp 02: 020023f1 0040c080 [4.036629] nouveau :00:05.0: DRM: DCB conn 00: [4.036664] nouveau :00:05.0: DRM: DCB conn 01: 0131 [4.036699] nouveau :00:05.0: DRM: DCB conn 02: 0210 [4.036735] nouveau :00:05.0: DRM: DCB conn 03: 0211 [4.036770] nouveau :00:05.0: DRM: DCB conn 04: 0213 [4.037233] nouveau :00:05.0: DRM: Saving VGA fonts [4.075567] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [4.075607] [drm] Driver supports precise vblank timestamp query. [4.076570] nouveau :00:05.0: DRM: Setting dpms mode 3 on TV encoder (output 2) [4.174450] nouveau :00:05.0: DRM: allocated 1920x1200 fb: 0x8000, bo (ptrval) [4.217697] fbcon: nouveaufb (fb0) is primary device [4.357759] nouveau :00:05.0: fb0: nouveaufb frame buffer device [4.376957] [drm] Initialized nouveau 1.3.1 20120801 for :00:05.0 on minor 0 (Sorry, Thunderbird has made some lines wrap) With nomodeset no lines match. You may want to try different kernels (4.9 from stretch, 5.2 from testing and/or 5.3 from unstable) and see if they give better results. As I said: Stretch works fine as it is. That is: The Stretch kernel works in Stretch using nouveau 1.0.13 with a 4.9 kernel. I haven't tried the Stretch kernel in Buster ... (Snippet from /var/log/Xorg.0.log under Stretch) [16.673] (II) Module nouveau: vendor="X.Org Foundation" [16.673]compiled for 1.19.3, module version = 1.0.13 [16.673]Module class: X.Org Video Driver [16.673]ABI class: X.Org Video Driver, version 23.0 (Snippet from /var/log/Xorg.0.log under Buster) [39.974] (II) Module nouveau: vendor="X.Org Foundation" [39.974]compiled for 1.20.3, module version = 1.0.16 [39.974]Module class: X.Org Video Driver [39.974]ABI class: X.Org Video Driver, version 24.0 Looks like the video driver ABI version has changed as well as the version of nouveau ... I guess it wouldn't be simple to mix and match. I normally try to stay clear of testing and unstable, but I'll try those when I get a chance ... -- Regards, Daniel James
Bug#943844: nouveau: cannot create GPU channel in Buster (worked in Stretch) - GeForce 6150
Package: xserver-xorg-video-nouveau Version: 1:1.0.16-1 Severity: important File: nouveau Dear Maintainer, [Message prepared by reportbug 7.5.3-de10u1 but mailed from Thunderbird on a different system] In Debian 10 "Buster" the Nouveau driver does not start correctly unless the "nomodeset" kernel parameter is supplied. Without "nomodeset" the system boots to a full-screen graphical login screen. Login credentials can be entered, but the screen then flashes off (black) for a fraction of a second and returns to the login dialog. With "nomodeset" Debian starts but the screen resolution is not optimal, and cannot be changed. The system boots to a graphical login screen with the edges black -- apparently a 1280x1024 displayed full-height but narrower than the screen. When login credentials are entered the system boots but still only shows a 1280x1024 desktop. Attempts to change the resolution (e.g. using xrandr to add a new mode and switch to it fail). The system uses an Asus M2NPV-VM motherboard with NForce 430 chipset and GeForce 61500 onboard graphics. The monitor is a Dell U2410 which has a native resolution of 1920x1200 pixels. On Debian 9 "Stretch" it was not necessary to specify "nomodeset", and the full screen resolution was used. This bug report is being prepared from a text console after booting WITHOUT "nomodeset". The errors ("EE") at 45.875 seem to be crucial. I have compared /var/log/Xorg.0.log files from this system when booting Buster and when booting Stretch, and (apart from minor details like module version numbers and the time field) the logs are identical up to this point. -- 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:05.0 VGA compatible controller [0300]: NVIDIA Corporation C51PV [GeForce 6150] [10de:0240] (rev a2) /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) Xorg X server log files on system: -- -rw-r--r-- 1 daniel daniel 33547 Oct 13 15:34 /home/daniel/.local/share/xorg/Xorg.0.log -rw-r--r-- 1 root root 26008 Oct 29 16:57 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [45.542] X.Org X Server 1.20.4 X Protocol Version 11, Revision 0 [45.542] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian [45.542] Current Operating System: Linux welly-buster 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 [45.542] Kernel command line: BOOT_IMAGE=/vmlinuz-4.19.0-6-amd64 root=UUID=4abd25ab-9425-42ee-8612-75c0164d13d5 ro noapic [45.542] Build Date: 05 March 2019 08:11:12PM [45.542] xorg-server 2:1.20.4-1 (https://www.debian.org/support) [45.542] Current version of pixman: 0.36.0 [45.542]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [45.542] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [45.543] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Oct 29 16:57:10 2019 [45.543] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [45.543] (==) No Layout section. Using the first Screen section. [45.543] (==) No screen section available. Using defaults. [45.543] (**) |-->Screen "Default Screen Section" (0) [45.543] (**) | |-->Monitor "" [45.544] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [45.544] (==) Automatically adding devices [45.544] (==) Automatically enabling devices [45.544] (==) Automatically adding GPU devices [45.544] (==) Max clients allowed: 256, resource mask: 0x1f [45.545] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [45.545]Entry deleted from font path. [45.545] (==) 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 [45.545] (==) ModulePath set to "/usr/lib/xorg/modules" [45.545] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [45.545] (II) Loader magic: 0x562deaa57e20 [45.545] (II) Module ABI vers
Re: Bug#912827: mpv 0.29.1 cannot display video on Weston 5.0.0
Control: reassign -1 weston Control: severity -1 normal Control: retitle -1 weston: add support for stable xdg-shell Control: affects -1 mpv Control: tags -1 upstream Hi, On 04/11/2018 07:04, Kelly Clowers wrote: > Package: mpv > Version: 0.28.2-3 > Severity: important > > Dear Maintainer, > > * What led up to the situation? > Updated MPV to 0.29.1 from 0.28.2 > > * What exactly did you do (or not do) that was effective (or > ineffective)? > > Tried to play a video file I have played many times before > > * What was the outcome of this action? > > MPV failed to play the file with the following error message: > > krc@ken:~/NFS/public/video/documentaries/David_Attenborough$ mpv > 2017_Blue_Planet_2/Blue_Planet_2_03_Coral_Reefs.mkv > Playing: 2017_Blue_Planet_2/Blue_Planet_2_03_Coral_Reefs.mkv > Unable to revert mtime: /usr/local/share/fonts > (+) Video --vid=1 (*) (h264 1920x1080 25.000fps) > (+) Audio --aid=1 --alang=eng (*) (dts 6ch 48000Hz) > Subs --sid=1 --slang=eng (*) (hdmv_pgs_subtitle) > [vo/gpu/wayland] Compositor doesn't support the required xdg_wm_base protocol! > [vo/gpu] Failed initializing any suitable GPU context! > Error opening/initializing the selected video_out (--vo) device. > Video: no video As of this commit (first in 0.29.0), mpv dropped support for xdg-shell v6 and now only supports the stable version of xdg-shell: https://github.com/mpv-player/mpv/commit/76211609e3c589dafe3ef9a36cacc06e8f56de09 Unfortunately Weston doesn't support stable xdg-shell yet. I have a feeling that currently mutter is the only compositor which does (although I may be wrong). There is an upstream mpv bug about this which hasn't seen any activity. I'll poke it and see what upstream has to say, but I doubt they're going to reintroduce xdg-shell v6 support. https://github.com/mpv-player/mpv/issues/6110 James signature.asc Description: OpenPGP digital signature
Re: Bug#903373: kitty: image rendering seems to be broken
Control: reassign -1 libxkbcommon-x11-0 0.8.0-2 Control: retitle -1 "not a valid UTF-8 string" errors creating compose table in en_IN locale On Mon, Jul 09, 2018 at 11:15:49AM +0530, Ritesh Raj Sarraf wrote: > Thank you for packaging the newer version of kitty. > > With this version, the `icat` and `diff` commands fail with the > following error: This also happens simply when starting kitty, but those go into your session error log. > rrs@priyasi:~$ kitty diff rrs-home/Data/Pictures/debian-transparent.png > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:87:34: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:88:29: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:89:29: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:90:29: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:91:29: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:92:27: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:93:27: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:94:27: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:95:27: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:96:29: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:97:29: string > literal is not a valid UTF-8 string > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:97:29: too many > errors > xkbcommon: ERROR: /usr/share/X11/locale/iso8859-1/Compose:97:29: failed to > parse file > [190 11:11:39.666312] [glfw error 65544]: Failed to create XKB compose table > > > Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en > (charmap=UTF-8) That error is directly from xkbcommon's code[0]. If you instead use LANG=en_IN.UTF-8, then there are no issues. It appears that xkbcommon is falling back incorrectly when there isn't an explicit codeset. [0]: https://sources.debian.org/src/libxkbcommon/0.8.0-2/src/compose/parser.c/?hl=207#L207 That being said, just "en_IN" is what "dpkg-reconfigure locales" generates when selecting that locale. Both reportbug and "locale -c charmap" are able to figure out that the codeset is UTF-8. kitty is using essentially the exact code[1] that xkbcommon's documentation suggests to use when calling xkb_compose_table_new_from_locale(). I'm reassigning to xkbcommon to see if there's something they can do to better handle this. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#884599: libinput10: jittery synaptics touchpad in wayland session
Hi, On 19/12/17 09:50, Tomas Janousek wrote: > Hi James, > > On Sun, Dec 17, 2017 at 03:00:46PM +0000, James Cowgill wrote: >> [...] >> Yes I can confirm that reverting fix-lp1696929.patch from 1.9.4-1 fixes >> my touchpad issues. > > If you can spare a few minutes, can you please take a look at the recent > discussion at https://bugs.freedesktop.org/show_bug.cgi?id=98839 ? > > Notably: > > - I had a similar problem on my wife's T440p which I fixed by upgrading the > touchpad firmware (which wasn't easy as I had to boot into Windows and > download a firmware update package for an entirely different laptop model), > and now it behaves *much* better with the patch. I don't think there is any new tochpad firmware for my laptop. It's quite a few years old and it doesn't seem Dell has released any updates for about 4 years now. I also don't own a copy of Windows anymore so doing the upgrade may be slightly complicated :) > - Peter would like to investigate and fix the patch so it works for people > like you, can you please provide him with the details he needs? I've replied to the upstream bug with some evemu recordings. Thanks, James signature.asc Description: OpenPGP digital signature
Bug#884599: libinput10: jittery synaptics touchpad in wayland session
Hi, On 17/12/17 13:40, Andreas Boll wrote: > On Sun, Dec 17, 2017 at 01:09:16PM +0000, James Cowgill wrote: >> Package: libinput10 >> Version: 1.9.4-1 >> Severity: normal >> >> Hi, >> >> Since upgrading to libinput 1.9.4-1, I have noticed my synaptics >> touchpad on my laptop has become very jittery. Placing my finger on the >> touchpad without moving it causes the mouse to move around very >> slightly. This is a massive PITA when trying to click precisely somewhere. >> >> Downgrading to 1.9.3-1 fixes this. >> >> The laptop is an old Dell XPS 15 L502X, but I'm not sure how to get any >> extra information about my touchpad (if that would be useful). >> >> Thanks, >> James > > Could be related to the new patch fix-lp1696929.patch we ship since > 1.9.4-1. Can you rebuild and test libinput 1.9.4-1 without that patch? Yes I can confirm that reverting fix-lp1696929.patch from 1.9.4-1 fixes my touchpad issues. Thanks, James signature.asc Description: OpenPGP digital signature
Bug#884599: libinput10: jittery synaptics touchpad in wayland session
Package: libinput10 Version: 1.9.4-1 Severity: normal Hi, Since upgrading to libinput 1.9.4-1, I have noticed my synaptics touchpad on my laptop has become very jittery. Placing my finger on the touchpad without moving it causes the mouse to move around very slightly. This is a massive PITA when trying to click precisely somewhere. Downgrading to 1.9.3-1 fixes this. The laptop is an old Dell XPS 15 L502X, but I'm not sure how to get any extra information about my touchpad (if that would be useful). Thanks, James -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libinput10 depends on: ii libc6 2.26-0experimental1 ii libevdev2 1.5.7+dfsg-1 ii libinput-bin 1.9.4-1 ii libmtdev1 1.1.5-1+b1 ii libudev1 235-3 ii libwacom2 0.26-1 libinput10 recommends no packages. libinput10 suggests no packages. -- no debconf information signature.asc Description: OpenPGP digital signature
Bug#881789: libglvnd: missing libGLX_indirect.so, breaks GLX with remote X server
Package: libglx0 Version: 1.0.0-1 Severity: important Dear Maintainer, I'm running testing on a headless system, and a recent change to use libglxvnd has stopped GLX from working when displayed to a remote machine. This was working fine before the migration to use glvnd for libGL/libGLX. e.g. running glxinfo fails with the following error: $ glxinfo name of display: localhost:11.0 Error: couldn't find RGB GLX visual or fbconfig strace'ing glxinfo shows it trying to load libGLX_indirect.so.0 and failing: $ strace -etrace=open glxinfo open("/lib/x86_64-linux-gnu/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/lib/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) Adding a symlink from libGLX_mesa.so.0 to libGLX_indrect.so.0 makes things work: $ sudo ln -s /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0 /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 $ glxinfo | head libGL error: No matching fbConfigs or visuals found libGL error: failed to load driver: swrast name of display: localhost:11.0 display: localhost:11 screen: 0 direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose) server glx vendor string: SGI server glx version string: 1.4 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig Looking at the source for glvnd and reading some NVIDIA documentation, it seems like glvnd is trying to fallback to a generic libGLX_indirect library if vendor-specific library doesn't exist or GLX_EXT_glvnd is not present on the remote X server (this is my situation). However, I can't find libGLX_indirect.so.0 provided by any Debian packages. It seems like either libglvnd or mesa should provide a symlink from libGLX_indirect.so.0 to a default GL implementation for these situations. I'd provide a patch but I'm not sure what package should be taking care of this -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages libglx0:amd64 depends on: ii libc6 2.24-17 ii libglvnd0 1.0.0-1 ii libglx-mesa0 [libglx-vendor] 17.2.4-1+b1 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 libglx0:amd64 recommends no packages. libglx0:amd64 suggests no packages. -- no debconf information
Bug#875446: libglvnd-dev: overwrites files in old libegl1-mesa-dev
Package: libglvnd-dev Version: 0.2.999+git20170802-3 Severity: serious Hi, On upgrading today I got this error: > Unpacking libglvnd-dev (0.2.999+git20170802-3) ... > dpkg: error processing archive > /tmp/apt-dpkg-install-Go1Tzy/19-libglvnd-dev_0.2.999+git20170802-3_amd64.deb > (--unpack): > trying to overwrite '/usr/lib/x86_64-linux-gnu/libEGL.so', which is also in > package libegl1-mesa-dev:amd64 17.1.5-1 I am guessing that libglvnd-dev needs to Breaks/Replaces the old mesa dev packages. Thanks, James signature.asc Description: OpenPGP digital signature
Bug#858304: vim-runtime: markdown syntax highlighting (and possibly others) goes crazy and drives the terminal crazy
On Fri, Apr 07, 2017 at 07:23:39AM -0400, G. Branden Robinson wrote: > At 2017-04-06T21:56:13-0400, James McCoy wrote: > > On Fri, Apr 07, 2017 at 12:54:19AM +0200, Francesco Poli wrote: > > > On Thu, 6 Apr 2017 15:06:17 -0400 G. Branden Robinson wrote: > > > > > > > At 2017-04-06T13:33:58-0400, James McCoy wrote: > > > > > On Thu, Apr 06, 2017 at 01:17:55PM -0400, G. Branden Robinson wrote: > > > > > > The below is not a sufficient reproduction receipe for me. > > > > > > > > > > > > I'm running Debian Stretch (testing). > > > > > > > > > > > > Things do not go wrong at step #5, nor afterward. > > > > > > > > > > Make sure the terminal is sized small enough (80x24). That causes the > > > > > syntax highlighting in Vim to get a little confused and enable some > > > > > bold > > > > > highlighting, which then causes the visual bell to turn everything > > > > > bold. > > > > > > > > It was. > > > > > > Hello Branden! > > > Thanks for trying to reproduce the bug. > > > > > > Does it help to know that I have: > > > > > > xset b off > > > > > > in my ~/.xsession script? > > > > I don't think that's relevant. My bell is on. I was also able to > > reproduce it without causing the bell. > > > > I've attached an asciinema recording of me reproducing the problem. > > When I replay the recording, it causes the same problem to the xterm in > > which it is running, so hopefully this helps debug the problem. > > That's really interesing. I _still_ can't repro this, even playing back > James's demo with asciinema--a tool of which I wasn't aware, thanks! > > I'm launching xterm in GNOME with the GNOME command runner, whatever > that's called--the Alt+F2 thing. > > However, my xterms are somewhat customized. I'm attaching my > .Xresources file. Perfect! That seems to be the difference. I, and presumably Francesco, aren't using TTF fonts. If I change your Xresources to use XTerm.*.VT100.Font: -misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1 instead of the FaceName/FaceSize resources, then playing the recording reproduces the problem. Cheers, James
Bug#858304: vim-runtime: markdown syntax highlighting (and possibly others) goes crazy and drives the terminal crazy
On Thu, Apr 06, 2017 at 01:17:55PM -0400, G. Branden Robinson wrote: > The below is not a sufficient reproduction receipe for me. > > I'm running Debian Stretch (testing). > > Things do not go wrong at step #5, nor afterward. Make sure the terminal is sized small enough (80x24). That causes the syntax highlighting in Vim to get a little confused and enable some bold highlighting, which then causes the visual bell to turn everything bold. > At 2017-04-05T22:03:50-0400, James McCoy wrote: > > On Mon, Mar 20, 2017 at 10:29:20PM +0100, Francesco Poli (wintermute) wrote: > > > I finally found a reliable way to reproduce it. > > > > > > Steps to reproduce: > > > > > > 0) open the attached test.md file: > > > > > > $ vim -u NONE test.md > > > > > > 1) enable syntax highlighting: > > > > > > :set bg=dark > > > :syn on > > > > > > 2) go to the end of the file: > > > > > > [Shift+G] > > > > > > 3) go back to the beginning of the file (line by line): > > > > > > [k].[k] ← hold the key pressed until you reach the first line > > > > > > 4) visualize file info on the status line: > > > > > > [Ctrl+G] > > > > > > 5) the syntax highlighting has gone crazy (even the status line is > > > in boldface!): see the attached screenshot > > > wrong_vim_syntaxmarkdown.png > > > > > > 6) exit from vim: > > > > > > :q > > > > > > 7) the terminal (xterm), or rather the shell (bash), has also gone > > > crazy (it now prints everything in boldface by default): see > > > the attached screenshot > > > wrong_vim_syntaxmarkdown2.png > > > > > > 8) the terminal won't come back to normal behavior until I quit it; > > > another trick to regain the normal behavior of the terminal is > > > opening test.md again, enable syntax highlighting, and exit vim > > > (steps 0, 1, and 6 above) > > Regards, > Branden -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: Bug#858304: vim-runtime: markdown syntax highlighting (and possibly others) goes crazy and drives the terminal crazy
Control: tag -1 confirmed Control: reassign -1 xterm Control: retitle -1 Terminal stays bold after visual bell with bold text displayed On Mon, Mar 20, 2017 at 10:29:20PM +0100, Francesco Poli (wintermute) wrote: > I have experienced this bug for a fairly long time, when editing > markdown documents with vim. It has been triggered in a seemingly > random manner. It's the visual bell that happens when you get to the top of the buffer and try to keep going. That causes Vim to send the BEL (Ctrl-G) to the terminal. The way the buffer is currently highlighted (some bold text) at that point is causing xterm to get stuck. You can reset it by Ctrl-RightClick -> "Escape Sequence". It works fine in at least pangoterm, but I haven't tried other more mainstream terminals. I'm reassigning to xterm for now. Rest of the context is below. > I finally found a reliable way to reproduce it. > > Steps to reproduce: > > 0) open the attached test.md file: > > $ vim -u NONE test.md > > 1) enable syntax highlighting: > > :set bg=dark > :syn on > > 2) go to the end of the file: > > [Shift+G] > > 3) go back to the beginning of the file (line by line): > > [k].[k] ← hold the key pressed until you reach the first line > > 4) visualize file info on the status line: > > [Ctrl+G] > > 5) the syntax highlighting has gone crazy (even the status line is > in boldface!): see the attached screenshot > wrong_vim_syntaxmarkdown.png > > 6) exit from vim: > > :q > > 7) the terminal (xterm), or rather the shell (bash), has also gone > crazy (it now prints everything in boldface by default): see > the attached screenshot > wrong_vim_syntaxmarkdown2.png > > 8) the terminal won't come back to normal behavior until I quit it; > another trick to regain the normal behavior of the terminal is > opening test.md again, enable syntax highlighting, and exit vim > (steps 0, 1, and 6 above) Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: Bug#856156: vim-gtk: launching gvim as root from terminal crashes X server
Control: reassign -1 xserver-xorg-core 2:1.19.1-4 Control: affects -1 vim-gtk Reassigning to xserver-xorg-core. Vim's gtk2 code hasn't changed significantly in some time, so it's more likely an issue with the glamor driver. On Sat, Feb 25, 2017 at 12:54:21PM -0500, Bruno Dantas wrote: > Either command in a terminal consistently crashes the X server: > # gvim foo.txt > $ gksudo gvim foo.txt > > I upgraded from Jessie to Stretch, which is when the problem started. The > error > message in the text console that appears after the crash is this: > "glamor_largepixmap.c:1448: glamor_composite_largepixmap_region: Assertion `0' > failed. xinit: connection to X server lost" > > Interestingly, starting gvim from within the file manager running as root (via > context menu's "Open with") works fine. Also, these work fine: > > # pluma foo.txt > $ gksudo pluma foo.txt > $ gvim foo.txt > > It seems the problem is isolated to launching gvim as root from the command > line. glamor_largepixmap.c is part of the xorg-server source package. If I > should report the bug there instead/in addition to here, please let me know. I > don't want to create noise. > > These are my package versions: > vim-gtk 2:8.0.0197-2 > xorg 1:7.7+18 > > If you need any further information, please let me know. gvim is my favorite > editor and I'm in a terminal most of the time, so I'm highly motivated to > help. -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
libx11: Issues with Data32/_XData32
Hi, I've been debugging an issue in gtk2-perl causing it to SIGBUS on sparc64, and traced it back to what seems to be dodgy code inside libx11. One of the tests calls gdk_window_set_opacity, which calls XChangeProperty with a pointer to a guint32, cast to char*, with the length set to 32 bits as expected. However, this data pointer then gets cast to a (long *) on line 83 of ChProp.c when calling Data32. Indeed, the definition of Data32 specifies that data is a (long *) on sparc64, since LONG64 is defined. This feels very wrong, but in and of itself is not too bad (I believe it violates strict aliasing). The problem really comes inside the implementation of _XData32. The destination buffer, buf, is an (int *), but data is still a (long *). These are not the same size. The issues with this are as follows: 1. Incrementing data increases the pointer by 8, so it skips over every other 4-byte int, and reads twice as many bytes as it should. 2. On big-endian systems, (int)*(long *)an_int_pointer will end up getting the 4 bytes *after* an_int_pointer, which means it gets completely the wrong data even in the case of len being 4 (bytes). 3. On sparc64, pointers have strict alignment requirements - they must be size aligned (ie (int *) must be 4-byte aligned, (long *) must be 8-byte aligned). In this case, the data pointer (which came all the way from gdk_window_set_opacity) is only 4-byte aligned (which is fine, since it's a pointer to a guint32), but it has been cast to a (long *) and dereferenced, so it is required to be 8-byte aligned. This is the cause of the observed crash. However, I wonder how 1. is not seen currently given the wide use of X11 on amd64. I can only assume 2. not being seen is because the only 64-bit big-endian architectures are generally used for servers, and there aren't many of them. I don't know what the solution to the problem is. There are various places in the call stack where this could be fixed up. The "correct" fix seems to be to change Data32 to take an (int *) (or some other data type of your choosing if you're worried about int's size not being portable) and fix up the casts at all the call sites, but this is an intrusive change to a public header, and I worry that there are things out there relying on the current behaviour. Alternatively, Data32 could be altered to still take a (long *), but cast it back to an (int *). This has the advantage of not touching public headers, but the prototype is then lying about what it's actually doing, and this still has the problem of breaking behaviour. The final, ugly alternative, is to alter XChangeProperty so it makes a copy of data as an array of long, padding or sign-extending each element, before passing it to Data32. I can't claim to have spent much time looking through the code, so it's highly likely I've missed something. Could those with more knowledge please comment on the above? Thanks, James
Bug#847073: X doesn't start with new xserver-xorg-video-intel
Control: tags -1 fixed-upstream > On 5 Dec 2016, at 12:49, Micha vor dem Berge > wrote: >> Am 05.12.2016 um 12:27 schrieb James Clarke: >> Package: xserver-xorg-video-intel >> Version: 2:2.99.917+git20161105-1 >> Severity: important >> Tags: patch upstream >> Control: retitle -1 segfaults due to missing NULL check in >> has_connector_backlight >> >>> On 5 Dec 2016, at 10:25, Micha vor dem Berge >>> wrote: >>> >>> Hi all, >>> >>> >>> I recently upgraded my xserver-xorg-video-intel package to the newest >>> jessie-backports (version 2:2.99.917+git20161105-1~bpo8+1). After a reboot, >>> X doesn't start anymore. I used this package from backports for several >>> months, so the newest update must have caused the trouble, I think. >>> >>> After a downgrade to jessie stable (version 2:2.21.15-2+b2) X is starting >>> fine again, but I have no HW acceleration... :( >>> >>> >>> Please find attached the Xorg.log. >>> >>> Just for information: I'm using Linux Mint Debian Edition, so my desktop is >>> Cinnamon. And I compiled my own kernel (which was no problem in the past). >>> I also tried some of my older kernels of the 4.8.x kernel series - just to >>> be sure that the problem is not introduced by the newest kernel upgrade. >>> >>> >>> Best regards, >>> >>> Micha >>> >>> >>> >>> PS: Please keep me in the loop when discussing this error as I didn't >>> subscribe to the backports mailing-list. Thanks! >>> >> >> >> This looks like [1] was reached with dir being NULL, though since you don't >> have debugging symbols (and I don't know/can't seem to work out what address >> intel_drv.so was loaded at) I can't know for sure. Having said that, this is >> the only place where the result of readdir is not checked for NULL, so I >> don't >> know how else this would happen. This bug was introduced by [2]. Can you >> please >> try the attached patch? Whether or not this is the problem, I'll forward it >> upstream. >> >> Regards, >> James >> >> [1] >> https://sources.debian.net/src/xserver-xorg-video-intel/2:2.99.917%2Bgit20161105-1%7Ebpo8%2B1/src/sna/sna_display.c/#L1036 >> [2] >> https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/325570e731b5819e28ce6bae72242914bb2d7f8e > > I can confirm that this patch > > https://lists.x.org/archives/xorg-devel/2016-December/051958.html > > solves the problem! :-) This has now been merged upstream[1]. Regards, James [1] https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=a1b39eb6dd1717501a0546275d07df8321fe4905
Bug#847073: X doesn't start with new xserver-xorg-video-intel
> On 5 Dec 2016, at 12:05, Emilio Pozuelo Monfort wrote: > > On 05/12/16 12:27, James Clarke wrote: >> Package: xserver-xorg-video-intel >> Version: 2:2.99.917+git20161105-1 >> Severity: important >> Tags: patch upstream >> Control: retitle -1 segfaults due to missing NULL check in >> has_connector_backlight >> >> This looks like [1] was reached with dir being NULL, though since you don't >> have debugging symbols (and I don't know/can't seem to work out what address > > What's wrong with xserver-xorg-video-intel-dbg ? I was being an idiot; I had unpacked -dbg, but pointed addr2line at the stripped library... debian:xserver-xorg-video-intel james% addr2line -e root/usr/lib/debug/usr/lib/xorg/modules/drivers/intel_drv.so 0x74502 /build/xserver-xorg-video-intel-CxTaWA/xserver-xorg-video-intel-2.99.917+git20161105/build/src/sna/../../../src/sna/sna_display.c:1036 So yes, this was the problem (though I wasn't really in any doubt after seeing the source). James
Bug#847073: X doesn't start with new xserver-xorg-video-intel
Package: xserver-xorg-video-intel Version: 2:2.99.917+git20161105-1 Severity: important Tags: patch upstream Control: retitle -1 segfaults due to missing NULL check in has_connector_backlight This looks like [1] was reached with dir being NULL, though since you don't have debugging symbols (and I don't know/can't seem to work out what address intel_drv.so was loaded at) I can't know for sure. Having said that, this is the only place where the result of readdir is not checked for NULL, so I don't know how else this would happen. This bug was introduced by [2]. Can you please try the attached patch? Whether or not this is the problem, I'll forward it upstream. Regards, James [1] https://sources.debian.net/src/xserver-xorg-video-intel/2:2.99.917%2Bgit20161105-1%7Ebpo8%2B1/src/sna/sna_display.c/#L1036 [2] https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/325570e731b5819e28ce6bae72242914bb2d7f8e > On 5 Dec 2016, at 10:25, Micha vor dem Berge > wrote: > > Hi all, > > > I recently upgraded my xserver-xorg-video-intel package to the newest > jessie-backports (version 2:2.99.917+git20161105-1~bpo8+1). After a reboot, X > doesn't start anymore. I used this package from backports for several months, > so the newest update must have caused the trouble, I think. > > After a downgrade to jessie stable (version 2:2.21.15-2+b2) X is starting > fine again, but I have no HW acceleration... :( > > > Please find attached the Xorg.log. > > Just for information: I'm using Linux Mint Debian Edition, so my desktop is > Cinnamon. And I compiled my own kernel (which was no problem in the past). I > also tried some of my older kernels of the 4.8.x kernel series - just to be > sure that the problem is not introduced by the newest kernel upgrade. > > > Best regards, > > Micha > > > > PS: Please keep me in the loop when discussing this error as I didn't > subscribe to the backports mailing-list. Thanks! >
Re: Bug#844357: binutils: mips* mesa libGL.so.1 contains an invalid symbol table
Control: tags -1 patch Hi, On 18/11/16 23:39, James Cowgill wrote: > On 16/11/16 17:15, James Cowgill wrote: >> Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=20828 >> >> Hi, >> >> I've submitted the bug upstream with a reduced testcase and a bisection. >> >> As the bug requires -Wl,--gc-sections to occur, it may be possible to >> workaround in mesa by recompiling without it. > > I have attached two patches: > > binutils-pr20828-v1.patch attempts to fix the underlying issue in > binutils where local symbols appear intermixed with global symbols. It > does this by applying another pass over the symbol table to assign all > the local symbol indexes first, then ignoring local symbols in the > second pass. This seems to fix my testcase and mesa, although I am not > 100% sure of it and I would like to get some feedback from upstream as > well since I don't really do much work with binutils. I think the breakage is too much to wait any longer, so please can you apply this patch to binutils so we can start recovering from all this. Thanks, James signature.asc Description: OpenPGP digital signature
Re: Bug#844357: binutils: mips* mesa libGL.so.1 contains an invalid symbol table
Hi, On 16/11/16 17:15, James Cowgill wrote: > Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=20828 > > Hi, > > I've submitted the bug upstream with a reduced testcase and a bisection. > > As the bug requires -Wl,--gc-sections to occur, it may be possible to > workaround in mesa by recompiling without it. I have attached two patches: binutils-pr20828-v1.patch attempts to fix the underlying issue in binutils where local symbols appear intermixed with global symbols. It does this by applying another pass over the symbol table to assign all the local symbol indexes first, then ignoring local symbols in the second pass. This seems to fix my testcase and mesa, although I am not 100% sure of it and I would like to get some feedback from upstream as well since I don't really do much work with binutils. mesa-mips-844227-workaround.patch is a workaround for mesa I was investigating in the meantime. It turns out that removing --Wl,gc-sections triggers some more undefined references so you need to link libnir.a in a few extra places. Thanks, James --- a/bfd/elfxx-mips.c +++ b/bfd/elfxx-mips.c @@ -743,6 +743,8 @@ static struct mips_got_entry *mips_elf_create_local_got_entry struct mips_elf_link_hash_entry *, int); static bfd_boolean mips_elf_sort_hash_table_f (struct mips_elf_link_hash_entry *, void *); +static bfd_boolean mips_elf_sort_hash_table_local_f + (struct mips_elf_link_hash_entry *, void *); static bfd_vma mips_elf_high (bfd_vma); static bfd_boolean mips_elf_create_dynamic_relocation @@ -3850,6 +3852,11 @@ mips_elf_sort_hash_table (bfd *abfd, struct bfd_link_info *info) = hsd.min_got_dynindx = (elf_hash_table (info)->dynsymcount - g->reloc_only_gotno); hsd.max_non_got_dynindx = count_section_dynsyms (abfd, info) + 1; + + mips_elf_link_hash_traverse (((struct mips_elf_link_hash_table *) +elf_hash_table (info)), +mips_elf_sort_hash_table_local_f, +&hsd); mips_elf_link_hash_traverse (((struct mips_elf_link_hash_table *) elf_hash_table (info)), mips_elf_sort_hash_table_f, @@ -3879,28 +3886,40 @@ mips_elf_sort_hash_table_f (struct mips_elf_link_hash_entry *h, void *data) { struct mips_elf_hash_sort_data *hsd = data; - /* Symbols without dynamic symbol table entries aren't interesting - at all. */ - if (h->root.dynindx == -1) + /* Only interested in global symbols with dynamic symbol table entries */ + if (h->root.dynindx == -1 || h->root.forced_local) return TRUE; - switch (h->global_got_area) -{ -case GGA_NONE: + if (h->global_got_area == GGA_NONE) { h->root.dynindx = hsd->max_non_got_dynindx++; - break; + } else { + if (h->global_got_area == GGA_NORMAL) + h->root.dynindx = --hsd->min_got_dynindx; + else + h->root.dynindx = hsd->max_unref_got_dynindx++; -case GGA_NORMAL: - h->root.dynindx = --hsd->min_got_dynindx; - hsd->low = (struct elf_link_hash_entry *) h; - break; + if (hsd->low == NULL || h->root.dynindx < hsd->low->dynindx) + hsd->low = (struct elf_link_hash_entry *) h; + } -case GGA_RELOC_ONLY: - if (hsd->max_unref_got_dynindx == hsd->min_got_dynindx) - hsd->low = (struct elf_link_hash_entry *) h; - h->root.dynindx = hsd->max_unref_got_dynindx++; - break; -} + return TRUE; +} + +/* All local symbols must be appear before global symbols in the dynamic symbol + table so they're assigned indexs first. */ + +static bfd_boolean +mips_elf_sort_hash_table_local_f (struct mips_elf_link_hash_entry *h, void *data) +{ + struct mips_elf_hash_sort_data *hsd = data; + + /* Only interested in local symbols with dynamic symbol table entries */ + if (h->root.dynindx == -1 || !h->root.forced_local) +return TRUE; + + h->root.dynindx = hsd->max_non_got_dynindx++; + if (h->global_got_area != GGA_NONE && hsd->low == NULL) + hsd->low = (struct elf_link_hash_entry *) h; return TRUE; } --- a/configure.ac +++ b/configure.ac @@ -543,17 +543,7 @@ AC_SUBST([BSYMBOLIC]) dnl dnl Check if linker supports garbage collection dnl -save_LDFLAGS=$LDFLAGS -LDFLAGS="$LDFLAGS -Wl,--gc-sections" -AC_MSG_CHECKING([whether ld supports --gc-sections]) -AC_LINK_IFELSE( -[AC_LANG_SOURCE([static char UnusedFunc() { return 5; } int main() { return 0;}])], -[AC_MSG_RESULT([yes]) -GC_SECTIONS="-Wl,--gc-sections";], -[AC_MSG_RESULT([no]) -GC_SECTIONS="";]) -LDFLAGS=$save_LDFLAGS - +GC_SECTIONS="" AC_SUBST([GC_SECTIONS]) dnl --- a/src/gallium/targets/va/Makefile.am +++ b/src/gallium/targets/va/Makefile.am @@ -29,6 +29,7 @@ gallium_drv_video_la_LIBADD = \ $(top_builddir)/src/gallium/auxiliary/libgalliumvl.la \ $(top_builddir)/
Re: Bug#844357: binutils: mips* mesa libGL.so.1 contains an invalid symbol table
Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=20828 Hi, I've submitted the bug upstream with a reduced testcase and a bisection. As the bug requires -Wl,--gc-sections to occur, it may be possible to workaround in mesa by recompiling without it. Thanks, James signature.asc Description: OpenPGP digital signature
Re: Bug#844357: binutils: mips* mesa libGL.so.1 contains an invalid symbol table (Was: fracplanet FTPFS on mips*: libQtOpenGL.so: undefined reference to `glLoadMatrixd')
On 16/11/16 11:32, James Cowgill wrote: > Here 3 = the index of the first non-global symbol, and 9 = the total s/non-global/non-local/ James signature.asc Description: OpenPGP digital signature
Re: Bug#844357: fracplanet FTPFS on mips*: libQtOpenGL.so: undefined reference to `glLoadMatrixd'
Control: reassign -1 binutils 2.25-5 Control: severity -1 important Control: affects -1 src:fracplanet Control: retitle -1 binutils: mips* mesa libGL.so.1 contains an invalid symbol table Hi, On 14/11/16 19:08, Adrian Bunk wrote: > Package: fracplanet > Version: 0.4.0-5 > Severity: serious > > https://buildd.debian.org/status/package.php?p=fracplanet&suite=sid > > g++ -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong > -Wformat -Werror=format-security -Wl,-z,relro -Wl,-O1 -o fracplanet > obj/common.o obj/control.o obj/control_about.o obj/control_render.o > obj/control_save.o obj/control_terrain.o obj/dialog_documentation.o > obj/fracplanet.o obj/fracplanet_main.o obj/geometry.o obj/image.o > obj/license.o obj/matrix33.o obj/matrix34.o obj/noise.o > obj/parameters_cloud.o obj/parameters_noise.o obj/parameters_object.o > obj/parameters_render.o obj/parameters_save.o obj/parameters_terrain.o > obj/progress.o obj/random.o obj/rgb.o obj/scan.o obj/spinbox.o obj/triangle.o > obj/triangle_edge.o obj/triangle_mesh.o obj/triangle_mesh_cloud.o > obj/triangle_mesh_terrain.o obj/triangle_mesh_viewer.o > obj/triangle_mesh_viewer_display.o obj/vertex.o obj/xyz.o > obj/moc_control_about.o obj/moc_control_render.o obj/moc_control_save.o > obj/moc_control_terrain.o obj/moc_dialog_documentation.o > obj/moc_fracplanet_main.o obj/moc_triangle_mesh_viewer.o obj/moc_triang > le_mesh_viewer_display.o-L/usr/lib/mips-linux-gnu -L/usr/X11R6/lib > -lboost_program_options -lGLU -lQtOpenGL -lQtGui -lQtCore -lGL -lpthread > /usr/lib/mips-linux-gnu/libQtOpenGL.so: undefined reference to `glLoadMatrixd' > > > Michael Biebl mentioned #844227 on IRC, are these bugs coincidence, > or is there something that broke/changed in Mesa on mips* recently? Looking at this a bit closer, it appears to be a longstanding binutils bug which was recently made worse due to a change in counting local symbols. Dumping the dynamic symbol table of libGL.so.1 on mipsel shows the first (long standing) bug: $ readelf --syms libGL.so.1 | head -n15 Symbol table '.dynsym' contains 1559 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 000163c0 0 SECTION LOCAL DEFAULT 10 2: 000902a8 0 SECTION LOCAL DEFAULT 16 3: 0007264052 FUNCGLOBAL DEFAULT 11 glCheckFramebufferStatusE 4: 0006c47052 FUNCGLOBAL DEFAULT 11 glConvolutionFilter1D 5: 0007219828 FUNCGLOBAL DEFAULT 11 glVertexAttrib3fvARB 6: 0006b73052 FUNCGLOBAL DEFAULT 11 glLoadMatrixd 7: 000943d0 0 NOTYPE LOCAL DEFAULT 24 _fbss 8: 0006c6a052 FUNCGLOBAL DEFAULT 11 glGetConvolutionParameter 9: 0006973052 FUNCGLOBAL DEFAULT 11 glVertex4i 10: 0006ebe052 FUNCGLOBAL DEFAULT 11 glGetBufferPointervARB 11: 0006e3d828 FUNCGLOBAL DEFAULT 11 glWindowPos2f Here the _fbss symbol is LOCAL which is prohibited by the ELF standard which requires all LOCAL symbols to precede GLOBAL symbols. This bug is definitely present in jessie's binutils, because jessie's libGL also has a symbol table similar to this. Wheezy's mesa doesn't have this bug but I don't know if binutils definitely doesn't have it in wheezy. Ordinarily this wasn't much of an issue since glibc and ld would just skip LOCAL symbols when processing the symbol tables. However somewhere between binutils 2.27-9 and 2.27.51.20161108-1 the behavior for calculating the 'st_info' field for the .dynsym section header changed. Recompiling mesa with both versions of binutils gives identical libGL binaries except for this difference in the section header: diffoscope output (- 2.27-9, + 2.27.51.20161108-1): │ - [ 5] .dynsym DYNSYM 2e40 002e40 009228 18 A 6 3 8 │ + [ 5] .dynsym DYNSYM 2e40 002e40 009228 18 A 6 9 8 Here 3 = the index of the first non-global symbol, and 9 = the total number of local symbols. These values should of course be equal if the rules about symbol ordering were followed. ld uses the value of the 'st_info' field to skip LOCAL symbols when linking, which explains why only the 5 symbols from 3-8 in the above symbol table cause link errors. I'm still investigating, but getting a reduced testcase is quite tricky and recompiling mesa on mips takes about an hour. Thanks, James signature.asc Description: OpenPGP digital signature
Bug#827651: vulkan: FTBFS on mips64el -- relocation truncated to fit: R_MIPS_CALL16
Source: vulkan Version: 1.0.8.0+dfsg1-1 Severity: important Tags: patch Hi, vulakn FTBFS on mips64el because the libVkLayer_core_validation.so library contains too many symbols and overflows the default GOT. This is what causes the relocation errors. This can be fixed by compiling vulkan with the -mxgot flag, although this does have a performance penalty. Before this can happen, the validation layer CMakeLists.txt file must be updated so it doesn't clobber the CXXFLAGS variable. Patches to do both of these tasks are attached. Thanks, JamesDescription: Don't clobber CXXFLAGS when building validation layers Author: James Cowgill --- This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ --- a/layers/CMakeLists.txt +++ b/layers/CMakeLists.txt @@ -91,7 +91,7 @@ if (WIN32) set (CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -D_CRT_SECURE_NO_WARNINGS /bigobj") endif() if (NOT WIN32) -set (CMAKE_CXX_FLAGS "-std=c++11") +set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wpointer-arith") set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wpointer-arith") endif() --- a/debian/rules +++ b/debian/rules @@ -4,6 +4,10 @@ DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/default.mk +ifeq ($(DEB_HOST_ARCH),mips64el) +export DEB_CXXFLAGS_MAINT_APPEND := -mxgot +endif + # main packaging script based on dh7 syntax %: dh $@ --with quilt --builddirectory=build/ signature.asc Description: This is a digitally signed message part
Bug#822179: xorg: X.Org X Server starts normally, crashes with Segmentation fault on starting any application
Control: forwarded -1 https://patchwork.freedesktop.org/series/6272/ Control: tags -1 upstream > On 24 Apr 2016, at 08:44, Emilio Pozuelo Monfort wrote: > >> On 23/04/16 17:27, James Clarke wrote: >> >> I rebuilt xorg-server-2_1.18.3-1 having patched Xpoll.h with this exact >> patch (with s/Xpoll.h.in/Xpoll.h, of course) and can confirm it works. > > Great. Please send the patch to xorg-de...@lists.x.org Done (thanks jcristau for the moderator approval!). Regards, James signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#822179: xorg: X.Org X Server starts normally, crashes with Segmentation fault on starting any application
> On 23 Apr 2016, at 15:03, James Clarke wrote: > > Hi, >> On 23 Apr 2016, at 14:55, Samuel Thibault > <mailto:sthiba...@debian.org>> wrote: >> >> Hello, >> >> James Clarke, on Sat 23 Apr 2016 14:44:52 +0100, wrote: >>> I have attached a proposed patch which ensures XFD_SETSIZE never >>> exceeds FD_SETSIZE. >> >> Did you test it? > > Not this specific version, but changing it to 256 directly in the header. > I’m about to test this exact patch. I rebuilt xorg-server-2_1.18.3-1 having patched Xpoll.h with this exact patch (with s/Xpoll.h.in/Xpoll.h, of course) and can confirm it works. Regards, James signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#822179: xorg: X.Org X Server starts normally, crashes with Segmentation fault on starting any application
> On 23 Apr 2016, at 15:06, Samuel Thibault wrote: > > James Clarke, on Sat 23 Apr 2016 15:03:29 +0100, wrote: >>> AIUI, nothing uses XFD_SETSIZE actually, it's just the default value >>> that X uses for FD_SETSIZE in case it's not already defined. >> >> No, in e.g. os/WaitFor.c in xorg-server, there are for loops using >> howmany(XFD_SETSIZE, NFDBITS) to iterate over each element, > > Ergl, ok, so XFD_SETSIZE also needs to be fixed. This *is* changing XFD_SETSIZE... >> These lines are fine; the indexing is guarded by the howmany check, and uses >> the real FD_SETSIZE. > > Ah, right. Overlooked the whole thing too fast. > > Sorry for the noise, Not to worry; always best to question these things :) Regards, James signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#822179: xorg: X.Org X Server starts normally, crashes with Segmentation fault on starting any application
Hi, > On 23 Apr 2016, at 14:55, Samuel Thibault wrote: > > Hello, > > James Clarke, on Sat 23 Apr 2016 14:44:52 +0100, wrote: >> I have attached a proposed patch which ensures XFD_SETSIZE never >> exceeds FD_SETSIZE. > > Did you test it? Not this specific version, but changing it to 256 directly in the header. I’m about to test this exact patch. > > AIUI, nothing uses XFD_SETSIZE actually, it's just the default value > that X uses for FD_SETSIZE in case it's not already defined. No, in e.g. os/WaitFor.c in xorg-server, there are for loops using howmany(XFD_SETSIZE, NFDBITS) to iterate over each element, which invokes undefined behaviour and a warning from GCC due to aggressive loop optimisations. There are a few more if you grep the xorg-server source tree, and who knows about other packages. > I.e. your > change doesn't actually change anything: if FD_SETSIZE is define on > poll.h inclusion, it'll be used, not 512. What probably actually breaks > is the > > (howmany(FD_SETSIZE, NFDBITS) > 8 && (__XFDS_BITS(p, 8))) || > > lines when FD_SETSIZE is not big enough. Probably these can be made > conditioned by the value of FD_SETSIZE, something like: > > #if FD_SETSIZE >= 512 > #define XFD_ANYSET_512(p) \ > ((howmany(FD_SETSIZE, NFDBITS) > 8 && (__XFDS_BITS(p, 8))) || \ >(howmany(FD_SETSIZE, NFDBITS) > 9 && (__XFDS_BITS(p, 9))) || \ >(howmany(FD_SETSIZE, NFDBITS) > 10 && (__XFDS_BITS(p, 10))) || \ >(howmany(FD_SETSIZE, NFDBITS) > 11 && (__XFDS_BITS(p, 11))) || \ >(howmany(FD_SETSIZE, NFDBITS) > 12 && (__XFDS_BITS(p, 12))) || \ >(howmany(FD_SETSIZE, NFDBITS) > 13 && (__XFDS_BITS(p, 13))) || \ >(howmany(FD_SETSIZE, NFDBITS) > 14 && (__XFDS_BITS(p, 14))) || \ >(howmany(FD_SETSIZE, NFDBITS) > 15 && (__XFDS_BITS(p, 15 > #else > #define XFD_ANYSET_512(p) 0 > #endif > > #define XFD_ANYSET(p) \ > ((howmany(FD_SETSIZE, NFDBITS) > 0 && (__XFDS_BITS(p, 0))) || \ >(howmany(FD_SETSIZE, NFDBITS) > 1 && (__XFDS_BITS(p, 1))) || \ >(howmany(FD_SETSIZE, NFDBITS) > 2 && (__XFDS_BITS(p, 2))) || \ >(howmany(FD_SETSIZE, NFDBITS) > 3 && (__XFDS_BITS(p, 3))) || \ >(howmany(FD_SETSIZE, NFDBITS) > 4 && (__XFDS_BITS(p, 4))) || \ >(howmany(FD_SETSIZE, NFDBITS) > 5 && (__XFDS_BITS(p, 5))) || \ >(howmany(FD_SETSIZE, NFDBITS) > 6 && (__XFDS_BITS(p, 6))) || \ >(howmany(FD_SETSIZE, NFDBITS) > 7 && (__XFDS_BITS(p, 7))) || \ > XFD_ANYSET_512(p)) These lines are fine; the indexing is guarded by the howmany check, and uses the real FD_SETSIZE. Regards, James signature.asc Description: Message signed with OpenPGP using GPGMail
Bug#822179: xorg: X.Org X Server starts normally, crashes with Segmentation fault on starting any application
Control: tags -1 - moreinfo Control: tags -1 + patch Control: reassign x11proto-core-dev 7.0.28-1 Hi, I looked into this, and it turns out https://anonscm.debian.org/cgit/pkg-xorg/proto/x11proto-core.git/commit/?id=2c94cdb453bc641246cc8b9a876da9799bee1ce7 is to blame, not the server itself. On GNU/Hurd FD_SETSIZE is only 256, so XFD_SETSIZE exceeds this, and when various files in os/ (e.g. WaitFor.c) iterate over the set, they go out of bounds; GCC very helpful gives "warning: iteration 8u invokes undefined behavior [-Waggressive-loop-optimizations]" for these. I have attached a proposed patch which ensures XFD_SETSIZE never exceeds FD_SETSIZE. Regards, James > On 22 Apr 2016, at 20:32, Julien Cristau wrote: > > Control: tags -1 moreinfo help > > On Thu, Apr 21, 2016 at 23:16:02 +0200, Matthias wrote: > >> Package: xorg >> Version: 1:7.7+14 >> Severity: normal >> >> Dear Maintainer, >> >> X crashes instantly when starting any application, e.g. FF or system >> configuration settings or display settings. The Xorg.0.log file states, >> xorg-server version is 2:1.18.3-1 . System is Debian testing running under >> hurd. >> > This would have to be looked at by a hurd person. (Also, there's no > such thing as debian testing for hurd, afaik, only unstable) > > Cheers, > Julien > >> >> -- Package-specific info: >> X server symlink status: >> >> lrwxr-xr-x 1 root root 13 Dec 28 11:32 /etc/X11/X -> /usr/bin/Xorg >> -rwxr-xr-x 1 root root 274 Apr 5 11:40 /usr/bin/Xorg >> >> VGA-compatible devices on PCI bus: >> -- >> >> Xorg X server configuration file status: >> >> -rw-r--r-- 1 root root 131 Dec 28 11:38 /etc/X11/xorg.conf >> >> Contents of /etc/X11/xorg.conf: >> --- >> Section "InputDevice" >> Identifier "Generic Keyboard" >> Driver "kbd" >> Option "XkbOptions" "terminate:ctrl_alt_bksp" >> EndSection >> >> /etc/X11/xorg.conf.d does not exist. >> >> /etc/modprobe.d contains no KMS configuration files. >> >> Kernel version (/proc/version): >> --- >> Linux version 2.6.1 (GNU 0.7 GNU-Mach 1.6+git20160311-486/Hurd-0.7 >> i686-AT386) >> >> Xorg X server log files on system: >> -- >> -rw-r--r-- 1 root root 29974 Apr 21 22:45 /var/log/Xorg.0.log >> >> Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): >> - >> [982589.873] >> X.Org X Server 1.18.3 >> Release Date: 2016-04-04 >> [982589.873] X Protocol Version 11, Revision 0 >> [982589.873] Build Operating System: GNU 0.7 i686-AT386 Debian >> [982589.873] Current Operating System: GNU debian 0.7 GNU-Mach >> 1.6+git20160311-486/Hurd-0.7 i686-AT386 >> [982589.873] Build Date: 05 April 2016 09:20:21AM >> [982589.873] xorg-server 2:1.18.3-1 (http://www.debian.org/support) >> [982589.873] Current version of pixman: 0.33.6 >> [982589.873] Before reporting problems, check http://wiki.x.org >> to make sure that you have the latest version. >> [982589.873] Markers: (--) probed, (**) from config file, (==) default >> setting, >> (++) from command line, (!!) notice, (II) informational, >> (WW) warning, (EE) error, (NI) not implemented, (??) unknown. >> [982589.873] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Apr 21 22:44:30 >> 2016 >> [982589.883] (==) Using config file: "/etc/X11/xorg.conf" >> [982589.883] (==) Using system config directory "/usr/share/X11/xorg.conf.d" >> [982589.883] (==) No Layout section. Using the first Screen section. >> [982589.883] (==) No screen section available. Using defaults. >> [982589.883] (**) |-->Screen "Default Screen Section" (0) >> [982589.883] (**) | |-->Monitor "" >> [982589.893] (==) No monitor specified for screen "Default Screen Section". >> Using a default monitor configuration. >> [982589.893] (==) Not automatically adding devices >> [982589.893] (==) Not automatically enabling devices >> [982589.893] (==) Not automatically adding GPU devices >> [982589.893] (==) Max clients allowed: 256, resource mask: 0x1f >> [982589.893] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not >> exist. >> [982589.893] Entry deleted from font path
Bug#822286: libvulkan1: calls ldconfig multiple times
Package: libvulkan1 Version: 1.0.8.0+dfsg1-1 Severity: minor Hi, Another minor bug I just noticed :) libvulkan1 ships a postinst and postrm to call ldconfig, but the call to ldconfig is already handled by debhelper through a dpkg trigger. This means that installing libvulkan1 ends up calling ldconfig 3 times instead of once. Removing the maintainer scripts should solve this. Thanks, James signature.asc Description: This is a digitally signed message part
Bug#822284: vulkan: split validation layers out of libvulkan1
Source: vulkan Version: 1.0.8.0+dfsg1-1 Severity: wishlist Hi, Firstly I haven't be using Vulkan that long so I might not have this totally right but... It seems to me that the validation layer files (*.json, libVkLayer_*.so and liblayer_utils.so) are not required to actually run Vulkan applications but are only used during development. These files should therefore be in a separate package, possibly depended or recommended on by libvulkan-dev. This would shave about 9M off the installed package size as well. Thanks, James signature.asc Description: This is a digitally signed message part
Bug#822283: libvulkan1: typo in package description
Package: libvulkan1 Version: 1.0.8.0+dfsg1-1 Severity: minor Tags: patch Hi, The package description for libvulkan1 claims to include the "vulkaninfo" binary, but it does not - it's in vulkan-utils instead. While looking at the control file I also noticed that vulkan-utils depends on libvulkan1 which seemed strange (since it's added automatically) so I removed it, but feel free to ignore that bit of the patch if you want. Thanks, Jamesdiff -ur a/debian/control b/debian/control --- a/debian/control 2016-04-14 11:57:06.0 +0100 +++ b/debian/control 2016-04-22 23:06:30.906063978 +0100 @@ -25,7 +25,7 @@ this, it dispatches API calls to the correct driver, and to the correct layers, based on the GPU object selected by the application. . - This package includes the loader library and vulkaninfo binary. + This package includes the loader library. Package: libvulkan-dev Section: libdevel @@ -45,6 +45,5 @@ Architecture: any Section: graphics Depends: ${shlibs:Depends}, ${misc:Depends}, - libvulkan1, Description: Miscellaneous Vulkan utilities This package provides utilities for Vulkan, including vulkaninfo. signature.asc Description: This is a digitally signed message part
Bug#801847: Cannot type after X restart
Julien Cristau writes: > On Tue, Oct 27, 2015 at 22:32:15 -0200, Andre N Batista wrote: > > >> [ 2832.788] (EE) systemd-logind: failed to get session: The name >> org.freedesktop.login1 was not provided by any .service files > > You need to be running logind. Install the libpam-systemd package and > things should work better. > or install xserver-xorg-legacy.
Bug#801401: Workarounds for rootless Xorg
On Fri, Oct 23, 2015 at 5:01 AM, Lingzhu Xiang wrote: * Privilege to drmSetMaster() If there is only one drm device no setup is needed. This is an incorrect understanding of what drmSetMaster() does. It is not setting a primary device, it's the process claiming the DRM_MASTER capability, which is required for things like modesetting and authorising other drm clients' access to the device. Claiming DRM_MASTER requires root.
Bug#801401: cannot start X from the console command line
Julien Cristau writes: > On Mon, Oct 12, 2015 at 10:59:27 -0400, James Richardson wrote: > >> Package: xserver-xorg >> Version: 1:7.7+12 >> Followup-For: Bug #801401 >> >> Dear Maintainer, >> >> I resolved this on my workstation by installing xserver-xorg-legacy >> and adding the line >> >> needs_root_rights=yes >> >> to /etc/X11/Xwrapper.config >> >> >> In case it matters: my init system is runit, I run fluxbox via startx. > > It does. X won't work as non-root without logind: > >> [ 172.319] (EE) systemd-logind: failed to get session: The name >> org.freedesktop.login1 was not provided by any .service files I don't have systemd-logind installed, so obviously it will not get a systemd session, nor do I need such a thing. Other than that it works.
Bug#801614: xserver-xorg-legacy: ask for needs_root_rights in Xwrapper.config
Package: xserver-xorg-legacy Version: 2:1.17.2-3 Severity: wishlist Dear Maintainer, Would it be possible to add the line needs_root_rights=auto to Xwrapper.config and have debconf query the user for the proper value. (I need it set to yes in my particular config). If such a thing is indeed acceptable, I am willing to do the particulars... -- System Information: Debian Release: stretch/sid APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: unable to detect Versions of packages xserver-xorg-legacy depends on: ii debconf [debconf-2.0] 1.5.57 ii libaudit1 1:2.4.4-4 ii libc6 2.19-22 ii xserver-common 2:1.17.2-3 xserver-xorg-legacy recommends no packages. xserver-xorg-legacy suggests no packages. -- debconf information: * xserver-xorg-legacy/xwrapper/allowed_users: Console Users Only xserver-xorg-legacy/xwrapper/actual_allowed_users: console
Bug#801401: cannot start X from the console command line
Package: xserver-xorg Version: 1:7.7+12 Followup-For: Bug #801401 Dear Maintainer, I resolved this on my workstation by installing xserver-xorg-legacy and adding the line needs_root_rights=yes to /etc/X11/Xwrapper.config In case it matters: my init system is runit, I run fluxbox via startx. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Dec 11 2011 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Oct 6 03:35 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108GLM [Quadro 1000M] [10de:0dfa] (rev a1) /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. KMS configuration files: /etc/modprobe.d/i915-kms.conf: options i915 modeset=1 Kernel version (/proc/version): --- Linux version 4.2.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.3 (Debian 4.9.3-4) ) #1 SMP Debian 4.2.3-1 (2015-10-06) Xorg X server log files on system: -- -rw-r--r-- 1 root root 9410 Dec 14 2011 /var/log/Xorg.8.log -rw-r--r-- 1 root root 38010 Jul 27 18:15 /var/log/Xorg.1.log -rw-r--r-- 1 root root 34217 Oct 12 10:35 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [ 172.294] X.Org X Server 1.17.2 Release Date: 2015-06-16 [ 172.296] X Protocol Version 11, Revision 0 [ 172.296] Build Operating System: Linux 4.2.0-1-amd64 x86_64 Debian [ 172.297] Current Operating System: Linux weasel 4.2.0-1-amd64 #1 SMP Debian 4.2.3-1 (2015-10-06) x86_64 [ 172.297] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.2.0-1-amd64 root=/dev/mapper/vg00-root ro quiet [ 172.298] Build Date: 06 October 2015 07:27:47AM [ 172.299] xorg-server 2:1.17.2-3 (http://www.debian.org/support) [ 172.300] Current version of pixman: 0.33.2 [ 172.301]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 172.301] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 172.304] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Oct 12 10:35:32 2015 [ 172.309] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 172.310] (==) No Layout section. Using the first Screen section. [ 172.310] (==) No screen section available. Using defaults. [ 172.310] (**) |-->Screen "Default Screen Section" (0) [ 172.310] (**) | |-->Monitor "" [ 172.311] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 172.311] (==) Automatically adding devices [ 172.312] (==) Automatically enabling devices [ 172.312] (==) Automatically adding GPU devices [ 172.313] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 172.313]Entry deleted from font path. [ 172.317] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist. [ 172.317]Entry deleted from font path. [ 172.317] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist. [ 172.317]Entry deleted from font path. [ 172.317] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, built-ins [ 172.317] (==) ModulePath set to "/usr/lib/xorg/modules" [ 172.317] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 172.317] (II) Loader magic: 0x555adf6cbde0 [ 172.317] (II) Module ABI versions: [ 172.317]X.Org ANSI C Emulation: 0.4 [ 172.318]X.Org Video Driver: 19.0 [ 172.318]X.Org XInput driver : 21.0 [ 172.318]X.Org Server Extension : 9.0 [ 172.319] (EE) systemd-logind: failed to get session: The name org.freedesktop.login1 was not provided by any .service files [ 172.321] (II) xfree86: Adding drm device (/dev/dri/card0) [ 172.737] (--) PCI:*(0:1:0:0) 10de:0dfa:17aa:21cf rev 161, Mem @ 0xd200/16777216, 0xc000/268435456, 0xd000/33554432, I/O @ 0x5000/128, BIOS @ 0x/524288 [ 172.739] (II) LoadModule: "glx" [ 172.741] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 172.759] (II) Module glx: vendor="X.Org Foundation" [ 172.759]compiled for 1.17.2, module version = 1.0.0 [ 172.759]ABI class: X.Org Server Extension, version 9.0 [ 172.759] (==) AIGLX enabled [ 172.759] (==) Matched nouveau as autoconfigured driver 0 [ 172.759] (==) Matched nv as autoconfigured driver 1 [ 172.759] (==) Matched nouveau as autoconfigured driver 2 [ 172.759] (==) Matched nv as autoconfigured dr
Bug#800959: xserver-xorg-core: fails to upgrade with old version of x11-common installed
Package: xserver-xorg-core Version: 1.17.2-2 Severity: serious Hi, xserver-xorg-core does not upgrade to the version in experimental if the old version of x11-common is installed. # dpkg -l xserver-xorg x11-common xserver-xorg-core Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersion Architecture Description +++-===--- ii x11-common 1:7.7+9 all X Window System (X.Org) infrastructure ii xserver-xorg1:7.7+9 amd64 X.Org X server ii xserver-xorg-core 2:1.17.2-1.1 amd64 Xorg X server - core server # dpkg -i /var/cache/apt/archives/xserver-xorg_1%3a7.7+11_amd64.deb /var/cache/apt/archives/xserver-xorg-core_2%3a1.17.2-2_amd64.deb (Reading database ... 209469 files and directories currently installed.) Preparing to unpack .../xserver-xorg_1%3a7.7+11_amd64.deb ... Unpacking xserver-xorg (1:7.7+11) over (1:7.7+9) ... Preparing to unpack .../xserver-xorg-core_2%3a1.17.2-2_amd64.deb ... Unpacking xserver-xorg-core (2:1.17.2-2) over (2:1.17.2-1.1) ... dpkg: error processing archive /var/cache/apt/archives/xserver-xorg-core_2%3a1.17.2-2_amd64.deb (--install): trying to overwrite '/usr/share/man/man5/Xwrapper.config.5.gz', which is also in package x11-common 1:7.7+9 dpkg: dependency problems prevent configuration of xserver-xorg: xserver-xorg depends on xserver-xorg-core (>= 2:1.17.2-2); however: Version of xserver-xorg-core on system is 2:1.17.2-1.1. dpkg: error processing package xserver-xorg (--install): dependency problems - leaving unconfigured Processing triggers for man-db (2.7.3-1) ... Errors were encountered while processing: /var/cache/apt/archives/xserver-xorg-core_2%3a1.17.2-2_amd64.deb xserver-xorg Thanks, James signature.asc Description: This is a digitally signed message part
Bug#778187: xorg-server: ftbfs with GCC-5
Control: tags -1 patch fixed-upstream On Thu, 12 Feb 2015 10:38:13 + Matthias Klose wrote: > The package fails to build in a test rebuild on at least amd64 with > gcc-5/g++-5, but succeeds to build with gcc-4.9/g++-4.9. The > severity of this report may be raised before the stretch release. Fixed upstream. The patch applied there is attached. http://cgit.freedesktop.org/xorg/xserver/commit/?id=21b896939c5bb242f3aacc37baf12379e43254b6 Thanks, James From 21b896939c5bb242f3aacc37baf12379e43254b6 Mon Sep 17 00:00:00 2001 From: Egbert Eich Date: Tue, 3 Mar 2015 16:27:05 +0100 Subject: symbols: Fix sdksyms.sh to cope with gcc5 Gcc5 adds additional lines stating line numbers before and after __attribute__() which need to be skipped. Signed-off-by: Egbert Eich Tested-by: Daniel Stone Signed-off-by: Peter Hutterer diff --git a/hw/xfree86/sdksyms.sh b/hw/xfree86/sdksyms.sh index 2305073..05ac410 100755 --- a/hw/xfree86/sdksyms.sh +++ b/hw/xfree86/sdksyms.sh @@ -350,13 +350,25 @@ BEGIN { if (sdk) { n = 3; +# skip line numbers GCC 5 adds before __attribute__ +while ($n == "" || $0 ~ /^# [0-9]+ "/) { + getline; + n = 1; +} + # skip attribute, if any while ($n ~ /^(__attribute__|__global)/ || # skip modifiers, if any $n ~ /^\*?(unsigned|const|volatile|struct|_X_EXPORT)$/ || # skip pointer - $n ~ /^[a-zA-Z0-9_]*\*$/) + $n ~ /^[a-zA-Z0-9_]*\*$/) { n++; +# skip line numbers GCC 5 adds after __attribute__ +while ($n == "" || $0 ~ /^# [0-9]+ "/) { + getline; + n = 1; +} +} # type specifier may not be set, as in # extern _X_EXPORT unsigned name(...) -- cgit v0.10.2 signature.asc Description: This is a digitally signed message part
Bug#780656: xserver-xorg-input-evdev: Logitech wireless keyboard ignores locale in X.org, defaults to en-us
Package: xserver-xorg-input-evdev Version: 1:2.9.0-2 Severity: normal After upgrading a machine from squeeze to wheezy to jessie, my Logitech K400 wireless keyboard no longer functioned correctly. My locale is en-gb but key presses resulted in en-us characters appearing in applications running under X.org, for example the pipe symbol on the keyboard became a chevron on the screen. It appears to be an old bug filed (twice) in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/993827 https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/995715 There is a detailed explanation of the issue here: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/995715/comments/19 Linux kernel 3.2 introduced the logitech_dj HID driver to explicitly support the Logitech Unifying Receiver. This wireless USB hardware is designed for compatible mice and keyboards so that you only need one dongle for multiple devices. It worked fine for both mice and keyboards under squeeze, using a generic USB driver. However the xserver-xorg-input-evdev package does not seem to support this change of drivers, as far as keyboards are concerned. The workaround is for the display manager startup script to force the locale. In my case, I did this in ~/.fluxbox/startup with the line: setxkbmap gb Thanks! Daniel -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55082579.3040...@64studio.com
Bug#767869: xserver-xorg-video-vmware: (WW) vmware(0): Failed to initialize Gallium3D Xa. No render acceleration available.
Package: xserver-xorg-video-vmware Version: 1:13.0.2-3+b1 Severity: important Running Debian Jessie in VMware Fusion 7.0.1 on Mac OS 10.10. 3D accleration for guests is enabled in the VMware Fusion settings. When X starts, render acceleration fails to initialise. Relevant parts of Xorg.0.log below. [27.477] (II) vmware(0): Initialized VMWARE_CTRL extension version 0.2 [27.477] (WW) vmware(0): Failed to initialize Gallium3D Xa. No render acceleration available. [27.477] (WW) vmware(0): Skipped initialization of direct rendering due to lack of render acceleration. [27.478] (--) vmware(0): Render acceleration is disabled. [27.478] (==) vmware(0): Rendercheck mode is disabled. [27.478] (--) vmware(0): Direct rendering (3D) is disabled. [27.478] (==) vmware(0): Backing store disabled [27.478] (==) vmware(0): Silken mouse enabled [27.478] (II) vmware(0): RandR 1.2 enabled, ignore the following RandR disabled message. [27.478] (==) vmware(0): DPMS enabled [27.478] (II) vmware(0): No 3D acceleration. Not setting up textured video. .. .. .. [28.883] (II) AIGLX: Loaded and initialized swrast [28.883] (II) GLX: Initialized DRISWRAST GL provider for screen 0 -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Oct 22 10:30 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 2397280 Sep 22 23:49 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:0f.0 VGA compatible controller [0300]: VMware SVGA II Adapter [15ad:0405] /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. KMS configuration files: /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 3.16-3-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-12) ) #1 SMP Debian 3.16.5-1 (2014-10-10) Xorg X server log files on system: -- -rw-r--r-- 1 root root 61574 Oct 22 17:52 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [25.821] X.Org X Server 1.12.4 Release Date: 2012-08-27 [25.821] X Protocol Version 11, Revision 0 [25.821] Build Operating System: Linux 3.11-2-amd64 x86_64 Debian [25.821] Current Operating System: Linux jtvm 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2 x86_64 [25.821] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 root=UUID=56b6fb69-8c73-487a-94f8-b15453581301 ro quiet [25.821] Build Date: 17 December 2013 07:37:58PM [25.821] xorg-server 2:1.12.4-6+deb7u2 (Julien Cristau ) [25.822] Current version of pixman: 0.26.0 [25.822]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [25.822] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [25.822] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Oct 22 15:07:18 2014 [25.874] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [25.917] (==) No Layout section. Using the first Screen section. [25.917] (==) No screen section available. Using defaults. [25.917] (**) |-->Screen "Default Screen Section" (0) [25.917] (**) | |-->Monitor "" [25.918] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [25.918] (==) Automatically adding devices [25.918] (==) Automatically enabling devices [26.070] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [26.070]Entry deleted from font path. [26.276] (WW) The directory "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" does not exist. [26.276]Entry deleted from font path. [26.276] (==) 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 [26.276] (==) ModulePath set to "/usr/lib/xorg/modules" [26.276] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [26.276] (II) Loader magic: 0x7f708cbe5ae0 [26.276] (II) Module ABI versions: [26.276]X.Org ANSI C Emulation: 0.4 [26.276]X.Org Video Driver: 12.1 [26.276]X.Org XInput driver : 16.0 [26.276]X.Org Server Extension : 6.0 [26.285] (--) PCI:*(0:0:15:0) 15ad:0405:15ad:0405 rev 0, Mem @ 0xe800/134217728, 0xfe00/8388608, I/O @ 0x1070/16, BIOS @ 0x/32768 [26.286] (II) Open ACPI successful (/var/run
Bug#742475: xserver-xorg-dev: X comes up with black screen lower 1/2 ignores xrandr until TV output shut off
Package: xserver-xorg-dev Version: 2:1.15.0-2 Severity: important Tags: upstream Bug#742472 Dear Maintainer, * What led up to the situation? I installed a new install of Debian PPC on my iMacG5 and was trying to get X working properly The session using the default desktop opened very strangely with missing characters, distorted menus barely readable. Tried Xfce desktop and that worked considerably better. Tried Lxde and that opened with the bottom 1/2 of the desktop background in black. Windows would open, but if you maximized them the lower portions would not have text. If you dragged them with the mouse and made them larger, then they were all OK. In no case did X configure the external monitor. It would flash and report that it was being asked to do 12 hz refresh! * What exactly did you do (or not do) that was effective (or ineffective)? I tried to create an xorg.conf file. X -configure failed saying the number of screens was incorrect. I found a single-monitor xorg.conf where the TV output of the iMac was turned off, along with the external monitor output. That worked properly for the single built-in monitor. I tried to turn on the external monitor in xorg.conf, leaving the TV output off, but that failed. Also, the iMac screen showed a darker area that looked to be 1024x768, the highest mode of the TV output. I finally did xrandr --output TV-1 --off followed by xrandr --output VGA-1 --mode 1280x1024 left-of DVI-D-1 . * What was the outcome of this action? That cleared most of the problems, but left the external monitor as the primary monitor. I found that whatever monitor was told to be the left monitor would become primary. * What outcome did you expect instead? I expected that having the TV output (TV-1) on but nothing plugged into the connector would cause it to be ignored and that the external monitor would auto-configure (I had tried --output VGA-1 --auto and it did not work). I expected X -configure to make a proper xorg.conf file. -- System Information: Debian Release: 7.4 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: powerpc (ppc64) Kernel: Linux 3.2.0-4-powerpc64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xserver-xorg-dev depends on: ii libpciaccess-dev 0.13.1-2 ii libpixman-1-dev 0.32.4-1 ii libxkbfile-dev1:1.0.8-1 ii mesa-common-dev 9.2.2-1 ii x11proto-core-dev 7.0.23-1 ii x11proto-dri2-dev 2.8-2 ii x11proto-dri3-dev 1.0-1 ii x11proto-fonts-dev2.1.2-1 ii x11proto-gl-dev 1.4.17-1 ii x11proto-input-dev2.3-1 ii x11proto-kb-dev 1.0.6-2 ii x11proto-present-dev 1.0-1 ii x11proto-randr-dev1.4.0-2 ii x11proto-render-dev 2:0.11.1-2 ii x11proto-resource-dev 1.2.0-3 ii x11proto-scrnsaver-dev1.2.2-1 ii x11proto-video-dev2.3.1-2 ii x11proto-xext-dev 7.3.0-1 ii x11proto-xf86bigfont-dev 1.2.0-3 ii x11proto-xf86dri-dev 2.1.1-2 ii x11proto-xinerama-dev 1.2.1-2 xserver-xorg-dev recommends no packages. xserver-xorg-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5f36da21-8ecf-46ec-b0d0-8eb16e595...@gmail.com
Bug#699746: probably fixed upstream
Xprop(1) got a significant overhall a while back. This should work correcly now. That said, xterm(1) doesn’t do the right thing with such titles in that it stores them on the server as STRING where they ought to be stored as COMPOUND_TEXT for WM_NAME and WM_ICON_NAME and as UTF8_STRING for _NET_WM_NAME and _NET_WM_ICON_NAME (which xterm does not set at all). (The latter two props, of course, were created just to provided the names as UTF8_STRINGs rather than as COMPOUND_TEXT.) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 signature.asc Description: PGP signature
Bug#505893: seems fixed upstream
Unless this bug is specific to debian, this should be fixed in xmessage-1.0.4 with a current Xorg server. At least it does the right thing for me on my Gentoo workstation. (I only use debian on my servers) -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m3ha9p283k@carbon.jhcloos.org
Re: Help with linking with libglapi
On Fri, 2012-11-30 at 10:37 +0900, Norbert Preining wrote: > Dear maintainers of libglapi-mesa, > > I am trying to update asymptote to use OSmesa and the configure script > of it also checks for libglapi. THe check is done by compiling a simple > program and trying to link it with > ... -lglapi ... > Now that does not work, because there is no link > libglapi.so -> libglapi.so.0 > which would normally be shipped with a -dev package. > > Can you recommend a way how to fix this? Thanks a lot Is there a particular reason why it's attempting to link to libglapi? libglapi is essentially an implementation detail of mesa to allow multiple providers of GL symbols in the same process (eg: libGL and libGLESv2). Possibly the correct way to fix this is just to remove the check? signature.asc Description: This is a digitally signed message part
Bug#682099: xserver-xorg-video-ati: EXAPixmaps=On screen tearing at high resolution under certain configurations
> Can you try a newer kernel? 3.6 or 3.7? That may help with the > modesettings. As for the acceleration, corruption, you might try a > newer version of mesa. I cheated a little and tried the latest aptosid kernel linux-image-aptosid-amd64_3.6-12_amd64 - same screen corruption issues. I followed some documentation and started to compile and install the latest mesa on Sid... I gave up after a few hours and as a test installed Arch as it has a new Kernel 3.6.3-1 and the latest Mesa 9.0-1 - Still had screen corruption issues. Bad for a Debian bug report, sorry about that but I was getting a bit frustrated. I can't help but think it's something to do with the monitors. I mean, why would a different model monitor (Benq) that has native 1920x1080 work fine when used paired with one of my AOC's? But using the 2 identical model AOC's causes the problem? I am going to try fglrx on Arch for a test. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMALoy9fZt8CEVt0x3rSu=1c7u9m-5ul1sahhhqqph3feg5...@mail.gmail.com
Bug#682099: xserver-xorg-video-ati: EXAPixmaps=On screen tearing at high resolution under certain configurations
> The only other option I was going to try was using a Display port to > DVI adapter from the side of my laptop to replace the VGA from the > docking station. If I purchase one to try that I'll let you know. I bought a an Active display port adapter for my laptop. That won't even work with resolutions above 1280x1024 under Debian (works fine up to native 1980x1080 res on Windows 7). I wanted to use one of my monitors in portrait mode but the the rotation would not work if I had Option "NoAccel" "true". Of course disabling it meant I get the hideous screen corruption. All of this works fine on Windows 7 with DVI/VGA or Display Port so at least I can confirm it's not a hardware limitation. I am quite bummed to have this problem. Can anyone suggest ways in which I can troubleshoot/resolve it? Thanks -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/camaloy_qnu3_kwn9gc9jrw+koqjvzpreocnvdjt4zsgxe+t...@mail.gmail.com
apitrace in Debian
Hey all, I've wrangled apitrace back into a pretty-much acceptable form in alioth git¹. The main remaining query is (1) manpages (urgh), and (2) statically linked zlib, png, snappy. For (2), the wrapper libraries probably should use the statically linked libs, as they'll be interposed in to arbitrary executables and won't want to have possibly-conflicting versions. Which means fixing the UI tools to link against the system libraries. It all works, and the tracing wrappers (glxtrace.so and egltrace.so) are multiarched and the correct architecture is automatically loaded. Which is nice. I'm looking for a once-over review at this point, so I can happily bug Timo to upload when I've fixed the static linking. Chris signature.asc Description: This is a digitally signed message part
Bug#682099: xserver-xorg-video-ati: EXAPixmaps=On screen tearing at high resolution under certain configurations
Update... Setting option Option "NoAccel" "true" Has fixed the problem. I haven't noticed any problems having this enabled in the way I use my computer, videos, glxgears etc. all work ok. So I suppose this bug report can be closed if desired. The only other option I was going to try was using a Display port to DVI adapter from the side of my laptop to replace the VGA from the docking station. If I purchase one to try that I'll let you know. Regards, James -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/camaloy8cowo8foupomgxl0px1oj2hfwq6hla61ml_qpsztm...@mail.gmail.com
Bug#682099: xserver-xorg-video-ati: EXAPixmaps=On screen tearing at high resolution under certain configurations
On 2 August 2012 20:31, Michel Dänzer wrote: > Thanks. That's not what we generally call 'tearing' but looks like some > kind of intermittent display corruption. > > Unfortunately, I don't have any ideas offhand what could cause that. I did some more testing and it seems as though the monitor, combination of identical monitor models or VGA port on the monitors might be the issue. The monitors I am using are identical AOC's. Product Name: e2250Swda, Model No: 215LM00019. I had a older spare Benq monitor E2200HD with native resolution of 1920x1080 and swapped it with the VGA connected AOC. Everything worked fine on both displays with 1920x1080 without disabling EXAPixmaps! I then swapped it around so AOC on VGA and Benq on DVI and the corruption came back. I also swapped out the AOC's in case the issue was with one of them but same problem on both. Previously even if I disabled the VGA port with the AOC attached to it, the AOC on the DVI port would still get display corruption. With the Benq connected to VGA but disabled no corruption occurs on (either of) the DVI connected AOC. I have attached an xrandr --verbose for both combinations in case it shows something useful. I couldn't see anything that might explain why sorry. Thanks again. James Screen 0: minimum 320 x 200, current 3840 x 1080, maximum 8192 x 8192 DVI-0 connected 1920x1080+0+0 (0x55) normal (normal left inverted right x axis y axis) 477mm x 268mm Identifier: 0x51 Timestamp: 324965 Subpixel: horizontal rgb Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC: 0 CRTCs: 0 1 Transform: 1.00 0.00 0.00 0.00 1.00 0.00 0.00 0.00 1.00 filter: EDID: 000009d10c794554 27120103802f1a782e3585a656489a24 125054a56bba710081408100950f8180 9500b3000101023a801871382d40582c 4500dd0c111e00ff004e3938 30343134373032360a2000fd0032 4c1e5e15000a20202020202000fc 0042656e5120453232303048440a0042 load detection: 1 (0x0001) range: (0,1) underscan vborder: 0 (0x) range: (0,128) underscan hborder: 0 (0x) range: (0,128) underscan: off supported: off on auto coherent: 1 (0x0001)range: (0,1) 1920x1080 (0x55) 148.5MHz +HSync +VSync *current +preferred h: width 1920 start 2008 end 2052 total 2200 skew0 clock 67.5KHz v: height 1080 start 1084 end 1089 total 1125 clock 60.0Hz 1680x1050 (0x56) 146.2MHz -HSync +VSync h: width 1680 start 1784 end 1960 total 2240 skew0 clock 65.3KHz v: height 1050 start 1053 end 1059 total 1089 clock 60.0Hz 1280x1024 (0x57) 135.0MHz +HSync +VSync h: width 1280 start 1296 end 1440 total 1688 skew0 clock 80.0KHz v: height 1024 start 1025 end 1028 total 1066 clock 75.0Hz 1280x1024 (0x58) 108.0MHz +HSync +VSync h: width 1280 start 1328 end 1440 total 1688 skew0 clock 64.0KHz v: height 1024 start 1025 end 1028 total 1066 clock 60.0Hz 1440x900 (0x59) 136.8MHz -HSync +VSync h: width 1440 start 1536 end 1688 total 1936 skew0 clock 70.6KHz v: height 900 start 903 end 909 total 942 clock 75.0Hz 1440x900 (0x5a) 106.5MHz -HSync +VSync h: width 1440 start 1520 end 1672 total 1904 skew0 clock 55.9KHz v: height 900 start 903 end 909 total 934 clock 59.9Hz 1280x960 (0x5b) 108.0MHz +HSync +VSync h: width 1280 start 1376 end 1488 total 1800 skew0 clock 60.0KHz v: height 960 start 961 end 964 total 1000 clock 60.0Hz 1280x800 (0x5c) 83.5MHz +HSync -VSync h: width 1280 start 1352 end 1480 total 1680 skew0 clock 49.7KHz v: height 800 start 803 end 809 total 831 clock 59.8Hz 1152x864 (0x5d) 108.0MHz +HSync +VSync h: width 1152 start 1216 end 1344 total 1600 skew0 clock 67.5KHz v: height 864 start 865 end 868 total 900 clock 75.0Hz 1152x720 (0x5e) 67.3MHz -HSync +VSync h: width 1152 start 1208 end 1328 total 1504 skew0 clock 44.7KHz v: height 720 start 721 end 724 total 746 clock 60.0Hz 1024x768 (0x5f) 78.8MHz +HSync +VSync h: width 1024 start 1040 end 1136 total 1312 skew0 clock 60.1KHz v: height 768 start 769 end 772 total 800 clock 75.1Hz 1024x768 (0x60) 65.0MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew0 clock 48.4KHz v: height 768 start 7
Bug#682099: xserver-xorg-video-ati: EXAPixmaps=On screen tearing at high resolution under certain configurations
On 22 July 2012 13:20, James Robertson wrote: > On 21 July 2012 03:45, Michel Dänzer wrote: >> >> Can you elaborate on what exactly 'tearing and corruption' means? > > I have created a brief video to show the tearing. It occurs when > basically any input occurs such as typing, moving the mouse and as per > the video moving windows. > > https://docs.google.com/open?id=0B2vLcjUrgXL-aUdWekU0dE9qbHM > >> Does booting with radeon.disp_priority=2 on the kernel command line >> help? > > No > >> Please provide the output of xrandr --verbose for each case > > Please see attached txt file. > > On 21 July 2012 04:33, Alex Deucher wrote: >> Also note that rendering can only be synchronized to one head at a >> time to avoid tearing. If you have windows that span multiple heads, >> you may get tearing on the non-synced heads. > > I don't fully understand the technical side of what you have described > but wouldn't this mean tearing should only occur when using multiple > monitors? I get tearing on DVI-0 or VGA-0 standalone. > > I would also note that the tearing is worse when using both DVI-0 and > VGA-0 together. I also physically removed DVI-0 and visa versa for > VGA-0 and still had the problem. > > Thanks Whilst watching a flash video in Chromium this evening, I scrolled down the web page and noticed the tearing even when I had "EXAPixmaps" "off". The tearing was not as severe, but nonetheless occurred. As a quick test I tried setting the VGA-0 Display to 1680x1050 (DVI-0 still at 1920x1080) and it was fine. Using just DVI-0 standalone @1920x1080 also had tearing. Thanks -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMALoy_2OT00eyb+mjqMGCNQ=KnTZzb8M=napxitducp8tn...@mail.gmail.com
Bug#581398: kde4-window-decorator crash when starting
> Because nobody has shown any interest in working on it? Are you > volunteering? Ha! Can you give me a clue about what would be involved? I would naively suppose that all I have to do is download the latest release, add a "debian/" directory, and compile the application for a bunch of different architectures - not counting also needing a login on some debian server, to upload the packages. But then, I also suspect that it's not that simple. Still, one step at a time. What's to do? James -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1swxuu-0007bn...@jasper.nurealm.net
Bug#581398: kde4-window-decorator crash when starting
Still broken after all these years. Application: KDE Window Decorator (kde4-window-decorator), signal: Segmentation fault Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1". [KCrash Handler] #6 0xb6e7579b in QRasterWindowSurface::~QRasterWindowSurface (this=0x9759860, __in_chrg=) at painting/qwindowsurface_raster.cpp:117 #7 0xb6e75832 in QRasterWindowSurface::~QRasterWindowSurface (this=0x9759860, __in_chrg=) at painting/qwindowsurface_raster.cpp:121 #8 0xb6e90ce4 in QWidgetBackingStore::~QWidgetBackingStore (this=0x976be40, __in_chrg=) at painting/qbackingstore.cpp:909 #9 0xb6c99fbc in QWidgetBackingStoreTracker::destroy (this=0x9779660) at kernel/qwidget.cpp:217 #10 0xb6c9a118 in QWidgetPrivate::deleteExtra (this=0x96d57a8) at kernel/qwidget.cpp:1830 #11 0xb6c9a32c in QWidgetPrivate::~QWidgetPrivate (this=0x96d57a8, __in_chrg=) at kernel/qwidget.cpp:357 #12 0xb6c9a642 in QWidgetPrivate::~QWidgetPrivate (this=0x96d57a8, __in_chrg=) at kernel/qwidget.cpp:362 #13 0xb68ef0cb in cleanup (pointer=) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:62 #14 ~QScopedPointer (this=0x96247ec, __in_chrg=) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:100 #15 QObject::~QObject (this=0x96247e8, __in_chrg=) at kernel/qobject.cpp:817 #16 0xb6c9c50d in QWidget::~QWidget (this=0x96247e8, __in_chrg=) at kernel/qwidget.cpp:1551 #17 0xb5e2dc0a in ?? () from /usr/lib/libplasma.so.3 #18 0xb5e94c4b in ?? () from /usr/lib/libplasma.so.3 #19 0xb5e936cb in Plasma::Theme::~Theme() () from /usr/lib/libplasma.so.3 #20 0xb5e93a89 in ?? () from /usr/lib/libplasma.so.3 #21 0xb5da19e9 in ?? () from /usr/lib/libplasma.so.3 #22 0xb5a9c50f in __run_exit_handlers (status=0, listp=0xb5bc6324, run_list_atexit=true) at exit.c:78 #23 0xb5a9c57f in *__GI_exit (status=0) at exit.c:100 #24 0xb5a83e4e in __libc_start_main (main=0x804fe30, argc=2, ubp_av=0xbfc2ad44, init=0x8064550, fini=0x8064540, rtld_fini=0xb77f0300, stack_end=0xbfc2ad3c) at libc-start.c:260 #25 0x08050ab5 in ?? () The latest stable release of Compiz is 0.8.8, while the current debian version is 0.8.4-5.1, so I don't know how much sympathy there would be from the Compiz people. Anyone know how it is that debian _unstable_ is a couple of years and four minor releases behind upstream? Is this ultimately a bug in the Qt libraries? There is also idle curiosity here, http://forums.debian.net/viewtopic.php?f=6&t=73980 KDE + compiz crashes kde4 window decorator http://ubuntuforums.org/showthread.php?t=1475164 KDE4 Window Decorator Crashes with Compiz in Lucid Lynx 10.04 This is a thread to discuss Bug #572780 https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/572780 KDE4 Window Decorator Crashes with Compiz in Lucid Lynx 10.04 James -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1swtzw-00068j...@jasper.nurealm.net
Bug#641197: patch submitted
It appears as though a patch has been submitted for this. http://cgit.freedesktop.org/xorg/lib/libXft/commit/?id=6f1d7bcdd461b1f6cc64370793f52d7c170187d0 -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMALoy_2HyEoV=6iK=1f9eJ8EZ6oBTEzH=3uks6zrdwxgdq...@mail.gmail.com
Bug#641197: libxft2: Include Ubuntu LCD filter patch
Package: libxft2 Version: 2.2.0-3 Severity: wishlist Dear Maintainer, xft does not utilise the lcdfilter option. An example is when using Openbox and GTK2 based apps with the following configuration in ~/fonts.conf. lcddefault The result is that the fonts rendered by Openbox look slightly different to those rendered by GTK2. I researched and found that Ubuntu had added a patch in the following version that utilises lcdfilter: http://archive.ubuntu.com/ubuntu/pool/main/x/xft/xft_2.1.14-2ubuntu1.diff.gz I tested the patch on 2.2.0-3 and it has worked well and my Window Manager fonts now look the same as GTK2. Attached is the patch (100-libXft-2.1.10-lcd-filter-3.patch) -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libxft2 depends on: ii libc6 2.13-20 ii libfontconfig1 2.8.0-3 ii libfreetype6 2.4.6-2 ii libx11-6 2:1.4.4-1 ii libxrender11:0.9.6-2 ii multiarch-support 2.13-20 libxft2 recommends no packages. libxft2 suggests no packages. -- no debconf information --- a/src/xftdpy.c +++ b/src/xftdpy.c @@ -369,6 +369,10 @@ goto bail1; if (!_XftDefaultInitInteger (dpy, pat, FC_RGBA)) goto bail1; +#ifdef FC_LCD_FILTER +if (!_XftDefaultInitInteger (dpy, pat, FC_LCD_FILTER)) + goto bail1; +#endif if (!_XftDefaultInitBool (dpy, pat, FC_ANTIALIAS)) goto bail1; #ifdef FC_EMBOLDEN @@ -521,6 +525,14 @@ XftDefaultGetInteger (dpy, FC_RGBA, screen, subpixel)); } +#ifdef FC_LCD_FILTER +if (FcPatternGet (pattern, FC_LCD_FILTER, 0, &v) == FcResultNoMatch) +{ + FcPatternAddInteger (pattern, FC_LCD_FILTER, + XftDefaultGetInteger (dpy, FC_LCD_FILTER, screen, + FC_LCD_DEFAULT)); +} +#endif if (FcPatternGet (pattern, FC_MINSPACE, 0, &v) == FcResultNoMatch) { FcPatternAddBool (pattern, FC_MINSPACE, --- a/src/xftfreetype.c +++ b/src/xftfreetype.c @@ -469,6 +469,21 @@ goto bail1; } +#ifdef FC_LCD_FILTER +/* + * Get lcd_filter value + */ +switch (FcPatternGetInteger (pattern, FC_LCD_FILTER, 0, &fi->lcd_filter)) { +case FcResultNoMatch: + fi->lcd_filter = FC_LCD_DEFAULT; + break; +case FcResultMatch: + break; +default: + goto bail1; +} +#endif + /* * Get matrix and transform values */ --- a/src/xftglyphs.c +++ b/src/xftglyphs.c @@ -21,27 +21,18 @@ */ #include "xftint.h" -#include #if HAVE_FT_GLYPHSLOT_EMBOLDEN #include #endif -static const intfilters[3][3] = { -/* red */ -#if 0 -{65538*4/7,65538*2/7,65538*1/7 }, -/* green */ -{65536*1/4, 65536*2/4, 65537*1/4 }, -/* blue */ -{65538*1/7,65538*2/7,65538*4/7 }, +#if FREETYPE_MAJOR*1 + FREETYPE_MINOR*100 + FREETYPE_PATCH < 20202 +# error "FreeType 2.2.2 or later required to compile this version of libXft" #endif -{65538*9/13,65538*3/13,65538*1/13 }, -/* green */ -{65538*1/6, 65538*4/6, 65538*1/6 }, -/* blue */ -{65538*1/13,65538*3/13,65538*9/13 }, -}; + +#include FT_OUTLINE_H +#include FT_LCD_FILTER_H +#include FT_SYNTHESIS_H /* * Validate the memory info for a font @@ -69,6 +60,295 @@ font->glyph_memory, glyph_memory); } + +/* we sometimes need to convert the glyph bitmap in a FT_GlyphSlot + * into a different format. For example, we want to convert a + * FT_PIXEL_MODE_LCD or FT_PIXEL_MODE_LCD_V bitmap into a 32-bit + * ARGB or ABGR bitmap. + * + * this function prepares a target descriptor for this operation. + * + * input :: target bitmap descriptor. The function will set its + * 'width', 'rows' and 'pitch' fields, and only these + * + * slot :: the glyph slot containing the source bitmap. this + * function assumes that slot->format == FT_GLYPH_FORMAT_BITMAP + * + * mode :: the requested final rendering mode. supported values are + * MONO, NORMAL (i.e. gray), LCD and LCD_V + * + * the function returns the size in bytes of the corresponding buffer, + * it's up to the caller to allocate the corresponding memory block + * before calling _fill_xrender_bitmap + * + * it also returns -1 in case of error (e.g. incompatible arguments, + * like trying to convert a gray bitmap into a monochrome one) + */ +static int +_compute_xrender_bitmap_size( FT_Bitmap* target, + FT_GlyphSlotslot, + FT_Render_Mode mode ) +{ +FT_Bitmap* ftbit; +int width, height, pitch; + +if ( slot->format != FT_GLYPH_FORMAT_BITMAP ) +return -1; + +// compute the size of the final bitmap +ftbit = &slot->bitmap; + +width = ftbit->width; +height = ftbit->rows; +pitch = (width+3) & ~3; + +switch ( ftbit->pixel_mode ) +
Bug#635251: any news on multi-arch for libpciaccess?
On Mon, 2011-08-29 at 16:38 +0300, Riku Voipio wrote: > On Mon, Aug 29, 2011 at 05:48:44PM +1000, Christopher James Halse Rogers > wrote: > > The -dev package shouldn't be marked as multiarch; the i386 package is > > not parallel installable with the amd64 package as they both > > ship /usr/include. In general, my understanding is that -dev packages > > should not be multiarched (yet). > > It is ok to incude same files in multiarch coinstallable packages, as long as > they are identical on all archictectures. Think > /usr/share/doc/libpciaccess0/copyright > for example. Hence all -dev packages where headers are same on all > architectures > are safe for multiarch. Yeah. I was confused by the documentation on wiki.debian.org/MultiArch/Implementation which said "policy forbids -dev packages from being marked as Multi-Arch: same". As you say, that only applies where the contents of headers change across architectures. I've updated that documentation to hopefully be clearer. signature.asc Description: This is a digitally signed message part
Bug#635251: any news on multi-arch for libpciaccess?
On Wed, 2011-08-24 at 11:54 +0300, Riku Voipio wrote: > On Wed, Aug 24, 2011 at 09:51:08AM +0200, Julien Cristau wrote: > > On Wed, Aug 24, 2011 at 10:27:56 +0300, Riku Voipio wrote: > > > Any updates here? As a udev reverse dependency this is quite important > > > for earlt multi-arch conversion. > > > It'll probably happen on the next upload, but I'm not going to rush > > that. (What does this have to do with udev?) > > Looks like an ubuntuisim. needed inderectly for animated startup graphics, > sigh. No hurry on debian side then it seems. libdrm-intel now depends on libpciaccess, plymouth depends on libdrm-intel, and so on. The -dev package shouldn't be marked as multiarch; the i386 package is not parallel installable with the amd64 package as they both ship /usr/include. In general, my understanding is that -dev packages should not be multiarched (yet). I should apparently also read Debian bug reports more often. I'd just pushed a dh7 cleanup branch which also adds multiarch to the debian-experimental git branch before reading this mail. signature.asc Description: This is a digitally signed message part
Re: libpciaccess: Changes to 'dhify+multiarch'
On Mon, 2011-08-08 at 06:10 +, Christopher Halse Rogers wrote: > New branch 'dhify+multiarch' available with the following commits: > commit 8d5d28a71feb352574a22598487ef47ba7906ebf > Author: Christopher James Halse Rogers > Date: Mon Aug 8 15:40:09 2011 +1000 > > Switch to compat 9 for easy multiarch > > commit 0b100bef8fccb4ce362f6b1a29c2789b775c41a0 > Author: Christopher James Halse Rogers > Date: Mon Aug 8 15:38:23 2011 +1000 > > Bump standards version; no changes needed > > commit d7c5c5d8f6e11a2930518a80a76ec12645d4572d > Author: Christopher James Halse Rogers > Date: Mon Aug 8 13:15:54 2011 +1000 > > Switch to dh and compat 7. > > Also kill the *.la files, and dh_install --fail-missing. > Does anyone have any objections to me merging this into either sid or experimental (depending on preference)? It's now required for libdrm multiarch, and hence for mesa multiarch, and I'd really, really like to not be dependent on ia32-libs for mesa. signature.asc Description: This is a digitally signed message part
Re: [RFC] proposal for reorganizing the MESA libraries to simplify replacing them with vendor implementations
On Fri, 2011-07-22 at 21:12 +0200, Cyril Brulebois wrote: > Julien Cristau (22/07/2011): > > So in principle I dislike the idea of making the mesa packages messier > > to make the closed driver packages' life easier. One thing that's been > > a source of countless bug in the current system is diversions, because > > they're evil, and people keep getting them wrong, and users don't > > understand/expect them, and all kinds of fun ensues. If mesa were to > > not ship the /usr/lib/$arch/libGL.so.1 (and friends) symlink, but > > instead ship an alternative itself, would that be enough to put an end > > to the diversions? Not that I think alternatives are ideal either, but > > if we're going to have to put up with something I'd rather it wasn't > > *both* alternatives and diversions. > > > > Not sure what other X people think. > > I'd rather avoid the mess of diversions *AND* alternatives indeed. If > adding alternative support to mesa is the price to pay, I guess we could > work something out. > > Please note I'm very busy right now, consequently far behind on anything > X-related; sorry for that. > In Ubuntu we use an alternatives system for switching between libGL (and, soon, libEGL) implementations. We indeed had endless troubles with the diversions we used to have; the alternatives system seems to have been significantly less trouble. We ship the GL implementations in a private directory and use a ld.so.conf snippet hung off the $DEB_HOST_MULTIARCH_GL_conf alternative to add that directory to the library search path. The proprietary drivers hang a bunch of other stuff off that alternative, too: modprobe blacklists to prevent nouveau/radeon loading, their annoyingly special libglx xorg modules, that sort of thing. Based on my informal impressions, I think this single-switch approach has resulted in fewer bugs where users are using a broken mix of proprietary/open pieces of the stack. Bryce would probably have better metrics on that. If it's desired I'd be very happy to add the equivalent to the Debian mesa packages, since it'd significantly reduce the Ubuntu changes we're carrying. signature.asc Description: This is a digitally signed message part
Re: handling proprietary vendor libs for OpenGL ES [Was: implement gles-alternatives like glx-alternatives]
On Mon, 2011-07-18 at 13:50 +0200, Heiko Stübner wrote: > Hi, > > short summary for debian-x: > It seems that also on embedded systems vendors start shipping proprietary > graphics drivers and OpenGL ES implementations like NVidia and AMD do for x86. > Therefore I talked to Andreas on what would be the best way to implement a > functionality like glx-alternatives for the OpenGL ES libs. > > Driver candidates I know off are: > - NVidia Tegra (http://tegradeveloper.nvidia.com/tegra/forum/linux-tegra- > release-12-alpha-1-released) > - Omap4 (http://launchpad.net/~tiomap-dev) > - Omap3 > and probably more. > > > Am Montag, 18. Juli 2011, 01:44:09 schrieb Andreas Beckmann: > > On 2011-07-16 22:26, Heiko Stübner wrote: > > > Hi, > > > > > > glx-alternatives provides the means to have more than one libGL and glx > > > implementation on a machine. > > > > > > I'm working on the Toshiba AC100 (NVidia Tegra ARM SoC) which also got a > > > proprietary driver released two weeks ago [1]. > > > > > > Tegra, like Omap, and probably other SoCs support "only" OpenGL ES (1 and > > > 2) wich is also provided by Mesa libs. > > > > > > So I was wondering what would be the best way to realise a diversion > > > system like glx-alternatives for the OpenGL ES stuff. > > > > I think we should include the MESA packagers to see how they intended to > > make glx/gles and vendor implementations working together (I do know > > nothing about egl/gles). > > Please repost your question (and my comments below and eventual answers > > to them) including debian-x@lists.debian.org in the Cc: > > > Possibilities I came up with were: > > > - build a completely separate gles-alternatives source package realising > > > the same functionality like glx-alternatives > > > > Is there any library (and diversion) overlap between glx and gles? > > yes -> merge with glx-diversions > > no -> separate packages (but eventually still the same source package > > for better code sharing) > there seems to be no overlap library-wise between OpenGL and OpenGL ES (1 and > 2) for the ones vendors want to replace. > Therefore my thoughts were on simply letting glx-alternatives also build > packages for handling OpenGL ES stuff (i.e. gles-diversions, gles-alternative- > tegra, ... like the glx-* packages) but sharing the same source package for > the code sharing you mentioned. > > > > > Libs that need to be diverted most of the time are libEGL.so.1, > > > libGLESv1_CM.so.1 and libGLESv2.so.2 (at least for Tegra and Omap4[2] ). > > > > Is libEGL.so.1.0 (from package libegl1-mesa) a "fixed" filename or is it > > expected to be changed regularily? (libGL.so.1.2 from libgl1-mesa-glx is > > "fixed", but libgl1-mesa-swx11 provides libGL.so.5.* which changes with > > each upstream version and is therefore not divertible). > > Same question for the other libraries. > Hopefully one of the mesa-guys can answer this :-) > > Libraries in question are: > - libGLESv1_CM.so.1.1.0 > - libGLESv2.so.2.0.0 > - libEGL.so.1.0 Filenames which *are* fixed are libGLESv1_CM.so.1, libGLESv2.so.2 and libEGL.so.1, as those are the SONAMEs of the respective libraries. I wouldn't guarantee that the filenames listed above won't change (I'm somewhat surprised it isn't libEGL.so.1.4, for example). dpkg-divert should be happy to divert those symlinks, right? Chris signature.asc Description: This is a digitally signed message part
Re: mesa: Changes to 'debian-experimental'
On Tue, 2011-06-21 at 18:51 +0200, Cyril Brulebois wrote: > Hi Michel, > > thanks for keeping an eye on the commits. > > Michel Dänzer (20/06/2011): > > This is wrong. r300g works fine without LLVM. The reason for the > > dependency is that without LLVM, Gallium's software vertex processing is > > very slow. But this only affects integrated GPUs without vertex shaders, > > which are only available for x86 CPUs. > > AFAICT, configure disagrees. But it's strange-ish anyway, so it might > just need some targeted patching. > > > > commit 7d332507bbffa1fdb59723808ef39b9e50983e16 > > > Author: Cyril Brulebois > > > Date: Sun Jun 19 15:37:18 2011 +0200 > > > > > > Stop building i915g at all. > > > > > > It's apparently never going to be a suitable replacement for i915c. > > It's also worth noting that even without shipping i915g_dri it might be worth building i915g to get OpenVG support - egl_dri2 can load the classic driver for GLES support, but only the gallium pipe drivers support OpenVG. signature.asc Description: This is a digitally signed message part
Bug#612529: Upstream status
The status of the Ubuntu patch upstream, as best I can remember it, is that they think it's fixing the problem in the wrong place. The libc dynamic loader is meant to have some special magic set aside so that at least some TLS code with the initial-exec class can be loaded, but this clearly isn't working properly. I started investigating this, then got busy with other things. signature.asc Description: This is a digitally signed message part
Bug#627367: xkb-data: Upgrade from 1.8 to 2.1 adds deadkeys to dvorak-intl
Package: xkb-data Version: 2.1-2 Severity: normal In commit b611a52d8 upstream kindly renamed dvorak-intl (which did not have dead keys) to dvorak-alt-intl. dvorak-intl now has dead keys, so upgrades from 1.8 or earlier to 2.1 will switch the user's keyboard behaviour. On upgrade from <= 1.8 we should transition users from dvorak-intl to dvorak-alt-intl. See also https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/742683, but I've verified this also affects Debian by upgrading an oldstable chroot to wheezy. -- System Information: Debian Release: squeeze/sid APT prefers natty-updates APT policy: (500, 'natty-updates'), (500, 'natty-security'), (500, 'natty') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-8-generic (SMP w/2 CPU cores) Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110520035757.12275.89629.reportbug@Ed
Bug#622606: xserver-xorg-video-r128: [regression] [powerpc] X dies with SIGBUS if I tell it "UseFBDev" "false"
On Wed, 13 Apr 2011 08:08:00 -0300 Rogério Brito wrote: RB> X-Debbugs-CC: debian-powe...@lists.debian.org RB> Package: xserver-xorg-video-r128 RB> Version: 6.8.1-5 RB> Severity: important RB> RB> Hi there. RB> RB> This is a PowerPC (iBook G3), with a R128 video card and with a very RB> recent kernel (2.6.38), all from Debian, none compiled by me. RB> RB> As per bug #484015 (see my comments there), I have to provide an RB> xorg.conf file or I get a completely screwed X. RB> RB> When I use the file attached below by the bug script, I get a SIGBUS RB> when I tell the X server that I want to disable UseFBDev. This is a RB> regression of, at least, version 1:6.8.0-1 of the driver. RB> RB> I am attaching the last log from X here. If any further information RB> is desired, please let me know. RB> RB> RB> Regards. I've got a similar machine that I just resurrected to test for endian-ness issues in a project I'm working on. I'm using the xorg.conf that was recommened to me a couple of weeks ago: http://mac.linux.be/content/xorgconf-ibook-g3-500-dual-usb-0 Changing UseFBDev to "false" with that configuration does not cause a problem, though I think (I've not done any detailed comparison) that it is a little slower (maybe 5%). As for needing an xorg.conf -- I think that the problem is that the screen does not send valid EDID information (presumably Apple were cutting corners and built OSX to know the screen capability from the machine's identity). IMHO -- Xorg needs to have a manual fallback that asks for information if there is neither an xorg.conf nor valid EDID and then creates an xorg.conf. -- ++---+-+ | James Tappin | School of Physics & Astronomy | O__| | s...@star.sr.bham.ac.uk | University of Birmingham | -- \/` | | Ph: 0121-414-6462. Fax: 0121-414-3722 | | ++-+ -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110415144950.6a31d131@star.sr.bham.ac.uk
Bug#576326: xserver-xorg: keys repeat without being held down
On Sat, Feb 26, 2011 at 12:53:30PM +0100, Cyril Brulebois wrote: > is that still happening with squeeze or higher? If so, please follow > up with more info: > http://pkg-xorg.alioth.debian.org/howto/report-bugs.html Thanks for following up. The affected host is currently tracking wheezy, updated weekly, last updated on Friday, and the symptom has not been seen for some months. Currently on 1:7.5+8 of xserver-xorg. On the other hand, having learned not to place the system under memory pressure, it is possible my learning has prevented the symptom from happening. I've just done a test by creating a workload (three parallel builds and an rsync of television transport stream), and was unable to reproduce the symptom. On that basis, assuming the other user no longer sees the problem, I think the bug can be closed. I'm interested to know if the problem was fixed though. There's nothing relevant in the changelog.gz for 1:7.5+6 onwards. Perhaps kernel? Was 2.6.30-2-686 now 2.6.32-5-686 . -- James Cameron http://quozl.linux.org.au/ -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110227234406.gc4...@us.netrek.org
Bug#578082: xserver-xorg-video-intel: xorg freezes and locks keyboard/mouse when switching to a virtual terminal
Original Message From: Cyril Brulebois [mailto:k...@debian.org] Sent: Tuesday, February 22, 2011 2:31 PM To: James Zuelow; 578...@bugs.debian.org Subject: Re: Bug#578082: xserver-xorg-video-intel: xorg freezes and locks keyboard/mouse when switching to a virtual terminal > > what's the status with squeeze? Or sid? > > KiBi. I do not see this behaviour with Squeeze. I'm not running any Sid machines to test, but I can set one up if need be. I think this is resolved. James -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4A09477D575C2C4B86497161427DD94C15C2C4B847@city-exchange07
Bug#556064: FTBFS with binutils-gold
On Thu, Feb 10, 2011 at 1:41 PM, Julien Cristau wrote: > On Fri, Jan 15, 2010 at 21:55:24 -0500, James Vega wrote: > >> reassign 556064 libxft-dev 2.1.12-3 >> retitle 556064 fontconfig incorrectly listed as a private library >> thanks >> >> As shown below, the patch introduced in #389831 incorrectly moved >> fontconfig to Requires.private. Thus, packages linking against Xft with >> --no-add-needed (or binutils-gold) FTBFS. This can also be verified by >> seeing that many of the symbols defined by Xft are simply a #define of >> XftFoo to FcFoo. >> > All those macros are in the XftCompat header though, which seems to > imply that users should use the fontconfig names instead nowadays, and > link to fontconfig themselves? > A similar change is now upstream in libXft 2.2.0 fwiw: > http://cgit.freedesktop.org/xorg/lib/libXft/commit/?id=8751e341bcc29952b4603e18767ab994653c6b01 I don't see any includes for XftCompat, only Xft.h, in the plt-scheme code (well the wxxt code they were using) that was failing. Regardless, plt-scheme (now racket) has removed the code that was using this, so it doesn't affect me anymore. Hmm, looking into it, Xft.h includes XftCompat.h unless _XFT_NO_COMPAT_ is defined and portions of their API still directly ask for (XftTextExtents*) and return (XftFontMatch) fontconfig types. If the expectation is that Xft users shouldn't be using either the XftCompat defines or XftFontMatch and as such don't need to link against fontconfig, I'm fine with that but it should be called out in the documentation and noted that doing so does require explicit linking against fontconfig. Instead, they're currently taking the route of providing API compatibility but dropping the required information to actually build with that compatibility, as I understand it. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimuauyuinbyoiq-o0wdtwbaqc+tzsa9ku451...@mail.gmail.com
Re: Upcoming package updates
On Wed, 2011-02-02 at 06:47 +0100, Cyril Brulebois wrote: > Hi folks, > > xsfbs was nice once upon a time, since it made it possible to handle > several repetitive tasks: > - patching/unpatching. > - computing substitution variables. > - generating maintainer scripts using macros. > > Now, during the last year, I've noticed the following: > - a simple mistake in xsfbs (e.g. the dependency issue we have when >patching, leading to unnecessary rebuilds) has to be fixed once but >merged into each package. That's not really nice. And quilt makes >it easy to get patches applied/unapplied today, either through >quilt.mk or through dh --with quilt. > - when updating the method used to compute substitution variables, >one has to merge it into all drivers, which is also not >nice. Shipping a script in xserver-xorg-dev (and consequently >bumping the build-dep on it) and calling it from drivers' rules >file is sufficient. Code duplication goes away. Hence the proposed >dh_xsf_substvars proposed on [1]. If that script needs tweaking, >it'll probably happen with a new major version, meaning we'd have >to bump the build-dep on xserver-xorg-dev anyway. Or we could just >handle this through binNMUs. > - a really small number of drivers (didn't check other packages yet) >use maintainer scripts. We could probably replace xsfbs macros with >dpkg-maintscript-helper. Or keep xsfbs merged into those for a >while. > > Also, trying to lower the packaging noise, I'm quite tempted to just > use dh, so that only non-trivial bits appear in debian/rules, see > libxkbcommon's rules file for example [2]. > I, too, like the way dh makes the interesting parts of the packaging obvious by omitting all the non-interesting bits. Also, unlike CDBS, it's quite straightforward to make the interesting bits happen :). > It would mostly boils down to something based on: > | #!/usr/bin/make -f > | > | %: > | dh $@ --with autoreconf,quilt --builddirectory=build/ > > I've pushed an update to -evdev to a personal repository on alioth > [3,4] to show another example. > > If we want to refine it a little bit more, we could also ship an xsf > sequence in xserver-xorg-dev. At the moment, it would just ensure > dh_xsf_substvars gets called before dh_gencontrol. But it could also > be used to run some other dh_xsf_* commands at some other places, > should we ever need more xsf-specific stuff. The call would then > become: > | %: > | dh $@ --with autoreconf,quilt,xsf --builddirectory=build/ > I'm a fan of automating common tasks. I think this might also be helpful in getting the small, but annoying, number of drivers that aren't maintained by the XSF to properly declare dependencies. > Finally, I'm not sure we need to build out-of-tree. It's easy to > clean, but I guess we could just fix clean targets if they break. As > far as auto*-related files, they are taken care of by dh-autoreconf, > so the debian clean target does its job properly. So I guess we could > get rid of --builddirectory=build/ as well. Of course, building OOT is > the way to go for the small amount of packages with several flavours. > I think that out-of-tree interacts poorly with ccache, but (a) that could be PEBKAC, and (b) for the packages where ccache is interesting we need to do out-of-tree builds anyway for the multiple flavours. I'm therefore of no strong opinion on out-of-tree. > > References: > 1. http://pkg-xorg.alioth.debian.org/reference/dependencies.html > 2. > http://git.debian.org/?p=pkg-xorg/lib/libxkbcommon.git;a=blob;f=debian/rules > 3. http://git.debian.org/?p=users/kibi/pkg-xorg/xserver-xorg-input-evdev.git > 4. > http://git.debian.org/?p=users/kibi/pkg-xorg/xserver-xorg-input-evdev.git;a=blob;f=debian/rules;hb=debian-experimental > > > Any drawback/objection for any of this? Summarizing: > - kiss xsfbs good bye. > - new dh_xsf_substvars in xserver-xorg-dev. > - probable move to dpkg-maintscript-helper where needed. > - switch to dh. > - ship a dh sequence. > - stop building OOT for single-flavoured packages. > > I might wait for the new upstream release (candidate?) of the server > to upload a dh_xsf_substvars-enabled xserver-xorg-dev package, so that > we can bump the build-dep in drivers to a new upstream release, rather > than having to remember the debian-specific revision in which this > command got introduced. (Preparing drivers in git should keep me busy > already.) > > KiBi. signature.asc Description: This is a digitally signed message part
Re: mesa: Changes to 'debian-experimental'
On Mon, 2011-01-24 at 17:40 +0100, Cyril Brulebois wrote: > Christopher Halse Rogers (24/01/2011): > > debian/changelog |4 +++- > > debian/libopenvg1-mesa.symbols | 12 > > 2 files changed, 15 insertions(+), 1 deletion(-) > > You know, you could have replied to my mail from yesterday [1] instead > of duplicating work… > > 1. http://lists.debian.org/debian-x/2011/01/msg00728.html Sorry. I didn't see that mail before starting work! signature.asc Description: This is a digitally signed message part
Re: Ubuntu plans for Natty release
On Fri, 2010-11-26 at 08:44 +0100, Michel Dänzer wrote: > On Fre, 2010-11-12 at 12:32 +1100, Christopher James Halse Rogers > wrote: > > On Thu, 2010-11-11 at 13:06 +0100, Michel Dänzer wrote: > > > On Don, 2010-11-11 at 12:26 +1100, Christopher James Halse Rogers > > > wrote: > > > > > > > Can you see an easy solution which allows changes during X's runtime and > > > > will handle UMS transparently? > > > > > > One possibility would be an r[36]00_dri.so wrapper which can pass > > > through to the classic or Gallium drivers based on KMS vs. UMS and > > > configuration via environment variables and/or configuration files. This > > > might be appropriate for upstream as well. > > > > > That sounds an awful lot like work :). > > I've thought of a simpler possible solution: > > * Fix the Gallium drivers to bail gracefully instead of crashing > with UMS (this will need to happen anyway). > * Ship the classic and Gallium drivers in separate directories and > set the libGL search path such that the two directories will be > tried one after another. > > r300g would be in the first directory searched. With UMS, it would fail > to initialize, and libGL would pick up r300 from the second directory. > > This solution would also allow overriding the default driver with > $LIBGL_DRIVERS_PATH. > > I really hope you don't have to stick with your ugly X driver patch. :} > That sounds like a good plan. Do you know off the top of your head how much of this is already ready? signature.asc Description: This is a digitally signed message part
Re: Ubuntu plans for Natty release
On Thu, 2010-11-11 at 13:06 +0100, Michel Dänzer wrote: > On Don, 2010-11-11 at 12:26 +1100, Christopher James Halse Rogers > wrote: > > On Wed, 2010-11-10 at 09:33 +0100, Michel Dänzer wrote: > > > On Mit, 2010-11-10 at 18:57 +1100, Christopher James Halse Rogers > > > wrote: > > > > > > > > 1) Ship both the classic and gallium versions of r300 & r600, and have > > > > the DDX select between them based on kms support and an xorg.conf > > > > setting (default to r300g, as that's the default upstream, and whichever > > > > r600 driver ends up being default in 7.10). This is not going to be > > > > accepted upstream, but is, I think, a reasonable distro-patch to retain > > > > UMS support for radeon while defaulting to the upstream-default driver. > > > > > > IMHO any solution which doesn't allow easily choosing between the 3D > > > drivers during the X server's runtime (when KMS is enabled) isn't > > > adequate. > > > > Certainly not adequate for driver development, > > Actually, driver developers probably tend to have their own custom > setups anyway. > > > but is it necessary for end-users? This would be necessary for > > allowing per-application overrides, but should we care about this? > > Probably not as long as the default 3D driver works (well enough), but > e.g. for comparing between the 3D drivers it would be much more > convenient and save nerves and time, also for bug triagers. > > > > Can you see an easy solution which allows changes during X's runtime and > > will handle UMS transparently? > > One possibility would be an r[36]00_dri.so wrapper which can pass > through to the classic or Gallium drivers based on KMS vs. UMS and > configuration via environment variables and/or configuration files. This > might be appropriate for upstream as well. > That sounds an awful lot like work :). Also, my understanding was that UMS / classic mesa would not be particularly supported upstream. If you'd welcome such a patch, maybe that work is justified. I was only expecting to carry this dual-stack UMS/KMS hack for one release, maybe two, and then not caring at all about UMS after that. > However, given that switching to UMS will require some kind of tweaking > anyway, I'm not sure why the script / procedure for that couldn't just > include appropriate update-alternatives calls. > The trick is getting all the users to see the same documentation :). signature.asc Description: This is a digitally signed message part
Re: Ubuntu plans for Natty release
On Wed, 2010-11-10 at 13:58 -0800, Eric Anholt wrote: > On Wed, 10 Nov 2010 18:57:45 +1100, Christopher James Halse Rogers > wrote: > > Hey all. > > > > There are a couple of things in mesa that we'd like to do for Natty that > > could do with some coördination with Debian-X: > > > > 1) Ship both the classic and gallium versions of r300 & r600, and have > > the DDX select between them based on kms support and an xorg.conf > > setting (default to r300g, as that's the default upstream, and whichever > > r600 driver ends up being default in 7.10). This is not going to be > > accepted upstream, but is, I think, a reasonable distro-patch to retain > > UMS support for radeon while defaulting to the upstream-default driver. > > > > 2) As always, we need more space on the CDs. The DRI drivers are both > > large (~44MB) and contain substantial quantities of common code. Fedora > > at one point linked their DRI drivers with a shared libdricore¹, and I'm > > looking at doing something similar for the gallium drivers. This shaves > > about 30MB off the DRI drivers on AMD64 - down to 12MB, without touching > > the gallium drivers. > > > > Are either of these interesting to debian-x? Should I be committing > > these changes to the debian branches, or keeping them Ubuntu-specific? > > > > Also, > > 3) We'll possibly strip out all the less-used (ie: non-intel, > > non-radeon) DRI drivers into a separate package & add jockey hooks for > > users to install them if needed. That's not going to be so interesting > > for Debian, though. > > I'd like to see libdricore patches pushed upstream as a build option if > it's not too invasive. Fedora dropped them because they got tired of > porting them forward, but I think at the point where two+ distros and > half the mesa developers want the patch in place, we should just shove > it in. Fair enough. I'll see how upstream-friendly I can make them, then submit them. signature.asc Description: This is a digitally signed message part
Re: Ubuntu plans for Natty release
On Wed, 2010-11-10 at 11:27 +0100, Cyril Brulebois wrote: > Christopher James Halse Rogers > (10/11/2010): > > There are a couple of things in mesa that we'd like to do for Natty that > > could do with some coördination with Debian-X: […] > > Unfortunately I haven't played with mesa at all yet, so I can't > comment for now. I guess I would prefer having your work kept in the > ubuntu branches for now. > No problem. I'll make sure it's easy to cherry-pick should you end up wanting it. signature.asc Description: This is a digitally signed message part
Re: Ubuntu plans for Natty release
On Wed, 2010-11-10 at 09:33 +0100, Michel Dänzer wrote: > On Mit, 2010-11-10 at 18:57 +1100, Christopher James Halse Rogers > wrote: > > > > 1) Ship both the classic and gallium versions of r300 & r600, and have > > the DDX select between them based on kms support and an xorg.conf > > setting (default to r300g, as that's the default upstream, and whichever > > r600 driver ends up being default in 7.10). This is not going to be > > accepted upstream, but is, I think, a reasonable distro-patch to retain > > UMS support for radeon while defaulting to the upstream-default driver. > > IMHO any solution which doesn't allow easily choosing between the 3D > drivers during the X server's runtime (when KMS is enabled) isn't > adequate. > Certainly not adequate for driver development, but is it necessary for end-users? This would be necessary for allowing per-application overrides, but should we care about this? Mainly I'm concerned with ensuring that users who turn off KMS get 3D. I don't expect upstream to care or support this; focusing on kms/gallium is a perfectly reasonable decision to make. From our end though, if UMS is *not too much effort* to keep going then it's both useful for debugging (when UMS works & KMS doesn't) and allows people to have a usable system while those bugs are being fixed. Changing the DRI driver name when using UMS seems like the simplest solution here, and once we're doing that it's close to no extra effort to add an xorg.conf option for users to twiddle. Can you see an easy solution which allows changes during X's runtime and will handle UMS transparently? signature.asc Description: This is a digitally signed message part
Ubuntu plans for Natty release
Hey all. There are a couple of things in mesa that we'd like to do for Natty that could do with some coördination with Debian-X: 1) Ship both the classic and gallium versions of r300 & r600, and have the DDX select between them based on kms support and an xorg.conf setting (default to r300g, as that's the default upstream, and whichever r600 driver ends up being default in 7.10). This is not going to be accepted upstream, but is, I think, a reasonable distro-patch to retain UMS support for radeon while defaulting to the upstream-default driver. 2) As always, we need more space on the CDs. The DRI drivers are both large (~44MB) and contain substantial quantities of common code. Fedora at one point linked their DRI drivers with a shared libdricore¹, and I'm looking at doing something similar for the gallium drivers. This shaves about 30MB off the DRI drivers on AMD64 - down to 12MB, without touching the gallium drivers. Are either of these interesting to debian-x? Should I be committing these changes to the debian branches, or keeping them Ubuntu-specific? Also, 3) We'll possibly strip out all the less-used (ie: non-intel, non-radeon) DRI drivers into a separate package & add jockey hooks for users to install them if needed. That's not going to be so interesting for Debian, though. ¹: http://pkgs.fedoraproject.org/gitweb/?p=mesa.git;a=blob;f=mesa-7.1-link-shared.patch;h=592e2e2163e8e06a1607dcaa5608024dab196745;hb=HEAD -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1289375866.5263.4.ca...@ed
EGL/GLES virtual packages
Hey all. As I mentioned on #debian-x yesterday, we're going to get some proprietary implementations of libEGL and libGLES and I think it would be good if we had a set of virtual packages for them. I therefore propose the following virtual packages: libgles1 libgles2 libegl-x11 There was concern that there's not necessarily a well-defined meaning for these packages. Reading the Khronos implementors guide¹ it looks like there's an official “strongly recommended” ABI defined for the GL| ES APIs. We could therefore define those virtual packages to provide that Khronos ABI, which looks well-defined to me. For EGL it is a little different - the ABI seems to be dependent on what EGLNativeDisplayType is. It looks like you need to initialise an EGLDisplay from an EGLNativeDisplayType which you've constructed yourself outside the EGL interface. Thus, the EGL ABI is backend-dependent, so we define a libegl-x11 virtual package for a libEGL with EGLNative*Types using the Khronos-defined X11 types. [1]: http://www.khronos.org/registry/implementers_guide.html#uncontrolled signature.asc Description: This is a digitally signed message part
Bug#546741: Kernel patches
The kernel patches on that upstream page were incorporated into the mainline kernel around 2008. They're no problem. So an xf86-video-sis-imedia source package is feasible, although ugly. Merging the 671/771 support into the freedesktop.org driver would clearly be better, but… urgh that's a big diff. signature.asc Description: This is a digitally signed message part
Bug#583346: xserver-xorg-input-synaptics: TapButton1 configuration option not respected in xorg.conf
Hi, I had this problem too, and worked out it was the GNOME mouse preferences. Touchpad/Enable mouse clicks with touchpad was disabled. There's also an option to enable two-finger and horizontal scrolling. http://who-t.blogspot.com/2010/06/incomplete-roundup-of-touchpad-features.html has a list of what features can be controlled from the GNOME GUI. -- # TRS-80 trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \ # UCC Wheel Member http://trs80.ucc.asn.au/ #| what squirrels do best | [ "There's nobody getting rich writing ]| -- Collect and hide your | [ software that I know of" -- Bill Gates, 1980 ]\ nuts." -- Acid Reflux #231 / -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.1.10.1006191234590.26...@martello.ucc.gu.uwa.edu.au
Bug#586085: xserver-xorg-video-nouveau: segfault prevents X start
On Wed, Jun 16, 2010 at 01:09:54PM +0200, Sven Joachim wrote: > This is the same segfault as in #579425, fixed in libdrm git. Could > somebody please upload libdrm 2.4.18-6 to fix that problem? I've downloaded libdrm 2.4.18-6 and built it locally, and it does indeed fix this bug. Thanks! -- James Cameron http://quozl.linux.org.au/ -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100616203120.gb6...@us.netrek.org
Bug#586062: mesa-dri-experimental: Missing /usr/lib/dri/nouveau_vieux_dri.so
nouveau_vieux_dri.so is the classic mesa driver for nv04-nv2x nVidia chips. It currently doesn't build against the libdrm in experimental. It appears to be more usable in mesa git master. I plan to add it when we start packaging from the mesa 7.9 branch. signature.asc Description: This is a digitally signed message part
Bug#586085: xserver-xorg-video-nouveau: segfault prevents X start
Package: xserver-xorg-video-nouveau Version: 1:0.0.15+git20100329+7858345-4 Severity: important After an apt-get dist-upgrade just now, X fails to start, a manual invokation of X from text console reveals this error: Backtrace: 0: X (xorg_backtrace+0x3b) [0x80addcb] 1: X (0x8048000+0x5ab75) [0x80a2b75] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xb78e040c] 3: /usr/lib/libdrm_nouveau.so.1 (nouveau_bo_ref+0x84) [0xb745e404] 4: /usr/lib/libdrm_nouveau.so.1 (nouveau_bo_new_tile+0xed) [0xb745e74d] 5: /usr/lib/libdrm_nouveau.so.1 (nouveau_bo_new+0x62) [0xb745e7c2] 6: /usr/lib/xorg/modules/drivers/nouveau_drv.so (0xb746+0xc86a) [0xb746c86a] 7: X (AddScreen+0x198) [0x806db98] 8: X (InitOutput+0x820) [0x80b0b00] 9: X (0x8048000+0x1e73b) [0x806673b] 10: /lib/i686/cmov/libc.so.6 (__libc_start_main+0xe6) [0xb761bc76] 11: X (0x8048000+0x1e4e1) [0x80664e1] Segmentation fault at address 0xc4 -- Package-specific info: /var/lib/x11/X.roster does not exist. /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 Feb 3 2009 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 1725180 Jun 4 02:14 /usr/bin/Xorg /var/lib/x11/xorg.conf.roster does not exist. VGA-compatible devices on PCI bus: 01:00.0 VGA compatible controller: nVidia Corporation NV6 [Vanta/Vanta LT] (rev 15) /etc/X11/xorg.conf does not exist. Kernel version (/proc/version): Linux version 2.6.32-5-686 (Debian 2.6.32-15) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-1) ) #1 SMP Tue Jun 1 04:59:47 UTC 2010 Xorg X server log files on system: -rw-r--r-- 1 root root 50812 Dec 28 2007 /var/log/Xorg.1.log -rw-r--r-- 1 root root 21368 Jun 16 19:25 /var/log/Xorg.0.log Contents of most recent Xorg X server log file /var/log/Xorg.0.log: X.Org X Server 1.7.7 Release Date: 2010-05-04 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32.14-dsa-ia32 i686 Debian Current Operating System: Linux nestor 2.6.32-5-686 #1 SMP Tue Jun 1 04:59:47 UTC 2010 i686 Kernel command line: auto BOOT_IMAGE=normal ro root=UUID=486d9cc8-ec18-44ee-9e25-faeaf3ee5755 quiet Build Date: 03 June 2010 04:08:50PM xorg-server 2:1.7.7-2 (Julien Cristau ) Current version of pixman: 0.16.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jun 16 19:25:33 2010 (==) Using system config directory "/usr/share/X11/xorg.conf.d" (==) No Layout section. Using the first Screen section. (==) No screen section available. Using defaults. (**) |-->Screen "Default Screen Section" (0) (**) | |-->Monitor "" (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. Entry deleted from font path. (==) 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, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins (==) ModulePath set to "/usr/lib/xorg/modules" (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. (II) Loader magic: 0x81eac60 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 6.0 X.Org XInput driver : 7.0 X.Org Server Extension : 2.0 (--) using VT number 7 (--) PCI:*(0:1:0:0) 10de:002c:10de:0072 nVidia Corporation NV6 [Vanta/Vanta LT] rev 21, Mem @ 0xf700/16777216, 0xfc00/33554432 (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) (II) LoadModule: "extmod" (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.7.7, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension SELinux (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "dbe" (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.7.7, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "glx" (II) Lo
Bug#585651: nouveau: Fails to use same resolution than console
This probably is due to your high resolution and low video memory - a 1900x1200 truecolour framebuffer takes up slightly more than half your VRAM. signature.asc Description: This is a digitally signed message part
Bug#585618: mesa: FTBFS on kfreebsd and hurd (gallium/auxiliary: os/os_time.c:51:4: error: #error Unsupported OS
On Sat, 2010-06-12 at 13:59 +0200, Julien Cristau wrote: > Package: mesa > Version: 7.8.1-2 > Severity: serious > > mesa in experimental ftbfs on kfreebsd and hurd: > https://buildd.debian.org/pkg.cgi?pkg=mesa&maint=&dist=experimental > > gcc -c -I. -I../../../src/gallium/include > -I../../../src/gallium/auxiliary -I../../../src/gallium/drivers -Wall > -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math > -fvisibility=hidden -fno-strict-aliasing -fPIC -D_GNU_SOURCE > -DPTHREADS -DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS > -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_INDIRECT_RENDERING > -DHAVE_ALIAS -D__STDC_CONSTANT_MACROS os/os_time.c -o os/os_time.o > os/os_time.c:51:4: error: #error Unsupported OS > os/os_time.c: In function 'os_time_get': > os/os_time.c:93: warning: control reaches end of non-void function > make[4]: *** [os/os_time.o] Error 1 > > Would be nice if porters could take a look. Otherwise we can disable > gallium there (I thought we already did, but apparently not). We only build the DRI drivers on Linux but we do build gallium swrast everywhere. signature.asc Description: This is a digitally signed message part
Re: Ubuntu X plans for the next release
On Thu, 2010-05-20 at 11:19 +0200, Michel Dänzer wrote: > On Don, 2010-05-20 at 17:53 +1000, Christopher James Halse Rogers > wrote: > > > > In support of our ARM friends we'd like to package mesa's GLES support. > > Cool, though can you elaborate how exactly this will help them? > From what I gathered at UDS, ARM hardware tends to have only EGL/GLES support. We want to have Unity, based on clutter, available on ARM hardware, so we need to build the egl clutter backend, so we need an egl library. Even better if we can also test these on regular desktop systems. So what we *need* is EGL to build the clutter backend. Having ES drivers to actually test on desktop hardware would be nice, too. > > It looks like this would be split into a libegl1-mesa containing the > > library and a libegl1-mesa-drivers containing the dri, dri2 and glx > > drivers. > > Note that EGL and GLES are different beasts - similar to GLX vs. OpenGL, > but there are actually separate EGL and GLES libraries. > Right. As I understand it, EGL is basically the windowing-system integration bit, covering what in OpenGL would be glx, wgl, and whatever Apple's got (agl?). GLES is the actual rendering API which was at one point kinda-sorta a subset of GL, but is now kinda-sorta a parallel API. > BTW, are you talking about the Gallium or non-Gallium EGL stacks, or > both? > Whichever works best, really. I haven't played around enough to make and informed decision here yet. Plausibly both. > > > Additionally, I understand that the r300g gallium driver is maturing > > rapidly, and there's a chance that it'll be the recommended 3D driver > > for mesa 7.9. If not, I think this would also be a good candidate for a > > libgl1-mesa-experimental package. > > Sounds good. It might also be nice to provide other Gallium options, > e.g. llvmpipe powered swrastg_dri.so / libgl1-mesa-swx11 or OpenVG. There's a bunch of interesting stuff there. I'm sure either I, or one of our intrepid contributors, would love to enable all the shiny. OpenVG at least seems safe to enable, and possibly g3dvl, too, although that's less interesting as (a) no one really cares about accelerating MPEG2 and (b) only nouveau has the hardware glue. signature.asc Description: This is a digitally signed message part
Ubuntu X plans for the next release
Hi all, I understand that it Bryce's habit to give the Debian XSF a heads up on the plans that Ubuntu have for the X stack each release. As Bryce is off hacking on Launchpad this release, I'll be responsible for X this cycle. So here's my attempt at a “heads up” email! I'd like to ensure that we don't unnecessarily duplicate work. I get the impression that Squeeze will be freezing sometime relatively soon, so I'd guess that you don't want these mesa and X versions in Sid, but would experimental be appropriate? I've had good experiences in the past with the Debian-mono team, and while X is a bit more tied to platform specifics I'd like to get as much as possible done in Debian. I can easily test-build against Debian and do some limited testing, and encourage others to do so, but that might not be sufficient. If that isn't regarded as sufficient then we can try and ensure our changes are easily merged with git. I've somewhat been watching on the sidelines before now - what would you find most helpful? So, without further ado, here's what we're aiming for in the next Ubuntu release: * Planned versions: We aim for xserver 1.9 and mesa 7.9. These are fairly aggressive targets, and we'll want to track git and pre-releases quite closely. We'll be on a 2.6.35 kernel, so we'll have the new 0.0.16 nouveau ABI which will be reflected in our libdrm packages. For intel, we're looking at 2.11 or potentially 2.12. * Packaging changes: In support of our ARM friends we'd like to package mesa's GLES support. It looks like this would be split into a libegl1-mesa containing the library and a libegl1-mesa-drivers containing the dri, dri2 and glx drivers. I'd like to ship nouveau's mesa component in a separate libgl1-mesa-experimental package. Considering upstream's “no 3D support!” policy I've had relatively good experiences with these drivers myself, but I think we want them to be opt-in. Additionally, I understand that the r300g gallium driver is maturing rapidly, and there's a chance that it'll be the recommended 3D driver for mesa 7.9. If not, I think this would also be a good candidate for a libgl1-mesa-experimental package. Any comments, queries, complaints? What are the feelings for how we should collaborate most effectively? signature.asc Description: This is a digitally signed message part
Bug#578082: xserver-xorg-video-intel: xorg freezes and locks keyboard/mouse when switching to a virtual terminal
Hi Julien -- It does not appear to, at least not right away. Sometimes this behavior waits until the machine has been up for a few days. James -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4a09477d575c2c4b86497161427dd94c14a6c83...@city-exchange07
Bug#578082: xserver-xorg-video-intel: xorg freezes and locks keyboard/mouse when switching to a virtual terminal
Package: xserver-xorg-video-intel Version: 2:2.9.1-3 Severity: normal When I switch from the X session on VT7 to another virtual terminal, X will lock up and the keyboard and mouse are unresponsive. The rest of the machine is operating normally and I can ssh in, but I cannot restart the X daemon or kdm. I usually reboot. While the system is in this locked state, Xorg.0.log gets filled up with these lines, several times a second: (II) AIGLX: Suspending AIGLX clients for VT switch Xorg.0.log gets quite large quite fast when this happens. I have a tarball of the Xorg.0.log file from the last time this happened -- however the tarball is 9.2MB. Please let me know if you want it (and how to attach to a bug report). The system was only locked for a few minutes, but the uncompressed Xorg.0.log file is 5.2GB. Thanks! -- Package-specific info: /var/lib/x11/X.roster does not exist. /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 Oct 28 2008 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 1876992 Apr 5 06:37 /usr/bin/Xorg /var/lib/x11/xorg.conf.roster does not exist. VGA-compatible devices on PCI bus: 00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02) /var/lib/x11/xorg.conf.md5sum does not exist. Xorg X server configuration file status: -rw-r--r-- 1 root root 1212 Mar 2 11:45 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # xorg.conf (X.Org X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type "man xorg.conf" at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section "InputDevice" Identifier "Generic Keyboard" Driver "kbd" Option "XkbRules" "xorg" Option "XkbModel" "pc104" Option "XkbLayout" "us" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" EndSection Section "Device" Identifier "Configured Video Device" Driver "intel" EndSection Section "Monitor" Identifier "VGA" Option "DPMS" "true" EndSection Section "Monitor" Identifier "TMDS-1" Option "DPMS" "true" EndSection Section "Screen" Identifier "Screen0" Monitor "VGA" SubSection "Display" Virtual 2880 900 EndSubSection EndSection Xorg X server log files on system: -rw-r--r-- 1 root root 31201 Dec 5 2008 /var/log/Xorg.2.log -rw-r--r-- 1 root root 37464 Oct 15 2009 /var/log/Xorg.1.log -rw-r--r-- 1 root root 39025 Apr 16 08:34 /var/log/Xorg.0.log Contents of most recent Xorg X server log file /var/log/Xorg.0.log: X.Org X Server 1.7.6 Release Date: 2010-03-17 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32-4-amd64 x86_64 Debian Current Operating System: Linux mis-jz-lnx 2.6.32-3-amd64 #1 SMP Wed Feb 24 18:07:42 UTC 2010 x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-3-amd64 root=UUID=cb1579ea-6000-4af5-9fe7-f70e3e915a64 ro quiet Build Date: 05 April 2010 02:21:15PM xorg-server 2:1.7.6-2 (Timo Aaltonen ) Current version of pixman: 0.16.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Fri Apr 16 08:33:44 2010 (==) Using config file: "/etc/X11/xorg.conf" (==) No Layout section. Using the first Screen section. (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "VGA" (==) No device specified for screen "Screen0". Using the first device section listed. (**) | |-->Device "Configured Video Device" (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. Entry deleted from font path. (==) 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, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins (==) ModulePath set to "/usr/lib/xorg/modules" (II) The server relies on udev to provide the list of input devi
Bug#576326: xserver-xorg: keys repeat without being held down
Package: xserver-xorg Version: 1:7.5+5 Severity: normal infrequently, roughly once or twice a day, a keyboard key will begin to repeat without being held down. another key press cancels the repeating symptom. the symptom occurs more frequently with xterm, wmaker, and mplayer. the symptom is more likely to occur if the system has been placed under memory pressure, such as a backup, playback of a DVB-T transport stream, or a kernel compile. in three scenarios has the symptom been observed: 1. while scp'ing a large file from another host, while playing a television programme using mplayer, pressing the "f" key to toggle between fullscreen and partial screen ... mplayer responded by oscillating between the two sizes until another key was pressed, 2. while doing a backup with tar, and no active screen use, pressing F12 to start an xterm (via a wmaker key definition), resulted in several hundred xterm's being forked, until an out-of-memory condition was triggered, 3. while playing a video with mplayer, pressing 'q' to quit, mplayer properly quits, and then finding the 'q' begins to repeat in the xterm that was being mplayer's window. -- Package-specific info: /var/lib/x11/X.roster does not exist. /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 Jun 3 2006 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 1712808 Feb 16 19:39 /usr/bin/Xorg /var/lib/x11/xorg.conf.roster does not exist. VGA-compatible devices on PCI bus: 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter /var/lib/x11/xorg.conf.md5sum does not exist. Xorg X server configuration file status: -rw-r--r-- 1 root root 2662 Sep 16 2009 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: ### BEGIN DEBCONF SECTION # XF86Config-4 (XFree86 server configuration file) generated by dexconf, the # Debian X Configuration tool, using values from the debconf database. # # Edit this file with caution, and see the XF86Config-4 manual page. # (Type "man XF86Config-4" at the shell prompt.) # # If you want your changes to this file preserved by dexconf, only make changes # before the "### BEGIN DEBCONF SECTION" line above, and/or after the # "### END DEBCONF SECTION" line below. # # To change things within the debconf section, run the command: # dpkg-reconfigure xserver-xfree86 # as root. Also see "How do I add custom sections to a dexconf-generated # XF86Config or XF86Config-4 file?" in /usr/share/doc/xfree86-common/FAQ.gz. Section "ServerFlags" Option "AutoAddDevices" "False" EndSection Section "Files" FontPath"/usr/share/fonts/X11/misc" FontPath"/usr/lib/X11/fonts/misc" FontPath"/usr/lib/X11/fonts/cyrillic" FontPath"/usr/lib/X11/fonts/100dpi/:unscaled" FontPath"/usr/lib/X11/fonts/75dpi/:unscaled" FontPath"/usr/share/fonts/X11/Type1" FontPath"/usr/lib/X11/fonts/Type1" FontPath"/usr/lib/X11/fonts/Speedo" FontPath"/usr/share/fonts/X11/100dpi" FontPath"/usr/lib/X11/fonts/100dpi" FontPath"/usr/share/fonts/X11/75dpi" FontPath"/usr/lib/X11/fonts/75dpi" EndSection Section "Module" Load"bitmap" Load"dbe" Load"dri" Load"extmod" Load"freetype" Load"glx" Load"int10" Load"record" Load"vbe" EndSection Section "InputDevice" Identifier "Generic Keyboard" Driver "keyboard" Option "CoreKeyboard" Option "XkbRules" "xfree86" Option "XkbModel" "lk450" Option "XkbLayout" "us" EndSection Section "InputDevice" Identifier "Configured Mouse" Driver "mouse" Option "CorePointer" # kernel 2.4.x # Option"Device""/dev/psaux" # kernel 2.6.x Option "Device""/dev/input/mice" Option "Protocol" "ImPS/2" Option "ZAxisMapping" "4 5" EndSection Section "Device" Identifier "Intel Corp. 82815 CGC [Chipset Graphics Controller]" Driver "sis" # VideoRam16384 # 8192 EndSection Section "Monitor" Identifier "hp L2035" HorizSync 30-140 # 75.1 VertRefresh 60 DisplaySize 408 306 Option "DPMS" EndSection Section "Screen" Identifier "Default Screen" Device "Intel Corp. 82815 CGC [Chipset Graphics Controller]" Monitor "hp L2035" DefaultDepth24 SubSection "Display" Depth 24 Modes "1600x1200" "800x600" EndSubSection EndSection Sect
Bug#252045: [font/mutt-misc PATCH] ClearlyU: fix off-by-one error in U+FFE1 through U+FFE6 range
>>>>> "Julien" == Julien Cristau writes: Julien> The range U+FFE1 (£, fullwidth pound sign) through U+FFE6 (₩, Julien> fullwidth won sign) is shifted by one position, pound being at position Julien> U+FFE0. Julien> Debian bug#252045 <http://bugs.debian.org/252045> Julien> Reported-by: Adrian 'Dagurashibanipal' von Bidder Julien> Signed-off-by: Julien Cristau Julien> --- Julien> cu12.bdf | 24 Julien> 1 files changed, 12 insertions(+), 12 deletions(-) Reviewed-by: James Cloos -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#487635: Performance degradation over remote ssh X11 forwarded display (and any other remote X connection)
I've been experiencing this problem in Lenny myself. I use unencrypted, remote X, using XDMCP to establish a connection. I find particular problems when using Evolution - it's unusable to scroll the lists. I also experience slow performance using X tunneled via ssh. I've applied Stephane Graber's patch for libxcb, which he created for Ubuntu. See the libxcb patch in: https://launchpad.net/~stgraber/+archive/ppa You can find my application of this patch to Lenny (for i386 only right now) here: http://www.wmltd.co.uk/debian/libxcb1/ This patch restores the acceptable performance I was experiencing in Debian Etch (prior to my upgrade to Lenny last week). I've uploaded all the files I edited there; you can download the .deb files and install (all of) them. The build tree is there, too. The patch is only a couple of lines. Hope it's helpful. Seb James -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#508767: /usr/bin/setxkbmap: setxkbmap resets xmodmap settings
Package: x11-xkb-utils Version: 7.4+1 Severity: normal File: /usr/bin/setxkbmap If after running "xmodmap ~/.xmodmaprc", I run "setxkbmap -option ctrl:nocaps" the settings from my .xmodmaprc are no longer in effect. xmodmap has to be re-run. $ cat ~/.xmodmaprc keysym Alt_R = Escape keycode 227 = Super_L -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (500, 'unstable'), (499, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages x11-xkb-utils depends on: ii cpp 4:4.3.2-2The GNU C preprocessor (cpp) ii libc6 2.7-16 GNU C Library: Shared libraries ii libice6 2:1.0.4-1X11 Inter-Client Exchange library ii libsm6 2:1.1.0-1X11 Session Management library ii libx11-62:1.1.99.2-1 X11 client-side library ii libxaw7 2:1.0.4-2X11 Athena Widget library ii libxkbfile1 1:1.0.5-1X11 keyboard file manipulation lib ii libxmu6 2:1.0.4-1X11 miscellaneous utility library ii libxt6 1:1.0.5-3X11 toolkit intrinsics library ii x11-common 1:7.4~4 X Window System (X.Org) infrastruc x11-xkb-utils recommends no packages. x11-xkb-utils suggests no packages. -- no debconf information -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Bug#374026: Try deleting dotfiles...
I also experienced keyboard failure after upgrading to Lenny and running Thunderbird. I was replying to a mail and hit ctrl-shift-r, then couldn't type anything else. Logging out with the mouse, the keyboard still worked in gdm and on a virtual console. I noticed that I was the only user on the system with the problem, so I deleted all the .dotfiles in my home directory, and the problem went away. Cheers! Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454202: Status poke
Any chance this can get enabled? -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]> signature.asc Description: Digital signature