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

2017-04-06 Thread Keith Packard 
Michel Dänzer  writes:

> When no such special client (Steam?) is running, the desktop environment
> will try to use the HMD anyway, right? So the expected use case would be
> for the user to start a special client first and only plug in the HMD
> afterwards? That seems a bit inconvenient.

I'd love a better alternative, but this is the best I've come up
with.

Of course, it needn't be the actual VR client, it could be a stub
application that popped open a 'which app would you like to run on the
HMD' chooser of some kind, or even hooks in the desktop system that
managed that.

Suggestions very much encouraged.

-- 
-keith


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 libX11 2/2] nls: Verify Compose at build

2017-04-06 Thread Mihail Konev 
On Thu, Apr 06, 2017 at 09:37:02PM +0300, Ran Benita wrote:
> On Sun, Apr 02, 2017 at 10:27:28PM +0500, Mihail Konev wrote:
> > Signed-off-by: Mihail Konev 
> > ---
> >  nls/Makefile.am | 18 +++---
> >  1 file changed, 11 insertions(+), 7 deletions(-)
> > 
> > diff --git a/nls/Makefile.am b/nls/Makefile.am
> > index 57665fff4282..c0f0d0c7181f 100644
> > --- a/nls/Makefile.am
> > +++ b/nls/Makefile.am
> > @@ -24,7 +24,7 @@ locale.alias: locale.alias.pre
> >  < locale.alias.l1 > locale.alias.l2
> > cat locale.alias.l2 locale.alias.l1 > locale.alias
> >  
> > -compose.dir: compose.dir.pre
> > +compose.dir: compose.dir.pre compose-check
> > $(AM_V_GEN)$(RAWCPP) $(RAWCPPFLAGS) $(CPP_FILES_FLAGS) < 
> > $(srcdir)/compose.dir.pre | $(CPP_SED_MAGIC) > compose.dir.l1
> > $(SED) -e '/^[^#][^  ]*:/s/://' -e '/^[^#].*[].*:/d' \
> >  < compose.dir.l1 > compose.dir.l2
> > @@ -36,12 +36,6 @@ locale.dir: locale.dir.pre
> >  < locale.dir.l1 > locale.dir.l2
> > cat locale.dir.l2 locale.dir.l1 > locale.dir
> >  
> > -if HAVE_PERL
> > -LOG_COMPILER = $(PERL)
> 
> I don't think you should remove this. I have no idea what it does, but
> it seems to have some function:
> https://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=3cdb6c3a1646f670afa03d424ec12ac418181d1e

It's interpreter for $(TESTS) (but now there are none).

> 
> Ran
> 
> > -TESTS = compose-check.pl
> > -endif HAVE_PERL
> > -
> > -
> >  # Per-locale data files
> >  
> >  XI18N_FILES = $(locales:%=%/XI18N_OBJS)
> > @@ -54,3 +48,13 @@ nobase_x11locale_DATA = $(XLC_FILES) $(COMPOSE_FILES)
> >  EXTRA_DIST += $(nobase_x11locale_DATA:%=%.pre)
> >  CLEANFILES += $(nobase_x11locale_DATA)
> >  
> > +# Checks for per-locale data files
> > +
> > +compose-check: $(COMPOSE_FILES)
> > +if HAVE_PERL
> > +   @ $(PERL) $(srcdir)/compose-check.pl
> > +else !HAVE_PERL
> > +   @:
> > +endif !HAVE_PERL
> > +
> > +.PHONY: compose-check
> > -- 
> > 2.9.2
Mihail
[automake]$ echo; grep '[{]ext[}]_LOG_COMPILER[}]' doc/automake.texi -B2 -A17

For tests that match an extension @code{.@var{ext}} listed in
@code{TEST_EXTENSIONS}, you can provide a custom ``test runner'' using
the variable @code{@var{ext}_LOG_COMPILER} (note the upper-case
extension) and pass options in @code{AM_@var{ext}_LOG_FLAGS} and allow
the user to pass options in @code{@var{ext}_LOG_FLAGS}.  It will cause
all tests with this extension to be called with this runner.  For all
tests without a registered extension, the variables @code{LOG_COMPILER},
@code{AM_LOG_FLAGS}, and @code{LOG_FLAGS} may be used.  For example,

