xorg issueshttps://gitlab.freedesktop.org/groups/xorg/-/issues2023-09-22T11:47:37Zhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1581Moving from xf86-video-ati to xf86-video-modesetting with multiple GPU's and...2023-09-22T11:47:37ZStuartMoving from xf86-video-ati to xf86-video-modesetting with multiple GPU's and MonitorsI have a setup with two (not recent) AMD graphics cards connected to two monitors.
I currently have an /etc/X11/xorg.conf (quite old) that uses the radeon (ati) driver which gives me two displays :0.0 and :0.1.
On display 0.0 I run a nor...I have a setup with two (not recent) AMD graphics cards connected to two monitors.
I currently have an /etc/X11/xorg.conf (quite old) that uses the radeon (ati) driver which gives me two displays :0.0 and :0.1.
On display 0.0 I run a normal X11 session using a display manager and I use it for normal desktop activites.
On display 0.1 I only run the X server and I use this display to present videos using mplayer.
I have recently updated the os on this machine to LFS/BLFS version 12.0 (Xorg-Server-21.1.8).
This version of LFS/BLFS only supports the modesetting driver, I have manually included the radeon (ati) driver to keep the system running.
However going forward I would, if possible, like to use the modesetting driver for this system.
So far I have discovered that it is not a simple matter of changing the driver type from radeon to modesetting (this just gives me a single :0 clone display).
I have read a number of documents (non describes exacly what I wish to do) which lead me to the concusion that it may be possible but the way forward is not clear to me.
So two questions:
1, Is it possible.
2, What is the simplest way forward.
Thankshttps://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/196Add compose sequences for all four Serbo-Croatian accents on Latin and Cyrill...2023-09-22T01:06:20ZIvan ZakharyaschevAdd compose sequences for all four Serbo-Croatian accents on Latin and Cyrillic letters (the missing ones)Serbo-Croatian uses either Latin or Cyrillic letters, and [four marks](https://en.wikipedia.org/wiki/Shtokavian#Accentuation) when one needs to show the accent (in a dictionary mostly): double grave, inverted breve, grave, acute. No matt...Serbo-Croatian uses either Latin or Cyrillic letters, and [four marks](https://en.wikipedia.org/wiki/Shtokavian#Accentuation) when one needs to show the accent (in a dictionary mostly): double grave, inverted breve, grave, acute. No matter what the base language is (perhaps, English), it would be convenient to be able to input these letters when editing a dictionary entry for a Serbo-Croatian word.
I believe there is currently no deficiency of compose sequences for putting a grave or acute mark on a Latin or Cyrillic letter.
As for double grave, there are [only sequences for Cyrillic letters](https://www.x.org/releases/current/doc/libX11/i18n/compose/en_US.UTF-8.html), but no corresponding ones for Latin letters:
```
Multi_key grave grave Cyrillic_a | "а̏" # CYRILLIC SMALL LETTER A WITH COMBINING DOUBLE GRAVE ACCENT |
Multi_key grave grave Cyrillic_A
Multi_key grave grave Cyrillic_ie
Multi_key grave grave Cyrillic_IE
Multi_key grave grave Cyrillic_i
Multi_key grave grave Cyrillic_I
Multi_key grave grave Cyrillic_o
Multi_key grave grave Cyrillic_O
Multi_key grave grave Cyrillic_u
Multi_key grave grave Cyrillic_U
Multi_key grave grave Cyrillic_er
Multi_key grave grave Cyrillic_ER
```
(Maybe also additionally all the accent marks combined with Cyrillic_el and Latin L would be useful for some Serbo-Croatian dialects that retained the syllabic L in words like *vlk* "wolf", such as [Timok-Prizren (Torlakian)](https://en.wikipedia.org/wiki/Shtokavian#Timok%E2%80%93Prizren_(Torlakian)).)
I suggest adding similar sequences for Latin A, E, I, O, U, R (and maybe L, together with all the other accents on L).
As for inverted breve, there are no such sequences either for Cyrillic or Latin letters now. I suggest inventing a key that would act as an inverted breve after the Compose key and adding sequences with it (for the listed vocalic letters, including R and maybe L). Perhaps, the key could be parenright (since parenleft is sometimes used for breve, though not for all these vocalic letters--there, u or b are used).
* * *
I think that the comments and sequences in <https://www.x.org/releases/current/doc/libX11/i18n/compose/sr_RS.UTF-8.html> miss that R (Cyrillic_er) should be accentable, too. Example: [cȓn / цр̑н](https://en.wiktionary.org/wiki/crn#Serbo-Croatian) "black". And maybe L (Cyrillic_el) in some dialects, which retain syllabic L (I mentioned this above); example: [vlk](https://en.wiktionary.org/wiki/vlk#Serbo-Croatian) "wolf".
And there, they implement the long falling accent as a circumflex, although as we can see in Wikipedia and other places, inverted breve is used for this. (Of course, if someone likes a circumflex, I don't think we should take away the possibility to do so, but we should also add the commonly used inverted breve to represent this accent. Well, I don't know, perhaps it'd be better to replace circumflex with inverted breve in these combinations for Serbian, since it's more correct, but I don't know what the actual wide-spread practice is, whether someone would prefer circumflex, and that would break the compatibility, but since this is limited just to Serbian, the compatibility problem might not be a real problem given that inverted breve is the correct mark.)https://gitlab.freedesktop.org/xorg/app/xrandr/-/issues/70Why is 1440x900 resolution missing from Ubuntu on Xorg environment, but not f...2023-09-17T07:33:21ZTomica KoracWhy is 1440x900 resolution missing from Ubuntu on Xorg environment, but not from Ubuntu environment (Wayland)?I run Ubuntu 22.10 on Dell XPS 13 2-in-1 2020. Its graphic card is Mesa Intel® Xe (TGL GT2). I noticed the following:
* When I log in to the default Ubuntu desktop environment (which is Wayland), I can choose the 1440x900 resolution (16...I run Ubuntu 22.10 on Dell XPS 13 2-in-1 2020. Its graphic card is Mesa Intel® Xe (TGL GT2). I noticed the following:
* When I log in to the default Ubuntu desktop environment (which is Wayland), I can choose the 1440x900 resolution (16x10 aspect ratio).
* When I log in to Ubuntu on Xorg desktop environment, the 1440x900 resolution is not offered as an option.
I see the same behaviour through both the GUI (Settings \> Display), and command line (xrandr). Also, the above resolution was available on Xorg in Ubuntu 22.04.
Why is this happenning? How can I re-enable 1440x900 resolution for the Xorg environment again?
If this is not the appropriate project to raise this issue, please direct me to the one that is.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1578Scrolling on some old style app (no support hi-res wheel scrolling) might ign...2023-12-20T21:00:15Zde tiamScrolling on some old style app (no support hi-res wheel scrolling) might ignore first scroll when direction is changedI just move issue from xorg/driver/xf86-input-libinput#61 to here
---
- Related issue: xorg/driver/xf86-input-libinput#5 #1339I just move issue from xorg/driver/xf86-input-libinput#61 to here
---
- Related issue: xorg/driver/xf86-input-libinput#5 #1339https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/72Fail to build libxcb-1.16 with some values of LC_CTYPE environment2024-02-22T06:09:50ZXi RuoyaoFail to build libxcb-1.16 with some values of LC_CTYPE environmentOriginally reported https://lists.linuxfromscratch.org/sympa/arc/blfs-support/2023-09/msg00019.html.
```
$ LANG=en_US.ISO-8859-1 make -j1
Making all in src
make[1]: Entering directory '/home/xry111/sources/xc/libxcb-1.16/src'
GEN ...Originally reported https://lists.linuxfromscratch.org/sympa/arc/blfs-support/2023-09/msg00019.html.
```
$ LANG=en_US.ISO-8859-1 make -j1
Making all in src
make[1]: Entering directory '/home/xry111/sources/xc/libxcb-1.16/src'
GEN composite.c
Traceback (most recent call last):
File "/home/xry111/sources/xc/libxcb-1.16/src/./c_client.py", line 3395, in <module>
module.generate()
File "//usr/lib/python3.11/site-packages/xcbgen/state.py", line 131, in generate
item.out(name)
File "/home/xry111/sources/xc/libxcb-1.16/src/./c_client.py", line 3212, in c_request
_man_request(self, name, void=not self.reply, aux=False)
File "/home/xry111/sources/xc/libxcb-1.16/src/./c_client.py", line 2676, in _man_request
f.write('%s \\- %s\n' % (func_name, brief))
UnicodeEncodeError: 'latin-1' codec can't encode character '\u201c' in position 68: ordinal not in range(256)
make[1]: *** [Makefile:1425: composite.c] Error 1
make[1]: Leaving directory '/home/xry111/sources/xc/libxcb-1.16/src'
make: *** [Makefile:799: all-recursive] Error 1
```https://gitlab.freedesktop.org/xorg/xserver/-/issues/1577DRM crash when connecting a screen while resuming from suspend2023-09-06T16:09:56ZThiago MacieiraDRM crash when connecting a screen while resuming from suspendBoth times the crash happened, this was the sequence of actions:
1. Suspend laptop with no external monitors connected
2. Plug USB-C cable with external monitor
3. Resume
Steps 2 and 3 do not have to be in that order; it's possible to c...Both times the crash happened, this was the sequence of actions:
1. Suspend laptop with no external monitors connected
2. Plug USB-C cable with external monitor
3. Resume
Steps 2 and 3 do not have to be in that order; it's possible to cause this by first resuming but then quickly attaching the USB-C cable before the screen comes up.
It does not happen 100% of the time: I have done the above without problems recently. Though they may have been different monitors / docks.
Xorg.log:
```
[ 60851.418] (II) modeset(0): Output DP-3-1 has no monitor section
[ 60851.421] (EE)
[ 60851.421] (EE) Backtrace:
[ 60851.421] (EE) 0: /usr/bin/Xorg.bin (xorg_backtrace+0x7e) [0x5618d751aaae]
[ 60851.421] (EE) 1: /usr/bin/Xorg.bin (0x5618d7344000+0x1df409) [0x5618d7523409]
[ 60851.421] (EE) 2: /lib64/libc.so.6 (0x7f95d5a00000+0x3f1b0) [0x7f95d5a3f1b0]
[ 60851.421] (EE) 3: /usr/lib64/xorg/modules/drivers/modesetting_drv.so (0x7f95d545f000+0xe2a0) [0x7f95d546d2a0]
[ 60851.421] (EE) 4: /usr/lib64/xorg/modules/drivers/modesetting_drv.so (0x7f95d545f000+0x14d00) [0x7f95d5473d00]
[ 60851.421] (EE) 5: /usr/bin/Xorg.bin (0x5618d7344000+0x1e2192) [0x5618d7526192]
[ 60851.421] (EE) 6: /usr/bin/Xorg.bin (WaitForSomething+0x1c9) [0x5618d751d4f9]
[ 60851.421] (EE) 7: /usr/bin/Xorg.bin (0x5618d7344000+0x4ceb8) [0x5618d7390eb8]
[ 60851.422] (EE) 8: /lib64/libc.so.6 (0x7f95d5a00000+0x281b0) [0x7f95d5a281b0]
[ 60851.422] (EE) 9: /lib64/libc.so.6 (__libc_start_main+0x8b) [0x7f95d5a28279]
[ 60851.422] (EE) 10: /usr/bin/Xorg.bin (_start+0x27) [0x5618d7391a15]
[ 60851.422] (EE)
[ 60851.422] (EE) Segmentation fault at address 0x0
```
Proper backtrace:
```
#9 0x00007f95d5a3f1b0 in <signal handler called> () at /lib64/libc.so.6
#10 0x00007f95d546d2a0 in drmmode_connector_check_vrr_capable (connector_id=<optimized out>, drm_fd=14)
at /usr/src/debug/xorg-server-21.1.8/hw/xfree86/drivers/modesetting/drmmode_display.c:3159
#11 drmmode_output_init
(pScrn=pScrn@entry=0x5618d8106d40, drmmode=drmmode@entry=0x5618d8107928, mode_res=mode_res@entry=0x5618da96d0d0, num=num@entry=5, dynamic=dynamic@entry=1, crtcshift=crtcshift@entry=0) at /usr/src/debug/xorg-server-21.1.8/hw/xfree86/drivers/modesetting/drmmode_display.c:3313
#12 0x00007f95d5473d00 in drmmode_update_kms_state (drmmode=0x5618d8107928)
at /usr/src/debug/xorg-server-21.1.8/hw/xfree86/drivers/modesetting/drmmode_display.c:4067
#13 0x00005618d7526192 in ospoll_wait (ospoll=0x5618d80e3980, timeout=<optimized out>) at ../../os/ospoll.c:657
#14 0x00005618d751d4f9 in WaitForSomething (are_ready=<optimized out>) at ../../os/WaitFor.c:208
#15 0x00005618d7390eb8 in Dispatch () at ../../dix/dispatch.c:492
#16 dix_main (envp=<optimized out>, argv=0x7ffd5e809588, argc=<optimized out>) at ../../dix/main.c:276
#17 main (argc=<optimized out>, argv=0x7ffd5e809588, envp=<optimized out>) at ../../dix/stubmain.c:34
(gdb) f 10
#10 0x00007f95d546d2a0 in drmmode_connector_check_vrr_capable (connector_id=<optimized out>, drm_fd=14)
at /usr/src/debug/xorg-server-21.1.8/hw/xfree86/drivers/modesetting/drmmode_display.c:3159
```
```
(gdb) f 10
#10 0x00007f95d546d2a0 in drmmode_connector_check_vrr_capable (connector_id=<optimized out>, drm_fd=14)
at /usr/src/debug/xorg-server-21.1.8/hw/xfree86/drivers/modesetting/drmmode_display.c:3159
3159 for (i = 0; !found && i < props->count_props; ++i) {
(gdb) l
3156 props = drmModeObjectGetProperties(drm_fd, connector_id,
3157 DRM_MODE_OBJECT_CONNECTOR);
3158
3159 for (i = 0; !found && i < props->count_props; ++i) {
3160 drmModePropertyPtr drm_prop = drmModeGetProperty(drm_fd, props->props[i]);
(gdb) p props
$1 = (drmModeObjectPropertiesPtr) 0x0
(gdb) up
#11 drmmode_output_init (pScrn=pScrn@entry=0x5618d8106d40, drmmode=drmmode@entry=0x5618d8107928, mode_res=mode_res@entry=0x5618da96d0d0, num=num@entry=5,
dynamic=dynamic@entry=1, crtcshift=crtcshift@entry=0) at /usr/src/debug/xorg-server-21.1.8/hw/xfree86/drivers/modesetting/drmmode_display.c:3313
(gdb) l
3312 ms->is_connector_vrr_capable |=
3313 drmmode_connector_check_vrr_capable(drmmode->fd,
3314 drmmode_output->output_id);
(gdb) p *ms
$6 = {fd = 14, fd_passed = 0, Chipset = 0, pEnt = 0x5618d8107bb0, noAccel = 0, CloseScreen = 0x5618d74305c0 <xf86CursorCloseScreen>,
CreateWindow = 0x5618d74e6380 <fbCreateWindow>, SaveGeneration = 4294967295, createScreenResources = 0x5618d7508ac0 <miCreateScreenResources>,
BlockHandler = 0x7f95d5433b60 <_glamor_block_handler>, SpriteFuncs = 0x5618d75b7c80 <miSpritePointerFuncs>, driver = 0x0, drmmode = {fd = 14, fb_id = 361,
mode_fb = 0x0, cpp = 4, kbpp = 32, scrn = 0x5618d8106d40, gbm = 0x5618d8122aa0, uevent_monitor = 0x5618d89befd0, uevent_handler = 0x5618d8bc4760,
event_context = {version = 0, vblank_handler = 0x0, page_flip_handler = 0x0, page_flip_handler2 = 0x0, sequence_handler = 0x0}, front_bo = {width = 3840,
height = 2400, dumb = 0x0, used_modifiers = 0, gbm = 0x5618da7807a0}, sw_cursor = 0, Options = 0x5618d811fd30, glamor = 1, shadow_enable = 0,
shadow_enable2 = 0, pageflip = 1, force_24_32 = 0, shadow_fb = 0x0, shadow_fb2 = 0x0, pixmapPrivateKeyRec = {offset = 152, size = 64, initialized = 1,
allocated = 0, type = PRIVATE_PIXMAP, next = 0x0}, spritePrivateKeyRec = {screenKey = {offset = 192, size = 0, initialized = 1, allocated = 0,
type = PRIVATE_SCREEN, next = 0x5618d75f0ac0 <miPointerScreenKeyRec>}}, vrrPrivateKeyRec = {offset = 0, size = 0, initialized = 0, allocated = 0,
type = PRIVATE_XSELINUX, next = 0x0}, sprites_visible = 0, reverse_prime_offload_mode = 0, is_secondary = 0, fbcon_pixmap = 0x0, dri2_flipping = 0,
present_flipping = 1, flip_bo_import_failed = 0, can_async_flip = 1, async_flip_secondaries = 0, dri2_enable = 1, present_enable = 1, vrr_prop_id = 24,
use_ctm = 0}, event_context = {version = 4, vblank_handler = 0x7f95d5469c00 <ms_drm_handler>, page_flip_handler = 0x7f95d5469c00 <ms_drm_handler>,
page_flip_handler2 = 0x0, sequence_handler = 0x7f95d5469c30 <ms_drm_sequence_handler_64bit>}, atomic_modeset_capable = 1, atomic_modeset = 0,
pending_modeset = 0, damage = 0x5618d8bc47f0, dirty_enabled = 1, cursor_width = 256, cursor_height = 256, has_queue_sequence = 1, tried_queue_sequence = 1,
kms_has_modifiers = 1, vrr_support = 0, flip_window = 0x5618d9323230, is_connector_vrr_capable = 0, connector_prop_id = 0, shadow = {Setup = 0x0, Add = 0x0,
Remove = 0x0, Update32to24 = 0x0, UpdatePacked = 0x0}, glamor = {back_pixmap_from_fd = 0x7f95d54317f0 <glamor_back_pixmap_from_fd>,
block_handler = 0x7f95d5433ae0 <glamor_block_handler>, clear_pixmap = 0x7f95d5433d40 <glamor_clear_pixmap>,
egl_create_textured_pixmap = 0x7f95d5431950 <glamor_egl_create_textured_pixmap>,
egl_create_textured_pixmap_from_gbm_bo = 0x7f95d54315a0 <glamor_egl_create_textured_pixmap_from_gbm_bo>,
egl_exchange_buffers = 0x7f95d5438c70 <glamor_egl_exchange_buffers>, egl_get_gbm_device = 0x7f95d542fe30 <glamor_egl_get_gbm_device>,
egl_init = 0x7f95d542feb0 <glamor_egl_init>, finish = 0x7f95d5435970 <glamor_finish>, gbm_bo_from_pixmap = 0x7f95d54391e0 <glamor_gbm_bo_from_pixmap>,
init = 0x7f95d5434690 <glamor_init>, name_from_pixmap = 0x7f95d54397a0 <glamor_name_from_pixmap>,
set_drawable_modifiers_func = 0x7f95d54358b0 <glamor_set_drawable_modifiers_func>,
shareable_fd_from_pixmap = 0x7f95d5439660 <glamor_shareable_fd_from_pixmap>,
supports_pixmap_import_export = 0x7f95d5435860 <glamor_supports_pixmap_import_export>, xv_init = 0x7f95d54303e0 <glamor_xv_init>,
egl_get_driver_name = 0x7f95d542fe60 <glamor_egl_get_driver_name>}}
(gdb) p name
$7 = "DP-3-1\000\000\b\000\000\000\025\000\000\000\000\000\000\000\000@\000\000\000\000\000\000\000@\000"
```https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/issues/61scrolling on some old style app (no support hi-res wheel scrolling) might ign...2023-11-23T06:14:29Zde tiamscrolling on some old style app (no support hi-res wheel scrolling) might ignore first scroll when direction is changedFor example, Firefox without MOZ_USE_XINPUT2=1 env var, switch KDE virtual desktop by scroll mouse wheel on desktop, any x11 program that don't support hi-res wheel.
Like this issue:
https://gitlab.freedesktop.org/xorg/xserver/-/issues/...For example, Firefox without MOZ_USE_XINPUT2=1 env var, switch KDE virtual desktop by scroll mouse wheel on desktop, any x11 program that don't support hi-res wheel.
Like this issue:
https://gitlab.freedesktop.org/xorg/xserver/-/issues/1339 <br>
but in KDE plasma x11 session
video (`libinput record` record normal input event, every time I scroll there a `REL_WHEEL` event. `xev` don't): <br>
![Video_2023-09-04_08-20-04](/uploads/a77bcce2cae20a43a4e30ef947d8731a/Video_2023-09-04_08-20-04.mp4)
on real app: <br>
![Video_2023-09-04_08-41-33](/uploads/fb7601035ee1d5a1c878c9f3a74268a8/Video_2023-09-04_08-41-33.mp4)
Mouse: Logitech G903 LS
And even on program support hi-res wheel, first scroll only have half long, maybe relate to #5 <br>
This issue won't happen on evdev or wayland.
<hr>
when I mess around try to find a solution, I found that if I change [this line](https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/blob/master/src/xf86libinput.c#L1853) to <br>`valuator_mask_set_double(mask, 3, value*2);`<br> the issue gone, though all hi-res wheel scroll are twice long now, and first hi-res wheel scroll still only have half longhttps://gitlab.freedesktop.org/xorg/app/xbacklight/-/issues/6Lock Minimum brightness to prevent screen turning off2023-09-02T08:55:31ZCelivalgLock Minimum brightness to prevent screen turning offXbacklight doesn't prevent the backlight from turning off, which some users have found a use for, but can sometimes require a ssh connection, a reboot, or blind typing on a terminal to fix if the keyboard keys haven't been linked to an x...Xbacklight doesn't prevent the backlight from turning off, which some users have found a use for, but can sometimes require a ssh connection, a reboot, or blind typing on a terminal to fix if the keyboard keys haven't been linked to an xbacklight call.
1rst solution:
A way to fix that would be an optional argument to keep the brightness value at a minimum of 1.
(`xcb_randr_query_output_property_valid_values` usually considers 0 as a valid value as far as I can tell, which in most cases, will turn off the backlight. I have not found a case where this is not true, but I am not 100% sure this is the case.)
This way, users that make use of the fact that xbacklight will turn off the screen won't see its behavior changed, but users with a need to keep the backlight on will have the option.
Problem:
One issue with that is that there is no guarantee that a value of 1 will keep the screen on, I have had a laptop whose lowest I could go before the backlight turned off was 40...
2nd solution:
An optional argument specifying the minimum value to set the brightness to.
Same behavior as before for users who don't need the limit.
Problem:
Different screens might have different turn-off and maximum values. As mentioned before, my old laptop turned off at 40, whereas from what I read on other issues, Toshiba Satellite L650D have a maximum backlight value of 7... I have not encountered a situation where xbacklight was capable of controlling multiple screens (either the screens I had didn't support the connected computer controlling the brightness or something else...) and I don't know how this would behave...
3rd solution:
An optional argument to specify the minimum brightness for each specific screen...
Problem:
This is starting to get pretty involved, and doesn't take into account the fact that a screen might change ports, and screen can't be reliably uniquely identified afaik (edid doesn't necessarily have all the info to uniquely identify a screen from what I've seen) Best we can do is specify the ports (eDP1 or DP-1, things like that) or maybe fingerprint the screens with the various info we have... But that's already way outside the scope of xbacklight...
So I don't have a one size fits all solution, which is why I haven't written the code myself, I simply don't know what to do with it...https://gitlab.freedesktop.org/xorg/xserver/-/issues/1576XWayland windows get stuck on drag when a tablet device is disconnected while...2023-10-07T22:58:53ZKodehawaXWayland windows get stuck on drag when a tablet device is disconnected while performing a drag event, inhibiting mouse clicks.If I'm dragging something with a tablet device inside of an XWayland window, and the tablet gets disconnected while dragging for whatever reason (discovered this because my feet met the cable), the dragging action does not get cancelled,...If I'm dragging something with a tablet device inside of an XWayland window, and the tablet gets disconnected while dragging for whatever reason (discovered this because my feet met the cable), the dragging action does not get cancelled, and it inhibits you from clicking anywhere on the window until you reconnect the tablet and move the cursor using the tablet device (or click with the pen), or restart XWayland.
Repro:
1. Start dragging text on an XWayland window using a tablet device
2. Disconnect the tablet device while dragging (do not stop dragging until its disconnected)
3. Moving the mouse will show you the drag contents without you clicking, and trying to right click anywhere in the window will be met with no response. Right clicking works, but if you right click and then left click, left click will still do nothing.
This cannot be reproduced on a Wayland client.
A video reproducing this issue:
![attached here](/uploads/9a7e709ea7f07ccf4cb971185acb10c5/20230901_131030.mp4)https://gitlab.freedesktop.org/xorg/app/xmh/-/issues/1format not a string literal and no format arguments2023-08-31T20:31:41ZMichałformat not a string literal and no format argumentsHello, I tried to compile this program using AUR `xorg-xmh` package and I've ran into this issue:
```
popup.c:511:9: error: format not a string literal and no format arguments [-Werror=format-security]
511 | fprintf(stderr, ptr...Hello, I tried to compile this program using AUR `xorg-xmh` package and I've ran into this issue:
```
popup.c:511:9: error: format not a string literal and no format arguments [-Werror=format-security]
511 | fprintf(stderr, ptr);
| ^~~~~~~
pick.c:250:30: note: expected ‘char *’ but argument is of type ‘const char *’
```
This happens many more times in this code.
I know there is workaround by just adding `-Wno-error=format-security` to CFLAGS, but I think much better solution is to fix these potential security issues.https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/-/issues/226PCI ID list out of date2023-09-21T12:11:03ZDavid OberPCI ID list out of date The file i915_pciids.h has not been updated since Tiger Lake and I have users getting unknown device ID when running un the Alderlake 770 chip They also expect to still be running using xorg with Raptor Lake The file i915_pciids.h has not been updated since Tiger Lake and I have users getting unknown device ID when running un the Alderlake 770 chip They also expect to still be running using xorg with Raptor Lakehttps://gitlab.freedesktop.org/xorg/xserver/-/issues/1573Key release events wake up monitors in DPMS standby2023-08-19T10:03:40ZChris BainbridgeKey release events wake up monitors in DPMS standby(this issue may not be filed against the right project - I don't know exactly which code wakes the monitors back up)
- hold shift
- run `xset dpms force standby`
- release shift after a second
- monitors go to standby but then immediate...(this issue may not be filed against the right project - I don't know exactly which code wakes the monitors back up)
- hold shift
- run `xset dpms force standby`
- release shift after a second
- monitors go to standby but then immediately wake back up
This has been a problem for years, and developers appear to workaround it by adding something like "sleep 1" before running a screen locker (e.g. see the xflock4 commit at https://gitlab.xfce.org/xfce/xfce4-session/-/issues/178 ).
I wonder if it would be possible to fix the root cause by waking up on key press events as usual, but just ignoring key **release** events?https://gitlab.freedesktop.org/xorg/xserver/-/issues/1572xserver segmentation fault when setting HorizSync too high2023-08-17T10:49:32ZStefan B.xserver segmentation fault when setting HorizSync too highWith xerver 1.21.1.8 the Nvidia 340 drivers no longer work due ABI changes.
So the nv driver has to be used.
However, the nv driver only succeeds starting if HorizSync is set in xorg.conf.
To get FHD resolution, it has to be set >60, 68...With xerver 1.21.1.8 the Nvidia 340 drivers no longer work due ABI changes.
So the nv driver has to be used.
However, the nv driver only succeeds starting if HorizSync is set in xorg.conf.
To get FHD resolution, it has to be set >60, 68.
Now the problem is that, the higher one sets HorizSync, the higher is the chance that xserver exits due seg fault.
I guess this might be fixable easily...https://gitlab.freedesktop.org/xorg/xserver/-/issues/1570DPMS state not updated when screen waked via VNC2023-08-11T20:51:40ZSean GreensladeDPMS state not updated when screen waked via VNCI'm working on an application that polls the DPMS state of a monitor, and I noticed that if the monitor goes to sleep and is then woken up via virtual inputs from a VNC session (using x11vnc), the DPMS state remains reported as "off".
`...I'm working on an application that polls the DPMS state of a monitor, and I noticed that if the monitor goes to sleep and is then woken up via virtual inputs from a VNC session (using x11vnc), the DPMS state remains reported as "off".
```
OS: Arch Linux
$ Xorg -version : 1.21.1.8
$ x11vnc -version : 0.9.16
VGA compatible controller: Intel Corporation Apollo Lake [HD Graphics 505]
kernel : 6.4.3-arch1-1
Using modesetting driver
```
Test workflow \#1 (expected behavior):
- \<Monitor is visibly off\>
- xset q | grep Monitor
- Monitor is Off
- \<tap the touchscreen\>
- \<Monitor is visibly on\>
- xset q | grep Monitor
- Monitor is On
Test workflow \#2 (unexpected behavior):
- \<Monitor is visibly off\>
- xset q | grep Monitor
- Monitor is Off
- \<click on window in VNC client\>
- \<Monitor is visibly on\>
- xset q | grep Monitor
- Monitor is Off
Please let me know if there's any additional information you need.https://gitlab.freedesktop.org/xorg/xserver/-/issues/1569Crash / freeze when switching between GUI desktop and tty on Artix, Arch and ...2023-08-04T21:52:32ZdvdCrash / freeze when switching between GUI desktop and tty on Artix, Arch and DevuanSwitching to a tty console results in an empty black screen perhaps 25% of the time, although you can get a sequence of it working or not. This freeze can usually be exited by pressing Fn + F10 (KB backlight) to cycle the keyboard backli...Switching to a tty console results in an empty black screen perhaps 25% of the time, although you can get a sequence of it working or not. This freeze can usually be exited by pressing Fn + F10 (KB backlight) to cycle the keyboard backlight to off, mid and full, then Fn + Insert (sleep) and after it has gone to sleep, press the power button to wake up and it returns to the expected state showing the tty. This is true for the current Zen kernel and LTS kernel, but it didn't happen with an older kernel. I tried updating the BIOS to the latest version and disabling all the performance options and virtualization support in the BIOS, forcing the CPU to 100% all the time with one core and thread, with no change. It is worse using the linux-git kernel and happens almost all the time.
First I tried the kernels available in the Artix archive, the problem started between these two versions:
Bad: linux-5.16.1.artix1-1-x86_64.pkg.tar.zst 16-Jan-2022 13:55
Good: linux-5.15.12.artix1-1-x86_64.pkg.tar.zst 30-Dec-2021 12:03
Then I tried the Arch archive:
Bad: linux-5.16.arch1-1-x86_64.pkg.tar.zst
Good: linux-5.15.13.arch1-1-x86_64.pkg.tar.zst
Then I bisected the kernel:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux/+/8e07757bece6e81b0b0910358ebceca3032bc6c7%5E%21/#F0
It seemed this commit was where the problem started:
commit 8e07757bece6e81b0b0910358ebceca3032bc6c7 (HEAD)
Author: Shyam Prasad N <sprasad@microsoft.com>
Date: Mon Jul 19 10:03:38 2021 +0000
cifs: do not negotiate session if session already exists
Reverting the patch in linux-git did not fix the issue, but changed / improved it. It seemed there were a lot of changes in this section of code including the function in question, the file had even moved to fs/smb/client/connect.c from it's previous location. Unmodified linux-git would never recover by pressing sleep, it required a forced power off. With the reverted patch sleep then resume almost always worked but still it often went to a black screen when switching to a tty. On recovery this message can sometimes be seen on the tty and in syslog:
__common_interrupt: 0.55 No irq handler for vector
I also found on a Dell M4400 a possible variation of the problem, when switching from a tty back to the desktop, the desktop crashes back to the login tty, as I have startx and autologin set up it then restarts automatically although any previously open apps were forcibly terminated in the crash. This happens only about say one in 50 times so it is not so obvious. But on a Dell M4500, switching tty works normally.
There was a similar bug (fixed now) in December 2021 relating to xorg and xorg-server:
https://bbs.archlinux.org/viewtopic.php?id=272327
This does not seem to happen when I use either a 5.15.12 or 5.16.1 Artix kernel on the M4400, so it was not triggered by the exact same commit on there.
I added a printk to the commit revert to try and find out when this was getting called, as I had not found any sign of it using trace-cmd when switching to a tty. But the printk output never appears in dmesg or syslog, even after switching to a tty and freezing - or not. So it looks like this section of code is not used. I don't use any samba things and also did -Rs samba caja-share to remove the samba package and related items, which has not changed the situation either. I guess from this that some kind of buffer overflow / memory corruption / stack smashing type situation could be loading this part of the kernel code due to an error elsewhere, even though it is not being used in the normal course of events?
I installed Gnome desktop (which uses wayland) and gdm, starting the Mate desktop with gdm still has the problem, so it isn't xinitrc, but Gnome using Wayland is not affected, while Gnome using Xorg is, so it seems to be an Xorg bug, or at least Xorg related. Then I tried downgrading various xorg components to see if older versions behaved differently, but they didn't, and beyond a certain point it became difficult with an otherwise updated system due to changes in libxcvt and the switch in Artix away from eudev.
I went back as far as these versions with no change in behaviour:
xf86-input-evdev-2.10.6-2.1-x86_64.pkg.tar.zst
xf86-video-fbdev-0.5.0-2.1-x86_64.pkg.tar.zst
xorg-server-xephyr-1.20.13-3-x86_64.pkg.tar.zst
xf86-input-libinput-1.2.0-1-x86_64.pkg.tar.zst
'xf86-video-intel-1 2.99.917+916+g31486f40-1.1-x86_64.pkg.tar.zst'
xorg-server-xnest-1.20.13-3-x86_64.pkg.tar.zst
xf86-input-synaptics-1.9.1-2-x86_64.pkg.tar.zst
xorg-server-1.20.13-3-x86_64.pkg.tar.zst
xorg-server-xvfb-1.20.13-3-x86_64.pkg.tar.zst
xf86-input-vmmouse-13.1.0-5.1-x86_64.pkg.tar.zst
xorg-server-common-1.20.13-3-x86_64.pkg.tar.zst
xf86-video-dummy-0.3.8-4.1-x86_64.pkg.tar.zst
xorg-server-devel-1.20.13-3-x86_64.pkg.tar.zst
Arch Linux (with systemd) has exactly the same problem. Devuan Daedalus is slightly different - you can switch to another tty, but cannot then switch back to tty7 and the GUI display, either using ctrl alt f7 or chvt. Trying to do so results in the cursor on the tty you are on freezing and becoming unresponsive. But here you can switch back to the existing tty, say tty2, and continue as you were, it is just impossible to return to tty7 once you have left it. In the same way as Artix, using Gnome Wayland works normally but Gnome Xorg exhibits the bug. Switching to tty1 is still possible where GDM starts up though.
This is using a Dell E7470 Ultrabook, hw details:
System:
Kernel: 5.8.14-artix1-1 arch: x86_64 bits: 64 compiler: gcc v: 10.2.0
Desktop: MATE v: 1.27.0 Distro: Artix Linux base: Arch Linux
Machine:
Type: Laptop System: Dell product: Latitude E7470 v: N/A serial: <filter>
Mobo: Dell model: 0T6HHJ v: A00 serial: <filter> UEFI: Dell v: 1.36.3
date: 09/18/2022
Battery:
ID-1: BAT0 charge: 30.4 Wh (100.0%) condition: 30.4/55.0 Wh (55.2%)
volts: 8.6 min: 7.6 model: LGC-LGC3.65 DELL 242WD6C status: full
CPU:
Info: dual core model: Intel Core i7-6600U bits: 64 type: MT MCP
arch: Skylake rev: 3 cache: L1: 128 KiB L2: 512 KiB L3: 4 MiB
Speed (MHz): avg: 2645 high: 2882 min/max: 400/3400 cores: 1: 2808 2: 2882
3: 2550 4: 2340 bogomips: 22408
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3
Graphics:
Device-1: Intel Skylake GT2 [HD Graphics 520] vendor: Dell Latitude E7470
driver: i915 v: kernel arch: Gen-9 bus-ID: 00:02.0
Display: server: X.Org v: 21.1.8 with: Xwayland v: 23.1.2 driver: X:
loaded: intel unloaded: fbdev,modesetting dri: i965 gpu: i915
resolution: 1920x1080~60Hz
API: OpenGL Message: Unable to show GL data. Required tool glxinfo
missing.
Network:
Device-1: Intel Wireless 8260 driver: iwlwifi v: kernel bus-ID: 01:00.0
IF: wlan0 state: down mac: <filter>
Drives:
Local Storage: total: 238.47 GiB used: 71.3 GiB (29.9%)
ID-1: /dev/nvme0n1 vendor: Western Digital model: PC SN720
SDAPNTW-256G-1016 size: 238.47 GiB temp: 40.9 C
Partition:
ID-1: / size: 120 GiB used: 71.07 GiB (59.2%) fs: btrfs dev: /dev/nvme0n1p6
ID-2: /boot size: 500 MiB used: 228.7 MiB (45.7%) fs: btrfs
dev: /dev/nvme0n1p2
ID-3: /boot/efi size: 299.4 MiB used: 292 KiB (0.1%) fs: vfat
dev: /dev/nvme0n1p1
ID-4: swap-1 size: 16 GiB used: 0 KiB (0.0%) fs: swap dev: /dev/nvme0n1p3
Info:
Processes: 199 Uptime: 11m Memory: available: 7.67 GiB
used: 680.6 MiB (8.7%) Init: OpenRC runlevel: default Compilers: gcc: 13.1.1
Packages: 707 Shell: Bash v: 5.1.16 inxi: 3.3.27
[]([oldkernelswitchingttynoproblemXorg.0.log.gz](/uploads/1012cd750a867af793f46f0753231c92/oldkernelswitchingttynoproblemXorg.0.log.gz)[example-of-ttyblackscreen-Xorg.0.log.gz](/uploads/415f9ec8713ae1c7c25a57c5b92a2ede/example-of-ttyblackscreen-Xorg.0.log.gz)[commitrevertpatch.diff.gz](/uploads/bf17cf034a7fd466df59fa224dcbc684/commitrevertpatch.diff.gz)https://gitlab.freedesktop.org/xorg/app/xclock/-/issues/425 hour, 26 hour2023-08-03T03:25:12ZAlex Remizoff25 hour, 26 hour```
xclock -digital -strftime '%a, %d %b, %Y-%m-%d %H:%M:%S' -update 1 -face 'Liberation Mono:size=72'
```
![photo_2023-08-03_06-23-06](/uploads/36c5e999cea2d5c8f98a7b65d77c639b/photo_2023-08-03_06-23-06.jpg)
![Снимок_экрана_2023-08-03...```
xclock -digital -strftime '%a, %d %b, %Y-%m-%d %H:%M:%S' -update 1 -face 'Liberation Mono:size=72'
```
![photo_2023-08-03_06-23-06](/uploads/36c5e999cea2d5c8f98a7b65d77c639b/photo_2023-08-03_06-23-06.jpg)
![Снимок_экрана_2023-08-03_06-24-20](/uploads/49bc9217b318a3ee0b0a9c85827e5529/Снимок_экрана_2023-08-03_06-24-20.png)https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/195Still reachable bytes, is that unavoidable?2023-09-02T20:14:12ZHenrique N. LenglerStill reachable bytes, is that unavoidable?I am developing a program using Xlib, and by running it through valgrind it detects many bytes that are still reachable after execution.
I posted the details and a minimal example here: https://stackoverflow.com/questions/76808501/xlib...I am developing a program using Xlib, and by running it through valgrind it detects many bytes that are still reachable after execution.
I posted the details and a minimal example here: https://stackoverflow.com/questions/76808501/xlib-memory-leak-when-loading-specific-font-string
I am using LibX11 6.4.0.
I know still reachable bytes are not that much of a problem, but I think ideally programs must have a clean exit.
Is this inevitable?
Thanks,https://gitlab.freedesktop.org/xorg/app/xditview/-/issues/1pop-up menu doesn't work2023-07-29T18:49:42ZG. Branden Robinsonpop-up menu doesn't workMenu items in the pop-up menu (drawn over the Dvi widget) cannot be selected.
To reproduce:
1. Launch xditview.
2. Left-click on the main window (not in the menu or scroll bars).
3. Attempt to select an item.
This issue also affects gr...Menu items in the pop-up menu (drawn over the Dvi widget) cannot be selected.
To reproduce:
1. Launch xditview.
2. Left-click on the main window (not in the menu or scroll bars).
3. Attempt to select an item.
This issue also affects groff's gxditview client, which is how it came to my attention. However, it does not affect _all_ of our users, so I suspect a problem with one of the libraries.
Background (possibly tedious):
A. https://lists.gnu.org/archive/html/groff/2023-07/msg00138.html
B. https://lists.gnu.org/archive/html/groff/2023-07/msg00153.htmlhttps://gitlab.freedesktop.org/xorg/app/xinit/-/issues/21xinit tries to use :0 every time.2023-07-29T15:40:54ZNobodyxinit tries to use :0 every time.I tried to start a second X server on my system, using startx, and it failed saying that Server :0 was already running. This is true, but there were may other available integeres.
I tracked down the issue to xinit, and created the foll...I tried to start a second X server on my system, using startx, and it failed saying that Server :0 was already running. This is true, but there were may other available integeres.
I tracked down the issue to xinit, and created the following patch, which works for me.https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/193display crashes on thin images2023-07-25T16:20:01Zthesourcerer8display crashes on thin imagesI have filed an issue against ImageMagick:
https://github.com/ImageMagick/ImageMagick/issues/6509
When I try to display the attached image ![output](/uploads/af18ffa80855b1e165e8977524c7e431/output.png), display crashes, the stacktrace ...I have filed an issue against ImageMagick:
https://github.com/ImageMagick/ImageMagick/issues/6509
When I try to display the attached image ![output](/uploads/af18ffa80855b1e165e8977524c7e431/output.png), display crashes, the stacktrace indicates an endless recursive loop inside the PutSubImage function:
```
#5954 0x00007ffff72e4c7a in PutSubImage (dpy=0x555555571d90, d=71305664, gc=0x5555555bda50, image=0x555555629c50, req_xoffset=, req_yoffset=, x=0, y=0, req_width=2096928,
req_height=1, dest_bits_per_pixel=32, dest_scanline_pad=32) at ../../src/PutImage.c:920
#5955 0x00007ffff72e4c7a in PutSubImage (dpy=0x555555571d90, d=71305664, gc=0x5555555bda50, image=0x555555629c50, req_xoffset=, req_yoffset=, x=0, y=0, req_width=2096928,
req_height=1, dest_bits_per_pixel=32, dest_scanline_pad=32) at ../../src/PutImage.c:920
#5956 0x00007ffff72e4c7a in PutSubImage (dpy=0x555555571d90, d=71305664, gc=0x5555555bda50, image=0x555555629c50, req_xoffset=, req_yoffset=, x=0, y=0, req_width=2096928,
req_height=1, dest_bits_per_pixel=32, dest_scanline_pad=32) at ../../src/PutImage.c:920
#5957 0x00007ffff72e4c7a in PutSubImage (dpy=0x555555571d90, d=71305664, gc=0x5555555bda50, image=0x555555629c50, req_xoffset=, req_yoffset=, x=0, y=0, req_width=2096928,
req_height=1, dest_bits_per_pixel=32, dest_scanline_pad=32) at ../../src/PutImage.c:920![output](/uploads/6070967f4e7ff8cb465bac134935f531/output.png)
```
I guess that the problem is that due to the very wide and thing image (138240 x 16) display wants to scale it down for a thumbnail to the screensize, divides the height by some bigger factor, which then gets rounded down to 0 pixel, and then Xlib/libxcb crashes trying to resize or display the 0 pixel height image.