Re: [PATCH xserver] present: Only send PresentCompleteNotify events to the presenting client

2017-10-20 Thread Keith Packard 
"Keith Packard"  writes:

> I'm *not* saying this isn't a good patch in practice, I just want to
> understand whether the system was designed wrong, or if we've
> implemented it wrong.

I spent some time this afternoon on IRC chatting with Pierre-Loup. Valve
has an application (vrcompositor in 'extended' mode) which is using
multiple display connections and selecting for Present events on all of
them. I thought for a while that this was doing precisely what we didn't
think reasonable -- expecting PresentCompleteNotify events generated
from a PresentPixmap request sent by client 'A' to be delivered via an
event selection by client 'B'. Nope, they're using the Vulkan
presentation API (which eventually sends PresentPixmap) on connection
'A', and PresentNotifyMSC on connection 'B'. The only events connection
'B' is interested in are those generated by the PresentNotifyMSC, not
those generated by the PresentPixmap sent on connection 'A'.

Thinking about this some more, I believe we can look at CopyArea and
GraphicsExposure events as a good analog -- in that case, the
GraphicsExposure events are *only* delivered to the client who sent the
CopyArea request. I think the Present extension is badly designed in
this area; it shouldn't have bothered to place event selection on the
window, and should have instead made it part of the generating request,
just like CopyArea does (well, it's part of the GC state, which is
effectively part of the request, not part of the drawable state).

I think we should still figure out why the application was failing, but
I'm more in favor of changing the implementation to deliver events only
to the client submitting the request which caused them to be generated.

-- 
-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: [PATCH xserver] present: Only send PresentCompleteNotify events to the presenting client

2017-10-20 Thread Keith Packard 
Giuseppe Bilotta  writes:

> Potentially stupid question, but any chances that some “higher level”
> clients (window manager, screensaver) might be interested in the other
> clients' notifications?

Well, Present isn't the only way to perform this operation, so anything
trying to do this is going to be disappointed if it expect it to work
for a wide range of applications.

I think the only case where it might be interesting is where an
application is trying to coordinate some rendering activity across
multiple X display connections.

-- 
-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: [PATCH] Add NonDesktop output property and behaviors.

2017-10-20 Thread Keith Packard 
Giuseppe Bilotta  writes:

> (Alternatively, one could lease that output and then maybe start an X
> server just for it, but that seems a bit … overkill?)

Oh, that's a completely plausible plan. Yes, that would work and would
offer a completely separate environment for the other device. X servers
aren't exactly heavy weight these days, especially compared with other
elements of a typical desktop.

I don't think it's crazy at all.

-- 
-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: [PATCH] Add NonDesktop output property and behaviors.

2017-10-20 Thread Keith Packard 
Giuseppe Bilotta  writes:

> (Still, I've been fancying the idea of dynamic X Screens for a while
> now, and the use case I mentioned seemed to fit the bill pretty
> nicely.)

Yes it does. When you have two or three years to spare, let us know!

-- 
-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: [PATCH xserver] present: Only send PresentCompleteNotify events to the presenting client

2017-10-20 Thread Giuseppe Bilotta 
On Fri, Oct 20, 2017 at 6:30 PM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> We were sending the events to all clients listening for them on the
> window. But clients can get confused by events from another client, and
> I can't imagine any case where reciving events from other clients would
> be required.

Potentially stupid question, but any chances that some “higher level”
clients (window manager, screensaver) might be interested in the other
clients' notifications?
___
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] configure.ac: unconditionally enable kdrive

2017-10-20 Thread Giuseppe Bilotta 
There's only one kdrive DDX now, Xephyr, which is controlled by its own
--enable-xephyr. Remove the conditional enabling of kdrive, which only
caused confusion (e.g. both --enable-xephyr and --enable-kdrive were
needed to be able to build Xephyr).

Suggested-by: Adam Jackson 

Signed-off-by: Giuseppe Bilotta 
---
 configure.ac | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index ec98f52c0..caf10dc98 100644
--- a/configure.ac
+++ b/configure.ac
@@ -594,7 +594,6 @@ AC_ARG_ENABLE(standalone-xpbproxy, 
AS_HELP_STRING([--enable-standalone-xpbproxy]
 AC_ARG_ENABLE(xwin,  AS_HELP_STRING([--enable-xwin], [Build 
XWin server (default: auto)]), [XWIN=$enableval], [XWIN=auto])
 AC_ARG_ENABLE(glamor, AS_HELP_STRING([--enable-glamor], [Build glamor 
dix module (default: auto)]), [GLAMOR=$enableval], [GLAMOR=auto])
 dnl kdrive and its subsystems
-AC_ARG_ENABLE(kdrive, AS_HELP_STRING([--enable-kdrive], [Build kdrive 
servers (default: no)]), [KDRIVE=$enableval], [KDRIVE=no])
 AC_ARG_ENABLE(xephyr, AS_HELP_STRING([--enable-xephyr], [Build the 
kdrive Xephyr server (default: auto)]), [XEPHYR=$enableval], [XEPHYR=auto])
 dnl kdrive options
 AC_ARG_ENABLE(libunwind,  AS_HELP_STRING([--enable-libunwind], [Use 
libunwind for backtracing (default: auto)]), [LIBUNWIND="$enableval"], 
[LIBUNWIND="auto"])
@@ -2293,6 +2292,10 @@ fi
 AM_CONDITIONAL([DMX_BUILD_USB], [test "x$DMX_BUILD_USB" = xyes])
 
 dnl kdrive DDX
+dnl we now have only one kdrive DDX, which is Xephyr, so we enable kdrive
+dnl unconditionally, and Xephyr will be enabled or not depending on whether
+dnl the required libs are available or not
+KDRIVE=yes
 
 XEPHYR_LIBS=
 XEPHYR_INCS=
-- 
2.14.1.439.g647b9b4702

___
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] present: Only send PresentCompleteNotify events to the presenting client

2017-10-20 Thread Keith Packard 
Michel Dänzer  writes:

> From: Michel Dänzer 
>
> We were sending the events to all clients listening for them on the
> window. But clients can get confused by events from another client, and
> I can't imagine any case where reciving events from other clients would
> be required.

While I agree that it's unlikely to be useful to send the event to all
listening clients, there is a 'PRESENTEVENTID' in the CompleteNotify
which clients "should" be using to check to see if the event being
delivered is the one associated with their action.

Did we mess up in some client library and not do this? If so, we might
want to fix that library?

I'm *not* saying this isn't a good patch in practice, I just want to
understand whether the system was designed wrong, or if we've
implemented it wrong.

-- 
-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: [PATCH] Add NonDesktop output property and behaviors.

2017-10-20 Thread Keith Packard 
Aaron Plattner  writes:

> I think this makes sense. Comments below.
>
> Reviewed-by: Aaron Plattner 

Thanks, Aaron. Have you also looked at the leasing changes on the same
branch? I'd like to know what you think of that plan for implementing
the Vulkan acquire Xlib display extension. I've got code which uses it,
but I'd like to know if that's something you might also be able to
implement in your environment. With those two pieces, I'd be able to
finish version 1.6.

> I don't think a separate NonDesktop connection state property is
> needed.  I agree that you can infer that from the presence of an EDID
> and modes.

To take the other side of this argument, in reviewing the contents of an
RRGetOutputInfo reply, I don't think any of those values are 100%
reliable in telling whether something is connected or not. You can
create and assign modes to a disconnected output, and there are no
properties guaranteed to be set.

Of course, it's rare these days for people to create their own modes and
assign them. We still have many cases where monitors fail to provide
EDID data, and I wonder if that won't be more common for some things
that we do want to hide from the normal desktop? Hrm. Now I'm thinking
that just having a property which gets set wouldn't be a terrible plan.

Thoughts?

> Add a period at the end of this sentence (and a couple below), maybe?

Thanks, just a cut error.

> Giuseppe, I'm not sure I understand your suggestion about "attached" and 
> "detached" modes here. I.e. what exactly would a driver do in response 
> to a client writing this property? If you just want to switch between 
> being part of the desktop and not, you can do that by attaching or 
> detaching it from a crtc.

I think the goal was to have it controlled through the X server, but not
play a part of the larger desktop.

> The motivation here is that a client would use this output through some 
> other non-X API. Specifically Vulkan direct-to-display for virtual 
> reality. So X wouldn't be configured to drive this output with a crtc. 
> Instead, it would lease the output and a crtc to the client for its 
> direct use.

That's certainly our current motivation; we need to be careful to not
design-out other possible uses, while at the same time not
over-designing the solution. Nothing in this proposal makes it
impossible for an application to use X to drive this extra output, it's
just not the motivation at present.

And, I agree that there's no particular need to write this property to
get the output to not appear in the desktop; the existing 'Monitor'
mechanism is sufficient for this.

Having it writable opens a huge question of how you would revert back to
device control from user control; we'd have to add *another* boolean
that would flip the value from 'device controlled' to 'user
overridden'. And that's more complexity than we should be doing at this
point; it's pretty obvious to me that we can do this in the future if it
becomes necessary.

-- 
-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: [PATCH] Add NonDesktop output property and behaviors.

2017-10-20 Thread Giuseppe Bilotta 
On Fri, Oct 20, 2017 at 6:08 PM, Keith Packard  wrote:
> Giuseppe Bilotta  writes:
>
>> (I actually wish I had some free time to put my coding hands where my
>> mouth is 8-P).
>
> I'd say it's more about waiting until we find a situation that actually
> requires the additional work. Right now, the goal is to make a leased
> output never part of the desktop, and that's where the current design is
> focused. If we find a real use for doing something more complicated
> later, we'll figure it out then.

I see. From Aaron's clarification I got that the idea is to either not
use the output via X (and thus only use X to get the lease), or if
it's to be used via X it should be done via the standard RANDR
management. Basically, the usage I was thinking of (using the output
from within X, but outside of the default X Screen), isn't being
contemplated.

> X has a long history of having systems designed in advance of their need
> and having that make things harder in the future, rather than easier...

I'll trust you on that 8-)

(Still, I've been fancying the idea of dynamic X Screens for a while
now, and the use case I mentioned seemed to fit the bill pretty
nicely.)

-- 
Giuseppe "Oblomov" Bilotta
___
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] Add NonDesktop output property and behaviors.

