xorg issueshttps://gitlab.freedesktop.org/groups/xorg/-/issues2022-05-08T16:18:13Zhttps://gitlab.freedesktop.org/xorg/lib/libxaw/-/issues/5_XawTextSelectionList should use XInternAtoms2022-05-08T16:18:13ZAlan Coopersmith_XawTextSelectionList should use XInternAtomshttps://gitlab.freedesktop.org/xorg/lib/libxaw/-/blob/master/src/Text.c#L3104-3125
The _XawTextSelectionList() function loops over a list of atoms, calling XInternAtom() on each one at a time, causing an X server round trip for each one...https://gitlab.freedesktop.org/xorg/lib/libxaw/-/blob/master/src/Text.c#L3104-3125
The _XawTextSelectionList() function loops over a list of atoms, calling XInternAtom() on each one at a time, causing an X server round trip for each one. It should call XInternAtoms() instead to batch the whole list into a single X server round trip.https://gitlab.freedesktop.org/xorg/xserver/-/issues/689Swapped dispatch code in MIT-SHM is broken under Xinerama2019-05-09T19:28:41ZAdam Jacksonajax@nwnk.netSwapped dispatch code in MIT-SHM is broken under XineramaSee [this thread on xorg-devel](https://lists.x.org/archives/xorg-devel/2019-May/058164.html) for details and a proposed fix.See [this thread on xorg-devel](https://lists.x.org/archives/xorg-devel/2019-May/058164.html) for details and a proposed fix.https://gitlab.freedesktop.org/xorg/xserver/-/issues/667xfree86 use byte access for dword write which will lead to corruption if some...2019-03-20T18:28:48Zgeniusshockxfree86 use byte access for dword write which will lead to corruption if some MMIO can't support byte accessxserver use an x86 emulator instead of calling VBIOS directly. But I find something wrong when it runs on an test chip. After traced xserver code I have found the root cause. Our VBIOS will access some 32-bit registers through memory map...xserver use an x86 emulator instead of calling VBIOS directly. But I find something wrong when it runs on an test chip. After traced xserver code I have found the root cause. Our VBIOS will access some 32-bit registers through memory mapped IO, but x86emu will translate this into 4 byte-write operations, which would cause an exception.
```
static void
write_l(xf86Int10InfoPtr pInt, int addr, CARD32 val)
{
#if X_BYTE_ORDER == X_LITTLE_ENDIAN
if (OFF(addr + 3) > 2) {
V_ADDR_WL(addr, val);
}
#endif
V_ADDR_WB(addr, val);
V_ADDR_WB(addr + 1, val >> 8);
V_ADDR_WB(addr + 2, val >> 16);
V_ADDR_WB(addr + 3, val >> 24);
}
```
The function write_w also has similar problem.
The #if is also very strange and it seems that the author just wants to write a dword directly for little endian case, but misses return command, so the dword will be written twice.https://gitlab.freedesktop.org/xorg/xserver/-/issues/533compiler.h header incorrectly equates ia64 with x86/amd642019-05-09T20:14:50ZBugzilla Migration Usercompiler.h header incorrectly equates ia64 with x86/amd64## Submitted by Jason Duerstock
Assigned to **Xorg Project Team**
**[Link to original bug (#105192)](https://bugs.freedesktop.org/show_bug.cgi?id=105192)**
## Description
In hw/xfree86/common/compiler.h, this line is incorrect:
#...## Submitted by Jason Duerstock
Assigned to **Xorg Project Team**
**[Link to original bug (#105192)](https://bugs.freedesktop.org/show_bug.cgi?id=105192)**
## Description
In hw/xfree86/common/compiler.h, this line is incorrect:
#elif defined(__amd64__) || defined(__i386__) || defined(__ia64__)
ia64 does not offer in[bwl] or out[bwl] instructions.
https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/common/compiler.h#n289
This results in several Debian/ia64 packages FTBFS:
https://buildd.debian.org/status/fetch.php?pkg=xserver-xorg-video-ast&arch=ia64&ver=1.1.5-1.1&stamp=1519222324&raw=0https://gitlab.freedesktop.org/xorg/xserver/-/issues/135Eliminate MAXFORMATS2019-05-09T16:35:37ZBugzilla Migration UserEliminate MAXFORMATS## Submitted by Stuart Anderson `@anderson`
Assigned to **Xorg Project Team**
**[Link to original bug (#3769)](https://bugs.freedesktop.org/show_bug.cgi?id=3769)**
## Description
The change for bug #2791 to add support for 12 & 30...## Submitted by Stuart Anderson `@anderson`
Assigned to **Xorg Project Team**
**[Link to original bug (#3769)](https://bugs.freedesktop.org/show_bug.cgi?id=3769)**
## Description
The change for bug #2791 to add support for 12 & 30 bit depths causes more
than MAXFORMATS depths to be created when RENDER is enabled. That overflows
GCperDepth in the Screen structure and causes a crash.
screen #0:
dimensions: 1024x768 pixels (260x195 millimeters)
resolution: 100x100 dots per inch
depths (9): 1, 4, 8, 12, 16, 24, 30, 32, 8
an additional questions, is why is the screen's depth listed twice?
Is it safe to just increase MAXFORMATS? or is there a more appropriate
solution?
Version: 6.9.0