@c Keep in sync with parallel-tests-log-compiler-example.sh
@example
TESTS = foo.pl bar.py baz
TEST_EXTENSIONS = .pl .py
PL_LOG_COMPILER = $(PERL)
AM_PL_LOG_FLAGS = -w
PY_LOG_COMPILER = $(PYTHON)
AM_PY_LOG_FLAGS = -v
LOG_COMPILER = ./wrapper-script
AM_LOG_FLAGS = -d
@end example

[libX11] $ grep '$(LOG_COMPILER)' nls/Makefile
LOG_COMPILE = $(LOG_COMPILER) $(AM_LOG_FLAGS) $(LOG_FLAGS)

[libX11]$ grep '$(LOG_COMPILE)' nls/Makefile -B5 -A2
compose-check.pl.log: compose-check.pl
@p='compose-check.pl'; \
b='compose-check.pl'; \
$(am__check_pre) $(LOG_DRIVER) --test-name "$$f" \
--log-file $$b.log --trs-file $$b.trs \
$(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS) $(LOG_DRIVER_FLAGS) 
-- $(LOG_COMPILE) \
"$$tst" $(AM_TESTS_FD_REDIRECT)
.test.log:

___
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

2017-04-06 Thread Michel Dänzer 
On 02/04/17 07:58 AM, Keith Packard wrote:
> 
>  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.

When no such special client (Steam?) is running, the desktop environment
will try to use the HMD anyway, right? So the expected use case would be
for the user to start a special client first and only plug in the HMD
afterwards? That seems a bit inconvenient.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer



signature.asc
Description: OpenPGP digital 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 xserver] xf86_crtc_supports_gamma: Return FALSE if RandR is disabled

2017-04-06 Thread Mariusz Bialonczyk 
On Thu, 6 Apr 2017 15:15:00 +0900
Michel Dänzer  wrote:

> On 06/04/17 12:27 PM, Alex Deucher wrote:
> > 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 
> 
> Thanks, Alex. However, after thinking about this bug and related
> https://bugs.freedesktop.org/show_bug.cgi?id=100294 some more, I suspect
> we might end up needing a different fix.

Tested-by: Mariusz Bialonczyk 

FWIW: the patch indeed fixes the xorg crash

Regarding bug #100294, I've added a photo from monitors, for you to see
what I am talking about:
https://bugs.freedesktop.org/attachment.cgi?id=130733
https://bugs.freedesktop.org/attachment.cgi?id=130734
In the same time the third monitor was constantly black, only cursor
was visible. Moving a window to this screen shows nothing (black) - maybe
the gamma was set to zero, or something like this?

Of course when I did a screenshot from xorg, all is fine:
https://bugs.freedesktop.org/attachment.cgi?id=130735

regards,
-- 
Mariusz Białończyk | xmpp/e-mail: ma...@skyboo.net
http://manio.skyboo.net | https://github.com/manio
___
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 xkbcomp] keycodes: Ignore high keycodes

2017-04-06 Thread Ran Benita 
On Thu, Apr 06, 2017 at 08:14:35PM +0100, Daniel Stone wrote:
> On 6 April 2017 at 19:57, Ran Benita  wrote:
> > I always hoped that Wayland systems could switch to a new keycode file,
> > which uses the full evdev key names (xkbcommon no longer has the 4
> > character limit), and the evdev codes (without the + 8 offset), and
> > aliases for backward compat with existing keymaps. But I guess that
> > would be a lot of pain for little gain.
> 
> Yeah, me too. But by the time we'd encoded the +8 offset in enough
> clients, that boat had already sailed, unfortunately.

Yeah.

