Releasing the next maintenance releases of X Server 1.19 and older
Hi, Now that the new year has started, I can finally send out this posting. I will like to see a new maintenance release of X Server 1.19 and even older versions over the next two months. Over the past month, I have finally poured in significant time resources to figure out why Xfce desktop manager crashes with SiS 6326 graphics chip (released in 1998) when EXA is utilized. It turns out EXA is missing one line of code to handle 24-bit color mode inside exaGetPixmapFirstPixel (/exa/exa_unaccel.c). I did post a patch to fix this issue back in December 2018 to this mailing list. [1] I compiled X Server 1.19.6 with this fix, and I can confirm that the crash bug is indeed fixed. I can now run SiS 6326 at 24-bit color mode with Xfce. SiS DDX does still suffer from some rendering bugs (artifacts), but this appears to be buggy DDX code related. Adam Jackson, who has been the release manager of several past X Servers, has indicated that he is not interested in getting involved in releasing older versions of X Servers. [2] Since I specialize in fixing underserved graphics hardware, can I be the release manager of X Server 1.19.7? I have never done this and other more experienced people may have to hold my hands, but I will really will like to see the EXA 24-bit color bug fixed. Note that this bug has existed since X Server 1.7. How far back can I backport the fix and release maintenance version for even older X Servers (i.e., X Server 1.18 and older up to 1.7)? Regards, Kevin Brace Brace Computer Laboratory blog https://bracecomputerlab.com [1] https://lists.x.org/archives/xorg-devel/2018-December/057794.html [2] https://lists.x.org/archives/xorg-devel/2018-December/057813.html ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: xkb_layout documentation
On Wed, Jan 02, 2019 at 01:16:22PM +0100, Jens Harms wrote: > imho both strings "XkbLayout" and "xkb_layout" are ?currently? used. i hope > i'm using the right repo. both are currently used, but why we switched from XkbLayout to xkb_layout evades my memory. Possibly because at some point udev was setting bits here, but I'm not sure. > Now i try to checkout what the crazy gnome desktop is doing to my keyboard > settings, maybe i switch back to fvwm2... I suggest to tone it down because there's a high chance you will want help from the people who wrote the code. Throwing words like crazy and annoying around (doubly so when you're not 100% sure of what the code does) will make those less likely to help you. > FYI: > https://gitlab.freedesktop.org/xorg/driver/xf86-input-keyboard/blob/master/src/kbd.c > : Line 78 > > #endif /* NetBSD */ > "XkbRules", "base", > "XkbModel", "pc105", > "XkbLayout", "us", > NULL > }; the xorg keyboard driver hasn't been used on linux in a decade or so, you can safely ignore it. > https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/blob/master/src/xf86libinput.c > : Line 1040 > rmlvo.layout = xf86SetStrOption(pInfo->options, > "xkb_layout", > defaults.layout); this loads the defaults from the xserver, overriding it with any XkbLayout or xkb_layout option found in the config snippets. GNOME hasn't used the xorg.conf settings in a long long time now, it will apply the user-configured layout on login. that layout is stored in gsettings and will overwrite anything you set in the xorg.conf. Cheers, Peter > Am Mi., 2. Jan. 2019 um 00:36 Uhr schrieb Peter Hutterer < > peter.hutte...@who-t.net>: > > > On Wed, Dec 26, 2018 at 11:41:11AM +0100, Jens Harms wrote: > > > Hi All, > > > please point me to the current "InputClass" documentatation (if > > available). > > > > should be in man xorg.conf, not sure there's more than that short of > > google. > > > > > I tried to configure my keyboard. because setting the option "XkbLayout" > > > did not work i was looking at the sources. i did not find any up-to-date > > > documentation but found anoying uses of XkbLayout and xkb_layout in > > > libinput. evdev is using only "xkb_layout". > > > > the X server's option parsing code is case-insensitive and ignores > > underscores. So XkbLayout and xkb_layout are the same option name, which is > > why the libinput driver only parses the latter. Not sure where you found > > XkbLayout. git grep shows nothing. > > > > Anyway. The drivers only do on-plug xkb option setting, if you have a > > desktop environment like GNOME it most likely overwrites the xorg.conf > > settings on login. > > > > Cheers, > >Peter > > > > > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: XChangeProperty accesses 32 bit values as 64 bit
> Date: Wed, 2 Jan 2019 16:31:39 +0100 > From: Hanno Böck > > Hi, > > Trying to debug a crash (in gajim) I discovered that it was due to a > stack buffer overread in gtk+/libX11. > > Digging down I am not entirely sure how to interpret it and whether > it's libX11's or GTK's fault. Here's what's going on: > > Gtk+ calls XChangeProperty where the second last parameters are a > pointer to a pid, see e.g. [1]. The "format" parameter is "32", which > is the bit size. > > Now in libX11 it ends up crashing in the function _XData32, because it > tries to access the variable as a long, which is 64 bit. > > Now this is kinda documented [2], where it says: > "If the specified format is 32, the property data must be a long array." > > However that is - to put it mildly - unexpected and confusing. If I > have a function that lets me tell I want to process a 32 bit value then > learning that I have to pass that 32 bit value as a 64 bit value is > surely the last thing I expected. Yes. the X11 API dates from the time when 32-bit computing was relatively new and short meant 16-bit and long meant 32-bit. And then 64-bit computers came around some years later... > Given this API this probably needs to be fixed in gtk by using long > instead of pid_t for the pid, but I strongly recommend rethinking that > design in libX11 and make it accept 32 bit values. POSIX defines pid_t as "integer type" of "an appropriate length". There is no guarantee that it is 32 bits, so GTK needs to be fixed anyway. Changing the libX11 API isn't possible at this point as software that uses the interface correctly would break on a 64-bit system. There is of course libxcb which (as far as I can tell) doesn't have this weirdness. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xserver] FIX:xf86nameCompare fix corner case compare with NULL
FIX:There is an bug in xf86nameCompare, if you compare
a zero string with a non-zero string the result is inverted.
s1=zero string, s2 = non-zero string
this should return a value less than zero but the code returns 1.
-if (!s1 || *s1 == 0) {
-if (!s2 || *s2 == 0)
-return 0;
-else
-return 1; // s1 == ZERO, s2 == NOT ZERO
-} else if (!s2 || *s2 == 0) {
-return -1;
The patch also rewrites and shrinkes the code to improve readability.
Signed-off-by: Jens Harms
---
hw/xfree86/parser/scan.c | 56 ++--
1 file changed, 25 insertions(+), 31 deletions(-)
diff --git a/hw/xfree86/parser/scan.c b/hw/xfree86/parser/scan.c
index 1eb35ed73..7d63f0983 100644
--- a/hw/xfree86/parser/scan.c
+++ b/hw/xfree86/parser/scan.c
@@ -1006,45 +1006,39 @@ xf86getStringToken(const xf86ConfigSymTabRec * tab)
return StringToToken(xf86_lex_val.str, tab);
}
+
+/* skips space, underscore and tab, increments pointer.
+ returns: lowercase character code
+*/
+inline static char skipws(const char **s)
+{
+if( *s == NULL ) return 0;
+while (**s == '_' || **s == ' ' || **s == '\t')
+(*s)++;
+char ch = tolower(**s) ;
+(*s)++;
+return ch;
+}
+
/*
- * Compare two names. The characters '_', ' ', and '\t' are ignored
+ * Compare two names. The characters '_', ' ', '\t',
+ * and upper/lower case are ignored
* in the comparison.
*/
int
xf86nameCompare(const char *s1, const char *s2)
{
-char c1, c2;
-
-if (!s1 || *s1 == 0) {
-if (!s2 || *s2 == 0)
-return 0;
-else
-return 1;
-} else if (!s2 || *s2 == 0) {
-return -1;
-}
-
-while (*s1 == '_' || *s1 == ' ' || *s1 == '\t')
-s1++;
-while (*s2 == '_' || *s2 == ' ' || *s2 == '\t')
-s2++;
-c1 = (isupper(*s1) ? tolower(*s1) : *s1);
-c2 = (isupper(*s2) ? tolower(*s2) : *s2);
-while (c1 == c2) {
-if (c1 == '\0')
-return 0;
-s1++;
-s2++;
-while (*s1 == '_' || *s1 == ' ' || *s1 == '\t')
-s1++;
-while (*s2 == '_' || *s2 == ' ' || *s2 == '\t')
-s2++;
-c1 = (isupper(*s1) ? tolower(*s1) : *s1);
-c2 = (isupper(*s2) ? tolower(*s2) : *s2);
-}
-return c1 - c2;
+register char c1, c2, ret;
+
+do {
+c1 = skipws();
+c2 = skipws();
+ret = c1 - c2;
+} while( !ret && c1 );
+return ret;
}
+
char *
xf86addComment(char *cur, const char *add)
{
--
2.17.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
XChangeProperty accesses 32 bit values as 64 bit
Hi, Trying to debug a crash (in gajim) I discovered that it was due to a stack buffer overread in gtk+/libX11. Digging down I am not entirely sure how to interpret it and whether it's libX11's or GTK's fault. Here's what's going on: Gtk+ calls XChangeProperty where the second last parameters are a pointer to a pid, see e.g. [1]. The "format" parameter is "32", which is the bit size. Now in libX11 it ends up crashing in the function _XData32, because it tries to access the variable as a long, which is 64 bit. Now this is kinda documented [2], where it says: "If the specified format is 32, the property data must be a long array." However that is - to put it mildly - unexpected and confusing. If I have a function that lets me tell I want to process a 32 bit value then learning that I have to pass that 32 bit value as a 64 bit value is surely the last thing I expected. Given this API this probably needs to be fixed in gtk by using long instead of pid_t for the pid, but I strongly recommend rethinking that design in libX11 and make it accept 32 bit values. [1] https://github.com/GNOME/gtk/blob/gtk-3-24/gdk/x11/gdkwindow-x11.c#L937 [2] https://tronche.com/gui/x/xlib/window-information/XChangeProperty.html -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] xfree86: Do not claim pci slots if fb slot is already claimed
The xf86PostProbe would terminate with fatal error if both fb and pci
slots were claimed at the same time, so there is no point in trying.
The opposite logic already exists in xf86ClaimFbSlot - fb slots will
not be claimed if any pci slot was claimed.
This fixes issue when (autoconfigured) fbdev and vesa drivers both claim
a device (e.g. /dev/fb0 provided by the vesafb kernel driver).
Signed-off-by: Michal Srb
---
hw/xfree86/common/xf86pciBus.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/hw/xfree86/common/xf86pciBus.c b/hw/xfree86/common/xf86pciBus.c
index 0718cdcb0..24396a63c 100644
--- a/hw/xfree86/common/xf86pciBus.c
+++ b/hw/xfree86/common/xf86pciBus.c
@@ -212,6 +212,9 @@ xf86ClaimPciSlot(struct pci_device *d, DriverPtr drvp,
EntityPtr p = NULL;
int num;
+if (fbSlotClaimed)
+return -1;
+
if (xf86CheckPciSlot(d)) {
num = xf86AllocateEntity();
p = xf86Entities[num];
--
2.16.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: xkb_layout documentation
imho both strings "XkbLayout" and "xkb_layout" are ?currently? used. i hope i'm using the right repo. Now i try to checkout what the crazy gnome desktop is doing to my keyboard settings, maybe i switch back to fvwm2... Cheers, Jens FYI: https://gitlab.freedesktop.org/xorg/driver/xf86-input-keyboard/blob/master/src/kbd.c : Line 78 #endif /* NetBSD */ "XkbRules", "base", "XkbModel", "pc105", "XkbLayout", "us", NULL }; https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/blob/master/src/xf86libinput.c : Line 1040 rmlvo.layout = xf86SetStrOption(pInfo->options, "xkb_layout", defaults.layout); Am Mi., 2. Jan. 2019 um 00:36 Uhr schrieb Peter Hutterer < peter.hutte...@who-t.net>: > On Wed, Dec 26, 2018 at 11:41:11AM +0100, Jens Harms wrote: > > Hi All, > > please point me to the current "InputClass" documentatation (if > available). > > should be in man xorg.conf, not sure there's more than that short of > google. > > > I tried to configure my keyboard. because setting the option "XkbLayout" > > did not work i was looking at the sources. i did not find any up-to-date > > documentation but found anoying uses of XkbLayout and xkb_layout in > > libinput. evdev is using only "xkb_layout". > > the X server's option parsing code is case-insensitive and ignores > underscores. So XkbLayout and xkb_layout are the same option name, which is > why the libinput driver only parses the latter. Not sure where you found > XkbLayout. git grep shows nothing. > > Anyway. The drivers only do on-plug xkb option setting, if you have a > desktop environment like GNOME it most likely overwrites the xorg.conf > settings on login. > > Cheers, >Peter > > ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
