Re: [PATCH v2 xserver 6/7] os-support/solaris: add asm to gitignore

[Alan Coopersmith]

On 04/ 4/17 04:49 PM, Mihail Konev wrote:

Signed-off-by: Mihail Konev 
---
 hw/xfree86/os-support/solaris/.gitignore | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 hw/xfree86/os-support/solaris/.gitignore

diff --git a/hw/xfree86/os-support/solaris/.gitignore 
b/hw/xfree86/os-support/solaris/.gitignore
new file mode 100644
index ..00a2f5d91aeb
--- /dev/null
+++ b/hw/xfree86/os-support/solaris/.gitignore
@@ -0,0 +1 @@
+solaris-*.il



Reviewed-by: Alan Coopersmith 

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
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: [PATCH xserver] xf86_crtc_supports_gamma: Return FALSE if RandR is disabled

[Alex Deucher]

On Wed, Apr 5, 2017 at 11:23 PM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> E.g. becuase Xinerama is enabled.
>
> Fixes crash on server startup when RandR is disabled and all other
> conditions in xf86_crtc_supports_gamma are satisfied.
>
> Bugzilla: https://bugs.freedesktop.org/100293
> Signed-off-by: Michel Dänzer 

Reviewed-by: Alex Deucher 

> ---
>  hw/xfree86/modes/xf86Crtc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
> index 3f9857b4a..9ce303de7 100644
> --- a/hw/xfree86/modes/xf86Crtc.c
> +++ b/hw/xfree86/modes/xf86Crtc.c
> @@ -3405,7 +3405,8 @@ xf86_crtc_notify(ScreenPtr screen)
>  Bool
>  xf86_crtc_supports_gamma(ScrnInfoPtr pScrn)
>  {
> -if (xf86CrtcConfigPrivateIndex != -1) {
> +if (dixPrivateKeyRegistered(rrPrivKey) &&
> +xf86CrtcConfigPrivateIndex != -1) {
>  xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(pScrn);
>  xf86CrtcPtr crtc;
>
> --
> 2.11.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
___
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] xf86_crtc_supports_gamma: Return FALSE if RandR is disabled

[Michel Dänzer]

From: Michel Dänzer 

E.g. becuase Xinerama is enabled.

Fixes crash on server startup when RandR is disabled and all other
conditions in xf86_crtc_supports_gamma are satisfied.

Bugzilla: https://bugs.freedesktop.org/100293
Signed-off-by: Michel Dänzer 
---
 hw/xfree86/modes/xf86Crtc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index 3f9857b4a..9ce303de7 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -3405,7 +3405,8 @@ xf86_crtc_notify(ScreenPtr screen)
 Bool
 xf86_crtc_supports_gamma(ScrnInfoPtr pScrn)
 {
-if (xf86CrtcConfigPrivateIndex != -1) {
+if (dixPrivateKeyRegistered(rrPrivKey) &&
+xf86CrtcConfigPrivateIndex != -1) {
 xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(pScrn);
 xf86CrtcPtr crtc;
 
-- 
2.11.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

Re: [PATCH 1/2] Introduce keyboard grabbing protocol for Xwayland

[Bill Spitzak]

On Tue, Apr 4, 2017 at 3:11 AM, Olivier Fourdan  wrote:
>
> Hi
>
>> I cannot see why this api cannot be correctly emulated using some
>> wayland api that normal wayland clients can also use. Allowing X
>> clients to have more rights and abilities than Wayland clients seems
>> horrendously wrong.
>>
>> The X emulation does not have to do 1:1 translation of X11 calls into
>> Wayland requests.
>>
>> In this case I would think an attempt to grab the keyboard would
>> instead send an "activate" or "raise" or "needs attention" (that seems
>> to be a popular name) request. The X client would then get keystrokes
>> (possibly after some more user interaction such as clicking or of
>> de-iconizing the client). Because the X11 app may not expect to lose
>> the focus until the grab is lost, the X emulator would also re-request
>> the focus if it is lost at any time it could, such as on mouse clicks
>> or mouse enter events.
>>
>> I suppose the plan is that this does not actually do something that
>> Wayland clients can't do, but in that case you are just moving "how to
>> replicate what X does" from the X emulator into the compositor. That
>> still seems wrong, since compositors may differ, making it impossible
>> for the client to be rewritten to not use the X emulator but still
>> have the same behavior. I would much rather see this done by the X
>> emulator.
>
> Again, even though the protocol does not specifically target 
> override-redirect windows, those are the main problem here, sensible X11 
> window managers do not "manage" those, so setting EWMH properties such as 
> "activate" or "demand attention" will be ignored by most X11 window managers 
> on O-R windows.
>
> I have attached a simple code sample to demonstrate this - And this is not an 
> hypothetical issue, this is 
> https://bugs.freedesktop.org/show_bug.cgi?id=96547 - This works fine on X11 
> thanks to the Xserver issuing the requested grab, it cannot work on Xwayland 
> because Wayland has no similar mechanism.
>
> But if you can solve this issue reliably for all X11 window managers/Wayland 
> compositors in Xwayland alone without the help of any additional protocol, 
> best would be to send your patches for Xwayland to xorg-devel.
>
> Cheers,
> Olivier

You seem to be thinking I am proposing some change to the client that
is using XLib.

I mean to change the code that you are currently proposing will
construct and send this Wayland request. Obviously you are able to do
that since you are modifying it right now to produce that request, and
since it is Wayland it is obviously not the Xlib-using client. My best
guess is that this is in the X server.

The proposal is that it instead sends an "activate" or whatever to
Wayland, and if it then receives a deactivate and loses the focus, it
makes some concerted attempt (ie send another "activate" on the next
mouse click) to get the focus back.

I realize the X server is quite a mess and that it may be very
difficult to do anything other than 1:1 translation of X requests to
Wayland requrests, such as adding spurious extra "activate" requests,
and that it is easier to do this mess in the compositor. If that is
the reason then this api makes sense, but the documentation should
*clearly* specify this reason. And it should say *exactly* what a
Wayland client can do to get the same result, and specify that any
compositor that produces a different result from this than from the
Wayland client is out of spec.

My main concern is that X11 clients not get special super powers that
normal clients don't have.

In a related note I am really scared that X11 apps are allowed to set
window xy positions and Wayland clients are not. That needs to be
fixed. I know our software will (if we ever stop using X11) be forced
to make fudge this somehow, possibly by figuring out how to nest a
Wayland window inside an X11 one. We need the ability to save/restore
window layouts in text files that are portable across operating
systems, so anything other than this is impossible. (in reality I
expect *every* compositor will add this as an "extension" but it is
pretty stupid to not define this from the start so we don't have to do
compositor-specific code).
___
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: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

[Daniel Vetter]

On Mon, Apr 3, 2017 at 8:25 AM, Manasi Navare  wrote:
>> So in that case you do need userspace to re-request the same mode at the
>> same bpp?
>
> So yes because when userspace requests the same mode at same bpp,
> kernel will still call intel_dp->mod_valid which validates the mode
> against 18bpp so if the requested mode can be displayed at the lowest of
> 18bpp, then the kernel will try to do the modeset for that mode at lower
> bpp. What I am trying to say is irrespective of what bpp userspace requests,
> kernel will check if it can display that at the lowest of 18bpp.

You're talking about two different bpp here I think. Eric talks about
the pixel format of the framebuffer, Manasi here about the bpp we send
over the wire. The kernel will auto-dither if the wire bpp is lower
than the stuff we scan out. Same with 6bpc panels really.

Right now userspace can't request a specific bpp for the sink/pipe,
that's fully under the kernel's control. It only gets to set the pixel
format of fbs.
-Daniel
-- 
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

Re: [PATCH 1/2] Introduce keyboard grabbing protocol for Xwayland

[Quentin Glidic]

On 4/3/17 3:47 PM, Olivier Fourdan wrote:

Hi Quentin,


I think it may be worth it to add a little safety net:
“Compositors are required to restrict this interface to Xwayland alone,
and raise a protocol error for native Wayland clients.”


Yes, agreed, good point! But do we really need to kill a client that would dare 
to try to bind to the grab interface?

Right now my implementation simply ignores the bind request...



I was thinking about your “hide global”[1] API, which does kill the 
client. It seems like a perfect use of it to me.


[1] 




--

Quentin “Sardem FF7” Glidic
___
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: [PATCH 1/2] Introduce keyboard grabbing protocol for Xwayland

[Quentin Glidic]

On 4/2/17 2:57 AM, Peter Hutterer wrote:

woohoo, grabs. My favourite topic! ;)
On Wed, Mar 22, 2017 at 05:27:22PM +0100, Olivier Fourdan wrote:

>> [snip]

+  
+   This protocol specifies a way for Xwayland to request all keyboard
+   events to be forwarded to a surface even when the surface does not
+   have keyboard focus.
+
+   Unlike the X11 protocol, Wayland doesn't have the notion of
+   active grab on the keyboard.
+
+   When an X11 client acquires an active grab on the keyboard, all
+   key events are reported only to the grabbing X11 client.
+   When running in Xwayland, X11 applications may acquire an active
+   grab but that cannot be translated to the Wayland compositor who
+   may set the input focus to some other surface, thus breaking the
+   X11 client assumption that all key events are reported.
+
+   When an X11 client requests a keyboard grab, the Wayland compositor
+   may either inform or ask the user for the right to forward all key
+   events to the given client surface.


this is confusing :) paragraph 3 talks aobut what's not working and
paragraph 4 about what this protocol should fix. How about something like:

 This protocol is application-specific to meet the needs of the X11
 protocol through Xwayland. It provides a way for XWayland to request
 all keyboard events to be forwarded to a surface even when the
 surface does not have keyboard focus.

 In the X11 protocol, a client may request an "active grab" on the
 keyboard. On success, all key events are reported only to the
 grabbing X11 client. For details, see XGrabKeyboard(3).

 The core Wayland protocol does not have a notion of an active
 keyboard grab. When running in Xwayland, X11 applications may
 acquire an active grab inside XWayland but that cannot be translated
 to the Wayland compositor who may set the input focus to some other
 surface. In doing so, it breaks the X11 client assumption that all
 key events are reported to the grabbing client.

This protocol specifies a way for Xwayland to request all keyboard
 be directed to the given surface. The protocol does not guarantee
 that the compositor will honor this request and it does not
 prescribe user interfaces on how to handle the respond. For example,
 a compositor may inform the user that all key events are now
 forwarded to the given client surface, or it may ask the user for
 permission to do so.

 Warning! Things may go boom... etc. etc.


I think it may be worth it to add a little safety net:
“Compositors are required to restrict this interface to Xwayland alone, 
and raise a protocol error for native Wayland clients.”


Cheers,

--

Quentin “Sardem FF7” Glidic
___
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: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Daniel Vetter]

On Sun, Apr 02, 2017 at 12:58:33PM -0700, Keith Packard wrote:
> Daniel Vetter  writes:
> 
> > On that, I think we could just unconditionally hand leases all encoders.
> > Encoders turned out to be a bit an uapi mistake.
> 
> Well, given the complexity of hardware these days, even crtcs would
> probably best have been hidden...
> 
> > Neither setcrtc nor atomic use it, the kernel always selects the right
> > encoder for you. It's only exposed to give userspace some hints wrt
> > routing (and it's pretty bad at describing modern restrictions, which
> > often means you get a 1:1 encoder/connector mapping). Unconditionally
> > exposing all encoders for all lessees would fix all these troubles.
> 
> Yeah, I can't find encoders passed into any kernel api, other than the
> getencoder call. It seems like we can leave them as shared objects not
> subject to leasing as they are query-only. I'll go ahead and do
> that. The encoder crtc set still needs to be filtered in the query
> operation so that the client knows which crtc to use for each output.
> 
> Now as to how we report the kernel objects that have been leased, we
> have two options:
> 
>  1) Report them back via the X protocol
> 
>  2) Have the client query the resulting lease for its contents
> 
> I already suggested that the drm query API should be changed to report
> both type and id for each leased object, that would make it sufficient
> here. Instead of duplicating that over the X protocol, I suggest we just
> use the adjusted kernel API.