> > So this seems like a good idea to me, to move things forward.
> >
> > My only concern about the patch is that I think that it will issue a
> > million warnings if keymaps start to use this? I looked at utils.c (a
> > true relic) and it seems that there is no filtering on these ERROR2 and
> > ACTION2, they just print. Add to that other files which would start to
> > use the new keycodes, and you get more warnings (hopefully not fatal
> > errors).
> >
> > I think a reasonable test plan would be:
> >
> > - Add ~15 new >255 keycodes.
> > - Use them in some symbols file.
> > - Try to load this with a patched xkbcomp.
> > - See that:
> >   - There's not a huge log spam.
> >   - That it actually doesn't fail.
> >
> > Note that I say ~15, because I vaguely remember that there are "allow 10
> > errors then give up" checks in some places.
> 
> Funnily, that's exactly what I did. And yeah, it does spam a lot more
> warnings, but there are already 46 lines of warnings spat out by
> xkbcomp just building a plain evdev/us keymap. I made sure that
> they're not errors though, so the number doesn't matter. Just to be
> doubly safe, I bumped it up to 16 new keycodes, and it worked fine,
> warnings notwithstanding. I could tune the WARNs down to INFO, but it
> already warns for things like no symbols defined for a given key, so
> ...

Good enough for me!

I think we should first hear if Sergey would even accept >255 keycodes
in xkeyboard-config keymaps which are shared with X11 (once this patch
is applied and sufficient time has passed). But regardless:

Reviewed-by: Ran Benita 

Ran
___
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 xkbcomp] keycodes: Ignore high keycodes

2017-04-06 Thread Daniel Stone 
Hi Ran,

On 6 April 2017 at 19:57, Ran Benita  wrote:
> On Thu, Apr 06, 2017 at 05:37:28PM +0100, Daniel Stone wrote:
>> Rather than throwing a fatal error when a keycode definition exceeds the
>> declared maximum (i.e. 255), just ignore the definition and continue.
>>
>> This allows xkeyboard-config to start shipping datasets including high
>> keycodes, which will work in xkbcommon as it ignores explicit range
>> declarations.
>
> I always hoped that Wayland systems could switch to a new keycode file,
> which uses the full evdev key names (xkbcommon no longer has the 4
> character limit), and the evdev codes (without the + 8 offset), and
> aliases for backward compat with existing keymaps. But I guess that
> would be a lot of pain for little gain.

Yeah, me too. But by the time we'd encoded the +8 offset in enough
clients, that boat had already sailed, unfortunately.

> So this seems like a good idea to me, to move things forward.
>
> My only concern about the patch is that I think that it will issue a
> million warnings if keymaps start to use this? I looked at utils.c (a
> true relic) and it seems that there is no filtering on these ERROR2 and
> ACTION2, they just print. Add to that other files which would start to
> use the new keycodes, and you get more warnings (hopefully not fatal
> errors).
>
> I think a reasonable test plan would be:
>
> - Add ~15 new >255 keycodes.
> - Use them in some symbols file.
> - Try to load this with a patched xkbcomp.
> - See that:
>   - There's not a huge log spam.
>   - That it actually doesn't fail.
>
> Note that I say ~15, because I vaguely remember that there are "allow 10
> errors then give up" checks in some places.

Funnily, that's exactly what I did. And yeah, it does spam a lot more
warnings, but there are already 46 lines of warnings spat out by
xkbcomp just building a plain evdev/us keymap. I made sure that
they're not errors though, so the number doesn't matter. Just to be
doubly safe, I bumped it up to 16 new keycodes, and it worked fine,
warnings notwithstanding. I could tune the WARNs down to INFO, but it
already warns for things like no symbols defined for a given key, so
...

Cheers,
Daniel
___
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 xkbcomp] keycodes: Ignore high keycodes

2017-04-06 Thread Ran Benita 
On Thu, Apr 06, 2017 at 05:37:28PM +0100, Daniel Stone wrote:
> Rather than throwing a fatal error when a keycode definition exceeds the
> declared maximum (i.e. 255), just ignore the definition and continue.
> 
> This allows xkeyboard-config to start shipping datasets including high
> keycodes, which will work in xkbcommon as it ignores explicit range
> declarations.

I always hoped that Wayland systems could switch to a new keycode file,
which uses the full evdev key names (xkbcommon no longer has the 4
character limit), and the evdev codes (without the + 8 offset), and
aliases for backward compat with existing keymaps. But I guess that
would be a lot of pain for little gain.

So this seems like a good idea to me, to move things forward.

