[PATCH xorg-gtest] xserver: add GetVersion() to retrieve server version
For non-integrated tests, knowing the X server version is important.
Signed-off-by: Peter Hutterer
---
I thought about decomposing this string into numbers, but really, strcmp()
will likely handle 90% of the cases we need
include/xorg/gtest/xorg-gtest-xserver.h | 10 ++
src/xserver.cpp | 31 +++
2 files changed, 41 insertions(+)
diff --git a/include/xorg/gtest/xorg-gtest-xserver.h
b/include/xorg/gtest/xorg-gtest-xserver.h
index 71857d3..0776d36 100644
--- a/include/xorg/gtest/xorg-gtest-xserver.h
+++ b/include/xorg/gtest/xorg-gtest-xserver.h
@@ -133,6 +133,16 @@ class XServer : public xorg::testing::Process {
const std::string& GetDisplayString(void);
/**
+ * Get the X server version as printed into the log file, usually in the
+ * form a.b.c[.d], with d being the optional part for release
+ * candidates.
+ *
+ * @return A string representing this server's version. If the server
+ * hasn't been started yet, GetVersion() returns an empty string.
+ */
+const std::string& GetVersion();
+
+/**
* Set startup options for the server.
*
* For arguments that do not take/need a value, use the empty string as
diff --git a/src/xserver.cpp b/src/xserver.cpp
index 2c551ff..08ff864 100644
--- a/src/xserver.cpp
+++ b/src/xserver.cpp
@@ -60,6 +60,7 @@ struct xorg::testing::XServer::Private {
std::string display_string;
std::string path_to_server;
std::map options;
+ std::string version;
};
xorg::testing::XServer::XServer() : d_(new Private) {
@@ -286,6 +287,36 @@ void xorg::testing::XServer::TestStartup(void) {
}
+const std::string& xorg::testing::XServer::GetVersion(void) {
+ if (Pid() == -1 || !d_->version.empty())
+return d_->version;
+
+ std::ifstream logfile;
+ logfile.open(d_->options["-logfile"].c_str());
+
+ std::string prefix = "X.Org X Server ";
+
+ if (logfile.is_open()) {
+std::string line;
+while (getline(logfile, line)) {
+ size_t start = line.find(prefix);
+ if (start == line.npos)
+continue;
+
+ line = line.substr(prefix.size());
+ /* RCs have the human-readable version after the version */
+ size_t end = line.find(" ");
+ if (end == line.npos)
+end = line.size();
+
+ d_->version = line.substr(0, end);
+ break;
+}
+ }
+
+ return d_->version;
+}
+
void xorg::testing::XServer::Start(const std::string &program) {
TestStartup();
--
1.7.10.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH xorg-gtest] process: use fork(), not vfork()
>From the man page:
The vfork() function has the same effect as fork(2), except that the
behavior is undefined if the process created by vfork() either modifies
any data other than a variable of type pid_t used to store the return
value from vfork(), or returns from the function in which vfork() was
called, or calls any other function before successfully calling
_exit(2) or one of the exec(3) family of functions.
We modify data and we call functions other than _exit/exec.
Signed-off-by: Peter Hutterer
---
src/process.cpp |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/process.cpp b/src/process.cpp
index debd92e..7df2b84 100644
--- a/src/process.cpp
+++ b/src/process.cpp
@@ -52,7 +52,7 @@ void xorg::testing::Process::Start(const std::string
&program, const std::vector
if (d_->pid != -1)
throw std::runtime_error("Attempting to start an already started process");
- d_->pid = vfork();
+ d_->pid = fork();
if (d_->pid == -1) {
throw std::runtime_error("Failed to fork child process");
--
1.7.10.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 1/7] xfree86/loader: Do not unload sibling modules.
On Tue, Aug 07, 2012 at 03:51:18PM -0700, Keith Packard wrote: > Michal Suchanek writes: > > > Ping? > > I'm not getting the feeling that this is resolving a known bug, so I > think it should wait for X server 1.14 at this point. Yes, I won't get to review this in time for 1.13, unfortunately. sorry. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 3/3] Kludge -- Call RandR screen before cleaning up xf86 crtcs
The core RandR screen cleanup now involves cleaning up any GPU screen
associations, and those call down into DDX to clean up the driver. If
the pointers from the xf86 structures back to the core randr
structures are set to NULL at that point, bad things happen.
This patch "knows" that the core RandR close screen is underneath the
xf86 randr close screen function, and so makes sure it gets called
first.
Signed-off-by: Keith Packard
---
hw/xfree86/modes/xf86Crtc.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index 154f684..1947c5be 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -726,6 +726,12 @@ xf86CrtcCloseScreen(ScreenPtr screen)
xf86RotateCloseScreen(screen);
+xf86RandR12CloseScreen(screen);
+
+free(config->name);
+
+screen->CloseScreen(screen);
+
for (o = 0; o < config->num_output; o++) {
xf86OutputPtr output = config->output[o];
@@ -749,10 +755,7 @@ xf86CrtcCloseScreen(ScreenPtr screen)
else if (screen->current_master)
DetachUnboundGPU(screen);
}
-xf86RandR12CloseScreen(screen);
-
-free(config->name);
-return screen->CloseScreen(screen);
+return TRUE;
}
/*
--
1.7.10.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 2/3] Close GPU screens before core screens
This should make cleaning up the GPU screens easier as the core
screens they are associated with will still be around.
Signed-off-by: Keith Packard
---
dix/main.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/dix/main.c b/dix/main.c
index 42f517d..fb935c9 100644
--- a/dix/main.c
+++ b/dix/main.c
@@ -331,6 +331,15 @@ main(int argc, char *argv[], char *envp[])
CloseDownEvents();
+for (i = screenInfo.numGPUScreens - 1; i >= 0; i--) {
+ScreenPtr pScreen = screenInfo.gpuscreens[i];
+FreeScratchPixmapsForScreen(pScreen);
+(*pScreen->CloseScreen) (pScreen);
+dixFreePrivates(pScreen->devPrivates, PRIVATE_SCREEN);
+free(pScreen);
+screenInfo.numGPUScreens = i;
+}
+
for (i = screenInfo.numScreens - 1; i >= 0; i--) {
FreeScratchPixmapsForScreen(screenInfo.screens[i]);
FreeGCperDepth(i);
@@ -342,15 +351,6 @@ main(int argc, char *argv[], char *envp[])
screenInfo.numScreens = i;
}
-for (i = screenInfo.numGPUScreens - 1; i >= 0; i--) {
-ScreenPtr pScreen = screenInfo.gpuscreens[i];
-FreeScratchPixmapsForScreen(pScreen);
-(*pScreen->CloseScreen) (pScreen);
-dixFreePrivates(pScreen->devPrivates, PRIVATE_SCREEN);
-free(pScreen);
-screenInfo.numGPUScreens = i;
-}
-
ReleaseClientIds(serverClient);
dixFreePrivates(serverClient->devPrivates, PRIVATE_CLIENT);
serverClient->devPrivates = NULL;
--
1.7.10.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 1/3] Only free Render filter names on last screen close
Hotplugging screens causes the render filter names to get freed while still in use; wait for the last core screen to be closed before freeing them. That only happens at server reset, when we want them to be freed. Signed-off-by: Keith Packard --- render/filter.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/render/filter.c b/render/filter.c index 8c401ee..019ea7f 100644 --- a/render/filter.c +++ b/render/filter.c @@ -273,7 +273,10 @@ PictureResetFilters(ScreenPtr pScreen) free(ps->filters); free(ps->filterAliases); -PictureFreeFilterIds(); + +/* Free the filters when the last screen is closed */ +if (pScreen->myNum == 0) +PictureFreeFilterIds(); } int -- 1.7.10.4 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 1/7] xfree86/loader: Do not unload sibling modules.
Michal Suchanek writes: > Ping? I'm not getting the feeling that this is resolving a known bug, so I think it should wait for X server 1.14 at this point. -- keith.pack...@intel.com pgpx3l2pNuqKs.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: libdrm-2.4.37: use ETIMEDOUT instead of ETIME?
> From: Matt Turner > Date: Tue, 17 Jul 2012 12:04:26 -0700 > > On Tue, Jul 17, 2012 at 11:58 AM, Thomas Klausner wrote: > > On Tue, Jul 17, 2012 at 07:02:56AM -0700, Matt Turner wrote: > >> On Mon, Jul 16, 2012 at 11:34 AM, Thomas Klausner wrote: > >> > libdrm-2.4.37 added a use of ETIME (from errno(3)) in > >> > intel/intel_bufmgr_gem.c. > >> > > >> > This errno is not defined on (at least) DragonFly BSD. > >> > > >> > A Linux man page for errno(3) says: > >> > ETIME Timer expired (POSIX.1 (XSI STREAMS option)) > >> > (POSIX.1 says "STREAM ioctl(2) timeout") > >> > > >> > Since this errno is only defined for a POSIX extension, wouldn't it > >> > make more sense to use the standard errno(3) ETIMEDOUT instead which > >> > exists in more environments? > >> > Thomas > >> > >> Does DragonFly BSD have Intel KMS? > > > > Not yet, but I don't see how this is relevant, because the file is > > compiled on DragonFly BSD independent of that question. Can you please > > explain? > > Thomas > > I was asking mostly out of curiosity, but at the same time I don't > think compiling this (libdrm_intel) is useful without KMS. Don't think it is KMS that matters here, but rather DRM/GEM support. We have the latter in OpenBSD, and do build an older version of libdrm, and I'm pretty sure that I've seen it used by applications. > Sorry for sort of off-topic. No idea about ETIME vs ETIMEDOUT. OpenBSD doesn't ETIME either, so ETIMEDOUT defenitely seems more portable to me. To be honest though, having a function return -EANYTHING outside of the Linux kernel doesn't make an awful lot of sense to me. If all that matters is that the return value is negative, simply returning -1 might make more sense. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Naive questions about Spice virtual frame buffer driver
The xf86-video-qxl driver is an Xorg driver, based on the dummy driver and some UXA code, which provides a virtualized Spice guest environment by linking to and running the Spice server code. Altogether, that stack is known as Xspice. I've been spending a lot of time with xf86-video-qxl in an attempt to improve the performance of Xspice over slow links. It's left me with some questions I was hoping others could help me with: 1. Is UXA still a reasonable choice? Or is there now a clearly better/different way that this should be done? Don't get me wrong; the UXA code seems nice; it makes the operations required a simple set, easy to connect up with the Spice server. I may also fail to understand a benefit it provides in terms of memory access that is useful for Spice. I just couldn't help but noticing that UXA seems to have gone from being The Hot New Thing (TM) to being Chopped Liver (TM). 2. Is there an official 'source' for uxa? Should there be some attempt to rebase this driver against updated versions? 3. Does having UXA, just for a virtual frame buffer, provide some valuable acceleration via software? It seems to, but I'm not sure if that's just wishful thinking on my part. Thanks for any insight. Cheers, Jeremy ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/2] Bump glproto requirement to 1.4.16
Julien Cristau writes: > Keith can you merge this patch? Thanks for the reminder. Merged. 02f94b2..9ca67de master -> master -- keith.pack...@intel.com pgpQP0RBtf9Ei.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 1/7] xfree86/loader: Do not unload sibling modules.
Ping? ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH 2/2] Bump glproto requirement to 1.4.16
Keith can you merge this patch? Thanks, Julien On Sun, Jul 15, 2012 at 04:45:41 +1000, Dave Airlie wrote: > On Sun, Jul 15, 2012 at 12:07 AM, Julien Cristau wrote: > > Signed-off-by: Julien Cristau > > Reviewed-by: Dave Airlie > > > --- > > configure.ac |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/configure.ac b/configure.ac > > index de12bb5..f5e192c 100644 > > --- a/configure.ac > > +++ b/configure.ac > > @@ -776,7 +776,7 @@ DRI2PROTO="dri2proto >= 2.8" > > XINERAMAPROTO="xineramaproto" > > BIGFONTPROTO="xf86bigfontproto >= 1.2.0" > > DGAPROTO="xf86dgaproto >= 2.0.99.1" > > -GLPROTO="glproto >= 1.4.15" > > +GLPROTO="glproto >= 1.4.16" > > DMXPROTO="dmxproto >= 2.2.99.1" > > VIDMODEPROTO="xf86vidmodeproto >= 2.2.99.1" > > WINDOWSWMPROTO="windowswmproto" > > -- > > 1.7.10.4 > > > > ___ > > xorg-devel@lists.x.org: X.Org development > > Archives: http://lists.x.org/archives/xorg-devel > > Info: http://lists.x.org/mailman/listinfo/xorg-devel > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: http://lists.x.org/mailman/listinfo/xorg-devel > ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