Hm, if you restrict getresources and getplanes, you'll get your leased
objects query api. Iirc that part was missing in your kernel patch. And it
gives you exaclty what you want: per-type list of object ids.
> 
> > Note that there's also no properties on encoders, those only exist on
> > crtc, connector and planes.
> 
> Any thoughts on access control for properties? Right now, the set
> property ioctl checks for access to the containing object, but there's
> no check when querying properties. This means that you don't need to add
> leases on properties.

This changes with atomic - without properties you can't change anything
using atomic. Otoh maybe we just want to add checks on the containing
object for now, some of the finer semantic points like "don't modeset" or
"don't steal shared resources at all" can't be expressed (in a generic way
at least) by restricting to specific properties anyway. E.g. on many chips
changing the fb is only ok if you keep the same stride, pixel format and
modifier (~ tiling).
-- 
Daniel Vetter
Software Engineer, Intel Corporation
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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Daniel Vetter]

On Sat, Apr 01, 2017 at 03:58:58PM -0700, "Keith Packard" wrote:
> 
> As a part of the DRM leasing work, we need a way to have the X server
> create a lease and pass it back to an X client. Here's a proposal for
> the RandR specification changes necessary for that. The basic plan is
> pretty simple:
> 
>  1. Expose the ability to create a lease for a set of CRTCs and
> OUTPUTs. The X server will have to pick a suitable encoder as that's
> not visible via RandR.

On that, I think we could just unconditionally hand leases all encoders.
Encoders turned out to be a bit an uapi mistake. Neither setcrtc nor
atomic use it, the kernel always selects the right encoder for you. It's
only exposed to give userspace some hints wrt routing (and it's pretty bad
at describing modern restrictions, which often means you get a 1:1
encoder/connector mapping). Unconditionally exposing all encoders for all
lessees would fix all these troubles.