2017-10-20 Thread Giuseppe Bilotta 
On Fri, Oct 20, 2017 at 8:35 PM, Aaron Plattner  wrote:
>
> From Giuseppe:
>>
>> For the aforementioned touchpad/display, for example, one could envision
>> a “detached” mode where it acts like, say, the Apple Touch Bar, and an
>> “attached” mode where it's used like a standard display, for example to
>> show a zoomed area around the cursor. Achieving this would require this
>> properly to be mutable though.
>
> Giuseppe, I'm not sure I understand your suggestion about "attached" and
> "detached" modes here. I.e. what exactly would a driver do in response to a
> client writing this property? If you just want to switch between being part
> of the desktop and not, you can do that by attaching or detaching it from a
> crtc.

As I mentioned in my reply to Keith, the driver might change operating
mode. For example, something like the Razer touchpad display would
work in absolute mode (mapped to that specific output) in detached,
and in relative mode otherwise. I'm not sure if the display can be
turned off entirely, but if this is the case one effectively needs
some kind of tri-state (off, external, part of the default X Screen).

> From Giuseppe:
>>
>> It would be interesting to make this an enum allowing
>> different values, so that clients could differentiate between, say, an
>> HMD and a TouchBar. (Maybe instead of RR_PROPERTY_NON_DESKTOP make it a
>> RR_PROPERTY_OUTPUT_USAGE and have values 0 for Desktop, 1 for HMD, 2 for
>> TouchSomething (could be the Apple thing or the Razer thing)?
>
> I agree with Keith that this should remain a simple boolean since you can
> infer the type of the device from the EDID. Trying to specify an enum here
> just opens the door to being inconsistent, and the list always being out of
> date and too restrictive when new types of devices show up.

That's a pretty solid reason. The only downside is that getting the
EDID isn't trivial in scripts (but that can be solved extending the
xrandr tool, for example).

> From Giuseppe:
>>
>> I'm having troubles wrapping my mind around how exactly this works,
>> particularly in relation to the root window framebuffer, and about how
>> (or rather if) this can be achieved while still granting X clients
>> access to the output, even if just in an ‘as needed’ use case (i.e. not
>> as part of the “normal” operating mode).
>
>
> The motivation here is that a client would use this output through some
> other non-X API. Specifically Vulkan direct-to-display for virtual reality.
> So X wouldn't be configured to drive this output with a crtc. Instead, it
> would lease the output and a crtc to the client for its direct use.

Ah, I see. The WM/DE doesn't use the output because it's marked
disconnected, then a client that wants to use it uses the X API to get
the lease, but then does NOT use X to render on the leased output.
Yes, I agree that for this specific use case it works perfectly fine.

> You could use a similar model for a touch bar thing, where you either drive
> it directly using Vulkan, or tell X to display the X screen on it using
> RandR to set a mode on it. You don't need to be able to write the NonDesktop
> property for that.

The downside of using the touch bar or whatever by extending the X
screen to it is that this would cause the desktop to extend to it. I
was thinking about the case where you wouldn't want the desktop to
extend to it, but still use the X API to render to the output, hence
the multiple X Screen ideas. (For example, I'm not sure if this is
still the case, but some older versions of GIMP for example supported
multiple X Screens relatively smoothly, and you could e.g. have the
toolbars on an X Screen and the main window in another: adding support
for the touch bar would be much simpler than the lease way).

(Alternatively, one could lease that output and then maybe start an X
server just for it, but that seems a bit … overkill?)

-- 
Giuseppe "Oblomov" Bilotta
___
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] modesetting: fail PreInit() if the device has zero connectors

2017-10-20 Thread tobias . jakobi1 
On laptop systems with a dedicated (powerful) GPU A, you usually
have all connectors routed to another (less-powerful) GPU B.

With my setup (GPU A = Nvidia, GPU B = Intel) I keep GPU A switched
off by not loading the nouveau kernel driver during boot.

Loading nouveau while X is running then crashes the server:
[   540.775] (EE) 0: /usr/bin/X (xorg_backtrace+0x41) [0x57fa31]
[   540.775] (EE) 1: /usr/bin/X (0x40+0x183429) [0x583429]
[   540.775] (EE) 2: /lib64/libpthread.so.0 (0x7ff02d508000+0x10ec0) 
[0x7ff02d518ec0]
[   540.775] (EE) 3: /lib64/libc.so.6 (gsignal+0x38) [0x7ff02d1a2178]
[   540.775] (EE) 4: /lib64/libc.so.6 (abort+0x16a) [0x7ff02d1a35fa]
[   540.775] (EE) 5: /lib64/libc.so.6 (0x7ff02d16f000+0x2c0b7) [0x7ff02d19b0b7]
[   540.775] (EE) 6: /lib64/libc.so.6 (0x7ff02d16f000+0x2c162) [0x7ff02d19b162]
[   540.775] (EE) 7: /usr/bin/X (dixRegisterPrivateKey+0x247) [0x452197]
[   540.775] (EE) 8: /usr/lib64/xorg/modules/libglamoregl.so 
(glamor_init+0x160) [0x7ff00ee564d0]
[   540.775] (EE) 9: /usr/lib64/xorg/modules/drivers/modesetting_drv.so 
(0x7ff01c19a000+0x83e1) [0x7ff01c1a23e1]
[   540.775] (EE) 10: /usr/bin/X (AddGPUScreen+0xf3) [0x4348b3]
[   540.775] (EE) 11: /usr/bin/X (0x40+0x90271) [0x490271]
[   540.775] (EE) 12: /usr/bin/X (0x40+0x9547b) [0x49547b]
[   540.775] (EE) 13: /usr/bin/X (0x40+0x905d7) [0x4905d7]
[   540.775] (EE) 14: /usr/bin/X (xf86VTEnter+0x1bb) [0x47399b]
[   540.775] (EE) 15: /usr/bin/X (WakeupHandler+0xda) [0x438e3a]
[   540.775] (EE) 16: /usr/bin/X (WaitForSomething+0x1ce) [0x57d6fe]
[   540.775] (EE) 17: /usr/bin/X (0x40+0x34221) [0x434221]
[   540.775] (EE) 18: /usr/bin/X (0x40+0x382f8) [0x4382f8]
[   540.775] (EE) 19: /lib64/libc.so.6 (__libc_start_main+0xf0) [0x7ff02d18f670]
[   540.776] (EE) 20: /usr/bin/X (_start+0x29) [0x4235b9]

