xserver issueshttps://gitlab.freedesktop.org/xorg/xserver/-/issues2022-01-11T14:24:14Zhttps://gitlab.freedesktop.org/xorg/xserver/-/issues/870Xephyr can not support evdev driver on version 1.20.12022-01-11T14:24:14Zmayoyo502Xephyr can not support evdev driver on version 1.20.1Xephyr-1.20.1 can not support evdev device whether when I update the kernel to 5.2.4-1.el7.elrepo.x86_64 . It is ok on Ubuntu18.04(Xephyr-1.19.6).
The log like this:
sudo Xephyr :1 -screen 800x600 -keybd evdev,,device=/dev/input/event2 ...Xephyr-1.20.1 can not support evdev device whether when I update the kernel to 5.2.4-1.el7.elrepo.x86_64 . It is ok on Ubuntu18.04(Xephyr-1.19.6).
The log like this:
sudo Xephyr :1 -screen 800x600 -keybd evdev,,device=/dev/input/event2 -mouse evdev,,device=/dev/input/event3
Couldn't find pointer driver evdev
Couldn't find keyboard driver evdev*
I downloaded the xserver-1.19.6 and xserver-1.20.1 source packets,and compare them, find the kdriver missing some file refer to evdev. Please give some advise and patchc to fix it.https://gitlab.freedesktop.org/xorg/xserver/-/issues/837Xephyr Crash when executing command lightdm --test-mode --debug2019-07-01T15:16:14ZPradeep KumarXephyr Crash when executing command lightdm --test-mode --debugExperiencing crash when executing command.
`lightdm --test-mode --debug`
* [log](/uploads/9e2ddcc42aee9b416a12cc277e414f20/ArQuzBGG.txt)
* [stack](/uploads/896c28cc9299c3841d8c5f812c938b5d/t0uydjEi.txt)
* [core dump](/uploads/4c8761d99d...Experiencing crash when executing command.
`lightdm --test-mode --debug`
* [log](/uploads/9e2ddcc42aee9b416a12cc277e414f20/ArQuzBGG.txt)
* [stack](/uploads/896c28cc9299c3841d8c5f812c938b5d/t0uydjEi.txt)
* [core dump](/uploads/4c8761d99d9bbc58ad9f3429b1d4cdf2/core)
X.Org X Server 1.19.6
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.4.0-148-generic x86_64 Ubuntu
Current Operating System: Linux pradeep-Z97N-WIFI 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-54-generic root=UUID=bbc5eb56-3db0-402e-8b98-7350c76f791b ro quiet splash vt.handoff=1
Build Date: 03 June 2019 08:10:35AM
xorg-server 2:1.19.6-1ubuntu4.3 (For technical support please see http://www.ubuntu.com/support)
Current version of pixman: 0.34.0
distro: elementary OS 5.0 Juno
GTK+ 3.22.30https://gitlab.freedesktop.org/xorg/xserver/-/issues/127Xephyr Composite extension broken2019-05-09T20:15:57ZBugzilla Migration UserXephyr Composite extension broken## Submitted by Theodore Lytras
Assigned to **Xorg Project Team**
**[Link to original bug (#105133)](https://bugs.freedesktop.org/show_bug.cgi?id=105133)**
## Description
I use Xephyr to play Sid Meier's Alpha Centauri (yes, peopl...## Submitted by Theodore Lytras
Assigned to **Xorg Project Team**
**[Link to original bug (#105133)](https://bugs.freedesktop.org/show_bug.cgi?id=105133)**
## Description
I use Xephyr to play Sid Meier's Alpha Centauri (yes, people still play that), and this requires disabling its Composite extension (or the game hangs). Unfortunately, on my Debian sid amd64 machine with Xephyr version 1.19.6 this throws an error (used to work with version 1.19.5):
$ Xephyr :1 -screen 800x600 -extension Composite
Xephyr: ../../../../include/privates.h:122: dixGetPrivateAddr: Assertion `key-
>initialized' failed.
(EE)
(EE) Backtrace:
(EE) 0: Xephyr (xorg_backtrace+0x4d) [0x5608257337bd]
(EE) 1: Xephyr (0x56082556d000+0x1ca559) [0x560825737559]
(EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f0b03af6000+0x12180)
[0x7f0b03b08180]
(EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (gsignal+0x110) [0x7f0b037746a0]
(EE) 4: /lib/x86_64-linux-gnu/libc.so.6 (abort+0x1c7) [0x7f0b03775cf7]
(EE) 5: /lib/x86_64-linux-gnu/libc.so.6 (0x7f0b03740000+0x2cfca)
[0x7f0b0376cfca]
(EE) 6: /lib/x86_64-linux-gnu/libc.so.6 (0x7f0b03740000+0x2d042)
[0x7f0b0376d042]
(EE) 7: Xephyr (0x56082556d000+0x3c252) [0x5608255a9252]
(EE) 8: Xephyr (0x56082556d000+0x1c1c1f) [0x56082572ec1f]
(EE) 9: Xephyr (0x56082556d000+0x12c667) [0x560825699667]
(EE) 10: Xephyr (0x56082556d000+0x12bcc5) [0x560825698cc5]
(EE) 11: Xephyr (0x56082556d000+0x12b115) [0x560825698115]
(EE) 12: Xephyr (InitExtensions+0x3d) [0x56082562ce2d]
(EE) 13: Xephyr (0x56082556d000+0x7c93f) [0x5608255e993f]
(EE) 14: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xea)
[0x7f0b03760f2a]
(EE) 15: Xephyr (_start+0x2a) [0x5608255a92fa]
(EE)
(EE)
Fatal server error:
(EE) Caught signal 6 (Aborted). Server aborting
(EE)
Without "-extension Composite" Xephyr starts, but unfortunately I can't play
the game.
Given that this is the only reason I use Xephyr (and I suspect that
applies to many people as well), I guess this bug qualifies as "major"...
Version: 7.7 (2012.06)https://gitlab.freedesktop.org/xorg/xserver/-/issues/126Xephyr crashes during "hotplug" event2018-12-13T18:27:26ZBugzilla Migration UserXephyr crashes during "hotplug" event## Submitted by zhi..@..il.com
Assigned to **Xorg Project Team**
**[Link to original bug (#101440)](https://bugs.freedesktop.org/show_bug.cgi?id=101440)**
## Description
Created attachment 131968
patch for Xephyr crashes during "h...## Submitted by zhi..@..il.com
Assigned to **Xorg Project Team**
**[Link to original bug (#101440)](https://bugs.freedesktop.org/show_bug.cgi?id=101440)**
## Description
Created attachment 131968
patch for Xephyr crashes during "hotplug" event
I use a PXE setup to boot a terminal and play multiseat with Xephyr to run the second seat. And I use a script to start Xephyr and loginctl to assign devices to Xephyr at the same time. The process with loginctl takes several seconds, so I hotplug the USB standard keyboard or mouse at the the meanwhile. That will lead to Xephyr crashes during "hotplug" event and generate a core dump.
Analyzed the core dump I found the "kdKeyboards" and "kdPointers" link list were run into mess. When deference the invalid address, a segment fault will occur.
Checked the code I found several memory leakages and use-after-free issues in the negative conditions. The places of use-after-free are match the scenario I've met.
If I hotplug the USB device during Xephyr boot up, the hotplugging operations
may lead to activate or enable device failed, in such case we not only
need to free memory, but also need to remove the point/keyboard info from the
kdPointers/kdKeyboards link list. Otherwise, when deference the node has left on the link list will cause crashes.
It's very hard to reproduce on a system run on hard disk or USB stick, since the loginctl will be finished in a flash, you cannot catch the moment to plug out the USB device.
I've enclosed the patch, after apply it the issue cannot be reproduced anymore.
**Patch 131968**, "patch for Xephyr crashes during "hotplug" event":
[kdrive-ephyr-fix-some-memory-leakage-and-use-after-free.patch](/uploads/a646ef599c9b57a10f23d2c04efbaa34/kdrive-ephyr-fix-some-memory-leakage-and-use-after-free.patch)
Version: githttps://gitlab.freedesktop.org/xorg/xserver/-/issues/122Xephyr crashes after xrandr -o left2018-12-13T18:27:19ZBugzilla Migration UserXephyr crashes after xrandr -o left## Submitted by Maciej Piechotka
Assigned to **Xorg Project Team**
**[Link to original bug (#100458)](https://bugs.freedesktop.org/show_bug.cgi?id=100458)**
## Description
```
#0 DamageDestroy (pDamage=0x0)
at /var/tmp/portag...## Submitted by Maciej Piechotka
Assigned to **Xorg Project Team**
**[Link to original bug (#100458)](https://bugs.freedesktop.org/show_bug.cgi?id=100458)**
## Description
```
#0 DamageDestroy (pDamage=0x0)
at /var/tmp/portage/x11-base/xorg-server-1.19.3/work/xorg-server-1.19.3/miext/damage/damage.c:1812
pScreen = <optimized out>
#1 0x00005555555945b6 in ephyrUnsetInternalDamage (pScreen=<optimized out>)
at /var/tmp/portage/x11-base/xorg-server-1.19.3/work/xorg-server-1.19.3/hw/kdrive/ephyr/ephyr.c:397
screen = <optimized out>
scrpriv = 0x555555a084c0
#2 0x000055555561e218 in KdCloseScreen (pScreen=0x555555a1abc0)
at /var/tmp/portage/x11-base/xorg-server-1.19.3/work/xorg-server-1.19.3/hw/kdrive/src/kdrive.c:696
screen = 0x555555a08420
card = 0x555555a083e0
ret = <optimized out>
#3 0x00005555556687d8 in CursorCloseScreen (pScreen=0x555555a1abc0)
at /var/tmp/portage/x11-base/xorg-server-1.19.3/work/xorg-server-1.19.3/xfixes/cursor.c:188
ret = <optimized out>
close_proc = <optimized out>
display_proc = <optimized out>
#4 0x00005555556eb673 in AnimCurCloseScreen (pScreen=<optimized out>)
at /var/tmp/portage/x11-base/xorg-server-1.19.3/work/xorg-server-1.19.3/render/animcur.c:105
ret = <optimized out>
#5 0x00005555556f0421 in present_close_screen (screen=0x555555a1abc0)
at /var/tmp/portage/x11-base/xorg-server-1.19.3/work/xorg-server-1.19.3/present/present_screen.c:64
No locals.
#6 0x00005555555dac37 in dix_main (argc=3, argv=0x7fffffffe188, envp=<optimized out>)
at /var/tmp/portage/x11-base/xorg-server-1.19.3/work/xorg-server-1.19.3/dix/main.c:336
i = 0
alwaysCheckForInput = {0, 1}
#7 0x00007ffff3b08a9c in __libc_start_main (main=0x555555592fc0 <main>, argc=3, argv=0x7fffffffe188,
init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe178)
at ../csu/libc-start.c:289
result = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, 2135648631830717996, 93824992489520, 140737488347520, 0, 0,
5257402869750015532, 5257412227087574572}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0,
0x5555557626d0 <__libc_csu_fini>, 0x7ffff7de82f0 <_dl_fini>}, data = {prev = 0x0, cleanup = 0x0,
canceltype = 1433806544}}}
not_first_call = <optimized out>
#8 0x0000555555593059 in _start ()
No symbol table info available.
```https://gitlab.freedesktop.org/xorg/xserver/-/issues/119Xephyr window resolution is limited to 2×width and 2×height of the current s...2018-12-13T18:27:10ZBugzilla Migration UserXephyr window resolution is limited to 2×width and 2×height of the current screen## Submitted by det..@..il.com
Assigned to **Xorg Project Team**
**[Link to original bug (#97629)](https://bugs.freedesktop.org/show_bug.cgi?id=97629)**
## Description
I use Xephyr to make high resolution screenshots of a web inte...## Submitted by det..@..il.com
Assigned to **Xorg Project Team**
**[Link to original bug (#97629)](https://bugs.freedesktop.org/show_bug.cgi?id=97629)**
## Description
I use Xephyr to make high resolution screenshots of a web interface. Screenshots must look good when printed. So I run
$ Xephyr :108 -dpi 300 -screen 3413x1920
(This resolution equals 1024×576 @90 dpi multiplied by 3.33(3), which is the ratio between 300 and 90 dpi)
but without passing -resizeable the window is smaller than it should be, and a part of the browser in fullscreen is hidden. I am not talking about those parts, that are initially hidden, because Xephyr window is way too large, I’m talking about those you won’t see even if you grab the window and drag to its very right or bottom edges.
I first noticed that at home, where I have 1920×1080 display, but I thought that the resolution is fixed to certain values. With the resolution I used, 3413×1920, which — note that — smaller than 2×1920 × 2×1080, I didn’t experience any troubles. But when I took my laptop and tried to open the same Xephyr window on a 1366×768 screen, I’ve seen only a part!
Strange is, that -resizeable key fixes the issue. Though I have to ‘untile’ the window first this way, which is not convenient to do each time and requires a setting in the WM to do this automatically.
Steps to reproduce:
1. Choose a screen resolution at least 2.5 times larger than yours.
2. Pick a high dpi, 300 for instance.
3. Run
$ Xephyr :108 -dpi 300 -screen XRESxYRES
4. Run some application.
$ DISPLAY=:108 vivaldi
Make it fullsreen. Window -> Go fullscreen or F11 works for vivaldi.
5. See the window cropped.
6. Drag the window so its right edge would be at physical screen edge. Move the mouse to the left edge of the physical screen, press and hold the left mouse button on the Xephyr window, so it could be dragged. Drag the cursor all the way to the right edge of the screen.
7. See that Xephyr window is limited to two widths of your screen.https://gitlab.freedesktop.org/xorg/xserver/-/issues/123Xephyr DPI handling2018-12-13T18:27:21ZBugzilla Migration UserXephyr DPI handling## Submitted by Vladimir
Assigned to **Xorg Project Team**
**[Link to original bug (#96240)](https://bugs.freedesktop.org/show_bug.cgi?id=96240)**
## Description
Please make Xephyr retain DPI when it's screen size is changed. This...## Submitted by Vladimir
Assigned to **Xorg Project Team**
**[Link to original bug (#96240)](https://bugs.freedesktop.org/show_bug.cgi?id=96240)**
## Description
Please make Xephyr retain DPI when it's screen size is changed. This is especially needed with '-resizeable' option.
Currently any screen size change results in inconsistent DPI jumps.
Also please make it possible to change Xephyr's DPI with 'xrandr --dpi XX'https://gitlab.freedesktop.org/xorg/xserver/-/issues/128Xephyr -parent option fails with a BadMatch error2019-06-18T22:36:37ZBugzilla Migration UserXephyr -parent option fails with a BadMatch error## Submitted by Javier Celaya
Assigned to **Xorg Project Team**
**[Link to original bug (#91700)](https://bugs.freedesktop.org/show_bug.cgi?id=91700)**
## Description
Created attachment 117808
potential patch for this bug
Tested ...## Submitted by Javier Celaya
Assigned to **Xorg Project Team**
**[Link to original bug (#91700)](https://bugs.freedesktop.org/show_bug.cgi?id=91700)**
## Description
Created attachment 117808
potential patch for this bug
Tested on Fedora 22 x86_64, with both packaged Xephyr and compiled from git.
Trying to use an existing window with Xephyr (option -parent) fails with a BadMatch X11 error. It looks like there is a problem with the visual selected to create new windows under the existing one. Inheriting the visual seems to fix the problem. A patch is attached.
The output of the error (with debug messages) is:
```
$ hw/kdrive/ephyr/Xephyr :1 -parent 52428817 -verbosity 100
InitConnectionLimits: MaxClients = 256
(!!) in ephyrinit.c:309:ddxProcessArgument: (!!) set verbosiry to 100
(WW) Failed to open protocol names file /usr/local/lib/xorg/protocol.txt
(!!) in ephyr.c:237:ephyrMapFramebuffer: (!!) screen->width: 640, screen->height: 480 index=0(!!) in ephyr.c:651:ephyrInitScreen: (!!) pScreen->myNum:0
(!!) in ephyrvideo.c:222:ephyrInitVideo: (!!) enter
(!!) in ephyrvideo.c:252:ephyrXVPrivNew: (!!) enter
(!!) in ephyrvideo.c:450:ephyrXVPrivQueryHostAdaptors: (!!) enter
(!!) in ephyrvideo.c:469:ephyrXVPrivQueryHostAdaptors: (!!) host has 2 adaptors
(!!) in ephyrvideo.c:563:ephyrXVPrivQueryHostAdaptors: (!!) leave
(!!) in ephyrvideo.c:575:ephyrXVPrivSetAdaptorsHooks: (!!) enter
(!!) in ephyrvideo.c:608:ephyrXVPrivSetAdaptorsHooks: (!!) leave
(!!) in ephyrvideo.c:269:ephyrXVPrivNew: (!!) leave
(!!) in ephyrvideo.c:619:ephyrXVPrivRegisterAdaptors: (!!) enter
(!!) in ephyrvideo.c:628:ephyrXVPrivRegisterAdaptors: (!!) there are 2 registered adaptors
(!!) in ephyrvideo.c:633:ephyrXVPrivRegisterAdaptors: (!!) leave
(!!) in ephyr.c:668:ephyrInitScreen: (!!) initialized xvideo okay
(!!) in ephyr.c:674:ephyrInitScreen: (!!) host x does not support DRI. Disabling DRI forwarding
Sync Extension 3.1
(II) AIGLX: Loaded and initialized swrast
(II) GLX: Initialized DRISWRAST GL provider for screen 0
(!!) in ephyr.c:718:ephyrCreateResources: (!!) mark pScreen=0xddc950 mynum=0 shadow=0[dix] Could not init font path element /usr/share/X11/fonts/TTF/, removing from list!
[dix] Could not init font path element /usr/share/X11/fonts/OTF/, removing from list!
Popen: `"/usr/bin/xkbcomp" -w 1 "-R/usr/share/X11/xkb" -xkm "-" -em1 "The XKEYBOARD keymap compiler (xkbcomp) reports:" -emp "> " -eml "Errors from xkbcomp are not fatal to the X server" "/tmp/server-1.xkm"', fp = 0xeabc50
Pclose: fp = 0xeabc50
Loaded XKB keymap /tmp/server-1.xkm, defined=0x7f
(II) XKB: Reusing cached keymap
added keyboard (null) with dix id 6
(dix) initialising device 6
initialising keyboard (null)
(II) XKB: Reusing cached keymap
(dix) initialising device 7
initialising pointer Generic Pointer ...
(dix) enabling device 6
(dix) enabling device 7
client(0): Reserved pid(18064).
client(0): Reserved cmdname(hw/kdrive/ephyr/Xephyr) and cmdargs(:1 -parent 52428817 -verbosity 100).
(EE)
Fatal server error:
(EE) X11 error
Error code: 8
Sequence number: 5
Major code: 1 Minor code: 0
Error value: 52428817
(EE)
```
**Attachment 117808**, "potential patch for this bug":
[0001-Fix-Xephyr-visual-with-parent-option.patch](/uploads/b30f50653933780d5b1df60f307cc794/0001-Fix-Xephyr-visual-with-parent-option.patch)
Version: githttps://gitlab.freedesktop.org/xorg/xserver/-/issues/124passing --enable-xephyr with --disable-kdrive will not build xephyr and does ...2018-12-13T18:27:22ZBugzilla Migration Userpassing --enable-xephyr with --disable-kdrive will not build xephyr and does not result in an error## Submitted by Dylan Baker `@dbaker`
Assigned to **Xorg Project Team**
**[Link to original bug (#87986)](https://bugs.freedesktop.org/show_bug.cgi?id=87986)**
## Description
I configured the xorg-xserver component with --enable-x...## Submitted by Dylan Baker `@dbaker`
Assigned to **Xorg Project Team**
**[Link to original bug (#87986)](https://bugs.freedesktop.org/show_bug.cgi?id=87986)**
## Description
I configured the xorg-xserver component with --enable-xephyr, and --disable-kdrive. This resulted in no configuration error, but in building an xserver that doesn't have xephyr. When I read the autoconfiguration files I became clear that kdrive was necissary, and once I enabled kdrive I did in fact get xephyr
Version: githttps://gitlab.freedesktop.org/xorg/xserver/-/issues/121Xephyr in the case of using XRandR2018-12-13T18:27:17ZBugzilla Migration UserXephyr in the case of using XRandR## Submitted by kta..@..il.com
Assigned to **Xorg Project Team**
**[Link to original bug (#69456)](https://bugs.freedesktop.org/show_bug.cgi?id=69456)**
## Description
Created attachment 85953
patch of Xephyr
We have developed a ...## Submitted by kta..@..il.com
Assigned to **Xorg Project Team**
**[Link to original bug (#69456)](https://bugs.freedesktop.org/show_bug.cgi?id=69456)**
## Description
Created attachment 85953
patch of Xephyr
We have developed a application that works on Xephyr.
Our system changes resolution of the display many times by using XRandR.
(For example, more than 1000 times)
At that time, undeletable modeline is set unintentionally.
For example...
Modelines when I changed the resolution twice.
(632x1140, 1288x1428)
/xorg-server-1.6.5/hw/kdrive/ephyr> xrandr
Screen 0: minimum 160 x 160, current 1288 x 1428, maximum 1600 x 1428
default connected 1288x1428+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
...
1024x768 0.0
...
160x160 0.0
632x1140 0.0 <- unexpected modeline. Cannot delete.
1288x1428 0.0* <- unexpected modeline. Cannot delete.
632x1140_60.00 59.4 <- expected modeline. Can delete.
1288x1428_60.00 59.8 <- expected modeline. Can delete.
As a result, the time required to change the display resolution increases steadily.
(Number of modelines will be more than 1000.)
Is this a specification?
To prevent increasing number of modelines, I have applied the patch to Xephyr.
In this patch, I intend to suppress RRRegisterSize call.
This measure is correct?
Are there any side effects?
Please tell me if there is other measures.
**Attachment 85953**, "patch of Xephyr":
[xorg-server-xephyrXRandR.patch](/uploads/bfd7a4ada9265d11f2b9a7438599fe9a/xorg-server-xephyrXRandR.patch)
Version: 7.4 (2008.09)https://gitlab.freedesktop.org/xorg/xserver/-/issues/117Add multitouch support to Xephyr2018-12-13T18:37:41ZBugzilla Migration UserAdd multitouch support to Xephyr## Submitted by Frederic Plourde `@fredinfinite23`
Assigned to **Xorg Project Team**
**[Link to original bug (#56011)](https://bugs.freedesktop.org/show_bug.cgi?id=56011)**
## Description
This bug is for upstream tracking purposes...## Submitted by Frederic Plourde `@fredinfinite23`
Assigned to **Xorg Project Team**
**[Link to original bug (#56011)](https://bugs.freedesktop.org/show_bug.cgi?id=56011)**
## Description
This bug is for upstream tracking purposes only.
The patch can be found here :
http://cgit.collabora.com/git/user/tomeu/xserver/log/?h=xephyr-touch
The patch has already been discussed. We're currently taking a look at making this branch acceptable for upstream.https://gitlab.freedesktop.org/xorg/xserver/-/issues/116Should set the keyboard layout based on the current X session2018-12-13T18:27:04ZBugzilla Migration UserShould set the keyboard layout based on the current X session## Submitted by Vincent Untz `@vuntz`
Assigned to **Matthew Allum**
**[Link to original bug (#15417)](https://bugs.freedesktop.org/show_bug.cgi?id=15417)**
## Description
My current X session has a FR keyboard layout. When I launc...## Submitted by Vincent Untz `@vuntz`
Assigned to **Matthew Allum**
**[Link to original bug (#15417)](https://bugs.freedesktop.org/show_bug.cgi?id=15417)**
## Description
My current X session has a FR keyboard layout. When I launch Xephyr, the default layout is US, which makes me want to do bad things :-)
It'd be nice to have Xephyr automatically set the default layout to the one used in the X session hosting Xephyr.https://gitlab.freedesktop.org/xorg/xserver/-/issues/129in Xephyr with -fakexa, using Render to composite a transformed, redirected w...2018-12-13T18:27:32ZBugzilla Migration Userin Xephyr with -fakexa, using Render to composite a transformed, redirected window has *really* bizarre coordinate problems## Submitted by Nathaniel J. Smith `@njs`
Assigned to **Matthew Allum**
**[Link to original bug (#13117)](https://bugs.freedesktop.org/show_bug.cgi?id=13117)**
## Description
This is basically a repeat of #13116, except for runnin...## Submitted by Nathaniel J. Smith `@njs`
Assigned to **Matthew Allum**
**[Link to original bug (#13117)](https://bugs.freedesktop.org/show_bug.cgi?id=13117)**
## Description
This is basically a repeat of #13116, except for running Xephyr in its -fakexa rendering mode, so see that bug's intial filing for details. The same test program generates even stranger results -- the same thing happens when the redirected window is moved against the root (its composited image moves around inside its coordinate space), but with -fakexa, moving the display window around against the root *also* causes its contents to move in strange ways. The whole coordinate system appears to be translated around -- both the composited image and the white box that I draw directly to show the origin of the transformed coordinate system move around together. I've attached a movie of this weirdness.
If I set the scaling factor to 1 and move the redirected window around, then its display does not move. If I move the display window around instead, then something odd happens as well -- the white origin box that I draw moves around just as in the above movie, but now the composited image of the redirected window remains fixed, at the correct location (!).
Version: 7.3 (2007.09)https://gitlab.freedesktop.org/xorg/xserver/-/issues/120in Xephyr, using Render to composite a transformed, redirected window has biz...2018-12-13T18:27:15ZBugzilla Migration Userin Xephyr, using Render to composite a transformed, redirected window has bizarre coordinate problems## Submitted by Nathaniel J. Smith `@njs`
Assigned to **Eric Anholt `@anholt`**
**[Link to original bug (#13116)](https://bugs.freedesktop.org/show_bug.cgi?id=13116)**
## Description
I'm attaching a test program (requires gtk >=2....## Submitted by Nathaniel J. Smith `@njs`
Assigned to **Eric Anholt `@anholt`**
**[Link to original bug (#13116)](https://bugs.freedesktop.org/show_bug.cgi?id=13116)**
## Description
I'm attaching a test program (requires gtk >=2.12, cairo, and python bindings to both). The test program creates two toplevel windows, sets one to manual redirection, and then just repeatedly draws a gradient image into the
redirected window, and composites the image of the redirected window into
the other 'display' window, using Render (via cairo -- I've verified that the
expected Render operations are occurring with xtrace). The display window also has a little white dot placed at where the upper-left corner of the composited image *should* land, given the transform matrix in use.
To test, run Xephyr, start a window manager, then start the test program and move the two windows around on the screen. Moving the display window has no effect. Moving the redirected window against the root window causes its image inside the display window to veer wildly -- each time the real window goes to the left, its image goes to the right, and so on. The only time it appears at the correct location is if the redirected window is placed at position (0, 0) against the root. (I'll also attach a little ogg video to show this.)
The amount of the offset seems to vary inversely with the scale factor applied. With a scale factor of 1, the display is correct. As the scale factor goes to 1, it looks like the transformed image moves by 1 pixel for every 1 pixel the redirected window moves by. For intermediate scale factors, the transformed image moves by intermediate amounts as the redirected window is moved. See attached screenshot.
I am deeply suspicious of the handling of redirected windows' ->screen_x/->screen_y offsets. It is like one piece of code is expected to leave the offsets in, and then they are corrected for later, but the first piece of code is multiplying them by the scale factor and the latter code is assuming a scale factor of 1 when it applies its correction.... or something.
This is with X.org 1.4.0 (Debian sid, xorg-server 2:1.4-3), on x86-64.
Version: 7.3 (2007.09)Emma Anholtemma@anholt.netEmma Anholtemma@anholt.net