Note that there's also no properties on encoders, those only exist on
crtc, connector and planes.

Kinda more a comment on the kernel side than for xrandr.
-Daniel

>  2. Provide a way to hide some monitors from other clients using EDID
> manufacturer ids and product codes. Outputs with EDID properties
> matching the grab will report 'disconnected' to all clients other
> than the grabbing client. This way, the desktop environment never
> knows that an HMD has been plugged in, so there's no transient
> flicker of desktop being presented to it.
> 
> I wanted to make it possible for the X server to set the mode on the
> leased outputs, but I'm not sure how -- I don't want to display the X
> screen on them, and there's no other frame buffer I can name over the
> wire. For now, that means the leasing client will need to set a mode
> itself. If that fails, it can go whack the X configuration over RandR
> and try again, which is all the X server would do anyways.
> 
> Comments are welcome; I'll go try to write the code in the next few
> days; it all looks pretty easy at this point.
> 
> diff --git a/randrproto.txt b/randrproto.txt
> index 74b7c36..8dded63 100644
> --- a/randrproto.txt
> +++ b/randrproto.txt
> @@ -1,6 +1,6 @@
>  The X Resize, Rotate and Reflect Extension
> -  Version 1.5.0
> -2015-03-14
> +  Version 1.6.0
> +2017-04-01
>  
> Jim Gettys
>  jim.get...@hp.com
> @@ -9,9 +9,7 @@
>   Hewlett Packard Company
>  
>Keith Packard
> - keith.pack...@intel.com
> -  Open Source Technology Center
> -Intel Corporation
> +   kei...@keithp.com
>  
>  1. Introduction
>  
> @@ -186,6 +184,24 @@ consider as single viewable areas.
>  Xinerama's information now comes from the Monitors instead of directly
>  from the CRTCs. The Monitor marked as Primary will be listed first.
>  
> +1.6. Introduction to version 1.6 of the extension
> +
> +Version 1.6 adds resource leasing.
> +
> + • A 'Lease' is a collection of crtcs and outputs which are made
> +   available to a client for direct access via kernel KMS and DRM
> +   APIs. This is done by passing a suitable file descriptor back to
> +   the client which has access to those resources. While leased, those
> +   resources aren't used by the X server.
> +
> +Version 1.6 adds EDID-based output 'grabbing'.
> +
> + • An 'Output Grab' matches a set of EDID Manufacturer ID and product
> +   codes. For outputs with matching EDID values, the connected status
> +   of the output is only visible to the grabbing client. Other clients
> +   will see the output as disconnected. Attempts to configure the
> +   grabbed output by other clients will fail.
> +
>  1.99 Acknowledgments
>  
>  Our thanks to the contributors to the design found on the xpert mailing
> @@ -273,6 +289,10 @@ Mode
>  Provider
>   A value for a PROVIDER argument does not name a defined PROVIDER.
>  
> +OutputGrab
> + A value for an OUTPUTGRAB argument does not name a defined
> + OUTPUTGRAB
> +
> ❧❧❧
>  
>  5. Protocol Types
> @@ -419,6 +439,23 @@ MONITORINFO { name: ATOM
>  
> ❧❧❧
>  
> +5.7. Protocol Types added in version 1.6 of the extension
> +
> +OUTPUTGRAB { XID }
> +
> +EDIDMATCH { id: CARD16
> +  code-min: CARD16
> +  code-max: CARD16 }
> +
> + These values come from the EDID specification. 'id' is the
> + Manufacturer ID value which is bytes 8 and 9 in the EDID
> + packet, stored in big endian order (MSB first). 'code-min' and
> + 'code-max' define a closed-interval of Manufacturer product
> + codes, which is byte 10 and 11 of the EDID packet, stored in
> + little endian order (LSB first).
> +
> +   ❧❧❧
> +
>  6. 

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Daniel Vetter]

On Tue, Apr 04, 2017 at 08:53:45AM -0700, Keith Packard wrote:
> Daniel Vetter  writes:
> 
> > The multi-seat thing sounds like vapourware, I think we should care about
> > the vr use-case for now, and only that one.
> 
> Ok, I can live with that, even if I like the idea of a slightly more
> general solution.
> 
> > For VR itself I'd go as far as saying that probably our "create lease"
> > ioctl should have only the semantics we need to pass one crtc+primary
> > plane for pageflipping in a VR compositor, expressed in a flag.
> 
> Yeah, we can't express planes through X anyways. I'll leave the kernel
> API with multiple planes as that's actually simpler than having it
> validate that only a single plane is in the lease.
> 
> > All the details about additional corner cases are just so unclear to
> > me (and there's not even a clear use case that will materialize) that
> > I don't think having the uapi is worth it. Too close to the "I'll
> > regret this immediately" bucket :-)
> 
> Removing the 'ChangeLease' ioctl eliminates a bunch of complexity in the
> code, and means I don't even have to think about sending events. I'll
> also go ahead and remove the ability to hide resources from the lessor.
> 
> Thanks, as always, for your thoughtful review.
> 
> ps -- Any thoughts on whether the X request should include the mode to
> use?  Doing that would let us restrict the lessee from setting modes,
> and avoid potential resource issues with the window system. However, it
> would also require providing a scanout buffer in the request.

Yeah I think that's a pretty neat idea to reduce the lease complexity even
more. If the VR compositor is unhappy and wants a different mode, it can
simply nuke the lease and as for a new one. Forgot to say that :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
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

Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Daniel Vetter]

On Mon, Apr 03, 2017 at 09:41:34AM -0700, Keith Packard wrote:
> Daniel Vetter  writes:
> 
> > Hm, if you restrict getresources and getplanes, you'll get your leased
> > objects query api. Iirc that part was missing in your kernel patch. And it
> > gives you exaclty what you want: per-type list of object ids.
> 
> Hrm. I think that's one Dave didn't want to restrict so that
> applications don't see resources disappear and get confused. But,
> perhaps a simple variant of those instead of a completely different API.

On the X side we don't want to restrict. But the VR client better be able
to deal with not seeing or being able to use everything.

Also if this confuses VR, then another reason why we want to make leases
invariant and only allow pure revoke, not changing the list.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
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

Re: [PATCH 1/2] Introduce keyboard grabbing protocol for Xwayland

[Bill Spitzak]

I cannot see why this api cannot be correctly emulated using some
wayland api that normal wayland clients can also use. Allowing X
clients to have more rights and abilities than Wayland clients seems
horrendously wrong.

The X emulation does not have to do 1:1 translation of X11 calls into
Wayland requests.

In this case I would think an attempt to grab the keyboard would
instead send an "activate" or "raise" or "needs attention" (that seems
to be a popular name) request. The X client would then get keystrokes
(possibly after some more user interaction such as clicking or of
de-iconizing the client). Because the X11 app may not expect to lose
the focus until the grab is lost, the X emulator would also re-request
the focus if it is lost at any time it could, such as on mouse clicks
or mouse enter events.