My only concern about the patch is that I think that it will issue a
million warnings if keymaps start to use this? I looked at utils.c (a
true relic) and it seems that there is no filtering on these ERROR2 and
ACTION2, they just print. Add to that other files which would start to
use the new keycodes, and you get more warnings (hopefully not fatal
errors).

I think a reasonable test plan would be:

- Add ~15 new >255 keycodes.
- Use them in some symbols file.
- Try to load this with a patched xkbcomp.
- See that:
  - There's not a huge log spam.
  - That it actually doesn't fail.

Note that I say ~15, because I vaguely remember that there are "allow 10
errors then give up" checks in some places.

Ran
___
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 libX11 0/2] Verify Compose at build

2017-04-06 Thread Ran Benita 
On Sun, Apr 02, 2017 at 10:27:26PM +0500, Mihail Konev wrote:
> This performs verification "on change", and prints errors out.
> 
> Before, it was "make check; cat nls/test-suite.log".

Sounds like a good idea to me, to catch mistakes early.

I left a comment on the second patch; with that fixed:

Reviewed-by: Ran Benita 
___
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 libX11 2/2] nls: Verify Compose at build

2017-04-06 Thread Ran Benita 
On Sun, Apr 02, 2017 at 10:27:28PM +0500, Mihail Konev wrote:
> Signed-off-by: Mihail Konev 
> ---
>  nls/Makefile.am | 18 +++---
>  1 file changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/nls/Makefile.am b/nls/Makefile.am
> index 57665fff4282..c0f0d0c7181f 100644
> --- a/nls/Makefile.am
> +++ b/nls/Makefile.am
> @@ -24,7 +24,7 @@ locale.alias: locale.alias.pre
>  < locale.alias.l1 > locale.alias.l2
>   cat locale.alias.l2 locale.alias.l1 > locale.alias
>  
> -compose.dir: compose.dir.pre
> +compose.dir: compose.dir.pre compose-check
>   $(AM_V_GEN)$(RAWCPP) $(RAWCPPFLAGS) $(CPP_FILES_FLAGS) < 
> $(srcdir)/compose.dir.pre | $(CPP_SED_MAGIC) > compose.dir.l1
>   $(SED) -e '/^[^#][^  ]*:/s/://' -e '/^[^#].*[].*:/d' \
>  < compose.dir.l1 > compose.dir.l2
> @@ -36,12 +36,6 @@ locale.dir: locale.dir.pre
>  < locale.dir.l1 > locale.dir.l2
>   cat locale.dir.l2 locale.dir.l1 > locale.dir
>  
> -if HAVE_PERL
> -LOG_COMPILER = $(PERL)

I don't think you should remove this. I have no idea what it does, but
it seems to have some function:
https://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=3cdb6c3a1646f670afa03d424ec12ac418181d1e

Ran

> -TESTS = compose-check.pl
> -endif HAVE_PERL
> -
> -
>  # Per-locale data files
>  
>  XI18N_FILES = $(locales:%=%/XI18N_OBJS)
> @@ -54,3 +48,13 @@ nobase_x11locale_DATA = $(XLC_FILES) $(COMPOSE_FILES)
>  EXTRA_DIST += $(nobase_x11locale_DATA:%=%.pre)
>  CLEANFILES += $(nobase_x11locale_DATA)
>  
> +# Checks for per-locale data files
> +
> +compose-check: $(COMPOSE_FILES)
> +if HAVE_PERL
> + @ $(PERL) $(srcdir)/compose-check.pl
> +else !HAVE_PERL
> + @:
> +endif !HAVE_PERL
> +
> +.PHONY: compose-check
> -- 
> 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: [PATCH util/modular] xorg.modules: Update for mesonic rendercheck

2017-04-06 Thread Eric Anholt 
Jon Turney  writes:

> Signed-off-by: Jon Turney 

Tested and pushed.  Thanks!


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-04-06 Thread Manasi Navare 
On Sun, Apr 02, 2017 at 07:21:09PM -0700, Eric Anholt wrote:
> Daniel Vetter  writes:
> 
> > 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.
> 
> So in that case you do need userspace to re-request the same mode at the
> same bpp?

Hi Eric,

