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

2017-03-31 Thread Eric Anholt 
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.


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: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD

2017-03-31 Thread Manasi Navare 
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.

Regards
Manasi

___
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

2017-03-31 Thread Eric Anholt 
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?


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: [PATCH 2/2 v2] Add keyboard shortcuts inhibitor

2017-03-31 Thread Michael Thayer 

Hello Olivier,

I won't add a reviewed-by as I have not yet touched Wayland much, but 
for VirtualBox (host parts) this actually looks better than X11 keyboard 
grabbing on first glance.


Regards
Michael

31.03.2017 17:31, Olivier Fourdan wrote:

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

 unstable/keyboard-shortcuts-inhibit/README |   4 +
 .../keyboard-shortcuts-inhibit-unstable-v1.xml | 133 +
 2 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/unstable/keyboard-shortcuts-inhibit/README 
b/unstable/keyboard-shortcuts-inhibit/README
new file mode 100644
index 000..929959c
--- /dev/null
+++ b/unstable/keyboard-shortcuts-inhibit/README
@@ -0,0 +1,4 @@
+Compositor shortcut 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..7a2b919
--- /dev/null
+++ 
b/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
@@ -0,0 +1,133 @@
+
+
+
+  
+   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 all
+   keyboard events, even those which would normally be caught by the
+   compositor for its own shortcuts.
+
+   The Wayland compositor is however under no obligation to disable
+   all of its shortcuts, and may keep some special key combo for its own
+   use, including but not limited to one allowing the user to forcibly
+   restore normal keyboard events routing in the case of an unwilling
+   client.
+
+   If the surface is destroyed, unmapped, or loses keyboard focus, the
+   the compositor will restore its own keyboard shortcuts.
+
+

Re: [PATCH rendercheck v3 4/4] Explain how to build using meson in the README.

2017-03-31 Thread Emil Velikov 
On 31 March 2017 at 15:47, Emil Velikov  wrote:
> On 31 March 2017 at 14:25, Eric Engestrom  wrote:
>> On Wednesday, 2017-03-29 13:19:35 -0700, Eric Anholt wrote:
>>> Signed-off-by: Eric Anholt 
>>> ---
>>>  README | 8 
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/README b/README
>>> index f5af0b0c64eb..2f8ec1ab0e46 100644
>>> --- a/README
>>> +++ b/README
>>> @@ -10,3 +10,11 @@ Tests currently include:
>>>  - Linear gradients
>>>  - Repeating sources/masks at POT and non-POT sizes
>>>  - Some regression tests for bugs from freedesktop.org bugzilla.
>>> +
>>> +rendercheck uses the Meson build system, which uses the "ninja" build
>>> +backend on Linux.  The three commands to configure (building into the
>>> +build/ directory), build, and install are:
>>> +
>>> +meson build
>>> +ninja -C build
>>> +sudo ninja -C build install
>>
>> s,build,build/, on all three lines, to make it clear this is the dir
>> name, not some target?
>>
> That or save yourself some typing and use the following.
>
> meson build && cd build
If you've done OOT builds with autotools/cmake the following is even
more idiomatic

mkdir build && cd build
meson ..

Pardon, if it comes too much ;-)

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 2/2 v2] Add keyboard shortcuts inhibitor

2017-03-31 Thread 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

 unstable/keyboard-shortcuts-inhibit/README |   4 +
 .../keyboard-shortcuts-inhibit-unstable-v1.xml | 133 +
 2 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/unstable/keyboard-shortcuts-inhibit/README 
b/unstable/keyboard-shortcuts-inhibit/README
new file mode 100644
index 000..929959c
--- /dev/null
+++ b/unstable/keyboard-shortcuts-inhibit/README
@@ -0,0 +1,4 @@
+Compositor shortcut 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..7a2b919
--- /dev/null
+++ 
b/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
@@ -0,0 +1,133 @@
+
+
+
+  
+   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 all
+   keyboard events, even those which would normally be caught by the
+   compositor for its own shortcuts.
+
+   The Wayland compositor is however under no obligation to disable
+   all of its shortcuts, and may keep some special key combo for its own
+   use, including but not limited to one allowing the user to forcibly
+   restore normal keyboard events routing in the case of an unwilling
+   client.
+
+   If the surface is destroyed, unmapped, or loses keyboard focus, the
+   the compositor will restore its own keyboard shortcuts.
+
+   When the compositor restores its own keyboard shortcuts, an
+   "inhibit_inactive" event is emitted to notify the client that the
+   keyboard shortcuts inhibitor is not effectively active for the
+   surface any more, and the client should

Re: [PATCH rendercheck v3 4/4] Explain how to build using meson in the README.

2017-03-31 Thread Emil Velikov 
On 31 March 2017 at 14:25, Eric Engestrom  wrote:
> On Wednesday, 2017-03-29 13:19:35 -0700, Eric Anholt wrote:
>> Signed-off-by: Eric Anholt 
>> ---
>>  README | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/README b/README
>> index f5af0b0c64eb..2f8ec1ab0e46 100644
>> --- a/README
>> +++ b/README
>> @@ -10,3 +10,11 @@ Tests currently include:
>>  - Linear gradients
>>  - Repeating sources/masks at POT and non-POT sizes
>>  - Some regression tests for bugs from freedesktop.org bugzilla.
>> +
>> +rendercheck uses the Meson build system, which uses the "ninja" build
>> +backend on Linux.  The three commands to configure (building into the
>> +build/ directory), build, and install are:
>> +
>> +meson build
>> +ninja -C build
>> +sudo ninja -C build install
>
> s,build,build/, on all three lines, to make it clear this is the dir
> name, not some target?
>
That or save yourself some typing and use the following.

meson build && cd build
ninja
sudo ninja install

Just my 2c.

-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

Re: [PATCH rendercheck v3 4/4] Explain how to build using meson in the README.

2017-03-31 Thread Eric Engestrom 
On Wednesday, 2017-03-29 13:19:35 -0700, Eric Anholt wrote:
> Signed-off-by: Eric Anholt 
> ---
>  README | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/README b/README
> index f5af0b0c64eb..2f8ec1ab0e46 100644
> --- a/README
> +++ b/README
> @@ -10,3 +10,11 @@ Tests currently include:
>  - Linear gradients
>  - Repeating sources/masks at POT and non-POT sizes
>  - Some regression tests for bugs from freedesktop.org bugzilla.
> +
> +rendercheck uses the Meson build system, which uses the "ninja" build
> +backend on Linux.  The three commands to configure (building into the
> +build/ directory), build, and install are:
> +
> +meson build
> +ninja -C build
> +sudo ninja -C build install

s,build,build/, on all three lines, to make it clear this is the dir
name, not some target?

Series is:
Reviewed-by: Eric Engestrom 

> -- 
> 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