xorg issueshttps://gitlab.freedesktop.org/groups/xorg/-/issues2019-11-29T15:22:10Zhttps://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/-/issues/5A memory leak in either radeon driver or xorg2019-11-29T15:22:10ZBugzilla Migration UserA memory leak in either radeon driver or xorg## Submitted by Maciej Piechotka
Assigned to **xf86-video-ati maintainers**
**[Link to original bug (#19200)](https://bugs.freedesktop.org/show_bug.cgi?id=19200)**
## Description
After a few days up X11 consumes over 200 MiB of me...## Submitted by Maciej Piechotka
Assigned to **xf86-video-ati maintainers**
**[Link to original bug (#19200)](https://bugs.freedesktop.org/show_bug.cgi?id=19200)**
## Description
After a few days up X11 consumes over 200 MiB of memory (physical - about 600 MiB of vmemory). I guess it is a memory leak.<br>
<br>
I'm using:<br>
x11-drivers/xf86-video-ati - git (otherwise there is no 2D/3D acceleration)<br>
x11-base/xorg-server - 1.5.3<br>
sys-kernel/zen-sources - 2.6.27-r31<br>
<br>
System uname: Linux-2.6.27-zen3-i686-Intel-R-_Celeron-R-_M_processor_1.50GHz-with-gentoo-2.0.0<br>
Timestamp of tree: Sat, 20 Dec 2008 03:01:01 +0000<br>
ccache version 2.4 [enabled]<br>
app-shells/bash: 3.2_p48<br>
dev-java/java-config: 1.3.7-r1, 2.1.6-r1<br>
dev-lang/python: 2.6.1<br>
dev-util/ccache: 2.4-r8<br>
dev-util/cmake: 2.6.2<br>
sys-apps/baselayout: 2.0.0<br>
sys-apps/openrc: 0.3.0-r1<br>
sys-apps/sandbox: 1.2.18.1-r3<br>
sys-devel/autoconf: 2.13, 2.63<br>
sys-devel/automake: 1.4_p6, 1.5, 1.7.9-r1, 1.9.6-r2, 1.10.2<br>
sys-devel/binutils: 2.19<br>
sys-devel/gcc-config: 1.4.0-r4<br>
sys-devel/libtool: 2.2.6a<br>
virtual/os-headers: 2.6.27-r2<br>
ACCEPT_KEYWORDS="x86 ~x86"<br>
CBUILD="i686-pc-linux-gnu"<br>
CFLAGS="-Os -mtune=pentium-m -march=pentium-m -mfpmath=sse -pipe -momit-leaf-frame-pointer -ggdb -w -ftree-vectorize -ftree-loop-optimize -freorder-blocks-and-partition -fgcse-sm -fgcse-las -fgcse-after-reload -ftracer -maccumulate-outgoing-args"<br>
CHOST="i686-pc-linux-gnu"<br>
CONFIG_PROTECT="/etc /var/lib/hsqldb"<br>
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d"<br>
CXXFLAGS="-Os -mtune=pentium-m -march=pentium-m -mfpmath=sse -pipe -momit-leaf-frame-pointer -ggdb -w -ftree-vectorize -ftree-loop-optimize -freorder-blocks-and-partition -fgcse-sm -fgcse-las -fgcse-after-reload -ftracer -maccumulate-outgoing-args -fvisibility-inlines-hidden"<br>
DISTDIR="/var/tmp/distfiles"<br>
FEATURES="ccache collision-protect cvs digest distlocks fixpackages multilib-strict parallel-fetch prelink preserve-libs protect-owned sandbox sfperms sign splitdebug stricter unmerge-orphans userfetch userpriv usersandbox"<br>
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"<br>
LANG="en_US.UTF-8"<br>
LC_ALL="en_US.UTF-8"<br>
LDFLAGS="-Wl,-O1 -Wl,--add-needed -Wl,--as-needed -Wl,--hash-style=both -Wl,--sort-common"<br>
LINGUAS="en_GB en_US pl"<br>
PKGDIR="/usr/portage/packages"<br>
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"<br>
PORTAGE_TMPDIR="/var/tmp"<br>
PORTDIR="/usr/portage"<br>
PORTDIR_OVERLAY="/usr/local/portage-crossdev /usr/portage/local/layman/rbu /usr/portage/local/layman/x11 /usr/portage/local/layman/java-overlay /usr/portage/local/layman/my-gnome /usr/portage/local/layman/zen-overlay /usr/local/portage"<br>
SYNC="rsync://rsync.gentoo.org/gentoo-portage"<br>
USE="X aac acl acpi alsa applet attr avahi avalon bash-completion berkdb bittorrent boo browseplugin bzip2 c++ cairo calendar caps cddb cdparanoia cdr cli clisp consolekit context cracklib crypt cups curl curlwrappers cxx d daap dbus deskbar detex devhelp disk-partition djvu docbook dri dvd dvdnav dvdr dvdread eclipse eds emacs emboss encode eog epiphany esd evo evolution exif expat extra fam ffmpeg flac flash fortran fuse galago gconf gd gdbm gdl gedit gif gimp git glib glut gmail gmp gnome gnome-keyring gnutls gpm groovy gsf gstreamer gtk guile hal iconv idle imap inherit-graph inotify ipod iproute2 ipv6 isdnlog jabber java java5 java6 jingle jpeg jpeg2k jython keyring kpathsea kqemu laptop latex libburn libffi libgda libnotify libsexy logrotate lucene mad maildir mailwrapper mhash midi mikmod mmap mmx mono moonlight mozilla mp3 mpeg mudflap mule musicbrainz nautilus ncurses network networkmanager nls nntp no-old-linux nptl nptlonly nsplugin nss ntpl ogg oggvorbis openal opengl openmp pam pango pbm pccts pch pcre pda pdf perl png policykit pop postgres ppds pppd pulseaudio python qt3support quicktime raw readline reflection regex reiserfs resolvconf rhino ruby samba scanner science sdl session snmp soap soup sourceview spell spl sqlite sqlite3 sse sse2 ssh ssl startup-notification subversion svg symlink sysfs syslog tcpd tetex theora threads threadsafe tiff timidity totem tracker trayicon truetype unicode usb valgrind vim vorbis vte webkit wifi win32codecs wxwindows x86 xattr xcb xforms xhtml xml xml2 xorg xsl xslt xulrunner xv zeroconf zlib" ALSA_CARDS="atiixp" ALSA_PCM_PLUGINS="null empty dmix dshare ioplug" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CAMERAS="panasonic" ELIBC="glibc" INPUT_DEVICES="evdev mouse keyboard" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en_GB en_US pl" NETBEANS_MODULES="ide java websvccommon " USERLAND="GNU" VIDEO_CARDS="radeon"<br>
Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS<br>
<br>
PS. I know that you would need valgrid log but running an old system I will not manage to get it (it will take ages).https://gitlab.freedesktop.org/xorg/xserver/-/issues/145Add information about Option NoDDC/NoDDC1/NoDDC2 to man page2018-12-13T18:28:26ZBugzilla Migration UserAdd information about Option NoDDC/NoDDC1/NoDDC2 to man page## Submitted by Andreas Stenglein
Assigned to **Xorg Project Team**
**[Link to original bug (#19427)](https://bugs.freedesktop.org/show_bug.cgi?id=19427)**
## Description
Created attachment 21731
sample patch, please check if the ...## Submitted by Andreas Stenglein
Assigned to **Xorg Project Team**
**[Link to original bug (#19427)](https://bugs.freedesktop.org/show_bug.cgi?id=19427)**
## Description
Created attachment 21731
sample patch, please check if the wording is ok
Add information about Option NoDDC/NoDDC1/NoDDC2 to radeon man page
I didn't find documentation to the NoDDC Option, but this option was necessary on my newly installed OpenSUSE 11.1 box, otherwise kdm didn't show up.
please check if attached patch (against current release candidate) is ok.
~~**Patch 21731**~~, "sample patch, please check if the wording is ok":
[radeon_man_ddc.patch](/uploads/75b5dda59e5b2bbeb77afec64eb3711f/radeon_man_ddc.patch)https://gitlab.freedesktop.org/xorg/app/xrandr/-/issues/3xrandr's transform feature has some problem in translating2018-08-10T20:33:08ZBugzilla Migration Userxrandr's transform feature has some problem in translating## Submitted by zhao jian
Assigned to **Keith Packard `@keithp`**
**[Link to original bug (#19436)](https://bugs.freedesktop.org/show_bug.cgi?id=19436)**
## Description
System Environment:
----------------------
Host: gm...## Submitted by zhao jian
Assigned to **Keith Packard `@keithp`**
**[Link to original bug (#19436)](https://bugs.freedesktop.org/show_bug.cgi?id=19436)**
## Description
System Environment:
----------------------
Host: gm45a
Arch: i386
OSD: Fedora release 10 (Cambridge)
Kernel: 2.6.28-release
Libdrm: (master)c34539e8bb5568b1d6059abf139dd08e07e84eea
Mesa: (intel-2008-q4)b9921a9fb2bc937194eac7e80e31d30f81cb6bb1
Xorg: 7.2
Xserver: (server-1.6-branch)32e81074b967716865aef08b66ec29caf0fec2c5
Xf86_video_intel:
(xf86-video-intel-2.6-branch)fac43181af0ad59fa6d06e26d369d886ce221c10
Bug Description:
---------------------
I tested xrandr's new feature transform under xrandr 1.2.99.3, With the command 'xrandr --output LVDS --transform 1,0,50,0,1,0,0,0,1' the output has no change, it should move left 50 far. Then if you type 'xrandr --output LVDS --transform 1,0,25,0,1,0,0,0,1', it will looks that it moves 25 far. That is to say it can only move right or down compared to its last position. Sometimes it doen't move at all no matter where you want to move it.
Reproduce Steps:
---------------------
1. xinit&
2. xrandr --output LVDS --transform 1,0,50,0,1,0,0,0,1
3. xrandr --output LVDS --transform 1,0,25,0,1,0,0,0,1
4. xrandr --output LVDS --transform 1,0,-5,0,1,0,0,0,1
5. xrandr --output LVDS --transform 1,0,50,0,1,0,0,0,1
6. xrandr --output LVDS --transform 1,0,15,0,1,0,0,0,1Keith PackardKeith Packardhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/262Support for more than 4 groups in xkb2018-12-13T18:36:57ZBugzilla Migration UserSupport for more than 4 groups in xkb## Submitted by Andriy Rysin
Assigned to **Xorg Project Team**
**[Link to original bug (#19501)](https://bugs.freedesktop.org/show_bug.cgi?id=19501)**
## Description
Some users need more than 4 layouts to switch between, so it wou...## Submitted by Andriy Rysin
Assigned to **Xorg Project Team**
**[Link to original bug (#19501)](https://bugs.freedesktop.org/show_bug.cgi?id=19501)**
## Description
Some users need more than 4 layouts to switch between, so it would be nice if xkb could support more than 4 groups.
Forwarded from https://bugs.kde.org/show_bug.cgi?id=174753https://gitlab.freedesktop.org/xorg/xserver/-/issues/686menu is shown on xMB press not on release2019-05-03T19:38:19ZBugzilla Migration Usermenu is shown on xMB press not on release## Submitted by Maciej Pilichowski
Assigned to **Jim Gettys**
**[Link to original bug (#19583)](https://bugs.freedesktop.org/show_bug.cgi?id=19583)**
## Description
( I am 100% sure I chose the wrong component, but I don't see any...## Submitted by Maciej Pilichowski
Assigned to **Jim Gettys**
**[Link to original bug (#19583)](https://bugs.freedesktop.org/show_bug.cgi?id=19583)**
## Description
( I am 100% sure I chose the wrong component, but I don't see anything more appropriate, I am very sorry for this ).
menu is shown on xMB press not on release
The action like showing context menu should be executed on release, not on
press.
a) it is about consistency -- all elements in environment like KDE are activated on release (links in web browser, window decoration) with only one exception -- menus
b) is not about accessibility -- when there is immediate reaction, there is hard to work in user pace, it is also harder to make emulation of MMB happen (even with some timeouts set)
ad.b) I didn't realize how hard to is to press both buttons (LMB+RMB) in KDE (Konq. actually to open page in new tab), because I had excellent mouse -- with literally three buttons (old unix school). Now I have two buttons mouse and pressing both of them hurts my hand -- it would be much easier to be able to press&hold RMB and then press LMB and then release them both.
So fixing this issue would have impact both on consistency of UI and accessibility. The first is rather a bug (flaw really), the second a wish.
I posted this report at KDE bugzilla, with answer that it is up to Qt. Qt team answered they are willing to provide configuration option, how menu should behave and this is valid report, but they will wait for you, for providing standard way to do this.
Just in case I would not be understood:
"
you should address this issue to the Freedesktop project
(http://www.freedesktop.org). If freedesktop defines a standard way to
configure this, the changes in Qt are trivial.
"
So I hope I finally reached the right place to ask for the change ;-)
Version: X11R6.6https://gitlab.freedesktop.org/xorg/xserver/-/issues/581xrandr causes crash in XkbCopyDeviceKeymap2018-12-17T17:27:34ZBugzilla Migration Userxrandr causes crash in XkbCopyDeviceKeymap## Submitted by Tomas Carnecky
Assigned to **Xorg Project Team**
**[Link to original bug (#19709)](https://bugs.freedesktop.org/show_bug.cgi?id=19709)**
## Description
A simple 'xrandr --output VGA --right-of LVDS' causes a SIGSEG...## Submitted by Tomas Carnecky
Assigned to **Xorg Project Team**
**[Link to original bug (#19709)](https://bugs.freedesktop.org/show_bug.cgi?id=19709)**
## Description
A simple 'xrandr --output VGA --right-of LVDS' causes a SIGSEGV inside XkbCopyDeviceKeymap. Sounds strange but it's 100% reproducible.
I'm using xorg + drivers from git. I'll attach xorg.log and the backtrace from gdb
Version: githttps://gitlab.freedesktop.org/xorg/xserver/-/issues/318Xkb Configuration in xorg.conf for us+il(lyx)+compose key misbehaves2018-12-13T18:39:28ZBugzilla Migration UserXkb Configuration in xorg.conf for us+il(lyx)+compose key misbehaves## Submitted by Shlomi Fish
Assigned to **Xorg Project Team**
**[Link to original bug (#19718)](https://bugs.freedesktop.org/show_bug.cgi?id=19718)**
## Description
I'm on Mandriva Linux Cooker and I have the following in my
/etc...## Submitted by Shlomi Fish
Assigned to **Xorg Project Team**
**[Link to original bug (#19718)](https://bugs.freedesktop.org/show_bug.cgi?id=19718)**
## Description
I'm on Mandriva Linux Cooker and I have the following in my
/etc/X11/xorg.conf :
{{{{{{{{{{{{{{{{{{
Section "InputDevice"
Identifier "Keyboard1"
Driver "kbd"
Option "XkbModel" "pc105"
Option "XkbLayout" "us,il"
Option "XkbCompat" ""
Option "XkbVariant" ",lyx"
Option "XkbOptions" "compose:rwin,grp:switch,grp:alt_shift_toggle,grp_led:scroll"
EndSection
.
.
.
Section "ServerLayout"
Identifier "layout1"
InputDevice "Keyboard1" "CoreKeyboard"
InputDevice "Mouse1" "CorePointer"
Screen "screen1"
EndSection
}}}}}}}}}}}}}}}}}}
After starting the X server I have the following setxkbmap -print:
{{{{{{{{{{{
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete+ledscroll(group_lock)" };
xkb_symbols { include "pc+us+il:2+inet(evdev)+group(alt_shift_toggle)+compose(rwin)" };
xkb_geometry { include "pc(pc104)" };
};
}}}}}}}}}}}
And then what happens is that the keyboard misbehaves when switching from
Hebrew to English and back - sometimes the LED is on when it's English
and vice versa.
When I run the following script:
{{{{
#!/bin/sh
# setxkbmap -option grp:switch,grp:alt_shift_toggle,grp_led:scroll -variant ",phonetic," 'us,ru,il'
setxkbmap \
-option "compose:rwin,grp:switch,grp:alt_shift_toggle,grp_led:scroll" \
-variant ",lyx" \
'us,il'
}}}}
I'm getting the following setxkbmap -print:
{{{{
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete+ledscroll(group_lock)" };
xkb_symbols { include "pc+us+il(lyx):2+inet(evdev)+group(switch)+group(alt_shift_toggle)+compose(rwin)" };
xkb_geometry { include "pc(pc104)" };
};
}}}}
Which behaves perfectly OK.
The xorg.conf worked up to a few weeks ago, so I don't understand why it
isn't working properly now.
Version: 7.4 (2008.09)https://gitlab.freedesktop.org/xorg/app/xrandr/-/issues/4X server should evaluate desktop resolution after applying rotation (and poss...2018-08-10T20:33:10ZBugzilla Migration UserX server should evaluate desktop resolution after applying rotation (and possibly other randr options)## Submitted by Jaroslav Stepanek
Assigned to **Jaroslav Stepanek**
**[Link to original bug (#20083)](https://bugs.freedesktop.org/show_bug.cgi?id=20083)**
## Description
exact settings:
virtual desktop size:2047x2047
first screen...## Submitted by Jaroslav Stepanek
Assigned to **Jaroslav Stepanek**
**[Link to original bug (#20083)](https://bugs.freedesktop.org/show_bug.cgi?id=20083)**
## Description
exact settings:
virtual desktop size:2047x2047
first screen:1024x768
secondary screen:1280x1024 (rotation left => pivot mode, makes 1024x1280)
first screen position (xrandr --pos): 0x0
secondary screen position: 1023x0
expected behaviour:
-secondary screen right of the primary and rotated left, with the two sharing a 1 pixel line (graphic card hast a 2047x2047 limit)
-works perfectly as axpected using a lower resolution on either screen
actual behaviour:
-the secondary screen is automatically placed with an offset of 767 (same as xrandr --pos 767x0), because Xorg thinks that the two screens will not fit the virtual desktop size (1024+1280=2304)
-there is the problem line in /var/log/Xorg.0.log: Mode 1280x1024+1023+0 does not fit virtual size 2047x2047 - offset updated to +767+0
notes:
-it seems that the X server validates the resolution before applying rotation, this results in a wrong interpretation, because the actual resolution after applying rotation is NOT 2303x1024 (which doesn't fit the given virtual desktop size), BUT rather 2047x1280 (which is obviously fine)
Version: 7.4 (2008.09)https://gitlab.freedesktop.org/xorg/xserver/-/issues/131Xnest and dix disagree about the -class option2024-02-15T15:20:36ZBugzilla Migration UserXnest and dix disagree about the -class option## Submitted by Christoph Kappel
Assigned to **Xorg Project Team**
**[Link to original bug (#20124)](https://bugs.freedesktop.org/show_bug.cgi?id=20124)**
## Description
Actually I don't know what's the version of my Xnest here - ...## Submitted by Christoph Kappel
Assigned to **Xorg Project Team**
**[Link to original bug (#20124)](https://bugs.freedesktop.org/show_bug.cgi?id=20124)**
## Description
Actually I don't know what's the version of my Xnest here - there's neither a -version argument nor does the manpage say anything about it beside that it belongs to xorg-server 1.5.3.
The output of -help lists two 'different' usages for the -class argument and -cc does something similar.
-class string default visual class
-class display-class specify display class to send in manage
I expected to set the window class with -class like -name for the window name.Enrico Weigeltinfo@metux.netEnrico Weigeltinfo@metux.nethttps://gitlab.freedesktop.org/xorg/lib/libxau/-/issues/2XauLockAuth() imposing huge delay (ignores EACCES errors)2018-08-10T20:18:13ZBugzilla Migration UserXauLockAuth() imposing huge delay (ignores EACCES errors)## Submitted by Radosław Zieliński
Assigned to **Jeremy Huddleston Sequoia**
**[Link to original bug (#20251)](https://bugs.freedesktop.org/show_bug.cgi?id=20251)**
## Description
"su - something" calls pam_xauth.so (if enabled), ...## Submitted by Radosław Zieliński
Assigned to **Jeremy Huddleston Sequoia**
**[Link to original bug (#20251)](https://bugs.freedesktop.org/show_bug.cgi?id=20251)**
## Description
"su - something" calls pam_xauth.so (if enabled), which calls xauth, which calls the XauLockAuth() from libXau.
It contains the following snippet:
while (retries > 0) {
if (creat_fd == -1) {
creat_fd = open (creat_name, O_WRONLY | O_CREAT | O_EXCL, 0600);
if (creat_fd == -1) {
if (errno != EACCES)
return LOCK_ERROR;
...which makes it ignore the "access denied" error and retry / wait again.
The effect: "su - other_user" from an X session is slow (20 seconds delay).
Obviously, the other_user is not supposed to be able to create my ~/.Xauthority-c.https://gitlab.freedesktop.org/xorg/xserver/-/issues/268grp:*_toggle gives weird layouts (both evdev and xkb)2018-12-13T18:37:12ZBugzilla Migration Usergrp:*_toggle gives weird layouts (both evdev and xkb)## Submitted by Fabio Zanini
Assigned to **Xorg Project Team**
**[Link to original bug (#20352)](https://bugs.freedesktop.org/show_bug.cgi?id=20352)**
## Description
Created attachment 23367
hal config file for evdev
Overview:
gr...## Submitted by Fabio Zanini
Assigned to **Xorg Project Team**
**[Link to original bug (#20352)](https://bugs.freedesktop.org/show_bug.cgi?id=20352)**
## Description
Created attachment 23367
hal config file for evdev
Overview:
grp:*_toggle is not working as expected. I get weird layouts, which have not been specified by me.
Steps to reproduce:
I'm using two language layouts: it and de. No variant (i.e. basic). Default layout is it (italian). To switch between them I use a usual grp:*_toggle.
Expected behaviour:
Expected behaviour is to get 2 layouts in this order:
- italian
- german
(and cyclic).
Real behaviour:
Instead, I get 4 layouts, in this order:
- italian
- german without some AltGr=ISO_LEVEL_3 activated keys (among them "½¬{[]")
- strange layout: "@łe¶ŧy" instead of "qwerty"
- german without etc. (identical to 2nd layout)
(and cyclic).
Other info:
Encountered both with old xkb driver and with new HAL-aware evdev driver (both cases are shown in config files in attachment).
**Attachment 23367**, "hal config file for evdev":
[10-keymap.fdi](/uploads/9a257b41eb3828f79945f44b29cdc77d/10-keymap.fdi)https://gitlab.freedesktop.org/xorg/meta/-/issues/11proto.pdf file on www.x.org out of date2019-05-03T19:30:36ZBugzilla Migration Userproto.pdf file on www.x.org out of date## Submitted by Markus Kuhn
Assigned to **Jim Gettys**
**[Link to original bug (#20428)](https://bugs.freedesktop.org/show_bug.cgi?id=20428)**
## Description
The URL
http://www.x.org/docs/XProtocol/proto.pdf
still contains the...## Submitted by Markus Kuhn
Assigned to **Jim Gettys**
**[Link to original bug (#20428)](https://bugs.freedesktop.org/show_bug.cgi?id=20428)**
## Description
The URL
http://www.x.org/docs/XProtocol/proto.pdf
still contains the old "Release 6.7" version of the "XWindow System Protocol" specification, however this is out of date as there have been substantial changes to Appendix A (keysyms) in the subsequent Release 6.9/7.0.
Please keep the above URL automatically updated to the latest released version of the X11 specification.
Version: X11R6.6https://gitlab.freedesktop.org/xorg/driver/xf86-video-r128/-/issues/2[r128] No usable resolution beneath 1600 x 1400 on Thinkpad A21p2018-08-10T20:50:07ZBugzilla Migration User[r128] No usable resolution beneath 1600 x 1400 on Thinkpad A21p## Submitted by Michael Jarosch
Assigned to **Xorg Project Team**
**[Link to original bug (#20446)](https://bugs.freedesktop.org/show_bug.cgi?id=20446)**
## Description
Hi there!
I have a problem with simply all actual linux-dist...## Submitted by Michael Jarosch
Assigned to **Xorg Project Team**
**[Link to original bug (#20446)](https://bugs.freedesktop.org/show_bug.cgi?id=20446)**
## Description
Hi there!
I have a problem with simply all actual linux-distributions on my Thinkpad A21p. I cannot use a resolution less than the biggest possible - if I try to use lower resolutions I get a garbled sreen. The bad thing is, that X is not able to recognize my maximum resolution - so, any time I want to use a live-system like Knoppix or the Ubuntu-Installer I simply can't use it. I first have to edit xorg.conf filling it with totally insane values about vertical and horizontal refresh-frequencies to make X start with the only possible resolution. I attached a "screenshot" taken with a digital camera when running OpenGEU on my Thinkpad with - I guess it was - 1024 x 768. So you get a picture about what's the whole thing looks like. (The picture is about 400k big - if those large files aren't allowed on bugzilla, or if you want to have a look at the 3 other pictures about this issue, please give me an adress to send it to!)
I cannot say anything about the reason for this strange behaviour. I can't even say, which was the latest x.org-version in which there wasn't that problem. I got the Thinkpad only since last autumn and there are hints in the internet on how you get an acceptable Desktop on the Thinkpad which are certainly 2 or 3 years old, prooving that this problem persists for a long time, now.
Somehow my problem looks related to #7460, because some issues are identical and the talks about DDC and modelines do sound like a good reason for this problem to me.
Oh - I've almost forgotten: The chipset we're talking about is the "Ati Rage Mobility M3" or "Mobility 128" using 16 MB of RAM. It's a notebook-version of the Ati Rage 128. There are at least three other Thinkpad models, named A20p, A22m, A22p using the same chipset (and getting the same problems).
Although my skills are limited, I have a great interest to help solving this problem!
Greetings!
Mitschhttps://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/31xcb_auth.c doesn't treat ipv6-mapped ipv4-addresses correctly2019-02-17T20:39:24ZBugzilla Migration Userxcb_auth.c doesn't treat ipv6-mapped ipv4-addresses correctly## Submitted by Christoph Pfister
Assigned to **xcb mailing list dummy**
**[Link to original bug (#20665)](https://bugs.freedesktop.org/show_bug.cgi?id=20665)**
## Description
from irc:
`<no_where>` I believe I have found a bug i...## Submitted by Christoph Pfister
Assigned to **xcb mailing list dummy**
**[Link to original bug (#20665)](https://bugs.freedesktop.org/show_bug.cgi?id=20665)**
## Description
from irc:
`<no_where>` I believe I have found a bug in libxcb: src/xcb_auth.c. Line 190 reads:
`<no_where>` APPEND(info->data, j, si6->sin6_addr.s6_addr[12]);
`<no_where>` As far as I can see, this will copy exactly one byte, because sizeof(si6->sin6_addr.s6_addr[12]) is 1. But it should copy four bytes, namely the IPv6-mapped IPv4-address from bytes 12 through 15.
`<no_where>` Can some knowledgable person confirm this, and if this analysis is correct, file a bug report?
`<christoph4>` no_where: hmm, your statement makes sense
`<no_where>` christoph4: at least in the old libX11/.../ConnDis.c, 4 bytes were copied explicitly
i've checked the xcb_auth.c code of current git head, and it matches the descriptionhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/376Animated cursor disappearing on XFixes[Hide/Show]Cursor2018-12-13T22:20:38ZBugzilla Migration UserAnimated cursor disappearing on XFixes[Hide/Show]Cursor## Submitted by Nicolas Bruguier `@gandalfn`
Assigned to **Xorg Project Team**
**[Link to original bug (#20736)](https://bugs.freedesktop.org/show_bug.cgi?id=20736)**
## Description
After using XFixesHideCursor/XFixesShowCursor al...## Submitted by Nicolas Bruguier `@gandalfn`
Assigned to **Xorg Project Team**
**[Link to original bug (#20736)](https://bugs.freedesktop.org/show_bug.cgi?id=20736)**
## Description
After using XFixesHideCursor/XFixesShowCursor all animated cursors disappearing.
It's seem when calling XFixesHideCursor or CursorFreeHideCount we call CursorDisplayCursor to initiate or to finish hiding. This function do Unwrap/Wrap
which break stack function calling and loose DisplayCursor from render animcursor.
Here a naive patch which just call directly the parent function when initiate or finish hiding/showing cursor.https://gitlab.freedesktop.org/xorg/xserver/-/issues/377[PATCH] rotated screen updated incorrectly2018-12-13T22:20:45ZBugzilla Migration User[PATCH] rotated screen updated incorrectly## Submitted by Joe Rabinoff
Assigned to **Xorg Project Team**
**[Link to original bug (#20762)](https://bugs.freedesktop.org/show_bug.cgi?id=20762)**
## Description
Created attachment 24071
Patch that fixes the problem
I'm using...## Submitted by Joe Rabinoff
Assigned to **Xorg Project Team**
**[Link to original bug (#20762)](https://bugs.freedesktop.org/show_bug.cgi?id=20762)**
## Description
Created attachment 24071
Patch that fixes the problem
I'm using randr 1.2 and the radeon driver with the xserver release 1.6.0. I have one monitor rotated left, and the other rotated normal. When I move a window in the rotated monitor, it leaves blit artifacts on the *left* side of the window. There are no such artifacts in the un-rotated monitor. The situation is similar when rotating one window to the right or 180 degrees.
After much hunting, I have identified the problem. It is in the xorg-server source (both in 1.6.0 and in git), in hw/xfree86/modes/xf86Rotate.c. The problem is in xf86RotateCrtcRedisplay (and also xf86CrtcRotate). Here's what happens, as illustrated by example. Suppose xf86RotateCrtcRedisplay() is told to update the framebuffer with the contents of the shadow buffer on my rotated monitor, in the logical box with bounds x1=0,y1=0,x2=100,y2=100. This means it needs to update the *pixels* with logical coordinates (x,y) with 0 <= x < 100 and 0 <= y < 100 -- that is, the bounds of the box are inclusive in the top-left corner, exclusive on the bottom-right corner. It then calls pixman_f_transform_bounds, which faithfully transforms the box into x1=0,y1=923,x2=100,y2=1023, then composites in the image. The problem is, it's now composting the pixels (x,y) with coordinates 0 <= x < 100, 923 <= y < 1023, but the desired behavior is 923 < y <= 1023. So you end up with an incorrectly updated frame buffer at y=coordinate 1023, i.e., a line on the left of your window.
I've included a patch that fixes this instance of the problem. It just wraps pixman_f_transform_bounds by first making the bounds *inclusive* (in the example, it changes the box to x1=0,y1=0,x2=99,y2=99), does the transform, then changes it back to exclusive bounds. I also applied this fix to xf86CrtcRotate, because crtc->bounds was being calculated incorrectly, hence my vertical monitor wasn't being updated with windows that only overlapped it with the leftmost pixel.
I know only enough about the xserver code to fix this bug, so I imagine the same error may show up in other places. I also understand you may want to implement a better solution than what my patch does. But it is worth some attention, since it will affect anybody with a rotated monitor and it is a quite irritating bug.
**Patch 24071**, "Patch that fixes the problem":
[fix-refresh.patch](/uploads/1cb752954e2d53170b97f7802af81ad7/fix-refresh.patch)
Version: 7.4 (2008.09)https://gitlab.freedesktop.org/xorg/xserver/-/issues/378Wrong DPI calculation2021-03-30T10:19:44ZBugzilla Migration UserWrong DPI calculation## Submitted by Nico R.
Assigned to **Xorg Project Team**
**[Link to original bug (#20931)](https://bugs.freedesktop.org/show_bug.cgi?id=20931)**
## Description
On a computer using xorg-7.4 with xorg-server-1.6.0, xf86-video-intel...## Submitted by Nico R.
Assigned to **Xorg Project Team**
**[Link to original bug (#20931)](https://bugs.freedesktop.org/show_bug.cgi?id=20931)**
## Description
On a computer using xorg-7.4 with xorg-server-1.6.0, xf86-video-intel-2.6.99.902 and libXrandr-1.2.99.4 and randrproto-1.2.99.4 (do not know whether the last two are relevant), the DPI values seem to be incorrectly calculated.
The screen is 331x207 millimeters (measured and given as DisplaySize in xorg.conf). The mode set in xorg.conf is 1680x1050.
Grepping the Xorg logfile for that stuff results in the following lines:
(II) intel(0): Output LVDS using initial mode 1680x1050
(**) intel(0): Display dimensions: (331, 207) mm
(**) intel(0): DPI set to (128, 206)
(II) intel(0): Setting screen physical size to 331 x 207
It seems that the vertical DPI value is calculated using the horizontal resolution:
xDPI = 1680/(331/25.4) ~= 128.9 (OK)
yDPI = 1050/(207/25.4) ~= 128.8 (should be that value)
yDPIwrong = 1680/(207/25.4) ~= 206.1 (is that value instead)
I filed this bug for the Driver/intel component, but it may belong to Server/general (or even App/xrandr?). Someone who knows better than me should properly set the component.
This bug might also be related to [bug 16789](https://bugs.freedesktop.org/show_bug.cgi?id=16789); that looks a bit different, though.
Version: 7.6 (2010.12)
### See also
* https://bugs.freedesktop.org/show_bug.cgi?id=102424
* https://bugs.freedesktop.org/show_bug.cgi?id=23705
* https://bugs.freedesktop.org/show_bug.cgi?id=41115https://gitlab.freedesktop.org/xorg/xserver/-/issues/379EDID info contains DS_ASCII_STR with nonprintable characters2018-12-13T22:20:59ZBugzilla Migration UserEDID info contains DS_ASCII_STR with nonprintable characters## Submitted by Nico R.
Assigned to **Xorg Project Team**
**[Link to original bug (#20989)](https://bugs.freedesktop.org/show_bug.cgi?id=20989)**
## Description
If I enable ModeDebug in the xorg.conf file, I can see the following ...## Submitted by Nico R.
Assigned to **Xorg Project Team**
**[Link to original bug (#20989)](https://bugs.freedesktop.org/show_bug.cgi?id=20989)**
## Description
If I enable ModeDebug in the xorg.conf file, I can see the following lines in the server log:
(II) intel(0): Ranges: V min: 0 V max: 200 Hz, H min: 0 H max: 200 kHz,
(II) intel(0): FD161^B154P2
(II) intel(0): (?HT}^B^A
(II) intel(0): EDID (in hex):
(II) intel(0): 00ffffffffffff004ca3503200000000
(II) intel(0): 00100103802115780a87f594574f8c27
(II) intel(0): 27505400000001010101010101010101
(II) intel(0): 010101010101932e90a0601a1e403020
(II) intel(0): 26004bcf100000190000000f00000000
(II) intel(0): 00000000003cd2026400000000fe0046
(II) intel(0): 443136310231353450320a20000000fe
(II) intel(0): 00283f48547da3d3ff02010a20200058
The second and third line are obviously printed, because a DS_ASCII_STR is detected (xorg-server-1.6.0/hw/xfree86/ddc/print_edid.c:350). But this string contains characters which are not printable (like ^B; and also some characters I can't even enter here, like y with diaresis).
Either this is a bug in the EDID block or in the code evaluating it or both are correct, but the printout is just "not nice". In the third case, I'd suggest changing the printing code so that nonprintable characters (0x00 to 0x1F, 0x7F to 0xFF) are written as "\x02", for example (for ^B). Nonprintable characters in log files are sometimes problematic to handle.
If the EDID block is buggy, perhaps a quirk should be added?
I am unsure whether this only happens with this monitor and with the intel driver or also with others. Perhaps the component for this bug should be DDX/xorg instead?
Version: 7.4 (2008.09)https://gitlab.freedesktop.org/xorg/xserver/-/issues/146[945GM] [XRANDR] Wrong screen dimensions when screen is rotated2019-03-13T23:32:59ZBugzilla Migration User[945GM] [XRANDR] Wrong screen dimensions when screen is rotated## Submitted by Bastien Nocera `@hadess`
Assigned to **Xorg Project Team**
**[Link to original bug (#20991)](https://bugs.freedesktop.org/show_bug.cgi?id=20991)**
## Description
Reproduced on:
xorg-x11-server-Xorg-1.6.0-15.fc11.i5...## Submitted by Bastien Nocera `@hadess`
Assigned to **Xorg Project Team**
**[Link to original bug (#20991)](https://bugs.freedesktop.org/show_bug.cgi?id=20991)**
## Description
Reproduced on:
xorg-x11-server-Xorg-1.6.0-15.fc11.i586
xorg-x11-drv-intel-2.6.99.902-1.fc11.i586
(with KMS enabled)
As well as:
xorg-x11-drv-i810-2.5.0-4.fc10.x86_64
xorg-x11-server-Xorg-1.5.3-15.fc10.x86_64
(without KMS)
xdpyinfo normal:
screen #0:
dimensions: 1680x1050 pixels (445x278 millimeters)
resolution: 96x96 dots per inch
xdpyinfo with the screen rotated left:
dimensions: 1050x1680 pixels (445x278 millimeters)
resolution: 60x153 dots per inch
The screen sizes aren't getting swapped, causing the wrong aspect ratio to be selected when playing back movies.
See the original bug:
http://bugzilla.gnome.org/show_bug.cgi?id=484454https://gitlab.freedesktop.org/xorg/xserver/-/issues/147Xorg server doesn't support XvPutImage drawing into a Pixmap2018-12-13T18:28:35ZBugzilla Migration UserXorg server doesn't support XvPutImage drawing into a Pixmap## Submitted by Austin Yuan
Assigned to **Xorg Project Team**
**[Link to original bug (#21143)](https://bugs.freedesktop.org/show_bug.cgi?id=21143)**
## Description
When using XvPutImage to draw into a pixmap, it always returns
er...## Submitted by Austin Yuan
Assigned to **Xorg Project Team**
**[Link to original bug (#21143)](https://bugs.freedesktop.org/show_bug.cgi?id=21143)**
## Description
When using XvPutImage to draw into a pixmap, it always returns
error because hw/xfree86/common/xf86xv.c:xf86XVPutImage checks whether the drawable is WINDOW, if not, it returns BadAlloc directly, see bellow code:
> static int
> xf86XVPutImage(
> ClientPtr client,
> DrawablePtr pDraw,
> XvPortPtr pPort,
> GCPtr pGC,
> INT16 src_x, INT16 src_y,
> CARD16 src_w, CARD16 src_h,
> INT16 drw_x, INT16 drw_y,
> CARD16 drw_w, CARD16 drw_h,
> XvImagePtr format,
> unsigned char* data,
> Bool sync,
> CARD16 width, CARD16 height
> ){
> XvPortRecPrivatePtr portPriv = (XvPortRecPrivatePtr)(pPort->devPriv.ptr);
> ScreenPtr pScreen;
> RegionRec WinRegion;
> RegionRec ClipRegion;
> BoxRec WinBox;
> int ret = Success;
> Bool clippedAway = FALSE;
>
> if (pDraw->type != DRAWABLE_WINDOW)
> => return BadAlloc;
But usually Xvideo implementation in Xserver video driver will handle WINDOW vs PIXMAP correctly, for example:
> if (pDraw->type == DRAWABLE_WINDOW)
> pPriv->pPixmap = (*pScreen->GetWindowPixmap)((WindowPtr)pDraw);
> else
> pPriv->pPixmap = (PixmapPtr)pDraw;
>
> #ifdef USE_EXA
> if (info->useEXA) {
> /* Force the pixmap into framebuffer so we can draw to it. */
> exaMoveInPixmap(pPriv->pPixmap);
> }
> #endif
>