Yes so we do need userspace to re-request the same mode at the same bpp/pixel 
rate.
Kernel will try that at that bpp or lower it. Its fully in kernel's control.
If it fails then the atomic_check phase will return a failure and in that case
the Gnome/KDE will have to do a full reprobe.

Eric, do you have any more concerns about this patch or can this be pushed to 
Xserver?

Its critical for thsi patch to be pushed to Xserver so that the entire Gfx 
stack can handle
link failures and we can see some of the bugs going away.

Regards
Manasi

> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-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 xkbcomp] keycodes: Ignore high keycodes

2017-04-06 Thread Daniel Stone 
Rather than throwing a fatal error when a keycode definition exceeds the
declared maximum (i.e. 255), just ignore the definition and continue.

This allows xkeyboard-config to start shipping datasets including high
keycodes, which will work in xkbcommon as it ignores explicit range
declarations.

Signed-off-by: Daniel Stone 
Reported-by: Christian Kellner 
---
 keycodes.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/keycodes.c b/keycodes.c
index 22d9eae..e692bf7 100644
--- a/keycodes.c
+++ b/keycodes.c
@@ -330,10 +330,10 @@ AddKeyName(KeyNamesInfo * info,
 
 if ((kc < info->effectiveMin) || (kc > info->effectiveMax))
 {
-ERROR2("Illegal keycode %d for name <%s>\n", kc, name);
+WARN2("Illegal keycode %d for name <%s>\n", kc, name);
 ACTION2("Must be in the range %d-%d inclusive\n",
 info->effectiveMin, info->effectiveMax);
-return False;
+return True;
 }
 if (kc < info->computedMin)
 info->computedMin = kc;
@@ -589,10 +589,10 @@ HandleKeycodeDef(KeycodeDef * stmt, unsigned merge, 
KeyNamesInfo * info)
 code = result.ival;
 if ((code < info->effectiveMin) || (code > info->effectiveMax))
 {
-ERROR2("Illegal keycode %d for name <%s>\n", code, stmt->name);
+WARN2("Illegal keycode %d for name <%s>\n", code, stmt->name);
 ACTION2("Must be in the range %d-%d inclusive\n",
 info->effectiveMin, info->effectiveMax);
-return 0;
+return 1;
 }
 if (stmt->merge != MergeDefault)
 {
-- 
2.12.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: voting confirmation

2017-04-06 Thread Alan Coopersmith 

On 04/ 6/17 07:39 AM, Antoine Martin wrote:

Hi,

Apologies for sending an image link to this list, but I can't think of a
better way to explain the somewhat confusing page that showed up after I
cast my ballot:
http://imgur.com/r8nSblg
Did it take my vote into account? Did I actually vote? And not for "".
I had agreed to the changed membership agreement, but again it shows "".


The output is confusing, but it's trying to show you a multi-paragraph
quote listing the entire ballot question it recorded your vote for, so
it's not "" but "\n\n".

--
-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: voting confirmation

2017-04-06 Thread Alex Deucher 
On Thu, Apr 6, 2017 at 10:39 AM, Antoine Martin  wrote:
> Hi,
>
> Apologies for sending an image link to this list, but I can't think of a
> better way to explain the somewhat confusing page that showed up after I
> cast my ballot:
> http://imgur.com/r8nSblg
> Did it take my vote into account? Did I actually vote? And not for "".
> I had agreed to the changed membership agreement, but again it shows "".

Yes, the votes were cast properly.

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

voting confirmation

2017-04-06 Thread Antoine Martin 
Hi,

Apologies for sending an image link to this list, but I can't think of a
better way to explain the somewhat confusing page that showed up after I
cast my ballot:
http://imgur.com/r8nSblg
Did it take my vote into account? Did I actually vote? And not for "".
I had agreed to the changed membership agreement, but again it shows "".

Cheers
Antoine
___
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

2017-04-06 Thread Michel Dänzer 
On 06/04/17 12:27 PM, Alex Deucher wrote:
> 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 

Thanks, Alex. However, after thinking about this bug and related
https://bugs.freedesktop.org/show_bug.cgi?id=100294 some more, I suspect
we might end up needing a different fix.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
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