I suppose the plan is that this does not actually do something that
Wayland clients can't do, but in that case you are just moving "how to
replicate what X does" from the X emulator into the compositor. That
still seems wrong, since compositors may differ, making it impossible
for the client to be rewritten to not use the X emulator but still
have the same behavior. I would much rather see this done by the X
emulator.


On Mon, Apr 3, 2017 at 11:56 AM, Olivier Fourdan  wrote:
> Hi Pekka,
>
>> you cannot ignore a wl_registry.bind request. Did you ever try to see
>> what happens? :-)
>
> Admittedly, I didn't go that far!
>
>> If you do not create a wl_resource when the protocol spec says "this
>> creates a new object", then if the client ever refers to the
>> non-created object, it will hopefully be automatically shot dead for
>> referencing a bad object id.
>
> Ah right, makes sense, of course...
>
>> Furthermore, I think it also violates the object id allocation scheme,
>> so if the client tries to create any new object after the ignored bind
>> request, that would also explode.
>>
>> So you might just let the client out of its misery before anything more
>> confusing can happen. At least you can then deliver a descriptive error
>> message. ;-)
>
> Yeah, I'll use the global filter API, it's the intended use and really simple 
> to put in place :)
>
>> As for the protocol wording, I think it should be enough to say that
>> compositors should restrict the interface to Xwayland. How they do that
>> is up to them.
>
> Yeap, agreed
>
> Thanks
> Olivier
> ___
> wayland-devel mailing list
> wayland-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-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: Proposal for RandR version 1.6, Leases and EDID-based output grabs

[Daniel Vetter]

On Mon, Apr 03, 2017 at 03:50:33PM -0700, Keith Packard wrote:
> Daniel Vetter  writes:
> 
> > Also if this confuses VR, then another reason why we want to make leases
> > invariant and only allow pure revoke, not changing the list.
> 
> I'm not sure why you want this to be asymmetrical, nor why you would
> expect lessees to be any more competent at dealing with hotplug than the
> lessor.
> 
> One use case already proposed for this API was to allow for multi-seat,
> where the lessee would be an existing window system, which we already
> accept as being incompetent at dealing with resource hotplug. I imagine
> that in this case, a newly plugged monitor would be detected by the
> multi-seat manager (logind?) and added to one of the existing leases,
> along with a suitable CRTC resource. For this to work, the lessee will
> need to already know about those resources and only have their
> connectivity status hidden.

The multi-seat thing sounds like vapourware, I think we should care about
the vr use-case for now, and only that one. And for that restricting stuff
is perfectly fine. Of course we can design the entire thing in a way that
doesn't draw us into a corner in the future right away, but that's mostly
on the implementation side. For VR itself I'd go as far as saying that
probably our "create lease" ioctl should have only the semantics we need
to pass one crtc+primary plane for pageflipping in a VR compositor,
expressed in a flag. All the details about additional corner cases are
just so unclear to me (and there's not even a clear use case that will
materialize) that I don't think having the uapi is worth it. Too close to
the "I'll regret this immediately" bucket :-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
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

Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

[Daniel Vetter]

On Fri, Mar 31, 2017 at 05:22:09PM -0700, Eric Anholt wrote:
> Manasi Navare  writes:
> 
> > On Fri, Mar 31, 2017 at 01:08:41PM -0700, Eric Anholt wrote:
> >> Manasi Navare  writes:
> >> 
> >> > On Thu, Mar 30, 2017 at 05:37:55PM -0700, Eric Anholt wrote:
> >> >> Martin Peres  writes:
> >> >> 
> >> >> > On 26/01/17 14:37, Martin Peres wrote:
> >> >> >> Despite all the careful planing of the kernel, a link may become
> >> >> >> insufficient to handle the currently-set mode. At this point, the
> >> >> >> kernel should mark this particular configuration as being broken
> >> >> >> and potentially prune the mode before setting the offending 
> >> >> >> connector's
> >> >> >> link-status to BAD and send the userspace a hotplug event. This may
> >> >> >> happen right after a modeset or later on.
> >> >> >>
> >> >> >> When available, we should use the link-status information to reset
> >> >> >> the wanted mode.
> >> >> >>
> >> >> >> Signed-off-by: Martin Peres 
> >> >> >
> >> >> > The relevant kernel patches have landed in drm-tip about a month ago.
> >> >> >
> >> >> > Eric, would you mind providing feedback on or merging this patch?
> >> >> 
> >> >> The later discussion has sounded like the kernel will (always) prune the
> >> >> mode when we re-query, meaning that it doesn't make any sense to try to
> >> >> re-set to the old mode.  Is this not the case?
> >> >
> >> >
> >> > No the kernel will simply send a hotplug with link status as bad
> >> > and then after that point its userspace driver's responsibility
> >> > to check if link status is BAD, retry the same mode and if it fails
> >> > then re probe.
> >> 
> >> So the kernel will sometimes allow the same mode to be re-set with the
> >> same bpp?
> >
> > So when userspace driver re-sets the same mode, the kernel will call the
> > mode valid function where it will see it can allow the sam mode perhaps
> > at a lower bpp now since the link parameters are lowered.
> > So the mode which failed at 30 bpp, might still work at 18bpp and is
> > better going to a lower resolution.
> 
> The question was whether the kernel will ever allow the same mode at the
> same bpp, since that's what this patch tries to do.

Yes, this can happen. Doing a full modeset with recomputing clocks and
everything behind userspace's back might not be something the kernel
driver can pull of with a reasonable amount of effort, hence why we punt
to userspace. The interface spec makes this a CAN, not WILL, to allow less
unreasonable hw to handle these cases directly in the kernel driver. E.g.
plain link-retraining is handled in i915.ko still.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
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

Re: [PATCH v2a xserver] sdksyms: fix typo in export keyword index

[Mihail Konev]

On Thu, Apr 06, 2017 at 05:14:22AM +0500, Mihail Konev wrote:
> 
> v2a: Fix GCC 4 paragraph: "when extern and type are on the same line" ->
>  "expansion is put on a single line".
> 

v2 was the correct one, sorry.
Wrongly assumed there are no declarations on a single line, yet "I saw
the entire decls when debug printing".

Mihail
___
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 v2a xserver] sdksyms: fix typo in export keyword index

[Mihail Konev]

In headers, the symbols exported from Xorg are declared as
  "extern _X_EXPORT type name [...]".

In 3dad57b1 ("sdksyms: Tighten up the symbols we add to the magic table"),
a check has been inserted that ensures the word at the index matches the
_X_EXPORT expansion.

With GCC 5, the "skip line numbers" loop will reassign the index, and
the check works as intended.

With GCC 4 and below, the expanded declaration is put on a single line,
the initial index is off by one, the check will look at the type
instead, never pass, and the build breaks.