In particular note that GLAMOR is initialized for GPU A, which
makes no sense since it has no connectors.

Fix this by bailing out early in the modesetting DDX when a setup
with zero connectors is detected.

Signed-off-by: Tobias Jakobi 
---
 hw/xfree86/drivers/modesetting/driver.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/hw/xfree86/drivers/modesetting/driver.c 
b/hw/xfree86/drivers/modesetting/driver.c
index 9afb344c8..8a5f63685 100644
--- a/hw/xfree86/drivers/modesetting/driver.c
+++ b/hw/xfree86/drivers/modesetting/driver.c
@@ -920,6 +920,12 @@ PreInit(ScrnInfoPtr pScrn, int flags)
 if (!check_outputs(ms->fd, _count))
 return FALSE;
 
+if (!connector_count) {
+xf86DrvMsg(pScrn->scrnIndex, X_INFO,
+   "Device is headless (no connectors available)\n");
+return FALSE;
+}
+
 drmmode_get_default_bpp(pScrn, >drmmode, , );
 if (defaultdepth == 24 && defaultbpp == 24) {
 ms->drmmode.force_24_32 = TRUE;
-- 
2.13.6

___
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 3/3] modesetting: Check crtc before searching link-status property

2017-10-20 Thread Adam Jackson 
On Fri, 2017-10-20 at 10:05 +0200, Daniel Martin wrote:
> No need to lookup the link-status property if we don't have a crtc.

This is the only change I was a little unsure of, but if
drmModeGetProperty has side effects if not called often enough, then I
think we're in trouble already. Merged, thanks!

remote: I: patch #183934 updated using rev 
66d8cbf8ce9285a8771118e46daa44faa73ad847.
remote: I: patch #183935 updated using rev 
8c455db0ebb6e5313ca81428bb6dd75ef12aaa15.
remote: I: patch #183936 updated using rev 
8d7f7e24261e68459e6f0a865e243473f65fe7ad.
remote: I: 3 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   6d7e1d1de0..8d7f7e2426  master -> master

- ajax
___
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 libXau] Avoid out of boundary read access

2017-10-20 Thread Adam Jackson 
On Thu, 2017-10-19 at 15:02 -0700, Alan Coopersmith wrote:
> On 10/19/17 01:18 PM, Tobias Stoeckmann wrote:
> > If the environment variable HOME is empty, XauFileName triggers an
> > out of boundary read access (name[1]). If HOME consists of a single
> > character relative path, the output becomes unexpected, because
> > "HOME=a" leads to "a.Xauthority" instead of "a/.Xauthority". Granted,
> > a relative HOME path leads to trouble in general, the code should
> > properly return "a/.Xauthority" nonetheless.
> > 
> > Signed-off-by: Tobias Stoeckmann 
> > ---
> >   AuFileName.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/AuFileName.c b/AuFileName.c
> > index 37c8b62..2946c80 100644
> > --- a/AuFileName.c
> > +++ b/AuFileName.c
> > @@ -85,6 +85,6 @@ XauFileName (void)
> > bsize = size;
> >   }
> >   snprintf (buf, bsize, "%s%s", name,
> > -  slashDotXauthority + (name[1] == '\0' ? 1 : 0));
> > +  slashDotXauthority + (name[0] == '/' && name[1] == '\0' ? 1 
> > : 0));
> >   return buf;
> >   }
> > 
> 
> Reviewed-by: Alan Coopersmith 

remote: I: patch #183854 updated using rev 
987fee49dc1750082cfe6e24833379233777a13b.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/lib/libXau
   42e152c..987fee4  master -> master

- ajax
___
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] Add NonDesktop output property and behaviors.

2017-10-20 Thread Aaron Plattner 

On 10/19/2017 10:52 AM, Keith Packard wrote:

NonDesktop devices are those to which the normal desktop environment
should not be extended. Examples are Head-mounted displays and the
Apple Touch Bar.

How an output device is set to NonDesktop is not part of this
proposal; it is expected that the underlying operating system will
provide this information and have it reflected to X applications
through this extension.

Signed-off-by: Keith Packard 


I think this makes sense. Comments below.

Reviewed-by: Aaron Plattner 


---
  randrproto.txt | 84 +++---
  1 file changed, 81 insertions(+), 3 deletions(-)

diff --git a/randrproto.txt b/randrproto.txt
index 7312e0b..e717a60 100644
--- a/randrproto.txt
+++ b/randrproto.txt
@@ -186,14 +186,23 @@ 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.

+Version 1.6 adds resource leasing and non desktop output management.
  
- • A 'Lease' is a collection of crtcs and outputs which are made

+ • 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.
  
+ • A “NonDesktop” output is a device which should not normally be

+   considered as part of the desktop environment. Head-mounted
+   displays and the Apple "Touch Bar" are examples of such
+   devices. A desktop environment should be able to discover which
+   outputs are connected to such devices and, by default, not present
+   normal desktop applications on them. This is done by having
+   RRGetOutputInfo report such devices as Disconnected while reporting
+   all other information about the device correctly.


I don't think a separate NonDesktop connection state property is needed. 
I agree that you can infer that from the presence of an EDID and modes.



  1.99 Acknowledgments
  
  Our thanks to the contributors to the design found on the xpert mailing

@@ -764,6 +773,12 @@ dynamic changes in the display environment.
monitor in some way; for fixed-pixel devices, this would generally
indicate which modes match the resolution of the output device.
  
+	Changes in version 1.6 of the protocol:

+
+   When a “NonDesktop” device is connected, the 'connection'
+   field will report Disconnected but the remaining fields will
+   report information about the connected device.
+
  ┌───
  RRListOutputProperties
output:OUTPUT
@@ -775,6 +790,12 @@ dynamic changes in the display environment.
This request returns the atoms of properties currently defined on
the output.
  
+	Changes in version 1.6 of the protocol:

+
+   When a “NonDesktop” device is connected, the property list
+   will be correct for the device, even though RRGetOutputInfo
+   reports the device as disconnected


Add a period at the end of this sentence (and a couple below), maybe?


+
  ┌───
  RRQueryOutputProperty
output: OUTPUT
@@ -806,6 +827,12 @@ dynamic changes in the display environment.
changed by clients. Immutable properties are interpreted by the X
server.
  
+	Changes in version 1.6 of the protocol:

+
+   When a “NonDesktop” device is connected, the property information
+   will be correct for the device, even though RRGetOutputInfo
+   reports the device as disconnected
+
  ┌───
  RRConfigureOutputProperty
output: OUTPUT
@@ -924,6 +951,12 @@ dynamic changes in the display environment.
is True and the bytes-after is zero, the property is also deleted
from the output, and a RROutputPropertyNotify event is generated.
  
+	Changes in version 1.6 of the protocol:

+
+   When a “NonDesktop” device is connected, the property value
+   will be correct for the device, even though RRGetOutputInfo
+   reports the device as disconnected
+
  ┌───
  RRCreateMode
window: WINDOW
@@ -1816,6 +1849,12 @@ factors, such as re-cabling a monitor, etc.
precise change can be detected by examining the new state of the
system.
  
+	Changes in version 1.6 of the protocol:

+
+   When a “NonDesktop” device is connected, this event will be
+   delivered when the connection status of the output changes,
+   however the 'connection' value will be set to 'Disconnected'.
+
  ┌───
  RROutputPropertyNotify:
window: WINDOW  window requesting notification
@@ -1955,6 +1994,13 @@ as long as the semantics are not altered.  Clients 
SHOULD fall back
  gracefully to lower version functionality, though, if the driver
  doesn't handle a mandatory property correctly.
  
+Changes in version 1.6 of the protocol:

+
+When a

Re: [RFC v2 03/12] sync: Move fence destroy call to object specific function

2017-10-20 Thread Adam Jackson 
On Wed, 2017-09-27 at 01:19 -0400, Louis-Francis Ratté-Boulianne wrote:

> @@ -41,11 +41,10 @@ miSyncScreenCreateFence(ScreenPtr pScreen,
> SyncFence * pFence,
>  pFence->triggered = initially_triggered;
>  }
>  
> -void
> -miSyncScreenDestroyFence(ScreenPtr pScreen, SyncFence * pFence)
> +int
> +miSyncGetFenceType(SyncFence *pFence)
>  {
> -(void) pScreen;
> -(void) pFence;
> +return pFence->type;
>  }

This function is not referenced in this commit, even the header decl
isn't present until 4/12. Since this function appears to be unrelated
to the this refactor it should probably be moved into 4/12. (But my
comments on 4/12 itself may make this point moot.)

> @@ -94,7 +101,8 @@ miSyncInitFence(ScreenPtr pScreen, SyncFence *
> pFence, Bool initially_triggered)
>  ,
>  ,
>  ,
> -
> +,
> +
>  };
>  
>  pFence->pScreen = pScreen;

Please use a , even on the last item in a list (yes even though the
original code didn't, it should have).

- ajax
___
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 v2 04/12] sync: Add support for DMA fences

2017-10-20 Thread Adam Jackson 
On Wed, 2017-09-27 at 01:19 -0400, Louis-Francis Ratté-Boulianne wrote:

> @@ -1931,6 +1959,9 @@ ProcSyncTriggerFence(ClientPtr client)
>  if (rc != Success)
>  return rc;
>  
> +if (pFence->type == SYNC_FENCE_DMA)
> +return BadMatch;
> +
>  miSyncTriggerFence(pFence);
>  
>  return Success;

This is a bad pattern, the dispatch code shouldn't need to know
anything about fence types. I think this should instead change
miSyncTriggerFence (and pFence->funcs.SetTriggered) to return a Status,
and have ProcSyncTriggerFence end with 'return miSyncTriggerFence()'.

> @@ -1950,7 +1981,8 @@ ProcSyncResetFence(ClientPtr client)
>  if (rc != Success)
>  return rc;
>  
> -if (pFence->funcs.CheckTriggered(pFence) != TRUE)
> +if (pFence->type == SYNC_FENCE_DMA ||
> +pFence->funcs.CheckTriggered(pFence) != TRUE)
>  return BadMatch;
>  
>  pFence->funcs.Reset(pFence);

Likewise here.

> diff --git a/miext/sync/misync.h b/miext/sync/misync.h
> index b3838f1e2..c32e4c961 100644
> --- a/miext/sync/misync.h
> +++ b/miext/sync/misync.h
> @@ -28,6 +28,10 @@
>  #ifndef _MISYNC_H_
>  #define _MISYNC_H_
>  
> +/* Sync fence types */
> +#define SYNC_FENCE_SHM  0
> +#define SYNC_FENCE_DMA  1
> +
>  typedef struct _SyncFence SyncFence;
>  typedef struct _SyncTrigger SyncTrigger;
>  
> @@ -73,6 +77,9 @@ extern _X_EXPORT SyncScreenFuncsPtr 
> miSyncGetScreenFuncs(ScreenPtr pScreen);
>  extern _X_EXPORT Bool
>   miSyncSetup(ScreenPtr pScreen);
>  
> +extern _X_EXPORT int
> +miSyncGetFenceType(SyncFence * pFence);
> +
>  Bool
>  miSyncFenceCheckTriggered(SyncFence * pFence);
>  

... and ...

> diff --git a/miext/sync/misyncstr.h b/miext/sync/misyncstr.h
> index 2eab2aa57..6d97894f0 100644
> --- a/miext/sync/misyncstr.h
> +++ b/miext/sync/misyncstr.h
> @@ -57,6 +57,7 @@ struct _SyncFence {
>  ScreenPtr pScreen;  /* Screen of this fence object */
>  SyncFenceFuncsRec funcs;/* Funcs for performing ops on fence */
>  Bool triggered; /* fence state */
> +unsigned char type; /* fence type */
>  PrivateRec *devPrivates;/* driver-specific per-fence data */
>  };
>  

... with all that changed, I think you can avoid needing to add the
'type' field and GetFenceType accessor at all.

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

[RFC PATCH] glxvnd: Various fixes

2017-10-20 Thread Kyle Brenneman 
This is a follow-on to the GLXVND patches by Adam Jackson, sent out on
8/30/2017. This still mostly proof-of-concept, but it's enough to at least
build and run.

Fix various compiler warnings.

Fix GlxGetXIDMap so that it calls dixLookupResourceByClass instead of
dixLookupResourceByType.

Update the autotools build system to include the glxvnd files.

In glxvnd, don't skip initializing GLX if the vendor list is empty. The init
callbacks themselves might allocate vendor handles.

Reworked the GLVND vendor initialization functions to work with the full
xfree86 server.

xorgGlxCreateVendor now just registers the xorgGlxServerInit callback with
GLVND. All of the actual initialization is in xorgGlxServerInit.

xorgGlxServerInit now initializes all screens, not just one. It'll go through
the provider stack for each of them.

Added __glXProviderStack and GlxPushProvider back in.
---
 glx/Makefile.am|   6 +-
 glx/glxext.c   | 115 +-
 glx/vnd_dispatch_stubs.c   | 139 -
 glx/vndcmds.c  |   7 ++-
 glx/vndext.c   |  15 +++--
 glx/vndserver.h|   2 +
 glx/vndservermapping.c |   2 +-
 hw/kdrive/ephyr/ephyr.c|   2 +-
 hw/vfb/InitOutput.c|   2 +-
 hw/xfree86/dixmods/glxmodule.c |   1 +
 hw/xquartz/darwin.c|   2 +-
 hw/xwayland/xwayland.c |   2 +-
 hw/xwin/winscrinit.c   |   2 +-
 include/glx_extinit.h  |   2 +-
 14 files changed, 181 insertions(+), 118 deletions(-)

diff --git a/glx/Makefile.am b/glx/Makefile.am
index 699de63..6af56c1 100644
--- a/glx/Makefile.am
+++ b/glx/Makefile.am
@@ -80,6 +80,10 @@ libglx_la_SOURCES = \
 singlesize.h \
 swap_interval.c \
 unpack.h \
-xfont.c
+xfont.c \
+   vndcmds.c \
+   vndext.c \
+   vndservermapping.c \
+   vndservervendor.c
 
 libglx_la_LIBADD = $(DLOPEN_LIBS)
diff --git a/glx/glxext.c b/glx/glxext.c
index 19d83f4..f699ce7 100644
--- a/glx/glxext.c
+++ b/glx/glxext.c
@@ -297,6 +297,15 @@ glxClientCallback(CallbackListPtr *list, void *closure, 
void *data)
 
 //
 
