Re: [PATCH xserver] man: Mention that InputClass overrides InputDevice.
On Tue, Aug 21, 2018 at 10:02:14AM +0200, Michal Srb wrote: > To prevent confusion, since user may consider InputDevice as "stronger > selector" and expect that it will take priority over InputClass. I don't think this is correct, because the two are completely different. InputClass will pick up any udev-added device it matches on. InputDevice will just apply to that one device, with the side-effect that if you don't exclude that explicit device from the InputClass section, you'll get a duplicate device. This is the case in the bug you linked: [11.068] (II) XINPUT: Adding extended input device "Touchpad" (type: TOUCHPAD, id 6) [11.372] (II) XINPUT: Adding extended input device "SynPS/2 Synaptics TouchPad" (type: TOUCHPAD, id 14) xinput list should show both devices and general behaviour is going to be odd because all events are now sent from both devices simultaneously. So each click is a double-click, etc. This all works with evdev because it has duplicate detection and refuses to add the InputClass device (which always comes after the InputDevice due to how the server works). synaptics doesn't have that because historically it didn't need to. the libinput driver doesn't have that duplicate detection either. So nak to this patch, we'll need some more detail explaining this in the man page. As the most simple general rule though: don't mix InputDevice and InputClass. Cheers, Peter > --- > Downstream reference: > https://bugzilla.opensuse.org/show_bug.cgi?id=1105311 > > hw/xfree86/man/xorg.conf.man | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/hw/xfree86/man/xorg.conf.man b/hw/xfree86/man/xorg.conf.man > index 958926243..c921a1487 100644 > --- a/hw/xfree86/man/xorg.conf.man > +++ b/hw/xfree86/man/xorg.conf.man > @@ -892,6 +892,10 @@ sections recognise some driver\-independent > which are described here. > See the individual input driver manual pages for a description of the > device\-specific options. > +.B InputClass > +sections which match this device will override the options specified in > +.B InputDevice > +section. > .TP 7 > .BI "Option \*qAutoServerLayout\*q \*q" boolean \*q > Always add the device to the ServerLayout section used by this instance of > @@ -1022,7 +1026,11 @@ class of input devices as they are automatically > added. An input device can > match more than one > .B InputClass > section. Each class can override settings from a previous class, so it is > -best to arrange the sections with the most generic matches first. > +best to arrange the sections with the most generic matches first. Options in > +.B InputClass > +sections override options from the device's backend, including those set in > +.B InputDevice > +section. > .PP > .B InputClass > sections have the following format: > -- > 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: [Mesa-dev] XDC 2018: Call for Papers
Hi all, We received an overwhelming response for this CFP - 35+ proposals (and still some latecomers trickling in), for only 18 slots. What we didn't much get (and the CFP failed to make it clear that we're looking for this) is proposals for the workshop/discussion track in the 2nd room. In the past we scheduled that ad-hoc at the conference, but this year it would make sense to organize this. Especially since we expect a lot of the talks we had to reject to end up in hallway discussions. Formal workshop submissions also help us in scheduling the main track - anything that's expected to generate a lot of discussions will be put early. Right now we have 1 proposal for the workshop track. We'd like to have more. For details please look at "Workshop Track" at https://www.x.org/wiki/Events/PapersCommittee/ If you have a topic, please send your proposal to bo...@foundation.lists.org. Thanks, Daniel On Mon, Apr 2, 2018 at 12:47 PM, Samuel Iglesias Gonsálvez wrote: > Hello, > > I have the pleasure to announce that the X.org Developer Conference 2018 > will be held in A Coruña, Spain from September 26th to September 28th. > The venue is located at the Computer Science faculty of the University > of Coruña. > > This year, we have created a new website for the event: > > https://xdc2018.x.org > > And a Twitter account for announcing updates, please follow us! > > https://twitter.com/xdc2018 > > However, we are going to keep updating the good old wiki too: > > https://www.x.org/wiki/Events/XDC2018 > > As usual, we are open to talks across the layers of the graphics stack, > from the kernel to desktop environments / graphical applications and > about how to make things better for the developers who build them. Other > topics such as Virtual Reality are also welcome. If you're not sure if > something might fit, mail us or add it to the ideas list found in the > program page at: > > https://www.x.org/wiki/Events/XDC2018/Program/ > > The Call for Papers information is here: https://xdc2018.x.org/#cfp. > Remember, the deadline for submissions is Wednesday 25th July 2018 17:00 > UTC. Don't forget to send your proposals to bo...@foundation.x.org! > > The conference is free of charge and open to the general public. If you > plan on coming, please add yourself to the attendees list: > > https://www.x.org/wiki/Events/XDC2018/Attendees/ > > We'll use this list of attendees to make badges and plan for the > catering, so if you are attending please add your name as early as > possible. > > I am looking forward to seeing you there. If you have any > inquiries/questions, please send an email to xdc2...@gpul.org, adding on > CC the X.org board (bo...@foundation.x.org). > > Best regards, > > Sam > ___ > mesa-dev mailing list > mesa-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ 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] glamor_egl: request GL2.1 when requesting Desktop GL context
Some devices cannot support OpenGL 2.1, which is the minimum desktop GL
version required by glamor. However, they may support OpenGL ES 2.0,
which is the GLES version required by glamor. Usually in this situation
the desktop GL version supported is 2.0 or 1.4.
Currently, as no requirements are passed when creating desktop GL
context, a OpenGL 1.4/2.0 context will be created, and glamor will
arguing that the context is not suitable, although the GPU supports a
suitable GLES context.
Add version number 2.1 requirement when requesting non-core desktop GL
context (core context has at least 3.1), so it will fall back to create
GLES contexts when the version number requirement is not met.
Tested on a Intel 945GMS integrated GPU, which supports GL 1.4 and GLES
2.0. Before applying this, it will fail to launch X server when no
configuration is present because of glamor initialization failure, after
applying glamor will start with GLES.
Signed-off-by: Icenowy Zheng
---
glamor/glamor.h | 4
glamor/glamor_egl.c | 4
2 files changed, 8 insertions(+)
diff --git a/glamor/glamor.h b/glamor/glamor.h
index 09e9c895c..abee6a3e8 100644
--- a/glamor/glamor.h
+++ b/glamor/glamor.h
@@ -75,6 +75,10 @@ typedef Bool (*GetDrawableModifiersFuncPtr) (DrawablePtr
draw,
#define GLAMOR_GL_CORE_VER_MAJOR 3
#define GLAMOR_GL_CORE_VER_MINOR 1
+/* We need OpenGL 2.1 to work at least */
+#define GLAMOR_GL_VER_MAJOR 2
+#define GLAMOR_GL_VER_MINOR 1
+
/* @glamor_init: Initialize glamor internal data structure.
*
* @screen: Current screen pointer.
diff --git a/glamor/glamor_egl.c b/glamor/glamor_egl.c
index b33d8ef15..8da8d2731 100644
--- a/glamor/glamor_egl.c
+++ b/glamor/glamor_egl.c
@@ -946,6 +946,10 @@ glamor_egl_init(ScrnInfoPtr scrn, int fd)
EGL_NONE
};
static const EGLint config_attribs[] = {
+EGL_CONTEXT_MAJOR_VERSION_KHR,
+ GLAMOR_GL_VER_MAJOR,
+ EGL_CONTEXT_MINOR_VERSION_KHR,
+ GLAMOR_GL_VER_MINOR,
EGL_NONE
};
--
2.18.0
___
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
X.Org security advisory: August 21, 2018
X.Org security advisory: August 21, 2018 Multiple issues in libX11 = The functions XGetFontPath, XListExtensions and XListFonts from libX11 are vulnerable to three different issues: Off-by-one writes (CVE-2018-14599). --- The functions XGetFontPath, XListExtensions, and XListFonts are vulnerable to an off-by-one override on malicious server responses. The server replies consist of chunks consisting of a length byte followed by actual string, which is not NUL-terminated. While parsing the response, the length byte is overridden with '\0', thus the memory area can be used as storage of C strings later on. To be able to NUL-terminate the last string, the buffer is reserved with an additional byte of space. For a boundary check, the variable chend (end of ch) was introduced, pointing at the end of the buffer which ch initially points to. Unfortunately there is a difference in handling "the end of ch". While chend points at the first byte that must not be written to, the for-loop uses chend as the last byte that can be written to. Therefore, an off-by-one can occur. Out of boundary write (CVE-2018-14600). --- The length value is interpreted as signed char on many systems (depending on default signedness of char), which can lead to an out of boundary write up to 128 bytes in front of the allocated storage, but limited to NUL byte(s). Casting the length value to unsigned char fixes the problem and allows string values with up to 255 characters. Crash on invalid reply (CVE-2018-14598). If the server sends a reply in which even the first string would overflow the transmitted bytes, list[0] (or flist[0]) will be set to NULL and a count of 0 is returned. If the resulting list is freed with XFreeExtensionList or XFreeFontPath later on, the first Xfree call: Xfree (list[0]-1) turns into Xfree (NULL-1) which will most likely trigger a segmentation fault. Patches === Patches for these issues have been commited to the libX11 git repository. libX11 1.6.6 will be released shortly and will include those patches. https://gitlab.freedesktop.org/xorg/lib/libx11 b469da1430cdcee06e31c6251b83aede072a1ff0 CVE-2018-14599 dbf72805fd9d7b1846fe9a11b46f3994bfc27fea CVE-2018-14600 e83722768fd5c467ef61fa159e8c6278770b45c2 CVE-2018-14598 Thanks == X.Org thanks Tobias Stoeckmann for reporting these issues to our security team and assisting them in understanding them and evaluating our fixes. signature.asc Description: PGP signature ___ 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: gitlab group permissions update
Hi Adan,
On 20 August 2018 at 20:17, Adam Jackson wrote:
> gitlab groups are recursive, which means if you are a member of the
> 'xorg' group, your permission level for every project in that group is
> at least as high as your permission at the top level. Most of the
> existing accounts were set as Maintainer, at which level you can do
> things like read and set the secret tokens used for web API
> integrations, which is maybe a little too permissive in general.
>
> I've bumped most people down to Developer, which is still enough to do
> things like close issues and merge MRs. The difference is essentially
> that Maintainers can modify the gitlab environment of a project, in
> addition to just the project's content like a Developer. If you need
> higher access for your subprojects, give a shout.
>
That solves some confusion, as the notification email came.
I'm 100% behind the reason, although a suggestion for the future:
I wonder about having this in gitlab/bugzilla issue tracking with
follow-up action/commit.
It serves as a nice example of transparent/open-source development
{admin really} model.
That said, I'm not 100% sure if permission changes are tracked - git
or otherwise.
HTH
Emil
___
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] man: Mention that InputClass overrides InputDevice.
To prevent confusion, since user may consider InputDevice as "stronger selector" and expect that it will take priority over InputClass. --- Downstream reference: https://bugzilla.opensuse.org/show_bug.cgi?id=1105311 hw/xfree86/man/xorg.conf.man | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/hw/xfree86/man/xorg.conf.man b/hw/xfree86/man/xorg.conf.man index 958926243..c921a1487 100644 --- a/hw/xfree86/man/xorg.conf.man +++ b/hw/xfree86/man/xorg.conf.man @@ -892,6 +892,10 @@ sections recognise some driver\-independent which are described here. See the individual input driver manual pages for a description of the device\-specific options. +.B InputClass +sections which match this device will override the options specified in +.B InputDevice +section. .TP 7 .BI "Option \*qAutoServerLayout\*q \*q" boolean \*q Always add the device to the ServerLayout section used by this instance of @@ -1022,7 +1026,11 @@ class of input devices as they are automatically added. An input device can match more than one .B InputClass section. Each class can override settings from a previous class, so it is -best to arrange the sections with the most generic matches first. +best to arrange the sections with the most generic matches first. Options in +.B InputClass +sections override options from the device's backend, including those set in +.B InputDevice +section. .PP .B InputClass sections have the following format: -- 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: [Xcb] [PATCH xcb] don't flag extra reply in xcb_take_socket
On 14.08.2018 14:46, Julien Cristau wrote:
> +xcb@
Thanks, Julien.
And sorry for this mail getting stuck in xorg-devel's moderation queue,
I'll remove that CC if I reply again.
> On 08/09/2018 12:20 AM, Erik Kurzinger wrote:
>> If any flags are specified in a call to xcb_take_socket,
>> they should only be applied to replies for requests sent
>> after that function returns (and until the socket is
>> re-acquired by XCB).
>>
>> Previously, they would also be incorrectly applied to the
>> reply for the last request sent before the socket was taken.
>> For instance, in this example program the reply for the
>> GetInputFocus request gets discarded, even though it was
>> sent before the socket was taken. This results in the
>> call to retrieve the reply hanging indefinitely.
Thanks for figuring this out. Still, I'm slightly confused about this. I
added another GetInputFocus request after the xcb_take_socket(). If I
get the reply for this second request first, everything works fine. If I
get the reply for this second request second, getting the first reply
still hangs. (See attached file)
I fail to understand this behaviour. Since pending replies are applied
when receiving responses from the server, shouldn't the order that I
actually fetch the replies from XCB make no difference?
(Also, I patched my local xcb with just your change to
xcb_take_socket(), expecting this to cause the first request after
taking the socket to be discarded, but this did not happen either)
I feel like I am understanding less than before I started to figure this
out...
Cheers,
Uli
[...]
>> diff --git a/src/xcb_out.c b/src/xcb_out.c
>> index 3601a5f..c9593e5 100644
>> --- a/src/xcb_out.c
>> +++ b/src/xcb_out.c
>> @@ -387,8 +387,14 @@ int xcb_take_socket(xcb_connection_t *c, void
>> (*return_socket)(void *closure), v
>> {
>> c->out.return_socket = return_socket;
>> c->out.socket_closure = closure;
>> -if(flags)
>> -_xcb_in_expect_reply(c, c->out.request,
>> WORKAROUND_EXTERNAL_SOCKET_OWNER, flags);
>> +if(flags) {
>> +/* c->out.request + 1 will be the first request sent by the
>> external
>> + * socket owner. If the socket is returned before this request
>> is sent
>> + * it will be detected in _xcb_in_replies_done and this
>> pending_reply
>> + * will be discarded.
>> + */
>> +_xcb_in_expect_reply(c, c->out.request + 1,
>> WORKAROUND_EXTERNAL_SOCKET_OWNER, flags);
>> +}
>> assert(c->out.request == c->out.request_written);
>> *sent = c->out.request;
>> }
>>
--
- Buck, when, exactly, did you lose your mind?
- Three months ago. I woke up one morning married to a pineapple.
An ugly pineapple... But I loved her.
#include
#include
#include
static void return_socket(void *closure) {
(void) closure;
}
int main(void)
{
xcb_connection_t *c = xcb_connect(NULL, NULL);
xcb_get_input_focus_cookie_t cookie1 = xcb_get_input_focus_unchecked(c);
uint64_t seq;
xcb_take_socket(c, return_socket, NULL, XCB_REQUEST_DISCARD_REPLY, &seq);
xcb_get_input_focus_cookie_t cookie2 = xcb_get_input_focus_unchecked(c);
xcb_generic_error_t *err;
#if 0
// This version does not hang
puts("before 2");
xcb_get_input_focus_reply(c, cookie2, &err);
puts("before 1");
xcb_get_input_focus_reply(c, cookie1, &err);
#else
// This version hangs
puts("before 1");
xcb_get_input_focus_reply(c, cookie1, &err);
puts("before 2");
xcb_get_input_focus_reply(c, cookie2, &err);
#endif
puts("done");
}
___
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
