Re: Display Link Adapter Hot-Swapping with xorg-server 1.13.0 and xrandr 1.4

2012-11-04 Thread Sam Lanning 

On 11/04/2012 10:18 AM, Dave Airlie wrote:
> On Sun, Nov 4, 2012 at 1:17 PM, Sam Lanning  wrote:
>> Hey Everyone,
>>
>> I'm new sending questions to this list so please forgive me. I wasn't sure
>> whether this should be directed at the devel list or users list.
>>
>> I am trying to get my DisplayLink adapter working with my Dell Vostro 3700
>> laptop. With nvidia optimus card.
>>
>> I came across Dave Airlie's work on hot-swapping slave USB gpus. And
>> discovered his git repo on freedesktop.org
>>
>> http://people.freedesktop.org/~airlied/prime-notes.txt
>>
>> I have tried to compile each of the parts (from the prime branch), but came
>> across trouble with compiling a few of them.
>>
>> Mesa: The first problem occurred when i tried to autogen. It couldnt find a
>> version of libdrm_nouveau greater than 0.6. I solved this with setting the
>> environment variables:
>>
>> NOUVEAU_LIBS=/usr/lib/libdrm_nouveau2.so.2:/usr/lib/libdrm_nouveau2.so.2.0.0
>> NOUVEAU_CFLAGS=empty
>>
>> so the make files were then generated fine.
>>
>> At compile time, make seems to get stuck in a loop constantly touching and
>> rm-f ing depend. And entering and leaving the directory src/glsl/.
>>
>>
>>
>> The second compile problem occurs when trying to create the make file for
>> xf86-video-nouveau. It comes up with this error after running autogen.sh
>>
>> ./configure: line 11987: syntax error near unexpected token `RANDR,'
>> ./configure: line 11987: `XORG_DRIVER_CHECK_EXT(RANDR, randrproto)'
>>
>> Any help would be greatly appreciated.
> Just get everything from upstream, nothing is in my personal branches
> anymore. Everything should be released except for xrandr which you can
> build from git.
>
> Dave.

Ahh ok then,

When i try and compile the current source from the repo
git://anongit.freedesktop.org/xorg/app/xrandr i get some errors at
compile time:

xrandr.o: In function `main':
.../xrandr.c:2969: undefined reference to `XRRSetProviderOffloadSink'
.../xrandr.c:2965: undefined reference to `XRRSetProviderOutputSource'
.../xrandr.c:3392: undefined reference to `XRRGetProviderResources'
.../xrandr.c:3397: undefined reference to `XRRGetProviderInfo'
.../xrandr.c:3404: undefined reference to `XRRFreeProviderInfo'
collect2: error: ld returned 1 exit status

I guess I'm missing some header files somewhere? But i'm not sure what
and autoconf didn't pick up on anything.

Cheers,
Sam.




___
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] XKB: Add two tests around XkbListComponents

2012-11-04 Thread Peter Hutterer 
On Mon, Nov 05, 2012 at 03:58:43PM +1100, Daniel Stone wrote:
> These require patches which aren't even in git master yet.
> 
> Signed-off-by: Daniel Stone 
> ---
>  configure.ac  |1 +
>  tests/Makefile.am |2 +-
>  tests/xkb/Makefile.am |7 
>  tests/xkb/list.cpp|  107 
> +
>  4 files changed, 116 insertions(+), 1 deletion(-)
>  create mode 100644 tests/xkb/Makefile.am
>  create mode 100644 tests/xkb/list.cpp
> 
> diff --git a/configure.ac b/configure.ac
> index f9459a7..0456678 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -93,5 +93,6 @@ AC_CONFIG_FILES([Makefile
>   tests/input/Makefile
>   tests/video/Makefile
>   tests/server/Makefile
> + tests/xkb/Makefile
>   tests/lib/Makefile])
>  AC_OUTPUT
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index 7e389e9..40c2545 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -1 +1 @@
> -SUBDIRS = common input server lib video
> +SUBDIRS = common input server lib video xkb

tbh I think the xkb tests should just be in the server directory.