+static __GLXprovider *__glXProviderStack = &__glXDRISWRastProvider;
+
+void
+GlxPushProvider(__GLXprovider * provider)
+{
+provider->next = __glXProviderStack;
+__glXProviderStack = provider;
+}
+
 static Bool
 checkScreenVisuals(void)
 {
@@ -493,62 +502,84 @@ xorgGlxServerPreInit(const ExtensionEntry *extEntry)
 return glxGeneration == serverGeneration;
 }
 
+static GlxServerVendor *glvnd_vendor = NULL;
+
+static GlxServerVendor *
+xorgGlxInitGLVNDVendor(void)
+{
+if (glvnd_vendor == NULL) {
+GlxServerImports *imports = NULL;
+imports = glxServer.allocateServerImports();
+
+if (imports != NULL) {
+imports->extensionCloseDown = xorgGlxCloseExtension;
+imports->handleRequest = xorgGlxHandleRequest;
+imports->getDispatchAddress = xorgGlxGetDispatchAddress;
+imports->makeCurrent = xorgGlxMakeCurrent;
+glvnd_vendor = glxServer.createVendor(imports);
+glxServer.freeServerImports(imports);
+}
+}
+return glvnd_vendor;
+}
+
 static void
 xorgGlxServerInit(CallbackListPtr *pcbl, void *param, void *ext)
 {
 const ExtensionEntry *extEntry = ext;
-xorgVendorInitClosure *closure = param;
-ScreenPtr screen = closure->screen;
-__GLXprovider *p = closure->provider;
-__GLXscreen *s = NULL;
+int i;
 
-if (!xorgGlxServerPreInit(extEntry))
-goto out;
+if (!xorgGlxServerPreInit(extEntry)) {
+return;
+}
+
+if (!xorgGlxInitGLVNDVendor()) {
+return;
+}
 
-if (!(s = p->screenProbe(screen)))
-goto out;
+for (i = 0; i < screenInfo.numScreens; i++) {
+ScreenPtr pScreen = screenInfo.screens[i];
+__GLXprovider *p;
 
-if (!glxServer.setScreenVendor(screen, closure->vendor))
-goto out;
+if (glxServer.getVendorForScreen(NULL, pScreen) != NULL) {
+// There's already a vendor registered.
+LogMessage(X_INFO, "GLX: Another vendor is already registered for 
screen %d\n", i);
+continue;
+}
+
+for (p = __glXProviderStack; p != NULL; p = p->next) {
+__GLXscreen *glxScreen = p->screenProbe(pScreen);
+if (glxScreen != NULL) {
+LogMessage(X_INFO,
+   "GLX: Initialized %s GL provider for screen %d\n",
+   p->name, i);
+break;
+}
 
-out:
-/* XXX chirp on error */
-free(param);
-return;
+}
+
+if (p) {
+glxServer.setScreenVendor(pScreen, glvnd_vendor);
+} else {
+LogMessage(X_INFO,
+   "GLX: no usable GL providers found for screen %d\n",

Re: [PATCH xserver 0/4] meson: Fix DEBUG definition

2017-10-20 Thread Adam Jackson 
On Fri, 2017-10-13 at 15:44 -0400, Lyude Paul wrote:
> At the moment, meson makes the mistake of never defining the DEBUG
> macro, regardless of the current build type. Unfortunately, just
> enabling that definition by default for debug builds brought up a good
> number of compiler warnings and errors from other files that were being
> silenced due to that.
> 
> This series makes it so meson defines DEBUG when the buildtype is debug,
> while additionally also fixing all of the compiler warnings/errors this
> causes in the default configuration.
> 
> Lyude Paul (4):
>   fbdevhw: Fix inconsistent #if DEBUG usage
>   x86emu: Fix type conversion warnings on x86_64 with DEBUG
>   meson: Silence -Wformat-nonliteral for x86emu
>   meson: Don't forget to define DEBUG!
> 
>  hw/xfree86/fbdevhw/fbdevhw.c |  6 +++---
>  hw/xfree86/int10/meson.build |  6 ++
>  hw/xfree86/x86emu/sys.c  | 12 ++--
>  hw/xfree86/x86emu/x86emu/types.h |  1 +
>  include/meson.build  |  4 +++-
>  5 files changed, 19 insertions(+), 10 deletions(-)

Merged, thanks:

remote: I: patch #182583 updated using rev 
01470ce0a9628abc8af4fe7b960f0d1eced8cd46.
remote: I: patch #182585 updated using rev 
cbca18c5516084ee540255df52e116209f1c1cbe.
remote: I: patch #182584 updated using rev 
0debe011901b87f686e2a76ce5edc150b04bf9d1.
remote: I: patch #182586 updated using rev 
6d7e1d1de06336c9b49a253810afda8ac4e9f7b2.
remote: I: 4 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   c66d65a645..6d7e1d1de0  master -> master

- ajax
___
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 0/5] Server-side vendor neutral dispatch for GLX

2017-10-20 Thread Kyle Brenneman 

On 08/30/2017 12:58 PM, Adam Jackson wrote:

The idea here is that the DDX creates a GLX provider during AddScreen,
and then GlxExtensionInit walks the list of created providers and calls
their setup functions to initialize GLX for a screen. If you have
heterogeneous GPUs in a Zaphod setup this would let you have GLX on
both. If you often change between drivers with different GLX stacks,
this lets the driver ask for the right thing instead of requiring
xorg.conf changes.

That's a lie, of course, because in this series the xfree86 DDX doesn't
implicitly register a provider for you. I'm not sure what the best way
to handle this is. I'd like not to have to touch every driver, and I'd
like it if the DRI2 provider was only probed if the screen called
DRI2ScreenInit, and I'd like it if that didn't rely knowing which order
CallCallbacks was going to walk its list; I may not get everything I
want. It might be worth just teaching the vnd layer about the swrast
provider and letting it claim any otherwise-unclaimed screens, even
though that feels like a layering violation.

Other things that aren't quite handled yet:

- autotools build system
- windows and osx builds
- dmx not ported
- libglx should be loadable for more than just xfree86

Still, feedback much appreciated.

- ajax

___
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
Based on some experiments I've been working on with this interface, I've 
got a few ideas and suggestions that I can offer.


Using swrast as a last-resort fallback for an unclaimed screen makes 
sense, because as far as I can tell, it can work no matter what hardware 
or driver (or lack thereof) is there. As such, special-casing it from 
the VND layer seems reasonable, and avoids relying on the callback order.


But, both swrast and the DRI2 provider are currently implemented 
internally under what would effectively be a single VND vendor handle. 
If each provider had its own vendor handle, then that would be a cleaner 
match to the VND interface, but that seems like it would be a more 
invasive change.


However, I think just using the same linked list of providers that it's 
got now would still work, so we could implement the VND interface with 
swrast and DRI2 still lumped together, and separate them out later, 
without having to break compatibility.


I've got some follow-on patches to get the xfree86 server working with 
this interface, plus a few other random fixes. I wouldn't call them 
ready for production yet, but I'll send them out so that anyone who's 
interested can try it out.



In the meantime, though, I've been looking into making GPU offloading 
work between drivers, and I was hoping to get some feedback as well.


The basic idea is that we'd extend the VND interface so that each screen 
has a primary vendor (from whichever driver is actually driving the 
desktop), but you can register any number of secondary vendors as well.


Each client would then have its own (screen -> vendor) map. By default, 
it would use the primary vendor for each screen, but the client could 
send some sort of extension request to tell the server to use an 
alternative. After that, the dispatching code is the same -- each 
request gets forwarded to the appropriate vendor based on a (client, 
screen) pair.


Creating contexts, allocating rendering surfaces, and so on would be an 
internal detail between the client and server vendor libraries, so the 
VND interface doesn't need to care about it. I'm also assuming that 
whatever communication you need between drivers to get the resulting 
image onto the screen will be separate from the VND interface.


I think X visuals would be the hardest part, because the secondary (off 
screen) vendor might have a different set of visuals that it can render 
to, but a GLX client still needs to be able to pass one of those visuals 
to XCreateWindow. That's easy enough to describe at the protocol level, 
but defining the resulting driver behavior gets tricky.


-Kyle

___
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] present: Only send PresentCompleteNotify events to the presenting client

2017-10-20 Thread Michel Dänzer 
From: Michel Dänzer 

We were sending the events to all clients listening for them on the
window. But clients can get confused by events from another client, and
I can't imagine any case where reciving events from other clients would
be required.

Signed-off-by: Michel Dänzer 
---

This fixes the same problem described in
https://patchwork.freedesktop.org/patch/183995/ . The problem doesn't
occur if either fix is present, and things work correctly when both are
present as well.

 present/present.c | 11 +--
 present/present_event.c   |  7 +--
 present/present_priv.h|  7 ++-
 present/present_request.c |  4 ++--
 4 files changed, 22 insertions(+), 7 deletions(-)

diff --git a/present/present.c b/present/present.c
index 176e89c0b..07da2c63c 100644
--- a/present/present.c
+++ b/present/present.c
@@ -206,13 +206,16 @@ present_vblank_notify(present_vblank_ptr vblank, CARD8 
kind, CARD8 mode, uint64_
 int n;
 
 if (vblank->window)
-present_send_complete_notify(vblank->window, kind, mode, 
vblank->serial, ust, crtc_msc - vblank->msc_offset);
+present_send_complete_notify(vblank->window, kind, mode, 
vblank->serial,
+ ust, crtc_msc - vblank->msc_offset,
+ vblank->client);
 for (n = 0; n < vblank->num_notifies; n++) {
 WindowPtr   window = vblank->notifies[n].window;
 CARD32  serial = vblank->notifies[n].serial;
 
 if (window)
-present_send_complete_notify(window, kind, mode, serial, ust, 
crtc_msc - vblank->msc_offset);
+present_send_complete_notify(window, kind, mode, serial, ust,
+ crtc_msc - vblank->msc_offset, NULL);
 }
 }
 
@@ -772,6 +775,7 @@ present_execute(present_vblank_ptr vblank, uint64_t ust, 
uint64_t crtc_msc)
 int
 present_pixmap(WindowPtr window,
PixmapPtr pixmap,
+   ClientPtr client,
CARD32 serial,
RegionPtr valid,
RegionPtr update,
@@ -882,6 +886,7 @@ present_pixmap(WindowPtr window,
 xorg_list_append(>window_list, _priv->vblank);
 xorg_list_init(>event_queue);
 
+vblank->client = client;
 vblank->screen = screen;
 vblank->window = window;
 vblank->pixmap = pixmap;
@@ -1001,6 +1006,7 @@ present_abort_vblank(ScreenPtr screen, RRCrtcPtr crtc, 
uint64_t event_id, uint64
 
 int
 present_notify_msc(WindowPtr window,
+   ClientPtr client,
CARD32 serial,
uint64_t target_msc,
uint64_t divisor,
@@ -1008,6 +1014,7 @@ present_notify_msc(WindowPtr window,
 {
 return present_pixmap(window,
   NULL,
+  client,
   serial,
   NULL, NULL,
   0, 0,
diff --git a/present/present_event.c b/present/present_event.c
index c222dd5ff..314e1c949 100644
--- a/present/present_event.c
+++ b/present/present_event.c
@@ -146,7 +146,9 @@ 
present_register_complete_notify(present_complete_notify_proc proc)
 }
 
 void
-present_send_complete_notify(WindowPtr window, CARD8 kind, CARD8 mode, CARD32 
serial, uint64_t ust, uint64_t msc)
+present_send_complete_notify(WindowPtr window, CARD8 kind, CARD8 mode,
+ CARD32 serial, uint64_t ust, uint64_t msc,
+ ClientPtr client)
 {
 present_window_priv_ptr window_priv = present_window_priv(window);
 
@@ -167,7 +169,8 @@ present_send_complete_notify(WindowPtr window, CARD8 kind, 
CARD8 mode, CARD32 se
 present_event_ptr event;
 
 for (event = window_priv->events; event; event = event->next) {
-if (event->mask & PresentCompleteNotifyMask) {
+if (event->mask & PresentCompleteNotifyMask &&
+(!client || client == event->client)) {
 cn.eid = event->id;
 WriteEventsToClient(event->client, 1, (xEvent *) );
 }
diff --git a/present/present_priv.h b/present/present_priv.h
index dfb4bdea9..01b930221 100644
--- a/present/present_priv.h
+++ b/present/present_priv.h
@@ -52,6 +52,7 @@ struct present_notify {
 struct present_vblank {
 struct xorg_listwindow_list;
 struct xorg_listevent_queue;
+ClientPtr   client;
 ScreenPtr   screen;
 WindowPtr   window;
 PixmapPtr   pixmap;
@@ -155,6 +156,7 @@ present_get_window_priv(WindowPtr window, Bool create);
 int
 present_pixmap(WindowPtr window,
PixmapPtr pixmap,
+   ClientPtr client,
CARD32 serial,
RegionPtr valid,
RegionPtr update,
@@ -172,6 +174,7 @@ present_pixmap(WindowPtr window,
 
 int
 present_notify_msc(WindowPtr window,
+   ClientPtr client,
CARD32 serial,

Re: [PATCH] Add NonDesktop output property and behaviors.

2017-10-20 Thread Keith Packard 
Giuseppe Bilotta  writes:

> (I actually wish I had some free time to put my coding hands where my
> mouth is 8-P).

I'd say it's more about waiting until we find a situation that actually
requires the additional work. Right now, the goal is to make a leased
output never part of the desktop, and that's where the current design is
focused. If we find a real use for doing something more complicated
later, we'll figure it out then.

X has a long history of having systems designed in advance of their need
and having that make things harder in the future, rather than easier...

-- 
-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: [PATCH libXau] Avoid out of boundary read access

2017-10-20 Thread Alan Coopersmith 

On 10/20/17 12:47 AM, walter harms wrote:



Am 19.10.2017 22:18, schrieb Tobias Stoeckmann:

If the environment variable HOME is empty, XauFileName triggers an
out of boundary read access (name[1]).


true but if HOME="" perhaps we could simply return

If HOME consists of a single

character relative path, the output becomes unexpected, because
"HOME=a" leads to "a.Xauthority" instead of "a/.Xauthority". Granted,
a relative HOME path leads to trouble in general, the code should
properly return "a/.Xauthority" nonetheless.


Why is that massage for slashDotXauthority done in the first place ?
if we drop it:
HOME  + "/.Xauthority" =
""+ "/.Xauthority" = "/.Xauthority"
"a"   + "/.Xauthority" = "a/.Xauthority"
"a/"  + "/.Xauthority" = "a//.Xauthority"


You missed the HOME="/" case which was commonly used on Unix systems
for the root user before the invention of the /root home directory.

"/"  + "/.Xauthority" = "//.Xauthority"


a "//" will be condensed to "/" by the system

did i miss something ?


I don't know of any systems that currently do this, but when X was written,
there were systems in which "//.Xauthority" would cause it to try to connect
to a host named ".Xauthority" and look in its filesystem, instead of just
trying to find ".Xauthority" as a file in the root of the local filesystem.

The system I used with this feature was Apollo Domain/OS, but I think it made
it's way into the DCE system from HP after they bought Apollo.  The syntax
inspired both the URL syntax we all use today with the same //hostname/path
model and the similar syntax with / turned to \ in Microsoft's networking.

It was fun to be in "/", run "cd .." and then have ls show all the hostnames
on your network, to which you could cd into and then have full access to their
filesystem.  (In hindsight also somewhat weird for / to not be the actual root
and somewhat scary for the unfiltered filesystem sharing, not just the portions
you wanted to share as NFS does.)

--
-Alan Coopersmith-   alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://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: [RFC xserver v4 07/14] modesetting: Use atomic modesetting to configure output/CRTCs

2017-10-20 Thread Daniel Martin 
On 16 October 2017 at 07:02, Louis-Francis Ratté-Boulianne
 wrote:
> To make sure we also use the same primary plane and to avoid
> mixing uses of two APIs, it is better to always use the atomic
> modesetting API when possible.
>
> Signed-off-by: Louis-Francis Ratté-Boulianne 
> ---
>  hw/xfree86/drivers/modesetting/drmmode_display.c | 402 
> +--
>  hw/xfree86/drivers/modesetting/drmmode_display.h |  35 +-
>  hw/xfree86/drivers/modesetting/pageflip.c|   2 +-
>  hw/xfree86/drivers/modesetting/present.c |   3 +-
>  4 files changed, 335 insertions(+), 107 deletions(-)
>
> diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
> b/hw/xfree86/drivers/modesetting/drmmode_display.c
> index 5d9770bb7..9caea858d 100644
> --- a/hw/xfree86/drivers/modesetting/drmmode_display.c
> +++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
> @@ -279,16 +279,100 @@ plane_add_prop(drmModeAtomicReq *req, 
> drmmode_crtc_private_ptr drmmode_crtc,
> info->prop_id, val);
>  return (ret <= 0) ? -1 : 0;
>  }
> +
> +static int
> +crtc_add_prop(drmModeAtomicReq *req, drmmode_crtc_private_ptr drmmode_crtc,
> +  enum drmmode_crtc_property prop, uint64_t val)
> +{
> +drmmode_prop_info_ptr info = _crtc->props[prop];
> +int ret;
> +
> +if (!info)
> +return -1;
> +
> +ret = drmModeAtomicAddProperty(req, drmmode_crtc->mode_crtc->crtc_id,
> +   info->prop_id, val);
> +return (ret <= 0) ? -1 : 0;
> +}
> +
> +static int
> +connector_add_prop(drmModeAtomicReq *req, drmmode_output_private_ptr 
> drmmode_output,
> +   enum drmmode_connector_property prop, uint64_t val)
> +{
> +drmmode_prop_info_ptr info = _output->props_connector[prop];
> +int ret;
> +
> +if (!info)
> +return -1;
> +
> +ret = drmModeAtomicAddProperty(req, 
> drmmode_output->mode_output->connector_id,
> +   info->prop_id, val);

You can use the output_id directly:
s/mode_output->connector_id/output_id/

We failed at least once handling the case of mode_output becoming NULL.
(And I'm going to send patches to rip the mode_output member out to
prevent such failures in the future.)
___
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 1/3] modesetting: Fix warning of unused variable if not GLAMOR_HAS_GBM

2017-10-20 Thread Daniel Martin 
../hw/xfree86/drivers/modesetting/driver.c: In function ‘redisplay_dirty’:
../hw/xfree86/drivers/modesetting/driver.c:586:20: warning: unused variable 
‘ms’ [-Wunused-variable]
 modesettingPtr ms = modesettingPTR(xf86ScreenToScrn(screen));

Move the variable ms into #ifdef GLAMOR_HAS_GBM, where it is used.

Signed-off-by: Daniel Martin 
---
 hw/xfree86/drivers/modesetting/driver.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/xfree86/drivers/modesetting/driver.c 
b/hw/xfree86/drivers/modesetting/driver.c
index 9afb344c8..91d850427 100644
--- a/hw/xfree86/drivers/modesetting/driver.c
+++ b/hw/xfree86/drivers/modesetting/driver.c
@@ -585,7 +585,6 @@ dispatch_slave_dirty(ScreenPtr pScreen)
 static void
 redisplay_dirty(ScreenPtr screen, PixmapDirtyUpdatePtr dirty, int *timeout)
 {
-modesettingPtr ms = modesettingPTR(xf86ScreenToScrn(screen));
 RegionRec pixregion;
 
 PixmapRegionInit(, dirty->slave_dst);
@@ -594,6 +593,7 @@ redisplay_dirty(ScreenPtr screen, PixmapDirtyUpdatePtr 
dirty, int *timeout)
 
 if (!screen->isGPU) {
 #ifdef GLAMOR_HAS_GBM
+modesettingPtr ms = modesettingPTR(xf86ScreenToScrn(screen));
 /*
  * When copying from the master framebuffer to the shared pixmap,
  * we must ensure the copy is complete before the slave starts a
-- 
2.13.6

___
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 3/3] modesetting: Check crtc before searching link-status property

2017-10-20 Thread Daniel Martin 
No need to lookup the link-status property if we don't have a crtc.

Signed-off-by: Daniel Martin 
---
 hw/xfree86/drivers/modesetting/drmmode_display.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c 
b/hw/xfree86/drivers/modesetting/drmmode_display.c
index e211e57eb..4906b0539 100644
--- a/hw/xfree86/drivers/modesetting/drmmode_display.c
+++ b/hw/xfree86/drivers/modesetting/drmmode_display.c
@@ -2270,12 +2270,14 @@ drmmode_handle_uevents(int fd, void *closure)
  */
 for (i = 0; i < config->num_output; i++) {
 xf86OutputPtr output = config->output[i];
+xf86CrtcPtr crtc = output->crtc;
 drmmode_output_private_ptr drmmode_output = output->driver_private;
 uint32_t con_id;
 drmModeConnectorPtr koutput;
 
-if (drmmode_output->mode_output == NULL)
+if (crtc == NULL || drmmode_output->mode_output == NULL)
 continue;
+
 con_id = drmmode_output->mode_output->connector_id;
 /* Get an updated view of the properties for the current connector and
  * look for the link-status property
@@ -2287,10 +2289,6 @@ drmmode_handle_uevents(int fd, void *closure)
 if (props && props->flags & DRM_MODE_PROP_ENUM &&
 !strcmp(props->name, "link-status") &&
 koutput->prop_values[j] == DRM_MODE_LINK_STATUS_BAD) {
-xf86CrtcPtr crtc = output->crtc;
-if (!crtc)
-continue;
-
 /* the connector got a link failure, re-set the current mode */
 drmmode_set_mode_major(crtc, >mode, crtc->rotation,
crtc->x, crtc->y);
-- 
2.13.6

___
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 2/3] modesetting: Remove #ifdefs XF86_PDEV_SERVER_FD

2017-10-20 Thread Daniel Martin 
XF86_PDEV_SERVER_FD is defined since:

commit 5fb641a29bfb4a33da964e1e9af523f3472015c6
Author: Hans de Goede 
Date:   Mon Jan 13 12:03:46 2014 +0100

hotplug: Extend OdevAttributes for server-managed fd support

ifdef'ing for it is a leftover from the external xf86-video-modesetting.

Signed-off-by: Daniel Martin 
---
 hw/xfree86/drivers/modesetting/driver.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/hw/xfree86/drivers/modesetting/driver.c 
b/hw/xfree86/drivers/modesetting/driver.c
index 91d850427..380dbbe17 100644
--- a/hw/xfree86/drivers/modesetting/driver.c
+++ b/hw/xfree86/drivers/modesetting/driver.c
@@ -244,14 +244,12 @@ probe_hw(const char *dev, struct xf86_platform_device 
*platform_dev)
 {
 int fd;
 
-#ifdef XF86_PDEV_SERVER_FD
 if (platform_dev && (platform_dev->flags & XF86_PDEV_SERVER_FD)) {
 fd = xf86_platform_device_odev_attributes(platform_dev)->fd;
 if (fd == -1)
 return FALSE;
 return check_outputs(fd, NULL);
 }
-#endif
 
 fd = open_hw(dev);
 if (fd != -1) {
@@ -712,10 +710,8 @@ FreeRec(ScrnInfoPtr pScrn)
 if (ms->pEnt->location.type == BUS_PCI)
 ret = drmClose(ms->fd);
 else
-#ifdef XF86_PDEV_SERVER_FD
 if (!(ms->pEnt->location.type == BUS_PLATFORM &&
   (ms->pEnt->location.id.plat->flags & 
XF86_PDEV_SERVER_FD)))
-#endif
 ret = close(ms->fd);
 (void) ret;
 ms_ent->fd = 0;
@@ -828,13 +824,11 @@ ms_get_drm_master_fd(ScrnInfoPtr pScrn)
 
 #ifdef XSERVER_PLATFORM_BUS
 if (pEnt->location.type == BUS_PLATFORM) {
-#ifdef XF86_PDEV_SERVER_FD
 if (pEnt->location.id.plat->flags & XF86_PDEV_SERVER_FD)
 ms->fd =
 xf86_platform_device_odev_attributes(pEnt->location.id.plat)->
 fd;
 else
-#endif
 {
 char *path =
 xf86_platform_device_odev_attributes(pEnt->location.id.plat)->
@@ -1496,11 +1490,9 @@ SetMaster(ScrnInfoPtr pScrn)
 modesettingPtr ms = modesettingPTR(pScrn);
 int ret;
 
-#ifdef XF86_PDEV_SERVER_FD
 if (ms->pEnt->location.type == BUS_PLATFORM &&
 (ms->pEnt->location.id.plat->flags & XF86_PDEV_SERVER_FD))
 return TRUE;
-#endif
 
 ret = drmSetMaster(ms->fd);
 if (ret)
@@ -1749,11 +1741,9 @@ LeaveVT(ScrnInfoPtr pScrn)
 
 pScrn->vtSema = FALSE;
 
-#ifdef XF86_PDEV_SERVER_FD
 if (ms->pEnt->location.type == BUS_PLATFORM &&
 (ms->pEnt->location.id.plat->flags & XF86_PDEV_SERVER_FD))
 return;
-#endif
 
 drmDropMaster(ms->fd);
 }
-- 
2.13.6

___
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] Add NonDesktop output property and behaviors.

2017-10-20 Thread Giuseppe Bilotta 
On Fri, Oct 20, 2017 at 3:25 AM, Keith Packard  wrote:
> Giuseppe Bilotta  writes:
>
>> FWIW, some Razer laptop models have a touchpad that doubles as a
>> secondary display. Not sure if it's worth mentioning (it does predate
>> the Apple Touch Bar, has some very patchy support under Linux, none that
>> I know of under Xorg).
>
> Thanks for another example. Is this display driven by the same hardware
> as the main display?

Nope, it's completely separate. I don't have the HW, so all I know I
gathered from these sources:

https://github.com/FxChiP/rzswitchblade
http://fxchip.net/RazerBlade/

>> Would it make sense to have a distinct connection status instead? This
>> would make it possible to differentiate between actual disconnection and
>> “connected, but not really a standard output to be used for desktop”.
>> (Would it possible to differentiate otherwise?)
>
> Yes, we could, but the goal is to remain backward compatible with the
> existing protocol, and adding a new value here wouldn't meet that
> requirement. If the RROutputChangeNotify event wasn't already 32 bytes
> long, we could have added a new field there and reported its presence
> with an updated version number. Alas.

I see. I don't suppose that making the new value correspond to pre-1.6
RR_UnknownConnection would help?
Older clients would still recognize it, but still not know what do
with it. (But I'm guessing recycling values this way wouldn't really
be very client friendly.)

> The obvious alternative would be to report the connected status in a new
> output property. I think the presence of all of the other data on the
> disconnected output (in particular, a list of modes), along with the
> non-desktop property, should be sufficient to know that it is connected?

That would work, although it's definitely more work on the client
side, rather than just checking a single field.

>> For the aforementioned touchpad/display, for example, one could envision
>> a “detached” mode where it acts like, say, the Apple Touch Bar, and an
>> “attached” mode where it's used like a standard display, for example to
>> show a zoomed area around the cursor. Achieving this would require this
>> properly to be mutable though.
>
> The current server architecture doesn't provide a mechanism for the user
> to override driver-provided values, which pushes against this reasonable
> request. It is a policy of sorts, and it's nice to be able to fix things
> in user space where necessary. How would you reset it back to 'whatever
> the driver thinks' though? Allow it to be set to some other value?

I was thinking along the lines of letting user change the value _when
possible_, e.g. when the driver itself might support multiple modes of
operation. There would need to be some kind of integration with the
input side of things though. Consider for example the aforementioned
Razer touchpad display: in “detached” mode the touchpad would work as
an absolute pointing device for its own display, in “attached” mode it
would work as a standard touchpad. Client setting the value would make
the driver switch both the nondesktop property _and_ the input device
M.O. —assuming that makes sense at all.

Another approach that might work would be for drivers that support
both M.O. to present two clone outputs instead of one, where one is
non-desktop and the other is desktop, and then runtime could switch
between them by turning them on and off, with the condition that
turning one on automatically turns the other off?

>> It would be interesting to make this an enum allowing
>> different values, so that clients could differentiate between, say, an
>> HMD and a TouchBar. (Maybe instead of RR_PROPERTY_NON_DESKTOP make it a
>> RR_PROPERTY_OUTPUT_USAGE and have values 0 for Desktop, 1 for HMD, 2 for
>> TouchSomething (could be the Apple thing or the Razer thing)?
>
> We can certainly add more information in additional properties. You do
> have access to the EDID data, of course, so you can make choices based
> on that. I want to leave the non-desktop property itself a simple
> boolean and consider adding more information when we find additional
> uses.

I'm probably a bit stuck in the C mindset that enums can work as
booleans as long as you have a single false state ;-) So checking if
the value is (present and) non-zero would act as a boolean, but the
same value could also carry the extra info. But I get the point.

> If you wanted to 'hide' it from other X applications, you would create a
> Monitor that covered the geometry of another active output and assign
> that to both the other output and the one to be hidden so that the
> geometry of the hidden output was not included in the overall Monitor
> geometry visible to applications.

[snip]

> It's an entirely normal output -- the position information would reflect
> which portion of the root window was being presented in the 'hidden'
> output.
>
>> Could an X client (say, something like Gimp

Re: [PATCH libXau] Avoid out of boundary read access

2017-10-20 Thread walter harms 


Am 19.10.2017 22:18, schrieb Tobias Stoeckmann:
> If the environment variable HOME is empty, XauFileName triggers an
> out of boundary read access (name[1]). 

true but if HOME="" perhaps we could simply return

If HOME consists of a single
> character relative path, the output becomes unexpected, because
> "HOME=a" leads to "a.Xauthority" instead of "a/.Xauthority". Granted,
> a relative HOME path leads to trouble in general, the code should
> properly return "a/.Xauthority" nonetheless.

Why is that massage for slashDotXauthority done in the first place ?
if we drop it:
HOME  + "/.Xauthority" =
""+ "/.Xauthority" = "/.Xauthority"
"a"   + "/.Xauthority" = "a/.Xauthority"
"a/"  + "/.Xauthority" = "a//.Xauthority"

a "//" will be condensed to "/" by the system

did i miss something ?

re,
 wh

> 
> Signed-off-by: Tobias Stoeckmann 
> ---
>  AuFileName.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/AuFileName.c b/AuFileName.c
> index 37c8b62..2946c80 100644
> --- a/AuFileName.c
> +++ b/AuFileName.c
> @@ -85,6 +85,6 @@ XauFileName (void)
>   bsize = size;
>  }
>  snprintf (buf, bsize, "%s%s", name,
> -  slashDotXauthority + (name[1] == '\0' ? 1 : 0));
> +  slashDotXauthority + (name[0] == '/' && name[1] == '\0' ? 1 : 
> 0));
>  return buf;
>  }
___
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