Fixes: b1dac41f ('Use libtool convenience libraries and better "symbol" table')
Signed-off-by: Mihail Konev 
---

v2a: Fix GCC 4 paragraph: "when extern and type are on the same line" ->
 "expansion is put on a single line".

 hw/xfree86/sdksyms.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/xfree86/sdksyms.sh b/hw/xfree86/sdksyms.sh
index 767ce2181d5f..0139a5077516 100755
--- a/hw/xfree86/sdksyms.sh
+++ b/hw/xfree86/sdksyms.sh
@@ -348,7 +348,7 @@ BEGIN {
 
 /^extern[  ]/  {
 if (sdk) {
-   n = 3;
+   n = 2;
 
 # skip line numbers GCC 5 adds before __attribute__
 while ($n == "" || $0 ~ /^# [0-9]+ "/) {
-- 
2.9.2

___
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: [RFC] Visual Class for On-Screen HDR Drawables

[Adam Jackson]

On Tue, 2017-02-28 at 19:23 -0800, Alex Goins wrote:

> 
> FYI - it's only the texture_from_pixmap texture target attributes that they 
> base
> off of the root window, e.g. GLX_TEXTURE_2D_EXT, GLX_TEXTURE_RECTANGLE_EXT,
> GLX_TEXTURE_FORMAT_RBGA_EXT. They get the fbconfig from the X pixmap's depth,
> along with a few other static attributes, which is still a problem for us 
> since
> with HDR we'll need more info than just depth. The texture target derivation 
> is
> still wrong behavior, however, as it should be done using FBConfig attributes.
> If they want to avoid looking up FBconfig attributes every time a window is
> mapped, a better implementation suggested internally would be to cache 
> FBconfig
> capabilities in a hash map or something based on the visual ID, due to the
> variability of texture format attributes between different visuals/fbconfigs.

It's on window creation, not map, right? You don't get to change the
fbconfig bound to a GLXWindow without destroying the GLXWindow. (And
even then, if you only have one fbconfig matching that visual ID the
map is static, which happens to be the case for Xorg atm.)

> The glXQueryDrawable() method of finding the fbconfig could be a problem with
> our driver, and possibly others per the spec. glXCreateWindow() doesn't
> guarantee that the GLX window and X window are the same, despite being
> associated, e.g.:
> 
> glXWin = glXCreateWindow(xWin);
> assert(glXWin == xWin);
> glXQueryDrawable(xWin);
> 
> will work in Mesa, but with our driver the assert will fail, and
> glXQueryDrawable() should too; it certainly can per the spec.
> 
> If glXWin != xWin, the composite manager can't rely on glXQueryDrawable(xWin)
> when it discovers a redirected window xWin. So, if we're going to use
> glXQueryDrawable(), we'd want a more reliable way to ascertain the GLX window
> XID from the native X window.

This is a really hard set of grafs to respond to because I'm not really
sure what you're getting at. (This thread in general is getting a bit
hard to follow; it might help to start over and restate the current
proposal/theory.)

First: glXCreateWindow _does_ create a new XID, even for Mesa; the
assert will fail. I don't think this matters for HDR-aware compositors,
because the compositor does not create a GLXWindow for the app. It has
only the Window, it only needs to get from the Window to _something_
describing the HDR format.

Second (lemma): Xorg is not presently as strict as the GLX spec
arguably demands. We will let you create multiple GLXWindows pointed at
the same Window as long as the fbconfig matches (for fairly loose
definitions of the word "match" that's not really important here). The
spec says if there is already an fbconfig associated with the window
then glXCreateWindow should throw BadAlloc; Xorg would need to learn
how to map from Window to GLXWindow to discover this. Not hard, merely
not done yet.

Third: glXQueryDrawable does have a special case for Window XIDs,
because the GLXDrawable type is a union of the three novel GLX drawable
types and the core Window type. Since Xorg does not have a map from
Window to GLXWindow (supra), when we are asked for the drawable
attributes of a Window, we can only return data that we can compute
from core X11 state, meaning we don't return an fbconfig. So, indeed,
glXQueryDrawable on the Window would not be sufficient right now, on
Xorg's GLX.

Fourth: I think the model I was envisioning was that the compositor
would call glXQueryDrawable on the Pixmap (that it got from
CompositeNameWindowPixmap). But obviously this doesn't work, you need
to operate on a GLXDrawable, and a Pixmap isn't one, and you can't
create a GLXPixmap unless you know the fbconfig you want to use with
it.

So the question is still how to map from the Window to the GLX drawable
state, but I think we can do it with existing queries and merely new
attributes. If the server's GLX has at most one GLXWindow per Window -
true I believe of NVIDIA, easy to make true of Xorg, probably what the
spec implies - then we can make QueryDrawable implicitly operate on the
GLXWindow if there is one. In which case, either you _can_ find an
attribute describing the HDR format (because the client is doing HDR
rendering to it and has set it), or you can't (because the client is
not HDR, or because there is no GLXWindow at all).

That's still not awesome. There's the corner case where the app posts
its first frame of damage and later starts doing HDR GL to the window,
to catch that transition you'd need to glXQueryDrawable on SDR windows
on every update. There's also the problem that the HDR window might be
a child of the redirected window, the cm would need to redirect the HDR
subwindow too. Hmm.

> If we make format data a property of the native X window, compositors should
> have no issues querying it from the redirected window, and we could piggyback
> off of it to do the transformation to unorm8 based on the specified format if 
> we
> have a 

Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

[Manasi Navare]

On Mon, Apr 03, 2017 at 09:19:35AM +0200, Daniel Vetter wrote:
> On Mon, Apr 3, 2017 at 8:25 AM, Manasi Navare  
> wrote:
> >> So in that case you do need userspace to re-request the same mode at the
> >> same bpp?
> >
> > So yes because when userspace requests the same mode at same bpp,
> > kernel will still call intel_dp->mod_valid which validates the mode
> > against 18bpp so if the requested mode can be displayed at the lowest of
> > 18bpp, then the kernel will try to do the modeset for that mode at lower
> > bpp. What I am trying to say is irrespective of what bpp userspace requests,
> > kernel will check if it can display that at the lowest of 18bpp.
> 
> You're talking about two different bpp here I think. Eric talks about
> the pixel format of the framebuffer, Manasi here about the bpp we send
> over the wire. The kernel will auto-dither if the wire bpp is lower
> than the stuff we scan out. Same with 6bpc panels really.
> 
> Right now userspace can't request a specific bpp for the sink/pipe,
> that's fully under the kernel's control. It only gets to set the pixel
> format of fbs.
> -Daniel
> -- 

Yes so in that case, Eric we do need userspace to re-request the same mode
at the same bpp or the same pixel format. 
And if this also fails, then we need Gnome or KDE to be re triggering a
complete re probe.

Regards
Manasi


> 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

Re: [PATCH v2 xserver 0/7] Minor build system corrections

[Mihail Konev]

On Wed, Apr 05, 2017 at 04:49:39AM +0500, Mihail Konev wrote:
> v2 (Emil Velikov):
>   2/7: Figure out what exactly happens.
>   3/7: Add missing ifdef.
>   5/7: Move DESTDIR to configure.
>Add missing Cc.
>   1-5/7: Reword.
> 
> The 7/7 has also been suggested to use "ln -s".
> Kept unchanged since:
> 
> - It is simpler than 
> https://lists.x.org/archives/xorg-devel/2017-February/052761.html
>   No need to SUFFIXES, CLEANFILES, or -include in every makefile.
> 
> - Compiler errors are acceptable:
> 
> CC   posix_tty.include.lo
>   In file included from posix_tty.include.c:1:0:
>   ../shared/posix_tty.c: In function `GetBaud':
>   ../shared/posix_tty.c:110:9: error: `rturn' undeclared (first use in this 
> function)
>rturn B460800;
>^
>   ../shared/posix_tty.c:110:9: note: each undeclared identifier is reported 
> only once for each function it appears in
>   In file included from /usr/include/termios.h:39:0,
>from ../../../../hw/xfree86/os-support/xf86_OSlib.h:186,
>from ../shared/posix_tty.c:63,
>from posix_tty.include.c:1:
>   ../shared/posix_tty.c:110:15: error: expected `;' before numeric constant
>rturn B460800;
>  ^
>   Makefile:670: recipe for target 'posix_tty.include.lo' failed
>   make: *** [posix_tty.include.lo] Error 1
> 

The missing part:

- Rebuilding the .include.c file when the original changes is taken care
  of by Automake (Dependecy Tracking).

  Symlinks could be used (both variants attached), but then:
  * If symlinks have the ".include.c" extension, it inappropriately goes also 
into error/warning messages.
  * If symlinks have the ".c" extension, they are not obvious in makefiles.

> Mihail Konev (7):
>   configure.ac: only stub sdksyms.dep as needed
>   sdksyms: fix typo in export keyword index
>   hw/xfree86: add suid wrapper to uninstall target
>   configure.ac: add missing xquartz destdir
>   hw/xquartz: fix path to pseudoramiX headers
>   os-support/solaris: add asm to gitignore
>   configure.ac: use automake option subdir-objects
> 
>  .gitignore|  1 +
>  configure.ac  | 10 ++
>  hw/dmx/Makefile.am|  4 ++--
>  hw/dmx/config/Makefile.am |  4 ++--
>  hw/dmx/config/dmxlog.include.c|  1 +
>  hw/dmx/config/strlcpy.include.c   |  1 +
>  hw/dmx/miinitext.include.c|  1 +
>  hw/dmx/panoramiX.include.c|  1 +
>  hw/kdrive/src/Makefile.am |  2 +-
>  hw/kdrive/src/miinitext.include.c |  1 +
>  hw/vfb/Makefile.am|  2 +-
>  hw/vfb/miinitext.include.c|  1 +
>  hw/xfree86/Makefile.am|  3 +++
>  hw/xfree86/dixmods/Makefile.am|  2 +-
>  hw/xfree86/dixmods/miinitext.include.c|  1 +
>  hw/xfree86/glamor_egl/Makefile.am |  4 ++--
>  hw/xfree86/glamor_egl/glamor_egl.include.c|  1 +
>  hw/xfree86/glamor_egl/glamor_eglmodule.include.c  |  1 +
>  hw/xfree86/int10/Makefile.am  |  4 ++--
>  hw/xfree86/int10/linux.include.c  |  1 +
>  hw/xfree86/int10/linux_vm86.include.c |  1 +
>  hw/xfree86/os-support/Makefile.am | 14 +-
>  hw/xfree86/os-support/bsd/Makefile.am | 20 ++--
>  hw/xfree86/os-support/bsd/agp_noop.include.c  |  1 +
>  hw/xfree86/os-support/bsd/ioperm_noop.include.c   |  1 +
>  hw/xfree86/os-support/bsd/kmod_noop.include.c |  1 +
>  hw/xfree86/os-support/bsd/lnx_agp.include.c   |  1 +
>  hw/xfree86/os-support/bsd/pm_noop.include.c   |  1 +
>  hw/xfree86/os-support/bsd/posix_tty.include.c |  1 +
>  hw/xfree86/os-support/bsd/sigio.include.c |  1 +
>  hw/xfree86/os-support/bsd/vidmem.include.c|  1 +
>  hw/xfree86/os-support/hurd/Makefile.am| 14 +++---
>  hw/xfree86/os-support/hurd/VTsw_noop.include.c|  1 +
>  hw/xfree86/os-support/hurd/agp_noop.include.c |  1 +
>  hw/xfree86/os-support/hurd/kmod_noop.include.c|  1 +
>  hw/xfree86/os-support/hurd/pm_noop.include.c  |  1 +
>  hw/xfree86/os-support/hurd/posix_tty.include.c|  1 +
>  hw/xfree86/os-support/hurd/sigiostubs.include.c   |  1 +
>  hw/xfree86/os-support/hurd/vidmem.include.c   |  1 +
>  hw/xfree86/os-support/linux/Makefile.am   |  8 
>  hw/xfree86/os-support/linux/VTsw_usl.include.c|  1 +
>  hw/xfree86/os-support/linux/posix_tty.include.c   |  1 +
>  hw/xfree86/os-support/linux/sigio.include.c   |  1 +
>  hw/xfree86/os-support/linux/vidmem.include.c  |  1 +
>  hw/xfree86/os-support/solaris/.gitignore  |  1 +
>  hw/xfree86/os-support/solaris/Makefile.am | 12 ++--
>  

Re: [PATCH libXdmcp v2] Use getentropy() if arc4random_buf() is not available

[Mark Kettenis]

> From: Benjamin Tissoires 
> Date: Tue,  4 Apr 2017 19:13:38 +0200
> 
> This allows to fix CVE-2017-2625 on Linux platforms without pulling in
> libbsd.
> The libc getentropy() is available since glibc 2.25 but also on OpenBSD.
> For Linux, we need at least a v3.17 kernel. If the recommended
> arc4random_buf() function is not available, emulate it by first trying
> to use getentropy() on a supported glibc and kernel. If the call fails,
> fall back to the current (vulnerable) code.
> 
> Signed-off-by: Benjamin Tissoires 

Same comment as the other diff.

Reviewed-by: Mark Kettenis 

> ---
> 
> changes in v2:
> - use the getentropy() from glibc, not the plain syscall
> - make it clear that arc4random_buf() should be preferred and that we
>   are only adding band-aids on top of the missing function
> ---
>  Key.c| 31 ++-
>  configure.ac |  2 +-
>  2 files changed, 27 insertions(+), 6 deletions(-)
> 
> diff --git a/Key.c b/Key.c
> index a09b316..70607d0 100644
> --- a/Key.c
> +++ b/Key.c
> @@ -62,10 +62,11 @@ getbits (long data, unsigned char *dst)
>  #define getpid(x) _getpid(x)
>  #endif
>  
> -void
> -XdmcpGenerateKey (XdmAuthKeyPtr key)
> -{
>  #ifndef HAVE_ARC4RANDOM_BUF
> +
> +static void
> +emulate_getrandom_buf (char *auth, int len)
> +{
>  longlowbits, highbits;
>  
>  srandom ((int)getpid() ^ time((Time_t *)0));
> @@ -73,9 +74,29 @@ XdmcpGenerateKey (XdmAuthKeyPtr key)
>  highbits = random ();
>  getbits (lowbits, key->data);
>  getbits (highbits, key->data + 4);
> -#else
> +}
> +
> +static void
> +arc4random_buf (void *auth, int len)
> +{
> +int  ret;
> +
> +#if HAVE_GETENTROPY
> +/* weak emulation of arc4random through the getentropy libc call */
> +ret = getentropy (auth, len);
> +if (ret == 0)
> + return;
> +#endif /* HAVE_GETENTROPY */
> +
> +emulate_getrandom_buf (auth, len);
> +}
> +
> +#endif /* !defined(HAVE_ARC4RANDOM_BUF) */
> +
> +void
> +XdmcpGenerateKey (XdmAuthKeyPtr key)
> +{
>  arc4random_buf(key->data, 8);
> -#endif
>  }
>  
>  int
> diff --git a/configure.ac b/configure.ac
> index 2288502..d2b045d 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -65,7 +65,7 @@ esac
>  
>  # Checks for library functions.
>  AC_CHECK_LIB([bsd], [arc4random_buf])
> -AC_CHECK_FUNCS([srand48 lrand48 arc4random_buf])
> +AC_CHECK_FUNCS([srand48 lrand48 arc4random_buf getentropy])
>  
>  # Obtain compiler/linker options for depedencies
>  PKG_CHECK_MODULES(XDMCP, xproto)
> -- 
> 2.9.3
> 
> 
___
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: [PATCH libICE v2] Use getentropy() if arc4random_buf() is not available

[Mark Kettenis]

> From: Benjamin Tissoires 
> Date: Tue,  4 Apr 2017 19:12:53 +0200
> 
> This allows to fix CVE-2017-2626 on Linux platforms without pulling in
> libbsd.
> The libc getentropy() is available since glibc 2.25 but also on OpenBSD.
> For Linux, we need at least a v3.17 kernel. If the recommended
> arc4random_buf() function is not available, emulate it by first trying
> to use getentropy() on a supported glibc and kernel. If the call fails,
> fall back to the current (partly vulnerable) code.
> 
> Signed-off-by: Benjamin Tissoires 

The emulate_getrandom_buf() name sounds a bit weird.  Perhaps call it
bad_getrandom_buf() or dangerous_getrandom_buf() or
insecure_getrandom_buf() to make it obvious that the fallback code
really isn't sufficient?

Reviewed-by: Mark Kettenis 

> ---
> 
> changes in v2:
> - use the getentropy() from glibc, not the plain syscall
> - make it clear that arc4random_buf() should be preferred and that we
>   are only adding band-aids on top of the missing function
> ---
>  configure.ac  |  2 +-
>  src/iceauth.c | 65 
> ++-
>  2 files changed, 47 insertions(+), 20 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 458882a..c971ab6 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -38,7 +38,7 @@ AC_DEFINE(ICE_t, 1, [Xtrans transport type])
>  
>  # Checks for library functions.
>  AC_CHECK_LIB([bsd], [arc4random_buf])
> -AC_CHECK_FUNCS([asprintf arc4random_buf])
> +AC_CHECK_FUNCS([asprintf arc4random_buf getentropy])
>  
>  # Allow checking code with lint, sparse, etc.
>  XORG_WITH_LINT
> diff --git a/src/iceauth.c b/src/iceauth.c
> index ed31683..de4785b 100644
> --- a/src/iceauth.c
> +++ b/src/iceauth.c
> @@ -44,31 +44,19 @@ Author: Ralph Mor, X Consortium
>  
>  static int was_called_state;
>  
> -/*
> - * MIT-MAGIC-COOKIE-1 is a sample authentication method implemented by
> - * the SI.  It is not part of standard ICElib.
> - */
> +#ifndef HAVE_ARC4RANDOM_BUF
>  
> -
> -char *
> -IceGenerateMagicCookie (
> +static void
> +emulate_getrandom_buf (
> + char *auth,
>   int len
>  )
>  {
> -char*auth;
> -#ifndef HAVE_ARC4RANDOM_BUF
>  longldata[2];
>  int  seed;
>  int  value;
>  int  i;
> -#endif
>  
> -if ((auth = malloc (len + 1)) == NULL)
> - return (NULL);
> -
> -#ifdef HAVE_ARC4RANDOM_BUF
> -arc4random_buf(auth, len);
> -#else
>  #ifdef ITIMER_REAL
>  {
>   struct timeval  now;
> @@ -76,13 +64,13 @@ IceGenerateMagicCookie (
>   ldata[0] = now.tv_sec;
>   ldata[1] = now.tv_usec;
>  }
> -#else
> +#else /* ITIMER_REAL */
>  {
>   longtime ();
>   ldata[0] = time ((long *) 0);
>   ldata[1] = getpid ();
>  }
> -#endif
> +#endif /* ITIMER_REAL */
>  seed = (ldata[0]) + (ldata[1] << 16);
>  srand (seed);
>  for (i = 0; i < len; i++)
> @@ -90,7 +78,46 @@ IceGenerateMagicCookie (
>   value = rand ();
>   auth[i] = value & 0xff;
>  }
> -#endif
> +}
> +
> +static void
> +arc4random_buf (
> + char *auth,
> + int len
> +)
> +{
> +int  ret;
> +
> +#if HAVE_GETENTROPY
> +/* weak emulation of arc4random through the entropy libc */
> +ret = getentropy (auth, len);
> +if (ret == 0)
> + return;
> +#endif /* HAVE_GETENTROPY */
> +
> +emulate_getrandom_buf (auth, len);
> +}
> +
> +#endif /* !defined(HAVE_ARC4RANDOM_BUF) */
> +
> +/*
> + * MIT-MAGIC-COOKIE-1 is a sample authentication method implemented by
> + * the SI.  It is not part of standard ICElib.
> + */
> +
> +
> +char *
> +IceGenerateMagicCookie (
> + int len
> +)
> +{
> +char*auth;
> +
> +if ((auth = malloc (len + 1)) == NULL)
> + return (NULL);
> +
> +arc4random_buf (auth, len);
> +
>  auth[len] = '\0';
>  return (auth);
>  }
> -- 
> 2.9.3
> 
> 
___
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 2/2 v3] Add keyboard shortcuts inhibitor

[Olivier Fourdan]

This adds a new protocol to let Wayland clients specify that they want
all keyboard events to be send to the client, regardless of the
compositor own shortcuts.

This is for use by virtual machine and remote connections viewers.

Signed-off-by: Olivier Fourdan 
---
 v2: Clarify that that the compositor is under no obligation to ignore
 every shortcut (ajax)
 Add "inhibit_active" and "inhibit_inactive" events to notify clients
 Add "already_inhibited" error
 v3: Rename "inhibit_active" and "inhibit_inactive" events to simply
 "active" and "inactive" and fix some Tab in the middle of the text.

 Makefile.am|   1 +
 unstable/keyboard-shortcuts-inhibit/README |   4 +
 .../keyboard-shortcuts-inhibit-unstable-v1.xml | 132 +
 3 files changed, 137 insertions(+)
 create mode 100644 unstable/keyboard-shortcuts-inhibit/README
 create mode 100644 
unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 12465e6..d100c13 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -13,6 +13,7 @@ unstable_protocols =  
\
unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
\
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml  
\
unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml  
\
+   
unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/keyboard-shortcuts-inhibit/README 
b/unstable/keyboard-shortcuts-inhibit/README
new file mode 100644
index 000..63ff335
--- /dev/null
+++ b/unstable/keyboard-shortcuts-inhibit/README
@@ -0,0 +1,4 @@
+Compositor shortcuts inhibit protocol
+
+Maintainers:
+Olivier Fourdan 
diff --git 
a/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
 
b/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
new file mode 100644
index 000..bb35de1
--- /dev/null
+++ 
b/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
@@ -0,0 +1,132 @@
+
+
+
+  
+   Copyright © 2017 Red Hat Inc.
+
+   Permission is hereby granted, free of charge, to any person obtaining a
+   copy of this software and associated documentation files (the 
"Software"),
+   to deal in the Software without restriction, including without 
limitation
+   the rights to use, copy, modify, merge, publish, distribute, sublicense,
+   and/or sell copies of the Software, and to permit persons to whom the
+   Software is furnished to do so, subject to the following conditions:
+
+   The above copyright notice and this permission notice (including the 
next
+   paragraph) shall be included in all copies or substantial portions of 
the
+   Software.
+
+   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
OR
+   IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+   FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+   THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
OTHER
+   LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+   FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+   DEALINGS IN THE SOFTWARE.
+  
+
+  
+   This protocol specifies a way for a client to request the compositor
+   to ignore its own keyboard shortcuts, so that all keyboard events
+   get forwarded to a surface.
+
+   Warning! The protocol described in this file is experimental and
+   backward incompatible changes may be made. Backward compatible
+   changes may be added together with the corresponding interface
+   version bump.
+   Backward incompatible changes are done by bumping the version
+   number in the protocol and interface names and resetting the
+   interface version. Once the protocol is to be declared stable,
+   the 'z' prefix and the version number in the protocol and
+   interface names are removed and the interface version number is
+   reset.
+  
+
+  
+
+
+  
+   Destroy the keyboard shortcuts inhibitor manager.
+  
+
+
+
+  
+   Create a new keyboard shortcuts inhibitor object associated with the 
given surface.
+
+   If shortcuts are already inhibited for the given surface, a protocol 
error
+   "already_inhibited" is raised by the compositor.
+  
+  
+  
+
+
+  
+
+  
+
+   A keyboard shortcuts inhibitor instructs the compositor to ignore
+   its own keyboard shortcuts when the associated surface has keyboard
+   focus. As a result, when the surface is focused, it will receive 

[PATCH 1/2 v3] Introduce keyboard grabbing protocol for Xwayland

[Olivier Fourdan]

This patch introduces a new protocol for grabbing the keyboard from
Xwayland.

This is needed for X11 applications that map an override redirect window
(thus not focused by the window manager) and issue an active grab on the
keyboard to capture all keyboard events.

Signed-off-by: Olivier Fourdan 
---
 v2: there is no v2, I just want to keep a numbering scheme consistent :p
 v3: Reword the protocol summary as per whot's review
 Mention that compositors are required to restrict access to Xwayland
 Reword the "grab_keyboard" description s per whot's comments
 Move a leftover out from the Makefile.am as spotted by Emil

 Makefile.am|   1 +
 unstable/xwayland-keyboard-grab/README |   4 +
 .../xwayland-keyboard-grab-unstable-v1.xml | 121 +
 3 files changed, 126 insertions(+)
 create mode 100644 unstable/xwayland-keyboard-grab/README
 create mode 100644 
unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index e693afa..12465e6 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -12,6 +12,7 @@ unstable_protocols =  
\
unstable/tablet/tablet-unstable-v2.xml  
\
unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
\
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml  
\
+   unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml  
\
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/xwayland-keyboard-grab/README 
b/unstable/xwayland-keyboard-grab/README
new file mode 100644
index 000..dbe45a5
--- /dev/null
+++ b/unstable/xwayland-keyboard-grab/README
@@ -0,0 +1,4 @@
+Xwayland keyboard grabbing protocol
+
+Maintainers:
+Olivier Fourdan 
diff --git 
a/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml 
b/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml
new file mode 100644
index 000..6abe854
--- /dev/null
+++ b/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml
@@ -0,0 +1,121 @@
+
+
+
+  
+   Copyright © 2017 Red Hat Inc.
+
+   Permission is hereby granted, free of charge, to any person obtaining a
+   copy of this software and associated documentation files (the 
"Software"),
+   to deal in the Software without restriction, including without 
limitation
+   the rights to use, copy, modify, merge, publish, distribute, sublicense,
+   and/or sell copies of the Software, and to permit persons to whom the
+   Software is furnished to do so, subject to the following conditions:
+
+   The above copyright notice and this permission notice (including the 
next
+   paragraph) shall be included in all copies or substantial portions of 
the
+   Software.
+
+   THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
OR
+   IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+   FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+   THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
OTHER
+   LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+   FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+   DEALINGS IN THE SOFTWARE.
+  
+
+  
+   This protocol is application-specific to meet the needs of the X11
+   protocol through Xwayland. It provides a way for Xwayland to request
+   all keyboard events to be forwarded to a surface even when the
+   surface does not have keyboard focus.
+
+   In the X11 protocol, a client may request an "active grab" on the
+   keyboard. On success, all key events are reported only to the
+   grabbing X11 client. For details, see XGrabKeyboard(3).
+
+   The core Wayland protocol does not have a notion of an active
+   keyboard grab. When running in Xwayland, X11 applications may
+   acquire an active grab inside Xwayland but that cannot be translated
+   to the Wayland compositor who may set the input focus to some other
+   surface. In doing so, it breaks the X11 client assumption that all
+   key events are reported to the grabbing client.
+
+   This protocol specifies a way for Xwayland to request all keyboard
+   be directed to the given surface. The protocol does not guarantee
+   that the compositor will honor this request and it does not
+   prescribe user interfaces on how to handle the respond. For example,
+   a compositor may inform the user that all key events are now
+   forwarded to the given client surface, or it may ask the user for
+   permission to do so.
+
+   Compositors are required to restrict access to this application