> diff --git a/tests/xkb/Makefile.am b/tests/xkb/Makefile.am
> new file mode 100644
> index 000..c7ef5b8
> --- /dev/null
> +++ b/tests/xkb/Makefile.am
> @@ -0,0 +1,7 @@
> +include $(top_srcdir)/tests/common/Makefile.am
> +
> +noinst_PROGRAMS = list
> +TESTS=$(noinst_PROGRAMS)
> +
> +list_SOURCES = list.cpp $(common_sources)
> +list_LDADD = $(GTEST_LDADDS)
> diff --git a/tests/xkb/list.cpp b/tests/xkb/list.cpp
> new file mode 100644
> index 000..2359744
> --- /dev/null
> +++ b/tests/xkb/list.cpp
> @@ -0,0 +1,107 @@
> +#include 
> +#include 
> +
> +#include "helpers.h"
> +#include "device-interface.h"
> +#include "xit-server-input-test.h"
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +class XKBTest : public XITServerTest {
> +public:
> +virtual void SetUpConfigAndLog() {
> +config.AddDefaultScreenWithDriver();
> +config.AddInputSection("void", "--device--", "Option \"CorePointer\" 
> \"on\"\n");
> +config.WriteConfig();
> +server.SetOption("-config", config.GetPath());

last two lines aren't needed anymore, XITServerTest will do this
automatically.

> +}
> +
> +virtual void SetUp() {
> +XITServerTest::SetUp();
> +dpy = Display();
> +ASSERT_TRUE(XkbQueryExtension(dpy, &base_req, &base_ev, &base_err, 
> NULL, NULL));
> +}
> +
> +::Display *dpy;

we already have a display variable in the parent class, why not use
Display()?

> +int base_req;
> +int base_ev;
> +int base_err;

rename to xkb_..blah

> +};
> +
> +TEST_F(XKBTest, XKBComponentListLength)
> +{
> +XORG_TESTCASE("Register for the XKB extension.\n"
> +  "Construct a component list query with a malicious 
> length.\n"

what's a malicious length? Too long? specific value?

rest looks good.

Cheers,
   Peter

> +  "Hope the server doesn't crash.\n");
> +
> +XErrorEvent *err;
> +xkbListComponentsReq *req;
> +xkbListComponentsReply rep;
> +char *str;
> +int i;
> +
> +SetErrorTrap(dpy);
> +
> +LockDisplay(dpy);
> +GetReq(kbListComponents, req);
> +req->reqType = base_req;
> +req->xkbReqType = X_kbListComponents;
> +req->deviceSpec = XkbUseCoreKbd;
> +req->maxNames = 1024;
> +req->length += 2;
> +BufAlloc(char *, str, 8);
> +for (i = 0; i < 6; i++)
> +*str++ = 255;
> +ASSERT_FALSE(_XReply(dpy, (xReply *) &rep, 0, xFalse));
> +UnlockDisplay(dpy);
> +SyncHandle();
> +
> +err = ReleaseErrorTrap(dpy);
> +ASSERT_ERROR(err, BadLength);
> +}
> +
> +TEST_F(XKBTest, XKBComponentListEmpty)
> +{
> +XORG_TESTCASE("Register for the XKB extension.\n"
> +  "Check the listed legacy components.\n"
> +  "Ensure that no components are listed.\n");
> +
> +XkbComponentListPtr list;
> +XkbComponentNamesRec patterns;
> +int max = 1024;
> +
> +memset(&patterns, 0, sizeof(patterns));
> +patterns.keymap = NULL;
> +patterns.keycodes = strdup("*");
> +patterns.types = strdup("*");
> +patterns.compat = strdup("*");
> +patterns.symbols = strdup("*");
> +patterns.geometry = strdup("*");
> +
> +list = XkbListComponents(Display(), XkbUseCoreKbd, &patterns, &max);
> +ASSERT_TRUE(list);
> +
> +ASSERT_EQ(list->num_keymaps, 0);
> +ASSERT_EQ(list->num_keycodes, 0);
> +ASSERT_EQ(list->num_types, 0);
> +ASSERT_EQ(list->num_compat, 0);
> +ASSERT_EQ(list->num_symbols, 0);
> +ASSERT_EQ(list->num_geometry, 0);
> +ASSERT_EQ(max, 0);
> +
> +free(patterns.keycodes);
> +free(patterns.types);
> +free(patterns.compat);
> +free(patterns.symbols);
> +free(patterns.geometry);
> +free(list);
> +}
> +
> +int main(int argc, char** argv) {
> +testing::InitGoogleTest(&argc, argv);
> +

[PATCH XIT] common/helper: fix error trap for stack-local XError

2012-11-04 Thread Peter Hutterer 
The error Xlib passes to the error handler is stack-local. Saving its
address is entertaining, but largely useless.

Signed-off-by: Peter Hutterer 
---
 tests/common/helpers.cpp   | 14 --
 tests/common/helpers.h |  2 +-
 tests/server/barriers-validity.cpp |  8 
 3 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/tests/common/helpers.cpp b/tests/common/helpers.cpp
index aa6079c..2484e80 100644
--- a/tests/common/helpers.cpp
+++ b/tests/common/helpers.cpp
@@ -132,9 +132,10 @@ void DeviceSetEnabled(Display *dpy, int deviceid, bool 
enabled)
 /* Basic error trapping */
 static struct {
 bool is_trapping;
-XErrorEvent *error;
+bool have_error;
+XErrorEvent error;
 XErrorHandler prev_error_handler;
-} trap_state = { false, NULL, NULL };
+} trap_state;
 
 static int
 ErrorHandler(Display *dpy,
@@ -143,7 +144,8 @@ ErrorHandler(Display *dpy,
 if (!trap_state.is_trapping)
 ADD_FAILURE() << "Error trap received error while not trapping. WTF?";
 
-trap_state.error = error;
+trap_state.have_error = true;
+trap_state.error = *error;
 return 0;
 }
 
@@ -156,7 +158,7 @@ void SetErrorTrap(Display *dpy) {
 trap_state.is_trapping = true;
 }
 
-XErrorEvent * ReleaseErrorTrap(Display *dpy) {
+const XErrorEvent* ReleaseErrorTrap(Display *dpy) {
 if (!trap_state.is_trapping)
 ADD_FAILURE() << "ReleaseErrorTrap() called while not trapping.";
 
@@ -164,9 +166,9 @@ XErrorEvent * ReleaseErrorTrap(Display *dpy) {
 XSetErrorHandler(trap_state.prev_error_handler);
 trap_state.prev_error_handler = NULL;
 
-XErrorEvent *error = trap_state.error;
-trap_state.error = NULL;
+const XErrorEvent *error = trap_state.have_error ? &trap_state.error : 
NULL;
 trap_state.is_trapping = false;
+trap_state.have_error = false;
 return error;
 }
 
diff --git a/tests/common/helpers.h b/tests/common/helpers.h
index 43f7c76..be2f9e7 100644
--- a/tests/common/helpers.h
+++ b/tests/common/helpers.h
@@ -92,7 +92,7 @@ void SetErrorTrap(Display *dpy);
  *
  * @return An XErrorEvent that was trapped.
  */
-XErrorEvent * ReleaseErrorTrap(Display *dpy);
+const XErrorEvent* ReleaseErrorTrap(Display *dpy);
 
 #define ASSERT_ERROR(err, code) \
 ASSERT_TRUE(err != NULL) << ("Expected " #code);\
diff --git a/tests/server/barriers-validity.cpp 
b/tests/server/barriers-validity.cpp
index 8aa9343..61d1cec 100644
--- a/tests/server/barriers-validity.cpp
+++ b/tests/server/barriers-validity.cpp
@@ -43,7 +43,7 @@ TEST_F(BarrierSimpleTest, DestroyInvalidBarrier)
 
 SetErrorTrap(Display());
 XFixesDestroyPointerBarrier(Display(), -1);
-XErrorEvent *error = ReleaseErrorTrap(Display());
+const XErrorEvent *error = ReleaseErrorTrap(Display());
 ASSERT_ERROR(error, xfixes_error_base + BadBarrier);
 }
 
@@ -83,7 +83,7 @@ TEST_P(BarrierZeroLength, InvalidZeroLengthBarrier)
 
 SetErrorTrap(dpy);
 XFixesCreatePointerBarrier(dpy, root, 20, 20, 20, 20, directions, 0, NULL);
-XErrorEvent *error = ReleaseErrorTrap(dpy);
+const XErrorEvent *error = ReleaseErrorTrap(dpy);
 ASSERT_ERROR(error, BadValue);
 }
 
@@ -104,7 +104,7 @@ TEST_P(BarrierNonZeroArea, InvalidNonZeroAreaBarrier)
 
 SetErrorTrap(dpy);
 XFixesCreatePointerBarrier(dpy, root, 20, 20, 40, 40, directions, 0, NULL);
-XErrorEvent *error = ReleaseErrorTrap(dpy);
+const XErrorEvent *error = ReleaseErrorTrap(dpy);
 ASSERT_ERROR(error, BadValue);
 }
 INSTANTIATE_TEST_CASE_P(, BarrierNonZeroArea, VALID_DIRECTIONS);
@@ -143,7 +143,7 @@ TEST_P(BarrierConflictingDirections, 
InvalidConflictingDirectionsBarrier)
 
 SetErrorTrap(dpy);
 XFixesCreatePointerBarrier(dpy, root, x1, y1, x2, y2, directions, 0, NULL);
-XErrorEvent *error = ReleaseErrorTrap(dpy);
+const XErrorEvent *error = ReleaseErrorTrap(dpy);
 
 /* Nonsensical directions are ignored -- they don't
  * raise a BadValue. Unfortunately, there's no way
-- 
1.7.11.7

___
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/2] helpers: Save a copy to the trapped error, not pointer

2012-11-04 Thread Peter Hutterer 
On Mon, Nov 05, 2012 at 03:58:42PM +1100, Daniel Stone wrote:
> SetErrorTrap/ReleaseErrorTrap were storing a pointer to the error,
> rather than a copy of it.  It was pretty liable to getting trashed, so
> instead store a copy of our error.
> 
> Signed-off-by: Daniel Stone 
> ---
>  tests/common/helpers.cpp |   10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/tests/common/helpers.cpp b/tests/common/helpers.cpp
> index f48a134..3803d26 100644
> --- a/tests/common/helpers.cpp
> +++ b/tests/common/helpers.cpp
> @@ -132,9 +132,9 @@ void DeviceSetEnabled(Display *dpy, int deviceid, bool 
> enabled)
>  /* Basic error trapping */
>  static struct {
>  bool is_trapping;
> -XErrorEvent *error;
> +XErrorEvent error;
>  XErrorHandler prev_error_handler;
> -} trap_state = { False, NULL, NULL };
> +} trap_state;
>  
>  static int
>  ErrorHandler(Display *dpy,
> @@ -143,7 +143,7 @@ ErrorHandler(Display *dpy,
>  if (!trap_state.is_trapping)
>  ADD_FAILURE() << "Error trap received error while not trapping. 
> WTF?";
>  
> -trap_state.error = error;
> +trap_state.error = *error;
>  return 0;
>  }
>  
> @@ -154,6 +154,7 @@ void SetErrorTrap(Display *dpy) {
>  XSync(dpy, False);
>  trap_state.prev_error_handler = XSetErrorHandler(ErrorHandler);
>  trap_state.is_trapping = True;
> +memset(&trap_state.error, 0, sizeof(trap_state.error));
>  }
>  
>  XErrorEvent * ReleaseErrorTrap(Display *dpy) {
> @@ -164,8 +165,7 @@ XErrorEvent * ReleaseErrorTrap(Display *dpy) {
>  XSetErrorHandler(trap_state.prev_error_handler);
>  trap_state.prev_error_handler = NULL;
>  
> -XErrorEvent *error = trap_state.error;
> -trap_state.error = NULL;
> +XErrorEvent *error = &trap_state.error;

unless I'm missing something, this will always return an address instead of
NULL if there is no error. I've got a similar patch, coming up in a sec.

Cheers,
   Peter

>  trap_state.is_trapping = False;
>  return error;
>  }
> -- 
> 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 v2] XKB: Remove component listing support

2012-11-04 Thread Peter Hutterer 
On Mon, Nov 05, 2012 at 03:58:25PM +1100, Daniel Stone wrote:
> No-one uses this - not xkbcomp, not GNOME, not KDE.  The preferred way
> to deal with component listing (which gives you RMLVO rather than
> KcCGST) is to use the XML files on the client side.
> 
> Indeed, a couple of hours after making this commit, it emerged that all
> *.dir files built with xkbcomp 1.1.1 (released two years ago) and later
> have been catastrophically broken and nearly empty.  So I think that's
> reasonable proof that no-one uses them.
> 
> Signed-off-by: Daniel Stone 
> Reviewed-by: Peter Hutterer 

merged, thanks

Cheers,
   Peter

> ---
>  include/xkbsrv.h |   17 ---
>  xkb/Makefile.am  |3 +-
>  xkb/ddxList.c|  304 
> --
>  xkb/xkb.c|   50 -
>  4 files changed, 20 insertions(+), 354 deletions(-)
>  delete mode 100644 xkb/ddxList.c
> 
> v2: 
>   Added a comment explaining the Pascal strings thing.
>   Read six components off the wire rather than five: turns out this has been
>   broken for four years since a botched removal of keymap support.
> 
> diff --git a/include/xkbsrv.h b/include/xkbsrv.h
> index d584785..2b926a9 100644
> --- a/include/xkbsrv.h
> +++ b/include/xkbsrv.h
> @@ -835,23 +835,6 @@ extern void XkbFakeDeviceButton(DeviceIntPtr /* dev */ ,
>  #define  _XkbListGeometry4
>  #define  _XkbListNumComponents   5
>  
> -typedef struct _XkbSrvListInfo {
> -int szPool;
> -int nPool;
> -char *pool;
> -
> -int maxRtrn;
> -int nTotal;
> -
> -char *pattern[_XkbListNumComponents];
> -int nFound[_XkbListNumComponents];
> -} XkbSrvListInfoRec, *XkbSrvListInfoPtr;
> -
> -extern _X_EXPORT Status XkbDDXList(DeviceIntPtr /* dev */ ,
> -   XkbSrvListInfoPtr /* listing */ ,
> -   ClientPtr/* client */
> -);
> -
>  extern _X_EXPORT unsigned int XkbDDXLoadKeymapByNames(DeviceIntPtr /* keybd 
> */ ,
>XkbComponentNamesPtr
>/* names */ ,
> diff --git a/xkb/Makefile.am b/xkb/Makefile.am
> index fb3ccbf..e386ce5 100644
> --- a/xkb/Makefile.am
> +++ b/xkb/Makefile.am
> @@ -6,8 +6,7 @@ DDX_SRCS = \
>  ddxBeep.c \
>  ddxCtrls.c \
>  ddxLEDs.c \
> -ddxLoad.c \
> -ddxList.c
> +ddxLoad.c
>  
>  DIX_SRCS = \
>  xkb.c \
> diff --git a/xkb/ddxList.c b/xkb/ddxList.c
> deleted file mode 100644
> index 79f4637..000
> --- a/xkb/ddxList.c
> +++ /dev/null
> @@ -1,304 +0,0 @@
> -/
> -Copyright (c) 1995 by Silicon Graphics Computer Systems, Inc.
> -
> -Permission to use, copy, modify, and distribute this
> -software and its documentation for any purpose and without
> -fee is hereby granted, provided that the above copyright
> -notice appear in all copies and that both that copyright
> -notice and this permission notice appear in supporting
> -documentation, and that the name of Silicon Graphics not be 
> -used in advertising or publicity pertaining to distribution 
> -of the software without specific prior written permission.
> -Silicon Graphics makes no representation about the suitability 
> -of this software for any purpose. It is provided "as is"
> -without any express or implied warranty.
> -
> -SILICON GRAPHICS DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS 
> -SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY 
> -AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL SILICON
> -GRAPHICS BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL 
> -DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, 
> -DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE 
> -OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION  WITH
> -THE USE OR PERFORMANCE OF THIS SOFTWARE.
> -
> -/
> -
> -#ifdef HAVE_DIX_CONFIG_H
> -#include 
> -#endif
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include "inputstr.h"
> -#include "scrnintstr.h"
> -#include "windowstr.h"
> -#define  XKBSRV_NEED_FILE_FUNCS
> -#include 
> -#include 
> -
> -#ifdef WIN32
> -/* from ddxLoad.c */
> -#define W32_tmparg " '%s'"
> -#define W32_tmpfile ,tmpname
> -#define W32_tmplen strlen(tmpname)+3
> -#else
> -#define W32_tmparg
> -#define W32_tmpfile
> -#define W32_tmplen 0
> -#endif
> -
> -/******/
> -
> -static const char *componentDirs[_XkbListNumComponents] = {
> -"keycodes", "types", "compat", "symbols", "geometry"
> -};
> -
> -/******/
> -
> -static Status
> -_AddListComponent(XkbSrvListInfoPtr list,
> -  int what, unsigned flags, char *str, ClientPtr client)
> -{
> -int slen, wlen;

Re: [PATCH] XKB: Remove component listing support

2012-11-04 Thread Peter Hutterer 
On Mon, Nov 05, 2012 at 03:56:32PM +1100, Daniel Stone wrote:
> Hi,
> 
> On 2 November 2012 14:37, Peter Hutterer  wrote:
> 
> > can you covert your test to a XIT test and add it to (a newly created)
> > tests/server/xkb?
> > http://cgit.freedesktop.org/~whot/xorg-integration-tests/
> 
> 
> Are these tests ever supposed to work with anything other than master? I
> wrote a test which I'll send to the list, but if I push that, the tests are
> going to fail on literally every released version of the server ever, which
> doesn't sound particularly useful.

No, there is no server version that passes all tests. I have a bunch of
tests in there that are known bugs that are not fixed yet.

The tests _cannot_ be written to be happy, you'd end up with an indefinite
number of ifdefs in there (the RHEL6 ones in there already show that there's
no future to that). What will be needed on any actual distributed server
version is that you need to know _which_ tests work on the server version
and which ones are supposed to fail.

What is needed here is a registry that at least notes which tests are
expected to fail. I have some ideas for that, but no code yet. Some tests
already link to the bug, or patchwork, or commit number when they fail.
That's a start, but not sufficient yet.

> Is there much of a compelling reason for not having the tests in-tree with
> the server? 

yes. we talked about that when Chase proposed them (1.12 cycle) and unlike
the current tests the XIT do require a full install. Which means we can't
make it as part of the server's make check. And the churn the XIT go through
atm makes them unsuitable with the review process.

> What's the actual split between xorg-gtest and
> xorg-integration-tests? 

historical. xorg-gtest was what Chase started with. XIT was something I
started based on xorg-gtest that originally was internal for RHEL6 testing.
Apparently xorg-gtest is used for some unity tests, so to avoid too much of
a XIT-focused API the split still exists. Which appears painful at first
(and second, and third) but I have to say that hadn't it been for the split,
xorg-gtest's API would be much worse than it is.

If someone can actually spec out a proper API that doesn't need to break
often on first go, then this may be a nonissue. the way XIT tests were
added, this wasn't an option.

> Why does the former have a couple of random tests
> and a device declaration file if it seems to mainly just be a framework? 

Did you look at the "random" tests? They're there to test xorg-gtest itself. 

> Is
> there much use in having the split, given how codependent they seem to be?

I think so, even if it were more convenient to merge them.

> Also, it relies on evemu, which isn't packaged in Debian, which is kind of
> irritating.  (Also, evemu's autogen.sh isn't actually the standard X.Org
> autogen.sh, and doesn't run ./configure for you.  And it's on Launchpad,
> using Bazaar ... I die.  For bonus points, it's even licensed under GPLv3,
> which means a hell of a lot of companies will not go near it no matter
> what, and probably just skip the integration tests.)

evemu was written by Henrik Rydberg originally. He worked for Canonical,
which is why the whole thing is in launchpad and bzr. I was closed to
forking it but once I added the few things needed I could largely ignore it
since it works fine now.

However, whichever way you go, it is _not_ an X.Org project. Henrik
originally wrote it for kernel driver testing, iirc. If you want to rewrite
it so it complies with your preferred license, or you want to maintain a
fork somewhere, be my guest. Happily for me, I don't have a problem with
GPLv3 and my employer has neither.

It's a tool, it's needed for input device emulation. Unless something better
comes along, we'll use it, just like we use gcc, autotools, etc.

> With all the linking of massive chunks of C++, it's also crazy slow to
> build: I can autoreconf, configure, make, and make check Weston and its
> sample clients from scratch at least four times over in the time it takes
> to just build the tests, let alone run them.  Probably closer to five or
> six.  

We don't have a lot of choice on the linking, we need to compile from
source. We can probably go for a static library once in XIT but even then we
need to be careful of compiler flags.

googletest has it's downsides and quirks, but so far pretty much every
feature I needed from a test suite ended up being there. I'm not fond of
implementing a test framework given how much time xorg-gtest and XIT's base
classes already took.

And unless my view of the Weston tests is really really outdated, you're
joking if you compare make check in Weston with the tests run here. They're
not the same, they don't even try to be the same.

> When I do get to run them, the Synaptics tests (massively valuable,
> don't get me wrong) all interfere with my running server, presumably
> because it doesn't know to ignore a test device. 

Devices created by the tests will look

[PATCH 1/2] helpers: Save a copy to the trapped error, not pointer

2012-11-04 Thread Daniel Stone 
SetErrorTrap/ReleaseErrorTrap were storing a pointer to the error,
rather than a copy of it.  It was pretty liable to getting trashed, so
instead store a copy of our error.

Signed-off-by: Daniel Stone 
---
 tests/common/helpers.cpp |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tests/common/helpers.cpp b/tests/common/helpers.cpp
index f48a134..3803d26 100644
--- a/tests/common/helpers.cpp
+++ b/tests/common/helpers.cpp
@@ -132,9 +132,9 @@ void DeviceSetEnabled(Display *dpy, int deviceid, bool 
enabled)
 /* Basic error trapping */
 static struct {
 bool is_trapping;
-XErrorEvent *error;
+XErrorEvent error;
 XErrorHandler prev_error_handler;
-} trap_state = { False, NULL, NULL };
+} trap_state;
 
 static int
 ErrorHandler(Display *dpy,
@@ -143,7 +143,7 @@ ErrorHandler(Display *dpy,
 if (!trap_state.is_trapping)
 ADD_FAILURE() << "Error trap received error while not trapping. WTF?";
 
-trap_state.error = error;
+trap_state.error = *error;
 return 0;
 }
 
@@ -154,6 +154,7 @@ void SetErrorTrap(Display *dpy) {
 XSync(dpy, False);
 trap_state.prev_error_handler = XSetErrorHandler(ErrorHandler);
 trap_state.is_trapping = True;
+memset(&trap_state.error, 0, sizeof(trap_state.error));
 }
 
 XErrorEvent * ReleaseErrorTrap(Display *dpy) {
@@ -164,8 +165,7 @@ XErrorEvent * ReleaseErrorTrap(Display *dpy) {
 XSetErrorHandler(trap_state.prev_error_handler);
 trap_state.prev_error_handler = NULL;
 
-XErrorEvent *error = trap_state.error;
-trap_state.error = NULL;
+XErrorEvent *error = &trap_state.error;
 trap_state.is_trapping = False;
 return error;
 }
-- 
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 v2] XKB: Remove component listing support

2012-11-04 Thread Daniel Stone 
No-one uses this - not xkbcomp, not GNOME, not KDE.  The preferred way
to deal with component listing (which gives you RMLVO rather than
KcCGST) is to use the XML files on the client side.

Indeed, a couple of hours after making this commit, it emerged that all
*.dir files built with xkbcomp 1.1.1 (released two years ago) and later
have been catastrophically broken and nearly empty.  So I think that's
reasonable proof that no-one uses them.

Signed-off-by: Daniel Stone 
Reviewed-by: Peter Hutterer 
---
 include/xkbsrv.h |   17 ---
 xkb/Makefile.am  |3 +-
 xkb/ddxList.c|  304 --
 xkb/xkb.c|   50 -
 4 files changed, 20 insertions(+), 354 deletions(-)
 delete mode 100644 xkb/ddxList.c

v2: 
  Added a comment explaining the Pascal strings thing.
  Read six components off the wire rather than five: turns out this has been
  broken for four years since a botched removal of keymap support.

diff --git a/include/xkbsrv.h b/include/xkbsrv.h
index d584785..2b926a9 100644
--- a/include/xkbsrv.h
+++ b/include/xkbsrv.h
@@ -835,23 +835,6 @@ extern void XkbFakeDeviceButton(DeviceIntPtr /* dev */ ,
 #define_XkbListGeometry4
 #define_XkbListNumComponents   5
 
-typedef struct _XkbSrvListInfo {
-int szPool;
-int nPool;
-char *pool;
-
-int maxRtrn;
-int nTotal;
-
-char *pattern[_XkbListNumComponents];
-int nFound[_XkbListNumComponents];
-} XkbSrvListInfoRec, *XkbSrvListInfoPtr;
-
-extern _X_EXPORT Status XkbDDXList(DeviceIntPtr /* dev */ ,
-   XkbSrvListInfoPtr /* listing */ ,
-   ClientPtr/* client */
-);
-
 extern _X_EXPORT unsigned int XkbDDXLoadKeymapByNames(DeviceIntPtr /* keybd */ 
,
   XkbComponentNamesPtr
   /* names */ ,
diff --git a/xkb/Makefile.am b/xkb/Makefile.am
index fb3ccbf..e386ce5 100644
--- a/xkb/Makefile.am
+++ b/xkb/Makefile.am
@@ -6,8 +6,7 @@ DDX_SRCS = \
 ddxBeep.c \
 ddxCtrls.c \
 ddxLEDs.c \
-ddxLoad.c \
-ddxList.c
+ddxLoad.c
 
 DIX_SRCS = \
 xkb.c \
diff --git a/xkb/ddxList.c b/xkb/ddxList.c
deleted file mode 100644
index 79f4637..000
--- a/xkb/ddxList.c
+++ /dev/null
@@ -1,304 +0,0 @@
-/
-Copyright (c) 1995 by Silicon Graphics Computer Systems, Inc.
-
-Permission to use, copy, modify, and distribute this
-software and its documentation for any purpose and without
-fee is hereby granted, provided that the above copyright
-notice appear in all copies and that both that copyright
-notice and this permission notice appear in supporting
-documentation, and that the name of Silicon Graphics not be 
-used in advertising or publicity pertaining to distribution 
-of the software without specific prior written permission.
-Silicon Graphics makes no representation about the suitability 
-of this software for any purpose. It is provided "as is"
-without any express or implied warranty.
-
-SILICON GRAPHICS DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS 
-SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY 
-AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL SILICON
-GRAPHICS BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL 
-DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, 
-DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE 
-OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION  WITH
-THE USE OR PERFORMANCE OF THIS SOFTWARE.
-
-/
-
-#ifdef HAVE_DIX_CONFIG_H
-#include 
-#endif
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "inputstr.h"
-#include "scrnintstr.h"
-#include "windowstr.h"
-#defineXKBSRV_NEED_FILE_FUNCS
-#include 
-#include 
-
-#ifdef WIN32
-/* from ddxLoad.c */
-#define W32_tmparg " '%s'"
-#define W32_tmpfile ,tmpname
-#define W32_tmplen strlen(tmpname)+3
-#else
-#define W32_tmparg
-#define W32_tmpfile
-#define W32_tmplen 0
-#endif
-
-/******/
-
-static const char *componentDirs[_XkbListNumComponents] = {
-"keycodes", "types", "compat", "symbols", "geometry"
-};
-
-/******/
-
-static Status
-_AddListComponent(XkbSrvListInfoPtr list,
-  int what, unsigned flags, char *str, ClientPtr client)
-{
-int slen, wlen;
-unsigned char *wire8;
-unsigned short *wire16;
-char *tmp;
-
-if (list->nTotal >= list->maxRtrn) {
-list->nTotal++;
-return Success;
-}
-tmp = strchr(str, ')');
-if ((tmp == NULL) && ((tmp = strchr(str, '(')) == NULL)) {
-slen = strlen(str);
-while ((slen > 0) && isspace(str[slen - 1])) {
-slen--;
-

[PATCH 2/2] XKB: Add two tests around XkbListComponents

2012-11-04 Thread Daniel Stone 
These require patches which aren't even in git master yet.

Signed-off-by: Daniel Stone 
---
 configure.ac  |1 +
 tests/Makefile.am |2 +-
 tests/xkb/Makefile.am |7 
 tests/xkb/list.cpp|  107 +
 4 files changed, 116 insertions(+), 1 deletion(-)
 create mode 100644 tests/xkb/Makefile.am
 create mode 100644 tests/xkb/list.cpp

diff --git a/configure.ac b/configure.ac
index f9459a7..0456678 100644
--- a/configure.ac
+++ b/configure.ac
@@ -93,5 +93,6 @@ AC_CONFIG_FILES([Makefile
  tests/input/Makefile
  tests/video/Makefile
  tests/server/Makefile
+ tests/xkb/Makefile
  tests/lib/Makefile])
 AC_OUTPUT
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 7e389e9..40c2545 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -1 +1 @@
-SUBDIRS = common input server lib video
+SUBDIRS = common input server lib video xkb
diff --git a/tests/xkb/Makefile.am b/tests/xkb/Makefile.am
new file mode 100644
index 000..c7ef5b8
--- /dev/null
+++ b/tests/xkb/Makefile.am
@@ -0,0 +1,7 @@
+include $(top_srcdir)/tests/common/Makefile.am
+
+noinst_PROGRAMS = list
+TESTS=$(noinst_PROGRAMS)
+
+list_SOURCES = list.cpp $(common_sources)
+list_LDADD = $(GTEST_LDADDS)
diff --git a/tests/xkb/list.cpp b/tests/xkb/list.cpp
new file mode 100644
index 000..2359744
--- /dev/null
+++ b/tests/xkb/list.cpp
@@ -0,0 +1,107 @@
+#include 
+#include 
+
+#include "helpers.h"
+#include "device-interface.h"
+#include "xit-server-input-test.h"
+
+#include 
+
+#include 
+#include 
+#include 
+
+class XKBTest : public XITServerTest {
+public:
+virtual void SetUpConfigAndLog() {
+config.AddDefaultScreenWithDriver();
+config.AddInputSection("void", "--device--", "Option \"CorePointer\" 
\"on\"\n");
+config.WriteConfig();
+server.SetOption("-config", config.GetPath());
+}
+
+virtual void SetUp() {
+XITServerTest::SetUp();
+dpy = Display();
+ASSERT_TRUE(XkbQueryExtension(dpy, &base_req, &base_ev, &base_err, 
NULL, NULL));
+}
+
+::Display *dpy;
+int base_req;
+int base_ev;
+int base_err;
+};
+
+TEST_F(XKBTest, XKBComponentListLength)
+{
+XORG_TESTCASE("Register for the XKB extension.\n"
+  "Construct a component list query with a malicious length.\n"
+  "Hope the server doesn't crash.\n");
+
+XErrorEvent *err;
+xkbListComponentsReq *req;
+xkbListComponentsReply rep;
+char *str;
+int i;
+
+SetErrorTrap(dpy);
+
+LockDisplay(dpy);
+GetReq(kbListComponents, req);
+req->reqType = base_req;
+req->xkbReqType = X_kbListComponents;
+req->deviceSpec = XkbUseCoreKbd;
+req->maxNames = 1024;
+req->length += 2;
+BufAlloc(char *, str, 8);
+for (i = 0; i < 6; i++)
+*str++ = 255;
+ASSERT_FALSE(_XReply(dpy, (xReply *) &rep, 0, xFalse));
+UnlockDisplay(dpy);
+SyncHandle();
+
+err = ReleaseErrorTrap(dpy);
+ASSERT_ERROR(err, BadLength);
+}
+
+TEST_F(XKBTest, XKBComponentListEmpty)
+{
+XORG_TESTCASE("Register for the XKB extension.\n"
+  "Check the listed legacy components.\n"
+  "Ensure that no components are listed.\n");
+
+XkbComponentListPtr list;
+XkbComponentNamesRec patterns;
+int max = 1024;
+
+memset(&patterns, 0, sizeof(patterns));
+patterns.keymap = NULL;
+patterns.keycodes = strdup("*");
+patterns.types = strdup("*");
+patterns.compat = strdup("*");
+patterns.symbols = strdup("*");
+patterns.geometry = strdup("*");
+
+list = XkbListComponents(Display(), XkbUseCoreKbd, &patterns, &max);
+ASSERT_TRUE(list);
+
+ASSERT_EQ(list->num_keymaps, 0);
+ASSERT_EQ(list->num_keycodes, 0);
+ASSERT_EQ(list->num_types, 0);
+ASSERT_EQ(list->num_compat, 0);
+ASSERT_EQ(list->num_symbols, 0);
+ASSERT_EQ(list->num_geometry, 0);
+ASSERT_EQ(max, 0);
+
+free(patterns.keycodes);
+free(patterns.types);
+free(patterns.compat);
+free(patterns.symbols);
+free(patterns.geometry);
+free(list);
+}
+
+int main(int argc, char** argv) {
+testing::InitGoogleTest(&argc, argv);
+return RUN_ALL_TESTS();
+}
-- 
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] XKB: Remove component listing support

2012-11-04 Thread Daniel Stone 
Hi,

On 2 November 2012 14:37, Peter Hutterer  wrote:

> can you covert your test to a XIT test and add it to (a newly created)
> tests/server/xkb?
> http://cgit.freedesktop.org/~whot/xorg-integration-tests/


Are these tests ever supposed to work with anything other than master? I
wrote a test which I'll send to the list, but if I push that, the tests are
going to fail on literally every released version of the server ever, which
doesn't sound particularly useful.

Is there much of a compelling reason for not having the tests in-tree with
the server? What's the actual split between xorg-gtest and
xorg-integration-tests? Why does the former have a couple of random tests
and a device declaration file if it seems to mainly just be a framework? Is
there much use in having the split, given how codependent they seem to be?

Also, it relies on evemu, which isn't packaged in Debian, which is kind of
irritating.  (Also, evemu's autogen.sh isn't actually the standard X.Org
autogen.sh, and doesn't run ./configure for you.  And it's on Launchpad,
using Bazaar ... I die.  For bonus points, it's even licensed under GPLv3,
which means a hell of a lot of companies will not go near it no matter
what, and probably just skip the integration tests.)

With all the linking of massive chunks of C++, it's also crazy slow to
build: I can autoreconf, configure, make, and make check Weston and its
sample clients from scratch at least four times over in the time it takes
to just build the tests, let alone run them.  Probably closer to five or
six.  When I do get to run them, the Synaptics tests (massively valuable,
don't get me wrong) all interfere with my running server, presumably
because it doesn't know to ignore a test device.  That's something that'd
be really nice to have a flag for.  The Wacom tests are all failing
(presumably due to not having the driver installed), but between the
two-second delay for server starting and five-second device wait, are
taking seven seconds a pop.  There's forty-eight of those tests, which
makes it just over five and a half minutes.  I also now have a bajillion
files directly under /tmp.

The keyboard tests all failed because the dummy display driver
configuration didn't get written out, so it tried to spawn a new Intel
server, only to die when it realised it couldn't become a DRM master.

Sorry if this comes across as kind of harsh - I really, really like the
idea, but it comes across as pretty irritating to actually write the tests.
 Take this with a grain of salt since I barely touch X these days, but it
just seems way too clunky become part of my regular workflow.  It's all
fixable, mind (with the possible exception of the massive chunks o' C++),
but the out-of-the-box experience isn't much fun.


> > -list.pattern[_XkbListKeycodes] = GetComponentSpec(&str, FALSE,
> &status);
> > -list.pattern[_XkbListTypes] = GetComponentSpec(&str, FALSE,
> &status);
> > -list.pattern[_XkbListCompat] = GetComponentSpec(&str, FALSE,
> &status);
> > -list.pattern[_XkbListSymbols] = GetComponentSpec(&str, FALSE,
> &status);
> > -list.pattern[_XkbListGeometry] = GetComponentSpec(&str, FALSE,
> &status);
> > -if (status != Success)
> > -return status;
> > +for (i = 0; i < _XkbListNumComponents; i++) {
> > +size = *((uint8_t *)str);
> > +str += (size + 1);
> > +}
>
> please add a short comment that str is a set of pascal-style strings so
> we're really just skipping over the content of the string here. it's not
> really obvious for the unsuspecting reviewer.
>

Sure, I've done this now.  I've also changed the 5 to 6: turns out
that 1ad80678 (committed 2009) broke this function anyway.  It shifted all
the component masks up one (so your keycode spec was actually the keymap
spec, types were keycodes, etc), and it'd also give you BadLength unless
you specified * for everything, or otherwise managed to have your length
such that the length of keymap string spec + 1 fit into the four-character
padding.


> I suspect if anyone was really using this instead of the xml, we won't hear
> of it until this feeds into RHEL or a similar distro...
>

Given that's the second problem I've found with this code, I doubt it'll be
too much of an issue.


> anyway, with the comment:
> Reviewed-by: Peter Hutterer 
>

Thanks, resent if you want to pull into your tree.

Cheers,
Daniel
___
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

[PULL] touch pointer emulation, per-device barriers

2012-11-04 Thread Peter Hutterer 
The following changes since commit a194630f7f7b287cb4ea4a459df0745f4c0d4c1a:

  Merge remote-tracking branch 'whot/for-keith' (2012-11-01 13:38:54 -0700)

are available in the git repository at:


  git://people.freedesktop.org/~whot/xserver for-keith

for you to fetch changes up to 355470f137aefe4a4907de5487288a1182a7ea98:

  Xi: Set modifier mask on touch events (2012-11-05 12:12:00 +1000)


Alexey Ten (Lynn) (1):
  Apply partial matches for option (#25873)

Carlos Garnacho (2):
  Xi: Update the device after delivering the emulated pointer event(#56558)
  Xi: Set modifier mask on touch events

Daniel Martin (1):
  Fix FP1616 macro

Jasper St. Pierre (5):
  cursor: Fix a minor unused variable warning
  cursor: CreatePointerBarrier has a variable request length
  cursor: Clean up pointer barrier creation code a tiny bit
  cursor: Clean up barrier finding code a bit
  cursor: Fix up implementation for per-device barriers

Peter Hutterer (1):
  dix: don't allow disabling XTest devices

 Xi/chgdctl.c   |   5 +-
 Xi/exevents.c  |  12 +++-
 dix/devices.c  |   8 ++-
 include/eventconvert.h |   2 +-
 xfixes/cursor.c| 145 +
 xkb/maprules.c |   1 +
 6 files changed, 130 insertions(+), 43 deletions(-)


pgpLepLbqpG7a.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 5/5] cursor: Fix up implementation for per-device barriers

2012-11-04 Thread Peter Hutterer 
On Sat, Nov 03, 2012 at 08:23:46PM -0400, Jasper St. Pierre wrote:
> From: "Jasper St. Pierre" 
> 
> Support multiple mast devices being specified as a parameter to the
> barrier. This should implement all parts of the XFixes specification,
> minus the existing non-specification detail where specifying no devices
> is the same as specifying XIAllDevices.
> 
> Signed-off-by: Jasper St. Pierre 
> ---
>  xfixes/cursor.c | 75 
> +++--
>  1 file changed, 68 insertions(+), 7 deletions(-)
> 
> diff --git a/xfixes/cursor.c b/xfixes/cursor.c
> index 45b07c3..7ca48c8 100644
> --- a/xfixes/cursor.c
> +++ b/xfixes/cursor.c
> @@ -56,6 +56,7 @@
>  #include "windowstr.h"
>  #include "xace.h"
>  #include "list.h"
> +#include "exglobals.h"
>  
>  static RESTYPE CursorClientType;
>  static RESTYPE CursorHideCountType;
> @@ -118,6 +119,8 @@ struct PointerBarrierClient {
>  ScreenPtr screen;
>  struct PointerBarrier barrier;
>  struct xorg_list entry;
> +int num_devices;
> +int device_ids[0]; /* num_devices */

We usually just use a int*, even if it is allocated just after the struct. I
can see why [0] is beneficial here, but let's stick with consistency here.
And iirc that's a gnu-ism anyway.

I've changed this locally, patches applied otherwise. thanks

Cheers,
   Peter

>  };
>  
>  /*
> @@ -1132,6 +1135,31 @@ barrier_is_blocking(const struct PointerBarrier * 
> barrier,
>  return rc;
>  }
>  
> +static BOOL
> +barrier_blocks_device(struct PointerBarrierClient *client,
> +  DeviceIntPtr dev)
> +{
> +int i;
> +int master_id;
> +
> +/* Clients with no devices are treated as
> + * if they specified XIAllDevices. */
> +if (client->num_devices == 0)
> +return TRUE;
> +
> +master_id = GetMaster(dev, POINTER_OR_FLOAT)->id;
> +
> +for (i = 0; i < client->num_devices; i++) {
> +int device_id = client->device_ids[i];
> +if (device_id == XIAllDevices ||
> +device_id == XIAllMasterDevices ||
> +device_id == master_id)
> +return TRUE;
> +}
> +
> +return FALSE;
> +}
> +
>  /**
>   * Find the nearest barrier that is blocking movement from x1/y1 to x2/y2.
>   *
> @@ -1143,7 +1171,8 @@ barrier_is_blocking(const struct PointerBarrier * 
> barrier,
>   * @return The barrier nearest to the movement origin that blocks this 
> movement.
>   */
>  static struct PointerBarrier *
> -barrier_find_nearest(CursorScreenPtr cs, int dir,
> +barrier_find_nearest(CursorScreenPtr cs, DeviceIntPtr dev,
> + int dir,
>   int x1, int y1, int x2, int y2)
>  {
>  struct PointerBarrierClient *c;
> @@ -1157,6 +1186,9 @@ barrier_find_nearest(CursorScreenPtr cs, int dir,
>  if (!barrier_is_blocking_direction(b, dir))
>  continue;
>  
> +if (!barrier_blocks_device(c, dev))
> +continue;
> +
>  if (barrier_is_blocking(b, x1, y1, x2, y2, &distance)) {
>  if (min_distance > distance) {
>  min_distance = distance;
> @@ -1221,7 +1253,7 @@ CursorConstrainCursorHarder(DeviceIntPtr dev, ScreenPtr 
> screen, int mode,
>  
>  #define MAX_BARRIERS 2
>  for (i = 0; i < MAX_BARRIERS; i++) {
> -nearest = barrier_find_nearest(cs, dir, ox, oy, *x, *y);
> +nearest = barrier_find_nearest(cs, dev, dir, ox, oy, *x, *y);
>  if (!nearest)
>  break;
>  
> @@ -1251,7 +1283,14 @@ CreatePointerBarrierClient(ScreenPtr screen, ClientPtr 
> client,
> PointerBarrierClientPtr *client_out)
>  {
>  CursorScreenPtr cs = GetCursorScreen(screen);
> -struct PointerBarrierClient *ret = malloc(sizeof(*ret));
> +int err;
> +int size;
> +int i;
> +CARD16 *in_devices;
> +struct PointerBarrierClient *ret;
> +
> +size = sizeof(*ret) + sizeof(int) * stuff->num_devices;
> +ret = malloc(size);
>  
>  *client_out = NULL;
>  
> @@ -1260,6 +1299,28 @@ CreatePointerBarrierClient(ScreenPtr screen, ClientPtr 
> client,
>  }
>  
>  ret->screen = screen;
> +ret->num_devices = stuff->num_devices;
> +
> +in_devices = (CARD16 *) &stuff[1];
> +for (i = 0; i < stuff->num_devices; i++) {
> +int device_id = in_devices[i];
> +DeviceIntPtr device;
> +
> +if ((err = dixLookupDevice (&device, device_id,
> +client, DixReadAccess))) {
> +client->errorValue = device_id;
> +goto error;
> +}
> +
> +if (!IsMaster (device)) {
> +client->errorValue = device_id;
> +err = BadDevice;
> +goto error;
> +}
> +
> +ret->device_ids[i] = device_id;
> +}
> +
>  ret->barrier.x1 = min(stuff->x1, stuff->x2);
>  ret->barrier.x2 = max(stuff->x1, stuff->x2);
>  ret->barrier.y1 = min(stuff->y1, stuff->y2);
> @@ -1273,6 +1334,10 @@ CreatePoint

Re: [PATCH 3/5] cursor: Clean up pointer barrier creation code a tiny bit

2012-11-04 Thread Peter Hutterer 
On Sat, Nov 03, 2012 at 06:39:34PM -0400, Jasper St. Pierre wrote:
> From: "Jasper St. Pierre" 
> 
> This will make it much simpler when we add more error paths to the code
> that constructs pointer barrier clients.
> 
> Signed-off-by: Jasper St. Pierre 
> ---
>  xfixes/cursor.c | 54 ++
>  1 file changed, 26 insertions(+), 28 deletions(-)
> 
> diff --git a/xfixes/cursor.c b/xfixes/cursor.c
> index 9d7c0f0..a34f65c 100644
> --- a/xfixes/cursor.c
> +++ b/xfixes/cursor.c
> @@ -1245,28 +1245,34 @@ CursorConstrainCursorHarder(DeviceIntPtr dev, 
> ScreenPtr screen, int mode,
>  }
>  }
>  
> -static struct PointerBarrierClient *
> +static int
>  CreatePointerBarrierClient(ScreenPtr screen, ClientPtr client,
> -   xXFixesCreatePointerBarrierReq * stuff)
> +   xXFixesCreatePointerBarrierReq * stuff,
> +   PointerBarrierClientPtr *client_out)
>  {
>  CursorScreenPtr cs = GetCursorScreen(screen);
>  struct PointerBarrierClient *ret = malloc(sizeof(*ret));
>  
> -if (ret) {
> -ret->screen = screen;
> -ret->barrier.x1 = min(stuff->x1, stuff->x2);
> -ret->barrier.x2 = max(stuff->x1, stuff->x2);
> -ret->barrier.y1 = min(stuff->y1, stuff->y2);
> -ret->barrier.y2 = max(stuff->y1, stuff->y2);
> -ret->barrier.directions = stuff->directions & 0x0f;
> -if (barrier_is_horizontal(&ret->barrier))
> -ret->barrier.directions &= ~(BarrierPositiveX | 
> BarrierNegativeX);
> -if (barrier_is_vertical(&ret->barrier))
> -ret->barrier.directions &= ~(BarrierPositiveY | 
> BarrierNegativeY);
> -xorg_list_add(&ret->entry, &cs->barriers);
> +*client_out = NULL;
> +
> +if (!ret) {
> +return BadAlloc;
>  }
>  
> -return ret;
> +ret->screen = screen;
> +ret->barrier.x1 = min(stuff->x1, stuff->x2);
> +ret->barrier.x2 = max(stuff->x1, stuff->x2);
> +ret->barrier.y1 = min(stuff->y1, stuff->y2);
> +ret->barrier.y2 = max(stuff->y1, stuff->y2);
> +ret->barrier.directions = stuff->directions & 0x0f;
> +if (barrier_is_horizontal(&ret->barrier))
> +ret->barrier.directions &= ~(BarrierPositiveX | BarrierNegativeX);
> +if (barrier_is_vertical(&ret->barrier))
> +ret->barrier.directions &= ~(BarrierPositiveY | BarrierNegativeY);
> +xorg_list_add(&ret->entry, &cs->barriers);
> +
> +*client_out = ret;
> +return Success;
>  }
>  
>  int
> @@ -1279,7 +1285,7 @@ ProcXFixesCreatePointerBarrier(ClientPtr client)
>  
>  REQUEST(xXFixesCreatePointerBarrierReq);
>  
> -REQUEST_FIXED_SIZE(xXFixesCreatePointerBarrierReq, 
> pad_to_int32(stuff->num_devices));
> +REQUEST_SIZE_MATCH(xXFixesCreatePointerBarrierReq);

did you really intend to undo the previous patch?

Cheers,
   Peter

>  LEGAL_NEW_RESOURCE(stuff->barrier, client);
>  
>  err = dixLookupWindow(&pWin, stuff->window, client, DixReadAccess);
> @@ -1304,9 +1310,9 @@ ProcXFixesCreatePointerBarrier(ClientPtr client)
>  if (barrier_is_horizontal(&b) && barrier_is_vertical(&b))
>  return BadValue;
>  
> -if (!(barrier = CreatePointerBarrierClient(pWin->drawable.pScreen,
> -   client, stuff)))
> -return BadAlloc;
> +if ((err = CreatePointerBarrierClient(pWin->drawable.pScreen,
> +  client, stuff, &barrier)))
> +return err;
>  
>  if (!AddResource(stuff->barrier, PointerBarrierType, &barrier->barrier))
>  return BadAlloc;
> @@ -1318,13 +1324,9 @@ int
>  SProcXFixesCreatePointerBarrier(ClientPtr client)
>  {
>  REQUEST(xXFixesCreatePointerBarrierReq);
> -int i;
> -CARD16 *in_devices = (CARD16 *) &stuff[1];
>  
>  swaps(&stuff->length);
> -swaps(&stuff->num_devices);
> -REQUEST_FIXED_SIZE(xXFixesCreatePointerBarrierReq, 
> pad_to_int32(stuff->num_devices));
> -
> +REQUEST_SIZE_MATCH(xXFixesCreatePointerBarrierReq);
>  swapl(&stuff->barrier);
>  swapl(&stuff->window);
>  swaps(&stuff->x1);
> @@ -1332,10 +1334,6 @@ SProcXFixesCreatePointerBarrier(ClientPtr client)
>  swaps(&stuff->x2);
>  swaps(&stuff->y2);
>  swapl(&stuff->directions);
> -for (i = 0; i < stuff->num_devices; i++) {
> -swapl(in_devices + i);
> -}
> -
>  return ProcXFixesVector[stuff->xfixesReqType] (client);
>  }
>  
> -- 
> 1.7.12.1
> 
> ___
> 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

Re: Display Link Adapter Hot-Swapping with xorg-server 1.13.0 and xrandr 1.4

2012-11-04 Thread Dave Airlie 
On Mon, Nov 5, 2012 at 12:35 AM, Sam Lanning  wrote:
>
> On 11/04/2012 10:18 AM, Dave Airlie wrote:
>> On Sun, Nov 4, 2012 at 1:17 PM, Sam Lanning  wrote:
>>> Hey Everyone,
>>>
>>> I'm new sending questions to this list so please forgive me. I wasn't sure
>>> whether this should be directed at the devel list or users list.
>>>
>>> I am trying to get my DisplayLink adapter working with my Dell Vostro 3700
>>> laptop. With nvidia optimus card.
>>>
>>> I came across Dave Airlie's work on hot-swapping slave USB gpus. And
>>> discovered his git repo on freedesktop.org
>>>
>>> http://people.freedesktop.org/~airlied/prime-notes.txt
>>>
>>> I have tried to compile each of the parts (from the prime branch), but came
>>> across trouble with compiling a few of them.
>>>
>>> Mesa: The first problem occurred when i tried to autogen. It couldnt find a
>>> version of libdrm_nouveau greater than 0.6. I solved this with setting the
>>> environment variables:
>>>
>>> NOUVEAU_LIBS=/usr/lib/libdrm_nouveau2.so.2:/usr/lib/libdrm_nouveau2.so.2.0.0
>>> NOUVEAU_CFLAGS=empty
>>>
>>> so the make files were then generated fine.
>>>
>>> At compile time, make seems to get stuck in a loop constantly touching and
>>> rm-f ing depend. And entering and leaving the directory src/glsl/.
>>>
>>>
>>>
>>> The second compile problem occurs when trying to create the make file for
>>> xf86-video-nouveau. It comes up with this error after running autogen.sh
>>>
>>> ./configure: line 11987: syntax error near unexpected token `RANDR,'
>>> ./configure: line 11987: `XORG_DRIVER_CHECK_EXT(RANDR, randrproto)'
>>>
>>> Any help would be greatly appreciated.
>> Just get everything from upstream, nothing is in my personal branches
>> anymore. Everything should be released except for xrandr which you can
>> build from git.
>>
>> Dave.
>
> Ahh ok then,
>
> When i try and compile the current source from the repo
> git://anongit.freedesktop.org/xorg/app/xrandr i get some errors at
> compile time:
>
> xrandr.o: In function `main':
> .../xrandr.c:2969: undefined reference to `XRRSetProviderOffloadSink'
> .../xrandr.c:2965: undefined reference to `XRRSetProviderOutputSource'
> .../xrandr.c:3392: undefined reference to `XRRGetProviderResources'
> .../xrandr.c:3397: undefined reference to `XRRGetProviderInfo'
> .../xrandr.c:3404: undefined reference to `XRRFreeProviderInfo'
> collect2: error: ld returned 1 exit status

you need libXrandr.

Dave.
___
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: Display Link Adapter Hot-Swapping with xorg-server 1.13.0 and xrandr 1.4

2012-11-04 Thread Dave Airlie 
On Sun, Nov 4, 2012 at 1:17 PM, Sam Lanning  wrote:
> Hey Everyone,
>
> I'm new sending questions to this list so please forgive me. I wasn't sure
> whether this should be directed at the devel list or users list.
>
> I am trying to get my DisplayLink adapter working with my Dell Vostro 3700
> laptop. With nvidia optimus card.
>
> I came across Dave Airlie's work on hot-swapping slave USB gpus. And
> discovered his git repo on freedesktop.org
>
> http://people.freedesktop.org/~airlied/prime-notes.txt
>
> I have tried to compile each of the parts (from the prime branch), but came
> across trouble with compiling a few of them.
>
> Mesa: The first problem occurred when i tried to autogen. It couldnt find a
> version of libdrm_nouveau greater than 0.6. I solved this with setting the
> environment variables:
>
> NOUVEAU_LIBS=/usr/lib/libdrm_nouveau2.so.2:/usr/lib/libdrm_nouveau2.so.2.0.0
> NOUVEAU_CFLAGS=empty
>
> so the make files were then generated fine.
>
> At compile time, make seems to get stuck in a loop constantly touching and
> rm-f ing depend. And entering and leaving the directory src/glsl/.
>
>
>
> The second compile problem occurs when trying to create the make file for
> xf86-video-nouveau. It comes up with this error after running autogen.sh
>
> ./configure: line 11987: syntax error near unexpected token `RANDR,'
> ./configure: line 11987: `XORG_DRIVER_CHECK_EXT(RANDR, randrproto)'
>
> Any help would be greatly appreciated.

Just get everything from upstream, nothing is in my personal branches
anymore. Everything should be released except for xrandr which you can
build from git.

Dave.
___
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

Display Link Adapter Hot-Swapping with xorg-server 1.13.0 and xrandr 1.4

2012-11-04 Thread Sam Lanning 
Hey Everyone,

I'm new sending questions to this list so please forgive me. I wasn't sure
whether this should be directed at the devel list or users list.

I am trying to get my DisplayLink adapter working with my Dell Vostro 3700
laptop. With nvidia optimus card.

I came across Dave Airlie's work on hot-swapping slave USB gpus. And
discovered his git repo on freedesktop.org

http://people.freedesktop.org/~airlied/prime-notes.txt

I have tried to compile each of the parts (from the prime branch), but came
across trouble with compiling a few of them.

Mesa: The first problem occurred when i tried to autogen. It couldnt find a
version of libdrm_nouveau greater than 0.6. I solved this with setting the
environment variables:

NOUVEAU_LIBS=/usr/lib/libdrm_nouveau2.so.2:/usr/lib/libdrm_nouveau2.so.2.0.0
NOUVEAU_CFLAGS=empty

so the make files were then generated fine.

At compile time, make seems to get stuck in a loop constantly touching and
rm-f ing depend. And entering and leaving the directory src/glsl/.



The second compile problem occurs when trying to create the make file
for xf86-video-nouveau. It comes up with this error after running autogen.sh

./configure: line 11987: syntax error near unexpected token `RANDR,'
./configure: line 11987: `XORG_DRIVER_CHECK_EXT(RANDR, randrproto)'

Any help would be greatly appreciated.

Thanks,
Sam Lanning.
___
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