xorgproto issueshttps://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues2023-12-18T09:10:09Zhttps://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/47Present: undocumented behavior when divisor == 02023-12-18T09:10:09ZyshuiPresent: undocumented behavior when divisor == 0Relevant code:
https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/present/present.c?ref_type=heads#L169
https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/present/present.c?ref_type=heads#L275
Apparently `divisor == 0` is...Relevant code:
https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/present/present.c?ref_type=heads#L169
https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/present/present.c?ref_type=heads#L275
Apparently `divisor == 0` is used to mean async presentation, which is not documented.https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/44Redefinition of CreateWindow on Windows platform2023-02-28T19:36:20ZPeter WilliamsRedefinition of CreateWindow on Windows platformIn the process of [updating the conda-forge build of libX11 to version 1.8.4][1], I think we have discovered a bug in the X.org proto packages that is at least 18 years old (!).
[1]: https://github.com/conda-forge/xorg-libx11-feedstock/...In the process of [updating the conda-forge build of libX11 to version 1.8.4][1], I think we have discovered a bug in the X.org proto packages that is at least 18 years old (!).
[1]: https://github.com/conda-forge/xorg-libx11-feedstock/pull/30
We got a compile error in the Windows build of this form:
```
../../include/X11/Xlibint.h:542:9: error: 'xCreateWindowAReq' undeclared (first use in this function)
```
What seems to be going on is that in 1.8.4, `Xlibint.h` now includes `Xthreads.h`, which on Windows includes the Windows OS headers via `Xwindows.h`. The Windows OS API has a function called `CreateWindow` that appears to actually be a `#define` mapping to the true symbol `CreateWindowA`.
The `Xwindows.h` header seems to attempt to fix this, but it does so incorrectly. Here's the relevant line:
https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/blame/master/include/X11/Xwindows.h#L89
This is `#undef CreateWindowA`, but as far as I can convince myself, it *should* be `#undef CreateWindow`. Patching our libX11 build to do this undef does indeed fix the builds. It seems that the only uses of the `CreateWindow` symbol in libX11 have been places where `windows.h` never got included, so this issue was hidden for a long time. The change to `Xlibint.h` in 1.8.4 mentioned above has exposed the problem, but the actual problem lies in `Xwindows.h`.
I can file a merge request to fix this issue, but I just wanted to raise an issue first in case there is any discussion to be had about the diagnosis here.https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/43Present: Add the PresentWindowDestroyed flag2023-02-15T14:28:41ZOlivier FourdanPresent: Add the PresentWindowDestroyed flagSee https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1057
The `PresentWindowDestroyed` flag should be defined in xorgproto.See https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1057
The `PresentWindowDestroyed` flag should be defined in xorgproto.https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/48Documentation of "Connection Initiation" does not match implementation2024-03-24T18:05:02ZCev IngDocumentation of "Connection Initiation" does not match implementationThe following fields seem to be missing in the documentation
- authorization-protocol-name-length
- authorization-protocol-data-length
See Wireshark ![authorization-protocol-name-length](/uploads/c648910dfd0f0766fc659f3b7e2c018c/au...The following fields seem to be missing in the documentation
- authorization-protocol-name-length
- authorization-protocol-data-length
See Wireshark ![authorization-protocol-name-length](/uploads/c648910dfd0f0766fc659f3b7e2c018c/authorization-protocol-name-length.png).https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/41Missing named keysyms for single guillemets2023-05-18T15:55:19Zjmcwilliams403Missing named keysyms for single guillemetsSingle guillemets are already used in many keyboard layouts and have existed in the Windows 1252 encoding for ISO-8859-1 compliant websites for seemingly as long as the other named quotation mark keysyms have. I find it somewhat baffling...Single guillemets are already used in many keyboard layouts and have existed in the Windows 1252 encoding for ISO-8859-1 compliant websites for seemingly as long as the other named quotation mark keysyms have. I find it somewhat baffling that most of the other essential quotation characters in the General Punctuation block of Unicode have named keysyms but not left/right single guillemets as logical extensions of the double ones found in Latin-1.<br>
I propose two possible macro names: `XK_singleguillemet{left|right}` or `XK_{left|right}anglequote`.https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/40presentproto.txt does not define or explain 'msc' or 'ust'2022-08-27T21:28:23ZAlan Coopersmithpresentproto.txt does not define or explain 'msc' or 'ust'The [Present Protocol spec](presentproto.txt) uses the terms 'msc' and 'ust' without ever defining them or explaining what they are.
https://lwn.net/Articles/569265/ says that the msc is the "media stream counter" and "The MSC is a mono...The [Present Protocol spec](presentproto.txt) uses the terms 'msc' and 'ust' without ever defining them or explaining what they are.
https://lwn.net/Articles/569265/ says that the msc is the "media stream counter" and "The MSC is a monotonically increasing counter of the number of frames since power on".
ust appears to be some form of the system time.https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/39randrproto.txt missing protocol encoding details for RandR 1.6 features2022-07-24T21:29:20ZRobert Russellrandrproto.txt missing protocol encoding details for RandR 1.6 features`RRCreateLease`, `RRFreeLease`, and `RRLeaseNotify` are all missing from Appendix A.`RRCreateLease`, `RRFreeLease`, and `RRLeaseNotify` are all missing from Appendix A.https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/36print errors / warnings only once, to avoid filling the disk and causing enti...2021-08-30T15:12:25Z積丹尼 Dan Jacobsonprint errors / warnings only once, to avoid filling the disk and causing entire system failureRegarding the warnings/errors in e.g., #35:
Please only emit them only once.
Else they will fill up the disk that /var/log/syslog is on,
and cause the whole computer to fail.Regarding the warnings/errors in e.g., #35:
Please only emit them only once.
Else they will fill up the disk that /var/log/syslog is on,
and cause the whole computer to fail.https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/33MIT-SHM: Support passing an explicit offset and size for a memory mapping2021-06-27T09:09:51ZDemi Marie Obenourdemiobenour@gmail.comMIT-SHM: Support passing an explicit offset and size for a memory mappingThis is needed to use MIT-SHM with Xen grant tables; see https://github.com/QubesOS/qubes-gui-daemon/pull/65#issuecomment-868961425 for details. I am willing to create a PR for both the extension specification and for implementations in...This is needed to use MIT-SHM with Xen grant tables; see https://github.com/QubesOS/qubes-gui-daemon/pull/65#issuecomment-868961425 for details. I am willing to create a PR for both the extension specification and for implementations in XCB and the server.https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/32XFixes: terminate the X server when a specific connection ends2021-07-28T02:42:50ZDemi Marie Obenourdemiobenour@gmail.comXFixes: terminate the X server when a specific connection endsCurrently, if a screen locker exits, the screen will be unlocked. This is inherently fragile and caused [Qubes Security Bulletin 068].
A much better solution would be for the X server to exit if the screen locker does. This can be acc...Currently, if a screen locker exits, the screen will be unlocked. This is inherently fragile and caused [Qubes Security Bulletin 068].
A much better solution would be for the X server to exit if the screen locker does. This can be accomplished by way of a new extension. When the client requests the extension, the server marks the connection as critical. If a critical connection is closed, the X server exits.
[Qubes Security Bulletin 068]: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-068-2021.txthttps://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/27MIT-SHM is underdocumented2021-06-26T07:46:49ZAdam Jacksonajax@nwnk.netMIT-SHM is underdocumentedEven the docs we do have read like they were reverse-engineered from the code, and they don't cover any of the file-descriptor-passing variants in newer protocol revisions.Even the docs we do have read like they were reverse-engineered from the code, and they don't cover any of the file-descriptor-passing variants in newer protocol revisions.https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/26Xv is underdocumented2020-03-24T13:49:01ZAdam Jacksonajax@nwnk.netXv is underdocumentedThe protocol text (draft! still!) stops at XvGetPortAttribute. The five requests past that look like they were added around XFree86 4.0 or so, but they've never been properly documented.The protocol text (draft! still!) stops at XvGetPortAttribute. The five requests past that look like they were added around XFree86 4.0 or so, but they've never been properly documented.https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/25Clean up the protocol documentation2020-05-06T14:00:42ZAdam Jacksonajax@nwnk.netClean up the protocol documentationThere's kind of two overlapping issues here. One is that the specifications are not in consistent formats, some are text and some are xml. Two, made worse by the first point, is that the specs are in principle normative, but there's no e...There's kind of two overlapping issues here. One is that the specifications are not in consistent formats, some are text and some are xml. Two, made worse by the first point, is that the specs are in principle normative, but there's no easy way to extract data types or enums from them.
I tend to lean toward markdown as the most pleasant output format, partly because it should then be easy to integrate into the gitlab wiki, but I'd take any reasonable structured format. It would probably be a good idea at this point to generate the final protocol documentation from a template and the XCB definitions (after we've re-double-checked that they concur), so that future additions are harder to leave undocumented.https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/22Improve common Remote Control Units support2019-10-28T15:48:55ZAndreyImprove common Remote Control Units supportHello,
it is really frustrating we still have poor support for common consumer electronic remotes.
It makes it impossible to use them without re-mapping dozen of their well known buttons to meaningless key names.
Most of these keys ...Hello,
it is really frustrating we still have poor support for common consumer electronic remotes.
It makes it impossible to use them without re-mapping dozen of their well known buttons to meaningless key names.
Most of these keys seem already grouped in evdev Input event codes:
https://gitlab.freedesktop.org/libinput/libinput/blob/master/include/linux/linux/input-event-codes.h#L422
Here is a few of them most common/welcomed here in xproto. I tried to group them by function:
```
KEY_EPG
KEY_PROGRAM
KEY_INFO
KEY_PROPS
KEY_SETUP
KEY_CONFIG
KEY_TITLE
KEY_TEXT
KEY_LANGUAGE
KEY_CHANNEL
KEY_ZOOM
KEY_SCREEN
```https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/17Add support for KEY_ROTATE_LOCK_TOGGLE2019-05-03T19:32:45ZBugzilla Migration UserAdd support for KEY_ROTATE_LOCK_TOGGLE## Submitted by Stefan Brüns
Assigned to **Xorg Project Team**
**[Link to original bug (#103998)](https://bugs.freedesktop.org/show_bug.cgi?id=103998)**
## Description
Corresponding report for libxkbcommon:
https://github.com/xkbc...## Submitted by Stefan Brüns
Assigned to **Xorg Project Team**
**[Link to original bug (#103998)](https://bugs.freedesktop.org/show_bug.cgi?id=103998)**
## Description
Corresponding report for libxkbcommon:
https://github.com/xkbcommon/libxkbcommon/issues/55
Kernel:
https://patchwork.kernel.org/patch/10052039/https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/6Xwinsock.h does not compile on 64-bit Windows.2019-05-03T19:08:07ZBugzilla Migration UserXwinsock.h does not compile on 64-bit Windows.## Submitted by Peter Williams
Assigned to **Xorg Project Team**
**[Link to original bug (#99461)](https://bugs.freedesktop.org/show_bug.cgi?id=99461)**
## Description
Created attachment 129047
Attempt to fix INT64 name clash.
If...## Submitted by Peter Williams
Assigned to **Xorg Project Team**
**[Link to original bug (#99461)](https://bugs.freedesktop.org/show_bug.cgi?id=99461)**
## Description
Created attachment 129047
Attempt to fix INT64 name clash.
If you try to compile a C file using Xwinsock.h (e.g., libXdmcp/Fill.c), you get a compilation failure since the Windows-related name mangling seems not to have been updated for the existence of 64-bit Windows: there's a name clash on INT64 between X Windows and Microsoft Windows. I'm hopeful that the attached patch fixes the problem, although I haven't yet finished a new build.
~~**Patch 129047**~~, "Attempt to fix INT64 name clash.":
[windows-int64.patch](/uploads/53e654dbbcf4c8ba57d0a7006cbe8302/windows-int64.patch)
Version: githttps://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/5Fix mistakes in file "randrproto.txt"2019-05-03T19:28:39ZBugzilla Migration UserFix mistakes in file "randrproto.txt"## Submitted by AHX..@..il.com
Assigned to **Xorg Project Team**
**[Link to original bug (#98803)](https://bugs.freedesktop.org/show_bug.cgi?id=98803)**
## Description
Patch for file
https://cgit.freedesktop.org/xorg/proto/randrp...## Submitted by AHX..@..il.com
Assigned to **Xorg Project Team**
**[Link to original bug (#98803)](https://bugs.freedesktop.org/show_bug.cgi?id=98803)**
## Description
Patch for file
https://cgit.freedesktop.org/xorg/proto/randrproto/plain/randrproto.txt
```
diff --git a/randrproto.txt b/randrproto.txt
index c06bc90..29ffd24 100644
--- a/randrproto.txt
+++ b/randrproto.txt
@@ -2359,7 +2359,7 @@ A.1 Common Types
A.1.1 Common Types added in version 1.5 of the protocol
┌───
- MONITORINFO (16 + 4*n)
+ MONITORINFO (24 + 4*n)
4 ATOM name
1 BOOL primary
1 BOOL automatic
@@ -2969,7 +2969,7 @@ A.2.3 Protocol Requests added with version 1.4
2 CARD16 sequence number
4 1+c+o+(a*2)+(n+p)/4 reply length
4 TIMESTAMP timestamp
- 4 CARD32 capabilities
+ 4 PROVIDER_CAPS capabilities
2 c number of crtcs
2 o number of outputs
2 a number of associated providers
@@ -2978,7 +2978,7 @@ A.2.3 Protocol Requests added with version 1.4
4c LISTofCRTC crtcs
4o LISTofOUTPUT outputs
4a LISTofPROVIDER associated providers
- 4a CARD32 associated provider capability
+ 4a LISTofPROVIDER_CAPS associated provider capability
n STRING8 name
p unused, p=pad(n)
└───
@@ -3054,11 +3054,11 @@ A.2.3 Protocol Requests added with version 1.4
4 ATOM property
4 ATOM type
1 CARD8 format
- 1 mode
+ 2 mode
0 Replace
1 Prepend
2 Append
- 2 unused
+ 1 unused
4 CARD32 length of data in format units
(= n for format = 8)
(= n/2 for format = 16)
```
Version: githttps://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/4XF86keysym.h has no copyright header2019-05-03T18:31:29ZBugzilla Migration UserXF86keysym.h has no copyright header## Submitted by Liang Guo
Assigned to **Xorg Project Team**
**[Link to original bug (#96474)](https://bugs.freedesktop.org/show_bug.cgi?id=96474)**
## Description
According to git
https://cgit.freedesktop.org/xorg/proto/x11proto/...## Submitted by Liang Guo
Assigned to **Xorg Project Team**
**[Link to original bug (#96474)](https://bugs.freedesktop.org/show_bug.cgi?id=96474)**
## Description
According to git
https://cgit.freedesktop.org/xorg/proto/x11proto/tree/XF86keysym.h
XF86keysym.h has no copright header, please add it.
Thanks,
Version: githttps://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/3xf86vmproto.h xXF86VidModeModeInfo incorrect padding2019-05-03T19:28:17ZBugzilla Migration Userxf86vmproto.h xXF86VidModeModeInfo incorrect padding## Submitted by Kevin Ryde
Assigned to **Jamey Sharp `@jamey`**
**[Link to original bug (#45202)](https://bugs.freedesktop.org/show_bug.cgi?id=45202)**
## Description
(Is component "Other" right for extension protocol stuff, or is...## Submitted by Kevin Ryde
Assigned to **Jamey Sharp `@jamey`**
**[Link to original bug (#45202)](https://bugs.freedesktop.org/show_bug.cgi?id=45202)**
## Description
(Is component "Other" right for extension protocol stuff, or is it "Protocol/Core"?)
Nosing around xf86vmproto.h I saw the xXF86VidModeModeInfo struct has its hskew field as
CARD32 hskew B16;
Is it supposed to be B32? The B macros are empty except on Cray are they? Perhaps it doesn't make a difference, or perhaps it lets the compiler bit field packing leak out ... I couldn't tell.
I wondered too if the "pad1" field there is supposed to be 32-bits. gcc reports unexpressed alignment padding after "pad1" before "flags".
gcc -Wpadded -x c -fsyntax-only /usr/include/X11/extensions/xf86vmproto.h
=>
/usr/include/X11/extensions/xf86vmproto.h:169:12: warning: padding struct to align 'flags' [-Wpadded]
Was hskew going to be 16 then became 32 and pad1 not updated, or something?https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/issues/37XDMCP don't support multiple sessions from a single client address at the sam...2022-02-23T21:43:52ZBugzilla Migration UserXDMCP don't support multiple sessions from a single client address at the same time## Submitted by Vincent Zhang
Assigned to **Keith Packard `@keithp`**
**[Link to original bug (#361)](https://bugs.freedesktop.org/show_bug.cgi?id=361)**
## Description
XDMCP depends on client address to distigush each client for
...## Submitted by Vincent Zhang
Assigned to **Keith Packard `@keithp`**
**[Link to original bug (#361)](https://bugs.freedesktop.org/show_bug.cgi?id=361)**
## Description
XDMCP depends on client address to distigush each client for
Query,BroadcastQuery and IndirectQuery packet,when multiple sessions from a
single client address act at the same time,display manager(usually xdm or
dtlogin) will confused and cann't act correctly for each client.XDMCP should add
more info to such packet to distigush clients from a single client address,such
as Xserver Pid or display number.
Version: X11R6.6