xorg issueshttps://gitlab.freedesktop.org/groups/xorg/-/issues2024-01-18T22:52:59Zhttps://gitlab.freedesktop.org/xorg/lib/libxpm/-/issues/7XPM parsing of three-digit hex colors2024-01-18T22:52:59ZGünther NoackXPM parsing of three-digit hex colorsHello!
I have come across a XPM collection at https://kinzler.com/picons/ftp/ in which some pixels have the color `#FFF`, and I am observing surprising behaviour when loading these images.
To reproduce, one affected image where it is n...Hello!
I have come across a XPM collection at https://kinzler.com/picons/ftp/ in which some pixels have the color `#FFF`, and I am observing surprising behaviour when loading these images.
To reproduce, one affected image where it is nicely visible is `domains/edu/yale/unknown/face.xpm` from https://kinzler.com/ftp/faces/picons/db/domains.tar.Z: The image contains the following two colors:
```
"o c white",
"O c #FFF",
```
When loaded with GIMP (and therefore with libxpm), these two colors appear differently: "o" is proper white (#ffffff), and "O" is shown in GIMP as "#f0f0f0" (very bright grey). -- Is this working as intended?
Here is the Yale icon from the picons collection:
[face.xpm](/uploads/109d1148b7e70d1ab7c4d1a948df07b8/face.xpm)
When looking at the libxpm code, I would have assumed that the three-digit hex code is flattened out into 8-bit values by multiplying each channel with 0x11?
Proposed patch: [0001-Parse-three-digit-hex-colors-correctly.patch](/uploads/d5d1a7c626f4d05c6dc599c501844884/0001-Parse-three-digit-hex-colors-correctly.patch)
In my understanding, at least the "HTML" meaning of #FFF is "completely white" -- was that different when XPM was invented? :->
Thanks,
—Güntherhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1598Crash: XWayland 22.1.1 crashes when disconnecting Lenovo Thunderbolt 4 dock2024-01-15T09:12:10ZLassi VäätämöinenCrash: XWayland 22.1.1 crashes when disconnecting Lenovo Thunderbolt 4 dock**OS:** Kde Neon User edition
**XWayland version:** 2:22.1.1-1ubuntu0.7
**Display driver:** NVIDIA 535 driver
**STEPS TO REPRODUCE**
1. Connect laptop to TB4 dock with two monitors: DP and USB-C
2. Log into KDE session
3. Disconnect...**OS:** Kde Neon User edition
**XWayland version:** 2:22.1.1-1ubuntu0.7
**Display driver:** NVIDIA 535 driver
**STEPS TO REPRODUCE**
1. Connect laptop to TB4 dock with two monitors: DP and USB-C
2. Log into KDE session
3. Disconnect TB 4 dock
**OBSERVED RESULT**
Laptop internal screen freezes, cannot switch VTs.
Alt + SysRq + REISUB works to boot the laptop
**EXPECTED RESULT**
Laptop can be operated normally using its internal screen.
**ADDITIONAL INFO**
XWayland also crashes when disconnecting HDMI cable directly connected to the laptop.
[Xwayland-22.1.1.gdb](/uploads/ed055763e196f1d01fc941ddf99d7e6b/Xwayland-22.1.1.gdb)https://gitlab.freedesktop.org/xorg/xserver/-/issues/1574Xwayland frequent crashes after update from 23.1.2 to 23.2.02024-01-12T13:09:28ZppXwayland frequent crashes after update from 23.1.2 to 23.2.0Ever since upgrading xorg-xwayland from 23.1.2 to 23.2.0 Xwayland crashes when doing the following:
Environment: kernel 6.4.11, wlroots-git, sway-git, mesa-git
1. Open vmware-player and start a VM on monitor 1, workspace 1
(optional: ...Ever since upgrading xorg-xwayland from 23.1.2 to 23.2.0 Xwayland crashes when doing the following:
Environment: kernel 6.4.11, wlroots-git, sway-git, mesa-git
1. Open vmware-player and start a VM on monitor 1, workspace 1
(optional: 2. Open Microsoft Teams on monitor 2, workspace 2)
3. Open Steam (valve) on monitor 1, workspace 4 (just the steam gui, not launching any game).
When I now switch back to vmware on workspace 1 Xwayland crashes (most of the time) and I assume because of this all xwayland programs crash with a dump.
This does not happen when I downgrade to xorg-xwayland 23.1.2.
Coredump gdb bt full:
```
#0 0x00007fb827e9ee3b in pthread_kill () from /usr/lib/libc.so.6
No symbol table info available.
#1 0x00007fb827e439a8 in raise () from /usr/lib/libc.so.6
No symbol table info available.
#2 0x00007fb827e26478 in abort () from /usr/lib/libc.so.6
No symbol table info available.
#3 0x00005619a22afb1d in OsAbort () at ../xwayland-23.2.0/os/utils.c:1363
No locals.
#4 0x00005619a22afefd in AbortServer () at ../xwayland-23.2.0/os/log.c:879
No locals.
#5 FatalError (f=f@entry=0x5619a230b5f8 "Caught signal %d (%s). Server aborting\n") at ../xwayland-23.2.0/os/log.c:1017
args = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = 0x7ffdc44af860, reg_save_area = 0x7ffdc44af7a0}}
args2 = {{gp_offset = 8, fp_offset = 48, overflow_arg_area = 0x7ffdc44af860, reg_save_area = 0x7ffdc44af7a0}}
beenhere = 1
#6 0x00005619a22b0460 in OsSigHandler (unused=<optimized out>, sip=<optimized out>, signo=11) at ../xwayland-23.2.0/os/osinit.c:156
No locals.
#7 OsSigHandler (signo=11, sip=<optimized out>, unused=<optimized out>) at ../xwayland-23.2.0/os/osinit.c:110
No locals.
#8 <signal handler called>
No symbol table info available.
#9 0x0000000000000000 in ?? ()
No symbol table info available.
#10 0x00005619a225017c in ProcXTestFakeInput (client=<optimized out>) at ../xwayland-23.2.0/Xext/xtest.c:440
stuff = <optimized out>
nev = <optimized out>
n = <optimized out>
type = <optimized out>
rc = <optimized out>
ev = <optimized out>
dev = 0x5619a48c5070
root = 0x0
extension = <optimized out>
mask = {last_bit = -1 '\377', has_unaccelerated = 0 '\000', mask = "\000\000\000\000", valuators = {0 <repeats 36 times>}, unaccelerated = {0 <repeats 36 times>}}
valuators = {0 <repeats 36 times>}
numValuators = <optimized out>
firstValuator = <optimized out>
base = <optimized out>
flags = <optimized out>
need_ptr_update = 0
#11 0x00005619a21ee997 in Dispatch () at ../xwayland-23.2.0/dix/dispatch.c:545
result = <optimized out>
client = 0x5619a49ddae0
start_tick = 115
#12 0x00005619a21773a8 in dix_main (envp=<optimized out>, argv=<optimized out>, argc=<optimized out>) at ../xwayland-23.2.0/dix/main.c:271
i = <optimized out>
alwaysCheckForInput = {0, 1}
i = <optimized out>
alwaysCheckForInput = <optimized out>
pScreen = <optimized out>
pScreen = <optimized out>
remember_it = <optimized out>
pScreen = <optimized out>
#13 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at ../xwayland-23.2.0/dix/stubmain.c:34
No locals.
```https://gitlab.freedesktop.org/xorg/xserver/-/issues/1615line segments not shown while drawing polygon in xfig when using XWayland2024-01-11T10:20:31ZFederico Beffaline segments not shown while drawing polygon in xfig when using XWaylandI use the xfig drawing program. Recently, after upgrading to NixOS-23-11 with Gnome 45.2, I have several issues with xfig on XWayland. For example when I try to draw a polygon, the segments are not visible while drawing, making it very d...I use the xfig drawing program. Recently, after upgrading to NixOS-23-11 with Gnome 45.2, I have several issues with xfig on XWayland. For example when I try to draw a polygon, the segments are not visible while drawing, making it very difficult to draw anything. Also, when I group objects, the corners of the bounding box are not visible anymore. This makes it very difficult to select them for any operation.
When I switch to using an X11 session, none of those problems appears, and xfig works as expected.
### Affected version
* system: `"x86_64-linux"`
* host os: `Linux 6.1.68, NixOS, 23.11 (Tapir), 23.11.2130.d65bceaee0fb`
* The problem manifests in Gnome 45.2 on Wayland, but not on XOrg
### Steps to reproduce
1. Install xfig
1. Try to draw a polygonhttps://gitlab.freedesktop.org/xorg/util/imake/-/issues/3Build failure with stricter C compilers (e.g. GCC 14)2024-01-08T18:55:52ZSam JamesBuild failure with stricter C compilers (e.g. GCC 14)Modern C compilers are becoming stricter with a variety of changes over the last year or so.
GCC 14 in particular (to be released in ~April 2024) fails to build imake-1.0.9 like:
```
imake.c: In function ‘doit’:
imake.c:803:29: error: p...Modern C compilers are becoming stricter with a variety of changes over the last year or so.
GCC 14 in particular (to be released in ~April 2024) fails to build imake-1.0.9 like:
```
imake.c: In function ‘doit’:
imake.c:803:29: error: passing argument 2 of ‘execvp’ from incompatible pointer type [-Wincompatible-pointer-types]
803 | execvp(cmd, argv);
| ^~~~
| |
| const char **
In file included from imake.c:172:
/usr/include/unistd.h:599:52: note: expected ‘char * const*’ but argument is of type ‘const char **’
599 | extern int execvp (const char *__file, char *const __argv[])
| ~~~~~~~~~~~~^~~~~~~~
```
This can be emulated with `-Werror=incompatible-pointer-types -Werror=implicit -Werror=int-conversion` on an older GCC or Clang.https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/5capslock+Greek_finalsmallsigma does not produce Greek_SIGMA2024-01-08T16:02:22ZBugzilla Migration Usercapslock+Greek_finalsmallsigma does not produce Greek_SIGMA## Submitted by Jennie Petoumenou
Assigned to **Xorg Project Team**
**[Link to original bug (#22145)](https://bugs.freedesktop.org/show_bug.cgi?id=22145)**
## Description
When using the Greek keyboard layout, pressing capslock+Gre...## Submitted by Jennie Petoumenou
Assigned to **Xorg Project Team**
**[Link to original bug (#22145)](https://bugs.freedesktop.org/show_bug.cgi?id=22145)**
## Description
When using the Greek keyboard layout, pressing capslock+Greek_finalsmallsigma (ς) does not produce the expected Greek_SIGMA (Σ). Instead, it produces Greek_finalsmallsigma (ς). However, according to Greek spelling rules, Greek_finalsmallsigma (ς) is capitalized as Greek_SIGMA (Σ). (Shift+Greek_finalsmallsigma correctly produces Greek_SIGMA, so it is only the capslock behaviour that is problematic.)https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/3Serbian locale updates (sr_RS and sr_ME)2024-01-08T16:02:21ZBugzilla Migration UserSerbian locale updates (sr_RS and sr_ME)## Submitted by Milos Komarcevic
Assigned to **Xorg Project Team**
**[Link to original bug (#11456)](https://bugs.freedesktop.org/show_bug.cgi?id=11456)**
## Description
Serbia and Montenegro (formerly CS) have since last year and...## Submitted by Milos Komarcevic
Assigned to **Xorg Project Team**
**[Link to original bug (#11456)](https://bugs.freedesktop.org/show_bug.cgi?id=11456)**
## Description
Serbia and Montenegro (formerly CS) have since last year and bug #5575 split
up, so we now have new sr_RS and sr_ME locales (from now on in UTF-8 only in
glibc).
Please update Xlib with the following patch after review.
Version: git
### See also
* https://bugs.mageia.org/show_bug.cgi?id=7797
* https://bugs.freedesktop.org/show_bug.cgi?id=42362https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/1libX11 fails to build with --disable-xlocale2024-01-08T16:02:18ZBugzilla Migration UserlibX11 fails to build with --disable-xlocale## Submitted by Ryan Lortie Lortie `@desrt`
Assigned to **Xorg Project Team**
**[Link to original bug (#201)](https://bugs.freedesktop.org/show_bug.cgi?id=201)**
## Description
If you build libX11 with --disable-xlocale then src/i...## Submitted by Ryan Lortie Lortie `@desrt`
Assigned to **Xorg Project Team**
**[Link to original bug (#201)](https://bugs.freedesktop.org/show_bug.cgi?id=201)**
## Description
If you build libX11 with --disable-xlocale then src/imConv.c doesn't get built.
src/imConv.c contains a function _XimGetCharCode()
This function is called by src/XKBCvt.c regardless of --disable-xlocale.
This results in undefined references to _XimGetCharCode
Version: githttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1394Add a toggle of some kind for pasting the primary selection on middle click2024-01-06T01:27:56ZChristopherJTrentAdd a toggle of some kind for pasting the primary selection on middle clickBinding Middle-Click to pasting the primary selection is behavior that many Linux users have come to expect out of X11.
It's also extremely jarring to people transferring from other operating systems, and causes problems with many piece...Binding Middle-Click to pasting the primary selection is behavior that many Linux users have come to expect out of X11.
It's also extremely jarring to people transferring from other operating systems, and causes problems with many pieces of software which use middle click for other functionality; Firefox uses it for dozens of different operations, all of which can behave unpredictably when the primary selection is dumped into whatever text input might be active when the middle click event occurs.
It would be advantageous for users to have the option to, for example, place a line in their xorg.conf along the lines of MOUSE_3_PASTE=0 to disable that behavior without having to do janky hacks like clearing PRIMARY every time M3 is pressed, or disabling the middle mouse button entirely.https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/issues/73OpenGL 4.3 compute shader crash2024-01-04T21:41:21ZMrLovaskocsi2OpenGL 4.3 compute shader crashI'm developing a simulation using OpenGL 4.3 compute shaders. After a recent linux image update (maybe 5.14->5.15 but I am not 100% sure) a weird error started popping up. The application crashes and I get this message in the console out...I'm developing a simulation using OpenGL 4.3 compute shaders. After a recent linux image update (maybe 5.14->5.15 but I am not 100% sure) a weird error started popping up. The application crashes and I get this message in the console output:
```
amdgpu: amdgpu_cs_query_fence_status failed.
amdgpu: The CS has been rejected (-61), but the context isn't robust.
amdgpu: The process will be terminated.
```
dmesg:
```
Dec 26 12:50:44 ubuntu2204 kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, but soft recovered
```
Things I tried:
- updated kernel to 6.5
- kernel parameters: amdgpu.mcbp=0, amdgpu.ppfeaturemask=0xfffd3fff (based on this thread: https://bbs.archlinux.org/viewtopic.php?id=284076&p=4 )
These did not help.
Config:
- Ubuntu 22.04
- Linux 6.5 (package linux-image-generic-hwe-22.04-edge, 6.5.0.14.14~22.04.6)
- X.Org X Server 1.21.1.4 (package 2:21.1.4-2ubuntu1.7~22.04.5)
- mesa libgl 23.0 (package 23.0.4-0ubuntu1~22.04.1)
- Video card: AMD RX 6750 XT
If I can provide any more info that could help resolve the problem I would be more than happy to help.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1057Fix 1bpp Xservers on "whitePixel=0, blackPixel=1" VRAMs2024-01-03T19:46:47ZIzumi TsutsuiFix 1bpp Xservers on "whitePixel=0, blackPixel=1" VRAMsI'm working on porting ancient X11R6/XFree86 based Xsun servers to build with recent Xorg 1.20 DIX APIs for old sun machines still supported by NetBSD. The Xsun server in the NetBSD local tree is now functional on 8bpp cgtwo on sun3, 8b...I'm working on porting ancient X11R6/XFree86 based Xsun servers to build with recent Xorg 1.20 DIX APIs for old sun machines still supported by NetBSD. The Xsun server in the NetBSD local tree is now functional on 8bpp cgtwo on sun3, 8bpp cgsix on SPARCstation, and 1bpp bwtwo on sun3.
- http://cvsweb.netbsd.org/bsdweb.cgi/xsrc/external/mit/xorg-server/dist/hw/sun/
- https://twitter.com/tsutsuii/status/1283063395248254976
- https://twitter.com/tsutsuii/status/1284605639587553280
To support sun3 bwtwo 1bpp framebuffer, I had to modify several DIX fb colormap code because its VRAM requires "whitePixel=0, blackPixel=1" settings (i.e. `-flipPixels` settings should be default). It would be great if my local changes will also be applied to upstream xorg tree.
There are two problem to support inverted b&w settings:
### (1) `fbSetupScreen()` in fb/fbscreen.c implicitly overwrites `blackPixel` and `whitePixel`
`fbSetupScreen()` has the following code:
https://gitlab.freedesktop.org/xorg/xserver/-/blob/0803918e64262482035f042e5e1f2a571d3dea1b/fb/fbscreen.c#L93
```c
/* let CreateDefColormap do whatever it wants for pixels */
pScreen->blackPixel = pScreen->whitePixel = (Pixel) 0;
```
However it doesn't seem `CreateDefColormap()` handles it in 1bpp case, so `fbSetupScreen()` should leave DDX settings.
### (2) `fbInitializeColormap()` doesn't check `blackPixel` and `whitePixel` on settings 1bpp colormap?
Even if `blackPixel` and `whitePixel` in `ScreenPtr` are set proplery (as `-flipPixels` is specified), it looks `fbInitializeColormap()` doesn't check `blackPixel` and `whitePixel` on settings 1bpp colormap.
Without this colormap settings, at least the following drawing operations don't reflect `blackPixel` and `whitePixel` values (they refer colormap directly even on 1bpp?)
- mouse cursor
- twm titlebar and window frames
- see pics in https://twitter.com/tsutsuii/status/1270362023080017921
To handle this, I had to take an old mfb function `mfbCreateColormap()` derived from X11R6 tree. It just calls `AllocColor()` for two colors per `whitePixel` value. I'm not sure if this should be implemented in the default `fbInitializeColormap()` function, but in NetBSD local tree I've just added an independent function (taken from old tree like https://gitlab.freedesktop.org/xorg/xserver/-/blob/0d7ec5c7d9b451066a079fe56bcc9722341a91ff/mfb/mfbcmap.c#L115 ) for 1bpp servers.
Note I have just noticed the `-flipPixels` option have been removed recently in this commit: https://gitlab.freedesktop.org/xorg/xserver/-/commit/d1c00c859c6676fbb540420c9055788bc19cb18f
but I would also like to denote "it just works with Xorg xf86-video-wsfb driver and this patch, at least Xorg 1.20.5 based NetBSD local tree."
https://twitter.com/tsutsuii/status/1283042381009498120
```diff
From 19c16dce27c220e1ae834e0c4eb10fab112c5b06 Mon Sep 17 00:00:00 2001
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
Date: Sun, 9 Aug 2020 11:34:23 +0900
Subject: [PATCH] Fix 1bpp Xservers on "whitePixel=0, blackPixel=1" VRAMs.
---
fb/fb.h | 3 +++
fb/fbcmap_mi.c | 35 +++++++++++++++++++++++++++++++++++
fb/fbscreen.c | 12 +++++++++---
3 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/fb/fb.h b/fb/fb.h
index 8ab050d0f..a113baf01 100644
--- a/fb/fb.h
+++ b/fb/fb.h
@@ -734,6 +734,9 @@ fbResolveColor(unsigned short *pred,
extern _X_EXPORT Bool
fbInitializeColormap(ColormapPtr pmap);
+extern _X_EXPORT Bool
+ mfbCreateColormap(ColormapPtr pmap);
+
extern _X_EXPORT int
fbExpandDirectColors(ColormapPtr pmap,
diff --git a/fb/fbcmap_mi.c b/fb/fbcmap_mi.c
index d9976ce9f..18acd2bf1 100644
--- a/fb/fbcmap_mi.c
+++ b/fb/fbcmap_mi.c
@@ -66,6 +66,41 @@ fbInitializeColormap(ColormapPtr pmap)
return miInitializeColormap(pmap);
}
+Bool
+mfbCreateColormap(ColormapPtr pmap)
+{
+ ScreenPtr pScreen;
+ unsigned short red0, green0, blue0;
+ unsigned short red1, green1, blue1;
+ Pixel pix;
+
+ pScreen = pmap->pScreen;
+ if (pScreen->whitePixel == 0)
+ {
+ red0 = green0 = blue0 = ~0;
+ red1 = green1 = blue1 = 0;
+ }
+ else
+ {
+ red0 = green0 = blue0 = 0;
+ red1 = green1 = blue1 = ~0;
+ }
+
+ /* this is a monochrome colormap, it only has two entries, just fill
+ * them in by hand. If it were a more complex static map, it would be
+ * worth writing a for loop or three to initialize it */
+
+ /* this will be pixel 0 */
+ pix = 0;
+ if (AllocColor(pmap, &red0, &green0, &blue0, &pix, 0) != Success)
+ return FALSE;
+
+ /* this will be pixel 1 */
+ if (AllocColor(pmap, &red1, &green1, &blue1, &pix, 0) != Success)
+ return FALSE;
+ return TRUE;
+}
+
int
fbExpandDirectColors(ColormapPtr pmap,
int ndef, xColorItem * indefs, xColorItem * outdefs)
diff --git a/fb/fbscreen.c b/fb/fbscreen.c
index 4ab807ab5..42efaa911 100644
--- a/fb/fbscreen.c
+++ b/fb/fbscreen.c
@@ -100,8 +100,10 @@ fbSetupScreen(ScreenPtr pScreen, void *pbits, /* pointer to screen bitmap */
if (!fbAllocatePrivates(pScreen))
return FALSE;
pScreen->defColormap = FakeClientID(0);
- /* let CreateDefColormap do whatever it wants for pixels */
- pScreen->blackPixel = pScreen->whitePixel = (Pixel) 0;
+ if (bpp > 1) {
+ /* let CreateDefColormap do whatever it wants for pixels */
+ pScreen->blackPixel = pScreen->whitePixel = (Pixel) 0;
+ }
pScreen->QueryBestSize = fbQueryBestSize;
/* SaveScreen */
pScreen->GetImage = fbGetImage;
@@ -118,7 +120,11 @@ fbSetupScreen(ScreenPtr pScreen, void *pbits, /* pointer to screen bitmap */
pScreen->RealizeFont = fbRealizeFont;
pScreen->UnrealizeFont = fbUnrealizeFont;
pScreen->CreateGC = fbCreateGC;
- pScreen->CreateColormap = fbInitializeColormap;
+ if (bpp == 1) {
+ pScreen->CreateColormap = mfbCreateColormap;
+ } else {
+ pScreen->CreateColormap = fbInitializeColormap;
+ }
pScreen->DestroyColormap = (void (*)(ColormapPtr)) NoopDDA;
pScreen->InstallColormap = fbInstallColormap;
pScreen->UninstallColormap = fbUninstallColormap;
--
2.25.3
```https://gitlab.freedesktop.org/xorg/xserver/-/issues/1388Got wrong resolutions table if EDID doesn't provide Detail Monitor Range tabl...2023-12-22T05:05:10ZAceLan KaoGot wrong resolutions table if EDID doesn't provide Detail Monitor Range table(0xfd), and intel driver works* Kernel: mainline 6.0.0
* xserver-xorg: 1:7.7+23ubuntu2
* xserver-xorg-core: 2:21.1.3-2ubuntu2.2
* xserver-xorg-video-intel: 2:2.99.917+git20210115-1
xrandr shows invalid resolutions and switch to those listed resolutions got blank scr...* Kernel: mainline 6.0.0
* xserver-xorg: 1:7.7+23ubuntu2
* xserver-xorg-core: 2:21.1.3-2ubuntu2.2
* xserver-xorg-video-intel: 2:2.99.917+git20210115-1
xrandr shows invalid resolutions and switch to those listed resolutions got blank screen.
This issue may result from EDID doesn't provide Detail Monitor Range table(0xfd), it only provides a fixed vrefresh(90Hz) in EDID, and X got both 0 of min_vfreq and max_vfreq.
```
[ 15.942028] u-Inspiron-14-5430 kernel: [drm:update_display_info.cold [drm]] Supported Monitor Refresh rate range is 0 Hz - 0 Hz
```
Switch to use intel driver, xrandr shows only one resolution and one framerate.
```
eDP1 connected primary 2560x1600+0+0 (normal left inverted right x axis y axis) 300mm x 190mm
2560x1600 90.00*+
```
[xrandr_xserver.log](/uploads/0de0833eca2a1b95975cbaeab0061c5c/xrandr_xserver.log)
[xrandr_intel.log](/uploads/5aebe75e526936f16015e9b70baecfba/xrandr_intel.log)
[journalctl_xserver.log](/uploads/b70ff53a6e0f7a313d89f47b00b5829e/journalctl_xserver.log)
[journalctl_intel.log](/uploads/ae0d17575ce137be5a63c6f9487fb776/journalctl_intel.log)
[edid.bin](/uploads/98921413fcaa165d0358fc07030bf94c/edid.bin)https://gitlab.freedesktop.org/xorg/xserver/-/issues/399X server logs need human-friendly timestamps2023-12-17T19:42:20ZBugzilla Migration UserX server logs need human-friendly timestamps## Submitted by Matej Cepl
Assigned to **Xorg Project Team**
**[Link to original bug (#28429)](https://bugs.freedesktop.org/show_bug.cgi?id=28429)**
## Description
So, there are now logs in Xorg.0.log (http://cgit.freedesktop.org/...## Submitted by Matej Cepl
Assigned to **Xorg Project Team**
**[Link to original bug (#28429)](https://bugs.freedesktop.org/show_bug.cgi?id=28429)**
## Description
So, there are now logs in Xorg.0.log (http://cgit.freedesktop.org/xorg/xserver/commit/?id=d2322b6309bf15a45002b42e7e6ba3d6b5bfa932), so [bug 25668](https://bugs.freedesktop.org/show_bug.cgi?id=25668) and [bug 26180](https://bugs.freedesktop.org/show_bug.cgi?id=26180) as they stand could be closed IMHO, but miliseconds / 1000 are not exactly easy to read for humans.
-- some more comments from the downstream bug (https://bugzilla.redhat.com/show_bug.cgi?id=582340):
I agree. I'm trying to understand a bug causing Xorg to crash and it would be
more helpful for timestamps to be easier to read. It looks like seconds since
last boot. Even if they stick with seconds as the time stamp, calendar time
(seconds since the epoch) would be more useful since it can be easily converted
to an absolute time without having to figure out when your computer was last
switched on.
It looks like the X server has started to timestamp its log entries, but
unfortunately this is just in the format of a decimal number. Making this
human readable would help enormously in debugging problems where log entries
need to be temporally correlated with a stimulus.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1532Both Xorg with xf86-video-dummy-0.4.0 and Xvfb report physical size 0mmx0mm2023-12-17T19:12:38ZTwaik YontBoth Xorg with xf86-video-dummy-0.4.0 and Xvfb report physical size 0mmx0mmHi. Weird thing. Both Xvfb and Xorg with xf86-video-dummy-0.4.0 report 0mmx0mm even after explicit setting those values to some positive numbers with `xcb_randr_set_screen_size_checked`, `xcb_randr_set_screen_size_checked_reply` did not ...Hi. Weird thing. Both Xvfb and Xorg with xf86-video-dummy-0.4.0 report 0mmx0mm even after explicit setting those values to some positive numbers with `xcb_randr_set_screen_size_checked`, `xcb_randr_set_screen_size_checked_reply` did not report any error. I simply can not make it work as expected.
### What steps will reproduce the bug?
<details>
```
~ $ Xvfb :1 -noreset &
~ $ xrandr
Screen 0: minimum 1 x 1, current 1280 x 1024, maximum 1280 x 1024
screen connected 1280x1024+0+0 0mm x 0mm
1280x1024 0.00*
~ $ xrandr --output screen --fbmm 100x100
~ $ xrandr
Screen 0: minimum 1 x 1, current 1280 x 1024, maximum 1280 x 1024
screen connected 1280x1024+0+0 0mm x 0mm
1280x1024 0.00*
```
</details>
Thank you very much for help.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1419fbdev_open fails to handle symbolic links2023-12-17T17:25:17ZMoritz Bruderfbdev_open fails to handle symbolic linksI have an issue with matching a device name for fbdev in X11 since it was changing non-deterministically. Therefore I created a `udev` rule to create a symbolic link. In the X11 configuration I set the `fbdev` key of this device to the...I have an issue with matching a device name for fbdev in X11 since it was changing non-deterministically. Therefore I created a `udev` rule to create a symbolic link. In the X11 configuration I set the `fbdev` key of this device to the path of the symbolic link. It seems reasonable to me that it should also work with symbolic links.
So I dove into the code and found that `fbdev_open` uses the filename directly to check whether the device is a PCI device:
1. It creates a _wrong_ sysfs path from the name of the symbolic link.
2. `readlink` will fail following the sysfs path.
3. The function will return `-1` and not open the device (leading to X11 not finding any screens).
Fixing it may be as simple as putting a `readlink` at the start.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1011mirrored glyph with glamor acceleration on big-endian machine (sparc)2023-12-17T17:06:30Zvladimir1795mirrored glyph with glamor acceleration on big-endian machine (sparc)I get problem with mirrored glyph and glamor acceleration on big-endian machine (SPARC) if using XDrawString for draw text character:
with glamor enabled, displays mirrored glyph, with disabled, works correctly.
Screenshot with problem:
...I get problem with mirrored glyph and glamor acceleration on big-endian machine (SPARC) if using XDrawString for draw text character:
with glamor enabled, displays mirrored glyph, with disabled, works correctly.
Screenshot with problem:
![screen-sparc](/uploads/7cc97940ed0a271d3255eabb9e006d89/screen-sparc.png)
packages version:
xorg 1.19.5 (with 1.20.7 same problem)
mesa 19.3.2
video card: radeon r5 230
test example:
[demo.c](/uploads/f2bfb97b74950d1e72dca86fff9139e4/demo.c)https://gitlab.freedesktop.org/xorg/lib/libxcb-errors/-/issues/31.0.1: test suite is failing in `contents:: :depth: 2`unit2023-12-12T20:18:08ZTomasz Kłoczko1.0.1: test suite is failing in `contents:: :depth: 2`unit```plaintext
+ cd xcb-util-errors-1.0.1
+ xvfb-run -a /usr/bin/make -O -j48 V=1 VERBOSE=1 check
/usr/bin/make tests/test
make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/xcb-util-errors-1.0.1'
/usr/bin/gcc -DPACKAGE_NAME=\"xcb...```plaintext
+ cd xcb-util-errors-1.0.1
+ xvfb-run -a /usr/bin/make -O -j48 V=1 VERBOSE=1 check
/usr/bin/make tests/test
make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/xcb-util-errors-1.0.1'
/usr/bin/gcc -DPACKAGE_NAME=\"xcb-util-errors\" -DPACKAGE_TARNAME=\"xcb-util-errors\" -DPACKAGE_VERSION=\"1.0.1\" -DPACKAGE_STRING=\"xcb-util-errors\ 1.0.1\" -DPACKAGE_BUGREPORT=\"https://gitlab.freedesktop.org/xorg/lib/libxcb-errors/-/issues\" -DPACKAGE_URL=\"\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_WCHAR_H=1 -DSTDC_HEADERS=1 -D_ALL_SOURCE=1 -D_DARWIN_C_SOURCE=1 -D_GNU_SOURCE=1 -D_HPUX_ALT_XOPEN_SOCKET_API=1 -D_NETBSD_SOURCE=1 -D_OPENBSD_SOURCE=1 -D_POSIX_PTHREAD_SEMANTICS=1 -D__STDC_WANT_IEC_60559_ATTRIBS_EXT__=1 -D__STDC_WANT_IEC_60559_BFP_EXT__=1 -D__STDC_WANT_IEC_60559_DFP_EXT__=1 -D__STDC_WANT_IEC_60559_FUNCS_EXT__=1 -D__STDC_WANT_IEC_60559_TYPES_EXT__=1 -D__STDC_WANT_LIB_EXT2__=1 -D__STDC_WANT_MATH_SPEC_FUNCS__=1 -D_TANDEM_SOURCE=1 -D__EXTENSIONS__=1 -DPACKAGE=\"xcb-util-errors\" -DVERSION=\"1.0.1\" -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DPACKAGE_VERSION_MAJOR=1 -DPACKAGE_VERSION_MINOR=0 -DPACKAGE_VERSION_PATCHLEVEL=1 -I. -I./src/ -fno-strict-aliasing -O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -c -o tests/test-test.o `test -f 'tests/test.c' || echo './'`tests/test.c
make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/xcb-util-errors-1.0.1'
make[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/xcb-util-errors-1.0.1'
/bin/sh ./libtool --tag=CC --mode=link /usr/bin/gcc -fno-strict-aliasing -O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -Wl,--gc-sections -Wl,--as-needed -flto=auto -flto-partition=none -fuse-linker-plugin -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,--build-id=sha1 -o tests/test tests/test-test.o libxcb-errors.la -lxcb
libtool: link: /usr/bin/gcc -fno-strict-aliasing -O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -Wl,--gc-sections -Wl,--as-needed -flto=auto -flto-partition=none -fuse-linker-plugin -Wl,-z -Wl,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -Wl,--build-id=sha1 -o tests/.libs/test tests/test-test.o ./.libs/libxcb-errors.so -lxcb
make[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/xcb-util-errors-1.0.1'
/usr/bin/make check-TESTS
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/xcb-util-errors-1.0.1'
FAIL: tests/test
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/xcb-util-errors-1.0.1'
make[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/xcb-util-errors-1.0.1'
=============================================
xcb-util-errors 1.0.1: ./test-suite.log
=============================================
# TOTAL: 1
# PASS: 0
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
.. contents:: :depth: 2
FAIL: tests/test
================
For xge event (131, 27): Expected (null), got GesturePinchBegin
For xcb xge wire event 27: Expected (null), got GesturePinchBegin
FAIL tests/test (exit status: 1)
============================================================================
Testsuite summary for xcb-util-errors 1.0.1
============================================================================
# TOTAL: 1
# PASS: 0
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
See ./test-suite.log
Please report to https://gitlab.freedesktop.org/xorg/lib/libxcb-errors/-/issues
============================================================================
make[2]: *** [Makefile:912: test-suite.log] Error 1
make[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/xcb-util-errors-1.0.1'
make[1]: *** [Makefile:1020: check-TESTS] Error 2
make: *** [Makefile:1234: check-am] Error 2
```https://gitlab.freedesktop.org/xorg/xserver/-/issues/266XKB settings lost after suspend/resume / not taken into account for new keyboard2023-12-07T22:30:24ZBugzilla Migration UserXKB settings lost after suspend/resume / not taken into account for new keyboard## Submitted by Vincent Lefevre
Assigned to **Xorg Project Team**
**[Link to original bug (#71168)](https://bugs.freedesktop.org/show_bug.cgi?id=71168)**
## Description
I have personal XKB settings. From my .initrc file:
xkbcom...## Submitted by Vincent Lefevre
Assigned to **Xorg Project Team**
**[Link to original bug (#71168)](https://bugs.freedesktop.org/show_bug.cgi?id=71168)**
## Description
I have personal XKB settings. From my .initrc file:
xkbcomp -w0 -I$HOME/.xkb -R$HOME/.xkb keymap/custom $DISPLAY
Most often they are lost after suspend/resume on my DELL Latitude E6400 laptop. Moreover when I plug-in a USB keyboard, these settings are not taken into account for this keyboard (the laptop keyboard remains unaffected).
After resume, I can run
xkbcomp -w0 -I$HOME/.xkb -R$HOME/.xkb keymap/custom $DISPLAY
again without quitting the X session, but some running X clients do not take all new settings into account (problem with modifier keys?).
I originally reported the bug on:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633849
where you can find additional details.
Version: githttps://gitlab.freedesktop.org/xorg/lib/libxpm/-/issues/6How to determine number of bits per color channel in XPM3 file2023-12-07T19:37:36ZRobert DodierHow to determine number of bits per color channel in XPM3 fileI'm working on extending a parser for XPM3 files and I think I need to figure out how many bits per color channel are in the color table specification. It appears that most XPM3 files (among the ones I've seen on a couple of Ubuntu insta...I'm working on extending a parser for XPM3 files and I think I need to figure out how many bits per color channel are in the color table specification. It appears that most XPM3 files (among the ones I've seen on a couple of Ubuntu installations, at any rate) assume 8 bits per color channel, so 24 bits per color and therefore 6 hexadecimal digits per color. However, there are a few which assume 16 bits per color channel, 48 bits per color, and 12 hexadecimal digits per color. Aside from inspecting the hexadecimal strings, is there any way to know how many bits per channel are assumed?
A related point for which I believe I know the answer. Whatever the number of bits in the XPM3 file, how many bits per channel are allowed in the libXpm source code? I believe the number is just 8, since it appears that each color channel in XpmColor is represented by a C `char`.
I looked at the source code for libXpm (thank you to all the contributors, I appreciate it) but I was unable to puzzle it out. Documentation which I was able to find (such as xpm.ps.gz in the libXpm project) didn't seem to address the question. Thanks for any light you can shed on this problem.
PS. In case anyone is wondering, I'm working in a language (Common Lisp) for which a parser for XPM3 does not yet exist from what I can tell.https://gitlab.freedesktop.org/xorg/app/xmodmap/-/issues/3Return key gets registered twice.2023-11-28T21:57:01ZTornaxO7Return key gets registered twice.If I execute `xmodmap -pke | rg "Return"` then I'm getting the following output:
```
keycode 36 = Return NoSymbol Return
keycode 55 = adiaeresis Adiaeresis adiaeresis Adiaeresis asciitilde Greek_eta Return Return U2135
```
I'm using th...If I execute `xmodmap -pke | rg "Return"` then I'm getting the following output:
```
keycode 36 = Return NoSymbol Return
keycode 55 = adiaeresis Adiaeresis adiaeresis Adiaeresis asciitilde Greek_eta Return Return U2135
```
I'm using the german `bone` keyboard layout.
Is that expected that a key gets two different keycodes assigned?